Re: [xdi] Exciting development: XDI graph model documented - please indicate your syntax preferences!

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

On Thu, Apr 11, 2013 at 2:45 PM, Joseph Boyle <boyle.joseph@gmail.com> wrote:

On Apr 11, 2013, at 2:04 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

On Thu, Apr 11, 2013 at 9:50 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:

1. If values now have JSON semantics, and XDI collections are now always ordered, why not allow specification of the two-line street address as a JSON array? The following looks like a legal statement even under current syntax.

=markus+address!4567+&street#/#/
   ["123 Main St","Apt 23"]

In the latest iteration of the model there's no such thing as collections, only classes, and they can have both ordered and unordered instances.

In the unordered case are the instances individually tagged? If so the collection would correspond to a JSON object.

Yes. Which is why ever since your suggestion about looking at more intuitive JSON serializations last week, I've been playing with a simple concept: model every XDI graph node as a JSON object. All nodes except a literal node would look like this (where <xxx> is a placeholder):

{

    "<context-symbols>": "context-id",

   "contexts": [

         { <nested-json-object-for-each-context> }

         ]

   "relations": {

    "<predicate>": "<object>",

    "<predicate>": "<object>"

     }

 }

A literal node would look like this (if # was the symbol for a literal node):

{

    "#": {

        "#": <value>

      }

}

 

In general, the problem with your above XDI statement is that the two individual street lines do not have their own XDI addresses in the graph.

We could say that if a literal is a JSON array, then you could address its elements just like ordered XDI instances (e.g. =markus+address!4567+&street[1]), but that would be a pretty exceptional rule.

This is what I was assuming - it seemed natural and implementable, and if we want everything to be addressable and to minimize the conceptual gap between JSON and XDI data structures, why not allow addressing into a JSON value structure using equivalents of the familiar JS accessors.

It's a good and valid question. Here are the reasons:

1. To add color to Markus' first answer, as soon as you move XDI addressing into a literal, you lose a primary feature of the XDI graph model, which is that any entity or attribute can have subentities or subattributes.
2. Secondly, if an XDI literal value is a JSON array, there's already a way to address into the array using JSON. That's why I think it should be fine to allow both JSON objects and JSON arrays as XDI lteral values. In the JSON serialization, it's unambiguous what the JSON data type of an XDI liiteral is, so you "cross over" from XDI addressing to JSON Path addressing when you move into a literal value. But we need to keep the XDI and JSON Path addressing spaces separate because XDI addressing has different properties than JSON addressing.

 

2. If retrieving =markus+address!4567+&street# can return a JSON array or object, or a JSON single value depending on whether you previously set it to an array / set one or more of its array members, vs setting it to simply a single value, then we don't need a singleton marker to specify singleton vs. collection; in fact it would simply lead to an error if mismatch.

I think I would argue for not allowing JSON arrays or objects as literal values, only strings, numbers, boolean.

I disagree - I think we definitely want to allow JSON arrays and objects as XDI literal values, for several reasons including what I mentioned above. But the question Joseph asked is a non-sequitor. The XDI dictionary definition for &+street (I simply can't force myself to write it the other way around) will specify the datatype of a literal value. It's either a string or an array (or possibly an object). Whatever it is, that's what you will get back.

 

3. Also, while [1] is very recognizable syntax for array indexing, if we only allow integer constant indexes and not computed expressions, we shouldn't have to use a paired delimiter, which should be reserved for cases where we need to specify the end of _expression_ that would otherwise be ambiguous. # is a nonpaired delimiter that would also be a recognizable choice to precede an integer index into a collection.

I could imagine using a nonpaired delimiter

Me too. In fact there's a pretty good argument that only roots and variables should use paired delimiters because they are the only ones that allow grouping of subgraph identifiers.

In which case if we use # for that, we need to pick a different symbol for literals. (It never ends ;-) 

4. I still do not get why the entity vs. attribute distinction is needed and especially why it has to be explicitly specified in every XDI address.

 For dictionary purposes, but I'd defer to Drummond for giving a more elaborate answer to this question :)

We're going to get this question 1000 more times, so I've decided we need a wiki page devoted entirely to documenting the design decisions for the XDI graph model.

Wrt this question, here's the bullet points:

1. As Markus alludes, in an XDI dictionary, entities and attributes have different rules. Attributes can have literal nodes. Entities cannot. This is similar (if not identical to) the distinction between roots and subgraphs. Roots can be the context for other roots (peer roots, inner roots, statement roots). Subgraphs cannot. (It's also akin to the rule about classes and instances. Classes can have instances; singletons cannot.)
2. The same concept identifier (e.g., +email, $uri) can serve as both an entity (in some contexts) and an attribute (in other contexts). Example: =markus&+email (attribute). +email+server (entity). =drummond+website|$uri (attribute). @ietf$uri+spec (entity). Without the ability to specify whether a node is serving as an attribute or entity in a particular context, it is semantically ambiguous.

I'll start compiling these answers for the graph model FAQ page as we're definitely going to need it by IIW.

=Drummond