- From: Øystein Åsnes via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 12:50:48 +0000
- To: public-dxwg-wg@w3.org
Thank you all for an enlightening discussion. Besides the discussion on cardinality for `dcat:Distribution` our concern is that a format property is the only one we need to complement an API-description based on `dcat:dataService` properties. Unless there are downloadable files involved, the rest of the class does not add any value. By using `dcat:distribution` to express format (regardless of content negotiation and multiple formats), we need to add accessURL (mandatory in DCAT-AP) and it also makes sense to add `dcat:distribution` (for the dcat:Dataset) to associate the distribution to the related dataset . The result is a dcat:Dataset/dcat:Distribution/dcat:accessService/dcat:DataService model instead of a much simpler dcat:Dataset/dcat:DataService/ (or only dcat:DataService if standalone dataservices are accepted in the catalog. We are fine with a catalog service (a data portal) being agnostic on _how_ to access data in a certain format, leaving this to the endpoint description, but our users expect to be able to filter/search on formats. Adding a dcat:Distribution for each format, seems to be a file-oriented way of describing APIs, making catalogs (data portals) less human-user friendly and the model more complex. We might have missed out on the basics so feel free to convince us that we need both dcat:Distribution and dcat:DataService to provide an API-description. -- GitHub Notification of comment by oystein-asnes Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1055#issuecomment-532206141 using your GitHub account
Received on Tuesday, 17 September 2019 12:50:49 UTC