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

--Richard,

> 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.

Please, let's not use "may" or "various" sort of phrasing. If an "option" is
rarely be honored, what is the point to discuss it.  Imagine yourself trying
to describe something in RDF.  Are you honestly going to start an RDF engine
behind just for that? 

> > 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.

A server can be a sophisticated web service, can't it?  And it will be case
in SW.  Software agents trying to things for human.  We use these agent to
handle RDF, not ourself.  How do you find out someplace's weather? Did you
visit each local stations or you go to a central one, who did that for you?

Xiaoshu

Received on Sunday, 30 July 2006 18:41:54 UTC