[dxwg] dcat:accessURL constraint is too restrictive (#1588)

bertvannuffelen has just created a new issue for https://github.com/w3c/dxwg:

== dcat:accessURL constraint is too restrictive ==
Hi,

In [section 6.8.9](https://w3c.github.io/dxwg/dcat/#Property:distribution_access_url) the following statement is made:

> dcat:accessURL matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.

This is a very restrictive formulation. It means from the moment you associate a DataService with a Distribution the values of 2 properties are identical. But that is often not the case.

Suppose the following situation:

Agency A builds a API service for all geospatial data. Each layer in the API corresponds to an Dataset.
E.g. The road network, the public transport lines, the busstops.
For each dataset there is a file dump.

The accessURL for a the roadnetwork is http://geo.api.example.com/roadnetwork.dump, for the public transport lines it is http://geo.api.example.com/publicTransport.dump en the last is http://geo.api.example.com/busstops.dump
The API is shielded with access credentials and the endpointURL is http://geo.api.example.com/api/wfs.

In that case the urls are connected but not the same value. That violates the axiom.

Lets continue the example. The DPO states that the busstops are not anymore public data but private data. Therefore the dump is still available only on request. This can be reflected by replacing the accessURL with  http://agency.com/accessToBusstopsData.html.
Observe that in this example the technical infrastructure of the dataset and its distribution has not changed, only the access possibility.
But yet again that violates the axiom.

**proposal**
Given the examples and that this also ties very strongly (beyond a vocabulary terminology) the values of two classes, the proposal is to remove the axiom. 


Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1588 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 February 2024 12:07:16 UTC