Flags

[yohanboniface]

Les clients de l'API doivent pouvoir "flagger" n'importe quelle version de n'importe quel objet, pour lui attribuer une "validation" par ce "client". Il faut que ces flags soient exposés dans l'API et qu'il soit possible de récupérer des dumps avec préférence pour les versions flaggées. Il faut que la source des flags soit lisible par les utilisateurs de l'API, pour dire par exemple je ne veux que les flags IGN, ou que les flags collectivité territoriale, ou les deux, etc.

[cquest]

Tu fais référence à la notion de "coups de tampon" que j'ai proposé lors de l'openlab 3 ?

Une entrée doit contenir à minima:

• l'identifiant du client/user
• l'id de l'objet
• la version de l'objet
• timestamp

[ebuard]

Exact. Je crois que c'est la même chose. La question que je me pose est: quels sont les clients habilités à attribuer des flags/coups de tampon? Ils sont modifiables par une liste bien définies de clients particuliers, contenant par exemple: La Poste, IGN, mairies, communautés de communes, DGFiP, INSEE, SDIS, SAMU, Opérateurs de téléphone? Du coup, le coup de tampon n'est pas hyper clair, parce qu'il peut y avoir une certification à différentes échelles (nationale, régionale, locale). Oui, pour les différents attributs proposés par Christian.

[cquest]

Le principe c'est de savoir que X valide la version V d'un objet. On peut être plusieurs à valider ainsi un même objet. Comme je l'imagine, une validation n'est pas modifiable, elle pourrait toutefois être supprimée par le validateur lui même.

[MaelREBOUX]

Peut-on prévoir l'apposition d'un "tampon" en même temps qu'un "commit" ? En élément optionnel ? Parce que ça peut faire gagner beaucoup de temps pour nous les collectivités.

[MaelREBOUX]

Comment allez-vous gérer les cas tags / surtags pour les exports ?

Exemple :

1. création d'un "10 rue des Tulipes | bâtiment" + coup de tampon "autorité locale" -> v 1 certifiée
2. modification par le SDIS qui déplace / change les coordonnées -> v 2

Si le SDIS ne met pas de tampon, la v 2 n'est pas certifiée par l'autorité locale / n'a pas de tampon, c'est bien ça ? S'il le met, alors l'autorité locale peut, si elle le souhaite venir également tamponner cette v 2 -> l'objet a 2 tampons. C'est bien ça ?

DU coup : quelle est la différence avec l'attribut "source" ?

[yohanboniface]

DU coup : quelle est la différence avec l'attribut "source" ?

source est censé être la source de la donnée, à noter qu'il n'est présent que sur Position si ma mémoire est bonne. Le tampon signifie "moi, entité X, je valide ces données", peu importe leur source initiale.

Peut-on prévoir l'apposition d'un "tampon" en même temps qu'un "commit" ? En élément optionnel ?

Oui, il faudrait arriver à ça. Dans le cas de l'import BAL, tu vois ça ligne par ligne? Ou un paramètre global qui dit "toutes les adresses de ce fichier sont à tamponner"? Est-ce que ça pourrait faire sens que certains clients de la BAN (mettons un importeur BAL ou le guichet mairies) tamponnent automatiquement dès qu'il crée ou modifie un objet? J'ai peur que ce soit un peu violent, mais ça pourrait simplifier le worlflow, alors je pose la question quand même :)

Si le SDIS ne met pas de tampon, la v 2 n'est pas certifiée par l'autorité locale / n'a pas de tampon, c'est bien ça ?

Un tampon est "nominatif", c'est-à-dire associé à un Client, au sens OAuth de la BAN. Vraisemblablement, par exemple, on aura un client pour une éventuelle application "import BAL", qui pourrait si on le souhaite tamponner automatiquement tous les imports. Les SDIS de leur côté passeraient par exemple par un autre client, qui aurait ou pas le flag bit, et donc si un SDIS tamponne une resource, elle est tamponnée au nom de son client. Dans ton example, on aurait donc V1 avec tampon "collectivité" et V2 avec tampon "sdis". Tout ça reste à affiner, mais globalement on aurait un client pour les écritures directement par l'IGN, un pour celles de la Poste, un pour le guichet mairies, un pour un importeur BAL, etc. Et donc autant de tampons différents potentiellement. A noter qu'on peut imaginer que plusieurs Client aient le même "identifiant de tampon", par exemple "ign" ou "collectivité". Par exemple, le guichet mairies et un importeur BAL pourraient tous les deux avoir l'identifiant de tampon "collectivité".

[yohanboniface]

En termes de gestion de diffs, je me demande si tamponner une ressource doit ou non créer une nouvelle version de cette ressource. D'un côté, ça me semblerait très bruyant d'avoir une nouvelle version par tampon, plus ça voudrait dire ne pas pouvoir avoir deux tampons pour la même version. De l'autre, ce pourrait être plus cohérent pour les utilisateurs qui vont consommer les diffs d'avoir le diff d'une ressource quand elle est tamponnée. Pour l'instant, je pars sur l'option pas de nouvelle version, et j'ajoute la class Flag dans les diffs. Mais à discuter.

[MaelREBOUX]

Peut-on prévoir l'apposition d'un "tampon" en même temps qu'un "commit" ? En élément optionnel ?

Oui, il faudrait arriver à ça. Dans le cas de l'import BAL, tu vois ça ligne par ligne? Ou un paramètre global qui dit "toutes les adresses de ce fichier sont à tamponner"?

Paramètre global.

D'un côté, ça me semblerait très bruyant d'avoir une nouvelle version par tampon, plus ça voudrait dire ne pas pouvoir avoir deux tampons pour la même version.

C'est sur ça qu'on s'interroge : la relation adresse - tampon est 0-1 ou 0-n ? La plus value collaborative est dans le 0-n. Ex (indépendamment de l'histoire du versionnement) :

• 1 : "10 rue des Tulipes | bâtiment" + tampon autorité locale
• 2 : ""10 rue des Tulipes | bâtiment" + tampon La Poste

Dans une logique collaborative gagnant-gagnant il faudrait voir les 2 tampons, ce qui donnerait plus de "poids" à cette adresse. Or, pour le moment, on comprend qu'un tampon remplace un autre. Ce n'est pas souhaitable.

[yohanboniface]

Or, pour le moment, on comprend qu'un tampon remplace un autre.

Ce n'est pas le cas. C'est un tampon par client, et donc plusieurs clients peuvent tamponner la même ressource.

[cquest]

Le principe est bien de pouvoir cumuler les tampons, exemple: 10 rue des Tulipes (v1): tampon IGN, Poste 10 rue des Tulipes (v2): tampon autorité locale 10 rue des Tulipes (v3): pas de tampon (par exemple une contribution issue du crowdsourcing)

Le tampon se met séparément sur chaque objet qui compose au final l'adresse:

• tampon sur la rue
• tampon sur le numéro
• tampon sur la position...

ça permet l'IGN ou une commune dotée d'un SIG de valider une position, et à La Poste ou une commune sans SIG de ne valider que le numéro

Pour moi, un tampon ne doit pas incrémenter la version de l'objet.

[MaelREBOUX]

Donc au final, le 10 rue des Tulipes est tamponné par 3 contributeurs et ça doit se voir dans les infos de l'objet retourné. On est d'accord ?

+1 : pas d'incrément de version : on va pas s'en sortir sinon.