Table of Contents:

1.X Change Log2.X Graph Basics3.X Special Forms in the XDI Graph6.X Dataweb Example7.X Link Contracts8.X Contract Exchange Process9.X Linking and Embedding10.X Permissioning a Community 11.X Resolving Synonyms – Unifying the Graph 12.X Removing a path - $Deleted? 13.X Delta Syntax - $Include and $Exclude? 14.X $word Usage15.X +word Usage16.X Universal Schema Representations20.X Questions

Physical

Logical

Type

Instance

Data

1.1 Changes:

DocumentVersion/Date Slide Affected New, Revised, Deleted

Summary of Change (Primary Author) Change Request

V 0.2 7.5,7.6 R Added Link from =Andy/$assoc/=Steven and named it $link (AD)

V 0.2 8.x N Caching (AD)

V0.2 7.9 N Introduce $public instance of $Contract

V0.2 2.8 N Logically split the levels.

V0.2 4.2 D Removed Virtual Node slide. I now consider $current to be explicit. (There may be other virtual nodes later… $parent, ??)

V0.2 7.2 R Changed $Dataset to +Dataset. This really is an App construct not a global one. Any app can call it’s grouping mechanism whatever it wants, it is still a valid target for a $op Ref.

V0.2 7.6 R Removed the $sig branch of the tree, preferring to put the signature as data in the $assoc branch instead. Seems cleaner to me.

V0.2 7.7 R Tried to correct the xris… again

V0.2 8.X N Started step by step evaluation of contract exchange.

V0.2 14.X N Description and example of different $words

V0.2 7.8 N Infinite recursion

Physical

Logical

Type

Instance

Data

1.2 Changes:

DocumentVersion/Date Slide Affected New, Revised, Deleted

Summary of Change (Primary Author) Change Request

V 0.3 20.1 R Updated answers to old questions (AD)

V 0.3 7.10 N Invalid Access (this would be bad)

V 0.3 16.X N Representations of the Universal Schema

V 0.3 2.5 R Updated definition of Ref

V 0.3

V 0.3

V 0.3

Physical

Logical

Type

Instance

Data

2.1 The XDI Graph Basics

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!!

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 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!!

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)

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 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

Physical

Logical

Type

Instance

Data


The first Graph Element is Resource Nodes. These are depicted as black circles.

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.

Resource Nodes serialize into Resource Elements in the XDI Universal Schema

The first Graph Element is Resource Nodes. These are depicted as black circles.

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.

Resource Nodes serialize into Resource Elements in the XDI Universal Schema

!!1010

Black lines depict authoritative relationships.

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.)

Black lines depict authoritative relationships.

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.)

Physical

Logical

Type

Instance

Data


!!1010

Resource Nodes at any level MUST have ONLY ONE authoritative parent at the level above. Resource Nodes at any level MUST have ONLY ONE authoritative parent at the level above.

=andy

+Email

home

[email protected]

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 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.

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.

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.

Physical

Logical

Type

Instance

Data


!!1010

=andy

+phone

home

510-456-7878

@ooTao*andy

contact

+email

[email protected]

A red dotted line shows a Reference (Ref). A Ref is a non-authoritative relationship. It is a way of saying.. “The graph at the references target is a sub-section of my graph”. It denotes a union.

The blue dotted line is a Backref. A Backref is the mechanism by which a node knows (or shows) that it is referenced.

A red dotted line shows a Reference (Ref). A Ref is a non-authoritative relationship. It is a way of saying.. “The graph at the references target is a sub-section of my graph”. It denotes a union.

The blue dotted line is a Backref. A Backref is the mechanism by which a node knows (or shows) that it is referenced.

+phone

work

510-445-5124

This implies that an XDI_get() on @ootao*andy would return one phone number and one email address. An XDI_get() on =andy would return 2 phone numbers and an email address.

Q: How are we going to resolve collisions? Proposal: We use the value at the Source node of the ref.

This implies that an XDI_get() on @ootao*andy would return one phone number and one email address. An XDI_get() on =andy would return 2 phone numbers and an email address.

