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: Mon, 24 Jul 2006 19:05:26 +0200
Message-ID: <1f2ed5cd0607241005w2baa7e1cye795fd7ce36ea548@mail.gmail.com>
To: "Xiaoshu Wang" <wangxiao@musc.edu>
Cc: public-semweb-lifesci@w3.org, "Semantic Web" <semantic-web@w3.org>

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

> >From my hasty look on the semantic-web, I think it is two different problem.
> One concerns if we should describe what "kind" of a resources is.  The other
> seems worry about what kind of closure one should get.

That sounds reasonable. I think we already have an example for a
pattern for the former case, the foaf:PersonalProfileDocument. The
detailed structure/content of the document isn't defined, the key part
is that such a document has a foaf:primaryTopic which is a foaf:Person
(I suspect the clause about the person being the maker of the document
is less portable).

> Using HTTP content negotiation to request different Closure of the RDF is
> not appropriate.  The Content negotiation is designed for data-format not
> the closure specific to RDF.

I agree that the typical current HTTP content negotiation setup would
not be appropriate, being format-oriented. However I do think there
may be potential for something analogeous to be useful.

The worst of it is it will put a big burden on
> the content provider.  By that suggestion, an ontology won't be simply
> placed on the web as an simple text RDF document.  You must implement a lot
> of server logic to do so, I don't think it will fly.

Look at it from the opposite direction: there are situations where
simply placing an RDF doc on the web will mean unnecessary burden, on
the client and/or server. In such cases it may be useful to do a
little preliminary negotiation to optimise what is served to the
client's requirements.

In a manner, this approach is already flying. An RDF store may contain
billions of triples, but by using a query protocol (i.e. SPARQL) it's
possible to deliver only the subset of interest to the client. This is
less burdensome that directly serving a document containing the
billions of triples.

But it seems to me there should be less demanding approaches. If, for
example, the client is only interested in say Geo data, that hint
could be passed (somehow) in a HTTP header. For a server that
recognised that header when an RDF-bearing URI was gotten, it would be
possible to redirect the client to a more appropriate resource, such
as one with a static file containing only Geo-related data.

I certainly wouldn't imagine this as a mandatory behaviour, more like
hints that could be ignored.

Cheers,
Danny.

-- 

http://dannyayers.com
Received on Monday, 24 July 2006 17:05:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:11 GMT