Commentaires (32)

@Topinambeur : je pense que ta remarque sur ODATA était plutôt à destination de Thomas...(les noms des contributeurs sont en bas du message et non en haut ;-)
As-tu la référence exacte du texte de la commission européenne qui énonce la règle que tu évoques ?

@Julien : merci pour le lien, le doc va devenir mon livre de chevet !
Sais-tu si l'étude du CETE s'est également penchée sur la norme SIRI (données de transport temps réel) ?

@Vincent : Non lors de notre étude nous ne nous sommes pas penché sur cette norme. La seule norme concernant les données de transports sur laquelle on a travaillé est Netpune.

@VincentD effectivement je me suis trompé, je voulais pinguer @ThomasVAILLIER.

Pour la référence du texte européen, il s'agit du cadre européen d'interopérabilité de 2004 qui est publié ici : http://ec.europa.eu/idabc/en/document/3473.html

La définition des standards ouverts est située page 9.

Je rejoins les nombreux avis exprimés : il faut avant tout employer des formats ouverts, tels que décrits sur Wikipedia : http://fr.wikipedia.org/wiki/Formats_ouverts#Les_principa...
L'idéal étant de proposer un mix CSV/XML/JSON voire RDF à la fois pour le statique et le dynamique.

Je vote aussi pour un mix de formats ouverts sous forme de "dumps" mis a jours régulièrement en fonction de la nature des données (1 fois par jours, mois, année...):

CSV, JSON, XML

+ des exemples de scripts de conversion pour passer d'un format a l'autre.

et éventuellement (dans un second temps) des APIs HTTP + JSON / XML pour un parcours plus interactifs (requetage dynamique par identifiant, recherche plein texte, range de dates, requêtes géographiques...)

De plus il serait intéressant de rendre ces données capables de s'inscrire dans un contexte d’interprétation sémantique qui rendra plus aisée la recombinaison avec d'autres bases de données structurées (Open Data publique de collectivités locales ou des bases d'entreprises privées).

Dans la pratique ce la passe par exemple par décrire les attributs d'entités géographiques en réutilisant des schemas de données existants comme celui de schema.org par exemple pour les lieux:

http://schema.org/Place

Les autres types et leurs attributs sont décrits ici:

http://schema.org/docs/schemas.html

Et éventuellement avec des typages plus fins comme ceux de DBpedia (extraits semi-automatiquement de Wikipedia), par exemple pour une gare:

http://dbpedia.org/ontology/Station

De la même manière il peut etre aussi utile d'identifier des instances de ces types par des identifiants uniques déréferenceables pour lever toute ambiguités. Par exemples les noms de certaines petites communes françaises peuvent être ambigus (avec des homonymes en France et à l'étranger). Par exemple les communes et les régions du fichier des gares pourrait etre mises en relations avec des fiches structurées telles que:

http://dbpedia.org/page/Royan

Ou des gares telles que:

http://dbpedia.org/page/Gare_Montparnasse

et ainsi de suite.

Enrichir vos données pour inclure explicitement de tels liens vers des définitions d'entités sur des bases externes permet la désambiguïsation (en cas d'homonymie) mais également la fusion et l'enrichissement des données avec les sources liées ou d'autres sources tierces qui possèdent également des liens sur une référence commune.

Pour intégrer ces informations sémantiques dans un format ouvert tel que le JSON il est notamment possible d'utiliser une convention telle que JSON-LD:

http://json-ld.org

Il a notamment des exemples de données utilisant les vocabulaires de schema.org sur cette page de demo:

http://json-ld.org/playground/

Ne pas oublié aussi RDF comme format, très important.

L'interprétation sémantique est en effet très intéressante, mais c'est pas la principale chose à faire, d'aurant plus que Schema.org est encore en béta et donc encore jeune pour être utilisé pour des données aussi importante, vaut donc mieux utiliser des formats de données structurées plus classique comme RDFa. Mais ceci doit être la dernière étape dans la publication de données sémantique.

Pour le moment, la première chose à faire avant de publier des données de manière structurée dans du HTML, il faut déjà publier les données dans le contexte 5 étoiles comme le décrit si bien Tim Berners-Lee. Plus de détail ici http://lab.linkeddata.deri.ie/2010/star-scheme-by-example/

Une fois que les données seront publiées suivant ce standard alors il faudra ajoutées des données structurées dans le HTML.

@Julien mes propositions sont 100% compatibles avec les technos basées sur RDF et RDFa:

• schema.org est un vocabulaire RDF:

http://schema.rdfs.org/
http://blog.schema.org/2011/11/using-rdfa-11-lite-with-sc...

• de même DBpedia propose des dumps RDF complets et un point d'entrée SPARQL pour des requetes dynamiques:

http://wiki.dbpedia.org/Downloads37
http://dbpedia.org/sparql

• enfin tout ce qui est écrit avec JSON-LD en ré-utilisant (ou non) des vocabulaires courant comme schema.org, dbpedia, foaf, dublincore, goodrelations, sioc... est convertibles automatiquement dans n'importe quel autre syntaxe RDF par exemple avec cet outil en ligne du W3C:

