• XriThree
• GcsDelimiter

($and/ <==do note remove - switch for preventing MathML interpretation of dollar signs)

About

This page describes the GCS Delimiter proposal for XRI 3.0 Syntax.

Motivation

Although it builds off several earlier proposals from within the XRI TC, this proposal is motivated by requirements from two sources.

OASIS XDI TC

The XDI TC uses XRI identifiers to express RDF statements in the XDI RDF Model. The XDI TC has been working with these use cases since early 2007. The XDI RDF model has evolved into a very simple yet very powerful model for expressing portable, interoperable RDF graphs. However this capability depends heavily on the ability of XRI 3.0 syntax to support GCS delimiters.

XRI Resolution Use Cases

Nat, Markus, and others have brought up that XRI 2.0 syntax currently restricts how GCS characters can be used in the path of an XRI that can be submitted to an XRI proxy resolver. This restriction forces workarounds that would no longer be necessary if GCS characters were allowed as delimiters.

Proposal

The proposal is for XRI 3.0 syntax to allow GCS characters to be used as delimiters within any XRI segment. ABNF that meets these requirements is posted at XriThree/SyntaxAbnf.

Same-Segment Examples

Following are five global XRIs that are all valid under XRI 2.0 syntax:

        @cordance
        =drummond
        +email
        $v
        $1

Under XRI 2.0 syntax, none of these global XRIs can be used unmodified to compose another XRI because, after the very first position in an XRI, a GCS character cannot be used in an XRI segment outside of a cross-reference which must be enclosed in parentheses and preceeded by either a reassignable (*) or persistent (!) subsegment delimiter as shown below:

        @cordance*(=drummond)*(+email)!($v)!($1)

Under this proposal, all GCS characters are subsegment delimiters just like (*) and (!). This permits XRIs to be composed of an ordered set of global XRIs. For example:

        @cordance=drummond+email$v$1

Multi-Segment Examples

