`*rights`/`license` at the `Dataset` level?

[streino]

The XSLT currently only includes dct:license/dct:accessRights/dct:rights in the Distribution(s) of a Dataset.

While this is mostly consistent with the GeoDCAT-AP 3.0.1 draft, I wonder if at least some *rights should also be included at the Dataset level. The main argument is that there may be no Distribution for a Dataset with restrictive rights, so in those cases the ISO gmd:resourceConstraints are not carried over to the GeoDCAT-AP output.

Having license at the Dataset level might make less sense (and is not currently supported in the spec), but given that mapping the various gmd:resourceConstraints to the different dct:licence/dct:*rights entities is not 100% reliable (mostly because ISO records are not always strictly following the somewhat vague guidelines), I'd argue it might also be interesting to support it (with license at the Distribution level overriding the one at the Dataset level when both are present).

Relevant sections of the GeoDCAT-AP 3.0.1 draft:

• 7.6 Data Service: Support for dct:license and dct:*rights.

  Properties
  For this entity the following properties are defined: access rights , ... , licence , ... , rights, ...

• 7.7 Dataset: No support for dct:license, but support for dct:*rights.

  Properties
  For this entity the following properties are defined: access rights , ... , rights , ...

• A.5.1 Overview of bindings for GeoDCAT-AP Core: No mention of dct:*rights at the Dataset level.

  INSPIRE metadata	DCAT-AP Property	Domain
  Conditions for access and use (M)	dct:license (R for dcat:Catalog and dcat:Distribution, O for dcat:DataService), dct:rights (O)	dcat:Catalog, dcat:Distribution, dcat:DataService
  Limitations on public access (C)	dct:accessRights (O)	dcat:DataService

• A.5.2 Overview of bindings for GeoDCAT-AP Extended: No mention of dct:*rights at the Dataset level.

  INSPIRE metadata	DCAT-AP Property	Domain
  Limitations on public access (C)	dct:accessRights (O), dct:rights (O)	dcat:Catalog, dcat:Distribution, dcat:DataService

• A.7.15 Conditions for access and use and limitations on public access – Use limitation and access / other constraints: Suggests no dct:*rights at the Dataset level (but not explicit).

  In DCAT-AP-3, licensing information is specified on (a) data catalogues (services) and on (b) the distribution(s) of a dataset, and not on the dataset itself. The principle is that different dataset distributions may be associated with different licensing terms. [...]

  It is not clear from the rest of the section that dct:*rights should also only be at the Distribution level, but the only Example 37 focuses on Distribution.

[streino]

Sorry I probably should have created this ticket in https://github.com/SEMICeu/GeoDCAT-AP. Could one of the repo managers move it?

[streino]

Thanks @jakubklimek!

[jakubklimek]

@streino just for completeness (and future testing) could you provide an XML example of a record that represents this?

[streino]

I thought I had a better example but I can't put my hands on it at the moment...

Here's one that initially raised the issue on our side: https://data.ofb.fr/catalogue/Donnees-geographiques-OFB/api/records/ef98692d-3be2-444e-8fe7-9d5760b5ac2c/formatters/iso19139 (github attachment).

This isn't the prototypical example because:

1. The original format is ISO-19115-3, but the GeoNetwork ISO-19139 conversion works as well as far as this ticket is concerned.
2. It's about a license and not *rights, which is the most uncertain case this ticket covers.
3. The problem would not occur if the original record declared its distributions properly via gmd:function.

But those caveats might in fact make this a good example, because it does show how difficult it is to reach 100% alignment in practice, especially:

• The SEMICeu XSLT relies on gmd:function to identify distributions, but gmd:function is not a strong requirement in the INSPIRE TG (Recommandations 1.9, 3.4 and 5.1 are all "should"/"if possible").
• Shows it might be worth having dct:license at the Dataset level (with some sort of override mechanism if present at both Dataset and Distribution level). This would make license and rights "symmetrical" in the way they can be declared in GeoDCAT-AP, and would cover for (imperfect and/or restricted) cases where we can't have distributions to attach licenses to.

Some parts might have more to do with improving the XSLT vs the spec, but I think the point about gmd:function not being mandatory in the INSPIRE TG makes it difficult to solve only at the XSLT level.

[PeterParslow]

Sorry to but in; Lena Hallin-Pihlatie pointed me to this discussion because I'm leading the ISO project to specify a mapping from ISO 19115-1:2014 to DCAT 3.0 (influenced by GeoDCAT 3.0).

It's worth noting that although DCAT Resource & DCAT Distribution both can have dcterms:license, dcterms:rights, dcterms:accessRights, and odrl:hasPolicy statements; DCAT is clear they should be provided on the distribution and that providing it on the dataset is "in addition but not instead" (& that they should not differ)

So I think the better answer (i.e. one that gives a better DCAT output) is a transform that finds the rights wherever they are hidden in the ISO 19115 record and outputs them on the DCAT Distribution

[streino]

