Re: Some recent Internet Drafts relating to URIs

On 2002-01-20 20:31, "ext Michael Mealling" <michael@neonym.net> wrote:

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

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.

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

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
> we going to get along?

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

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

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

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

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

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

And where precisely is "here"?  Planet Earth? IETF? W3C? The URN list?
The URI list?
 
>> 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....

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

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

--
               
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 01:49:35 UTC