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
Maintenant convaincre la rédaction de DVP c'est une chose. Faire vivre le projet c'en est une autre. Surtout qu'avec mon intitulé je suis à la frontière entre la théorie des graphes et le test de Turing. C'est donc un peu attrape-tout. Je m'attends à voir des gens passer, poser des questions, demander plus de ressources, et puis finalement repartir sans rien avoir contribué, même pas en retour utilisateur. Ertaï est habitué à ça (donner plus que recevoir) mais pas moi, ça va me faire un choc culturel. Il va falloir convaincre et fidéliser. Et bien sûr ERic n'est pas tout à fait le seul logiciel dans sa catégorie. Il y a de la concurrence. Je vais devoir faire de la promotion. Comme un vendeur de lessive.
Le forum DVP de discussion du projet ERic est maintenant actif.
Vous y trouverez toutes les informations pour installer / utiliser ERic v0.2a
Yeah, trop bien ! \ô/
*découvre la signature de SpiceGuid*
Yeaaaah, trop bieeeen ! \ô,ô/
*va bouquiner ces articles*
Bilan provisoire
Presque une semaine après le lancement du projet.
J'ai utilisé à peu près tous les canaux de communications raisonnables, c'est-à-dire sans en faire trop, quitte à ne pas en faire assez.
Pour l'instant :
Le dernier point est le plus pénible car ERic est un projet que j'aimerais bien poursuivre. Les possibilités d'extension sont multiples mais (à partir de maintenant) elles peuvent s'exclure mutuellement. J'entrevois quatre issues possibles :
Ou bien cinquième option : le projet est mort-né
J'aimerais connaître la bonne réponse à ton choix d'issues, malheureusement je crois que je serais dans la même incertitude si je me retrouvais dans le même cas que toi.
Je pense quand même que j'essaierai de rendre mon programme extensible génériquement. Comme tu peux décider du niveau d'imbrication des extensions dans ton programme principal, tu peux choisir le niveau de complexité ajouté.
Et si tu te retrouves trop limité par une de tes propres extensions, alors rien ne t'empêche de revoir le système d'extension.
Comme l'inaction commençait à trop me peser je viens d'opter pour la requête au(x) gourou(s).
On va bien voir ce que ça donne. Même si un gourou ne se sent pas concerné il a toujours autour de lui une kyrielle d'étudiants/doctorants qui se feront un plaisir de m'expliquer comment ERic est laaaaaaaaaaargement améliorable.
En attendant qu'une féministe du forum (Daenerys es-tu là?) me donne le féminin de gourou (oui j'ai cherché dans un dictionnaire, gourou n'a pas de féminin, c'est carrément sexiste) on va dire que j'ai contacté la Grande-exécutrice des Graphes-conceptuels.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Guilde : Graphes-conceptuels
Rang : Grande-exécutrice
Faction Préférée : Graphes-biparti
Résidence Préférée : Subsomption, raisonnement automatique
Rôle : Grande-ordonnatrice
Familiers et montures : C++, Java
Un bisou de chameau baveux
pour celui ou celle qui trouvera le nom IRL de la Grande-exécutrice des Graphes-conceptuels. Envoyez vos propositions par MP.
Et vu que ma documentation est 100% en français ça me limite pas mal le nombre de contacts possibles à l'étranger. Donc on va dire qu'il ne me reste plus que 3 options d'évolution. D'autre part je n'ai toujours aucun utilisateur (déclaré) ce qui fait d'ERic un parfait inutilitaire en puissance. Si je ne me bouge pas dans quelques semaines ERic sera un projet zombie. D'ailleurs developpez.net met en archives les projets sans actualité quand le forum est sans activité (sachant que le mien est carrément vide
ça se présente mal).
Fausse bonne idée : faire une interface graphique.
Pourquoi c'est une mauvaise idée :
Vous pouvez à présent consulter la documentation en ligne.
(@TSG attention ça pique les yeux
)
Juste deux images pour vous montrer l'expressivité d'ERic.
Après si vous préférez UML c'est votre droit le plus entier
Après presque 1 mois d'errances ERic a enfin une (modeste) feuille de route vers la version 0.2b :
Un nouveau type de base: les nombres réels flottants.
Deux annotations pour mieux documenter les relations :
La barre verticale symbolise un miroir, elle sépare un couple de relations inverses comme
L'encadrement par un tiret symbolise une relation réciproque (bidirectionnelle) comme
Ce que j'ai appris pendant ce mois d'inactivité
J'ai compris qu'il n'y aurait pas d'extension miraculeuse pour rendre ERic plus "intelligent". À partir de maintenant tout ce que j'ai à faire n'est plus que maintenance, documentation, ergonomie, interface graphique, client/serveur,...
En résumé, même s'il reste encore à faire quelques morceaux assez consistants, la matière principale est déjà là. Tout le reste n'est qu'extensions d'un proof-of-concept vers un logiciel complet/efficace/convivial. Est-ce vraiment ce que je souhaitais au départ ? Pas vraiment. Tout en sachant qu'il y avait bien une limite indépassable, je m'étais bercé d'illusions en fantasmant une escalade d'IA toujours plus sophistiquées. En fait d'escalier il ne me reste plus que deux ou trois marches à gravir avant d'arriver à un "plateau" d'intelligence. Tant pis pour la "créativité orgasmique". J'ai fini de m'amuser. Cette fois-ci j'ai vraiment décidé d'aller jusqu'au bout, c'est-à-dire un logiciel utilisable avec comme but ultime la viabilité commerciale. Pas seulement un programme pour me faire plaisir mais pour une fois un programme socialement utile (enfin j'espère).
Si j'arrive finalement à faire de la recherche appliquée en OCaml sans mourir de faim et de froid, ce sera déjà pas si mal.
Quant à ceux (ici ou là), que je suspecte de vouloir faire de la recherche fondamentale, je dis ceci : regardez encore une fois Spiderman II
Premier problème avec l'extension aux nombres réels flottants.
ERic dit que 2.21 GigaWatt ça n'est pas la même chose que 2210 MegaWatt ou que 2.21e9 Watt parce que :
En fait le problème existait déjà avec les entiers : 1000 Meter ≠ 1 KiloMeter. C'est juste que je m'en rends compte que maintenant.
Peut-être une gestion différente des unités pourrait résoudre ce problème... En eux-même, les concepts "Megawatt" "Gigawatt" "watt" sont les même, un unique concept "watt" avec un préfixe "mega" ou un préfixe "giga" ou préfixe "rien du tout"...
http://fr.wikipedia.org/wiki/Pr%C3%A9fixes_du_syst%C3%A8me_international_d%27unit%C3%A9s#Pr.C3.A9fixes_courants
Le principe est là, tu as le concept "GigaWatt", tu peux y reconnaître "Watt" avec un préfixes "Giga", or, si ton concept "Giga" existe déjà et indique à l'IA qu'un "Giga-{quelque chose}" équivaut à un "1000000000 x {quelque chose}", elle pourra identifier que ton "2.21 GigaWatt" est la même chose que ton "2210 MegaWatt" ou même ton "2210000000 Watt".
Dans ta langue simplifié du monde de l'entité-relation, il est peut-être temps d'introduire des suffixes et préfixes pour nuancer relations, concepts et référents, apportant peut-être un petit plus "d'intelligence"...
Beschrelle a écrit :
Je lance l'idée comme ça, mais fondamentalement ERic est limité par la richesse de son vocabulaire, l'introduction de préfixes et de suffixes suffisamment bien pensés pourrait aisément multiplier les possibilités de son vocabulaire par simple combinaisons...
(Simple idée en l'air qui me passe par la tête, c'est toi qui fait ce que tu veux...)
Après, sur l'interface client-serveur, y'a quelque chose de (très) rudimentaire à l'aide de deux sockets qui rendrait ERic utilisable dès aujourd'hui :
C'est fortement archaïque, mais pour un premier pas vers l'utilité, c'est déjà considérable. Après, je dis pas ça en désintéressé, à partir de ce système simple, il est aisé de concevoir quelques fonctions PHP pour interfacer un site web avec un ERic.
(Non, je ne suis pas objectif, simplement de passage)
P.S. : Nanaaaan, la recherche fondamentale, c'est devenu bien loin de mon orientation, un peu de sérieux, que diable !
De t'intéresser à mes petites misères informatiques.
Un système de préfixes / suffixes, j'y avais pensé.
Alors pourquoi est-ce que je ne le fais pas ?
Parce que l'intelligence ce n'est pas seulement l'expressivité. Il y a un compromis à faire entre expressivité et computabilité. Quand tu augmente l'expressivité générale tu diminue la computabilité générale. Or le critère qui compte vraiment c'est la computabilité. Il ne sert à rien de pouvoir tout exprimer si tu ne peux plus rien calculer.
Ceci veut dire que pour retomber sur mes pattes je devrais :
D'autre part la question des préfixes / suffixes est plus générale, avec les concepts Much et Little on peut dériver Too-Much, Too-Little, Very-Much, Very-Little, So-Much, So-Little, How-Much, How-Little, ...
En IA, tant qu'on a pas une solution générale pour le problème général, il vaut mieux ignorer les petits ennuis particuliers. Sinon on multiplierait les rustines jusqu'à détruire toute possibilité de calcul. Et c'est très vite fait car la calculabilité n'est pas universelle, elle n'est pas la règle, elle est l'exception. Bref elle est fragile, il faut la préserver à tout prix.
Si la langue du monde de l'entité-relation est simplifiée, et même simpliste, c'est justement à dessein. Ça n'est pas pour le plaisir de se brider. Le plus important c'est que les limitations soit bien documentées pour que l'utilisateur n'ait pas de mauvaises surprises au dernier moment.
PS: je suis vraiment désolé pour l'absence de chaussettes, si tu veux tu peux aller sur le forum et créer un fil de protestation "On se gèle les pieds, on veut des chaussettes!"
Ou, encore mieux, tu peux contacter les chameliers du SdZ (il y en a tout plein dans autres langages) et leur proposer d'ajouter des chaussettes.
ERic v0.2b : Fait
Il va me falloir une nouvelle feuille de route
Préfixes / Suffixes
ERic possède déjà certaines relations destinées à élargir le champ d'usage de certains concepts. Par exemple ERic n'a pas besoin du suffixe -ment parce que ce suffixe sert à construire des adverbes. Or ECO possède déjà la relation Manner, en français façon ou manière, qui sert précisément à construire des adverbes.
Par exemple on ne peut pas dire "agir illégalement", mais on peut dire :
On ne peut pas dire "un chat peureux", mais on peut dire :
Autant que possible ERic + ECO remplacent les préfixes / suffixes par des relations appropriées qui font sens pour lui et pour son algorithme de subsomption.
C'est tout le principe du modèle Entités/Relations, on créer un langage artificiel aussi riche que possible mais avec un vocabulaire aussi réduit que possible comparativement à un langage naturel.
Les unités de mesure
Il y a là une exception. Sans doute parce que le système de mesure n'a rien d'un langage naturel puisqu'il a été conçu après des siècles de sciences. J'ai étudié la proposition de Sbirematqui pour que 1000 Meter = 1 KiloMeter et je l'ai amendée pour la rendre compatible avec le reste du système à l'aide d'une extension minimale.
Modification n°1
Micro, Kilo,... ne sont pas des préfixes de Meter, Watt,... mais des suffixes des nombres réels. Par exemple au lieu d'écrire 1.e3 on peut écrire 1. Kilo, au lieu d'écrire 1.e-6 on peut écrire 1. Micro. Donc essentiellement il n'y a plus du tout d'extension, il n'y a que la possibilité d'écrire en lettres ce qu'on pouvait déjà écrire en chiffres. Or pas d'extension du tout c'est justement l'extension que l'on recherche.
Modification n°2
Il y a exclusion entre les nombres réels et les autres référents. En particulier il n'y a plus de risque d'avoir à comparer des réels avec des entiers. Les concepts ordinaires acceptent tous les référents ordinaires (dont les entiers) mais pas les réels. Au contraire, les unités de mesure sont déclarées à l'aide de crochets et d'un point comme [.Meter], [.Gram], [.Watt] et leur référent ne peut être qu'un nombre réel précédent l'unité au lieu de suivre le concept. Ainsi on a [1. Kilo Meter] mais on ne peut pas avoir [1. Kilo Apple] dont on ne saurait pas s'il s'agit d'1Kg de pomme ou bien de mille pommes.
Modification n°3
Toute unité a un super-type qui indique de quoi l'unité est la mesure.
C'est essentiel pour pouvoir utiliser une proposition quand on ne connaît pas la quantité exacte.
Conclusion
Tous les problèmes de mesure ne sont pas résolus pour autant. Par exemple il reste à étendre le système de requêtes pour pouvoir filtrer les réponses selon des critères quantitatifs (au dessus d'un minimum, au dessous d'un maximum, à l'intérieur d'un intervalle). Ce genre de filtrage serait également intéressant sur les dates (avant, après, pendant une période).
Une autre limitation mentionnée dans la documentation concerne l'absence de négation. Une forme restreinte de négation (appelée graphes polarisés) pourra néanmoins être ajoutée sans perturber l'équilibre du système.
Il y a également la possibilité de créer des "contextes" en imbriquant les graphes ER (un graphe ER est alors le référent d'une boîte-entité). Cependant on n'obtient pas forcément toute l'expressivité qu'on pourrait attendre d'un modèle in-the-box / out-of-the-box.
Je viens de m'inscrire
À la mailing-list cg@conceptualgraphs.org
En parcourant la (maigre) archive de la liste je constate la quasi-absence de marché US pour du logiciel entités/relations, c'est typique du domaine de l'informatique appliquée, le buzzword c'est ce dont tout le monde parle mais que personne n'utilise.
Au début je pensais qu'il n'y avait qu'un simple problème d'absence interface graphique et de capacité multi-utilisateurs mais apparemment la résistance/réticence va bien plus loin que ça.
En recoupant avec d'autres sources d'information j'en conclus que :
2.0, 3.0, ++ ce que vous voulezAu total c'est assez démotivant
Si tu as une offre, mais pas de demande, il faut créer une demande artificiellement. Le moyen le plus direct serait une poignée de démonstrations techniques alléchante, tu dois donc trouver des domaines d'application qui intéressent les gens et proposer des démonstrations interactives conçues pour toucher un public au plus large. Créer sa niche, en quelque sorte. :3
Tu sais ce qu'on dit : dans chaque niche il y a un chien méchant.
Je n'ai plus qu'à construire ma niche et ensuite "tu les manges mes croquettes ou je te mords les fesses". Bref, aller chercher la croissance avec les dents (©Sarkozy 2007).
Mise à jour mineure de 0.2b vers 0.2c (ECO étendue, plus d'unités SI, pas de nouvelle fonctionnalité).
La poupée qui dit "non"
La prochaine version ERic v0.2d implémentera la négation atomique (et non, TSG, ça n'est ni toxique ni radioactif
).
Alors me direz-vous, quelle différence entre la négation logique et la négation atomique
Hé bien la réponse est simple : je vais être obligé de m'atomiser le cerveau dans le seul but de réussir à l'implanter
Et si je survis je pourrai continuer avec des super-pouvoirs algorithmiques renforcés.
Et voilà !
Nouvelle version 0.2d avec négation atomique
Il va y avoir une longue
posepause de brainstorming avant la spécification de la version 0.3aExplications :
Je ne crois pas que j'arriverai à tout faire, mon objectif pour la version 0.3a c'est de résoudre au moins 3 parmi ces 5 points afin d'avancer un peu plus vite.
En attendant vos questions / commentaires / critiques sur la version 0.2d sont toujours les bienvenues
Mon but à moyen/long terme c'est d'avoir une Graph-based DB à visée commerciale.
Pour ça, une fois les 5 points précédents résolus il en restera encore 2 autres :
Et tout ça peut se faire 100% en OCaml
Bon courage pour cette pause
Edit : A propose de base de données en graph, j'ai eu l'occasion de m'intéresser à Neo4j, un système de base de donnée en graph commercial qui est assez populaire, je ne sais pas si tu peux t'inspirer de leur modèle (ou pas).
Tu as notre soutient ! Du moins, le soutient de tous ceux qui ont de petits ponayzs dans la tête quand ils cherchent à saisir la nature de tes méta-capacités d'algorithmique.
Je suis heureux (pour toi) de constater qu'il y a encore une vie après SQL. Tu penses bien que je ratisse large. Alors oui j'ai regardé du côté de Neo4j.
Mais aussi des tas d'autres choses, HyperGraphDB, QGraph, Prometheus et j'en oublie... Ce qui m'a fait la meilleure impression c'est HyperNode/HyperLog. Cependant c'est davantage orienté-objet et moins langage-naturel que mon approche initiale. Il n'y a pas de sémantique logique associée. Mais l'approche objet ne m'est pas du tout étrangère et je n'écarte aucun modèle à priori.
@sbirematqui
Je ne peux pas t'expliquer l'algo de subsomption d'ERic 0.2, pas parce que c'est secret, au contraire c'est du logiciel libre EUPL. Par contre je vais essayer de faire des petits tutoriels pour vous expliquer des choses plus simples mais néanmoins intéressantes.
Comme je le craignais la longue pause de brainstorming est en train de tourner à la dérive. Épisode dépressif, baisse de motivation, manque de perspectives professionnelles, dégoût de la programmation... Je n'ai même pas la force d'installer OCaml 4.0 c'est tout dire.
Bref, arrêt total. Là je vais souhaiter un joyeux anniversaire à Zeami et on reparlera d'ERic plus tard.
les gars pour votre soutient amical.
Pour vous faire patienter avant de dévoiler les nouvelles caractéristiques d'ERic 0.3a, voici un petit tutoriel sur mon algo de reachability en version 0.2
ERic 0.2 possède une double hiérarchie: une pour les concepts et aune autre pour les relations.
Dynamiquement ERic compare les types de milliers de paires de concepts et de paires de relations. La vitesse de comparaison de deux types est donc vitale pour la performance.
L'ordre dans une hiérarchie est un ordre partiel.
Voici comment on compare deux types A et B :
Voici une représentation d'une hiérarchie, une liaison vers la droite est un lien vers un nœud frère, une liaison vers le bas est un lien vers une liste de nœuds fils.
Le nœud A est le nœud sommet. Les nœuds B,C,D sont ses fils directs.
Dans ce cas comparer deux nœuds quelconques est une opération complexe.
Il faut partir d'un nœud et parcourir le chemin qui mène jusqu'au sommet en espérant rencontrer l'autre nœud au passage. Et si ça échoue alors il faut partir de l'autre nœud et parcourir le chemin qui mène jusqu'au sommet en espérant rencontrer le premier nœud au passage. Et si ça échoue encore alors les deux nœuds n'étaient pas comparables !
Bref il faut parcourir l'arbre.
TROP LENT.
Voici la solution de SpiceGuid.
Au départ l'arbre ci-dessus est étiqueté avec des intervalles d'entiers. Comme ceci.
Les nœuds proches du commet ont un intervalle plutôt large.
Alors que les nœuds feuilles ont un intervalle plutôt étroit.
À présent la comparaison entre deux nœuds se fait en temps constant : un nœud A est l'ancêtre d'un nœud B si et seulement si l'intervalle A contient l'intervalle B.
Évidemment l'objectif de la version 0.3a est d'offrir un niveau similaire de performance dans la comparaison de deux nœuds tout en offrant la possibilité de l'héritage multiple. La hiérarchie n'est alors plus un arbre mais un DAG (Directed-Acyclic-Graph).
La solution s'inspirera probablement de la technique générale dite de structural-boostrapping. Cette technique consiste (pour simplifier) à se baser sur un TAD incomplet (ici mon arbre étiqueté avec des intervalles) pour construire le TAD recherché (ici un DAG qui résout le problème de reachability). Cette solution devrait donner de bons résultats pratiques puisque plusieurs études chiffrent le nombre moyen de types parents à environ presque 2 pour les ontologies les plus foisonnantes et à peine plus de 1 pour les ontologies les plus arborescentes.
Ça me rappelle les cours d'algorithmie que nous avons pris ensemble avec Aka Guymelef, je me rappelle bien de ce type d'arbre "borné". La complexité réside dans l'insertion et la suppression, mais l'accès ( = recherche ) est ultra-rapide.
Hmmm... Ici il s'agit d'un arbre n-aire (n quelconque), pas d'un arbre binaire de recherche (où n=2 et l'arbre est totalement ordonné). Ici mon arbre est partiellement ordonné et chaque nœud est étiqueté par un intervalle, pas par un simple entier
Ordre partiel
Même avec la page Wikipédia que tu as mise en lien je ne comprends pas bien pourquoi ton arbre est partiellement ordonné ?
Mon arbre est un dendrogramme.
Je vais essayer d'être plus clair que Wikipédia.
Avec un ordre total il n'y a que 2 cas possibles (d'où n=2 pour un arbre qui fait un tri total) :
Un arbre d'héritage est trié selon un ordre partiel, c'est-à-dire qu'il y a 3 cas possibles (il faut un arbre n-aire pour faire un tri partiel) :
Ne sont pas comparables :
Je comprends mieux, merci pour l'explication
Bravo, tu n'as plus qu'à imaginer comment on étiquette chaque nœud avec un intervalle d'entiers
(aide: on fait un parcours en profondeur d'abord)
Qu'est-ce qu'un arbre n-aire ?
Mise à jour mineure vers la version 0.2f
Suite à une visite de nlegriel la relation Attribut a été renommée Attribute et une relation Value a été ajoutée.
Le couple Property/Value constitue une alternative à Attribute :
Interface source avec OCaml.
L'interface source avec Ocalm, c'est quoi ?
Cela signifie que la source est encore plus modulaire (le moteur de subsomption est encore mieux encapsulé). Du coup si tu programmes en OCaml alors tu peux facilement changer la syntaxe de la console interactive.
Par exemple tu peux utiliser un langage pseudo-naturel comme Attempto Controlled English.
Attempto Project
Quelles différences entre ERic et une base de données orientée graphes ?
Les bases de données orientées graphes classiques s'appuient toutes sur un langage à objets. La conséquence c'est que les entités sont des objets et les relations sont des références. Du coup il y a une hiérarchie sur les types d'entités (la hiérarchie des classes) mais il n'y a pas de hiérarchie sur les types de relations. Au contraire, ERic 0.2 possède deux hiérarchies distinctes, une pour les entités, une autre pour les relations.
Deuxième conséquence, plus importante: ERic 0.2 possède la subsomption. Les données sont des graphes. Les requêtes sont des graphes. Les réponses sont des graphes. Avec les autres bases de données, les données sont des objets, les requêtes sont des chemins+filtres, les réponses sont des objets. Il n'y a pas de notion de subsomption. En fait les bases de données orientées graphes classiques ne sont guère plus qu'un moyen de (dé-)sérialisation pour des amas d'objets à charger/sauver sur disque.
La documentation des bases de données orientées graphes affirme que le graphe est la structure de données la plus générale. La documentation d'ERic n'affirme rien de tel. Au contraire. ERic 0.3+ a pour objectif d'offrir une structure de données plus générale que les graphes, les multi-graphes, les graphes bipartites, les hyper-graphes et autres variations ou extensions de la définition d'un graphe.
La plupart des bases de données orientées graphes offrent certains algorithmes classiques comme le plus court chemin d'un objet à un autre, les plus proches voisins vérifiant une certaine propriété... ERic n'offre rien de tel, il ne fonctionne que par subsomption.
Et au niveau des applications pratiques ?
Les origines du modèle que j'utilise prennent racines dans la logique, les mathématiques et la philosophie. Il y a sur terre des personnes suffisamment exceptionnelles pour cumuler les trois compétences. Ces personnes là pensent aux modèles, pas aux applications.
Les applications viennent après les outils qui viennent après les modèles.
Mon ambition c'est de produire un outil qui rende hommage aux génies qui ont pensé le modèle.
J'ai comme l'impression que derrière ta question il y a le soucis de mon sort personnel. Et je t'en remercie.
La vérité sur les applications c'est que jusqu'à présent je n'en connais pas de vraiment convaincante. Au choix on peut dire que j'innove, que j'anticipe, ou bien que je me suicide socialement.
SpiceGuid a écrit :
Je crois que ces trois caractéristiques décrivent bien les génies incompris de leur temps.
Sur le mur tu disais "inadapté".
La première chose que l'on voit ou que l'on pense de moi c'est que je ne travaille pas.
Inadapté mais génial, en tout cas ici tu n'as pas à craindre l'opprobre productiviste.
(In)conscience artificielle
Quelque part sur un site d'informatique un membre enthousiaste d'AG a émis cette idée qu'une conscience artificielle pourrait se résumer dans la formule "je sais que je sais".
Je n'ai pas d'opinion philosophique sur la question. Par contre je pense être suffisamment avancé sur le plan technique pour exprimer artificiellement "je sais que je sais" beaucoup plus aisément que notre gentil membre ne pourra le faire malgré sa bonne volonté évidente.
D'ailleurs je vais le faire pas plus tard que tout de suite.
Voilà c'est fait. On a créé une conscience artificielle (ou pas).
Ce que j'ai exposé sur le site du zéro était une manière de lancer l'émule parmi des gens plus ou moins "normaux", de voir leurs réactions à certains postulats, de voir d'autres avis que le mien de la part de personnes qui n'ont pas déjà un avis fixe.
Après, la discussion qu'on pourrait faire autour de la conscience est longue, j'ai cependant ma propre opinion sur la question, qui pourrait se résumer a fait que la conscience est le fait de se rappeler qu'on a existé, pas de savoir qu'on existe.
En effet, si la conscience était le fait de savoir qu'on sait, de savoir qu'on existe, du moment qu'on acquiert ce savoir, notre conscience devient passée, présente et future. En effet, un savoir que tu utilise en permanence (dès que tu es conscient) ne pourrait s'oublier spontanément, et donc tu peux dès lors énoncer que tu sauras que tu existera, que tu sais que tu existe et que tu as su que tu existe. La conscience serait une demi-droite débutant à l'instant de ta naissance et se poursuivant à l'infini dans le futur. En gros, avec une telle définition, tu serais conscient d'exister à la fois hier, aujourd'hui, demain, dans mille ans.
De façon virtuelle, la conscience serait donc passée, présente et future avec une telle définition, on en convient, c'est absurde. De même, il est difficile d'expliquer les absences de la conscience (le sommeil, le coma... etc) de courtes durées dans le temps, ce serait imaginer un savoir qui *disparaît* au moment de l'endormissement et *réapparaît* au moment de l'éveil.
Si on imagine la conscience comme étant le fait de se rappeler qu'on a existé à l'instant juste antérieur, on éloigne le paradoxe. En effet, au passé, tu peux dire que tu étais conscient car tu te rappelais que tu avais existé, et par récurrence déduire qui tu existe à l'instant juste antérieur à l'instant présent. A l'instant présent (qui certes n'existe pas, mais je raccourcis la disserte en postulant que le présent existe. Puis, c'est mieux compréhensible comme cela), on ne peut prétendre de se rappeler d'une chose du présent (c'est un fait, tu ne peux te rappeler que du vécu), on ne peut être ainsi conscient au futur, car on ne peut énoncer au futur le fait qu'on existait à l'instant juste antérieur sans devoir utiliser l'instant présent, qui lui n'est pas conscient. Nous ne sommes donc conscients que de l'instant de nos premiers souvenirs (ceux de la prime enfance dont on peut difficilement se rappeler, personne ne peut prétendre se souvenir de lui-même à l'instant 0 de sa vie) jusqu'à l'instant antérieur à l'instant présent. De même, le sommeil ou l'excès d'alcool, les moments où notre mémoire ne peut fonctionner, sont souvent associés à une "perte de conscience", conscience qui revient dès qu'on commence à retrouver l'usage de notre mémoire.
Ainsi, la conscience est le souvenir de nous-même, et en rajoutant deux ou trois pages, tu peux aisément aboutir au fait que ce souvenir est la somme successive de tous nos états successifs, les plus anciens n'étant reconnaissables que dans les modifications majeures de nous même et les plus récents étant présents dans leurs détails. Nous sommes la somme de ce que nous avons été, et à chaque instant nous devenons ce que nous allons être lorsque l'instant présent devient l'instant juste antérieur.
Ajoutons encore du blabla empiriste pour enfin comprendre que le souvenir que nous avons de l'instant présent est constitué par les perceptions que nous avons du monde et plus particulièrement de nos interprétations, nous avons donc au final :
Une conscience C qui passe de C{t} à C{t+1} lorsque le E{t+1} (Environnement à l'instant t+1) vient s'y adjoindre dans sa propre interprétation issue de C{t}.
C{t+1} = E{t+1} + C{t}
Ainsi, C{t} est et sera la somme des états antérieurs C{t'} avec t > t'.
Bien sûr, n'oublions pas que la philosophie ne peut prétendre à une vérité scientifique, mais qu'elle fournit juste des voies de réflexions. Il existe évidemment d'autres manières de considérer la conscience.
Pour le coup, tu nous as fait :
C{t} = C{t} (Le fait de savoir ce que je sais, d'être conscient d'être conscient, en ces conditions ce sera vrai pour tous les instants t)
Je te dois des excuses parce qu'en fait la formule "je sais que je sais" n'est même pas de toi.
J'ai essayé de répondre honnêtement. Peut être que j'ai répondu à côté. Selon moi la conscience n'est pas réductible à une simple conscience de soi. Et même si c'était le cas je doute qu'aucune implantation logicielle ne te donne entièrement satisfaction, quelque soit ta définition personnelle de la conscience. Dans tous les cas Haskell est un très bon investissement.
En tout cas j'ai réveillé le fil de discussion.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
L'horaire tardive à laquelle a été rédigé cet article est due à un petit ennui technique.
à Ertaï de l'avoir corrigé au plus vite.
J'en profite pour ajouter que pour fêter le passage de Sbirematqui vers le langage Haskell j'ai décidé de rehausser légèrement le niveau. De façon purement mesquine, juste histoire d'être certain de rester au top
Ne vous étonnez pas si vous ne comprenez pas tout tout de suite, lisez lentement, relisez, et dans quelques semaines/mois/années ça prendra davantage de sens même si ça vous paraît totalement ésotérique aujourd'hui.
L'histoire continue
Ceux qui croient que la mise en parenthèse du projet ERic m'empêche d'alimenter ce blog se fourvoient. Un temps mort dans le développement c'est au contraire le moment idéal pour mieux fixer des idées parfois trop mouvantes. Et quoi de mieux pour fixer ses idées que de les mettre au propre pour les partager. De façon informelle, en français, bien avant de devoir rédiger la documentation officielle et définitive (qui serait cette fois en anglais).
Les pré-requis
Ce tutoriel n'est pas le plus facile de la série sur ERic.
Pour l'assimiler au mieux je ne peux que vous recommander :
la lecture de la documentation officielle d'ERic 0.2f (en français)
éventuellement, la lecture de l'introduction aux graphes-conceptuels par John F. Sowa (en anglais)
Les 4 visages d'ERic
Il y a 4 façons de comprendre et d'envisager ERic en tant qu'un système complet d'information :
comme une représentation graphique du langage naturel
comme une structure de données informatique
comme une modélisation des connaissances
comme une logique diagrammatique
Jusqu'ici on a surtout insisté sur les deux premiers aspects :
Quoique de manière incomplète ERic nous permet d'assez bien rendre compte de la sémantique du langage naturel.
La structure de données de prédilection est le multi-digraphe-étiqueté. On a justifié ce choix par le fait que cette structure de données est familière au lecteur et au programmeur.
On a également donné un méta-modèle d'ERic. C'est dire qu'au moins implicitement on assume une certaine capacité de modélisation.
On n'a pas donné de sémantique logique formellement dérivable d'un graphe entités/relations. Pour ne pas embarrasser le non-logicien mais surtout parce que le programmeur principal est plus à l'aise avec la vision "structure de données". Cependant aux détours de certaines explications on a laissé entrevoir qu'une telle logique était à l'œuvre. De plus on a identifié l'homomorphisme comme la méthode de requête et la subsomption comme la méthode de classification. Il n'y aucune raison de remettre en cause ces choix de mathématique/logique.
Comment améliorer ERic ?
Quelque soit la modification opérée sur ERic elle impactera simultanément les 4 interprétations de façon cohérente.
Avoir 4 interprétations étroitement liées est-il un avantage ou bien une complexité supplémentaire ?
A-t-on l'obligation d'anticiper 4 fois plus et de tourner 4 fois sa langue dans sa bouche avant de changer une ligne de code ?
Heureusement non. Dans le cas contraire ERic serait de fait condamné à la stagnation.
En fait on peut carrément choisir une interprétation, améliorer ERic dans cette interprétation, et l'amélioration se répercutera sur les 3 autres interprétations sans même qu'on ait à y penser.
Mieux: on peut identifier une limitation dans une interprétation et la corriger à l'aide d'une extension dans une autre interprétation. Chaque amélioration se répercute sur les 4 interprétations.
C'est d'ailleurs exactement comme ça que l'on va procéder.
L'homme est supérieur en capacités linguistiques, c'est donc sur ce point qu'on va chercher des problèmes.
ERic est supérieur en capacités de modélisation, c'est dans ce domaine qu'on va chercher les solutions.
ERic 0.2f possède des limitations linguistiques
Dans les deux premier cas on a un complément d'objet direct (un Dieu, une crème-glacée).
Le dernier cas est plus composite. Tom croit à une Proposition qui affirme (Statement) quelque chose. Éva veut une Situation qui décrit (Description) un certain état.
ERic 0.2 ne gère pas cette configuration de façon optimale :
Il n'est pas possible d'exprimer que le marin n'existe pas ailleurs que dans la tête de Tom.
Pire encore: si on demande "une personne veut-t-elle se marier" on aura pour réponse "oui, Éva veut se marier". Sans rien préciser des pensées de Tom. Le problème ici est que le graphe n'est pas assez structuré. Le fait que Tom croit quelque chose n'est qu'une extension du fait qu'Éva veut épouser un marin. Et vice-versa. Il y a des propositions mais il n'y a pas de propositions subordonnées.
Évidemment on voudrait bien remédier à ces déficiences.
On a dit également qu'ERic ne supportait pas la négation. La version ERic 0.2d supporte la négation atomique qui n'a de négation à peu près que le nom. En fait il s'agit juste d'interdire un certain type de lien entre deux entités. On n'a pas de négation générale. Et pour des raisons de logique qui dépassent le cadre de ce tutoriel on n'ambitionne pas d'en avoir.
Modéliser ERic pour améliorer ERic
Comme n'importe quel concepteur de logiciel on va utiliser un langage de conception pour faciliter la re-factorisation d'ERic.
Remarque cruciale n°1: dans ce méta-modèle tous les référents (Name, Integer, String, Reference, Float) sont des types atomiques, il n'y a aucun type structuré.
Remarque cruciale n°2: ce méta-modèle définit le type EntityRelationGraph qui lui est un type très structuré.
Idée: On va simplement ajouter le type EntityRelationGraph dans la liste des référents possibles. De cette façon on pourra avoir des nœuds dont le référent est un graphe entités/relations. Un graphe dont les nœuds peuvent contenir des graphes s'appelle un graphe à hyper-nœuds.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Certains parlent de graphes imbriqués plutôt que de graphes à hyper-nœuds. Moi je préfère graphe à hyper-nœuds parce que sinon on pourrait imbriquer dans les nœuds ou bien dans les arêtes ou bien dans les deux. C'est trop ambigu. Graphe à hyper-nœuds c'est clair : on imbrique que dans les nœuds.
Ceux qui connaissent les diagrammes d'états (StateCharts) ont déjà rencontré des graphes imbriqués.
Conséquences linguistiques
Comme on va le voir cette modification résout le problème des propositions subordonnées.
Par contre cela ne résout pas le problème de l'existence (in)certaine du marin.
On voit que les arêtes Statement et Description ont disparu.
Chaque proposition subordonnée est désormais délimitée par un nœud-cadre.
Désormais le code contient une indentation pour marquer le niveau d'imbrication des nœuds :
Conséquences logiques
Les notions d'homomorphisme et de subsomption deviennent récursives. En particulier les requêtes deviennent récursives. Elles se propagent à l'intérieur des hyper-nœuds tout en mémorisant le contexte externe.
Concrètement lorsque l'on demande "une personne veut-t-elle se marier" on aura pour réponse "oui, Tom croit qu'Éva veut se marier" au lieu de simplement "oui, Éva veut se marier".
Conséquences sur les structures de données
Comme on l'a dit on passe du multi-digraphe-étiqueté au multi-digraphe-étiqueté-à-hyper-nœuds.
Le challenge n'est pas tant dans la représentation de ce type de graphe que dans la façon d'en stocker une très grande quantité tout en ralentissant le moins possible la recherche récursive d'homomorphismes.
Conclusion
On a présenté une solution au problème des propositions subordonnées et ce que cette solution implique sur les 4 interprétations d'un graphe entités/relations.
Le prochain article présentera une solution au problème de l'existence (in)certaine du marin ainsi que ses implications profondes sur la nature algorithmique des graphes-conceptuels.
Une question simple :
Tom croit qu'Éva veut épouser un marin vous trouvez ça plus lisible en multi-digraphe-étiqueté ou bien en multi-digraphe-étiqueté-à-hyper-nœuds ?
Personnellement la direction des flèches à partir des verbes me perturbe. Si la personne Tom croît au thème de Dieu, l'inverse n'est pas forcément vrai, si ? Je veux dire que le thème de Dieu ne croît pas en la personne Tom. Pourquoi mettre des flèches dans les deux sens alors ?
C'est comme en cours de français des collèges.
La phrase est centrée sur le verbe :
le verbe (Believe ou Want) a un sujet (Experiencer)
le verbe (Believe ou Want) a un complément d'objet (Theme)
Où vois-tu 1 flèche dans les deux sens ? Il y a 2 flèches qui partent de la boîte-verbe et elles partent dans le même sens (ce sont 2 flèches sortantes qui sortent de la boîte-verbe).
Si c'est un complément d'objet direct alors il y a une seule boîte-carrée (God ou IceCream).
Si le complément d'objet est une proposition alors il y a aussi une seule boîte-carrée (Proposition ou Situation). Seulement dans ce cas c'est une hyper-boîte (parce que son contenu est plus complexe).
J'ai refait le schéma exprès pour ceux qui ont des difficultés à lire les graphes.
Dans un graphe il ne faut pas regarder l'image. Il faut seulement observer les propriétés de connectivité.
Pour comprendre ERic 0.1 il faut :
savoir lire et écrire un graphe
comprendre ce qu'est un (Wiki) homomorphisme de graphes
Pour comprendre ERic 0.2 il faut en plus comprendre la notion de subsomption de graphes.
Pour comprendre ERic 0.3 il faudra en plus (et entre autres) comprendre la notion d'hyper-nœud.
Je comprends mieux. Je supposais qu'il fallait que la relation aille dans ce sens là :
Mais grâce à ton explication, je comprends mieux le sens des flèches.
Merci SpiceGuid !
C'est linguistique, la phrase (ou la proposition) est enracinée sur le verbe.
Comme à l'école en cours de français, quand on te faisait décomposer grammaticalement
Après la notion d'homomorphisme (autre définition Wiki) est importante, et là j'avoue que je ne sais pas comment le vulgariser. Et plus c'est difficile à expliquer plus c'est difficile à vendre
Sans parler de la subsomption, des hyper-nœuds et de tout ce que je vais encore ajouter dans la version 0.3 
Edit: je dessine toujours les graphes sous MS-Paint et c'est vraiment une corvée
Résumons-nous
Lors de nos précédents arbitrages parmi la grande famille des graphes nous nous étions arrêtés au multi-digraphe-étiqueté-à-hyper-nœuds. C'est le point de départ de cet article où nous achevons notre spécification d'ERic 0.3.
Droit au but
Cette fois je fais fi de la démarche (trop tortueuse) pour vous présenter directement le résultat.
Les hyper-nœuds sont des conteneurs
C'était le credo de l'article précédent. Un hyper-nœud est une boîte fermée hermétiquement. Intérieur et extérieur sont isolés. Chaque boîte contient une donnée. Il suffit de désigner une boîte pour accéder à la donnée qu'elle contient. Éventuellement il y a encore une boîte dans la boîte. Comme des poupées russes. C'est du grand classique de l'algorithmique.
Les hyper-nœuds sont des membranes
Maintenant on change de point de vue. Les hyper-nœuds ne sont plus des boîtes hermétiques. Ce sont des membranes biologiques. Cela fait deux différences fondamentales :
Les hyper-nœuds sont des cadres-contextes. À l'extérieur de l'hyper-nœud on est dans le contexte de l'hyper-nœud parent. À l'intérieur de l'hyper-nœud on est dans un nouveau contexte plus spécifique qui enrichi le contexte parent (celui de l'hyper-nœud parent). C'est plus organique, il y a des systèmes et des sous-systèmes.
Il y a toujours un intérieur et un extérieur mais les échanges sont possibles entre les deux mondes. Le conteneur était un sarcophage. La membrane est une interface. C'est plus organique, il y a des flux qui traversent les parois.
Comme toujours des schémas valent mieux qu'un long discours.
Tom croit toujours qu'Éva veut épouser un marin.
Sauf que maintenant il y a 3 variantes possibles selon l'hyper-nœud dans lequel se trouve le marin.
C'est beaucoup plus précis, n'est-ce pas ?
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Je maudis MS-Paint. Je le hais du plus profond de mon âme. Ça me prends un temps fou de faire ces schémas à la noix. Je préfère de loin la notation textuelle. Dommage que les schémas soient plus lisibles. Parce que pour les éditer c'est un sacerdoce.
Les graphes conceptuels
C'est encore un graphe (ou pas ) ? C'est encore une structure de données (ou pas ) ? On trouve ça dans les livres d'algorithmique (ou pas ) ? Et sinon c'est grave docteur ? Non, ça n'est pas grave. Tout ce dont on a besoin c'est d'une base de données et d'un mécanisme de requête. Et le mécanisme de requête c'est la recherche de tous les homomorphismes existant entre un motif et une collection de données. D'ailleurs c'était déjà le cas avec Eric 0.2. Wikipédia était bien capable de définir les homomorphismes de graphe tout en étant incapable de donner un algorithmique pour les trouver. Ça n'a pas empêché d'implanter ERic 0.2. Ce sera pareil avec ERic 0.3. Si on n'a plus le courage de faire de la recherche en algorithmique alors on changera de projet.
*enfile sa casquette de livreur*
*sonne à la porte de SpiceGuid*
Bonjour chez vous ! C'est vous qui aviez commandé 1kg de motivation ?
Tenez, signez ici.
*tend sa tablette de livreur*
Comment ? Ah ! Oui, vos tartines seront livrées demain. Euh, au fait, j'ai encore de la motivation à livrer, vous sauriez pas où se trouve le "laboratoire gobelet" ?
Ah, il a changé de nom ? Vous pouvez m'indiquer où il est ?
*regarde le bonhomme lego agiter ses bras*
Merci, oui, passez vous aussi une bonne journée.
*remonte dans son camion en lâchant un chapelet de jurons et passe ses nerfs sur son GPS*
Les pizzas motivantes je pense que c'est pour le "laboratoire gobelin"
C'est qu'on la veut notre v8 d'AG et notre v0.3 d'ERic !
Liens trans-hyper-nœuds
Cela fait 3 jours que, à part jouer à l'excellent Scrambled Nations je me pose la question suivante :
Dans mes 3 schémas d'exemple les liens qui traversent le cadre d'un hyper-nœud le font tous dans le sens du nœud courant vers le nœud parent.
Je me creuse la tête pour trouver un contre-exemple. Un graphe qui nécessiterait un lien qui traverse le cadre d'un hyper-nœud dans le sens du nœud courant vers un nœud fils.
Comme je ne trouve pas ce contre-exemple je ne sais pas si mon modèle est complet (tous les liens utiles qui traversent le font toujours dans le même sens) ou extensible (des liens qui traverseraient dans le même sens contraire seraient également utiles).
D'où blocage. Un linguiste (avec une spécialisation en graphes conceptuels) pourrait me débloquer mais je n'en connais pas.
En l'absence de réponse définitive je vais devoir prendre un risque :
Parier que les liens sont uni-sens (quitte à me tromper).
Autoriser les liens dans les deux sens (quitte à compliquer encore plus la notion d'homomorphisme de structure).
Ne pas trancher prématurément (quitte à perdre du temps).
Mon expérience des contextes (informatiques) m'incite à penser que c'est toujours le contexte englobé qui dépend du contexte englobant et jamais l'inverse.
D'autre part les choses sont bien assez compliquées comme elles sont et je n'ai pas davantage de temps à perdre.
Mon seul soucis c'est qu'au cours du développement d'autres questions pourraient surgir et m'amener à multiplier les choix arbitraires de conception. Avec le risque d'un résultat final sous-optimal qui pourrait remettre en question tout le travail. Pour quasiment me ramener où j'en suis, à la version 0.2
De ce que j'ai compris de tes trois exemples, c'est que les liens qui traversent le cadre le font tous pour désigner un concept qui existe en-dehors de ce cadre. Une sorte de référence à un concept indépendant du cadre.
L'inverse, ce serait un concept qui n'existe que dans un cadre et qui y est fait référence par quelque chose en-dehors du cadre.
Est-ce que cet exemple conviendrait :
Le clown n'existe que dans le cadre du rêve d'Eva, mais pourtant Tom qui est extérieur au rêve peut y faire référence.
Oh mon dieu ! C'est pas croyable ! Je n'en reviens pas. Tu es un lecteur très attentif.
J'ai changé ton exemple en "Eva parle du clown du spectacle de ses rêves".
En tout cas toutes mes félicitations
Honnêtement, je n'osais même pas imaginer que quelqu'un me mettrait sur la bonne voie.
En plus j'étais carrément parti pour faire le mauvais choix. Tu viens ni plus ni moins de sauver mon projet
En un seul message de toi je viens de rentabiliser tous mes efforts investis dans cette série d'articles de vulgarisation
Je ne pensais pas que mon petit message aurait une telle portée
Je suis très content d'avoir pu t'aiguiller alors que jusqu'ici je n'avais une compréhension très vague de ton projet
Je vais te donner une seconde occasion d'être très content de ta trouvaille.
Après une semaine de recul je peux maintenant te l'avouer : l'exemple "Éva parle du clown du spectacle de ses rêves" n'était qu'un exemple de transition. Pour que tu reconnaisses l'esprit de ta participation. Et aussi pour ne pas t'embrouiller avec de nouveaux "gadgets" de mon invention.
L'exemple auquel je pensais vraiment c'était : "Éva monte un spectacle de clown", mais un spectacle vu comme un business-plan. Donc Éva doit trouver des fonds pour financer son spectacle, et un interprète pour jouer le clown.
Au niveau de la nouvelle gadgetry, il y a 2 choses :
Une relation peut sortir d'un cadre-contexte puis entrer dans un autre cadre-contexte. Plus généralement, une relation sort de zéro ou plusieurs cadre-contexte(s) puis entre dans zéro ou plusieurs autre(s) cadre-contexte(s).
Un hyper-nœud comme Asset est également un conteneur pour un ou plusieurs (morceaux de) graphes. L'hyper-nœud joue le rôle des collections dans les langages de programmation. Ici l'hyper-nœud Asset collectionne [Capital] et [Man].
Pourquoi "Acting" et "Financing" ne sont pas des verbes comme "Dream" ou "ProspectFor" ?
Il n'y a pas de raison profonde. C'est totalement arbitraire. Ce n'est que du vocabulaire.
[Capital] (Finance) [Show] et [Man] (Act) [Clown] conviendraient aussi bien.
Ma réponse est insatisfaisante et incomplète.
Ta question est une sorte de variante de la question de Aka "pourquoi le verbe est dans une boîte-ronde et pas dans une boîte-carrée (comme on me l'a appris) ?". Elle mérite davantage de commentaire.
Commençons par l'anglais.
Est-ce que dream est un verbe ?
Est-ce que dream est un nom commun ?
À voir. Au cas par cas.
Maintenant Entités/Relations.
Ce qui compte vraiment c'est qu'une boîte-ronde (Relation) relie toujours deux boîtes-carrées (Entités).
À part ça on met le mot que l'on veut à l'intérieur pourvu que ce mot soit présent dans la hiérarchie des relations (la relation Acting est à la ligne 113).
Y-a-t-il une relation univoque anglais ↔ ERic ?
Il n'y en a certainement pas. L'anglais autorise la négation, ERic ne l'autorise(-ra) pas.
Y-a-t-il une relation ERic ↦ anglais ?
C'est loin d'être évident (pour moi).
Au bout du compte est-ce que tout ça n'est pas que de l'enfumage ?
Si on croit qu'ERic est un agent conversationnel alors oui je dirais que c'est de l'enfumage.
C'est plutôt un modèle de BDD orienté linguistique.
Merci de l'explication, en informatique au moins ce genre de graphe fonctionnel possède une légende bien précise, et les formes gardent la même signification non seulement dans le même graphe, mais dans tous les graphes ayant la même finalité, d'où ma question.
À la recherche de l'homomorphisme induit
Maintenant que je tiens une structure suffisamment expressive il me suffit de construire l' homomorphisme induit pour finaliser la construction de ma catégorie.
C'est exactement la même démarche que pour ERic 0.2 où :
ma structure était le digraphe étiqueté
mon homomorphisme était l'homomorphisme de graphes
ma catégorie était la catégorie où les objets étaient des graphes et où les flèches étaient des homomorphismes de graphes
C'est encore tout pareil cette fois-ci. En plus compliqué.
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Je me doute bien que certains membres d'AG doivent se questionner sur l'opportunité de poster ici ce genre de considérations limite ésotériques.
La réponse est simple :
• normalement je devrais le faire sur DVP.com où je suis rédacteur
• sur DVP.com, éditer un message est un calvaire, publier un article est un enfer, et quand bien même je n'ai pas d'avantage de lecteurs attentifs que j'en ai ici
• j'ai un blog sur DVP.com, on me l'a pourri en le passant sous wordpress (disparition de l'en-tête, des paragraphes, des images, des liens, des styles)
• Ertaï, au contraire, a mis en place un système de blog, simple, rapide, efficace, pérenne. Je l'en remercie. Et j'en profite.
Et bien pour une fois que quelqu'un dit du bien d'eZ Publish qui fournit la structure des blogs et l'éditeur de texte riche qui fournit le style, j'apprécie grandement
eZ Publish c'est le bien
Sinon les définitions de Wikipedia.org sont systématiquement écrites comme s'il n'y avait absolument aucune application informatique. Il faut lire entre les lignes. À force d'être généraliste ça en devient pathologiquement abstrait. Des fois c'est à peine si je comprends de quoi ça parle
L'homomorphisme induit on le construit à la main, en imposant les cas de base (image d'une entité, image d'une relation, image d'une hyper-entité,...).
Du coup il y a une certaine liberté dans le choix de l'homomorphisme.
ERic 0.2 utilise un homomorphisme particulièrement "autiste" :
On l'aime EzPublishhh. : D
Pour ma part, je sors d'un module sur l'algèbre générale, et je comprends (enfin) le sens de tous les termes marrants que tu utilise depuis le début du fil...
Je suis bien avancé, n'ayant vu que le côté abstrait et théorique, j'arrive à peine à me faire une idée de ce que ces termes foutent là. Mais bon, je ne soigne.
En tous cas, je commence à saisir un peu mieux le point d'ÉRic, je me rends mieux compte de ce qui a dû être fournit, et même si je reste encore un peu dubitatif vis-à-vis de beaucoup de choses, je ne peux que te dire : Bravo !
Je renouvelle mes encouragements pour ERic !
Moi aussi je suis dubitatif.
J'y crois à peine qu'au bout du compte toute cette cogitation pseudo-savante va déboucher sur un programme exécutable. D'ailleurs j'angoisse à mesure qu'approche le moment de commencer à coder. C'est loin d'être gagné d'avance.
Si l'on comptait en minutes alors cela ferait déjà une éternité que j'ai pseudo-formalisé un homomorphisme induit pour ERic 0.3
Quand j'essaye de progresser plus loin dans la formalisation j'arrive presque au détail d'implémentation, et là je préfère faire confiance à OCaml plutôt qu'à mon intuition. Du coup il n'y a plus qu'à implémenter ERic 0.3 avant de passer à ERic 0.4 qui ajoutera la multiple hyperonymie ( plusieurs super-concepts et plusieurs super-relations au lieu d'un(e) seul(e) ).
Et sinon, qui veut se coller sur le développement du Projet RAMzy?
Je me disais aussi "Tiens, TSG qui poste sur un sujet hautement théorique ?"
ERic 0⁴ hyper-symétrique
Des fois je m'ennuie dans l'après midi. Normalement sur France 5 il y a deux documentaires scientifiques dans l'après midi. Un avec des dinosaures en images de synthèse qui chassent d'autres dinosaures en images de synthèse. Celui-là je ne le regarde pas. Le second est un documentaire sur le cosmos. J'en regarde un de temps en temps. On y apprend que chaque particule possède son antiparticule symétrique. Et pour aller plus loin dans la cosmologie on nous parle même de super-symétrie. C'est fascinant d'élégance quand on sait que tout ça est complétement abstrait et entièrement basé sur la théorie des catégories (voir par exemple Introducing categories to the practicing physicist).
À mon tour maintenant, car après tout ERic est lui-aussi basé sur la théorie des catégories.
J'ai déjà les boîtes carrées et les hyper-boîtes carrées. J'ai aussi les boîtes rondes.
Attendez une minute ! Tout cela manque de symétrie !
On va ajouter les hyper-boîtes rondes ! Et voilà, on a une structure hyper-symétrique
Qu'est-ce qu'une hyper-boîte ronde ?
C'est une boîte ronde qui contient un graphe Entité/Relation.
Et à quoi ça sert ? À construire des relations plus sophistiquées. Que l'on ne pourrait pas exprimer rien qu'à l'aide du vocabulaire des relations de base. Bien entendu on aurait des hyper-liens qui pourraient entrer et sortir des hyper-boîtes rondes et des hyper-boîtes carrées à des niveaux d'imbrication hyper-arbitraires.
Et quel serait l'homomorphisme induit ? Le même que celui d'ERic 0.3, il suffirait, dans la définition, de remplacer carré par rond, et rond par carré. On resterait en terrain connu
C'est pas un peu abstrait ?
Il n'y a pas si longtemps un Programmeur Hautement Performant m'a soufflé une Phrase Hyper Pénétrante. Et d'un coup d'un seul, ce qui n'était qu'un gadget largement hypothétique est devenu une nécessité absolue. Alors donnez moi une raison, une seule, un exemple, un seul, et je passe dès aujourd'hui au modèle hyper-symétrique. Au boulot les Ertaï, les Luminox et les Sbirematqui, je compte sur vous !
Désolé pour la faute, en anglais on écrit Attribute au lieu de Attribut.
Dans cet exemple il y a un lien entrant dans une hyper-boîte ronde mais pas de lien sortant. Cependant à quoi bon chercher un exemple ? Du moment qu'on peut sortir d'une hyper-boîte carrée pourquoi pas d'une hyper-boîte ronde ? L'interdire serait d'ailleurs plus compliqué que de l'autoriser.
Je saute la version 0.3, je vais passer directement à l'implémentation de ERic 0⁴, la version hyper-symétrique
Bon, si il faut chercher...
Le juge a prononcé la dissolution du mariage d'Alice et Bob par consentement mutuel, ce qui cause qu'il y a eu partage des biens, ce qui fait qu'Alice ne peut plus dépenser aux frais de Bob.
Bref, je n'ai pas trouvé mieux dès potron-minet.
Pauvre Alice, espérons qu'elle a un amant fortuné
Il y a plus simple pour créer des liens sortants : au lieu d'un "consentement mutuel" je mettrais 2 consentements, le consentement d'Alice et le consentement de Bob. Ça ferait un lien sortant vers Alice et un lien sortant vers Bob.
Mon problème n'est pas là. Mon problème du moment c'est qu'en fait je pourrais exprimer la même chose avec une boîte carrée "Mariage" au lieu d'une boîte ronde "SpouseOf". Et dans ce cas il n'y aurait même plus besoin d'hyper-boîte ronde, une hyper-boîte carrée ferait l'affaire
Je ne peux pas le prouver mais j'ai l'intuition que l'hyper-symétrie est redondante. Cependant :
Pour l'anecdote, d'après ce que j'ai entendu dire, avec le mariage homosexuel les mariés s'appelleront marié(e) n°1 et marié(e) n°2.
Je le dit ouvertement, si ça n'était pas assez explicite, ERic n'a qu'un lointain rapport avec un langage naturel. Le but est davantage le développement d'un modèle pour le monde et la conscience. Un langage naturel au contraire n'est pas un modèle mais un moyen de communication, pas du tout universel, développé empiriquement et en évolution constante.
En y réfléchissant bien (la nuit) l'hyper-symétrie n'est envisageable qu'avec un modèle de graphe biparti (anglais).
Par conséquent, et contrairement aux apparences, l'hyper-symétrie n'est pas du tout dans la lignée d'ERic 0.2 et 0.3, ça n'a plus rien à voir autant en terme de structure qu'en terme d'homomorphisme.
Du coup j'abandonne cette piste qui aurait pu être enrichissante si au départ j'avais fait le choix des graphes bipartis.
Il n'empêche que ça valait le coup de consacrer 2-3 jours à étudier cette option. Histoire de ne pas avoir à le regretter plus tard.
La méthode de développement zéro défaut
ERic a été conçu selon une méthode de développement qui garanti le zéro défaut.
Cet article a pour but de vulgariser les cinq points clés de cette méthode.
Afin qu'elle se démocratise et que vous puissiez en bénéficier pour vos propres développements.
Je ne comprends rien à la source.
C'est normal. La source d'ERic est en OCaml. Seuls des chameaux expérimentés élevés dans un profond désert sentimental peuvent interpréter l'odeur de la pisse de chameau. Les autres seront victimes de mirages et autres hallucinations. Ils finiront par se perdre dans une étendue sableuse interminable. Ils agoniseront dans d'atroces souffrances, sucés par d'ignobles insectes, traqués par les serpents et les scorpions.
Où est le Bug-Tracker ?
La mauvaise nouvelle c'est qu'il n'y a pas de Bug-Tracker.
La bonne nouvelle c'est que, comme il y a zéro défaut, il n'y a pas besoin de Bug-Tracker.
J'ai trouvé un bug, que dois-je faire ?
Votre cerveau de primate a cru déceler un bug dans la dernière version d'ERic. Ou même dans une ancienne version. Peu importe. Ce qui importe c'est de vous rappeler que vous n'êtes qu'un primate. La réponse d'ERic est difficilement interprétable par votre cerveau de primate. Ou bien ERic n'a pas donné de réponse. Parce que vous lui avez posé une question de primate. ERic est un peu hautain, il n'aime pas trop dialoguer avec de simples primates. Les deux paragraphes suivants traitent ces deux cas séparément.
Je ne comprends pas la réponse d'ERic.
Soumettez vos données, votre question, et la réponse qui vous a été faite. Un chamelier se chargera de tenter d'éclairer votre cerveau primitif.
ERic ne me répond pas.
Soumettez vos données et votre question. Un chamelier se chargera de les reformuler dans un langage plus évolué.
Je devrais sans doute mettre les choses au clair
Avant que Cathaseris ne me tombe dessus à bras raccourcis, à juste titre
•
je n'habite pas la planète des singes
• Le seul secret du zéro défaut c'est le zéro utilisateur
• Une seule personne qualifiée (DEA informatique) a un peu testé ERic. Son verdict :
nlegriel a écrit :
Alors pourquoi ce billet provocateur ?
Les plus avertis d'entre-vous l'auront compris : c'est une parodie de discours méthodologiste.
Il y a plein de gens qui veulent vous vendre des recettes miracles pour éradiquer les bugs.
Ils n'ont qu'un seul but : détourner votre attention pour vous faire renier votre expérience.
Ne reniez jamais votre expérience, c'est votre bien le plus précieux, c'est votre valeur-ajoutée sur le marché du travail. Sans votre expérience vous ne seriez rien. Rien d'autre qu'un pantin dans les mains d'un gourou méthodologiste.
Amen.
Merci pour le billet, garde couraj pour la suite ! On est derrière toi !
Les premières lignes de code
Pas fâché d'abandonner Microsoft-Paint
Alors tout est là, on a les diagrammes, on construit un diagramme à partir du diagramme vide (empty), en ajoutant un par un les entités (avec extend) et les relations (avec connect). On peut envelopper un diagramme dans une hyper-entité (grâce à EntityD).
On peut interroger un diagramme (avec select).
Ça compile bien.
Encore une victoire éclair du langage chameau
Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)
Après on peut aussi faire de vrais programmes qui font vraiment quelque chose
Mais c'est plus difficile
Il faut affronter la réalité en face.
Cela fait 1 semaine que je tente vainement d'entrer dans une dynamique de productivité. Entre fatigue psychologique / épisode(s) dépressif / problème difficile, si je laisse filer je risque de perdre des mois à rêvasser que je "conçois" tout en ne produisant rien du tout.
Dans l'immédiat je vais jouer mes atouts :
j'ai une licence compatible OSI
j'ai une base de code, petite et de grande qualité
j'ai une assez bonne documentation (en français)
Par conséquent ERic 0.3 ferait un excellent projet de fin d'année pour un étudiant motivé.
Évidemment je vais encore faire choux-blanc mais qui ne tente rien n'a rien
Le texte de mon appel à contribution.
Je te souhaite de trouver un sympathique collaborateur, et vu le niveau d'abstraction, l'université est sans doute le seul endroit où tu pourras trouver un tel collaborateur
Moi, une relation avec toi, dans tes rêves !
Dans la documentation d'ERic 0.2 j'ai commis 2 erreurs, à savoir dire :
Deux affirmations à cause desquelles j'ai dû rembarrer un utilisateur potentiel qui commençait à s'enthousiasmer pour mon projet. Il s'en est allé poursuivre ailleurs sa quête chimérique d'une Imbécillité Artificielle.
Avec ERic 0.3 je vais rectifier le tir :
Selon mes estimations cet étalage de volapük épistémologique devrait suffire à éloigner la plupart des importuns.
Alors je devine votre objection : dans entités/relations il y a relations.
Point d'entité sans une relation.
Que nenni dis-je.
Preuve à l'appui. Grâce aux hyper-nœuds
La nuit tous les chats sont gris
Le paragraphe précédent était initialement destiné à introduire, avec un certain humour, la problématique de la quantification universelle. Malheureusement des incertitudes pèsent encore qui retardent ma rédaction sur ce sujet. D'autant plus que depuis ma désillusion sur les Rubik's cubes j'ai tendance à devenir plus précautionneux.
Griiiiiiiis.
En fait il ne sera même pas possible d'affirmer que la nuit tous les chats sont gris.
Les détails gores de mon investigation
Par contre il est bien heureusement possible d'affirmer que tous les chats sont des félins.
Et d'obtenir des conclusions en conséquence.
Dans ce cas on peut parce que c'est inconditionnel (toujours vrai).
Raisonnement en langage naturel
On m'a fait plusieurs fois la remarque : pourquoi ne pas modifier ERic pour lui permettre de raisonner en langage naturel ? À chaque fois j'ai répondu que c'était hors de question, mais un comme un autocrate, sans argumenter davantage ma décision. Cette fois je suis décidé à vous convaincre de la vanité de ce genre de requête. Par l'exemple. Plutôt que par le mépris.
Langage naturel et raisonnement
D'où viendrait cette fascination pour le mariage du langage naturel et du raisonnement ?
D'après moi elle prendrait racine dans le fameux test de Turing.
Ce fameux test de Turing qui a été démythifié lors du Turing 1990 Colloquium.
L'exemple
Pour les détails techniques je vous renvoie vers ma contribution sur DVP.com
On pourrait m'objecter plein de choses.
Par exemple que l'outil en démonstration a été choisi à dessein afin de discréditer la technique utilisée.
À cette objection je réponds :
On pourrait aussi m'objecter que, bon marché ou pas, les Rubik's cubes sont toujours trop chers. C'est une opinion que je respecte et à laquelle j'adhère totalement. Cependant je pense qu'un outil doit obéir à la loi du moindre étonnement, ce qui n'est clairement pas le cas ici.
On pourrait encore m'objecter qu'ERic n'est nullement à l'abri d'une quelconque incohérence / absurdité / stupidité. Certes. À cela je réponds qu'un langage artificiel est un avertisseur efficace : vous posez une question artificielle à laquelle vous obtenez une réponse toute aussi artificielle. En cela il n'y a pas de mauvaise surprise.
Mes acquis
Par contre au niveau algorithmique tout reste à inventer, à ma connaissance ça n'a jamais été fait auparavant.
Exemples de syntaxe concrète
L'exemple de la création du spectacle de clown :
Les 3 variantes de Tom croyant qu'Éva veut épouser un marin :
Cependant la plupart des spécialistes du domaine s'accordent à dire que l'utilisateur final préfère une représentation graphique plutôt qu'une représentation textuelle.
Or cela fait une différence énorme pour le programmeur :
Les perspectives commerciales
Elles sont minces. De l'avis général le marché n'existe pas, il faut le créer à force de techno-évangélisme. De plus les entreprises ont une fâcheuse tendance à privilégier les standards industriels, même nouveaux, comme OWL-RDF ou BPEL. Elles restent réticentes à la recherche universitaire et encore plus à la recherche privée.
Pour résumer
Je rentrerais dans une phase de développement où je sortirais du fun tout en restant très éloigné de la viabilité commerciale. Ça ne m'enchante pas. Ça serait davantage soutenable si j'avais une subvention ou du sponsor. J'aimerais minimiser le temps de développement contraint sans perspectives de rémunération. Le chemin le plus court c'est peut être un IDE simpliste pour ERic 0.2, ça resterait assez sympathique tout en me procurant un minimum de matériel de démonstration.
Tu parles de perspectives commerciales, de graphes, de relations, est-ce que Eric peut aider à la gestion de problèmes proches de ceux dans lesquels les réseaux bayesiens sont impliqués ? Est-ce qu'un possible rapprochement d'Éric vers les réseaux bayesiens serait intéressant ?
Parce que pour ceux-ci que je nomme, les perspectives scientifiques et commerciales vont en élargissant, et je trouve que la représentation apportée par Eric y serait peut-être pertinente.
Pour ce qui est des perspectives scientifiques et commerciales qui vont en élargissant je dirais qu'on nous a déjà fait le coup avec les fractales, les supra-conducteurs et les réseaux de neurones.
Comme je suis un psychorigide qui
détesten'aime pas les statistiques, je ne m'investirai pas une seule seconde dans les réseaux bayesiens. Disons que c'est une idée que je vais considérer avec un dédain mêlé d'un silence plein de bienveillance.Le modèle de graphe d'ERic 0.3
Par un heureux miracle il est en fait déjà implémenté
Sans même que j'en sois conscient. En fait ERic 0.2 est une sorte d'assembleur pour les modèles de graphe.
L'exemple de la création du spectacle de clown :
[Dream*d] Experiencer [Person Eva*v] [ProspectFor*p] Agent v d Theme [Event*e] [Show*s] Performer [Clown*w] s In e w In e p Theme [Asset*a] [Capital*c] Financing s [Man*m] Acting w c In a m In a.Remarquez la relation a In b qui indique qu'une boîte a est contenue dans une autre boîte b.
J'espère bien faire d'autres découvertes du même acabit qui démultiplient autant l'expressivité d'ERic
Les perspectives commerciales
Comme je l'ai déjà dit c'est à moi de les créer. Pour ce faire il faut que je réécrive toute la documentation du point de vue du client. Quels problèmes ERic est-il capable de résoudre ? Quelles solutions est-il capable d'apporter ? Il faut que j'arrête de modéliser du langage naturel et que je montre comment ERic peut modéliser du business model, de l'analyse SWOT ou de l'organisationnel. En un mot transformer mon gadget algorithmique en un produit consommable par les entreprises / administrations.
Ma nouvelle documentation devra introduire petit à petit toutes les subtilités de la modélisation Entités/Relations sans jamais s'éloigner des préoccupations du client. Tout ceci afin de convaincre le client qu'ERic est bien une technologie de rupture.
Je viens de refabriquer une nouvelle ontologie à partir de zéro.
Avec plus d'expérience, peu de vocabulaire et la nouvelle relation In je m'amuse à créer des graphes délirants
Tant que tu t'amuses, je crois que c'est l'essentiel
Ce n'est même pas moi qui ai inventé cette relation In.
Je l'ai découverte dans une thèse datant de 2001 mais qui n'a été mise en ligne qu'en octobre 2009.
Cette relation In est encore plus puissante que le modèle que j'avais initialement proposé. Par exemple rien n'empêche qu'une boîte appartienne à deux boîtes différentes ou plus. Ça permet de modéliser le recouvrement partiel de plusieurs contextes.
Et pourtant dieu sait combien de fois on m'a affirmé que "personne ne lit les thèses universitaires"
Si j'en crois le tableau de cet article ERic pourrait être adapté à la Business Intelligence décisionnelle. Un débouché de plus à creuser
On pourrait croire que je passe mes journées à me branler. Mais pas uniquement.
Là j'ai du faire des efforts pour trouver des diagrammes réalistes "vendable" comme du Business Modelling.
À priori le modèle standardisé le plus connu qui ressemble le plus à mes boîtes de graphes c'est le Statechart de David Harel. Cette notation fait depuis toujours partie du standard UML (c'est pas parce que je n'utilise pas la POO que je ne connais pas vos petits fétiches
). Bon, en pratique il semble que personne n'utilise vraiment ces modèles d'états hiérarchisés. Du coup on ne trouve que des exemples scolaires, surtout des modèles d'états de montres, de calculatrices, de lecteurs MP3. À croire que les programmeurs POO sont tellement désabusés qu'ils n'adhèrent même pas à leur principes 
Le problème si l'on ne s'adresse pas à des programmeurs c'est qu'on s'adresse à des personnes habituées à des schémas entités/relations beaucoup plus basiques, donc sans imbrication. Ces personnes font du Business Modelling.
Ça ne fait toujours pas mon affaire. Ce qu'il me faudrait c'est un exemple similaire à la souris verte qui courrait dans l'herbe, mais avec des graphes imbriqués. Et surtout qui me fasse passer du niveau école maternelle au niveau école de commerce. Et j'ai trouvé quelque chose qui y ressemble beaucoup : BPMN Business Process Model Notation, un standard de l'OMG.
Alors du coup on est en droit de se poser la question : finalement, il existe déjà des notations standard (certes plus spécifiques) pour modéliser la même chose qu'ERic. Est-ce que je ne suis pas en train de réinventer la roue ? Hé bien je pense que non. Car ces standards ne servent qu'à la documentation/communication.
Aucun de ces standards n'est équipé d'un mécanisme de subsomption comme l'est ERic.
Grâce à la subsomption ERic est capable :
EDIT: bien que pas mauvais, l'exemple ci-dessus n'illustre pas encore parfaitement toutes les capacités d'ERic. ERic accepte que les flèches traversent les boîtes, qu'elles y entrent ou qu'elles en sortent. Ce qui n'est pas le cas dans le schéma ci-dessus.
Au risque de me faire taper (encore) avec des idées déplacés, mais il me semble que Eric apporte quelque chose aux notations, quelque chose de plus concret pour un businessman...
Je m'explique, ce genre de schémas, pourquoi ils existent ? Pour permettre de structurer, structurer les idées, les mettre à plat, et surtout : Mettre en évidence les relations entre ces idées.
Pour moi, l'utilité qu'on en a dans l'entreprise est celle de la performance, de l'efficacité, lorsqu'il s'agit de faire fonctionner beaucoup de choses en même temps, ce genre de schémas est un gain de temps précieux, et surtout un miracle quand il s'agit de garder les idées claires.
La limite de ces modèles est leur taille, leur complexité, plus ils deviennent gros, plus ils perdent leur utilité. Pour moi, Eric pourrait surmonter ce problème, en amenant une dimension dynamique, la possibilité d'interagir avec des modèles de grande à très grande taille, la possibilité d'imbriquer facilement des gros modèles dans de plus grands modèles, de zoomer, d"zoomer, de faire obstruction de certaines parties du schéma, de le triturer dans tous les sens, le formalisme apporté par Eric pourrait être le noyau d'un outil puissant.
Mais dans cette voie, c'est bien la forme que prendrait l'outil qui sera déterminante, car c'est avec cette forme qu'interagira l'utilisateur final.
J'ai dit le mot qui tue : utilisateur.
Tu m'enlèves les mots de la bouche
J'ai bien conscience que la notation texte est indéchiffrable pour un manageur, si elle ne l'est pas déjà pour un programmeur. Donc tout devrait reposer sur l'ergonomie graphique, la facilité à digérer et à interagir avec des schémas imbriqués à grande échelle. Par exemple à l'échelle d'une multinationale ou d'une administration comme la commission européenne. J'ai lu des papiers de recherche sur la modélisation à grande échelle (par exemple sur le projet Ariane V). À cette échelle la notion de point de vue est primordiale. Le modèle doit être global, il doit tout contenir. Paradoxalement il doit aussi savoir rester local, adopter le cœur de métier de l'utilisateur et retirer toute l'information qui n'a aucun impact sur son travail.
Bon, ceci dit, j'ai déjà un train de retard, les caricaturistes m'ont devancé, les salauds
Base de connaissances et fichage
La subsomption est un très bon mécanisme de reconnaissance de motifs. Toute application consistera à développer une ontologie qui spécialise cet outil abstrait pour un usage concret. On passe ainsi d'une définition algébrique abstraite à des définitions et des genres concrets.
On veut un outil d'assistance au diagnostic médical ?
Il suffit de créer une ontologie des pathologies et des parcours de soin.
En théorie on vient de créer une application pour mieux soigner le monde.
En pratique on vient de créer un formidable outil de fichage qui pourrait bien intéresser votre assurance maladie, votre assurance vieillesse, votre employeur, vos contacts sur Meetic et j'en passe.
On veut un outil d'assistance à la sécurité publique ?
Il suffit de créer une ontologie des crimes et délits et des parcours judiciaires.
Même causes, mêmes conséquences.
En théorie on vient de créer une application de lutte contre le crime et la récidive.
En pratique on vient de créer un formidable outil de flicage qui pourrait intéresser aussi bien les démocraties de plus en plus sensibles au sentiment d'insécurité que les dictatures de plus en plus sensibles à la contestation sur les réseaux sociaux.
Moralité
Avant de commencer à développer une ontologie, posez-vous d'abord cette question : l'information stockée est-elle potentiellement liberticide ? Si la réponse est affirmative alors abandonnez l'idée tout de suite. Oubliez les bénéfices sur les autres critères (santé,sécurité,...). Les bénéfices sur ces critères ne seront acceptés que s'ils ne se font pas au détriment des libertés individuelles.
À peine 1h après avoir écrit cet article je reçois une offre d'emploi dans ma boîte-à-lettres électronique, dont voici un extrait :
À croire que :
Bref, croyez-le ou non : la demande existe
Et bien, qu'attends-tu, go go go !
Il faudrait d'abord que je m'entraîne à classifier les manquements à la charte du refuge :
• Prau deu l'ortografe
• freepost, lurking, stalking, bashing
• incitation à la pratique de jeux vidéos violents
• graine latente d'homophobie larvée
• détournement de mineur et incitation à la pornographie
• techniques de drague éhontées (dont avatar et smileys personnalisés)
• mode manuel pour les autres infractions non répertoriées
• bannissements automatisés
Le Refuge d'Aerie's Guard est le repaire du crime organisé. Plus spécifiquement, le crime de création et d'originalité.
Politiquement inapplicable, pour le moment, du moins je le crois. L'idée d'être fiché et étiqueté est de moins en moins politiquement incorrecte, par le biais des médias sociaux et notamment des réseaux sociaux type Facebook, cette idée de voir ses informations d'individu groupées dans un fichier informatique devient moins menaçante et plus usuelle.
Je le constate notamment dans la génération dans laquelle je suis plongée (je pense aux 10-20 ans), la sensibilisation aux dangers de l'information, de la collecte de données, du "fichage" est bien moindre en rapport à ce que j'observe chez les personnes plus âgées, moins imbibées d'Internet. Ce ne sont que mes propres observations et je ne suis pas sociologue, mais je pense que la collecte de donnée à propos des individus associée à l'utilisation de ces données à propos des individus tendra et tends déjà un peu vers la banalisation, à devenir quelque chose de "commun".
Pour m'être un peu plongé récemment dans le sujet, la cybercriminalité, l'utilisation commune de moyens de chiffrages forts par tout le monde (hashs, clés publiques/privées, des bidules 256-bits abominables...etc), rend la tâche de plus en plus difficile avec des moyens traditionnels. Actuellement, acheter en toute sécurité n'importe quelle drogue depuis chez soi et à des prix défiant toutes concurrences, c'est possible : On se télécharge un petit Routeur Onion, on se procure quelques Bitcoins, on fait ses transactions anonymes vers un vendeur anonyme sur un serveur anonyme avec une IP anonyme, en prenant soin d'avoir un petit SSL au coin, et pof, trois jours plus tard on reçoit dans sa boîte au lettre son petit colis. Même, si on se fait attraper, comme il n'y a eut aucune transaction, aucun achat, on peut nier l'existence même de l'intention de se droguer : Ce colis n'était qu'une erreur !
Il y a un besoin croissant de faire face à ces petits groupes d'individus qui avec des moyens simples permettent de grandes choses, comme les terroristes qui ont eut l'idée de détourner des avions, des internautes ont l'idée de monter leur petite affaire d’assassinats, de ventes libres de stupéfiants, d'armes à feu, de divers produits chimiques dangereux... tout ce qui rapporte de l'argent et qui n'est pas très légal. Je suis d'avis que le passage de notre société à la sphère mondialisée, à la sphère sociale, conduit et a déjà conduit à de nouvelles formes de criminalités, utilisant les nouveaux outils.
Or, comment luter contre la criminalité ? Collecter des informations, les recouper, intervenir, compléter les informations, avancer...etc Les méthodes de base ne changeront pas, c'est surtout l'échelle qui changera. Pour réussir à trouver une aiguille dans une botte de foin mille fois plus grosse, on regarde mille fois plus longtemps, ou on regarde avec mille cerveaux. Réussir à avancer sur la mise au point d'un système automatisé de collecte de données, de fichage, de recoupement (de reconnaissance de motif), ce sont devenu des choses d'avenir pour ce qui est de la criminalité, car le temps où on cassait les codes, où on déchiffrait les disques durs, où on écoutait les lignes téléphoniques... c'est finit. Demain, on aura besoin de "gros engins".
C'est liberticide, oui, mais je crois que la société va l'oublier petit à petit, et que le jour où il y aura une action criminelle d'envergure qui marquera l'opinion, avec un jeu politique, la mise en place d'une telle base de donnée sera du domaine du possible, politiquement acceptable. Or, il faut pouvoir l'implémenter au bon moment et avoir des résultats rapides pour calmer le public sur ses angoisses de liberté et d'intimité, et donc avoir déjà mené de longues recherches à ce propos pour pouvoir catapulter le projet sous les projecteurs au bon moment.
Enfin, tout cela est ma vision de la chose, je trouve que l'Union Européenne fait bien son travail en travaillant sur ce genre de projets, même si ce n'est pas très moral.
L'argument selon lequel nous vivons dans un monde fait de menaces qu'Iron-Man ne pourra pas toujours anticiper et c'est pourquoi il doit fournir son armure au gouvernement ne me convainc pas que je doive par avance renoncer à mes libertés.
Alors en effet je suis de la génération où l'on se "cache derrière un pseudo" pour commettre ses cyber-délits en toute impunité
Plutôt que de continuer à disserter ici sur les (dé-)mérites de ce projet européen qui ne concerne pas ERic, j'ai préféré faire directement un signalement à un lobby des libertés informatiques.
La boîte centrale cerne toutes les fonctionnalités d'ERic 0.2f, en résumé les relations sont binaires et non-typées, l'interface est textuelle et synchrone, les opérations disponibles sont la subsomption et la négation, les taxonomies sont de simples hiérarchies.
Tout ce qui est en dehors de la boîte centrale représente autant d'extensions envisageables.
Les boîtes carrées And et Xor sont reliées aux autres par la boîte ronde implicite (Relation).
Une boîte And signifie que l'utilisateur pourrait cumuler toutes les fonctionnalités.
Une boîte Xor signifie que les fonctionnalités seraient mutuellement exclusives.
La mise à jour de la base de données pourrait se faire à l'aide d'un système de réécriture [RewriteSystem] si ERic possédait les [Bigraphs] avec leurs [Interfaces] au lieu des simples graphes de boîtes (boxed graphs) comme c'est le cas actuellement.
Le déploiement de l'application sur plusieurs postes de travail suppose une architecture client-serveur [Asynchronous] qu'ERic ne possède pas actuellement.
D'après les experts du domaine, une interface 100% visuelle est incontournable.
Comme vous pouvez le remarquer, le fait de "zoomer" sur une boîte particulière vous place dans un contexte mais ne vous isole pas totalement de l'extérieur. À cause des liens entrants et sortants et du fait que les boîtes peuvent se recouvrir partiellement.
Joli graphique, mais pourquoi l'interface graphique serait-elle mutuellement exclusive avec l'interface textuelle ?
Parce que je suis trop fainéant pour chercher une bijection entre les deux (à supposer qu'elle existe
).
Les deux systèmes ne peuvent pas tout simplement cohabiter ?
Les deux notations ont leurs avantages :
C'est donc tout bénéfice si les deux notations sont acceptés.
Même chose pour le layout, manuel ou assisté, on peut imaginer un 1ier jet manuel, puis une optimisation automatisée du positionnement des boîtes et du routage des arêtes (moins de coudes, moins de croisements), puis conclure avec une retouche manuelle pour des raisons esthétiques.
Ertaï a écrit :
Si
Apparemment j'avais le cerveau tellement obscurci que je t'ai pondu une réponse à la Nostradamus. Ça m'arrive d'être totalement dans la lune, tu as bien fait d'insister 
En tout cas j'aime bien ce graphique qui expose clairement les capacités actuelles et futures de ton logiciel. On reste loin de la complexité de langages de modélisation plus fournis et du coup moins utilisés.
La boîte [Not-this-relation] remplace la très mal nommée boîte [Negation] (car il n'y a pas et il n'y aura jamais de négation en ERic pour des raisons de logique fondamentale).
Le nouvel opérateur [Différence-link] force deux boîtes-entités à représenter 2 entités distinctes (que le mécanisme de ne pourra de subsomption pas identifier l'une à l'autre). Cet opérateur pourrait éventuellement être ajouté à une éventuelle version ERic 0.2g
L'opérateur [Generalization] reste inchangé. Il est toujours possible de calculer un unique graphe-ER qui subsume 2 autres graphe-ER quelconques. C'est possible grâce à la [Taxonomy] qui a toujours une racine. Que ce soit un tree, un DAG ou un lattice il y a toujours une racine unique. Donc forcément quand on remonte dans la généralité on tombe tôt ou tard sur un point commun.
Le nouvel opérateur [Specialization] est tout le contraire. Il doit calculer un unique graphe-ER qui est subsumé par 2 autres graphe-ER quelconques. Ça n'est possible que si les 2 taxonomies (celle des entités et celle des relations) possèdent une anti-racine. De toutes les taxonomies seules les lattice possèdent une anti-racine.
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