Re: Announcement: The "info" URI Scheme

On 2003-10-01 21:42, "ext Garret Wilson" <garret@globalmentor.com> wrote:

> 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.

Fair enough. I used to hold a different view myself some years ago ;-)

> 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 you can. Accessing a resource does not mean *getting* the resource,
but interacting with one or more representations of that resource. That's
all HTTP provides, a means to interact with representations of resources.
Whether interaction with those representations can affect the state of
the resource is another issue. Sometimes it can. Sometimes it can't.

> 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.

Why not. All HTTP does is provide access to representations. You
never, ever GET the actual resource (even when the resource is
digital and the representation returned is a bit-equal copy).

(this is the REST view of web architecture, of course)

It is an understandable common misconception that what an HTTP
server actually returns is what is denoted by the URI. The fact
is that we can never be absolutely sure what resource a URI
denotes based on what is returned by a server. In some cases
it's easier to guess than other cases, but typically you can't
ever be sure. Hence the car/document problem.

And hence the reason for URIQA. To be able to obtain an authoritative
answer to the questions "What does this URI denote, and what is
that thing like?". A representation of the resource might be able
to give a human some clues, but being able to obtain a formal,
precise description of the resource is much better.

> It's an 
> abstract thing. It should have its own abstract URI.

Even abstract things can have representations, and thus it's perfectly
acceptable for them to be denoted by http: URIs.

I used to think differently, but several years of real-world
implementation of SW applications changed my mind.

The turning point was appreciating the distinction between
resources and representations, and realizing that web servers
do not serve the resources denoted by the URIs in the request.

> 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.

But when all one has is a single URI, how do you find out *where*
authoritative descriptive metadata resides, if that URI is not
meaningful to HTTP? That's the problem. If all you have is
uri:foo:blargh how do you know where to go for information about
the thing denoted by that URI, and how do you know that the information
you find is authoritative? And even if you manage to work out a
solution, will that solution scale globally?

Using http: URIs to denote any resource which should be accessible
(by representation and/or description) on the Web or SW, is garunteed
to scale globally and work *today* with little to no changes to the
existing global infrastructure.

If you don't care about the Web or SW, then sure, go ahead and use
whatever URI schemes you like. But if you want your information
to be accessible and useful to Web or SW applications, you should
use http: URIs.

Cheers,

Patrick

> Garret
> 
> 
>

Received on Thursday, 2 October 2003 03:25:15 UTC