Re: Announcement: The "info" URI Scheme

Patrick Stickler wrote:
> On 2003-09-30 17:23, "ext Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
> wrote:
> 
>>The "info" URI
>>scheme will facilitate the referencing of information assets that have
>>identifiers in such public namespaces by means of URIs.
> 
> Rather than create yet another URI scheme, particularly one which is not
> meaningful to HTTP and the presently defined web architecture, why not
> set up the equivalent using http: URIs, and a (distributively) managed
> domain name space?

While I have a long history of agreeing with Patrick, I don't know that 
I like this idea. Note that I'm not necessarily agreeing with the info: 
proposal below, just reacting to the "everything http:" statement. (I 
also have a hunch that the things I will soon say will be old news and 
will have been discussed for years on the RDF lists when I wasn't looking.)

To me, the http: scheme says two things: (1) I'm identifying some 
resource (2) that can be accessed using the Hypertext Transfer Protocol 
(HTTP). In my mind, a language isn't hypertext like an HTML page. It 
isn't even a physical thing. There is some abstract notion of a 
language, but you can't really "retrieve" a language---although we can 
use it and even identify a hazy concept, for example, what one might 
call "English".

I can't go to my browser and access the language "English" using HTTP. 
Sure, I can access a web page that describes English, but that's 
different. Even if we try to equate the two, what happens when the 
standard protocol of the web is not HTTP anymore, and it's the "YML 
Transfer Protocol (YTP)" (based upon the new Yet-another-generation 
Markup Language, of course).

I don't think abstract non-retrievable things should be given 
identifiers in the domain of a scheme for HTTP transfers. It's an 
abstract thing. It should have its own abstract URI. In fact, didn't I 
read a few years ago that there was going to be some scheme that allows 
mapping of existing non-URI identifiers, like "uri:lang:en" or 
"uri:ssn:123456789" or something?

We can always settle on some way to access *metadata* about a language 
or some other abstract thing, as Thomas mentioned, using HTTP, but that 
URL for the metadata should be distinct from the abstract URI to the 
abstract thing itself.

Garret

Received on Wednesday, 1 October 2003 14:43:03 UTC