Re: What is at the end of the namespace?

Hi Patrick,

I would suggest that perhaps uri@w3.org would be an even more
appropriate forum for this debate? Whatever the case, I'll send this
to www-talk, BCC'ing uri, and you can decide where to follow-up to.

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

No; you are implying that there is a default base of semantics for
HTTP identifiers, that they are intended to resolve to a set of
documents, or somesuch. HTTP makes no such assumption; if you look
through the range of HTTP respose codes, you'll find that there are a
multitude of things that HTTP can say already: here's some
information, it's moved to here, I couldn't find it, you need to be
authenticated, or whatever. HTTP is very extensible, so one could
quite easily conceive of a "here's some information about what you are
looking for" response code in a future version of HTTP. TimBL
mentioned this idea on RDF IG (but I don't have a reference, and I'm
going to be lazy).

The point is that there is no "intention" about what an HTTP URI, or
any other of the so-called "URLs" identify - that is up to the person
who owns the information space under some domain name or IP address.

> Gee, how about if I start minting bogus 'mailto:' URLs [...]

"mailto:" URIs are not HTTP URIs, and it's not helping your case to
back up your assertion by noting the properties of an unrelated URI
scheme. The semantics of "mailto:" are clearly defined as representing
"a mailbox", I agree. HTTP URIs don't necessarily identify anything in
particular; they are much looser.

> I could just as validly say that 'http:' URIs are meant to
> resolve, [...]

HTTP URIs denote a resource. The nature of the discussion that we're
having is whther or not they necessarily identify some subset of
resources, and where this is defined. Until you show me that
definition in a standards track document, or through a resoned
dissertation on common practices, then I will not be given over to the
idea that HTTP URIs can only identify certain resources. This is a
wholly arbitrary restriction you are placing upon HTTP, and I see no
grounds or basis for this at all.

> Common behavior is to expect that 'http:' URIs resolve
> to web resources of some sort.

What you meant to say is that common behaviour is to stick an HTTP URI
into a browser of some sort, and hit "go". That is not the same as
expecting an HTTP URI to resolve to a Web resource. You expect it to
resolve to a Web resource when you stick it in a browser, but beyond
that, you don't know what behaviour a User Agent is going to have.

But that's besides the point... the question of this debate is what
*sort* of resource HTTP URIs are supposed to resolve to, and you seem
to be avoiding addressing that question directly. What do you expect
an HTTP URI to resolve to? Some data? I can argue, as I have done many
times in the past, that the *practicality* of the use of HTTP URIs is
that the binding of the identifier to the resource is acutually
variable depending upon the context. This is an idea that I usually
pitch when talking about persistence, and goes something like this:-

There are various levels of use for HTTP URIs, ranging from the very
large scale through to the small scale:-

   http://example.org/widgets

   * This HTTP URI identifies some path on some server;
      "widgets" on "example.org"
   * This HTTP URI identifies the concept of widgets, example
      use: "it is commonly known that _widgets_ [link] are becoming
      increasingly rare..."
   * This HTTP URI identifies *a* page about widgets, example:
      "see _Fred's page on widgets_ [link]"
   * This HTTP URI identifies *the* page about widgets, example:
      "Fred: 'I like Widgets', Cite: _widgets_ [link]"

You can see that the level of persistence decreases as you go down the
list. As far as we are concerned for this conversation, we can note
that the expectation of what the URI denotes changes as we go down the
list, increasing in specificity at each step. You can tell that all of
these steps (and probably some further steps in between) are valid
uses of HTTP URIs, and I think that it is wrong of you to assert that
HTTP is tied to any one of these. It isn't used that way, and no one
has ever said that you must use it that way. All RDF does is go up the
list instead of down it, and although that disquiets people, it's a
perfectly valid use of HTTP URIs.

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

Of course - but I don't think that anyone is trying to hide that. On
the contrary, I believe that the W3C at least is trying very hard to
clear up the mess; but the field is a mix of opinions (about 5 per URI
expert), and so it's going to take time to resolve. I can't even
discern a clear consensus on the most basic of issues from any of the
"experts".

> And I'm not just complaining. I'm also working to try to help
> clean up the mess, for the sake future web generations.

Join the club :-)

[...]
> And to be honest, the lack of a *formal* taxonomy of URI
> schemes is a pity. I think that one is sorely needed.

The problem with trying to initiate and install a URI taxonomy within
the Web environment at this late stage is that no one is going to
listen, or no one is going to care, or most likely: both. People don't
really want to understand what's going on with URIs and so on when
they're just using them in day-to-day applications, and that's fine...
but the software developers and so on need to be very wary, and it is
evident that there hasn't really been a market for making sure that
URIs are well defined until things like RDF came around.

And of course, it's clear that we do in fact need some decent corpus
devoted to URI usage - we've been arguing amongst ourselves for
a long time now, and often go around in circles.

[...]
> > Like "tag:" and "urn:pts:"? :-)
>
> Yes. Exactly. And others like 'em.

Well, we only really need one. Really, I would like "tag:" to be
registered, but it doesn't seem as if that's going to happen any
time this year, and perhaps not even next year, so my impatience will
probably dictate that I register an informal URN NID. Heck, it
only takes about 3 weeks to push one through, and I'm sure that there
would be very little in the way of resistance, due to the
determination of so many people to have such a scheme.

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

Er...

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

Heh, heh! :-) What I meant is that we both have different reasons for
wanting to have a set of easily creatable URIs for generic
concepts that are not HTTP-URIs. You want then because for some reason
you think that HTTP-URIs-to-identify-concepts suck. I want
them because I don't believe that we should be necessarily tied to
using HTTP URIs to identify concepts, that we should have to pay
for domains to have decent persistent identifers, and that we
shouldn't have to fear having our domains whipped out from underneath
us because we didn't pay the bill, or the registrar screwed up, or
whatever. Ask DanC: it happens, and it's not pretty when it does.

Of course, there's also the point that Roy Fielding raised, which is
that URIs are only persistent when you have a big enough user
base for them. HTTP URIs are good because the entire world uses them,
and it's something that's going to be difficult to address for
"tag:" or whatever. We need to get these URIs going so that we can
start evangelizing them right away; implementing them, and
spreading the word.

[...]
> And in case I didn't add enough of these above...
>
>  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)  ;-)

Same goes, BTW; as usual, it has been a pleasure to rant at you,
Patrick :-)

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Wednesday, 7 November 2001 16:40:03 UTC