Loi défibrillateur cardiaque


(Charles Nepote) #21

Merci pour vos cas “terrain” je comprends un peu mieux. Est-ce une question d’accès depuis la voie publique ou d’accès illimité : dans le cas de votre supermarché je comprends qu’il est parfois fermé (probablement la nuit et le dimanche) et que le défibrillateur n’est pas accessible en permanence ; dans le cas du gymnase je crois comprendre qu’on peut l’utiliser n’importe quand, c’est ça ? Dans le cas où l’accès est possible sans limite, est-ce que la solution n’est pas de préciser que l’accès est possible 24/24-7/7 ? C’est cette information qui compte non ? Du coup la notion ACCES_LIBRE n’aurait plus lieu d’être non ?

Il y a peut-être une bonne raison de garder ACCES_LIBRE mais je ne vois toujours pas pourquoi. Il permet de distinguer plus facilement, avec un peu de redondance, les défibrillateur accessibles 24/24-7/7 ?


(Dominique Baron) #22

Merci Laure nous cherchions des acteurs ayant réfléchi à la question, je pense que ARLoD l’a également déjà fait. On peut retrouver les infos demandés par ARLodD dans un formulaire de déclaration des défibrillateurs sur leur site http://arlod.e-monsite.com/medias/files/formulaire-declaration-dae-arlod-3.pdf
ACCESS_LIBRE c’est accessible 24/24-7/7=oui - heures ouvrables=non + horaire ouverture, tout cela pour moi est la m^me chose juste une histoire de sémantique. il faut simplement s’accorder sur les éléments de réponse dans le corps du tableau pour qu’il soit compréhensible et réutilisable


(Charles Nepote) #23

J’ai regardé dans le détail. Il y a pas des bonnes choses mais dans l’ensemble et je trouve ça très (trop ?) généraliste.
Les choses intéressantes :

Ce qui est moins bien :

  • ils ont voulu embrasser trop large, du plus petit standard au standard international complet estampillé W3C : il aurait été plus utile je trouve de réduire le champ aux standards plus “simples”, plus “locaux” si je puis dire ; ou de faire des entrées “quick and (not so) dirty standards” ou “standards for dummies”
  • je pense que dans certains cas on peut prendre des raccourcis, des libertés sur la manière et les moyens
  • les grands principes ne sont pas lisibles immédiatement
  • le prisme anglo-saxon est gênant je trouve : pourquoi s’intéresser à d’autres langues et d’autres cultures ? Je note tout de même nos amis de Nord Ouvert : http://standards.theodi.org/community/who-can-i-work-with/opennorth/

(Charles Nepote) #24

Oui merci @LaureHuguenin. Et merci Dominique pour avoir trouvé le formulaire que je cherchais en vain… On voit qu’il n’est pas très différent de ce que l’on propose sauf qu’il ne contient pas de donnée pivot (code INSEE pour la ville). Comme leur base est privée il y a également toutes les données relatives au gestionnaire du défibrillateur, ce qui est intéressant pour des relances par exemple, mais qui pose le problème des données à caractère personnel. Sans doute serait-il utile de créer deux standards : un standard incluant les données “gestionnaire” et l’autre les excluant, les deux partageant le maximum de champs communs. Le premier pourrait ainsi être utilisé par les agents publiques (ou des acteurs privés) pour suivre des “parcs” de machines.

Oui d’accord. C’est le documentation qui doit permettre de comprendre et le nom des champs ne fait qu’aider si possible.


(Charles Nepote) #25

@dom_datarmor je te sens hyper-chaud, on pourrait ouvrir un pad et faire converger toutes nos discussions. En parallèle on peut aussi documenter la façon dont le fait pour pouvoir le refaire sur d’autres cas. Et ça nous permettrait d’avoir une documentation exemplaire sur ce jeu de données.

Je suis souvent partant de faire une première proposition construite pour la mettre en discussion. Mais le petit risque s’est aussi d’assécher la participation si on en fait trop : “c’est leur truc”.


(Joël Gombin) #26

puis-je suggérer, plutôt qu’un pad (éphémère, peu versionnable…) un repo github, avec utilisation des issues ? Ça m’intéresse aussi de participer, pas tant pour le sujet de fond que pour la méthodo d’élaboration et de maintien d’un standard.


(Joël Gombin) #27

et côté Etalab/Etat ? Rien ?


(Charles Nepote) #28

Le pad c’était la première étape. Ce qui m’ennuie un peu avec Github (que j’utilise pour la spec des prénoms des nouveaux-nés), c’est qu’il représente plusieurs barrières à l’entrée :

  • tout est en anglais
  • il faut posséder un peu de culture informatique pour en comprendre le fonctionnement

Je pense qu’il faut maintenir deux canaux :

  • un canal très accessible : ici c’est bien mais quand il faut rédiger un doc on touche aux limites du forum ; cela dit le forum pourrait peut-être servir pour les remontés
  • un canal éventuellement plus technique, permettant une collaboration plus rigoureuse, un versionnement, etc.

Donc si tu veux bien on peut démarrer un pad ou gdocs pour faire simple avant de basculer sur Github.


(Charles Nepote) #29

Pas de retours pour l’instant mais je ne trouve pas dramatique de bosser de notre côté. Ça nous permet d’y réfléchir et des propositions bien instruites le moment venu non ?


(Joël Gombin) #30

Pas de souci, je comprends bien ta préoccupation. À court terme je suis sûr que tu as raison, à long terme je ne sais pas mais à long terme nous sommes tous morts :wink:


(Dominique Baron) #31

ok je suis chaud mais github pad ce que vous voulez pourvu que se soit facile d’accès et pas trop compliqué …comme de l’opendata…et comme ce que l’on veut faire…enfin j’éspère


