Knowledge is Music (et vice-versa) (6) - Corrections, améliorations, downloads

[le post précédent marquait la conclusion de la première étape de mon petit mashup musico-sémantico-graphique]

Corriger l’extraction linguistique

D’abord, maintenant que ma chaine Wikipedia -> Gate -> ITM -> Touchgraph fonctionne, il est temps de jeter un oeil à la qualité des résultats. Pour bien faire, j’aurais pu mesurer cette qualité en terme de silence (information non-extraite alors qu’elle aurait due l’être) et de bruit (information extraite alors qu’elle n’aurait pas due l’être); le temps me manque pour de telles mesures. Mais un simple parcours des résultats fait déjà resortir un problème : il semblerait par exemple que des groupes comme “Air” ou “Avril” soient liés à beaucoup d’autres artistes, certains n’ayant carrément rien à voir sur le plan musical…

Pas étonnant. Gate fait simplement de la reconnaissance d’entités, si bien qu’il voit l’entité “Air” partout où le mot “Air” est présent dans le texte. Je vous laisse imaginer les dégats. Un parcours de la liste d’entités de départ fait resortir celles qui pourraient être litigieuses : Air, Alambic, Alpes, Ange, Arsene, Avril, Bijou, Dogs, Eiffel, Java, Zoo dans les noms de groupes de musique, et Anaïs, Anis, Barbara, Bruno, Camille, Camus, Carlos, Corneille, Dave, Elsa, Jordy, Juliette, Raphael, Régine, Renaud dans les noms de chanteurs. Pour le moment, une seule solution pour que ces entités ne nuisent pas à la qualité globale de l’extraction : les supprimer de la liste d’entités analysées (désolé pour les fans); C’est-à-dire qu’elles ne seront jamais extraites par Gate (mais leur page Wikipedia sera quand même analysée) (1).

D’autre part, il me semblait bien qu’aucune entité possédant un caractère accentué dans son nom n’était extraite… étonnant que l’on ne trouve pas Céline Dion dans les liens de Jean-Jacques Goldman par exemple. Bug d’encoding de caractère, plaie de l’informaticien mondialisé. C’est au niveau de Gate que ça se passe : celui-ci accepte un paramètre d’encoding, qu’il ne vaut mieux pas oublier sous peine de voir les résultats sérieusement faussés.

Aprés ces corrections, j’obtiens 2259 liens entre 721 entités (vs. 1882 liens avant les corrections).

Améliorer la visualisation

La visualisation avec Touchgraph était vraiment une solution de dernier recours. Je ne pourrai pas en tirer beaucoup plus que ce que j’ai déjà fait. Par contre, sur la suggestion de Chritophe Tricot, j’ai jeté un oeil à la bibliothèque prefuse. Assez impressionnant, plein de possibilités, open-source. Le premier résultat donne un espèce de gros pâté informe qui bouge dans tous les sens, mais c’est tout à fait le genre de bibliothèque adaptée (et adaptable) avec plus de temps. A suivre. Vous pourrez juger du résultat en téléchargeant l’applet (voir ci-dessous).

D’autre part, j’ai profité de l’intégration de prefuse pour utiliser les API de sesame, bibliothèque permettant de manipuler du RDF, en version 2.0 alpha. Très propre et facile à prendre en main, rien à voir avec Jena !

Rendre les résultats accessibles

Finalement, je me suis dit qu’il serait intéressant de rendre les résultats de l’expérience accessibles pour ceux que cela intéresserait. Vous pouvez donc trouver :

• La mini-ontologie en OWL à http://www.unabstract.net/lecondechoses/onto
• Le résultat correspondant en RDF à http://www.unabstract.net/lecondechoses/knowledge_is_music_instances_1_1.rdf
• Les applications de visualisation à http://www.unabstract.net/lecondechoses/music-graph.zip avec touchgraph et prefuse (nécessite java 5). Les sources sont incluses. (note : ces applets lisent directement le RDF en ligne à l’adresse ci-dessus, une connexion Internet est donc nécessaire pour les faire fonctionner).

Next ?

A signaler : le lancement d’une vraie ontologie sur la musique. Rien à voir avec ma mini-modélisation, ce serait sans doute quelque chose à regarder de plus près…

——
(1) : la solution théorique plus pérenne consisterait à construire une grammaire dans Gate, lui indiquant d’extraire ces entités uniquement si elles sont repérées dans un contexte permettant de les désambigüiser.

———

