Re: [URN] Re: URI documents

Dan Connolly said this:
> Harald Tveit Alvestrand wrote:
> > - The solution must document the overall concept that embraces all the
> >   identifiers of this class, commonly called "URI". (This rules out a)
> > - The solution must not invalidate current UR* schemes, including URNs.
> > - The solution should not needlessly complicate or constrain future UR*
> >   schemes
> > 
> > All I can say is - I hope we find a solution.
> 
> Harald, it would help me out if you would
> please point out how it is that (b) is not a solution.
> I read it quite carefully and I find it satisfactory.
> 
> I don't understand the arguments from the folks who
> find it unsatisfactory; rather, I think I understand them,
> but I can't find any technical content to them. They
> seem to boil down to "but we're not sure it's going to
> work that way for URNs."

I'll try to explain some below.

> ============
> Univeral Resource Identifiers -- Axioms of Web architecture
> Tim Berners-Lee
> Date: December 19, 1996 
> [1]http://www.w3.org/DesignIssues/Axioms.html
> 
> Universal Resource Identifiers
> 
> The Web is a universal information space. It is a space in
> the sense that things in it have an address. The
> "addresses", "names", or as we call them here identifiers,
> are the subject of this article.  They are called Univeral
> Resource Identifiers (URIs). 
> 
> On object is "on the web" if it has a URI.  Objects which
> have URIs are sometimes known as "First Class Objects"
> (FCOs).  The Web works best when anything of value and
> identify is a first class object.  If someothing does not have
> a URI, you can't refer to it, and the power of the Web is the
> less for that. 

No argument. Just a desire that has been explained before:
It is agreed that all Objects have identifiers. It is
observed that there are identifiers that have the characteristics
of names (spatial/temporal uniqueness, encouraged but not required 
persistence) and others that have the characteristics of addresses 
(strong tie to location, non temporal uniqueness, no desire for
persistence (some are specifically one-time use only)). 

The URN group's desire was to attempt to group those identifiers
that had naming qualities into a class of identifiers so that
ANYTHING that identified itself as being part of that class
could be assumed to have those same qualities by an entity that
didn't know that particular subscheme.

> 
> By Universal I mean that ...
> ============
> 
> The name has changed over the years (from UDI=Universal Document
> Identifier to URI=Universal Resource Identifer to
> URI=Uniform Resource Identifier) but the concept remains
> the same. Not to mention the fact that the gizmos themselves
> remain the same (try
> http://info.cern.ch/hypertext/WWW/TheProject.html and you'll
> still get information about the World Wide Web project at CERN.)
> 
> So we (W3C) disagree with what Leslie wrote:
> 
> Leslie, 23 Dec 1997:
> >Roy, 22 Dec 1997:
> >> Within the WWW, a fragment serves the purpose of a client-side
> >> specialization of the resource identification.  It is implicit that
> >
> >URIs are not limited to the WWW (okay, these are getting into old
> >arguments...).
> 
> URIs are limited to the WWW by definition; that is, the
> WWW is the set of things addressable by URIs.

This is true by definition. What Leslie was trying to explain was
that many URIs may never be used by by a parser and were never
intended to do so by their creators. E.g. the library commmunity may want
to use URNs as a way to umbrella several identifiers out there. 
The syntax defines how they do it. There is no "protocol slot".

> I have asked whether folks
> expect URNs to fit into the same protocol/software slots
> as today's URIs do (e.g. in proxied HTTP GET requests,
> Java URLConnection() parameters, libwww URI parsing
> calls, etc.) but I don't think I got a clear answer. If
> URNs _are_ expected to fit into those slots, then
> we need a spec for those slots, and (b) is good enough for me.

But the document's we have been talking about talk in
terms of those slots. Not the identifiers themselves. What
we are concerned about is that the requirments created by the protocol
slots are inappropriate for the universaly understood definition
of a URI.

I've always wanted a document that described URIs in a completely
abstract way. Sans the Web. Sans hypertext. Sans libwww. Sans any
protocol or markup language.

