SDMN — SDMN itemKinds - too broad, too complex, too ad hoc?

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:

• Conceptual - documented as representing non-physical / mental entity; if the intention is to represent something that can at least be named, e.g. a CPG name or id, then this should be covered by a Data Type capable of carrying such a name or reference.
• Document - either this is a reference to a document, in which case it is just a DataType capable of carrying an identifier, or else it is to do with the content, in which case, it is a complex DataType representing the document content; the variable definitions of Document in BMPN versus CMMN might be problematic here.
• Folder - this is a CMMN Case File Item, according to the documentation; can this not be captured by an appropriate kind of URI or other identifier?
• Physical - a reference to a physical BPMN entity, location etc; from an abstract SDMN model definition perspective, this could presumably be carried in a suitable data item for which a Datatype instance will be constructed;
• UMLClass - it is unclear how this can be an SDMN DataItem - more explanation would be useful.
• Unknown/Unspecified - documented as a CMMN Unknown/Unspecified type; would it not be better to include type unknown-ness or optionality within the SDMN meta-model rather than make it a kind of DataItem?

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.

Change ItemKinds into an Enumerated Set and Review the types of that set

The ItemKind property, not a class, and should be a string.
We will list in the spec a table of the default items.
There would be a mapping to the other specs (e.g., BPMN).
Vendors can then extend the list if they want to.

Also, remove Section 12.1 - ItemKind - from the Vocabularies section.
Replace Section 10.2.2 - ItemKind - with the definition of the enumerated list instead of the vocabulary