abulte
commented
3 months ago Ci-dessous une analyse rapide du dashboard existant avec le prisme suivant : si on utilise une source de données data.gouv.fr vs le dump de CKAN existant, quels seraient les solutions et impacts ?
Alimentation du dashboard
On considère que la solution Metabase continue à être utilisée.
Plusieurs possibilités :
- synchronisation d'un référentiel dédié (e.g. PostgreSQL) avec la base data.gouv.fr
- synchronisation initiale via un export du catalogue data.gouv.fr
- synchronisation différentielle via webhook ou autre méthode de diff OU resynchronisation complète (probablement faisable au quotidien)
- utilisation en direct des API
- probablement impossible vu que les indicateurs sont calculés sur l'ensemble du catalogue
- peut-être utilise pour enrichir certaines parties du dashboard de manière opportuniste
- branchement direct sur la base Mongo de data.gouv.fr (évoqué par Gabriel)
- élimine le besoin de synchronisation
- challenges d'architecture et de sécurité data.gouv.fr
- branchement direct du catalogue en CSV ou Parquet
Ce point reste à creuser notamment en fonction des fonctionnalités cibles, des ressources utilisées pour le projet et du calendrier, voire de la gouvernance de l'outil pour la piste direct Mongo. La piste synchronisation d'un référentiel dédié me parait la plus naturelle.
Mapping des métadonnées
Ci-dessous une analyse des indicateurs présents sur le dashboard existant et quelles correspondances on peut trouver vers des attributs existants ou non de data.gouv.fr.
- Partie générale
- Nombre de jdd : OK (API suffisante)
- Liste des jdd : OK (API suffisante)
- Date dernière modification : OK (API suffisante)
- dispo dernière modification : 100%
- voir si pertinent de mapper un autre attribut (harvest.last_modified)
- Maturité
- Pas métadonnée INSPIRE ? Pas dans le guide
- Quelle source pour le dashboard actuel ? Demander à Leslie
progressen ISO
- DCAT :
adms:status - Pas moissonné par data.gouv.fr actuellement
- A priori récupérable en DCAT mais qui l'expose ?
- Pas métadonnée INSPIRE ? Pas dans le guide
- Doublons
- "comparaison stricte sur le titre du jeu de données"
- OK
- Catalogue
- Deux équivalents possibles :
- Organisation
- Moissonneur
- Pas strictement équivalent
- Classe dcat:Catalog
- Moissonnable ?
- Préconisation faisable
À terme, ce filtre pourra être lié aux bouquets de données (et donc aux cas d’usage) ecologie.data.gouv.fr. En effet, les indicateurs devront pouvoir être analysés sur un bouquet de données.
- Deux équivalents possibles :
- Organisations
- Au sens data.gouv.fr OK
- Pas strictement équivalent aux organismes Inspire
- Classe foaf:Organization
- Probablement moissonnable
- Points de contact
- Implémenté "nativement" sur data.gouv.fr
- Moissonné
dct:contactPoint(au moins) - OK (moins de 53%)
- Accès à la donnée
- Licence native data.gouv.fr OK
- Couverture probablement équivalente
- Conditions d'accès
- Moissonné
dct:accessRights(extras) - Très faible couverture à date
- Moissonné
- Couverture géographique
- Plusieurs attributs correspondants
- Géozone (entité nommée)
- Non moissonnée
- Meilleure correspondance vs existant (niveau et zone)
- Bounding box(es)
- Moissonné https://github.com/opendatateam/udata/blob/c4ab76d6f4b647c8ef9670ab533eb0902f5ec3b0/udata/core/dataset/rdf.py#L353
- Traitement différent à effectuer, surface(s) vs entité
- Géozone (entité nommée)
- Plusieurs attributs correspondants
- Remplissage des métadonnées
- OK, à redéfinir en fonction des attributs qu'on récupère via la source data.gouv.fr
streino
Ticket en avance de phase par rapport aux priorités actuelles.
Points d'entrée :