Two thoughts about what it will take to reach XDI 1.0 specs

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

Per the recent thread discussing the tension between the pragmatic
need to push out the first XDI 1.0 specs and the purist need to "get
the semantics right", I want to offer two thoughts that I've been
cooking on over the U.S. Thanksgiving break (no pun intended ;-)

1) ON THE RELATIONSHIP OF XDI AND RDF

On a recent TC telecon, we captured some points of consensus about the
relationship of XDI and RDF -- see the minutes of agenda item 1 listed
here:

   http://lists.oasis-open.org/archives/xdi/201011/msg00012.html

However I have been thinking about this more and am now more convinced
than ever that the XDI graph is an RDF graph in which: a) all
non-literal nodes are RDF blank nodes, and b) XDI provides a way to
address every blank node so that they can be used the subject or
object of conventional RDF statements (i.e., RDF statements that have
a URI for the subject or object).

In other words, what we have developed is an RDF graph where all the
nodes except literals are addressable blank nodes.

This is important because: a) it means defining the difference between
XDI and conventional RDF is not as hard as it might seem, but at the
same time b) it explains why there is so much you can do with XDI that
you can't do with conventional RDF (at least that we haven't figured
out yet).

It also means that there is in fact a straightforward way to
"decompose" an XDI graph into a conventional RDF graph with 100%
fidelity (meaning that from that RDF graph you could completely
reconstruct the corresponding XDI graph). The secret is that: a) the
deconstructed RDF graph will be filled with blank nodes (literally
every non-literal XDI node will become an RDF blank node), and b) that
the RDF graph will contain a number of RDF statements whose purpose is
to assert the identifier of each blank node (that use the XDI
metagraph vocabulary, below). So, even though the result is unusual
from the perspective of a conventional RDF graph, it is still a
conventional RDF graph, and thus something that conventional RDF tools
should be able to process to at least a limited extent.

Most importantly, it brings closure to the question about the
relationship of XDI graphs and RDF graphs, and provides a basis for
holding productive discussions with the RDF community about XDI as a
"branch" of RDF (even if this branch is considered a "wild child").

2) THE ESSENTIAL ROLE OF THE XDI METAGRAPH MODEL

The second contention is that I believe the only way we will reach an
acceptable set of XDI 1.0 specifications within the next two months is
by proceeding with the XDI metagraph model. This is the model
currently written up at:

 http://wiki.oasis-open.org/xdi/MetagraphSymbols

I make this contention for the following reasons:

1) This model is rooted in the fundamental structure of a directed
multi-graph. It is only possible with an addressable graph model,
which is why the semantics of the XDI metagraph model is so closely
tied to having an addressable RDF graph.

2) The properties of each of the metagraph symbols (previously, the
metagraph $words) have grown simpler and more consistent over time.
They each correspond to universal modeling constructs as shown by the
page Giovanni started at
http://wiki.oasis-open.org/xdi/XdiNewFoundation.

3) At and after Whistler, we found it was the simplicity and precision
of these symbols help us cut the Gordian knot of the XDI JSON
serialization format.

4) I'm working on a writeup now of how they can similarly solve the
problem of describing: a) multiple values of an XDI predicate (e.g.,
multiple phone numbers or email addresses, and b) multiple instances
of an XDI subject (e.g., multiple personas).

5) I can't envision how we could start from any other ontology and map
it into the addressable XDI graph structure, above all in a short
period of time.

6) By starting with a model that captures the basic graph
relationships, we can start experimenting and see what the XDI graph
model is and is not capable of expressing -- while at the same time
being reasonably sure that the model is sound.

I hope these observations are helpful - by all means let's discuss
here on the list and then continue on our call on Thursday.

=Drummond