Both background and some arrows (e.g. BPMN -> DMN) are black or near black.
The definition of id: String [1] is:
This attribute is used to uniquely identify a SCERootElement. The id is REQUIRED if this element is referenced or intended to be referenced by something else. If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.
This seems a problematic definition for a mandatory attribute...
SCEModel has an attribute category, and also inherits categoryRef from SCEElement; both of type Category. Is this intended?
John Butler response (09-04-2022): I suspect not. Probably an oversight.
Typo (para 1, sentence 3): 'A modeler can set the direct of the'
Currently, extension of a Vocabulary has to be done by creating a new instance of SCEVocabulary or a descendent, e.g. BKPMNVocabulary, that individually recreates the membership of the 'term' property of the vocabulary, including all the terms of the original vocabulary (say SCE RelationshipKinds) along with the required extension terms.
With small vocabularies, this works, but creates a static definition that will go out of date if the top-level standard (SCE) is re-issued with new terms in say SCE RelationshipKinds. Any extension of this done by exhaustive listing of the original terms will only capture those from the older version. Normally, the intention of extension is to obtain a resulting vocabulary consisting of your extension terms plus whatever is considered to be the 'core' (original) vocabulary today - which is usually different from its first publication.
With larger vocabularies, e.g. in the 100+ terms range, the approach is likely to be unwieldy and error-prone, as well as having the above problem.
I suggest that the requirements we have are:
Further requirements that could be considered:
A change proposal for all this would include:
Both of these are not too hard to do, but will create breaking changes in SCE, SDMN, BKPMN, and PPMN at least.
Finally, there is an alternative modelling pattern that John Butler has used in PPMN that specialises Vocabulary classes before defining instances. The effect of this is that a given Vocabulary can only contain (at runtime) exactly those terms defined for it, whereas the more generic pattern defined in SCE doesn't prevent wrong terms being included in a Vocabulary at runtime, because there is no static typing that prevents it. Both ways work, so a decision should be made on which pattern is preferred (or even that both could be used, with criteria given for why / when).
More details to follow
The spec doesn't clearly specify the constraints on the types of items that can be imported for an SDMN model.
The current SDMN XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.
Proposed change
The possible values of MultiplicityKind can be (and are) exhaustively definable. It would be more easily expressed as an enum type, and its use elsewhere in the model should be replaced by that enum type.
SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
SDMN uses the vocabulary mechanism and thus will need to be updated appropriately.
BPMN Messages are similar to Data Objects. In a sense, they are the Data Objects between Pools. And they can have data structures as well.
This file linked to from the SCE catalog page (https://www.omg.org/spec/SCE )
https://www.omg.org/spec/SCE/20211101/SCE.xmi does not include the SCE package but seems to be the SDMN package which imports SCE (there are proprietary hrefs to SCE.mdzip) though the file has more than the official SDMN metamodel.
Further the files on this catalog page https://www.omg.org/spec/SCE which have SCE in their name have descriptions which refer to SDMN not SCE e.g.
"Shared Data Model and Notation (SDMN) XSD" is the description for SCE/20211101/SCE-Library.xsd
It has unnamed Associations and Properties which are not permitted
It is not clear why there are references specifically to e.g. BKPMN, SDMN, or even BPM+.
Proposed change:
Why not just say 'classes outside this model' in places where BKPMN etc classes are mentioned.
John Butler response (09-04-2022): Same reason as above generally but I agree that this should be removed.
Terms like Case, DataItem, DataState etc are all defined as elements of CMMN, SDMN etc. E.g. 'Case' = 'A CMMN element....'.
Proposed change:
Terms like 'Case' etc should have standard definitions that do not need to refer to some model like CMMN. I think every term in the glossary could be improved by removing these model / standard references.
Even better, a common glossary could be created for all of BPM+, and either published as a separate doc, or included by reference in each BPM+ doc.
John Butler response: Agreed. Yes, I’m thinking that perhaps a companion, non-normative document could be created to discuss the genesis of the language. A reference to that document wouldn’t be fragile and the contents could be updated without requiring update to this spec.
The scope of SCE is documented as follows:
The primary goal of SCE is to provide a set of structural elements that are common to other OMG specifications. The proposed specifications, BKPMN, PPMN, and SDMN, are structured to be dependent on the elements defined in SCE.
It's unusual that a more foundational spec mentions the dependencies other specs have on it, even if it was originally derived / extracted from such specs. These are likely to be fragile references in the long term, and don't (as far as I can see) add anything useful to the spec. The BKPMN etc specs of course have to mention SCE in their dependencies.
Whether BPM+ even needs to be mentioned as a dependency is a question in my mind - if SCE provides general capabilities, it is surely useable for all kinds of things, e.g. MDMI.
Additionally, I might have expected that the SCE model wasn't just defined as 'common things to BKPMN, SDMN and PPMN', but in terms of some coherent capabilities, e.g. 'a simple meta-modelling language' or so. IN section 8.1.5 it is stated that SCE is likely to be used as a basis for building models in languages utilising SCE.
John Butler response (09-04-2022): Agree with all that. Though I will say that others might ask why we didn’t just use one of the other OMG languages already out there. The fact that the BPM+ languages including BPMN, CMMN and DMN have similar elements is what kind of drove us to this.
Proposed change:
consider a more definitional description of what SCE is about, rather than just a collection of elements common to BKPMN etc. Reduce / remove direct conceptual dependency of SCE on those specs such that SCE may serve a more generic purpose within OMG specfications.
Section text:
Clause 10.4 describes in detail the meta-model used to keep the layout and the look of SCE-dependent Diagrams.
Clause 10.5 presents in tables a library of the SCE element depictions and an unambiguous resolution between a
referenced SCE model element and its depiction.
There is no section 10.4 or 10.5; probably the intent was to refer to 11.3 and 11.4. Proper Word Xrefs are needed...
Description of name : String [0..1] is:
The name attribute is a text description or label of the element. In general, the name is optional, but many elements will require a name. The definition of each specialization of SCERootElement may identify this requirement.
The second sentence seems subjective. The final sentence one is not clear.
This section contains an unresolved xref.
Under Conventions (and therefore likely apply to many OMG docs), it says:
The cardinality of any content part is specified using the following operators:
o <none> — exactly once
o etc
This is probably an OMG standard practice, but a blank cardinality standing for [1] is problematic, because you can't tell on a model which relationships have been fully analysed to be cardinality = [1], and which ones have not been analysed, or are in contention in a draft - and due to this, some unanalysed relationships may end up in final standards. (This probably applies to every BPM+ standard).
John Butler comment (09-04-2022): I thought there was a UML standard for that and I used to think it was “” (0..). But I was told differently recently so I decided to go look it up and in version 2.5.1 it states “If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model.” So I guess I’ll have to agree with you on that.
Section 8.2.3 first para,
TYPO: "A Category, which have user-defined semantics" have -> has
Figure 12 caption
TYPO: ".. a Groups referencing Categories ..."
General comment: Categories, as described and illustrated in the examples seems like a terminological device, very similar to vocabularies. If vocabularies were not flat, i.e. items could relate to other items via the IS-A (subsumption) relation, then the effect of Categories could be achieved just by allowing SCEElements to have SemanticReferences as their categories / classifiers. Any vocabulary that is extensible, e.g. RelationshipKind is in reality likely to be extended with both new top-level terms and specialised forms of some of the existing terms.
John Butler (09-04-2022): Good point. Could just use SemanticReference as the type of the property “category” on SCEElement and then it could be as rich as one would want.
Property RelationshipDirection:
ERROR: the backward and none enumeration literals have the same definition.
to be MOF compliant.
Error: para 2 refers to SDMNVocabulary, but it probably should be SCEVocabulary (or else the UML is wrong).
8.4.3 RelationshipKind
The description here & UML are repeated in 9.1 under SCE Library - is this intended - a cross-reference might be better, especially since the RelationshipKind Instances table is repeated.
SDMN should remain a logical data model. Associating terms to ontologies is of the realm of conceptual models and is already better served by SBVR.
DataAssociation is a Connector type documented as:
The DataAssociation class is a Connector and used to model how data is mapped between two DataItems. The source of the association is mapped to the target.
The word 'association' tends to imply a UML association, i.e. the alternative to Composition.
Additionally, a data mapping is often not 1:1, as implied by this model, which possibly indicates that it is not a Connector, but a mapping that may associate 1:N or N:N other items, with an algorithm to define the transformation.
Further, the arrow type is not very evocative of the idea of mapping - and also not easily distinguishable from the Reference Connector arrow type.
Proposed change
Suggest a better name for DataAssociation class would be DataMapping or similar.
Consider whether this class really is a Connector type, or should be understood as its own relationship.
Improve the symbol to be more evocative of the idea of mapping.
In the detailed description of both these types is the following (bullets 3 & 4):
• If element within a folder-type DataItem container is updated (e.g., through a change in the value of a
property), the container will not be updated. I.e., the container is not aware of changes to existing contained
DataItems.
• If DataItem within a non-folder-type DataItem container is updated (e.g., through a change in the value of
a property), the container will also be updated. I.e., the container is aware of changes to contained
DataItems.
This seems just to be saying that Folder 'containment' of other items is not really containment, such that the containing object is not considered to be changed when a sub-part is. This is contrary to the very idea of containment, and likely indicates that Folder 'containment' should really just be referencing. If a 'Folder' is deleted for example, are all the items within it deleted? If so, this indicates that a Folder is not a reference object but a true container, and the above special logic is not needed.
My suspicion is that the semantics of Folders is not that clear in SDMN, and knowing what SDMN's primary purpose is, it it not clear that Folder is even needed there - it seems just to be some kind of document-organising concept in CMMN. It might simplify SDMN significantly to get rid of it.
Proposed change:
At least the documentation of Folder needs to be improved to make the semantics clear OR perform analysis to determine if it can be removed from SDMN altogether.
Description of CompositionConnector:
A CompositionConnector is used to define a relationship between DataItems. This relationship will specify that
one DataItem is contained within another DataItem. This relationship supports the composition of DataItems.
Description of ContainmentConnector:
A ContainmentConnector is used to define a relationship between DataItems. This relationship will specify that
one DataItem is contained within another DataItem. This relationship supports the containment of DataItems,
including the parent and child association that exists between CMMN CaseFileItems.
These are effectively the same and are aiming to replicate the UML composition relationship. The detailed description given in four bullet points for each class is also the same.
The ContainmentConnector type seems to add needless complexity, possibly to accommodate some slight difference in CMMN data object semantics? If so, this should be abstracted away in SDMN, and dealt with in some SDMN / CMMN binding layer.
Proposed change:
Either:
The definition of this property says:
This attribute was added because ItemDefinition is based on the DMN ItemDefinition, which is not based on the SCE specification and thus, does not have a built in SemanticReference as
part of its definition.
Refer to comments in https://issues.omg.org/issues/SDMN-6
Proposed change:
It is suggested to make the SDMN definition of ItemDefinition either standalone or incorporate a copy of the DMN form, if it truly fits (but this is debatable; see SDMN-6).
The property mentioned in this issue would then no longer be needed.
Various comments on the following propreties:
dataItemRef: QName: "... A DataItem can have only one of dataItemRef or ItemDefinitionRef as a set attribute. Neither of them is required, though ..."
ERROR? - I could not find ItemDefinitionRef within DataItem; perhaps it was meant to be ItemDefinition or metaDefinitionRef; ItemDefinition does contain ItemDefinitionRef.
locationRef : Location [0..*] A list of potential Locations for the DataItem.
MISSING: this provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else?
preAssignment : Assignment [0..1] Specifies an optional pre-assignment DMN Expression. The expression will provide values for one or more of the simple type itemComponents of the ItemDefinition set for the DataItem.
ERROR? I could not locate 'itemComponents' in the model - probably what is meant is DMN1-3 ItemDefinition.itemComponent (singular name, multiple cardinality).
Proposed change:
ItemDefinitionRef is referenced in DataItem.dataItemRef, but doesn't exist in the model. Correction needed somewhere.
DataItem.locationRef (possibly renamed as per SDMN-4) needs to be better defined. The current definition provides no idea what kind of 'location' is meant here; there are technical possibilities in the descendant types, but it doesn't tell us the semantics - is the location a source-of-truth repository where an instance of the item is maintained? Locations of copies? Something else? Without a clearer distinction between information entities and physical ones, this might be difficult to clarify.
DataItem.preAssignment and (other properties in the model - need to do a global search) refer to 'itemComponents', which is not defined in the model. Possibly what is meant is DMN1-3 ItemDefinition.itemComponent
Firstly I would expect to see Locations in the Party model, and shared by all other BPM+ specs. This is probably intended; just noting it here.
The documentation of Location is:
Location is an abstract class where its concrete specializations identify a particular place or position. Locations are contained within a SDMNPackage and can be referenced by DataItems.
Better wording of the first sentence:
Location is an abstract class whose concrete specializations identify a particular place or position.
Semantically, it should possibly say 'a particular addressable place ...', since this part of the model is about locations that can be identified by address. There arguably should be a derived attribute, function or even data property to carry such an address. If derived, it would be a stringified form of a structural address.
Addresses are likely to take different structural forms, e.g. street address, geo-spatial (lat/long) address, cadastral map references and so on.
There is a sub-type for NetworkAddress, which is not a 'location' in the physical sense. I would call it a kind of address rather than a kind of location.
On the other hand, GeoSpatialExtent is documented as: A location that is a volume in the world such as a container or a room. This is arguably a kind of location - although perhaps an object - presumably movable - is also intended. It is not clear how it is addressed. If movable things are intended, then the 'address' is some sort of identifier of the container, e.g. truck, plane, test-tube in a lab etc.
A useful resource for thinking about some of these types is BFO2.0, which can be found here: http://gbadske.org/Files/BFO2-Reference.pdf - see p3 for the is-a hierarchy.
Another reference is how we do this in openEHR, which separates 'place' from 'address'. See https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1648920292880_630012_5562
Proposed Change:
The Locations part of the model needs to be adjusted to correctly distinguish between 'places' and 'addresses', and also between physical and informational entities. It appears that the real need of the model is to be able to form references to any kind of entity.
It might therefore be clearer to change DataItem.locationRef to DataItem.locator, meaning a reference that can be resolved to find the target entity. The Location class could also be renamed to Locator, and the subtypes could be as follows:
* PhysicalLocator
* SpatialLocator - locators for entities fixed in space
* PlaceAddress, meaning a building, site, home etc address
* GeospatialLocator, meaning lat/long, possibly altitude as well
* possibly type(s) for any other common types of map / cadastral reference
* ObjectLocator: locator for movable objects
* DataLocator, meaning a (probably) URI resolvable to obtain a data item
The type SpaceTime is not a Locator as such, it just adds a time period, presumably to indicate validity. It would be better to remove this type and add the two attributes startTime and endTiime as optional attributes in Locator.
Properties in other classes that are currently named 'locationRef' could potentially be renamed 'locator'.
Class description:
DataItems can optionally reference a DataState element, which is the state of the data contained in the DataItem.
The definition of these DataStates, e.g., possible values and any specific semantic are out of scope of this
specification. Therefore, SDMN adopters can use the DataState element and the SDMN extensibility capabilities to
define their DataStates.
It is not clear what kind of 'states' are intended here. Is the intention that users of SDMN invent their own local lifecycle models for certain kinds of data? Since an SDMN DataItem can be literally anything, from a single Quantity to an entire document, such lifecycles could widely vary, and it is not clear that they would even apply to many kinds of DataItem.
Proposed change:
Suggest the description of DataItem.dataStateRef be improved, possibly with some examples.
If the intention really is to support lifecycle states (e.g. of a document, from draft to approved, or similar) then a more comprehensive facility including a state machine or at least a set of possible states (perhaps in some DataStateType class or vocabulary) would seem to be better, since it is likely to lead to more interoperable SDMN instances.
SharedDataModel has property connector[0..*]: Connector
Is the meaning of the class Connector connector types or instances? The documentation of this property is:
This is a list of the Connectors (Composition, Containment, Reference, and Data Association) that are included in the SharedDataModel.
It is not clear whether this is a list of possible Connector types or a list of actual Connector instances. The type Connector has outgoing relationships targetRef and sourceRef, which suggests an instance level concept; I am not sure how this relates to the idea of Connector as a specialised ElementRelationshipType, which appears to be as a definer of relationship types.
Proposed change:
improve documentation of SharedDataModel.connectors to clarify whether it is a list of connector types used within a model, or connector instances.
Update the spec, metamodels, and xsds.
The approach taken is not ideal
The Data item folder shape collides with CMMN notation. It should be used.
Location is a physical attribute and should be left out of SDMN which should remain a Logical Data model.
The first sentence in the section lists the SCE Diagram shapes, not the SDMN Diagram shapes.
The text references an SDMN element that no longer exists (or was renamed). The text reads: "All other properties that are REQUIRED for the unambiguous depiction of the SDMN element are derived from the referenced SDMN element [SDMNElementRef]."
At the end of the sentence should read: "[SDMNDiagramElement]" instead of "[SDMNElementRef]".
See previous issues.
If CompositionConnector and ContainmentConnector were collapsed to just one type, and DataAssociation was modelled as a complex N:N relationship, and ReferenceConnector considered the equivalent of a UML association (call it AssociationConnector), then we would just have:
as descendants of Connector.
This simplification would imply that the subtyping approach could be removed altogether, and Connector be a concrete type with a boolean such as isComposition to indicate that it is a Composition; if False, it is an association.
The class currently called DataAssociation could be modelled as a new class Mapping, probably just inheriting from SCEElement, with multiple source items and one target i.e. an N:1 mapping, plus a transformation function taking the N source items as arguments.
I am not convinced that SDMN DataItems need to cover entity types so broad as Conceptual, Document, Folder, Physical, UMLClass, XSDComplexType and so on. I suggest that in an SDMN model, any technical data definition type - at least DataType, XSDComplexType, WSDLMessage, XSDElement, XSDSimpleType - should just be represented in SDMN as a technical DataType metatype.
With respect to other item types:
I would suggest that SDMN would make more sense as a slimmed down UML static model formalism, with some extras to do with data quality and currency.
SDMN ItemDefinition would seem to be a major extension of the DMN ItemDefinition class. It is documented as: "The itemDefinition element is the mechanism for providing the data structure of DataItems. It is contained within a SDMNDefinitions"
Since SDMN is intended to be a formalism for defining data models / items in a simple way (i.e. simpler than using UML), I would not expect it to contain classes that depend on anything in DMN. If DMN were being written now, I would suggest it would reference SDMN::ItemDefinition. If there are solid semantics for the split between SDMN::ItemDefinition and DMN::ItemDefinition, I would suggest they should be preserved by modelling both within SDMN, and making future versions of DMN refer to that.
The DMN form appears to model data items, rather than 'anything', which appears to be the scope of SDMN ItemDefinition. It is therefore not obvious to me that the inheritance is right. We might expect something more like:
ItemDefinition (abstract)
+--- DataItemDefinition (more or less the DMN version)
+--- XXXItemDefinition
where the XXXItemDefinition is various meta-classes representing e.g. document, class, - all the other kinds of itemKindRef, with appropriate meta-modelling attributes.
The class DataItemRelationship seems to have gone in the UML models I have. From what I can see, Connector is now a direct descendant of ElementRelationshipType.
Aside: I would have expected this class to have a name like ConnectorType, or indeed, DataItemRelationshipType.
The UML diagrams in the PDF spec is different from in MagicDraw.