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) associated with the value for human display

• Mylyn Scenario

• CmScenariosApplicationAnalysisTools
• CmTaskTracking

Details (New)

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.

Keep it simple by restricting by these rules:

• Mapping from custom to standard values via skos:narrower
• If high, use cm:High. If something else, use custom value URI.
• Property is at most one and type/range is of cm:Priority or cm:Severity
• Queries would have to look for flat + 1 level deep of skos:narrower

@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 rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core> .

<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://example.com/enums#S1>
   a cm:Severity;
   rdfs:label "Severe - HOT" ;
   skos:narrower <http://open-services.net/ns/cm#Major> ;
   ex:icon <http://example.com/severity/S1.gif>.

Details (old proposal)

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.

Keep it simple by restricting by these rules:

• No mapping from custom to standard values
• If high, use cm:High. If something else, use custom value URI.
• Property is at most one.

@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 rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@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>.

<http://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 - 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:

• 14 Dec 2011: SteveSpeicher, SamPadgett, DaveSteinberg, SofiaYeung, SamitMehta
  • General agreement on option 3 (priority/severity as resources and may have mappings to some standard)

References

• EvoOnt BOM http://www.ifi.uzh.ch/ddis/evoont/2008/11/bom/doc/index.html
  • Mappings http://code.google.com/p/baetle/wiki/EvoOntBomMappings
• Helios_BT http://heliosplatform.sourceforge.net/ontologies/helios_bt.html
• CmCommonProperties

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>.

Category:Supporting documents