[oslc-core] OSLC representations change proposal

[Dave]

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 <sspeiche at us.ibm.com> wrote:
> Some initial feedback/thoughts below.  Can discuss more at tomorrow's
> meeting.
>
>> From: Dave <snoopdave at gmail.com>
>> To: oslc-core <oslc-core at open-services.net>
>> Date: 07/20/2010 09:13 AM
>> Subject: [oslc-core] OSLC representations change proposal
>> Sent by: oslc-core-bounces at open-services.net
>>
>> 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
>> Oslc-Core at open-services.net
>> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>