Julien et Olivier Grisel ont commenté
Olivier Grisel a voté
Guillaume a voté
Roux a voté
Roux a commenté
Topinambeur a commenté
VincentD, Topinambeur et Julien ont commenté
Guillaume a voté
Pierre et Thomas VAILLIER ont commenté
VincentD, Vincent et Mathias Herberts ont commenté
François a voté
Mourad a commenté
Yassine a voté
Ferdinand a voté
Adrien a partagé
A propos de SNCF Open Data
- CGU - Contactez-nous - Mode d'emploi - Mentions légales
- Imagine Cup 2012
© 2012
Commentaires (31)
Ferdinand
Par définition, les données ouvertes doivent être sous le format le plus brut possible, le moins traitée possible. On penserait donc au format natif dans lequel elles sont récoltées, sinon au Raw Data Format qui est une pratique généralisée pour l'Open Data.
Selon le mécanisme de mise à disposition des données: téléchargement ponctuel du dataset, query sur les datasets actualisés en permanence, API, ces formats peuvent aussi varier.
Stéphane
Comme je l'avais signalé, deux formats sont à définir:
Mourad
Pourquoi ne pas rester sur un seul format de données pour les deux types données (statique et dynamique) ?
Ferdinand
La création d'une API est un élément crucial lorsqu'on cherche à ouvrir son service aux développeurs.
L'implication des développeurs est essentielle car ce sont eux, avec leurs idées auxquelles l'entreprise fournissant ses APIs n'avait pas pensé, qui mènent les évolutions du produit API.
Lier une relation de confiance avec la communauté de développeur est un élément essentiel à la réussite d'un tel projet.
Mourad
Je pense que le format XML est un bon format à envisager. Même si il est plus "lourd" que le Json par exemple, il n'e reste pas moins un standard exploitable par n'importe quel communoté de développeurs (Java/.Net/C/ObjectiveC/Python etc)
L'un des services que pourrais fournir cette API serait aussi d'offrir des mécanismes de rendering au choix, dans des formats exploitable par le grand public. Exemple: http://api.sncf.com/gares/Stationnements/idf pourrait retourner un flux XML des stationnements régies par la SNCF en Ile de france
http://api.sncf.com/gares/Stationnements/idf/csv le même flux en fichier csv etc...
Mathias
Il faut différencier deux types de données, les données statiques d'une part dont la mise à jour est faite périodiquement mais avec une périodicité potentiellement longue, de quelques heures à quelques jours/semaines/mois, et les données dynamiques qui évoluent en temps réel.
Pour les premières, peu importe le format dès lors que celui-ci est documenté. J'ai pour ma part tendance à écarter le XML qui est verbeux, mais c'est un choix personnel.
Pour les données dynamiques, avant d'envisager un mode de distribution il faut clairement identifier les données, en effet selon le volume de celles-ci et la fréquence de mise à jour, la mise à disposition pourra aller d'une URL toute bête renvoyant les dernières valeurs à une API plus élaborée, mais ne pas mettre la charrue avant les bœufs.
VincentD
Je partage les différents avis concernant le format :
Une question complémentaire se pose : pour des données de type "évènement" (ex: un retard sur un train) un mécanisme de push serait plus approprié : avez-vous des idées sur une implémentation envisageable ? Par exemple, une API REST qui renvoie les x derniers messages pourrait-elle convenir selon vous ?
Vincent
Je ne suis pas un grand fan de l'API REST, malgré ses qualités propres. A l'heure actuelle, je me base sur du CSV et du RDF. Le SPARQL permet d'interroger directement les données (je pense aux données dynamiques). En aucun, je suis pour l'utilisation des fichiers, techniquement on peut très bien s'en passer quelque soit les données. Pour les développeurs, un SPARQL-Endpoint permet à chacun d'utiliser son format de prédilection.
VincentD
Je ne connaissais pas le SPARQL...intéressant.
En revanche, quand on voit ce qui existe (en France), on retrouve surtout des API REST avec des réponses XML et JSON, ainsi que (beaucoup) de fichiers aux différents formats.
Le dernier exemple en date est le portail open data de Nantes (data.nantes.fr).
J'ai quand même l'impression que ces formats sont en train de devenir des standards de fait...
Vincent
La France n'est pas encore un exemple dans ce domaine. Pour moi, c'est une erreur la multiplication des fichiers, même en qualité de développeur, même si je peux faire les extractions nécessaires. En fait, ce que je propose c'est que la technique soit totalement transparente pour l'utilisateur final de l'application. L'API REST donne une URL complexe et visible, même si techniquement nous pouvons faire une réécriture d'URL. J'ai simplement donné des formats de base reconnus dans l'écosystème opendata en cours. A ma connaissance la SNCF sera la première entreprise et donc se doit de proposer une approche innovante par rapport aux pratiques en cours.
Mourad
Concernant la multiplication des fichiers en fait ça dépend des usages. D'ailleurs il faut prendre en compte les usages potentiels des données ainsi que le profil des utilisateurs qui vont les importer/utiliser. Je suis d'accord avec toi Vincent sur le fait qu'un développeur préfère avoir affaire à une API, plutôt que de traiter un fichiers et en faire une extraction nécessaire. Sauf que le public visé par un projet Open Data est large, et pour une grande partie d'entre eux une API est quelque chose d'abstrait, de compliqué, etc...
J'ai parlé hier avec une amie qui fait de la recherche dans le domaine de l'analyse spatiale, cartographie des risque, sciences du sol etc. Elle utilise beaucoup des données de géolocalisation, issue de l'Open data, qu'elle importe et traite. Pour elle, il est important que les données de géolocalisation soient disponibles avec un large choix, parmi les formats les plus utilisés (qui de facto deviennent des standards comme la dit VincentD)
Voici en gros son retour d'expérience (Et du coups l’approche de data.nantes.fr me paraît très logique)
"(...) Pour les données de géolocalisation:
Donc voilà , ça reste un point de vu issue d'un domaine bien spécifique. Néanmoins, l'approche de data.nantes.fr permet de répondre à des besoins différents et de couvrir un champs plus large où le développeur, le partenaire commercial, la SS2I, les ONG et les chercheurs, trouverons leur bonheur :)
Tout ça pour dire, que multiplier les fichiers n'est pas forcement une erreur Vincent, mais plutôt un avantage si on prend la chose d'un angle différent.
Vincent
Mourad,
Désolé de te répondre tardivement. Une API n'est pas nécessaire, un format ouvert avec SPARQL permet de s'en passer, en tant que développeur je travaille là-dessus. Je ne connais pas les formats ouverts pour les applications de géolocalisation, mais je suis d'accord sur le fait qu'il faut pouvoir donner cette possibilité. En dehors de ce domaine très particulier, les formats CSV et RDF me semble suffisant. A la limite, il faut pouvoir offrir une solution où la question du format ne se pose plus quelque soit l'utilisateur des données opendata. C'est génial de bosser là-dessus. A titre perso, c'est cela que je recherche.
Mathias Herberts
Il existe tout un tas de bibliothèques permettant de lire les shapefiles (.SHP), nul besoin d'avoir une licence ESRI.
Je prône une approche itérative, déterminons les données, mettez les à disposition simplement sous forme de fichiers dans un premier temps (même pour des données qui à terme seront temps réel), observons ce qu'il en est fait et itérons.
Un peu d'agilité que diable !
Vincent
Mathias, c'est pour cela que le format CSV est quasi un standard à ce niveau et que je l'inclu toujours dans ma démarche. Le grand avantage de ce format, c'est que l'on a réellement les données brutes et donc pour faire une application sur-mesure, c'est très pratique. En plus pour récupérer les données c'est très simple et léger.
VincentD
Sur la question de la publication des "raw data" au format CSV : je vois bien l'usage pour une plateforme tierce de récupérer cet ensemble de données, et le croiser (par exemple sur une map) pour une visualisation. En revanche, il me semble tout de même nécessaire qu'un projet open data puisse publier des données plus unitaires pour une utilisation "directe" dans un mahsup client (en situation de mobilité notamment).
Vincent
Vincent, tu as tout à fait raison. C'est pour cela que j'utilise indifféremment CSV et RDF comme format de données. Il faut pouvoir proposer les deux.
Thomas VAILLIER
Une bonne idée serait d'exposer les données sous la forme de flux OData (http://www.odata.org). C'est agnostique en terme de clients possibles et permet d'exposer ce qu'on veut, comme on veut.
Pierre
Je rejoins Ferdinand : Il faut absolument publier des données non seulement ouvertes mais pleinement réutilisables : à cet égard, on ne saurait se contenter de proposer de sous forme d'une collection, aussi riche soit-elle, de fichiers XLS, PDF ou même CSV qui vont nécessiter beaucoup de travail pour que les données qu'ils renferment soient vraiment exploitées.
Le W3C a défini des standards pour l'accès aux données brutes, via l'approche du "web sémantique" ou "web des données" qui seul permet une réutilisation généralisée des données, par la mise en réseau massive des silos de données ouvertes où qu'ils se trouvent sur le web. Ces standards s'appellent XML, RDF, OWL et SPARQL, ils sont désormais matures et de nombreux outils existent pour les mettre en œuvre.
C'est notamment le cas de ceux proposés par Antidot - chez qui je travaille - et déjà utilisés par des clients comme le CNRS, EDF R&D ou encore LexisNexis (*) : les solutions Antidot Information Factory et Antidot Finder Suite permettent, de manière industrielle, de mailler très largement des données de provenance et de nature très diverses, de les exploiter et de les valoriser. Pour ceux qui ne connaîtraient pas et souhaiteraient découvrir l'approche ouverte du "web des données" je conseille ce blog dont l'approche est très pédagogique : http://www.lespetitescases.net/petite-histoire-du-web-sem....
Vous pouvez aussi consulter les différentes présentations d'Antidot sur Slideshare : http://www.slideshare.net/antidotNet
Je me permets d'insister : la donnée brute en RDF, publiée dans le nuage du LOD - voir http://punktokomo.abes.fr/2011/09/21/lactu-du-web-de-donn... pour mesurer la croissance fantastique du LOD cloud - est la seule vraie façon pérenne de permettre une réexploitation massive des données.
Espérer que des APIs associées à chaque jeu de données vont être vraiment utiles est illusoire, et pour une raison très simple : si pour bâtir une appli exploitant 13 jeux de données différents il faut se coltiner 13 APIs de fournisseurs différents, alors le résultat du développement sera un monstre totalement impossible à maintenir et à faire évoluer dans le temps, et donc au final inutile.
(*) Le rapprochement et la normalisation de données issues de silos différents pour ensuite construire un graphe RDF "propre" permettant des requêtes SPARQL d'une puissance inimaginables, cela peut se faire industriellement, notamment avec notre outil Antidot Information Factory. Lire ce doc de 4 pages pour comprendre ce que fait cette solution : http://bit.ly/doc-AIF
Pour information, Antidot a permis au CNRS de le faire sur 1,5 millions de documents scientifiques avec pléthore de méta-données, avec lesquelles on a construit un triple store renfermant environ 40 millions de triplets. Voir ce doc de 4 pages pour tout comprendre : http://bit.ly/CasClientISIDORE
Le résultat utilisable par tous c'est http://rechercheisidore.fr
Depuis, on a aussi fait la même chose sur 4 millions de documents juridiques chez LexisNexis France, pour le nouveau portail d'information destiné à leurs clients. Le triple store généré sur les métadonnées de ces documents (textes de lois, décrets, jugements, avis de cours d'appel etc etc) contient environ 90 millions de triplets...
Bref aujourd'hui RDF et SPARQL cela marche, reste à imaginer ce que l'on veut en faire :-)
Topinambeur
@vincent ODATA n'est pas un format ouvert. En effet, comme le rappelle la commission européenne pour être un format ouvert il faut que la gestion du format et de ses évolutions soit réalisé par une organisation à but non lucratif dont la gouvernance est ouverte. Ce n'est pas le cas pour les initiateurs de l'ODATA.
De plus, l'ODATA est contrairement à ce que vous dite pas très agnostique en terme de technologie.
RDF et SPARQL sont de vrais formats ouverts, ils sont des déjà bien utilisés et existent depuis plus longtemps que l'ODATA.
Pourquoi donc vouloir réinventer la roue ?
Julien
Bonjour,
Une initiative a déjà été prise par le CETE en collaboration avec le LIRMM pour la publication des données de transport sur le Web de données en RDF.
Vous pourrez trouver plus d'information sur cette étude sur ce site :
http://www.cete-mediterranee.fr/tt13/www/article.php3?id_...