Then write a document that describes how specific technologies use
them. 

I.e. I think your desire for a spec for those slots is wrong.
You should want a spec for URIs in an abstract sense. And then
a spec for how those abstractly defined URIs fit your protocol/software
slots.

> (we also need one registry of schemes, and one
> process document for adding items to that registry). If
> URNs are _not_ expected to fit in those slots, then
> I have a problem with that.

URNs are expected to fit those slots. But those slots should not
get to define what URNs are. Instead those slot specifications should 
define how they use them.

> The axioms document[1] goes on to say things like:
> 
> =============
> Axiom 1: Global uniqueness 
> 
>  It doesn't matter to whom or where you specify that URI, it
>  will have the same meaning.

URNs also define an additional requirment of uniqueness: time.
This is the non-reassignment requirment.

> =============
> 
> These axioms are exactly that: arbitrary assertions without
> supporting evidence. They take on value as folks choose
> to accept them (folks being implementors, information providers,
> etc.) "The value of
> a network goes up as the square of the number of connected
> resources" and all that.
> 
> So while it's perfectly possible
> to use names/addresses/identifiers that aren't part of
> the URI space, any such set of names doesn't benefit from
> the value of being part of the URI space. At W3C, we
> think there's plenty of ways to improve the operation of
> the URI space, and no reason to invest in something
> that doesn't interoperate, at this point.

Which is why we formulated URNs to fit that scheme. What
I think we're after is a definition of URIs that isn't
in terms of specific technology but of a true abstract
definition unencumbered by specific technology.

> 
> =============
> Axiom 3: non unique 
> 
>  URI space does not have to be the only universal space
> 
> 
> The assertion that the space of URIs is a universal space
> sometimes encounters opposition from those who feel
> there should not be one universal space. These people
> need not oppose the concept because it is not of a single
> universal space: Indeed, the fact that URIs form universal
> space does not prevent anyone else from forming their own
> universal space, which of course by definition would be
> able to envelop within it as a subset the universal URI
> space. Therefore the web meets the "independent design"
> test, that if a similar system had been concurrently and
> independently invented elsewhere, in such a way that the
> arbitrary design decisions were made differently, when
> they met later, the two systems could be made to
> interoperate. 
> 
> There may be in the world many universal spaces, and
> there need not be any particular quarrel about one
> particular one having a special status. (Of course, having
> very many may not be very useful, and in the World Wide
> Web, the URI space plays a special role by being the
> universal space chosen in that design.) 
> 
> For example, it would be possible to map all international
> telephone numbers into URI space very easily, by inventing
> a new URI "phone:" after which was the phone number. It
> would in fact also conversely be possible to map URIs into
> international phone numbers by allocating a special phone
> number not used by anyone else, perhaps a special
> country code for URI space, and then converting all URIs
> into a decimal representation. In that case, both URIs and
> phone numbers would be universal spaces. Identifiers in
> one space would be consisting only of numbers, and in the
> other of alphanumeric characters. One would be shorter
> than the other, but there is no reason why, in principle, the
> two could not co-exist, allowing you to dial any Web object
> from a telephone as a telephone number, and point to any
> phone from a hypertext document.
> 
> So, on this last axiom rests not specifically the operation of
> the web, but its acceptance as a non-domineering
> technology, and therefore our trust in its future evolvability.

I think you're bordering on Larry's last suggestions which
I liked. What I'm suggesting is that the currently discussed
draft makes to many _hypertext_ specific requirments that cause
it to not be able to subsume other namespaces in your interoperability
example. Make the definition of URIs general enough and not tied
to any current implementation so that the requirments on grandfathered/
interoperated schems is _extremely_ minimal.

It's then perfectly reasonable to create a new document that
describes the limitations that use by the hypetextually oriented
Web creates (relative URIs and fragments).

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | michaelm@rwhois.net

Received on Friday, 2 January 1998 11:48:03 UTC