ECLASS RDF Representation

[VladimirAlexiev]

A spec came out that's important for AAS RDF representation since "semantics' in AAS is often imparted through ECLASS. https://github.com/admin-shell-io/aas-specs/issues/383 consists of two parts:

• how to make URLs for Submodels and Submodel Elements
• how to use ECLASS props/classes by URL, rather than by GLOBAL_REFERENCE. The

ECLASS Serialization as RDF, Part 1, ECLASS Technical Specification 110, 22 April 2024. This is the first part of a series:

• Part 1: ECLASS Base Model & ECLASS Content
• Part 2: ECLASS Validation with SHACL & SPARQL
• Part 3: ECLASS RDF Usage
  • Part 3.a: RDF product description based on ECLASS
  • Part 3.b: Usage of ECLASS RDF in W3C Web of Things (WoT) Thing Description
  • Part 3.c: Usage of ECLASS RDF in AAS

These parts are still upcoming, but this older paper can serve as insight into part 3.c: Modelling the Semantics of Data of an Asset Administration Shell with Elements of ECLASS V. 1.0 Date: 2021-06-29

The AAS RDF WG members are listed in the linkedin post, and I think we should connect to them; Andreas Neumann and I think Oliver Drumm are in both groups.

---

2.5y ago I made an extensive presentation to this WG, criticizing some aspects of the representation. I'll repeat it at the AAS Semantics WG on 16 May. Some of these criticisms are still valid, eg

• ECLASS' modeling methodology (OntoML) doesn't promote "Ontological realism". Eg instead of product parts and documents, it talks about blocks, aspects, polymorphism, cardinalities.
• ECLASS class and property URLs are unstable at 2 levels: ECLASS namespace has the release number, and each term uses a versioned IRDI (the last part is a counter)

And there are some new ones, eg:

