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

[editorial] 14.2 Usage guide on Dataset Series #354

Open jimjyang opened 4 months ago

jimjyang commented 4 months ago

Since the class Dataset Series in DCAT-AP now is not a subclass of dcat:Dataset but dcat:Resource, I think several of the bullet points in 14.2 Usage guide on Dataset Series need to be rewritten, especially the 3rd one about distributions (thus also the last sentence in the 4th one), the 5th one about data services, some parts of the 6th one (Dataset series being a member of Dataset series), the last one about metadata quality.

bertvannuffelen commented 3 months ago

@jimjyang in DCAT-AP we aim to focus Dataset Series on its unique aspect: namely grouping a sequence of Datasets. Therefore we do not impose that a DCAT-AP Dataset Series is a DCAT-AP Dataset, but it is not excluding that possibility.

Catalogue owners can still decide to interpret a Dataset Series as a Dataset. But in that case the additional constraints of DCAT-AP Dataset preferably apply. In this case the Dataset Series is more than a grouping element but an collection of data itself. That additional interpretation may create semantical conflicts or complex expectations (bullet point 3 and 5 try to address these), but since there was not yet sufficient consensus to limit the usage of Dataset Series to a single specific approach it is left to the publishers to resolve the emerging semantical conflicts.

matthiaspalmer commented 2 months ago

@jimjyang @bertvannuffelen. I think DCAT-AP 3 should be corrected and indicate that dcat:DatasetSeries is a subclass of dcat:Dataset as that is the most specific class it inherits from. I remember the discussion around this being somewhat convoluted and maybe I missed the conclusion or even voted wrong, I apologize if this is the case.

I think that as DCAT-AP claims to be an application profile, it should NOT CHANGE / RELAX any of the classes or properties it reuses (with respect to subclass relationships, ranges etc.). It may though further RESTRICT properties ranges in a softer sense, i.e. something like "in the context of this application profile the property is expected to only have values from this subclass".

DCAT 3 claims that dcat:DatasetSeries is a subclass of dcat:Dataset, which in turn is a subclass of dcat:Resource. Hence, that the statement in the specification is not false, but I think it is misleading in the sense that it somehow indicates that the application profiles tries to do something it is strictly not allowed to do, i.e. relaxing a restriction.

Lets take an easier example to show how wong this is from a semantic perspective. An organisation O has introduced the classes o:FourWheeler and o:TwoWheeler as subclasses of the class o:Vehicle. In addition they have introduced the subclass o:Bike as a subclass of o:TwoWheeler. Now another organization want to reuse the class o:Bike, but decides to indicate that in their view of things o:Bike is a larger thing. Hence they claim o:Bike to be a subclass of o:Vehicle instead of o:TwoWheeler. People using this application profile (without checking the details of the original class declarations) will now happilly treat cars as bikes.

jimjyang commented 2 months ago

I also have difficulties to see why DCAT-AP 3 doesn't follow DCAT 3 here. It makes it more difficult to use, see e.g. also my comment https://github.com/SEMICeu/DCAT-AP/issues/348.