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

Samuel Padgett spadgett at us.ibm.com
Fri Oct 22 10:53:39 EDT 2010


+1 on Steve's proposed resolution (defer from 2.0 spec).

- Sam




From:
Steve K Speicher/Raleigh/IBM at IBMUS
To:
oslc-cm at open-services.net
Date:
10/20/2010 09:26 AM
Subject:
Re: [oslc-cm] Fw:  Proposed new rdf:type URIs for CM 2.0
Sent by:
oslc-cm-bounces at open-services.net



Hi Scott,

These are valid concerns.  Unfortunately I haven't seen anyone else weigh 
in on this thread.  Though I have solicited feedback from some individuals 

and I get some similar concerns.  There is a clear alignment with 
leveraging rdf:types in this way, there isn't much time to adapt this in 
current implementations and some additional experience in implementation 
would be desired.

With that, my proposed resolution to this is:
- Defer from 2.0 spec
- Continue to better understand how multi-typed resources should be 
represented or introduced into the spec

Please weigh in on this resolution.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: Scott Bosworth/Raleigh/IBM at IBMUS
> To: oslc-cm at open-services.net
> Date: 10/18/2010 11:41 AM
> Subject: Re: [oslc-cm] Fw:  Proposed new rdf:type URIs for CM 2.0
> Sent by: oslc-cm-bounces at open-services.net
> 
> 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
> _______________________________________________
> 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/20101022/560bd5c9/attachment-0003.html>


More information about the Oslc-Cm mailing list