- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 23 Oct 2008 08:00:30 -0400
- To: "Drummond Reed" <drummond.reed@cordance.net>
- Cc: www-tag@w3.org, "Peter Davis" <peter.davis@neustar.biz>, jbradley@mac.com
- Message-ID: <760bcb2a0810230500v7d99b8f1p70c3119b93a79dc4@mail.gmail.com>
On Thu, Oct 23, 2008 at 3:04 AM, Drummond Reed <drummond.reed@cordance.net>wrote: > > 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 spontaneously. Best Jonathan Rees
Received on Thursday, 23 October 2008 12:01:14 UTC