[oslc-core] OSLC representations change proposal

[Steve K Speicher]

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