Re: Standard URI Set, and Resource Description Protocol (rdp://)

At 10:43 AM -0700 2003-05-21, Sherman Monroe wrote:
>I am in the process of developing a global, standard URI set. The 
>set will contain exactly one URI for each ěconceptî within the setís 
>domain. In other words, a concept will be represented by exactly one 
>URI. The idea is to solve the problem of interoperability. When RDF 
>publishers wish to describe a resource, they use URI's which they 
>have looked up the in the global URI set. This would/could develop 
>into a defacto consensus. This does two things:

At some point, having a well-known set of URIs for referring to 
common concepts will be very useful. It isn't clear to me whether 
we're at that point, but I suppose that depends on what set of 
concepts you're talking about identifying.

>I read <http://www.w3.org/DesignIssues/HTTP-URI.html>TBL's paper[1] 
>about the URI crisis, and I agree with most of what he says. I feel 
>that the URI should be completely opaque, and that no promises 
>should be made as to what a URI will return if a browser is pointed 
>to it. Browsers are for locating resources in the www space. We need 
>a protocol that the semantic web machines can use to denote 
>resources in the semantic space. Therefore, the URIs in our global 
>set will begin with rdp://. This settles the issue as to what a 
>browser will return for RDF URIís.

First, is a new URI scheme really necessary? Why not use URNs?

Second, I have to say that I'm not yet convinced by TBL's argument. 
It seems to me that I can easily assign a URI to my car (eg, 
<http://example.com/my/car>) and other URIs to documents describing 
my car (eg, <http://example.com/my/car.html>, 
<http://example.com/my/car.jpg>) and use content negotiation and the 
Content-Location header to return an appropriate representation if 
someone happened to dereference <http://example.com/my/car>.

[1] <http://www.w3.org/DesignIssues/HTTP-URI.html>

-- 
Dave Menendez - zednenem@psualum.com - http://www.eyrie.org/~zednenem/

Received on Thursday, 22 May 2003 00:08:00 UTC