Subject: FW: Re: Some recent Internet Drafts relating to URIs

From: Bryan Schlegel <[email-masked]>
Date: Fri, 18 Jan 2002 20:05:22 -0500

remove [email-masked] or [email-masked]....I am getting mail
forwarded from old job.

-----Original Message-----
From: Justin Couch [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:37 PM
To: [email-masked]
Subject: Re: Some recent Internet Drafts relating to URIs

Patrick Stickler wrote:

> As to RDF applications that attempt to grok URIs for various
> purposes, I can't say. If they are "stupid" and presume that
> every URI is an 'http:' URI and barf when they fail to resolve,
> then of course, any of the URP schemes will choke such apps.
>
> But I think folks should be able to start using them immediately
> with few, if any, concerns of that sort.

For those using Java-based parsers, I'd be interested to know if my
generalised URI resolver library handles these without modification. If
not, what additions should I make to help that process out:

http://www.vlc.com.au/urilib/

Latest updates are not in pre-compiled form, will need CVS for that.

--
Justin Couch                         http://www.vlc.com.au/~justin/
Freelance Java Consultant                  http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------

---

From: Patrick Stickler <[email-masked]>
Date: Sat, 19 Jan 2002 13:01:38 +0200

It's important IMO to note that it is particularly such applications
such as this urilib which require the classical view of URI Classification.

If an application such as the urilib resolver cannot differentiate
URIs based on scheme, and schemes based on classification as URL, URN,
URP, etc. then it does not know if it should try to resolve a URI, and
if so, how (by some protocol agent or some global mapping mechanism).

Patrick

--

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

---

From: Justin Couch <[email-masked]>
Date: Sat, 19 Jan 2002 23:04:12 +1100

> if so, how (by some protocol agent or some global mapping mechanism).

Internally the urilib does not care, it resolves everything according to
the URI DDDS mechanisms. It is only if you use the derived classes of
URL and URN do you notice at the application level any difference. The
URN class is coded to look for the "urn:" prefix, so that would be of no
use to you.

When using the URL class, it will strip the URI and look for the
protocol part and then dynamically load an appropriate protocol handler
for it. However, you don't need to do that either as you can perform the
standard transformations such as I2C, I2Ns etc. Scheme and protocol are
treated theoretically the same in this case. If you created a URL object
using "hrn:" as the start of the string, I think it would pass through
the system unnoticed (assuming you wrote the right resource-resolver
implementation).

Alternatively, you could extend the URI base class to create a HRN class
and do any extra bits yourself. I'm not sure how well that would fare,
but first pass approximation should not be that hard to do. Maybe some
of the trickier semantics internally would be where you fall over. eg,
does the HRN have the equivalent to a L2N transformation?

---

From: Patrick Stickler <[email-masked]>
Date: Sun, 20 Jan 2002 18:29:31 +0200

On 2002-01-19 14:04, "ext Justin Couch" <[email-masked]> wrote:

> ... The
> URN class is coded to look for the "urn:" prefix,

But not all URNs are 'urn:'s.

'hrn:'s are also URNs.

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

Furthermore, it seems much more efficient and reliable to
define the class of the scheme rather than manually define
the class of each URI instance.

I.e., define once that 'http:' URIs are URLs and 'urn:' URIs
are URLs, and interpret all URIs based on those formal
classifications.

Eh?

Patrick

--

---

From: Michael Mealling <[email-masked]>
Date: Sun, 20 Jan 2002 12:00:28 -0500

> But not all URNs are 'urn:'s.

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

> But you wouldn't do that, since an 'hrn:' is not a URL, it

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.

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

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Patrick Stickler <[email-masked]>
Date: Sun, 20 Jan 2002 20:13:38 +0200

> arguments that in the end wouldn't have changed much anyway...

Interesting....   so you propose a monopoly on indirect identifier schemes?

What about folks who need or want a hierarchical URN scheme? 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...

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

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

> that for a long time and in the end I realized it just wasn't worth the

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.

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.

And when I assert that 'hrn:' is a URN scheme, that assertion is valid,
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).

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

