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

Well, I agree about two things with you there:-

* The wording in the RFCs for URIs and HTTP is not as clear about
these issues as it could have been. I accept Roy's plea that in a
networking group, you have to discuss networking stuff, but I think
that a short philisophical treatise is a good basis on which to build
any networking specification. Rationale and guidance in those areas
may have been able to avoid a substantial portion of the mess that has
been created. For example, if the one line "the set of resources that
HTTP URIs may identify are wholly equivalent to those that any URI may
identify" had been added, then although you wouldn't have liked it, at
least the point would have been achingly clear.
* Picking up your kids is much more important than messing about on
mailing lists.

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; and yet people love to read
all sorts of things into sentences like the above. 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], and as Roy and Mark have been discussing for quite a while now
with the REST architecture [2]. HTTP is a tremendous utility, but it
is only a method of getting representations of resources back through
a distributed network system. That is why the HTTP specification says
(of a 200 OK response code):-

[[[
   The request has succeeded. The information returned
   with the response is dependent on the method used in
   the request, for example:

   GET    an entity corresponding to the requested resource
          is sent in the response;
]]] - RFC 2616

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. It also confuses me a bit that people don't
accept that representations of resources can be resources themselves,
and that what is identified to the public does change with context.
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. 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. 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. 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 (as long as the
latter is "RESTful"), and they are starting to work quite nicely.

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

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.

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

Ask Tim Kindberg, and/or Sandro Hawke. I'm sure that they're
listening.

[1]
http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model
[2] http://conveyor.com/RESTwiki

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

Received on Friday, 16 November 2001 11:35:43 UTC