Display more dates

[at-github]

Fix : ecolabdata/ecospheres#422

[netlify]

✅ Deploy Preview for ecospheres ready!

Name	Link
🔨 Latest commit	fbbb792
🔍 Latest deploy log	https://app.netlify.com/sites/ecospheres/deploys/674868c9e6f2210008f10ff1
😎 Deploy Preview	https://deploy-preview-592--ecospheres.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for meteo-france ready!

Name	Link
🔨 Latest commit	fbbb792
🔍 Latest deploy log	https://app.netlify.com/sites/meteo-france/deploys/674868c90cd07f000826acfb
😎 Deploy Preview	https://deploy-preview-592--meteo-france.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[streino]

J'ai des cas bizarres :

https://deploy-preview-592--ecospheres.netlify.app/datasets/l-parkings-sup-1500m2-1
"Dernière mise à jour" + "Dernière modification" (on devrait pas avoir les deux)

https://deploy-preview-592--ecospheres.netlify.app/datasets/5808de39c751df1e0679df72
Deux fois "Dernière mise à jour"

Et aussi virer les deux-points en fin de header pour rester cohérent avec les autres entrées de l'encart.

[streino]

Je pense qu'il faut qu'on retravaille le wording : "dernière modification" vs "dernière mise à jour" risque de provoquer la confusion.

"dernière modification" -> "dernière révision" ? @abulte @alhyss un avis ?

Fiche non-moissonnée

Fiche moissonnée

[streino]

Qu'est-ce que ça donne avec les autres types de moissonneurs (dcat, ckan, ods) ?

[at-github]

Qu'est-ce que ça donne avec les autres types de moissonneurs (dcat, ckan, ods) ?

Comment tester ça stp ?

[streino]

Qu'est-ce que ça donne avec les autres types de moissonneurs (dcat, ckan, ods) ?

Comment tester ça stp ?

DCAT: https://demo.data.gouv.fr/fr/organizations/ville-devry-courcouronnes/
CKAN: https://demo.data.gouv.fr/fr/datasets/donnees-gtfs-du-reseau-de-transport-public-cara-bus/
ODS: J'en trouve pas 🤨

[abulte]

ODS: J'en trouve pas 🤨

Normalement il n'y en a plus, c'est du DCAT maintenant.

[at-github]

Qu'est-ce que ça donne avec les autres types de moissonneurs (dcat, ckan, ods) ?

Comment tester ça stp ?

DCAT: https://demo.data.gouv.fr/fr/organizations/ville-devry-courcouronnes/ CKAN: https://demo.data.gouv.fr/fr/datasets/donnees-gtfs-du-reseau-de-transport-public-cara-bus/ ODS: J'en trouve pas 🤨

[at-github]

Je pense qu'il faut qu'on retravaille le wording : "dernière modification" vs "dernière mise à jour" risque de provoquer la confusion.

"dernière modification" -> "dernière révision" ? @abulte @alhyss un avis ?

Fiche non-moissonnée

### Fiche moissonnée

J'attend les réactions avant de faire la modification ?

[alhyss]

Je pense qu'il faut qu'on retravaille le wording : "dernière modification" vs "dernière mise à jour" risque de provoquer la confusion.
"dernière modification" -> "dernière révision" ? @abulte @alhyss un avis ?

@streino D'accord qu'il faudrait des libellés plus clairs, et "dernière révision" a l'intérêt d'être est en phase avec le vocabulaire utilisé côté INSPIRE. Mais le point qu'il me semblerait le plus important à clarifier est le fait qu'on parle de la date de création, de révision et de publication du jeu de données et pas de la fiche de métadonnées (du moins dans la version cible, si j'ai bien compris c'est encore un peu confus pour les dates de création et publication à ce stade).

Donc je proposerais bien "dernière révision du jeu de données".

J'ai l'impression qu'il y a suffisamment de place pour ajouter cette précision ?

[at-github]

Je pense qu'il faut qu'on retravaille le wording : "dernière modification" vs "dernière mise à jour" risque de provoquer la confusion.
"dernière modification" -> "dernière révision" ? @abulte @alhyss un avis ?