E.g. see attachment...

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Sun, 20 Jan 2002 20:27:52 +0200

On 2002-01-20 20:13, "ext Patrick Stickler" <[email-masked]>
wrote:

> ... surely I don't need to enumerate all of the

Sorry. Typo. that should have been 'urn:'.
                                      ^

Hopefully it was obvious ;-)

Patrick

--

---

From: Michael Mealling <[email-masked]>
Date: Sun, 20 Jan 2002 13:31:07 -0500

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

> 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

'uri:'?

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?

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

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

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

> such RDF schemas as the mechanism for formal application of such

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

-MM

---

From: Patrick Stickler <[email-masked]>
Date: Mon, 21 Jan 2002 08:50:29 +0200

> universal isn't very productive...

But your trying to assert the opposite. That there is no such thing
as a URN other than a 'urn:'.

The characteristics of a URN scheme are clear enough. If a URI
scheme has those characteristics then it is fair to call it
a URN.

Honestly, I find the contemporary view very "backwards" in terms
of "contemporary" object oriented engineering which attempts to
capture and reuse generalities wherever possible.

Having no formal taxonomy of URI schemes imposes extra burden
on applications which must interpret URIs.

> don't call it a URN since that name is already taken for a different

I disagree. A "clarification" from the W3C does not constitute
the dissolution of the relevant RFC's IMO, and unless you can
justify that the use of a formal taxonomy has a negative impact
to *applications* I see no valid reason for precluding its use.

> Fine. I don't agree with some of yours. The question is: how are

Well, I don't intend to win my point by argument (alone). My
present work in the are of metadata driven systems and semantic
web applications (which make use of URPs, URTs, URVs, and of
course, URNs and URLs) should sufficiently demonstrate the need
and validity of a formal URI class taxonomy.

All in good time...

>> namely 'urn:', fine, but they are *not* the same thing.

Sorry, but I don't get that from *any* of the official publications of
either the W3C or IETF (and I've been reading carefully). Perhaps you
or a group of folks in some discussion list say so, but from what I can
tell, URN and 'urn:' are not considered the same thing.

It is true that the recent W3C clarification appears to assert that there
is one and only one URN scheme, 'urn:', and from that, one may consider
the two synonymous -- but only if one agrees with such an assertion
(I certainly don't, and it appears that alot of other folks also don't).

> then fine. But please don't re-use old ones. Its to confusing and raises

I'm not using any new terms. I'm using the terms as they have been defined.

I *am* of course, using them as defined by the classical view, and even
to a certain extent compatable with my understanding of the contemporary
view.

It seems that there is a third view -- the "absolutist view" ;-) which
does not recognize the terms URN or URL at all.

> deprecate the use of the term 'URL' ever since '93.

It may need to try harder ;-)

IMO, and with all due respect to all of the participants of those long
and painful debates that I seem to have missed, the contemporary view
has emerged simply because (a) even though URNs were defined, there was
no standard resolution solution and those that needed them were a very
small minority of web users and (b) 'http:' URLs were highly visible and
taken by the majority of web users to be synonymous with URIs and
when folks needed URIs for non-digital or abstract resources, they used
'http:' URIs and the (bad) practice became so prolific, that folks
threw up their hands and said "since 'http:' URIs are no longer
consistently URLs, let's forget about the distinction -- missing the whole
point that (1) the distinction is valuable and valid, and (2) bad practice,
however prolific, should not be a basis for architectural design.

Yes, I admit, "them's fightin words" and apologies in advance for all
insult and injury that may result from them, but I think there is much
more than a grain of truth there...  and there's more...

When XML Namespaces came along, folks understandably but inadvisably
began using 'http:' URIs for namespaces -- with the interpretation
and expectation (not specified in the XML NS spec) that the namespace
URI resolve to "something" giving us hacks like RDDL which (albeit
a useful solution for general cataloging of model related information)
misses the whole point that a namespace does not equate to either a
vocabulary or a single schema but is nothing but punctuation; and
further served to encourage the mis-interpretation of namespace URIs.
Had there been valid URT schemes in place when XML NS came, and had they
been used in the XML NS examples, we would have avoided *alot* of confusion
and the differences between namespace, vocabulary, content model, and
schema would be clearer and more widely understood.

