How-to install a Sesame RDF server

[An english translation of the previous french article]

Every profession has its own tools. For the emerging professions of the semantic web, RDF repositories will become the foundations of the semantic pyramid, a tool that every “semantic worker” will use; maybe one day, when referring to these “semantic workers”, we will speak about “semantic manager”, or “semantic architects”… Anyway these RDF repositories are talking about promising performances for growing amounts of data : they are reaching one billion of triples, and that is the focus of the next “semantic web challenge” (see also here and there). This remains however ridiculously small compared to relationnal databases, that can store terabytes of data; especially when you consider that, in order to garantee optimal performances on complex queries and inference, RDF databases are generally all loaded into memory…

But not everyone needs a billion-triple-large RDF database, and you can start working with such a tool by installing the Sesame RDF server.

Un moteur de transformation RDF basé sur SPARQL (2)

[la suite du billet précédent sur le manque d'outil pour effectuer des transformations sur un graphe RDF, et la pertinence de cette opération pour l'échange de données.]

Pourquoi faire ?

La problématique est la suivante : je veux échanger des données exprimées en RDF, d’un système de départ à un système d’arrivée; les ontologies de départ et d’arrivée sont différentes, je dois donc transformer les données de départ pour construire un graphe conforme à l’ontologie d’arrivée. Il sera possible que seule une partie m’intéresse, et que toute l’information ne soit pas transformée.

Chaque opération de transformation est exprimée sous la forme d’une requête CONSTRUCT en SPARQL (1), qui permet de construire un pattern dans le graphe d’arrivée en fonction d’un pattern dans le graphe de départ; la requête s’exécute sur le graphe de départ, et ses résultats sont insérés dans le graphe d’arrivée.

Il suffit donc de décrire les requêtes SPARQL à exécuter à chaque opération. A l’usage, un peu de “sucre syntaxique” ne sera pas complètement inutile; certaines opérations de transformations vont en effet souvent revenir, et des raccourcis pour les écrire seront les bienvenus :

• recopier tous les statements RDF qui ont un prédicat donné (typiquement recopier tous les rdfs:label);
• recopier tous les statements rdf:type qui ont une certaines valeur, éventuellement en changeant cette valeur si elle n’est pas dans mon ontologie d’arrivée;
• etc;

Et maintenant… un exemple.

How-to install a Sesame RDF server - Comment installer un serveur RDF Sesame

Il n’y a pas d’artisans sans outils. Dans les nouvelles professions du web sémantique, les repository RDF vont s’imposer comme des fondations incontournables, comme les outils de base des artisans de la pyramide sémantique; peut-être un jour, à propos de ces artisans, parlera-t-on de “semantic manager”, ou de “semantic architect”… Bref, ces bases RDF commencent à annoncer de bonnes performances pour des volumes conséquents, on parle en ce moment du milliard de triplets, c’est d’ailleurs le sujet du prochain “semantic web challenge” (voir aussi ici). Cela reste toutefois bien en deçà des bases relationnelles classiques, où les volumes de données peuvent se compter en tera-octets, d’autant que, pour garantir des performances optimales sur des requêtes complexes et de l’inférence, les bases RDF sont en général entièrement montées en mémoire…

Mais tout le monde n’a pas besoin d’un bulldozer qui gère un milliard de triplets RDF, et pour commencer à se faire la main sur ces outils, je vous propose de vous équiper d’un simple marteau et d’un tournevis, en installant le serveur RDF Sesame.

Requêter le contenu de Wikipedia avec SPARQL

Pour prolonger le débat récent entre Thomas et Bruno sur RDF et XML, un petit exemple illustrant le fait que SPARQL permet de requêter un graphe RDF, même très grand, sans connaître a priori ni sa structure, ni l’ontologie sous-jacente.

DBpedia, dont je vous ai déjà parlé, définit une URI à partir de chaque article du Wikipedia anglais, cette URI identifiant le sujet de l’article, la chose dont il parle. En fait l’article parle en général de beaucoup de choses, mais il a un sujet principal, par principe même de l’encyclopédie : “un article, une chose décrite”.

UIMA peut-il réconcilier le text-mining et les outils sémantiques ?

… peut être.

UIMA (Unstructured Information Management Architecture) est le framework de traitement des données non structurées d’abord lancé par IBM, dont l’architecture est en cours de normalisation à l’OASIS. L’objectif de ce framework est de décrire des étapes de traitement d’un document non structuré (texte, image, vidéo, etc.), en vue d’en extraire de façon automatique des informations structurées. UIMA ne décrit par contre ni comment ces informations doivent être extraites du texte, ni la façon de s’en servir.

