Schéma des lieux proposant des services #214
Comments
|
Merci beaucoup pour la création de l'issue ! Il y a sans doute un joli chantier qui nous attend, car la modularisation des schémas de données a des conséquences non négligeables sur la manière de publier/récolter les données. Il y a un bel enjeu de conception à cet égard - qui pourrait peut être prétendre à un financement Dapsi d'ailleurs ? @cedricr pour être plus explicite, il semble que l'interface la plus utilisée pour publier des jeux de données soit toujours le bon vieux tableur. Je ne sais pas si Open Data France (@johanricher ) a des informations à ce sujet, en tout cas la modularisation des schémas aurait des conséquences sur les interfaces de saisies ? On se planifie une discussion en début d'année sur le sujet ? @geoffreyaldebert @vinber ? (si tu es à Toulouse @cedricr j'essaye d'y monter pour l'occasion :) ) |
|
Avec grand plaisir @bouviermullerp! (on a déjà un rendez-vous pris dans le cadre de Dora début janvier je crois d'ailleurs!) |
|
Voir pour regarder du côté de schema.org pour "place" https://schema.org/Place ? |
A mon sens il n'y a pas de "modularité" des schémas, avec par exemple des schémas lieux et services qui seraient imbriqués pour qu'un seul et même producteur les utilise dans un processus unifié. Il faut considérer la production des données des lieux et des données des services comme des processus distincts, correspondant à des métiers ou des politiques publiques distincts, menés par des organisations distinctes. A mon sens c'est vraiment important de rappeler qu'un schéma n'est pertinent que si des organisations produisent déjà des données sur ce sujet et ont vocation à les publier. C'est pour ça qu'il faut identifier les données déjà produites (mais pas forcément publiées !) et concevoir le schéma avec leurs producteurs. Quand il s'agit d'ERP par exemple, les données sont déjà détenues par les collectivités ou établissements publics qui sont propriétaires et/ou gestionnaires de ces lieux. Un schéma adapté à cette réalité leur permettra de savoir à l'avenir quel est le formalisme à suivre pour publier ces données (i.e. respecter la loi), ce qui permettra à data.gouv.fr de les agréger ensuite à l'échelle nationale. C'est grâce à un identifiant unique que ces lieux pourront être référencés dans d'autres données, par exemple les données des services fournis dans ces lieux, et qui en l'occurence seront produites par d'autres acteurs spécialisés. publier.etalab.studio est un outil à disposition de tous les acteurs qui pourra, si nécessaire, les aider à produire des données conformément aux différents schémas. |
Je cherchais à mettre un nom sur ce qu'on cherche à modéliser, et me faisais aussi la réflexion que schema.org apporte un cadre assez bien défini et supporté par des usages très nombreux. "Lieu" ne correspond en effet à aucune définition juridique ou administrative (contrairement à ERP) ou de spécification existant (comme schema.org). Il faut deconstruire les concepts existants : Etablissement recevant du public (ERP)
C'est un type de lieu, tous les lieux ne sont pas des ERP. Cependant on peut faire l'hypothèse que des organisations publiques (qui ont donc vocation à mettre leurs données en open data) ont déjà des données sur les ERP dont elles ont la propriété ou la gestion. Equipement collectifDéfinition donnée par un groupe de travail EquipCo du CRIGE PACA en 2008 :
C'est un type de lieu, tous les lieux ne sont pas des équipements collectifs. Le schéma, écrit en 2018, et issu d'un vieux groupe de travail de 2008, n'a jamais été adopté. Des leçons doivent être tirées de cet échec ! Place(qu'on pourrait traduire par "endroit" ou "lieu") Spécification défine par schema.org
A l'avantage d'être générique, ce qui est très souhaitable pour ce schéma des "lieux". "Place" ne correspond pas à la notion de bâtiment (qui elle porte par exemple la notion d'adresse, correspondant à l'entrée sur la voie publique). Dans ce modèle, un "endroit" peut ainsi contenir (ou être contenu dans) un autre "endroit". Point d'intérêt (PoI, pour Point of Interest)Notion de cartographie popularisée par les GPS puis par les applications comme Google Maps. Correspondance assez forte avec la notion de "Place" dans schema.org ; ce n'est pas un hasard puisque les spécifications schema.org ont été écrites pour un usage par les moteurs de recherche et en particulier par Google. D'où une modélisation d'ailleurs assez "business-centric". La correspondance dans OSM est plus floue. N'importe quel élément de base tel qu'un noeud (point) peut porter des attributs et ce sont eux qui vont faire de cet élément un point d'intérêt spécifique ( Dernier détail à savoir : les éléments qu'on peut apparenter à des PoIs dans OSM (noeuds, surfaces...) n'ont pas d'identifiant pérenne ce qui ne permet pas de les référencer à l'extérieur. |
@johanricher à mon avis, ce sont deux usages distincts, mais tous les deux interessants.
@bouviermullerp |
Oui l'identifiant unique va être un des gros problèmes à résoudre. Quelques pistes de reflexion: https://www.teamopendata.org/t/identifiant-unique-batiment/2899/29 |
|
Pour les ERP, je m'étais arrêté aux travaux de l'IGN sur lesquels je n'avais pas vraiment vu de suite. J'avais vu un prototype local jamais passé à l'échelle mais sans avoir les raisons profondes de l'absence d'avancement (moyens humains, financiers, temps, difficulté à récupérer les données des acteurs détenant la donnée,... parmi mes hypothèses sans réponse) https://geoservices.ign.fr/sites/default/files/2021-07/Note%20sur%20la%20cr%C3%A9ation%20d%27une%20couche%20ERP%20dans%20la%20BD%20TOPO%C2%AE.pdf Pour les équipements collectifs, j'ai tendance à les assimiler à la "Base permanente des équipements / BPE" de l'INSEE https://www.insee.fr/fr/metadonnees/source/serie/s1161 mais qui exclue déjà de nombreux lieux par rapport à la discussion sur les "Schéma des lieux proposant des services" du fait que ces équipements ne prennent pas en compte les initiatives privées, sauf erreur. |
|
Un grand + pour tous les éléments techniques et sémantiques.
Je pense qu'on est d'accord sur le fond, et que c'est peut être ce qu'on met derrière "modularité" qui est différent. Deux questions :
|
geoffreyaldebert
added
the
Schéma en investigation
|
Une discussion intéressanté liée : https://teamopendata.org/t/identifiant-unique-batiment/2899/20 |
|
L'API du marché de l'inclusion, récemment publiée, liste elle aussi des 'lieux proposant des services' |
|
Pour essayer d'avancer, est-ce qu'on pourrait essayer de décomposer le problème? A. l'identification unique B. l'identification "lisible" C. la classification D. l'adressage / la localisation géographique E. les horaires F. les informations de contact G. les metadonnées |
|
Très pertinent: https://numerique-en-communs.fr/exploration-donnees-territoires/
Merci @bouviermullerp ! |
|
@cedricr je connais vraiment trop mal le sujet, mais j'aurai tendance à ne pas associer F/ et oui pour tous les autres, F/ étant soumis à beaucoup d'interprérations (bailleur/locataire/etc.) Je notifie AntoineBreitwiller sur le forum Open Data. |
@bouviermullerp ça me parait être une information fondamentale quand même, non? Est-ce qu'il ne faudrait pas juste rajouter un champ "type de contact"? |
@bouviermullerp oui c'est une discussion extrêmement intéressante, mais à voir si on aura la même granularité: est-ce que le "batiment" est l'entité pertinente ici? |
|
@cedricr fondamtentale...ment pas RGPD ? 🔒 😄 |
Non c'est clair, ça peut être un problème, mais pas si on met des emails/téléphones "publics" je pense (ceux qui seraient cités sur le site web de la structure) |
Excellente question ! Je vais enquêter sur ce sujet avec le réseau ami des juristes qui doivent avoir un point de vue sur la question. https://twitter.com/Calimaq |
|
On parle de "lieux" donc à la base c'est géographique. Pour la partie géo, ça peut se limiter à un lat/lon, donc ponctuel, soit à une emprise surfacique et tout ça peut en plus avoir une hiérarchie que la géo peut rendre implicite:
Cela ne permet pas des liens explicites entre bases, mais ils sont implicites par la géo... avec une marge de flou plus ou moins bien facile à gérer. A. Identifiants unique... Le SIRET identifie plus ou moins une activité dans un lieu donné. On a de plus une idée par le code NAF/APE de l'activité en question et par qui elle est assurée (le préfixe SIREN). C'est pas parfait, car tout n'est pas dans SIRENE... surtout les activités non économiques (un bon nombre d'associations manquent). Le SIRET est quand même loin d'être parfait mais a l'avantage d'être attribué par un seul organisme, l'INSEE. Je pense que les identifiants uniques non signifiants ne fonctionnent que lorsqu'on a ce mode de fonctionnement; enregistrement obligatoire et attribution centralisée de l'id. B. Les libellés... Les noms, enseignes... c'est un beau bazar, regardez le nombre de champs que SIRENE prévoit pour ça ! Pour les rapprochements, on se raccroche à ça quand on n'a pas mieux. C. Classification D. Adressage / localisation L'adresse est un index le long d'une voie... elle n'identifie par le lieu en lui même mais le moyen d'y accéder. Si on saisit une adresse, il faudrait toujours le faire avec une saisie par autocomplétion pour choisir une adresse existant dans un référentiel, ce qui du coup permet de récupérer une position géo immédiatement et de conserver l'identifiant unique de l'adresse et pas seulement son libellé. L'idéal est en plus de montrer sur une carte, pour éventuellement affiner la position ;) Associer le lieu à une géométrie (ponctuelle ou surfacique) est quand même le mieux, mais ça ne peut pas se systématiser, surtout sur des données existantes. Le lien avec le bâtiment n'est pas forcément pertinent... il va falloir gérer les services proposés dans des lieux qui comportent de multiples bâtiments... par évident du tout. Je rappelle les multiples relation 0-N qu'on a entre adresses, parcelles et bâtiments... E. Horaires F. Contact G. Métadonnées Je pense qu'en l'absence d'identifiant unique et centralisé, ce n'est que par l'accumulation de champs pouvant être rapprochés qu'on arrive à apparier des données. Vous avez regardé datatourisme ? ça mélange lieux et services... |
|
Pour la géométrie, suivre les travaux de @datagistips frictionlessdata/datapackage#771. |
Tout à fait! Encore que ces lieux peuvent éventuellement être conceptuels (siège social), et les services être proposés dans d'autres lieux (antennes, maraudes, évenement organisé à l'exterieur, etc.)
Mon opinion est que lat/lon suffisent ici; on n'a pas besoin d'une répresentation précise du lieu. Dans ce schéma, le lieu me semble plus un "aggrégateur de services" qu'une entité géographique interessante en tant que telle. Mais ce n'est que mon opinion, et c'est pour ça qu'on en discute!
Entièrement d'accord avec toi, je partirais aussi sur le siret, avec éventuellement un second code pour les éventuelles subdivisions; dans ce cas il n'y aurait pas d'attribution centralisée, mais ce serait de la responsabilité de la structure.
👍
SIREN -> SIRET oui, mais pour un même SIRET on peut avoir des tonnes de lieux (ex: les antennes de la Croix Rouge)
Entièrement d'accord avec tout ça. De notre coté (schéma de l'inclusion) on proposera un formulaire de saisie qui permettra ça au mieux, mais on ne peut pas exclure ceux qui veulent saisir directement des données tabulaires, éventuellement préexistante. Et dans ce cas, il parait difficile de leur demander de renseigner lng/lat, et il faudra alors le géocoder. Et oui, effectivement il faut une absolument des colonnes pour indiquer source et fiabilité de la géo.
👍
Ça me parait quand même hyper compliqué pour les besoins de ce schema
Merci infiniment pour tous ces avis precieux! |
Oui! Et idéalement de pouvoir synchroniser des mises à jour provenant de sources differentes…
Pas encore, mais merci pour le pointeur… |
|
Documentation DATAtourisme: https://www.datatourisme.gouv.fr/ontology/core/#PointOfInterest |
oui pour la croix rouge, une discussion sur la team opendata sur un identifiant unique généré avec le siret plus un mix lat-long (mais cela semble une fausse binne idée) si on parle de lieux conceptuels, alors les cas encore plus à la marge n'ayant pas de siret (en particulier les associations n'ayant pas eu besoin de siret, ni salarié ni demande de financement). |
Est-ce que le RNA les contient bien dans ce cas? |
|
Merci pour la qualité des échanges, on avance :) Je viens d'arriver sur le sujet, en sidekick de @cedricr 🦹🏻 Je pense qu'ici on veut pouvoir décrire quelque chose de très générique, donc même la notion de bâtiment est trop contraignante (le lieu peut être sur un terrain de sport, un terrain vague, dans une forêt, sur un parking...). Les coordonnées géographiques sont donc centrales, même si d'autres données peuvent les compléter avantageusement :
Ici l'accent est mis sur "décrire où se trouve un lieu et comment y accéder". Voyez-vous d'autres objectifs pour ce schéma ? |
|
Merci Colin de relancer ce sujet qui n'a aucunement perdu de son importance. Oui l'objectif est de ne pas créer un n-ième "standard" mais de permettre de publier des données qui s'appuient sur les standards existants. Donc un schéma le plus générique possible (à l'échelle de la France), mais qui pourra servir de hub vers d'autres données (par exemple identifiant BatID pour un bâtiment, identifiant BAN de l'adresse, identifiant acceslibre*, etc.). En essayant de réduire au minimum son périmètre, dès que d'autres schémas, données ou services traitent déjà le sujet. Par exemple :
* voir aussi MTES-MCT/acceslibre#277 |
|
Oui, je n'étais pas au courant de l'initiative sur les schémas de parking à vélo :) Si ce schéma supporte les stationnements privés (accessible uniquement aux usagers d'un lieu), alors ça marche ! |
Description du schéma
Plusieurs schemas déjà publiés aujourd'hui ou à l'étude correspondent à des "lieux" qui proposent des "services": lieux d'inclusion numériques, accessibilité des ERPs, équipements collectifs, etc.
Chacun réinvente la partie "lieu" dans son schéma: identifiant, adresse, informations de contact, horaires, etc. Pour une meilleure interopérabilité il parait souhaitable de réfléchir à un schéma commun pour le "lieu", et à ne garder que la partie spécifique (le ou les "services") dans les schémas dédiés.
Liens
Equipement collectifs: https://schema.data.gouv.fr/scdl/equipements/
Lieu d'inclusion numérique: https://schema.data.gouv.fr/etalab/schema-inclusion-numerique/
Accessibilité des ERP: https://schema.data.gouv.fr/MTES-MCT/acceslibre-schema/
Tiers-lieu: #179
Offre d'insertion: #206
Commentaire sur les tiers lieux décrivant la nécessité de la séparation lieux/service: #179 (comment)
Stade d'avancement
Ce schéma est :
The text was updated successfully, but these errors were encountered: