W3C home > Mailing lists > Public > www-tag@w3.org > October 2008

Re: [XRI] XRI-as-Relative-URI proposal

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 23 Oct 2008 08:00:30 -0400
Message-ID: <760bcb2a0810230500v7d99b8f1p70c3119b93a79dc4@mail.gmail.com>
To: "Drummond Reed" <drummond.reed@cordance.net>
Cc: www-tag@w3.org, "Peter Davis" <peter.davis@neustar.biz>, jbradley@mac.com
On Thu, Oct 23, 2008 at 3:04 AM, Drummond Reed

> The proposal is written up on an XRI TC wiki page at:
>        http://wiki.oasis-open.org/xri/XriAsRelativeUri

Thanks for the chance to look at this.

I have one comment, which is not, as far as I can tell so far, a fault in
what you have written. Apparently you mean for the XRI =Drummond to name (or
"identify") a person, while a corresponding HXRI
http://xri.net/=Drummondnames (or "identifies") the resource
descriptor, which is a document. That
is, you have two names naming two different things, and one name is not a
URI, while the other is. There is nothing at all wrong with that.

My comment is just that for any XRI, there is not necessarily a URI that
names the same thing as the XRI, and if there is then there is no
deterministic way to figure out what it is. This is a lost opportunity for
XRI in semantic-web-like use cases, as I will explain.

This omission mainly makes a difference in applications that want to use RDF
or OWL, or otherwise use URIs as logical names for things as opposed to
those applications (such as web browsers) that only needs names for
documents such as resource descriptors. If you don't care about such
applications, then there is not much to be said - except that my preference
is that you should care about such applications, because it would make my
life easier (since I would immediately have names for all the things that
are named by XRIs for use in my applications); and I think I'm not alone.
Without XRI-equivalent URIs, I would have to make up my own names (URIs) for
things named by XRIs, and that would be inconvenient.

If you do want a URI equivalent to each XRI (as opposed to a URI that names
the resource descriptor), then you have two choices. One is to change the
design so that the HXRI names the thing, and invent a second URI, call it
the RDI (resource descriptor identifier), which, like the HXRI, is obtained
by a deterministic rule applied to the XRI, but a different rule than the
one used to obtain the XHRI.  For example, you could follow the ARK lead and
have the RDI be the HXRI with a '?' appended.

Another solution is to use the HXRI as specified, that is, playing the role
of RDI, but invent a second URI that names the thing, again using some
ARK-like deterministic syntactic client-side rule.

In either case, the httpRange-14 recommendation, which in my view is just an
interpretation of RFC 2616, would advise that of these two URIs, the one
that does not name the resource descriptor (i.e. the one that names the
thing) should not lead to a 200 response when resolved via HTTP. (Nowadays
semantic web applications generally use a 303 response instead in this
situation, even though that's stretching RFC2616 a little bit.) httpRange-14
has been beaten to death on this forum, so I will not give the rationale
here, but if you would like one I'm sure it would arise almost

Jonathan Rees
Received on Thursday, 23 October 2008 12:01:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:25 UTC