Re: Semantic content negotiation (was Re: expectations of vocabulary)

Xiaoshu Wang wrote:
>>> Let me put it in this way, if I have a resource R that is composed 
>>> with two parts A and B.  uri(R) should always return the 
>>> representation of R, ie.,
>>> (A+B) right?  If as you suggested, the uri(R) would have three 
>>> possible
>>> results:
>>> (1) A
>>> (2) B
>>> (3) A+B
>>>
>>> It fundemantally breaks the purpose of URI, don't you think?
>>>       
>> I don't think so, no. A, B and A+B could all be 
>> representations of the same resource. If the client only 
>> needs A, what's the point in sending B over the wire too?
>>     
>
> Of course, the intention for saving network bandwidth is good.  But to solve
> one problem may potentially a lot of other problems.  IMHO, the tradeoff for
> this particular case is just too much.  
>   
The feature is hardly implementable with traditional file-based
webservers, but what's the trade off? They may ignore the
Accept-Vocabulary header as most webservers ignore the Accept and the
Accept-Language header.

If you send the following HTTP-Request to dannyayers.com:

GET / HTTP/1.1
Host: dannyayers.com
Accept: application/x-turtle
Accept-Language: en

You'll get a lot of triples your client probably can't deal with, if
Danny turns on inference on the server you would get many triples the
client could infer itself, as more RDF is transferred over HTTP plain
serialization negotiation will no longer be enough.

reto