Re: Announcement: The "info" URI Scheme

On 2003-10-02 18:56, "ext Garret Wilson" <garret@globalmentor.com> wrote:

> Patrick Stickler wrote:
>> 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?
> 
> Fine---there needs to be a standard solution for finding out "where
> authoritative descriptive metadata resides." We can all agree that this
> is a problem. So?
> 
> "Everything HTTP" is one answer that has the side-effect of confusing
> the resource with its metadata. There are surely thousands of other
> answers. Here are a few off the top of my head. (I'm not proposing
> them---I'm just pointing out that there are thousands of other answers
> that don't have the same semantic deficiencies.)
> 
> 1. The uri+meta: scheme, e.g.
> uri+meta:person:poets:shakespeare?meta=http://shakespeare.org/bard.rdf .
> (This would best be done with a URI comparison algorithm that ignored
> the ?meta part.)
> 
> 2. The rdf:baseMetadataURI attribute, e.g.
> rdf:baseMetadataURI="http://example.org/metadata/lookup?"

URIQA is IMO superior to all of the above approaches, and coexists
alongside the present HTTP semantics, without affecting it, but
merely enhancing it.

Web servers that are not URIQA englightened will simply not understand
URIQA requests (just as is the case for servers that do not support
WebDAV extensions, which don't understand WebDAV requests) yet the
addition of URIQA or WebDAV functionality has zero impact on the
fundamental HTTP behavior of the server.

And with URIQA, all you need is the URI. That's it. No parsing or
hacking the URI. No multiple system requests to find out where to
ask for metadata (resulting in even more requests to get the metadata).
Just the URI. Simple. Clean.

> 3. The new protocal that replaces HTTP (yes, there will be one, just as
> sure as there will be a syntax that replaces XML) might reserve an
> entire branch of its URI tree for just this problem, e.g.
> ytp://metadata/lookup?person:poets:shakespeare . Maybe YTP will have its
> own system of DNS-like tables that route requests to this tree to a
> metadata page on the server of the owner of the object.
> 
> 4. Heck, maybe the W3C or some other standard body could even do the
> same thing with HTTP, reserving a branch and saying that, "If you see an
> identifier in a specific scheme, use http://metadata.net/... to get its
> metadata." Oh, wait, the DOI/handle.net people are already doing that.
>
> If we use HTTP for everything, what happens when HTTP is replaced by the
> next protocol? 

When the future comes, we'll face it. But we live in the here and now,
and although one should be aware of what lies on the horizon and do
what one can to prepare, there's the old adage "if it ain't broke,
don't fix it" and it applies here.

Evolution of the web architecture should be driven by need and proven
benefit. And above all, things should be kept simple.

There is no need for new URI schemes such as info:, as one can accomplish
the same result using http: URIs and DNS management. And adding such
a new scheme makes the overall infrastructure that much more complex
and expensive to use.

> The likely answer would be, "well, we'll just map all
> those HTTP requests to the new YTP URI tree in some standard way." Good
> answer---but why can't we do the same thing now with other URI schemes
> that doesn't pretend to indicate a retrieval method, be it info: or
> whatever?

Because of the cost and effort to deploy such a solution globally,
to the degree that HTTP is now deployed. I fail to see any clear,
motivating reason to do such a thing. It would be IMO, purely socially
motivated (NIH syndrome and the like) rather than based on an actual
technical need.

Regards,

Patrick

Received on Friday, 3 October 2003 05:37:52 UTC