Voir, Savoir et/ou Agir

décembre 20, 2006

Dans un papier au titre provocateur présenté à ISWC 2006, une excellente critique des représentations « graphiques » des graphes RDF, et du dogme implicite sous-jacent: « Puisque c’est un graphe, montrez-le comme un graphe ». N’ayant jamais été complètement convaincu des avantages de ce type de visualisation, cette lecture m’a profondément réjoui, et mon point de vue en sort renforcé. En gros, si le graphe est petit, c’est joli mais inutile car la structure serait évidente sous toute autre forme, et si le graphe est grand c’est illisible donc inutilisable. Des interfaces qui s’adapteraient à la structure locale du graphe pour en donner une représentation utile à toutes les échelles, avec des algorithmes savants de réduction, même si elles sont techniquement concevables, entraînent de tels surcoûts en terme d’implémentation et de temps de requête qu’on en voit mal le modèle économique. Le périmètre d’utilité véritable se limite donc à des types de scénario bien choisis, par exemple une démonstration commerciale ou une « preuve de concept ». Enfin attendons ce que Thomas va nous montrer pour sa base musique, il va peut-être vous convaincre du contraire.
Cela dit, la critique du papier va plus loin que le simple problème « graphe ou pas graphe ». Les vrais croyants dans un modèle de représentation des connaissances ont une tendance fâcheuse à vouloir que ce modèle – bien sûr génial – transpire par tous les pores des interfaces utilisateurs, de la même façon qu’une certaine génération d’architectes a tenu absolument à ce que la géniale structure de béton ou de tuyauterie de leurs édifices impérissables s’impose à tout moment aux utilisateurs des lieux … nous avons à Paris des exemples célèbres.
Ayant moi-même succombé à cette tentation plus d’une fois, je me garderai bien de jeter la pierre à tous ces enthousiastes. Aux débuts de Mondeca, je voulais à tout prix que tous les utilisateurs comprennent la beauté du méta-modèle Topic Maps sous-jacent … mais l’expérience amène petit à petit à une conception plus utilitaire des modèles. Et le papier en question le dit fort bien. La question importante en fin de compte à propos des données, quelle que soit la façon dont elles sont représentées et stockées dans les systèmes, est bien de savoir à quoi elles servent et comment on s’en sert. Savoir ce qu’elles « sont » ou ce qu’elles « représentent » n’étant pas la préoccupation essentielle de la majorité des utilisateurs.
Comme l’histoire du Web l’a toujours montré, et comme les applications Web 2.0 qui fleurissent de partout le montrent de nouveau, ce qui intéresse le plus les utilisateurs, c’est bien d’agir sur l’information. On veut interroger et naviguer, mais surtout on veut créer, modifier, copier, ajouter, retrancher, reconnecter, mettre en perspective, republier, renvoyer … et tout cela bien sûr de façon ergonomique. Donc, autant et sinon plus que la structure des données et du système de représentation qu’elles utilisent, c’est la sémantique des actions sur les données qui doit être transparente dans les interfaces.
Si on rapproche cette réflexion de nos propos récents sur la sémiotique de RDF, on pourrait dire que le signifié d’une ressource doit être pensé plus en termes fonctionnels qu’en termes purement descriptifs ou déclararatifs. Certes, une description RDF décrit son référent, mais le choix des éléments de description, et donc les choix de modélisation sont pilotés par l’usage fonctionnel de cette description. La description d’une personne en tant que musicien ne sera pas la même que la description de cette même personne en tant que contribuable parce que l’amateur de musique attend des fonctions comme la découverte des oeuvres ou des musiciens associés (vous avez aimé … vous aimerez aussi), alors que la description du contribuable a de tout autres usages pour d’autres utilisateurs.
Ceci nous renvoie encore une fois à la question de l’identité. Le musicien et le contribuable sont-ils ou non la même personne? Si la question reste ouverte dans la vraie vie, dans nos systèmes d’information il est certain qu’il s’agit bien de deux concepts différents, avec des représentations, des propriétés et des fonctions différentes. Peut-on, doit-on pouvoir les rapprocher, voire les fusionner, et si oui pourquoi et comment? C’est une des grandes questions des technologies sémantiques. Nous y reviendrons.

Publicités

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

décembre 19, 2006

[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)

L’application Gate paramétrée

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 :

La page de Jean-Jacques Goldman après le traitement

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

décembre 14, 2006

