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

FWIW I'm with David on this one. The rdf-mt example shows that you
can't tell what the resource is by looking at a representation; you
have to look elsewhere. I would like this group to pave the way for a
future in which there is lots of information 'elsewhere' about
resources for which 200s are given. For example, nose-following (e.g.
Link: header) might lead to RDF that tells you that the dated rdf-mt
is [promised to be] stable (for some documented definition of
'stable') while the undated one isn't, or that the dated one is a
snapshot of the undated one.

Jonathan

On Mon, May 17, 2010 at 4:37 PM, David Booth <david@dbooth.org> wrote:
> 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 Friday, 21 May 2010 19:09:23 UTC