[oslc-core] Some comments on OSLCCoreSpecDRAFT

[Dave]

Hi Oliver,

Thanks very much for your comments. My responses are below.


On Fri, Mar 5, 2010 at 12:37 PM, Olivier Berger
<olivier.berger at it-sudparis.eu> wrote:
> (Short intro first : I've been involved only on -CM so far (and actually
> only implementing and not much specifying ;), and haven't read
> thoroughly the prior exchanges, so forgive my naive comments bellow.)
>
> I've read http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT and
> have a few comments.
>
> I've been very pleased with the rationale explaining the seek for
> simplicity in the specs of OSLC, but then I'm a bit disappointed when
> reading further :
>
> * Abusing the "resource" word :
>
> I'm not sure I understood the whole of the intentions in calling
> everything resource, but I think it is too much generalized... yes,
> everything is a resource in Web 3 world, hence in OSLC... but I believe
> it would make it much more understandable to call only resource the
> artifacts that are managed : created, retrieved, updated and deleted
> through the REST APIs of the services. The rest should be "methods",
> "services", "endpoints", "callbacks", "descriptors", or whatever better
> illustrates their role.
> This applies for "Service Resources", "Creation Resources" and "Query
> Resources", in the document, I think.

Terminology is very important, so we want to get this right.

We do use (and perhaps overuse) the term resource to mean anything
with a URI and this is useful because we don't have to define new
terms like endpoint, callback or descriptor. Maybe some or all of
those terms are useful. Can you offer some definitions and make
suggestions where we should use those words instead of resource?

The spec does differentiate between resources and artifacts managed by
OSLC, or it attempts to. The artifacts that are managed are either
"OSLC Resources," which can be anything, and OSLC Defined Resources"
which are things defined in the spec and/or in an OSLC Resource Shape.


> In the OSLC-CM V1 specs I've read before, I think the word used was
> "Methods" : i.e. a URL which is used to activate a REST HTTP transaction
> in order to manipulate resources.
>
> * Then, abusing the "URI" instead of "URL" in places
>
> Much in the sense of the previous comment, I think that URI of resources
> which are Methods of a REST API should be called URLs, period ;)

I don't have a strong feeling about this, but URL is more specific. Do
we really want to narrow down to only URLs?

> -> s/Creation Resource URI/Factory Method URL/g and similar edits would
> make the specs much more simple to read.
>
> * I'm confused about the Query Resource : is this supposed to be some
> REST API Method living at a URL or some actual Collection Resource (as
> in OSLC-CM V1), that is indeed a Resource that has a URI (which may be a
> resolvable URL indeed) ? ... then, in the latter case, shouldn't it be
> named "QueryResults Resource" instead, or something less confusing ?

Yes, in my opinion too Query Result Resource would be a better name.


> * About the Shape Resources : I've not exactly understood the whole of
> the point, but ain't it reinventing existing standards like OWL and
> schemas/ontologies ?

We need want a mechanism that OSLC Services can use to describe the
shape of resources at creation, edit and query time. But we want
something very simple, loose and light-weight. The information that is
captured in a Resource Shape is the same information that we describe
in the OSLC Defined Resource section.

OWL and RDFS seem too heavy and I'm trying to write the core spec so
it uses an RDF-compatible datamodel but does not require people to go
read about triples, graphs, blank nodes and other RDF things. From
that point of view, using OWL or RDFS would increase the learning
curve of the spec.

XSD seems too heavy and too brittle in places and I'm also trying to
minimize the XML knowledge required in the spec. We also have to
appeal to web UI JavaScript developers.


> * RDF Examples : I'd suggest to add proper RDF/XML headers and not only
> excerpts of the contents/resources.

I'm not sure what you mean here. Do you mean that we should use
<rdf:RDF> as the root?


> Also, as being involved in implementing OSLC-CM V1, I'd be curious as to
> how much these new core specs would impact on OSLC-CM V2 and needed
> variations in implementation of the servers, but that's a topic for
> another discussion I think.

I believe that the Core WG must provide some guidance on how to
migrate to the Core Spec. I'm trying to tune the Core spec so that it
follows familiar concepts and the rules that it uses for
representations produce RDF/XML, JSON and Atom representations that
are not very different from those in the v1 specs.


> I hope these comments will be useful, even though I've not (yet) read
> everything related to the Core group (minutes, archives, etc.).

Your comments are very useful and I hope you will keep on digging into
the spec and discussing issues here and at our WG meetings. If you
would like to ensure that specific issues are addressed, please add
them to the Core Spec Issues page here:

   http://open-services.net/bin/view/Main/OslcCoreV1Issues

Thanks,
- Dave