RE: URNs for 'naming authority assignment', not 'permanent'

Hello Larry,

> -----Original Message-----
> From: Larry Masinter [mailto:LMM@acm.org] 
> Sent: 16 September 2003 19:25
> To: 'Williams, Stuart'
> Cc: uri@w3.org; urn-nid@lists.verisignlabs.com; 
> leslie@thinkingcat.com; thiemann@acm.org
> Subject: URNs for 'naming authority assignment', not 'permanent'
> 
> 
> (giving the thread a subject line)

Mea culpa... somehow managed to reply without retaining the subject line :-(

> 
> > I like the idea of a univerally applied principle such as you
> > suggest. Could you expand a little on "'naming authority assignment' 
> > schemes". I think I know what you are getting at... but I'm trying to
> > see why, for example, the http URI scheme wouldn't fall on the URN 
> > namespace side of this distinction - it establishes URI assignment 
> > authorities  that then control the assignment of URI within some 
> > sub-space. Maybe URI assignment authorities don't fall within the 
> > locus of what you mean by a 'naming authority'.
> 
> URIs are protocol elements intended for communication.
> To be useful, the definition of the URI scheme should
> tell the receiver of a URI what resource the URI identifies.

Isn't that one of those vexing questions that has generated large volumes of
traffic on the uri and www-tag lists?

I can see that the HTTP and FTP schemes (and others) do so in a very
operational sense (as you observe below) that describes how to process the
URI to retrieve representations (of something [maybe]) - or more generically
how to make use of it in a particular context.

A large number of the early URI scheme registrations speak of URIs being
used to 'designate'. Then there are other terms floating around that may
have subtle differences and similarities of meaning, like 'denote',
'indicate' and 'identify'. 

So... I'm not sure that any of the URI scheme registrations I've looked
actually "what resource the URI identifies." 

Folks also quibble about whether is some sense or other its possible to
determine the sort of thing a URI identifies - and indeed whether can even
be said to identify a single thing.... agggghhhh I can see the thread
explosion coming round for another cycle....

> When you define a URI scheme, you are expected to define the 
> access semantics of the scheme -- how it is that a receiver 
> of a URI in the scheme is supposed determine the resource 
> that the URI identifies. 

I can see that operationally many schemes describe how a scheme URI is used
to access a resource... but whether that constitutes a determination of what
resource the URI identifies is unclear (to me). It may be satisfatory for
some. In some sense the resource is then whatever you perceive it to be as a
result of the experience of interacting with it. Different individuals may
reach different, reasonable, conclusions about what resource is being
'identified'.

I guess this all collapses into a rathole if one is talking solely in the
operational sense of determining the resource that the URI identifies - that
seems a very pragmatic view (good), which has successfully avoided answering
the question of what the URI identifies...

> For 'http', the definition URIs with 
> the http scheme is in the HTTP protocol specification, and 
> the definition is tied to the HTTP protocol.  (People might 
> use HTTP URIs in other ways to indicate something else, but 
> that use isn't part of the definition of the HTTP scheme.)

Yes... 
 
> The "urn" namespace was defined as a system which had no 
> defined operational interpretation for determining the 
> resource identified; rather, it allowed namespace authorities 
> to create naming rules, and that the receiver of a URN would 
> have to use other means to actually locate the resource.

Ok...

> Of course, it is possible to treat a locator (such as a HTTP
> URI) as if it were a uninterpreted identifier; many 
> applications of URIs do this. And it is possible to devise an 
> operational protocol for resolution of URNs. But neither of 
> these are definitional.

Ok...

> The guidelines for IETF registration of URI schemes vs.
> URN namespaces could be specific that the namespace 
> definition needs to be explicit about whether the operational 
> protocol is definitional or merely a heuristic.

I think this is getting close... but I have had to think about this...

RFC2616 defines the syntax and semantics of the HTTP URI scheme wrt to
operational use of HTTP scheme URI with the HTTP protocol. As I understand
it this is not a closed definition and other uses are allowed... but
unspecified. However, in circumstances an HTTP scheme URI is used to access
a resource, I can think of no-circumstances in which the access protocol is
not HTTP... can you? ie. the use of the HTTP protocol is implicit when
dereferencing an HTTP URI.

> For doi, hdl and info, it seems that the intent is
> to make the registry itself definitional, and the resolution 
> mechanisms heuristic. Because of this, I think they fit into 
> the "URN namespace" scope.  For "tag", again, the goal is to 
> avoid any definition of any operational means of 
> identification, so it would fit into a URN namespace also.

For these schemes/namespaces (I don't know if this is true of all of them)
there is no single define way of deferencing an identifier that is implicit
in the identifier. The specification of does not link the identifier to the
use of any particular operational mechanism for resolving access to the
referenced resource.

I think this would reinforce the notion that different URI schemes imply
different access mechanisms AND that with the exception of the URN scheme,
the intended access mechanism is implicit in the definition of the scheme.

How do we square the gatewaying of other URI schemes over HTTP as an access
mechanism? Maybe its that there is a native or intrinsic access mechanism
defined with the scheme, but that does not preculde other means of access
being used.

> However, for "tdb" and "duri" (http://larry.masinter.net/duri.html),
> as well as "hash", (draft-thiemann-hash-urn-00), there *is*
> an operational definition for determining the resource 
> identified, so they would fit better as new URI schemes.

Interesting... you drafted tdb: and duri: as URN namespaces... and I think
that fits with the above notions of definitional and heuristic operational
protocols. Section 5.4 of .../duri.html seems at best heuristic... and I see
little (maybe nothing) in the way of an operational way of dereferencing
duri/tdb identifiers. So I think you made the right call in the draft... 

I haven't looked at "hash" URIs.

> What do you think of this as a guideline? 

I think it could work... although maybe we should see if we can categorise a
few more examples before really patting ourselves on the back. 

> I believe there are many namespace registrations that are hanging because
> of the weak guidelines between "URN namespace vs. URI 
> scheme", and this might help. 
>
> Except for inertia of work already underway, are these workable as
guidelines?

I think that would perhaps require a test to see if several *independent*
people could apply them to a set of test cases and make substantially the
same deterimination. Application to a number of existing schemes/namespaces
might reveal some anomallies which would have to be grandfathered simply
because oe installed based.

I think it would be hard (politically) to apply new criteria to work in
progress.

> Larry

Regards

Stuart

Received on Wednesday, 17 September 2003 10:56:26 UTC