IDS Communication Guide v2

[sebbader]

The works around the next version of the IDS Communication Guide touch a number of aspects of the information model. Let's use this discussion to bring them to the table and to document our decision process.

[sebbader]

1. dcat:Dataset:
   Is there a reason why (1a) only ids:DigitalContent inherits from dcat:Dataset, and (b) why does dcat:Dataset not replace ids:Resource completely? Or asked the other way around, does ids:Resource bring additional definitions at all?

[clange]

@lcomet @JohannesLipp can you answer this question based on what you have learned and studied in the FDS T60 and T66 projects, in other words, #591?

[sebbader]

2. dcat:Distribution: why not replace ids:Artifact with it?

[clange]

@lcomet @JohannesLipp same question as above – can you answer this?

[lcomet]

Considering the following points, we could replace ids:Artifact by dcat:Distribution:

• In DCAT 3 the property spdx:checksum is defined (Note in the DCAT 3 specification: This is the usage note in [DCAT-AP]. To be decided if it should be adopted in DCAT.)
• The following properties are equivalent: ids:fileName and dcat:title, ids:byteSize and byte size
• In the infomodel we have ids:duration. Instead we could use dcat:temporalResolution which is encoded in xsd:duration
• ids:representationStandard is defined as subPropertyOf dct:conformsTo which is already covered in DCAT 2
• ids:Artifact is a subClassOf odrl:Asset, possibly to indicate that it is part of a collection of assets. Also, by using the ODRL vocabulary, it is possible to describe policies (duties, obligations). However, this is covered already in DCAT 3: https://www.w3.org/TR/vocab-dcat-3/#license-rights

[sebbader]

3. odrl:Policy, odrl:Offer, odrl:Request, odrl:Agreement: Can't we take the directly instead of ids:Contract,ids:ContractOffer, ids:ContractRequest, and ids:ContractAgreement? The original motivation was that the IDS classes extend the original meaning too much. But again, I don't see a fundamental added value in the definitions (anymore)...

[clange]

@lcomet @JohannesLipp same question as above – can you answer this?

[sebbader]

4. Generally speaking, some classes are "in the air" for me, for example ManagedEntity, DescribedSemantically, and so on. They are used by one or two rdfs:subClassOf relations, but these relations don't really add value for the subclasses. Can't we omit those?

[clange]

AFAICT we introduced just to modularize the maintenance/engineering of the ontology.

E.g., ManagedEntity is needed to accommodate the version property. Looking at this class with just one property, this may appear over-engineered, but I think in general the approach makes sense.

Same for DescribedSemantically and its property shapesGraph.

[clange]

To complete this: Indeed we have meanwhile understood that we can get rid of these classes and fall back to plain DCAT. However, we considered these changes breaking and thus have not yet merged them into develop.
More specifically, the changes regarding ManagedEntity are under commit 0e580bf, and the changes in the class DescribedSemantically are under commit e7c3300

[sebbader]

5. What's the general approach towards the Gaia-X information model? Are the core entities still mappable? If so, where can we get an overview?

[clange]

In what will become Gaia-X release 22.11 (cf. latest version of the Trust Framework), there is now a Data Resource class, defined to extend dcat:Dataset. Further alignment of Gaia-X with DCAT, e.g., including DataService, is in progress – please see the Data Exchange specification for some ideas about that, and see https://gitlab.com/gaia-x/technical-committee/service-characteristics/-/issues/101 for further steps planned.

On the IDS side, we are continuing the alignment with DCAT. Previous work has focused on dcat:Dataset. Next steps will include dcat:DataService (which had not existed when the core of the IDS Information Model was defined).