[oslc-cm] Fw: Proposed new rdf:type URIs for CM 2.0

[Scott Bosworth]

Hi Steve, I can see the need and value for these type URI's, but I wonder
if we are at the right point in the process to add them. Also, I'm not sure
whether we've provided enough guidance on their appropriate use.

For example, if I'm a client and I queried for ...cm#defect, I would expect
to get a list of defects back, yet none of the V2 spec provider
implementations already delivered would reply in such a way today. This
might seem like a bug to a client implementation?

Also, I wonder what the introduction of these types does to portability
across CM provider implementations, especially since we haven't had much
discussion/adoption of their use.  If I wanted to query for all resources
that were some type of ChangeQuest, I'm thinking I would now have to
construct a query that includes all of the possible CM defined types rather
than query for rdf:type of ChangeRequest as I did in the past? I suspect
clients written today might do the latter? If this is the case and new
providers make use of the new type uri's, then might some Change Requests
be left out of the response? Or are we implying that the new types are all
of the ChangeRequest class and would be included in a query response for
resources of type ChangeRequest?

Anyhow, given that the CM V2 spec is in finalization, I wonder if we should
defer introduction of these types until such time when we can explore these
questions and have consumer/provider implementations that support their use
in the intended way...Scott



Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 919.486.2197
(w) | 919.244.3387(m) | 919.254.5271(f)

oslc-cm-bounces at open-services.net wrote on 10/13/2010 03:19:36 PM:

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: oslc-cm at open-services.net
> Date: 10/13/2010 03:20 PM
> Subject: [oslc-cm] Fw:  Proposed new rdf:type URIs for CM 2.0
> Sent by: oslc-cm-bounces at open-services.net
>
> Per today's WG meeting, I have made this change:
> http://open-services.net/bin/view/Main/
> CmSpecificationV2#Additional_Type_URIs_for_ChangeR
>
> Please raise any issues with this change.
>
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
>
> > From: Steve K Speicher/Raleigh/IBM at IBMUS
> > To: oslc-cm at open-services.net
> > Date: 10/06/2010 02:52 PM
> > Subject: [oslc-cm] Proposed new rdf:type URIs for CM 2.0
> > Sent by: oslc-cm-bounces at open-services.net
> >
> > When looking at the current CM 2.0 spec, there are a number of  "usage"

> > URIs that are used to identify services for a particular usage.  It is
> > clear that these would be suitable as values for identifying the
> rdf:type
> > of a oslc_cm:ChangeRequest.
> >
> > So I propose that we elevate these usage URIs:
> >     *  http://open-services.net/ns/cm#defect - primarily used by QM
> tools
> > to report defects in testing.
> >     * http://open-services.net/ns/cm#planItem - used by QM and PPM
tools
>
> > for associating change requests into plans (project, release, sprint,
> > etc).
> >     * http://open-services.net/ns/cm#task - used by QM and PPM tools
for
>
> > associating change requests into executable and track-able items.
> >     * http://open-services.net/ns/cm#requirementsChangeRequest - used
by
>
> > RM tools for associating a change request for usage in tracking changes

> to
> > a Requirements resource
> >
> > That would allow service providers to return multiple rdf:type property

> > values when defining a ChangeRequest format representation to respond
> > with.
> >
> > Will add to agenda for next meeting.
> >
> > Thanks,
> > Steve Speicher | IBM Rational Software | (919) 254-0645
> >
> >
> > _______________________________________________
> > Oslc-Cm mailing list
> > Oslc-Cm at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
>
>
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20101018/6aefba73/attachment-0003.html>