Re: Proposal: 'tag' URIs

At 11:20 AM 4/27/2001 -0400, Michael Mealling wrote:

>Temporal uniquenss means no reassignment, correct?

Yes.


> >     2) identifiers are convenient for humans to mint (create), read, type
> >        etc.;
>
>Why humans? Humans tend to do #1 very badly....

You're right that #1 is iffy-er than the others. I'd envisage more that an 
entity has a local web site or an account with 'myTags.com', which 
dispenses new tags to them and their software -- optionally with some 
choice from the user .

> >     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.



> >     C) They do not want to have to communicate with anyone else in order
> >        to mint identifiers for their documents.
>
>Beyond a domain registrar and/or an email mailbox?

Yes.

>Or are you
>concerned about the minting of each individual identifier?

No. -- see 'tag-dispensing website' above.


> >     D) It is natural to use a name associated with the user or their
> >        organisation within the identifier, since that is the origin of
> >        the identifier.
>
>Does a document get a new name if it moves to a new organization?

Not by default. Again, the wording about having human information in the 
tags is that that should be an option, not that anyone should rely upon it.


> >     E) As a good net citizen, the user does not want to use an identifier
> >        that might be assumed by software to imply the existence of a
> >        corresponding resource in a default binding scheme  so that an
> >        attempt to retrieve that resource is likely but doomed to failure.
> >        Of course, this leaves them free to exploit the identifier in
> >        particular applications and services, where the context is clear.
> >
> >     Existing identification schemes satisfy some but not all of the
> >     general requirements 1-5. For example:
> >
> >     UUIDs [UUID, ISO-11578] are hard for humans to read and the assigning
> >     organisation is not explicit.
>
>Why does it need to be explicit?

It doesn't but we think it's useful to have that option.



> >     OIDs [OID, RFC3061] and Digital Object Identifiers [DOI] require
> >     naming authorities to register themselves, even if they already hold
> >     a domain name registration.
>
>That's a simple policy change. OIDs would make it fairly easy to say
>that anyone with a domain-name now has an OID as well. The only
>problem is does the OID move with the domain-name when someone doesn't
>pay their bill?

Tags only have to be unique. As long as there are adequate criteria for 
assignment and unassignment, those operating according to our proposal can 
be confident of minting unique tags.


> >     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'.

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'. That means, a 
deterministic algorithm that maps from the name space to 'the' resolver(s). 
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.

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.


> > 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'?


> > 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.


> >     Requirement 4 -- convenient identification of the minting entity, where
> >     desirable -- also follows from use of domain names and email 
> addresses. An
> >     entity may use its authority name in a tag if it wishes to be so
> >     identified; alternatively, it could lease identifiers privately from
> >     another entity ('myTags.com').
>
>Mind if I ask where this requirement comes from? Why does the
>minting entity have to be conveniently identified?

See the above (doesn't have to be).


> > 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.

Thanks for your feedback,

Tim.



Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
timothy@hpl.hp.com
voice +1 650 857 5609
fax +1 650 857 2358

Received on Friday, 27 April 2001 12:37:56 UTC