- From: Reto Bachmann-Gmür <reto@gmuer.ch>
- Date: Mon, 5 Apr 2010 20:47:50 +0200
- To: Erik Hetzner <erik.hetzner@ucop.edu>
- Cc: www-tag@w3.org
I think the negotiation of the (serialization) format and the used ontologies should be independent. So I think an extra header should be used to indicate preferences on vocabularies, the server should then attempt to express things using terms of the preferred vocabularies wherever possible. There was A discussion on Swig about semantic content negotiation [1] Cheers, Reto 1. http://lists.w3.org/Archives/Public/semantic-web/2006Jul/0062.html On Mon, Apr 5, 2010 at 8:09 PM, Erik Hetzner <erik.hetzner@ucop.edu> wrote: > At Mon, 05 Apr 2010 01:27:36 +0200, > Jan Algermissen wrote: >> I usually address the subclassing issue (which is primarily an issue >> of expressing a client side capability of expectation, IMHO) with >> a profile parameter on the media type(s) in the Accept header: >> >> Accept: application/rdf+xml;profile=http://xmlns.com/foaf/0.1/ >> >> The server can respond with just Content-Type: application/rdf+xml or, >> if desired, with a 406 Not Acceptable if the profile 'request' cannot >> be satisfied. > > I want this solution to work, but I have some concerns. > > Is there a profile parameter defined for the application/rdf+xml media > type? (I don’t believe there is.) Or is profile considered an HTTP > accept-param? If the latter, shouldn’t it follow a q param? Futher, if > it is an accept-param, am I right in thinking that the Content-Type > response will not return the profile value? > > best, > Erik Hetzner > > ;; Erik Hetzner, California Digital Library > ;; gnupg key id: 1024D/01DB07E3 > >
Received on Monday, 5 April 2010 18:48:24 UTC