Calcul de la métadonnée restricted_access

[martyKN]

• Accès a des données tagguées « données restreintes » , pb dans les MD?

[benoitdavidfr]

La fiche initiale de Dido en DCAT ne mentionne pas la caractéristique "données restreintes", ni l'organisation DDTM30. Il s'agit donc probablement d'un bug Ecosphères de mapping DCAT et non d'un bug IHM.

[streino]

Pour comparaison, le jeu 5.17 ITDD - Provence-Alpes-Côte d'Azur - Toutes les communes est indiqué "données ouvertes", alors qu'il n'y a pas de différence notable au niveau de la fiche initiale Dido.

[alhyss]

Ce n'est pas un bug, la valeur de la métadonnée est actuellement choisie au hasard par le moissonneur...

Dans la définition de la fonction ecospheres.dcat.profiles.dataset.parse_dataset.parse_dataset, ligne 304 :

    #TODO: 
    import random
    dataset_dict["restricted_access"]=random.choice([True,False])

Évidemment, ça ne devrait pas être le cas. Comme l'indique le schéma YAML, elle devrait être déduite de la propriété access_rights.

C'est pour moi typiquement le genre de chose qui devrait être fait par un validateur plutôt qu'indépendamment par chaque moissonneur. Le calcul n'est pas du tout trivial, par contre, du moins en théorie.

Non avons à date deux vocabulaires contrôlés pour access_rights, qu'il est possible de mapper. Avec celui de la commission européenne, PUBLIC et son prédécesseur NORMAL sont les seuls qui correspondent à des données non restreintes. Avec le vocabulaire INSPIRE, tout est restreint sauf noLimitations.

La difficulté, c'est que nous n'aurons pas systématiquement une valeur issue d'un de ces deux vocabulaires. GéoDCAT-AP autorise du texte libre pour dct:accessRights et on peut aussi ne rien avoir du tout. On pourrait essayer d'utiliser la présence de ressources associées comme un élément d'entrée, mais ça me semble très hasardeux. Par exemple on peut avoir un lien de téléchargement pour une donnée restreinte qui renvoie sur une page d'authentification. À l'inverse on pourrait avoir des cas où le moissonneur n'arrive pas identifier de ressource parce que les métadonnées sont incomplètes, mais la donnée n'est pas restreinte du tout et en retournant dans le catalogue d'origine l'utilisateur arrivera à la récupérer.

Ceci étant dit, je pense qu'avec nos métadonnées actuelles mapper sur True les valeurs des vocabulaires qui correspondent à des données restreintes et le reste sur False doit donner de bons résultats, considérant que nous n'avons que de l'INSPIRE (avec vocabulaire INSPIRE), du Dido (il faudra voir avec eux pour s'assurer que s'ils ont un jour des données restreintes ils utilisent dct:accessRights avec un vocabulaire connu d'Ecosphères) et potentiellement des données issues de data.gouv.fr où tout est pour l'heure censé être ouvert. Il faudra juste se reposer la question lorsque nous ajouterons des catalogues.

En clair, ça donne un validateur qui, si restricted_access n'est pas renseigné à l'issue du moissonnage, regarde la valeur du sous-champ uri de access_rights. Si elle appartient à la liste suivante, restricted_access vaudra True. Dans tous les autres cas, il faudra lui donner la valeur False.

access_rights_restricted_uri = [
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1a',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1b',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1c',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1d',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1e',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1f',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1g',
    'http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1h',
    'http://publications.europa.eu/resource/authority/access-right/CONFIDENTIAL',
    'http://publications.europa.eu/resource/authority/access-right/NON_PUBLIC',
    'http://publications.europa.eu/resource/authority/access-right/RESTRICTED',
    'http://publications.europa.eu/resource/authority/access-right/SENSITIVE'
]

En toute première approche, il serait entendable de le dupliquer dans chaque moissonneur plutôt que d'utiliser un validateur.

Quelques références sur les validateurs :

• Le code des validateurs par défaut de CKAN est dans le module ckan.lib.navl.validators.
• Leur usage est documenté ici.
• L'interface pour déclarer de nouveaux validateurs est ckan.plugins.interfaces.IValidators.