This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

CM Definition of Common Properties: Priority and Severity

NOTE: This is a early working draft and is subject to change frequently.

The purpose of this page is to define how some common properties such as severity and priority can be represented in OSLC-CM. They have unique characterizations in that they are typically a close choice of a configured set of values. The choices are defined by a system administrator or a specific tool instance. There is a need to be able to query on these property values, standard values and assign based on either value set as well.

Use Cases and Requirements

  • MUST Be able to have a common property, easy to query against
  • MUST Have standard values (enumerations), easy to create or query
  • SHOULD Be able to have custom values
  • MAY Be able to map custom values to standard ones
  • MAY Be able to provide a label (and icon) for human display

Details

Property Read-only Value-type Range Occurs Description
cm:priority False Resource cm:High, cm:Medium, cm:Low at-most-one Priority of this ChangeRequest?
cm:severity False Resource cm:High, cm:Medium, cm:Low at-most-one Severity or criticality of ChangeRequest?

Option: Simple URIs as value This takes the approach of just use URIs for values (objects) for a standard predicate. Has the nice quality of being very simple. Has the poor quality of not easy to get additional information about the values; either the provider needs to include in the response or acquire through query.

@prefix ex: <http://example.com/bugtracker> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix cm: <http://open-services.net/ns/cm#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.com/bugs/2314>
   a cm:ChangeRequest ;
   dcterms:identifier " 00002314 " ;
   oslc:shortTitle "Bug 2314" ;
   dcterms:title " Invalid installation instructions " ;
   cm:priority <http://open-services.net/ns/cm#High> ;
   cm:severity <http://example.com/severity#S1> .

<http://open-services.net/ns/cm#High>
   rdfs:label " High " ;
   ex:icon <http://example.com/priority/high.gif>.

<hhttp://example.com/enums#S1>
   rdfs:label "Severe - HOT " ;
   ex:icon <http://example.com/severity/S1.gif>.

Option: Resources for values, using oslc:usage

Like previous simple example but now there is a level of indirection. This works nicely as now providers don't have to send back with each response or client doesn't need to query for additional data about the priority/severity values. These simple "value" resources are very static and highly cacheable. Downside for query is now you need to map each provider's mapping of "usage".

@prefix ex: <http://example.com/bugtracker> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix cm: <http://open-services.net/ns/cm#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.com/bugs/2314>
   a cm:ChangeRequest ;
   dcterms:identifier " 00002314 " ;
   oslc:shortTitle "Bug 2314" ;
   dcterms:title " Invalid installation instructions " ;
   cm:priority <http://example.com/priority/high> ;
   cm:severity <http://example.comseverity#S1> .

<http://example.com/priority/high>
   a cm:SeverityPriority ;
   rdfs:label " High " ;
   oslc:usage <http://open-services.net/ns/cm#High>;
   ex:icon <http://example.com/priority/high.gif>.

<http://example.com/severity#S1>
   a cm:SeverityPriority ;
   rdfs:label "Severe - HOT" ;
   oslc:usage <http://open-services.net/ns/cm#High>;
   ex:icon <http://example.com/severity/S1.gif>.

To do

  • How to represent label, icon and custom values RDF reified statements (this doesn't seem to fit this model properly) or separate resource definition
  • Need to check with what other tools do and have for values - 3 seems like the right minimal set of values
    • possibly use same values for both priority/severity: High, Medium, Low
  • How to define property mapping: in resource shape or with the resource
    • need a way to communicate custom priorities to standard ones, for example: custom values are 1, 2, 3, ... 10 and map 1=High, 2=High, 3=High, ...., 10=Low
  • Possibly just add in additional values for provider specific:
         <bugs/2314>
            cm:priority <#high>;
            rtc:priority <http://mytool/priority>.
        
    - Decided this was too confusing, clients and providers would have to be careful to send only one or both or ???
  • Some suggestions on how we can use owl:sameAs to help communicate: app-spec properties mapping to standard, or app-spec values to standard

Meeting Notes:

References

Past Exploration

Option: Resources for values, using Priority values as types

Disbanded this approach as it adds way too much in the way of "meaning" of the various concepts, like a rdf:type of cm-x:PriorityHigh implies a rdfs:Class.

@prefix ex: <http://example.com/bugtracker> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix cm: <http://open-services.net/ns/cm#> .
@prefix cm-x: <http://open-services.net/ns/cm-x#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.com/bugs/2314>
   a oslc_cm:ChangeRequest ;
   dcterms:identifier " 00002314 " ;
   oslc:shortTitle "Bug 2314" ;
   dcterms:title " Invalid installation instructions " ;
   dcterms:type " Defect " ;
   cm-x:priority <http://example.com/priority/high> ;
   cm-x:severity <http://example.com/severity/low> .

<http://example.com/priority/high>
   a cm-x:PriorityHigh ;
   dcterms:title " High " ;
   ex:icon <http://example.com/priority/high.gif>.

<http://example.com/severity/low>
   a cm-x:SeverityLow ;
   dcterms:title " Low " ;
   ex:icon <http://example.com/severity/log.gif>.
Edit | Attach | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r11 - 30 Aug 2012 - 18:52:48 - SteveSpeicher
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback