W3C home > Mailing lists > Public > uri@w3.org > October 2003

RE: Announcement: The "info" URI scheme

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 03 Oct 2003 14:13:27 -0400
Message-Id: <>
To: "Williams, Stuart" <skw@hp.com>, "'Tim Bray'" <tbray@textuality.com>, "Roy T. Fielding" <fielding@apache.org>
Cc: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>, uri@w3.org

At 09:01 AM 2003-10-03, Williams, Stuart wrote:

> > So, as I understand it, 'info:' is just like 'urn:' except for:
> >
> > - For 'info:xxx:', NISO hands out the 'xxx'
> > - There is no requirement for permanence or reference stability.
> >
> > This latter is I suppose why you wouldn't want to do 'urn:info:xxx:'
> > which otherwise would work just fine.
> >
> > Is that oversimplifying?
>After ploughing through scads of email on this thread, I found it refreshing
>to find such a well framed question. Regrettably, it seems to have gone
>unanswered :-(

Let me try to answer that one, at least.  Yes, it is oversimplifying.

The info: scheme resolves, in the scheme name, the car/document ambiguity
that Patrick Stickler mentioned earlier.  The urn: scheme does not.  So far
as I understand it.  If it includes ISBNs as well as Dewey Decimal category
numbers, then I am wrong.  But I got the impression this was all about
category designators.


The proposed domain of the info: scheme if I understood it is for
categories, known to be abstract concepts, and not documents or otherwise
concrete utterances.

Can someone from the NISO proponents of the info: scheme confirm or
deny this interpretation?


Long version:

As I understand it, the info: scheme is being offered as not an omnibus
ur-scheme for delegated naming, but as a merged naming scheme for a
collection of similar concept pools.  The commonality among all the concepts
so collected is far stronger than that which obtains for urn: subdomains.

We have heard two arguments against the 'info' scheme.

One is "One ur-scheme is more than enough"

The other is "All schemes existing primarily for the purpose of federating
naming authority should be subschemes of the 'urn' scheme."

Neither of these is, to me, convincing.  I can see the community succeeding
with either an urn: subscheme or collection of such subschemes, or with a
novel top-level scheme.  Let's look at the pros and cons for each, however.

Let's take the second argument one first.

Remember, DNS federates naming, as the http:-does-it-all voices have
reminded us often.

But my root argument is that there are two performance metrics that URIs are
valued by: ease of recovery, and authenticity of communication.  Most URI users
want to support both in the services that they deliver over the web.  There
is a lively debate over the relative importance of naming and retrieval, but
despite the differences in emphasis between advocates of the two performance
metrics, the question "which is more important" cannot be answered completely
until recovery time when the value system of the recipient is known.  So it
can't be the rule used for naming decisions.

All we know is that the publisher wishes to support authentic identification
and facile recovery with some concrete provisions in the URI or in the
network services that handle that URI.

In the URN case, it is ease of recovery that is dependent on services on the
network more than on data in the URI.

In the http: URL case, authenticity of the recovery is supported by network
services -- PKI linking a signature in the body of the communication to an
authentication argument involving a chain of certificates.

In the case of an httpsy: YURL, we have data explicitly targeted to improving
performance on both axes of performance: facility of recovery, and authenticity
of communication.  Even if this scheme isn't the answer, this is the way that
URIs have got to evolve to grow up with the Internet.

The presence of intelligent, hostile agents on the net has by now been well
established, and the next wave of development will be more defensive against
the actions of such agents than the waves up through DNS and the Web were.

Authentic communication is what we will need to build more fundamentally into
URI usage.  This can be done today with http: scheme URLs with the network
support of OpenURL schemas.  Or almost fundamentally.  Maybe fundamentally
enough.  Just as SOAP can run happily over HTTP even 'though in a way the
capabilities in SOAP, had we had them then, would have made some of the
features in HTTP unnecessary.

In the case of the 'info' scheme there is a body of usage, some well-wrought
community concepts like the Dublin Core Element Set, that would be better
integrated into Web usage if they had an agreed linearization in the URI
namespace.  Functionally, this could be urn:dds:blah and urn:etc.:blah.

urn: could be the syntax at the front of an info: URI just as "www." is
the literal syntax at the start of a site address on the web.  You know, 
the Web
collapsed DNS into a flat space with structure

siteAddress ::= 'www.' agglutenattedBusinessName '.com'

..but this is sub-optimal.  It would be better to let this class float to
the top of the syntax and give it its own top-level scheme.  The internal
consistency of the meaning of info: scheme URIs is far greater than the
commonality that they share with other candidate urn: scheme applications.

It's a matter of judicious source coding.  'Naming' is too flimsy a concept
to be the sole connotation of the root segment (that is to say the scheme
part) in the URI's construction.

The URI language is to be practiced by a vary large pool of
mostly-autonomous actors.  Thus the 'technical factors' that Roy sees as
absent are not the only factors to be considered in deciding what schemes to
authorize.  It is also important that the URI language, in Cranmer's terms,
be "understanded of the people."  For the class of things that would be
named under the proposed 'info' scheme, a root scheme would be much better
'understanded of the people,' the people coining and interpreting these
URIs, than would a branch of the 'urn' scheme tree.

The stretch to see a common concept across both Dewey Decimal sorting
buckets and Library of Congress sorting buckets is a stretch we can begin to
believe we can get many people to master and generally apply right.  The
stretch to the abstract notion of "a name, any name" is far less amenable
to popular understanding.

I can see this domain of application being served competently either by
embedding these sub-schemes in the urn: tree or by coining a new top-level
scheme for this application.  But on balance as far as I can see now, this
domain would most likely be better served by a dedicated top-level scheme.

This is not a show-stopper, just a leaning.  But those are some factors
that I think we should be considering, and that's my leaning of the


> > -----Original Message-----
> > From: Tim Bray [mailto:tbray@textuality.com]
> > Sent: 2 October 2003 18:58
> > To: Roy T. Fielding
> > Cc: Hammond, Tony (ELSLON); uri@w3.org
> > Subject: Re: Announcement: The "info" URI scheme
> >
> >
> >
> > So, as I understand it, 'info:' is just like 'urn:' except for:
> >
> > - For 'info:xxx:', NISO hands out the 'xxx'
> > - There is no requirement for permanence or reference stability.
> >
> > This latter is I suppose why you wouldn't want to do 'urn:info:xxx:'
> > which otherwise would work just fine.
> >
> > Is that oversimplifying?
> >
> > Eric Hellman outlined, quite clearly, the notion that the
> > absence of a
> > built-in dereference mechanism is an advantage for political reasons.
> > While his sentences parse and I have to acknowledge that empirically,
> > it's possible for a human to believe this, the whole notion that an
> > identifier is better because non-dereferenceable just comes from a
> > different planet thatn the one I live on.
> >
> > Like Roy says, let the market decide.
> >
> > I think, though, that if the URN fans and the doi: and info: and tag:
> > people all got together in a room and came out with a reduced
> > number of
> > URI schemes, they and the community would be winners.
> > --
> > Cheers, Tim Bray (http://www.tbray.org/ongoing/)
> >
> >
> >
Received on Friday, 3 October 2003 14:15:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:06 UTC