($and/ <==do note remove - switch for preventing MathML interpretation of dollar signs)


This page is for documenting common XDI graph patterns to test the proposed XDI 1.0 specifications against different common use cases.

GB 2010-01-12: unfortunately, this page has become a bit too hard to read, as now it is a mix of two different views. We have to work at a clean version... meanwhile I've submitted a note summarizing my viewpoint here, hopefully to be discussed during next phcs.

Graph Notation

Graph diagrams on this page use the following notation.


The following diagram illustrates how this notation is applied.


(original version available here)

Note the self-referential arc in the lower right-hand corner. This illustrates an XDI synonym -- an equivalent XDI address for the same XDI context node.

GB: I don't think that a self referential arc is the best way to visually depict XDI synonyms in a graph. I propose a different representation: a XDI synonym is a contextual arc (or a path made of contextual arcs and contextual nodes) that ends exactly at the same contextual node. This has been illustrated in the graph above with a blue arc - please note that the usage of a different color is only for illustration purposes and is not part of the proposal

DR 2010-12-23: I have reviewed the options and arrived at the conclusion that the self-referential arc is still the only logically consistent way for any XDI context node to be able to assert the *set of synonyms of which that node itself has knowledge*. Such synonyms are expressed as XDI statements in the form xdi-address/$/synonymous-xdi-address. Following the rules of the graph notation, where every first-segment subsegment represents a contextual arc, the only way to graph such a statement is to show a self-referential contextual arc at a context node that shows the name of the synonym (which may be multiple subsegments) as the name of the arc. Thus only self-referential contextual arcs may be multiple subsegments; all other contextual arcs must be single subsegments. This also explains why the root context node must have self-referential arcs to express synonyms -- they cannot originate from any other node.

Root Context Pattern

Any context node in the graph may have a synonym, including the root context node. XDI discovery works by looking up properties of the synonym for the root context node of any XDI document.


Note that this XDI document contains branches for both =abc and =xyz. This is typical, as an XDI document may contain a cache of XDI data for which it is not authoritative. A proposal is for authority for an XDI graph instance to determined by the XDI synonyms for the root -- in this case, the root (=abc) is an assertion that =abc is authoritative for this instance of the XDI graph.

GB: Though I agree that an XDI document may contain a cache of XDI data for which it is not authoritative, I am not sure that authority is determined by the XDI synonym for the root. I do not know enough about the resolution process you suggest, but maybe it would be productive to discuss it and check whether this is the only or best way to perform discovery.

DR 2010-12-23: Although a link contract could be used to express authority over a root context node, using a context reference in the form (xdi-address) provides a simple, elegant, and accurate way to express this authority that is compatible with the proposed XDI discovery method. In XDI discovery, the URIs for a XDI endpoint can be discovered by doing an XDI $get on the following XDI address: (context-authority-xri)$uri. This would return an instance of the Multi-Valued Property Pattern as illustrated below, where all of the literals are URIs for the XDI endpoint.

Relation Vs. Subcontext Pattern

One of the most basic patterns illustrates the difference between expressing a relation between two XDI subjects and creating a subcontext.


This graph in X3 Short:


XDI statements in this graph:


GB: for discussion here is what the statement $/$/(=abc) stands for and how you can read this in the graph?

DR 2010-12-23: The statement $/$/(=abc) is the assertion of a synonym for the root node of the graph. The subject $ is the root node, the predicate $ is the equivalence predicate, and the object (=abc) is the context of =abc. In the graph this appears as the self-referential arc on the root node.

In English, this is the difference between “ABC has a friend XYZ” (complete subject/predicate/object statement) and “ABC’s friend XYZ” (compound subject only).

Single-Valued Property Pattern

A single-valued property permits only one literal object, so it is the easiest form of expressing an XDI property. This diagram shows the +age predicate on =abc. It also shows how metadata about this predicate can be expressed -- in this case the datestamp +age$d.


(original version available here)

This graph in X3 Short:


XDI statements in this graph:


GB: do not agree with this way of modeling a property of a property. I think that a more uniform and understandable way could be:


This is clearer as it contextualizes the property +age in =abc, subjectifies it and declares one of its properties ($d) in a similar way as you assign a value to property +age of subject =abc. Consequently the diagram is a bit different, as it has a contextual arc labeled +age from node =abc to a second contextual node, then a literal arc labeled $d pointing to a literal node representing "2010-09-20T10:11:12Z".

DR 2010-12-23: See the notes from our last telecon.

Multi-Valued Property Pattern

A multi-valued property can accept multiple literal objects. Common examples are telephone numbers, email addresses, IM addresses, etc.

To support the increased complexity of multi-valued properties, the property is reified into a context, and XDI metagraph semantics are applied as follows:


(original version available here)

XDI statements in this graph:


Note that the objects in these XDI statements are local XRIs, i.e., they begin with the ! local context symbol. That means they are resolved local to the current context in which they appear, =abc+tel.

Though not shown in this diagram, metadata can be expressed the same way as in the single-value pattern -- for example, a datestamp on the !2 literal would be the !2$d literal.

Multi-Instance Subject Pattern (also Persona Pattern)

Many XDI subjects can have multiple instances. For example, a person may own multiple cars, in which case the +car subject would have multiple instances. A person can even have multiple instances of their digital "self" -- this is the concept of "persona".

This pattern is similar to the multi-valued property pattern but using XDI metagraph semantics are applied as follows:

The following example illustrates the persona pattern applied to the person with the XRI =abc.


(original version available here)

DR 2010-12-23: There is a structural problem with the Proposal graph on the right: it shows relational arcs to a literal node. A literal node can only be addressed through a literal arc. At present we do not have a way to do a cross-reference to a literal arc, but in the context graph model we have not yet needed one.

XDI statements in this graph:


Though not shown here, metadata on each instance subject can be expressed using literal arcs directly on the subject (e.g., a datestamp using a $d literal arc).

IMPORTANT: The semantics of "subject instance" (or "self"), as expressed by the $n contextual arc, mean that each child subject inherits its property values from the parent subject. However a property may be:

  1. Overriden by a child by including it on the child and specifying a different value for the property.
  2. Excluded by a child by including any of its sibling properties while omitting the excluded property.

Link contracts are how portable authorization works in XDI.

The following example illustrates the persona pattern applied to the person with the XRI =abc.


XdiGraphPatterns (last edited 2011-01-12 19:06:42 by giovanni.bartolomeo)