Dxwg: Collate existing practice in use of dct:conformsTo with DCAT

[rob-metalinkage]

The target for dct:conformsTo is an identifier for a specification. In attempting to implement DCAT (and PROF) establishing canonical URIs for a range of well known specifications is not trivial.
Can people implementing DCAT please advise how they are doing this now, and if possible publish links to the sets of specifications they have identified.

this relates to #1146 #1211 #1130 #990

[andrea-perego]

Some examples below, excluding those not in scope with PROF:

• DCAT-AP (https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/release/200):
  
  
  
  • Metadata conformance (§4.2)
  
  
  • Service conformance (§4.3.2)
  
  
  • Distribution conformance (§4.5.3)
  
  
• GeoDCAT-AP:
  
  
  
  • Metadata conformance (https://semiceu.github.io/GeoDCAT-AP/drafts/latest/#metadata-standard-name-metadata-standard-version)
  
  
• DCAT-AP-JRC:
  
  
  
  • Distribution conformance (https://ec-jrc.github.io/dcat-ap-jrc/#distribution-conforms-to)
  
  
  • Service conformance (https://ec-jrc.github.io/dcat-ap-jrc/#endpoint-protocol)
  
  
  • Metadata conformance (https://ec-jrc.github.io/dcat-ap-jrc/#catalogue-record-conforms-to)
  
  

[kcoyle]

In recognition of the great variety of uses of Dublin Core terms, DCMI recently moved to a use of "range includes" for many properties rather than the more strict RDF range, and dct:conformsTo is one of those properties. Therefore a non-URI "identifier" could be used (and probably has been in practice). Obviously, DCAT can develop its own practice, requiring URIs if it wishes.

[rob-metalinkage]

Thanks - what I'm actually looking for is the set of target objects in use - actual specification URIs - (I've already looked into the definitions and use of conformsTo when designing PROF to make sure it fits in with this)

[andrea-perego]

@rob-metalinkage , can we close this issue, or you would like to re-launch it to collect additional feedback?

[rob-metalinkage]

@andrea-perego - I guess the original issue can be closed - thanks to your very useful info. Pity no others have seemed to think about the issue. Looking at the examples you cite its very clear there is critically important semantics in the usage notes of the profiles. I guess the default position is therefore DCAT doesnt specify what dcterms:conformsTo actually relates to - its up to profiles of DCAT to decide what the predicate means - the API or data or other possibilities (such as service level agreements). I'd be happier to close it with a pointer to the statement that gives guidance on how to use it... or better a new issue to make such a statement and close this one - since it has provided evidence this is a valid concern.

[jakubklimek]

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 of dcat:endpointDescription there is a list of possible types of services that can be described, specifically:

• OpenAPI (Swagger)
• SPARQL
• WMS, WFS
• WSDL
• OpenSearch
• HYDRA

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.

[andrea-perego]

Thanks, @rob-metalinkage & @jakubklimek .

I think that we should then keep this issue open.

Defining a URI registry for dct:conformsTo is out of scope of DCAT and of the DXWG's mandate. However, it might be possible to provide guidance for at least a subset of the specifications that dct:conformTo may point to. The WG needs to discuss about this.

Meanwhile, my personal feedback.

We actually had to deal with the same issues in the JRC Data Catalogue, and in the definition of the JRC profile of DCAT-AP. We therefore explicitly defined the list of URIs to be used in the DCAT-AP-JRC specification mentioned above.

More precisely:

1. For metadata conformity, the list of URIs is documented in §A.3
2. For service conformity, we built upon the list of URIs maintained by OSGeo, and you can find the resulting list in §A.4

The additional issue you are pointing out, @jakubklimek , is that a resource may be conformant with a specific version of a specification. And, of course, it might be conformant with other specifications or profiles (e.g., a GeoDCAT-AP record is conformant with GeoDCAT-AP & DCAT-AP, and, at least at the conceptual level, with INSPIRE and the core profile of ISO 19115:2003).

If a PROF description is available, and the server/client is able to deal with a PROF description, versions and profiles will be resolved automatically. But if this is not the case, a possible option is to specify a dct:conformsTo statement for (at least some of) the relevant specifications, versions and profiles, including a link to the version-independent URI of a specification.

[jakubklimek]

@andrea-perego What is the reason behind having https://www.w3.org/TR/sparql11-protocol for SPARQL in the list instead of https://www.w3.org/TR/sparql11-protocol/, i.e. without the slash? Is it a bug, or is there a rationale behind this?

[andrea-perego]

@jakubklimek said:

@andrea-perego What is the reason behind having https://www.w3.org/TR/sparql11-protocol for SPARQL in the list instead of https://www.w3.org/TR/sparql11-protocol/, i.e. without the slash? Is it a bug, or is there a rationale behind this?

The reason is that the trailing slash is missing from the OSGeo's URI list (which, as I said, is re-used and extended in DCAT-AP-JRC):

https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv

I don't know if there was any specific decision about this in OSGeo.

[rob-metalinkage]

Good to see this being looked at.. its a significant practical issue.

I have sympathy for the view that given the adopted charter DXWG scope is limited to DCAT, not resolving data exchange interoperability architecture concerns, (in spite of the name :-) ). There are multiple separate architectural concerns here IMHO:
1) the domain of dct:conformsTo and how to make statements about the service and data itself, rather than the DCAT object
2) how to distinguish service behaviour (API) from data access (e.g. login requirements) from data payload etc
3) how to handle fine-grained semantics regarding conformance (as expressed by profile hierarchies - or even harder canonical and comprehensive descriptions of things)
4) Canonical identifiers for interoperability domains - what is an interoperable range for dct:conformsTo

