RE: Using URIs to identify non-information resources

Given the thunderous silence I've heard in response to my
thing-described-by.org proposal, I thought I should be slightly more
provocative. ;)

I think we should recommend this approach as best practice for
identifying non-information resources, in conformance with the TAG's
httpRange-14 decision[1].

	- It is better than # identifiers because its meaning is 
	  not dependent on the MIME type of any describing document.
	  Making the meaning of an identifier dependent on the MIME 
	  type of a describing document is clearly architecturally 
	  broken, given that the whole point of URIs is to be 
	  universal -- spanning languages, devices, systems, whatever.

	- It is better than serving your own 303-redirects because 
	  software can recognize well-known URI prefixes of 
	  "http://thing-described-by.org?" and optimize away the extra 
	  HTTP access that would only be 303-redirected anyway.
	  However, it does not *require* such prefixes to be
	  recognized.  Thus, it does not break URI opacity[2]
        (more on this below).

Of course, RDF folks who only care about the RDF world may be content
with # identifiers.  They may not care about the ability to give an
identifier meaning that is independent of the MIME type of a particular
describing document.  But I think we have a responsibility to take a
broader view than that and recommend a solution that transcends MIME
types.

Why do I say this approach does not break URI opacity?   First, because
there is no *need* to examine the syntactic structure of the URI.  It
will work exactly right (returning a 303 redirect to another page) even
if you do not look into the URI's structure.  Second, bear in mind that
the reason URI opacity is desirable is to prevent someone who inspects
the URI from drawing false conclusions about its meaning.   If you
*choose* to look at the URI's structure, and you were already aware of
the delegation of authority provided by the thing-described-by.org site
(see 
http://thing-described-by.org/#Delegation_of_Authority ), then you could
*correctly* optimize away the HTTP access to thing-described-by.org.
Note that this is *not* a heuristic (guess).  It is following the
explicitly defined meaning of the URI, as documented at 
http://thing-described-by.org/#Delegation_of_Authority .

BTW, one thing I did not make clear in my previous postings is that I
have registered and implemented thing-described-by.org, so you can
actually try this out if you wish: http://thing-described-by.org .   And
for those who think that "thing-described-by" is 13 characters too much
to type, you can instead use http://t-d-b.org .

Comments?  Rebuttals?

David Booth

1. TAG decision:
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
2. URI opacity: http://www.w3.org/TR/webarch/#uri-opacity


> -----Original Message-----
> From: Booth, David (W3C Fellow - Boston) 
> Sent: Monday, July 11, 2005 2:24 PM
> To: public-swbp-wg@w3.org
> Cc: Sandro@w3.org
> Subject: RE: Using URIs to identify non-information resources
> 
> 
> Correcting a couple of typos . . .
> 
> > -----Original Message-----
> > From: public-swbp-wg-request@w3.org
> > [mailto:public-swbp-wg-request@w3.org] On Behalf Of Booth, 
> > David (HP Software - Boston)
> > Sent: Monday, July 11, 2005 10:18 AM
> > To: public-swbp-wg@w3.org
> > Cc: Sandro@w3.org
> > Subject: Using URIs to identify non-information resources
> > 
> > 
> > How about using an http site such as thing-described-by.org
> > to do 303 redirects?
> > 
> > If I have a URI for a Web page that describes myself, such as
> > 	http://dbooth.org/2005/dbooth/
> > then
> > 	http://thing-defined-by.org?http://dbooth.org/2005/dbooth/
> 
> Oops! The above URI should have been:
> 	http://thing-described-by.org?http://dbooth.org/2005/dbooth/
> 
> > could be a URI that identifies me, and the
> > thing-defined-by.org server would do a 303-redirect to 
> > http://dbooth.org/2005/dbooth/ .
> 
> Same typo again. :(  The sentence above should have said "the 
> thing-described-by.org server would do a 303-redirect . . .".
> 
> > 
> > It seems to me this would have several advantages:
> > 	- The URI for me always has the same meaning, regardless of the 
> > 	  MIME type returned by http://dbooth.org/2005/dbooth/ .
> > 	- I would not have to set up my server to return a 303, because
> > 	  the thing-described-by.org site would do it for mt.
> > 	- I would not have to pre-register
> > http://dbooth.org/2005/dbooth/ with
> > 	  the thing-described-by.org site.
> > 	- Since thing-described-by.org would *always* return 
> > 303 redirects, there
> > 	  would be no need for software to do an HTTP access to 
> > it. Software
> > 	  could skip the extra HTTP request to 
> > thing-described-by.org and
> > 	  access http://dbooth.org/2005/dbooth/ directly.
> > 
> > This idea is similar in concept to the "*" operator proposed
> > by Sandro Hawke and Eric P, or the tdb: URI scheme proposed 
> > by Larry Masinter, but does not require any change to RDF nor 
> > a new URI scheme.
> > 
> > What do others think of this idea?
> > 
> > BACKGROUND
> > The TAG's 303 redirect solution for permitting http URIs to
> > identify non-information resources seems inadequate to me because:
> > 
> > 	- Authors don't always have control over their Web
> > servers, to be 
> > 	  able to return 303.
> > 	- It makes the *absence* of a document be significant, 
> > which seems 
> > 	  counter-intuitive and error prone.
> > 	- Creating and maintaining an additional URI just to 
> > return a 303 
> > 	  seems unnecessarily troublesome.
> > 	- The relationship between the concept URI and the 
> > defining document URI
> > 	  can only be determined by a successful HTTP access, 
> > and a 303 result
> > 	  is not even cacheable, thus placing a 
> > 
> > And of course, the use of hash URIs
> > (http://example.org/ont#DansCar) to identify non-information 
> > sources also seems inadequate to me because its meaning is 
> > dependent on the returned MIME type.
> > 
> > David Booth, Ph.D.
> > HP Software
> > dbooth@hp.com
> > Phone: +1 617 629 8881
> >  
> > 
> > 
>

Received on Friday, 22 July 2005 22:32:46 UTC