ODRL policy and accessRights only on Distribution and not on Dataset?

[mathiasrichter]

Dear DCAT Team

I am new to DCAT. I am wondering why the odrl:Policy resp. dct:accessRights are only associated with specific Distributions. If I want to describe a DataService producing a certain Dataset I would want to somehow describe the access rights/access policies under which the DataService can be asked to produce a new Distribution of the DataSet.

My context: I want to write a piece of code that traverses the graph describing a DataService and Dataset and thereby extracts the information necessary (access URL, frequency/periodicity, access rights) to pull a new distribution from the service automatically. I am thinking that the policy or access rights on the DataSet would be used to describe the credentials my code needs to actually access the DataService to create a new Distribution.

Many thanks for your support.

Mat

[andrea-perego]

Thanks for contributing your use case, @mathiasrichter . It would be great to know more about your approach. I wonder whether you would kindly share a working example showing, e.g., a dataset record, a data service record, and the criteria used to derive a new distribution.

Coming to your questions:

Properties dcterms:accessRights (§6.4.1 Property: access rights) and odrl:hasPolicy (§6.4.22 Property: has policy) are associated also with dcat:Resource, so they can be re-used by its sub-classes, as dcat:Dataset and dcat:DataService.

For instance, Example 60 shows the use of dcterms:accessRights on a dcat:DataService.

BTW, the list of properties that can be re-used by dcat:Dataset and dcat:DataService are listed at the beginning of the relevant sections - §6.6 Class: Dataset and §6.9 Class: Data Service, respectively.

[davebrowning]

Project/Milestone modified.

Explanation: As DCAT v3 moves through review and hopefully ratification, we want to make sure that open issues and feedback that have yet to be completely addressed are properly recorded and tagged/assigned in github to both clarify their status and to help review and prioritise as a source of improvements and new requirements in future DCAT versions

As DCAT v3 moves through review and hopefully ratification, we want to make sure that open issues and feedback that have yet to be completely addressed are properly recorded and tagged/assigned in github to both clarify their status and to help review and prioritise as a source of improvements and new requirements in future DCAT versions.