XDI TC Minutes

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

Date: Friday, 27 February 2015 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Peter Davis
Les Chasen
Drummond Reed
Markus Sabadello
Joseph Boyle
Phil Windley

PRESENTATIONS/DISCUSSIONS

Handling Addresses of Collections in JSON-LD

We continued the topic suggested by Peter in the context of the “RDFifying XDI” project about referencing non-unique RDF predicates and the problem of signatures.

Peter said the JSON-LD signature spec that he checked does message-level signing, i.e., the whole JSON document, so it doesn’t contain a solution to “inner signatures”, i.e., signatures that only cover a branch of the document. Peter said that if the LSON-LD sig spec does not have answer, he will experiment with writing some code.

Glossary Updates

Drummond reviewed several updates to the Glossary wiki page:

https://wiki.oasis-open.org/xdi/Glossary

Drummond explained the definitions he added for various kinds of XDI addresses, including relative addresses. Joseph said he felt that the term “relative” was not used in very clear way and that it could mean different things. Drummond replied that the idea is to use the term similar to how it is used for URIs, but he will improve the definitions.

#ACTION ITEM: DRUMMOND to improve the Glossary definitions.

Core Spec Outline

Drummond and Joseph quickly reviewed the revised outline for the XDI Core 1.0 spec:

https://wiki.oasis-open.org/xdi/CoreSpecOutline

Besides refactoring and simplifying the sections explaining the node types and adding sections for Equivalence Relations and XDI Addressing, the final section on Serialization was refactored to reduce it to one wire format and three display formats. Peter said he did not think the JSON Pretty Print format needed a separate definition. Drummond agreed and removed it. That leaves just 3 serialization formats—one wire format and two display formats:

Statement format (display only)
JSON format (wire format)
JSON display format (display only)

Peer Roots and Inner Roots

In the context of reification, we had been assuming for some time that peer roots cannot appear after inner roots in an XDI address.

https://wiki.oasis-open.org/xdi/XdiAbnf

However Drummond explained that in the past week, he and Joseph and Markus had discovered clear use cases where a peer root node must follow an inner root. The easiest example is reification of a relational statement between two peer roots. Example:

(=a)/$ref/(=b)

To reify that statement, for example to add a timestamp, requires:

((=a)/$ref)(=b)<$t>/&/”2010-09-20T10:11:12Z"

To generalize, anytime a peer root is the object of a relational statement that needs to be reified, it will end out following the inner root in the XDI address. So the assumption that peer roots would always proceed inner roots no longer holds. Ironically, this will actually simplify the ABNF.

#ACTION ITEM: XDI CORE EDITORS to update the ABNF.

Canonical Graph Examples

We discussed the wiki page that Drummond started to develop a set of canonical XDI graph examples to use consistently throughout the specs.

https://wiki.oasis-open.org/xdi/ExampleGraphs

Drummond explained that he only just started the page, and was looking for feedback on the types of examples that should be included. The feedback from other TC members was:

Add a “service graph” to represent a software service or agent that has an independent identity (a * entity) but is not a physical device.
Instead of a graph representing a quantified-self device, use one representing a car, since that’s easier to understand and less complex and privacy-sensitive.
Add an example community graph showing a peer root registry.

We then talked about how these graph examples will be used. Peter suggested two objectives:

Start by describing a set of graphs and their specific features.
Then show how the graphs change as messages are applied.

As Peter put it, when put together, the chain of examples should “tell a complete story” about a use case that the reader can understand.

Drummond raised one other key issue that he encountered in preparing the first example graph, which he adapted from our quad tree serialization examples. The issue was that if we show examples of the actual XDI addresses we expect in the wild, they will have large, difficult-to-read UUIDs all over them. This is a major barrier to easy comprehension of the example graph.

Markus suggested truncating the UUIDs, which have done often in the past. However this can still be hard to read because the human semantic meaning of a node is not easily recognizable. After more discussion, we hit upon a solution: rather than just truncating the UUIDs, we should replace them with human-friendly labels that follow the :uuid: scheme. Example:

{
"/$isref": [
"([=])(!:uuid:alice)"
]
}
}

#ACTION ITEM: DRUMMOND to update the examples following this rule.

JSON Quad Tree Open Issue

Markus explained that he ran across an issue when implementing the JSON quad tree format. It appears when you have a common variable {} in an address, e.g.:

=a{}<#b>/&/"test"

Because the quad tree format splits the XDI subject into three parts—the graph root part, the entity part, and the attribute part—the question arises: in which part should the common variable appear? In other words, for the statement above, should the quad tree format look like this:

{
"=a{}": {
"<#b>": {
"&": "test"
}
}
}

Or like this:

{
"=a": {
"{}<#b>": {
"&": "test"
}
}
}

The same problem appears if the common variable (or any untyped variable) appears between a root node and entity node:

(=a){}=b/#c/=d

Markus explained that this problem doesn’t occur with a typed variable because you know the type of node it represents.

Markus proposed that the rule be that the common variable (or any untyped variable) always be included with the node that it follows.

#CONSENSUS: This is the rule to include in XDI Core.

#ACTION ITEM: DRUMMOND to update https://wiki.oasis-open.org/xdi/XdiQuadTreeSerialization.

Variable Matching Question

One final question arose at the end of the call with regard to the variable matching rules for the following two expressions:

=markus{}<#tel>
=markus{<#tel>}

The question is: do they both evaluate to the same set of matching nodes? Or does the first one specify a single match because it ends in concrete singleton?

We did not have time to close on this and will take it up on the email list.

NEXT CALL

The next call is next week at the regular time.

xdi message