Q: How are we going to resolve collisions? Proposal: We use the value at the Source node of the ref.

Physical

Logical

Type

Instance

Data


contact

NOTE: Because a Ref denotes equivalence it can ONLY go horizontally, i.e., across a level of the graph.NOTE: Because a Ref denotes equivalence it can ONLY go horizontally, i.e., across a level of the graph.

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 wherever possible).

I highlight them as we are actively looking for the exceptions that will disprove the rule.

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 wherever possible).

I highlight them as we are actively looking for the exceptions that will disprove the rule.

!!1010

=andy

+Email

work

[email protected]

@ooTao

contact

+Email

Physical

Logical

Type

Instance

Data


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.

One way to express the XRI of ooTao’s contact email is therefore;

xri://@ooTao/(+Contact)/email*(=Andy/(+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.

One way to express the XRI of ooTao’s contact email is therefore;

xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work)

!!1010

=Andy

+Email

work

[email protected]

@ooTao

email

+Contact

=Andy/(+Email)/work

Physical

Logical

Type

Instance

Data


!!1010

=Andy

+Email

work

[email protected]

@ooTao

email

+Contact

=Andy/(+Email)/work

Andy =Andy/(+Email)/work

@ooTao*Andy

You can actually imagine that each level is split into 2 sub-levels. The top sub-level is for Resources and the lower is for Links.

Drawn this way, a Black Line, an Authoritative Relationship should always traverse down either 1 or 2 levels.

You can actually imagine that each level is split into 2 sub-levels. The top sub-level is for Resources and the lower is for Links.

Drawn this way, a Black Line, an Authoritative Relationship should always traverse down either 1 or 2 levels.

NOTE: A link MUST have a synonym that is equal to the XRI that is addressed by the Links Reference.

NOTE: A link MUST have a synonym that is equal to the XRI that is addressed by the Links Reference.

Physical

Logical

Type

Instance

Data

A’s Paths to C:

xri://=A*B/CYou may alternately use the =B synonym:

xri://=A*(=B)/C

A’s Paths to C:

xri://=A*B/CYou may alternately use the =B synonym:

xri://=A*(=B)/C

=B

3.1 Delegation Syntax

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.

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.

=A

!!1011!!1012

C

B, =B =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”.

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”.

Physical

Logical

Type

Instance

Data

3.2 Versioning Syntax

!!1010

=Andy

+Email

Primary

$v/1

[email protected]

$v/2

[email protected]

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.

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

Physical

Logical

Type

Instance

Data

6.1 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.

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.

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.

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.

@ooTao

!!1010, http://xdi.example.com,https://xdi.example.com

Physical

Logical

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/!A2B3xri://!!1010/(@ooTao*andy)xri://@ooTao*andy

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/!A2B3xri://!!1010/(@ooTao*andy)xri://@ooTao*andy

@ooTao

!!1010

andy

!A2B3,@ooTao*andy

Physical

Logical

Type

Instance

Data


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.

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.

@ooTao

!!1010

andy

steven

+Phone

Support Admin

+Email

Work

+Email +Email+Phone

Cell Primary Primary

!A2B3,@ooTao*steven

!A2B4,@ooTao*andy

Physical

Logical

Type

Instance

Data


If Steven now registers a global i-name, =Steven, we simply add a synonym at the node. This synonym represents a reference from the Logical Authority represented by the “=” registry.

If Steven now registers a global i-name, =Steven, we simply add a synonym at the node. This synonym represents a reference from the Logical Authority represented by the “=” registry.

@ooTao

!!1010

andy

steven

+Phone

Admin

+Email

Work

+Email +Email+Phone

Cell Primary Primary

!A2B4

!A2B3,@ooTao*steven,=Steven

Physical

Logical

Type

Instance

Data

7.1 Link Contracts

!!1010

=Steven

+Email

Home

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’.

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)

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’.

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)

Physical

Logical

Type

Instance

Data

7.2 Link Contracts

!!1010

=Steven

+Email $contract

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.

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.

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.

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.

Home

+Dataset

