Le Web sémantique a été conçu par Tim Berners-Lee, co-inventeur du Web. Le Web a changé notre façon de communiquer, la façon dont nous menons nos affaires, notre façon de rechercher des informations et de se divertir. Le Web sémantique est la prochaine étape de l'évolution du Web et se définit, selon, Tim Berners-Lee, comme « un Web de données, qui peuvent être traitées directement et indirectement par des machines ». C'est comme un moyen efficace de représenter les données sur le Web, une base de données globalement liées.

Les données qui sont généralement cachées dans des fichiers HTML sont souvent utiles dans certains contextes, mais pas dans d'autres. Le problème avec la majorité des données qui sont sous cette forme sur le Web à l'heure actuelle, c'est qu'il est difficile de les utiliser à une grande échelle, parce qu'il n'y a pas de système « mondial » pour la publication des données, de telle manière qu'elles puissent être facilement traitées par qui que ce soit.

Par exemple, si l'on cherche des informations sur les événements sportifs locaux, des informations météo, les horaires d'avion ou le programme de télévision sur le Web, on se doute bien que toutes ces informations sont présentées par de nombreux sites, mais dans du (X)HTML. Le problème, c'est que, dans certains contextes, il est difficile d'utiliser ces données de la manière dont on pourrait vouloir le faire. Ainsi, si on lie les données et non les pages entre elles, il est plus facile de retrouver toutes les informations que l'on souhaite.

Si vous cherchez sur un moteur de recherche quelconque par exemple le mot « frégate » et que vous vous intéressez à l'oiseau, votre moteur de recherche va vous retourner des résultats qui n'ont rien à voir avec les oiseaux, il va en plus vous retourner des résultats sur les bateaux de guerre et sur les vieux bateaux.

Comment résoudre ce problème ? Tout simplement en donnant un sens aux mots que vous écrivez. On peut facilement imaginer que, lorsque vous tapez "frégate", votre moteur de recherche vous propose « voulez-vous les oiseaux ? les bateaux de guerre ? les vieux bateaux ? » ou bien trois onglets avec chacun sa catégorie.

Ainsi, le moteur de recherche comprend ce que vous lui demandez et pourra mieux vous répondre. Évidemment, cet exemple est très simple et basique, mais vous pouvez ainsi mieux voir l'une de ses utilités.

Une autre aussi que l'on peut voir : au lieu de taper des mots-clés dans votre moteur de recherche, vous voulez poser une ou plusieurs questions du genre « qui est le recordman du cent mètres crawl et quel est son temps ? » ; avec le Web sémantique, il est possible de répondre à ces deux questions.

Il est possible de faire des applications pour le Web sémantique dans la plupart des langages connus (Java, C++, Python, Ruby, PHP...). Le plus utilisé est Jena, un framework écrit en Java. Il fournit un environnement pour RDF pour tous ses formats connus, RDFS et OWL, SPARQL et inclut aussi un moteur d'inférence à base de règles. Ce moteur sert à créer des règles sur votre ontologie.

Un autre framework pour Java est Sesame ; contrairement à Jena, Sesame ne permet pas de manipuler les ontologies en OWL. Mais il reste très pratique, car il contient un magasin de triplets, ceci permet de stocker des triplets RDF et ainsi d'avoir une sorte de base de données contenant des triplets RDF et de l'interroger pour les manipuler.

Un troisième framework souvent utilisé est, lui, en PHP, c'est ARC2, il est semblable à Jena.

Python avec librdf et rdflib puis .NET avec dotNetRDF sont aussi beaucoup utilisés.

Il existe plusieurs types de technologies dans le domaine du Web sémantique. Tout d'abord, la base du Web sémantique est le RDF, toutes les technologies existantes du Web sémantique tournent autour de ce langage.

Ensuite, pour créer des données en RDF, on utilise principalement ce que l'on appelle une ontologie. On écrit une ontologie principalement en OWL (Web Ontology Language), l'un des langages développés et normés par le W3C. Il en existe un autre, RDFS (Ressource Description Framework Schema), aussi normé et développé par le W3C, mais moins évolué que OWL. Il y a aussi SPARQL qui est un langage permettant d'effectuer des requêtes sur un graphe RDF.

Il y a aussi des frameworks écrits dans différents langages, permettant de développer des applications autour du Web sémantique.

L'interconnexion est l'action de connecter entre elles les données contenues à différents endroits sur le Web. C'est-à-dire que, avec ce procédé, on peut relier toutes les données que l'on veut entre elles et ainsi avoir des informations sur un sujet qui sont définies sur d'autres sites. Une interconnexion se fait en connectant deux URI parlant du même sujet avec un lien « owl:sameAs ».

