Question: Assumptions a Consumer Can Make About idShort in Submodel Instances

[empwilli]

This question concerns what assumptions a consumer of a Submodel Instance can
make about the identification of SubmodelElements. The core issue is that it is
unclear which properties a consumer can reliably use to identify a
SubmodelElement in a Submodel Instance.

Observed Assumptions

Semantic IDs

Based on my reading of the specification, I assume the following:

• SemanticIds are not mandatory for SubmodelElements. While strongly
  recommended, a SubmodelElement may be defined without one.
• SemanticIds are not required to be unique within their context (e.g., within a
  Submodel or a SubmodelElementCollection). Multiple elements may legally share
  the same semanticId.

Please correct me if either assumption is wrong.

idShort Modeling

Again, from my reading of the spec I see four distinct ways in which a Submodel
Template constrains or suggests the idShort of a SubmodelElement in derived
Submodel Instances.

"Plain" idShort

Submodel Template

{
  "idShort": "Name",
  "valueType": "xs:string",
  "modelType": "Property"
}

Here, the implicit assumption is that instances will use the same idShort
("Name") as defined in the template.

Enumeration Template

Submodel Template

{
  "idShort": "Wheel__00__",
  "valueType": "xs:string",
  "modelType": "Property"
}

This pattern is commonly used in combination with an SMT/Cardinality qualifier
(ZeroToMany or OneToMany). In instances, this typically results in idShorts
such as: Wheel00, Wheel01, ... .

However, in several SMT specifications (e.g., Handover Documentation 2.0), the
enumeration template is described as a production rule, not a strict constraint.
That is, alternative idShorts may still be valid as long as they are unique:

SMT/AllowedIdShort

Submodel Template

{
  "idShort": "SomeName__00__",
  "qualifiers": [
    {
      "type": "SMT/AllowedIdShort",
      "valueType": "xs:string",
      "kind": "TemplateQualifier",
      "value": "^SomeName(0[0-9]|[1-9][0-9]+)$"
    }
  ],
  "valueType": "xs:string",
  "modelType": "Property"
}

In this case, the valid idShorts of the instance are explicitly constrained by a
regular expression (e.g., SomeName00, SomeName01, …).

(I've included the enumeration template as otherwise valid idShorts cannot
easily be generated automatically.)

Arbitrary Elements

{
  "idShort": "ArbitraryProperty",
  "semanticId": {
    "type": "ExternalReference",
    "keys": [
      {
        "type": "GlobalReference",
        "value": "https://admin-shell.io/SMT/General/Arbitrary"
      }
    ]
  },
  "valueType": "xs:string",
  "modelType": "Property"
}

For elements marked as arbitrary, the instance creator is free to choose the
idShort, subject only to general syntactic constraints.

Problem Statement

Given the patterns above, it is easy to construct Submodel Templates where the
sets of valid idShorts overlap between different SubmodelElements in the same
context. For arbitrary elements without an SMT/AllowedIdShort qualifier, this
overlap is effectively unavoidable.

From a consumer’s perspective, it is therefore unclear, whether ambiguity in
idShorts is expected, discouraged, or considered a modeling error, and, more
importantly, how ambiguity should be resolved during deserialization, validation,
or data extraction.

Questions

• Validity of assumptions: Are the assumptions stated above regarding semanticId
  and idShort generally correct?

  • More precisely: Can a consumer assume that a non-arbitrary
    SubmodelElement without an enumeration template, or SMT/AllowedIdShort
    qualifier will use exactly the idShort defined in the Submodel Template in all
    derived instances?

    In other words: is this situation semantically equivalent to constraining
    the idShort via SMT/AllowedIdShort to a single fixed value?

• Ambiguity as a modeling error: Is it considered a modeling error if idShort specifications
  in the same context are ambiguous (i.e., overlapping sets of valid idShorts)?
• Ambiguity resolution: If ambiguity is not considered an error, how is a
  consumer expected to resolve it when deserializing or validating instances?
  • By semanticId (and if so, what if it is absent or ambigious)?
  • By modelType?
  • By any other precedence or matching rules defined (explicitly or implicitly) in the specification?

I’m particularly interested in guidance from a consumer’s perspective, i.e.,
what can be relied upon without out-of-band knowledge or template-specific
conventions.

[empwilli]

We came to the resolution, that:

• id shorts are the means to identify submodel elements (conceptually, they should also be identifiable by their semantics, however in a submodel instance, there might not be a semantic id available)
• identification should thus be possible unambigiously
• wrt. to SMT/AllowedIdShort and enumeration patterns (00) it is open whether they are still useful with the availability of SubmodelElementLists in the meta model

As a result, I'd suggest to extend Are there any best practices how to choose the idShort of an element? with the following paragraph (at least as long as the situation w/ SMT/AllowedIdShort and enumeration patterns is not decided):

SubmodelElements (i.e., referables that are not identifiable) should always be uniquely
identifiable by IdShort, as specified in the SMT, as special case are list elements,
which are identifiable via index. Wrt. to a SMT, it should be possible to resolve an
element by its id short unambigiously.

Note, that means, enumeration patterns (IdShort__00__) or the SMT/AllowedIdShort, can lead
to situations where a unique resolution of an IdShort to an element is impossible. Hence, they
should be used cautiously. Their necessity/usefulness is currently in considerations.

[StenGruener]

16.03.2026: wait for other member to check on answer, PR to be proposed by @empwilli

[StenGruener]

thanks @empwilli we will review today