[oslc-core] Should RDF/XML be MUST?

[Steve K Speicher]

> From: Dave <snoopdave at gmail.com>
> To: oslc-core <oslc-core at open-services.net>
> Date: 05/11/2010 10:18 AM
> Subject: [oslc-core] Should RDF/XML be MUST?
> Sent by: oslc-core-bounces at open-services.net
> 
> Sorry to raise this old issue again, but I've been getting some new
> feedback that the Core spec should not be so prescriptive (or is it
> proscriptive) about RDF/XML representation. I captured this feedback
> in a new issue on the issues page:
> 
> OPEN Consensus among RDF experts seems to be that RDF/XML is not the
> best representation for RDF, so why do we mandate it as a MUST in the
> Core spec. In reality, most OSLC workgroups will probably make RDF/XML
> a MUST, but perhaps we should leave that up to them. Here are two
> alternatives: (DaveJohnson, 05/11/2010)
>       * Option #1 - say this: OSLC services SHOULD provide RDF/XML
> representations for all resources and MAY provide Turtle, JSON or Atom
> representations.
>       * Option #2 - say this: OSLC services SHOULD provide an RDF
> serialization, either RDF/XML or Turtle, and MAY provide JSON or Atom
> representations.
>       * *Response* pending... (DaveJohnson 05/11/2010)
> 
> As always, feedback, comments, etc. are most welcome.
> 

I think the core requirement to capture is: if a domain spec defines a 
resource, it should use RDF to define that resource and its properties. 
Since there exists already standardized ways to serialize this resource to 
XML, then we should leverage that standards (RDF/XML).

There could be cases where XML-only format may be valid, where full valid 
RDF/XML may not be warranted.

How do you capture this in the spec?

Perhaps:
Option #3 - say this: OSLC services MUST provide a RDF/XML valid XML 
representation for OSLC defined resources and MAY provide Turtle, JSON or 
Atom representations.

This leaves it open for "non-OSLC defined resources".
Then domain specs can mandate it further if needed as well.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100511/4e3c2335/attachment-0003.html>