1

XDI Graph PatternsOASIS XDI TC Submission

Drummond Reed2012-03-22

This document contains illustrations of basic XDI graph patterns:

1. I-names, i-numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource

2. Single-valued simple contexts: contexts that accept a single data value and can describe versioning of that value

3. Multi-valued simple contexts: contexts that represent a one-dimensional array of single-valued contexts and can describe ordering and typing of those values

4. Complex contexts: contexts that represent a two-dimensional array of simple contexts and other complex contexts

5. Local graphs: statements that enable the global XDI graph to be distributed, discovered, and navigated across multiple locations on the network

6. Social graphs: relationships between XDI authorities

7. Personas and roles: complex contexts and relations that model contextual identity for individuals

8. Link contracts: contexts used for XDI authorization

9. Policy expression: a context with conditional logic for rules evaluation

10. Messages: XDI graphs used in the XDI protocol

2

XDI Graph Notation

Context node: Represents any logical context (see next page)

Contextual arc: Uniquely identifies a root or context node

Relational arc: Non-uniquely links root or context nodes

Literal node: Represents a leaf node containing data

Root node: Represents the root context of an XDI graph

Literal arc: Singleton arc that identifies a Literal node

Symbol Usage In RDF graph model?

✔

✖

✔

✔

✖

✔

3

Node hierarchy

Node

Literal Context Root

Ordinal

Simple

Multi-Valued

Complex

Literal nodes are the leaf points of the graph – the ones containing the raw data

Root nodes are the starting points of the

full 3-dimensional XDI graph

Simple contexts are 1-dimensional arrays

Complex contexts are 2-dimensional arrays of simple contexts and other complex contexts

Complexity

An ordinal context has exactly one relational arc used for ordering. Its XRI always begins with $*

A multi-valued context contains zero or more single-valued contexts of the same type and zero or more ordinal contexts

Single-Valued

A single-valued context has exactly one literal arc. Its XRI always begins with $!

I-names, i-numbers, and synonyms

=!0999.a7b2.25fd.c609

$1

4

=abc

()

=abc

=!0999.a7b2.25fd.c609

=!0999.a7b2.25fd.c609$1

+household

+home

=!0999.a7b2.25fd.c609+household

=!0999.a7b2.25fd.c609+home

The top two i-names are synonyms for the bottom i-number (a $number is a form of i-number)

Every non-root XDI node has exactly one canonical XDI address. A canonical equivalence relationship between two XDI context nodes (i.e., that they represent the same logical resource and thus their XDI addresses are “synonyms”) may be declared using a $is relational arc. (The inverse relation is $is$is.) When navigating the graph, an XDI processor is required to redirect to the target node of a $is relation before continuing.

This is the “I am” statement, i.e., a way for the local root of this graph to assert its own XDI address.

(=!0999.a7b2.25fd.c609)

$is

$is

$is$is

The XRI =abc, an i-name, is a synonym for the XRI =!0999.a7b2.25fd.c609, an i-number

5

Single-valued simple contexts

=!1111

“33”

$!(+age)

!

“2010-10-10T11:12:13Z”!

$v

$1

“32”!

“2010-09-09T10:11:12Z”

$!t

$2

Literal context +age

Literal value

Versioning subgraph

First version context

First version timestamp

Second version, which is also the current version

=!1111

=!1111+age

=!1111+age$!t

=!1111+age$v

=!1111+age$v$1

$is

$!t

!

First version value

timestamp subgraph

$v

=!1111+age$v$2

A single-valued context has a single literal arc to a literal node. It may also contain other contexts describing it (subproperties). The diagram below illustrates two standard XDI subproperties: a timestamp (also a single-valued context) and versioning (a complex context).

=!1111+age$v$1$!t

=abc

$is

=abc

$is() (=!1111)

(=!1111)

6

Multi-valued simple contexts

+tel

“+1.206.555.1111”!

$!1

$!2

“+1.206.555.2222”!

$*2

$*1=!1111+tel

=!1111+tel$!1

=!1111+tel$!2

=!1111+tel$!2$!t$!t

=!1111+tel$!2$v$v

…=!1111+tel$v

$v

…

+home

+home+fax

+work