@streino D'accord qu'il faudrait des libellés plus clairs, et "dernière révision" a l'intérêt d'être est en phase avec le vocabulaire utilisé côté INSPIRE. Mais le point qu'il me semblerait le plus important à clarifier est le fait qu'on parle de la date de création, de révision et de publication du jeu de données et pas de la fiche de métadonnées (du moins dans la version cible, si j'ai bien compris c'est encore un peu confus pour les dates de création et publication à ce stade).

Donc je proposerais bien "dernière révision du jeu de données".

J'ai l'impression qu'il y a suffisamment de place pour ajouter cette précision ?

C'est modifié

[streino]

L'ajout de "... du jeu de données" sur les différentes dates alourdit pas mal et me semble redondant, dans la mesure où on pourrait l'ajouter dans la plupart des entrées de l'encart : "Licence du jeu de données", et par la suite "Couverture territoriale du jeu de données", etc.

Même Geonetwork ne s'embête pas avec ça, donc je serais tenté de suivre le mouvement :

On pourrait par contre utiliser "Mise à jour des métadonnées". Ça aurait l'avantage de clarifier les autres dates par contraste, et d'être cohérent avec l'entrée "Qualité des métadonnées" de data.gouv. Je m'attends à ce qu'on ait moins de cas "... des métadonnées" que de cas "... du jeu de données", donc on devrait gagner sur la moyenne :)

Pour ce qui est du changement "modification" -> "révision", tout à fait d'accord. C'est cohérent INSPIRE et Geonetwork.

[at-github]

L'ajout de "... du jeu de données" sur les différentes dates alourdit pas mal et me semble redondant, dans la mesure où on pourrait l'ajouter dans la plupart des entrées de l'encart : "Licence du jeu de données", et par la suite "Couverture territoriale du jeu de données", etc.

Même Geonetwork ne s'embête pas avec ça, donc je serais tenté de suivre le mouvement :

On pourrait par contre utiliser "Mise à jour _des métadonnées_". Ça aurait l'avantage de clarifier les autres dates par contraste, et d'être cohérent avec l'entrée "Qualité des métadonnées" de data.gouv. Je m'attends à ce qu'on ait moins de cas "... des métadonnées" que de cas "... du jeu de données", donc on devrait gagner sur la moyenne :)

Pour ce qui est du changement "modification" -> "révision", tout à fait d'accord. C'est cohérent INSPIRE et Geonetwork.

J'ai supprimé "du jeu de données" redondant.
Concernant la proposition "Mise à jour des métadonnées", c'est à mettre dans tous les cas (harvest ou pas) ?

[abulte]

@streino on est bon ? sinon dis-moi, je ferai les changements.

[streino]

Il y a la question du "Dernière mise à jour des métadonnées". Qui malheureusement(?) m'a fait tirer d'autres fils...

Si on utilise "Dernière mise à jour des métadonnées", on devrait aussi utiliser "Création des métadonnées" dans le cas d'une fiche directement créée sur data.gouv. Je sais pas pourquoi mais ça convient pas super pour "Création". Ça passerait mieux avec "Création de la fiche de métadonnées" par exemple. Alors que sur "Mise à jour" ça ne me choque pas 🤷

Par ailleurs, INSPIRE ne spécifie qu'une seule date de métadonnées :

TG Requirement C.7: metadata/2.0/req/common/md-date
The latest update date of the metadata description shall be given for each metadata record. It shall be encoded using the gmd:MD_Metadata/gmd:dateStamp element. If no updates to the metadata have been made since publishing it, the creation date of the metadata shall be used instead.
The multiplicity of this element is 1.

Donc est-ce qu'on se complique pas la vie à vouloir afficher "Création" concernant les MD ? Geonetwork ne le fait pas.

Partant de là, j'ai l'impression qu'on devrait systématiquement séparer dates données et date métadonnée. Ce qui donnerait :

