This proposal has been implemented in the Core spec: http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT
And separate guidance has been created for representations: http://open-services.net/bin/view/Main/OSLCCoreRepresentationsGuidance As always, feedback is most welcome. Thanks, - Dave On Tue, Jul 20, 2010 at 9:34 AM, Steve K Speicher <[email protected]> wrote: > Some initial feedback/thoughts below. Can discuss more at tomorrow's > meeting. > >> From: Dave <[email protected]> >> To: oslc-core <[email protected]> >> Date: 07/20/2010 09:13 AM >> Subject: [oslc-core] OSLC representations change proposal >> Sent by: [email protected] >> >> Following the discussion at the OSLC Core workgroup meeting last week, >> I've been thinking about how the core should best handle statements >> about representation formats. Up until now, we've been requiring >> RDF/XML and specifying a specific constrained form of RDF/XML. >> Additionally, we stated that other representation formats may be >> supported or required by domain specs and product implementations. >> Some of the reasons we did that were to stay in-line with existing >> OSLC implementations, to make the RDF/XML more consistent and easier >> to handle with XML tools and to give guidance to those attempting to >> generate RDF/XML without the benefit of an RDF toolkit. >> >> Several people suggested that it was unwise to put constraints on >> what was is deemed a valid RDF/XML format and attempt to specify an >> RDF/XML subset, essentially a new format that will require much better >> specifications, conformance tests, etc. Instead, they argue that we >> should stick with plain-old RDF/XML, recognizing that particular >> implementations may have temporary constraints that will be worked out >> as they improve their RDF infrastructure over time. > > Agree > >> I agree with those suggestions and have a proposal to mandate RDF/XML >> and allow other formats, but remove any suggestion to offer a subset >> of RDF/XML from the Core spec entirely. Here's a summary of the >> changes I propose: >> >> 1) Change the OSLC Core spec to say: >> >> OSLC services MUST provide RDF/XML and MAY provide other formats such >> as Turtle and JSON. OSLC clients can not assume any specific subset or >> form of RDF/XML, such as Abbreviated RDF/XML. > > What is "Abbreviated RDF/XML"? I can't find any concrete definition of > this. Perhaps we can just remove reference of it. > >> For HTTP POST and PUT operations, OSLC services SHOULD accept RDF/XML >> content and MAY accept other representations. OSLC domain >> specifications should specify which formats are required and which, if >> any, are optional. > > Agree. > >> 2) We remove the step-by-step instructions for generating RDF/XML, >> JSON and Atom from the Core spec because they are not well specified >> or widely implemented enough to be in the final OSLC Core >> specification. > > Agree for RDF/XML. > For JSON and Atom, I believe an algorithm/approach/guidance is still > needed since there are no well-defined or industry standards to use. > >> 3) There is no longer a need for a separate section for each >> representation format that we allow so remove those sections. Replace >> them with some text at the start of the OSLC Representations section >> and mention only RDF/XML, Turtle and JSON. > > Agree. > >> 4) Create a new OSLC Core Representation Guidance document that tells >> people: use an RDF toolkit to generate your representations and if you >> don't have a toolkit, then here are some step-by-step instructions for >> going from OSLC defined resources to valid RDF/XML, JSON and Atom >> representations. > > Agree. > >> I'd like to discuss this at tomorrow's workgroup meeting so please >> review, and if you have time give some feedback. >> >> Thanks, >> Dave >> >> _______________________________________________ >> Oslc-Core mailing list >> [email protected] >> http://open-services.net/mailman/listinfo/oslc-core_open-services.net > >
