Closed bertvannuffelen closed 2 years ago
@bertvannuffelen An alternative could be to define the property as follows:
dcat:service
Definition: a data service that is listed in the catalog.
(with the cross-reference)
I think it makes sense to point to some of the data services via dcat:service from the catalog and to some only via dcat:accessService from distributions. It provides a distinction between those data services that are "stand alone" (potentially serving many datasets) and those that are more a technicality of a distribution.
@bertvannuffelen if other agree with this position I think that this could merit a difference in definition. At least to state that it is allowed to have a data service that is only referenced to from a distribution. (I cannot easily read this into the current definitions though.)
I agree. In ISO 19119 terms, there are services that are 'tightly coupled' to a dataset, and I'd argue are essentially distributions of that data, and services that provide functionality that can work with many datasets, as long as they are accessible via the API&interchange format that the service understands. Services in this second category should be described as services, and specify the interface/interchange format(s) they use. Services of the first type are more usefully documented in a dataset catalog as distributions of a dataset.
@matthiaspalmer and @smrgeoinfo, with this request I only wanted to highlight the difference between the definition of the property dcat:service and the class dcat:DataService. I did not intended to initiate a discussion on the nature of data service vs distributions.
My observation is that because of this distinction (which for the similar pair dcat:dataset + dcat:Dataset does not exists) there exists thus a possible ambiguity. Namely is A site or end-point that is listed in the catalog
identical to A collection of operations that provides access to one or more datasets or data processing functions.
?
From your comments, I get that you interpret that dcat:service should point to a subset of all dcat:DataService's in a catalogue? Namely only the standalone ones? That is an interpretation which I never had made. Namely I always have interpret dcat:dataset as the shorthand for the path dcat:record/foaf:primaryTopic having as range dcat:Dataset. And thus likewise dcat:service as the shorthand for the path dcat:record/foaf:primaryTopic having as range dcat:DataService.
If there is a more subset oriented interpretation then this is really non-obvious and hard to explain. It sounds really arbitrary that for dcat:service a subset is intended and for dcat:dataset not. Any specific interpretation at this level I would propagate to DCAT profiles.
@bertvannuffelen fair point, I was only voicing my thoughts on a possible reason for having two different definitions. But, looking at the definitions again I agree with you that the current definitions cannot (easily) be interpreted like that. Also, the distinction that I am suggestion would fit better in a usage note than in a definition.
Hence, I just created a separate issue to discuss it further. @smrgeoinfo maybe you can provide your feedback there instead, it would be much appreciated.
For me, I expected a definition similar as @makxdekkers suggested.
The definition of dcat:service
has been revised accordingly via PR https://github.com/w3c/dxwg/pull/1466
Closing.
The definition of dcat:service is
Why is the definition of dcat:service not: A data service that is listed in the catalog? As for me, there are now two "definitions" for Data Service: one via the property and one via the class.
Unless dcat:service is intented to relate to a subset of entities of all dcat:DataServices, I'd do not see the need to make such difference.
Observe that for dcat:dataset and dcat:Dataset both are using the same 3 words: "a collection of data". In that spirit one could state as definition for dcat:service " A collection of operations that is listed in the catalog".