• All ECLASS props are ObjectProps, and a lot of them go through a "parasitic" node (eg iec61360:IntType) before they reach the literal iec61360:value
  • (the literal uses XSD datatypes, which is better than https://github.com/admin-shell-io/aas-specs/issues/284)
• subPropertyOf is used as a mere hierarchical organization device rather than with its proper semantics of inferring new triples, eg
  • <p> rdfs:subPropertyOf eclass:condition: will derive <x> eclass:condition <y> for each <x> <p> <y>, which is pointless. Better make a new class eclass:ConditionalProperty; rdfs:subClassOf owl:ObjectProperty and then <p> rdf:type eclass:ConditionalProperty.
  • a whole bunch of iec61360:value sub-props like numerator, denominator, wholePart, xValue, xRotValue.... What is the purpose of inferring that each of these is also value?
  • eclass:hasAlternativeUnit rdfs:subPropertyOf eclass:hasUnit, so if inference is enabled, you cannot easily tell the alternative unit from the main unit
• subClassOf is also used as an organizational device, and the inferences of this are not taken into account:
  • for the classification hierarchy that is not an ontological hierarchy but a weaker taxonomic hierarchy akin to skos:broader
  • for various ECLASS and OntoML constructs, eg to tag classes as Basic vs Advanced vs Asset, value lists as Explicit vs Implicit, other value classes with iec61360: "datatype", to tag blocks as ClassReferenceType...
• Blocks (groups of properties) are subClassOf iec61360:ClassReferenceType, which itself is subClassOf iec61360:DataType ??
• Properties have rdfs:range but not rdfs:domain (instead eclass:isDescribedBy is used)
• Property cardinality is indicated with eclass:multivalent (boolean) instead of being owl:FunctionalProperty (when single-valent)
• could reuse QUDT units and quantityKinds rather than its own treatment (probably inherited from IEC CDD),
  • eclass:AoC "AspectOfConversion" is the analog of of qudt:QuantityKind but it introduces some strange fundamental quantities eg
  • eclass:exponentByte "0"^^xsd:int (can there be Byte ^2 (Byte squared) or Byte ^ -1. Byte is a dimensionless unit!
  • that are not documented in RDF, eg what is exponentE, exponentDec, exponentSh?
  • (In fact even a google search eclass "exponentDec" finds only this issue and the gist below)

[VladimirAlexiev]

I made a diagram of sec 7 Real ECLASS Content Example: I had to make some fixes, see https://gist.github.com/VladimirAlexiev/49f8c240b57eeb71f29641fc99047d29, eg:

changed 8 prefixes from eclass: (used for ECLASS "metadata" terms) to eclass13-0: (used for ECLASS content terms)

"Content" here means the ECLASS product categories, and block/aspect/property definitions.

However, I would also like to see a realistic instance data example (i.e. a bit of content from a product catalog). There are some fragmented examples scattered through the spec, eg 6.3.4 Application Class Individuum:

example:UUID_6c15a391-3622-4eef-8eb5-c4080d37fbb4
  rdf:type eclass:0173-X-ADVANCED_01-XXX999-001 ;
  eclass:0173-X-02-XXX001-001 example:UUID_56d0e29e-54ea-4ccc-8aa5-daf39cabd803 ;
  eclass:aspect example:UUID_d91f97d6-a03d-4a03-a2d4-397a0d0b5eec ;

[mbmaja]

@VladimirAlexiev Thank you very much for pointing out these important issues. My feeling is that we have to accept that ECLASS is in its essence a data model that does not follow ontological realism. ECLASS classes can easily be viewed as object types (where type is seen as a collection of mandatory and optional attributes, possibly grouped together). ECLASS classes and properties can also be seen as part of a well-defined classification modeled as ontology classes. Probably some incosistencies in the classification would be found if ontological rigour was applied to them. Various data structuring constucts form ECLASS do not have a meaningful representation in ontologies, IMO. So I would view ECLASS RDF representation as a data exchange format, rather than something you use in data integration directly. As AAS is also about to provide an RDF exchange format, I believe ECLASS RDF serialization should builid on top of that.

Considering the use of QUDT instead of prorietary ECLASS units in the RDF representation- this makes sense and is about to become possible through the unit harmonization between IEC CDD and ECLASS (led by Gernot Rossi) and a collaboration between IEC CDD and QUDT in which harmonization between QUDT and IEC CDD is under progress.

[VladimirAlexiev]

hi @mbmaja ! Can you give some links about these harmonization initiatives?

[mbmaja]

Unfortunately I could not find an official link about IEC CDD- ECLASS unit harmonization - I have the information from the working group leader G. Rossi. The next release of ECLASS (v15) is expected to reflect this harmonization.

QUDT included hunderds of new (IEC CDD referenced) units and quantity kinds, as mentioned in QUDT release https://github.com/qudt/qudt-public-repo/releases/tag/v2.1.36 as a part of harmonization in progress with IEC CDD.

[Christian-Block]

Hi @VladimirAlexiev, great to get into exchange again. Thanks for your mentioned insight years ago. Also thank you @mbmaja for your opinion and statements.

From my point of view we are facing a generic semantic web / ontological issue: There is no right or wrong. There is a good or bad or many steps between. Furthermore, it is a question about the use case. But lets stopp that here, that could get very philosophic.

ECLASS is an existing and industrial used standard, which is based on IEC 61360 model, therefore it is not possible to change things in general. Please see the conceptual model of ECLASS Furthermore, the dictionary exists. Therefore, it is not possible to replace existing content e.g. with QUDT. However, there is a ongoing harmonization, that's right.

The motivation is to make ECLASS available as RDF in general. In the first step as an export like the XML (based on ontoML) representation, the JSON serialization or CSV.

There are also many SHACL rules, which will be documented in the next days as Part 2 and make the application much more convenient.

Regarding to your question about an example, please give me some days to set up playground, where we can define some example products based on ECLASS RDF.

It is always great to get hints, what could be better. However, it would be excellent to get examples for optimization as well. Lets start a discussion how to bring the ECLASS Dictionary in a RDF concept, which fits to your requirements.

BR

[VladimirAlexiev]

@mbmaja @Christian-Block @a5n8 @NicoWilh @arnoweiss @kenwenzel

• Yesterday at the IDTA Semantics WG we had a brief presentation and discussion about ECLASS. I'm copying here some of the people so they can provide feedback (but can't find the github id of Paulo Zanini who had a strong opinion about the issues)
• I've published my old presentation (2020-12):
  • single page: https://rawgit2.com/VladimirAlexiev/my/master/pres/20201221-ECLASS-RDF/index.html
  • interactive: https://rawgit2.com/VladimirAlexiev/my/master/pres/20201221-ECLASS-RDF/Slides.html

I think we should take the issues one by one, rather than wholesale, eg:

• Restructuring the grouping of props into Aspects and Blocks to correspond to real-world objects is not really possible
• Omitting the version number (last part: counter) from IRDIs when making URLs is IMHO very possible. The IEC CDD website uses this version-independent part of the IRDI (they call it "code") in their links: eg https://cdd.iec.ch/cdd/common/iec61360-7.nsf/PropertiesAllVersions/0112-2---61360_7%23AAS007?opendocument
• Subclass and subproperty declarations must comply with RDFS semantics, and should not be used for mere organizational purposes.
  • The ECLASS classification hierarchy is NOT a subclass hierarchy but a conceptual (SKOS) hierarchy. Eg class 72 is defined as "Electric engineering, automation, process, control engineering". If you take a concrete application class (eg a Switch or Lamp), then the subClass declaration will infer that they are "Electric engineering, automation, process, control engineering": but that's false!
• Similarly, "marker" classes like eclass:Advanced and props like eclass:nonDependent should be represented in a different way (eg as rdf:type) instead of using subClass/subProperty.
  • A Switch or Lamp is not eclass:Advanced (because the very same Switch or Lamp will be represented as eclass:Basic if you have access only to the basic version).
  • Say you have a triple <product> :numberOfParts 3 (I've denoted the eclass prop by an English name for clarity only), then you DON'T want to have <product> eclass:nonDependent 3 because that's useless: but subProperty would infer exactly that
• We could merge the lowest-level classification class and its corresponding application class
• Props that are pure literals (number or string) don't need to point to a parasitic node that has only iec61360:value that carries the literal.

I'll try to make a presentation to illustrate these issues and propose an improved representation in each case. Cheers!