- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 May 2021 21:06:21 +0000
- To: public-dxwg-wg@w3.org
> Hi, following a suggestion from my colleague @Abbe98 suggested we could have two `dcterms:conformsTo`, one for the language and one for the protocol. Would this be acceptable? Sorry for my late reply, @aisaac . Not sure `dcterms:conformsTo` is the most appropriate property. Probably, a specific one should be used (e.g., `dcat:queryLanguage` or `dcat:supportedQueryLanguage`). But this links to the more general issue (still under discussion) on whether DCAT should describe the specific characteristics of the service / API interface. The current approach is minimal: the description of the service / API interface is meant to be included in the "document" linked to from `dcat:endpointDescription`, whose correct interpretation is meant to be indicated by `dcterms:conformsTo` (e.g., the endpoint description is specified via Swagger/OpenAPI, OGC WMS / WFS / WF* Capabilities, etc.). Said that, it might be worth extending the current approach by making DCAT able to specify at least a subset of the information in the endpoint description - as the supported query languages, formats, and profiles - if relevant for uses in scope of DCAT (e.g., search / filtering services / APIs). @aisaac , I wonder whether you could elaborate on the requirement of having the query languages included in DCAT records, and the related use cases. PS: Probably, we'd better open a new issue on this specific point. -- GitHub Notification of comment by andrea-perego Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1211#issuecomment-843563459 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 May 2021 21:06:25 UTC