Re: What is at the end of the namespace?

Hi Patrick,

> > What more do you want?
>
> Well, for one, the realization that URI != HTTP URL.
>
> Are you really going to tell me that because a *URI*  doesn't
> have to resolve to something that a *HTTP URL* doesn't?

If you'll take the time to read my mail again carefully, you'll find
that I was simply establishing a ground fact about URIs, that in
general they can denote anything which may be identified, and then
asking you to point out where - in any specification - it says once
and for all that HTTP URIs cannot identify "abstract concepts". Since
I have asked and you have not provided (indeed - your "weanie" point
notwithstanding - you cannot), I am not inclined to believe that HTTP
URIs cannot identify abstract concepts.

> You're in URL denial, Sean ;-)

If anyone is in denial here, it is surely you; whatever you say,
Patrick, you can't change the way things are, and when they work just
fine, I don't see why you would want to. Your arguments have always
come across as contentious to me.

People *are* using HTTP URLs to identify abstract concepts. People are
using URI references with absolute HTTP URIs as bases as such; the W3C
is using them as such, everyone in their right minds is using them.
Dublin Core uses URLs to identify concepts such as "creator" and
"identifier". HTTP URIs were designed to meet the utility of
identifying things on the Web and proving an authoritative route to
get a representation of that resource. It is staggering to me that
after years of people using URLs as namespaces (in XML), and URLs and
URI-views of all kinds in RDF, with many working implementations, that
you could deny that HTTP URIs are unfit for the task on practically
any ground other than DNS persistence, or ease of creation [1].

[...]
> And I'll continue to cook weanies on my car engine,
> until someone shows me where it's written that car
> engines are *not* stoves.

Your comparision is a little weak here, because car stoves clearly do
both their "intended" job, and the extra job of cooking decent food
(as long as you know what you're doing). So what if I drive my URIs
and cook food on them?

[...]
> > Ugh, why on Earth do you keep saying that? How are
> > URNs "indirect identifiers"?
>
> As in they don't represent locations, only keys in a global
> dictionary defined by the URN scheme.

Er... who says that they don't? What makes them explicitly different
from HTTP URIs? URNs can quite easily resolve (by network) to a set of
resources; they may even map into HTTP space. Take the series of URNs
that identify the RFCs. You can set your program so that when you
enter:-

   urn:ietf:rfc:2396

You get the URI RFC back. Perhaps you'll do that via. HTTP. Perhaps
you won't. Perhaps you'll do it using a series of different protocols,
or whatever. How do you think HTTP URIs got established? In the same
way: by programming browsers to accept them, and to open up HTTP
connections. The only fundamental difference is that HTTP URIs have
the recipies for opening up the connections and getting the resource
back contained within the string - they have the server address, and
the name of the document in there. That's a useful utility, but all it
says is that "hey, you can try this if you want to get some
authoritative information back about this resource".

[...]
> > They are bound to their resources in exactly the same
> > manner as every other URI. There's nothing special
> > about URNs excapt in the way that the authority to
> > create the binding is delegated.
>
> I completely disagree, and don't even know where
> to begin in response to that. It's so "out there"...

Oh come on Patrick, if you can't present a structured argument against
something that you consider to be so "out there", then why on Earth
are we even bothering to discuss it?

Cheers,

[1] And, of course, PURLs sort out that mess to a great extent.

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

Received on Wednesday, 14 November 2001 18:46:02 UTC