applications exemples

16 views
Skip to first unread message

Jean-Marc Vanel

unread,
Oct 18, 2010, 1:00:33 PM10/18/10
to deduct...@googlegroups.com
Bonjour

Une des choses qui manquent dans le projet ce sont des applications métier construites avec le cadriciel (framework).
Voici quelques conseils pour en construire.
  1. partir d'une ontologie existante si possible
  2. ajouter des règles métiers et applicatives: contraintes et règles constructives
    pour ce faire on pourra les écrire en anglais contrôlé via ACE View ou ACEWiki, ou directement en N3, ou une combinaison des deux
  3. s'appuyer sur une sémantique simple pour l'interaction utilisateur, mettant en avant ces concepts: CRUD (CReate, Update, Remove), log, statistics, current_tasks
  4. dans un premier temps, on génèrera une IHM minimale, peut-être en ligne de commande;
    c'est à dire qu'on va laisser de côté les règles existantes pour formulaires Swing, car ces règles sont à revoir avec le nouveau mapping N3-Java , voir: http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/html/architecture.html#L5714 .
    du point de vue des règles N3 mélangeant triplets métier et triplets Java, le principe ne change pas, mais dans les détails la compatibilité ne peut pas être maintenue. Le changement essentiel est que les appels de méthodes Java se font en direct, et non pas après une (re)traduction globale de la WorkingMemory en JavaScript.
  5. séparer les données en différents fichiers dans un projet EulerGUI: ontologie, règles métiers, règles applicatives;
    je propose de créer cela dans deux répertoires wines/ et contacts/ ici :
    https://eulergui.svn.sourceforge.net/svnroot/eulergui/branches/refactoring/eulergui/examples/
    chaque répertoire contiendra:
    model.n3 , rules-bizz.n3 ,  rules-app.n3 , contraints.n3 , java.n3 ; project.n3p.n3 ; src/main/java/
  6. utiliser la version de développement d'EulerGUI, actuellement via Subversion ici:
    https://eulergui.svn.sourceforge.net/svnroot/eulergui/branches/refactoring/eulergui
  7. pour visualiser les ontologies et utiliser ACE View , utiliser Protégé 4.1 beta, avec la version de dév. de ACE View via Subversion ici:
    http://aceview.googlecode.com/svn/branches/1_3 ,
    mais on peut aussi utiliser Protégé 4.0.X avec ACE View installé comme plugin, c'est plus commode.
Les deux exemples
Je propose de commencer par développer en parallèle ces deux exemples:
  1. gestion de contacts commerciaux
  2. gestion de cave à vin
Le cas 1 met l'accent sur l'aspect CRUD, tandis que le cas 2 sur les règles (comment associer un vin à des circonstances sociales et gastronomiques).
Je n'ai pas trouvé d'ontologie pour les contacts commerciaux, et pas beaucoup cherché d'ailleurs. On peut poser des questions sur la liste semantic-web.w3.org ou sur l'IRC #swig sur irc.freenode.net.
Pour le cas 2, il y a une ontologie célèbre, qui est un exemple OWL classique:
On en parle aussi dans :
Au sujet des règles pour associer vin et plats, il ne manque pas de pages sur le web. On pourra entrer ces règles dans ACE View.

Ajouter des règles métiers et applicatives
Les règles métier, ce sont des règles purement logiques, comme les exemples de cette documentation :
Les règles applicatives expriment des spécifications sur l'application elle-même: dans quelles circonstances elle va afficher quelque chose, proposer à l'utilisateur de mettre à jour les données.
Les règles "constructives" créent de l'information, comme la règle des suggestions d'amis dans rules-examples.html ci-dessus.
Les contraintes sont imposées par des règles d'interdiction, ayant false dans le membre de droite .

Une sémantique simple pour l'interaction utilisateur
On va s'appuyer sur une sémantique simple pour l'interaction utilisateur, mettant en avant ces concepts: log, statistics, current_tasks, CRUD (CReate, Update, Remove).
app:log représente des messages qui sont affichés à la queue le leu et restent affichés.
app:statistics  représente des messages qui sont affichés à la queue le leu, restent affichés, mais peuvent être supprimés. Ils représentent un tableau de bord de l'application.
app:current_tasks est la partie du tableau de bord de l'application qui représente les tâches en cours de l'utilisateur.

