RE: What is at the end of the namespace?

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

How about a response such as "Retrieve *that*?, are you out of your mind?!"
such as an HTTP URL for the abstract concept of 'INSANE'.

I.e., those responses are based on the *expectation* that the resource
is a web resource that is *retrievable* (or accessible, or dereferencable,
or pick your favorite word).
 
> 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, 

Never said they were. 

> and it's not helping your case to
> back up your assertion by noting the properties of an unrelated URI
> scheme. 

You might want to try reading more slowly... ;-)

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

No, HTTP URIs denote *web* resources. There's a difference ;-)

> [SNIP]
 
> > [...] 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 it's those software vendors that will care about an explicit
taxonomy and use it. "People" shouldn't even necessarily see most
URIs. "People" need not understand about URIs. "People" are not the
ones to decide whether an explicit URI taxonomy is necessary or not.

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

Exactly. I empathize with all of those motivations, and share many
of them. The biggest problem with using HTTP URIs for abstract
concepts or for indirect idenifiers (e.g. URNs) is that "People"
get gonzo confused when some HTTP daemon doesn't resolve it to
"something". Hence, all the folks trying to find stuff from
XML namespace URIs and "hacks" (sorry for the derogatory
connotation there) like RDDL which, while being a great idea
overall, and may very well be part of the long term solution,
are tied to the wrong vehicle (namespace URLs), and further 
propagate misunderstandings about what URIs (not URLs) are
and what to expect from different URI schemes.

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

Agreed. Though I think that a good URI scheme will partly sell
itself.

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

Rant *with* me, not at me ;-)

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 Monday, 12 November 2001 16:59:00 UTC