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

--Danny,

>  It is cheaper and easier doing this
> > sort of things at other places.
> 
> Well maybe, but without a concrete proposal + use cases it's 
> hard to compare (with a SPARQL endpoint presumably being the 
> alternative). But my suspicion is that in quite a few 
> circumstances graph negotiation (better term?) would be more 
> convenient - the mobile device case mentioned by Richard in 
> particular.

Say, for example, we have two competing ontologies O1 and O2. In the
Accept-Vocabularies cases, an ontology developer must prepare two documents
accordingly to describe a resource.  The alternative is: write one version
say in O1. and then point to a mapping ontology O1-TO-O2 and indicate the
URI in its description.  

<> wang:seeMapping http://eg.com/o1-to-o2 .
<> o1:foo "foo" .
<> o1:bar "bar" .
<> o1:....

The increased cost is one extra statement.  But the increased cost for
Accept-Vocabulary is one extra document. like,

<> o1:foo "foo" .
<> o1:bar "bar" .
<> o1:....
----
<> o2:foo "foo" .
<> o2:bar "bar" .
<> o2:....

Which way is cheaper?  What would you do, had you have similar choice? To
implement a server logic to take HTTP header and return accordingly. Or
write it in one version and indicate the mapping ontologies?  

> > Problem 2: Let's call this subgraph problem.  I.e., the 
> > Accept-Vocabulary ask the server to return only those 
> subgraphs that the client request.
> >
> > My position to this problem. No.  It is fundemantally wrong and we 
> > should do it with a web service etc., using SPARQL.
> 
> Hmm, Problem 1 delivers subgraphs, though presumably with 
> inference they would be equivalent.

Nope.  I don't think it as a subgraph unless you are considering writing a
description of resource with all possible ways.  No one, at least I, won't
do it that way.  It is an alternative representation, not a subgraph.

Xiaoshu