URL: https://linuxfr.org/users/montaigne/journaux/une-structure-de-donnees-generique Title: Une structure de données générique ? Authors: Ontologia Date: 2012年07月03日T12:24:38+02:00 Tags: sémantique, ocaml et programmation_fonctionnelle Score: 5 On est souvent confronté dans le développement à des besoins constants d'évolution de structures de données. C'est pourquoi on possède maintenant de nombreux outils qui gèrent la migration, la colle objet-relationnel et autres problématiques purement techniques. Mais peut-on construire une structure de donnée totalement générique, étanche à l'évolution des données à encoder ? J'entend généricité par sa capacité à exprimer n'importe quel contenu sémantique. M'étant pas mal amusé avec [Attempto Controlled English](http://linuxfr.org/news/attempto-controlled-english), je m'en suis inspiré pour construire une structure de donnée assez générique, facilement évolutive, et dont l'évolution, à condition que l'on ne supprime pas de vocabulaire, permet la reprise d'anciennes données. Comme je l'expliquerais, celle-ci n'est pas totalement générique à cause d'un problème de profondeur de l'arbre. Mais c'est un choix facilement modifiable. J'utilise pour ce faire un typage en OCaml, facilement reproductible en Scala ou Haskell. En OCaml, je dispose d'Atdgen, écris par Martin Jambon, qui permet de sérialiser/désérialiser des données définies dans un type OCaml en JSON. Cela permet l'échange de données inter application, le stockage dans de nombreuses bases NoSQL adaptée au JSON. Le concept consiste simplement à définir une phrase simple: sujet, verbe, complément d'objet, complément d'objet indirect. On commence par la définition d'un ordre, qui est une bête structure : ```ocaml type ordre = { sujet : mot; verbe : mot; complementObjet : mot; complementObjetIndirect : mot; } ``` Par définition, un verbe peut être intransitif (il pleut), transitif (je mange une pomme), bitransitif (je donne quelque chose à quelqu'un), ainsi on peut représenter diverses formes de contenus. Un ordre se structure donc comme une phrase simple : sujet, verbe, complément d'objet, complément d'objet indirect. On s'arrête là car on pourrait aller plus loin avec des relations de position, etc... Un mot se défini comme suit : ```ocaml type mot = | NA | Sujet of nomSpeciaux | Verbe of verbeSpeciaux ``` Un mot peut être vide, être un nom ou un verbe, on ne s’embarrasse pas d'adjectif. Reste ensuite à définir le vocabulaire : ```ocaml type verbeSpeciaux = | DemandeInscription | Creation | Envoie ``` ```ocaml type login = string type pass = string type forumId = int type nomSpeciaux = | User of (userName * nomReel) | Fichier of string | Message of string | Forum of forumId * login * pass ``` Un phrase/ordre peut être ainsi : ```ocaml { sujet = Nom (User("userFichet","Pierre Pichet")); verbe = Verbe DemandeInscription; complementObjet = Nom (Forum (23,"login","pass")) } ``` Il ne reste plus qu'à enrichir petit à petit le vocabulaire des verbes et noms, afin d'enrichir la sémantique des données. La limitation de cette structure, en l'état, est la limite de profondeur de la phrase. On peut régler ce problème en permettant de définir une phrase à la place de chaque mot, en précisant si c'est une phrase. Si l'on souhaite aller réellement plus loin, on sera alors obligé de représenter complètement un Discourse Representation Structure [dont j'ai écris un parser](https://github.com/ontologiae/DRS-Analysis-Tool). J'utilise cette astuce dans un logiciel client/serveur et celle-ci permet de représenter énormément d'informations. Elle permet aussi de traiter facilement le message par pattern matching.