RE: What is at the end of the namespace?

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 16 November, 2001 18:34
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-talk@w3.org; uri@w3.org
> Subject: Re: What is at the end of the namespace?
> 
> 
> > > You've just summed up, IMO, the whole issue in a nutshell.
> > > The HTTP URI is relevant only to the semantics of the HTTP
> > > protocol. And the HTTP protocol is for *access* of concrete
> > > web resources. Thus HTTP URIs are only intended to be
> > > meaningful to processes based on the HTTP protocol, which
> > > expect to *return* something. Therefore HTTP URIs are not
> > > intended to denote abstract concepts.
> >
> ...
>
> But the RFCs are at least carefully worded:-
> 
> [[[
>    The "http" scheme is used to locate network resources via the HTTP
>    protocol.
> ]]] - RFC 2616
> 
> Well, it is. But that's all that is said; 

Yes. That's *all* that is said. Everything else is a non-standard
extension.

> and yet people love to read
> all sorts of things into sentences like the above. 

Yes, but there is a limit to "interpretation". The assertion that
an HTTP URI does not need to resolve to "something" crosses the line
of reasonable interpretation, IMO.

> You wrote "The HTTP
> URI is relevant only to the semantics of the HTTP protocol", but those
> "semantics" are incredibly broad, as Mark demonstrated with his note
> [1], 

Yet, no matter how broad, they have to do with *providing access to data*.

> It does not say that the resource is sent back. When I do an HTTP GET
> request on an abstract concept, I should hopefully get an entity
> corresponding to the requested resource sent back. I've never been all
> that happy intuitively with that notion, but it works, quite clearly,
> because the Web works. 

But now you are arguing against your previous assertion, that HTTP URIs
need not resolve to anything. If they don't, then a 401 error (or
similar) is a completely acceptable response. It does not denote an error,
per se.

> It also confuses me a bit that people don't
> accept that representations of resources can be resources themselves,

They can't if you wish to make statements about both.

What you are saying is that it is reasonable to make statements
such as:

   <rdf:Description rdf:about="mailto:patrick.stickler@nokia.com">
      <foo:hasEmailAddress rdf:resource="mailto:patrick.stickler@nokia.com">
   </rdf:Description>

   <rdf:Description rdf:about="mailto:patrick.stickler@nokia.com">
      <bar:isInDomain>nokia.com<bar:isInDomain>
   </rdf:Description>

Now, which statement is about *me* and which is about my email address?
And how do I know the difference? And is the email address of myself
me, or my email address? And am *I* in the domain nokia.com, or is
my email address?

> You can't just slam the door shut on the way in which HTTP URIs are
> used by millions of people around the world, but likewise, you can't
> restrict some sound Web architecture on fantastical myths that have
> very little sound basis whatsoever. 

Are they fantastical because you don't subscribe to them?

> If HTTP URIs really did just
> denote some bits of data floating about on Web servers, then the Web
> would not be portioning out excitement about XML and RDF ten years or
> more after it had been initially designed. 

Hold on now. Back up. If you leave out the 'HTTP' above, then I agree.

Just because folks are able to hack together systems using HTTP URIs
to denote abstract concepts, or which serve the purpose of URNs by
always redirecting to some other location, and get those systems
to work does not prove your point that HTTP URIs are the mechanism
of choice for all of those uses.

> Being able to click in a
> link in a browser and get some data back from halfway around the world
> instantly was a really neat idea, but after ten years, we need
> something else to talk about. 

Seems we've got that ;-)

> Identifying other crud with HTTP URIs,
> and then talking about it, 
> or using HTTP URIs to uniquely name sets of
> XML elements and attributes, or using it as the contact points for RPC
> over the Web all seem like excellent ideas to me

Or identifying other crud with URIs
or using URIs to uniquely name sets of
XML elements and attributes, or using it 
as the contact points for RPC
over the Web 

... also seem like excellent ideas to me.

I'm sorry Sean but you (and others) seem to be incapable of
imagining a web which does what you want it to do without
using HTTP URIs for everything.

I've never argued that you *can't* use HTTP URIs to denote
abstract or non-web-accessible resources, only that you 
*shouldn't* because the semantic distinctions are useful
and when you blur those distinctions you breed confusion,
not only for humans but also for software applications
which need to make decisions about URIs.

The class and scheme of a URI is an (in)valuable source
of information, and using HTTP URIs for everything is just
plain sloppy. Yes, you can make it work, but that doesn't
mean that's the optimal way to do it.

The continuous confusion and debate about URL vs. URN, or
should namespaces point to "something", etc. etc. are the
evidence that the *masses* are confused, and that confusion
is due to blurring the semantics of HTTP URIs, which should
give folks half a clue that something is not quite right
with that practice.

> Oh dear, so we're going to extend this discussion to what URNs can
> identify, are we? A new URN scheme can identify anything! Just as a
> new URI scheme can.

As I said above, there is a difference between "can" and "should".

See my matrix analysis of URL vs URN vs URP in 

http://lists.w3.org/Archives/Public/www-talk/2001NovDec/0059.html

 
Patrick

Received on Monday, 19 November 2001 06:59:25 UTC