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.