Personal

$get

Private

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.

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.

Home

Physical

Logical

Type

Instance

Data

7.3 Link Contracts

!!1010

=Steven

+Email$contract

This graph section is setup so that the Personal Dataset and the Private Contract can both be independently versioned.

This graph section is setup so that the Personal Dataset and the Private Contract can both be independently versioned.

Home

+Dataset

Personal $get $v/1 Private

$v/2$set$v/1

$get

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.

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.

Home

Physical

Logical

Type

Instance

Data

7.4 Link Contracts

!!1010

=Steven

+Email$contract

Home

+DataSet

Personal

$get

Private

=Andy

+Email

Work

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.

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.

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.

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.

Physical

Logical

Type

Instance

Data

7.5 Link Contracts

!!1010

=Steven

+Email$contract

Home

+Dataset

Personal

$get

Private

=Andy

+Email

Work

$assoc

=Andy

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/($contract)/Private node establishes the contract instance that specifies the permissions.

Now =Andy CAN access =Stevens data but hasn’t yet.

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/($contract)/Private node establishes the contract instance that specifies the permissions.

Now =Andy CAN access =Stevens data but hasn’t yet.

Physical

Logical

Type

Instance

Data

7.6 Link Contracts

!!1010

=Steven

+Email$contract

Home

+Dataset

Personal

$get

Private

=Andy

+Email

Work

$assoc

=Andy

=Andy Signed copy of the contract

$assoc

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.

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.

$assoc

$link

=Steven

Physical

Logical

Type

Instance

Data

7.7 Link Contracts

!!1010

=Steven

+Email$contract

Home

+Dataset

Personal

$get

Private

=Andy

+Email

Work

$link

=Andy


$link

$link

=Steven

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*($link)*(=steven/($contract)/private))*($get)*(=Steven/(+Email)/Home)2) xri://=Steven/($assoc)/=Andy*(=steven/($contract)/Private)*($get)*(=Steven/(+Email)/Home)

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*($link)*(=steven/($contract)/private))*($get)*(=Steven/(+Email)/Home)2) xri://=Steven/($assoc)/=Andy*(=steven/($contract)/Private)*($get)*(=Steven/(+Email)/Home)

Physical

Logical

Type

Instance

Data

7.8 Link Contracts – Reciprocal Relationships

!!1010

=Steven

+Email$contract

Home

+Dataset

Personal

$get

Private

=Andy

+Email

Work

$assoc

=Andy


$assoc

$link=Steven

NOTE: Links to Resources that have Links back is valid in the XDI Graph it is incumbent on Apps that are navigating the graph to avoid infinite recursion.

NOTE: Links to Resources that have Links back is valid in the XDI Graph it is incumbent on Apps that are navigating the graph to avoid infinite recursion.

$contract+Dataset

Personal

$get

Private

=Steven Signed copy of the contract

$link

Physical

Logical

Type

Instance

Data

7.9 Link Contracts – The $public $contract

!!1010

=Steven

+Email$contract

Home

+Dataset

Personal

$set

Private

=Andy

+Email

Work

$assoc

=Andy


$assoc$assoc

$link

=Steven

The $public instance of a $Contract type is a special Contract Template. It establishes an Anonymous access path to a determined set of data. The $public contract does not require an $assoc to be valid.

This is different from a ‘Public’ contract that permissions everyone; The ‘Public’ contract will still require authentication and an $assoc to provide valid access.

The $public instance of a $Contract type is a special Contract Template. It establishes an Anonymous access path to a determined set of data. The $public contract does not require an $assoc to be valid.

This is different from a ‘Public’ contract that permissions everyone; The ‘Public’ contract will still require authentication and an $assoc to provide valid access.

$public

$get

Physical

Logical

Type

Instance

Data

7.10 Link Contracts – INVALID ACCESS!!

NOTE: One logical authority CANNOT provide a rights path directly into another logical authorities data. Access MUST be mediated via a valid contract at the logical authority that ‘owns’ the data.

See next slide for valid access delegation

