D´ efinition et application des r` egles

Du fait que le langage OWL est limit´e au niveau des inf´erences que l’on peut ´etablir lors de la d´efinition des propri´et´es des classes. Nous devons construire des r`egles d’inf´erence qui vont nous permettre de d´eduire des dysfonctionnements qui pourraient entraˆıner une d´egradation de la QdS.

Comme annonc´e pr´ealablement, la d´efinition des r`egles est faite en utilisant le lan- gage SWRL support´e par le plugin ayant le mˆeme nom dans Prot´eg´e. Ensuite, la com- pilation et l’ex´ecution des r`egles sont faites par le biais du moteur d’inf´erence Jess.

Les dysfonctionnements `a rep´erer sont ceux identifi´es et expos´es dans la classification des dysfonctionnements de la QdS introduite pr´ec´edemment.

Fig. 6.9 – Instances de la classe Person.

Une premi`ere r`egle nomm´ee keywordMismatch est illustr´ee par la figure 6.11. Cette r`egle permet d’identifier les relecteurs dont le papier affect´e ne correspond pas `a son do- maine de recherche. Ceci a ´et´e pr´esent´e comme le dysfonctionnement III.2 dans la clas- sification des dysfonctionnements de la QdS pour le syst`eme de gestion de conf´erences. D’autres types de dysfonctionnements pourrait ˆetre identifi´es par des r`egles du mˆeme type, notamment le dysfonctionnement I.2 Renvoie de conf´erences dont le th`eme n’est pas pertinent et le dysfonctionnement IV.3 Rapport ne correspondant pas au papier (paperId).

La logique derri`ere la d´efinition de cette r`egle est comme suit : – Du cˆot´e de l’ant´ec´edent :

1. pour chaque publication cherche ses mots cl´es et les noms des relecteurs qui lui ont ´et´e affect´es,

2. pour chaque relecteur r´ecup`ere son nom et cherche les mots cl´es qui d´efinissent son domaine de recherche,

3. du fait que les noms des relecteurs sont obtenus `a partir de deux classes diff´erentes (Publication et Reviewer ), on doit v´erifier qu’il s’agit de la mˆeme personne, en comparant leurs noms.

4. pour inf´erer qu’il s’agit d’un dysfonctionnement, les mots cl´es associ´es au relecteur et `a la publication doivent ˆetre diff´erents.

– Du cˆot´e du cons´equent :

1. si l’ant´ec´edent ´etais vrai, on pourrait affirmer qu’un dysfonctionnement ca- ract´eris´e par la propri´et´e nonQualifiedreviewer est pr´esent. Cette propri´et´e a ´et´e d´efinie dans la classe ArgumentRelatedQoS. Lors de son ex´ecution, la r`egle montrera les noms des relecteurs qui sont dans une telle situation. La r`egle nomm´ee ReviewerNoAuthor est illustr´ee par la figure6.12. Cette r`egle per- met d’identifier les papiers dont le relecteur affect´e est aussi un des auteurs. Ceci a ´et´e pr´esent´e comme le dysfonctionnement III.3 dans la classification des dysfonction- nements de la QdS pour le syst`eme de gestion de conf´erences.

La logique derri`ere la d´efinition de cette r`egle est comme suit : – Du cˆot´e de l’ant´ec´edent :

1. pour chaque publication r´ecup`ere le nom de ses auteurs et le nom des relec- teurs qui lui ont ´et´e affect´es,

2. pour inf´erer qu’il s’agit d’un dysfonctionnement, le nom d’un des auteurs doit ˆetre ´egal au nom d’un des relecteurs.

Fig. 6.11 – Dysfonctionnement dans l’affectation des papiers : relecteur dont le domaine de recherche et ´etranger au sujet du papier.

Fig. 6.12 – Dysfonctionnement dans l’affection des papiers : Papier dont le relecteur et aussi auteur.

1. si l’ant´ec´edent ´etais vrai, on pourrait affirmer qu’un dysfonctionnement ca- ract´eris´e par la propri´et´e reviewerMismatch est pr´esent. Cette propri´et´e a ´et´e d´efinie dans la classe ArgumentRelatedQoS. Lors de son ex´ecution, la r`egle montrera les noms des relecteurs qui sont dans une telle situation.

La r`egle nomm´ee SubmissionOut Of Date est illustr´ee par la figure6.13. Cette r`egle permet d’identifier les papiers qui n’ont pas respect´e la date limite ´etablie pour la soumission dans une conf´erence. Cette r`egle repr´esente un cas g´en´erique qui pourrait se d´ecliner dans plusieurs des cas list´es dans la classification des dysfonctionnements de la QdS pour le syst`eme de gestion de conf´erences. En particulier nous pouvons l’associer aux cas suivants :

– I.1 Renvoie de conf´erences dont le « deadline » est d´epass´e. – II.4 Pas de soumission de papier apr`es l’inscription d’un auteur. – IV.1 Papier non envoy´e `a temps (« deadline » d´epass´e) aux relecteurs. – IV.2 Rapport non envoy´e `a temps (« deadline » d´epass´e).

