xdi graph patterns
DESCRIPTION
This document contains XDI introductory materials plus illustrations of many standard XDI graph patterns: I-names, i -numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource - PowerPoint PPT PresentationTRANSCRIPT
1
XDI Graph PatternsOASIS XDI TC Submission
Drummond Reed2012-07-06
This document contains XDI introductory materials plus illustrations of many standard XDI graph patterns:
1. I-names, i-numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource
2. Remote graphs and XDI discovery: statements used to describe and navigate the distributed global XDI graph
3. Social graphs: relationships between XDI authorities
4. Attribute singletons: contexts that contain a single literal value and can describe versioning of that value
5. Attribute collections: contexts containing a collection of attribute singletons
6. Entity singletons: contexts containing a single entity
7. Entity collections: contexts containing a set of entity singletons
8. Personas and roles: entities and relations that model contextual identity for individuals
9. Link contracts: entities and relations used for XDI authorization
10. Policy expression: conditional logic for rules evaluation
11. Messages: XDI graphs used in the XDI protocol
12. Dictionaries: machine-readable XDI ontology definitions
2
XRI context symbols
Globally unique identifiers controlled by legal organizations (trademarks)
Globally unique identifiers controlled by standard bodies (e.g., XDI grammar)
Globally unique identifiers controlled by the general public (generic nouns)
Globally unique identifiers controlled by natural persons
Symbol Meaning Examples
=
@
+
$
Context
Individual
Institutional
Generic
Specific
@neustar@kynetx
$and$or
+photo+email
=drummond=windley
Global Context Symbols
Locally unique identifiers that may be reassigned to different resources over time (“i-names”)
Locally unique identifiers that are assigned to a resource once and never reassigned (“i-numbers”)
Symbol Meaning Examples
!
*
Context
Immutable
Mutable *susan*back.forty
!1234!4c3f.87e2
Local Context Symbols
An identifier assigned in one context being reused in another context
Symbol Meaning Examples
() (http://example.com/)@kynetx+customer(http://example.com/)
Cross-References
3
XDI Graph Notation
Context node: Represents any entity or attribute within the graph
Contextual arc: Uniquely identifies a context node
Relational arc: Non-uniquely links context nodes
Literal node: Represents a leaf node containing data
Root context node: Represents the starting point of an XDI graph
Literal arc: Singleton arc that identifies a Literal node
Symbol Usage In RDF graph model?
✔
✖
✔
✔
✖
✔
4
Simple examples
=alice
“+1-206-555-1212”
$!(+tel)
!
“2010-10-10T11:12:13Z”
!
=alice
=alice$!(+tel)
=alice$!(+tel)$!($t)$!($t)
=bob
+friend
=bob
()
(=bob) (=bob)
relational
“value”literal
contextual
contextual
contextual
contextual
contextual
“value”literal
local root
remote root
context
context
context
context
literal
literal
$!($uri)
“http://xdi.example.com/bob”!
(=bob)$!($uri)
“value”literal
contextual
contextliteral
5
JSON serialization (1){ "=alice/+friend": [ "=bob" ], "(=bob)$!($uri)/!": [ ”http://xdi.example.com/bob" ], "=alice$!(+tel)/!": [ "+1-206-555-1212" ], "=alice$!(+tel)$!($t)/! ": [ "2010-09-20T10:11:12Z" ]}
6
JSON serialization (2){ "(=!1111.2222.3333.4444)/$is": [ "()" ], "=example/$is": [ "=!1111.2222.3333.4444" ], "=!1111.2222.3333.4444/$is+": [ "+person" ], "=!1111.2222.3333.4444/+friend": [ "=example2", "=example3*john.smith", "(mailto:[email protected])", "(http://example.com/friend)" ], "=!1111.2222.3333.4444$!(+age)/!": [ 33 ], "=!1111.2222.3333.4444$!(+vegetarian)/!": [ true ], "=!1111.2222.3333.4444+favorite$!(+colors)/!": [ "red", "blue", "green" ], "=!1111.2222.3333.4444+address$*(+street)$!1/!": [ "123 Corliss Ave N" ], "=!1111.2222.3333.4444+address$*(+street)$!2/!": [ "Apt 42" ], "=!1111.2222.3333.4444+address$!(+city)/!": [ "Seattle" ], "=!1111.2222.3333.4444+address$!(+state)/!": [ "WA" ], "=!1111.2222.3333.4444+address$!(+postal.code)/!": [ "98133" ]}
7
Multiplicity
Node
Context
SubgraphRoot
Entity Singleton
Attribute
Attribute Collection
Entity
Leaf nodes of the graph that contain the raw data
Starting nodes of the graph – may be
local or remote
Contains zero or more attributes
and zero or more entities
Contains zero or more attribute
singletons of the same type
Attribute Singleton
Contains zero or one literal node
Entity Collection
Contains zero or more entity
singletons of the same type
Literal
All nodes that provide context for
the data
Nodes that are neither starting nor leaf nodes
8
Multiplicity and dictionary syntax
Concept English syntax
Class – plural
Instance – plural
Class definition
Instance - singular
Class – singular
Class specialization
Specialized class definition
XDI syntax
photos
the photos
a photo
the photo
photo
color photoFlicker photo
a color photoa Flicker photo
$(+photo)
$*(+photo)
+(+photo)
$!(+photo)
+photo
+color+photo+(@flicker)+photo
+(+color)+(+photo)+(@flicker)+(+photo)
I-names, i-numbers, and synonyms
=!0999.a7b2.25fd.c609
!1
9
=abc
The local root node address is ()
=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
Every non-root XDI node has exactly one canonical XDI address. A canonical equivalence relationship may be asserted between two XDI context nodes (i.e., that they represent the same logical resource and thus their XDI addresses are “synonyms”) 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
Remote graphs and XDI discovery
10
()
The XDI global graph is a single logical graph of which subsets are distributed across a unlimited set of network locations (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 describe other remote XDI graphs by including XDI statements describing remote root nodes. 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 describes two remote roots each with a URI attribute singleton
$!($uri)
!
This $uri attribute collection is a property of the local 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)
The “I am” statement where the local root node describes its own identifier(s) using a $is relation
11
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 *bob in the Facebook context
+seattle
+best+friend
*bob
+friend
+soccer=xyz
Social graph expressed at the (=!1111) local graph, for which =abc is the authority
$is() (=!1111)
=!1111
$is=!2222
!a726df $is
$is
=!2222 $is
XDI graphs can 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, *bob in a Facebook context, and in a Seattle soccer context.
$is
12
Attribute singletons
=!1111
“33”
$!(+age)
!
“2010-10-10T11:12:13Z”!
$*($v)
$!1
“32”!
“2010-09-09T10:11:12Z”
$!($t)
$!2
Attribute singleton +age
Literal value
Versioning subgraph
First version context
First version timestamp
Second version context, which is also the current version
$is
$!($t)
!
First version value
Timestamp subgraph
$v
An attribute singleton has a single literal arc to a literal node. It may also contain other contexts describing it (subproperties). An attribute singleton is always prefixed with $!. The diagram below illustrates a person's age, $!(+age), with two standard XDI subproperties: a timestamp and a versioning subgraph.
$is
=abc
$is() (=!1111)
13
Attribute collections
$*(+tel)“+1.206.555.1111”
!$!1
$!2
“+1.206.555.2222”!
$*2
$*1
$!($t)
$*($v)
…
$($v)
…
+home
+home+fax
+work
An attribute collection represents a set of attribute singletons of the same type and optionally ordinals expressing their order. An attribute collection is always expressed as a cross-reference prefixed with $*. Each member is a subcontext identified with an i-number prefixed with $!. The example shown below is a phone number with two instances, =abc$*(+tel)$!1 and =abc$*(+tel)$!2. Ordering of these instances is done with ordinal contexts – i-names in the form $*n, where n is a unique number. Relational arcs describe the non-unique type of each instance, e.g., +home, +home+fax, and +work.
Version subgraph – reflects changes to literal values only
Version subgraph – reflects changes at this level only
$!($t)
… …
$is
$is
Two ordinal contexts, =abc$*(+tel)$*1 and =abc$*(+tel)$*2, assert the order of the two phone number instances
$is
=abc
$is() (=!1111)
=!1111
14
$*(+tel)
“+1.206.555.1111”!$!1
$!2
“+1.206.555.2222”!
$*2
$*1
+home
+home+fax
+work
Attribute singletons and attribute collections may be used together to express the full semantic richness of contextual data. This example illustrates how the XDI graph for a person (=abc) can express his/her default, work, home, and home fax telephone numbers.
$is
$is
$is
=abc
$is() (=!1111)
=!1111
$!(+tel)
Combining attribute singletons and attribute collections
+home
+work
+fax
$!(+tel)
$!(+tel)
$!(+tel)
$is $is $is $is
15
Entity singletons
+passport
$($v)
…
An entity singleton represents a single instance of an entity. Like a single noun in the English language, it does not use any prefix. The example shown below is +passport. It contains three attribute singletons: a country string, a number string, and an expiration date.
Version subgraph – represents changes to this level only
“2010-10-01T00:00:00Z”
“New Zealand”
“123456789”
$!($t)
…
!
!
!
$!($t)
$*($v)
…
Version subgraph – reflects changes to the literal value only
…
$is
=abc
() (=!1111)
=!1111
$!(+country)
$!(+num)
$!(+expires)
$is
16
Entity collections
$(+passport)
!
$(!1)
$(!2)
$!($t)
$($v)
…
$($v)
…
+ca
+nz
An entity collection represents a set of entities of the same type. An entity collection is always expressed as a cross-reference prefixed with $. Each member is a subcontext identified with an i-number in the form $(!n), where n is an i-number. The example shown below is a set of passports. 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 pattern as with attribute collections.)
Version subgraph – reflects changes to this level only
Version subgraph – reflects changes to this level only
“2005-01-01T00:00:00Z”
“Canada”
“987654321”
“2010-10-01T00:00:00Z”
“New Zealand”
“123456789”
$!($t)
……
!
!
!
!
!
$!(+country)
$!(+num)
$!(+expires)
$!($t)
$*($v)
…
Version subgraph – reflects changes to the literal value only
…
$is
$is
$is
=abc
() (=!1111)
=!1111
$!(+country)
$!(+num)
$!(+expires)
$is
17
Personas and roles
$(!1)
$(!2)
*home
*work
Personas are an example of using entities to model the identity of a person. In the example below, the person =!1111 (aka =abc) has two personas, $(=!1111)$(!1) and $(=!1111)$(!2). @!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) $is
$is
“33”
$!(+age)
!
($)
@!4444
@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 subgraphs to be included in other graphs – in this case, the $(=!1111)$(!2) persona includes =!1111$!(+age)
$is
=abc
$is() (=!1111)
=!1111
18
Link contracts (1)
This root link contract uses the $all relation to permit the XDI authorities to which it is assigned to perform all XDI operations on the local graph
A link contract is an entity 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 local root node. The $all relation pointing back to the root asserts that the assignee(s) of this contract have “root access”, i.e., permission to perform all XDI operations on the entire local graph.
=!0999.a7b2.25fd.c609
()
=abc
(=!0999.a7b2.25fd.c609)
$is
$is
$do$all
$is$do
$is$do (the inverse of the $do relation) is the relation used to explicitly assign a link contract to one or more XDI subjects
19
Link contracts (2)
$(!1)
$(!2)
*home
*work
This diagram shows the addition of a link contract to the previous Personas and Roles diagram. This link contract, created by =!1111 to control access to the $(=!1111)$(!2) persona, gives the organization @!4444 $get (read) permission on that persona.
$(=!1111) $is
$is
“33”
$!(+age)
!
($)
@!4444
@example.co
$is+president
$is
=abc
$is() (=!1111)
=!1111
$do
$get
$is$do
The $is$do relation assigns this link contract to @!4444, which means people from that organ-ization will be able to access the $(=!1111)$(!2) persona
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
Policy expression
$(!2)
$do
20
$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}”!
$!2
“{policy}”!
Policy expression is handled by the $if subgraph of a link contract. 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). These can be nested as needed for any boolean logic tree.
Link contract
Each policy is a Javascript statement that may include standard XDI graph references“{policy}”
!
$!1
21
Messages
(=!2222)
$do
$get
$add
“to” XDI remote graph
Message singleton
Message operations
Message envelope
“2010-12-22T22:22:22Z”
$!($t)
$(!1234)
=!1111
Message timestamp
Message collection
()
$($msg)
“from” XDI authority (sender)
(=!1111)
$is“from” XDI local graph
$(=!2222)
$(!1)
!
(!3)
XDI messages are XDI graphs sent from the local XDI graph (the “from” graph) to remote XDI graph(s) (the “to” graph(s)) to perform an XDI operation (e.g., $get, $add, $mod, $del, $copy, $move). Every message must reference the link contract authorizing the operation(s) 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 authorizing the opera-tion(s) it is requesting. For example, this message references the $(=!2222)$(!1)$do link contract for $get permission on the $(=!2222)$(!1) persona
$do
$is$do
22
Dictionaries (1)
+(+age)
“{XBNF statement}”!
“2010-09-09T10:11:12Z”
$!($t)
The global + context is the root of the XDI literal type tree
Dictionary statements may be timestamped and versioned like any other XDI graph
!
XBNF (XDI BNF) is a version of ABNF in which statement components can be XRIs. This provides 100% machine readability of the structure of the literal data
$is+ statements define supertype relationships
XDI graphs containing XDI ontology statements are called XDI dictionaries. They are machine-readable definitions of entities and attributes. Attribute types are defined by reference to the XDI literal type tree, which includes the datatypes defined in JSON, XML, and MIME. Entity types are built up from attribute types and other entity types.
+
$is() (+)
$json
$number
!
$is+
$*($xbnf)
$!1
“{XBNF statement}”!
$!2
All branches of the XDI literal type tree end in !$xml
$mime
23
Dictionaries (2)
+(+passport)
“{XBNF statement}”!
The XBNF for this definition of +num overrides the XBNF in the global definition
$!($*) is the dictionary context for multiplicity – it takes a literal expression that defines the cardinality of a subcontext
An entity type is defined using definitions of attribute types and/or other entity types. Note that these “definitions in context” may override the global definition. For instance, in the example below, the definition +(+num) in the context of the definition of +(+passport) overrides the global definition of +(+num) by providing its own specific XBNF. All other properties of the global definition still apply.
$is() (+)
+(+num)
$!1
“{XBNF statement}”!
$!2
+(+country)
+(+expires)
“1”!
$!($*)
$*($xbnf)“1”
!
“1”!
$!($*)
$!($*)
Values correspond to cardinality notation in UML, e.g., “1” means exactly one
24
Dictionaries (3)
+(+person)
Relations for a context are defined using the dictionary context $has. Multiplicity of a relation is defined the same way as multiplicity for a subcontext. Note that complex relations can be defined, e.g., +(+best+friend).
$is() (+)
$has
“1”!
$!($*)
+(+mother)
“1”!
$!($*)
+(+father)
“0-n”!
$!($*)
+(+friend)
“0-1”!
$!($*)
+(+best+friend)
25
Extra Examples
Device identity
26
()
This pattern represents an approach to putting a device on the XDI graph. Since a device, such as a GPS transponder, may change ownership over time, the device is identified with a URI using the URN UUID schema. The XDI root node is identified using a cross-reference to this UUID. At any point in time, this cross-reference may be put in the context of a specific owner, such as =!2222. Data output by the device is in a subgraph in the context of the device identity. This subgraph is identified with an i-number which is cross-reference to the UUID.
“http://xdi.example.com/(uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)/”
!
$!($uri)
$is
(urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)
(=!2222)
(urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)
$is
!(urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)
+sensor
+accuracy
+gps
@!1111
$(+location)
$is+
$(!1)
Sensor attributes…
…
…
Accuracy attributes
Location event instances