gaia-x4plc-aad/ontology-management-base

Our implementation for an open automated ontology management process for GAIA-X interoperable ecosystems. Please use a community agreed domain specific class or if not yet available please create a new class and submit it for review.

ontology-management-base's Issues

add metadata.jsonld files as test vectors for each ontology

All domain-specific shapes should embed GeneralShape

reference to general-namespace should be included

LICENSE MISSING

I actually lean towarld MPL-2.0

Update: Due to the input I am ok with EPL 2.0

Proposal: Create proper specifications

https://github.com/ASCS-eV/EVES/

404: not found

@Prefix gax-trust-framework: http://w3id.org/gaia-x/gax-trust-framework#

TODOS discussion 06.05.2024

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

Issue on Surface Model Ontology

@3Dbastian @MircoNierenz @JustinDxx @jtdemer
refers to Pull Request
#14
The field origin in the SHACL is defined with a single float value, but two or threes coordinates are needed.

Ideas on the solutions:
(i) is it better within the xsd datatypes to have an string with a defined format to represent the coordinates
(ii) shall we define minCount ==2 and maxCount ==3
(iii) is there a available data type to define a numeric tuple within xsd

This questions is similar to the problem in this issue:
https://github.com/GAIA-X4PLC-AAD/map-and-scenario-data/issues/6#issue-2175811114

Scenario Ontology: Link to OpenDRIVE map

I am looking at the following element:

"scenario:trafficSpace": {
      "@type": "general:Link",
      "general:url": {
        "@value": "https://inavlid.link.com/my_map.xodr",
        "@type": "xsd:anyURI"
      },
      "general:type": "Document"
    }

I think a map is its own asset with its own meta data description. In this case we would depend with a scenario on a map that has already been instantiated as a separate asset and should be referenced through the asset id?

Maybe @lenasauermann has an opinion here as well?

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

@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:)

Incomplete examples like skos:example "nan"

At least in ontology environment-model there are a bunch of skos:example with the value nan.

TODO:
either place a reasonable example instead of nan or remove the example at all.

Arised from PR: #31

Separate SHACL-shape for 'Georeference'

The PLC-specific SHACL-shape for domain-specific metadata of scenarios includes attributes regarding georeferences. As aligned in AP 3.3 / data-provider-meeting, we would like to use those attributes also for other data categories in a similar way. Therefore we need a separate folder, ontology and SHACL-shape for georeference.

I will delete the georeference-related parts from the scenario-SHACL and copy it hereby. Please take it as a starting point for the new shape.

Using ontology for metadata definition of sensor models

Would it be possible to use the definitions in the sensor shacl to validate an SRMD file? Is there any tooling for that?

An example of an SRMD file according to the specification developed in the SETLevel research project can be found here.

Ontologies & SHACL-shapes for OpenLABEL

We need to create both ontology and SHACL in order to use OpenLABEL for our extended metadata.

Right now, I already created an ontology-draft for OpenLABEL in separate branch, s.:
https://github.com/GAIA-X4PLC-AAD/ontology-management-base/blob/openlabel-ref/openlabel/openlabel_ref_ontology_extended.ttl

The SHACL-shape is yet missing.

@heuerfin, I saw your comments and suggestion in scenario pull request #6

As this pull request is dedicated to our custom extensions from PLC-AAD or SRMD/SetLevel I would like to keep OpenLABEL out there for a moment. Can we further elaborate OpenLABEL specific issues here and the openlabel_ref branch from above?

Generally speaking, my suggestion would be to nest OpenLABEL under scenario-metadata but separate to SRMD-extension and our PLC-AAD specific content. Therefore, it seems easier to me reusing OpenLABEL-parts also for other domains like maps and sensor-data.

What would you think?

Refactor shacl shapes to reduce duplication

As discussed with @jtdemer and @rcrswld we should refactor the shacl shapes to reduce duplication of shapes.

As an example there is a BoundingBoxShape duplicated in several other ontologies.

As I understood there will be a new GeoReferenceShape (name might sligtly change) where those geo informations will be encapsulated. After that this new shape can be encapsulated into the another ones with something like this:

     [ sh:minCount 1 ;
            sh:node geo-reference:GeoReferenceShape ;
            sh:path environment-model:geoInformation;
            sh:order 1 ] ;

Add information about file size n general metadata?

Should we include information about the file size of the data in the metadata?