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 ?
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
note : il me gène un peu dans le sens où il faudrait trouver UN usage unique du standard (“the use case”) or nous savons bien qu’un standard peut avoir plusieurs usages
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
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.
@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”.
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.
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.
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 ?
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
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
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 ?
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.
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. 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).
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
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.
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.
Notre ami @secourisme_net (Frédéric Séguret) a été plus vite que moi
Pour info, j’ai intégré les schéma de données des DAE dans le wiki OpenStreetMap avec les tags correspondants. Ce sera à discuter, à amender, car j’ai créée des tags pour l’occasion. Certains champs me semblent également inutile à chercher une correspondance OSM.
Cela étant je m’interroge sur le fait que l’identifiant interne du DAE dans la base de données, soit en diffusion limitée. Est-ce une erreur ou un acte délibéré, car je ne vois pas bien l’intérêt de se priver d’une clé unique.
J’étais tombé sur le code SIREN de l’exploitant, lui aussi limité, du coup il faudra se rabattre sur la raison sociale « figurant au RCS »… ce qui est une erreur car seules les entreprises commerciales y figurent, pas les collectivités. C’est la raison sociale de SIRENE qui aurait été plus pertinente et surtout le code SIREN.
Ce sont soit des erreurs, soit cela n’est que le résultat de la négociation avec les quelques acteurs privés qui aujourd’hui détiennent la majorité de ces données et ne partagent que sous la contrainte.
Par contre, pour les horaires d’ouverture, c’est le format utilisé par OSM qui a été retenu, mais comme c’est facultatif, je doute qu’il sera souvent renseigné.
Dommage que ce genre de choix ne soient pas faits avec plus d’aller-retour qu’une consultation « en aveugle » où chacun a pu donner certes son avis, mais sans retour qui aurait évité après quelque itérations ce genre de problème. C’est de l’ouverture quand même encore bien « top down ».
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 
