Re: [pedantic-web] Re: The OWL Ontology URI

On Fri, 2010-05-14 at 16:17 -0500, Pat Hayes wrote:
[ . . . ]
> Now, I guess that one could have the very same 'thing' be both a  
> resource in its own right and also be part of a content-negotiated  
> bundle, with a different URI which accesses the content negotiation  
> process. 

Yes, and that is the recommended practice: one URI for the generic thing
and one for each specific version / language / media type / whatever.

> I have a worry with this, however, as it seems to drive a  
> truck through the purpose of httpRange14, since it means there is then  
> no way, given a URI which yields a 200 level response, to figure out  
> what it denotes. 

It denotes the particular w:InformationResource that the URI denotes and
whose representation you just obtained in the 200 response.  If you want
to know more about it you might look at the content of the response for
clues or ask the owner or someone else you trust.  

This is no different than with use of the conventional web.  For
example, if you dereference http://www.nytimes.com/ you might notice
that the content returned looks an awful lot like today's front page
(web version) of the New York Times.  But unless you had some additional
information, such as looking up the domain registration to discover that
the URI is owned by the New York Times, or believing me when I say "the
URI for the New York Times online is http://www.nytimes.com/ ", you may
not know for certain.  Furthermore, if you only use it once you may not
know that it is the URI for the *current* front page, which changes
daily -- not merely the URI for the 17-May-2010 front page.  But you
soon figure that out by noticing that it changes each day or having
somebody tell you.  

> Which I thought was the whole point.  (Maybe my  
> interpretation of that ruling is too narrow. Though if so, I really  
> cannot see what the point of the ruling is.) So if someone urges this  
> idea, let me ask them: what specifies that one URI A denotes the  
> concrete resource (eg the RDF/XML document) and that the other URI B  
> denotes a more abstract entity which can provide different  
> representations based on content negotiation, when both of these URIs  
> send back identical 200-coded responses to a GET? How is the 'naming'  
> done?

Without other information you may not know.  This is not much different
from other situations in which you cannot determine the relationship
between URIs unless someone tells you, such as whether X and Y denote
the same resource.

As a similar example, the HTTP response itself does not tell you that
http://www.w3.org/TR/rdf-mt/
is the URI for the generic "current" RDF Semantics document, while
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ 
is the URI for a specific version, even though they both return a 200
response with identical content.  But the beginning of the document
tells you:
[[
This Version:
        http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
Latest Version:
        http://www.w3.org/TR/rdf-mt/
]]

Actually, in the case of content negotiation the HTTP response *should*
give you some help, because the "Content-Location:" header can be used
to indicate the URI of the specific variant that was returned, as
RFC2616 explains:
[[
14.14 Content-Location

   The Content-Location entity-header field MAY be used to supply the
   resource location for the entity enclosed in the message when that
   entity is accessible from a location separate from the requested
   resource's URI. A server SHOULD provide a Content-Location for the
   variant corresponding to the response entity; especially in the case
   where a resource has multiple entities associated with it, and those
   entities actually have separate locations by which they might be
   individually accessed, the server SHOULD provide a Content-Location
   for the particular variant which is returned.

       Content-Location = "Content-Location" ":"
                         ( absoluteURI | relativeURI )

   The value of Content-Location also defines the base URI for the
   entity.

   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular entity at the time of the request.
   Future requests MAY specify the Content-Location URI as the request-
   URI if the desire is to identify the source of that particular
   entity.
]]




-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Monday, 17 May 2010 20:37:37 UTC