Open JohannesLipp opened 4 years ago
Overview of DCAT-AP constraints and their implications to the IDS Infomodel
Concept
skos:prefLabel 1..*
ids:Concept
is abstract, but never used. How to continue?skos:ConceptScheme
dct:title 1..*
rdf:Resource
dcat:Catalog
Catalog
dct:description 1..*
, dct:title 1..*
, dct:publisher 1..1
ids:Catalog
differently from DCAT, as we do not specify these fields explicitly.DigitalContent
and Representation
dcat:accessURL 1..1
ids:accessUrl
with dcat:accessURL
DigitalContent
(and its subclass Resource
)dct:description 1..*
, dct:title 1..*
dcat:DataService
, dcat:CatalogRecord
, dcat:Relationship
spdx:Checksum
ids:checkSum
instead), is optional anywayFor all ids
terms, we need to introduce idsm:notNull
annotations. Also, we need to integrate the above-mentioned restrictions into SHACL shapes.
@JohannesLipp as #391 was merged, could you please clarify what still remains to be done in order to achieve full DCAT-AP compatibility? To my understanding we are ready in a technical sense but need to discuss whether in a general IDS environment it will make sense to enforce the same "mandatory attributes" as DCAT-AP does. DCAT-AP compatibility is increasingly being requested, see https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/issues/90.
The following steps would be required to do so:
Assure full compatibility for the DCAT application profile (DCAT-AP) of the European Union in version 2.0.0 (https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/release/200).