Unclear to me if dcat:dataset rdfs:subPropertyOf dcterms:hasPart . makes sense.
The relationship is more like membership (rdfs:member, skos:member, inverse-of-dcterms:memberOf) than partition?
(the documentation of dcterms:hasPart is ambiguous on this though).

Also see #116

I would vote to keep the domain and range here -- this property is one of the properties that are part of the backbone structure of DCAT:
Catalog > dataset > Dataset > distribution > Distribution

Subproperty of dct:hasPart, given the definition at DCMI, sounds fine to me.

I have in mind the distinction between part-whole or subset, and membership.
See https://en.wikipedia.org/wiki/Mereology
I find the DCMI definition confusing. We shouldn't be held hostage to sloppy work elsewhere ;-)

I'm convinced by Makx' argument that the domain and range here are part of the DCAT backbone.
No change needed.

If I'm the only one advocating dropping the sub-property axiom, then I'll yield on that.

I'll bring this proposition to the next DCAT team telecon for resolution.

There's a use case from GeoDCAT-AP, mentioned in #166 (comment), that could motivate relaxing the domain restriction of dcat:dataset.

I copy-paste here the explanation posted at #166 (comment) :

How to model [the relationship from a service (metadata record) and the data accessible from it] was one of issues discussed in the development of GeoDCAT-AP. The adopted solution was following from the decision of considering dcat:Catalog as a type of service (corresponding to a geospatial catalogue service, as a CSW). dcat:dataset was then the proposed property for linking any type of data service with a dataset. However, as the domain of dcat:dataset is restricted to dcat:Catalog, the decision was to use instead dct:hasPart (as dcat:dataset is a sub-property of it).

In Geoplatform, we are using dcat:dataset to relate a map layer to its dataset it represents, which is very useful for traceability. For example, you could ask what layers are derived from a given dataset. For this reason, I would relax the domain restriction of dcat:dataset by removing the axiom.

@andrea-perego I think we can do better, and have an explicit link from a service to the datasets that it serves. In my proposal for a Data Service class it is provisionally called dcat:servesDataset.

@fellahst I would argue that your appropriation of dcat:dataset for that purpose was inconsistent with its axiomatization. It entails that your map layer is a dcat:Catalog which makes little sense. I find @makxdekkers argument that there is a DCAT backbone convincing. If we need other links to dcat:Dataset we should model them properly.

+1 to no change

+1 to not change dcat:dataset

https://www.w3.org/2018/03/21-dxwgdcat-minutes
resolved: no change to domain/range of dcat:dataset