Thanks @PeterParslow for joining in. I wasn't aware there is also an effort on the ISO side to work on a DCAT mapping. What's the best way to follow progress on that front?

I agree the better general solution is to gather rights wherever they are in the ISO record and output them at the Distribution level in *DCAT.

But what about the corner case of a Dataset/DataService without any Distribution? If this case is to be supported (?), I don't see a way around needing record-level dct:license/dct:*rights attributes.

Records with no Distributions might be a degenerate case (?) but if they can exist in practice maybe there should be a (fallback) way to support them?

[STatVL]

Hi everyone,

Writing this from the perspective of Digitaal Vlaanderen (Flanders Digital Agency).

We analysed this internally because it impacts our DCAT-AP-VL profile (Metadata Vlaanderen) and, downstream, interoperability with EU harvesting/aggregation.

A key point for our context: DCAT-AP-VL is based on DCAT-AP 3.0.1. (data.vlaanderen.be)

Why we advise against adding dct:license on dcat:Dataset

1. It conflicts with the core DCAT-AP legal-modelling strategy
DCAT-AP explicitly motivates expressing legal information at the most concrete level of sharing, i.e. Distribution or Data Service, because legal information can differ per distribution/service and dataset-level statements can conflict with those. In other words: introducing dataset-level dct:license does not just add “symmetry”; it introduces precedence ambiguity (“which licence wins if Dataset and Distribution disagree?”), which DCAT-AP tries to avoid.

2. DCAT-AP-VL already has a clean split: access restrictions vs. legal terms
In DCAT-AP-VL, access restrictions are modelled at Dataset level using dct:accessRights, and this is mandatory (cardinality 1) with controlled values PUBLIC / NON_PUBLIC. Legal constraints for how the data/service is made available are then attached to the concrete access/embodiment level:

• Distribution:
  • dct:license (0..1)
  • dct:rights (0..n)
  • dcat:accessURL is mandatory (1), meaning every distribution must have an access point you can hang these statements on.
• DataService (DCAT-AP-VL choice):
  • dct:license (0..1)
  • dct:rights (0..n)
  • and also dct:accessRights mandatory (1) with PUBLIC/NON_PUBLIC.

This structure already solves the main modelling needs (for us) without moving dct:license up to Dataset.

3. Important distinction: DCAT-AP 3.0 vs. DCAT-AP-VL on dct:rights for DataService
In DCAT-AP 3.0, a Data Service includes dct:license (0..1) and dct:accessRights (0..1), but dct:rights is not part of the Data Service property list. In DCAT-AP-VL, dct:rights is allowed on DataService (0..n). So: “put rights on DataService” is valid in our VL profile, but we don’t want to present that as a universal DCAT-AP 3.0 rule.

How we recommend handling the “degenerate/offline/restricted” cases without changing the model

We recognise the scenario raised in this issue: rights/licensing info exists, but there is no “real” downloadable distribution.
In DCAT-AP-VL, we recommend keeping legal statements non-floating by modelling a “proxy” Distribution:

• Create a dcat:Distribution where dcat:accessURL points to:
  • a landing page,
  • a request form,
  • or instructions on how to obtain access. (dcat:accessURL is mandatory in DCAT-AP-VL Distributions, so this fits well.)
• Attach:
  • dct:license when you have a proper licence resource/URI
  • and/or dct:rights for additional legal statements/conditions (e.g., attribution requirements, usage constraints).

This addresses the information-loss problem while staying aligned with the DCAT-AP strategy (legal info at Distribution/DataService).

ISO “free text constraints”: licence vs rights

We also see that ISO gmd:otherConstraints often contains free text. In such cases, mapping that free text directly to dct:license is often not appropriate (as dct:license is intended for a licence document/resource), so we recommend mapping free-text constraints to dct:rights (as legal statements), and keep dct:accessRights for the access classification (PUBLIC/NON_PUBLIC) at Dataset (and, where relevant, at DataService in DCAT-AP-VL).

Conclusion (DCAT-AP-VL / Metadata Vlaanderen advice)

For stability and cross-border interoperability, we recommend sticking to the current hierarchy:

• Dataset → dct:accessRights (PUBLIC / NON_PUBLIC) for access classification.
• Distribution → dct:license + dct:rights (and always an dcat:accessURL).
• DataService → dct:license (+ in DCAT-AP-VL also dct:rights) and (in DCAT-AP-VL) dct:accessRights.
• Offline/restricted/no-download → model a proxy Distribution via dcat:accessURL and attach rights/licence there.

This solves the “information loss” edge cases without introducing dataset-level licensing ambiguity, and it remains consistent with DCAT-AP’s rationale of placing legally binding reuse conditions on the Distribution or Data Service.

Stijn Tallir, PO Metadata - Digitaal Vlaanderen

[jakubklimek]

Based on the above discussion, the proposition is not to change the spec. Note that the XSLT can always be customized by the implementers, and the goal of the reference implementation is not to support all possible edge cases.

Feel free to re-open the issue in a future iteration, if necessary.