[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.

mini-ontologie dans ITM

 

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&gt;
</chanteur>
<chanteur>
<nom>Abd Al-Malik</nom>
<url>http://fr.wikipedia.org/wiki/Abd_al_Malik_%28chanteur%29</url&gt;
</chanteur>
<chanteur>
<nom>Myriam Abel</nom>
<url>http://fr.wikipedia.org/wiki/Myriam_Abel</url&gt;
</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 :


Liste initiale des groupes
Page initiale d’un groupe

Au total : 598 chanteurs et 138 groupes de musique.


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

décembre 10, 2006

[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)

décembre 8, 2006

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 :Graphe des personnalités politiques anglaises(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 !


Leçon 4 : Anatomie d’une Description (2)

décembre 8, 2006

Dans une leçon précédente on avait volontairement laissé en pointillés la chose décrite, pour ne s’intéresser qu’aux éléments de la description elle-même. Je vais donc revenir là-dessus aujourd’hui à partir du même exemple, cette fameuse montagne d’altitude 3913 m, voisine du Mont Pelvoux.
Le lecteur un peu familier du Massif des Ecrins, à l’aide d’une bonne carte, aura tôt fait de s’assurer qu’il ne peut s’agir d’autre chose que de notre bon vieux Pic Sans Nom. Et s’il a suivi les leçons précédentes, il pourra même lui attribuer illico un identifiant homologué Web sémantique. Et il pourra dire que tout est pour le mieux dans le meilleur des mondes sémantiques, où toutes les choses sont identifiées par une URI.
Fort bien. Mais est-ce que deux utilisateurs humains qui effectuent le même processus d’identification ci-dessus, et tombent d’accord sur le fait d’attribuer à la chose cette même URI, sont pour autant d’accord sur l’identité de la chose en question? Après Quine, nous pouvons soutenir qu’une telle conclusion est impossible. Et de fait, on peut raisonnablement douter que Pierre le géographe qui a identifié la montagne à partir d’une carte topographique, et qui n’a encore jamais mis les pieds dans les Ecrins, en aura la même conception que Jacques l’alpiniste qui a failli y mourir de froid lors d’une tentative hivernale sur la redoutable face Nord. Et si l’on va plus loin dans le détail de la description, les éléments que vont y ajouter Pierre et Jacques risquent d’être au mieux singulièrement différents, et au pire totalement contradictoires. On découvrira sans doute assez vite qu’au-delà de leur accord initial sur le fait qu’ils parlent bien de la même montagne, ils ne décrivent pas vraiment la même conception de cette montagne. Et nous arrivons ici à un point fondamental : on ne décrit jamais directement une chose, on décrit le concept qu’on a de la chose. Et même si on s’accorde à parler de la même chose, on peut être en désaccord sur la conception qu’on en a.
L’approche linguistique, et en particulier le triangle sémiotique introduit par Saussure : signifiant, signifié, référent, peut être utilisée ici. Une ressource RDF identifiée par une URI, décrite par un ensemble de propriétés formelles est dans cette approche un signe linguistique. L’URI en est le signifiant, la description formelle associée est une explicitation du signifié, et la chose décrite est le référent.
Dans le triangle sémiotique, la question de l’identification peut se poser à plusieurs niveaux. On peut bien sûr avoir des signifiants différents pour le même signifié (synonymie), ou des signifiés différents pour le même signifiant (homonymie, que le système des URI est censé évacuer). Mais on peut aussi avoir des couples signifiant-signifié différents pour le même référent. C’est la situation évoquée plus haut. Malheureusement les langages, spécifications et pratiques du Web sémantique ne semblent pas avoir vraiment prévu cette dernière situation, pourtant capitale pour la recherche et l’agrégation de l’information. OWL permet d’exprimer l’identité de deux concepts, que ces concepts soient des classes, des propriétés ou des individus, en utilisant respectivement les relations owl:equivalentClass, owl:equivalentProperty et owl:sameAs. Toutes ces relations servent à déclarer l’identité logique des signifiés de deux signifiants (URI) différents. Mais rien n’est prévu dans ce langage, du moins de façon native, pour exprimer que deux signifiés différents ont le même référent.

Pourtant, comme je l’ai suggéré çà et là depuis plus d’un an, RDF possède des caractéristiques qui permettraient de représenter cette situation, en utilisant une ressource anonyme (blank node) pour représenter le référent. Ainsi on pourra dire que le Pic Sans Nom selon Geonames, celui de Pierre et celui de Jacques ont le même référent de la façon suivante.

 geonames:6295658     sem:referent      _:b
 pierre:PicSansNom     sem:referent      _:b
 jacques:PicSansNom     sem:referent      _:b

Le fait d’utiliser une ressource anonyme comme représentation du référent constitue une entorse minimale au principe disant que le référent est en dehors de l’espace linguistique. Le fait de ne pas lui attribuer de signifiant propre (ni nom, ni URI) est conforme toutefois à ce principe. La propriété sem:referent proposée ici n’est bien sûr pour l’instant définie par aucun vocabulaire standard, mais elle pourrait l’être dans une ontologie des signes qui reste à construire. Elle n’entraîne pas la fusion logique des trois ressources, autrement dit elle n’implique pas l’identité des signifiés. On peut la considérer à la rigueur comme une spécification de la propriété Dublin Core dc:subject.

Représenter le référent par une ressource anonyme permet d’en faire un « hub sémantique » sur lequel on pourra par exemple accrocher des « indicateurs de sujet » employant le vocabulaire des Topic Maps repris par SKOS, ou encore des images en utilisant le vocabulaire FOAF.

 _:b      skos:subjectIndicator     <http://yannick.michelat.free.fr/PicSansNomRussenberger1.htm>
 _:b     foaf:depiction      <http://ascensions.free.fr/images/col_est_pelvoux/lever_pic.jpg>

Attacher ces ressources directement à chacun des signifiants spécifiques définis plus haut est encore la pratique courante aujourd’hui dans le Web sémantique, qui n’a pas vraiment intégré le triangle sémiotique, et ce que nous proposons ici a encore un bout de chemin à faire pour être compris et accepté …
 


Aussi simple que possible …

décembre 1, 2006

… « mais pas plus » selon la célèbre formule attribuée à Einstein, et dont la forme originale serait, selon Wikiquote

« The supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience. »

Dans le genre dépouillé, notre ami Michel Biezunski avait déjà à son actif la co-paternité du concept de Topic Maps avec son vieil acolyte Steve Newcomb, lorsqu’il se penchait sur le berceau de Mondeca au tournant de ce siècle. Et d’ailleurs, en tant qu’auteur d’ouvrages consacrés à l’illustre physicien et à l’histoire de la physique du 20ème siècle, il pourra peut-être nous confirmer l’authenticité de la citation dont il semble s’être inspiré une fois encore. Je savais que depuis un bon bout de temps Michel travaillait sur un modèle encore plus épuré, dans le prolongement du travail de Newcomb, Durusau et al. sur le Reference Model de Topic Maps, et de ses propres idées sur les « perspectives » présentées à Extreme Markup 2005. Des idées qui avaient à l’époque alimenté mes propres réflexions sur les « hubjects » et autres « blank concepts », qui depuis ont fait un bout de chemin et j’y reviendrai ici un de ces jours. Je savais donc qu’il était dans un tunnel de recherche au bout duquel quelque chose d’encore plus simple surgirait.
Et voilà … la nouvelle m’est parvenue ce matin via planète web sémantique et ce petit billet de notre ami Eric van der Vlist sur xml.fr, qui nous explique dans son style sobre habituel déjà pas de choses – que je ne vais pas répéter ici. DPM, Data Projection Model, un nom austère s’il en est, mais nous avons pris l’habitude de ces concaténations triangulaires à la sémantique mystérieuse, que seul l’anglais permet. Resource Description Framework, Intelligent Topic Manager … et bien d’autres.
Je suis donc allé faire un tour et je vous conseille d’aller directement à cette page pour apprécier l’extrême dépouillement du modèle, dont la DTD tient en 9 lignes courtes que je ne résiste pas à la tentation de recopier ici.

<!ELEMENT perspectors (p)+>
<!ATTLIST perspectors
id ID #IMPLIED >
<!ELEMENT p (x,o,y)>
<!ATTLIST p
id ID #REQUIRED>
<!ELEMENT x (#PCDATA) >
<!ELEMENT o (#PCDATA) >
<!ELEMENT y (#PCDATA) >

C’est la quintessence des triplets RDF sans les URI, ni les ressources, ni les literals. « Sujet, Verbe, Complément » en grammaire. « Opérande 1, opérateur, Opérande 2 » en mathématiques. RDF apparait comme une version encore mal dégrossie et particulière de DPM, et Topic Maps également.

Brillant. Maintenant le plus difficile reste à faire pour Michel. Reprendra-t-il son bâton de pélerin, comme il l’a fait avec Topic Maps? Et de cette idée simplissime, si la communauté s’en empare, parviendra-t-elle à lui garder sa pureté initiale, ou deviendra-t-elle, comme XML et bien d’autres, une usine à gaz encombrée d’accommodements avec le diable? Ce dernier seul le sait … Je pense que Michel ne se fait pas d’illusions, lui qui aime à rappeler que : « On n’a jamais intérêt à être plus intelligent que tout le monde ».