Now, all of that mess was still something the Web could live with, but...

The SW, however, changes things quite a bit. Now there is a significant
need for globally unique identifiers denoting abstract concepts and
the difference between a 'thing' and some representation of that 'thing'
that is web accessible becomes acute. And of course, we've needed URT
schemes all along for our DTDs, XML Schemas, RDF Schemas, etc. And
applications neeed to know if an identifier denotes a web resource or
some other, non-accessible (non-digital or abstract) resource, and
that requires knowledge about the URI schemes.

Furthermore, online publishing and media distribution is beginning to
come of age, and the need for URNs is growing with it. Surely folks
at the IETF have noted a increase in the demand for registered 'urn:'
namespaces? Hence the recent streamlining?

Thus there is growing need for applications to be able to organize
and interpret URIs according to scheme specific semantics, and
there are numerous schemes with major, functional intersections
of semantics which would beg for a taxonomy of schemes, thus the
classical view is becoming a necessity.

(and just so folks know where I'm coming from, in addition to being
active in the RDF and SW communities, and a member of the W3C RDF Core
WG, I am also a member of both the Metadata and Identifiers working
groups of the Open eBook Forum, the leading standard for ePublications,
and also am the chief architect of Nokia's documentation and digital
resource management solutions, managing several million pages of
complex technical, procedural, and user documentation, so my views
are based on long, hard experience, and are not just so much arm waving
and armchair philosophising)

All in all, I think that the contemporary view does not serve the
needs of the emerging semantic web and that if 'http:' (mis)use is set
aside, out of the picture, it becomes very hard to justify the
disposal of the URL, URN, etc. distinctions, and the extended classes
URP, URT, and URV reflect distinctions needed by the SW and KM
communities for some time.

Oh, and by the way...   ;-) ;-) ;-)

> for your terms than most here would...

And where precisely is "here"?  Planet Earth? IETF? W3C? The URN list?
The URI list?

> talking about URI classes _in general_ is a useless endeavor and _in general_

What's interesting is that, while I've always understood the W3C
clarification as being a clarification of the *views* -- a tour of
the classical and contemporary views and what each one asserts or
presumes -- the folks who were involved in writing it seem to
think that it rather is a mandate for adoption of the contemporary
view. I.e. that the interpretation and understanding of the document
requires alot of reading between the lines or familiarity with the
discussions of the past.

Furthermore, I consider the choice of terms "contemporary" and
"classical" as politically biased, such that if one does not
subscribe to the "contemporary" view, one is behind the times and
not "with it".

It says nothing specific to application designers about what
the two views mean -- apart from a single mention of the word
"formal", which implies that per the contemporary view, URI
classes have no formal definition that an application could
make use of. If not for implementors, then who is the document
intended for?

And, contrary to what you assert above, it does not IMO say that
it is either unproductive nor unadvisable or incorrect to speak
in terms of URI classes or to assign classifications to URI schems.

As far as "clarifications" go, it's not very clear.

> Fine. But don't start out by attempting to redefine how URIs work.

And why the heck not? If ever there was something in need of standardized
definition, it is URI classification. As I've said before, URIs are the
heart and soul of both the Web and the Semantic Web, so while it is
clearly a challenge, we do need to agree about them.

And my extended taxonomy is based on foundational RFCs which, as far as
I am aware, are still valid and authoritative (to the extent that any
RFC is authoritative).

Again, if the IETF or W3C wishes to "kill" URI classes once and for all,
then rewrite the RFCs or publish new ones that supercede and deprecate
the current ones.

"Clarifications" that have multiple interpretations just won't do.

As for me, whether or not it remains a standard, I will continue to
hold the classicial view and utilize formal definitions of URI classes,
and avoid misusing 'http:' URLs as URNs or URTs.

Regards,

Patrick

--