OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Bill and Giovanni - special note about today's call


Bill and Giovanni:

Just a note to you both, since you were not able to attend today's call, about agenda item #3 below (RE the latest XDI Graph Patterns doc).

As two of the semantics experts on the TC, I wanted to call to your attention the proposal in this latest version that solves the single-valued vs. multi-valued contexts problem, i.e., can we avoid in an XDI dictionary having to define whether a context intended to represent a literal takes only a single value or multiple values.

For example, it would be ideal if +tel could simply be defined in the dictionary as:

  +tel/$is$a/$a$json$string

Note: there would be more statements in the dictionary than this one, e.g., XBNF, human-readable description, labels in various languages, etc. But my point is that it would be ideal if the dictionary definition did not by itself have to say anything about cardinality.

That has not been the case so far, i.e., if you saw the XDI statement =drummond+tel, you don't know whether it is referring to a single instance of a phone number or a set of phone numbers, i.e., whether it is single-valued or multi-valued. That is the equivalent in English of not being able to distinguish whether a noun is singular or plural.

In English, the solution is to do an algorithmic transformation from singular to plural by adding an "s" (of course there are many exceptions to the rule).

  Drummond's phone number  <== singular
  Drummond's phone numbers  <== plural

The proposed solution for XDI semantics is similar, just the other way around:
  1. All XDI "generic nouns" (definitions in the + space) are by definition plural (multi-valued), and there is an algorithmic transformation to make them singular:
  +tel <== plural
  $!(+tel)  <== singular

The origination of the proposal was the realization that if we specified that the $! space identifies ONLY single-valued instances of a class, then all XDI subject addresses that end in a subsegment that begins wtih $! identify literals. Similarly, all XDI subject addresses that end in a subsegment starting with $* would identify ordinals. For example, the following XDI addresses all represent single-valued contexts:

  =drummond$!(+tel)
  =drummond+address$1+street$!1
  =drummond+address$1+street$!2
  =drummond+address$1$!(+city)
  =drummond+address$1$!(+state)
  =drummond+address$1$!(+zip)

Whereas the following represent multi-valued contexts:

  =drummond+tel
  =drummond+address$1+street

Notice in these examples that an instance of a complex context, like =drummond or +address, is identified with a $number, e.g., $1, $2.

I am enthusiastic that this is a clean semantic solution for distinguishing between single-valued and multi-valued contexts.

Thoughts?

=Drummond

On Fri, Mar 23, 2012 at 10:01 PM, Drummond Reed <drummond.reed@xdi.org> wrote:
Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 24 February 2012 USA
Time:  9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


THE ETHERPAD LINK FOR TODAY IS:
     http://xdi.idearpad.org/57

ATTENDING

Mike Schwartz
Drummond Reed
Joseph Boyle
Markus Sabadello

GUESTS

Kari Lippert
Cameron Hunt


1) IDTRUST BUDGET PROPOSAL

Drummond had a call with the OASIS IDTrust member section staff.  This resulted in revisions to the proposal which we need to review:

  http://wiki.oasis-open.org/xdi/IdTrustProposal

Drummond said the key revisions needed were:
  • Clarification that deployment of the public test servers was a key step towards finishing the XDI 1.0 spec suite.
  • Clarification on the breadth of involvement of TC members.
  • Setting a deliverable date of the end of 2012, producing a final report at that time, and then optionally applying to renew in 2013.

There was a consensus that the proposal was ready to submit.

# DRUMMOND to send email to Dee.


2) OPEN SOURCE PROJECT UPDATES

Mike reported that the OpenXDI Project implemented binary storage, so that if a datatype is specified in the value of the data: URI, then it is now stored in a binary LDAP node. 

Mike also reported that no code change to OxServer or OxGraph is necessary to support literal contexts. It will result in a change to OxModel. The nested roots work is still waiting.

Markus reported that he's been doing some work on XDI Squared, and is next looking at implementing it on the Freedom Box, as there is a thread on the VRM mailing list about p2p usage of VRM.

Drummond said Phil Windley has published a blog post about how KRL (Kinetic Rules Language) is going to add XDI support, so that KRL will be operate on a consistent semantic data interchange layer.

  http://www.windley.com/archives/2012/03/krl_data_and_personal_clouds.shtml

This is very encouraging from both an adoption and engineering standpoint, as Phil is very well recognized as a technology pioneer.

# MARKUS, MIKE, DRUMMOND to create a page on the XDI TC wiki with a directory of the XDI open source projects.


3) UPDATED XDI GRAPH PATTERN DOCUMENT

Drummond uploaded a new version that solves one additional key issue:

  http://www.oasis-open.org/committees/download.php/45530/xdi-graph-patterns-2012-03-22.pdf 

The key issue was how to semantically distinguish single-valued contexts from multi-valued contexts. This not only makes it possible to algorithmically compose XDI addresses, but makes XDI dictionary  construction much easier. Drummond showed examples of both single-valued and multi-valued contexts, and the initial reaction was positive.


4) NESTED ROOT CONTEXTS

Mike asked about the use cases for nested root contexts. Drummond clarified the constraints:
  • Root nodes can only be subcontexts of other root nodes.
  • Every local graph still has only one local root node whose XDI address is (). All other root nodes must be nested under this.

The primary use case is XDI discovery, i.e., the ability to ask one local graph for metadata about another local graph, e.g., its URI(s). Such metadata could be considered cached, or it could be fully subscribed, since it is essentially a remote copy of self-description data.


5) XDI QUERY

Mike Schwartz and Yuriy Zabrovarnyy sent an email outlining why they  don't believe XML Path & JSON Path are good models on which we should based XDI Query:

  http://lists.oasis-open.org/archives/xdi/201203/msg00036.html

Mike clarified that having an XDI Path capabiility could be very useful, but on the client side, not on the server, i.e., it is much more feasible to implement on a return graph. 

It also needs to as efficient as possible on the network.

# MIKE will post a proposal on the XDI TC wiki and send an email to the list with a link for discussion. We will make this the focus of next week's call.


6) NEXT CALL

The next call is next week at the regular time.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]