Par exemple, vous avez des données dans une base concernant des auteurs de livres, pour un de vos auteurs, disponible à l'URI http://exemple.com/mon_auteur, il vous manque sa date de naissance. Vous savez que sur Wikipedia (donc, DBPedia) se trouve cette information. Au lieu d'aller sur Wikipédia la récupérer vous-même ou bien de développer un parseur qui parcourt les pages HTML de Wikipédia, deux solutions s'offrent à vous :

• soit vous interrogez DBPedia sur son point d'accès SPARQL pour récupérer le RDF de cette donnée sur votre auteur qui est contenue sur Wikipédia pour ensuite, le stocker dans votre base, admettons à l'URI http://exemple.com/wikipedia/mon_auteur, et vous rajoutez un lien « owl:sameAs » allant de l'URI http://exemple.com/mon_auteur à l'URI http://exemple.com/wikipedia/mon_auteur dans votre ressource http://exemple.com/mon_auteur ;
• soit vous interrogez DBPedia sur son point d'accès SPARQL pour ne récupérer que l'URI de l'auteur sur DBPedia, par exemple http://dbpedia.org/resource/mon_auteur, et vous rajoutez un lien « owl:sameAs » allant de l'URI http://exemple.com/mon_auteur à l'URI http://dbpedia.org/resource/mon_auteur dans votre ressource http://exemple.com/mon_auteur.

Pour que les données soient visibles sur l'Internet par les moteurs de recherche, il faut les publier et les relier entre elles. À l'instar des liens hypertextes du HTML, il existe aussi un moyen de relier des données. Pour le Web sémantique, ce ne sont pas les pages (documents) que l'on lie entre elles, mais bien les données qu'elles contiennent.

Pour cela, deux méthodes. Le moyen classique est de développer une application à la main, qui interroge les points d'accès SPARQL de chaque magasin de triplets contenant les données intéressantes et de comparer les résultats pour ne garder que ce qui est nécessaire.

La seconde solution est d'utiliser un outil qui effectue tout ce travail, il en existe plusieurs. Les deux principaux sont Silk et LIMES.

Silk est configurable par un fichier contenant toutes les informations nécessaires pour les extractions des données et les met dans un fichier contenant le résultat sous forme de triplets RDF.

LIMES, quant à lui, est un outil en ligne, il permet donc de se passer d'un fichier de configuration mais est plus long à donner un résultat.

Le gros problème actuellement est que les données contenues dans les pages Web ne sont lisibles que par les humains, pas par les machines. Pour résoudre ce problème, on ajoute de la sémantique dans les pages Web. Pour cela, on dispose de trois solutions.

La première : RDFa. Il s'agit d'une norme développée par le W3C, devenue la recommandation pour ajouter de la sémantique à vos pages Web. Il ne fonctionne que pour les pages XHTML et permet d'utiliser les ontologies afin de dire que telle ou telle donnée appartient à telle ou telle classe ou propriété. Ainsi, lorsque l'on parsera une page XHTML, on aura le sens de la page et on pourra ainsi connaître l'auteur, le sujet de la page, le copyright de la page..., en fonction de ce qui est défini.

Il existe aussi les Microformats, qui ont le même objectif, mais maintenant déconseillés, ils peuvent être ajoutés à toute page HTML, dans des balises <span>, en spécifiant la propriété class.

La troisième solution est d'utiliser les nouvelles balises ajoutées dans HTML5, que l'on appelle les microdata (microdonnées). Comme le standard n'est pas encore finalisé, il est conseillé de les utiliser avec précaution.

Les plus grosses sources de données existantes pour le Web sémantique sont :

• DBpedia, la version de Wikipédia pour le Web sémantique, on peut récupérer son contenu par l'intermédiaire de son point d'accès SPARQL ;
• FreeBase, le concurrent de DBPedia, puisqu'il a le même but. Par contre, pour récupérer son contenu il faut passer, non par un point d'accès SPARQL, mais par une autre méthode, MQL API (MQL est un autre langage de requête, semblable à SPARQL) ;
• Geonames, une source de données exclusivement réservée aux données géographiques et cartographiques. Pour récupérer les données contenues sur Geonames, il est impossible de passer par un langage de requête, car aucun moyen n'a été mis à disposition pour le faire. Pour cela vous devez télécharger tout le contenu de la base et l'installer vous-même dans votre magasin de triplets et l'interroger.

DBPedia est la plus grosse base de données RDF actuelle pour le Web sémantique. C'est avant tout un projet communautaire permettant d'extraire les articles contenus sur Wikipédia sous forme de triplets RDF, afin de rendre ces informations utilisables par les méthodes du Web sémantique. Les données peuvent être soit consultées en ligne, soit téléchargées. DBPedia est mis à jour très régulièrement pour ajouter les nouvelles pages de Wikipédia, ce qui veut dire qu'un article sur Wikipédia n'est pas forcément disponible sur DBPedia.

DBPedia gère actuellement, majoritairement, que le contenu de Wikipédia en anglais.

