• [^] # Re: En guise de conclusion

    Posté par . En réponse au journal mes présentations: à l'OSDC, et jeudi prochain. Évalué à 0.

    Merci Thomas pour relancer le débat. Ca va mieux avec des questions précises !

    Je réécris la règle avec des variables pour la traçabilité :
    "les personnes P ayant acheté la même chose A1 que vous ont aussi acheté A2 "

    Du point de vue applicatif , c'est en fait une règle de présentation :
    S'il existe une personne P ayant acheté la même chose A1 et qui a aussi acheté A2,
    et si A1 et A2 sont distincts, alors il faut afficher le message proposant A2 .

    Ce qui se traduit en logique N3 par :

    {

    ?P a_acheté ?A1 .
    client_courant a_acheté ?A1 .
    ?P a_acheté ?A2 .
    ?A1 owl:distinct ?A2 .
    } => {
    ?message contient ( "Les personnes ayant acheté " ?A1 "
    ont aussi acheté " ?A2 ).
    affichage_courant contient ?message .
    } .

    Chaque point délimite un triplet ("statement"). Les parenthèses délimitent une liste. Bien sûr le dernier triplet va déclencher d'autres règles qui vont ultimement afficher qq'chose en Swing ou en HTML, etc, suivant la plateforme et le contexte de la session. La variable ?message à droite du signe => correspond à une création d'objet.

    Pour voir un exemple de règles qui sont effectivement utilisées pour la génération de formulaires:

    http://deductions.svn.sourceforge.net/viewvc/deductions/n3/app_gui-rules2.n3?view=markup

    Ce qui est intéressant c'est que la même technologie N3 est utilisée pour les règles d'infrastructure (les formulaires) et pour les règles métier (les conseils d'achat).

    Dans la vraie vie, les règles sont certainement plus complexes; on ne va pas proposer des livres sur la pêche à un amateur de romans policiers juste parce que q'un autre
    amateur de polars en a acheté.