Re: URI: Name or Network Location?

On Jan 26, 2004, at 13:32, ext Hammond, Tony (ELSLON) wrote:

>> I simply can't fathom any real benefit to having a URI
>> which, by definition, cannot be used to access such knowledge.
>
> The reason is to keep the barrier to entry as low as possible. By 
> explicitly
> excluding dereference we have devised a very simple, focussed 
> registration
> mechanism which requires almost zero maintenance and is consistent 
> across
> the whole INFO namespace with a predictable behaviour (i.e. disclosure 
> of
> identity). This is a baseline service - think of it as something like 
> the
> Model T.

Well, er, fair enough. But I don't know anyone these days who would
particularly *want* to drive a Model T as their primary vehicle.

But let me address what I understand as the key components which you 
identify
above:

1. low barrier to entry

The bottom line here is that the info: scheme does not offer any
lower barrier to entry than http:, and in fact, if the principles
of PURLs and well-choosen and maintaned domain names are understood,
I'd argue that info: has a higher barrier than http: (i.e. domain
name registration).

2. zero maintenance

After obtaining the namespace (either info: or http:) neither info:
or http: URIs require any more maintanance than the other. Both
simply require that the owner of the particular namespace keep
track of which URIs are minted to avoid collisions.

But since there is no requirement that http: URIs resolve to
any representation, or that there actually be any HTTP server
accessible at any address/port per the web authority component
of the URI, http: URIs impose no greater maintenance overhead
than the proposed info: URIs.

3. consistent, predictable behavior

This seems to be the only possible distinction between info:
and http: URIs; however

(a) the intended behavior (or lack thereof) of interpreting
     info: URIs cannot be guarunteed (per DDDS and other non-HTTP
     resolution protocols)

(b) one is actually likely to find great inconsistency in
     localized resolution of info: URIs, since systems will
     still want/need to store and retrieve labels, descriptions,
     and other knowledge about the terms (resources) for
     various purposes, and since info: defines no resolution
     mechanism, everyone will have to roll their own

(c) any term worth minting an info: URI for is likely
     of sufficient importance that folks will *want* to
     be able to dereference that URI to get a description
     of the term in question

(d) providing for a user-friendly, consistent, and informative
     response for any http-based URIs grounded in an INFO managed
     namespace -- for cases where representations and/or
     descriptions are not available -- is simple to do, and
     thus in no way justifies prohibiting everyone from exploiting
     a globally deployed infrastructure to provide representations
     and/or descriptions if so desired.

--

So, to summarize, the only distinction between the use of info: URIs
rather than http: URIs -- intended non-resolvability -- is a distinct 
and
significant *disadvantage*.


>
> I agree that it would be useful to have resource representations 
> sitting out
> there on some network endpoint - but that is just way too expensive 
> for the
> namespaces we are interested in fostering.

I'll give you the software to do it for free. Really. All you need is
the RDF. And the server will automatically fall-back to trying to return
a description if no representation is otherwise available.

> There are no (human) resources
> available to maintain such an undertaking.

Surely someone, somewhere is maintaining the formal definitions
of these vocabularies. Surely you will have somewhere descriptions
of those term sets, with the labels/titles/descriptions of those
terms. Even a trivially simple RDF schema that just lists the
terms as terms would be better than nothing (though I expect that
in reality, it would not be much work to create fairly respectible
RDF descriptions of those terms based on existing materials).

Also, you'd want to delegate the work as much as possible, to
each owner/manager of each subnamespace. Yes, there will be a few
vocabularies where the actual owners will perhaps not want to do
anything other than give permission for minting the URIs, but I
would expect that to be the exception rather than the rule.

>  The conclusion is that we either
> go this zero-resolution route or we accept that many of these 
> namespaces
> will continue not to be represented on the Web.

That does not need to be the conclusion.

Rather, why not simply begin with http: URIs grounded in your own
INFO organization's top level domain, such that initially there is
no resolution provided (or perhaps providing a fall-back to a nice
user-friendly explaination of why clicking on that URI isn't
providing anything useful) and then, *when* the descriptions
are created, *BINGO* you've got web-accessible descriptions of those
terms! With *zero* impact to any usage of those terms as names.

Thus, the real conclusion is that choosing http: URIs which don't 
resolve
to anything costs you nothing more in effort or overhead than info: 
URIs,
yet keeps the door open to when (not if) folks will need/want those
descriptions.

> Which means that we will
> continue to be frustrated by not being able to 'talk' about well-known
> public information assets in Web description technologies.
>

You'll be able to talk just fine with/about those terms using http: URIs
as you will with info: URIs, but eventually be able to do so much
more.

All of your goals can be met *better* and with no more cost/effort
by http: URIs.

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 26 January 2004 07:12:36 UTC