Data catalogs should not treat services as first class citizens

[davebrowning]

(Issue created to track comments received on Second PWD of DCAT Recommendation from Clemens Portele - email archived here)

The rationale for making services first class citizens in data catalogs is not clear to me. The model of DCAT 1.0 is in this area, in my view, clearer and more useful from an end user perspective. The items registered in a data catalog should be restricted to data (that is: datasets - unless you register individual items). As a user I go to a data catalog looking for datasets, not services; once I have found some candidate datasets then I want to understand how to access the data, whether that is a file download, through webpages or an API. This relationship is described in the Data on the Web Best Practices (https://www.w3.org/TR/dwbp/#context), too.

While DCAT 1.0 does not provide sufficient detail or guidance for documenting the different kinds of distributions. A downloadable file is straightforward, but an API could benefit from more information than what DCAT 1.0 supports. From the UCR document I expected that the revision of DCAT would improve Distribution instead of adding Services as additional, separate resources in the mix. The separation between Distribution and Service looks blurred to me, with overlap and redundancies in their properties. Please reconsider this design decision.

In my view, the current direction is repeating some of the mistakes that the spatial data community made in their standards.

[agbeltran]

Including here an extract of other comment received from Luca Trani (message available here) with reference to data services and more clarifications needed:

"In particular, the introduction of additional resources (beyond Dataset) as first-class citizens in a Catalogue was definitely required and we accommodated that by extending DCAT 2014. My view is that in the context of RIs catalogues have an essential role to represent a variety of assets -- having the focus only on Dataset would be too restrictive. Therefore, I am pleased to see that there is a dcat:Resource in this new version. Also, two specialisations of a dcat:Resource are provided: Dataset and DataService. I assume that more might be added to extend the scope of a Catalogue when needed. Am I correct? Do you support composition of resources? Would that be covered by dct:relation?
Also, I would be interested in the approach you are considering to tackle Issue 66 and Issue 71.

Another important feature for us is the support for Data Services. I like your solution and I would like to understand a bit more about how to deal with a service that is providing multiple datasets e.g. by different methods/operations. I agree that the description of a service, via dcat:endpointDescription, should be as much as possible relying on dedicated description standards (e.g. WADL, OpenAPI/Swagger, OpenSearch). However, in some cases where such descriptions are not available a templating approach might be useful. In our case, while promoting the first approach, we also provided an alternative by embedding the W3C Hydra Vocabulary. For instance, Templated Links can be used. Hydra offers quite extensive descriptions although its status (Unofficial Draft) makes its adoption and future support unclear."

[dr-shorthair]

how to deal with a service that is providing multiple datasets e.g. by different methods/operations.

1. There is no cardinality constraint on the dcat:servesDataset property, so a single service can provide access to multiple datasets
2. if multiple APIs are available, I would suggest describing these as multiple service instances, even if the endPointURL is the same.

[dr-shorthair]

Response to Clemens Portele
https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jan/0000.html

[davebrowning]

As notified/discussed: https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2019.04.02