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

>> No -- HTTP returns *representations* of *resources*. Those
>> representations don't have to be fixed documents; they can be
>> dynamically composed, reflecting the client, various
>> properties, or anything else that could make the
>> representation better suited.
>
> As for transportation, HTTP shouldn't worry about those things.   
> How the
> document is prepared is irrelevant.  C'mon, let's not go back to those
> arguments.  Think about the general artitecture, not the  
> feasibility and
> then decide is some solution should be solved at some place.

You have missed this point.

>> No. You were suggesting that the server provide the mapping
>> information and the original data, and let the client sort it out.
>> Accept-vocabulary allows the server to do that work if it can.
>
> Then which way is more expensive?  I was giving a hypothetical  
> solution to
> show the expensiveness of Accept-Vocabulary.  If it were me, I  
> won't even
> put the mapping ontology in there.  I use the vocabulary that suits  
> me the
> best.

Firstly, it is not *necessary* for a server to do anything. It can  
offer to limit vocabulary, apply simple rules to do so, or do full  
ontology translation. The expense is variable

Secondly, it may not even be possible to shift the expense to the  
client. My mobile phone has very limited reasoning capacity!

The two key phrases in that paragraph were "allows" and "if it can".

> In case 1, anyone who serves RDF should be armed with a reasoner  
> (if you
> don't prefer the document analogy, which give you a way to quantify  
> things,
> I will use your reasoner case.)  This requires an extension of HTTP
> protocol.

Rubbish. They may *optionally* provide these facilities, and no  
extension is needed beyond those which HTTP allows.

> In case 2, only those agent who wants to handle the RDF needs be  
> armed with
> reasoner, which they should already sisnce that is what their task.  
> This
> approach doesn't require any HTTP extension or the server who  
> serves the RDF
> description.

I expect smart servers to be more feasible than smart clients.  
Servers have the advantages of better hardware, caching, and more  
available information.

>> Where does the RDF come from? If you request a representation
>> of a resource, and get RDF back, does it matter if it was
>> generated on-the- fly from a database? This is exactly
>> analogous to a HTML page generated by PHP from a database. My
>> point is that it is trivial, with no ontology mapping needed,
>> to put a switch into a *generated* page to produce vCard,
>> FOAF, Norm Walsh's vocab, etc. on demand.
>
> Please, you ever see HTTP protocol discuss Server Side Technology?   
> The
> Server Side Technology needs to know HTTP, not vice versa!  What do  
> PHP,
> database etc. has anything to do with this?

Again, you have missed my point. This was a case against your  
assumption that Accept-vocabulary means that "anyone who serves RDF  
should be armed with a reasoner". There are a great many simpler  
situations which do not involve automatic ontology translation.

Received on Sunday, 30 July 2006 18:28:02 UTC