RE: Vocabulary for HTTP headers

エリクソン　トーレ wrote:

> Allow me to point out that Content-Type and Content-Length 
> are meta data not describing the resource, but the entity 
> body/representation (httpRange-14 and all that). For an 
> internal application conflating these into one compound 
> resource is one way of modelling, but in my experience 
> keeping them separate makes things clearer in the end.

The two places I can see this causing a problem are:

1) A URI, <foo>, might be the identifier for some physical 
resource, such as a painting, but dereferencing <foo> might 
give a document of some sort, and therefore have a 
Content-Type, which is not anything to do with the painting.

2) A URI, <foo>, might be an electronic resource, such as a 
photo, but the entity you get by dereferencing <foo> might 
vary because of, say, HTTP content negotiation.  Therefore 
<foo> might have different Content-Types depending on 
context.

AFAIK the usual interpretation of httpRange-14 in these 
cases is:

1) URIs for non-digital resources should either be hash URIs 
or 303 URIs.

2) Content negotiation should result in a 303 before serving 
content, so that each distinct representation has a distinct 
URL.

That way, by the time you get a 200 response, the Content-* 
headers will generate RDF triples whose subject is the URL 
after redirection, and with the fragment identifier 
stripped.  By contast, triples such as foaf:depicts will 
apply to the URL before redirection and with the fragment 
identifier still attached.

However in my case, most resources are electronic documents 
and I do not generally expect content negotiation to be 
occurring, so these are largely irrelevant.  Most of the 
time, the resource *is* the entity resulting from 
dereferencing its URI.

Richard