CoCoML - Controlled Vocabulary
Note: This vocabulary is the very beginning and will be complemented step by step following the discussion in the interested community.
Among the concepts offered by UML/SysML those deemed relevant for overarching system modeling will be selected. Different modeling languages use their own terminology - but share many concepts. The final goal is to put system information from difference sources into a common context.
A common terminology is essential in all those cases.
Of course, established terms shall be re-used whenever possible, for example from the Dublin Core Metadata Initiative (DCMI) or Schema.org.
| Concept | Term | Type of Term | Description |
|---|---|---|---|
| Model Diagram | uml:Diagram | Entity | SpecIF:View is a normalizing (preferred) synonym. |
| Model Diagram | SpecIF:View | Entity | |
| Class | uml:Class | Entity | SpecIF:ModelElement is a normalizing (preferred) synonym. |
| Model Element | SpecIF:ModelElement | Entity | |
| Active Entity | FMC:Actor | Entity | An ‘Actor’ is a fundamental model element type representing an active entity, be it an activity, a process step, a function, a system component or a role. The original type is specified with a dcterms:type property of the FMC:Actor. A value of that property should be a vocabulary-term itself. |
| Passive Entity | FMC:State | Entity | A ‘State’ is a fundamental model element type representing a passive entity, be it a value, a condition, an information storage or even a physical shape. The original type is specified with a dcterms:type property of the FMC:State. A value of that property should be a vocabulary-term itself. |
| Event | FMC:Event | Entity | An ‘Event’ is a fundamental model element type representing a time reference, a change in condition/value or more generally a synchronization primitive. The original type is specified with a dcterms:type property of the FMC:Event. A value of that property should be a vocabulary-term itself. |
| Requirement | IREB:Requirement | Entity | A ‘Requirement’ is a singular documented physical and functional need that a particular design, product or process must be able to perform. (source: Wikipedia) |
| Requirement | RFLP:Requirement | Entity | IREB:Requirement is a normalizing (preferred) synonym. |
| Function | RFLP:Function | Entity | |
| Logical (Element) | RFLP:Logical | Entity | |
| Physical (Element) | RFLP:Physical | Entity | |
| Composition | dcterms:hasPart | Relation | This property is intended to be used with non-literal values. This property is an inverse property of Is Part Of. |
| Aggregation | dcterms:hasPart | Relation | This property is intended to be used with non-literal values. This property is an inverse property of Is Part Of. Most practitioners don’t make a difference between Composition and Aggregation and therefore it is proposed to use hasPart in both cases. |
| Occurence | SpecIF:shows | Relation | |
| Satisfaction | oslc_rm:satisfy | Relation | |
| Title | dcterms:title | Property | A name given to the resource. |
| Description | dcterms:description | Property | Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. |
| Type | dcterms:type | Property | Recommended practice is to use a controlled vocabulary such as the DCMI Type Vocabulary DCMI-TYPE. |