– V.1 D´ecision ne respectant pas le d´elai de temps.

– VI.1 Non envoie de version final du papier dans la limite du temps. La logique derri`ere la d´efinition de cette r`egle est comme suit :

– Du cˆot´e de l’ant´ec´edent :

1. pour chaque conf´erence cherche son nom et le « deadline » ´etabli pour la soumission des papiers,

2. pour chaque publication cherche le nom de la conf´erence o`u elle a ´et´e sou- misse, et la date de soumission,

3. du fait que les noms des conf´erences sont obtenus `a partir de deux classes diff´erentes (Conference et Publication), on doit v´erifier qu’il s’agit de la mˆeme conf´erence, en comparant leurs noms.

4. pour inf´erer qu’il s’agit d’un dysfonctionnement, la date o`u la publication a ´et´e soumisse doit ˆetre post´erieure `a la date limite pour la soumission des publications ´etablie par la conf´erence.

– Du cˆot´e du cons´equent :

1. si l’ant´ec´edent ´etais vrai, on pourrait affirmer qu’un dysfonctionnement ca- ract´eris´e par la propri´et´e outOfDayMismatch est pr´esent. Cette propri´et´e a ´

et´e d´efinie dans la classe TimeRelatedQoS. Lors de son ex´ecution, la r`egle montrera les noms des publications qui sont dans une telle situation.

Mise `a part les r`egles pour la d´etection des dysfonctionnements, nous pouvons aussi d´efinir des r`egles qui agissent de fa¸con pr´eventive. Dans ce cas, il s’agit d’actions qui pourrait ˆetre v´erifi´ees afin d’´eviter les dysfonctionnement qui am`enent le syst`eme vers

Fig. 6.13 – Dysfonctionnement dans la soumission des papiers : La date de soumission ne respect pas le « deadline ».

un ´etat anormal o`u la QdS est d´egrad´ee. Ce type de r`egle nous l’appelons une recom- mandation.

La figure 6.14 illustre un exemple de recommandation. Afin de pr´evenir le dys- fonctionnement o`u un relecteur re¸coit un papier dont il est auteur, la recomman- dation nomm´ee RecommendedReviewers conference pourrait ˆetre utilis´ee. Ainsi, cette r`egle cherche des relecteurs ayant des int´erˆets de recherche proches des th`emes de la conf´erence.

Fig. 6.14 – Recommandation de relecteurs en fonction des th`emes de la conf´erence. La logique derri`ere la d´efinition de cette r`egle est comme suit :

– Du cˆot´e de l’ant´ec´edent :

1. pour chaque conf´erence cherche ses mots cl´es identifiant ses th`emes de re- cherche,

2. pour chaque relecteur r´ecup`ere son nom et ses mots cl´es identifiant ses int´erˆets de recherche,

3. pour inf´erer qu’il s’agit d’un relecteur habilit´e pour la conf´erence, les mots cl´es de la conf´erence et du relecteur doivent co¨ıncider.

– Du cˆot´e du cons´equent :

1. si l’ant´ec´edent ´etais vrai, on pourrait affirmer qu’un relecteur est habilit´e, ceci est caract´eris´e par la propri´et´e recommendedReviewers. Cette propri´et´e a ´et´e d´efinie dans la classe Conference. Lors de son ex´ecution, la r`egle montrera les noms des relecteurs, les mots cl´es co¨ıncidents et les conf´erences o`u les relecteurs sont habilit´es.

Application des r`egles

Nous avons appliqu´e les r`egles introduites pr´ec´edemment, un exemple des r´esultats est illustr´e dans la figure 6.15. Les r´esultats obtenus sont en fonction des instances d´efinies dans la basse de connaissance de l’ontologie. Durant l’ex´ecution l’outil Jess applique toutes les r`egles d´efinies dans l’´editeur de r`egles, est les r´esultats (caract´eris´es par le cons´equent de la r`egle) son affich´es sous l’onglet Asserted Properties.