search

International-Data-Spaces-Association / InformationModel

The Information Model of the International Data Spaces implements the IDS reference architecture as an extensible, machine readable and technology independent data model.
Apache License 2.0
64 stars 37 forks source link

DCAT-conforming title and description for all infomodel terms #530

Open clange opened 2 years ago

clange commented 2 years ago

In the same direction as discussed in #521 it turns out that for the Eclipse Dataspace Connector each term in the infomodell needs to have (in conformance with DCAT) a dct:title and a dct:description. So far we have had a good coverage, but using rdfs:label and rdfs:comment. The decision to be taken (@sebbader what do you think from a Java perspective?) is to either replace the RDFS properties, or to introduce the DCAT/DC properties additionally, redundantly. The latter should then be supported by automated generation or at least validation to avoid out-of-sync issues.

sebbader commented 2 years ago

Reading through https://github.com/International-Data-Spaces-Association/InformationModel/issues/521, I think the requirement is not to replace the RDFS terms but to enhance them with additional attributes to give the instances also "title"/"description" capabilities. On the Java-side, we already have an artificial top class, from which all other classes inherit, and this class can have these attributes (Option a). Or, Option b, we can simply add the two properties to all "lower" classes.

JohannesLipp commented 2 years ago

Please note that #504 replaces all existing ids:title with dct:title, and ids:description with dct:description. This (following this comment and the subsequent discussion) is probably already fully supported by the Java Lib.

image

What is the remaining task here? Do you want to enforce everything in the IDS to have at least one dct:title and dct:description or shall this be only mandatory for some but optional for most others (as we already do it currently)?

sebbader commented 2 years ago

Hi @JohannesLipp, I think the output should be a bit different, using https://github.com/International-Data-Spaces-Association/InformationModel/blob/refactorIDSModel-enhancement/model/infrastructure/AppStore.ttl as an example:

ids:AppStore
    a owl:Class ;
    rdfs:subClassOf ids:Connector;
    rdfs:label "App Store"@en ;
    rdfs:comment "Secure platform for distributing Data Apps."@en.

dct:title a owl:DatatypeProperty ;
    rdfs:label "title" ;
    rdfs:domain  ids:AppStore ;
    rdfs:range xsd:string ;
.
dct:description a owl:DatatypeProperty ;
    rdfs:label "description" ;
    rdfs:domain  ids:AppStore ;
    rdfs:range xsd:string ;
.

And that for every class that is "important enough". Then of course dct:title rdfs:domain ids:AppStore is a bit stupid because it would need to be repeated for every class... Maybe:

dct:title a owl:DatatypeProperty ;
    rdfs:label "title" ;
    rdfs:domain  owl:Class ;
    rdfs:range xsd:string ;
.
dct:description a owl:DatatypeProperty ;
    rdfs:label "description" ;
    rdfs:domain   owl:Class ;
    rdfs:range xsd:string ;
.

or some other way to connect it "as high as possible" at the abstract classes we use?

JohannesLipp commented 2 years ago

The precise task might be: Scan through all important classes and properties in the IDS infomodel and ensure that they have both dct:title and dct:description. In most cases, we could copy the values from rdfs:label and rdfs:comment, respectively.

(awaiting answer in #521 )