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 11:20:24 -0400
To: Tim Kindberg <timothy@hpl.hp.com>
Cc: uri@w3.org, sandro@w3.org
Message-ID: <20010427112024.X15395@bailey.dscga.com>
On Thu, Apr 26, 2001 at 08:10:24PM -0700, Tim Kindberg wrote:
>     A 'tag:' identifier is a type of Uniform Resource Identifier (URI)
>     [RFC2396] designed to meet the following requirements:
>     1) Identifiers are unique across space and time and come from a
>        practically inexhaustible supply;

Temporal uniquenss means no reassignment, correct?

>     2) identifiers are convenient for humans to mint (create), read, type
>        etc.;

Why humans? Humans tend to do #1 very badly....

>     3) zero registration cost, at least to holders of domain names or
>        email addresses; and negligible cost to mint new identifiers;
>     4) easy identification of the entity that has minted the identifier,
>        should that be desirable;
>     5) independence of any particular resource-location or identifier-
>        resolution scheme.
>     For example, the above requirements may apply in the case of a user
>     who wants to place identifiers on their documents:
>     A) They want to be sure that the identifier is unique. Global
>        uniqueness is valuable because it guarantees that one identifier
>        cannot conflict with another, however identifiers become shared.
>     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?
If the 'category' of the document changes does that mean the identifier
changes? Hmm... I don't the term categorise used elsewhere. What
categorization method are you refering to?

>     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? Or are you 
concerned about the minting of each individual identifier? I.e. you
need to have a sub-space delegated to you instead of continually
having to ask someone else for one?

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

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

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

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

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

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

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

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


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 11:30:49 UTC

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