Re: [dxwg] Values for dcterms:conformsTo of instances dcat:DataService (sparql endpoints, for example) (#1211)

> 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 18 May 2021 21:06:25 UTC