Open issue and proposal about XDI literals

[Drummond Reed <drummond.reed@xdi.org>]

XDI TC Members and Observers (and Cameron Hunt -- see below):

A second key topic was discussed on today's call that I agree to send a dedicated message to the list about: XDI literals.

Recent discussion on this list has highlighted that there is an option for any XDI literal node to be encoded as an XRI, and thus be turned into a context node.

On today's call, the question was raised: "What about the option of eliminating XDI literals entirely by forcing them to be encoded as XRIs?"

My own first reaction was that this seemed like an extreme step. I have done some further investigation and now feel even more strongly that way. Here are my reasons:

1) RDF has supported literal data nodes from the start, and to my knowledge, they are not controversial. Given Cam's wonderful feedback about the relationship of XDI and RDF three weeks ago (thank you again Cam for your excellent comments that you sent afterwards), I'm cc'ing him to find out if there have been any particular problems with RDF literals that we should be aware of.

2) Second, the distinction in RDF between URIs and literals as RDF objects (which corresponds to the distinction in XDI between XRIs and literals as XDI objects) has proved to be very valuable for certain use cases. See http://www.semanticoverflow.com/questions/2882/why-are-uris-sometimes-treated-as-literals-in-rdf. 

3) Thirdly, forcing all XDI literals -- which can be anything from a single byte to an entire encyclopedia -- to be encoded as XRIs seems like it ignores the thousands of other data encodings that already exist and can be productively used by XDI implementers.

4) Fourth, eliminating the potential for XDI literals to be different formats would essentially nullify the value of using the native JSON datatypes in our JSON serialization. We worked very hard last summer to enable this. Why would we want to give it up?

5) Fifth, XDI literals have a very special property: they are uniquely addressable. Non-literal XDI objects are not uniquely addressable because they represent context nodes, and context nodes can only be related to other context nodes using relational arcs, which are not unique. So forcing all literals into XRIs would give up the usefulness of literal arc uniqueness.

6) Lastly, one of the complaints about literals in XDI addressing is that they are not part of an XDI address, whereas in RDF, literals are part of an RDF statement -- they are the third node in an RDF triple. But this mixes up two different concepts. In RDF, a statement is always a triple consisting of three parts - the subject, predicate, and object, where the object can be either a URI or literal or blank node. I believe the same is true for an XDI statement, i.e., all XDI statements are triples consisting of the same three parts as RDF statements, and if the object is an XDI literal, then it is the third component of the statement. However an XDI statement is different from an XDI address. It is only XDI addresses that can consist of less than three XRI segments. And the XDI address of an XDI literal (one that does not include a cross-reference to the literal) consists of only two XRI segments, because the third segment (the object portion) that represents the actual literal is not part of the address. But it IS part of the XDI statement. That resolves any tension with RDF.

Having explained why I think we should not make any changes to XDI literals, let me explain why I support the new proposed requirement (illustrated in the XDI documents I uploaded last night) that, in the address of all XDI literals, the literal arc (the second XRI segment) MUST end in a single character segment consisting of !

The reason is that this gives us a clean way to support the option for ANY XDI literal datatype to be encoded as an XRI and therefore addressed using a relational arc instead of a literal arc.

The example I gave in the minutes below is a date. In its literal form it can be addressed as $d!, and in its XRI form it can be addressed as $d. Furthermore, an XDI dictionary can define both the literal form and the XRI form of any datatype, and both the dictionary and the instances will be unambiguously distinguishable everywhere. (Note that the dictionary definition of any other XRI that includes a date as an attribute will need to choose whether it wants to use the literal form or XRI form for the date attribute, otherwise the definition will be ambiguous.)

To conclude, my proposal is: a) no change to XDI literals, and b) a requirement in the XDI 1.0 specs that all XDI literals must be addressed using ! as a suffix on the XRI of the literal arc.

Thoughts?

=Drummond

On Thu, Feb 10, 2011 at 8:29 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Thursday, 10 February 2011 USA
Time:  1:00PM - 2:30PM Pacific Time (21:00-22:30 UTC)

ATTENDING

Michael Schwartz
Drummond Reed
Joseph Boyle
Giovanni Bartolomeo


THE GOTOMEETING FOR TODAY IS:
     https://www2.gotomeeting.com/join/969244355

THE IDEARPAD LINK FOR TODAY IS:
     http://xdi.idearpad.org/22

Please try to preface each of your comments with your name so the
transcription into the minutes is easier.


1) XRI AND XDI RESOLUTION QUESTION

Mike asked about XRI resolution and XDI resolution. Specifically about a first use case :

XRI xri = new XRI("=schwartz");
XRIServiceEndPoint[ ] endPoints = xri.getServiceEndPoint();

