the xdi graph model - oasis · web view[ref to ... xdi contexts just like a natural language word...

The XDI Graph ModelTo meet the design goals in the preceding section, the XDI TC developed the semantic graph model defined in this and the following sections.

OverviewThe XDI graph model builds on the RDF subject-predicate-object triples model [ref]. This model in turn builds on the Entity-Attribute-Value (EAV) data model that dates back over 40 years. Note that in RDF, a graph node containing a data value is called a literal. So the RDF data model could also be termed an Entity-Attribute-Literal (EAL) model.

With RDF 1.1 datasets [ref], the model was expanded to context-subject-predicate-object quads. The fourth component—context—represents a named RDF graph. The XDI graph model also has an analogous fourth component representing the root of an XDI graph. Thus it is called a the Root-Entity-Attribute-Literal (REAL) model.

Node TypesFigure ___ shows a simple UML class diagram (not an XDI graph) of the highest level node types in the XDI REAL graph model.

All graph nodes are one of two fundamental types: literal nodes or context nodes.

5

10

15

Literal Nodes

As in RDF, XDI literal nodes are the terminal leaf nodes of the graph. They contain the raw data values described by all the other metadata in the graph. XDI natively supports the six data types defined by JSON [ref]:

1. Number (double-precision floating-point format in JavaScript)2. String (double-quoted Unicode, with backslash escaping)3. Boolean (true or false)4. Array (an ordered, comma-separated sequence of values enclosed in square

brackets; the values do not need to be of the same type)5. Object (an unordered, comma-separated collection of key:value pairs

enclosed in curly braces, with the ':' character separating the key and the value)

6. null (empty—note that this is not the equivalent of undefined, which is when an XDI attribute has no literal node at all)

In addition to the basic data type semantics provided by JSON, the type of a literal MAY be further described using one or more XDI type statements (see Type Relations).

Context Nodes

All non-literal nodes in the XDI graph model are called context nodes. In RDF the term “context” is only used to describe the top level of semantic context available in the RDF 1.1 graph model, i.e., a named RDF graph. In addition, RDF blank nodes can may be used to add a type of context to the relationship between other nodes. However, RDF does not use the term “context” for this purpose.

In XDI the term “context” is used uniformly across all levels of the REAL model to describe all forms of semantic context, including when:

A graph root node provides context for another graph root node, an entity node, or an attribute node.

An entity node provides context for another entity node or an attribute node.

An attribute node provides context for another attribute node.

See Contextual Arcs and Contextual Statements, below.

All context nodes MUST have:

1. Exactly one context type identified in XDI syntax by exactly one context symbol.

2. One or more context roles identified in XDI syntax by zero or more pairs of context brackets.

20

25

30

35

40

45

50

55

Context Types and Symbols

The XDI REAL model defines six global context types in three two groups:

1. Classes represent entity and attribute types.

2. Instances represent entity and attribute individuals.

[3.] Authorities represent the two specific types of entities that are ultimately responsible for control of XDI graphs.

The context symbols for each type are shown in the table below__:

Group Context Type Symbol Also Known AsClasses Reserved $ keywords, dollar words,

Unreserved # hashtags, dictionary words

Instances Ordered @ at numbers

Unordered * thing names, thing numbers

Authorities Personal = equals names, equals numbers

Legal + plus names, plus numbers

Group Context Type Symbol Also Known AsClasses Reserved $ keywords, dollar words

Unreserved # hashtags, dictionary words

Instances Person = equals names/numbersperson names/numbers

Group + plus names/numbersgroup names/numbers

Thing * star names/numbersthing names/numbers

Ordinal @ at numbersorder numbers

A definition of each context type is provided in the Entity section below.

Note that XDI syntax also uses three four other single-character symbols as summarized in table __:

Name Symbol

Purpose See Section

Literal symbol & Identify a literal arc Literal Arcs and Literal Statements

Immutability symbol ! Express an immutable Mutable and

60

65

identifier Immutable identifiers

Relativity symbol ~ Express a relative identifier

Absolute and Relative Identifiers

Separator / Separate an XDI subject, predicate, and object in XDI statement format

Statement Format

[1.] & (ampersand) to identify a literal arc (see Literal Arcs and Literal Statements, below).

[2.] ! (exclamation mark) to indicate an immutable XDI identifier (see Mutable and Immutable Identifiers).

[3.] / (forward slash) to separate XDI subjects, predicates, and objects in XDI statement format (see Statement Format).

70

75

Context Roles and Brackets

The XDI REAL model defines six context roles in two groups:

1. Primary roles: every context node MUST have exactly one primary role.

2. Secondary roles: depending on the context, a context node MAY have one or more secondary roles.

The context brackets for each role are shown in the table below:

Group Context Role Brackets Also Known AsPrimary Entity none plain, naked

Attribute < > chevrons

Root ( ) parentheses

Secondary Collection [ ] square brackets

Definition | | pipes

Variable { } curly brackets

Each context role is defined in its own section below.

Arc Types and Statement TypesAn RDF graph is a labeled directed graph in which every predicate represents a directed arc from a subject node to an object node. Each RDF subject/predicate/object statement represents exactly one such arc.

The same is true of the XDI graph model, however in XDI, an arc MUST be one of three types:

[1.] A literal arcs describes the relationship between a context node and a literal node.

[2.] A contextual arcs defines the identity, type, and role of one context node in the context of another context node.

[3.] A relational arcs describes any other relationship between two context nodes.

Each type of arc is expressed using a specific type of XDI statement as defined in this section.

80

85

90

95

100

Literal Arcs and Literal Statements

In the XDI REAL model, a literal node MUST be the object of exactly one literal arc expressed by exactly one literal statement. The subject of a literal arc MUST be an XDI attribute node. An XDI attribute node MUST have no more than one literal arc.

There are two key differences between XDI literal arcs and RDF predicates whose object is a literal node:

1. In RDF, the semantic meaning of a literal is expressed by its predicate arc. In XDI, the semantic meaning of a literal is expressed by the sequence of XDI attribute node(s) that precede the literal arc.

2. In RDF, a literal may have its own datatype and language attributes. In XDI, a literal node is always an atomic leaf node. Any other semantic description of a literal node MUST be expressed using one or more XDI type statements about the parent attribute node (see Relational Arcs and Relational Statements, below).

Because of the first difference above, an XDI literal arc is the semantic equivalent of the rdf:value property in RDF [ref]. Thus in XDI, all literal arcs MUST have the same XDI identifier: the ampersand character &. This is called the literal symbol. All XDI literal statements MUST use the literal symbol as the predicate. Examples:

Subject Predicate Object

=example<#email> & "[email protected]"

+example<#main><#telphone> & "+44-2222-888888"

*!1234[<#event>]<@~78><$t> & "2010-09-20T10:11:12Z"

In XDI JSON serialization format:{

"=example<#email>": {

"&": "[email protected]"

},

"+example<#main><#telphone>": {

"&": "+44-2222-888888"

},

"*!1234[<#event>]<@~78><$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

105

110

115

125

130

Because an XDI attribute node may only contain one literal node, that literal node may be uniquely addressed by appending the literal symbol & to the XDI address of the attribute node. Examples:

XDI Address of Attribute Node XDI Address of Literal Node

=example<#email> =example<#email>&

+example<#main><#tel> +example<#main><#tel>&

*!1234[<#event>]<@~78><$t> *!1234[<#event>]<@~78><$t>&

Contextual Arcs and Contextual Statements

In the RDF graph model, a blank node exists to provide context for other nodes., however A blank node does not have a URI. It can only be identified relative to the RDF graph in which it exists. [ref]

In the XDI graph model, all context nodes can provide context for other context nodes, and all context nodes are uniquely addressable. With the exception of the common root node, a context node MUST be the object of exactly one contextual arc expressed by a exactly one contextual statement. The subject of a contextual statement MUST be a another context node, called the parent node or supercontext. Only the common root node has no parent. The predicate of a contextual statement MUST be empty. The object of a contextual statement MUST be another context node, called the child node or subcontext. The object of a contextual statement MUST have an XDI identifier that is unique in that the parent context.

The result of these requirements is that XDI context nodes form a rooted directed acyclic graph, called a semantic tree, in which every node is uniquely addressable and every node has a semantic meaning. The absolute XDI address of a context node is the sequence of XDI identifiers for each contextual arc that must be traversed to go from the common root node to the target context node.

If the common root node of an XDI graph is itself assigned a URI, all nodes in the graph become globally addressable in the universal URI addressing space as recommended by [WebArch]. See the XDI Addressing section for details.

Following is an example of three contextual statements (each with the empty predicate) that establish the context for the final literal statement. In this example, =example and #car are XDI entities; <#interior> and <#color> are XDI attributes.


=example #car

=example#car <#interior>

=example#car<#interior> <#color>

140

145

150

155

160

165

=example#car<#interior><#color> & “black”

Figure ___ shows the same set of statements in XDI JSON serialization format. Note that when serialized the empty predicate in a contextual statement is represented by two forward slashes:{

"=example": {

"//": [

"#car"

]

},

"=example#car": {

"//": [

"<#interior>"

],

"<#interior>": {

"//": [

"<#color>"

]

},

"<#interior><#color>": {

"&": "black"

}

}

}

Contextual statements are inherent in the XDI addresses of the subjects and objects of literal or relational statements. Therefore contextual statements are not included in the JSON serialization by default and are only added if they are explicitly requested using the _____________ parameter (see the Serialization section for details). Figure ___ shows the same example graph without the contextual statements:{

"=example#car": {

"<#interior><#color>": {

"&": "black"

}

}

}

170

175

180

185

190

195

200

Relational Arcs and Relational Statements

Any relationship between two XDI graph nodes that is not described by a literal or contextual arc is described by a relational arc expressed by a relational statement. The predicate of a relational statement MUST be a sequence of one or more XDI entities.

XDI relational arcs are the equivalent of RDF properties that describe the relationship between two RDF resources. Examples:


=person-1 #friend =person-2

=person-1 #friend =person-3

=person-1 #best#friend =person-3

=person-1 #employer +example.company

[#device]*!:uuid:1234... #owner =person-1

In the XDI JSON serialization, a predicate of expressing a relational arc is prefixed with a forward slash character:{

"=person-1": {

"/#friend": [

"=person-2",

"=person-3"

],

"/#best#friend": [

"=person-3"

],

"/#employer": [

"+example.company"

]

},

"[#device]*!:uuid:1234...": {

"/#owner": [

"=person-1"

]

}

205

210

215

220

225

230

}

Relational statements may also be used to assert type or subclass relationships. See Type Relations. In an XDI type statement or subclass statement, the subject is the context node being described, the predicate is $is#, and the object is the class of which the subject is a member (corresponds to an rdf:type), or the class of which the subject is a subclass (corresponding to rdf:subClassOf). Examples:


#sedan $is# #car

#car $is# #vehicle

*!:uuid:1234 $is# #car

=person-1 $is# #carpenter

<#email> $is# $string

Visual Graph Diagramming NotationFor consistency across implementationsof documentation, the XDI Technical Committee RECOMMENDS the notation shown in Figure ___ for visual diagramming of XDI graphs.

The root node symbol (a circle) is suggestive of the parentheses ( ) used in XDI syntax, and the attribute node symbol (a diamond) is suggestive of the chevron brackets < >. The root node symbol is open not filled to represent suggest that an XDI graph is only a container of XDI statements. The entity and attribute node symbols are filled solids to represent concrete identities and properties.

For diagrams that support color, it is RECOMMENDED to use:

235

240

245

250

1. A red outlined circle for the common root node.

2. A blue outlined circle for a peer root node.

3. A green outlined circle for an inner root node.

Literal nodes are a direct representation ofrepresented by the actual JSON value. If the value is truncated to save space, it is RECOMMENDED that the portion shown end in ellipses.

All contextual and relational arcs MUST be labeled. A literal arc MAY be labeled with the ampersand symbol, but it is not recommended. For a contextual arc, the label MUST be the unique XDI identifier of the object context node. For a relational arc, the label MUST be the predicate of the relational statement it represents.

Since there are many ways to organize an XDI graph diagram that usesusing this notation, the following two forms are RECOMMENDED:

[1.] Free form. In this organization, the common root appears at roughly in the center of the diagram, and arcs are arranged radiating outward from it so as to best communicate the semantic information in the graph.

[2.] Tree form. This organization mimics a typical file or directory tree layoutstructure. The common root node appears in the upper-left-hand corner, contextual and literal arcs follow a grid, and only relational arcs are curved.

The choice of form depends on the particular XDI graph being shown. It is RECOMMENDED that viewing/editing tools support both forms and enable viewers to switch between them dynamically.

Figure ___ shows the example XDI graph from the Introduction section in free form.

255

260

265

270

Figure ___ shows the same graph in tree form.

280

EntitiesIn the XDI REAL model (and the Entity-Attribute-Value model upon which it is based), an entity is anything (except an XDI graph itself) that can be independently identified and described independently, whether tangible or intangible (except an XDI graph itself). An entity may represent a person, group/, organization, physical or digital object, concept, definition, or even a variable that may itself represent any set of these things.

From a linguistic perspective, entities are the “nouns” of XDI. However, this does not mean an entity is the only type of node that can serve as the subject of an XDI statement. In the XDI REAL model, both either a root node (representing an entire XDI graph) or and an attribute node may also serve as an XDI subject (and both are disjoint from entities). Thus an XDI entity is not exactly the same thing as an RDF resource—the latter may be anything with a URI (which would include XDI root nodes and attribute nodes).

XDI entities fall into three two groups: classes and, instances, and authorities.

ClassesA class, also known as a concept in description logic, is a set of entities that have some attribute(s) or propert(ies) in common. The set of entities belonging to the class are its members. In XDI, the instances of a class share the same definition.

XDI classes fall into two groups: reserved and unreserved.

Reserved ($ Symbol)

A reserved class is a class defined by the XDI Technical Committee to establish the universal grammar of XDI. The goal of the XDI TC is to define the smallest set of reserved classes that produce the greatest degree of semantic interoperability across XDI graphs.

The XDI identifier of a reserved class MUST begin with the $ context symbol. The $ context symbol by itself represents the class of all reserved classes. Reserved class names are also known as dollar words or keywords. Examples:

$uriiri

$do

$and

$or

$not

$public

A reserved class name MUST be immutable and MUST NOT use the XDI immutability symbol. A reserved class name MUST be defined in a specification from either: 1) the

285

290

295

300

305

310

315

OASIS XDI Technical Committee (including this specification), 2) another OASIS Technical Committee specified by the OASIS XDI Technical Committee, or 3) another standards body specified by the OASIS XDI Technical Committee.

The set of Reserved class names of all non-negative integers (e.g., $0, $1, $2, $3…), also called dollar numbers, is reserved for named variables and MUST NOT be defined for any other purpose. See Named Variables.

Unreserved (# Symbol)

An unreserved class is a class defined by any XDI authority other than the OASIS XDI Technical Committee or its specified delegate. The XDI identifier of an unreserved class MUST begin with the # context symbol. The # context symbol by itself represents the class of all unreserved classes. Unreserved class names SHOULD be defined in XDI dictionaries using XDI dictionary definitions (see Definitions, below). Unreserved class names are also known as tags, hashtags, or dictionary words. Examples:

#email

#passport

#home

#work

#friend

#enemy

An unreserved class name MUST be immutable and MUST NOT use the XDI immutability symbol.

Unreserved class names SHOULD be defined in XDI dictionaries using XDI dictionary definitions (see Definitions, below). In a dictionary context, unreserved class names are called dictionary words. Unreserved Dictionary words MAY be defined by any XDI authority in any XDI context. Unreserved Dictionary words whose semantics are intended to be confined to a specific set of XDI contexts SHOULD be defined by an in the context of the XDI authority (a person or other legal entitygroup) responsible for those contextsfor those contexts and SHOULD be defined in that authority’s own XDI dictionary context. Dictionary words that are intended to be generic, i.e., to share the same semantics in all XDI graphs, SHOULD be defined directly in the common root context. See Roots, below.

This begs the question of authority for generic XDI dictionary words. Like the nouns in a human language, such words represent a shared community consensus about shared semantics. Thus It is RECOMMENDED that generic XDI dictionary words be specified in an XDI community dictionary cooperatively maintained by the XDI authorities contributing to that community.

This is the model popularized (and proven to scale) by Wikipedia for human-readable concept definitions. It is also the model , and also being followed by machine-readable community ontologies such as schema.org.

320

325

330

335

340

345

350

355

InstancesAn instance, also known as an individual in description logic, is a member of a class. The four XDI context symbols for instances are based on the fundamental nature of the context being identified as described in table __:

Instance Type Symbol Personal Authority Legal Authority OrderedPerson = Yes Yes No

Group + No Yes No

Thing * No No No

Ordinal @ No No Yes

The first three instance types are based on authority and accountability.

1. A person is the only entity instance that can be held personally accountable for actions taken using the XDI protocol.

2. A group of people (in any form) is the only entity instance that may be held legally but not personally accountable for actions taken using the XDI protocol.

3. A thing is an entity instance that may initiate an XDI action but cannot be held legally accountable it, such as a physical device or a software program that cannot act “of its own accord”.

Since legal accountability plays a significant role in XDI policies and link contracts, table __ defines terms for referring to precise subsets of these three types of entity instances:

XDI Term Includes Person Includes Group Includes ThingXDI person Yes No No

XDI authority Yes Yes No

XDI actor Yes Yes Yes

The legal implications of each of these terms with regard to XDI link contracts and policies is further discussed in the XDI Policy 1.0 specification.

The final type of instance identifiers are used to specify logical order. Since XDI graphs, like RDF graphs, are unordered by default, a special class of instance identifiers called ordinal identifiers is needed to define explicit ordering within an XDI context.In the XDI graph model, the XDI identifier for an instance node does not by itself convey any semantics about the class. It only conveys whether the instance

360

365

370

375

380

385

is ordered or unordered in relationship to other instances in the same context. The relationship of an instance node to a class MAY be asserted in three ways:

By putting an instance node in the context of a collection node. By definition that instance is a member of the collection. See Collections, below.

By describing an instance node with one or more XDI type statements. See Relational Arcs and Relational Statements, above.

Personal (= Symbol)

The most common actor in XDI interactions is a person (also called a “user”). The XDI identifier of a natural person is called a personal authority. A personal authority MUST begin with the = context symbol (selected to suggest equality among peers). The = context symbol by itself represents the class of all personal authoritiespeople. Personal XDI authority identifiers for people are also known as equal names (mutable) or equal numbers (immutable).

390

395

As explained in the XDI Addressing section, (below), the XDI identifier for a personal authorityperson may be either an native referenceXDI name, an XDI number, or ann encapsulated external referenceIRI. Examples of personal native referencesXDI names:

=example

=example-name

=example.name

=!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e93c1

Example of a personal XDI number (in this case, using the XDI UUID scheme):

= !:uuid:f81d4fae-7dec-11d0-a765-00a0c91e93c1uuid:33ad7beb-1abc-4a26-b892-466df4379a51

External references may be either to globally unique URIs or to locally unique identifiers. In either case they are encapsulated in parentheses. Examples of personal encapsulated IRIs:

=(https://example.name/)

=(mailto:[email protected])

+example.company=(local.name)

+(https://example.com/)=(local-name)

An personal XDI personal authority identifier represents a new form of digital identity for individuals. This is can be referred to as sovereign identity because XDI’s heterarchical and contextual graph model enables an individual to interact with other XDI authorities (both personal and legalpersons and groups) as an independent autonomous peer. [ref to http://blogs.law.harvard.edu/doc/2013/10/14/iiw-challenge-1-sovereign-identity-in-the-great-silo-forest/].

400

405

410

415

425

http://blogs.law.harvard.edu/doc/2013/10/14/iiw-challenge-1-sovereign-identity-in-the-great-silo-forest/

http://blogs.law.harvard.edu/doc/2013/10/14/iiw-challenge-1-sovereign-identity-in-the-great-silo-forest/

Legal Group (+ Symbol)

The second class of actor that may be held legally responsible for XDI interactions is a group— a set of people whose existence is independent of any one person. Administrative identity.

The XDI identifier of any legal entity other than a natural person is called a legal authority. A legal authoritygroup MUST begin with the + context symbol. The + context symbol by itself represents the class of all legal authoritiesgroups. Legal authorityGroup identifiers are also known as plus names (mutable) or plus numbers (immutable).

Examples:

+example

+example-company

+example.org

+!: uuid:9ce739f0-7665-11e2-bcfd-0800200c18f2uuid:f336a645-f5a9-41b7-ab80-ace41a8f69c2

+(https://example.com/)

+(mailto:[email protected])

An XDI legal authoritygroup identifier may represent any type of “legal person” that is not a natural person, including an group, association, sole proprietorship, partnership, corporation, or any type of governing, political, or social body. It may also represent any form of non-personal identifier to which legal rights may apply, including trademarks, trade names, service marks, trust marks, etc.

430

435

440

445

450

Unordered Thing (* Symbol)

Any unordered XDI instance that does not represent a person or a group represents an XDI thing. This includes any device, sensor, or other object that when connected to a network are commonly referred to as the Internet of Things. However it also includes any other logical “thing” such as a software program, a database, a data structure, a concept, or a unique member of a set.

Note: an XDI thing is not the same as the owl:Thing, which is the root class of all classes in OWL [ref].

The XDI identifier of an unordered instancething MUST begin with the * context symbol. The * context symbol by itself represents the class of all unordered instancesthings. Unordered instanceXDI thing identifiers are also known as star names (mutable) or star numbers (immutable).

A set of unordered instance nodes in a context MUST NOT be interpreted as having any logical order regardless of their XDI identifiers or their document order in a serialized XDI JSON document.

An unordered instance may represent any “thing”, so the * context is the XDI namespace for the Internet of Things. An unordered instance within a collection conveys the type of thing; an unordered instance outside a collection does not convey type information unless described by an XDI type statement.By itself, an XDI thing identifier does not convey any semantics about its type. The relationship of an XDI thing to a class of which it is an instance MAY be asserted in two ways:

1. By making the thing a member of a collection. By definition a member of a collection is an instance of the collection class. See Collections.

2. By describing a thing instance with one or more XDI type statements. See Type Relations.

Following is an example of XDI unordered entitythings serving as entity instances instances (in this case identified using immutable UUIDsstar numbers using the ! immutability symbol):{

"+example[#item]*!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e58d1uuid:33ad7beb-1abc-4a26-b892-466df4379a51": {

"<#price>": {

"&": "24,995"

}

},

"+example[#item]*!:uuid:9ce739f0-7665-11e2-bcfd-0800200cb439uuid:f336a645-f5a9-41b7-ab80-ace41a8f69c2": {

"<#price>": {

"&": "36,995"

455

460

465

470

475

480

485

490

}

},

"+example[#item]*!:uuid:3a96e460-7be9-f7e4-b92a-83d3c45e0ea4uuid:1c958708-d5aa-4213-a6a9-73dd423502b3": {

"<#price>": {

"&": "18,495"

}

}

}

495

500

Following is an example of unordered attribute instancesXDI things serving as attribute instances. This example also uses immutable UUIDs for immutable identifiers. Note that these instance identifiers will not change even if the literal value changes.{

"=example": {

"[<#email>]<*!:uuid:35bcc3c0-da48-df9b-a16b-0002a5d557c4uuid:05c070d1-122e-4688-a88d-ef7b54eca044>": {


},

"[<#email>]<*!:uuid:fbc71e40-da47-47a6-a00e-0002a5d577b5uuid:8ded2f7e-afb4-4494-9918-0fecf38f80d5>": {


},

"[<#email>]<*!:uuid:eeba8eb3-0d44-4c0c-85ed-ee00281f0e26uuid:62079220-da48-21cc-aca9-0002a5d51fe6>": {


}

}

}

OrderedOrdinal (@ Symbol)

In the absence of ordinal identifiers, the set of nodes in an XDI context or the document order of XDI statements in a serialized XDI JSON document MUST NOT be interpreted as having any logical order.

Since the order of a set of subcontexts is always relative to the parent context, to express logical order within an XDI context, theThe ordered subcontexts MUST use a relative ordinal identifier. XDI identifier of an ordered instanceA relative ordinal identifier:

1. MUST begin with the @ context symbol.

2. MUST include the ~ relativity symbol.

3. MUST be a nested identifier.

See Absolute and Relative Identifiers and Rooted and Nested Identifiers.

The @ context symbol by itself represents the class of all ordered instances.

An absolute ordinal identifier (one that does not use the ~ relativity symbol) represents the concept of a particular order position (e.g., the concept of the number “3”) and not the actual relative position in an ordered sequence. Absolute ordinal identifiers MUST NOT be interpreted as being members of an ordered set.

505

510

515

520

525

530

535

540

By default, ordinal identifiers are non-negative integers, called order numbers. The identifier following the @ context symbol MUST be a non-negative integer, called the order number. The logical order of a set of ordered instances in a context MUST be by order number, beginning order numbers MUST begin with the number zero if present. The document order of the ordered instances in a serialized XDI JSON document MUST be ignored. An example of nested ordered entity instances order numbers (in this case inside a collection):

545

{

"=example#favorite[#car]@~0": {

"$ref": [

"=example[#car]*!:uuid:f81d4fae-7dec-11d0-a765-00a0c91ea751uuid:33ad7beb-1abc-4a26-b892-466df4379a51"

]

},


"$ref": [

"=example[#car]*!:uuid:9ce739f0-7665-11e2-bcfd-0800200c4bd2uuid:f336a645-f5a9-41b7-ab80-ace41a8f69c2"

]

},


"$ref": [

"=example[#car]*!:uuid:3a96e460-7be9-f7e4-b92a-83d3c45e76a3uuid:1c958708-d5aa-4213-a6a9-73dd423502b3"

]

}

}

550

555

560

565

OrderingOrder numbers also applies apply to attribute instances as shown in this example:{

"=example": {

"<#pref>[<#email>]<@~0>": {

"&": "alice#example.com"

},

"<#pref>[<#email>]<@~1>": {


},

"<#pref>[<#email>]<@~2>": {


}

}

}

570

575

580

585

Although order numbers are the default type of ordinal identifier, they are not the only ordering algorithm. By appending an XDI scheme, ordinal identifiers may use other ordering algorithms, such as alphabetic, alphanumeric, or byte order. An example using the :alpha: scheme for alphabetical ordering:

+example.school[#student]@~:alpha:doe-jane

+example.school[#student]@~:alpha:doe-john

+example.school[#student]@~:alpha:smith-mary

See XDI Schemes for more about ordinal identifier schemes.

Note: Explicit ordering of XDI graph nodes within a context using ordinal identifiers is different than canonical ordering of XDI statements for purposes of digital signatures. Canonical ordering is specified in the XDI Cryptographic Mechanisms 1.0 specification. [ref]

590

595

AuthoritiesTwo specific classes are important enough to be distinguished by their own context symbol because they represent the entities ultimately responsible for control of XDI graphs:

[1.] Natural persons.

[2.] All other legal entities.

These classes are referred to as XDI authorities.

Attributes < >In the Entity-Attribute-Value (EAV) model, an attribute is a property of an entity that does not exist independently of the entity it describes. An attribute (and only an attribute) can may have a literal value; an entity by itself cannot have a literal value.

In the RDF subject-predicate-object graph model, an attribute of a resource node is described by a predicate whose object is a literal node. In RDF, an attribute is not required to be unique; a resource may have multiple predicates with the same URI describing multiple literal values for the same attribute (e.g., multiple email addresses for a person).

In the XDI REAL model, all attributes are uniquely addressable because they are modeled as context nodes an attribute is represented by a context node in an attribute role. The XDI identifier of an attribute context node MUST be an entity class or entity instance enclosed in chevron brackets < >. Examples:

=example<#email>

+example-company<#support><#tel>

+(https://example.com/)#shipping#address<#city>

*!: uuid:9ce739f0-7665-11e2-bcfd-0800200c18f2<#price>

Any type of XDI context node in any role (root, entity, attribute, collection, definition, variable) MAY have an attribute node. Note that attributes of a root node are attributes of that XDI graph as a whole and not attributes of any entity within that graph.

There are three reasons to model attributes as context nodes. First, it means all XDI attributes, like all XDI contexts, are uniquely addressable. This applies even if an entity has multiple values of the same attribute, e.g., a person with multiple email address attributes. —This can be modeled as a collection where each instance is uniquely identified, as shown below.{

"=example": {

600

605

610

615

620

625

630

635



},



},

"[<#email>]<*!:uuid:62079220-da48-21cc-aca9-0002a5d51fe6uuid:eeba8eb3-0d44-4c0c-85ed-ee00281f0e26>": {


}

}

}

Secondly, attributes can specialize other attributes (see Specialization and Generalization). For example, <#home> and <#work> can be used to to specialize <#email>.

=example<#home><#email>

=example<#work><#email>

Thirdly, an attribute may itself have attributes. For example, to express the timestamp when the literal value of an attribute was assigned, add the <$t> (timestamp) attribute.

=example<#work><#email><$t>

{

"=example": {

"<#work><#email>": {


},

"<#work><#email><$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

}

Standard XDI attributes like $t are defined in the XDI Dictionary specification [ref].

640

645

650

655

660

665

670

As defined in Literal Arcs and Literal Statements, only an attribute node can may have a literal node, and it can may have exactly zero or one literal node. The semantics of the relationship between an attribute node, its literal node, and the value of that literal node are very precise:

1. If an attribute node does not have a literal node, then the value of that attribute is undefined.

2. If an attribute node has a literal node, then its value is the literal JSON value of the literal node, including:

a. null for a null value.

b. "" for an empty string.

675

680

685

The following example in JSON illustrates these rules.

1. =example<#home><#email> is undefined. Note that in this case, the attribute node must be defined with an explicit contextual statement because no statement with the literal symbol will exist.

2. =example<#work><#email> has the literal JSON value of null.

3. =example<#student><#email> has the literal JSON value of the empty string.

4. =example<#employed> has the literal JSON value false.

{

"=example": {

"<#home>": {

"//": [

"<#email>"

]

},


"&": null

},

"<#student><#email>": {

"&": ""

},

"<#employed>": {

"&": false

}

}

}

690

695

700

705

710

Roots ( )After entities and attributes, the third primary role for a context node in the XDI REAL model is to represent the root of an XDI graph. While there is exactly one ultimate root node for all XDI graphs—the common root node—due to the heterarchical design of XDI means that, it also has two other types of root nodes: peer roots and inner roots.

The Common Root Every XDI graph MUST have exactly one common root node. It is so named because it the one logical node shared by all XDI graphs. To use the analogy of trees in a forest, if every tree represents an XDI graph, the common root node is the earth.

The XDI address of the common root node is the empty address. Thus any XDI statement that does not begin with a peer root address or an inner root address is by definition relative to the common root node. The set of all XDI statements context nodes that are relative only to the common root node and not to a peer root node is called the common graph.

The common root node MUST NOT be the object of a direct contextual statement. It MAY be the object of an inverse contextual statement. See Inverse Relations.

The common root node of any XDI graph MAY describe the location of its own XDI endpoint using the <$uriiri> attribute as defined in the XDI Discovery specification [ref]. Note that all attributes of a root node are attributes of an XDI graph as a whole and not attributes of any entity within that graph.

715

720

725

730

735

Peer Roots

A peer root node is a context node in one XDI graph that represents the common root node of another separate independent XDI graph. This concept is fundamental to XDI architecture—peer root nodes are how the XDI graph model can is able to represent peer-to-peer relationships between independent XDI graphs when where each graph itself is its ownis a rooted tree. A node that serves as a peer root node in one XDI graph MUST serve as the common root node of its own XDI graph.

Peer root nodes may be nested to any depth within a single XDI graph. The set of contextual arcs describing these peer root nodes forms a hierarchical rooted tree. However Each peer root node can be envisioned as a point on a global circle representing the logical common root node of all XDI graphs. Pick any specific starting point on this circle, and the references to the other starting points (peer roots) may be arranged hierarchically. However if you move to a different starting point, you will discover a different hierarchy. Each hierarchy represents the set of XDI peer root nodes known to a particular peer.

740

745

750

The graph contained by a peer root node is called a peer graph. A peer graph MUST be a subset of the independent XDI graph which that the peer root node represents. Every peer graph is in turn a subset of the logical XDI common graph. Thus the XDI statements in every peer graph MUST be logically consistent. (The same is not true for Inner Graphs., below).

The XDI identifier of a peer root node MUST be enclosedbegin and end with parentheses ( ) and MUST NOT be preceded by an XDI context symbol. The identifier contained within the parentheses MUST be either an XDI entity identifier or an absolute URI. Examples:

(=example)

(+example-company)

(*!: uuid:9ce739f0-7665-11e2-bcfd-0800200c18f2)

(*(https://example.com/))

Like any other context nodes, peer root nodes MAY be nested to any depth. This enables XDI authorities to separate create different XDI graphs at different XDI endpoints for different purposes and link them for the purpose of discovery. Examples:

(=example)(#household)

(+example-company)(#legal)(#mexico)

In keeping with the XDI REAL model, peer root and inner root nodes MUST precede entity or attribute nodes in the context tree. Like the common root node, a peer root node MAY use the <$uriiri> attribute to describe the network location of its XDI endpoint. Using the XDI protocol to discover the URI IRI for XDI peer root nodes is defined in the XDI Discovery specification [ref]. Following is an example XDI graph from which the URI IRI of two peer roots can be discovered:{

"(=example)": {

"<#uriiri>": {

"&": "https://xdi.example.com/"

}

},

"(=example)(#household)": {

"<#uriiri>": {

"&": "https://xdi.example.com/household/"

}

}

}

755

760

770

775

780

785

790

Drummond Reed, 09/27/15,

The option to have a bare URI inside a peer root was eliminated.

The common root node of an XDI graph may also describe its own XDI address by virtue ofusing either an a direct and/or inverse XDI equivalence statement to a peer root node (see Equivalence Relations). This is called the self-description pattern. It is illustrated in the example below. Note that:

1. In the first statement (a direct equivalence statement), where the peer root is the subject and the common root is the object, the address of the common root is the empty string.

2. In the second statement (an inverse equivalence statement), where the common root is the subject and the peer root is the object, the common root is represented by the outermost JSON object enclosing the entire JSON document.

{

"(=example)": {

"/$ref": [

""

]

},

"/$is$ref": [

"(=example)"

]

}

Note: in the XDI Messaging specification, the term “peer” is used for any XDI an agent or actor that sends and receives XDI messages between XDI endpoints.

Inner RootsThe third type of root node plays a very special role in XDI architecture. An inner root node represents the root of an XDI graph that is itself the object of an XDI relational statement. The graph contained by an inner root node is called an inner graph.

The XDI identifier of an inner root node MUST be enclosed with parentheses ( ) and MUST NOT be preceded by an XDI context symbol. The identifier contained within the parentheses MUST include the subject followed by theand predicate of the XDI relational statement whose object is the root node of the inner graph. The subject and predicate MUST come first and MUST be separated from the predicate by a forward slash. Examples:

(=example/#nominated)

(+example-company/#hired)

(*!: uuid:9ce739f0-7665-11e2-bcfd-0800200c18f2/#buyer)

795

800

805

810

815

820

825

In RDF terms, each context node in an inner graph represents a reification of an XDI statement. [ref] The subject and predicate of the reified statement are expressed by the XDI identifier of the inner root node. The object of the statement is the context node in the inner graph. Examples:

XDI Statement Reified Statement

=a/#b/=c (=a/#b)=c

=alice/#buddy/=charlie (=alice/#buddy)=charlie

As in RDF, once a statement has been reified, it is now a new XDI context that can serve as the subject of other XDI statements can now be made about thatthat describe the reified statement. This inner graph pattern is very common in XDI graphs since reification can be used to describe any relationship between two entities. Examples:

(=a/#b)=c/#d/=e

(=alice/#buddy)=charlie/#dentist/=edith

(=example/#hired)=abc/#employer/+example-company

(+example-company/+acquired)+other-.co<$year>/&/"2014"

The inner graph pattern is fundamental to the structure of link contracts, the primary control structure in the XDI protocol. Link contracts are defined in the XDI Policy specification [ref].

An inner root node or a context node within it can also serve as the object of an XDI statement. Examples:

=a/#b/(=c/#d)=e

=alice/#buddy/(=charlie/#dentist)=edith

Like other context nodes, peer root nodes MAY be nested to any depth. This enables “statements about statements about statements”. Examples:

(=a/#b)(=c/#d)=e/#f/=g

(=alice/#buddy)(=charlie/#dentist)=edith/#friend/=greg

835

840

850

855

In the JSON serialization, when a sequence of peer roots and/or inner roots is serves as an XDI subject, they are serialized as first level nested JSON objects. See Serialization.{

"(=alice/#buddy)": {

"=charlie": {

"/#dentist": [

"=edith"

]

}

},

"(=example/#hired)": {

"=abc": {

"/#employer": [

"+example-company"

]

}

},

"(+example-company/+acquired)": {

"+other-co": {

"<$year>": {

"&": "2014"

}

}

},

"=alice": {

"/#buddy": [

"(=charlie/#dentist)=edith"

]

}

}

860

865

870

875

880

885

890

There is a criticalan important distinction between peer graphs and inner graphs. Peer graphs are independent graphs that each contain a subset of the logical XDI common graph. By contrast every an inner graph can only be understood in the context of the unique XDI subject/predicate relationship that defines it. Therefore XDI statements in inner graphs are not required to be logically consistent with statements in the logical XDI common graph. XDI statements contained by an inner graph are relative to its specific inner root node and can only be merged with another XDI graph by also merging that the containing inner root node.

Therefore inner graphs are part of the XDI common graph and can be visualized as wholly contained “graphs within graphs”. Because peer graphs are all subsets of the logical XDI common graph, peer graphs can also contain inner graphs.

895

900

905

Collections [ ]In the XDI REAL model, a context node whose role is to define a group set of other context nodes of the same type is called a collection. The XDI identifier of an collection node MUST be enclosed with square brackets [ ].

The set of context nodes that belong to the collection are called its members. To be a member of a collection, a context node MUST be: a) a child subcontext of the collection node, and b) either an ordered instance or an unordereda valid instance of the collection class. For example, members of a [#passport] entity collection must represent instances of a passport, and members of a [<#color>] attribute collection must represent instances of a color.

A collection MAY be any class in a primary role, e.g., a root collection, an entity collection, or an attribute collection. Member instances of a collection MUST be of the same type as the collection, e.g., members of a [#passport] entity collection must represent instances of a passport, and members of a [<#color>] attribute collection must represent instances of a color. A collection MAY contain other child nodes, however any child node that is not an ordered or unordered instance of the collection class is not a member of the collection, but a descriptor of the collection. The following example shows a collection of email address attributes with three thing unordered member instances as members, plus a timestamp attribute that describes the collection itself and is not a member of the collection.

{

"=example": {



},



},

"[<#email>]<*!:uuid:62079220-da48-21cc-aca9-0002a5d51fe6uuid:eeba8eb3-0d44-4c0c-85ed-ee00281f0e26>": {


},

"[<#email>]<$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

910

915

920

925

930

935

940

945

A collection may also consist of ordered member instances, for example to indicate the priority or preference of those instances. Here is the same example showing ordered member instances:{

"=example": {

"[<#email>]<@~0>": {


},

"[<#email>]<@~1>": {


},

"[<#email>]<@~2>": {


},

"[<#email>]<$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

}

Note that in this example the order in the collection is mutable because the addresses of the ordered member instances do not include the immutability symbol. Ordering may be made immutable by adding the symbol, as shown below.{

"=example": {

"[<#email>]<@~!0>": {


},

"[<#email>]<@~!1>": {


},

"[<#email>]<@~!2>": {


},

"[<#email>]<$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

}

950

955

960

965

970

975

980

985

In some cases, an XDI authority may wish to combine both mutable ordering and immutable addressing within the same collection—for example, where the order of preference is mutable but a reference to a specific unordered member of the collection will be immutable. In the XDI REAL model, the advantages of both can be combined in the same collection using $ref relations (see Equivalence Relations). This is called the ordered/unordered reference pattern. An example using email address attributes is shown below (with UUIDs shortened for readability):{

"=example": {

"[<#email>]<@~0>": {

"/$ref": [

"=example[<#email>]<*!:uuid:x-1>"

]

},

"[<#email>]<@~1>": {

"/$ref": [


]

},

"[<#email>]<@~2>": {

"/$ref": [


]

},

"[<#email>]<*!:uuid:x-1>": {


},

"[<#email>]<*!:uuid:x-2>": {


},

"[<#email>]<*!:uuid:x-3>": {


},

"[<#email>]<$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

990

995

1000

1005

1010

1015

1020

}

A context node that is not explicitly a collection is a singleton, i.e., a single instance of that context node type. Singletons and collections in XDI are analogous to singular and plural nouns in English, e.g., “passport” and “passports”. The following example shows the same three email address attribute values as in the previous example, only each one is expressed as an <#email> singleton in a different context:

{

"=example": {

"<#email>": {

"&": "alice#example.com"

},

"<#home><#email>": {


},



}

}

}

1025

1030

1035

1040

By definition an attribute singleton may have only one literal value, whereas an attribute collection may contain multiple values. Again, the advantages of both can be combined in the same context using $ref relations. This is called the singleton/collection reference pattern. An example using email address attributes is shown below (with UUIDs shortened for readability):{

"=example": {

"<#email>": {

"/$ref": [


]

},

"<#home><#email>": {

"/$ref": [


]

},


"/$ref": [


]

},

"[<#email>]<*!:uuid:x-1>": {


},

"[<#email>]<*!:uuid:x-2>": {


},

"[<#email>]<*!:uuid:x-3>": {


},

"[<#email>]<$t>": {

"&": "2010-09-20T10:11:12Z"

}

}

}

1045

1050

1055

1060

1065

1070

1075

Definitions | |XML has schemas; RDF has ontologies; XDI has dictionaries. XDI uses the term “dictionary” for XDI ontology definitions because an XDI ontology term may be reused in many different XDI contexts just like a natural language word may be reused in many different linguistic contexts.

As with a natural language dictionary, a subject node in an XDI dictionary is called a definition. Each XDI definition is the subject of one or more definition statements. The XDI identifier of a definition context node MUST be enclosed with pipe symbols | |.

A definition MUST be a primaryone of four context roles, i.e., an entity definition, attribute definition, or root definition: root, entity, attribute, or collection. Only the definition statement types applicable to a particular context role may be used with that context role. For example, only an attribute definition may define the datatype of a literal value.

The universal standard attributes and relations for XDI definition statements types are defined in the XDI Dictionary 1.0 specification. These include the same basic ontological building blocks as in RDFS [ref] and OWL [ref], e.g.:

types

subtypes

supertypes

entities (for roots)

subentities (for entities)

superentities (for entities and attributes)

attributes (for roots and entities)

subattributes (for attributes)

superattributes (for attributes)

datatypes (for literals)

incoming relations (range)

outgoing relations (domain)

cardinality

Following is an example generic dictionary definition illustrating a number of common dictionary statement types (in order: entity type, outgoing relations, subentities and attributes, cardinality, and attribute types).

1080

1085

1090

1095

1100

1105

1110

{

"|#car|": {

"/$is#": [

"|#vehicle|"

],

"(/)": [

"|#owner|",

"|#driver|",

"|#insurer|"

],

"//": [

"|#engine|",

"|#door|",

"|<#model>|",

"|<$year>|"

]

},

"|#car||#engine|": {

"<$n>": {

"&": "1"

}

},

"|#car||#door|": {

"<$n>": {

"&": "2-4"

}

},

"|#car||<#model>|": {

"$is#": [

"|<$string>|"

]

},

"|#car||<#year>|": {

"$is#": [

"|<$number>|"

]

}

1115

1120

1125

1130

1135

1140

1145

1150

}

Using contextual statements, XDI dictionaries can also define superentities and superattributes. Following is an example of defining superentities for a #car:

{

"|#car|": {

"/$is()": [

"|#sports|",

"|#race|",

"|#economy|",

"|#luxury|"

]

}

}

These dictionary statements define the following specializations of the entity #car:

#sports#car

#race#car

#economy#car

#luxury#car

The same can be done for attributes:{

"|<#email>|": {

"/$is()": [

"|<#home>|",

"|<#work>|",

"|<#school>|",

"|<#priority>|"

]

}

}

These dictionary statements define the following specializations of the attribute <#email>:

<#home><#email>

<#work><#email>

<#school><#email>

<#priority><#email>

1155

1160

1165

1170

1175

1180

1185

Not all XDI dictionary definitions are generic, i.e., at the top level. The reason for the “X” in XDI (“extensibility”) is that any XDI authority can define its own XDI vocabulary in its own XDI namespace. To do this, the enclosing pipe | | syntax is used with either a personal or a legal authoritygroup identifier to define a “dictionary space”. Following is an example of the <#email> attribute being specialized by the legal authoritygroup +(https://xdi.org/) in its own dictionary space:{

"|<+(https://xdi.org/)>||<#email>|": {

"/$is#": [

"|<$string>|"

]

},

"|<+(https://xdi.org/)>||<#email>|<$xbnf>": {

"&": "1*( ALPHA / DIGIT ) %[email protected]%22"

}

}

Note: that $xbnf is an XDI-addressable variant of BNF that will be defined in the XDI Dictionary 1.0 specification.

This specialized dictionary definition may now be used in XDI statements by prefixing the <#email> attribute with the |<+(https://xdi.org/)>| attribute dictionary space. For example:{

"=example": {

"|<+(https://xdi.org/)>|<#email>": {


}

}

}

In English the same type of specialization would be expressed by prefixing an entity or attribute name with a proper noun. For example, the generic concept of “an “email address” could be specialized by calling it “an “XDI.org email address”.

1190

1195

1200

1205

1210

1215

1220

Variables { }A variable is an XDI context node that represents a set of XDI context nodes that will replace the variable context node when it is instantiated. Variables are needed in XDI policies, queries, and other expressions that need to reference a set of XDI nodes that meet specified parameters. The XDI identifier of a variable context node MUST be enclosed with curly brackets { }.

When instantiated, a variable is matched against a target graph. The matching rules depend on the type of variable. All variables except the common variable MUST match at least one arc to have a match. The common variable always has a match because it can also match zero arcs.

The Common VariableThe common variable is the simplest of all XDI variables. Like the common root node, it is empty, consisting of only a pair of curly brackets. By definition, the common variable matches any subgraph rooted in the context node where the common variable appears. The common variable MAY match any number of arcs, including zero.

For example, the following XDI operation will return the entire subgraph rooted in =example<#home>:

.../$get/=example<#home>{}

Typed VariablesA typed variable is a variable containing an XDI class identifier. The matching rules for typed variables are:

1. A matching instance of a typed variable MUST be a member of the XDI class identified by the variable.

2. By default, a matching instance MAY be at any depth in the subgraph rooted on the typed variable. (To constrain the depth of matching requires using a defined variable—see Defined Variables).

3. A typed variable containing a singleton class identifier MUST match either a singleton instance of that class or a member instance of a collection of that class.

4. A typed variable containing a collection class identifier MUST match an instance of that collection class.

1225

1230

1235

1240

1245

1250

Drummond Reed, 09/13/15,

Text from this section onward is new (i.e., not marked with revision marks). However sections that have been added after feedback are highlighted in yellow.

Examples:

Variable Matches an instance of

{()} A peer root node

{(/)} An inner root node

{=} A person

{+} A group

{*} A thing

{@} An orderordinal

{[]} An entity collection

{<>} An attribute

{[<>]} An attribute collection

{<*>} An attribute

{<@>} An attribute orderordinal

{$} A reserved class

{$from} A specific reserved class—$from

{#} An unreserved class

{#vehicle} A specific unreserved class—#vehicle

{[$]} A reserved entity collection

{[$to]} A specific reserved entity collection—$to

{[#]} An unreserved entity collection

{[#vehicle]} A specific unreserved entity collection—$vehicle

{<$>} A reserved attribute

{<$iri>} A specific reserved attribute—$iri

{<#>} An unreserved attribute

{<#email>} A specific unreserved attribute—#email

{[<$>]} A reserved attribute collection

{[<$iri>]} A specific reserved attribute collection—$iri

{[<#>]} An unreserved attribute collection

{[<#email>]} A specific unreserved attribute collection—$email

1255

Defined VariablesA defined variable is a variable that has additional constraints defined by a set of XDI statements using XDI dictionary vocabulary. The syntax for defined variables is the same as for typed variables except the class identifier uses XDI definition syntax, i.e., is enclosed in pipe characters.

Examples:

{|=|}

{|+|}

{|*|}

{|$from|}

{|#vehicle|}

{|<$iri>|}

{|<#email>|}

Note that the common variable may also serve as a defined variable by including a pair of pipe characters inside the curly brackets, i.e.:

{||}

In this case the defined variable itself imposes no type constraint on the instance; all constraints will be defined by the variable definition.

The location of the definition of a defined variable depends on the location of the defined variable.

1. If the defined variable appears in an XDI subject, the definition MUST appear in the same context as the defined variable.

2. If the defined variable appears in an XDI object, the definition MUST appear in the same context as the defined variable within an inner graph of that XDI statement.

The defined variable definition MUST be expressed using additional XDI statements as defined in the XDI Dictionary specification. For example, in the following XDI statement, the typed variable {<#phone>} will match any instances of a phone number to any depth below =example.

.../$get/=example{<#phone>}

To constrain: a) the match to only one instance, and b) the maximum depth of matching nodes to three, use the defined variable {|<#phone>|} with two definition statements in an inner graph:

1260

1265

1270

1275

1280

1285

1290

1. The first definition statement constrains the number of matches using the XDI dictionary cardinality attribute <$n>.

2. The second definition statement constrains the depth of matches using the XDI dictionary attribute <$depth>.

Example:{

"...": {

"/$get": [

"=example{|<#phone>|}"

]

},

"(.../$get)": {

"=example": {

"|<#phone>|<$n>": {

"&": "1"

},

"|<#phone>|<$depth>": {

"&": "1-3"

}

}

}

}

Note: when there are more matches for a variable than a definition constraint allows, it is up to the XDI endpoint (or the XDI authority for queried graph) to select the matches.

Reserved VariablesReserved variables are typed variables that use an XDI reserved class name (keyword) and have a specified function in the XDI protocol. Examples:

{$to}

{$from}

{$do}

Reserved variables are not defined variables because their definitions are not expressed as a set of XDI statements. Instead their function is specified in one or more XDI specifications, e.g., XDI Messaging, XDI Policy, XDI Connection, etc. [ref]

1295

1300

1305

1310

1315

1320

1325

Nested VariablesVariables are commonly used in XDI templates— XDI subgraphs used as the model for creating other XDI subgraphs. When an XDI template is instantiated, the variables it contains are replaced with a valid instance of each variable.

In some cases, an XDI template must contain a variable whose instantiation will be another variable. To enable this, XDI supports nested variables—one variable that contains another. Nested variable are expressed with a double pair of curly brackets. The outer pair represents the containing variable; the inner pair represents the nested variable. Following is an example of a nested reserved variable:

{{$from}}

To avoid recursion, variables may only be nested one level deep.

The Literal VariableXDI templates may need a variable to be instantiated with a literal value. This is called a literal variable and is expressed using the XDI literal symbol: {&}.

The literal variable MUST only be used as an XDI predicate. The XDI object of this predicate MUST be an attribute variable. When instantiated, the attribute variable MUST be instantiated with a valid attribute value.

Following is an example of an XDI template that uses a literal variable to specify that a minimum age value is required when the template is instantiated.{

"{{$to}}": {

"<#minimum><#age>": {

"/{&}": [

"{<#age>}"

]

}

}

}

Following is an example instantiation of this template.{

"{$to}": {

"<#minimum><#age>": {

"&": 13

}

}

}

1330

1335

1340

1345

1350

1355

1360

Core RelationsThis section defines the set of XDI relations that express standard relationship types in a semantic graph. These together with the XDI ABNF rules define the universal grammar of XDI. As shown in table __, many of the core relations correspond to the basic types of relationships defined in UML [ref] and other object modeling languages.

Category Relationship Expresses How modeled in XDI

XDI Relation

Inverse Relation

Equivalence Transitive equivalence

Logical union of subject and object

nodes

Identity relation

/$is/ /$is/

Visible canonical

equivalence

Transpose subject node onto object

node

Reference relation

/$ref/ /$is$ref/

Hidden canonical

equivalence

Transpose object node onto subject

node

Replacement relation

/$rep/ /$is$rep/

Hypernym-hyponym(supertype-subtype)

(superclass-subclass)

Subsumption(is-a)

(type-of)

Taxonomic hierarchy

(inheritance tree)

Type relation between classes

/#/ /$is#/

Class-instance(concept-object)

(type-token)

Instantiation(instance-of)

An instance belongs to a class

Type relation between class &

instance

Holonym-meronym Aggregation(has-a)

Possession without ownership

Aggregation relation

/$has/ /$is$has/

Composition(part-of)

Possession with ownership

Contextual relation

// /$is()/

Containment(member-of)

Set membership Collection

Equivalence RelationsThe same resource may be represented by multiple context nodes within an XDI graph. The XDI graph model provides two ways such equivalence may be asserted:

1. Equivalent identifiers may be used in different XDI contexts.

2. Equivalence statements may be made between different XDI contexts.

Equivalence statements are made using using three types of equivalence relations:

1. An identity relation asserts that two context nodes represent the same logical resource and that neither context is canonical. In this case a complete description of the resource requires a union of both subgraphs.

1365

1375

1380

2. A reference relation asserts that two context nodes represent the same logical resource and the object node is canonical. In this case only the object node may contain a subgraph describing the resource.

3. A replacement relation is the same as a reference relation except that XDI address of the object node is replaced by the XDI address of the subject node. In this case it will appear as if the subject node is canonical, i.e., the object subgraph will appear as if it was the subject subgraph, and the replacement relation will be invisible to a requestor.

Equivalent Identifiers

The first way equivalence may be established between two context nodes is by using the same absolute XDI identifier to identify the final arc in the context path. If two XDI context node addresses terminate in the same absolute XDI identifier, those XDI addresses MUST represent the same logical resource in different contexts. The two nodes MAY also have an explicit equivalence relation, but such a relation is not required to establish equivalence.

Absolute XDI identifiers are defined in Absolute and Relative Identifiers.

Following is an example of the same natural person represented by the same absolute XDI name =alice in three different contexts (the common root context and two group contexts).{

"=alice": {

"<#email>": {


}

},

"+example-company=alice": {

"<#email>": {


}

},

"+example-club=alice": {

"<#email>": {


}

}

}

Since XDI names are mutable (reassignable), immutable references require XDI numbers. Here is the same example using XDI numbers in the form of UUIDs.

1385

1390

1395

1400

1405

1410

1415

{

"=!:uuid:33ad7beb-1abc-4a26-b892-466df4379a51": {

"<#email>": {


}

},

"+!:uuid:f336a645-f5a9-41b7-ab80-ace41a8f69c2=!:uuid:33ad7beb-1abc-4a26-b892-466df4379a51": {

"<#email>": {


}

},

"+!uuid:1c958708-d5aa-4213-a6a9-73dd423502b3=!:uuid:33ad7beb-1abc-4a26-b892-466df4379a51": {

"<#email>": {


}

}

}

Identity Relations ($is)

It may not be possible or desirable to use the same absolute XDI identifier for the same resource in different XDI contexts. In this case the same type of equivalence MAY be established using an identity relation. An identity relation MUST be expressed using the XDI predicate $is.

Unlike all other XDI predicates, there is no inverse form—$is is its own inverse. See Inverse Relations.

A $is assertion of equivalence is reflexive, symmetric and transitive. It is not canonical, meaning that both the subject node and object node MAY have their own subgraphs without restriction. This means a full description of the described resource requires a union of both subgraphs.

A $is statement does not have any special XDI processing rules. Therefore if an XDI endpoint returns a $is statement, it is the requestor’s responsibility to determine if it needs to request the subgraph identified by the object of that statement.

1420

1425

1430

1435

1440

1445

1450

Following are two examples of $is identity relations. The first asserts equivalence between two XDI names—a rooted absolute person name and a nested relative personal name (in the context of a rooted absolute group name).

{

"=alice": {

"/$is": [

"+example.club=~alice.smith"

]

}

}

The second asserts equivalence between two XDI numbers (in the form of UUIDs)—a rooted absolute person number and a nested absolute person number (in the context of a rooted absolute group number).

{


"/$is": [

"+!:uuid:1c958708-d5aa-4213-a6a9-73dd423502b3=!:uuid:8ded2f7e-afb4-4494-9918-0fecf38f80d5"

]

}

}

Reference Relations ($ref)

In contrast to identity relations, which establish the equivalence of two context nodes where neither is canonical, a reference relation establishes the equivalence of two context nodes where the XDI address for the object node is canonical. In this case only the object node may contain a subgraph—the subject node may only contain a reference to the object node.

A reference relation MUST be expressed using the XDI predicate $ref. An inverse reference relation MUST be expressed with the XDI predicate $is$ref. See Inverse Relations.

A $ref assertion of equivalence is irreflexive, asymmetric and transitive. Because it is canonical, a context node described by a $ref relation MUST be the subject of exactly one $ref statement and MUST NOT be the subject of any other XDI statements.

1455

1460

1465

1470

1475

1480

1485

1490

An inverse reference relation is not canonical, so a context node described by an $is$ref relation MAY be the subject of more than one $is$ref statement and MAY contain its own subgraph.

When a $ref relation is reached while traversing an XDI address, the $ref relation MUST be followed to the object node, and traversal of the XDI address MUST continue from the object node. By default, when an XDI operation requests a subgraph containing a $ref relation, both the $ref relation and the object subgraph will be included in the returned subgraph.

Note: this behavior can be modified by an XDI messaging parameter as defined in the XDI Messaging specification.

Reference relations are needed for one of the most common patterns in XDI graphs: mapping a human-friendly mutable (reassignable) identifier (an XDI name) to a machine-friendly immutable (persistent) identifier (an XDI number). This is called the name/number reference pattern. The following example shows a name/number $ref relation for both a person and a group:

{

"=alice": {

"/$ref": [

"=!:uuid:33ad7beb-1abc-4a26-b892-466df4379a51"

]

},

"+example.club": {

"/$ref": [

"+!:uuid:1c958708-d5aa-4213-a6a9-73dd423502b3"

]

}

}

Replacement Relations ($rep)

A replacement relation is identical to a reference relation except for the XDI addressing rules. With a reference relation, the XDI address of the object node is canonical—the $ref relation on the subject node “redirects” to the object node. With a replacement relation, the XDI address of the subject node is canonical, and the subgraph of the object node is logically transposed onto the subject node. The XDI address of the object node is never revealed—nor is the replacement relation. It is only visible to the XDI authority for the graph.

A replacement relation MUST be expressed using the XDI predicate $rep. An inverse replacement relation MUST be expressed with the XDI predicate $is$rep. See Inverse Relations.

1495

1500

1505

1510

1515

1520

1525

1530

A $rep assertion of equivalence is irreflexive, asymmetric and transitive. Because it is canonical, a context node described by a $rep relation MUST be the subject of exactly one $rep statement and MUST NOT be the subject of any other XDI statements.

An inverse replacement relation is not canonical, so a context node described by an $is$rep relation MAY be the subject of more than one $is$rep statement and MAY contain its own subgraph.

When a $rep relation is reached while traversing an XDI address, the $rep relation MUST be followed to the object node, and traversal of the XDI address MUST continue from the object node. When an XDI operation requests a subgraph containing a $rep relation, the $rep relation MUST NOT be included in the returned subgraph. Instead the object’s subgraph MUST be transposed to become the subject’s subgraph.

Replacement relations are fundamental to Privacy by Design [ref http://privacybydesign.ca/]. In particular, $rep relations enable XDI authorities to publish pseudonyms in order to control correlation between different XDI contexts. Following is an example of a private XDI number used as a pseudonym to share a person’s age using a $rep relation without revealing the individual’s public XDI number. See Public and Private Identifiers.{


"<#age>": {

"/$rep": [

"+!:uuid:1c958708-d5aa-4213-a6a9-73dd423502b3<#age>"

]

}

},

"+!:uuid:1c958708-d5aa-4213-a6a9-73dd423502b3": {

"<#name>": {

"&": "Alice Smith"

},

"<#email>": {


},

"<#age>": {

"&": 33

}

}

}

1535

1540

1545

1550

1555

1560

1565

1570

If the following XDI $get request was performed on the graph above:

.../$get/=!:uuid:33ad7beb-1abc-4a26-b892-466df4379a51<#age>

Then the following XDI graph would be returned:{


"<#age>": {

"&": 33

}

}

}

Equivalence of Context Types and Roles

For two context nodes to be equivalent, they MUST have the same context type and role. For example, if two context nodes represent different XDI names for the same person, both must be person entity nodes. If two context nodes represent the same email address in different contexts, both must be attributes. If two context nodes represent synonyms in a dictionary, both must be definitions.

Equivalence and Directed Graph Cycles

The contextual arcs in an XDI graph form a rooted tree. To ensure deterministic traversal, this rooted tree must be acyclic—it cannot allow a chain of contextual arcs to loop around in a circle, i.e., that start at one node and end up back at that same node. In graph theory, such a loop is called a cycle.

Cycles would not be a problem if an XDI rooted tree consisted of only contextual arcs where all the labels were relative (like DNS). However if either: a) equivalent identifiers are used for nodes within the rooted tree, or b) equivalence relations are added between nodes in the rooted tree, then it becomes possible to form a cycle. Therefore, if an XDI agent or an XDI endpoint adds an equivalent identifier or an equivalence statement to an XDI graph, it MUST NOT create a cycle.

Rules for Processing Equivalence Relations

Rules for processing of operations on XDI graphs are defined in the XDI Messaging specification [ref]. This includes rules for processing of equivalence relations. For informative purposes, here is a summary:

1. A standard XDI /$get/ operation must return all reference relations but must not return any replacement relations.

2. If an XDI /$get/ message specifies a <$deref> parameter, the operation must process all reference relations as if they were replacement relations. This means: a) each $ref predicate in the result graph must be replaced

1575

1580

1585

1590

1595

1600

1605

with a $rep predicate, and b) the resulting statement must be processed as a replacement relation. Therefore the XDI graph returned by this /$get/ operation will not contain any reference or replacement relations—they will all have been dereferenced.

3. If a reference relation or replacement relation is included in the processing of an XDI $add, $set or $del operation, it must be processed according to the standard rules for equivalence relations, and processing of the operation must continue at the object of the statement. The final target statement(s) to be added or deleted must be determined only after all reference or replacement relations have been processed.

4. If the target of an XDI operation is itself a reference relation or replacement relation, that relation must not be processed. Instead, the operation must apply directly to the $ref or $rep statement.

Inverse RelationsDue to its semantic tree architecture, the inverse of any XDI predicate may be expressed algorithmically by prefixing it with the $is identity equivalence relation. If an XDI predicate is prefixed by $is, it MUST be interpreted as expressing the inverse relation of the same XDI predicate without the prefix. Examples:


=luke.skywalker #father =darth.vader

=darth.vader $is#father =luke.skywalker

[#vehicle]!*:uuid:x-1 #owner =example

=example $is#owner [#vehicle]!*:uuid:x-1

+example.club $ref +!:uuid:x-2

+!:uuid:x-2 $is$ref +example.club

In semantic terms, the $is prefix expresses that the subject of a statement whose predicate includes the $is prefix is equivalent to the object of the same statement made without the $is prefix.

A predicate that uses the $is prefix is called an inverse predicate. A statement that uses an inverse relation is called an inverse statement. A predicate that does not use the $is prefix is called a direct predicate. A statement that does not use an inverse relation is called a direct statement.

An inverse relation may be used to express the inverse of any XDI statement except the $is identity equivalence relation itself (which is its own inverse). This includes XDI contextual statements. However, because the predicate of an XDI contextual

1610

1615

1620

1625

1630

1635

statement is empty, an inverse contextual statement MUST use the predicate $is(). The empty parentheses encapsulate the empty predicate.

Inverse contextual statements are particularly useful in XDI graphs because they provide a mechanism for discovering other contexts for a resource. For example, a requestor who only has knowledge of =alice could query the following XDI graph (assuming the requestor has permission) to discover that =alice also exists in the +example.company and +example.club contexts.

{

"=alice": {

"/$is()": [

"+example-company",

"+example-club"

],

"<#email>": {


}

},

"+example-company=alice": {

"<#email>": {


}

},

"+example-club=alice": {

"<#email>": {


}

}

}

1640

1645

1650

1655

1660

1665

Type Relations (#)The heart of ontologies is type relationships, i.e., defining subtypes (subclasses) and supertypes (superclasses). In XDI, these relationships are expressed using XDI type statements. Since the concept of “type” is already represented in XDI as # (the context symbol for unreserved classes), an XDI type relation MUST be expressed using the XDI predicate #. An inverse type relation MUST be expressed with the XDI predicate $is#.

XDI type statements fall into two categories:

1. Relationships between subclasses and superclasses. These correspond to rdf:subClassOf relations.

2. Relationships between instances and classes. These correspond to rdf:type relations.

Since the context symbol for an XDI context already indicates whether it is a class or an instance, the same XDI type relations can express either category of type statement.

Examples of superclass/subclass relations:


#food # #fruit

#fruit # #apple

#fruit # #banana

#fruit # #pear

<$string> # <#name>

<$string> # <#email>

Examples of subclass/superclass relations:


#fruit $is# #food

#apple $is# #fruit

#banana $is# #fruit

#pear $is# #fruit

<#name> $is# <$string>

<#email> $is# <$string>

1670

1675

1680

1685

Examples of class/instance relations:


#carpenter # =!:uuid:...

#church # +!:uuid:...

#car # *!:uuid:...

Examples of instance/class relations:


=!:uuid:... $is# #carpenter

+!:uuid:... $is# #church

*!:uuid:... $is# #car

Aggregation Relations ($has)From an object modeling standpoint, XDI contextual relations are analogous to UML composition (whole/part) relationships, where a composite object both possesses and owns a set of component objects. The defining feature of composition is ownership, i.e., when a composite object is destroyed, so are its component objects. This is true of XDI contexts—if a context node is deleted, so are all the context nodes in its subgraph.

UML also defines aggregation relationships, where an aggregate object possesses but does not own a set of aggregated objects. The defining feature of aggregation is lack of ownership, i.e., when an aggregate object is destroyed, its aggregated objects are not. They continue to live independently of the aggregate object.

This is often called a “has-a” relationship. For this reason, aggregation relations in XDI are expressed using the XDI predicate $has. An inverse aggregation relation MUST be expressed with the XDI predicate $is$has.

1690

1695

1700

1705

Compared to contextual relations, the defining feature of $has relations in XDI is the same as in UML: if the subject of a $has relation is deleted, the object of the relation is not affected (unless the object happens to be in the subgraph of the subject).

A classic example is a university department: it has a set of professors, but if the university department is closed, the professors still exist. The following example shows both the university group entity and each of the professors’ person entities as independent root-level entities aggregated via a $has relation:

{

"+example-university#magic#department": {

"/$has": [

"=example-prof-1",

"=example-prof-2",

"=example-prof-3"

]

},

"=example-prof-1": {

"<#name>": {

"&": "Albus Dumbledore"

}

},


"<#name>": {

"&": "Minerva McGonagall"

}

},


"<#name>": {

"&": "Severus Snape"

}

}

}

Because the aggregated entities in this example are root-level, their attributes (such as the <#name> attribute shown above) describe them independently of any other context. XDI’s semantic tree architecture also enables the aggregated entities to be described in the context of the aggregating entity. This is called the contextual description pattern.

1710

1715

1720

1725

1730

1735

1740

The advantage of contextual descriptions is that the attributes and relations of the aggregated entity can be specific to the aggregating context. For example, in the university professor scenario above, contextual descriptions may be used to express the names and email addresses of the university professors in the context of a specific university department. {

"+example-university#magic#department=example-prof-1": {

"<#name>": {

"&": "Headmaster Dumbledore"

},

"<#email>": {


}

},


"<#name>": {

"&": "Professor McGonagall"

},

"<#email>": {


}

},


"<#name>": {

"&": "Professor Snape"

},

"<#email>": {


}

}

}

Contextual description of the members of a group is optional because it is only needed when a group member has context-specific attributes or relations. When it is required to express group membership in XDI, it MUST be expressed using a $has relation between the group entity and each group member entity. A group member entity MAY be either a person entity or another group entity, i.e., groups may contain other groups.

In general, as with UML aggregation relationships, an XDI $has aggregation relation does not constrain the type of entity that may be aggregated. There is one exception.

1745

1750

1755

1760

1765

1770

1775

1780

If the subject of a $has relation is a collection, the object of this relation MUST be a member of the collection class. This is called the virtual collection pattern. It applies whenever members of a collection are independent entities that do not have contextual descriptions. A typical example is a person’s music album collection.{

"=example-person[#album]": {

"/$has": [

"+moody-blues[#album]*~every-good-boy-deserves-favour",

"+rolling-stones[#album]*~sticky-fingers",

"+derek-and-the-dominos[#album]*~layla"

]

},

"+moody-blues[#album]*~every-good-boy-deserves-favour": {

"<#release><#year>": {

"&": "1971"

}

},

"+rolling-stones[#album]*~sticky-fingers": {


"&": "1971"

}

},

"+derek-and-the-dominos[#album]*~layla": {


"&": "1971"

}

}

}

Virtual collections are another example of how traditional database indexes may be modeled in an XDI graph.

$has aggregation relations are as useful in XDI as they are in UML. They can model many forms of resource ownership and control. A specific application is digital signatures: an XDI signature attribute can use a $has relation to specify the set of XDI subgraphs included in the signature’s scope. The use of $has relations with XDI digital signatures is specified in the XDI Cryptographic Mechanisms specification [ref].

1785

1790

1795

1800

1805

1810

1815

Boolean RelationsTo meet the design goal of describing authorization, policy, and rights expression, XDI must be able to describe Boolean logic trees. These relations are formally defined in the XDI Policy specification but are summarized in table __ for reference:

Relation Definition$true Logical true statement

$false Logical false statement

$and Logical conjunction

$or Logical disjunction

$not Logical negation

$if Logical branching

XDI OperationsThe final category of core relations is the set of XDI predicates representing the standard XDI protocol operations on XDI graphs. These are formally defined in the XDI Messaging specification [ref], but are summarized in table __ for reference:

Relation Operation in Target Graph$get Read statements

$set Write statements (union of $add and $mod)

$add Add new statements

$mod Update the value of a literal

$del Delete statements

$connect Instantiate a new XDI connection

$send Send an XDI message

$push Publish an XDI message to subscribers

$do Authorize other operations

1820

1825

NominalizationIn linguistics, nominalization is the use of a verb as a noun. In XDI, nominalization is the use of an XDI relation as an XDI context. The nominalization pattern is needed in XDI for the same reason as in human language: to embody relations so they may have their own descriptions, attributes, and ordering.

A common case is when an XDI protocol operation needs a parameter. For example, in the following XDI message, the $get request in the first statement is nominalized in order to add the <$deref> parameter in the second statement.

{

"=!:uuid:x-1[$msg]*!:uuid:x-2$do": {

"/$get": [

"=!:uuid:x-3<#email>"

]

},

"=!:uuid:x-1[$msg]*!:uuid:x-2$do$get": {

"<$deref>": {

"&": true

}

}

}

Another common example involves the name/number reference pattern, where a mutable human-friendly XDI name for an entity has a $ref equivalence relation to an immutable XDI number for the entity. With this pattern it is easy to start with the XDI name to look up the XDI number. However a relying party such as an online merchant may frequently need to do the opposite, i.e., look up a human-friendly XDI name from a persisted XDI number (e.g., to greet a returning customer).

This is not as simple as following an inverse reference relation ($is$ref) from the XDI number to the XDI name because the person may have more than one XDI name that references his/her XDI number.

1835

1840

1845

1850

1855

1860

As shown in example __, the solution is to nominalize the $is$ref relation so it may be treated as a subcontext in the person’s XDI graph. This new subcontext can now express a canonical ref relation to the person’s preferred XDI name. (Note that this preference is stored inside an inner graph describing the merchant’s unique relationship with that particular customer.){

"=!:uuid:x-1": {

"/$is$ref": [

"=alice",

"=alison",

"=alice.smith"

]

},

"+!:uuid:x-2": {

"/$is$ref": [

"+example.merchant"

]

},

"(+!:uuid:x-2/=!:uuid:x-1)": {

"=!:uuid:x-1$is$ref": {

"/$ref": [

"=alice.smith"

]

}

}

}

ABNF[modules here]

1865

1870

1875

1880

1885

1890

XDI AddressingThe first design goal of XDI architecture is 100% addressability of all graph nodes. This is accomplished via XDI’s semantic tree structure and formally defined in the ABNF rules. The patterns and rules for addressing and traversing nodes within this semantic tree structure are summarized in this section.

Semantic Tree ArchitectureAs shown in figure __, a semantic tree is a hybrid between a semantic graph and a conventional directory tree.

Like an RDF semantic graph, all arcs in an XDI graph are represented with subject/predicate/object triples. Like a conventional X.500 directory tree, hierarchical relationships in an XDI graph may be represented using contextual arcs that form a rooted tree structure. This combination yields the identifier and addressing features described in this section.

1895

1900

1905

REAL Sequences

The first rule of XDI addressing within a semantic tree, enforced in the ABNF, is that the sequence of XDI identifiers composing an XDI address MUST follow the XDI REAL (Root-Entity-Attribute-Literal) sequence order. Table __ lists the sequence patterns that are valid per the ABNF.

Pattern # Root Entity Attribute Literal

1 X X X X

2 X X X

3 X X

4 X

5 X X X

6 X X

7 X

8 X X

9 X

10 X X X

11 X X

Note that in patterns 8, 9, 10, and 11, the attribute describes the root node, i.e., the graph itself, and not any entity in the graph. In patterns 8 and 9, the attribute describes the common root node of the current graph. In patterns 10 and 11, the attribute describes a peer root or inner root node.

Note also that a peer root node MUST appear before an inner root node in a sequence that includes both root node types.

Specialization and Generalization

Within a semantic tree, there is a standard pattern called the specialization/ generalization pattern for specializing the semantic meaning of an entity or attribute. This pattern is based entirely on the order of the XDI identifiers representing each arc in an XDI address. The rule is: each identifier in a sequence of entity identifiers specializes the final entity in the sequence, and each attribute in a sequence of attribute identifiers specializes the final attribute in the sequence.

1910

1920

1925

1930

This rule applies no matter how deep the sequence. For example, each of the following XDI addresses further specializes the final entity—in this case a bolt.

#bolt

#locking#bolt

#engine#locking#bolt

#airplane#engine#locking#bolt

#jet#airplane#engine#locking#bolt

+example-corp#jet#airplane#engine#locking#bolt

Note: although the specialization/generalization pattern happens to align with the way a noun is specialized by a series of adjectives or adverbs in English, it is not derived from the English language (or any other human language). It is a natural property of semantic trees.

In the first five cases in the example above, the specialization is one of type; each preceding entity class further specializes the type of bolt. Such type specializations may be one of two kinds:

1. Defined specializations are formally defined in an XDI dictionary so there are machine-understandable rules describing how the specialization either categorizes or modifies the attributes and/or relations of the specialized entity.

2. Ad hoc specializations do not change the semantic definition of an entity but serve only to categorize it.

In the final case in the example above, where the class sequence is put in the context of the +example-corp group instance, the specialization is only one of ownership and does not affect the semantic definition of the entity.

The specialization/generalization pattern also applies to attributes. The following examples shows how a phone number attribute might be specialized:

<#phone>

<#home><#phone>

<#work><#phone>

<#fax><#phone>

<#home><#fax><#phone>

<#work><#fax><#phone>

In this example, none of the specializations changes the semantics of the phone number being described; they all serve only to categorize it.

1935

1940

1945

1950

1955

1960

1965

Note that the specialization/generalization pattern cannot be applied to peer root nodes—because they all represent peer XDI graphs—or to literal nodes—because they cannot be nested.

Peer Roots and XDI Discovery

Conventional directory tree architectures such as X.500, LDAP, and DNS assume a single rooted directory information tree (DIT). XDI semantic tree architecture assumes there may be any number of parallel rooted trees (peer graphs), each with its own peer root node. As discussed in the Peer Roots section, while all peer graphs have a single logical root (the XDI common root node), none of them are assumed to be authoritative for a particular branch of the graph. Authority may only be determined by consensus among a set of peers.

The process of determining this consensus is called XDI discovery and is defined by the XDI Discovery specification [ref]. XDI discovery begins with the assumption that any peer root node may contain its own subgraph of other peer root nodes, including attributes such as the authoritative IRIs for their XDI endpoints. Each of these subgraphs is itself a branch of the semantic tree. An XDI discovery agent may “walk the tree” of the peer root nodes it trusts to discover the location of other peer graphs. In this process it may also determines their consensus about the authority for a particular branch of the XDI semantic tree.

The sequence of peer root nodes that need to be traversed to determine the location and authority of another peer root node is called the peer root address. Each peer root node in the address includes the XDI identifier for the entity authoritative for that peer root relative to the previous peer root. This discovery process can be applied to all XDI entities, including persons, groups, and things. Examples of peer root addresses:

(=example-person)

(+example-corp)(=example-person)

(+example-consortia)(+example-corp)(=example-person)

(=example-person)(*example-thing)

(=example-corp)(*example-thing)

Each peer graph for(=example-person) in the above examples represents the same natural person (because it has the same absolute XDI identifier). However each is a different peer graph because of its position in the peer root address. In the first example, the peer graph is at the common root level. This means the authority is the natural person with the following XDI entity address:

=example-person

In the second example, the peer root (=example-person) is relative to the peer root(+example-corp). This means it is authoritative for the following XDI address:

+example-corp=example-person

1970

1975

1980

1985

1990

1995

2000

2005

This is a contextual description of =example-person in the context of +example-corp, for which +example-corp is authoritative.

In the third example, the peer root (+example-corp) is itself relative to the peer root(+example-consortia). This means it is authoritative for the following XDI address:

+example-consortia+example-corp=example-person

This is a contextual description of =example-person in the context of +example-corp, which in turn is a contextual description in the context of +example-consortia. The first entity in this sequence, +example-consoritia, is ultimately authoritative for this entire address.

This pattern may be nested as deeply as needed in order to delegate authority for XDI peer graphs the same way authority may be delegated in DNS or other hierarchical naming and directory tree systems.

Note that because any number of peer graphs may describe the same peer root address, in XDI there is no single authoritative peer root node at which to begin discovery of that address. Instead, an XDI discovery agent may choose a specific peer root node to trust as the starting point, or it may query multiple peer root nodes and compare their answers to determine a consensus.

For more details on XDI discovery, see the XDI Discovery specification [ref].

2010

2015

2020

2025

Inner Roots and XDI Reification

As described in Inner Roots [ref], semantic tree architecture uses the inner graph pattern to reify a relationship so it can be further described. This pattern is fundamental to many aspects of XDI architecture including XDI messaging, XDI connections, and XDI policies.

From an XDI addressing standpoint, the inner graph pattern enables context nodes to be described and addressed in the context of either a generic or a specific relationship. For a generic relationship, the predicate of the inner graph is an XDI class, and all the root-level subjects of the inner graph are members of that class, as shown in the following example.{

"(=alice/#friend)": {

"=bob": {

"/#introducer": [

"=beth"

],

"<#introduction><$date>": {

"&": "2010-11-12"

}

},

"=edith": {

"/#introducer": [

"=beth"

],


"&": "2010-11-13"

}

},

"=frank": {

"/#introducer": [

"=edith"

],


"&": "2010-11-14"

}

}

}

2030

2035

2040

2045

2050

2055

2060

}

For a specific relationship, the predicate of the inner graph is an XDI instance, and the root-level subjects of the inner graph are either attributes of that specific relationship, or entities describing the relationship, as shown in the following example.{

"(=alice/=bob)": {

"#marriage": {

"/#minister": [

"=parson-brown"

],

"<$date>": {

"&": "2010-08-22"

}

}

}

}

From the standpoint of XDI addressing, it does not matter if an inner graph is generic or specific. It both cases, the inner graph serves as the root of another complete XDI graph, and addressing within this graph works the same way as inside any XDI common graph, with one exception: an inner graph MUST NOT contain a peer root node. Only the common root node or another peer root node may contain a peer root node. However an inner root node MAY contain another inner root node.

Both generic and specific relationships described by inner graphs are the starting point for XDI link contracts. A link contract is an entity that describes the rights and permissions over one or more XDI subgraphs that an authorizing XDI authority extends to a requesting authority. Each link contract includes a policy branch that uses nested inner graphs to express the policies that must be satisfied in order to grant authorization. XDI link contracts and policy expressions are defined in the XDI Policy specification [ref].

2065

2070

2075

2080

2085

2090

Namespace ArchitectureThe ABNF defines six native namespaces for XDI identifiers. Table __ summarizes the properties of these namespaces as defined in the following sections.

Namespace

Mutable Immutable!

Absolute Relative~

Rooted Nested IRI( )

$ No Yes Yes No Yes Yes No

# No Yes Yes Yes Yes Yes Yes

= Yes Yes Yes Yes Yes Yes Yes

+ Yes Yes Yes Yes Yes Yes Yes

* Yes Yes Yes Yes Yes Yes Yes

@ Yes Yes Yes* Yes Yes* Yes No

* Absolute ordinal identifiers are not ordered. See Ordinals.

Four of the namespaces also allow the use of IRIs as XDI identifiers. This allows any resource with an IRI to be described by an XDI graph. In addition, any XDI address may be transformed into a valid IRI, so all XDI graph nodes may be treated as Web resources. See IRI. [ref]

Mutable and Immutable Identifiers (XDI Names and XDI Numbers)

To meet the Persistent Identification design goal [ref], XDI namespace architecture requires the ability for XDI authorities to assign identifiers that are immutable, i.e., assigned once to identify a resource and never reassigned to identify a different resource. Immutable XDI identifiers are also called XDI numbers. The requirements for immutable identifiers are defined by the IETF URN (Uniform Resource Name) specification [ref].

At the same time, to meet human usability requirements, XDI namespace architecture requires the ability for XDI authorities to assign identifiers that are mutable, i.e., that may be assigned to identify one resource at one point in time and a different resource at a different point in time. Mutable XDI identifiers are also called XDI names. Examples of mutable identifiers are dynamic IP addresses, domain names that may be bought and sold by different owners, and email addresses that may be recycled to different users.

Because XDI names are typically more human-friendly than XDI numbers, they are the default form of XDI identifier. XDI addressing only requires explicit syntax to express an XDI number. All XDI identifiers except those in the class namespaces ($ and #) MUST use the ! immutability symbol if and only if the XDI authority for that identifier asserts that the identifier is immutable.

All identifiers in the XDI class namespaces are immutable by definition and MUST NOT use the immutability symbol. While an XDI class identifier MUST NOT be reassigned, its definition MAY evolve. An evolved definition SHOULD be identified with an XDI version number. See Versioning.

2095

2100

2105

2110

2115

2120

The XDI & literal symbol is immutable by definition and MUST NOT use the immutability symbol.

An XDI address consisting of a sequence of XDI identifiers is immutable if and only if all of the XDI identifiers in the sequence are immutable.

The name/number reference pattern defined in the Reference Relations section demonstrates how XDI graphs may use equivalence relations to map human-friendly mutable identifiers to machine-friendly immutable identifiers. Such mappings may also be cryptographically signed. Thus, while neither an XDI name nor an XDI number by itself can solve the namespace design problem known as Zooko’s Triangle [ref https://en.wikipedia.org/wiki/Zooko%27s_triangle], the combination of an XDI name/number mapping can effectively “square Zooko’s triangle”.

Absolute and Relative Identifiers

Absolute and relative identifiers play a very different role in semantic tree architecture than in conventional directory tree or federated namespace architectures. In the latter, absolute identifiers only exist at the top level of the tree, i.e., they identify first level of nodes under the root. All other identifiers for nodes below the first level are relative to the nodes above them.

In XDI, an absolute identifier is one that identifies the same logical resource regardless of its parent context. A relative identifier is one whose scope of identification of a resource is relative to its parent context.

For example, in each of the following three XDI addresses, the identifier =!:uuid:x-1 identifies the same natural person.

=!:uuid:x-1

+!:uuid:x-2=!:uuid:x-1

+!:uuid:x-3+!:uuid:x-2=!:uuid:x-1

In the second address, the person is represented in the context of a group that also has an absolute address. In the third address, both the person and the first group are represented in the context of a second group that also has an absolute address.

Because absolute identifiers may exist at any level of the XDI graph and because they provide so much semantic value, they are the default form of XDI identifier. XDI addressing only requires explicit syntax to express when an XDI identifier is relative. All XDI identifiers except those in the $ reserved class namespace MUST use the ~ relativity symbol if and only if the XDI authority for that namespace asserts that the identifier is relative.

All identifiers in the $ reserved class namespace are absolute by definition and MUST NOT use the relativity symbol.

The following two XDI addresses are an example of a relative identifier for a person in the context of absolute identifiers for two different groups.

2125

2130

2135

2140

2145

2150

2155

2160

https://en.wikipedia.org/wiki/Zooko's_triangle

+!:uuid:x-4=~alice

+!:uuid:x-5=~alice

Unlike the previous example, no inference can be made that the person identified by =~alice relative to the first group has any relationship to the person identified by =~alice relative the second group. The equivalence of the two relative identifiers has no semantic meaning in an XDI graph.

An XDI address consisting of a sequence of XDI identifiers is absolute if and only if it begins with an absolute identifier. Because of this rule, when a relative identifier is placed in the context of an absolute identifier, the combination becomes absolute. For example, in the three XDI addresses below, the combination of +!:uuid:x-4=~alice represents the same unique person in all three.

+!:uuid:x-4=~alice

+!:uuid:x-5+!:uuid:x-4=~alice

+!:uuid:x-6+!:uuid:x-5+!:uuid:x-4=~alice

This rule holds true even for multiple relative identifiers. For example, in the three XDI addresses below, the combination of +!:uuid:x-4=~alice*~phone represents the same unique device in all three.

+!:uuid:x-4=~alice*~phone

+!:uuid:x-5+!:uuid:x-4=~alice*~phone

+!:uuid:x-6+!:uuid:x-5+!:uuid:x-4=~alice*~phone

An XDI address consisting of a sequence of XDI identifiers that begins with a relative identifier is always relative, even if other identifiers in the sequence are absolute.

To summarize the rules, an XDI absolute identifier:

1. MUST be globally unique in the XDI logical graph.

2. MUST NOT include the relativity symbol.

3. MAY appear at any level of an XDI graph.

4. MUST be inferred as identifying the same logical resource regardless of the context in which it appears.

An XDI relative identifier:

1. MUST be unique within the scope of its parent context node.

2. MUST include the relativity symbol.

3. MUST NOT appear at the root level of an XDI graph.

4. MUST NOT be inferred as identifying the same resource relative to any other XDI context node.

2165

2170

2175

2180

2185

2190

2195

Rooted and Nested Identifiers

For the same reason a semantic tree has different definitions of absolute and relative identifiers, it needs different terms for describing the relative position of an identifier in an XDI address.

In conventional directory tree or federated namespace architectures, an absolute identifier must be the first identifier in an address sequence because its parent is the root node. All other identifiers in the address sequence are relative.

In a semantic tree, an absolute identifier may exist at any level of the tree. So XDI uses the term rooted identifier for an identifier whose parent is a root node, and rooted address for an XDI address that begins with a rooted identifier. It uses the term nested identifier for an identifier that whose parent is not a root node, and nested address for an XDI address that begins with a nested identifier.

Per the rules in the previous section, it follows that:

1. An XDI rooted identifier MUST be an absolute identifier, and a rooted address MUST be an absolute address.

2. An XDI nested identifier MAY be either an absolute or a relative identifier, and a nested address MAY be either an absolute or a relative address.

An XDI rooted address is the equivalent of a fully-qualified address in conventional directory tree or federated namespace architectures. Those architectures assume only a single root node so there is only a single form of a rooted address. In XDI semantic tree architecture there are four forms of rooted addresses as shown in table __.

Rooted Address Type

Example

Common rooted =alice<#email>

Peer rooted (+example-corp)=alice<#email>

Inner rooted (+example-corp/#employee)=alice<#email>

Peer and inner rooted (+example-dir)(+example-corp/#employee)=alice<#email>

In all four examples, the rooted address is =alice<#email>. In the first example, the root is the common root. In the second, the root is a peer root; in the third, an inner root; and in the fourth, both a peer root and an inner root.

Note that when an XDI address begins with a peer or inner root node, that peer or inner root node is itself still rooted in the common root node. The common root node is the logical parent node of all absolute XDI addresses.

2200

2205

2210

2215

2220

2225

Public and Private Identifiers

Most directory tree and federated namespace architectures are designed for either public or private access, but not both. XDI semantic tree namespaces are equally suited for both public and private access.

Unlike the distinctions between mutable and immutable identifiers and between absolute and relative identifiers, the distinction between public and private identifiers is not syntactic, but rather one of access policy.

A public identifier is an XDI identifier whose XDI discovery information is available at an XDI endpoint accessible via a public link contract, i.e., a link contract that does not require thegrants any requesting authority to have permission to access the subgraph without authentication. Public link contracts are defined in the XDI Policy specification [ref].

A private identifier is an XDI identifier that requires an authenticated link contract in order to access its XDI discovery information.

Note that the distinction between public and private identifiers in XDI does not dependent on the visibility of the identifier itself. A public identifier may be kept completely hidden or a private identifier may be publicly known. The distinction is based on control over access to discovery information.

A special XDI context, $anon, is reserved for private identifiers whose subgraphs are intended for sharing XDI data while preserving anonymity, such as might be required for aggregated health records or quantified self data. The $anon context is defined in the XDI Privacy Mechanisms specification [ref].

The ability to support both public and private identifiers—and for private identifiers to use $rep replacement relations to protect pseudonymity as described in the Replacement Relations section [ref]—is a key component of how XDI semantic tree architecture supports Privacy By Design [ref].

InternationalizationTo enable XDI to describe any resource that humans are able to identify in natural language, XDI identifiers support the full Unicode character set [ref] within the limits of the canonicalization requirements in the following section.

To enable XDI to describe any resource on the World Wide Web, XDI identifiers support the encapsulation of any IRI (Internationalized Resource Identifier) as covered in the IRI section.

Normalization and CanonicalizationConsistent identification of resources both within and across contexts is vital to interoperability of XDI. Therefore XDI requires stringent normalization of XDI identifiers. The following normalization and canonicalization rules apply to all XDI identifiers except encapsulated IRIs.

2230

2235

2240

2245

2250

2255

2260

2265

1. XDI identifier characters in the ASCII range MUST be normalized to use only lowercase ASCII letters.

2. XDI identifier characters outside the ASCII range must be normalized according to Unicode form NFKC.

3. If an XDI identifier character requires percent-encoding, the hexadecimal characters required to express the percent-encoding MUST be in uppercase.

When an IRI is encapsulated as an XDI identifier, it MUST be normalized as defined in the following section.

Finally, XDI identifiers MUST be normalized by XDI agents prior to the first time they are written into an XDI graph. It is OPTIONAL for an XDI endpoint to verify XDI identifier normalization. However, if an XDI endpoint does perform such verification, it MUST generate a protocol error if verification fails.

If these normalization rules require an XDI authority to maintain a mapping between a normalized XDI identifier and the original identifier, it is RECOMMENDED that the authority store the original identifier as an attribute of the XDI context node identified by the normalized XDI identifier. With this technique, little or no escape-encoding of the original identifier should be necessary.

Security Consideration: These normalization rules do not by themselves prevent homographic attacks (spoofing of an XDI identifier by using a look-alike identifier from a different character set). XDI authorities—and in particular those who act as XDI registries—SHOULD impose identifier registration policies that prevent homographic attacks.

IRIsTo be fully compliant with W3C World Wide Web architecture, XDI addressing incorporates IRIs in two ways:

1. Any World Wide Web resource identified by an IRI MAY be described in an XDI graph by encapsulating the IRI as an XDI identifier.

2. Any XDI graph node identified by an XDI address MAY be expressed as a World Wide Web resource by appending the XDI address to an IRI that identifies the host XDI graph.

This section defines the rules in both directions.

2270

2275

2280

2285

2290

2295

Describing IRIs in XDI Addresses

Describing an IRI-identified resource in XDI requires two steps:

1. Normalize the IRI (to prevent misinterpretation of where the IRI terminates when encapsulated within an XDI identifier).

2. Encapsulate the IRI within an XDI identifier by enclosing it in parentheses as required by the XDI ABNF.

Examples:

IRI XDI Address with Encapsulated IRIhttp://example.com/ +(http://example.com/)

mailto:[email protected] =(mailto:[email protected])

https://example.com/item#id *!(https://example.com/item#id)

To normalize an IRI prior to encapsulation, the following steps MUST be performed in order and exactly once (since they are not idempotent).

1. Put the IRI into its absolute normalized form, including any required percent-encoding, as required by the specification for the applicable IRI scheme and by RFC 3987 [ref].

2. Percent-encode all percent “%” characters as “%25”.

3. Percent-encode all right parentheses “)” characters as “%29”.

If it is later necessary to extract the original IRI, the following steps MUST be performed on the encapsulated IRI in order and exactly once (since they are not idempotent).

1. Decode all “%29” percent-encoding as right parentheses “)” characters.

2. Decode all “%25” percent-encoding as percent “%”characters.

Note that when the IRI is encapsulated as an XDI identifier, semantic meaning is added—at a minimum, a prefixed XDI context symbol (and potentially an immutability symbol and/or a relativity symbol). So there is always a difference between the semantic meaning of the XDI identifier and the original IRI.

In addition, although the resource identified by the XDI identifier MUST be the same resource identified by the IRI on the World Wide Web, the XDI graph node representing the resource in the logical XDI graph MUST NOT be the same resource identified by the IRI on the World Wide Web. This separation between the Web resource and the XDI description of the Web resource avoids the HTTPRange-14 issue [ref https://en.wikipedia.org/wiki/HTTPRange-14].

2300

2305

2310

2315

2320

2325

https://en.wikipedia.org/wiki/HTTPRange-14

Transforming XDI Addresses into IRIs

Transforming an XDI address identifying an XDI graph node into a valid IRI identifying a World Wide Web resource address requires two steps:

1. Normalize the XDI address (to turn it into a valid relative IRI and prevent misinterpretation by an IRI parser).

2. Append the XDI address as a relative IRI to a base IRI identifying the host XDI endpoint.

To normalize the XDI address, the following steps MUST be performed in order and exactly once (since they are not idempotent).

1. Percent-encode all percent “%” characters as “%25”.

2. Percent-encode each of the characters in table __.

Character Name Character Percent-Encoding

Dollar $ %24

Hash # %23

Equals sign = %3D

Plus + %2B

Asterisk * %2A

At sign @ %40

Ampersand & %26

Pipe | %7C

Open chevron < %3C

Closed chevron > %3E

Open square bracket [ %5B

Closed square bracket ] %5D

Open curly bracket { %7B

Closed curly bracket } %7D

If it is later necessary to restore the original XDI address, the following steps MUST be performed on the normalized XDI address in order and exactly once (since they are not idempotent).

1. Decode all the percent-encoded characters in Table __.

2. Decode all “%25” percent-encoding as percent “%”characters.

2330

2335

2345

Once the XDI address is transformed into a relative IRI, it may be appended to a base URI that identifies the host XDI endpoint as defined in section __ of RFC 3987 [ref]. It is RECOMMENDED that the base URI end with a forward slash. To the extent that the XDI authority is also the authority for the DNS name, it is RECOMMENDED that DNS host name of the IRI for an XDI endpoint begin with xdi.

If an XDI address does not contain percent-encoding, the resulting IRI will only reflect percent-encoding of the XDI syntax characters. For example, start with the following XDI address:

=alice<#email>

If the base IRI for the XDI endpoint hosting this XDI address is:http://xdi.example.com/

Then the resulting fully qualified IRI would be:http://xdi.example.com/%3Dalice%3C%23email%3E

If the base URI contains percent-encoding, the resulting IRI will have percent-encoding of both the original percent-encoding as well of the XDI syntax characters. For example, take this XDI address:

=alice*some%20pet%20name

When normalized and appended to the same base URI above, the fully qualified IRI would be:

http://xdi.example.com/%3Dalice%2Asome%2520pet%2520name

XDI SchemesIn addition to context, immutability, and relativity symbols, in some cases XDI identifiers require additional syntactic structure in order to express identifiers with specific properties. To meet this requirement, XDI addressing syntax uses the same mechanism as URIs and IRIs: schemes.

With URIs and IRIs, an absolute identifier must begin with a scheme name followed by a colon (e.g., “http:”, “ftp:”, “mailto:”). Scheme names must also use a limited character set.

With XDI identifiers, a scheme is an optional syntactic feature. If an XDI identifier includes an XDI scheme, the following rules apply:

1. An XDI scheme name MUST begin and end with a colon character and include a sequence of one or more characters as allowed by the xdi-scheme rule in the XDI ABNF.

2. The scheme name MUST follow the XDI context symbol and, if present, the immutability symbol and/or relativity symbol.

3. The identifier following the scheme name MUST be valid according to the scheme specification.

2350

2355

2360

2365

2370

2375

2380

As with URIs and IRIs, XDI schemes are extensible. An XDI scheme MUST be defined in a specification from either: 1) the OASIS XDI Technical Committee (including this specification), 2) another OASIS Technical Committee specified by the OASIS XDI Technical Committee, or 3) another standards body specified by the OASIS XDI Technical Committee.

Note that use of an XDI scheme with an XDI identifier does not alter the requirement for the XDI identifier to be unique in the scope of its parent context—and for all XDI absolute identifiers to be globally unique. Indeed, the motivation for the two XDI schemes defined in the following sections is to establish interoperable standards for how XDI identifiers can meet the global uniqueness requirement.

UUID (Universally Unique Identifier)

UUIDs as defined by RFC 4122 [ref] are widely used in distributed computing as globally unique identifiers that do not require a central registration authority. When an XDI authority needs to generate an absolute XDI identifier that does not have any other specific properties (such as a cryptographic identifier—see the next section), the use of the XDI UUID scheme is RECOMMENDED.

As defined in the XDI ABNF, the XDI UUID scheme name is :uuid:. An XDI UUID MUST be a valid UUID conforming to RFC 4122. It SHOULD be a Version 4 UUID as specified in sections 4.1.3 and 4.4 of RFC 4122. Implementers SHOULD follow the recommendations in RFC 4122 and RFC 1750 for generating random numbers with sufficient entropy.

Although the probability of collision of two UUIDs is extremely small, XDI authorities SHOULD always check to ensure the uniqueness of an XDI identifier within its parent context. This is particular important for XDI authorities who offer XDI registry and discovery services to other XDI authorities.

CID (Cryptographic Identifier)

The XDI CID scheme family is reserved for identifiers with cryptographic properties. As defined in the XDI ABNF, the XDI CID scheme prefix is :cid-:. The hyphen MUST be followed by one or more digits identifying a specific XDI CID scheme. Specific XDI CID schemes will be defined in either the XDI Scheme specification or the XDI Cryptographic Mechanisms specification.

VersioningUsing semantic tree architecture, XDI graphs can model versioning uniformly and interoperably at all levels of the tree. The overall rules for XDI versioning are defined in the XDI Versioning specification. The minimal rules for expressing the version of an XDI graph conformant with this specification are defined here.

2385

2390

2395

2400

2405

2410

2415

2420

The XDI reserved class name for versions is $v. Since a version tree is by definition an ordered collection of version instances, a version class will always appears as a collection:

([$v]) for a graph root version collection.

[$v] for an entity version collection.

[<$v>] for an attribute version collection.

The members of the collection must be ordinal identifiers expressing a ordered set of version instances.

To express that it conforms to a specific version of this specification, an XDI graph MAY include an XDI version statement. An XDI version statement is an XDI type statement that uses an XDI version collection to describe the common root node of the XDI graph.

The current specification is the first version of the XDI Core specification, so its version instance identifier is (@~0). Therefore if an XDI graph needs to assert conformance with this version of this specification, it MUST include the following XDI version statement:{

"/$is#": [

"($xdi)([$v])(@~0)"

]

}

It is NOT REQUIRED for an XDI graph to contain an XDI version statement.

2425

2430

2435

2440

2445

the xdi graph model - oasis · web view[ref to ... xdi contexts just like a natural language word...

Documents