NOTE: One logical authority CANNOT provide a rights path directly into another logical authorities data. Access MUST be mediated via a valid contract at the logical authority that ‘owns’ the data.

See next slide for valid access delegation

description

$instance $type

validation

$logical $type

Description of how +email should be interpreted when used at the Instance level

Description of how +email should be interpreted when used at the Type level

$contract

1.0

revision

$public

$get

Physical

Logical

Type

Instance

Data

7.10 Link Contracts –VALID ACCESS!!

Here the wholesale pet company only provides access to their inventory to select vendors. But the Vendor makes the data publicly available via their catalog.

Here the wholesale pet company only provides access to their inventory to select vendors. But the Vendor makes the data publicly available via their catalog.

birds

sparrow$contract

partners

vendors

vendors

$get

$contract

birds

catalog

$public

$get

@wholesale.pets

love.bird

@wholesale.pets @birds.online

price

price

description

description

$assoc

$link

@birds.online

8.1 Link Contracts – Contract Exchange

Physical

Logical

Type

Instance

Data

8.2 Link Contracts – Contract Exchange

!!1010

=Steven

$contract+Dataset

Personal

$get

Private

=Andy

+Email

Work

$assoc

=Andy

!!1011

XDI_Get()

XDI Doc

<xdi> <xri> … </xri> <resource> </resource></xdi>

How do we represent an Error Code in the response to an xdi request?How do we represent an Error Code in the response to an xdi request?

Physical

Logical

Type

Instance

Data

9.1 Linking and Embedding

!!1010

=Steven

$contract+Dataset

Personal

$get

Private

=Andy

+Email

Work

$assoc

=Andy


$assoc$assoc

$link

=Steven

Navigating across a $link node at the Instance level signifies crossing an authority boundary and is the equivalent of Linking in a compound document architecture.

Navigating across a $link node at the Instance level signifies crossing an authority boundary and is the equivalent of Linking in a compound document architecture.

Physical

Logical

Type

Instance

Data

10.1 Link Contracts – Permissioning a Community

Physical

Logical

Type

Instance

Data

11.1 Resolving Synonyms – Unifying the Graph

Physical

Logical

Type

Instance

Data

12.1 Removing a path - $Deleted?

Physical

Logical

Type

Instance

Data

13.1 Delta Syntax - $Include and $Exclude?

Physical

Logical

Type

Instance

Data

14.1 $word Usage - Intro

description

$instance $type

$policy

validation

$logical $type

Description of how $policy should be interpreted when used at the Instance level

Description of how $policy should be interpreted when used at the Type level

All $words are themselves Logical Authorities and as such can all be found at the Logical level of the graph. The graph segment under a $word entry should contain the description and specification for the intended usage of that $word. The entire graph should be accessible via a $public contract.

All $words are themselves Logical Authorities and as such can all be found at the Logical level of the graph. The graph segment under a $word entry should contain the description and specification for the intended usage of that $word. The entire graph should be accessible via a $public contract.

$contract

1.0

spec

$public

$get

Physical

Logical

Type

Instance

Data

14.2 $word Usage - Intro

description

$instance

$public

Description of how $public should be interpreted when used at the Instance level

Position: Instance level ResourceContains:

1. Contains $op-named Link Nodes that provide anonymous access to specified data.

Versioning: NoCode Use: When determining a requester’s access this node is included in addition to

specifically permissioned data.





First attempt at capturing $word usage specification.First attempt at capturing $word usage specification.

Physical

Logical

Type

Instance

Data

14.3 $word Usage - $contract

Position: Type level ResourceContains:

1. A user-named node that has $op*-named Links that specify permissioning (required)

2. $policy Instance Node (optional)3. $public Instance Node (optional)

Versioning: NoCode Use: When a new Assoc is being established the code will traverse the $Contract children

to find the portion of the graph that should be available to the requester.


1. A user-named node that has $op*-named Links that specify permissioning (required)

2. $policy Instance Node (optional)3. $public Instance Node (optional)

Versioning: NoCode Use: When a new Assoc is being established the code will traverse the $Contract children

