Closed stigbd closed 2 months ago
For the records, this issue has also been raised as future work for DCAT (yet to be discussed) - see https://github.com/w3c/dxwg/issues/1242
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.
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.
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 https://github.com/w3c/dxwg/issues/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.
Issue in https://github.com/w3c/dxwg/issues/1394 has been closed. So I propose to close also this issue.
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:
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:
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:
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:
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].