AeriesGuard Le Refuge des Créateurs Minecraftiens !

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.