2007-06-02 Edit

Depuis la migration du nouveau site web de mondeca, les précédents liens vers les fichiers n’étaient plus valides. Vous pouvez maintenant trouver :

• La mini-ontologie en OWL ici
• Le résultat correspondant en RDF ici
• Les applications de visualisation ici

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…

Knowledge is Music (et vice-versa) (4) - Extraction linguistique avec Gate

[le post précédent décrit la constitution de l'ontologie, de la liste d'entitées nommées, et de la liste des pages web à analyser]

Etape n°3 : Créer des liens entre les entités à l’aide de Gate
C’est l’étape clé du processus, où l’on mixe une liste d’entités, des pages de texte non structuré, et un outil linguistique, Gate, de façon à relier entre elles les entités (chanteurs et groupes de musique) de notre liste de départ.

D’abord, il s’agit de paramétrer Gate. Gate se décompose en “briques” qui s’assemblent pour former un processus d’extraction linguistique. Les briques peuvent être adaptées et enrichies en fonction du besoin, ce qui en fait une plate-forme de développement d’outils de TALN (Traitement Automatique du Langage Naturel). Un processus d’extraction linguistique classique, qui répond bien à mon besoin, se compose des “briques” suivantes, appliquées dans l’ordre lors du traitement de chaque document :

1. D’abord, une étape de “reset”, qui remet à jour le processus par rapport à tout ce qui aurait pu être gardé en mémoire lors des traitements précédents.
2. Puis, un “tokeniser”, qui découpe le texte en mots. Le tokenizer utilisé dépend en principe de la langue des textes traités. (Note : j’utilise ici un “english tokenizer”, qui fera l’affaire même si les documents sont en français).
3. Puis, un “sentence splitter”, qui organise les mots en phrases.
4. Puis, un “part of speech tagger” (POS tagger). Le “part of speech tagging” est le processus de reconnaissance de la catégorie lexicale d’un mot (nom, verbe, adjectif, etc.), en se basant sur sa forme et sur son contexte dans la phrase.
5. Une fois les mots découpés et marqués avec leur catégorie lexicale, on peut appliquer un “gazetteer”, c’est à dire une étape de reconnaissance d’entités nommées à partir de dictionnaires pré-établis.
6. Enfin, on peut appliquer sur les mots taggés et les entités reconnues un “transducer”, c’est-à-dire une grammaire compilée permettant la reconnaissance de certaines structures de phrase.

Tous ces modules sont disponibles dans la plate-forme standard de Gate, il suffit de les assembler. La seule modification consiste à enrichir le dictionnaire du gazetteer avec les deux listes de chanteurs et de groupes préparées à l’étape précédente. Pour ça, rien de plus simple :

• Copier les 2 fichiers textes contenant respectivement les noms des chanteurs et les noms des groupes dans le répertoire de gazetteer de Gate (plugins\ANNIE\resources\gazetteer)
• Modifier le fichier de configuration du gazetteer (lists.def), pour lui indiquer ces 2 nouveaux fichiers, en rajoutant ces 2 lignes :
  
music_singers.lst:person_full
music_bands.lst:person_full

  (note : le nom après les “:” représente le nom de l’élément de la grammaire qui sera produit lors de la reconnaissance d’une entité de la liste en question. Ici, comme je ne veux faire aucune modification au niveau de la grammaire, les chnateurs et les groupes sont tous les deux identifés comme “person_full”, qui est un élément de la grammaire de base de Gate)

Ensuite, une fois l’application Gate paramétrée, elle peut être appelée via une API Java. And this is where the magic happens. En effet, le module d’acquisition de connaissances d’ITM, connecté à Gate, va être capable d’enrichir la base de connaissances à partir des annotations linguistiques. Plutôt que de rentrer dans des détails techniques abscons, je prends un exemple :

• Lors du traitement de la page http://fr.wikipedia.org/wiki/Hubert-F%C3%A9lix_Thi%C3%A9faine, Gate, à l’aide son gazetteer, extrait les entités suivantes :
  • Alambic
  • Hubert-Félix Thiéfaine
  • Machin
  • Zazie
  • Zoo

  (note : la pertinence de ces extractions est bien sûr cruciale. Ce n’est pas la question ici, mais j’y reviendrai)

