W3C home > Mailing lists > Public > semantic-web@w3.org > July 2006

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

From: Danny Ayers <danny.ayers@gmail.com>
Date: Sun, 30 Jul 2006 09:37:44 +0200
Message-ID: <1f2ed5cd0607300037p15faf6b3vc89d59d48c3a139@mail.gmail.com>
To: "Xiaoshu Wang" <wangxiao@musc.edu>
Cc: "Reto Bachmann-Gmür" <reto@gmuer.ch>, "Semantic Web" <semantic-web@w3.org>

On 7/30/06, Xiaoshu Wang <wangxiao@musc.edu> wrote:

Thanks for spelling out your position.

> Problem 1: an RDF document can be written in multiple similar vocabularies.
> Use Accept-vocabulary to ask the server to return the statement written in
> certain vocabularies but not the other.
> My position for this problem (let's call it alternative vocabulary problem).
> It is O.K., fundamentally.  But I don't think it is practical.  It puts too
> much burdern on ontology developer.

I don't see how there would be *any* burden on the ontology developer...

 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.

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

I still don't see anything wrong in the fundamentals of delivering
alternate/subgraphs (different representations, thread passim) but
coming up with working definitions on how it might operate could be
tricky (but maybe worth it ;-)



Received on Sunday, 30 July 2006 07:37:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:16 UTC