Journal Une structure de données générique ?

Posté par  (site web personnel) .
Étiquettes :
5
3
juil.
2012

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, 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 :

    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 :

    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 :

    type verbeSpeciaux =
    | DemandeInscription
    | Creation
    | Envoie


    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 :

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

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.

  • # Où est la donnée ?

    Posté par  . Évalué à 6. Dernière modification le 03 juillet 2012 à 12:46.

    En fait, il me semble dans tes exemples que les données elles-mêmes ce sont les noms.
    La phrase n'est pas une donnée, mais une requête.
    Selon comment tu représente les choses, ça aurait pu être représenté par une méthode en objet, une fonction en fonctionnel, un message en acteurs, etc… et toi tu as utilisé la structure de donnée phrase pour ça.

    Mais la donnée elle-même, au final, ce n'est que la déclaration d'un type caml.

    Non ?

    • [^] # Re: Où est la donnée ?

      Posté par  (site web personnel) . Évalué à 3.

      Alors :-)

      1. Effectivement, c'est une requête, enfin ça peut l'être, mais pas que. Je les utilise principalement pour exprimer des évènements, des informations, et je peux aussi en faire une requête, en définissant un Quoi/Qui/Que/Comment dans le sujet.

      2. Effectivement, on planque la donnée dans la déclaration d'un type, mais l'intérêt, c'est le polymorphisme : je peux utiliser plusieurs verbes avec des noms identiques, et ça permet de définir plein de choses différentes, car tu peux par exemple associer, plein de verbes, plein de noms à la place du sujet pour le nom "fichier" en position de complément d'objet.
        Mais il est vrai que si c'est mal utilisé, tu perd la généricité dans le nom, tel que tu le définis.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Hormis que

      Posté par  . Évalué à 2.

      je suis assez d'accord. Je rapproche vraiment ça du typage: il est utile car définissant trés bien un élément de base.

      A bien y réfléchir, je reprocherais à ta démonstration la même chose qu'au typage String permettant de contenir n'importe quoi: avantages et inconvénients identiques.

      • [^] # Re: Hormis que

        Posté par  (site web personnel) . Évalué à 2.

        A bien y réfléchir, je reprocherais à ta démonstration la même chose qu'au typage String permettant de contenir n'importe quoi: avantages et inconvénients identiques.

        C'est pas faux, à ceci près qu'en OCaml/Haskell et à moindre mesure en Scala, le compilateur vérifie pour toi que tu traites les cas exhaustivement, ce qui est particulièrement intéressant. De plus l'utilisation du pattern matching rend l'écriture plus aisé et facile à relire.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Hormis que

        Posté par  (Mastodon) . Évalué à 4.

        Moi, quand j'ai lu le titre et le début, j'ai pensé à array de PHP qui est un truc bâtard entre le tableau (array) et le tableau associatif (map).

    • [^] # Re: Hormis que

      Posté par  (site web personnel) . Évalué à 3.

      • Je ne suis pas un scientifique, je n'ai pas eu la chance d'en avoir la formation.

      • Je préfère délayer pour être sûr d'être compris par tout le monde.

      • J'essaye de proposer une solution pragmatique à un problème pragmatique dans le domaine de l'informatique de gestion. J'appartiens pas à un laboratoire.

      • L'objectif n'est pas ici de représenter du code, surtout que dans le monde de l'informatique de gestion, c'est dangereux, on évite.

      • L'Homoiconicité est un concept bien trop puissant pour mon besoin et les besoins courants en informatique de gestion

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Hormis que

      Posté par  (site web personnel) . Évalué à 2.

      Le problème de l'homoiconicité est qu'elle créé un trou de sécurité : on peut exécuter du code à travers elle et c'est excessivement dangereux.
      Dans l'application que je développe, la sécurité est absolument cruciale.
      J'essaye, by design, de ne laisser aucune porte ouverte possible.

      Un exemple d'homoiconocité qui a été vidé de sa substance est le format JSON. À la base, on pouvait planquer du code dans le JSON, à cause de son homoiconocité intrinsèque.
      JSON.parse garantie que le JSON ne contient que des données.

      Bref, l'homoiconocité c'est beau dans un laboratoire, mais pas dans la vraie vie.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # ??

    Posté par  . Évalué à 4.

    J'ai l'impression que c'est une transposition des classes (avec de l'héritage, des liens entre ces classes, etc).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # asn.1

    Posté par  (site web personnel) . Évalué à 3.

    Ça ressemble à de l'asn.1 http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # A propos qui n'a rien à voir

    Posté par  . Évalué à 1.

    Ca me rappelle une discussion dans la mailing list d'opencog …

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.