• Pour chacune des entités extraites, on créé un attribut “voir aussi” sur le chanteur/groupe ayant comme identifiant l’URL de la page traitée, avec comme valeur l’entité extraite. L’entité Hubert-Félix Thiéfaine se retrouve donc pouvue de 5 attributs “voir aussi”, respectivement vers les entités Alambic, Machin, Zazie, Zoo, et Hubert-Félix Thiéfaine.

On voit bien que ce dernier attribut d’”auto-référence” d’un chanteur vers lui-même est dépourvu de sens. Pourtant, impossible de s’en défaire facilement à cette étape du traitement.
Bref, après le processing des 598 pages de chanteurs français et des 138 pages de groupes musicaux, j’obtiens une première version de ma “base de liens” musicaux. Seul un post-traitement sur cette base permet de se débarasser des “auto-références” gênantes. Après ce post-traitement, j’obtiens 1882 liens pour 736 entités. Voici par exemple le résultat pour Jean-Jacques Goldman :

Et voilà ! C’était l’étape cruciale de l’expérience. Ma liste d’entités initiale s’est maintenant enrichie de liens pour former un joli graphe. Evidemment, cette étape de création des liens pourrait être améliorée, tant au niveau de la pertinence (élimination du bruit), que de l’intégration techniques (Vous avez remarqué ? Léo Ferré n’est pas extrait de la page d’HFT, ni Céline Dion de celle de JJ Goldman… ces deux noms ont des accents… encoding, encoding, quand tu nous tiens…). Prochaine étape : exploiter le graphe, en requête et en visualisation.

Knowledge is Music (et vice-versa) (3) - une liste d’entités nommées à partir de Wikipedia

[le post précédent décrit les objectifs et les étapes de ma petite expérience.]

Etape n°1 : modéliser une ontologie.
Mot d’ordre : “keep it simple”
En fait, j’ai choisi de rester tellement simple que parler d’ontologie n’a plus vraiment de sens ici, en tous cas pour l’instant : 2 classes d’objets, les “chanteurs” (singer) et les “groupes” (band). 2 propriétés : “à propos de” (about) (un lien vers une URL descriptive du chanteur ou du groupe en question), et “voir aussi” (see also) (une référence à un autre chanteur ou groupe de la base de connaissances).
Une sémantique au ras des paquerettes donc.

La distinction entre chanteurs et groupes tient au fait que Wikipedia les distingue dans son portail sur la musique française, donc autant garder la distinction - même si celle-ci n’est pas toujours claire (Manu Chao, un groupe ?).

Je n’ai pas pris la peine d’exprimer cette ontologie en OWL, mais implement en XTM, pour pouvoir l’importer directement dans ITM et paramétrer le logiciel.

 

Etape n°2 : Constituer une liste d’entités.
Wikipedia contient pour ce faire 2 pages intéressantes : La liste des chanteurs français et francophones (600 entrées environ) et La liste des groupes musicaux français (130 entrées environ).

“Fichier > Enregistrer sous…” pour chacune de ces 2 pages, et un petit bout de XSLT permettent d’en extraire deux listes XMLisées propres, contenant pour chaque entrée le nom et l’URL Wikipedia associée :

<chanteur>
<nom>Dominique A</nom>
<url>http://fr.wikipedia.org/wiki/Dominique_A</url>
</chanteur>
<chanteur>
<nom>Abd Al-Malik</nom>
<url>http://fr.wikipedia.org/wiki/Abd_al_Malik_%28chanteur%29</url>
</chanteur>
<chanteur>
<nom>Myriam Abel</nom>
<url>http://fr.wikipedia.org/wiki/Myriam_Abel</url>
</chanteur>


(note : les 2 pages de Wikipedia sont en fait malformées, et ne peuvent pas se traiter directement par XSLT; il faut d’abord passer par un copier-coller pour former un fichier HTML valide)
(note : dans les pages d’origine, on ignore les liens qui correspondent à des pages qui n’existent pas encore dans Wikipedia. Inutile de les sortir.)

De ce format initial, j’ai besoin de tirer 3 choses :

1. Deux fichiers texte contenant respectivement la liste des noms des chanteurs et la liste des noms de groupes, pour alimenter les extractions linguistiques de Gate.
2. Un fichier texte contenant la liste des URL des pages Wikipedia qui devront être analysées par Gate.
3. Un fichier XTM Topic Maps permettant d’importer les chanteurs et les groupes dans ITM.

Pour les deux premiers éléments de cette liste, 2 feuilles de style très simples donnent respectivement comme résultat :
La liste des noms des chanteurs/groupes :