• Pour une fiche native data.gouv : Aucun changement (par rapport à l'existant data.gouv) car on a que la date MD. Sauf éventuellement à renommer "Dernière mise à jour" en "Dernière mise à jour des métadonnées" pour clarifier.
• Pour une fiche moissonnée : Toutes les dates données dispo (pour l'instant création/révision) + "Dernière mise à jour des métadonnées" (quand on aura branché la MD INSPIRE correspondante).

On pourrait clarifier cette distinction en séparant les deux types de dates dans l'encart. Ça aurait d'autant plus de sens visuellement si on utilise le label "Dernière mise à jour des métadonnées" :

Producteur                            -|
                                       |
Création                               |
                                       |
Publication                            | section données
                                       |
Révision (ou Dernière révision)        |
                                       |
Licence                               -|

Dernière mise à jour des métadonnées  -|
                                       | section métadonnées
Qualité des métadonnées               -|

Voire même redesigner un jour l'encart pour expliciter ces deux sections (et éviter de répéter "des métadonnées" sur les labels si on en ajoute d'autres), mais ça ne me semble pas urgent.

@abulte WDYT?

[abulte]

Je pense qu'on s'éloigne un peu du scope de la PR. Démêler le micmac métadonnées vs données mérite une autre discussion, et peut-être même d'autres métadonnées (sic). Il faudra probablement étendre le panneau d'informations, l'encart ne suffira pas.

L'objectif principal ici AMAH est de rendre l'information plus fiable pour les usagers d'écologie.data.gouv.fr, en essayant de rester simple.

Je dirais donc que "Publication" et "Dernière révision" sont déjà un joli pas en avant et ne sont pas fondamentalement faux.

[streino]

J'ai l'impression qu'on peut faire un légèrement plus grand pas sans ouvrir la discussion sur d'autres MDs, et qui aurait le mérite d'être plus compréhensible (au moins pour moi 😅).

Si je reprend le truc sous forme de tableau pour comparer les deux possibilités :

Proposition d'origine - ecolabdata/ecospheres#422 (comment) :

	non-moissonnée	moissonnée
"Création"	created_at	-
"Publication"	-	harvest.created_at
"Dernière modification"	-	harvest.modified_at
"Dernière mise à jour"	last_update

Nouvelle proposition - #592 (comment) :

	non-moissonnée	moissonnée
"Création"	created_at -	-
"Publication"	-	harvest.created_at
"Dernière révision"	-	harvest.modified_at
"Dernière mise à jour des métadonnées" (déplacé sous la license)	last_update	last_update

Cf #615 pour le diff.

C'est à la fois :

• Plus proche de data.gouv pour les fiches non-moissonnées : on change rien, si ce n'est l'ordre de présentation dans l'encart et l'ajout de "des métadonnées" dans le label (ce label étant déjà utilisé pour le score qualité, on n'introduit pas une nouvelle complexité en parlant de "métadonnées").
• Pas vraiment plus compliqué pour les fiches moissonnées : une MD de plus.
• Potentiellement plus lisible dans l'ensemble : on se contente d'ajouter des infos, plutôt que d'en substituer.

Ça introduit par contre la question de la pertinence de last_update pour les fiches moissonnées. C'est la raison pour laquelle on avait initialement décidé de la supprimer. Mais cette date joue un rôle particulier (utilisée pour les tris, affichée sur les cartes en page liste des jeux de données), donc il me semble en fait judicieux de la conserver, du moins tant qu'on ne s'attaque pas au reste des fonctionnalités qui l'utilisent.

Je serais tenté d'ajouter une infobulle pour expliquer que last_update concerne les métadonnées data.gouv et non celles d'origine, mais ça peut faire l'objet d'une autre PR, ou attendre qu'on s'attaque plus précisémment cette MD (qui aura une source différente selon que c'est une fiche data.gouv ou moissonnée, donc plus complexe à gérer).

[streino]

Au delà de la solution choisie, je me demande s'il y a pas quelque chose à faire sur l'espacement entre les différentes dates, vs l'espacement entre ces dates et les autres MD sémantiquement distinctes.

Dans la version actuelle l'espace entre Publication et Dernière révision me semble trop grand :

[abulte]

Au delà de la solution choisie, je me demande s'il y a pas quelque chose à faire sur l'espacement entre les différentes dates, vs l'espacement entre ces dates et les autres MD sémantiquement distinctes.

Dans la version actuelle l'espace entre Publication et Dernière révision me semble trop grand :

Je pense qu'il faut garder un espacement constant si la seule séparation est un espace.