The XDI Graph Basics
Physical
The XDI Universal Graph is the logical data
model by which resources and their associated
data are discovered, identified and accessed on
the Dataweb.
This does not imply anything about the native
data schema or physical storage mechanism!!
Logical
Type
Instance
Data
Any resource that can be associated with an XRI
is a candidate for inclusion in the XDI Graph
(although XDI does place some constraints on the
structure of the XRI)
The XDI Graph Basics
Physical
Logical
Type
Instance
Data
The proposed XDI Universal Schema stipulates that the XRI
element identifying an XDI Resource be made up of a combination
of 4 subelements:
•Physical Authority
•Logical Authority
•Type
•Instance
The XDI Graph Basics
The first Graph Element is Resource Nodes. These are depicted as
black circles.
Physical
A Resource Node is any point in the XDI Graph that is the parent of
either another Resource Node, a Link Node, or a Data Node. It can
also contain a reference to another Resource Node.
!!1010
Resource Nodes serialize into Resource Elements in the XDI
Universal Schema
Logical
Black lines depict authoritative relationships.
Type
Instance
Data
Authoritative Relationships are arcs where the Child Node is wholly
dependent for it’s existence on the Parent Node. If the parent is
deleted the child is also deleted. (This is analogous to a UML
Composition Relationship.)
The XDI Graph Basics
Physical
Logical
Type
Instance
!!1010
It is important to note that ‘labels’ (XRIs) actually name the arcs
(lines) between nodes not the nodes themselves. Space permitting I
always try to place the labels as close as I can to the arrow head of
an arc.
=andy
+Email
Resource Nodes at any level MUST have ONLY ONE authoritative
parent at the level above.
home
Data Nodes are depicted in green and CANNOT have children. They
are ‘Terminal Nodes’
XMLResource Nodes are also Terminal Nodes and are also depicted
as green dots.
Data
[email protected]
The XDI Graph Basics
A red dotted line shows a Reference (Ref). A Ref is a nonauthoritative relationship. It is a way of saying.. “My value is
the same as another node at this level. Whatever he says goes”.
It denotes equivalence.
Physical
The blue dotted line is a Backref. A Backref is the mechanism
by which a node knows (or shows) that it is referenced.
!!1010
Logical
=andy
Type
+Email
Instance
work
@ooTao
+Email
contact
In this example the ooTao contact email is delegated to Andy’s
work email so if Andy’s work email changes, ooTao’s contact
email will still be up to date.
Someone executing an XDI_get() for ooTao’s contact email
wouldn’t NEED to know that there is a Ref involved as the path
to the data could be expressed as:
xri://@ooTao/(+Email)/contact
Data
[email protected]
The XDI Graph Basics
Physical
!!1010
Logical
Type
=andy
@ooTao
+Email
+Email
These NOTES in red will show up from time to time.
These are statements that we believe to be ‘Theorems’
about the XDI Graph ( and should therefore be imposed
by the Schema whereever possible).
I highlight them as we are actively looking for the
exceptions that will disprove the rule.
contact
Instance
work
contact
Data
[email protected]
NOTE: Because a Ref denotes equivalence it can ONLY go
horizontally, i.e., across a level of the graph.
The XDI Graph Basics
Physical
!!1010
Logical
Type
Instance
@ooTao
=Andy
+Contact
+Email
email
work
The red dot is a Link Node. Links denote aggregation or
inclusion. (This is analogous to a UML Aggregation
Relationship.)
A red dot is similar to the English language concept of
‘includes’; in this example @ooTao’s contact email
includes =Andy’s work email, it can also include other
values.
=Andy/(+Email)/work
One way to express the XRI of ooTao’s contact email is
therefore;
Data
xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work)
[email protected]
Delegation Syntax
A’s Paths to C:
xri://=A*B/C
You may alternately use the =B synonym:
Physical
xri://=A*(=B)/C
!!1011
!!1012
Logical
=B
=A
B, =B
Type
Instance
Data
=B
C
XRI delegation syntax (* or !) is used when
one authority wants to provide a link to data at
another authority… It looks like C is coming
from =A (has a path rooted in =A), but C
comes from B.
Resources representing Physical Authority nodes – the
“root” of each instance of an XDI graph – can be linked
just like any other level. In this case the Refs shown are
links from a global registry representing the XRI 2.0
global context symbol (GCS) “!”. This registry has
assigned the i-numbers “!1012” and “!1011” to these two
Physical Authorities, so the absolute XRI paths are
“!!1012” and “!!1011”.
Versioning Syntax
Physical
!!1010
Logical
=Andy
+Email
Type
Instance
Versioning Syntax is a form of delegation that can occur at any
level. It represents an XRI cross-reference to the type “$v”
(for version), followed by a version instance.
!1
!2
Primary
$v/1
$v/2
Data
[email protected]
[email protected]
Virtual Nodes
We propose that XDI supports some special ‘Virtual
Node’ syntax; one example of the ‘Virtual Node’ syntax
is the $Current system word. This is an addressable
node at the Version level that signifies ‘get the latest
version’ .
Physical
!!1010
Logical
=Andy
This is a virtual node because there does not actually
need to be any node named $Current. For example;
+Email
xri://=Andy/(+Email)/Primary/($Current)
Type
should return the $v/2 node.
Instance
!1
!2
Primary
$v/1
$v/2
Data
[email protected]
[email protected]
Building the Dataweb
To start building any “tree” (instance) of the XDI graph
“forest” (Dataweb), you first need a Physical Authority
on which to root it. This Resource Node represents the
network endpoint through which other nodes on the
graph are addressable. Like any XDI Resource, it may
have multiple XRI synonyms.
Physical
!!1010,
http://xdi.example.com,
https://xdi.example.com
Logical
Type
Instance
Data
@ooTao
This Physical Authority represents an i-broker
addressable both via an abstract global independent
XRI (!!1010) and via two concrete URIs based on DNS
domain names.
A Physical Authority could be any network-addressable
endpoint, from a server farm to a cell phone to a
thermostat. The Dataweb abstracts all Physical
Authorities as peers, just like all IP addresses are peers.
Building the Dataweb
Physical
!!1010
!A2B3,
@ooTao*andy
@ooTao
Logical
andy
Type
Instance
Data
A Physical Authority registers and hosts
Logical Authorities (similar to the way a
PC can have multiple Users).
A Logical Authority can in turn register
other Logical Authorities. Note that while
the i-number “!A2B3” for the second
Logical Authority above is assigned by the
Physical Authority !!1010, the i-name
“andy” is assigned by the Logical Authority
“@ooTao”. Thus there are now 3 XRI paths
to this new Resource Node:
xri://!!1010/!A2B3
xri://!!1010/(@ooTao*andy)
xri://@ooTao*andy
Building the Dataweb
Here the @ooTao authority has resources
that are about ooTao. It has delegated
authority for Andy and Steven’s data to
other (local) Logical Authorities.
Physical
!!1010
steven
Logical
@ooTao
!A2B4,
@ooTao*andy
andy
Type
Instance
Data
!A2B3,
@ooTao*steven
+Phone
Support
+Email
Admin
+Phone
Work
+Email
Cell
Primary
+Email
Primary
Building the Dataweb
Physical
If Steven now registers a global iname, =Steven, we simply add a
synonym at the node. This synonym
represents a reference from the
Logical Authority represented by the
“=” registry.
!!1010
steven
Logical
!A2B3,
@ooTao*steven,
=Steven
@ooTao
!A2B4
andy
Type
Instance
Data
+Phone
+Email
Admin
+Phone
Work
+Email
Cell
Primary
+Email
Primary
Link Contracts
One of the primary goals of XDI is to provide
CONTROLLED access to data. The mechanism
for control is establishing ‘Link Contracts’
between logical authorities that define ‘rules of
engagement’.
Physical
!!1010
Logical
=Steven
+Email
Type
Instance
Home
In order to make data accessible via an XDI
Service one must create Link Contract Templates.
Link Contracts are used to establish “Rights
Paths” to data.
NOTE: Any Logical Authority can only respond
to requests on data (get, set, etc…) on Nodes
under it’s own authority. The establishment of a
‘Rights Path’ is the process of establishing a XRI
from one Logical Authority Node to a section of
the XDI graph under another Logical Authority
via an association node.
If Steven only had his one piece of data, what
might his Link Contract Template look like?...
(next slide)
Data
Link Contracts
The first step in establishing a Link Contract Template is
creating a permission path to the data.
In this example the Private contract permissions an XDI Get
path to =Stevens Home email via =Steven’s Personal
Dataset.
Physical
!!1010
This example is a little simplistic as it doesn’t have any
versioning syntax. See the next slide to see a more realistic
version of what a Contract Template might look like.
=Steven
Logical
Type
Instance
+Email
$Dataset
Home
Private
Personal
Home
Data
$Contracts
$Get
TODO: Somewhere there should be a $Policies node that can
be linked into the contract that stipulates the policies
governing the sharing of this data.
Link Contracts
This graph section is setup so that the Personal Dataset and
the Private Contract can both be independently versioned.
Physical
!!1010
=Steven
Logical
Type
Instance
+Email
$Dataset
$Contracts
Personal
Home
Home
$Get
$v/1
Private
$Get
$v/1
$v/2
$Set
Data
Here version 1 of the Private
Contract permissions Get on the
Personal Dataset and version 2
permissions both Get and Set on the
same dataset.
In this example $Get is repeated in
both versions of the contract, so we
theorize that there may be ‘delta’
syntax that would let v2 reference v1
and specify only the differences
between them.
Link Contracts
In order to show ‘permissioning’ we need another
Logical Authority to ‘permission’
I am intentionally showing a case where both entities
are at the same Physical Authority so we don’t (yet)
have to deal with replication across Physical
Authorities.
Physical
!!1010
=Steven
Logical
=Andy
Type
Instance
+Email
Home
$DataSet
$Contracts
Private
Personal
In order to save space and simply illustrate
the concepts I have gone back to the simple,
non-versioned, depiction of the Link
Contract Template.
Work
$Get
Data
+Email
Link Contracts
By adding the $Assoc (association) node we are saying that
=Steven has a relationship with =Andy. The link between the
=Steven/($Assoc)/(=Andy) node and the
=Steven/($Contracts)/Private node establishes the contract
instance that specifies the permissions.
Now =Andy CAN access =Stevens data but hasn’t yet.
Physical
!!1010
=Steven
Logical
=Andy
Type
Instance
+Email
Home
$Dataset
$Contracts
Private
Personal
$Get
Data
+Email
$Assoc
=Andy
Work
Link Contracts
When =Andy agrees to the contract,
=Andy’s digital signature of the contract is
captured within =Stevens graph and =Andy
creates an association node that completes
the creation of the Rights Path.
Physical
!!1010
=Steven
Logical
=Andy
Type
Instance
+Email
Home
$Assoc
$Dataset
$Contracts
Private
Personal
$Assoc
+Email
$Sig
=Andy
Work
(=Steven/($Assoc)/(=Andy))
$Get
Data
=Andy Signed copy of the contract
Link Contracts
The Rights path explicitly states the privileges to the Data Node (# 1 from Andy’s perspective and #2 from
=Steven’s perspective)
1) xri://=Andy/($Assoc)/((=Steven/$Assoc/(=Andy))*($Contracts/Private))*($Get)*(=Steven/(+Email)/Home))
2) xri://=Steven/$Assoc/(=Andy)*($Contracts/Private)*($Get)*(=Steven/(+Email)/Home))
Physical
!!1010
=Steven
Logical
=Andy
Type
Instance
+Email
Home
$Assoc
$Dataset
$Contracts
Personal
$Get
Private
$Assoc
+Email
$Sig
=Andy
Work
(=Steven/$Assoc)/(=Andy))
=Steven/(+Email)/Home
$Contract/Private
Data
=Andy Signed copy of the contract
TO DO:
Physical
Logical
Type
Instance
Data
The Following slides are place holders for functional
areas that we still need to consider in depth. I consider
these headings future sections that may each be several
slides in length.
Link Contracts – More Complex Example
The Biz Card contract permissions an Entity to Get ‘Support Phone’ and ‘Work Email’. What would I do if I
want to permission the Admin contract to Get the same 2 thing AND Set ‘Work Email’?
Physical
Logical
Type
Instance
Data
Option 1) Have 3 Links from Admin/($V/1), one that Refs each of the permission nodes. You could then link
an $Assoc node to just that contract.
Option 2) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work Email’ node. You would then
need to link an $Assoc node to BOTH contract to provide all the permission.
Option 3) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work Email’ node and add a Link at
the Instance level from the Admin contract to the Biz Card contract. You could then link an $Assoc node to
just the Admin contract to get all the permissions.
Link Contracts – Permissioning a Community
Physical
Logical
Type
Instance
Data
Resolving Synonyms – Unifying the Graph
Physical
Logical
Type
Instance
Data
Removing a path - $Deleted?
Physical
Logical
Type
Instance
Data
Delta Syntax - $Include and $Exclude?
Physical
Logical
Type
Instance
Data
Questions:
•Is, and if so how, authentication expressed in the XDI Graph?
•Should +Type words (Dictionary Words) be constrained to Singular or Plural, and if yes, which?
•Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?)
•Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer?
Physical
Logical
Type
Instance
Data