There is a need to standardize the naming (and structure) of data objects.
[Semantics] The naming convention SHOULD reflect the meaning of the named model element - input, decision, task, item, etc…
Consider leveraging the DataTypes that may be associated to a model element
Consider using semantic annotations, e.g. references to external ontologies/terminologies
Future: addressed in MVF - until then, tools may provide proprietary solutions (e.g. Trisotech’s “accelerators”)
The name SHOULD be consistent with any official term/label defined in the ontology being (implicitly or explicitly) referenced
[Semantics] The name MUST be unique/unambiguous, at a minimum within the scope of the model
Implicit semantics (within the scope of the model).
E.g. “Age” truly means “Current Chronological Age”, as implied by the context of useDisambiguation (within the scope of the model)
E.g. “Current Age” vs “Age at Initial Diagnosis” SHOULD NOT be both labeled “Age”
[Pragmatic] The name should not be too long to become impractical
Consider using “Descriptions” instead
[Technical] The naming convention MUST be a valid identifier as per the modeling specification
The (human readable) name used in the model MAY be mapped/aligned to formal model elements e.g. ‘variables', which are constrained by the specification.
For example, it MAY be problematic if special characters, punctuation, and other symbols beyond common letters and numbers are used.
Historically, especially when DMN is involved, the name of an “InputData” model element is bound to the name of the underlying variable (as is, or for example via x-casing), which is then used in an API “signature” definition.
However, it can be argued that this requirement - the definition of an interface specification - needs more information, along the lines of what would be included in an OpenAPI or a WSDL API spec, which is way more than what a ‘name’ can contain.
Consequently, the need for a naming strategy may also be considered in a broader context of annotating model elements with a combination of:
name
human readable/localizable aka “title”
technical name
description
associated datatype / schema
semantic annotations
ontology binding (conceptual level)
valueset binding (admissible instance level - related to datatype/schema)
This ‘technical' motivation should be considered - and possibly handled - independently from the general author’s requirement of CLARITY: i.e. ensuring that the underlying meaning (semantic and/or computational) is reflected in the presentation/communication layer, including the labels/names used in the model itself.
Example:
When working with Labs, one COULD adopt a naming convention such asL
<specimen type><lab test name><units>
which would lead, e.g. to “Serum glucose in mmol per L”
In doing so, one should be careful when units may involve special characters that may be corrupted in the underlying mappings, and one should consider properly formalizing the units as constraints/schema elements, and removing it from the element name altogether.
However, if units help disambiguate - e.g. consider a model that uses a patient’s weight in both kilos and pounds - the names of two two model elements should reflect that distinction.