[oslc-core] Should RDF/XML be MUST?
Steve K Speicher
sspeiche at us.ibm.com
Tue May 11 11:22:45 EDT 2010
> 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
> * Option #2 - say this: OSLC services SHOULD provide an RDF
> serialization, either RDF/XML or Turtle, and MAY provide JSON or Atom
> * *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?
Option #3 - say this: OSLC services MUST provide a RDF/XML valid XML
representation for OSLC defined resources and MAY provide Turtle, JSON or
This leaves it open for "non-OSLC defined resources".
Then domain specs can mandate it further if needed as well.
Steve Speicher | IBM Rational Software | (919) 254-0645
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oslc-Core