Re: URx Questions

On 2002-01-21 18:42, "ext Tim Kindberg" <timothy@hpl.hp.com> wrote:

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

I fully appreciate the benefit of guarunteed global and temporal
uniqueness (hence support for UUIDs), but I feel that there are
other means of anchoring names in time, not just by date, such
as version numbers, and there is nothing to prevent you from including
a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't
manditory.

While the goal of persistence is one that all URN schemes should
embrace, there are different degrees of persistence and different
degrees of uniqueness, and given the intended use of 'hrn:'s felt
it reasonable (if not proper) to leave it up to the minting
authority to decide what degree of persistence is optimal.

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

I'm not sure I follow you -- though per my unsure understanding,
you would like to leave everything beyond the authority portion
opaque?

Well, there's no restriction about having "local" syntax for
partitioning of any sort, and you can have any valid URI string
(sans '/' characters) in your local part, with just one level
of naming.

Having a standardized representation for hierarchy, though,
is very useful for scoping identifier models which define the
identity of resources in terms of superordinate context.

E.g. work/expression/realization/instance is a common hierarchy
in the library/literature fields.

We use a similar hierarchical, scoping identity model for
modular digital resources here at Nokia.
 
> By the way, tag: is in the RFC editor's queue. It's also somewhere in the
> urn nid registration process.

I am well aware of that, and wish the 'tag:' URI scheme
well. In fact, I referenced it specifically in my I-D
http://ietf.org/internet-drafts/draft-pstickler-uri-taxonomy-00.txt

I will admit, however, that the intended purpose and utility
of the 'tag:' and 'hrn:' URN schemes do overlap, and one
advantage of the 'hrn:' scheme (having of course a biased
view) is that the semantics of the 'hrn:' scheme expect an
instance of that scheme to denote a retrievable digital
resource whereas the 'tag:' URN/URT scheme may be used for
either digital or non-digital resources, which introduces
problems for software applications needing to decide what
to do with one.

Regards,

Patrick

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

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Tuesday, 22 January 2002 09:27:20 UTC