Un moteur de transformation RDF basé sur SPARQL

Le Web Sémantique permettra aux applications de communiquer entre elles plus facilement et plus efficacement, en limitant les formats d’échanges, en explicitant la sémantique des informations, en les rendant publiques, réutilisables, etc.

Mais soyons honnêtes, d’un point de vue pragmatique, nous n’y sommes pas encore (et ce n’est pas faute d’évangélisation de notre part !) même si on sent les choses bouger; l’échange de données entre les applications est toujours limité par :

• la syntaxe des fichiers : le plus souvent du XML, mais combien de fois avons-nous encore à traiter des fichiers textes, des feuilles excel, des dump de base de données ?
• leur grammaire : quand les fichiers sont en XML, combien n’ont pas de DTD explicite ? et même lorsqu’elle l’est, il existe de toutes façons autant de formats propriétaires qu’il y a de propriétaires… RDF est là pour remédier à ce problème (encore que le problème de sa sérialisation reste entier), et commence à gagner en visibilité;
• leur sémantique : même en étant optimiste et en supposant que deux applications A et B du même domaine sachent respectivement exporter et importer du RDF, quelle est ma chance qu’elles s’appuient sur la même ontologie ? quand bien même elle partagerait la même ontologie, quelle est mon pourcentage de chance qu’elles l’implémentent de la même façon et avec le même degré de complétude ?

Knowledge is Music (et vice-versa) (5) - Exploiter et afficher la base de liens musicaux

[le post précédent décrit la façon d'enrichir une liste de groupes et de chanteurs français à l'aide d'ITM et d'extractions linguistiques de Gate]

Etape n° 4 - exploiter la connaissance
Bien. J’ai donc à ma disposition une base de liens entres chanteurs et groupes de musique français. Il s’agit maintenant d’illustrer quelques utilisations possibles de cette base.

Requêter la base de liens
La première application qui vient à l’esprit est de requêter cette base. On imagine très bien une application du type : “Entrez le nom de votre chanteur ou de votre groupe préféré… alors vous aimerez aussi…” (avec l’option facultative : “puis allez acheter leurs CDs sur Amazon“).
ITM dispose d’API Java permettant d’effectuer ce type d’interrogation, qui est également possible à travers les écrans de l’application. On peut imaginer que, lorsqu’un nom de chanteur/groupe est donné, l’application ramène à la fois les chanteurs/groupes qui le référence, et aussi les chanteurs/groupes qui sont référencés par lui. On peut même supposer de faire apparaître en premiers dans la liste de réponses ceux qui ont un lien dans les deux sens avec le chanteur/groupe saisi.

Exporter la base en RDF
La base de liens dans ITM n’est pas liée à un format de représentation particulier. Ce qui veut dire qu’il est possible de l’exporter dans différents languages de représentation. L’export en RDF donne, pour reprendre le même exemple d’Hubert-Félix Thiéfaine pris dans le post précédent, ceci :

<rdf:Description rdf:about=”http://fr.wikipedia.org/wiki/Hubert-F%C3%A9lix_Thi%C3%A9faine”>
<rdf:type rdf:resource=”http://music.mondeca.com/music#Singer”/>
<rdfs:label>Hubert-Félix Thiéfaine</rdfs:label>
<music:See_also rdf:resource=”http://fr.wikipedia.org/wiki/Machin_%28groupe%29″/>
<music:See_also rdf:resource=”http://fr.wikipedia.org/wiki/Zazie”/>
<music:See_also rdf:resource=”http://fr.wikipedia.org/wiki/Zoo_%28groupe%29″/>
<music:See_also rdf:resource=”http://fr.wikipedia.org/wiki/Alambic_%28musique%29″/>
</rdf:Description>

Ces exports sont des moyens de transfert de l’information depuis la base de liens vers d’autres systèmes. (il est par exemple possible de générer la liste d’entités nommées de Gate non plus à partir des pages Wikipedia, mais à partir de la base de liens directement).

(note : un tel RDF peut être chargé dans l’éditeur d’ontologies SWOOP pour être visualisé et navigué)

Je mettrai à disposition dans un prochain post l’ontologie en OWL et l’export des entités en RDF.

