Oui, je sais, je devrais programmer sinon cette version 0.2 ne verra jamais le jour. D'un autre côté j'ai des choses à dire alors je les dis, tant pis si l'essentiel prend du retard parce que l'essentiel est dit.

Release early, release often

Quel est le cœur du cœur de votre application.
C'est la question clé. Répondez à cette question, réduisez au maximum la voilure, comprimez la spécification jusqu'à ce qu'il ne reste plus que la peau sur les os. Puis implémentez, déboguez, documentez, et appelez ce premier jet version 0.1a

Alors toute la suite de l'histoire n'est plus qu'extensions sur extensions. N'essayez pas d'ajouter des greffons, refactorisez la conception au fur et à mesure de l'implantation de nouvelles fonctionnalités. Visez d'abord les extensions utilitaires. Ce sont celles qui manquaient cruellement à la version 0.1 pour en faire autre chose qu'un jouet.

Utilisez la méthode Quality First .

Comparez avec les logiciels existants. Même si votre programme est très exotique il existe forcément quelques programmes avec des buts similaires ou partiellement équivalents. Sachez distinguer la caractéristique indispensable et le gadget superfétatoire.

Dois-je ajouter une interface graphique.
L'utilisateur final sera sans doute très sensible à la présence d'une interface graphique. Cependant cela représente un travail énorme pour le programmeur. Par conséquent il faut le repousser très en aval de la conception. Pensez d'abord à ajouter les fonctionnalités indispensables. Quand votre programme commence à rivaliser avec les solutions alternatives alors seulement il sera temps d'accoler une interface graphique.

Dois-je ajouter une architecture client-serveur.
Même raisonnement que pour l'interface graphique. C'est une demande de l'utilisateur final. Ne la prenez pas prématurément en compte. Concentrez-vous sur l'essentiel, c'est ce qui fera la véritable valeur ajoutée de votre programme une fois que vous aurez ajouté tout ce que vos utilisateurs réclament.

Google est mon ami

 J'ai déjà dit et répété qu'Eric était sujet à de multiples possibilités d'extension. Foin de promesses, il est grand temps de décider quelle extension fera d'Eric 0.2 un logiciel autrement plus avancé qu'Eric 0.1b

Une recherche rapide dans le domaine de l'ingénierie de la connaissance permet d'isoler les quelques principaux concurrents d'Eric. Ce sont des logiciels matures souvent issus de deux dizaines d'années de recherche universitaire.

Le plus proche (géographiquement) est Cogitant , une charpente pour les graphes conceptuels écrite en C++ et reliée à l'interface CoGui écrite en Java.

Un autre est Loom (maintenant évolué en PowerLoom ) écrit en STELLA (environ 50000 lignes, sans compter l'interface en Java).

Quelle est donc la particularité commune à Cogitant et à Loom qui en fait des bases de connaissances bien plus crédibles qu'Eric 0.1b (environ 600 lignes d'OCaml).

La première réponse c'est sans aucun doute la subsomption . Eric possède bien quelques rudiments de logique de description mais il est incapable d'en tirer pleinement parti car son vocabulaire est plat. Comme Cogitant et Loom l'ont déjà, il lui faudrait une ontologie (un vocabulaire structuré) et un raisonnement par subsomption (un ordre partiel sur l'ensemble des graphes entités-relations).

Bien évidemment l'ontologie d'Eric serait initialement vide au chargement. Il faudrait donc éditer (ou bien charger) une ontologie avant d'éditer un graphe entités-relations, puisqu'autrement on n'aurait aucun vocabulaire pour étiqueter les boîtes-concepts et les boîtes-relations.

Comme je ne vais pas réinventer la roue, autant considérer une création complexe (par exemple Kernherd de Cathaseris ), et utiliser une ontologie appropriée (ici RPGOntology ) pour tenter de la modéliser. Après tout rien de tel que l'épreuve du réel.

Mais pas cette fois-ci

Pas de chance. RPGOntology est introuvable. Ou plutôt si, Google connaît bien RPGOntology , mais il s'agit malheureusement de Radiation Protection Guidelines Ontology
Tant pis, j'aurais bien aimé fournir une ontologie pour le jeu de rôle, et ce même si elle se révélait insuffisante pour modéliser Kernherd.

Exit donc le jeu de rôle. Je me rabats sur des ontologies plus généralistes qui auront le mérite de me permettre les mêmes petits exemples d'introduction accessibles à tous comme dans mon premier article sur le modèle entités-relations. Deux retiennent mon attention. Les autres ont l'air très (trop?) spécialisées dans la description des ressources web ( web sémantique ).

gist: the minimalist upper ontology est une ontologie généraliste écrite en OWL. Elle est également visionnable (uniquement dans Internet Explorer) à l'aide du plugin Visio pour ActiveX .

GUM (Generalized Upper Model) est également une ontologie généraliste, la version 2.0 est sous forme diagrammatique au format pdf tandis que la version 3.0 est écrite en OWL.

Problème: autant gist que GUM , les deux ontologies utilisent les types conjonctifs. Un type conjonctif est un type qui peut avoir 2 super-types ou plus. Or ma conception d'Eric 0.2 est simplissime: elle n'autorise qu'un unique super-type, il n'y aura pas de types conjonctifs. En vocabulaire de POO ( Programmation Orientée Objet ) on dirait qu'Eric 0.2 n'autorise que l'héritage simple alors que gist et GUM utilisent l'héritage multiple.

Solution: des deux ontologies GUM ( pdf ) est la plus petite et (de loin) la plus facile à visionner dans son intégralité. Je choisi GUM ( pdf ) et je décide de la reconcevoir afin d'éliminer les types conjonctifs. C'est assez facile pour les concepts car la majorité des types haut-placés dans la hiérarchie n'ont qu'un unique super-type. Ce sera plus délicat (ou plus dévastateur) pour les relations car elles utilisent intensément les types conjonctifs.

Une autre solution (qui vient en complément) consiste à concevoir ma propre ontologie de haut niveau sur la base de considérations purement sémantiques et/ou computationnelles (GUM est un peu trop philosophico-linguistique).