Conventions on uml:Enumeration elements
Technical conventions on uml:Enumeration elements
In UML the controlled lists, discussed in Section [Controlled List] are represented as uml:Enumeration. They are transformed into instances of a SKOS model [skos-spec].
Title: Interpretation of uml:Enumeration |
Identifier: rule:enumeration-to-skos |
Statement: An uml:Enumeration element is transformed into |
Description:
Each uml:Enumeration element is transformed into skos:ConceptScheme, and each enumeration item, if present as an uml:Attribute value, is transformed into a skos:Concept. An enumeration might be empty, especially when they refer to externally specified controlled lists.
In a uml:Enumeration element, the name shall be interpreted as the controlled list name; it must be a normalised string. Each attribute name is used as a local segment in the generation of the concept URI. The attribute type is ignored and by default is considered to be skos:Concept. The attribute alias is transformed into the `skos:Concept`s preferred label. The attribute initial value is transformed into the alternative label of the concept.
In case no attribute alias is specified then the attribute name is used as preferred label of the skos:Concept. This happens as skos:prefLabel is a mandatory property in the SKOS model.
It is possible to employ the enumerations for class properties by drawing a dependency (uml:Dependency) relation from the class to the enumeration and provide a relation target role. However, the enumeration should not connect to other elements.
Title: uml:Enumeration constraint level |
Identifier: rule:enumeration-constraint-level |
Statement: An uml:Enumeration items are restricted according to one of two constraint levels set for their uml:Enumeration element. |
Description:
Formal specification of a controlled list is important for enabling validation of data described with the model. Particularly, this is required for the purpose of validating values of properties expecting a controlled list values (as described in rule:dependency-uni-range-ds).
However, providing such a formal specification (incorporated into the conceptual model as described in rule:incorporation-of-controlled-list) for validation purposes is not always possible or desirable. For example, a SKOS specification of the controlled list may not exist. Therefore, SHACL shapes for corresponding enumerations, that implements constraints for validation purposes, accomodate for both referencing and defining usage cases. It is done by introducing a concept of a constraint level that is used to specify restrictiveness of a NodeShape for an enumeration. Every UML Enumeration element is expected to specify the constraint level. There are two constraint levels that are suitable for the use cases:
-
permissive: Suitable when a controlled list specification is not available. Causes generation of a permissive shape for items of the corresponding enumeration. The generated constraint makes no assumptions about the corresponding controlled list and setsskos:Conceptas the expected type for an item. -
restrictive: Suitable when a controlled list specification is available. Causes generation of a restrictive shape for items of the corresponding enumeration. The generated constraints assume that an item belongs to a concept scheme (skos:ConceptScheme) identified by the URI used as the name of the corresponding UML Enumeration element.
Every UML Enumeration element have to specify the constraint level as a tag, using a datatype property of choice for that purpose (set in configuration). The following example use a hypothetical ex:constraintLevel property to set restrictive level for at-voc:applicability enumeration.
Details on how to configure model2owl can be found in the User Guide section.
A tag with the specified key is not materialized in model2owl artefacts. It is used only to control what SHACL shapes should be generated.
