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 Victor . É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 Ontologia (site web personnel) . Évalué à 3.
Alors :-)
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.
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 Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hormis que
Posté par Graveen . É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 Ontologia (site web personnel) . Évalué à 2.
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 rewind (Mastodon) . Évalué à 4.
Moi, quand j'ai lu le titre et le début, j'ai pensé à
arrayde PHP qui est un truc bâtard entre le tableau (array) et le tableau associatif (map).[^] # Re: Hormis que
Posté par Ontologia (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 YBoy360 (site web personnel) . Évalué à 3.
ça me fait penser au Web sémantique, à Nepomuk. C'est à peu près ce que tu décris : les données sont stockées dans des bases sous forme de triplet "sujet - prédicat - objet". Dans le cas de Nepomuk, ce sont même des quadruplets, le dernier terme définissant le graphe de stockage (en gros les méta données et les données).
http://techbase.kde.org/index.php?title=Development/Tutorials/Metadata/Nepomuk/RDFIntroduction
En même temps, ton pseudo c'est Ontologia, donc je pense que tu dois connaitre ..
[^] # Re: Hormis que
Posté par Ontologia (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 barmic . É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 Etienne Bagnoud (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 Enzo Bricolo 🛠⚙🛠 . É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.