Change Management vocabulary questions

["Jim Amsden" <jamsden@us.ibm.com>]

CCM TC members,
I'm in the process of replacing section
4, "CM Resource Definitions" in the Change Management specification
(https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/change-mgt/change-mgt.html)
with a reference to the updated CM 3.0 vocabulary and resource shapes.
It looks like Steve Speicher started this work but didn't quite complete
it. As a result, I have some questions that some of you may be able to
answer, or that we can discuss and resolve in some subsequent CCM TC meeting.

I created a change-mgt-vocab.ttl file
by converting the RDF/XML file at http://open-services.net/ns/cmto Turtle. change-mgt-resources.html is one of the multi-part specifications
for Change Management, and describes the vocabulary terms and constraints
using ReSpec to generate the HTML from change-mgt-vocab.ttl and change-mgt-shapes.ttl.

Following Nick's lead for Configuration
Management, I removed all the rdfs:seeAlso predicates from this file since
it is now part of the multi-part specification that would be referenced.

Here are the specific issues:

1. CM2.0 defines property oslc_cm:status
and defines a number of enumeration literal URIs for the values. CM3.0
defines oslc_cm:state and appears to be in the process of using OSLC 2.0
Actions to define the values and permissible state changes. This will create
an incompatibility with CM2.0. Do we want to do this, or is compatibility
more important than richer state management in the vocabulary? Or do we
need to include both?

2. OSLC vocabulary guidance best practices
recommend creating URIs for enumeration literals (or individuals) for property
values, e.g., 
oslc_cm:closed
  rdfs:isDefinedBy oslc_cm: ;
  rdfs:label "closed"
;
  rdfs:comment """Whether
or not the Change Request is completely done, no
           
further fixes or fix verification is needed.""" .
The CM3.0 spec has tables that describe
Resources: State, Priority and Severity that list these individuals. But
there is no way in the vocabulary or shapes to associate a list of individuals
with a property value. 

What is the convention for documenting
these enumeration values for properties in the specifications? Is there
any convention for using ReSpec to handle enumeration types and enumeration
literals?

3. There are many deprecated relationship
properties defined in CM2.0 that are not currently included in the draft
CM3.0 spec or resource shapes. These include: testedByTestCase, affestsTestResults,
blocksTestExecutionREcord, relatedTestExecutionREcord, relatedTestCase,
relatedTestPlan, relatedTestScript. Can these be safely removed from CM3.0
vocabulary without creating compatibility issues?

4. There are some individuals defined
in the CM2.0 vocabulary that specify values for oslc:usage, e.g., 
oslc_cm:task
  rdfs:isDefinedBy oslc_cm: ;
  rdfs:label "task" ;
  rdfs:comment """used
by QM and PPM tools for associating change requests
           
into executable and track-able items.""" .
Should these individuals continue to
be provided in CM3.0 given that there are now specific classes defined
for some of these usage patterns? 
oslc_cm:Task
  a rdfs:Class, oslc_cm:ChangeRequest
;
  rdfs:isDefinedBy oslc_cm: ;
  rdfs:label "Task" ;
  rdfs:comment """An
executable and trackable activity. Tasks can be used in many context. A
    QM tool that create tasks
to write test plans and test cases is one example.""" .


5. CM2.0 defined oslc:usage individuals
for planItem and requirementsChangeRequest, but there are no corresponding
new rdfs:Classes in the CM3.0 vocabulary. Are these needed?

6. Notice that I used multiple inheritance
to indicate a Task is and RDFS Class and a ChangeRequest (I have to include
the redundant rdfs:Class to get ReSpec to include the item). Is this OK?




Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575