 |
 |
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:[log in to unmask]] > Sent: 06 November, 2001 20:16 > To: Stickler Patrick (NRC/Tampere) > Cc: [log in to unmask] > 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: [log in to unmask]