RE: Vocabulary for HTTP headers

$B%(%j%/%=%s(B $B%H!<%l(b 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