RE: What is at the end of the namespace?

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 15 November, 2001 17:55
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-talk@w3.org; uri@w3.org
> Subject: Re: What is at the end of the namespace?
> 
> 
> > Assertion 1: Mammals may have either no legs, two legs
> > or four legs.
> > Assertion 2: Dogs may have either no legs, two legs or
> >              four legs, because mammals may have either no
> >              legs, two legs or four legs.
> >
> > and totally misses the fact that
> >
> > Assertion 3: Dogs have four legs.
> 
> Close, but no cigar. For a start, your comparison this time assumes
> that subsets of URIs (URIs with a certain scheme) must have a set
> number of legs... er, i.e. they necessarily denote a non-equivalent
> subset of the whole set of resources that URIs can denote. If that
> were true, it would be pointless to continue with a "tag:" or
> "urn:pts:" style scheme/NID, because those are meant to be able to
> denote anything.

No. You missed my point. You seem to be arguing that a specific
URI scheme can not *itself* constrain its use to a subset of URI
applications, and I'm arguing that it can, and that the HTTP URI
specification *does*.

> Nothwithstanding that, you're still really missing what I'm saying.
> I'll lay the facts out sequentially, so that you can just stop me
> where I'm wrong:-
> 
> * The URI specification says that the definition of a resource is
> "anything which has identity"
> * When creating a new scheme, it is possible to come up with one which
> can denote "anything which has identity"
> * Unless a scheme's documentation says that those URIs necessarily
> denote a subset of resources, they don't
> 
> That's it. 

I don't disagree with any of the above.

But I assert that the HTTP URI scheme *does* define such a subset
in the language of the specification and inherited from the
semantics and purpose of the HTTP protocol.

> This is turning into a bizarre argument, because in the
> words of a man whom I greatly admire:-
> 
> [[[
> I feel like I've been in the Twilight Zone where every word I use no
> longer holds its meaning and every time I write "green" folks read
> "blue", and the frustration has been significant.
> ]]]

;-)

> All I want you to do is point me to a bit of verbiage in an RFC which
> says "thou shalt use HTTP URIs to identify chunks of data only", and
> I'll go "fair enough, I accept that now".

See my recent response to Roy, repeated here:

---

>
> > The HTTP
> > specification
> > can only talk about those aspects of the protocol that are relevant to
> > HTTP.
>
> 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.

---

I think that sums it up. I can go and cut and paste stuff from
the RFC's if you like, but not just now... gotta run and fetch
the kids...

> [...]
> > They are using them, because that's *all* there is to use.
> >
> > Show me one, single, solitary URI scheme provided or
> > promoted by either the IETF or W3C for denoting abstract
> > concepts *only*.
> 
> Register an informal NID. It takes two, maybe three weeks to do so,
> and then you have a set of persistent identifers forever. The
> registration process could not be all that simpler, and you get to
> decide what they denote.

That's only good if (a) you are registering a URN namespace, and
(b) your namespace is not a hierarchical path based URI

Nope. I'll be going the full URI route.

> But we're pressing through "tag:" as such a URI scheme, and it's quite
> far down the recommendation track. 

Great. I may ask you for a roadmap ;-)

> We'll just have to be patient, and
> I know that it's very difficult... but we don't have much of a choice.

In that we are agreed.

Cheers,

Patrick

Received on Friday, 16 November 2001 09:41:50 UTC