Cardinality of dcat:endpointURL for dcat:DataService breaks maxCardinality of DCAT 2 and is hard to implement

[stigbd]

Submitter name and affiliation

Stig B. Dørmænen, Norwegian Digitalisation Agency

Portal, service or software product represented or affected

Norwegian national dataportal

Description of the problem or requirement

In DCAT_AP_2.0.1 endpointURL property of dcat:DataService is given by:

Property	URI	Range	Usage note	Card
endpointURL	dcat:endpointURL	rdfs:Resource	The root location or primary endpoint of the service (an IRI).	1..n

I have two (interrelated) problems with this property, as given by DCAT-AP:

1. Cardinality of endpointURL breaks maxCardinality restriction given by W3C DCAT 2.0

In W3C DCAT 2.0 we find the following statements:

dcat:DataService
  a owl:Class ;
  rdfs:subClassOf [
      a owl:Restriction ;
      owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty dcat:endpointURL ;
    ] ;
.

As I understands the owl:maxCardinality, W3C DCAT 2 states that a dcat:DataService is a thing with at most one endpointURL. I cannot see that DCAT-APs definition of the property falls under "additional constraints" or emphasizing usage in relation to DCAT 2.

2. How to implement a DataService with many endpointURLs

If it would be the case that a DataService did have more than one endpointURL, I can not see how to describe it in a way that does not break the definition (usage note in dcat-ap ) endpointURL. Consider the following example:

<http://example.com/dataservices/1> a dcat:DataService;
         dcat:endpointURL <http://example.com/endpointURL/1> ,                           
                          <http://example.com/endpointURL/2>
.

There is no way to identify "the root location or primary endpoint", since there is no distinguishing criteria to discriminate the one from the other. One solution might be:

<http://example.com/dataservices/1> a dcat:DataService;
         dcat:endpointURL <http://example.com/endpoints/1> ,
                          <http://example.com/endpoints/2>
.
http://example.com/endpoints/1> a rdfs:Resource;
         ????:url <http://example.com/endpointURL/1> ;
         ????:description "test"@en ;
.
http://example.com/endpoints/2> a rdfs:Resource;
         ????:url <http://example.com/endpointURL/2> ;
         ????:description "production"@en ;
.

This solution does validate according to dcat-ap 2 shacl, but I cannot see that it preserves the intention of the definition.

Proposed solution

I would propose to change the cardinalty of dcat:endpointURL to be [0..1].

• DCAT-AP would no longer contradict W3C DCAT 2.
• A "dataService" with two endpointURLs would then result in two distinct instances of DataService.

[andrea-perego]

For the records, this issue has also been raised as future work for DCAT (yet to be discussed) - see w3c/dxwg#1242

[bertvannuffelen]

For the cardinality constraints: I agree we should align with the cardinality requirements from DCAT. A proposal adaption in the next draft will be made.

[bertvannuffelen]

The discussions in the w3c group are of interest for this working group. So far this working group has not expressed major specific requirements for data services in the application context of DCAT-AP, namely Open Data Portals in the Europe. Aside of highlighting key information the DCAT-AP relies for data service description entirely on DCAT.

[bertvannuffelen]

proposal:

An issue on this topic has been filed at W3C: namely it is unclear if the cardinalities in the w3c dcat.ttl file are normative or not.
See w3c/dxwg#1394

motivation:
The cardinalities only appear in this ttl file, and are expressed as OWL constraints, and thus only when interpreting the dcat.ttl file as OWL then the cardinalities appear. This issue should be resolved by W3C.

Note that for properties this also holds and thus it would violate the interpretation that W3C DCAT is not imposing cardinalities when reading the html specification.

[bertvannuffelen]

Issue in w3c/dxwg#1394 has been closed. So I propose to close also this issue.