[oslc-core] [rant] Re: OSLC Core spec query shapes example
Dave
snoopdave at gmail.com
Wed May 12 09:20:56 EDT 2010
Olivier, this is excellent feedback and I've heard many of the same
concerns from others not directly involved in the workgroup. Thanks
for taking the time to write this.
More comments below...
On Wed, May 12, 2010 at 5:18 AM, Olivier Berger
<olivier.berger at it-sudparis.eu> wrote:
> Pardon me in advance for that "rant"... It's just meant to help clarify
> the current OSLC direction. Apologies in advance for the good people
> investing efforts in OSLC... I'm just a devil's advocate.
>
> And I'm a bit fearful that OSLC turns to a too complex thing to ever
> achieve some potential of being a standard in the ALM field, if it
> becomes too hard to grasp (at least for the core mandatory concepts).
>
> In particular, I don't quite get it why one needs to reinvent the wheel
> with shapes in OSLC when there's already ontologies as OWL to describe
> resources on the Semantic Web... for instance.
I'll defer here to Arthur's response, which I think is a very good one.
> At least for the first half of the document references below, it isn't
> clear. Now, when the format of the query results is described, it may
> make more sense... but so hard to grasp at first sight !
We need more illustrative examples. Here's one that I wrote-up outside
of the Core spec:
http://open-services.net/bin/view/Main/OslcCoreQueryDiscussion
Right now, our examples are confined to the representation in the
appendices. This is probably not good enough. Do you have suggestions
for places where examples would be most helpful?
> I'm a bit afraid of too much over-specification for these
> shapes/queries... whereas it isn't even clear if there's a single
> consumer available somewhere (OK, I mean in the Open Source landscape)
> that supports at least OSLC-CM V1 at the moment.
This is an important concern and I'm going to propose that we postpone
finalization beyond May 26 and wait to hear more from other workgroups
as they adopt the Core spec and products as they implement the Core.
> Ensuring OSLC becomes a standard (an Open one, I mean), means it may not
> need to go too far and too fast, in particular in what concerns
> over-specification for the core. I strongly believe bottom-up approaches
> are interesting, and not so sure this is happening here now.
Good point. I like the "rough consensus and working code" model and
right now we are missing a lot of the working code part.
> Pardon me if I haven't fully understood all that's happening (unability
> to participate in conf calls certainly doesn't help much, and focusing
> on coding (OAuth ATM) prevents me from reading all the docs in time),
> but I fear there's some confusion between requirements for one
> implementor's requirements design/specs, and specification of an open
> standard, that should be at least a little bit understandable by the man
> in the street.
>
> I'm doubtful it will be really easy to convince people to implement so
> complex specs in existing tools, given the level of complexity I can
> feel around here.
>
> Maybe a more KISS approach would be better until more feedback comes
> from the grassroots implementors ?
>
> Hope this helps anyway ;)
It does. I think we need to take steps to further simplify and to make
the spec more understandable with examples. Thanks again from the
write up.
- Dave
More information about the Oslc-Core
mailing list