RE: Using URIs to identify non-information resources

Hi Benjamin,

> From:  Benjamin Nowack
> 
> hi, just wanted to suggest continuing this thread
> somewhere else (e.g. on semantic-web) as the promotion
> of a centralised service shouldn't really be considered
> a best practice. 

It sounds like you may be misunderstanding my intent.  I don't think
"centralized service" is a fair characterization of what
thing-described-by.org intends to do.  Analogy: If a particular ontology
from a particular site becomes widely used, does that mean it is a
"centralized service"?  I don't think so.  Anyone is free to use it or
not as they desire.  Obviously there is more benefit if lots of people
use the same ontology, but its use is entirely by choice.  Thus, it is
not a limiting or gating centralization, rather it is a result of the
network effect.

The same is true of thing-described-by.org.  Anyone can offer a similar
service, though obviously better optimization is possible if there are
fewer such sites to recognize.  Nobody is forced to use
thing-described-by.org, but there is mutual benefit if people do.

> The thing-descr..-approach is also
> quite similar to all the (failed) attempts such as "the
> info uri scheme" etc., 

It is very different from defining a new URI scheme, because it does not
require any changes to existing software.  It works today.  However, if
you do wish to change your software to recognize thing-described-by.org
URIs, then your software can run faster, by opimizing away unnecessary
HTTP accesses, as described at
http://thing-described-by.org/#optimizing

> and with the TAG compromise, it's 
> getting really easy to add this type of functionality to rdf 
> apps directly, without having to rely on an external service 
> or hard-coded URI-examination.

I don't think that's quite correct.  If you are given an arbitrary http
URI that you have not seen before, and you want to determine whether it
is being used to directly identify a Web page at that address or
indirectly identify something else, it seems to me that you MUST perform
an HTTP access on that URI to find out whether it returns 2xx (meaning
it directly identifies a document at that address) or 303, meaning you
need to look elsewhere to learn what it identfies.  However, if you are
given a thing-described-by.org URI, you can determine by inspection that
it does not directly identify a document at that address, because of the
delegation of authority provided by thing-described-by.org:
http://thing-described-by.org/#Delegation_of_Authority
That is a significant optimization.

> (It would be nice though to see a swbpd note about how to
> best implement the TAG suggestion, possible ways of
> naming resources so that the 303-mechanism works, . . . .

The question of how to best implement the TAG's suggestion, and how to
best name resources so that the 303-mechanism works, is *exactly* what I
am trying to address in suggesting the thing-described-by.org approach!


AFAICT, thing-described-by.org provides a very practical and scalable
solution to the problem.  

David Booth

Received on Friday, 19 August 2005 04:37:46 UTC