Re: [POLL] What is at the end of the namespace?

Right on, Patrick ... let's get this straightened out !!

Seth Russell

----- Original Message ----- 
From: <Patrick.Stickler@nokia.com>
To: <www-talk@w3.org>
Cc: <danbri@w3.org>; <sean@mysterylights.com>
Sent: Wednesday, November 07, 2001 9:46 AM
Subject: RE: [POLL] What is at the end of the namespace?


> 
> 
> > -----Original Message-----
> > From: ext Dan Brickley [mailto:danbri@W3.ORG]
> > Sent: 07 November, 2001 14:44
> > To: DC-ARCHITECTURE@JISCMAIL.AC.UK
> > Subject: Re: [POLL] What is at the end of the namespace?
> > 
> > 
> > You're not crazy, 
> 
> Some may disagree with you there ;-)
> 
> > just 5 years late 
> 
> That's almost certainly true ;-)  
> 
> Though maybe not *too* late...
> 
> > (and wrong ;-)
> 
> That also may be true, but I don't think so...
>  
> > www-talk@w3.org might be a better home for URIs and HTTP etc 
> > questions.
> 
> Agreed. I've redirected the thread there. For better or worse...
>  
> > dan
> 
> Cheers,
> 
> Patrick
> 
> --
>                
> Patrick Stickler              Phone: +358 50 483 9453
> Senior Research Scientist     Fax:   +358 7180 35409
> Nokia Research Center         Email: patrick.stickler@nokia.com
> 
> 
> > On Wed, 7 Nov 2001, Patrick Stickler wrote:
> > 
> > > Hi Sean,
> > >
> > > I guess this means I've been getting all crazy again ;-)
> > >
> > > I propose that we take this discussion elsewhere, so I won't
> > > be CC'ing further responses to the list...  promise ;-)
> > >
> > > > -----Original Message-----
> > > > From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> > > > Sent: 06 November, 2001 20:16
> > > > To: Stickler Patrick (NRC/Tampere)
> > > > Cc: DC-ARCHITECTURE@JISCMAIL.AC.UK
> > > > Subject: Re: [POLL] What is at the end of the namespace?
> > > >
> > > >
> > > > > Meaning that folks are defining URLs which are never intended
> > > > > *ever* to actually resolve to anything to represent 
> > either abstract
> > > > > concepts, [...]
> > > >
> > > > Which in theory is perfectly fine; it just confuses people
> > > > because on a
> > > > practical level, they have been working with the notion 
> > of "URLs are
> > > > recipies for getting files" for so long. Let it go.
> > >
> > > Sorry, I just don't agree. To define e.g. an 'http:' URL which
> > > is never intended to resolve to anything is IMO contrary to the
> > > defined semantics for such URLs and thus bad practice. Anytime
> > > you deviate from the intended purpose of a mechanism you will
> > > breed confusion.
> > >
> > > Gee, how about if I start minting bogus 'mailto:' URLs to identify
> > > abstract things and laugh at people as their emails bounce when
> > > they try to send questions to those bogus email addresses, 
> > or perhaps
> > > a few 'ftp:' URLs that don't equate to any real space on the server
> > > or even better, on a password protected server that will keep folks
> > > wondering "what's in there...".
> > >
> > > Sorry, URLs are meant to resolve. Even if I let go of the term "URL"
> > > I could just as validly say that 'http:' URIs are meant to resolve,
> > > therefore intentionally minting 'http:' URIs that are never meant
> > > to resolve is wrong. Just plain wrong. And folks have a right to
> > > complain about the confusion that such bad practices generate.
> > >
> > > There was the argument made here by Aaron that we should 
> > try to capture
> > > common social behavior on the net in our standards. Great. Let's
> > > use this as an example case. Common behavior is to expect that
> > > 'http:' URIs resolve to web resources of some sort. So don't make
> > > bogus 'http:' URIs which denote abstract concepts that have no
> > > web realization. Such as, hey, just about every darn XML and RDF
> > > vocabulary on the planet...  but you can't blame the common folks
> > > for following the bad practices of others who should know better.
> > >
> > > To be fair, we're all just stumbling along in a new frontier,
> > > but let's keep our eyes on the horizon a bit more and not at our
> > > feet, eh? HTML and HTTP URLs have given birth to the web, but also
> > > have warped its development.
> > >
> > > IMO, the IETF/W3C really dropped the ball with regards to 
> > facilitating
> > > the definition of URI schemes optimal for the denotation of abstract
> > > concepts and vocabularies, and the current "There's no such thing as
> > > URL or URN, only URI" nonsense seems just spin to make the 
> > mess seem less
> > > than it is. IMO the IETF/W3C should be a bit embarrased. 
> > They blew it.
> > > And yes, "them's fightin words", but there, I've said it ;-)
> > >
> > > (and yes, this is almost surely not the forum to say it in, 
> > apologies)
> > >
> > > And I'm not just complaining. I'm also working to try to 
> > help clean up
> > > the mess, for the sake future web generations. Stay tuned 
> > to your local
> > > IETF I-D server...
> > >
> > > > > [...] or as indirect identifiers for web resources (i.e. URNs).
> > > >
> > > > How are URNs "indirect identifiers for web resources?". I 
> > believe that
> > > > you're getting hopelessly muddled here: URLs and URNs are 
> > no longer
> > > > considered disjoint spaces of "these are addresses, these are
> > > > names". The
> > > > distinction now is merely "this is an out of date term
> > > > ascribed to certain
> > > > URIs that have fasionable protocols associated with them" and
> > > > "these are
> > > > URIs that start with 'urn:'", respectively.
> > >
> > > Interesting that you think so, as I've read and re-read the recent
> > > "clarification" and I don't get that. I think you're reading into
> > > it something that it doesn't say.
> > >
> > > It merely says that the terms "URL" and "URN" are not *formal*
> > > meaning that a given system need not know what they mean. But
> > > they still are valid terms for classifying URI schemes according
> > > to shared behavior, and URI schemes themselves still embody
> > > the qualities of 'location' or 'name', etc.
> > >
> > > And to be honest, the lack of a *formal* taxonomy of URI schemes
> > > is a pity. I think that one is sorely needed.
> > >
> > > > > The lack of specific URI types for denoting abstract concepts
> > > > > and entities, and the use of URLs rather than "proper" URNs
> > > > > for location-independent indirect identifiers is a big problem.
> > > >
> > > > The only real "problem" is one of URL assignment and
> > > > persistence, but there
> > > > is also an advantage in that delegation of authority is very
> > > > clear, and has
> > > > been proven to work for many years now.
> > >
> > > Ahh, no problem. We can use that delegation authority as well
> > > for other classes of URIs, not just URLs. URLs have the common
> > > characteristic that they are associated with protocols which
> > > provide *access* to web resources. They do not provide a means
> > > to denote abstract entities which have no web realization.
> > >
> > > > > And one in fact that I'm working on trying to address, and will
> > > > > be submitting several I-D's to that end very shortly.
> > > >
> > > > Like "tag:" and "urn:pts:"? :-)
> > >
> > > Yes. Exactly. And others like 'em.
> > >
> > > But folks saying, "Go ahead, use 'http:' URLs for everything"
> > > seems short sighted and irresponsible to me.
> > >
> > > Hey, I can make URLs work, sure, and I can also cook hot
> > > dogs on the engine of my car... but should we park a car
> > > in the kitchen of a restaurant to cook on?  Nope.
> > >
> > > > Your results will hopefully
> > > > be useful, but
> > > > I'm really not convinced about the validity of your motive.
> > >
> > > My motives are pure. Really. I'll send you a photo of me
> > > in my white hat ;-)
> > >
> > > > You're in effect saying that Dublin Core shouldn't use URLs
> > > > to identify
> > > > abstract concepts, that to do so kinda works, but is not
> > > > architecturally
> > > > sound, and alternatives should be sought... I would suggest
> > > > that this is a
> > > > slightly contentious point of view, and I do not believe that
> > > > DCMI should
> > > > be at all concerned, and nor should the rest of the world.
> > >
> > > Obviously, I'm not advocating any sudden change to how DCMI,
> > > or anyone, currently defines their models and ontologies.
> > > But a gradual move towards a better way of doing things is
> > > reasonable to hope for.
> > >
> > > This discussion arose concerning what to put "at the end" of
> > > a namespace URI, and the very fact that such a question could
> > > arise, shows that things are rather messed up in the are of
> > > URI methodologies and taxonomic classification (or total lack
> > > thereof).
> > >
> > > And I responded to that question by saying "nothing" because
> > > a namespace URI does not resolve, even if it *is* a URL, and
> > > to put something there is to add to the confusion. The reality
> > > is that vocabularies should be defined by non-URL URIs. Yet
> > > of course we can't blame folks for using URLs. That's all there
> > > is to choose from -- insofar as common perception is concerned.
> > >
> > > So, no, I'm not saying DCMI should rewrite all their schemas,
> > > etc. but in this particular case, that of namespace resolution,
> > > they do have the opportunity to "do the right thing" which is
> > > to do nothing. And that's what I'm suggesting they do.
> > >
> > > > N.B. There's no point in playing the pragmatism card again:
> > > > URLs clearly
> > > > work :-)
> > >
> > > Right. To heck with progress, eh? Where did I put my abacus?
> > >
> > > And in case I didn't add enough of these above...
> > >
> > >  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)
> > >
> > > 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 Wednesday, 7 November 2001 13:18:43 UTC