Closed bertvannuffelen closed 2 years ago
Please note that the use of dct:title
with skos:ConceptScheme
and skos:prefLabel
with skos:Concept
is a normal practice followed by most of the existing SKOS thesauri, code lists, etc. This is based on the examples included in the SKOS specifications - see, e.g., the following example in §3.1 of the [SKOS-PRIMER]:
ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
dct:title "Extensive list of animals"@en.
ex1:animal rdf:type skos:Concept;
skos:prefLabel "animal"@en;
skos:inScheme ex1:referenceAnimalScheme.
ex1:platypus rdf:type skos:Concept;
skos:prefLabel "platypus"@en;
skos:inScheme ex1:referenceAnimalScheme.
If the constraint is going to be changed, this should be taken into account. E.g., an option is to specify an sh:or
constraint, requiring the presence of either dct:title
or skos:prefLabel
.
The reason for this is that it seems not to be the default by the Publications Office. I checked one NAL: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/data-theme , and the practice is there not to add dct:title but using skos:prefLabel. So this rule actually fails each time.
I am not in favor to add complex obligations. They are hard to check (and maintain).
In general, the challenge is that with this constraint embodies is that DCAT-AP aims to impose quality constraints on controlled vocabularies: on entities that are managed outside the control of the DCAT-AP specification, the dataset publishers and often the data portals too, since we aim to reuse controlled vocabularies managed by external organisations. Some are accessible like the Publications Office, but some are harder to connect to like IANA, or spdx. This leads to the challenge: shall the DCAT-AP community create (and maintain) reflections of those controlled vocabularies according to its own specification requirements or shall it adapt itselves so that "incompatible" external sources can be used. Both are viable, it depends on the case. And in this issue, the proposal is more towards the second.
This change will impact the Data Portal builders: they would like to get an easy way to know the value they have to put in the label of the widget. I doubt it will impact the dataset publishers.
@bertvannuffelen said:
The reason for this is that it seems not to be the default by the Publications Office. I checked one NAL: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/data-theme , and the practice is there not to add dct:title but using skos:prefLabel. So this rule actually fails each time.
Yes, I know. The NALs are not aligned with the general practices I mentioned above.
I am not in favor to add complex obligations. They are hard to check (and maintain).
In general, the challenge is that with this constraint embodies is that DCAT-AP aims to impose quality constraints on controlled vocabularies: on entities that are managed outside the control of the DCAT-AP specification, the dataset publishers and often the data portals too, since we aim to reuse controlled vocabularies managed by external organisations. Some are accessible like the Publications Office, but some are harder to connect to like IANA, or spdx. This leads to the challenge: shall the DCAT-AP community create (and maintain) reflections of those controlled vocabularies according to its own specification requirements or shall it adapt itselves so that "incompatible" external sources can be used. Both are viable, it depends on the case. And in this issue, the proposal is more towards the second.
This change will impact the Data Portal builders: they would like to get an easy way to know the value they have to put in the label of the widget. I doubt it will impact the dataset publishers.
I think there are two options here:
About option 2, I understand the concern about maintenance and consistency, but you cannot help it in a distributed context.
Concerning the EDP issue, it may be worth checking with the team. However, I don't think this is a problem: dealing with exceptions is what the EDP has always been doing.
We would vote for option 1. If the AP says, it is mandatory to use a specific external vocabulary, someone who wants to build a portal around this will have to check the vocabulary and decide, which information they want to pull into the portal. If we think that the vacabulary does not fit the usecase because essential attributes are missing, we shouldn't make it mandatory to use.
dct:title property will be added skos:ConceptScheme of EU Vocabularies used in DCAT-AP (Named Authority Lists maintained by Publications Office of the European Union). The revision is scheduled for the 16/06/2021 publication.
@ODP-hil, in order to close the ticket, I looked to https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/data-theme. Maybe I have overlooked it, but it seems not been executed.
Speaking from OP side. We do intend to have both dct.title and skos:prefLabels added but it was not really planned for a particular publication and definitely not for all the NALs at a specific time. There are more than 100 and each of them with their own cycles. Refreshing them all just for the labeling the conceptScheme is not something that we had considered. Will try anyway to proceed with that but it is hard to give a specific deadline. If there are any particular emergencies will be good to know in order to advance with those.
@MPaunescu thanks for the update.
The June 16th publication of EU controlled vocabularies includes the addition of dct:title
to the following Authority Tables used in DCAT-AP:
This issue is considered fixed, as the responsible party, i.e. Publications Office, has accepted to take care that these expectations are satisfied.
motivation:
Since skos:ConceptsScheme follows the SKOS guidelines, the title of a conceptscheme is expected to be the skos:prefLabel property and not dct:title.
proposal: make the dct:title property optional (or even dropping) and adding skos:prefLabel as optional.