Under XRI 2.0 syntax, none of the global XRIs listed above can be reused unmodified even in the context of a subsequent path segment. They can only be reused to express a relative or local cross-reference (in parentheses) as shown below:

        @cordance/(=drummond)/(+email)/($v)/($1)
        @cordance/*(=drummond)/*(+email)/!($v)/!($1)

Under this proposal, a GCS character can be reused directly in the context of a new path segment, as shown below:

        @cordance/=drummond/+email/$v/$1

Requirements

This proposal is motivated by four requirements.

#1: Literal Expression of RDF Statements in XDI

The power of the XDI RDF graph model is based on one fundamental design principle:

Every XRI identifying a node in the XDI RDF graph is an expression of an XDI RDF statement, and every XDI RDF statement represents a path through the XDI RDF graph.

To implement this design principle, XRIs representing arcs in the XDI RDF graph must be composed according to some very simple rules. For example, a standard XDI RDF subject-predicate-object statement (where the object is not a literal or a subgraph) MUST use the following ABNF pattern:

        subject-xri "/" predicate-xri "/" object-xri

Examples:

        =drummond/$is/=drummond.reed
        =drummond/+employer/@cordance
        =drummond/$has/+friend

In addition, each multi-subsegment XRI contained within an XDI RDF segment MUST represent an XDI RDF statement in the following ABNF pattern:

        subsegment "/$has/" subsegment

For example, the following XDI RDF statement...

        =drummond/$has/+friend

...expresses the following XRI:

        =drummond+friend

For these simple rules to work, every XRI must express a precise XDI RDF statement, and every XDI RDF statement must be expressed with a precise XRI. It follows that any change to an XRI represents a change to the underlying XDI RDF statement.

XRI 2.0 syntax does not support this requirement because, as explained above, it currently requires an XRI that begins with a GCS character to change in order to be put in the context of either: a) another XRI subsegment, or b) another XRI segment.

The GCS Delimiter proposal fixes this problem by removing the restriction that GCS characters cannot be used as delimiters.

#2: XRI Composition

XRI 2.0 currently enables the expression of identifier scope (uniqueness) at three levels:

1. Global.
2. Local.
3. Relative.

Global scope is expressed using a Global Context Symbol (GCS) delimiter (=, @, +, $). Local scope is expressed using a Local Context Symbol (LCS) delimiter (*, !). Relative scope is expressed by the absence of either a GCS or LCS delimiter. Examples:

        =drummond                       <== global scope
        *drummond                       <== local scope
        /drummond                       <== relative scope
        drummond                        <== relative scope

XRI 2.0 also support the concept of identifier composition using cross-references – the reuse of identifiers (either XRIs or URIs) across contexts. However XRI 2.0 syntax restricts composition of XRIs to requiring any global XRI after the first global XRI to be enclosed in parentheses and preceeded with a local context symbol, as shown in the examples above.

This is in contrast to natural language, where most common form of identifier composition is to simply order the identifiers. For example, each of the following six global identifiers has its own independent defined meaning (i.e., in a dictionary or registry of some kind):

        Example
        international
        employment
        contract
        signature
        date

In English, it is easy to reuse each of these global identifiers by putting it into the context of another global identifier. This pattern can be repeated to any depth, as shown by the following example:

        Example international
        Example international employment
        Example international employment contract
        Example international employment contract signature
        Example international employment contract signature date

The semantics of each identifier used in this progression is modified by the semantics of the previous identifier(s), however each identifier still retains its meaning in a global context.

Some uses of XRI syntax (for example XDI RDF statements) need this same expressive capability. They need to be able to take a set of global XRIs defined in registries or dictionaries...

        @example
        +international
        +employment
        $contract
        $sig
        $d

...and express the same contextual qualifications as in English:

        @example+international
        @example+international+employment
        @example+international+employment$contract
        @example+international+employment$contract$sig
        @example+international+employment$contract$sig$d

Interestingly, English actually has a very precise grammatical construct to express that an identifier is NOT to be interpreted in a global context, but only in a local context.

        Example "international"
        Example "international" employment
        Example "international" employment contract
        Example "international" employment contract signature
        Example "international" employment contract signature date

In all five examples above, the word "international" has been delimited by quotes to explicitly convey that "this word does not have its standard meaning". In other words, it must be interpreted in a local context, not a global context. XRI syntax can express precisely the same semantics by use of cross-references and local context symbols:

        @example*(+international)
        @example*(+international)+employment
        @example*(+international)+employment$contract
        @example*(+international)+employment$contract$sig
        @example*(+international)+employment$contract$sig$d

The irony is that, because XRI 2.0 syntax only supported identifier composition through cross-references, XRI authors and users tended to focus on the global identifier inside the parentheses, e.g., (+international), and ignore the explicit semantics of the local context symbol * that casts this as a local cross-reference.

The GCS Delimiter proposal removes the syntactic restriction so XRI composition can follow the same ordering pattern as natural language.

Note: At the XRI TC F2F on November 13-14, we clarified that when a global XRI is used in the context of another global XRI, its interpretation/resolution is always in that context of the parent identifier and thus is not strictly "global". It is more accurate to say that a global XRI used in the context of another global XRI is an inference to the same entity identified by the XRI when used in a global context. For example, in @cordance=drummond, the subsegment =drummond is an inference to the entity identified by =drummond in a global context.

#3: Consistency with the XRI-as-Relative-URI Proposal

Under the XriAsRelativeUri proposal, every XRI is a relative URI. Relative URIs that support hierarchical URI syntax can be composed together into other relative URIs. For example, the following four relative URIs all represent independent pathnames or filenames.

        /hr
        /budget
        /2008
        /projections.txt

At the same time, a URI author may compose a new path using any number of such pathnames simply by ordering them. For example:

        /hr/budget/2008/projections.txt

Note that because this is a relative URI, there is no explicit semantics that the relative pathnames within it (e.g., /budget) represent the same conceptual entity as the "/budget" represented as a root directory. However the point is that no syntactic modification was necessary to any of the independent pathnames to compose them into a composite pathname. For consistency with the syntax of other relative URIs, XRIs should follow the same rule: no modification of an XRI should be necessary to compose it into another XRI.

#4: Human-Readability and Comprehension

Lastly, the XDI TC also has a requirement for XDI documents to be easily human readable in a simple text form. This requirement is similar to that for HTML and XML (and which is generally credited to have aided greatly in adoption of the Web). Human readability has also been a goal for RDF, although it is widely acknowledged that some RDF serialization formats (e.g., RDF XML) are lacking in this respect.

To meet this requirement, the XDI TC developed the X3 serialization format for XDI RDF documents. It is highly readable compared to most RDF formats (including N3, which inspired it), especially the X3 Simple variant. However the readability of all X3 formats depends almost entirely on the readability of the XRIs that identify every node in the XDI RDF graph.

In this light, the XDI TC has found the clear semantics of ordered composition of global XRIs and their direct translation into unambiguous XDI RDF statements is a major advantage. Although we understand there has not been consensus among XRI TC members regarding the importance of human readability as a requirement, for XDI as a protocol and data interchange format we believe this is crucial for widespread adoption.