January, 12 2011 - The following is an informal note containing a brief but accurate explanation
of my viewpoint on the main global graph concepts. Backward compatibility with RDF is
highlighted and explained whenever it occurs. Please provide any feedback to
[email protected]
There are three kinds of arcs, contextual, relational and literal.
Relational and literal arcs are similar to the corresponding arcs in RDF links (RDF triples
connecting one subject, one predicate and one object). If the graph contained only those types of
arcs, it would be quite similar to an ordinary RDF graph (depicted in black in the following picture.
Gray colour is used for illustration purpose only and is not part of the notation).
root context
literal
“literal”
relational
Instead, contextual arcs do not exist in RDF graphs. They are an XDI/XRI specific extension.
Contextual arcs represent composite subjects (identifiers made of two or more subsegments).
root context
contextual
context
literal
contextual
“literal”
context
contextual
relational
context
Synonyms - in RDF graphs traditionally expressed through the owl:sameAs property - are
represented by arcs (or paths made of arcs and nodes) pointing to the same node. The following
graph illustrates two identifiers which are synonyms; the first identifier (in gray colour) is made of
one single subsegment and the second one (in black) consisting into a two subsegments.
root context
contextual
context
contextual
contextual
context
Single value properties instance1 are represented by a relational or literal arc pointing to either a
node or a literal. Multiple value properties property instances are represented by relational or literal
arcs each of them pointing to a different node (or literal).
=abc
“33”
+age
+friend
=jkl
+friend
=xyz
To identify one particular property instance in the context of one particular subject, the contextual
mechanism is used. To see this, consider the above graph which can be expressed in wired format
as a set of X3 triples:
=abc/+age/“33”
=abc/+friend/=jkl
=abc/+friend/=xyz
Suppose one wants to identify the two properties instances +age and +friend in the context of
=abc (they are classified, respectively, as an instance of a single literal value property and an
instance of a multiple value relational property).
=abc+age
=abc+friend
=abc/+age/“33”
=abc/+friend/=jkl
=abc/+friend/=xyz
1
We use the term “property instance” to distinguish it from “property”. In fact, a property, in its own, does not have any
value; it is only whenever it is instantiated, e.g. put in the context of a given subject, that it can be assigned one or more
values.
The contextual mechanism, by definition, assigns these property instances the following two XRIs
=abc+age
=abc+friend
In the graph notation, they are represented as it follows:
=abc
+age
+friend
Note that contextual (solid) arcs are used instead of relational (dashed) arcs (the contextual
mechanism always uses solid arcs).
Identifying a particular property instance is the first to express “something” (i.e. metadata) about it.
Once the original property instance has been uniquely identified through the contextual mechanism,
one can simply reuse the relational or literal mechanism seen above to provide metadata statements.
Example of such statements include but not limit to: $d statement, expressing timestamps, or $n
statements, conveying information about the number of values pointed by that property instance. An
example in graph notation follows.
=abc
+age
+friend
“2010-09-20
T10:11:12Z”
$d
$n
“2”
In wired format:
=abc+age/$d/“2010-09-20T10:11:12Z”
=abc+friend/$n/”2”
As well, the contextual mechanism can be used to uniquely identify one particular object (i.e. a
property value) in the context of a triple
=abc+father=def
=abc/+father/def
In wired format, assuming that the object in the statement =abc/+father/=def has to be
identified, the unique identifier assigned to that object is
=abc+father=def
Note that =def identify a different entity than =abc+father=def, as the first may have
different properties, different property values and different access control policies than the latter. In
the graph notation, the two identifiers are associated to two distinct nodes.
=def
+father
=abc
=abc
+father
By its own definition, a multi value property instance - whether literal or relational - consists in a
property instance that has many values. In the graph notation, it is represented by many outgoing
dotted or dashed arcs2, each of these incoming to different nodes or literals which are generically
referred as values (or “object values”).
=abc/+friend/=jkl
=abc/+friend/=xyz
2
It is not a design goal to assign an identifier to each instance of the same property appearing in the context of the same
subject. In fact, in X3 simple notation, no distinction is made between them, as in the following example.
=abc
+friend
=jkl
=xyz
However, it is considered a goal to uniquely identify each object value in the context of the same property instance, as it
will be illustrated in the following.
=xyz
+friend
=abc
+friend
=jkl
+friend
In case of object values being context nodes (not literals), the contextual mechanism is used to
assign their own identifiers:
=abc+friend=jkl
=abc+friend=xyz
Graphically, they look as it follows:
=xyz
=abc +friend
+friend
=jkl
=xyz
+friend
=jkl
Object values may also be accessed using the following synonyms
=abc+friend$1
=abc+friend$2
Which uses the $1, $2, etc. accessory operators to identify the target object value. The following
diagram describes the resulting graph (gray colour is only used to improve the diagram readability,
but is not part of the standard notation).
=xyz
=abc +friend
$2
+friend
=xyz
=jkl
+friend
=jkl
$1
The same applies to multi value property instances pointing to literal values: the two telephone
numbers in the following example:
=abc/+tel/”+1234567890”
=abc/+tel/”+1098765432”
+tel
+tel
=abc
+tel
are assigned the identifiers:
=abc+tel$1
=abc+tel$2
+tel
+tel
$2
=abc
+tel
$1