Une URI est l'identifiant d'une ressource (une « chose », qui peut être n'importe quoi) ; dans un triplet RDF, composé d'un sujet, d'un prédicat et d'un objet, le sujet est une URI (ou parfois un nœud anonyme, ou nœud blanc, qui n'a pas d'URI), le prédicat est une URI, et l'objet est soit une URI, soit un nœud blanc, soit un littéral.

Vous êtes sans doute familier avec la notion d'URL (Uniform Ressource Locator) qui est ce qui s'affiche dans la barre d'adresse de votre navigateur quand vous naviguez sur Internet. Ces URL sont en fait un sous-ensemble des URI (Uniform Resource Identifier) ; toute URL est une URI, mais l'inverse n'est pas vrai. Une URI, comme son nom l'indique, identifie une ressource. Cette ressource peut être n'importe quoi, une personne, une ville, votre chat, etc.

Lorsqu'on essaie d'accéder à une URI, en la mettant dans la barre d'adresse du navigateur, il est bien évident que la chose identifiée ne pourra pas elle-même être retournée en réponse : si vous décidez d'identifier votre chat par une URI, et que vous mettez cette URI dans votre navigateur, votre chat ne sera pas « aspiré » du canapé où il est endormi pour réapparaître coincé dans la fenêtre du navigateur. Cependant, vous pourriez (mais ce n'est pas obligatoire) obtenir en réponse une représentation de la chose identifiée : par exemple une photo de votre chat. C'est la différence – subtile – entre une URI et une URL : l'URL localise un document, et permet d'accéder à ce document, l'URI identifie une chose, et permet (normalement, mais ce n'est pas obligatoire) d'accéder à une représentation de cette chose.

La négociation de contenu est un mécanisme défini par la norme HTTP permettant à un serveur de retourner des réponses différentes pour une même URI. Ainsi, un internaute en France et un internaute aux États-Unis pourraient voir deux versions de la même URI, l'une en français, l'autre en anglais. La négociation de contenu s'appuie sur les en-têtes de la requête HTTP envoyée par le client pour déterminer quel contenu retourner.

Dans le Web sémantique où toutes les ressources sont identifiées à l'aide d'URI, la négociation de contenu est utilisée pour retourner une représentation « pour les humains » de la ressource (une page HTML) lorsque c'est un internaute qui accède à l'URI par son navigateur, ou bien une représentation « pour les machines » de la même ressource (un fichier RDF). Par exemple, DBPedia identifie la ville de Berlin par l'URI http://dbpedia.org/resource/Berlin.

Si un programme accède à la même URI en stipulant dans l'en-tête de la requête qu'il accepte du RDF, il obtiendra http://dbpedia.org/data/Berlin, qui est un document RDF. Il est important de noter que ni http://dbpedia.org/page/Berlin, ni http://dbpedia.org/data/Berlin ne sont des identifiants de ressource dans DBPedia; seul http://dbpedia.org/resource/Berlin identifie une ressource DBPedia, et http://dbpedia.org/page/Berlin et http://dbpedia.org/data/Berlin sont des représentations de cette ressource. Par ailleurs il est toujours possible d'accéder de façon directe (sans mécanisme de négociation de contenu) à http://dbpedia.org/page/Berlin et http://dbpedia.org/data/Berlin.

Non, RDF n'est pas du XML. RDF est un modèle de données dont l'une des sérialisations (ou représentations) possibles est en XML. Cependant il n'existe pas de sérialisation canonique de RDF : c'est-à-dire que les mêmes données RDF peuvent être représentées par plusieurs fichiers différents. Par exemple, cet extrait de XML :

<foaf:Person rdf:about="http://www.ex.com/annuaire#sf">
          <foaf:name>Sophie Fonfec</foaf:name>
</foaf:Person>

Et celui-là :

<rdf:Description rdf:about="http://www.ex.com/annuaire#sf">
          <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person" />
          <foaf:name>Sophie Fonfec</foaf:name>
</rdf:Description>

Sont différents, et pourtant ils représentent les mêmes informations RDF (à savoir <http://www.ex.com/annuaire#sf> est une personne qui a pour nom « Sophie Fonfec »).

En théorie, il n'est donc pas conseillé de traiter des données RDF avec une feuille de style XSLT, car ces données RDF peuvent être dans d'autres sérialisations (comme N3), et la sérialisation des données peut varier. Dans la pratique, si on est sûr que le RDF à traiter est toujours en XML, et qu'on a des garanties sur sa sérialisation, ou qu'on prend en compte toutes les sérialisations possibles dans la feuille de style, il est possible de transformer du XML avec du XSLT.

L'approche recommandée est d'utiliser des outils comme XSparql ou XSLT+SPARQL permettant de combiner la flexibilité de SPARQL et la puissance du XSLT.