the URI with or without / (or #) comes down to a wider issue around namespaces vs identifiers. This needs some serious thought across communities that use identifiers to locate resources - I am thinking owl:imports and JSON-LN context here especially. I dont think DXWG can resolve this.

I think @andrea-perego is probably on the right track which is that for DCAT there is an assumption that an "interoperability domain" will need to adopt a register. I suspect each domain may also need to adopt a canonical mechanism for identifying equivalence and subsumption (conforming profiles). The question is whether we want to define an interoperability domain for DCAT and declare all this, or explicitly state that DCAT profiles SHOULD define these aspects.

Leaving it open for DCAT users to define their own mechanisms in an ad-hoc way pretty much guarantees lack of interoperability as @jakubklimek points out.

[andrea-perego]

@rob-metalinkage , @kcoyle , @jakubklimek ,

I've added a few paragraphs in the ED at the end of §13.2.1 Conformance to a standard (PR https://github.com/w3c/dxwg/pull/1310), to provide guidance on the URIs to be used with dcterms:conformsTo.

Do you think this is addressing the issue?

[jakubklimek]

@andrea-perego looks good to me.
There is a typo I think:

[andrea-perego]

Thanks for spotting this, @jakubklimek .

Fixed via commit https://github.com/w3c/dxwg/pull/1323/commits/03ca0bcd9ce699ca43beb05ab76123898cf4a8dc on existing PR (yet to be merged).

[andrea-perego]

Thanks for spotting this, @jakubklimek .

Fixed via commit 03ca0bc on existing PR (yet to be merged).

PR https://github.com/w3c/dxwg/pull/1323 merged.

[andrea-perego]

@rob-metalinkage , @kcoyle , @jakubklimek ,

Not having got further input on the guidelines added to the ED, I propose we close this issue, and we move the discussion to the following threads:

• for discussion about which URIs to be used with dcterms:conformsTo: https://github.com/w3c/dxwg/issues/1211
• for discussion on conformance with specific versions or profiles: https://github.com/w3c/dxwg/issues/1338

[andrea-perego]

@rob-metalinkage , @kcoyle , @jakubklimek ,

Not having got further input on the guidelines added to the ED, I propose we close this issue, and we move the discussion to the following threads:

• for discussion about which URIs to be used with dcterms:conformsTo: #1211
• for discussion on conformance with specific versions or profiles: #1338

Thanks, @jakubklimek .

No objections raised. Closing this issue.