Dominique A
Abd Al-Malik
Myriam Abel
Salvatore Adamo
Isabelle Adjani
Admiral T
Akhenaton
(etc…)


Et la liste des URL des pages à traiter :

http://fr.wikipedia.org/wiki/Dominique_A
http://fr.wikipedia.org/wiki/Abd_al_Malik_%28chanteur%29
http://fr.wikipedia.org/wiki/Myriam_Abel
http://fr.wikipedia.org/wiki/Salvatore_Adamo
http://fr.wikipedia.org/wiki/Isabelle_Adjani
http://fr.wikipedia.org/wiki/Admiral_T
http://fr.wikipedia.org/wiki/Akhenaton_%28rappeur%29
(etc…)


En ce qui concerne la génération du XTM, c’est un tout petit plus compliqué, mais guère. Le résultat ressemble à ça :

<topic id=”N10005″>
<instanceOf>
<subjectIndicatorRef xlink:href=”http://music.mondeca.com/music#Singer” mce_href=”http://music.mondeca.com/music#Singer”/>
</instanceOf>
<subjectIdentity>
<subjectIndicatorRef xlink:href=”http://fr.wikipedia.org/wiki/Dominique_A” mce_href=”http://fr.wikipedia.org/wiki/Dominique_A”/>
</subjectIdentity>
<baseName>
<baseNameString>Dominique A</baseNameString>
</baseName>
<occurrence>
<instanceOf>
<subjectIndicatorRef xlink:href=”http://music.mondeca.com/music#About” mce_href=”http://music.mondeca.com/music#About”/>
</instanceOf>
<resourceRef xlink:href=”http://fr.wikipedia.org/wiki/Dominique_A” mce_href=”http://fr.wikipedia.org/wiki/Dominique_A”/>
</occurrence>
</topic>


Le fichier XTM est “prêt à l’import” dans ITM. Il structure les informations conformément à l’ontologie définie à l’étape précédente (dans la mesure où on peut parler de structuration…) : des topics de classe “chanteur” ou “groupe”, ayant pour nom le nom tiré de Wikipedia, pour subjectIdentity l’URL de leur page Wikipedia, et pour attribut “à propos de” la même URL. (note : l’URL est remise comme attribut en plus du PSI de façon à apparaitre dans les écrans par la suite)

Le fichier XTM est ensuite importé dans l’outil ITM. On peut donc déjà, à la fin de cette étape, y consulter les 2 listes des chanteurs et des groupes, avec pour chaque entrée un nom, un identifiant, et une page associée :

Au total : 598 chanteurs et 138 groupes de musique.

Knowledge is Music (et vice-versa) (2) - un mashup musico-sémantique

[le post précédent explique d'où vient l'idée originale de cette expérience.]

Mon objectif : créer de façon automatisée, à partir de textes non-structurés, une base de connaissances sur les chanteurs et les groupes de musique français. La base de connaissances se restreindra à des relations simples entre chanteurs et/ou groupes de musique. Puis montrer comment cette base peut être exploitée et peut évoluer dans le temps.

Mes outils : si l’article de hackdiary cité dans le précédent post utilisait les webservices Yahoo, et de simples fichiers texte pour structurer ses données, je me propose de réaliser l’expérience avec des outils plus scalables et sur lesquels je peux avoir entièrement la main (impossible de modifier le comportement d’un webservice externe) :

• Gate analyser le contenu des pages (Gate est une plateforme de développement d’applications de traitement automatique du langage développée par l’Université de Stanford)
• ITM, la solution de Mondeca, pour la modélisation de l’ontologie, le stockage de la connaissance, et son exploitation.
• JGraph pour la représentation graphique
• Un soupçon de XSLT
• Une pincée de Java

Ma source de connaissances : j’ai l’impression que “In Wikipedia We Trust” pourrait devenir la devise de beaucoup de gens ces temps-ci. Hé bien je vais moi-aussi supposer que Wikipedia est une source sûre, et en extraire la connaissance qui va alimenter mon petit prototype. (note : une autre bonne source aurait pu être le wiki de last.fm, mais je ne crois pas qu’il soit très fourni en artistes français)

Mon mot d’ordre : “keep it simple” ! compte-tenu de la complexité de la chaîne à mettre en place, je fais d’abord simple, voire très simple, et ensuite, si le temps le permet, j’augmenterai la complexité.

Les 4 étapes de base pour aller au bout de mon petit prototype sont :

