Re: Media Type Sub-Sub-types?

Jan Algermissen wrote:
> On Apr 5, 2010, at 1:17 AM, Nathan wrote:
> 
>> Hi All,
>>
>> I've hit upon something which may be a future issue (unsure).
>>
>> As the read/write web of data is realised (and assuming that RDF remains
>> the primary datatype for linked data), then machines will become reliant
>> on specific ontologies in some use-cases.
>>
>> With XML we have things like Atom - application/atom+xml. However if
>> Atom were in RDF instead, and any serialization could be used
>> (n3/rdf/xml etc), then how would one create a media type for it?
>>
>> Major / commonly used ontologies will arise; just as with the many
>> registered ****+xml media types, there may be a need for ****+rdf but
>> without the limitation of a specific serialization, or with the addition
>> of multiple serializations.
>>
>> Examples: Machines / Agents may wish to indicate they "Accept:" a
>> specific ontology "i understand x ontology / type of data in y&z
>> serializations" - perhaps foaf-onto+rdf on the client side or
>> diff-onto+rdf on the server side (accept-patch).
>>
>> Perhaps a non-issue, but worth mentioning I hope,
> 
> 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.
> 

Fantastic that about answers my question :) will need to check how that
stacks up w/ Accept-Patch from the new HTTP PATCH rfc; if so then I'm
all good (personally).

The only thing I will add, that later realised the above is primarily
due to the multiple serializations of rdf; if only a single rdf
serialization existed then it'd be a non issue. As even with the above
profile=, We'll still need to chain up 2-3 of them for each
serialization / preference.

Regards, and thanks - that's enough to get me going!

Nathan

Received on Sunday, 4 April 2010 23:33:37 UTC