- From: Bert Van Nuffelen via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 Jun 2021 11:18:46 +0000
- To: public-dxwg-wg@w3.org
@jimjyang In Flanders we have create a DCAT profile https://data.vlaanderen.be/doc/applicatieprofiel/metadata-dcat capturing Open data, Geospatial data and closed data and standalone services. When discussing data services this aspect has been kept as part of the endpoint description. So outside of the metadata that is collected in the DCAT catalogue. We observed that those technical details are very different depending from the ecosystem the data service has been designed in. Moreover many dataservices offer content-negotation so the actual syntax XML, json, etc is less important than knowing the business setting or the technical standards it follows. E.g. it is more important to know it is a OGC:WFS service than it is a service which returns XML. Personally, I am when exploring a catalog of dataservices not interested in the actual data syntax format that is returned. As technical person I am more interested in what the kind of data that provided, it is easy linkable with other service, are there any shared identifiers in the data, etc. The technical format is just added to amount of work and libraries that have to be supported. Note that even if one has the same syntax their is no guarantee that one can connect the two services. So I rather consider the format for a dataservice as a low value property. Looking into the future, we thought of constraints on the endpointdescription (e.g. SOAP WSDL description, Open API descriptions, ...) so that dataservice builders can use their native ecosystem documentation tools in such a way that generic metadata useful in the DCAT catalog context can be derived. I personally do not think DCAT should replace the documentation practices in each ecosystem, but we should enable smart bridges between them. -- GitHub Notification of comment by bertvannuffelen Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1381#issuecomment-867554499 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 24 June 2021 11:18:54 UTC