(Loïc Haÿ) #32

Parmi les ressources intéressantes, il y a également la sélection d’outils pour trouver des standards ouverts http://standards.theodi.org/find-existing-standards/tools-to-find-open-standards/ mais qui là aussi est trop ancrée dans le contexte anglo-saxon … Il serait peut-être opportun de commencer à recenser des standards utilisables et utilisés dans le contexte de l’ouverture des données en France / Europe, sur le modèle de ce tableau par exemple ? Des listes de recommandations sont maintenues par des gouvernements (USA, Ireland, UK) : Etalab/Etat pourrait aussi aller dans ce sens ?


(Charles Nepote) #33

C’est parti : https://annuel.framapad.org/p/spec-defibrillateurs
Ce que je propose pour le moment c’est seulement de synthétiser tout ce qu’on a raconté dans cette discussion : de quoi on parle, quels usages possibles, les champs, la spec de chaque champs.


(Johan) #34

J’ai contribué sur le pad :

OpenStreetMap

Tag emergency=defibrillator

http://overpass-turbo.eu/s/Ac7

Cartographie qui montre que la donnée est assez complète

Documentation

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator

Tags complémentaires

opening_hours pour préciser les horaires de dispo
access (oui/non…) pour préciser l’accès (cf. https://wiki.openstreetmap.org/wiki/FR:Key:access)
defibrillator:location pour préciser textuellement l’endroit où il est situé
indoor (oui/non) pour préciser si il est en intérieur ou pas

Ca me paraît une bonne base de départ, non ?

Si l’objectif est d’écrire un schéma en partant de zéro il me semble que le premier pas est de regarder la base de données la plus complète sur le sujet et de s’en servir comme modèle pour ce schéma, puis faire converger les autres producteurs vers un schéma communément accepté.
Et quoi de plus complet qu’OSM en matière de défibrillateurs ?
Bien sûr, OSM (de même que Wikidata) ne respecte pas un schéma à proprement parler. :slight_smile: Mais ça me paraît plutôt un avantage qu’un inconvénient ! Agilité avant tout. Ne pourrait-on pas créer un système ou la logique est “OSM d’abord, schéma ensuite” ? en ajoutant les défibrillateurs sur OSM et en exportant au besoin vers un jeu de données CSV qui respecte un schéma JSON calqué sur les tags OSM ? Un peu à l’image de ce que fait Jungle Bus avec le GTFS par exemple (en utilisant osm2gtfs).

PS : et pour contribuer à OSM spécifiquement sur ce sujet, il y a déjà un projet MapContrib ! Que demander de plus ?


(Dominique Baron) #35

Je me suis parti du terrain pour proposer un prototype de fichier sur Dat’Armor et à ODF pour l’extension du SCDL, à partir d’une application sur le store qui n’existe plus


(Charles Nepote) #36

Ta proposition est intéressante Johan mais pose plein de questions et de problèmes.

Tout d’abord le cas des défibrillateurs vient “d’en haut” et la loi impose la création d’une base de données nationale. Pour des questions de pérennité on peut penser que l’État voudra l’opérer et ne pas la laisser dans les mains d’un service dont il connaît mal le fonctionnement et les engagements.

On pourrait d’ailleurs trouver assez logique que l’État ne veuille pas se fier à un outil dont le schéma n’est pas fixé et peut évoluer sans qu’il soit consulté.

Ensuite il me paraît illusoire de proposer à tous les agents publics concernés de verser des données de ce type dans OSM : même avec MapContrib il faut connaître un minimum le fonctionnement d’OpenStreetMap. Je ne parle même pas de basculer automatiquement des données dans OSM, pratique très surveillée par la communauté. Il faut bien connaître les rouages d’OSM pour savoir ce qui est possible ou non.

Je peux me tromper mais OpenStreetMap ne pourra probablement pas accueillir des données à caractère personnel qui pourraient être utiles à cette base (par exemple pour suivre localement l’évolution du “parc”) : les acteurs publics devront donc faire le travail en double.

Pour toutes ces raisons ça ne me paraît pas aujourd’hui réaliste. Mais l’idée est évidemment inspirante :

  • tout d’abord elle raconte qu’il est important de tenir compte de la sémantique d’OSM et d’essayer de d’en approcher pour garantir la possibilité de facilement importer des données dans OSM
  • elle suggère aussi que des acteurs privés opérateurs ou des petits territoires acculturés à OSM, comme Dignes-les-Bains, pourraient vouloir utiliser OSM directement, en connaissance de cause

On se posait la question plus haut dans la conversation, mais le champ opening_hours semble en particulier très bien spécifié par OSM : https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
Le tag defibrillator:location convient aussi.
À l’inverse, le tag access me paraît mal adapté aux usages. Et je m’interroge sur l’intérêt/l’adaptation à l’usage du tag indoor.

Je pense que tout s’éclaircira quand on rédigera.


(Donat ROBAUX) #37

Cette opinion n’engage que moi, mais pour le coup, je suis d’accord avec Charles sur l’opportunité de prévoir qu’OSM soit le réceptacle de la BNDef. Je ne suis pas sûr que ce soit une bonne idée.
Je préfère largement des beaux fichiers opendata mis à jour régulièrement avec plein de champs utiles, qu’OSM pourra intégrer via nos mécanismes habituels. Je vais faire mes remarques dans le pad concernant les champs.
Pour la petite histoire, nous avions contacté de manière informelle les collecteurs d’infos des défibrillateurs. Certains étaient prêts à jouer le jeu de l’ouverture et d’autres beaucoup moins, pour ne garder les infos que pour les Samu… Autant vous dire que c’est une sacrée avancée… à concrétiser car la route sera longue.