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 :

join
 [Believe *b] Experiencer [Person:Tom]
 b Theme [Proposition *p]
 [Want *w] Experiencer [Person:Eva*e]
 w Theme [Situation *s]
 [Marry *m] Agent e
 m Theme [Sailor*sailor]
 (w In p) (s In p) (m In s).

Pourrait éventuellement se noter comme ceci :

join
 [Person:Tom] 
 [Believe] (Experiencer)
 (Theme) [Proposition]
 [Want] (In) 
 (Experiencer) [Person:Eva] rot2
 (Theme) [Situation] rot4
 (In) rot4
 [Marry] (Agent)
 (Theme) [Sailor] rot2 rot5
 (In)

Où [xxx] empile une boîte carrée, (xxx) connecte les 2 boîtes carrées en tête de pile, et rotN déplace le N -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 :

• Elle ne nécessite pas de nommer les boîtes carrées avec des variables.
• Elle rend le graphe de boîtes davantage composable/réutilisable.

Inconvénients de cette nouvelle notation :

• Elle est moins déclarative, il faut se représenter mentalement les manipulations sur une pile pour imaginer la construction du graphe de boîtes.

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 .

Aujourd'hui, j'ai passé mon aprem sur des graphes pour programmer des automates. J'ai pensé à ERic.

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

C'est exactement ça.

Bonjour, je programme en tic-tac-toe, et je ne comprends pas comment utiliser mes compétences pour bénéficier des services de ce HAL 9000.

Parce que le Java c'est plus simple ? 

Mais pourquoi diable veulent-ils tout mixer avec du Java.

Ça leur ferait mal un programme monolingue en Erlang ou en OCaml.

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 :

1. Ça en fait une des technologies du web du futur .
2. Typiquement ERic est en concurrence avec le couple OWL + RDF , c'est-à-dire le web sémantique .
3. Selon certaines personnes (beaucoup) le web sémantique c'est le web 3.0 .

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 :

Citation :

Selon  Joel de Rosnay ce serait alors du web 4.0 .

