W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > October 2020

Re: [dxwg] Collate existing practice in use of dct:conformsTo with DCAT (#1225)

From: Jakub Klímek via GitHub <sysbot+gh@w3.org>
Date: Mon, 26 Oct 2020 06:29:06 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-716334778-1603693745-sysbot+gh@w3.org>
I came across the same problem when implementing DCAT-AP 2.0.1 in Czechia, specifically I came across `dct:conformsTo` on `dcat:DataService`.

In the [usage note](https://w3c.github.io/dxwg/dcat/#Property:data_service_endpoint_description) of `dcat:endpointDescription` there is a list of possible types of services that can be described, specifically:
- OpenAPI (Swagger)
- OpenSearch

However, if I am not mistaken, as this issue says, there is actually no way of saying "This data service is a SPARQL endpoint" in a way that all users of DCAT understand.

I think it would greatly improve interoperability if this could be standardized. And, since those service types really are world-wide, and the most common ones are just few, there is no point in deferring the specification of this to application profiles. Use cases like "give me all SPARQL endpoints in the catalog" or "give me all WFS services", etc. are IMHO global enough to be supported directly by DCAT.

e.g. for SPARQL endpoints, I plan to say
[] a dcat:DataService ;
    dcterms:conformsTo <https://www.w3.org/TR/sparql11-query/> .

However, someone else might use

[] a dcat:DataService ;
    dcterms:conformsTo <https://www.w3.org/TR/2013/REC-sparql11-query-20130321/> .
leading to worsened interoperability.

I think that DCAT, being a W3C Recommendation, should provide guidance regarding this at least for W3C specified services like SPARQL, or WSDL based web services.

GitHub Notification of comment by jakubklimek
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1225#issuecomment-716334778 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 26 October 2020 06:29:09 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:35 UTC