allow using Linked Data principles in the RDF rendition

AAS pros:

☺ Allows incorporating important industrial data exchange standards: OPC UA, AutomationML, Collada, eCl@ss.
☺ Schema definitions in UML, XML schema, JSON schema, RDFS
☺ Data renditions as XML, JSON, RDF

AAS cons: relies on data copying not LD

☹ Reference data is copied over into blank nodes
☹ Uses string identifiers (e.g. IRDI) not URI/URLs

For example:

aas_submodel:submodelElement [
    a aas:Property;
    rdf:subject <type/1/1/F13E8576F6488342/Manufacturer>;
    aas_referable:idShort "Manufacturer";
    rdfs:label "Manufacturer";
    aas_property:category aas_category:CONSTANT;
    aas_hasKind:kind aas_modelingKind:INSTANCE;
    aas_hasSemantics:semanticId [
      a aas:Reference;
      aas_reference:key [
        a aas:Key;
        aas_key:index "0"^^xsd:integer;
        aas_key:type aas_keyElements:GLOBAL_REFERENCE;
        aas_key:local "false"^^xsd:boolean;
        aas_key:value "0173-1#02-AAO677#002";
        aas_key:idType aas_identifierType:IRDI]];
      aas_key:value "Company GmbH"];

The eClass IRDI 0173-1#02-AAO677#002 stands for a property "Manufacturer name" with possible definition "Legally valid designation of the natural or judicial person which is directly responsible for the design, production, packaging...".

Compare this to an idiomatic representation, using eg schema.org:

s:manufacturer <https://some-company-kg.org/DE/1234567>.

Where the company data is:

<https://some-company-kg.org/DE/1234567> a s:Organization;
  s:vatId "DE1234567";
  s:name "Company";
  s:legalName "Company GmbH";
  s:additionalType <company>.

The current AAS approach has numerous disadvantages compared to an RDF representation that follows Linked Data principles. I wrote about this a bit in:

Data Spaces vs Knowledge Graphs: How to Get To Semantic Data Spaces? Alexiev, V. In Data Spaces & Semantic Interoperability Workshop, Vienna, Austria, July 2022. slides video blog
- See this slide
Semantic Interoperability for Data Spaces Alexiev, V. SEMIC: Data Spaces in an Interoperable Europe (SEMIC 2022), December 2022.
- See this slide
Data Wants To Be Truly Sovereign: Designing Data Spaces with Linked Data Principles In Mind Petkova, T.; and Alexiev, V. Ontotext blog post, November 2022.

Here are some of the disadvantages:

Copying data makes it obsolete the moment it is copied. In contrast, LD is "up to date on demand": whenever you want the latest version, resolve its URL
When company data is made explicit, it is unambiguous and can be shared between AAS's. There are numerous company KGs that can be leveraged.
The IRDI includes a version number (increment), which makes it an unstable identifier
The IRDI is unresolvable. Compare this to numerous approaches that allow legacy identifiers to be resolved:
- Digital Object Identifier in publishing
- GS1 Digital Link
- IEC 61406 Identification Link QR code
About 2 years ago I participated in a WG on eClass RDF representation (and I see recent news at https://eclass.eu/en/news/news/first-eclass-as-rdf-specification, https://eclass.eu/en/news/news/eclass-as-rdf-an-overview). When eClass RDF is available, the above approach will still require copying of eClass data locally in every using model!

admin-shell-io / aas-specs

allow using Linked Data principles in the RDF rendition #383