Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit timestamps #81

Open
anteverse opened this issue Feb 24, 2022 · 2 comments
Open

Audit timestamps #81

anteverse opened this issue Feb 24, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@anteverse
Copy link

Bonjour,

Avant toute chose, le service est d'une très grande qualité, très bien documenté et performant. C'est un excellent exemple de ce à quoi doit ressembler l'open-data.

Est-il possible d'accéder aux timestamps d'audit des données, par exemple :

  • le timestamp de création du document. À différencier de la date de rendu de la décision.
  • le timestamp d'update du document. Plus précis que la date.
  • et aussi, pourquoi pas, le timestamp de publication du document, ou mise en ligne, qui est toujours plus grand que la création.

Pourquoi ?

  • timestamps : l'évaluation par timestamps permet de d'avoir une résolution d'overlap beaucoup plus fine quand on lance 2 appels successifs. En filtrant sur une date simple, on a facilement des overlaps.
  • timestamp de publication : de nombreuses décisions sont publiées après leur date de rendu, ce qui me semble tout à fait normal, car la rédaction ne peut être instantanée. Avec l'exemple suivant :
    • la décision A, du 24 février est publiée le 24 février,
    • la décision B, du 23 février est publiée le 26 février,
    • la décision C, du 25 février est publiée le 25 février,
      Dans ce cas on perd la notion d'ordre. Et un export quotidien filtré sur la date de création va manquer la décision B, car le 26 février elle sera publiée avec la date de création du 23 février.

La possibilité d'ordonner selon un timestamp de publication résout ce problème. En attendant, une des solutions consiste à faire un appel quotidien à /export selon la date de modification en plus de la date de création.

Des exemples dans l'open-data en France : CR de réunion en commission CRCANR5L15S2022PO59051N006

  • l'Assemblée nationale différencie 4 timestamps:
    • la création du document → date de rédaction
    • le dépôt du document → date de rendu
    • la mise en ligne des metadata sur leur portail open-data
    • la mise en ligne du contenu du document

S'il y a de meilleures stratégies à adopter de mon côté, n'hésitez pas à me le signaler.

@SebCourvoisier
Copy link
Collaborator

Bonjour,

La principales dates qui nous parviennent (rendu, création, mise à jour) ne contiennent pas d'information horaire.

Par souci de simplicité et d'homogénéité de l'API, il a été décidé de conserver un tel format pour toutes les informations de date publiées (normalisées au format ISO-8601 réduit, YYYY-MM-DD).

Cependant il paraît effectivement pertinent que les informations de date de mise en ligne et de mise à jour (timestamp ISO-8601 complet). Cela nécessite une évolution en cours d'analyse.

@anteverse
Copy link
Author

Merci @SebCourvoisier pour les renseignements.

Cependant il paraît effectivement pertinent que les informations de date de mise en ligne et de mise à jour (timestamp ISO-8601 complet). Cela nécessite une évolution en cours d'analyse.

Très bien, je suivrais avec beaucoup d'attention cette évolution. J'imagine qu'il sera aussi possible de filtrer / ordonner selon ces dates ?

@SebCourvoisier SebCourvoisier added the enhancement New feature or request label Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants