Utiliser les filtres et ordres de l'API data.gouv.fr (thèmes et sous-thèmes blocking)

[abulte]

Following #164

Utiliser les filtres et ordres de l'API data.gouv.fr afin de basculer la navigation sur la liste des bouquets côté serveur.

[abulte]

Probablement pas utile tant que la liste des bouquets tient sur une page ou deux.

Also, les thèmes et sous-thèmes ne sont pas dispo dans l'API data.gouv.fr, on ne peut donc pas tout migrer côté serveur.

Peut-être envisager de migrer thèmes et sous-thèmes vers des tags ?

[streino]

Probablement pas utile tant que la liste des bouquets tient sur une page ou deux.

Tout à fait d'accord. Ca risque d'augmenter avec la territorialisation, mais tout dépend comment on gère le listing des bouquets territorialisés.

Le filtre par zone géo peut tout de même être intéressant pour offrir une vue ciblée d'un territoire. Ca reste du nice-to-have à ce stade (edit: c'est fait).

Peut-être découper en plusieurs étapes en fonction de l'importance des différents filtres. Et conserver ce ticket pour la mise en place de la mécanique de base (s'il faut la compléter ?). A discuter en hebdo -> [question]

Peut-être envisager de migrer thèmes et sous-thèmes vers des tags ?

On dupliquerait l'info ou on stocke uniquement dans des tags ? Si 2e option il faudra une convention (= prefix) pour les retrouver. Sauf si on abandonne l'affichage spécial du sous-thème ? cc @martyKN

[abulte]

On dupliquerait l'info ou on stocke uniquement dans des tags ?

Bonne question. J'ai l'intuition qu'on pourrait utiliser uniquement des tags. Le risque principal étant qu'ils soient modifiés par ailleurs, mais je connais pas d'acteur autre que data.gouv.fr via l'admin (et les propriétaires via l'API mais si on part par là...) qui puissent le faire, donc il me semble faible.

Ca pourrait ressembler à :

themes:
  id: logement
  label: Se loger
  tag: ecospheres:logement  # or use ecospheres:{id} 
  subthemes:
    - id: construction_renovation
      label: Construction et rénovation des logements
      tag: ecospheres:construction_renovation

[abulte]

Si 2e option il faudra une convention (= prefix) pour les retrouver. Sauf si on abandonne l'affichage spécial du sous-thème ?

Je pense que c'est intéressant de garder une hiérarchie quand même. Et on pourrait avoir besoin des tags pour autre chose que des thèmes / sous-thèmes.

[martyKN]

Je pense que garder thèmes/sous themes est important. Sinon on va perdre tout le monde rapidement. Soit trop de sous theme et donc illisible soit peu de theme et donc introuvable

[streino]

Je pense que garder thèmes/sous themes est important. Sinon on va perdre tout le monde rapidement. Soit trop de sous theme et donc illisible soit peu de theme et donc introuvable

Pas question ici de supprimer la navigation par thème/sous-thème. Je parlais de l'affichage du sous-thème en tant que "label" après le titre sur la page d'un bouquet.

Pour la navigation thème/sous-thème on a les thèmes hard-codés dans la config, donc pas besoin de les retrouver dans les tags pour ça. Par contre, pour l'affichage, à moins d'utiliser la-dite config pour essayer de matcher ce qu'il y a dans les tags (bof), on a besoin de "typer" les tags en tant que thème et sous-thème.

on pourrait avoir besoin des tags pour autre chose que des thèmes / sous-thèmes.

Oui, ce qui me fait dire que ecospheres:... est insuffisant : on pourrait avoir d'autres types de tags Ecosphères, voire des libres ajoutés pas les utilisateurs (qu'on ne veut pas propager sans contexte à tout data.gouv).

ecospheres:theme:..., ecospheres:subtheme:... ? Pas super user-friendly à l'affichage... A voir si c'est grave, ou si on applique une transformation au champ tag pour simplifier l'affichage (jouable en restant dans les composants data.gouv ?)

tag: ecospheres:logement # or use ecospheres:{id}

Le slug est intéressant si on affiche les tags tels quels (tjs plus lisible, y compris en debug), mais l'id évite de se retrouver avec des divergences label/slug bizarres comme on peut en voir sur data.gouv. Si on part sur un traitement des tags à l'affichage, j'aurais tendance à partir sur l'id ?

[streino]

TODO :

• arbitrer sur les thèmes / sous-thèmes en tags pour faire du full serveur (et voir comment ça scale up quand aura d'autres métadonnées ? plutôt contribuer l'indexation des extras sur data.gouv.fr ?)
• brancher les filtres API vs les filtres locaux sur le front

[abulte]

Argument sur indexer les extras : cas d'usage des séries. Un jeu de données peut être associé à une série, qu'on peut imaginer moissonner en extras. On aimerait pouvoir filtrer une liste de jeu de données en fonction de la série à laquelle il appartient.