Data catalogs should not treat services as first class citizens #530
Comments
|
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? 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
changed the title
dr-shorthair
changed the title
davebrowning
added
the
due for closing
davebrowning
removed
the
due for closing
(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.
The text was updated successfully, but these errors were encountered: