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.