Incorrect Serialization of AbstractLangString Subclasses in RDF

[mhrimaz]

Subclasses of AbstractLangString serialized differently in XML and RDF. Due to this inconsistency, SHACL shapes cannot validate most of the official examples that have displayName, dataSpecificationIec61360 preferred name, ...

XML

Let's see an example in XML: maximal AssetAdministraionShell XML example

In this example to have displayName we have:

<displayName>
  <langStringNameType>
    <language>de</language>
    <text>something_1e73716d</text>
  </langStringNameType>
</displayName>

and to have dataSpecificationIec61360 preferred name we have:

<preferredName>
  <langStringPreferredNameTypeIec61360>
    <language>zh-cmn-Hans-CN</language>
    <text>something_5282e98e</text>
  </langStringPreferredNameTypeIec61360>
  <langStringPreferredNameTypeIec61360>
    <language>en-GB</language>
    <text>Something random in English 5b15c20d</text>
  </langStringPreferredNameTypeIec61360>
</preferredName>

RDF

Now let's look at the RDF maximal AssetAdministraionShell RDF/Turtle example

Here to have displayName we have:

<https://admin-shell.io/aas/3/0/Referable/displayName> [
    rdf:type aas:LangStringNameType ;
    <https://admin-shell.io/aas/3/0/AbstractLangString/language> "de"^^xs:string ;
    <https://admin-shell.io/aas/3/0/AbstractLangString/text> "something_1e73716d"^^xs:string ;
] ;

However, if we want to follow the same pattern as we have in XML we should have something like this:

<https://admin-shell.io/aas/3/0/Referable/displayName> [
    rdf:type aas:LangStringNameType ;
    <https://admin-shell.io/aas/3/0/LangStringNameType/language> "de"^^xs:string ;
    <https://admin-shell.io/aas/3/0/LangStringNameType/text> "something_1e73716d"^^xs:string ;
] ;

Indeed this is what SHACL states:

aas:LangStringNameTypeShape a sh:NodeShape ;
    sh:targetClass aas:LangStringNameType ;
    rdfs:subClassOf aas:AbstractLangStringShape ;
    sh:property [
        a sh:PropertyShape ;
        sh:path <https://admin-shell.io/aas/3/0/LangStringNameType/text> ;
        sh:datatype xs:string ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:maxLength 128 ;
    ] ;
.

For this reason, the official example is actually incorrect. This is the same for other cases like dataSpecificationIec61360. I know that Ontology workgroup is working on a new representation, but regardless, IMO, if the effort to fix this is low, it would be better to fix it for now. We can fix by correcting the examples, or by correcting the SHACL shape. This issue doesn't appear in JSON serialization.

[mristin]

Thanks, @mhrimaz ! I think it would be easiest to fix the examples, assuming that the RDF and SHACL schemas are already usable.

Can you please explain me exactly how I should change the examples? (Maybe make a two-three concrete rewrites?)

[mristin]

Sorry, now I see it again. It's the problem of inheritance -- LangStringNameType inherits from AbstractLangString; so then how should the inheritance be dealt with? That is, how should we represent it in SHACL/RDF and/or in the examples?

[mristin]

(You have to explain me everything like I'm 5 -- I still don't really know much about RDF/SHACL.)