Re: URx Questions

At 09:29 AM 1/21/02 +0200, Patrick Stickler wrote:
>On 2002-01-21 5:37, "ext Sean B. Palmer" <sean@mysterylights.com> wrote:
>
> > Hi Patrick,
> >
> > Sorry for taking so long to go through your recent URx publications;
> > here are some fairly innane questions, and some general comments.
> >
> > My first Q is about the hierarchial URN scheme. Michael pointed out
> > that they can have domain names as authority components, which isn't
> > all that persistent. UUIDs would be alright, but they're fairly
> > difficult to generate. The other option is a tag-esque "domain,date"
> > component - which brings me to the question: how does "hrn:" differ
> > from "tag:"?

As one of the people who devised tags -- 
http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-01.txt -- I'm 
having trouble understanding Patrick's hrn: design and his comments below.

One of the rationales for tag: has always been to separate minting from 
binding and make minting convenient for humans, so we seem to share that. 
An important aspect of minting, obviously, is a guarantee of uniqueness. 
Email addresses and domain names belong to at most one entity at a time and 
are thererfore suitable 'seeds' for uniqueness -- hence we use them in 
tags. But they're not uniquely assigned over time. Therefore we qualify 
them with a date on which they're assigned:

tag:timothy@hpl.hp.com,2002-01-21:ikaika, which is a name that I have just 
assigned for my dog, is guaranteed to be unique now and forever, because I 
own that email address on today's date. No-one -- in particular, a 
timothy@hpl.hp.com at HP in the year 2034 -- is allowed to mint a tag for 
any date other than one on which they own the email address/domain name, so 
they can never legitimately choose the same name.

In contrast, the person who holds abc.com in 2034 might 're-mint' 
hrn://abc.com/288918293/3/en/global/docbook. At least, there may be no 
records of what previous owners of abc.com have minted, so the new minter 
can't be sure.

As for the hierarchical nature of hrns -- sure, hierarchies are nice. But 
why mandate a syntax to that extent for the 'local' part of the identifier? 
It's nobody else's business; it just has to be unique.

By the way, tag: is in the RFC editor's queue. It's also somewhere in the 
urn nid registration process.

Tim.