Drummond explained that to use today's XRI resolution infrastructure, you must do XRI 2.0 resolution, and get an XRDS document. You can then put an XDI endpoint in that XRDS document and "switchover" to XDI.

But he said that as soon as Gluu wants to, it can bring up an XDI endpoint doing "XDI resolution", which is really just standard XDI $get calls for the URI representing the XDI endpoint for any XDI-addressable context. For example:

XDISubject subject = new XDISubject("=schwartz")


2) NEW DOCUMENTS: XDI GRAPH PATTERNS AND XDI GRAPH MODEL

Drummond uploaded documents that illustrate the full set  of basic patterns using the XDI graph model as explained in Giovanni's last document. The first is a set of visual graph diagrams showing the  patterns for simple properties, complex properties, simple subjects,  complex subjects, link contracts, and messages.

  PDF: http://www.oasis-open.org/committees/download.php/41091/xdi-graph-patterns-2011-02-09.pdf
  PPTX: http://www.oasis-open.org/committees/download.php/41090/xdi-graph-patterns-2011-02-09.pptx

The second is an update to what used to be the XDI RDF Model  document, now just titled the XDI Graph Model, that includes the  metagraph symbol vocabulary:

  PDF: http://www.oasis-open.org/committees/download.php/41089/xdi-graph-model-2011-02-09.pdf
  DOC: http://www.oasis-open.org/committees/download.php/41088/xdi-graph-model-2011-02-09.doc

We started our review on the first document above.

Giovanni had a question about the use of the ! suffix to distinguish a predicate that identifies a literal. Drummond explained that this rule satisfies a practical need for XDI processors to be able to identify the address of a literal. This would apply whether the literal is encoded as an XRI or not.

Giovanni felt that the datatype represented by an XRI predicate should be referenced in a dictionary entry.

Drummond agreed but said that this additional "metatyping" information at the address level has another advantage: using the ! suffix provides the option for XRIs that can identify both the literal form and the XRI form of some data. For example, a date in literal form could be addressed as $d!, and in XRI form could be addressed as $d.

Giovanni suggested that the question of whether a ! suffix was required or not for addressing a literal should be an open issue that can wait until we first decide whether all literals can (or must) be encoded as XRIs. We discussed this briefly that there could be a  great number of benefits to treating all literals as contexts. In  addition, it is trivial to turn a literal context into an actual  literal.

Drummond will add this to the open issues list.

Drummond next ran through the simple property pattern, explaining how metadata is applied, and also how versioning is applied.

We discussed the difference between the proposal to use !1, !2, !n and using $1, $2, $n. Giovanni has had a specific semantic proposed for $n, which is that they are used for defining synonyms for the elements (properties or objects) that appear, in a given document, under the context they are applied to. Example:

=bob
   +friend
     =alice
     =trudy
   +age
     "33"

=bob$1 is a synonym of =bob+friend, =bob$2 is a synonym of =bob+age; =bob+friend$1 is a synonym for =bob+friend=alice,  bob+friend$2 is a synonym for =bob+friend=trudy.

Drummond pointed out that this will only work if the $numbers represent document order, because the XDI graph (like RDF graphs) is inherently unordered. However if the semantics of $n are defined to mean document order, that will work. This also means that *numbers can be used to express explicit ordering within the graph itself ("graph order").

Drummond noted that in his versioning examples, the version instances should be using *numbers for explicit ordering. He will make that change.

3) TINY BUT IMPORTANT REVISION TO THE JSON SERIALIZATION FORMAT

In  doing the documentation above, Drummond realized that the metagraph  symbol () should have been used instead of $ for serializing subcontexts  in the JSON serialization format. Originally it looked like either $ or  () could have been used, and $ seemed to make more sense. However as  the semantics of the metagraph symbols are becoming more rigourously defined, it is now clear that () is not only semantically accurate but  and solves one key semantic problem we would have had with using $.  We'll discuss on the call to make sure there is consensus on this.


4) NEXT CALL

The next call is next week at the regular time. Drummond hopes to have another major chunk of documentation completed and posted before that call.



------------
ONGOING ISSUES LIST

Each of these is a candidate for the agenda for future calls.

* STATUS OF XDI LITERALS

Should we force all literals to be encoded as XRIs, thus turning them into contexts?

* PROPOSED CONSTRUCTS/OPERATORS FOR XDI

Discuss the following wiki page originally posted by Giovanni:

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

* DICTIONARY STRUCTURE

Mike would like an example of the PDX dictionary as soon as we can do it.

*   EQUIVALENCE SEMANTICS

Close on whether we need an additional $ word that is the equivalent
of Higgins Personal Data Model (PDM)  semantics   of h:correlation,
which is not as strong as $is.

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

* COOL URIS

Continue previous discussion about the use of standard RDF URIs in XDI:

  http://lists.oasis-open.org/archives/xdi/201006/msg00023.html