Voici la 7e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

7. Recettes pour exposer des informations sous la forme de données liées

Ce chapitre fournit des recettes pratiques pour la publication de différents types d’informations sous la forme de données liées. Les informations doivent remplir au moins les conditions suivantes pour être considérées comme « publiées en tant que données liées sur le Web » :

  • Les choses doivent être identifiées avec des URI HTTP déréférenceables.
  • Si un tel URI est déréférencé en demandant un type MIME application/rdf+xml, une source de données doit retourner une description RDF/XML de la ressource identifiée.
  • les URI qui identifient les ressources non-informatives doivent être créés de l’une de manières qui suit : soit la source de données doit renvoyer une réponse HTTP 303 qui contient une redirection HTTP vers une ressource d’information décrivant la ressource non-informative, tel que discuté précédemment dans le présent document. Ou l’URI de la ressource non-informative doit être obtenue en prenant l’URI de la ressource d’information et en ajoutant un fragment d’identifiant (#foo, par exemple), tel que discuté dans la recette 7.1.
  • Outre les liens RDF aux ressources d’une même source de données, des descriptions RDF devraient également contenir des liens RDF vers des ressources fournies par d’autres sources de données, de sorte que les clients puissent naviguer sur le Web de données dans son ensemble en suivant les liens RDF.


Parmi les recettes suivantes, lesquelles correspondent à vos besoins ?

  • Quelle quantité de données voulez-vous servir ? Si vous voulez seulement de publier plusieurs centaines de triplets RDF, vous voudrez peut-être les servir dans un fichier RDF statique en utilisant la Recette 7.1. Si votre ensemble de données est plus grand, vous pourrez vouloir le charger dans un magasin RDF (en anglais : RDF store) propre et mettre le Pubby Linked Data Interface en face de celui-ci tel que décrit dans la recette 7.3.
  • Comment vos données sont-elles actuellement stockées ? Si vos informations sont stockées dans une base de données relationnelle, vous pouvez utiliser D2R Server comme indiqué dans la recette 7.2. Si l’information est accessible via une API, vous pourriez mettre en œuvre un wrapper autour de cette API comme décrit dans la recette 7.4. Si votre information est représentée dans un autre format tel que Microsoft Excel, CSV ou BibTeX, vous devrez d’abord le convertir en RDF comme décrit dans la recette 7.3.
  • Combien de fois vos données doivent-elles changées ? Si vos données changent fréquemment, vous préférez les approches qui peuvent générer des vues sur vos données RDF, tels que D2R Server (Recette 7.2), ou les wrappers (Recette 7.4).

Après avoir publié vos informations sous forme de données liées, vous devez vous assurer qu’il y a des liens RDF externes pointant vers des URI de votre ensemble de données, de sorte que les navigateurs RDF et les robots puissent trouver vos données. Il existe deux méthodes de base pour y parvenir :

  1. Ajouter plusieurs liens RDF à votre profil FOAF qui pointent des URI identifiants des ressources centrales de votre dataset. En supposant que quelqu’un dans le monde vous connaisse et note votre profil FOAF, votre nouvel ensemble de données sera désormais accessible via des liens RDF.
  2. Convaincre les propriétaires de sources de données liées d’auto-générer des liens RDF vers des URI de votre dataset. Ou pour faciliter les choses pour le propriétaire d’un autre ensemble de données (en anglais dataset), créez des liens RDF vous-même et envoyer les lui, il ne lui plus qu’à les fusionner avec son ensemble de données. Un projet qui est extrêmement ouvert à la création de liens vers d’autres sources de données RDF est le projet communautaire DBpedia. Il suffit juste d’annoncer votre source de données sur la liste de diffusion DBpedia ou d’envoyer un ensemble de liens RDF à la liste.

7.1 – Servir des fichiers statiques

La plus simple façon de servir les données liées est de produire des fichiers RDF statiques et les télécharger sur un serveur web. Cette méthode est généralement choisie dans les situations où

  • les fichiers RDF sont créés manuellement, par exemple lors de la publication personnelle fichiers FOAF ou de vocabulaires RDF ou
  • les fichiers RDF sont produits ou exportés par un bout de logiciel qui n’a que des sorties fichiers.

Il y a plusieurs aspects à considérer :

Configuration du serveur pour des types MIME correct

Les anciens serveurs Web ne sont parfois pas configurés pour renvoyer le bon type MIME lorsqu’ils doivent servir des fichiers RDF/XML. Les navigateurs de données liées peuvent ne pas reconnaitre les données RDF servies de cette façon parce que le serveur fait valoir que ce n’est pas RDF/XML, mais du texte brut. Pour savoir si votre serveur a besoin d’une correction de ce problème, utilisez l’outil cURL et suivez les étapes décrites dans ce tutoriel.

La façon de réparer cela dépend du type de votre serveur web. Dans le cas d’Apache, ajoutez cette ligne au fichier de configuration httpd.conf, ou à un fichier. Htaccess dans le répertoire du serveur web où les fichiers RDF sont placés :

AddType application/rdf+xml .rdf

Cela indique à Apache de servir les fichiers ayant une extension .rdf en utilisant le bon type MIME pour RDF/XML, à savoir application/rdf+xml. Remarque, cela signifie que vous avez nommer vos fichiers avec l’extension .rdf.

Pendant que vous y êtes, vous pouvez également ajouter ces lignes pour faire en sorte que votre serveur web soit prêt pour d’autres syntaxes RDF (N3 et Turtle) :

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Taille du fichier

La publication de pages HTML de très grandes tailles n’est pas recommandée, car elles se chargent très lentement dans les navigateurs et consomment inutilement de la bande passante. La même chose est vraie quand il s’agit de publication de données liées : vos fichiers RDF ne devraient pas être plus grand que, disons, quelques centaines de kilo-octets. Si vos fichiers sont plus volumineux et décrivent de multiples ressources, vous devez les diviser en plusieurs fichiers RDF, ou l’utilisation Pubby tel que c’est décrit dans la recette 7.3 et ainsi les servir par morceaux.

Lorsque vous servez plusieurs fichiers RDF, assurez-vous qu’ils sont liés les uns aux autres par le biais de triplets RDF qui impliquent des ressources décrites dans les différents fichiers.

Le choix des URI pour les ressources non-informatives

L’approche de fichiers statiques ne supporte pas les 303 redirections nécessaires pour les URI des ressources non-information. Heureusement il existe une autre méthode conforme aux normes de nommer les ressources non-information, qui fonctionne très bien avec les fichiers statiques RDF, mais a un inconvénient, nous discuterons plus tard. Cette méthode est fondée sur les URI avec dièse.

Lorsque vous servez d’un fichier statique RDF à, disons, http://example.com/people.rdf, vous devez alors le nom de la non-information sur les ressources décrits dans le fichier en ajoutant un identificateur de fragment d’URI du fichier. L’identifiant doit être unique dans le fichier. De cette façon, vous vous retrouvez avec des URI comme cela pour votre non-ressources d’information :

  • http://example.com/people.rdf#alice
  • http://example.com/people.rdf#bob
  • http://example.com/people.rdf#charlie

Cela fonctionne parce que les clients HTTP déréférencent les URI avec dièse en séparant la partie qui suit le dièse et en déréférençant l’URI résultant. Un navigateur de données liées va ensuite se scruter la réponse (le fichier RDF dans ce cas) et trouver des triplets qui en disent plus sur la ressource non-informative, obtenant ainsi un effet assez similaire à la redirection 303.

L’inconvénient de cette approche est que le nommage des URI n’est pas très « cool » au sens des critères énoncés dans la section 3. Il y a une référence à un format de représentation spécifique dans les identifiants (l’extension .rdf). Et si plus tard vous décidez de renommer le fichier RDF, ou si vous décidez de diviser vos données en plusieurs fichiers, alors tous les identifiants changeront et les liens existants casseront.

C’est pourquoi vous ne devriez utiliser cette approche que si la structure globale et la taille de l’ensemble de données ne risquent pas de changer beaucoup dans l’avenir, ou pour une solution temporaire pour des données transitoires où la stabilité des liens n’est pas si importante.

Extension de la recette pour des redirections 303 et la négociation de contenu

Cette approche peut être étendue pour utiliser des redirections 303 et même pour permettre la négociation de contenu, si vous êtes prêt à faire toutes sortes de gymnastique. Malheureusement, ce processus dépend de votre serveur web et de sa configuration. Le W3C a publié plusieurs recettes qui montrent comment faire avec un serveur web Apache : Best Practice Recipes for Publishing RDF Vocabulaires. Le document est officiellement destiné aux éditeurs de vocabulaires RDF, mais les recettes marchent aussi pour d’autres types de données RDF servies à partir de fichiers statiques. Notez qu’au moment d’écrire il reste un problème avec la négociation de contenu dans ce document qui pourrait être résolu en passant le serveur Apache du mode mod_rewrite à celui de mod_negotiation.

7.2 – Servir des bases de données relationnelles

Si vos données sont stockées dans une base de données relationnelle, c’est généralement une bonne idée de les y laisser et de publier uniquement une vue sur les données de votre base sous la forme de données liées.

Un outil qui permet de servir des vues de bases de données relationnelles sous forme de données liées est D2R Server. D2R Server repose sur un mapping déclaratif entre les schémas de la base et les termes RDF ciblés. Sur la base de ce mapping, D2R Server sert une vue de données liées sur votre base de données et fournit un endpoint SPARQL pour la base de données.

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Il existe plusieurs serveurs D2R ligne, par exemple Berlin DBLP Bibliography Server, Hannover DBLP Bibliography Server, Web-based Systems @ FU Berlin Group Server ou EuroStat Countries and Regions Server.

La publication d’une base de données relationnelles sous la forme de données liées comporte habituellement les étapes suivantes :

  1. Téléchargez et installez le logiciel serveur comme indiqué dans la section Démarrage rapide de la page d’accueil D2R Server.
  2. Ayez un D2R serveur pour générer automatiquement un mapping D2RQ à partir du schéma de votre base de données (voir Démarrage rapide).
  3. Personnalisez le mapping en remplaçant les termes générés automatiquement par des termes de vocabulaires RDF bien-connus et accessibles au public.
  4. Ajoutez votre nouvelle source de données dans la liste des ensembles de données du Wiki ESW dans la catégorie « données liées » et dans la liste « endpoint SPARQL », puis établissez plusieurs liens RDF à partir de votre profil FOAF vers des URI de ressources centrales au sein de votre nouvelle source de données afin que les robots puissent découvrir vos données.

Alternativement, vous pouvez aussi utiliser :

  1. OpenLink Virtuoso pour publier votre base de données relationnelles à la façon de données liées.
  2. Triplify, un petit plugin pour les applications Web, qui révèle les structures sémantiques encodées dans les bases de données relationnelles en rendant le contenu disponible sous la forme de base de données RDF, JSON ou de données liées.

7.3 – Exposer d’autres types d’informations

Si vos informations sont actuellement représentées dans des formats CSV, Microsoft Excel, ou BibTeX et si vous voulez les servir comme des données liées sur le Web, voici des bonnes idées à réaliser dans ce qui suit :

  • Convertissez vos données en RDF en utilisant un outil de RDFisation. Il y a deux endroits où de tels outils sont répertoriés : ConverterToRdf qui est mis à jour dans le wiki ESW, et RDFizers maintenu par l’équipe de SMILE.
  • Après la conversion, stockez vos données dans un référentiel RDF. Une liste des référentiels RDF est maintenue dans le wiki ESW.
  • Idéalement, le référentiel RDF choisi est accompagné d’une interface de données liées qui prend soin de rendre accessibles vos données Web. Comme de nombreux référentiels RDF n’ont pas encore implémenté des interfaces pour les données liées, vous pouvez également choisir un référentiel qui fournit un endpoint SPARQL et met à disposition Pubby comme interface de données liées en front de votre endpoint SPARQL.

L’approche décrite ci-dessus est entre autres adoptée par le projet DBpedia. Ce projet utilise des scripts PHP pour extraire des données structurées à partir de pages Wikipédia. Ces données sont ensuite converties en RDF et stockés dans un référentiel Virtuoso OpenLink qui fournit un endpoint SPARQL. Afin d’obtenir une vue sous forme de données liées, Pubby est placé en front pour exploiter l’endpoint SPARQL.

Si votre ensemble de données est de taille suffisamment petite pour s’adapter complètement dans la mémoire principale du serveur Web, alors vous pouvez vous passer d’un repository RDF, et utiliser l’option conf:loadRDF de Pubby pour charger les données RDF à partir d’un fichier RDF directement dans Pubby. Cela pourrait être plus simple, mais à la différence d’un dépôt réel RDF, Pubby tient tout en mémoire principale et ne propose pas d’endpoint SPARQL.

7.4 – Mise en œuvre autour des applications existantes ou des API Web

Un grand nombre d’applications Web ont commencé à rendre leurs données disponibles sur le Web au travers d’API Web. Des exemples de sources de données fournissant de tels API sont donnés par des entreprises comme eBay, Amazon, Yahoo, Google et Google Base. Une liste plus complète des API se trouve sur Programmable Web. Différentes API fournissent différentes requêtes et interfaces d’extraction et renvoient les résultats en utilisant un certain nombre de formats différents tels que XML, JSON ou ATOM. Ceci conduit à trois limitations générales des API Web :

  • Leur contenu ne peut pas être exploré par les moteurs de recherche
  • Les API Web ne peuvent être accédés à l’aide de navigateurs de données génériques
  • Des Mashups ont été réalisés pour un certain nombre de sources de données et ne peuvent pas profiter des nouvelles sources de données qui apparaissent sur le Web.

Ces limitations peuvent être surmontées par la mise en œuvre de wrappers de données liées sur la base des API. En général, les wrappers de données liées procèdent comme ceci :

  1. Ils assignent des URI HTTP aux ressources non-informatives pour lesquelles l’API qui fournit des données.
  2. Lorsque l’un de ces URI est déréférencé en demandant un type application/rdf+xml, le wrapper réécrit la demande du client en une requête pour l’API sous-jacente.
  3. Les résultats de la requête de l’API sont transformés en RDF et renvoyés au client.

Exemples de wrappers de données liées notamment :

Le RDF Book Mashup

Le RDF Book Mashup expose l’information sur les livres, leurs auteurs, les critiques et les librairies en ligne, et les rend disponible sous forme RDF sur le Web. Le RDF Book Mashup assigne un URI HTTP pour chaque produit qui a un numéro ISBN. Lorsque l’un de ces URI est déréférencé, le Mashup demande des données sur le livre, son auteur ainsi que des notes de lecture et des offres commerciales à l’aide des API d’Amazon et des API Google Base. Ces données sont ensuite transformés en RDF et retournés au client.

Le RDF Book Mashup est implémenté comme un petit script PHP qui peut être utilisé comme modèle pour la mise ou point d’autres wrappers similaires dans d’autres API Web. Vous trouverez plus d’information sur le Book Mashup et la relation entre les API Web et les données liées en général dans The RDF Book Mashup: From Web APIs to a Web of Data (diapositives).

Exporteurs SIOC pour WordPress, Drupal, phpBB

Le projet SIOC a développé des wrappers de données liées pour les moteurs de plusieurs blogs populaires, des systèmes de gestion de contenu et des forums de discussion. Voyez exporteurs SIOC pour une mise à jour la liste de leurs wrappers. Le projet fournit également un API d’exportation en PHP qui permet aux développeurs de créer d’autres outils d’export SIOC sans qu’il soit nécessaire d’entrer dans des détails techniques sur la façon dont l’information est représentée en RDF.

Virtuoso Sponger

Virtuoso Sponger est un cadre pour le développement de wrappers de données liées (appelés cartouches) autour de différents types de sources de données. La source de données peut varier depuis la page HTML contenant des données structurées jusqu’aux API Web. Voyez Injecting Facebook Data into the Semantic Data Web pour une démonstration sur la façon utilisée par Sponger pour générer une vue de données liées sur Facebook.