why xri

I thought this email thread was interesting enough to share with you all... I was asked in an email...

I do not understand however, the statement about URIs having some intrinsic limitation or to bound by hard trees. A URI is an identifier. No more, no less.

In as much as meaning can be expressed by statements and a statement can be expressed in RDF, which uses the URIs as an identifier's for the subjects on both sides of the statement predicates, is in no way a limitation on what can be expressed about those subjects or the relationships between them.

Perhaps you can elaborate on the perceived limitation of URIs?

I'm publishing my response for two reasons...

1) Maybe my answer will help others with the same question.
2) So that other XRI folks can help refine my answer

So this was my answer:

You actually answered your question in your questions... URI is insufficient to describe the relationships between resources. In order to understand the context of an identifier you need RDF, or XRI. I believe that XRI and RDF solve different parts of the same problem and used together provide some pretty cool capabilities.

XRI is a fully backward compatible extension of URI so nothing is lost with this approach. It does bring some useful additions for anyone that wants to use them. Here's a couple of examples:

1) XRI Resolution spec defines 2 mechanisms for 'Trusted Resolution'. While you can turn trusted resolution off and use dns infrastructure as-is (nothing lost) you can turn on either 'ssl resolution' or full 'signed authority chain resolution' to greatly increase the confidence that the results of a resolution are what they should be. Given how easy it is to undermine the DNS infrastructure this seems important to me as we move higher value transactions around a distributed web.

2) XRI's cross reference syntax lets you build your RDF tuples right into your address.

XRI://(uri://my_subject)*(uri://my_predicate)*(uri://my_object)

Here's an example directly from the w3c tutorial.....

http://www.example.org/index.html has a language whose value is English

Which it then breaks down to...

[http://www.example.org/index.html] [http://purl.org/dc/elements/1.1/language]"en"

could be expressed as:

xri://(http://www.example.org/index.html)*
(http://purl.org/dc/elements/1.1/language)*
en

although starting to slip in some more xri 'stuff' it might look like:

xri://(http://www.example.org/index)*(@ISO639-1)*(+en)

In this last example the subject is still expressed as and dereferenced as a URL, it's natural form. The @ in the predicate means that ISO639-1 is resolvable in the @ namespace (dereferencing it would likely return the same as http://purl.org/dc/elements/1.1/language). The addition of the + to +en indicates that it is resolvable in the + space, which can be used to do things like find synonyms... (in the next draft of ISO639 en became eng... these might be made synonymous in the + space).

We have found that building indexes of xris that use RDF syntax is a highly efficient way to navigate semantic space. (I'm not saying that it should be the only way, just that it is a viable alternative to XML serialization of RDF. We store our XRI index as a native b-tree which we find to be much more efficient to process than RDF XML.

I'll stop there as you might already feel like your at the wrong end of a fire hose spending way more time on this question than you ever intended. If you want to spend more time learning about how and why I feel XRI (and I haven't even started on XDI yet) is important and useful, just let me know.

how'd I do?