XDI Graph Patterns

1. This document contains illustrations of basic XDI graph patterns: I-names, i-numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource Single-valued simple contexts: contexts that accept a single data value and can describe versioning of that value Multi-valued simple contexts: contexts that represent a one-dimensional array of single-valued contexts and can describe ordering and typing of those values Complex contexts: contexts that represent a two-dimensional array of simple contexts and other complex contexts Local graphs: statements that enable the global XDI graph to be distributed, discovered, and navigated across multiple locations on the network Social graphs: relationships between XDI authorities Personas and roles: complex contexts and relations that model contextual identity for individuals Link contracts: contexts used for XDI authorization Policy expression: a context with conditional logic for rules evaluation Messages: XDI graphs used in the XDI protocol XDI Graph Patterns OASIS XDI TC SubmissionDrummond Reed 2012-03-22

2. XDI Graph Notation Symbol Usage In RDF graph model? Root node: Represents the root context of an XDI graph ✖ Context node: Represents any logical context (see next page) ✔ Literal node: Represents a leaf node containing data ✔ Contextual arc: Uniquely identifies a root or context node ✖ ✔ Relational arc: Non-uniquely links root or context nodes Literal arc: Singleton arc that identifies a Literal node ✔

3. Node hierarchy Complexity Node Literal Context Root 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 Complex contexts are 2-dimensional arrays of simple contexts and other complex contexts Simple contexts are 1-dimensional arrays Simple Complex Single-Valued Ordinal Multi-Valued A multi-valued context contains zero or more single-valued contexts of the same type and zero or more ordinal contexts A single-valued context has exactly one literal arc. Its XRI always begins with $! An ordinal context has exactly one relational arc used for ordering. Its XRI always begins with $*

4. I-names, i-numbers, and synonyms 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. $is 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) =abc =abc The XRI =abc, an i-name, is a synonym for the XRI =!0999.a7b2.25fd.c609, an i-number =!0999.a7b2.25fd.c609 $is =!0999.a7b2.25fd.c609 +home =!0999.a7b2.25fd.c609+home +household =!0999.a7b2.25fd.c609+household The top two i-names are synonyms for the bottom i-number (a $number is a form of i-number) $is $is $1 =!0999.a7b2.25fd.c609$1

5. Single-valued simple contexts 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). $is () (=!1111) (=!1111) =abc =abc $is =!1111 $!(+age) =!1111 =!1111+age Literal context +age ! $is “33” Literal value $!t timestamp subgraph =!1111+age$!t ! “2010-10-10T11:12:13Z” $v Versioning subgraph =!1111+age$v $2 $1 =!1111+age$v$1 =!1111+age$v$2 First version context ! $v “32” First version value Second version, which is also the current version $!t =!1111+age$v$1$!t First version timestamp ! “2010-09-09T10:11:12Z”

6. Multi-valued simple contexts 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. $is () (=!1111) (=!1111) +home+fax “+1.206.555.1111” =abc =abc +home ! $is =!1111+tel$!1 $!1 $is =!1111 =!1111 Two ordinal contexts, =abc+tel$*1 and =abc+tel$*2, assert the order of the two phone number instances $*2 =!1111+tel$*2 +tel =!1111+tel$*1 =!1111+tel $*1 $is $!2 =!1111+tel$!2 +work ! “+1.206.555.2222” $!t $!t =!1111+tel$!2$!t =!1111+tel$!t … … $v $v =!1111+tel$!2$v =!1111+tel$v … … Multi-valued context version subgraph – represents changes at this level only Single-valued context version subgraph – reflects changes to literal values only

7. Complex contexts 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.) () (=!1111) (=!1111) =!1111+passport$1$!(+country) $!(+country) =abc ! =abc $!(+num) =!1111+passport$1 “Canada” $is ! =!1111 =!1111 $1 “987654321” $is +ca ! +passport $!(+expires) “2005-01-01T00:00:00Z” =!1111+passport $!(+country) =!1111+passport$2$!(+country) +nz $is ! $2 $!(+num) “New Zealand” ! =!1111+passport$2 “123456789” ! $!(+expires) “2010-10-01T00:00:00Z” $!t $!t $!t =!1111+passport$2$!(+expires)$!t =!1111+passport$!t … … … $v $v $v =!1111+passport$2$!(+expires)$v =!1111+passport$v … … … Complex context version subgraph – represents changes to this level only Simple context version subgraph – reflects changes to the literal value only Complex context version subgraph – represents changes to this level only