to find the portion of the graph that should be available to the requester.

$Contract

$get

$set

$get Friends

$public

$Policy

Physical

Logical

Type

Instance

Data

14.4 $word Usage - $policy


1. XML Data Node representing the text that will be presented to an end user for acceptance and application readable instructions. (optional)

2. Links to other Instance Nodes that contain instructional information.Versioning: YesCode Use: When a contracts are being negotiated $policy must be satisfied by either App Logic

or human interaction.


1. XML Data Node representing the text that will be presented to an end user for acceptance and application readable instructions. (optional)

2. Links to other Instance Nodes that contain instructional information.Versioning: YesCode Use: When a contracts are being negotiated $policy must be satisfied by either App Logic

or human interaction.

$Contract

$get

$set

$get Friends

$public

$Policy

Don’t call after 10:00 PM

Physical

Logical

Type

Instance

Data

14.5 $word Usage - $assoc


1. Instance nodes whose names match the URIs of Logical AuthoritiesContaining:

1. $link Link Node that provides access to a graph segment under the named Logical Authority (optional)

2. Link nodes to one or more Instance Nodes of Type $Contract (optional)

Versioning: NoCode Use: The $assoc is used to find and validate the location of signed contracts and therefore

confirm access to requested information. It can also be used to manage the local representation of another Logical Authority


1. Instance nodes whose names match the URIs of Logical AuthoritiesContaining:

1. $link Link Node that provides access to a graph segment under the named Logical Authority (optional)

2. Link nodes to one or more Instance Nodes of Type $Contract (optional)

Versioning: NoCode Use: The $assoc is used to find and validate the location of signed contracts and therefore

confirm access to requested information. It can also be used to manage the local representation of another Logical Authority

$assoc$contract

Private =Andy

$link

Physical

Logical

Type

Instance

Data

14.6 $word Usage - $public









$Contract

$get

$set

$get Friends

$public

$Policy

Physical

Logical

Type

Instance

Data

14.7 $word Usage - $link

Position: Instance level Link (child of an instance of an $assoc)Contains:

1. Ref to an access node under another Logical AuthorityVersioning: NoCode Use: Differentiates ‘My’ data about another Logical Authority from the data from that

authority. Used to identify an authority boundary.

Position: Instance level Link (child of an instance of an $assoc)Contains:

1. Ref to an access node under another Logical AuthorityVersioning: NoCode Use: Differentiates ‘My’ data about another Logical Authority from the data from that

authority. Used to identify an authority boundary.

!!1010

=Steven

$assoc

=Andy

$link, =andy/($assoc)/(=steven)

Physical

Logical

Type

Instance

Data

14.8 $word Usage - $v

Position: ANY level LinkContains:

1. Ref to a resource that contains a versioned representation of the parent resourceVersioning: NoCode Use: Used to identify a versioning delegation and support version control logic such as

automatically incrementing the version number to the next version number


1. Ref to a resource that contains a versioned representation of the parent resourceVersioning: NoCode Use: Used to identify a versioning delegation and support version control logic such as

automatically incrementing the version number to the next version number

!!1010

=Andy

+Email

Primary

$v/1

[email protected]

$v/2

[email protected]

!1!2

Physical

Logical

Type

Instance

Data

14.9 $word Usage - $current


1. Ref to a resource that contains a versioned representation of the parent resourceVersioning: NoCode Use: Explicitly maintained by Apps this alias of a version link node is used to specify the

graph representation that should be used when multiple versions are available.


1. Ref to a resource that contains a versioned representation of the parent resourceVersioning: NoCode Use: Explicitly maintained by Apps this alias of a version link node is used to specify the

graph representation that should be used when multiple versions are available.

!!1010

=Andy

+Email

Primary

$v/1

[email protected]

$current,$v/2

[email protected]

!1!2

Physical

Logical

Type

Instance

Data

14.10 $word Usage - $exception


1. Ref to a resource that contains a versioned representation of the parent resourceVersioning: NoCode Use: Explicitly maintained by Apps this alias of a version link node is used to show that a