http://www.w3.org/2007/08/pyRdfa/Shadow.html

J'ai choisit volontairement de pas rentrer dans ces détails techniques dans mon commentaire initial afin d'essayer de démontrer en priorité l’intérêt de lier ses données et de réutiliser des vocabulaires existants.

A mon sens il est inutile d'essayer de "vendre" artificiellement la stack Semantic Web complète (RDF/XML, turtle, ntriple, SPARQL, SWRL) à des développeurs web "classiques" qui ne feront pas l'effort de rentrer dans ces technos si on ne leur montre pas concrètement à quoi ça sert avec des exemples et des mots simples plutôt que des acronymes.

Enfin RDFa c'est très bien mais c'est plus pour publier un contenu qui contient à la fois une mise en forme (HTML) et du contenu structuré (les attributs RDFa eux memes). Dans le cas de l'initiative data.sncf.com il me semble plus opportun de se focaliser au moins dans un premier temps sur les données brutes (tabulaires) sans mise en forme HTML ou autres.

@Olivier, je n'ai jamais dit le contraire, je dit juste que c'est pas forcément la meilleure façon de commencer.

Schema.org est en effet 100% compatible avec RDF mais c'est pas encore un standard (vue que la norme sur les microdata et donc HTML5 n'est pas encore terminé) il y a donc un risque d'adopter, pour un projet aussi conséquent, une techno pas encore finie et aussi jeune qu'est Schema.org.

DBPedia propose en effet un SPARQL endpoint et des dumps RDF régulier et c'est une très bonne base à laquelle la SNCF peut interconnecter ses données en faisant bien attention à bien nettoyer car les données de DBPedia sont pour la plupart très mal organisée. Freebase à moins de contenu mais à une fiabilitée sur les données qui est beaucoup plus grande.

L'utilisation de JSON-LD est une excellente chose, je l'utilise moi même pour quelques projets, mais il ne faut pas oublier que ce n'est pas (encore car c'est en cours) un standard, donc à bien faire attention car choisir des formats non standards comporte toujours des risques. Je pourrai dire la même chose de Turtle qui va devenir un standard avec la nouvelle norme RDF 1.1. D'ailleurs l'outil que tu donnes est régulièrement mis à jour en fonction des nouvelles draft qui sortent, notamment pour RDFa 1.1.

Je suis entièrement d'accord avec toi sur le fait qu'il est difficile pour des développeurs Web "classiques" d'assimiler ce domaine. C'est d'ailleurs pour cette raison que le CETE et le LIRMM travaillent conjointement sur des méthodes de publications des données de transport (Neptune).

Ta définition de RDFa est très correct, mais il ne faut pas oublier que Schema.org à le même but ;) il a été développé pour les Rich Snippet mais surtout conjointement avec Google, Microsoft et Yahoo! pour qu'il y ai un standard de structuration des données contenu dans le HTML et tout particulièrement dans le HTML5 d'où le choix de l'utilisation des microdata pour son fonctionnement. Sauf que RDFa à un vocabulaire beaucoup beaucoup plus étendu puisque que l'on peut lui ajouter tous les vocabulaires que l'on veut^^ Mais bon il est prévu pour Schema.org de pouvoir permettre aux utilisateurs d'étendre le vocabulaire en l'interconnectant avec d'autres. Mais ce n'est pas encore pour tout de suite.

@Julien On est d'accord. Juste une précision, dans schema.org il y a deux choses:

• un vocabulaire : la listes des classes et de leurs attributs (exprimable formellement avec RDFS + OWL)

• une syntaxe pour l'embarquer dans du HTML (en fait il y en a 2): HTML5 microdata et RDFa-Lite

La partie qui m’intéresse dans schema.org c'est la partie vocabulaire indépendamment de la syntaxe utilisée.

@Olivier Exact, tu as raison :-) Schema.org, une fois terminé, est un projet qui aura beaucoup d'avenir.

Pour les développeurs (web ou autre), le plus simple est une API REST retournant du XML ou du JSON.

Télécharger et décompresser des fichiers contenant du CSV est vraiment trop lourd, d'autant que cette opération doit être reproduite très régulièrement (pratiquement tous les jours) pour s'assurer d'avoir les dernières versions de ces données. De plus, ce principe de fonctionnement exclut totalement la possibilité de récupération de données en temps réel (récupération des horaires à une gare, par exemple).

De plus, comme cela a été dit par certains, une API REST peut parfaitement proposer différents formats de récupération (XML, JSON, CSV, etc.) et différentes versions d'API.

On pourrait par exemple, pour récupérer les prochains horaires de passage d'un train, imaginer des requêtes comme suit :

• http://data.sncf.com/api/1.0/nexttimes/melun/xml
• http://data.sncf.com/api/1.0/nexttimes/melun/json
• http://data.sncf.com/api/2.0/nexttimes/melun/xml
• Etc.

Ce type de projet d'API est-il prévu ?