W3C home > Mailing lists > Public > uri@w3.org > April 2001

Re: Proposal: 'tag' URIs

From: Michael Mealling <michael@bailey.dscga.com>
Date: Fri, 27 Apr 2001 13:52:48 -0400
To: Tim Kindberg <timothy@hpl.hp.com>
Cc: michaelm@netsol.com, uri@w3.org, sandro@w3.org
Message-ID: <20010427135248.M19625@bailey.dscga.com>
On Fri, Apr 27, 2001 at 09:37:38AM -0700, Tim Kindberg wrote:
> At 11:20 AM 4/27/2001 -0400, Michael Mealling wrote:
> > >     B) It is useful for the identifier to be tractable to humans: they
> > >        should be able to mint new identifiers conveniently and to type
> > >        them into forms; the identifiers should be able to contain a hint
> > >        about how to categorise the document.
> >
> >A persistent identifier should contain the 'category' of the document?
> 
> We say "should be able to contain a hint about how to categorise the 
> document". That's not the same thing. And it's only an example.

I'm still confused about what a category is and if its a specific part of
the namespace or just an example of something someone might due given the
ability of the minting entity to put whatever they want after the date?

> > >     URNs [RFC2141] are intended to be resolvable in a default naming
> > >     context.
> >
> >Very incorrect. URNs are never required to be resolvable. The OID and UUID
> >namespaces not allow resolution simply because there is no such thing as
> >a global OID or UUID database. There is a process for discoverying whether
> >or not a given URN namespace is resolvable. But even then, that isn't 
> >required.
> 
> There are two things: 'resolvable' and 'default namespace'. For the first, 
> we're only talking about conventions. Any identifier is resolvable in any 
> namespace, trivially -- it just might not be bound there. It seemed to me 
> that the default assumption with URNs was 'it's worth a try to resolve it'.

Nope. URNs require that resolution never be required by any URN namespace.
I.e. RFC 2141 only mentions resolution in one section and that's where it
concerns the requirement that nothing about the URN framework should
disallow resolution if so required by some application. The default
assumption for all URNs is that it names something persistently. That's it.
Resolution is something that you can try within some application context but
that's just that application's context. URNs themselves aren't required
to support resolution. You'll notice that none of the URN namespaces defined
to date define a resolution mechanism....

> On the second point, you say 'there is a process for discovering whether or 
> not a given URN namespace is resolvable'. That's philosophically opposed to 
> my view. I think you mean: ''there is a process for discovering whether or 
> not there is a resolver for a given URN namespace'. 

Nope. That is _not_ what I mean. I explicitly mean there is a way of finding
out if a URN is resolvable if that is what you want to do. But you are
not required to do that in any way. If your application requires resolution
then there are several methods you can use to attempt to do that. But there
is nothing in RFC 2141 or RFC 2611 that require you to do it.

> That means, a 
> deterministic algorithm that maps from the name space to 'the' resolver(s). 

Nope. You can define such a thing but it is divorced form the specification
of the namespace and the resolution service cannot be required for use by
the URN namespace.

> There is no 'the resolver' in my world -- there is a plurality of resolvers 
> that may be discovered in all sorts of ways and one couldn't possibly have 
> an algorithm for enumerating them -- it would be like having an algorithm 
> to enumerate web sites.

Sure. That's exactly how the OID and UUID namespaces are expected to work.
They're URNs because that's the semantics they have. If resolution of an OID
or UUID URN is needed for some application specific function then that
application has to provide the resolution mechanism because there are no
defined 'resolvers' for either namespace. If you're in the Windows world
and you needed to find some COM object by its UUID URN then you'd use
the COM API for asking for it. There are many other functions using UUIDs
in Windows where you don't 'resolve' the identifier. You just use it to
tell two objects (or interfaces) apart.

> I wanted to work inside the URN scheme, I really did. But it was misgivings 
> such as the ones I've just tried to express that made me give up on that. 
> Perhaps I should reconsider but I'm not yet convinced.

I think you might have been confused by some of the erroneous statements
about URNs that tend to float around. The only ones that matter are
RFC 2141 and RFC 2611. And neither one of these define resolution or
require it in any way....

> > > Software encountering a URN in a document is liable to
> > >     attempt to resolve it, even though the entity that minted the
> > >     identifier has not bound any resource in that context.
> >
> >That's an historical artifact that only happens in one browser (older
> >verions of Netscape. And even then they only ask the HTTP proxy).
> >No browser should attmpt to resolve all URNs unless it has specific
> >software that can tell it whether or not that makes sense....
> 
> Is there a document that states a policy for URNs on something like 
> 'criteria for attempting resolution'?

Not really, no. The reason is that URNs exist outside of any attempt to 
resolve them. There are some documents that define how you might resolve
them in some specific contexts (see 
http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt
as just one example). There was also the WIRE stuff that few people from
W3C did at one point. You could also just ask a local cache. But again,
all of these exist in some application. RFC 2141 never specifies
any of these as required (it doesn't even mention them at all).

> > > 3. MEETING REQUIREMENTS 1-5
> > >
> > >     Requirement 2 of Section 1 -- convenience for humans -- is met by 
> > the URL-
> > >     like syntax for tag authorities. However, the onus is on individual 
> > naming
> > >     authorities to use human-friendly specific identifiers.
> >
> >In our experience, if it looks like http URL then people are going to treat
> >it like one. I.e. they're going to look at that '1' as a directory and
> >treat it as such (i.e. does tag://foo.com/../1:../foo.html make sense?)
> 
> We're open to alternative suggestions for the specific delimiters that we 
> should use. But logically I believe the date belongs with the authority 
> name inside the colons.

Sure. Since you're not using '//' or port numbers you're safe for alot of
delimiters. I'd do this:
authority;date:specifc

> > > 4. EQUALITY OF TAGS
> > >
> > >     The tag syntax rules in Section 2 uniquely determine tag authority
> > >     identifiers for any particular authority and date. Furthermore, 
> > specific
> > >     identifiers are mandated to be single-valued.
> > >
> > >     Therefore, two tag URIs are equal if and only if they are identical as
> > >     character strings.
> >
> >  Hmm... what do you do about the fact that you are using the '/' character
> >and that implies the hierarchy equivalence rules of the common syntax
> >stuff in 2396?
> 
> Maybe we've erred by using the '/'. I'll look into what we can use instead.

I like either ';' or ',' but that's just me...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com
Received on Friday, 27 April 2001 14:03:16 UTC

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