Fetch dct:accessRights from proper locations

[streino]

Access rights can be a property of Resource (super-class of Dataset) or Distribution.

Some conditions apply :

Information about licenses and rights SHOULD be provided on the level of Distribution.
Information about licenses and rights MAY be provided for a Dataset in addition to but
not instead of the information provided for the Distributions of that Dataset. Providing
license or rights information for a Dataset that is different from information provided
for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts.

Also, in the case of DCAT resources coming from the SEMICeu transformation, if I'm not mistaken, the rights are taken at the dataset level from the ISO input and copied at the distribution level in the DCAT output. So we should be able to assume that what we find at the distribution level is in fact applying to the entire record.

Since udata doesn't display distribution-level rights, we'll have to approximate at the dataset-level. It's probably better to be overly careful than miss some restrictions. So we could go with :

• Collect all access rights found at Resource and Distribution levels.
• Uniqify the collection.
• Assign/display the set of access rights at the dataset level.

The other approach would be to store all information in the extras as-is and retrieve what we're interested in displaying when needed.

Finally, the same sort of logic should apply to license, but that part needs to be articulated with existing license logic in udata. So probably another PR.

[ThibaudDauce]

Why not put accesRight information inside Resource extras directly?

[streino]

Why not put accesRight information inside Resource extras directly?

Right. I used what was already there, but it makes sense to move it outside of the harvest section into resource and/or dataset extras directly (depending on the implementation we go with).

[maudetes]

The other approach would be to store all information in the extras as-is and retrieve what we're interested in displaying when needed.

I would rather store the information as-is for now instead of consolidating it at the dataset level.

[streino]

I would rather store the information as-is for now instead of consolidating it at the dataset level.

We (ping @alhyss) were leaning the other way for the following reasons:

• Udata doesn't have licence/access-rights at the distribution level, so having it in extra is inconsistent with the udata model and won't be usable in the front.
• That's possibly quite a bit of duplicate information stored in extras, with no clear use.
• Spec is complex so I'm worried the cases of specific distribution-level conditions we might encouter would be caused by poor implementation of the spec rather than actual distribution-level conditions.
• Avoid putting consolidation logic in the front-end to keep it as dumb as possible.

That said, if there are plans to use distribution-level licence/access-rights in udata :

• I can work directly on that instead.
• We can go for dataset-level now and switch to distribution-level later by simply removing the consolidation logic.

[alhyss]

I would rather store the information as-is for now instead of consolidating it at the dataset level.

I agree that distinct distribution-level rights and licenses should be stored as they are. If these properties are not the same for all distributions, this is the only way to prevent losing an important information. Legal conditions are meaningless (and confusing) if users can't tell which distribution they're applicable to.

That being said:

• udata already has a standardized dataset-level license property. Unless you decide not to use it for DCAT metadata records, some kind of consolidation work will be necessary there.
• As @streino explained, rights and licenses will always be the same for all distributions if the metadata record was transformed from ISO.
• Rights and licenses are generally the same for all distributions. Forcing udata users to enter the same information multiple times will bother them and (probably) affect metadata quality.
• Allowing dataset-level and distribution-level properties to coexist in a metadata record would be hazardous without consistency checks.

Using only distribution-level properties is arguably simpler, but wouldn't be very efficient.

Ideally, you could allow both dataset and distribution level properties, though not together:

• Distribution-level properties would be used in the (rare) case of harvested metadata with distribution-level rights or licenses that are not exactly the same for all distributions. If there are more than one license, I wouldn't use the standardized dataset-level license property either. Example of metadata record that would require distribution-level access rights and license properties:

  [] a dcat:Dataset ;
    dcat:distribution [ a dcat:Distribution ;
          dct:accessRights [ a dct:RightsStatement ;
                rdfs:label "Accès restreint"@fr ] ] ,
       [ a dcat:Distribution ;
          dct:accessRights [ a dct:RightsStatement ;
                rdfs:label "Pas de limitation d'accès"@fr ] ;
          dct:license <https://www.etalab.gouv.fr/licence-ouverte-open-licence> ] .

• Dataset-level properties would be used in all other cases. Example:

  [] a dcat:Dataset ;
    dcat:distribution [ a dcat:Distribution ;
          dct:accessRights [ a dct:RightsStatement ;
                rdfs:label "Pas de limitation d'accès"@fr ] ;
          dct:license <https://www.etalab.gouv.fr/licence-ouverte-open-licence> ] ,
       [ a dcat:Distribution ;
          dct:accessRights [ a dct:RightsStatement ;
                rdfs:label "Pas de limitation d'accès"@fr ] ;
          dct:license <https://www.etalab.gouv.fr/licence-ouverte-open-licence> ] .

If all distributions have the same access rights property but not the same license, a dataset-level property would be used for access rights and distribution-level properties for the licenses.

Finding a way to display the distribution-level properties doesn't seem urgent at all, considering this case might never happen. But when it does, we'll be able to detect it and decide how to show it.

[streino]

@maudetes, we rediscussed the topic with @alhyss so I'm go with her suggestion above. Ok on your side?

[maudetes]

Thank you for the detailed explanation of the different considerations. This seems like the best approach to cover the main usages as well as possible tricky ones. :+1: I think we can also iterate quite easily on this if needed since these are extras properties.