Provide guidance on extending CM state values

[ndjc]

CM 3.0 says:

OSLC CM 3.0 provides a similar means of defining a set of standard states that is also extensible. The oslc_cm:state property can have a value of type oslc_cm:State which represents an enumeration of individuals representing a standard set of ChangeRequest states. Servers may define additional individuals to extend the states of different ChangeRequest types and lifecycles.

What the standard does not say is how to extend the values of oslc_cm:State. About priority and severity, the standard says:

• Providers may have custom oslc_cm:priority and oslc_cm:severity values.
• Providers should use skos:narrower when custom priority or severity values refine standard values.
• Providers should not use owl:sameAs when custom priority or severity values refine standard values.

Shouldn't we provide similar guidance on how to extend the oslc_cm:State enumeration?

[berezovskyi]

Is there a need to rely on SKOS in our specs?

Is there a reason why State is not an rdfs:Alt?

-- /Andrew (from phone)

On Wed, May 29, 2019 at 12:14 AM +0200, "Nick Crossley" notifications@github.com<mailto:notifications@github.com> wrote:

CM 3.0 says:

OSLC CM 3.0 provides a similar means of defining a set of standard states that is also extensible. The oslc_cm:state property can have a value of type oslc_cm:State which represents an enumeration of individuals representing a standard set of ChangeRequest states. Servers may define additional individuals to extend the states of different ChangeRequest types and lifecycles.

What the standard does not say is how to extend the values of oslc_cm:State. About priority and severity, the standard says:

• Providers may have custom oslc_cm:priority and oslc_cm:severity values.
• Providers should use skos:narrower when custom priority or severity values refine standard values.
• Providers should not use owl:sameAs when custom priority or severity values refine standard values.

Shouldn't we provide similar guidance on how to extend the oslc_cm:State enumeration?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/oslc-op/oslc-specs/issues/35?email_source=notifications&email_token=AAAPZXR2QQC5TR3Y4DBBMHDPXWVFTA5CNFSM4HQHQ3UKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWK3E3Q, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAPZXXGDQIWKHJC3F5ZBITPXWVFTANCNFSM4HQHQ3UA.

[ndjc]

We recommended against any use of RDF Collections (Alt, Bag, and Seq) early on in OSLC, partly because they did not work very well with SPARQL (at least, not without custom extensions or property functions to interpret the _1, _2, ... predicates), and partly because there were better ways to represent most use cases. For example, a Bag was better represented as multiple triples with the same subject and predicate. The ordering of a Seq was best added by the client using some property of the linked object, rather than hard-coding it into the predicate.

For Alt, we came up with a best practice for representing enumerations - see Use URIs to Represent Enumerated Values. Again, the equivalent might once have been on an open-services.net wiki, or possibly just email exchanges.

[ndjc]

The use of skos come out of the CM 3.0 committee, trying to come up with ways to add custom priority and severity values to the OSLC standard enumerations. Note that OSLC Core and OSLC CM do not depend on skos - the CM spec recommends providers use skos to extend the standard. As far as I know, it is not used elsewhere in OSLC. It is used in IBM Engineering Test Management (aka RQM).

[jadelkhoury]

Shouldn't we provide similar guidance on how to extend the oslc_cm:State enumeration?

Makes sense. Good enough if we generalize or extend current text on priority & severity to include State? That is, “ Providers may have custom oslc_cm:state, oslc_cm:priority and oslc_cm:severity values. ... “

It goes beyond the scope of this issue, but it makes me think that there are domains specs (& core) that have such enum properties.

[berezovskyi]

Note that OSLC Core and OSLC CM do not depend on skos - the CM spec recommends providers use skos to extend the standard.

Thanks, I overlooked that.

[ndjc]

Firefox kept dropping my audio connection during the meeting. I believe we ended agreeing that the CM spec should describe extending state enum values in just the same way as priority and severity.

[ndjc]

Personally, I'd also like to see some way to order extended values of priority and severity, which skos predicates do not provide.

One way to do that would be to allow an extensible ordering property. We have this in Configuration Management for the contribution property, where the ordering is defined as a simple string:

Contributions are sorted lexicographically on the Unicode code points of this value to resolve component skew. To ensure predictable sorting regardless of implementation and locale, this string SHOULD be restricted to ASCII characters. Servers MUST support at least 64 characters in this string.

If the standard enum values are assigned simple 1-character ordering values (such as 1,2,3,4,...), it is easy for someone to interpolate new values between those (1a, 1b, 1c) and between those previously interpolated values (1aa, 1ab, ...), as well as before or after the ends (0z, 0zz, ..., 5a, 5aa, ...).

[ndjc]

We could add an oslc:order optional property to all orderable OSLC enumerations with such a string value.

[jamsden]

Here's my notes on oslc_cm:state:

OSLC 2.0 used oslc_cm:status to represent the location of a Change Request in its workflow lifecycle. But this value is a simple string and could be anything the server needs to support its workflow.

State predicates were introduced to represent a standard set of common statuses in order to facilitate interoperability between CM servers.

In CM 2.0, these state predicate properties were were specific Change Request boolean properties. Servers could then map their status values onto a set of standard states by setting the values of these various boolean properties.

For example, a CM server could map status "BeingInvestigated" to:

• oslc_cm:closed=false
• oslc_cm:inprogress=true
• oslc_cm:fixed=false
• oslc_cm:approved=false
• oslc_cm:reviewed=false
• oslc_cm:verified=false

CM 3.0 retains these state predicates, but deprecates status in favor of enumerated oslc_cm:state property values from oslc_cm:State. These can of course also be extended and mapped to state predicates.

oslc_cm State, Priority and Severity all have a set of defined individuals (enumeration literals) that represent a set of standard values. Each of these can be extended. Extensions follow these conformance clauses:

• Providers may have custom oslc:cm:state, oslc_cm:priority and oslc_cm:severity values.
• Providers should use skos:narrower when custom state, priority or severity values refine standard values.
• Providers should not use owl:sameAs when custom priority or severity values refine standard values.

These clauses should be applied to extensions of state, priority and severity. I will add a section that explains this better in the CM 3.0 spec.

[ndjc]

This change has been made in the CM spec, so can we now close this issue?

[DavidJHoney]

DOORS Next and GCM use rdf:value on the referenced oslc:allowedValue. ELM Report Builder supports use of skos for definining hierarchical values (broader/narrower).

[berezovskyi]

@DavidJHoney what is the meaning of a narrower value in ELM Report Builder? Does it affect ordering of the entities?

[ndjc]

Report Builder uses broader/narrower to build hierarchic views of the enum values - David used the example of animal classification: animal mammal cat Siamese Burmese Manx

For this example, Siamese, Burmese, and Manx are all skos:narrower than cat, which is narrower than mammal, etc. There is no implied ordering of Siamese, Burmese, and Manx.

So there is some value in the skos broader and narrower predicates, but it is not intended for ordering. We agreed in the meeting to leave ordering to be considered for future versions of the specs.