Voici un exemple d'utilisation de app:log. On suppose qu'on est dans le membre de droite d'une règle (le conséquent); ainsi une variable comme ?CONTACT qui n'existe pas dans le membre de gauche de la règle (l'antécédent) correspond à une création d'un nouvel identifiant.

:myApp app:log [ "Ajout d'un nouveau contact"@fr ?CONTACT ].
?CONTACT a :Contact.

Voici un exemple d'utilisation pour app:statistics :
{ _:d e:findall( ?CONTACT { ?CONTACT a :Contact } ?CONTACTS ).
   ?CONTACTS math:memberCount ?NB_CONTACT.
} => {
  ?S a app:statistics.
  ?S rdfs:label "Nombre de contacts: "@fr .
  ?S app:information ?NB_CONTACT .
}.
Le rdfs:label agit comme une clé qui va permettre à une régle d'infrastructure de mettre à jour les app:statistics.

Quand aux opérations CRUD, elles se font grâce aux prédicats décrits ici :

Mélanger triplets métiers et appels Java
Ayant quelques règles métiers et applicatives, on peut aller plus loin, et ajouter des règles mélangeant triplets métiers et appels Java.
L'exemple simple (sans règles) est :

Un exemple  avec règles est :

Après, pour appeler l'API EulerGUI, ça se passe comme ça :

Il ne reste plus qu'à écrire un petit main() qui lance la base de connaissance, la peuple avec un ou quelques objets Java, et s'arrange pour que chaque fois  que l'utilisateur ou le monde extérieur agit, alors fireAllRules() est appelé.

Je pense que ça sera plus simple , et tout aussi instructif, de commencer par une application en ligne de commande, ou bien une application mixte, où l'affichage est graphique, et les commandes en ligne de commande.

--
Jean-Marc Vanel
Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/
EulerGUI, a turntable GUI for Semantic Web + rules, XML, UML, eCore, Java bytecode
+33 (0)6 89 16 29 52 -- +33 (0)1 39 55 58 16
( we rarely listen to voice messages, please send a mail instead )

Jean-Marc Vanel

unread,
Oct 19, 2010, 6:16:22 AM10/19/10
to deduct...@googlegroups.com
J'ai oublié un point important.

Le 18 octobre 2010 19:00, Jean-Marc Vanel <jeanmar...@gmail.com> a écrit :

Une sémantique simple pour l'interaction utilisateur

 Je propose de modéliser de manière déclarative une interaction utilisateur avec les concepts de transaction et de champ.
Une transaction est une liste de champs. Un champ de saisie est une entrée de donnée de la part de l'utilisateur. Un champ est associé à un sujet et à une propriété au sens OWL / RDF. 
Il y a trois sortes de champs pour les deux sortes de propriétés au sens OWL ( propriétés "objet" et propriétés "datatype" ): champ ajout, champ modification, champ destruction, et champ création. On entend par là , ajout, modification, ou destruction d'un triplet RDF, et création d'un d'un nouvel identifiant avec son type. Les champs modification et destruction comportent en plus un objet au sens RDF.

Par exemple un champ ajout correspond à l'ajout d'un identifiant d'article dans une commande commerciale. 
Un champ création correspond à la création d'un compte bancaire nouveau pour faire ensuite des virements dessus.

Quand on crée une transaction via une règle, on a toutes les possibilités du language N3 pour ajouter des conditions supplémentaires. Par exemple pour l'ajout d'un identifiant d'article dans une commande commerciale, on peut se restreindre à des catégoreis correspondant aux intérêts de d'utilisateur, ou à ses commandes passées.
 
Il ne reste plus qu'à créer des implémentations pour ce language pour l'interaction utilisateur, grâce à des règles mixtes métier - Java. On peut envisager plusieurs implémentations: Swing, GWT, SWT, dialogue en ligne de commande, etc.

Pour commencer, il faut écrire ce petit vocabulaire en N3.
On va le mettre dans le projet Déductions dans owl/user_interaction.owl.n3

A noter que la specification utilisée dans la génération Swing dans :
utilisée dans l'exemple:

est beaucoup moins flexible mais plus automatique puisqu'il n'y a qu'un seul prédicat
app:editedClass

à partir duquel les règles prennent toutes les propriétés disponibles à partir de cette classe.

Cyril Hansen

unread,
Oct 22, 2010, 8:00:46 AM10/22/10
to deduct...@googlegroups.com
Bonjour,

Je souhaite contribuer au projet Déductions dans les limites de mon temps libre et cette todo liste me semble tout à fait intéressante pour illustrer ce que l'on peut faire avec l'approche technique du projet.

Je vais tenter de me lancer dans ces tâches ce week end et la semaine prochaine, avec probablement des retours sur le "programme d'études". Je vous ferai un petit mail pour vous faire part des tâches que j'aurai attaquées, de mon avancement et de mes inévitables questions.

Cordialement,

Cyril Hansen
Reply all
Reply to author
Forward
0 new messages