[OSLC-CM] CM 1.0 comments and issues

[Olivier Berger]

Hi.

(responding just as a late comer to the group, and not one of the
initial authors, and from what I could understand of the specs only...)

Le lundi 23 novembre 2009 à 12:05 -0500, Martin Nally a écrit :
> Here are some comments on the CM 1.0 spec and suggestions of issues to
> track for CM 2.0
> 
> 
> Query string description 
> 
> 
> The wording of this section could be improved. Instead of saying 
>         
>                 “Request the Change Request resource at /bugs/bug123
>                 and only the properties of title and full owner
>                 details.” 

Shouldn't it just be changed as :
“Request the Change Request resource at /bugs/bug123 and only _return
its_ properties of title and full owner details.” ?

I.e. "SELECT title, owner FROM change_requests WHERE id = bug123" ... 

> We should say: 
>                 “Request the resource that contains only the only the
>                 properties of title and full owner details of the
>                 Change Request resource at /bugs/bug123.” 
> The point is that the URL (including the query string) identifies a
> new resource.
> This resource has a relationship to the resource whose URL does not 
> contain the query string.
> 

I think that the URL including the question mark and the selection
properties cannot really be understood as being the URI of a new change
request... it's just a URL used in a protocol, i.e. it's another method
of the REST API, and not the URI of a change request resource.


> 
> Namespaces 
> 
> 
> In the example “/bugs/bug123?oslc_cm.properties=dc:title,dc:owner{*}”,
> dc appears to have meaning, but it is not clear what it means. Are we
> saying that in OSLC URLs of this form, dc always means
> “http://purl.org/dc/terms/”? This does not seem to me like a workable
> scheme. To make this work, we would need a way to register and endless
> number of prefixes.

No. Only the ones that are used as base ontologies the OSLC-CM ontology
is itself built on. It's just a set of prefixes that are imposed by the
REST API in its specs.

If you needed to be in a real Semantic Web perspective, then you'd
better issue a SPARQL query on another kind of interface where the
prefixes used would then be non-ambiguous... but that's not in the
current state of OSLC-CM V1 AFAICT to support any Semantic query (i.e.
no reasoning on ontologies is required from the server).

>  Very few things on the web work this way – IANA is an exception, but
> it’s cumbersome. I think this design needs to be revisited. The
> obvious alternative is to allow a URI in place of a simple "word" and
> to eliminate the "word:word" form.

Or provide a clear SPARQL or other Semantic Web language query interface
in later revisions of the protocol ;-)


Just my 2 cents on part of the points that you've raised, where I think
I could provide some useful feedback.

Best regards,
-- 
Olivier BERGER <olivier.berger at it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)