[oslc-core] Should RDF/XML be MUST?
ncrossley at us.ibm.com
Tue May 11 10:41:51 EDT 2010
Personally, I do not care about RDF, but surely we must have at least one
common representation for OSLC. If all domains are completely free to
mandate their own favored representation, then a cross-domain client is
put in an almost impossible position of having to deal with a potentially
large number of different representations. Imagine a client trying to
trace down from requirements through CM, SCM, test cases, build automation
producing software assets, etc., and every one requiring a different
RDF/XML might not be the ideal way to represent RDF, but it is something
we seem to have invested quite a lot of time in already. I believe it is
essential to have at least one common representation that is required by
all OSLC domains.
From: Dave <snoopdave at gmail.com>
To: oslc-core <oslc-core at open-services.net>
Date: 05/11/2010 07: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.
"that prescribes; giving directions or injunctions"
"outlawry, interdiction, or prohibition"
Oslc-Core mailing list
Oslc-Core at open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oslc-Core