Le fil des nouvelles sur l'avancement de mon projet ERic (Entity-Relationship interactive calculator).
La dernière version stable ERic 0.2g :
- Vous pouvez consulter la documentation en ligne
- Vous pouvez récupérer l'archive zip de la dernière version
- Vous pouvez également récupérer la version SVN d'ERic
- Rejoignez le forum des utilisateurs d'ERic
ERic vient de passer en version 0.2g :
Ajout de la relation d'inégalité a =/= b entre deux entités, dans les requêtes (select).
Sur le dessin ci-dessous cela signifie que la boîte Difference-link est maintenant dans la boîte principale ERic 0.2g (tout en restant dans la boîte Operators).
Pas d'archive. J'ai uniquement mis à jour le dépôt SVN.
Comme je ne teste pas et que je n'ai aucun utilisateur il n'y a pas de bug connu.
SpiceGuid a écrit :
Génie !
Tester c'est une perte de temps. Au lieu de pleurer qu'il y a un bogue, un utilisateur constructif devrait poster dans Certification d'un algorithme efficace de H-coloration.
Pourquoi modifier un code boggué si je ne peux même pas prouver que le nouveau code est correct ? Ça ne sert à rien. C'est une perte de temps.
Il n'y a qu'une seule façon de prouver que le code (modifié ou pas) est correct c'est de contribuer à la Certification d'un algorithme efficace de H-coloration. Si vous connaissez une autre façon de procéder merci de me la communiquer.
Il existe des programmeurs qui préfèrent tester. Le résultat on le connaît : leurs programmes sont truffés de bogues.
ERic est en phase de conversion vers le toolkit GTK+ 2.24 (travail qui n'est pas terminé à l'heure qu'il est).
À l'occasion de cette conversion j'ai pu repenser aux problèmes qui sapent ERic depuis le tout début du projet (pas d'utilisateurs, pas de domaine d'application privilégié, pas de killer-app, trop de généralité, trop d'incitation à des dérivatifs fantaisistes / utopiques / délirants).
J'en suis venu à conclure que le problème n'est pas dans l'interface. Et donc la GTK-isation ne va rien changer aux fondamentaux :
Pour l'instant la GTK-isation offre un IDE limité : seules les parties hiérarchie entités et hiérarchie relations sont 100% graphiques et intuitive. Le gros du travail, c'est-à-dire la spécification des graphes, reste 100% textuel.
La GTK-isation ne peut pas apporter plus d'utilisateurs. Au contraire ERic devient quasiment Linux-only (plus il va falloir générer un paquet pour chaque grosse distribution Linux, ce qui ajoute du travail, toujours sans toucher plus d'utilisateurs que la version actuelle, sur console donc 100% portable tous systèmes).
Plus fondamentalement c'est la documentation qui pêche par manque de focus. Elle ne dit pas à quoi peut bien servir ERic exactement tout en laissant penser qu'il peut servir à tout et n'importe quoi. C'est une erreur qui ne vient pas de moi mais de la documentation universitaire sur le sujet. L'universitaire aime être universel. Il n'aime pas admettre que son travail a un champ limité d'applications.
La conclusion c'est que je dois moi-même trouver un ou des domaines d'applications privilégiés. Et cibler la documentation 100% vers ces domaines.
J'ai encore 1 ou 2 idées d'extensions faciles à implémenter, qui augmenteront encore l'expressivité d'ERic, lui ouvrant de nouvelles perspectives. Mais sans le faire déborder de son cadre initial.
Quel est ce cadre initial ? Il est caché. Il m'a fallu des mois (1 ans ?) pour l'identifier à peu près vaguement :
ERic n'est pas un outil linguistique. ERic n'est pas un agent conversationnel. ERic n'est pas une intelligence artificielle. ERic n'est pas capable de raisonner.
Si on pouvait éditer les graphes-imbriqués de façon 100% graphique ERic pourrait éventuellement concurrencer les autres méthodes de modélisation (formelles ou informelles). Malheureusement je n'en suis pas à ce stade de développement et j'en suis loin. Et je n'y parviendrai peut être jamais (à supposer qu'il soit envisageable d'y parvenir, ce qui n'est pas une vérité acquise d'avance).
De fait il ne reste que la modélisation des graphes-imbriqués sous une forme textuelle. À quoi cela peut-il bien servir ? À soutirer de l'information hautement spécifique d'une énorme base de données hautement généraliste. Ou du moins très richement expressive. C'est petit comme domaine d'application. Car les personnes qui alimentent la base de données doivent être qualifiées (sinon la base sera de mauvaise qualité) et nombreuses (sinon la base sera de petite taille et alors pas besoin d'outil, on peut extraire à la main). Or qui dit nombreuses personnes qualifiées dit coûts élevés de personnel. Commercialement parlant ça veut dire qu'ERic est difficilement viable. Trop coûteux d'utilisation.
Je vais sans doute poursuivre la GTK-isation et réécrire une autre documentation (en anglais) plus ciblée pour une nouvelle version aux possibilités étendues. Rien que pour le plaisir de montrer qu'on peut faire des choses complexes avec une interface sophistiquée, tout ça 100% en ocaml. Mais en dilettante, sans enthousiasme.
Pour la suite, il n'y en aura une que s'il y a de la demande ou si je peux la créer.
Comme de nombreux membres sur ce site j'ai (autrefois) songé, comme une possibilité, à travailler (en indépendant) dans le domaine du jeu-vidéo. Aujourd'hui j'exclus cette voie pour les raisons suivantes :
Je suis incapable d'innover en matière de gameplay, ce qui me semble être le principal atout d'un indépendant.
Le marché du jeu-vidéo est devenu trop concurrentiel. Les prix sont trop bas. Pas assez de visibilité sur la rentabilité.
Pas assez de visibilité sur le déplacement de la valeur ajoutée. Certaines plateformes sont des déserts commerciaux où tout doit être gratuit. D'autres sont des vaches à lait. Impossible de prédire quelle plateforme sera la vache à lait dans 2 ans (le temps minimum pour développer un premier jeu).
Devant le manque de visibilité sur l'avenir du hardware la tentation est grande (c'est une question de survie) de viser les technos les plus portables. En général ça veut dire Java ou JavaScript + SDL ou SFML. Ça produit des jeux aux performances médiocres qu'on déguise derrière un look "rétro". Ça ne correspond en rien à mes aspirations. Je ne suis pas motivé.
Des personnes qualifiés qui gèrent des produits complexes avec de forts enjeux financiers qui dépassent le coût du personnel ça existe dans le secteur bancaire.
Pourquoi ERic est inadapté au secteur bancaire :
Les produits financiers sont complexes à la fois dans leur structure (ce que ERic peut modéliser facilement) et dans leur contexte (que ERic peut aussi modéliser facilement).
Malheureusement pour ERic, si la structure d'un produit financier est stable, son contexte lui est extrêmement volatile.
ERic ne gère pas la volatilité. Il n'a pas de mécanisme de mise à jour. Il ne modéliser que des connaissances (des choses stables dans le temps).
Il est plus que temps de passer à l'étude de marché
Je change complètement de démarche de développement :
"Le client..., le client..., les besoins du client..., les attentes du client..." c'est ce que ne cesse de me répéter mon pote qui travaille dans une SSII. Je ne suis pas exempté de cette démarche. Je ne suis pas dans une tour d'ivoire: ERic n'est pas un PFE (Projet de Fin d'Études), je n'aurai pas de diplôme. Donc je suis obligé d'avoir un (des) utilisateur sinon autant tout arrêter. Je ne vais me prendre la tête pour le plaisir de me prendre la tête. Jusqu'ici j'avais une tendance à ça, mais maintenant c'est du passé.
Comment savoir ce que veulent les utilisateurs. À première vue c'est le problème de la poule et de l’œuf puisque j'ai exactement zéro utilisateur. Mais en fait c'est plus simple que ça : on appelle cela de la vieille technologique. Typiquement un (éventuel) futur utilisateur d'ERic utilise déjà un outil de base de données sémantiques qui ne lui donne pas entièrement satisfaction. Ou qui lui donne satisfaction mais ERic serait encore plus avantageux et il ne le sait pas. D'où la démarche en deux temps (1) dénicher ces utilisateurs (2) les convaincre de changer d'outil.
Dénicher ces utilisateurs
Ils sont dans une niche. Toutefois ils ne sont pas cachés comme des chiens méchants. Je connais leur niche. Ils
rongent un osutilisent un outil qui ressemble de près ou de loin à ERic 0.2g. Il suffit de lister ces outils et de consulter les wikis associés pour se faire une idée. Démarche efficace : on va aller du plus proche d'ERic jusqu'au plus éloigné.Le plus proche d'ERic
Le projet le plus proche d'ERic est sans conteste CoGUI / Cogitant. C'est un projet universitaire français, open-source développé par LIRMM, l'aboutissement de plus de 20 ans de recherche.
Il ne sert à rien (à part pour se miner le moral) de lister tout ce que peut faire CoGUI / Cogitant et dont ERic est incapable.
Ce qui importe c'est le contraire, où ERic est-il meilleur que CoGUI / Cogitant :
ERic est plus beaucoup plus compact, n'utilise pas Java, peut facilement s'utiliser sur un eeePC 701 où tout autre appareil ultra-portable. ERic est sans doute aussi plus performant (estimation pifométrique : je n'ai pas de benchmark pour appuyer cette supposition).
ERic supporte le modèle des boxed-graphs (les liens peuvent entrer et sortir des boîtes), alors ne supporte que le modèle des nested-graphs (les liens ne peuvent ni entrer ni sortir des boîtes).
Ok, maintenant où est le Wiki, où sont les utilisateurs, qui sont-ils ?
cogitant wiki,cogitant user list,cogitant forum,cogitant mailing-list,... tous les résultats renvoient vers le portail cogitant.sourceforge.netAucune trace d'un quelconque utilisateur. Pas plus de trace d'un cogitanteur que d'un martien tout vert
Ça démarre très mal pour ERic. S'il y a zéro utilisateur Cogitant alors il y a zéro utilisateur déçu / à convaincre / à convertir.
Restons positif. Disons que Cogitant est 100% universitaire, qu'il n'a pas su se mettre en avant, et que les utilisateurs sont à chercher ailleurs.
Le camp ennemi
Pas besoin d'être un grand détective pour constater que les utilisateurs sont chez Protégé (pas moins de 4 pages de projets).
L'approche Protégé est radicalement différente de ERic / Cogitant. Au lieu d'être basée sur un formalisme mathématique / logique elle est basée sur une POO (
ProgrammationOrientéeObjets) repensée à la sauce KR (KownledgeReprésentation).Alors je devine votre réaction. Vous vous dites "la POO je maîtrise" et "la logique ça me prend la tête" et d'autres choses dans le genre qui vous font penser que Protégé est bien plus user-friendly que ERic ou Cogitant. Seulement vous n'y connaissez rien en
KR. Autrement dit vous êtes confis de préjugés à la con. Protégé est aussi (sinon plus) difficile à maîtriser que n'importe quel autreKR-tool.À vrai dire je me fiche de ce que vous pensez, ce qui importe avec 4 pages de projets c'est que j'ai trouvé un vivier d'utilisateurs à partir duquel je peux dégager un profil-type pour un (éventuel) futur utilisateur d'ERic
Les musées
J'aime bien l'exemple des musées.
Malheureusement pour moi CIDOC a l'air bien installé, ou en tout cas très soutenu par les grandes institutions telles que ICOM et la commision européenne. Difficile pour un particulier de se faire une place là où il y a déjà un standard de-facto
Protégé supporte les graphs.
Cogitant supporte les nested graphs.
ERic supporte les boxed graphs.
Qu'est-ce ça veut dire pour le client/utilisateur ?
Dit autrement qu'en termes de liens et de boîtes.
Bref, qu'est-ce ça veut dire en français ?
Protégé a un modèle entités-relations.
Cogitant a un modèle entités-relations avec zoom.
ERic a un modèle entités-relations avec point de vue.
Avec Protégé on ne peut pas zoomer. On voit toujours un graphe dans sa totalité.
Quand on zoome sur une boîte avec Cogitant on tombe sur un nouveau graphe dans lequel on peut éventuellement zoomer à nouveau. Mais à chaque étape on est isolé, il n'y a pas de lien venant de l'extérieur ou allant vers l'extérieur. À chaque étape on voit toujours un graphe dans sa totalité, enfermé dans son contexte (la boîte englobante).
Quand on zoome sur une boîte avec ERic on tombe sur un nouveau graphe dans lequel on peut éventuellement zoomer à nouveau. Mais on n'est pas forcément isolé, il y a éventuellement des liens venants de l'extérieur ou allants vers l'extérieur. On ne voit pas un graphe dans sa totalité. On voit un graphe partiel. Ce que l'on observe c'est un point de vue sur la totalité.
Qui dit liens venants de l'extérieur ou allants vers l'extérieur dit interface.
Visionnons le schéma de conception. Où est la boîte [Interfaces] ?
Elle est dans la boîte [Bigraphs] laquelle est à l'extérieur de la boîte [ERic 0.2g].
Dit autrement : ERic a une conception bâtarde. Ses données sont de type point de vue sans qu'il supporte les opérations sur les interfaces avec les autres points de vue.
Comment arranger ça ? Il faudrait tout recommencer en partant des bigraphs.
Est-ce que c'est réaliste/envisageable ? Non. À l'heure actuelle le bigraph est l'une des structures les moins bien comprises de toute l'informatique.
Que comptes-tu faire du coup ?
Du coup c'est un projet d'avenir qui devient un projet personnel.
L'outil tel qu'il est n'est pas fondamentalement invalidé, ce sont juste certaines possibilités d'évolution qui se brouillent ou qui se referment pour longtemps.
Je pourrais même lui ajouter deux extensions mineures, qui vont de soi :
Il faudrait aussi réécrire la documentation, en anglais.
Après il faudrait un dépôt sur la forge de l'UE.
Et puis démarcher/communiquer pour voir comment l'environnement administratif/industriel peut ou ne peut pas s'approprier l'outil. En y mettant de la conviction. Mais sans jouer mon avenir uniquement là-dessus.
Communiquer aussi avec des logiciens/linguistes/philosophes pour un retour d'idées.
Suggestion n°1 :
Suggestion n°2 :
Bonnes suggestions, on voit bien à quel point ça te réussit, TSG
J'ai plutôt choisi sa suggestion n°2, ce qui est un moindre mal vu ce que pourrait être ma suggestion n°3, n'est-ce-pas
Vos trucs de codes de chameaux, j'y comprends rien, mais j'ai cru comprendre qu'il était un peu question d'une problématique désespérée. Je suis un peu expert dans le domaine, mais ça veut pas dire que c'est une bonne chose.
La documentation en ligne (et dans le dépôt SVN) évoque désormais le modèle du graphe de boîtes.
Par contre la nouveauté de la version 0.2g (les difference links) n'est toujours même pas mentionnée. C'est dire mon degré de motivation
Comme c'est la rentrée universitaire, les étudiants / élèves ingénieurs doivent sans doute rechercher (beaucoup n'ont pas d'idée) un sujet pour leur projet de fin d'année / fin d'étude. Ça me paraît une bonne période pour prospecter des utilisateurs en étroite collaboration avec des institutions d'enseignement supérieur technologique.
À moins que le jeu ne soit plus fort.
J'ai un peu de mal à définir ce que serait le web si les données y étaient codées comme dans ERic.
Clairement ERic est une technologie de représentation des connaissances.
D'après Wikipédia :
Cependant ERic repose sur les graphes de boîtes (une version restreinte des bigraphes) ce qui en fait de l'informatique ubiquitaire et de l'intelligence ambiante.
C'est dit explicitement à propos des bigraphes :
Selon Joel de Rosnay ce serait alors du web 4.0.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Techniquement parlant ERic ne supporte pas les bigraphes à 100%.
Un bigraphe c'est un peu comme une pièce d'un grand puzzle, c'est une petite image insérable dans la grande image.
Pour l'instant (et pour encore longtemps) ERic n'est pas capable de :
• Trouver (ou fabriquer) la (ou les) pièce manquante dans un puzzle entier.
• Reconstituer un puzzle entier en assemblant autant de pièces que nécessaire.
Toutefois ERic supporte très bien la subsomption sur les bigraphes
On aurait tous les avantages du web sémantique (avec les graphes de boîtes en bonus).
Par contre on n'aurait pas les côtés componentiel et ubiquitaire des bigraphes.
Mais pourquoi diable veulent-ils tout mixer avec du Java.
Ça leur ferait mal un programme monolingue en Erlang ou en OCaml.
Parce que le Java c'est plus simple ?
Parce qu'il faut rajouter des failles et consommer plus de mémoire là où on en avait pas besoin
C'est exactement ça.
Suite à la discussion Maman raconte moi une histoire je viens de reconsidérer ma documentation ERic 0.2 à la lumière de The Art and Science of Writing publié par l'INRIA.
Et j'ai TOUT faux. J'ai commis toutes les erreurs possibles.
Petites erreurs :
• Au moins une personne a cru (à tort) qu'il y avait (ou qu'il y aura) un raisonneur artificiel alimenté par des graphes. À ma charge de montrer qu'ERic a son utilité même sans raisonneur.
• J'ai écrit en français alors qu'une documentation technique doit être en anglais. Je l'ai fait parce que le projet est hébergé sur un site francophone mais à posteriori ça n'interdisait pas une documentation en anglais. Par contre le français me barre l'accès à des dépôts/forges-logiciel plus internationaux.
• J'ai rédigé en HTML pour une meilleure visibilité sur le butineur. Alors qu'une documentation technique doit être en pdf pour être imprimable. C'est essentiel en particulier dans les administrations : on peut toujours y sortir un papier, mais jamais un eeePC 701.
• J'ai exposé un méta-modèle. Ça n'a d'intérêt que pour le concepteur. Pour le lecteur c'est juste une nouvelle source de complexité/d'interrogations.
Grosses erreurs :
• J'ai oublié de rédiger a convincing story. À la place j'ai montré comment une phrase en langage naturel peut se décomposer grammaticalement, ce que n'importe quel élève d'école primaire sait faire, et qui ne produit aucune information.
• J'ai rédigé une sorte de journal de bord : à chaque extension du logiciel j'ajoutais un chapitre. Ça n'a absolument aucun intérêt pour le lecteur. Les entreprises achètent des solutions, pas des technologies. Si la documentation doit aller crescendo ça n'est certainement pas sur du featurism mais plutôt sur la complexité des problèmes qu'ERic pourrait résoudre.
• On m'a dit sur IRC qu'on ne voyait absolument pas à quoi ERic pouvait servir. C'est sans doute dû au fait que l'élégance de ma solution m'a davantage enthousiasmé que le problème associé. D'où le sentiment pour le lecteur qu'en fait il n'y a pas de problème associé. Or une entreprise n'achète des solutions que si elle est confrontée au problème associé.
• J'ai trop insisté sur la subsomption. C'est stérile. Je n'ai pas mis en lumière les synergies possibles entre la subsomption, la fusion et les graphes de boîtes (qui sont arrivés trop tardivement).
Ceci dit je ne me fais pas trop d'illusions. Je ne suis pas le seul à élaborer ce genre de logiciel et d'après ce qu'en dit la communauté c'est particulièrement difficile à vendre. Mais bon, quitte à le faire, autant le faire bien et mettre toutes les chances de mon côté.
Au pire je pourrai devenir consultant...
Aujourd'hui, j'ai passé mon aprem sur des graphes pour programmer des automates. J'ai pensé à ERic.
On devrait pouvoir faire des automates basés sur les graphes de boîtes.
Si tu en fais un :
• poste-le dans ce fil.
• tente de répondre à la question : en terme de calculabilité, que signifie la subsomption entre 2 automates basés sur les graphes de boîtes ?
Pendant ce temps moi je m'arrache les cheveux avec la BPMN 2.0.
Dans l'espoir d'exposer des exemples plus business oriented.
Vu que la BPMN 2.0 c'est du FlowCharting on est occupés à des activités très similaires
EDIT: j'arrête la BPMN 2.0.
À la place j'adopte une approche moins sémantique et plus algébrique.
J'essaye d'identifier de nouvelles opérations, possibles grâce aux graphes de boîtes, et qui permettraient de prolonger les capacités d'ERic.
(la théorie dit qu'il n'y en aurait aucune, mais bon... ça m'empêche pas de chercher)
J'ai trouvé 3 opérations spécifiques aux graphes de boîtes :
• envelopper une boîte dans une boîte-contexte
• retirer une boîte de sa boîte-contexte
• échanger la boîte-contexte contre une autre boîte-contexte
Ces 3 opérations étaient déjà possibles sur une relation (ajouter, retirer, échanger). La théorie avait raison : mes opérations sur les graphes de boîtes correspondent en tous points aux opérations sur les graphes non imbriqués. Du coup ça laisse peu d'espoir pour un killer-example plus convaincant que le tutoriel actuel.
Sinon pour mon business plan j'ai choisi l'option terre-à-terre. C'est tellement plus concret que BPMN 2.0.
Après avoir lu Why concatenative programming matters j'ai prototypé une notation alternative pour les graphes Entités/Relations.
Ainsi, ce graphe de boîtes :
Qui se notait comme ceci :
Pourrait éventuellement se noter comme ceci :
Où
[xxx]empile une boîte carrée,(xxx)connecte les 2 boîtes carrées en tête de pile, etrotNdéplace leN-ième élément vers la tête de pile.Les variables ont disparu. Elles ont été remplacées par l'instruction
rotN.Avantages de cette nouvelle notation :
Inconvénients de cette nouvelle notation :
Où est-ce qu'on peut trouver la dernière spécification de la syntaxe d'ERic ?
La syntaxe est trop simple pour mériter une formalisation.
Voir la documentation en ligne.
Les graphes n'apparaissent que dans les commandes join et select.
Un graphe est une liste de triplets entité relation entité.
Parfois, pour améliorer la lisibilité, le triplet est parenthésé (entité relation entité).
Une relation est juste un nom.
Pour les entités c'est détaillé au chapitre 6.
Les extensions documentées :
- Les nombres réels flottants en tant que référent, voir chapitre 27.
- Dans une commande select une relation peut être niée grâce au caractère ~, voir chapitre 28.
La seule extension non documentée :
Dans une commande select il est possible de forcer deux entités à être distinctes à l'aide de la relation =/=.
Les graphes de boîte :
Il y a cette notion de graphes de boîte, voir chapitre 29.
Est-ce que ça complique énormément les choses par rapport aux graphes "ordinaires" ? Hé bien curieusement non, pas le moins du monde