>As I pointed out in an earlier response, the use of the web
>authority does not make an 'hrn:' non-persistent, as the
>web authority in an 'hrn:' represents only the minting
>authority, and not the resolution authority. In an 'http:'
>URL, a web authority is both, and thus if it changes or
>becomes inactive, the resolution authority becomes invalid
>and thus persistence is impacted.
>
>'hrn:' URNs do not have that problem, even though web authorities
>may be used, because the web authority remains historically valid
>and even if it becomes inactive, that has no impact on the
>persistent validity of the 'hrn:' URN.
>
>See section 3 of draft-pstickler-uri-taxonomy-00 regarding
>these distinctions.
>
>The benefit of allowing a web authority as the minting authority
>is that it provides a far less centralized method of "namespace"
>than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI,
>ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN
>based on a web authority, or a non-mnemonic (or partially
>mnemonic) URN based on a UUID easily and without fear of
>collision. And those URNs can be hierarchically defined to boot.
>
>'hrn:' = "URN Power to the People" ;-)
>
> > I presume that the hierarchial aspect is what you're
> > after, although I'm not sure what the relationship between the
> > segments is.
>
>Hierarchy was one desired characteristic. Minimially-centrallized
>minting was another (i.e. based on any web authority, not having
>to register a namespace or pay some agency that has a namespace).
>
>Per above.
>
> > Why not use ":" as a hierarchial segment delimiter in
> > "tag:"?
>
>Because there already is a standard syntax for hierarchical URIs and
>many APIs and libraries exist for parsing such hierarchical URIs into
>their components.
>
>Why introduce another hierarchical syntax if the present standard
>does the job?
>
> > Note that "tag:" was going to be registered as a URI, and URN
> > NID.
>
>I understand that. But it appears to me that it is only the
>contemporary view that forces this redundancy. You should be
>able to register it simply as a URI with a classification of URN.
>
>Or, you can register it as an NID of the 'urn:' scheme.
>
>Why do both?
>
>Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in
>alot of needless overhead.
>
> > Next Q: I can't work out what "voc:" is for, if anything. The draft
> > states: "This provides a more robust and safe treatment of unqualified
> > names than the 'online:' or 'genid:' treatments employed by most RDF
> > systems to date.", so it sounds as if they're meant to be replacements
> > for anonymous nodes... but the structure of the URIs suggests
> > otherwise.
>
>The use of 'voc:' in RDF for providing non-collisive identifiers
>for local (not anonymous) resources is very much a fringe use.
>
>The 'voc:' URT scheme is intended for vocabularies. See the
>examples in the I-D. That should clarify its intended usage.
>
>In short, for the URIs of all element and attribute names of all
>XML content models, for the URIs of all resource names of all
>RDF schemas, for the URIs of all controlled vocabularies
>and taxonomies such as ISO language and country codes, TGN
>geographic names, etc. etc.
>
>I.e. for all abstract identifiers.
>
>I think that the 'voc:' URT scheme is the most important of
>all of the newly proposed schemes, and has the widest application.
>
> > I've also been wondering about the taxonomy in general. A lot of
> > people will tell you that an HTTP URI is just as good a persistent
> > identifier as any URN - it's the social contract that matters, and
> > HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather
> > artificial to me, and I fear that creators of new schemes will have to
> > beg to you as the arbiter of where a new scheme belongs.
>
>I agree that before such a taxonomy would reach the maturity
>of a standard that it would need more precise definition. I think
>though that the criteria distinguishing the proposed classes is
>fairly straightforward.
>
>If your URI scheme denotes a point of access, it is a URL. If it
>denotes an indirect access key, it is a URN, if it does not resolve
>(is self contained) it is a URP.
>
>I.e.:
>
>    URL     direct resolution
>    URN     indirect resolution
>    URP     no resolution
>
> > [BTW, I'm not
> > sure I would have chosen the acronym "URP". Every time I write it, I
> > feel like excusing myself afterwards].
>
>It does seem to give a few folks indigestion ;-)
>
> > For example, you've listed ESL as a URV. I can see the motivation
> > behind that, and I would agree - if not for the fact that ESL could
> > easily have been submitted as a URN NID.
>
>But why? Is the primary and fundamental purpose of an 'esl:' URI to
>denote some other web resource independent of its location?
>
> > At the moment, I am one of
> > those who feel that the boundary between URP and URN is not all that
> > solid. [In fact, I wonder why there isn't a "uri-x:" alternative of
> > "urn:urn-x:".]
> >
> > I'm not sure what the utility of the "qname:" scheme is. In fact, many
> > of the drafts are lacking in describing the utility of the schemes
> > themselves. Whilst this seems to be common practise, it's something
> > that I battle against. All new schemes should have a detailed space
> > describing their purpose and motivation, because it obviates arguments
> > later on. If you could prepare a summary of the aims of each scheme,
> > that would be rather useful.
>
>All of the schemes have specific utility but I tried to avoid being
>too specific with regards to all possible applications, keeping each
>I-D focused on the essential technical details regarding the URI
>scheme in a generic fashion that would be as future-flexible as
>possible.
>
>I am actually working on a more descriptive account of where/how each
>is used, which, if I get it done in time, I will likely submit for
>the SW track at WWW12.
>
>Cheers,
>
>Patrick
>
>
>--
>
>Patrick Stickler              Phone: +358 50 483 9453
>Senior Research Scientist     Fax:   +358 7180 35409
>Nokia Research Center         Email: patrick.stickler@nokia.com


Tim Kindberg

mobile systems and services 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 Monday, 21 January 2002 11:36:40 UTC