Subject: Re: URx Questions

From: Patrick Stickler <[email-masked]>
Date: Mon, 21 Jan 2002 16:43:40 +0200

From: Patrick Stickler <[email-masked]>
Date: Mon, 21 Jan 2002 16:06:03 +0200
To: "ext Daniel R. Tobias" <[email-masked]>
Subject: Re: URx Questions

On 2002-01-21 15:38, "ext Daniel R. Tobias" <[email-masked]> wrote:

>> Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in
>> alot of needless overhead.
>
> True... I've noticed a current trend in Internet drafts to try to get
> both forms of each new scheme... this is rather confusing, and leaves
> me wondering which I'm supposed to use if I decide I want to use one
> of those new schemes to give unique names to things.  Do I use the
> "urn:" prefix if I want them to ultimately resolve to some Web
> resource, and leave it out if I don't expect such resolution to ever
> happen?  But what if I change my mind later?  Does that mean I end up
> with two different URIs for the same thing?

Exactly. It should be clearly stated that there should either be
a URI scheme or a 'urn:' Namespace, but not both, otherwise one
must equate all pairs of URIs from either.

> But even if I want them
> to resolve, how wold they... none of these new schemes seem to be
> giving the slightest clue as to how they would actually be resolved
> as URNs.
>
> Actually, in general, that seems to be the biggest problem with URNs;
> they're a good concept in theory, but in practice even after years of
> discussion nobody seems to really know how they're going to be made
> resolvable.

Well, resolution of URNs has always been contextual. Work is finally
reaching maturity on a global, distributed mapping table that would
bind URNs to URLs and would allow any client, anywhere to retrieve
resources by URN as easily as URLs using a system similar (actually
based on) the DNS system. But one can always provide localized
resolution solutions.

Nokia uses URNs to identify all managed digital resources, and
retrieval is based on configuration for a given site or client, as
to which registry or archive the resource is accesable. This system
has been in use now for a couple of years, and so when folks say
that all URNs must be urn:s, I have to laugh.

C.f. http://www-nrc.nokia.com/sw/Metia.zip

> Some of these new proposed schemes offer namespaces
> whereby anybody can create names at will, but in the absence of any
> registration system that puts them all in a big database, and with
> explicit definitions to the effect that the use of domain names to
> identify the minting authority does not imply that this authority is
> actually reachable currently at that address, there simply does not
> seem to be any reasonable mechanism by which a user agent might try
> to resolve them into a resource.
>
> By those standards, URPs may make more sense, since they are
> explicitly defined not to resolve into anything.

We still need URNs. We need a way to name things without having
to worry about where those things might be stored or managed.
Such as the name of a book or image or soundtrack, which may
in fact get stored in many locations for various reasons, but
is still the very same "thing".

I see three parts to URN usage:

1. Minting of the URN, which must be globally and temporally unique.
2. Describing the resource in terms of the URN (optional really) such
   as ownership, encoding, language, etc.
3. Mapping the URN to a URL or other means of retrieval, for a given
   environment (which may be global)

Most URN schemes (ISBN, DOI, etc.) force you to pay for all three
services, when one may not need all of them -- and most such schemes
put a focus on high persistence, security, and quality which, while
very important for large publishers, are not as critical for most
folks and also price such services way beyond the reach of most
folks (just price a few DOIs and ISBNs, very expensive).

So my goals with the 'hrn:' URN scheme is to provide a reliable and
cheap way for folks to mint URNs and then address the description
and mapping issues seperately.

There already are several description solutions available, including
open source such as the Open Archives Initiative. And since it is
not too hard or expensive to get Web or FTP space, the mapping
and retrieval is also easy to arrange -- especially if the description
solution is used to define the mapping, by simply including a
property such as 'location' which is a URL.

So, whether or not the global resolution solutions planned for URNs
happen or not, we can still use URNs very effectively and they are
very much needed.

Cheers,

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [email-masked]

---

From: Bryan Schlegel <[email-masked]>
Date: Mon, 21 Jan 2002 06:59:59 -0500

how do i get off this list?

-----Original Message-----
From: Patrick Stickler [mailto:[email-masked]]
Sent: Monday, January 21, 2002 2:30 AM
To: [email-masked]
Subject: Re: URx Questions

On 2002-01-21 5:37, "ext Sean B. Palmer" <[email-masked]> 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 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?

> 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

--