[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2015-02-20
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 20 February 2015 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Peter Davis
Markus Sabadello
Drummond Reed
Les Chasen
Phil Windley
Joseph Boyle
Peter brought up this topic in the context of the “RDFifying XDI” project. He explained that the problem is that in RDF, a subject can have multiple predicates that are identical. In JSON-LD, this is serialized as members of an array. But that means that they are only uniquely addressable and orderable in the context of that array, which could change in a different serialization.
Drummond said that this was the issue that the TC ran into during the period from roughly 2005 to 2007 in which it was trying to figure out how to do XDI in RDF. We never did solve it, and thus went on to develop the XDI graph model.
Markus said he had found a spec for signatures in JSON-LD. Peter said that in that case, those authors may have already a found solution.
#ACTION ITEM: PETER to read up on the JSON-LD signature spec and see how they solved the problem to enable “inner signatures” (signatures that don’t cover the whole document).
Markus pointed out that when the Higgins Project faced the same problem with trying to adapt RDF to XDI, they used content-based addressing to give each RDF predicate a unique ID. One problem with this, however, is that the ID changes when the value changes, which most of the time is not the behaviour you want.
JSON Quad Serialization Format
We further reviewed the XDI Quad Tree format, especially the handling of “implied” statements:
https://wiki.oasis-open.org/xdi/XdiQuadTreeSerialization
https://server.xdi2.org/XDIConverter
Drummond explained the current status of this proposed format, including
“solitary context nodes”: Always show them with an empty JSON object, independently of the “implied” parameter
“object-only context nodes”: Show them only if “implied=1”
Joseph asked about the current thinking on the double slash // entries in the JSON objects. Drummond replied that using adding the // explicit context statements, in conjunction with the object-only context nodes, in the implied=1 serialization format has two advantages:
Every single statement in the graph (contextual, relation, literal) will be explicitly visible in the serialization.
Every single context node in the graph will be serialized with exactly one JSON object, effectively producing the tree serialization format without requiring a separate MIME type for it.
Drummond also stated he doesn’t expect the “implied=1” setting to be used widely, but that in his view it still it made sense to have it for two reasons:
For use by “thin” XDI clients who want to be able to get the full graph with all statements and all context objects in order to be able to programmatically navigate it in certain ways (which we can’t know in advance, which is why it is so important to specify it very uniformly and precisely).
For teaching XDI, i.e., the quad tree implied=1 format will be to XDI graphs what “View Source” was to HTML.
Markus then created the following example where the current rules may lead to a non-intuitive serialization:
{
"=markus": {
"[<#tel>]<@0>": { },
"[<#tel>]<@1>": { },
"[<#tel>]<@2>": { },
"[<#tel>]<@3>": { },
"[<#tel>]<@4>": { }
}
}
{
"=markus": {
"<#home><#tel>": {
"$ref": [
"=markus[<#tel>]<@1>"
]
},
"[<#tel>]<@0>": { },
"[<#tel>]<@2>": { },
"[<#tel>]<@3>": { },
"[<#tel>]<@4>": { }
}
}
In the second case, the =markus[<#tel>]<@1> context node is seemingly “missing” from the list, because as an “object-only” context node, it is therefore not serialized inside its parent JSON object unless “implied=1”. Markus felt that the downside here is that there is no easy way to enumerate all attributes under the entity context node. Markus also mentioned that this example is probably not very realistic, given that here the attributes have no values. Peter reminded us that the seemingly “missing” entry in the root JSON object is actually a good thing, since it avoids duplication. Peter said that in an extreme case you may have a high number of relations that could lead to a much bigger serialization if all their context nodes had to be serialized separately.
Drummond also pointed out that this was another reason to specify and require support for the implied=1 option. If a developer has a a need for a serialization that enumerates all the attributes under an entity node, the developer just needs to ask for implied=1 and "[<#tel>]<@1>": { }, would reappear on the list above because it is an object-only context.
We then discussed inner root statements and whether they can be considered implied and therefore left out of serialization. At first Drummond said that he thought both of the XDI statements required for an inner root—the relational statement and the contextual statement—should be serialized because both are required to be in the graph. But then Markus pointed out that if that were the rule, then XDI messages and constructs such as link contracts would look bigger and more complicated when serialized.
Drummond and the rest of the TC members agreed with Markus. Thus the consensus was that only the essential statements and JSON objects representing context nodes should be shown when implied=0, and all statements and all JSON objects representing context nodes should be shown when implied=1.
That rule meant that we needed to decide, for inner root statements, which is the essential statement that must be shown when implied=0 and which is the implied statement that is only shown when implied=1. After some discussion, we agreed that the essential statement should be the relational statement because then the inner root node is covered by the object-only rule.
We created the following example using both the Statement and Quad Tree formats:
NON-EMPTY INNER ROOT
//(=a/#b) <-- only shows if implied=1
=a/#b/(=a/#b) <-- only shows if implied=1
(=a/#b)=x/#y/=z
{
"=a": {
"/#b": [ "(=a/#b)" ] <-- only shows if implied=1
},
"(=a/#b)": {
"=x": {
"/#y": [ "=z" ]
}
}
}
EMPTY INNER ROOT
//(=a/#b) <-- only shows if implied=1
=a/#b/(=a/#b) <-- always shows
{
"=a": {
"/#b": [ "(=a/#b)" ]
},
"(=a/#b)": { } <-- only shows if implied=1
}
At the conclusion of the discussion, we agreed that this was the end of known issues with the quad tree format.
#CONSENSUS that in the JSON quad tree format:
When implied=0, the serialization MUST only include:
Solitary context nodes (empty context nodes that are not the object of any relational statements).
Inner root relational statements.
When implied=1, the serialization MUST also include
All contextual statements (“//” predicate) for all context nodes
All object-only context nodes, which include any empty inner root nodes.
#ACTION ITEM: DRUMMOND and MARKUS to add the inner root examples to the quad tree format wiki page.
#ACTION ITEM: DRUMMOND to: a) add the inner statement rule to that page, and b) fix the object-only statements in the examples on that page.
#ACTION ITEM: XDI CORE EDITORS to specify this JSON serialization and display format, using the rules on the the quad tree format wiki page, in the next Working Draft.
We discussed the need to require single arc syntax for peer roots last week, but we did not finish closing on it. Drummond, Joseph, and Markus had the action item to discuss it and make a recommendation.
Drummond explained the core issue, which is that if multiple arcs are allowed inside the parentheses for a peer root address, it introduces a normalization nightmare. If there are only two arcs, there are two variants that need to be checked for equivalence:
(=a)(=b)
(=a=b)
But as soon as you go to 3 arcs, now there are four combinations that must be checked for equivalence:
(=a)(=b)(=c)
(=a=b)(=c)
(=a)(=b=c)
(=a=b=c)
And when you go to four arcs, it balloons to 7 combinations:
(=a)(=b)(=c)(=d)
(=a=b)(=c)(=d)
(=a=b=c)(=d)
(=a)(=b=c)(=d)
(=a=b)(=c=d)
(=a)(=b=c=d)
(=a=b=c=d)
And so on. In all cases, what is the normalized form to use for equivalence matching? And this “exploding normalization” problem is not just one of comparison for discovery, but for any semantic statement that includes a peer root node.
Drummond also summarized the argument he gave Joseph and Markus discussed about why inner root nodes, which do allow multi-arc subjects and predicates, are different than peer root nodes:
There is no discovery protocol for inner root nodes. To discover an inner root node, you must first discover the peer root that contains it.
Inner root nodes are a mechanism for reifying an XDI statement, so they must be able to have multi-arc subjects and multi-arc predicates. Peer root nodes have nothing to do with reification, but are much more like entity nodes or attribute nodes. And neither entity or attribute node syntax can contain more than one arc.
Peer root nodes are identified ONLY with contexual arcs ( just like entity, attribute, collection, definition, and variable nodes). The ONLY type of node that is identified with BOTH a contextual arc and a relational arc is an inner root node.
Peer root nodes all contain logically consistent portions of the common root graph. Inner root nodes do not—they are the only graphs that are not required to be logically consistent, because they can reflect one authority’s own view of the world.
Lastly, Drummond pointed out that if peer root node syntax could span more than one arc, it would be the only exception where a contextual statement consisting of only a subject, empty predicate, and object (vs. an inner root node contextual statement that does not an empty predicate) spans more than one arc. Entity, attribute, collection, definition, and variable nodes all follow the single-arc rule for the same reason—to prevent what otherwise would be hellish normalization and semantic equivalence nightmares.
The one exception—root node syntax—is an exception because it’s the only XDI address that consists of both a contextual arc and a relational arc.
For an example of what the single-arc peer root node syntax see:
https://wiki.oasis-open.org/xdi/XdiDiscovery
The other TC members agreed with these arguments, so this issue is now closed.
#CONSENSUS: Peer root node syntax is restricted to a single arc so that no normalization of peer root addresses is required.
#ACTION ITEM: XDI CORE EDITORS to update this in the ABNF of the next Working Draft.
Given that spec progress is picking up again, Peter and Drummond had a short discussion about drafting formats. As chair of the Editor’s Subcommittee, Peter reminded us that the editors had agreed that you can draft in any format you want, and when the draft is ready, it will be converted to Docbook format for publication.
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]