Xiaoshu Wang wrote:
>> 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.
>>
>
> The HTTP protocol is not designed to do content partition.
Not sure, after all we have Byte Ranges for binary content.
> Of course, it
> cannot carry the task. As I wrote in the latter part of that message, the
> trade-off is breaking the orthogonality of protocols by asking a
> transportation protocol to do query.
>
It's not about about (arbitrary) queries but about selecting the
representation. Representation of a resource may be incomplete, so if G
is an appropriate representation of R every subgraph of G is as well.
Media types seems unsuitable to select the most appropriate
graph-representation.
> The difference between the Accept header and Accept-vocabulary is that the
> server can ignore the former but not the latter. If a client try to get a
> JPEG image but get back a PNG instead. The client can still figure it out
> due to different MIME type retruned. How can a client know if the returned
> RDF graph is what he wanted if the server has the option to ignore the
> Accept-Vocabulary?
>
The client may get more triples, but what it wants is always part of the
response. While it could be a MUST-level requirement for client using
the Accept-Vocabulary header to accept arbitrary triples, for the
Accept-Header things are more difficult as a not-acceptable response may
not be interpretable at all. Furthermore the server is free to return a
406 response or a response which doesn't match the Accept-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.
>>
>
> I am not sure if I understand you. What you suggested seems more expensive.
> If the eventral RDF set were made from vocabularies of n different
> namespace. The inference will be conducted at n places, instead of once (at
> client side). Inference is not exactly a cheap process. I am not sure
> where you are going at
Let's take Henry's example.
The server has the following 7 base triples:
<> a :CategoryList;
:category [ :scheme <http://eg.com/cats/>;
:term "dog" ];
:category [ :scheme <http://eg.com/cats/>;
:term "house" ].
doing OWL-Inference it can infere the following additional 7 triples:
<> a :McDonaldCategoryList;
:McCategory [ :McScheme <http://eg.com/cats/>;
:McTerm "dog" ];
:McCategory [ :McScheme <http://eg.com/cats/>;
:McTerm "house" ].
To allow clients knowing any of the two ontologies to understand the
response the server would deliver all 14 triples. If the requests would
have an Accept-Vocabulary header the client could in this case avoid
getting too many redundant triples. Of course the simple
Accept-Vocabulary-Header doesn't solve the problem of distributing
inference in the general case, whether or not inferred triples are
valuable to the client or a simple redundancy depends on the client
capabilities and of the cpu/bandwith ratio, additional headers could
give the server some hints.
Reto