RE: What is at the end of the namespace?

On Fri, 16 Nov 2001 Patrick.Stickler@nokia.com wrote:

>
>
> > -----Original Message-----
> > From: ext Dan Brickley [mailto:danbri@w3.org]
> > Sent: 16 November, 2001 16:14
> > To: Stickler Patrick (NRC/Tampere)
> > Cc: fielding@eBuilt.com; a.powell@ukoln.ac.uk; www-talk@w3.org;
> > uri@w3.org
> > Subject: RE: What is at the end of the namespace?
> >
> >
> > On Fri, 16 Nov 2001 Patrick.Stickler@nokia.com wrote:
> >
> > >
> > > > 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.
> >
> > SOAP Web Service endpoints can be named with http:* URIs, and
> > communicated
> > with via XML representations shipped over HTTP. But you can't
> > download the
> > service itself; that wouldn't make sense.
>
> I would argue that the HTTP URI in that case does not denote the
> service, but a description of the service, if dereferencing
> the URI provides the SOAP instance.

It doesn't. SOAP doesn't have 'instances'; its a protocol layered over
HTTP for talking to services using SOAP-ese XML messages.

> Of course, there's a gray zone there. Does a CGI HTTP URI denote
> the service provided by the CGI application or the application
> itself, or just one access portal to that application (or service).
> Still, its a web-resource, and so it is reasonable to denote it
> with an HTTP URI.
>
> > When you think of
> > HTTP as a way
> > of talking to some (possibly authoritative) service about URI-named
> > resources, this whole URI thing makes a bit more sense. If
> > you think of it
> > as a glorified form of file-sharing (like NFS, Samba etc) URIs for
> > abstractions seem odd.
>
> Exactly. HTTP URIs for abstractions seem odd. HTTP defines, like
> you say, a global filesystem of sorts. HTTP URIs denote real
> and accessible resources stored in that global filesystem.

I didn't say HTTP is a global filesystem, I said that if you think of it
that way (a mistake, btw), you'll end up disliking the URI design.

> To use an HTTP URI to denote an abstract concept, such as
> "LOVE" or an ontological term, or a non-web resource such
> such as "The city of Paris" is quite odd. I fully agree.


I'm using...

http://xmlns.com/wordnet/1.6/Love
and
http://xmlns.com/wordnet/1.6/Paris

...and have rigged the Web to respond with RDF/XML representations of
those ontological categories should someone ask about them using HTTP GET.

Its a slippery slope from HTTP's innate content negotiation mechanism,
which provides us the ability to give an abstract intellectual work (eg.
an image) a Web name (URI) distinct from its various (content negotiable)
renderings. Why is the notion of an image (eg. the W3C logo) appropriately
less 'abstract' than the two notions you mention above?  Images and
concepts and services have representations that can be transmitted via
HTTP. One might make the case that a representation of an image can tell
you, in some bag-of-bytes, everything needed about that image. But that
distinction breaks down when you consider URIs for services, which usually
expose only partial representations.

Dan


-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Friday, 16 November 2001 09:55:08 UTC