W3C home > Mailing lists > Public > uri@w3.org > January 2002

Re: Some recent Internet Drafts relating to URIs

From: Michael Mealling <michael@neonym.net>
Date: Sun, 20 Jan 2002 13:31:07 -0500
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: Michael Mealling <michael@neonym.net>, URN <URN-IETF@LISTS.NETSOL.COM>, URI <uri@w3.org>
Message-ID: <20020120133107.D4756@bailey.dscga.com>
On Sun, Jan 20, 2002 at 08:13:38PM +0200, Patrick Stickler wrote:
> On 2002-01-20 19:00, "ext Michael Mealling" <michael@neonym.net> wrote:
> > On Sun, Jan 20, 2002 at 06:29:31PM +0200, Patrick Stickler wrote:
> >> On 2002-01-19 14:04, "ext Justin Couch" <justin@vlc.com.au> wrote:
> >>> ... The
> >>> URN class is coded to look for the "urn:" prefix,
> >> 
> >> But not all URNs are 'urn:'s.
> >> 
> >> 'hrn:'s are also URNs.
> > 
> > We tried that route and after almost 10 years never got any agreement on it.
> > Both sides had perfectly valid points so we wasted _years_ of time on
> > arguments that in the end wouldn't have changed much anyway...
> Interesting....   so you propose a monopoly on indirect identifier schemes?

No. I'm saying that attempting to assert something like that as 
universal isn't very productive...

> What about folks who need or want a hierarchical URN scheme? 

Fine. Specify a new URI scheme and say those are its semantics. But
don't call it a URN since that name is already taken for a different

> What about folks who do not wish to reserve a 'urn:' namespace because the 
> space they want to use will be transient -- but none the less in need of 
> global uniqueness. What about ... surely I don't need to enumerate all of the
> obvious cases where 'uri:' doesn't do the job...


There is a method specified in RFC 2717 for how to get a new URI scheme.
The document uses the term 'URL' but that's a historical artifact and
not indicative that it excludes particular schemes.

> Sorry that I wasn't present for those ten long years of discussion.

Don't be. It wasn't fun. But please don't ignore it....

> I don't agree, though, with your asserted conclusions.

Fine. I don't agree with some of yours. The question is: how are
we going to get along?

> >>> ... If you created a URL object
> >>> using "hrn:"
> >> 
> >> But you wouldn't do that, since an 'hrn:' is not a URL, it
> >> is a URN.
> > 
> > And I disagree. A 'URN' is just one URI scheme and trying to get everyone
> > to agree that there's more to it than that just wont' fly. I tried arguing
> > that for a long time and in the end I realized it just wasn't worth the
> > effort.
> Let's please keep the terminology straight. 'URN' is a URI Class, not a
> scheme. If you wish to assert that there is one and only one URN scheme,
> namely 'urn:', fine, but they are *not* the same thing.

Nope... Sorry. I have to use the terminology that we've been using
for the past several years that a lot of us have finally agreed upon.
If you want to introduce new terms that are specific to your application
then fine. But please don't re-use old ones. Its to confusing and raises
to many hackles....

> Whether you subscribe to the classical or contemporary view of whether
> URI classes should be formal or not, the classes still have definition,
> and when we speak of URI, URL, URN, etc. we speak of classes, not schemes.

Nope. These groups have spent _considerable_ amount of time coming to the 
contemporary conclusion. Most importantly the IETF has been trying to
deprecate the use of the term 'URL' ever since '93. 

> And when I assert that 'hrn:' is a URN scheme, that assertion is valid,

For you it might be. But you're asserting _vastly_ different definitions
for your terms than most here would...

> even per the contemporary view. Whether or not some application should
> *know* that it is a URN and ascribe some common shared semantics of URN'ness
> to it, or whether it should take it in isolation of any classification,
> is a separate issue.
> I.e. the only difference between the classical and contemporary views
> is whether URI classifications are formal or not, not whether those
> URI classes have definition (possibly only informal).

Ok, then we weren't clear. I think what the group meant to say is that
talking about URI classes _in general_ is a useless endeavor and _in general_
shouldn't be done....

> > The best thing you can and will get is to simply say that there are URIs
> > and that each scheme has its own semantics and anything beyond that is
> > application specific. IMNSHO, I think you'll have a better chance putting
> > these semantics into RDF than you ever will getting them as standard parts
> > of the URI definitions....
> I intend to express them in RDF, and applications which choose the classical
> view of URI classification (that such classifications are formal) may use
> such RDF schemas as the mechanism for formal application of such
> common semantics. 

Fine. But don't start out by attempting to redefine how URIs work. Do that
redefinition in RDF using RDF's rule. Its kind of like me redefining
now RDF works so I can do what I want to do. It might work for me but
it causes all sorts of interoperability problems...


Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net
Received on Sunday, 20 January 2002 13:35:48 UTC

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