search

SEMICeu / DCAT-AP

This is the issue tracker for the maintenance of DCAT-AP
https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
74 stars 24 forks source link

Cardinality of dct:type in DCAT-AP (PDF) specification #153

Closed aidig closed 2 years ago

aidig commented 4 years ago

I noted the mismatch in the cardinality of the DCAP-AP specification and the SHACL constraints in version 2.0.0 in this (closed) issue, stating that the SHACL implementation would reflect the DCAT correctly and that the PDF specification should be amended.

Instead the SHACL file in version 2.0.1 has been changed and now restricts the use of dct:type to a maximum multiplicity of 1 although DCAT clearly states that "It is also possible for multiple classifications to be present in a single description".

Please see section 5.5 Classifying dataset types in DCAT 2.0: https://www.w3.org/TR/vocab-dcat-2/#classifying-dataset-types

Hence the cardinality should not be 0..1 for this property.

What are the arguments for changing the SHACL contraints and not the PDF specification here? https://github.com/SEMICeu/DCAT-AP/issues/126

bertvannuffelen commented 3 years ago

@aidig the restriction has been already in DCAT-AP 1.2.1. So it is an additional restriction of DCAT in the context of DCAT-AP. With the closed issue we addressed the incoherence between the human readible and machine readible specifications.

Your comment

Hence the cardinality should not be 0..1 for this property.

contains an underlying question for me: can DCAT-AP put additional constraints on DCAT? For me, this is the purpose of DCAT-AP: namely to add constraints to DCAT so that it is better fitted for the Open Data Portal community in Europe.

Then to the motivation of the restriction itself: I think the original objective was to capture only one aspect of categorisation of datasets, and that this categorisation is determined by the concepts in one conceptscheme. If I remember right, the Publications Office requested this ability in the context of the EU ODP. According to the DCAT-AP specification there is no concept-scheme being created yet, but when exploring the PO NAL list I find this: https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/dataset-type.

Questions are thus:

aidig commented 3 years ago

Indeed DCAT-AP should definately be able to put additional contraints on DCAT in the context of this specific application for data portals in Europe in general (and not limited to EU ODP). So, in other words, while there could be benefits for the data portals in Europe using the same concept scheme to classify datasets according to their type, what are the benefits of not permitting datasets to be classified separately using values from different vocabularies as well?

H-a-g-L commented 2 years ago
  • do we include the above list as (recommended/mandatory) codelist?

+1 to adding the dataset-type authority table as a recommended codelist.

Indeed DCAT-AP should definately be able to put additional contraints on DCAT in the context of this specific application for data portals in Europe in general (and not limited to EU ODP)

The distinction between EU Open Data Portal and European data portal is indeed redundant, especially since the two portals are now consolidated.

DCAT-AP is already defined as as lemon:context for the following terms:

bertvannuffelen commented 2 years ago

wg 21 Oct 2021 decided to lift the max-cardinality constraint to allow multiple values add the https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/dataset-type as recommended controlled vocabulary.