Naviguer graphiquement
L’utilisation la plus concrète, visuelle et “fun” de ce mashup est d’arriver à visualiser la base de liens. Ce n’est sans doute pas - comme le fait à juste titre remarquer Bernard dans ce post - le meilleur moyen de l’exploiter d’un point de vue utilisateur. Cependant son intérêt didactique est indéniable. Et compte-tenu de la simplicité de la structure du graphe, cette visualisation reste un bon moyen d’appréhender le résultat final de cette expérience (on reste effectivement ici dans une optique de “preuve de concept”).
Idéalement, cette visualisation (ou des algorithmes d’analyse du graphe) ferait apparaitre des composantes fortement connexes entre elles, c’est-à-dire des chanteurs et des groupes ayant de forts liens entre eux, révélant ainsi des tendances et des courants musicaux.

Mon idée de départ était d’utiliser JGraph pour cette visualisation. JGraph est une librairie Java de manipulation de graphes assez complète, tant pour la visualisation que pour l’édition. (on peut tout à fait imaginer une intégration entre JGraph et un outil de gestion de réseau sémantique pour faire de l’édition de graphes).
Cependant après un premier essai, je me suis vite aperçu que la version gratuite de JGraph ne propose pas d’algorithme de layout du graphe (disponible uniquement en version payante) : il faut donner explicitement les positions des noeuds et des arêtes; beaucoup trop compliqué; je ne m’y risque pas.

Je me suis donc tourné vers Touchgraph, que je sais être moins complet, mais avec lequel je suis au moins certain d’arriver à une visualisation correcte. Il me faut quelque chose de “quick and dirty”. Je passe les détails d’implémentation. Le résultat final ressemble à ceci, pour Hubert-Félix Thiéfaine et Manu Chao :

(note : les chanteurs apparaissent en bleu, les groupes en rosé)

C’est intéressant pour appréhender les connexions autour d’un artiste en particulier. Par contre, dès que le graphe s’étend (autour d’entités importantes, comme par exemple notre Johnny suisse national), il devient rapidement inutilisable :

Je vais voir si je peux faire en sorte que cette petite applet soit téléchargeable quelque part.

Conclusion
A partir d’un corpus documentaire non structuré (des pages web wikipedia), et à l’aide d’outils :

• de transformation XML (XSLT)
• de text-mining (Gate)
• de gestion d’ontologie et de stockage de réseau sémantique (ITM)
• de visualisation (Touchgraph)

J’ai pu créer de façon automatisée une base de liens entre des entités nommées, et l’exploiter pour la requêter, l’exporter ou la visualiser.

Cet exemple de mise en oeuvre montre plusieurs choses :

• d’abord, l’utilité de liens sémantiques entre entités; ces liens existaient auparavant sous forme de simples références textuelles dans les pages Wikipedia; ce mashup les a rendus explicites et exploitables. Ils forment la vraie “connaissance” du domaine étudié (celui de la musique française), pris dans son ensemble.
• l’utilisation d’outils de text-mining pour automatiser le processus de création d’une base de liens, et leur criticité pour la qualité du résultat final; c’est en effet à cette étape que beaucoup de choses se jouent et que les problèmes apparaissent (bruit, référence d’une entité vers elle-même, etc.)
• l’intérêt de l’exploitation d’une telle base de connaissances pour un ensemble d’applications extérieures, de requêtes, de visualisation, de raisonnement (à venir), etc. Cela est permis par l’utilisation d’une syntaxe partagée (XML), de languages ouverts (Java), et de standards du Web sémantique (OWL et RDF).

L’expérience est donc concluante. Cependant, il est nécessaire d’améliorer le processus existant en :

• réduisant le bruit de l’extraction linguistique
• générant la liste d’entités nommées à partir de la base de connaissance (ce qui permettra de gérer des synonymes et des alias).

Ensuite, plusieurs pistes d’extension de ce premier noyau sont possibles :

• traiter d’autres sources que Wikipedia (je suis à la recherche d’un bon site candidat…), en utilisant pourquoi pas un crawler (Gate en intègre un).
• faire évoluer l’ontologie pour affiner les relations entre chanteurs et groupes.
• enrichir l’extraction linguistique en construisant une vraie grammaire, capable d’extraire les nouvelles relations de l’ontologie.
• trouver un algorithme de layout et être capable de générer un graphe en SVG.
• regrouper les artistes par courant musicaux, grâce à des tags.
• enrichir la liste initiale des chanteurs en traitant les entités devinées par Gate mais rejetées car inexistantes dans la base.
• utiliser un raisonneur pour trouver tous les liens inverses.
• et UIMA dans tout ça ?
• etc., etc., les idées ne manquent pas !

to be continued…