Edit : après y avoir pensé sous la douche je dirais que ça serait du web 3.0+

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 .

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.2 g (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.

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.

Bonnes suggestions, on voit bien à quel point ça te réussit, TSG

Suggestion n°1 :

Suggestion n°2 :

Que comptes-tu faire du coup ?

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 zoom e 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. 

Mine de rien je suis toujours à fond dans ERic.

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 os utilisent 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 ?

J'ai tout essayé cogitant wiki , cogitant user list , cogitant forum , cogitant mailing-list ,... tous les résultats renvoient vers le portail cogitant.sourceforge.net

Aucune 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 ( P rogrammation O rientée O bjets) repensée à la sauce KR ( K ownledge R epré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 autre KR -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

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

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

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.

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.

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. 

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.

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 .

Mes acquis

• J'ai une confirmation que le modèle de graphe d'ERic 0.3 est viable et tout aussi utilisable que celui d'ERic 0.2, tout en étant beaucoup plus expressif.
• J'ai une syntaxe concrète pour exprimer le modèle de graphe d'ERic 0.3

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 :

[Dream*d] Experiencer [Person Eva*e]
[ProspectFor*p] Agent e
d Theme [Event
        [Show*s] Performer [Clown*c]]
p Theme [Asset
        [Capital] Financing s 
        [Man] Acting c].

Les 3 variantes de Tom croyant qu'Éva veut épouser un marin :

[Believe*b] Experiencer [Person Tom]
b Theme [Proposition 
        [Want*w] Theme
        [Situation [Marry*m] Agent ?e]]
w Experiencer [Person Eva*e]
m Theme [Sailor].


[Believe*b] Experiencer [Person Tom]
b Theme [Proposition 
        [Want*w] Theme
        [Situation [Marry*m] Agent ?e m Theme [Sailor]]]
w Experiencer [Person Eva*e].


[Believe*b] Experiencer [Person Tom]
b Theme [Proposition 
        [Want*w] Theme
        [Situation [Marry*m] Agent ?e]
        m Theme [Sailor]]
w Experiencer [Person Eva*e].

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 :

• Avec une représentation textuelle il suffit d'afficher le résultat-texte dans un GtkSourceView2 , c'est presque aussi facile que dans une console.
• Avec une représentation graphique il faut convertir le résultat-graphe en un diagramme affichable à l'écran. À ma connaissance ce graph-drawing n'a jamais été réalisé pour le modèle de graphe d'ERic 0.3

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.

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

Tout ce qui est rare est cher.

Un Rubik's cube bon marché est rare.

Donc un Rubik's cube bon marché est cher.

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 :

• Le but n'est pas de discréditer tel ou tel outil ou institution. Le but est de vous montrer ce qui se fait de mieux et pourquoi je ne vais pas le copier.
• L'outil en démonstration a été élaboré dans une très grande école à la renommée mondiale. Y ont enseigné notamment Albert Einstein et Niklaus Wirth. Et si je n'en cite que deux c'est parce que citer les autres serait tout simplement trop long.

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.

Moi, une relation avec toi, dans tes rêves !

Dans la documentation d'ERic 0.2 j'ai commis 2 erreurs, à savoir dire :

• qu'un graphe entités/relations est proche du langage naturel
• qu'un graphe entités/relations permet certains raisonnements sommaires

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 :

• un diagramme entités/relations est une machine autopoïétique à interprétation endoporeutique
• un diagramme entités/relations permet de dé raisonner gravement pour la santé

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

Araignée du soir, espoir

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.

Il fait nuit. Félix est un chat. Quelle est la couleur de Félix ?

Griiiiiiiis.

c'est un raisonnement trop subtil pour ERic 0.3, il ne sera pas capable de répondre.

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

Les premières lignes de code

Pas fâché d'abandonner Microsoft-Paint

module type Diagram
=
sig
   type diagram
   type concept
   type relation
   type entity =
      | EntityC of concept
      | EntityI of concept * int
      | EntityS of concept * string
      | EntityF of concept * float
      | EntityD of concept * diagram
   val empty : diagram
   val extend : diagram -> entity -> diagram
   val connect : diagram -> relation -> diagram
   type pattern = diagram 
   val select : diagram -> pattern -> diagram list 
end

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

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

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 !

Et sinon, qui veut se coller sur le développement du Projet RAMzy?

À 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é.

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

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 ?

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.

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. 

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 :

join
   [Believe *b] Experiencer [Person:Tom] b Theme
   [Proposition
      [Want *w] Experiencer [Person:Eva] w Theme
      [Situation
         [Marry *m] Agent [Person:Eva]
         m Theme [Sailor]
      ]
  ].

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.

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

> ERic
Entity-Relationship interactive calculator.
version 0.2e by Damien Guichard.
# load "ECO.bdd".
# super-type [Think] Know.
# join
  [Know*k] Agent [Person:I]
  k Theme [Proposition*p]
  p Statement k.

Voilà c'est fait. On a créé une conscience artificielle (ou pas).

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.

Mise à jour mineure vers la version 0.2f

Suite à une visite de nlegriel la relation Attribut a été renommée  Attribut e et une relation Value a été ajoutée.

Le couple Property / Value constitue une alternative à Attribute :

• Si la modélisation est orientée Graphe Conceptuel on préfèrera →(Attribute)→[Age 17]
• Si la modélisation est orientée RDF / OWL on préfèrera →(Property)→[Age]→(Value)→[Integer 17]

Interface source avec OCaml.

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 :

• ou bien le type A est un ancêtre du type B (on note A ≥ B)
• ou bien le type B est un ancêtre du type A (on note B ≥ A)
• ou bien les deux types A et B ne sont pas comparables

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.

  A
  |
  B-----------------C-----D
  |                 |     |      
  E------F------G   H     I------J

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.

[0,10]
  |
[1,5]-------------[5,7]-[7,10]
  |                 |     |      
[2,3]-[3,4]-[4,5] [6,7] [8,9]-[9,10]

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.

Il va y avoir une  longue pose pause de brainstorming avant la spécification de la version 0.3a

Explications :

• Je suis tout nouveau dans le monde des bases de données. Je n'avais pas compris que les données stockées ont un cycle de vie. Il ne suffit pas d'un langage de déclaration et d'un langage de requête, il faut en plus un langage de mise à jour. Et mettre à jour des graphes ça n'est pas évident. En tout cas c'est plus difficile que mettre à jour des enregistrements ou des objets. C'est une faiblesse de l'approche que je n'avais pas vue initialement. Une recherche rapide dans le domaine me confirme que le problème est peu étudié / non-résolu.  
• J'aimerais étendre les capacités des requêtes. En particulier dans le quantitatif (minimum, maximum, intervalle) et dans le temporel (durée minimale, durée maximale, date butoir).
• J'aimerais pouvoir créer des cadre-contextes qui rendraient l'information contextuelle. C'est-à-dire liée à une situation, un état, un point de vue,... C'est une extension bien étudiée, dont on connaît les propriétés. Toutefois ça complique considérablement l'implantation et ça n'arrange rien quant à la résolution des deux problèmes précédents.
• J'aimerais autoriser le sous-typage multiple (héritage multiple) dans la hiérarchie des concepts et dans la hiérarchie des relations.
• J'aimerais faciliter l'embarquement dans les applications utilisateurs, en particulier dans les langages C et OCaml (tant pis pour les autres, ils n'auront qu'à s'interfacer avec le C). Comparativement aux points précédents celui-ci est le plus facile. Pour OCaml c'est trivial et pour le C c'est (assez bien) documenté et il est facile de contacter nombre de personnes expérimentées en la matière.

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 :

• une interface graphique GTK+
• un mécanisme de requêtes asynchrones distribuées

Et tout ça peut se faire 100% en OCaml

La poupée qui dit "non"

La prochaine version ERic v0.2 d 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.

Mise à jour mineure de 0.2b vers 0.2c (ECO étendue, plus d'unités SI, pas de nouvelle fonctionnalité).

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 :

• quand il n'y a presque pas de marché US pour de l'IA alors il n'y en a pas du tout dans l'UE
• l'acteur majeur du marché c'est Google qui fait du "web sémantique" ou du moins qui prétend qu'il va bientôt en faire que d'ailleurs il en fait déjà, que c'est pour demain mais qu'aujourd'hui c'est déjà demain et que d'ailleurs son nouveau langage s'appelle Google Noop heu non en fait il s'appelle Google Go ... aux dernières nouvelles il s'appelle Google Dart ... (mais ça n'est pas le même, c'est un nouveau ++ mieux bien)
• le "web sémantique" c'est simplement du web 2.0, 3.0 , ++ ce que vous voulez
• la faiblesse (économique) de mon approche vient de ce qu'il faut alimenter la base manuellement, de préférence avec du personnel qualifié en informatique/linguistique, qui sait ce qu'il fait. or les personnes qui savent ce qu'elles font sont trop rares et trop chères. le coût est trop immédiat, le gain d'échelle est trop lointain ou trop difficile à chiffrer.
• d'où l'approche Googlesque (je spam le net avec des robots collecteurs et j’agrège pour les nuls puis je vends du trafic aux annonceurs)

Au total c'est assez démotivant

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 :

// agir de façon illégale
[Act] Manner [Illegal]

On ne peut pas dire "un chat peureux", mais on peut dire :

// un chat sujet à la peur
[Cat] Temper [Fear]

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.

[Apple 1000]  // mille pommes
[Apple] Weight [1. Kilo Gram]  // 1Kg de pomme

Modification n°3

Toute unité a un super-type qui indique de quoi l'unité est la mesure.

super-type [Fruit] Apple.    // n'est pas une unité
super-type [Power] [.Watt].  // est une unité de puissance

C'est essentiel pour pouvoir utiliser une proposition quand on ne connaît pas la quantité exacte.

// La puissance requise par le convecteur temporel de la DeLorean
// afin de voyager dans le temps
[Power] Description [Consume*c]
c Agent [Time Convector*t]
[Car DeLorean] EquippedWith t
c RequiredBy [Time Travel]

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.

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

ParentOf|ChildOf  SalariedOf|EmployerOf

  L'encadrement par un tiret symbolise une relation réciproque (bidirectionnelle) comme

-Spouse- -Sibling- -Twin- -Friend- -Associate- -Colleague- -Rival-

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

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

Vous pouvez à présent consulter la documentation en ligne .

( @TSG attention ça pique les yeux )

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 :

• je n'ai eu aucun retour utilisateur
• j'ai reçu un courriel d'un autodidacte me demandant si ERic est capable de raisonner (la réponse est non évidemment, dans le cas contraire ERic serait un être doté de raison)
• je suis à cours de feuille de route

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 :

1. décider d'une extension "raisonnable" en faisant le pari que ça ne mène pas à une impasse (impossibilité d'ajouter d'autres extensions)
2. refactoriser la conception pour rendre ERic "extension neutral", les extensions deviendraient des composants enfichables pour faire un logiciel à la carte (toutefois c'est hyper-complexe et ça pénalise la performance)
3. faire appel aux conseils d'un gourou (un mentor, une personne reconnue dans le domaine de la représentation des connaissances)
4. continuer à communiquer, à promouvoir, jusqu'à trouver une niche applicative puis se laisser guider par des demandes communautaristes

Ou bien cinquième option : le projet est mort-né

 Le forum DVP de discussion du projet ERic est maintenant actif.

Vous y trouverez toutes les informations pour installer / utiliser ERic v0.2a