Re: URx Questions

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

Received on Monday, 21 January 2002 02:28:52 UTC