You're not crazy, just 5 years late (and wrong ;-)

[log in to unmask] might be a better home for URIs and HTTP etc questions.

dan

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:[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]
>