A multi-valued context represents a set of single-valued contexts of the same type and optionally ordinals expressing their order. The example shown below is a phone number. Two instances are shown, =abc+tel$!1 and =abc+tel$!2. The i-numbers ($!1 and $!2) persistently identify each instance within the set. Ordinal contexts with i-names ($*1 and $*2) assert the unique order of these instances. Relational arcs describe the non-unique type of each instance, e.g., +home, +home+fax, and +work.

Single-valued context version subgraph – reflects changes to literal values only

Multi-valued context version subgraph – represents changes at this level only

=!1111+tel$!t$!t

… …

$is

$is

=!1111+tel$*2

=!1111+tel$*1

Two ordinal contexts, =abc+tel$*1 and =abc+tel$*2, assert the order of the two phone number instances

=!1111

=abc

$is

=abc

$is() (=!1111) (=!1111)

=!1111

7

Complex contexts

+passport

!

$1

$2

=!1111+passport

=!1111+passport$1

$!t

$v

…=!1111+passport$v

$v

…

+ca

+nz

A complex context represents a set of simple contexts and other complex contexts. Each instance of a complex context is another complex context. The example shown below is a passport. Two instances are shown, =abc+passport$1 and =abc+passport$2. (Ordering of these instances is not shown in this diagram, but uses the same ordinal pattern as with simple contexts.)

Complex context version subgraph – represents changes to this level only

Complex context version subgraph – represents changes to this level only

“2005-01-01T00:00:00Z”

“Canada”

“987654321”

“2010-10-01T00:00:00Z”

“New Zealand”

“123456789”

=!1111+passport$!t

$!t

……

!

!

!

!

!

$!(+country)

$!(+num)

$!(+expires)

=!1111+passport$1$!(+country)

$!t

$v

…

Simple context version subgraph – reflects changes to the literal value only

…

=!1111+passport$2$!(+expires)$!t

=!1111+passport$2$!(+expires)$v

=!1111+passport$2$!(+country)

=!1111+passport$2

=!1111$is

$is

=abc

$is

=abc

() (=!1111) (=!1111)

=!1111

$!(+country)

$!(+num)

$!(+expires)

Local graphs and XDI discovery

8

()

The XDI global graph is a single logical graph of which subsets are distributed across any network location (clients, servers, databases, etc.) Each subset, called a local graph, begins with a local root node, expressed as an empty XRI cross-reference, (). A local root node accessible on the network is called an XDI endpoint. A local graph may include XDI statements about the locations of other local graphs. This enables XDI clients to perform XDI discovery: navigation of the global graph by making XDI queries across a chain of local graphs to discover the URIs for other XDI endpoints.

(=!0222.e3f2.76cb.904a)

(@!0111.db4a.e317.7a12)

“http://xdi.example.com/(@!0111.db4a.e317.7a12)”

!

“http://xdi.example.com/(=!0222.e3f2.76cb.904a)”

This local graph contains two other roots describing the URIs of two other local graphs

$!($uri)

!

The $uri context is a property of a root

$is

“http://xdi.example.com/(=!0111.7af3.65d5.8cb7)”

!

$uri

(=!0111.7af3.65d5.8cb7)

$!1

“http://xdi2.example.com/(=!0111.7af3.65d5.8cb7)”

!

$!2

$!($uri)

9

Social graphs

=abc

