RE: infoURI standard officially blessed

From: Tansley, Robert <robert.tansley_at_hp.com>
Date: Thu, 17 Nov 2005 18:36:35 -0500

> But, I don't know of any registries that make it trivial for 3rd
> parties to register that they offer service X on the names; for
> example ratings on product-codes, or geo location info on IP
> addresses. Such complementary services are typically left
> out in the
> cold to compete in the open market. So
> Amazon can offer reviews key'd off all these name spaces, but it
> can't get the
> registries for those numbers to help interested parties find them.

This hits the nail on the head for me... I don't think we should be
talking about names and locations/resolution, but names and *services*,
of which resolution to some set of bits is one. HTTP + DNS
infrastructure does offer a way to do this, by having some standard
means to specify services in a blob of data you get back from an HTTP
GET, but it's very limiting. The notion ingrained in HTTP URIs, that
identifiers are something you resolve to a single location and get some
set of bits back, is bogus for a lot of entities, but it's with us,
probably for good.

Also the HTTP URI and services associated with that URI will forever be
perceived as (and, for the forseeable future, actually) coming from the
same entity. Isn't it a more intriguing notion (and one that's at the
heart of the Semantic Web, as I understand it) that the names
themselves, i.e. the language of discourse, can be controlled by one
authoritative entity, but the actual conversations, such as what are the
available services, can be controlled/supplied elsewhere?

Think of a musical composition, like Vivaldi's Four Seasons. Ideally we
need an authoritative, non-ambiguous name so we can talk about the
composition 'Vivaldi's Four Seasons' -- not a particular performance,
not a printed musical score, but the work. It makes perfect sense for
one organisation to take stewardship of that authoritative *name*, but
not to have the final say on what the services available for the work
are.

Add to this that it's also very hard to transfer stewardship of URIs,
given that organisational and other information is often a part of those
URIs (mit.edu, hp.com, etc). HTTP URIs suddenly don't look so
attractive to use as names for anything and everything. (Sure,
theoretically you can make sensible 'future proof' HTTP URIs, but in
practice host names and URLs represent the organisational,
sociopolitical or economic context of the day and as such will become
invalid or even undesirable).

We need some infrastructure that probably isn't built yet, or at least
standardised (like the Web) with the required consensus.

And in the meantime, having non-resolution/resource retrieval services
on http: URIs is going to be difficult because the idea that http: URIs
just locate a particular resource is now so deeply ingrained. People
will see a URL, they'll click on it, and what they get will be all they
think they can out of that URL. And of course if it so happens that URL
*doesn't* resolve to anything useful or at all, that will be that; "it
doesn't work", move on.

But give them something else they *can't* click on, or at least don't
have the expectation of click-boom, and suddenly they'll wonder what's
up -- in the absence of any decent way to bind services to names,
they'll do a Google search, and might find multiple services available
on that name, including multiple locations from which to retrieve the
resource, if indeed that is what is being named, or other interesting
annotations and information.

I'm not necessarily saying that info: or other URIs are 'the answer',
I'm sure they have problems too; I'm just saying that while there may be
many valid arguments that could be leveled against info: and other
schemes, I don't think "you can just use HTTP URIs" is one.

Rob (finally clicking on the SIMILE mail folder that's accumulated over
600 emails)
Received on Thu Nov 17 2005 - 23:30:31 EST