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
76 stars 24 forks source link

Class `dct:Location` In Conflict With Controlled Vocabularies #266

Closed init-dcat-ap-de closed 3 months ago

init-dcat-ap-de commented 1 year ago

dct:spatial in Catalogue, Dataset and Dataset Series has as range dct:Location, but on the same time, dct:spatial MUST be used with an controlled vocabulary:

grafik (Minor bug: DatasetSeries is missing.)

Proposal: Unclear. Maybe these CVs can't be mandatory? Or we should make it more clear, when the class should be used and when a NAL/Geoname has to be used.

While I would prefer the use of Geonames/EU-NALs for known locations over their "raw geometrie", neither http://publications.europa.eu/resource/authority/place/DEU_BER nor https://sws.geonames.org/2950159/about.rdf (or https://sws.geonames.org/2950157/about.rdf ) include the polygon. So a data portal would have to have its own gazetteer to display Datasets "only" tagged by URIs on a map. That could be okay, but should be some we keep in mind (and probably should explicitly state somewhere).

bertvannuffelen commented 1 year ago

Some properties have as specific class as range e.g. dct:Location, dct:LinguisticSystem, ...

That will not prevent the use of controlled vocabularies for these. One can be a skos:Concept and a dct:Location at the same time.

The problem sits them in the expected validation process: A concept https://sws.geonames.org/2950159/about.rdf will probably have not itself declared as being a member of a dct:Location. It even might have not declared itself as a skos:Concept. Nevertheless in using these URIs in the context of DCAT-AP this class membership can be inferred / assumed / externally be imposed.

In general instance collections might not satisfy the "formal" rules of a proper code list, but in the practice they can be considered as if they would satisfy them.

Despite I would prefer that the all codelists would follow the same minimal publication requirements, I think we should also be practical that in some cases there are codelists maintained in a form that is not 100% formally compliant. If geonames URIs provide the coverage of the spatial needs and geonames is properly maintained, then I am inclined to enforce it rather than opening the space of other controlled vocabularies with a lower quality. Nevertheless if there is an alternative that better fits the formal requirements, then it is of interest to make a switch.