AeriesGuard Le Refuge des Créateurs Minecraftiens !

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.