(http://facebook.com/)

=xyz

+teammate

=abc is a teammate of =xyz in a Seattle soccer context

=abc is best friends with =xyz

=abc is friends with =xyz in the Facebook context

=abc

=xyz

+seattle

+best+friend

=xyz

+friend

+soccer

=xyz

(http://facebook.com/)

+seattle

+seattle+soccer

+seattle+soccer=xyz

Social graph expressed at the (=!1111) local graph, for which =abc is the authority

$is() (=!1111) (=!1111)

=!1111

$is

+seattle+soccer=!2222

=!2222

=!2222 $is

$is

=!2222 $is

=!1111

=!2222

(http://facebook.com/)=xyz

(http://facebook.com/)bob

XDI graphs can also express the relationships between XDI authorities in different contexts. This example illustrates the relationship between =abc (i-number =!1111) and =xyz (i-number =!2222) in a global context, in a Facebook context, and in a Seattle soccer context.

bob (http://facebook.com/)=!2222$is

10

Personas and roles

$1

$2

=!1111$1

+home

+work

Personas are an example of using complex contexts to model the identity of a person. In the example below, the person =!1111 (aka =abc) has two personas, =!1111$1 and =!1111$2. Each of these is an instance of =!1111. @!4444 (aka @example.co) is a company in which the =!1111$2 persona plays the role of president.

+president is a role that the persona =!1111$2 plays in the context of company @!4444

=!1111$2

=!1111

=!1111

$is

$is

“33”

$!(+age)

!

=!1111$!(+age)($)

@!4444

@!4444

@example.co

@example.co

$is +president

=!1111$1 and =!1111$2 are personas of =!1111 that enable =!1111 to control the sharing of portions of =!1111’s personal graph

The ($) variable relation allows graphs to be included in other graphs – in this case, the =!1111$2 persona includes =!1111+age

=abc

$is

=abc

$is() (=!1111)

(=!1111)

=!1111+work=!1111+home

11

Link contracts (1)

This root link contract permits the XDI subjects to which it is assigned to perform all XDI operations on the local graph

A link contract is a complex context used for XDI authorization. A link contract is defined by a$do context. Shown below is the “bootstrap” link contract in a graph, called a root link contract: a $do child of the root node. The $all relation that points back to the root asserts that the assignee(s) of this contract have “root access”, i.e., permission perform all XDI operations on the entire local graph.

=!0999.a7b2.25fd.c609

=abc

()

=abc

=!0999.a7b2.25fd.c609

(=!0999.a7b2.25fd.c609)

$is

$is

$do$do

(=!0999.a7b2.25fd.c609)

$all

$is$do

$is$do is the relation used to explicitly assign the permissions of a link contract to one or more XDI subjects

12

Link contracts (2)

$1

$2

=!1111$1

+home

+work

This diagram shows the addition of a link contract to the Personas and Roles diagram shown earlier. This link contract, created by =!1111 to control access to his/her =!1111$2 persona, gives the organization @!4444 $get (read) permission on that persona.

=!1111$2

=!1111

$is

$is

“33”

$!(+age)

!

=!1111$!(+age)($)

@!4444

@!4444

@example.co

@example.co

$is+president

This link contract gives the assignee(s) permission to do an XDI $get operation on the =!1111$2 persona, i.e., read anything in its subgraph

$do

$get

$is$do

The $is$do relation assigns this link contract to @!4444, which means people from that organization will be able to access the =!1111$2 persona

=!1111

=abc

$is

=abc

$is() (=!1111)

(=!1111)

Policy expression

$2

$do

13

$if begins the policy expression branch of a link contract

$and branches group policy instances that must all evaluate to true

$not branches group policies that must evaluate to false

(=!1111)

$or branches group policies of which at least one must evaluate to true

=!1111

$is

$if

$and

$or

$not

“{policy}”!

$!1

“{policy}”!

$!1

“{policy}”!

$!2

“{policy}”!

$!1

Policy expression is handled by the $if branch of link contracts. The three policy contexts are $and (all policies must be satisfied), $or (at least one policy must be satisfied), and $not (all policies must not be satisfied). They can be nested as needed for any boolean logic tree.

Link contract

14

Messages

(=!2222)

$do

$get

$add

“to” XDIlocal graph

Message instance

Message operations

Message envelope

“2010-12-22T22:22:22Z”

$!t

$1234

(=!2222)

=!1111

=!1111$msg

Message timestamp

Message context

()

$msg

=!1111

“from” XDI authority (sender)

=!1111$msg$1234

=!1111$msg$1234$!t

=!1111$msg$1234$do

(=!1111)

$is“from” XDI local graph

=!2222

=!2222$1$do

$1=!2222

(=!1111)

!

(!3)(=!1111)(!3)

XDI messages are XDI graphs sent from one XDI local graph (the “from” graph) to another local graph (the “to” graph) to perform an XDI operation (e.g., $get, $add, $mod, $!tel, $move, $copy). Every message must reference the link contract that authorizes the operation it is requesting. Note that the $add relation records the source graph for auditing purposes.

$get$do

$is()

Every message must include a $do reference to the link contract that authorizes the operation it is requesting, e.g., this message references the =!2222$1$do link contract for $get permission on the =!2222$1 persona

$do

$is$do

=!2222$1