Re: Media Type Sub-Sub-types?

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