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: Minutes: XDI TC Telecon Thursday 1-2:30PM PT 2011-02-17


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

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

ATTENDING

Giovanni Bartolomeo
Drummond Reed
Joseph Boyle
Michael Schwartz


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


1)  STATUS OF XDI LITERALS

On last week's call, we discussed if we should we force all literals to  be encoded as XRIs, thus turning them into contexts. Drummond  subsequently posted a strong argument as to why we should not do this, but rather have clear syntax-level typing that distinguishes at the XDI  address level between a literal arc and a relational arc. His arguments are summarized in this email to the list:

  http://lists.oasis-open.org/archives/xdi/201102/msg00014.html

The following indented numbered pargraphs are key points copied from the message, followed by discussion:

    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.

Giovanni pointed out that there are some issues with literals in RDF. One of them is that they cannot currently serve as RDF subjects. Tim Berners-Lee has advocated that literals should be able to serve as a subject. http://www.w3.org/DesignIssues/RDF-Future.html

Drummond pointed out that in XDI, XDI literals can solve that problem because they are addressable. For example, the literal value of ABC's age can, in XDI, be referenced with an XRI that can serve as an XDI subject. This is done with a cross-reference: =abc/+age! -- which is the address of the literal, can in another context be referenced using the cross-reference (=abc/+age!).

Giovanni said that in this case what goes into the subject slot is a reference to a literal, not the literal itself.

Drummond agreed, but pointed out that if we want to support this, then we can specify an XRI encoding of a literal (presumably as a Data URI) which can be used as an XDI subject. The Data URI syntax is:

       data:[<MIME-type>][;charset=<encoding>][;base64],<data>

However that doesn't require us to get rid of literals altogether.

Joseph then asked a really good question, which is whether the XRI-encoded literal and the actual literal would be considered equivalent?

Giovanni noted an analogy to Java, where you have primitives, and then you have wrappers for primitives. These wrappers enable primitives to be used as Java objects.

So there would be two ways to express/represent a literal:

 * As the actual literal, e.g., "33"
 * As a cross-reference to a data URI representing the literal, e.g., (data:,33)

Joseph points out that this could introduce normalization problems if they are considered fully equivalent.

    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.

Giovanni said that the distinction is between when you want to talk about "the resource identified by the URI" ("referent") versus when you want to talk about the sequence of characters that compose the URI.

    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?

Giovanni asked a queston about expressivity of literals: In RDF, you have "typed" literals such as
"17"^^xsd:integer
"17.00"^^xsd:double
"17"^^xsd:string
In JSON instead there are only strings, numbers, true|false and null as literals.

Drummond points out that JSON datatyping does not override or eliminate the option of providing much richer XDI data typing (done through $! statements). But support for the native JSON datatypes in the JSON serialization format allows for very easy and efficient encoding of XDI literals that use those data types. An example in X2:

{
    =abc
        {
            +age
                "33"
            +age
                {
                    $!
                        +number!
}

    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, 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, and c) that "XRI-encoding" of literals be specified in the XDI 1.0 specs to use the Data URI encoding specified in RFC 2397 (http://tools.ietf.org/html/rfc2397).


2) NEW XDI GRAPH PATTERN DOCUMENT

Drummond uploaded a new version of the XDI Graph Pattern document to review.

  http://www.oasis-open.org/committees/download.php/41188/xdi-graph-patterns-2011-02-17.pdf
 
We did not have time to review it - we will do that on next week's call (or the week after if we don't hold a call next week).


3) NEXT CALL

Note that Drummond will be travelling in San Francisco and may not be able to make next week's telecon. He will send an email to the list.



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

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

* 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





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