TODOS discussion 06.05.2024

[jdsika]

Participants

@robertschubert
@jtdemer
@jdsika

Decisions

1. Every ontology is created in its own folder
   Codeowners
   Rename: VARAIBLES -> prefix_properties.md OR PROPERTIES.md
   files and folders without capitals
   prefix is always the same as the folder name
   prefix names use "-" as separators
   Classes PascalCase
   Properties camlCase
2. Rename examples folder to example
   Carlo: merge examples. Question of taste
3. Add test vector as example .json file into each ontology folder
   not extra folder, just same level
   everyone adding an ontology must add an example
4. Add CI workflows
   test if ontology/shacl parses successfully
   test if example .json complies with shacl property definitions (schema)
5. Add gaiax ontologies as sub repository and link resources in readme
   GaiaX definitions are provided as json and not as a repo
   we add an extra folder to the repo named e.g. "gaiax" with a readme and original json plus pthon converter to .ttl
6. Can we discuss some structural elements used in the old demo as Carlo thinks it is useful
   token meta data

[robertschubert]

#5 is done, see PR

[robertschubert]

• Every ontology is created in its own folder
• -> Codeowners --> updated and improved README.md
• -> Rename: VARAIBLES -> prefix_properties.md OR PROPERTIES.md
• -> files and folders without capitals --> enhanced README.md
• -> prefix is always the same as the folder name --> enhanced README.md
• -> prefix names use "-" as separators --> enhanced README.md
• -> Classes PascalCase --> enhanced README.md
• -> Properties camlCase --> enhanced README.md
• Rename examples folder to example
• -> Carlo: merge examples. Question of taste --> I would prefer to leave it as it is.
• Add test vector as example .json file into each ontology folder --> added for gx and example, enhanced README.md. The rest is up to the data providers.
• -> not extra folder, just same level --> documented in README.md
• -> everyone adding an ontology must add an example --> documented in README.md
• Add CI workflows
• -> test if ontology/shacl parses successfully --> introduced ci pipeline
• -> test if example .json complies with shacl property definitions (schema) --> introduced ci pipeline
• Add gaiax ontologies as sub repository and link resources in readme
• -> GaiaX definitions are provided as json and not as a repo
• -> we add an extra folder to the repo named e.g. "gaiax" with a readme and original json plus pthon converter to .ttl
• Can we discuss some structural elements used in the old demo as Carlo thinks it is useful
• -> token meta data

[robertschubert]

regarding
"test if example .json complies with shacl property definitions (schema)"

This task is simple for shapes that do not reference "external" shapes.

Example:

prefix:SomeShape a sh:NodeShape ;
    sh:property [ sh:minCount 1 ;
            sh:node gx:PostalAddressShape ;
            sh:path general:myAddress;
            sh:order 5 ] ;
    sh:targetClass general:General .

With this syntax you would be able to reference an "external" gx:PostalAddressShape. The validation in the Federated Catalogue is no problem as long the gx:PostalAddressShape was uploaded before. All shapes are loaded for validation in the Federated Catalogue upfront.

In the context of this repository we will not have access to gx:PostalAddressShape so no validation against this shape is possible.

[jdsika]

Can the shapes also be uploaded somewhere more independend from EDC? Reference to a URL? I don't want to use custom software to access the shapes. Just a trusted source.

[robertschubert]

Task "-> test if ontology/shacl parses successfully":
solved with PR #58

[robertschubert]

Can the shapes also be uploaded somewhere more independend from EDC? Reference to a URL? I don't want to use custom software to access the shapes. Just a trusted source.

@jdsika not sure if I understand the question. Which subtask are you referring to? Or where do we have a link to EDC in this issue / repository?

[jdsika]

I am sorry, I was reading this comment and may have misunderstood it? It was regarding "where" are the ontologies uploaded to in order to have a source for the validation.

With this syntax you would be able to reference an "external" gx:PostalAddressShape. The validation in the Federated Catalogue is no problem as long the gx:PostalAddressShape was uploaded before. All shapes are loaded for validation in the Federated Catalogue upfront.

[robertschubert]

I am sorry, I was reading this comment and may have misunderstood it? It was regarding "where" are the ontologies uploaded to in order to have a source for the validation.

With this syntax you would be able to reference an "external" gx:PostalAddressShape. The validation in the Federated Catalogue is no problem as long the gx:PostalAddressShape was uploaded before. All shapes are loaded for validation in the Federated Catalogue upfront.

The source for validation is the federated catalogue. Ontologies and shapes must be uploaded so the catalogue knows what an HdMap is (as an example). The validation against the shacl shape is then done in the federated catalogue when someone uploads a self description containing an HdMap.

Since we now have a working (because fixed) gx ontology in our repo I will also have access to the PostalAddressShape in the context of this repo.
So it should work out to load all existent SHACLs and validate one json-ld against all loaded shapes. I will have a look.

[robertschubert]

Task "-> test if example .json complies with shacl property definitions (schema)":
solved with PR #58

[robertschubert]

@jdsika
my proposal is that I create a new Issue for
Rename: VARAIBLES -> prefix_properties.md OR PROPERTIES.md
See #71

After the open branches are merged I will make the change.

Is there anything else that has to be done in this Issue or can we close it?