Linking standard metadata attributes to domain-specific ontollogies and Shacl-shapes

[jtdemer]

@robertschubert or @JustinDxx can you give us an example how we can do this in an correct way?

My suggestion would be that we can use the latest version of the general ontology branch and link there the metadata attribute "name" and "description" from the Gaia-X DataResource-shape.

We can do this before or after improving the pull request.

Thx:)

[robertschubert]

My suggestion would be another approach.
Since an HDMap will be a subclass of DataResource there should not be a name and description attribute at all in the HDMapShape or the GeneralShape.
When creating claims those two fields should be filled out in the DataResource.

[robertschubert]

There will be soon an example how claims could look like for the gaia-x Vocabulary here:
https://github.com/GAIA-X4PLC-AAD/gaia-x-complaint-claims-example

[MircoNierenz]

the repro seems to be empty

[jtdemer]

My suggestion would be another approach. Since an HDMap will be a subclass of DataResource there should not be a name and description attribute at all in the HDMapShape or the GeneralShape. When creating claims those two fields should be filled out in the DataResource.

@robertschubert:
Why I choose the way I proposed was:

• We may want to have in our ecosystem the attribute name and drescription not optional like it is defined in the gaia-x framework 22.10. So we need therefore a different shcal-file which contains a subset of requirements from the original DataResource-shcal.file. Or can we handle that different?
• We will have in the future the need to link metadata attributes from standard ontologies like OpenLabel, Auto, ... into a domain-specific shacl-file and therefore we should have an example. Which shows us a portal and gaia-x compliant way. I think this would also help the guys for building the scenario and sensor shacl-files.

[robertschubert]

@jtdemer
I understand. Then I see three possibilities:

1. make name and description mandatory in the GeneralShape.
2. remove name and description in GeneralShape and add it to each of the domain Shapes, e. g. HdMap and make them mandatory there. Reuse the sh:path from the DataResourceShape
3. remove name and description in GeneralShape and add it to each of the domain Shapes, e. g. HdMap and make them mandatory there. use hdmap as prefix for the sh:path

I would prefer 2 or 3.

An example to link an external attribute would be:

hdmap:HdMapShape a sh:NodeShape ;
    sh:description "my description..." ;
    sh:name "HdMap ..." ;
    sh:property [
            sh:path gx:description ;
            sh:datatype xsd:string ;
            sh:description "A free text description of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "description" ;
            sh:order 5 
        ],
        [
            sh:path gx:name ;
            sh:datatype xsd:string ;
            sh:description "A human readable name of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "name" ;
            sh:order 4 
        ] ;
    sh:targetClass hdmap:HdMap .

Note that you have to redefine the constraints and add minCount 1. The path is gx:name resp gx:description. If we would stick to 3. then it would be hdmap:name resp hdmap:description.

Sidenote:
it is easier to link complete Shapes into existing shapes.
Example:
see #29 (comment)

[robertschubert]

Or 4th alternative:
do not define name and description at all in the HdMap and stick to a "gentlemen's agreement" that name and description in the DataResourceShape should always be filled (when creating the claims).

[jtdemer]

@jtdemer I understand. Then I see three possibilities:

1. make name and description mandatory in the GeneralShape.
2. remove name and description in GeneralShape and add it to each of the domain Shapes, e. g. HdMap and make them mandatory there. Reuse the sh:path from the DataResourceShape
3. remove name and description in GeneralShape and add it to each of the domain Shapes, e. g. HdMap and make them mandatory there. use hdmap as prefix for the sh:path

I would prefer 2 or 3.

An example to link an external attribute would be:

hdmap:HdMapShape a sh:NodeShape ;
    sh:description "my description..." ;
    sh:name "HdMap ..." ;
    sh:property [
            sh:path gx:description ;
            sh:datatype xsd:string ;
            sh:description "A free text description of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "description" ;
            sh:order 5 
        ],
        [
            sh:path gx:name ;
            sh:datatype xsd:string ;
            sh:description "A human readable name of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "name" ;
            sh:order 4 
        ] ;
    sh:targetClass hdmap:HdMap .

Note that you have to redefine the constraints and add minCount 1. The path is gx:name resp gx:description. If we would stick to 3. then it would be hdmap:name resp hdmap:description.

Sidenote: it is easier to link complete Shapes into existing shapes. Example: see #29 (comment)

Why don't we use option 1 and link there the name and description attribute from the DataResource as descriped in option 2 ?

general:GeneralShape a sh:NodeShape ;
    sh:description "my description..." ;
    sh:name "HdMap ..." ;
    sh:property [
            sh:path gx:description ;
            sh:datatype xsd:string ;
            sh:description "A free text description of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "description" ;
            sh:order 5 
        ],
        [
            sh:path gx:name ;
            sh:datatype xsd:string ;
            sh:description "A human readable name of the entity." ;
            sh:maxCount 1 ;
            sh:minCount 1 ;
            sh:name "name" ;
            sh:order 4 
        ] ;
    sh:targetClass general:GeneralShape .

I think we should always have the name and designation as mandatory information in our GAIA-X4PLCC-AAD ecosystem.
This would also give the portal and marketplace planning security for visualization.

[jtdemer]

x:description

@JustinDxx or @lenasauermann can you give us here feedback if it work with the catalogue?

[JustinDxx]

In my understanding it should work and I would also agree that referencing the GX-attributes in the General-Shape would be the best solution. SHACL files are just used for the validation of properties, not for the definition and therefore it should not produce any issues if we reference the GX-attributes in the Generalshape and the DataResourceShape simultaneously. It could even avoid having the same description multiple times as different attributes.

Anyways, I am not 100% sure if I miss a crucial argument for options 2 or 3 as suggested by @robertschubert, but in the meantime I would assume that your suggestion, @jtdemer, would fit.

[robertschubert]

@JustinDxx @lenasauermann @jtdemer
also fine with that option from Johannes.

[lenasauermann]

@jtdemer Can we close this issue?

[lenasauermann]

@jtdemer Can we close this issue?