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

--Richard,

> > Document model is for HTTP.  And we are talking about 
> extending HTTP, 
> > aren't we?
> 
> 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.  

> Rather, think of every request on the Semantic Web, even 
> trivial GETs, as being implicitly a simple query -- "give me 
> triples about this resource".
> 
> >>    "Write it in one version and indicate the mapping 
> ontologies". The 
> >> work just happens to be done on the server side, where it is more 
> >> likely that the mappings are known and a reasoner is available.
> >
> > What is your point? Isn't that what I was suggesting?
> 
> 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. 

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.

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.

You tell me whihch way is a cheaper way to carry the task? I was responding
to Danny's request to put up some detail so we can comparatively compare the
approach. It is fruitless to illustrate a senario and say: "Sure, it can
work this way so it should work this way". Feasibility is not the issue
here.     

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

Xiaoshu

Received on Sunday, 30 July 2006 18:10:04 UTC