admin-shell-io
Clarification request regarding usage of SubmodelElementList and cardinality qualifiers
With the introduction of AAS spec v3.0 the additional SubmodelElementList type was introduced, that covers most, if all, cases of collection types. To my understanding, this introduces some ambiguity with the cardinality qualifiers. For example, I would expect the "Markings" digital nameplate to be modeled as a SubmodelElementList, whereas it is modeled there as a SubmodelElementCollection with a Qualifier of [1..*].
Could you please elaborate on when to use SubmodelElementLists and when to use SubmodelElementCollections? How would I model bounds on the number of elements in a SubmodelElementList?
Furthermore, are SubmodelElementLists suitable to model {arbitrary} property fields (as for example in the AssetSpecificProperties in the digital nameplate)? Per AASd-109 a SubmodelElementList with a typeValueListElement of type Property (or Range) must specify the value type of the enclosed Property (or Range). With an {arbitrary} property field this would not be possible at the moment. Do I use cardinality qualifiers for this case?
If you have a set of equal (but not same) objects and do not know in advance how many there will be then it is a list. A list typically has the cardinality 0..* or 1..* (e.g. Authors, Documents)
If you have quite different kind of information to be described then it is a collection (e.g. Title, Author, Version). If a qualifer is attached to a collection in V3.x then it is just an abbreviated notation to list every element individually. In collections the numbers is always restricted to a specific number. Typical cardinality qualifier for collections are 0..1 and 1.
An update of the guide "How to create a submodel template" is in work.
Note: the current V3.0 SubmodelTemplates (SMT) in https://github.com/admin-shell-io/submodel-templates used the default migration strategy saying that SubmodelElementCollection (old) will be mapped to SubmodelElementCollection (new). For all SMT a new version needs to be done to decide which of the SubmodelElementCollections should be realized as SubmodelElementList.
Maybe we should also ask the best practice group to place an explanatory statement in the FAQ.
Sorry for coming back to this old issue:
If you have a set of equal (but not same) objects and do not know in advance how many there will be then it is a list. A list typically has the cardinality 0..* or 1..* (e.g. Authors, Documents)
Just to clarify: Is there then a way to model optional SMLs? If not, are SMLs always considered to be present and non-empty or empty and thus optional?
If you have quite different kind of information to be described then it is a collection (e.g. Title, Author, Version). If a qualifer is attached to a collection in V3.x then it is just an abbreviated notation to list every element individually. In collections the numbers is always restricted to a specific number. Typical cardinality qualifier for collections are 0..1 and 1.
Is it then safe to assume that the preferred way starting with V3.x would be to use cardinalities > 1 more or less exclusively for SubmodelElementLists?
Sure, give the SML the Qualifier "SMT/Cardinality" of "ZeroToOne".
So the SML is optional, inside you may have many elements.
In the SMT, you can give the first element inside the SMT the "SMT/Cardinality" of "ZeroToMany".
In the example, see LifeCycleData.
In addition to that I want to comment your question "SMLs always considered to be present and non-empty or empty and thus optional?". Generally, we discourage from modelling any optional SME as being present, but "empty". This would leave unneccessary room for interpretation and faults. If an optional SME is deliberately not being used, it should not be present in the model at all. Now, when dynamically changing the entries of an SML one can temporarily end up with an empty list. But this can then be clearly distinguished from the case where the optional SML is not being used at all: Then this SML should not be part of your SM at all.
see how empty lists are dealt with in ValueOnly serialization: https://github.com/admin-shell-io/aas-specs/issues/402
2024-10-16 TF AAS Metamodel SML was introduced with V3.0, before only SMC was available. So when migrating existing SMT still SMC with cardinality >1 is used. From metamodel point of view we recommend to use SML in cases the the number of elements is unrestricted or quite high.
Feel free to reopen the issue if there are still open questions