• ESMF: The Eclipse Semantic Modeling Framework (ESMF) is a sub-project of the Eclipse Digital Twin project which is driven by the Industrial Digital Twin Association (IDTA). In the ESMF, the Semantic Aspect Meta Model (SAMM) and corresponding tooling is developed. See the ESMF project page for a more detailed explanation.
  
• IDTA: The IDTA develops, maintains and publishes [1] specifications that describe the Asset Administration Shell (AAS) ecosystem, such as its meta model, exchange formats and APIs.
  
• AAS: Quoting from the AAS Reading Guide:
  Quote:

  TThe Asset Administration Shell (AAS) is the digital representation of an asset. The AAS consists of a number of submodels in which all the information and functionalities of a given asset including its features, characteristics, properties, statuses, parameters, measurement data and
  capabilities can be described.

  
  
• SAMM: The Semantic Aspect Meta Model (SAMM) specifies how Aspect Models can be created, which are formal (machine readable) semantic descriptions of the aspects of a digital twin (which can represent an asset, or an abstract concept such as a service).
  

However, the added value remains unclear. When you talk about "semantically describing the digital twin", what you mean exactly? Would you have any use cases that we cannot solve with the AAS metamodel and its submodels?

• In SAMM Aspect Models, domain semantics are expressed by explicitly named and referenceable Characteristics.
  
• In OWL, domain semantics are expressed by class restrictions, subclass relationships and subproperty relationships.
  
• In AAS, domain semantics are expressed by data specificiations and concept descriptions, i.e., references to externally defined vocabularies, taxonomies or standards.
  

:voltage a owl:DatatypeProperty .
:minVoltage a owl:DatatypeProperty ;
  rdfs:subPropertyOf :voltage .
:maxVoltage a owl:DatatypeProperty ;
  rdfs:subPropertyOf :voltage .
:nominalVoltage a owl:DatatypeProperty ;
  rdfs:subPropertyOf :voltage .

:battery01 :minVoltage "5.0"^^xsd:float ;
           :maxVoltage "12.0"^^xsd:float ;
           :nominalVoltage "6.0"^^xds:float .
# the above also implies the following:
:battery01 :voltage "5.0"^^xsd:float,
                    "12.0"^^xsd:float,
                    "6.0"^^xsd:float .

:voltage a owl:NamedIndividual .
:characteristic a owl:AnnotationProperty .
:minVoltage a owl:DatatypeProperty ;
  :characteristic :voltage .
# .. and so on

AAS already provides RDF representation and the serialization between xml-json-rdf is already in the scope. So you have the freedom to use that RDF representation. The ontology and relationship between elements of metamodel already exists (aas-ontology-rdf [7]), and you can also validate it against metamodel SHACL rules which is also provided (aas-shacl-schema [8]). So you can use that representation and connect it to external ontology such as QUDT ontology [2] for unit of measurements.

Therefore, in my view, under the same project name (Eclipse Digital Twin), two parallel activities are ongoing, which is confusing for me.

When I look at projects like Catena-X [5], everything is described using Aspect models. AAS (aasx) is a side artifact generated via SAMM-CLI, which cannot be opened in the AASX Package Explorer V3 2023-09-12 [6] because it is invalid.

Therefore, I feel that Bosch wants to push his own toolset, and SAMM is going to replace and rule the AAS.

Let's assume I follow your advice and add links to units defined in QUDT. But my colleague in another department happens to prefer the QUDV ontology instead. Then a customer comes along and claims "I'd like to refer to units in the GNU Units catalog".

This is were SAMM can step in: If it's a first class citizen in the AAS tool landscape, evaluation of concept descriptions needs not longer be a random encounter.