node is ‘soft deleted’. The $deleted can be used in the syntax - $deleted*2 replacing the $v in the xri and providing restoration information while de-activating the version path.




Physical

Logical

Type

Instance

Data

14.11$word Usage - $delete







!!1010

=Andy

+Email

Primary

$delete/($v/1)

[email protected]

$current,$v/2

[email protected]

!1!2

Physical

Logical

Type

Instance

Data

14.12 $word Usage - $op*($XXXXX)

Position: Instance level Link from an instance of a $contract type resource.Contains:

1. Ref to any resource that should be permissioned.Versioning: NoCode Use: Used to validate the rights of the requester to act upon the specified resource.



$op*($get)$op*($set)*($add)*($resource)$op*($set)*($add)*($link)$op*($add)*($data)$op*($set)*($add)*($xri)$op*($set)*($add)*($ref)$op*($set)*($add)*($backref)$op*($set)*($delete)*($resource)$op*($set)*($delete)*($link)$op*($set)*($delete)*($data)$op*($set)*($delete)*($xri)$op*($set)*($delete)*($ref)$op*($set)*($delete)*($backref)$op*($set)*($replace)*($data)$op*($set)*($replace)*($xri)


!!1010

=Steven

+Dataset

Personal

$get

$contract

Private

Physical

Logical

Type

Instance

Data

14.12 $word Usage - $header







!!1010

$header

+Dataset

Personal

$get

$session

Private

Physical

Logical

Type

Instance

Data

15.1 +word definitions

description

$instance $type

validation

$logical$type

Description of how +email should be interpreted when used at the Instance level

Description of how +email should be interpreted when used at the Type level

$contract

1.0

revision

$public

$get

@IDcommons

$dictionary

+emailemail.primary

Physical

Logical

Type

Instance

Data


!!1010

+email

$mask

+US-EN

$definition $validation

A valid, native SMTP address

$representation

+UK-EN

I say, lets have a cup of tea.

Physical

Logical

Type

Instance

Data


!!1010

+email

$mask

*@*.???

$definition$validation

"^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z0-9][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$"

$representation

simple verbose

Physical

Logical

Type

Instance

Data


!!1010

+email

$mask

member

$definition$validation $representation

range

Physical

Logical

Type

Instance

Data


!!1010

+email

$mask$definition

$validation $representation

+US-UK+US-EN

Email: <mailto: X> <mailto: X>

Resource

16.1 Universal Schema

BackRefLink

Data

XRI

0..1

1

1..n1..n

1..n

1..n

0..n

0..n

1

Ref

0..n0..n

Resources can contain zero or more Resources, Links, BackRefs, and Refs. Each of these elements are “addressable”—they have one or more XRIs describing their graph address and synonyms. Resources have zero or one Data element, and Links and BackRefs each have a Ref.

16.2 Universal Schema

Physical

Logical

Type

Instance

Data

17.1 Community Membership

=

Shorthand

Physical

Logical

Type

Instance

Data


!!1010

@ooTao

+Email

contact

+Phone

main

+members$contract

members

+dataset

community members

$public

This is a community that has no members that is ready to receive members.This is a community that has no members that is ready to receive members.

Physical

Logical

Type

Instance

Data


!!1010

@ooTao

+Email

contact

+Phone

main

+members$contract

members

+dataset

community members

$public

barry

barry

$link+Dataset

i-brokeri-broker@ootao

$contract

primary

+email

Physical

Logical

Type

Instance

Data

20.1 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?

•See XRI normalization rules•Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?)

•See XRI normalization rules•Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer?

•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?

•See XRI normalization rules•Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?)

•See XRI normalization rules•Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer?

Physical

Logical

Type

Instance

Data

Scratch

!!1010

@ooTao

+Email$contract

Home

+Dataset

Personal

$get

Private

$link

=barry

He did bad things

incident

$d/01-01-2004

barry

=barry

email

emergency

email

primary

T&E

$d/01-01-2004

Worked on IDC

!A2B1

$link+Dataset

Personal

$get

Private@ootao

$contract

Documents

Table of Contents: