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 12:46:04 UTC