Le langage de règles SmartRules

Dans notre approche, la gestion du contexte s’effectue en combinant des concepts et leurs relations dans un ensemble de règles sémantiques définies dans un langage de règles, appelé SmartRules¹ [118]. Ces règles sont exprimées à partir de l’ontologie définie pour l’application considérée.

4.3.1 Caractéristiques recherchées pour les règles

Les exigences spécifiées pour la définition de ce langage de règles sont les sui-vantes :

– Exprimer des règles en utilisant le vocabulaire d’une ontologie décrite avec le langageµConcept, figure 4.2;

– Manipuler une base de connaissances qui change continuellement ; – Exprimer les règles de manière simple ;

– Avoir la possibilité de modifier les valeurs des instances de concepts vérifiant l’ensemble des contraintes définies dans le modèle sémantique ;

– Lancer des actions sur les instances de concept ;

Figure ^{4.2 – Schéma général d’une règle SmartRules.}

1. Les règles considérées sont de type règles de production.https://en.wikipedia.org/wiki/ Production_rule

4.3.2 Formalisme du langage SmartRules

Pour répondre à l’ensemble des exigences énumérées ci-dessus et garantir la cohérence du système, le moteur de raisonnement doit être capable de prendre en compte la dynamicité du contexte. La décidabilité et la capacité à traiter une grande base de connaissances font de l’algorithme Rete [40] et en particulier sa version

Rete Oriente Objet (Rete OO), un moteur de raisonnement particulièrement bien adapté au modèle sémantique proposé dans ce chapitre. Le langage de règles que nous proposons est indissociable du langage µConcept. Ce langage s’appuie sur le modèle de règles classique suivant :

IF condition(s) THEN operation(s)/actions(s) sur les instances.

Exemple :Supposons que dès le déclenchement d’un incendie, on désire identi-fier et suivre les déplacements des occupants d’un immeuble. Pour ce faire, chaque personne est équipée d’un tagRF ID. Les lecteursRF ID, installés dans les parties communes et dans chaque habitation (escalier, ascenseur, couloir, toilettes, salle de bain, porte d’entrée, etc.), servent à notifier l’entrée d’une personne dans un espace donné. Si nous définissons une propriété “allLocation”, à chaque passage d’une per-sonne dans la zone de couverture d’un lecteur RF ID, sa position est enregistrée dans la base de connaissances sous la forme d’une instance d’un concept. Il est ainsi possible de tracer son déplacement en utilisant la règle “Human Movement Tracking” définie dans le tableau 4.1.

rule "Human Movement Tracking" conditions

?p := Person( ?currentLocation := one (allLocation) ) ; actions

définir une ou plusieurs actions d’adaptation au contexte ....

end

Table^{4.1 – Suivi d’une personne dans un habitat donné.}

Dans cet exemple, le concept Person est le domaine de la propriété allLocation

qui est une propriété multivaluée. Cette propriété peut avoir plusieurs valeurs pour une instance donnée. À l’aide de l’opérateur one utilisé uniquement avec une pro-priété multivaluée, la règle “Human Movement Tracking” pourra traiter toutes les valeurs de cette propriété. Ainsi, cette règle permet de vérifier l’existence d’abord d’une instance de Person, puis de déduire toutes les valeurs de cette propriété pour chacune des personnes.

4.3.2.1 Définition des règles

La syntaxe formelle d’une règleSmartRulesest définie dans 4.2où le symbole

quant à lui, représente une ou plusieurs actions (mise à jour de propriété, action définie dans l’ontologie d’une application, etc.). Formellement :

m ^ i=0 CP −→ n ^ j=0 AP (4.2)

où CP est une conjonction de conditions (cp₀∧cp₁∧ ... cp_m−1∧cp_m), et AP une conjonction d’actions(ap0∧ap1∧...apn−1∧apn).

Figure ^{4.3 – Diagramme de définition d’une règle SmartRules.}

Figure^{4.4 – Exemple de règle SmartRules.}

Le diagramme de définition d’une règle SmartRules est illustré figure 4.3. La figure 4.4 décrit un exemple de règle permettant de mettre à jour la valeur de la propriété isAtHome à false. Cette opération s’effectue grâce à l’action (a1) après vérification de la véracité des conditionsc1, c2, ..., c6.

4.3.2.2 L’appariement

L’appariement consiste à chercher tous les unificateurs tels que la représentation sémantique des concepts définis dans les prémisses des règles pouvant être appariées

(unifiées) avec une ou plusieurs instances (faits) de la base de connaissances. Une prémisse peut avoir ou non des contraintes 4.3. Une contrainte Ct, définie pour un concept C, peut être simple ou composée. Notons que seules les instances d’un concept C mises à jour dans la base de connaissances sont considérées.

C(

n

^

i=0

Ct) (4.3)

oùC etCt appartiennent au domaine de l’ontologie.

Une prémisse sans contraintes signifie que toutes les instances du même concept sont évaluées. Ainsi dans la figure 4.4, la condition (c6) impose que toutes les instances du concept Person soient évaluées, tandis que les conditions (c1), ..., (c5) définissent chacune une contrainte (isOccupied) booléenne .

4.3.2.3 Déclaration de variable

La notion de variables dans le langage de règlesSmartRulesest similaire à celle utilisée dans les autres langages de règles, tels que Drools,J ess, etc. Une variable peut être utilisée pour stocker une connaissance (instance, valeur de propriété ou d’un littérale), figure 4.5. L’identifiant de chaque variable est défini à l’aide de l’expression suivante : [?][a−z][a−zA−Z0−9]∗. Formellement :

v←−C(

n

^

i=0

Ct) (4.4)

Figure ^{4.5 – Diagramme de définition de variable.}

Contrairement aux langages imposant la déclaration du type de la variable, le langage SmartRules déduit automatiquement le type de la variable de l’élément référencé. Les variables déclarées dans une règle ne sont visibles qu’à l’intérieur de cette règle. Cependant, il n’est pas possible de déclarer une variable de même nom déjà déclarée comme variable globale. Dans la condition (c6), figure 4.4, la variable ?x permet de référencer toutes les instances de typePerson.

Figure ^{4.7 – Exemple de règle d’adaptation au contexte}

Figure ^{4.6 – Diagramme de déclaration d’action}

4.3.3 Définition des actions

La partie “actions” d’une règle représente les actions à exécuter dans l’environ-nement réel, ou les nouvelles connaissances contextuelles inférées. Dans la version actuelle du langage SmartRules, il s’agit de créer, supprimer des instances ou une valeur de propriété dans la base de connaissances et/ou modifier/ajouter une valeur de propriété, figure 4.6. Par exemple, l’action (a1) définie dans la règle illustrée, figure 4.7, permet d’éteindre une cuisinière. Il s’agit ici d’inférer que

l’habitat est vide (c1) et que la personne a oublié d’éteindre la cuisinière (Stove)

(c2). Le paramètre instanceId de l’action _SwitchOff indique l’instance exacte correspondant à la cuisinière à éteindre. L’adaptation à ce contexte consiste alors à éteindre cette cuisinière (Stove).

4.4 Démarche de modélisation d’un environnement à