8. Local graphs and XDI discovery 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. $is () (=!0111.7af3.65d5.8cb7) $uri The $uri context is a property of a root $!1 ! “http://xdi.example.com/(=!0111.7af3.65d5.8cb7)” $!2 ! “http://xdi2.example.com/(=!0111.7af3.65d5.8cb7)” (@!0111.db4a.e317.7a12) This local graph contains two other roots describing the URIs of two other local graphs $!($uri) ! (=!0222.e3f2.76cb.904a) “http://xdi.example.com/(@!0111.db4a.e317.7a12)” $!($uri) ! “http://xdi.example.com/(=!0222.e3f2.76cb.904a)”

9. Social graphs 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. $is () (=!1111) (=!1111) Social graph expressed at the (=!1111) local graph, for which =abc is the authority =abc =abc $is =!1111 =!1111 =abc is best friends with =xyz =xyz =xyz +best+friend $is =!2222 =!2222 (http://facebook.com/) (http://facebook.com/) =abc is friends with =xyz in the Facebook context (http://facebook.com/)=xyz =xyz $is =!2222 +friend (http://facebook.com/)=!2222 bob $is +seattle =abc is a teammate of =xyz in a Seattle soccer context (http://facebook.com/)bob +seattle +soccer +seattle+soccer =xyz +seattle+soccer=xyz $is =!2222 +teammate +seattle+soccer=!2222

10. Personas and roles 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. $is () (=!1111) (=!1111) =abc =!1111$1 =abc $1 =!1111$1 and =!1111$2 are personas of =!1111 that enable =!1111 to control the sharing of portions of =!1111’s personal graph $is $is =!1111 +home =!1111+home =!1111+work =!1111 +work $is $2 The ($) variable relation allows graphs to be included in other graphs – in this case, the =!1111$2 persona includes =!1111+age =!1111$2 $!(+age) ($) =!1111$!(+age) @example.co ! “33” @example.co $is +president @!4444 +president is a role that the persona =!1111$2 plays in the context of company @!4444 @!4444

11. Link contracts (1) A link contract is a complex context used for XDI authorization. A link contract is defined by a$docontext. 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. $is () (=!0999.a7b2.25fd.c609) (=!0999.a7b2.25fd.c609) =abc =abc =!0999.a7b2.25fd.c609 $is =!0999.a7b2.25fd.c609 $all $do $do $is$do $is$dois the relation used to explicitly assign the permissions of a link contract to one or more XDI subjects This root link contract permits the XDI subjects to which it is assigned to perform all XDI operations on the local graph

12. Link contracts (2) 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. $is () (=!1111) (=!1111) =abc 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 =!1111$1 =abc $1 $is $is =!1111 +home =!1111 +work $get $is $2 $do =!1111$2 $!(+age) ($) =!1111$!(+age) ! “33” @example.co @example.co $is +president @!4444 $is$do @!4444 The $is$dorelation assigns this link contract to @!4444, which means people from that organization will be able to access the =!1111$2 persona

13. Policy expression 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. $is (=!1111) =!1111 $2 $do Link contract $if begins the policy expression branch of a link contract $if $and $and branches group policy instances that must all evaluate to true $!1 ! “{policy}” $or $or branches group policies of which at least one must evaluate to true $!1 ! $!2 “{policy}” $not ! “{policy}” $!1 $not branches group policies that must evaluate to false ! “{policy}”

14. Messages 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. $is “from” XDI local graph (=!1111) (!3) () (=!1111)(!3) (=!1111) “from” XDI authority (sender) =!1111 =!1111 $msg $add Message context =!1111$msg $1234 $is$do Message instance =!1111$msg$1234 $!t Message timestamp (=!2222) =!1111$msg$1234$!t $is() ! (=!2222) “2010-12-22T22:22:22Z” “to” XDIlocal graph Message envelope Message operations =!2222 $do =!2222 =!1111$msg$1234$do $get $1 $get 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 =!2222$1 $do =!2222$1$do