AeriesGuard Le Refuge des Créateurs Minecraftiens !

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?