Understanding 'Content-Location' header in the IETF HTTPbis draft

Hello everybody,

due my recent thoughts in trying to understand the relationship between 
resources, information resources and documents (see [1]), I also had the 
chance to have a deeper look into the latest IETF HTTPbis draft.
Here are my observation:

"An HTTP request representation, when present, is always associated with 
an anonymous (i.e., unidentified) resource.

    In the common case, an HTTP response is a representation of the
    target resource (see Section 4.3 of [Part1]). However, this is not
    always the case.

    1.  If the response status code is 200 or 203 and the request method 
was GET, the response payload is a representation of the target resource.

    4.  If the response has a Content-Location header field, and that 
URI is not the same as the effective request URI, then the response 
asserts that its payload is a representation of the resource identified 
by the Content-Location URI.  However, such an assertion cannot be 
trusted unless it can be verified by other means (not defined by HTTP)." 
(see [2])

=> that means i.e. it is not a representation of the requested URI, but 
rather it can be a representation of the description that is identified 
by the Content-Location URI; that means for the 200 response code case: 
the target resource is identified by the Content-Location URI

=> in general it is the same with fragment Ids, however generally the 
request engines strip down the fragment Id and do the requested with 
that new URI, however the effective request URI is that one with the 
fragment Id and the Content-Location URI is that one without fragment 
Id, so they are indeed different and it is the representation of the 
Content-Location URI and not of the effective request URI

=> that means I can get always a Representation that contains a 
Description that realizes the Information Resource that describes the 
Resource*


"Most, but not all, representations transferred via HTTP are intended to 
be a representation of the target resource (the resource identified by 
the effective request URI)." (see [3])

=> this is maybe somehow in contrast to the findings above; because a 
response with a 200 response code can also return a Content-Location URI


"The "Content-Location" header field supplies a URI that can be used as 
a specific identifier for the representation in this message.

The Content-Location value is not a replacement for the effective 
Request URI (Section 4.3 of [Part1]).  It is representation metadata.

If Content-Location is included in a response message and its value is 
the same as the effective request URI, then the response payload SHOULD 
be considered the current representation of that resource." (see [4])

=> otherwise, we cannot really conclude something about their relation, 
only that they are somehow related to each other


"If Content-Location is included in a response message and its value 
differs from the effective request URI, then the origin server is 
informing recipients that this representation has its own, presumably 
more specific, identifier.

For a GET or HEAD request, this is an indication that the effective 
request URI identifies a resource that is subject to content negotiation 
and the representation selected for this response can also be found at 
the identified URI." (see [4])

=> also: "... can be found at the identified URI"

This leads me to the overall conclusion that there might not be a 
problem with these definitions and the view point that a 200 response 
can also be a Representation of a Descriptions that realizes an 
Information Resource that describes the Resource*, because as I 
understand, effective request URI and target resource URI can be 
different and only if these URIs are equal we can conclude that the 
Representation (Resource) that should be identified by the target 
resource URI is a Representation of the Resource that should be 
identified by the effective request URI. Otherwise we can include the 
necessary intermediate step of Description that should help by the 
identification task.
All these findings and especially the PhD thesis from Harry Halpin [5] 
inspired me to an attempt of an abbreviated definition of Information 
Resource that is based on the existing AWWW definition:

"An Information Resource is a Resource which can convey or describe 
(essential) characteristics of a Resource somehow e.g., in a Semantic 
Graph, and i.e. this Description can then be realized (or embodied) as a 
concrete message e.g., a serialisation (Representation) of a Semantic 
Graph in RDF/N3. This Resource can also be the Information Resource 
itself and is hence then a self description."

Please correct, if I got something wrong (it's all about interpretation 
;) ). Feedback, critics and recommendations are very welcome.

Happy philosophical engineering!

Cheers,


Bob


*) please note: all capitalized terms like Representation, Description, 
Information Resource and Resource should be viewed as defined in [1]; 
that means, their definitions may vary a bit from the given AWWW 
definitions of these terms - however, since some of these terms are not 
so well-defined and there are still hot discussions about their 
definitions, I guess it is okay, when I'm using here my predefined ones, 
which are sometimes quite similar to view points of some parties of the 
debates ;)


[1] 
http://infoserviceonto.wordpress.com/2010/11/25/on-resources-information-resources-and-documents/
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-6
[3] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#section-4
[4] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#section-6.7
[5] http://www.ibiblio.org/hhalpin/homepage/thesis/index.html

Received on Wednesday, 5 January 2011 10:55:31 UTC