Open sabinem opened 3 years ago
Isn't it a opendata.swiss issue too...? What would be the consequence of removing this property? I am convinced it should be removed, but we should also think about the consequences..
The reason that dct:coverage
exists on the dataset is the lack of support for polygons in [dct:spatial
(https://dcat-ap.ch/releases/2.0/dcat-ap-ch.html#dataset-coverage):
It is not possible with dct:Location to provide a polygon as geographical coverage, therefore dct:coverage should be used for this purpose (§ 7.3.14 Property: coverage)
So this part:
In this case the DCAT properties dct:spatial and dct:temporal are able to completely replace dct:coverage on dct:Dataset.
is not true.
Of course we could decide that the range of dct:Location
(that dct:spatial
provides) is enough and arbitrary polygons are not necessary. But I think it's important to have the full picture why this property was added in the first place.
In #61 it is stated that dct:spatial
now supports polygons (via GeoDCAT). If this is the case, forget my previous comment and get rid of dct:coverage
😁
I would need an example of a Dataset/Ressource at hand to be able to understand from a user's pespective what need(s) we want to cover with this change.
Hi @andreasamsler, in this case there wouldn't be a big change for the user. The catalogue would be structured slighlty differently, so that the information may (it depends how opendata.swiss would implement this change) be presented in slightly in a different way. It's way more a compatibility issue with DCAT-AP: this value does not exist there and this kind of information is carried through dct:spatial and dct:temporal instead. This may lead to issues like the information is not made available on data.europa.eu.
(Note that I'm not taking into account the topic "dcat:Distributions Usage note should not encourage the usage of Distributions as Dataseries #112", since it's only indirectly linked to it).
@metaodi and @andreasamsler I have launched a discussion about this topic of modeling a Series as Distributions on DCAT-W3C: the suggestions there are quite good. Feel free to jump right into that discussion: https://github.com/w3c/dxwg/issues/1429
For dct:coverage
on dcat:Dataset
I created a new issue, since this case is more clear and can be decided already, whereas
the case of dct:coverage
on dcat:Distribution
is harder to solve until DCAT and DCAT-AP over support for the related use cases.
dct:coverage
on dcat:Dataset
: https://github.com/opendata-swiss/dcat_ap_ch/issues/189 dct:coverage
on dcat:Distribution
. I also added a changed proposal. Please let me know what you think about this: should it replace the original proposal?I think we should include this proposal in 3.0.0 to a) make clear dct:coverage should not be used for DatasetSeries b) make sure #214 is adopted as well, which actually add the new DatasetSeries class
Update: I think we should close this issue and use the proposal in #112 instead.
Property: dct:coverage Class:dcat:Dataset and dcat:Distribtution Conformance Problem:
dcat:Distribution
there is no DCAT property to replacedct:coverage
. But this is because Distribution properties all relate to resolution, format, size, language, etc. that is to properties that refer to the same content in different physical representations. On opendata.swissdct:coverage
is used to model dataseries as distributions of a dataset. But this considered bad practice in DCAT-AP, see https://github.com/opendata-swiss/dcat_ap_ch/issues/112Proposal:
dct:coverage
ondcat:Distribution
and encourage the use ofdcat:DataSeries
(https://www.w3.org/TR/vocab-dcat-3/#Class:Dataset_Series) as soon as it is ready to be added to DCAT-AP CH. This has to be done in correspondence with https://github.com/opendata-swiss/dcat_ap_ch/issues/112Changed Proposal: Watch what happens on DCAT-AP and DCAT regarding the modeling on Series of Data, since this seems to be a topic where there is some movement in the DCAT community.