[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2015-02-06
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 6 February 2015 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Peter Davis
Les Chasen
Drummond Reed
Markus Sabadello
Phil Windley
Joseph Boyle
We discussed the need for examples. Key conclusions:
We should create one canonical set of examples we can use throughout the specs (and with papers and primers such as the How XDI Builds on RDF paper).
We should put all example files, whether JSON docs or text files or image files of graphs directly into Git folder called Examples.
We should have one canonical overall example XDI graph that shows all the typical components, including link contracts.
We should have at least one pair of XDI graphs that show the full relationship between two XDI authorities, including the link contracts they have with each other. Ideally these will be pairs showing person-to-person connections, person-to-business connections, and person-to-thing connections.
Drummond also brought up JSON-LD and how it maps RDF into JSON. We discussed if XDI could mapped into JSON-LD in much the same way. Peter pointed out that this is what he and Hubert Le Van Gong had in mind. The key (literally) is mapping XDI addresses into the JSON-LD @id attribute. There was consensus that this was a very valuable approach.
Drummond updated the status of his work with Joseph on XDI Core 1.0:
Drummond submitted his edits to the first two sections to Joseph last night.
Joseph will be consolidating them with Joseph’s changes to produce the next draft.
Drummond will proceed with drafting the major new sections (new Introduction, XDI Visual Graph Notation, XDI Addressing, Equivalence Relations).
JSON Triples/Quad Serialization Format
Last week we reviewed a proposed XDI Triples serialization format. This led to more discussion and experimentation, out of which came a proposal for a “quad” serialization format. Drummond documented both a “nested graphs” and an “all flat” variation on this format.
https://wiki.oasis-open.org/xdi/XdiTriplesSerialization
https://wiki.oasis-open.org/xdi/XdiTriplesSerialization/Discussion
Drummond opened the discussion by explaining that it’s now being referred to as “quads” because the triples format last week did not actually show peer graphs, only inner graphs, and when peer graphs are included, it become directly analogous to RDF quads.
Drummond explained that the two new features in the XDI quad serialization format are:
Attributes have their own level in the JSON object structure. So there are 4 levels in the JSON object structure: 1st level = graph roots, 2nd level = entities and relations of the graph, 3rd level = attributes and relations of the entities, 4th level = values and relations of the attributes.
The unique fully-qualified XDI address of peer graphs and/or inner graphs are the “graph key” for addressing the JSON object representing the graph (“graph object”). Similarly, the unique fully-qualified XDI address of an entity is the “entity key” for addressing the “entity object”, and unique fully-qualified XDI address of an attribute is the “attribute key” for addressing the “attribute object”. Within an attribute object, “&” is the key for addressing the literal (if it exists).
We next discussed the differences between the “all flat” vs. “nested graph” variants.
In the all flat variant, there is only one graph key, just as there is for entity and attribute objects.
In the nested graph variant, there is one graph object for every graph root node.
Drummond explained the three reasons why he favors the “all flat” pattern:
JSON developers like less nesting.
This format closely mimics the structure of an RDF graph.
It is very efficient to find the JSON object representing any particular peer root or inner root by using a single graph key.
Joseph pointed out that they are both “nested”—one is just more nested than the other. Joseph also noted that this is the first time that we are breaking up addresses along the entity / attribute separation. We had never done this before, since entities and attributes are both contexts. However Markus then gave a demonstration of how XDI graph translate into RDF graphs in TriG and JSON-LD formats. In these formats, the data in RDF format looks structurally very similar to the all-flat quad format proposal. In both cases, an XDI subject is serialized only once (not repeated). Also in both cases, attributes are separate from entities, because an XDI entity translates to an RDF subject while an XDI attribute translates to a reified RDF predicate.
This demonstration produced a consensus that it makes sense to show the entity / attribute separation in an XDI serialization format. Since the nesting of JSON objects for each of the four levels forms a tree, Joseph proposed the name “quad tree” format. There was agreement on that name.
Drummond shared the view that the quad tree format represented the Goldilocks “just right” amount of nesting.
It is not completely flat, as that would be very verbose and hard to read.
It is not completely nested, as that would be very deep, inefficient to traverse, and hard to read (as is the case with the tree format, where there is one JSON object per XDI context node, and the parse format, where every XDI delimiter is represented).
Instead, it nests to exactly three levels in the common graph and four levels in contained graphs.
We asked whether it is correct and necessary to include XDI’s special syntax characters (e.g. the context symbols) in the RDF mapping, and whether this would require a lot of percent-encoding, which would reduce readability. Peter pointed out that he and Hubert had been working on an approach that would make XDI in JSON-LD format cleaner and more readable by “hiding” XDI’s special characters, e.g. by utilizing JSON-LD’s @context feature.
#ACTION ITEM: DRUMMOND to create additional quad tree serialization examples that show messaging formats.
#ACTION ITEM: JOSEPH, if he gets time, to create a proposal for a fully flat JSON serialization format.
Drummond also said that this work on serialization had finally answered a longstanding question about inner graphs: is the relational arc, representing the XDI predicate, from the inner graph subject node to the inner graph root node required?
His answer is “Yes”. This has an important implication: when an inner graph node is created as a new XDI context node, it always requires TWO XDI graph statements representing TWO arcs:
The contextual arc identifying the new inner graph node.
The relational arc pointing to this inner graph node from the subject node.
For example, to create the inner graph node (=a/#b) requires the following two XDI statements:
The contexual statement //(=a/#b)
The relational statement =a/#b/(=a/#b)
Drummond pointed out that merely creating the inner graph node (=a/#b) does not actually reify any XDI statements about XDI objects of =a/#b. That does not happen until you add an XDI subject below in inner root. For example, the statement (=a/#b)//=c represents a reification of the statement =a/#b/=c. However, it is not required to have the statement =a/#b/=c in the graph in order to reify it with the statement (=a/#b)//=c. That way, you can make statements about other statements that may not exist, or may be false. This case is explicitly called out in the Wikipedia page about reification.
Peter mentioned that he’s been looking at how to do RDF ordered sets. He asked for this topic to be put on the agenda for next week’s 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]