1. Modéliser une ontologie
2. Constituer une liste d’entités (ici des noms de chanteurs et de groupes de musique), et importer cette liste dans la base de connaissances.
3. L’étape clé : à l’aide de Gate et du module d’indexation d’ITM, analyser les pages de Wikipedia, pour en extraire des relations entre chanteurs et/ou groupes, et rajouter ces relations dans la base de connaissance.
4. Utiliser la base de connaissances : la requêter et la visualiser avec JGraph.

D’autres étapes pourront venir se rajouter si l’expérience avec les 4 premières est concluante; comme par exemple la mise à jour périodique de la base de connaissance pour rendre compte des évolutions des pages Wikipedia, ou encore un export de la base en RDF.

Knowledge is Music (et vice-versa) (1)

Il y a quelque mois de cela (debut 2006), j’étais tombé sur cet article du site hackdiary. L’auteur (Matt Biddulph) y décrit comment, à partir d’une liste de noms de personnalités politiques anglaises, en utilisant Wikipedia et les webservices Yahoo de recherche et d’extraction de termes, il arrive à créer des liens entre les personnalités de la liste initiale. Le mécanisme est le suivant :

1. pour chaque nom dans la liste, il fait une recherche via le webservice Yahoo. Cela donne une liste de page web de résultat
2. parmi cette liste, il prend le premier des résultats venant de Wikipedia
3. il appelle ensuite le webservice Yahoo d’extraction de termes sur cette page de wikipedia. Ce webservice renvoie une liste de mots ou d’expressions (dont des noms de personnalités) contenus dans la page.
4. parmi cette liste de mots, il prend les noms de personnalités présents dans la liste initiale
5. cela dessine ainsi un graphe des relations entre ces personnalités politiques :(par exemple, si on parle de Margaret Thatcher sur la page wikipedia de Tony Blair, alors il y a un lien, un “pointeur”, de Blair vers Thatcher).

A l’époque, cet article avait été pour moi le premier exemple concret des possibilités offertes par les combinaisons de webservices, ce qu’on appelle aujourd’hui un “mashup”.

L’autre intérêt de cette expérience est de montrer comment il est possible de “créer du lien” de façon automatique. Le lien contextualise l’information, même s’il n’est pas sémantisé (mais c’est encore mieux quand il l’est); et c’est cette contextualisation qui, au-delà des simples informations ou attributs des personnalités en question, se rapproche le plus de ce qu’on pourrait appeler connaissance. C’est la même chose pour le web : ce qui a fait tout l’intérêt et la puissance du web, ce ne sont pas les pages, ce sont les liens entre les pages.

Je me propose donc de réitérer l’expérience dans cette série de post “Knowledge is Music (et vice-versa)”, dans un autre domaine, celui de la musique, à une toute autre échelle, et avec d’autres outils… et autant utiliser ceux de Mondeca !

Knowledge is Music (et vice-versa) (0)

J’ai lu il y a quelques jours dans le magazine Inside Knowledge, édition de septembre 2006, un extrait du livre The Organizational Zoo : A Survival Guide to Workplace Behavior, qui dresse un parallèle entre la musique et la gestion de connaissances dans le monde de l’entreprise, je recopie :

“
Music is written, recorded, filed, archived, accessed, performed and used in many ways by different people for different reasons.
We may participate as writer, performer, teacher, critic or just as a listener. We can be influenced by others or be divergent in what we deliver. Music/knowledge can be done very well or very badly by individuals, small or large groups.
In very large groups it usually involves some common documentation in an understood format and structure so that each person knows what part he or she is responsible for and at what stage. The oboe may not always be heard but it intermittently contributes to the harmony, only occasionnally in evidence as a a solo. Trombones, on the other hand, are usually heard every time they contribute.
(…)
Music can be categorised, used, experienced, enjoyed or hated very differently depending on who we are, what we want from it and in what situations we find ourselves.
No wonder we can never agree on what music/knowledge is. It is a thing, a process and a range of other things depending upon our individual perspective. It becomes something different just through our involvment with it. Because we are all doing different things with our music and engaging it with entities differently, we can never collectively agree on exactly what it is.
“

Le parallèle est intéressant et pour le moins original, et permet de faire émerger des idées. C’est en tous cas une bonne introduction, car on peut comparer la gestion de connaissances à la musique, mais on peut aussi l’appliquer à la musique… c’est ce que je vais essayer de faire, dans un exemple concret de mise en application d’une base de connaissances… à suivre…