Voici la 2e 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).
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.