Voici la traduction française complète du tutoriel How to Publish Linked Data on the Web publié 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).
Ce document explique la façon de publier des données liées sur le Web. Après un aperçu général de la notion de données liées, plusieurs recettes pratiques sont présentées pour la publication d’information sous forme de données liées sur le Web.
- la section 1 introduit la problématique.
- la section 2 énonce les principes de base des données liées.
- la section 3 fournit des conseils pratiques sur la façon de nommer les ressources avec des références URI,
- la section 4 examine des termes bien connus de vocabulaires et de sources de données qui devraient être réutilisé pour représenter de l’information,
- la section 5 explique quelles informations doivent être incluses dans les descriptions RDF qui sont publiés sur le Web,
- la section 6 donne des conseils pratiques sur la façon de générer des liens entre les données RDF à partir de sources de données différentes,
- la section 7 présente plusieurs recettes complètes pour l’édition de différents types d’information comme données liées sur le Web à l’aide des outils liés publication des données existantes,
- la section 8 concerne le test et le débogage de sources de données liées,
- la la section 9 donne un aperçu des mécanismes de substitution pour la découverte de données liées sur le Web.
- et la la section 10 qui vous fournit des liens vers des documents de référence et de nombreux outils.
Il reste encore 3 annexes dans le tutoriel dont la traduction suivra.
Résumé
Ce document fournit un tutoriel sur la façon de publier des données liées sur le Web. Après un aperçu général de la notion de données liées, nous présentons plusieurs recettes pratiques pour la publication d’information sous forme de données liées sur le Web.
1 – Introduction : les données liées sur le Web
L’objectif des données liées est de permettre aux gens de partager des données structurées sur le Web aussi facilement qu’ils peuvent partager des documents d’aujourd’hui.
Le terme de données liées (en anglais : linked data) a été inventé par Tim Berners-Lee dans sa note d’architecture Linked Data sur le Web de données liées. Le terme se réfère à un style de publication et d’interconnexion des données structurées sur le Web. L’hypothèse de base est que plus les données sont étroitement liées à d’autres données, plus leur valeur et leur utilité augmente. En résumé, les données liées concernent tout simplement l’utilisation du Web pour créer des liens typés entre données provenant de sources différentes.
Les principes de base des données liées sont les suivantes :
- utiliser le modèle de données RDF pour publier des données structurées sur le Web
- utiliser des liens RDF pour interconnecter les données provenant de sources différentes
L’application de ces deux principes conduit à la création de données communes sur le Web, un espace où les gens et les organisations peuvent déposer et consommer des données de toutes sortes. Cet espace commun de données est souvent appelé le Web de données ou de Web sémantique.
Le Web de données peut être consultés à l’aide d’un navigateur de données liées (en anglais : Linked Data browser), tout comme le Web des documents est accessible en utilisant un navigateur HTML. Toutefois, au lieu de suivre des liens entre les pages HTML, les navigateurs de données liées permettent aux utilisateurs de naviguer entre les différentes sources de données en suivant les liens RDF. Cela permet à l’utilisateur de démarrer d’une source de données pour passer ensuite d’autres sites Web, potentiellement une infinité de sources de données connectées par des liens de RDF. Par exemple, si un utilisateur étudie les données sur une personne provenant d’une source, il peut être intéressé à poursuivre sur des informations sur la ville où réside cette personne. En suivant un lien RDF, l’utilisateur peut naviguer vers l’information sur cette ville figurant dans un autre ensemble de données.
Tout comme le Web traditionnel de documents peut être exploré en suivant les liens hypertextes, le Web de données peut être exploré en suivant les liens RDF. En travaillant sur les données explorées, les moteurs de recherche peuvent fournir des capacités de recherche sophistiquées, semblables à celles fournies par les bases de données relationnelles classiques. Parce que les résultats des requêtes elles-mêmes sont des données structurées, non pas seulement des liens vers des pages HTML, ils peuvent être immédiatement traitées, permettant ainsi une nouvelle classe d’applications basées sur le Web des données.
La glu qui maintient ensemble le Web traditionnel, celui qu’appelle le Web des documents, ce sont les liens hypertextes entre les pages HTML. La glu du Web de données, ce sont les liens RDF. Un lien RDF établit simplement qu’une donnée est en relation avec une autre donnée. Ces relations peuvent être de différents types. Par exemple, un lien RDF qui relie des données sur des personnes peut indiquer que deux personnes se connaissent, un lien RDF qui connecte les informations d’une personne avec des informations sur des publications dans une base de données bibliographiques pourrait stipuler que la personne est l’auteur d’un document précis.
Il existe déjà beaucoup de données structurées accessibles sur le Web via des API Web 2.0, comme par exemple pour eBay, Amazon, Yahoo et Google Base. Par rapport à ces API, les données liées ont l’avantage de fournir un mécanisme d’accès unique et normalisé au lieu de s’appuyer sur différents formats d’interfaces et de résultat. Cela permet aux sources de données :
- d’être plus facilement explorées par les moteurs de recherche,
- d’être accessibles à l’aide de navigateurs génériques de données,
- d’avoir des liens avec des sources de données différentes.
Après avoir posé les concepts des données liées, le reste de ce document se structure comme suit :
- la section 2 énonce les principes de base des données liées.
- la section 3 fournit des conseils pratiques sur la façon de nommer les ressources avec des références URI,
- la section 4 examine des termes bien connus de vocabulaires et de sources de données qui devraient être réutilisé pour représenter de l’information,
- la section 5 explique quelles informations doivent être incluses dans les descriptions RDF qui sont publiés sur le Web,
- la section 6 donne des conseils pratiques sur la façon de générer des liens entre les données RDF à partir de sources de données différentes,
- la section 7 présente plusieurs recettes complètes pour l’édition de différents types d’information comme données liées sur le Web à l’aide des outils liés publication des données existantes,
- la section 8 concerne le test et le débogage de sources de données liées,
- la la section 9 donne un aperçu des mécanismes de substitution pour la découverte de données liées sur le Web.
- et la la section 10 qui vous fournit des liens vers des documents de référence et de nombreux outils.
2 – Principes de base
Ce chapitre décrit les principes de base des données liées. Comme les données liées sont étroitement alignées sur l’architecture générale du Web, nous résumons d’abord les principes de base de cette architecture. Ensuite, nous donnons un aperçu du modèle de données RDF et donnons des recommandations sur la façon dont le modèle de données doit être utilisé dans le contexte de données liées.
2.1 – Architecture Web
Cette section résume les principes de base de l’architecture du Web et introduit une terminologie telle que ressource et représentation. Pour plus d’informations, vous pouvez vous référer à l’Architecture du World Wide Web, Volume 1 recommandation du W3C et les résultats actuels du W3C Technical Architecture Group (TAG).
2.1.1 – Ressources
Pour publier des données sur le Web, nous devons d’abord identifier les points d’intérêt de notre domaine. Ce sont les choses dont nous voulons décrire les propriétés et les relations dans les données. Dans la terminologie de l’architecture du Web, tous les objets d’intérêt sont appelés ressources.
Dans « Dereferencing HTTP URIs », le W3C Technical Architecture Group (TAG) distingue entre deux types de ressources : les ressources informatives et de ressources non-informatives (également appelés « autres ressources »). Cette distinction est très importante dans un contexte de données liées. Toutes les ressources que nous trouvons dans le Web traditionnel (on l’appelle aussi le Web des documents), comme des textes, des images et d’autres fichiers multimédias, sont des ressources informatives. Mais beaucoup de choses que nous voulons partager ne sont pas des données, par exemple : des personnes, des produits physiques, des lieux, des protéines, des concepts scientifiques, et ainsi de suite. En règle générale, tous les « objets du monde réel » qui existent en dehors du Web sont des ressources non-informatives.
2.1.2 – Identifiant de ressource
Les ressources sont identifiés à l’aide d’identifiant uniforme de ressource (URI). Dans le contexte des données liées, nous nous limitons uniquement à l’utilisation d’URI HTTP et évitons d’autres schémas d’URI comme les URN et DOI. Les URI HTTP forment de bons noms pour deux raisons : ils fournissent un moyen simple de créer des noms uniques au monde sans une gestion centralisée, et les URI fonctionnent pas seulement comme un nom, mais aussi comme un moyen d’accéder à de l’information sur une ressource dans le Web. La préférence pour HTTP sur d’autres formes d’URI est longuement discutée dans le projet de TAG du W3C URN, espaces de noms et les répertoires.
2.1.3 – Représentations
Les ressources d’information peuvent avoir des représentations. Une représentation est un flux d’octets dans un certain format, tels que HTML, RDF / XML, ou JPEG. Par exemple, une facture est une ressource d’information. Elle pourrait être représentée comme une page HTML, comme un document PDF imprimable, ou comme un document RDF. Une ressource unique d’information peut avoir de nombreuses représentations différentes, par exemple dans des formats différents, des qualités de résolution, ou des langues naturelles.
2.1.4 – Déréférencement d’URI HTTP
Le déréférencement d’URI est le processus de recherche d’un URI sur le Web afin d’obtenir des informations sur la ressource référencée. Le projet du W3C TAG concernant le déréférencement d’URI HTTP introduit une distinction sur la façon de déréférencer les URI de ressources informatives et de ressources non informatives :
Les ressources informatives : Quand un URI qui identifie une ressource informative est déréférencé, le serveur du propriétaire de l’URI génère habituellement une nouvelle représentation, un nouvel instantané de l’état actuel de la ressource informative, et la renvoie au client en utilisant le code de réponse HTTP 200 OK.
Les ressources non-informatives ne peuvent pas être déréférencées directement. Par conséquent, l’architecture du Web utilise une astuce pour permettre le déréférencement d’URI identifiants de ressources non-informatives : au lieu d’envoyer une représentation de la ressource, le serveur envoie au client l’URI d’une ressource informative qui décrit la ressource non des informations en utilisant le code de réponse HTTP 303 See Other. C’est ce qu’on appelle une redirection 303. Dans un second temps, le client déréférence cette nouvelle URI et obtient une représentation décrivant la ressource non-informative.
Note : Il existe deux approches que les éditeurs de données peuvent utiliser pour fournir aux clients des URI de ressources informatives décrivant les ressources non-informatives : les URI avec dièse et la redirection 303. Ce document porte essentiellement sur l’approche de la redirection 303. Voir la Section 4.3 de URI cool pour le Web sémantique pour une discussion sur les compromis entre les deux approches.
2.1.5 – Négociation de contenu
Les navigateurs HTML affichent généralement les représentations RDF comme du code brut RDF, ou tout simplement les téléchargent sous forme de fichiers RDF sans les afficher. Ce n’est pas très utile pour l’utilisateur moyen. Par conséquent, une bonne représentation HTML en plus de la représentation RDF d’une ressource aide les humains à comprendre à quoi se réfère un URI.
Ceci peut être réalisé en utilisant un mécanisme HTTP appelé négociation de contenu. Les clients HTTP envoient les en-têtes HTTP avec chaque requête pour indiquer quels types de représentation ils préfèrent. Les serveurs peuvent inspecter ces en-têtes et sélectionnez une réponse appropriée. Si les en-têtes indiquent que le client préfère le HTML, alors le serveur peut générer une représentation HTML. Si le client préfère le RDF, alors le serveur peut générer du RDF.
La négociation de contenu pour les ressources non-informatives est généralement mise en œuvre de la manière suivante. Quand un URI identifiant une ressource non-informative est déréférencé, le serveur envoie une redirection 303 à une source d’information appropriée pour le client. Ainsi, une source de données se sert souvent de trois URIs relatives à chaque ressource non-informative, par exemple :
- Http://www4.wiwiss.fu-berlin.de/factbook/resource/Russia (URI identifiant la non-information sur les ressources Russie)
- Http://www4.wiwiss.fu-berlin.de/factbook/data/Russia (ressource informative avec une représentation RDF/XML décrivant Russie)
- Http://www4.wiwiss.fu-berlin.de/factbook/page/Russia (ressource informative avec une représentation HTML décrivant Russie)
La figure ci-dessous montre comment un déréférencement d’URI HTTP identifiant une ressource non-informative joue en même temps que la négociation de contenu :
- Le client effectue une requête HTTP GET sur un URI identifiant une ressource non-informative. Dans notre cas un URI de vocabulaire. Si le client est un navigateur de données liées, et préfère une représentation RDF/XML de la ressource, il envoie un en-tête Accept: application/rdf+xml avec la requête. Un navigateur HTML enverrait un Accept: text/html au lieu de l’en-tête.
- Le serveur reconnaît l’URI pour identifier une ressource non-informative. Comme le serveur ne peut pas renvoyer une représentation de cette ressource, il répond en utilisant le code de réponse HTTP 303 See Other et envoie au client l’URI d’une ressource informative décrivant la ressource non-informative. Dans le cas RDF : RDF content location.
- Le client demande à présent par un GET au serveur d’obtenir une représentation de cette ressource informative, en demandant à nouveau application/rdf+xml.
- Le serveur envoie au client un document RDF/XML contenant une description de la ressource originale vocabulary URI.
http://www.w3.org/TR/swbp-vocab-pub/img/deref-ont-uri-rdf.png
Un exemple complet d’une session HTTP pour le déréférencement d’un URI identifiant une ressource non-informative est donné en Annexe A.
2.1.6 – URI Alias
Dans un environnement ouvert comme le Web, il arrive souvent que les différents fournisseurs d’information parlent de la même ressource non-informative, par exemple un lieu géographique ou une personne célèbre. Comme ils ne se connaissent pas les uns des autres, ils introduisent des URIs différentes pour identifier le même objet du monde réel. Par exemple : la source de données DBpedia donne des informations qui sont extraites de Wikipedia utilise l’URI http://dbpedia.org/resource/Berlin pour identifier Berlin. Geonames, une source de données fournissant des renseignements sur des millions de lieux géographiques, utilise l’URI http://sws.geonames.org/2950159/ pour identifier Berlin. Comme les deux URI se réfèrent à la même ressource non-informative, ils sont appelés alias URI. Les alias URI sont courants sur le Web des données, puisqu’il n’est pas réaliste de s’attendre à ce que tous les fournisseurs soient d’accord pour donner le même URI afin d’identifier la même ressource non-informative. Les alias URI assurent une fonction sociale importante dans le web de données, leurs déréférencements produisent des descriptions différentes de la même ressource non-informative, ils permettent ainsi à différents points de vue et opinions de s’exprimer. Afin d’être toujours en mesure de suivre les informations que les différents prestataires expriment sur la même ressource non-informative, ceux-ci peuvent placer des liens owl:sameAs vers des alias URI qu’ils connaissent. Cette pratique est approfondie dans la section.
2.1.7 – Descriptions associées
Dans ce tutoriel, nous utilisons un nouveau terme qui ne fait pas partie de la terminologie standard de l’architecture du Web, mais qui est utilisé dans le contexte les données liées. Le terme est description associée et il se réfère à la description d’une ressource non-informative qu’un client obtient par le déréférencement d’un URI spécifique identifiant cette ressource non-informative. Par exemple : en déréférençant l’URI http://dbpedia.org/resource/Berlin, la requête application/rdf+xml donne, après une redirection, une description associée égale à la description RDF de http://dbpedia.org/resource/Berlin dans la ressource informative http://dbpedia.org/data/Berlin. L’utilisation de ce nouveau terme est logique dans un contexte de données liées comme il est de pratique courante d’utiliser plusieurs URI pseudonymes pour se référer à la même ressource non-informative et aussi parce que les différents alias URI se déréférencement en plusieurs descriptions différentes de la ressource.
2.2 – Le modèle de données RDF
Lors de la publication de données liées sur le Web, nous représentons des informations sur les ressources en utilisant le cadre de description de ressources (Resource Description Framework, RDF). RDF fournit un modèle de données qui est d’une part extrêmement simple, mais aussi, d’autre part, strictement adaptée à l’architecture Web.
En RDF, une description d’une ressource est représentée par un nombre de triplets. Les trois parties de chaque triplet sont appelées : sujet, prédicat, et objet. Un triplet reflète la structure de base d’une phrase simple, comme celle-ci:
Chris – a – l’adresse email – chris@bizer.de
(sujet) – (prédicat) – (objet)
Le sujet d’un triplet est l’URI identifiant la ressource décrite.
L’objet peut être soit une valeur littérale simple, comme une chaîne, un nombre, une date ou l’URI d’une autre ressource qui est en quelque sorte liée au sujet.
Le prédicat, au milieu, indique quel type de relation existe entre le sujet et l’objet, par exemple s’il s’agit du nom ou de la date de naissance (dans le cas d’un littéral), l’employeur ou quelqu’un que la personne connaît (dans le cas d’une autre ressource). Le prédicat est aussi un URI. Ces URI proviennent de vocabulaires, des collections d’URI qui peuvent être utilisées pour représenter des informations sur un domaine particulier. Vous pouvez vous référer à la section 4 pour plus d’informations sur les vocabulaires à utiliser dans le contexte des données liées.
Certaines personnes imaginent l’ensemble des triplets RDF comme un graphe RDF. Les URI figurant des sujets et des objets y sont les nœuds du graphe, et chaque triplet est un arc (flèche) qui relie le sujet à l’objet.
Deux principaux types de triplets RDF peuvent être distingués, les triplets littéraux et les liens RDF :
Triplets littéraux
- Ce sont ceux qui ont pour objet un littéral RDF tels qu’une chaîne, un nombre ou une date. Les triplets littéraux sont utilisés pour décrire les propriétés des ressources. Par exemple, les triplets littéraux sont utilisés pour décrire le nom ou la date de naissance d’une personne.
Liens RDF
- Ils représentent les liens typés entre deux ressources. Les liens RDF se composent de trois références d’URI. Les URI qui sont à la position du sujet et de l’objet identifient des ressources liées entre elles. L’URI qui est à la position du prédicat, définit le type du lien. Par exemple, un lien RDF peut affirmer qu’une personne est employée par une organisation. Un autre lien RDF peut attester que des personnes en connaissent certaines autres.
Les liens RDF sont le fondement du Web des données. Le déréférencement d’URI qui apparaissent comme la destination d’un lien donne une description de la ressource liée. Cette description contient généralement des liens RDF supplémentaires qui pointent d’autres URI qui à leur tour peuvent également être déréférencé, et ainsi de suite. Ceci est la façon dont les descriptions des ressources individuelles sont tissées dans le web de données. C’est aussi la façon dont le Web de données peut être parcouru en utilisant un navigateur de données liées ou exploré par le robot d’un moteur de recherche.
Prenons un navigateur RDF comme par exemple Disco ou Tabulator. L’internaute utilise le navigateur pour afficher des informations sur Richard depuis son profil FOAF. Richard s’est lui-même identifié avec l’URI http://richard.cyganiak.de/foaf.rdf#cygri. Lorsqu’un internaute tape cette URI dans son navigation, celui-ci déréférence l’URI sur le Web, demandant le type de contenu application/rdf+xml et affiche les informations récupérées (cliquez ici pour voir ce que fait Disco). Dans son profil, Richard a déclaré qu’il est basé près de Berlin, en utilisant l’URI de DBpedia http://dbpedia.org/resource/Berlin comme alias d’URI de la ressource non-informative de Berlin. Si l’internaute est intéressé par Berlin, il indique au navigateur de déréférencer cet URI en cliquant dessus. Le navigateur déréférence alors cet URI en demandant un contenu application/rdf+xml.
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/RDFlinks1.gif
Après avoir été redirigé par un code de réponse HTTP 303, le navigateur récupère un graphe RDF décrivant Berlin avec plus de détail. Une partie de ce graphe est représenté ci-dessous. Le graphe contient un triplet littéral indiquant que Berlin a 3.405.259 habitants et un autre lien RDF vers une ressource représentant une liste des villes allemandes.
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/RDFlinks2.gif
Comme les deux graphes partagent l’URI RDF http://dbpedia.org/resource/Berlin, ils se regroupent naturellement comme illustré ci-dessous.
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/RDFlinks3.gif
L’internaute peut également être intéressé par d’autres villes allemandes. Par conséquent, il laisse le navigateur déréférencer l’URI identifiant la liste. Le graphe RDF obtenu contient plusieurs liens vers des villes allemandes, par exemple, Hambourg et Munich, comme indiqué ci-dessous.
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/RDFlinks4.gif
Vu selon une perspective Web, les liens RDF les plus intéressants sont ceux qui relient une ressource à des données externes publiées par d’autres sources de données. En effet, ils relient différentes îles de données dans le Web. Techniquement, un tel lien RDF externe est un triplet RDF, qui a pour sujet un URI d’une source de données et pour objet un URI d’une autre source de données. L’encadré ci-dessous contient des liens RDF externes variés tirés de différentes sources de données sur le Web.
2.2.1 – Exemples de liens RDF externe
# Deux liens RDF provenant de DBpedia
<http://dbpedia.org/resource/Berlin>
owl:sameAs <http://sws.geonames.org/2950159/> .
<http://dbpedia.org/resource/Tim_Berners-Lee>
owl:sameAs <http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007> .
# Liens RDF pris dans le from Tim Berners-Lee’s FOAF profile
<http://www.w3.org/People/Berners-Lee/card#i>
owl:sameAs <http://dbpedia.org/resource/Tim_Berners-Lee> ;
foaf:knows <http://www.w3.org/People/Connolly/#me> .
# RDF links taken from Richard Cyganiaks’s FOAF profile
<http://richard.cyganiak.de/foaf.rdf#cygri>
foaf:knows <http://www.w3.org/People/Berners-Lee/card#i> ;
foaf:topic_interest <http://dbpedia.org/resource/Semantic_Web> .
2.2.2 – Avantages à utiliser le modèle de données RDF dans le contexte des données liées
Les principaux avantages de l’utilisation du modèle de données RDF dans un contexte de données liées sont les suivantes :
- Les clients peuvent rechercher tous les URI dans un graphe RDF sur le Web pour obtenir des informations supplémentaires.
- L’information provenant de sources différentes fusionnent naturellement.
- Le modèle de données permet d’établir des liens entre les données RDF à partir de sources différentes.
- Le modèle de données permet de représenter l’information qui est exprimée à l’aide des schémas différents dans un seul modèle.
- En combinaison avec des langages de schéma comme RDF-S ou OWL, le modèle de données permet d’utiliser autant de structures qu’on veut, peu comme beaucoup. Cela signifie qu’on peut représenter autant des données fortement structurés que des données semi-structurées.
2.2.3 – Caractéristiques RDF qu’il vaut mieux éviter dans le contexte des données liées
Afin de faciliter pour les clients la fusion et l’interrogation de données, nous recommandons de ne pas utiliser pleinement l’expressivité du modèle de données RDF, mais un sous-ensemble des fonctionnalités de RDF. En particulier :
- Nous déconseillons l’utilisation de nœuds vides. Il est impossible de définir des liens RDF externes sur un nœud vide, et la fusion de données provenant de différentes sources devient beaucoup plus difficile lorsque des nœuds vides sont utilisés. Par conséquent, toutes les ressources d’une certaine importance doivent être nommées en utilisant des références URI. Notez que les spécifications actuelles de FOAF ont rejeté les nœuds vides en faveur de références URI (voir rdf:about= »#me » dans leur exemple, et le post de Tim Berners-Lee sur le même sujet Offrez-vous un URI).
- Nous déconseillons l’utilisation de la réification RDF car les sémantiques de la réification sont pas claires et les déclarations réifiées sont peu commodes pour interroger avec le langage de requêtes SPARQL. A la place, les métadonnées peuvent être jointes aux ressources informatives, comme cela est expliqué dans la section 5.
- Vous devriez réfléchir à deux fois avant d’utiliser les collections RDF ou les conteneurs RDF car ils ne fonctionnent pas bien ensemble avec SPARQL. Est-ce que votre application a vraiment besoin d’une collection ou un conteneur ou bien l’information peut-elle également être exprimé en utilisant plusieurs triplets ayant le même prédicat ? La deuxième option simplifie les requêtes SPARQL.
3 – Choisir les URI
Les ressources sont nommées avec des références URI. Quand vous publiez des données liées, vous devez consacrer un certain effort au choix de bons URI pour vos ressources.
D’une part, ils doivent être de noms que d’autres éditeurs pourront utiliser en toute confiance pour lier vos ressources à leurs propres données. D’autre part, vous aurez à mettre en place l’infrastructure technique afin de les rendre déréférençable, et cela peut ajouter quelques contraintes sur ce que vous pouvez faire.
Cette section énumère quelques éléments à garder à l’esprit.
Exemples d’URI cool :
Voir aussi :
4 – Quels vocabulaires dois-je utiliser pour représenter l’information ?
Afin de faciliter le traitement de vos données aux applications clientes, vous devez réutiliser autant que faire se peut les termes de vocabulaires bien connus. Vous ne devez définir de nouveaux termes vous-même que si vous ne trouvez pas les termes requis dans les vocabulaires existants.
4.1 – Réutilisation des termes existants
L’ensemble des vocabulaires bien connus évolue dans la communauté du Web sémantique. Pour vérifier si vos données peuvent être représentées en utilisant des termes de ces vocabulaires avant d’en définir de nouveaux, commencez par regarder ici :
Une liste plus complète de vocabulaires bien connus est maintenue par le projet communautaire W3C SWEO Linking Open Data dans le wiki ESW. Une liste des 100 espaces de nom RDF les plus courants (août 2006) est fournie par UMBC eBiquity Group.
Il est courant de mélanger des termes de vocabulaires différents. Nous recommandons particulièrement l’utilisation des propriétés rdfs:label et foaf:depiction chaque fois que possible, car ces termes sont bien utilisés par les applications clientes.
Si vous avez besoin des références URI pour des lieux géographiques, des domaines de recherche, des thèmes généraux, des artistes, des livres ou des CD, vous devriez considérer l’utilisation des URI de sources de données présentes dans le projet communautaire W3C SWEO Linking Open Data, par exemple, Geonames, DBpedia, Musicbrainz, dbtune ou RDF Book Mashup. Les deux principaux avantages à utiliser des URI à partir de ces sources de données sont les suivants :
- Les URI sont déréférençables, cela signifie qu’une description de ce concept peut être trouvée sur le Web. Par exemple, en utilisant l’URI DBpedia http://dbpedia.org/page/Doom pour identifier le jeu vidéo Doom vous obtenez une description détaillée du jeu, y compris les résumés en 10 langues différentes et de diverses classifications.
- Les URI sont déjà liés à des URI d’autres sources de données. Par exemple, vous pouvez naviguer à partir de l’URI DBpedia http://dbpedia.org/resource/Berlin vers des données sur Berlin fournies par Geonames et Eurostat. Ainsi, en utilisant des URI de ces ensembles de données, vous reliez vos données grâce à un réseau de sources de données dense et en croissance rapide .
Une liste plus étendue d’ensembles de données avec des URI déréférençables est maintenue par le projet de la communauté Linking Open Data dans le wiki ESW.
Dans les profils FOAF de Tim Berners-Lee et Ivan Herman, vous trouverez de bons exemples sur la façon dont des termes de différents vocabulaires bien connus sont mélangés au sein d’un seul document et sur la manière de réutiliser des URI existants.
4.2 – Comment définir les conditions ?
Lorsque vous ne pouvez pas trouver de bons vocabulaires existants qui couvrent toutes les classes et les propriétés dont vous avez besoin, vous devez définir vos propres termes. La définition de nouveaux termes n’est pas difficile. Les classes et les propriétés RDF sont elles-mêmes des ressources identifiées par des URI et publiées sur le Web. Donc tout ce que nous avons dit à propos de la publication des données liées s’applique à elles aussi.
Vous pouvez définir des vocabulaires RDF en utilisant le langage RDF Vocabulary Description Language 1.0: RDF Schema ou le langage Web Ontology Language (OWL). Pour les introductions aux RDFS, voir la section sur le vocabulaire de documentation dans le tutorial SWAP, et la section très détaillée RDF Schema du Primer RDF. OWL est introduit dans OWL Overview.
Nous donnons ici quelques conseils pour ceux qui sont familiers avec ces langues :
- Ne définissez pas un nouveau vocabulaire à partir de zéro, mais complétez les vocabulaires existants avec des termes supplémentaires (dans votre propre espace de noms) pour représenter vos données selon vos besoins.
- Définissez pour les humains et pour les machines. Au stade actuel du développement du Web de données, il y a plus de gens que de machines qui viennent visiter votre site, même si le Web de données est a priori plus destiné aux machines. N’oubliez pas d’ajouter de la prose, par exemple rdfs:comment pour chaque terme inventé. Et fournissez toujours une étiquette pour chaque terme qui utilise la propriété rdfs:label.
- Faites des termes d’URI dereferenceables. Il est essentiel que les termes d’URI soient déréférenceables afin que les clients puissent rechercher la définition d’un terme. Suivez donc les recettes du W3C sur les meilleures pratiques de la publication de vocabulaires RDF pour faire des termes d’URI déréférenceables.
- Faites usage de termes d’autres personnes. L’utilisation de termes d’autres personnes, ou de mapping sur eux, contribue à promouvoir le niveau d’échange de données sur le Web de données, de la même manière que les liens hypertextes construisent le Web de documents. Des propriétés communes pour fournir des telles applications sont rdfs:subClassOf ou rdfs:subPropertyOf.
- Faites état explicitement de toutes les informations importantes. Par exemple, indiquez explicitement tous les ranges [c’est le terme anglais] et tous les domaines. N’oubliez pas : les humains peuvent souvent faire des conjectures, mais pas les machines. Ne négligez pas d’informations importantes !
- Ne créez pas de termes trop limités, ou fragiles ; laissez une certaine souplesse pour permettre les évolutions. Par exemple, si vous utilisez des fonctionnalités OWL complètes pour définir votre vocabulaire, vous pourrez avoir des choses qui conduisent à des conséquences non désirées et à des incohérences quand quelqu’un d’autre utilisera vos références dans une définition de vocabulaire différent. Ainsi, à moins que vous sachiez exactement ce que vous faites, utilisez RDF-Schema pour définir des vocabulaires.
L’exemple suivant contient la définition d’une classe et une propriété en suivant les règles ci-dessus. L’exemple utilise la syntaxe de Turtle. Les déclarations d’espace de noms ont été omises.
# Définition de la classe « Lover »
<http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabulary#Lover>
rdf:type rdfs:Class ;
rdfs:label « Lover »@en ;
rdfs:label « Liebender »@de ;
rdfs:comment « A person who loves somebody. »@en ;
rdfs:comment « Eine Person die Jemanden liebt. »@de ;
rdfs:subClassOf foaf:Person .
# Définition de la propriété « aime »
<http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabublary#loves>
rdf:type rdf:Property ;
rdfs:label « loves »@en ;
rdfs:label « liebt »@de ;
rdfs:comment « Relation between a lover and a loved person. »@en ;
rdfs:comment « Beziehung zwischen einem Liebenden und einer geliebten Person. »@de ;
rdfs:subPropertyOf foaf:knows ;
rdfs:domain <http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LoveVocabulary#Lover> ;
rdfs:range foaf:Person .
Notez que les termes sont définis dans un espace qui est contrôlée par Chris Bizer et qu’elles sont liées au vocabulaire FOAF utilisant des liens rdfs:subPropertyOf et rdfs:subClassOf liens.
5 – Que dois-je retourner en tant que description RDF pour une URI ?
En supposant que nous ayons parfaitement exprimé toutes nos données à l’aide de triplets RDF : quel triplet devrait être retourné (après une redirection 303) en réponse au déréférencement de l’URI identifiant une ressource non-informative ?
- La description : la représentation doit inclure tous les triplets de votre ensemble de données dont l’URI de la ressource est le sujet. Ceci est la description immédiate de la ressource.
- Les liens arrière (backlinks) : la représentation devrait aussi inclure tous les triplets de votre ensemble de données dont l’URI de la ressource est l’objet. Ces triplets sont apparemment redondants, en effet, ils peuvent déjà être trouvés par l’URI de leur sujet, mais ça permet aux navigateurs et aux robots d’exploration (crawlers) d’emprunter les liens dans les deux sens.
- Les descriptions connexes : vous pouvez inclure toute information additionnelle sur les ressources connexes qui peuvent avoir un intérêt dans des scénarios types d’utilisation. Par exemple, vous souhaitez peut-être envoyer des informations sur un auteur avec celles qui concernent un de ses livres, car de nombreux clients intéressés par les livres peuvent également être intéressé par l’auteur. Une approche modérée est recommandée, car celle qui consiste à renvoyer un mégaoctet de RDF sera considéré comme excessive dans la plupart des cas.
- Les métadonnées : la représentation devrait contenir toutes les métadonnées que vous souhaitez joindre à vos données publiées, comme par exemple l’URI identifiant l’auteur, mais aussi ceux sur les licences. Elles doivent être enregistrées comme des descriptions RDF de la ressource d’information qui décrit une ressource non-informative ; c’est-à-dire que le sujet des triplets RDF devrait être l’URI de la ressource d’information. En joignant des méta-informations à cette ressource d’information plutôt qu’à la ressource décrite lui-même ou à des déclarations spécifiques sur la ressource RDF (comme avec la réification RDF), cela apparentent très bien à l’utilisation des graphes nommés et du langage de requêtes SPARQL dans les applications clientes de données liées. Afin de permettre aux consommateurs des informations d’utiliser vos données dans des conditions juridiques claires, chaque document RDF devrait contenir une information sur la licence sous laquelle le contenu peut être utilisé. Référez-vous à Creative Commons ou Talis pour les licences standard.
- La syntaxe : Il existe différentes manières de sérialiser les descriptions RDF. Votre source de données devrait au moins fournir une description RDF comme RDF/XML qui est la seule syntaxe officielle pour RDF. Comme RDF/XML n’est pas très lisible, votre source de données pourrait en outre fournir des descriptions Turtle lorsqu’on lui demande application/x-tortue comme mime-type. Dans les situations où vous pensez que les gens pourraient vouloir utiliser vos données avec des technologies XML telles que XSLT ou XQuery, il pourrait être également utile de recourir à une sérialisation Trix, puisque TriX fonctionne mieux avec ces technologies que RDF/XML.
Dans ce qui suit, nous donnons deux exemples de descriptions RDF qui respectent les règles ci-dessus. Le premier concerne le cas des informations sur l’auteur et la propriété servies par un propriétaire d’URI. Le deuxième concerne le cas d’informations non officielles servies par quelqu’un qui n’est pas le propriétaire de l’URI décrites.
5.1 – Description de l’autorité
L’exemple suivant montre une partie de la représentation en Turtle de la ressource d’information http://dbpedia.org/data/Alec_Empire. La ressource décrit le musicien allemand Alec Empire. En utilisant la terminologie de l’architecture du Web, il s’agit d’une description officielle telle qu’elle est servie après une redirection 303 par le propriétaire de l’URI http://dbpedia.org/resource/Alec_Empire. Les déclarations d’espace de noms ont été omises.
# Metadata and Licensing Information
<http://dbpedia.org/data/Alec_Empire>
rdfs:label "RDF description of Alec Empire" ;
rdf:type foaf:Document ;
dc:publisher <http://dbpedia.org/resource/DBpedia> ;
dc:date "2007-07-13"^^xsd:date ;
dc:rights
<http://en.wikipedia.org/wiki/WP:GFDL> .
# La description
<http://dbpedia.org/resource/Alec_Empire>
foaf:name "Empire, Alec" ;
rdf:type foaf:Person ;
rdf:type <http://dbpedia.org/class/yago/musician> ;
rdfs:comment
"Alec Empire (born May 2, 1972) is a German musician who is ..."@en ;
rdfs:comment
"Alec Empire (eigentlich Alexander Wilke) ist ein deutscher Musiker. ..."@de ;
dbpedia:genre <http://dbpedia.org/resource/Techno> ;
dbpedia:associatedActs <http://dbpedia.org/resource/Atari_Teenage_Riot> ;
foaf:page <http://en.wikipedia.org/wiki/Alec_Empire> ;
foaf:page <http://dbpedia.org/page/Alec_Empire> ;
rdfs:isDefinedBy <http://dbpedia.org/data/Alec_Empire> ;
owl:sameAs <http://zitgist.com/music/artist/d71ba53b-23b0-4870-a429-cce6f345763b> .
# Les liens arrière - Backlinks
<http://dbpedia.org/resource/60_Second_Wipeout>
dbpedia:producer <http://dbpedia.org/resource/Alec_Empire> .
<http://dbpedia.org/resource/Limited_Editions_1990-1994>
dbpedia:artist <http://dbpedia.org/resource/Alec_Empire> .
Notez que la description contient un lien owl:sameAs indiquant que http://dbpedia.org/resource/Alec_Empire et http://zitgist.com/music/artist/d71ba53b-23b0-4870-a429-cce6f345763b sont des URI alias se référant à la même ressource non-informative.
Pour faciliter aux clients de données liées la compréhension de la relation entre http://dbpedia.org/resource/Alec_Empire, http://dbpedia.org/data/Alec_Empire, et http://dbpedia.org/page/Alec_Empire, les URI peuvent être reliés entre eux en utilisant les propriétés rdfs:isDefinedBy et foaf:page comme c’est recommandé dans l’article Cool URI.
5.2 – Description non officielle
L’exemple suivant montre la représentation en Turtle dans la ressource d’information http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LinkedDataTutorial/ChrisAboutRichard qui est publiée par Chris pour fournir des informations à propos de Richard. Notez qu’en Turtle, le raccourci syntaxique <> peut être utilisé pour se référer à l’URI du document actuel. Richard possède l’URI http://richard.cyganiak.de/foaf.rdf#cygri et est donc la seule personne autorisée qui peut fournir une description sur cet URI. Ainsi en utilisant la terminologie de l’architecture du Web, on dit que Chris fournit des informations non officielles sur Richard.
# Metadata and Licensing Information
<>
rdf:type foaf:Document ;
dc:author <http://www.bizer.de#chris> ;
dc:date "2007-07-13"^^xsd:date ;
cc:license <http://web.resource.org/cc/PublicDomain> .
# La description
<http://richard.cyganiak.de/foaf.rdf#cygri>
foaf:name "Richard Cyganiak" ;
foaf:topic_interest <http://dbpedia.org/resource/Category:Databases> ;
foaf:topic_interest <http://dbpedia.org/resource/MacBook_Pro> ;
rdfs:isDefinedBy <http://richard.cyganiak.de/foaf.rdf> ;
rdf:seeAlso <> .
# Les liens arrière - Backlinks
<http://www.bizer.de#chris>
foaf:knows <http://richard.cyganiak.de/foaf.rdf#cygri> .
<http://www4.wiwiss.fu-berlin.de/is-group/resource/projects/Project3>
doap:developer <http://richard.cyganiak.de/foaf.rdf#cygri> .
6 – Comment définir des liens vers d’autres sources de données RDF
Les liens RDF permettent aux navigateurs et aux robots d’exploration de naviguer parmi les sources de données et de découvrir des données supplémentaires.
Le domaine d’application permet de déterminer quelles propriétés RDF sont utilisées comme prédicats. Par exemple, les propriétés des liens couramment utilisées dans le domaine de description des personnes sont foaf:knows, foaf:based_near et foaf:topic_interest. Des exemples combinant ces propriétés avec des valeurs de propriété de DBpedia, de la bibliographie DBLP et du RDF Book Mashup peuvent être trouvés dans les profils FOAF de Tim Berners-Lee et d’Ivan Herman.
Il est de pratique courante d’utiliser la propriété owl:sameAs pour exprimer qu’une autre source de données donne aussi des informations sur une ressource non-informative particulière. Un lien owl:sameAs indique que deux références URI se rapportent à la même chose. Ainsi owl:sameAs est utilisé pour exprimer la correspondance entre différents alias URI (voir section 2.1). On peut voir des exemples d’utilisation de owl:sameAs pour indiquer que deux URI parlent de la même chose dans le profil FOAF de Tim qui stipule que http://www.w3.org/People/Berners-Lee/card#i identifie la même ressource que http://www4.wiwiss.fu-berlin.de/bookmashup/persons/Tim+Berners-Lee et http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007. D’autres exemples d’utilisation se trouvent dans DBpedia et le serveur DBLP de Berlin.
Les liens RDF peuvent être définis manuellement, ce qui est généralement le cas pour les profils FOAF, mais ils peuvent aussi être générés par des algorithmes automatisés de liaison. Cette approche est habituellement prises pour interconnecter les grands ensembles de données.
6.1 – Configurer manuellement des Liens RDF
Avant de pouvoir mettre des liens RDF manuellement, vous devez savoir quelque chose sur les ensembles de données avec lesquels vous souhaitez établir un lien. Afin d’obtenir un aperçu des différents ensembles de données qui peuvent être utilisés comme cibles de liens consultez la liste des ensembles de données liées et ouvertes (Linking Open Data Dataset list). Une fois que vous avez identifié des ensembles de données particuliers comme des cibles de lien appropriées, vous pouvez rechercher manuellement dans ces URI les références sur lesquelles vous souhaitez créer un lien. Si une source de données ne fournit pas une interface de recherche, comme par exemple un SPARQL endpoint ou un formulaire HTML, vous pouvez utiliser des navigateurs de données liées comme Tabulator ou Disco pour explorer l’ensemble des données et trouver les bons URI.
Vous pouvez également utiliser des services tels que Uriqr ou Sindice pour rechercher des URI existants et choisir le plus populaire si vous trouvez plusieurs candidats. Uriqr vous permet de trouver des URI pour les personnes que vous connaissez, simplement en cherchant avec leur nom. Les résultats sont classés en fonction du rang de référencement de l’URI particulier dans les documents RDF du Web, mais vous devrez tout de même mettre un peu d’intelligence humaine dans le choix de l’URI le plus approprié à utiliser. Sindice indexe le Web sémantique et peut vous indiquer quelles sources mentionnent un URI donné. Ainsi, ce service peut vous aider à choisir l’URI le plus populaire pour un concept.
Rappelez-vous que les sources de données sont susceptibles d’utiliser des redirections HTTP-303 pour rediriger des clients identifiants des URI de ressources non-informatives vers des URI identifiant les ressources d’information qui décrivent les ressources non-informatives. Dans ce cas, assurez-vous que vous liez bien la référence d’URI identifiant la ressource non-informative, et non le document sur ce sujet.
6.2 – Auto-production de Liens RDF
L’approche décrite ci-dessus n’est pas envisageable sur des masses de données, par exemple l’interconnexion de 70.000 lieux dans DBpedia avec leurs entrées correspondantes dans Geonames. Dans ce cas, il est logique d’utiliser un algorithme de couplage automatisé d’enregistrements pour générer les liens entre les sources de données RDF.
Le couplage d’enregistrements (record linkage) est un problème bien connu dans la communauté bases de données. Le projet Linking Open Data recueille des données relatives à l’usage des algorithmes de couplage d’enregistrements dans le contexte des données liées sur la page wiki Equivalence Mining.
On est encore un manque de bons outils faciles à utiliser pour générer automatiquement des liens RDF. Dans la pratique, il est donc habituel de mettre en œuvre des algorithmes de couplage d’enregistrements sur des ensembles de données spécifiques pour générer des liens entre les sources de données RDF. Nous décrivons maintenant deux classes d’algorithmes :
Les algorithmes basés sur des modèles (pattern based)
Dans de nombreux domaines, il existe des règles de nommage reconnues. Par exemple, dans le domaine de la publication il y a les numéros ISBN, dans le domaine financier, il existe les identificateurs ISIN. Si ces identifiants sont utilisés pour former une partie des URI HTTP pour identifier des ressources particulières, alors il est possible d’utiliser des algorithmes basé sur des modèles simples pour générer des liens entre ces ressources RDF.
Un exemple d’une source de données qui utilise les numéros ISBN dans la constitution de ses URI est le RDF Book Mashup, qui, utilise par exemple l’URI http://www4.wiwiss.fu-berlin.de/bookmashup/books/0747581088 pour identifier le livre « Harry Potter and the Half-Blood Prince ». On voit bien que si on a le numéro ISBN dans ces URI, il était facile pour DBpedia de générer des liens owl:sameAs entre les livres dans DBpedia et le Mashup Book. DBpedia utilise l’algorithme basée sur le modèle suivant :
- Itérer dans DBpedia sur tous les livres qui ont un numéro ISBN.
- Créer un lien owl:sameAs entre l’URI d’un livre dans DBpedia et son URI correspondant dans Book Mashup en utilisant le modèle suivant pour les URI Book Mashup : http://www4.wiwiss.fu-berlin.de/bookmashup/books/ {numéro ISBN}.
L’exécution de cet algorithme pour tous les livres dans DBpedia crée plus de 9000 liens RDF, qui sont reliés avec l’ensemble de données DBpedia. Par exemple, le lien résultat pour le livre de Harry Potter est le suivant :
<http://dbpedia.org/resource/Harry_Potter_and_the_Half-Blood_Prince>
owl:sameAs <http://www4.wiwiss.fu-berlin.de/bookmashup/books/0747581088>
Algorithmes plus complexes fondés sur les propriétés
Dans les cas où il n’existe aucun identifiant commun entre les ensembles de données, il est nécessaire d’employer des des algorithmes de couplage plus complexes basées sur les propriétés. Nous décrivons ici deux algorithmes :
- Interconnexion entre DBpedia et Geonames. Des informations sur des lieux géographiques sont présentes dans la base de données Geonames, ainsi que dans DBpedia. Afin d’identifier les lieux qui apparaissent dans les deux ensembles de données, l’équipe de Geonames utilise une heuristique basée sur les propriétés qui repose sur le titre de l’article ainsi que sur des informations sémantiques, comme la latitude et la longitude, mais aussi le pays, la division administrative, le type d’entité, la population et des catégories. L’exécution de cette heuristique entre les deux sources de données a permis de trouver 70500 correspondances qui ont été fusionnées comme des liens Geonames owl:sameAs avec l’ensemble de données DBpedia de la même façon qu’avec l’ensemble de données Geonames.
- Interconnexion entre Jamendo et MusicBrainz. Vous pouvez vous référer au post du blog d’Yves Raimond relatif à son approche de l’articulation entre Jamendo et MusicBrainz.
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 :
- 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.
- 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 :
- Téléchargez et installez le logiciel serveur comme indiqué dans la section Démarrage rapide de la page d’accueil D2R Server.
- 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).
- 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.
- 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 :
- OpenLink Virtuoso pour publier votre base de données relationnelles à la façon de données liées.
- 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 :
- Ils assignent des URI HTTP aux ressources non-informatives pour lesquelles l’API qui fournit des données.
- 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.
- 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.
8 – Test et débogage de données liées
Après avoir publié vos informations sous la forme de données liées dans le Web, vous devez maintenant vérifier si elles peuvent être correctement consultées.
Un moyen simple pour tester cela consiste à soumettre plusieurs de vos URI au service de validation Vapour, celui-ci génère un rapport détaillé sur la façon dont vos URI réagissent aux différentes requêtes HTTP.
A côté de cela, il est également important de voir si vos informations s’affichent correctement dans différents navigateurs de données liées et si les navigateurs peuvent suivre les liens au sein de vos données RDF. Prenez donc plusieurs URI de votre ensemble de données et entrer les dans la barre de navigation des navigateurs suivants qui sont liés de données :
- Tabulator. Si Tabulator prend beaucoup de temps avant d’afficher vos informations, c’est un indicateur que vos graphes RDF sont trop grands et doivent être fractionnés. Tabulator fait aussi quelque inférence de base sur des données du Web, sans effectuer les contrôles de cohérence. Aussi, si Tabulator se comporte étrangement, cela pourrait indiquer des problèmes avec des déclarations rdfs:subClassOf et rdfs:subPropertyOf dans les schémas RDFS et OWL utilisés dans vos données.
- Marbres
- OpenLink RDF Browser
- Disco. Le navigateur Disco prend un temps de 2 secondes pendant la récupération des données sur le Web. Donc, ça peut être un indicateur que votre serveur est trop lent, si Disco n’affiche pas correctement vos données.
Si vous rencontrez des problèmes, vous devez effectuer les opérations suivantes :
- Testez avec cURL si le déréférencement de vos URI conduit à corriger les réponses HTTP. Richard Cyganiak a publié un tutoriel sur le débogage sémantique des sites Web avec cURL, il vous conduit dans le processus.
- Utilisez le service de validation du W3C RDF pour vous assurer que votre service offre valable RDF / XML.
Si vous n’arrivez pas à comprendre par vous-même ce qui ne va pas, demandez de l’aide sur la liste de diffusion Open Linking Data.
9 – Découverte de données liées sur le Web
La façon habituelle de découvrir des données liées dans le Web consiste à suivre les liens RDF au sein des données que le client connait déjà. Afin de rendre la poursuite de la découverte encore plus aisée, les fournisseurs d’information peuvent décider de mettre en oeuvre des mécanismes de découverte complémentaires :
Ping le Web sémantique
Ping le Web sémantique est un service d’enregistrement des documents RDF dans le Web, il est utilisé par plusieurs autres services et applications clientes. Vous pouvez ainsi augmenter les chances de faire découvrir vos données par l’enregistrement de votre URI avec « Ping le Web sémantique ».
Lien HTML d’auto-découverte
Il est également judicieux dans de nombreux cas d’établir des liens depuis des pages Web existantes vers vos données RDF, par exemple en mettant dans votre page d’accueil personnalisée des liens vers votre profil FOAF. Ces liens peuvent être définis en utilisant l’élément HTML dans l’en-tête de votre page HTML.
<link rel="alternate" type="application/rdf+xml" href="link_to_the_RDF_version" />
Les éléments HTML sont utilisés par des extensions du navigateur comme Piggybank et Semantic Radar pour découvrir des données RDF dans le Web.
Semantic Web Crawling : un extension de sitemap
Semantic Web Crawling : une extension de Sitemap. L’extension de sitemap permet aux éditeurs de données de faire état de l’endroit où est situé le RDF et de savoir quels moyens alternatifs sont prévus pour y accéder (données liées, SPARQL endpoint, dump RDF). Les clients du Web sémantique et les robots du Web sémantique peuvent utiliser cette information pour accéder aux données RDF de la manière la plus efficace pour la tâche qu’ils ont à accomplir.
Liste de Dataset dans le wiki ESW
Afin de faciliter la découverte vos données, non seulement pour les machines mais aussi pour les humains, vous devez insérer votre dataset à la liste Dataset du wiki ESW. N’hésitez pas à inclure quelques exemples d’URI de ressources intéressantes de votre ensemble de données (dataset), de sorte que les gens aient des points de départ pour la navigation.
10 – D’autres outils et d’autres lectures utiles
Pour plus d’information sur le Web lié (Linked Data) vous pouvez vous référez à ceci :
10.1 – Pour une vue d’ensemble et des bases théoriques
10.2 – Documentations techniques
10.3 – Projets et expériences pratiques dans la publication de données liées
10.4 – Des clients de données liées
10.5 – Des moteurs de recherche dans le Web des données liées
