Content uploaded by Michel Héon
Author content
All content in this area was uploaded by Michel Héon
Content may be subject to copyright.
Content uploaded by Michel Héon
Author content
All content in this area was uploaded by Michel Héon
Content may be subject to copyright.
TÉLÉ-UNIVERSITÉ DU QUÉBEC À MONTRÉAL
OntoCASE:
MÉTHODOLOGIE ET ASSISTANT LOGICIEL POUR UNE INGÉNIERIE
ONTOLOGIQUE FONDÉE SUR LA TRANSFORMATION D’UN MODÈLE
SEMI-FORMEL
THÈSE
PRÉSENTÉE
COMME EXIGENCE PARTIELLE
DU DOCTORAT EN INFORMATIQUE COGNITIVE
PAR
MICHEL HÉON
MARS 2010
ii
REMERCIEMENTS
Je désire offrir toute ma grattitude aux membres de ma famille. L’amour de ma vie,
Élisabeth Camus, sans qui cette thèse n’existerait pas. Toujours présente, supportante,
écoutante et encourageante, elle a su, dès les premiers moments, me soutenir,
m’accompagner dans ce long parcours. Cette thèse, c’est aussi un peu la sienne. Dans
ce cercle, je joins aussi mes deux fils, Frédérick et David, qui, par leur présence, ont
donné un sens à cette démarche. Finalement, je désire offrir des remerciements pleins
de tendresse à mon père Gustave et à ma mère Rita.
J'ai aussi beaucoup de reconnaissance pour mes deux directeurs de thèse, Gilbert
Paquette et Josianne Basque. Merci pour leur patience, leur rigueur et leur soutien
constant tout au long de mon cheminement.
Merci aussi à mes ami(e)s : Catherine Escojido ma relectrice de dernière instance,
Pierre-François Hébert, mon copain d’écoute et de présence, et tous les autres…
Thierry et Stéphanie, Kathleen Blair et Louis Dubeau, Gilles et Pascale, Jean-Claude,
Pascale et Alain, Mathieu et Tanya, Albert et Nancy, Yves, Émilie, Bruno et Brigitte,
Philippe et Catherine, Chantale et André, Carole Galland, Stéphanie Larrue, Annie et
Henry, Sylvie et Gary, Soizig et Nicolas, Christa et Julien, Michel et Marilianne,
André et Marie Camus et bien sûr, tous les autres, qui de près ou de loin ont fait
partie de mon parcours.
Une pensée pour Alphonse Grypinich et Léo Jolie.
Mes derniers remerciements vont aux organismes subventionnaires suivants, qui ont
appuyé financièrement cette recherche:
- Emploi-Québec en collaboration avec le centre local de développement (CLD)
d'Argenteuil. Tout particulièrement, M. Stéphane Braney;
iii
- Le fonds à l'accessibilité et à la réussite des études (Bourse FARE) de
l'UQAM;
- La chaire de recherche du centre de recherche LICEF de la TELUQ;
- Conseil de recherches en sciences naturelles et en génie du Canada (CRSNG)
qui finance le programme de recherche sur l'ingénierie ontologique et le Web
Sémantique (PRIOWS);
- Le fonds québécois de recherche sur la nature et les technologies (FQRNT).
iv
AVA NT-PROPOS
L'idée de cette thèse a émergé en 2003. À ce moment, j’étais architecte et concepteur
informatique pour Hydro-Québec. Dès cette époque, plusieurs signes de la
problématique de la perte d’expertise en entreprise commençaient à se manifester, en
raison notamment du départ à la retraite d’une couche importante d’employés de la
génération des Baby Boomers. Il m’apparaissait évident que l’informatique avait un
rôle à jouer dans la résolution de cette problématique et que le domaine des systèmes
experts était une voie à envisager. Par la nature de mon métier, j’étais aussi fasciné
par la représentation graphique de la réalité. L’idée de représenter des connaissances
de manière schématique était quelque chose qui me semblait porteur. Ayant été mis
au courant d’un projet de transfert d’expertise alors mené chez Hydro-Québec
(Basque, Paquette, Pudelko et Léonard, 2004), j’entrepris de me documenter sur le
projet et c’est ainsi que je découvris le langage de modélisation par objets typés
(MOT). J’ai été charmé par sa simplicité d’utilisation et par la puissance de son
expressivité. Parallèlement, les ontologies, l’Ontology Web Language (OWL) et ses
applications, faisaient leur apparition dans l’univers du Web. Le double volet
représentationnel et opérationnel d’une ontologie m’apparaissait comme une qualité
importante à exploiter dans l’éventualité de la conception d’un système expert.
L’idée à l’origine du projet de thèse était de développer un système expert pour la
conception de systèmes experts. Il s’agissait de construire une application
informatique dont la simplicité d’utilisation permettrait à une personne experte d’un
domaine de connaissances et possédant un minimum de connaissances en
programmation informatique de concevoir un système expert. C’est dans ce contexte
que je fis la connaissance du concepteur du langage MOT, Gilbert Paquette, ainsi que
de Josianne Basque, tout deux chercheurs au Centre de recherche LICEF de la Télé-
université, qui acceptèrent de me diriger pour la réalisation de cette thèse.
Progressivement, au fil des discussions, notamment par la précision des besoins en
conception d’ontologies par des non-initiés à la programmation informatique, le
v
projet s’est précisé pour se fixer sur la conception d’une méthodologie et d’un
assistant logiciel pour la transformation de modèles semi-formels en ontologies.
La figure ci-dessous présente le nuage des mots-clés de la thèse, qui comme on peut
le constater, met en évidence le domaine de la connaissance avec une multitude de
thèmes s’y rapportant. Ce nuage de mots-clés offre un survol des éléments de contenu
abordés dans la thèse.
Figure 1 : Nuage de mots-clés de la thèse.
Pour faciliter la lecture, nous avons segmenté la thèse en deux volumes. Le premier
comporte le développement de la thèse et le deuxième, ses appendices. À de multiples
endroits dans la thèse, nous avons appuyé nos explications par des schémas en
langage de modélisation par objets typés (MOT). Le lecteur, qui n’est pas familier
avec ce langage, peut consulter l’appendice A pour en apprendre les rudiments
d’utilisation.
Une version d’OntoCASE 1.0 sera éventuellement disponible sur le site
www.cotechnoe.com. Les diagrammes MOT de la thèse ont été édités avec l’éditeur
de modèles MOT eLi, qui est une composante d’OntoCASE. La préparation de la
thèse aura permis une mise à l’essai intensive d’eLi en vue d’en faire un produit
stable et robuste.
vi
TABLE DES MATIÈRES
REMERCIEMENTS .................................................................................................... II
AVANT-PROPOS ...................................................................................................... IV
TABLE DES MATIÈRES .......................................................................................... VI
LISTE DES FIGURES ............................................................................................. XVI
LISTE DES TABLEAUX ........................................................................................ XXI
RÉSUMÉ ............................................................................................................... XXV
VOLUME I
INTRODUCTION ........................................................................................................ 1
CHAPITRE 1 RECENSION DES ÉCRITS ................................................................. 8
1.1 Concept de représentation ....................................................................................... 8
1.1.1 Théorie des idées ........................................................................................... 9
1.1.2 Représentation dans un système d'information ........................................... 10
1.1.3 Sémiotique ................................................................................................... 11
1.1.4 Abstraction et couche d'abstraction ............................................................. 13
1.1.5 Généralisation et abstraction ....................................................................... 15
1.1.6 Modèle sémiotique de la synonymie et de la polysémie ............................. 16
1.1.7 Donnée, information et connaissance .......................................................... 18
1.1.8 Représentation des connaissances ............................................................... 19
1.1.9 Représentation des connaissances en sciences cognitives ........................... 20
1.2 Modélisation des connaissances ............................................................................ 22
vii
1.2.1 Langage ....................................................................................................... 22
1.2.2 Modèle ......................................................................................................... 23
1.2.3 Classification des langages de représentation des connaissances selon leur
degré de formalisme ............................................................................................. 24
1.2.4 Ontologies dans la perspective des sciences cognitives .............................. 25
1.3 Classification des ontologies ................................................................................. 29
1.3.1 Classification des ontologies selon la précision sémantique ....................... 30
1.3.2 Expressivité d’un système de représentation de degré formel .................... 31
1.3.3 Classification selon le degré de généralité du domaine représenté ............. 32
1.3.4 Ontologie et métadonnée ............................................................................. 33
1.3.5 Ontologie cadre ........................................................................................... 34
1.4 Langages semi-formels de représentation de la connaissance .............................. 38
1.4.1 MindMap ..................................................................................................... 39
1.4.2 Carte conceptuelle (Concept map) .............................................................. 40
1.4.3 Thinking Maps ............................................................................................. 41
1.4.4 Modèle orienté objet .................................................................................... 41
1.4.5 Modélisation par objets typés ...................................................................... 42
1.5 Langages formels de représentation de la connaissance ....................................... 44
1.5.1 Taxonomie et le thesaurus ........................................................................... 44
1.5.2 Langage de descriptions pour la représentation de connaissances .............. 45
1.5.3 Graphe conceptuel ....................................................................................... 47
1.5.4 Langage ontologique ................................................................................... 48
1.5.5 Langage à base de règles ............................................................................. 51
1.5.6 Business Process Modeling Notation .......................................................... 54
1.6 Transformation de modèles par la technique de métamodélisation ...................... 55
1.6.1 Abstraction et couches d'abstraction ........................................................... 55
1.6.2 Espace de modélisation ............................................................................... 57
1.6.3 Processus de transformation de modèles ..................................................... 58
1.6.4 Principe de transformation parallèle ............................................................ 60
viii
1.6.5 Principe de la transformation orthogonale .................................................. 61
1.6.6 Transformation d'un modèle semi-formel en ontologie .............................. 63
1.7 Ingénierie des connaissances................................................................................. 66
1.7.1 Structure de conception d'une méthodologie ............................................... 66
1.7.2 Élicitation des connaissances ...................................................................... 68
1.7.3 Méthodologies d'ingénierie ontologique ..................................................... 71
1.8 Environnements informatiques d'assistance à l’usager ......................................... 76
1.9 En résumé .............................................................................................................. 78
CHAPITRE 2 MÉTHODOLOGIE D’ONTOCASE ................................................... 79
2.1 Hypothèse .............................................................................................................. 79
2.2 Objectifs ................................................................................................................ 80
2.3 Produits de la recherche ........................................................................................ 81
2.3.1 Volets d'OntoCASE ..................................................................................... 81
2.3.2 Ontologie de transformation d'OntoCASE .................................................. 84
2.3.3 Portrait synthèse de la méthodologie d'OntoCASE ..................................... 85
2.4 Ontologie du langage semi-formel ........................................................................ 86
2.5 Ontologie de référence .......................................................................................... 86
2.5.1 Structure interne de l'ontologie de référence ............................................... 87
2.5.2 Entités de l'ontologie de référence ............................................................... 88
2.5.3 Relations du modèle de référence ................................................................ 91
2.6 Ontologie cadre en représentation des connaissances d’OntoCASE .................... 93
2.6.1 Ressources de l'ontologie cadre d’OntoCASE ............................................ 95
2.6.2 Propriétés de l'ontologie cadre d’OntoCASE .............................................. 96
2.6.3 L’ontologie cadre d’OntoCASE en OWL-N3 ............................................. 97
2.7 Méthodologie de conception d'une ontologie formelle à partir d'un modèle semi-
formel .......................................................................................................................... 97
2.7.1 Méthode de conception d'un modèle semi-formel....................................... 99
2.7.2 Méthode de formalisation en ontologie du domaine ................................. 101
ix
2.7.3 Méthode de validation de l'ontologie de domaine ..................................... 109
2.8 En résumé ............................................................................................................ 116
CHAPITRE 3 DÉMARCHE DE CONSTRUCTION D'ONTOCASE ..................... 118
3.1 Phase 1: Mise en place des composants représentationnels, procéduraux et
informatique de la méthodologie. ............................................................................. 122
3.1.1 Élaborer le processus de formalisation de l'ontologie ............................... 122
3.1.2 Choix du langage cible : l'Ontology Web Language ................................. 123
3.1.3 Choix du langage source: le langage de modélisation par objets typés MOT
............................................................................................................................ 124
3.1.4 Déterminer les catégories de l'ontologie de référence ............................... 130
3.1.5 Déterminer la structure de l'ontologie cadre .............................................. 134
3.1.6 Représenter de manière formelle le vocabulaire de MOT ......................... 135
3.1.7 Choix de l'environnement informatique .................................................... 146
3.1.8 Choix des outils informatiques associés à l'édition des ontologies ........... 153
3.2 Phase 2: Agrégation des composants ontologiques, procéduraux et informatiques
d'OntoCASE .............................................................................................................. 155
3.2.1 Développement du module d'édition ......................................................... 158
3.2.2 Développement du module d'importation ................................................. 160
3.2.3 Développement du module de traitement .................................................. 162
3.2.4 Développement du module de désambiguïsation ...................................... 163
3.2.5 Développement du module de conversion ................................................ 168
3.2.6 Développement du module de validation .................................................. 174
3.2.7 Développement des interfaces utilisateurs ................................................ 177
3.3 Phase 3: Consolidation ........................................................................................ 180
3.3.1 Cas de test .................................................................................................. 180
3.3.2 Concevoir le banc d'essais ......................................................................... 181
3.3.3 Concevoir et exécuter les cas de test ......................................................... 183
x
CHAPITRE 4 VALIDATION D’ONTOCASE ........................................................ 184
4.1 Modèle d’utilisabilité .......................................................................................... 185
4.2 Généralité des types de connaissances à formaliser et mesure de l'efficacité
d'OntoCASE .............................................................................................................. 187
4.2.1 Scénario de tests unitaires ......................................................................... 187
4.2.2 Scénario de tests d'intégration ................................................................... 189
4.2.3 Scénario de tests systèmes ......................................................................... 190
4.2.4 Scénario de tests du mécanisme de détection d'incohérence ..................... 192
4.3 Ergonomie d’OntoCASE .................................................................................... 192
4.3.1 Mécanismes visant à assurer l'efficience d'OntoCASE et la satisfaction de
l’usager ............................................................................................................... 193
4.3.2 Mécanisme de rétroaction d'OntoCASE .................................................... 193
4.3.3 Mécanisme de pilotage de l'ingénieur ....................................................... 194
4.3.4 Évaluation expérimentale de l’ergonomie d’OntoCASE .......................... 195
4.3.5 Déroulement du test d'utilisabilité ............................................................. 197
4.3.6 Modèle semi-formel d'expérimentation ..................................................... 198
4.3.7 Texte à modéliser en MOT et à formaliser ................................................ 199
4.3.8 Bilan et commentaires ............................................................................... 200
4.4 Généricité de la méthode de formalisation des systèmes semi-formels .............. 202
4.4.1 Métamodèle de MindMap .......................................................................... 202
4.4.2 Méthode d'intégration du langage MindMap à OntoCASE ....................... 205
4.4.3 Définition du langage semi-formel et production du scénario de test ....... 206
4.4.4 Concevoir l'ontologie du langage semi-formel.......................................... 207
4.4.5 Conception du module d'import/export ..................................................... 208
4.4.6 Adapter les ontologies ............................................................................... 209
4.4.7 Exécuter le scénario de test ....................................................................... 211
4.5 Conclusion .......................................................................................................... 213
CHAPITRE 5 CONCLUSION ET DISCUSSION ................................................... 215
xi
5.1 Réalisations ......................................................................................................... 215
5.2 Contributions ....................................................................................................... 219
5.2.1 Apports en représentation des connaissances ............................................ 219
5.2.2 Apports en ingénierie ontologique et aux applications du Web sémantique
............................................................................................................................ 221
5.2.3 Apports en gestion des connaissances ....................................................... 222
5.3 Limites de la recherche ....................................................................................... 223
5.3.1 Limites en représentation des connaissances ............................................ 223
5.3.2 Limites informatiques du prototype .......................................................... 224
5.3.3 Limites du volet méthodologique d’OntoCASE ....................................... 225
5.4 Perspectives ......................................................................................................... 225
5.4.1 Perspectives de développement et d’utilisation ......................................... 225
5.4.2 Perspectives en recherche sur la modélisation .......................................... 226
5.4.3 Perspectives en représentation des connaissances ..................................... 226
5.4.4 Perspectives en gestion des connaissances ................................................ 227
5.4.5 Perspective de recherche pour les Environnements Informatiques pour
l'Apprentissage Humain (EIAH) ........................................................................ 228
VOLUME II
APPENDICE A GUIDE DU LANGAGE DE MODÉLISATION PAR OBJETS
TYPÉS MOT ............................................................................................................. 230
A.1 Structure du langage MOT ................................................................................. 230
A.2 Alphabet du langage MOT ................................................................................. 231
A.3 Types des connaissances en MOT ..................................................................... 232
A.3.1 Alphabet de MOT associé aux types de connaissances ............................ 232
A.3.2 Sémantique de MOT associée aux types de connaissances ...................... 233
A.3.3 Stéréotype ................................................................................................. 234
A.4 Type de relations dans MOT .............................................................................. 234
A.4.1 Alphabet des relations .............................................................................. 234
xii
A.4.2 Sémantique des relations .......................................................................... 235
A.5 Sémantique des éléments grammaticaux du langage MOT ............................... 238
A.5.1 Composition .............................................................................................. 238
A.5.2 Spécialisation ............................................................................................ 239
A.5.3 Régulation ................................................................................................. 240
A.5.4 Instanciation .............................................................................................. 241
A.5.5 Intrant et le produit ................................................................................... 242
A.5.6 Précédence ................................................................................................ 242
A.5.7 Lien d’application ..................................................................................... 243
A.5.8 Propriété et l'attribut ................................................................................. 243
A.5.9 Règle ......................................................................................................... 244
A.6 Résumé ............................................................................................................... 245
APPENDICE B CATALOGUE DE LA SÉMANTIQUE FORMELLE DE MOT .. 246
B.1 Utilisation du catalogue ...................................................................................... 246
B.2 Entités atomiques d’OntoCASE ......................................................................... 247
B.3 Spécialisation et l’instance ................................................................................. 251
B.3.1 Spécialisation entre deux concepts, deux procédures et deux principes ... 251
B.3.2 Instanciation entre une abstraction et son observable ............................... 253
B.4 Intrant et le produit ............................................................................................. 255
B.4.1 Intrant-produit entre connaissances d’action et d’objet de niveau abstrait
............................................................................................................................ 255
B.4.2 Intrant-produit entre des connaissances d’action et d’objet observables .. 257
B.5 Régulation .......................................................................................................... 258
B.5.1 Régulation entre connaissances abstraites ................................................ 258
B.5.2 Interprétation de la régulation entre un énoncé et des observables d’objets,
de procédures et de principes. ............................................................................ 260
B.6 Propriété ............................................................................................................. 262
B.6.1 Définition d’un domaine et d’une image à une propriété entre des objets 262
xiii
B.6.2 Propriétés unaires ...................................................................................... 264
B.6.3 Exemple de représentation en langage MOT ............................................ 264
B.7 Composition entre connaissances ....................................................................... 265
B.7.1 Holonyme entre deux abstractions ............................................................ 265
B.7.2 Composition entre deux connaissances observables ................................ 267
B.7.3 Composition entre des connaissances de niveau d’abstraction différent .. 269
B.8 Attribut de connaissances déclaratives ............................................................... 271
B.9 Lien de précédence ............................................................................................. 274
B.9.1 Relation de précédence entre connaissances d’actions ............................. 274
B.9.2 Précédence entre connaissances d’actions et stratégique ......................... 275
B.10 Règle ................................................................................................................. 278
B.10.1 Règle à partir de connaissances abstraites .............................................. 278
B.10.2 Règle à partir de connaissances factuelles .............................................. 281
B.11 Connaissance qui englobe des connaissances .................................................. 284
APPENDICE C CATALOGUE DES COHÉRENCES DE L'ONTOLOGIE CADRE
D'ONTOCASE .......................................................................................................... 287
C.1 Axiomes d'identification des erreurs de cohérences ........................................... 287
C.2 Règles de génération des erreurs ........................................................................ 293
APPENDICE D SCÉNARIOS DE CAS DE TESTS ............................................... 295
D.1 Scénario de tests unitaires .................................................................................. 295
D.2 Scénario de tests fonctionnels ............................................................................ 299
D.3 Scénario de tests systémiques ............................................................................ 303
D.3.1 Scénarios de tests systémiques issus de l'expérimentation ....................... 304
D.3.2 Scénarios de tests systémiques issus d'ouvrage en modélisation ............. 306
D.4 Scénarios de tests d'incohérences ....................................................................... 313
APPENDICE E ÉLÉMENTS POUR GUIDER LA MODÉLISATION SEMI-
FORMELLE À L’AIDE DE CONCEPTS ONTOLOGIQUES .............................. 317
xiv
E.1 Métamodèle MOT d'OWL .................................................................................. 317
E.1.1 Ressource .................................................................................................. 318
E.1.2 Concept de classe ...................................................................................... 319
E.1.3 Propriété .................................................................................................... 320
E.1.4 Relations .................................................................................................... 321
E.2 La notation N3 .................................................................................................... 322
E.3 Heuristiques de modélisation .............................................................................. 323
E.3.1 Polysémie .................................................................................................. 323
E.3.2 Modéliser selon le bon niveau d’abstraction ............................................. 324
E.3.3 Représentation d'un attribut ...................................................................... 328
E.3.4 Désambiguïser la synonymie d'agrégation ................................................ 329
E.3.5 Résumé ...................................................................................................... 331
APPENDICE F CODE SOURCE ............................................................................. 332
F.1 Base de règles de la désambiguïsation typologique ............................................ 332
F.2 Base de règles de la désambiguïsation topologique ............................................ 343
F.3 Base de règles de transformation: état initial ...................................................... 346
F.4 Base de règles de transformation: état création .................................................. 346
F.5 Base de règles de transformation: état classification .......................................... 351
F.6 Base de règles de transformation: état final ........................................................ 359
F.7 Base de règles de transformation: état validation ............................................... 359
F.8 Ontologie du langage semi-formel MOT ............................................................ 359
F.9 Ontologie du traitement des ambiguïtés ............................................................. 362
F.10 Ontologie de référence ...................................................................................... 364
F.11 Ontologie cadre en représentation des connaissances d’OntoCASE ................ 367
F.12 Ontologie de transformation ............................................................................. 369
F.13 Bibliothèque de codes Java nécessaire à l'implantation du modèle de conception
commande ................................................................................................................. 383
F.13.1 Structure de la built-in command swrlbi.owl .......................................... 383
xv
F.13.2 Implantation de SWRLBuiltInLibraryImpl.java ..................................... 384
F.13.3 Interface Command.java ......................................................................... 385
F.13.4 Interface Receiver.java ............................................................................ 385
F.13.5 Interface Invoker.java .............................................................................. 385
F.13.6 Implantation InvokerImpl.java ................................................................ 385
F.14 Quelques implantations de Receiver ................................................................. 385
F.14.1 Implantation de CreerUneOntologieCmdReceiver.java ......................... 385
F.14.2 Implantation de OWLCreerUneClasseCmdReceiver.java ...................... 386
F.14.3 Implantation de
OWLAjoutDuneProprieteEntreResourceCmdReceiver.java ............................. 386
APPENDICE G ÉVALUATION EXPÉRIMENTALE ............................................ 388
G.1 Protocole d’expérimentation .............................................................................. 389
G.2 Certificat d’éthique ............................................................................................. 392
G.3 Réponse commentée des participants ................................................................. 393
G.3.1 Réponse commentée du participant 1 (d’après son verbatim) .................. 393
G.3.2 Réponse commentée du participant 2 (d’après son verbatim) ................. 396
G.3.3 Réponse commentée du participant 3 (d’après le verbatim) .................... 397
G.3.4 Réponse commentée du participant 4 (d’après le verbatim) .................... 399
BIBLIOGRAPHIE .................................................................................................... 404
xvi
LISTE DES FIGURES
Figure 1.1: L'objet et son abstraction: l'idée ................................................................ 9
Figure 1.2: Le modèle de la représentation d'un domaine dans un système
d'information. (Tirée et adaptée d'Olivé, 2007 p. 46) ............................. 10
Figure 1.3: Tableau La trahison des images, Magritte 1929. (Tirée de Paquet,
2006, p. 9) ............................................................................................... 11
Figure 1.4: Le triangle sémiotique. ............................................................................ 12
Figure 1.5: Exemple d'un triangle sémiotique associé à la conceptualisation du
chien Bahia. ............................................................................................. 12
Figure 1.6: Les deux mystères. (Magritte 1966) ........................................................ 14
Figure 1.7: Le concept d'abstraction représenté à partir du triangle sémiotique. ....... 15
Figure 1.8 : Le modèle sémiotique représenté en MOT. ............................................ 16
Figure 1.9 : Exemple de synonymie entre 4 et quatre. .............................................. 17
Figure 1.10 : Exemple de polysémie du mot feu. ....................................................... 17
Figure 1.11: Donnée, information et connaissances dans le modèle sémiotique. ...... 18
Figure 1.12: Le métaconcept de représentation des connaissances. .......................... 19
Figure 1.13: Modèle cognitif de la représentation des connaissances. (Tirée de
Helbig, 2006, p. 8) ................................................................................... 20
Figure 1.14: Langage de modélisation. ...................................................................... 23
Figure 1.15: Positionnement constructiviste de la définition d’ontologie. ................ 26
Figure 1.16: Définition d'une ontologie en informatique. .......................................... 29
Figure 1.17: Échelle de classification d'ontologies en fonction du spectre
sémantique de McGuiness. (Tirée de Breitman et al., 2007, p. 26) ........ 31
Figure 1.18: Taxonomie des classes de haut niveau dans SUMO-OWL. .................. 35
Figure 1.19: Taxonomie de patrons de conception ontologique du projet NeOn.
(Tirée de ODP.org, 2008) ........................................................................ 37
Figure 1.20: Exemple de schéma MindMap. (Tirée de Okada et al, 2008, p. xi) ...... 39
Figure 1.21: Exemple de modèle représenté dans le formalisme Concept map.
(Tirée d'Okada et al, 2008, p.xi) ............................................................. 40
Figure 1.22: Synthèse du langage des Thinking Maps. (Tirée de Hyerle 2008, p.
50) ........................................................................................................... 41
xvii
Figure 1.23: Diagramme de classes UML pour représenter un arbre de décision.
(Tirée de Rhem 2006, p. 181) ................................................................. 42
Figure 1.24: Métamodèle du langage MOT présenté dans le langage MOT.
(Tirée de Paquette 2002, p. 73) ............................................................... 43
Figure 1.25: Illustration d’un graphe conceptuel tel que proposé par Sowa. (Tirée
de Chein et Mugnier, 2008, p. 26.) ......................................................... 47
Figure 1.26: Évolution des langages ontologiques. (Tirée de Calero et al., 2006,
p. 37) ....................................................................................................... 49
Figure 1.27: Métamodèle UML du Semantic Web Rule Language. (Tirée de
Brockmans et al., 2006,p. 9). .................................................................. 53
Figure 1.28: Éléments d'un modèle BPMN. (Tirée de Weske, 2007, p. 209) ............ 54
Figure 1.29: Exemple de réseau de Pétri pour représenter un workflow. (Tirée de
Weske, 2007, p. 271) ............................................................................... 55
Figure 1.30: Couches d'abstraction de la métamodélisation. ..................................... 56
Figure 1.31: Espaces de modélisation EBNF, RDFS et MOF adaptée de Gašević
et al. (2006e p. 132). ............................................................................... 57
Figure 1.32: Processus de transformation de modèles dans l’OMG-MDA. .............. 59
Figure 1.33: Processus de transformation parallèle. .................................................. 60
Figure 1.34: Processus de transformation orthogonale. ............................................. 61
Figure 1.35: Modèle du processus de transformation orthogonale. ........................... 62
Figure 1.36 : La modélisation d’ontologie dans le contexte de l’ACM et du Web
sémantique. (Tirée de Gašević et al., 2006c, p. 175) .............................. 64
Figure 1.37: Modèle MOT de la définition d'une méthodologie. (Tirée et adaptée
en MOT de Gómez-Pérez et al., 2003, p. 109) ....................................... 68
Figure 1.38: Le cycle des connaissances dans MASK. (Tirée d'Ermine et Matta,
2003, p. 8) ............................................................................................... 69
Figure 1.39: Processus de développement d'une ontologie. (Tirée de Gómez-
Pérez et al.2003, p. 110). ......................................................................... 71
Figure 1.40: Processus de développement d’une ontologie On-To-Knowledge.
(Tirée de Staab et al. 2001) ..................................................................... 72
Figure 1.41: Cycle de vie du processus de développement d'ontologie de
METHONTOLOGY. (Tirée de Gómez-Pérez et al., 2003, p.127) ......... 73
Figure 2.1: Positionnement d'OntoCASE en fonction des degrés de formalisation
et classification d’exemples de formalisme. ........................................... 80
xviii
Figure 2.2: Volets méthodologique, computationnel et représentationnel
d'OntoCASE. ........................................................................................... 83
Figure 2.3: Architecture de l'ontologie de transformation. ........................................ 84
Figure 2.4: Principe de transformation guidée par l'ontologie de référence. ............. 87
Figure 2.5: Ontologie cadre de la biologie. ................................................................ 94
Figure 2.6: Exemple de classification avec L’ontologie cadre d’OntoCASE. ........... 95
Figure 2.7: Modèle de la méthodologie de conception d'une ontologie à partir
d'un modèle semi-formel. ........................................................................ 98
Figure 2.8: Méthode de conception d'un modèle semi-formel. .................................. 99
Figure 2.9: Méthode de formalisation d'un modèle semi-formel en ontologie du
domaine. ................................................................................................ 101
Figure 2.10: Méthode de validation de l'ontologie du domaine. .............................. 110
Figure 2.11: Processus de validation syntaxique. .................................................... 111
Figure 2.12: Processus de validation sémantique. ................................................... 112
Figure 3.1: Objets et activités de la démarche de construction d’OntoCASE. ....... 121
Figure 3.2: Représentation taxonomique des classes et propriétés de l'ontologie
cadre. ..................................................................................................... 135
Figure 3.3: Modèle procédural EMF de production de code source Java à partir
d'une conceptualisation. ........................................................................ 148
Figure 3.4: Modèle ecore de la structure de donnée d'eLi pour la modélisation en
langage MOT. ....................................................................................... 150
Figure 3.5: Processus de construction d'un éditeur graphique GMF. (Tirée du
GMF Tutorial 2009d) ............................................................................ 152
Figure 3.6: Les composants de l'application OntoCASE. ........................................ 156
Figure 3.7: Relations entre les modules de l'application et les méthodes
d'OntoCASE. ......................................................................................... 157
Figure 3.8: Interface utilisateur de l'application OntoCASE. .................................. 158
Figure 3.9: Processus de conception du programme Eli2OWL.java. ....................... 161
Figure 3.10: Modèle du processus de conception du module de
désambiguïsation. .................................................................................. 163
Figure 3.11: Développer le module de conversion de l'ontologie du modèle semi-
formel désambiguïsé en ontologie du domaine. .................................... 168
Figure 3.12: Relations et utilisations d'un invocateur, d'une commande et d'un
receveur. ................................................................................................ 169
xix
Figure 3.13: Sous-processus et ontologies impliqués dans la création de
l'ontologie du domaine. ......................................................................... 172
Figure 3.14: Modèle procédural du développement du module de validation. ........ 175
Figure 3.15: Interfaces de communication avec l'utilisateur. ................................... 177
Figure 3.16: Le tableau de bord à la formalisation. ................................................. 179
Figure 3.17: Le tableau de bord à la validation. ....................................................... 180
Figure 3.18: Exécution d'un cas de test pour la mesure d'efficacité d'OntoCASE. . 182
Figure 4.1: Modèle semi-formel d'expérimentation: l’Objet céleste. ...................... 199
Figure 4.2: Texte présenté lors de la phase 3 de l’expérimentation. ........................ 200
Figure 4.3: Métamodèle ecore du langage MindMap. (Tirée de Reitsma et al.,
2008). .................................................................................................... 204
Figure 4.4: Méthode d'intégration d'un nouveau langage source à OntoCASE. ...... 205
Figure 4.5: Modèles MindMap sur le thème de l'automobile et le thème de la
rédaction d'une thèse. ............................................................................ 207
Figure 4.6: Structure de l'ontologie de transformation après l'intégration des
éléments structurels nécessaires à la transformation d'un modèle
MindMap. .............................................................................................. 210
Figure 4.7: Restauration dans le formalisme de MOT du thème de l'automobile
(a) et de la rédaction d'une thèse (b). ..................................................... 213
Figure A.1 : Structure générale d’un langage. ......................................................... 230
Figure A.2 : Structure de l’alphabet de MOT. ......................................................... 231
Figure A.3: Représentation des connaissances en langage MOT. ........................... 233
Figure A.4: Représentation de la procédure P dont le stéréotype une méthode. ..... 234
Figure A.5: Hiérarchie des relations typées utilisées en langage MOT et leur
représentation dans l'ontologie du langage semi-formel. ...................... 235
Figure B.1:La représentation en UML des différentes valeurs possibles des
entités d’OntoCASE. ............................................................................. 248
Figure B.2 : Exemple de définition des entités atomiques de MOT et leur
stéréotype de désambiguïsation possible............................................... 248
Figure E.1: Hiérarchie des concepts de haut niveau d'OWL selon ODM. ............... 318
Figure E.2: Hiérarchie des classes d'OWL. .............................................................. 319
Figure E.3: Hiérarchie des propriétés d'OWL. ......................................................... 320
Figure E.4: Relations unissant les divers concepts d'OWL. .................................... 321
xx
Figure E.5: Représentation en OWL-N3 de l'énoncé: la pomme, qui est un Fruit,
est de couleur rouge. ............................................................................. 322
Figure G.1 : Structure de chaque réponse commentée. ............................................ 393
xxi
LISTE DES TABLEAUX
Tableau 1.1 Expressivité de divers systèmes de représentation formels ................... 31
Tableau 1.2 Éléments du Dublin Core (tirée de Breitman et al., 2007, p. 178) ......... 34
Tableau 1.3 L'ontologie de KR (Tirée de Sowa, 2003) ............................................. 36
Tableau 1.4 Exemple d’une base de connaissances en DL (inspiré de Baader et
al., 2004) ................................................................................................. 46
Tableau 1.5 Constructeurs de la DL et leur correspondance langagière (tirée de
Gómez-Pérez et al., 2003, p. 17) ............................................................. 46
Tableau 1.6 Sommaire des caractéristiques des langages ontologiques (adapté de
Gómez-Pérez et al., 2003, p. 286) ........................................................... 50
Tableau 1.7 Sommaire comparatif du processus de développement d'ontologies
(extrait de Gómez-Pérez et al., 2003, p.151) .......................................... 75
Tableau 2.1 Méthodes, techniques et outils de la méthodologie OntoCASE ............ 85
Tableau 2.2 Structure de classes de l’ontologie du langage semi-formel .................. 86
Tableau 2.3 Catégorie des entités du modèle de référence ........................................ 89
Tableau 2.4 Catégorie des entités et leur couleur correspondante ............................. 89
Tableau 2.5 Exemple de représentation d'une règle em MOT ................................... 91
Tableau 2.6 Catégorie des relations du modèle de référence ..................................... 92
Tableau 2.7 Ressources de l'ontologie cadre d’OntoCASE ....................................... 96
Tableau 2.8 Propriétés de l'ontologie cadre d’OntoCASE ......................................... 97
Tableau 2.9 Études de cas représentés en langage MOT et en langage OWL-N3. .. 105
Tableau 2.10 Modèle semi-formel formalisé en OWL-N3 ...................................... 108
Tableau 2.11 L’Objet céleste: le modèle semi-formel et son interprétation
possible en langage naturel ................................................................... 113
Tableau 2.12 Bilan du rapport de validation syntaxique du modèle L’Objet
Céleste ................................................................................................... 114
Tableau 2.13 Rapport de validation sémantique généré par OntoCASE ................. 115
Tableau 3.1 Représenter une agrégation en MOT ................................................... 125
Tableau 3.2 Représenter l'utilisation d'un instrument en MOT ............................... 126
Tableau 3.3 Représenter selon le niveau d'abstraction en MOT .............................. 127
Tableau 3.4 Interprétation formelle de la règle brûler des déchets .......................... 128
xxii
Tableau 3.5 Représenter un attribut en MOT ........................................................... 129
Tableau 3.6 Polysémie de MOT............................................................................... 130
Tableau 3.7 Vocabulaire du langage MOT .............................................................. 131
Tableau 3.8 Vocabulaire du diagramme UML de classes (tiré de Rhem, 2006) ..... 132
Tableau 3.9 Vocabulaire du diagramme UML de cas d'utilisation (tiré de Rhem,
2006) ..................................................................................................... 132
Tableau 3.10 Vocabulaire du diagramme UML d'état (tiré de Rhem, 2006) ........... 132
Tableau 3.11 Vocabulaire du diagramme BPMN (tiré de OMG BPDM, 2007 ;
Weske, 2007) ......................................................................................... 132
Tableau 3.12 Classification des entités des divers langages pour chacune des
catégories d'entités de l'ontologie de référence ..................................... 133
Tableau 3.13 Classification des relations de divers langages pour chacune des
catégories de langage de l'ontologie de référence ................................. 134
Tableau 3.14 Correspondance formelle de représentations MOT des
connaissances déclaratives .................................................................... 137
Tableau 3.15 Correspondance formelle de représentations MOT des
connaissances procédurales ................................................................... 139
Tableau 3.16 Correspondance formelle de représentations MOT des
connaissances stratégiques .................................................................... 140
Tableau 3.17 Correspondance formelle de représentations MOT des
connaissances mixtes ............................................................................ 141
Tableau 3.18 Correspondance formelle de représentations MOT des
connaissances mixtes associées par un lien de régulation ..................... 142
Tableau 3.19 Correspondance formelle de représentations MOT des
connaissances mixtes pour la formation d'une règle produisant une
conclusion ............................................................................................. 144
Tableau 3.20 Correspondance formelle de représentations MOT des
connaissances mixtes pour la formation d'une règle résultant de
l'exécution d'une opération .................................................................... 145
Tableau 3.21 Représentation MOT, XMI et OWL-N3 de Bahia est un Berger
Allemand qui est une sorte de Chien. .................................................... 159
Tableau 3.22 Ontologie cadre (OWL) du vocabulaire de MOT [a) et b)], et
exemple d'importation en OWL-N3 d'un modèle MOT-XMI [c)] ......... 162
Tableau 3.23 Structure de l'ontologie de traitement des ambiguïtés ........................ 165
xxiii
Tableau 3.24 Règle de désambiguïsation topologique dans le cas d’un principe
lié par lien R d’un concept (domaine) à un autre (codomaine) ............. 166
Tableau 3.25 Exemple d'implantation d'une commande Java appelée lors du
déclenchement d'une règle SWRL ........................................................ 171
Tableau 3.26 Axiomes et règles impliqués dans la conversion d'une
spécialisation entre deux concepts ........................................................ 173
Tableau 3.27 Exemple de rapport complet de validation syntaxique ..................... 176
Tableau 4.1 Structure de présentation des divers cas de test unitaires. .................... 187
Tableau 4.2 Quelques cas de test unitaire ................................................................ 188
Tableau 4.3 Quelques cas de tests d'intégration ....................................................... 189
Tableau 4.4 Quelques cas de tests systèmes ........................................................... 191
Tableau 4.5 Icônes de rétroaction des ambiguïtés et des erreurs d’incohérence ..... 194
Tableau 4.6 Ontologie du langage MindMap dans le formalisme OWL-N3 ........... 207
Tableau 4.7 Représentation XMI (a) et OWL (b) du modèle MindMap sur le
thème de l'automobile ........................................................................... 209
Tableau 4.8 Règles de conversion pour un hyperonyme ......................................... 211
Tableau 4.9 Rapport de validation sémantique ........................................................ 212
Tableau A.1 Type de connaissances dans le langage MOT et leur symbole
associé. .................................................................................................. 234
Tableau A.2 Sémantique des relations typées dans MOT (adapté de Paquette
2002b, 2010) ......................................................................................... 236
Tableau A.3 Grammaire des relations MOT (adapté de Paquette 2002b) ............... 237
Tableau A.4 Exemple de représentation d'une composition entre connaissances ... 238
Tableau A.5 Exemple de représentation de la spécialisation de connaissances ...... 239
Tableau A.6 Exemple de représentation d'une régulation entre des connaissances . 240
Tableau A.7 Exemple de représentation de l'instanciation entre une connaissance
abstraite et un connaissance factuelle ................................................... 241
Tableau A.8 Exemple représentation d'un intrant et d'un produit entre une
connaissance procédurale et une connaissance conceptuelle ................ 242
Tableau A.9 Exemple de représentation de la préséance ......................................... 242
Tableau A.10 Exemple de représentation d'un lien d'application ............................ 243
Tableau A.11 Exemple de représentation d'un attribut et d'une propriété ............... 244
Tableau A.12 Exemple de représentation d'une règle .............................................. 245
xxiv
Tableau B.1 Structure de chaque élément du catalogue .......................................... 246
Tableau B.2: Tableau des règles concernant chaque relation légale en MOT
combiné au numéro de page de l'interprétation ..................................... 247
Tableau C.1 Axiomes d'identification des incohérences ......................................... 288
Tableau C.2 Règles de génération des erreurs ......................................................... 294
Tableau D.1 nom du test, modèle d'origine et bilan du scénario de test unitaire ..... 296
Tableau D.2 nom du test, modèle d'origine et bilan du scénario de test
fonctionnel ............................................................................................. 300
Tableau D.3 Scénario de test systémique: Le système solaire ................................. 304
Tableau D.4 Scénario de test systémique: La gestion des déchets .......................... 305
Tableau D.5 Scénarios de test d'incohérences ......................................................... 314
Tableau E.1 Polysémie de MOT .............................................................................. 324
Tableau E.2 Représenter selon le niveau d'abstraction en MOT ............................. 326
Tableau E.3 Interprétation formelle de la règle d'incinération des déchets ............. 327
Tableau E.4 Représenter un attribut en MOT .......................................................... 328
Tableau E.5 Représenter une agrégation en MOT ................................................... 329
Tableau E.6 Interprétation formelle des modèles semi-formels du tableau e.5 ....... 330
Tableau E.7 Test de complétude pour les modèles du tableau e.5 ........................... 331
xxv
RÉSUMÉ
Concevoir une ontologie formelle demande une expertise certaine, qui est la plupart
du temps, peu accessible à des experts de contenu. En revanche, de plus en plus
d'experts utilisent la modélisation semi-formelle pour représenter leur expertise, car
ce type de langage est notamment reconnu pour sa simplicité d'utilisation et sa
capacité à représenter des connaissances de types déclaratifs, procédurales,
stratégiques et factuels. La modélisation semi-formelle, qui peut constituer une
première démarche dans la mise en place d'une mémoire d'entreprise, n'élimine en
rien la nécessité de représenter formellement la connaissance, obligeant ainsi à mettre
en oeuvre une étape de formalisation du modèle semi-formel. Nous avons conçu une
méthodologie de transformation d'un modèle semi-formel en ontologie et développé
un assistant logiciel qui semi-automatise, ou automatise les processus de la
méthodologie de transformation. La démarche de conception de la méthodologie et de
son assistant informatique se divise en trois phases: 1) la phase de Mise en place des
composants architecturaux, procéduraux et informatiques de la méthodologie est la
phase initiale de la démarche; 2) la phase d'Agrégation des composants ontologiques,
procéduraux et informatiques est la phase de développement et d'harmonisation des
modules de l'assistant aux processus de la méthodologie; 3) la phase de confirmation
est l'étape de tests et de raffinement de la fonctionnalité, de l'assistant informatique et
de la méthodologie. Quatre champs disciplinaires sont concernés par cette thèse: en
gestion des connaissances, notre approche offre une méthode de formalisation de la
connaissance fondée sur une représentation semi-formelle de la connaissance; en
ingénierie ontologique, nos travaux offrent un cadre architectural et procédural qui
formalise et instrumente le processus de construction d'une ontologie à partir d'une
représentation semi-formelle des connaissances; en représentation des connaissances,
notre thèse approfondit l'étude d'une catégorisation formelle de la représentation des
connaissances qu'elles soient déclaratives, procédurales, stratégiques ou factuelles; et
finalement, d'un point de vue informatique, cette recherche présente une architecture
xxvi
et des outils informatiques qui formalisent et rendent exécutable le processus de
transformation.
Mots-clés: Ingénierie ontologique, système expert à la formalisation, représentation
de connaissances, architecture conduite par les modèles, modélisation semi-formelle,
modélisation d'ontologie, transformation d'un modèle semi-formel en ontologie.
INTRODUCTION
Dans le contexte actuel du vieillissement de la population, les organisations sont de
plus en plus confrontées à une problématique de rétention de leur culture d'entreprise
et des savoirs spécifiques à leur domaine d'intervention. Que ce soit sur le plan des
processus organisationnels ou des connaissances liées au domaine d'activité, les
départs massifs à la retraite des employés risquent d'handicaper fortement les
organisations. On n’a qu'à penser à la problématique actuelle du système de santé
dont l'une des composantes identifiées et reconnues a été la mise à la retraite massive
des infirmières et des médecins dans les années 1990. Même quand le départ des
employés n’est pas forcé, comme ce fut le cas pour les infirmières, le problème de
perte d'expertise risque fort de mettre en péril, dans les années à venir, l'efficacité des
organisations selon le comité de travail sur l'intégration des jeunes à la fonction
publique québécoise (2001). La mise en place de stratégies de « gestion de
connaissances » (Knowledge Management) s'impose donc rapidement puisque la
qualité des services offerts par les organisations en dépend.
De surcroît, le contexte économique des années 1980-1990 n'a pas favorisé
l'embauche des jeunes de cette époque. Pour les organisations, cette situation restreint
l’accès à une relève pouvant assurer la pérennité d’un savoir de terrain durement
acquis. Elle force la mise en place de politiques d'embauche massive de jeunes. Par
exemple, le Comité de travail sur l'intégration des jeunes à la fonction publique
québécoise (2001) évalue le pourcentage des moins de 35 ans à 6,9% en 2001, à
13,4% en 2006 et à 20,3% en 2011. Cet état de fait impose aux organisations la mise
en place de politiques et stratégies visant à assurer la formation efficiente de la relève.
Selon la proposition d’Apostolou, Mentzas, Young et Abecker (2000), la gestion des
connaissances en entreprise peut se réaliser selon deux approches, soit une approche
centrée processus ou une approche centrée produit. L'approche centrée processus
valorise les échanges directs entre les personnes expertes et les personnes apprenantes
2
pour l'échange de connaissances. Le processus de communication sociale est au
centre de celle-ci. Quant à l'approche centrée produit, qui nous intéresse plus
particulièrement dans cette thèse, elle valorise la production de documents et
l'entreposage des connaissances organisationnelles dans des systèmes informatiques.
Elle vise à constituer la « mémoire » de l'organisation. Le besoin de rendre les
connaissances le plus accessibles possible à l’ensemble des employés impose
l'utilisation d'un système de codification de l'information pour maximiser cette
accessibilité. La codification doit se faire au niveau sémantique, ce que l’ingénierie
ontologique, appuyée par la technologie du Web sémantique, permet de faire.
Cette thèse se situe à l’intersection de plusieurs domaines: la gestion des
connaissances, l'élicitation des connaissances, la représentation des connaissances,
l'ingénierie ontologique et l'assistance automatisée à la conception d'artéfacts
logiciels. Ces domaines doivent être considérés dans l’utilisation du Web pour traiter
la sémantique des connaissances, au-delà de la syntaxe des termes qui figurent dans
les pages ou les documents diffusés sur le Web.
L'avènement du Web sémantique procure aux gestionnaires de la connaissance un
langage standardisé qui permet de représenter les connaissances sous la forme d'un
modèle que l'on nomme ontologie, ainsi qu'un ensemble d'outils qui permet de
manipuler les connaissances représentées dans l'ontologie. Une ontologie utilise un
langage formel, c'est-à-dire utilisable par un logiciel, qui se présente sous la forme
d'un fichier définissant les concepts, les propriétés, les axiomes et les faits concernant
un domaine.
Concevoir une ontologie est une activité complexe, qui nécessite notamment la
participation de ceux qui détiennent l’expertise dans l’organisation. On pourrait
croire, en pensant économiser temps et énergie, qu’il est préférable d’éliciter les
connaissances de ces experts directement dans une représentation de type
ontologique. Nous pensons au contraire que le processus de conception d’une
3
ontologie gagne à être décomposé en au moins deux étapes bien distinctes: une étape
d’élicitation des connaissances dans un formalisme semi-formel relativement évolué
qui optimise l’expressivité tout en structurant la représentation explicitée à un premier
niveau de formalisme, puis une étape de formalisation plus poussée des
connaissances, où le modèle semi-formel est transformé dans un formalisme
ontologique. Bien qu'un modèle semi-formel contienne toujours des éléments
d'ambigüité, sa souplesse d’expression, surtout lorsqu’il fait appel à un format
graphique, permet d’accéder plus facilement à l’identification des connaissances
tacites des experts. Dans un tel cadre, la spontanéité n’est pas bloquée par une charge
cognitive trop lourde associée à une formalisation poussée de la pensée (Basque et
al., 2008b). Nous pensons que l’usage d’un système de représentation plus convivial
que les systèmes de représentation ontologique, tels ceux utilisés dans les éditeurs
d'ontologies Protégé1 ou TopBraid2, pourrait permettre: (1) d’élargir le bassin des
personnes aptes à contribuer activement aux premières étapes de la représentation de
leurs connaissances, et ce, sans l’aide d’un ingénieur des connaissances;
(2) d'économiser du temps lors de l’élicitation des connaissances des experts, les
libérant ainsi plus rapidement pour la réalisation de leur travail habituel.
La stratégie de co-modélisation des connaissances, qui amène de petits groupes
d’employés à représenter leurs connaissances à l’aide d’un langage graphique semi-
formel et qui a été expérimentée par Basque et al. (2008b), s’accorde bien à l’aspect
consensuel de la définition d'ontologie fournie par Gruber (1993a) et ajustée par Borst
(1997) : « An ontology is a formal, explicit specification of a shared
conceptualization.» Cette activité nous semble ainsi pouvoir être mise à profit aux
premières étapes de la conception d'une ontologie. Ainsi, nous pensons que le
processus de construction d’une ontologie doit être décomposé en trois phases bien
distinctes: une phase d’élicitation de la connaissance dans un formalisme de degré
1 Protégé Home Site, Welcome to protégé: http://protege.stanford.edu/
2 TopQuadrant, TopBraid Composer (TM): http://www.topquadrant.com/products/TB_Composer.html
4
semi-formel relativement évolué, une phase de formalisation des connaissances où le
modèle semi-formel est transformé dans un formalisme ontologique, puis une phase
de validation qui assure la cohérence syntaxique et sémantique (par rapport au
domaine de connaissances ciblé) de l'ontologie produite. C’est l’ensemble de ce
processus qu'OntoCASE, une méthodologie instrumentée d’un assistant logiciel qui
est présentée dans cette thèse, vise à soutenir.
Les avancées des dernières années en représentation des connaissances ainsi qu'en
intelligence artificielle, notamment celles qui sont associées au Web sémantique, ont
permis d'accroître la disponibilité et l'accessibilité des outils informatiques
intelligents et puissants. Nous pensons que le développement d'une méthodologie
comme celle développée ici doit inclure l'intégration de tels outils pour faciliter
l'utilisation des méthodes et des techniques qui la composent, la rendant ainsi plus
efficiente.
La modélisation est une activité importante dans plusieurs méthodologies de
développement de logiciels. Qu'il s'agisse de la représentation de cas d'utilisations, de
fonctionnalités de logiciels, de la structure de déploiement des modules de logiciels,
de structures de classes pour la génération automatique de codes sources, le modèle
issu de l'activité de modélisation est un artéfact au cœur du processus de génie
logiciel. Or, ce modèle est de type représentationnel, c'est-à-dire que la principale
fonction du modèle est de représenter « quelque chose » alors que l'opérationnalité
(qui est la propriété d'exécuter des opérations ou des commandes) est concrétisée par
la génération du code source à partir du modèle. Une caractéristique importante de
cette façon de faire est que le modèle et le code source qui lui correspond forment
deux artéfacts distincts. Cette distinction occasionne parfois des problèmes de
synchronicité entre le modèle et le code source puisque les deux peuvent évoluer de
façon indépendante.
5
En informatique, on peut considérer l'ontologie comme une sorte de conceptualisation
d'un domaine qui inclut une fonctionnalité à la fois représentationnelle et
opérationnelle, c'est-à-dire que l'ontologie sert à représenter « quelque chose » et
permet l'exécution automatique de commandes informatiques. Ainsi, l'expression des
ces deux fonctionnalités soutenue par un seul artéfact, comme le propose OntoCASE,
offre plusieurs avantages. D'une part, elle permet une synchronisation en temps réel
de l'une et l'autre des fonctionnalités selon que l'on modifie l'ontologie pour des
raisons de représentationnalité ou pour des raisons d'opérationnalité et, d'autre part,
l'ontologie, de par sa nature représentationnelle, constitue un document de référence
compréhensible.
OntoCASE apporte des solutions concrètes et fonctionnelles aux problématiques
organisationnelles exposées plus haut et qui vont être développées dans cette thèse.
Ce travail a déjà été présenté dans des congrès scientifiques (Héon, Basque et al.,
2010 ; Héon, Paquette et al., 2008, 2009a, 2009b) et dans un chapitre de livre dédié à
la modélisation des connaissances à paraître en 2010 (Héon et Paquette).
Cette thèse est divisée en cinq chapitres et en sept appendices. Le premier chapitre,
La recension des écrits, délimite le domaine de connaissances utilisé pour la thèse.
Nous aborderons les concepts liés à la représentation et à la modélisation des
connaissances. Le type de modèle de connaissances particulier que constituent les
ontologies ainsi que leurs classifications seront aussi abordés et un aperçu sera fourni
de quelques formalismes semi-formels et formels utilisés pour représenter des
connaissances. Nous aborderons également le concept de métamodélisation en
identifiant les processus qui permettent de réaliser la transformation de modèles. C'est
par une implantation de cette technique que nous réaliserons la transformation d'un
modèle semi-formel en ontologie. Une méthodologie d'ingénierie des connaissances
sera ensuite présentée de manière générale. Nous y aborderons la structure d'une
méthodologie, l'élicitation de connaissances, la conception de systèmes experts et
l'ingénierie ontologique. Finalement, nous exposerons à la section huit quelques
6
notions concernant le volet assistance automatique de cette thèse, un aspect important
qui sera implanté dans la méthodologie et les outils OntoCASE.
Le chapitre 2, Méthodologie d'OntoCASE, décrit la méthodologie et l'assistant
informatique d'OntoCASE développés dans cette thèse. Les première et deuxième
sections de ce chapitre posent l'hypothèse de recherche associée au cadre conceptuel
d'OntoCASE ainsi que les objectifs de la recherche. La section 3 présente la
description des volets d'OntoCASE, de la structure de l'ontologie de transformation et
du portrait synthèse de la méthodologie à développer. Les sections 4 à 6 exposent
successivement la structure de l'ontologie cadre, de l'ontologie de référence ainsi que
la méthodologie de conception d'une ontologie à partir d'une conceptualisation semi-
formelle.
Le chapitre 3, La démarche de construction d'OntoCASE, présente la démarche de
recherche qui a permis de construire le volet procédural, représentationnel et
computationnel d'OntoCASE. Le processus de construction d'OntoCASE a été divisé
en trois phases, soit la phase 1 Mise en place des composants architecturaux,
procéduraux et informatiques, la phase 2 Agrégation des composants ontologiques,
procéduraux et informatiques et la phase 3 Consolidation dont l'objectif est de valider
la méthodologie développée.
Le chapitre 4, Validation d'OntoCASE, présente les résultats de la validation
méthodologique et computationnelle d'OntoCASE. Les résultats obtenus sont évalués
selon les critères d'utilisabilité que sont l'efficacité, l'efficience et la satisfaction. La
démonstration de la généricité de la méthodologie à transformer des modèles de
connaissances dans divers formalismes est réalisée par l'implantation complète d’un
langage semi-formel autre que celui utilisé à l'étape initiale de construction
d'OntoCASE.
Le chapitre 5, Conclusion et discussion, présente le sommaire des réalisations, des
contributions, des limites et des perspectives de la recherche selon les axes
7
informatiques, de la gestion des connaissances, de la représentation des connaissances
et de l'ingénierie ontologique
En annexe à cette thèse l’appendice A présentent un guide du langage de
modélisation par objet typé (MOT) qui sera utile au lecteur non familier avec le
langage MOT. L’appendice B (catalogue de la sémantique formelle de MOT)
présente la sémantique formelle d'exemples de modèles MOT qui couvrent
l'utilisation de la totalité des règles de la grammaire et du vocabulaire du langage
MOT. L’appendice C (catalogue des cohérences de l'ontologie cadre d'OntoCASE)
présente les axiomes et les règles qui permettent de valider la cohérence de
l'ontologie du domaine produit par la méthodologie. L’appendice D (Scénarios de cas
de tests) présente les divers scénarios de tests qui permettent de valider la
méthodologie par la réalisation des tests unitaires, des tests fonctionnels, des tests de
systèmes et des tests d'incohérences. L’appendice E (Éléments pour guider la
modélisation semi-formelle à l’aide de concepts ontologiques) est une contribution
de la thèse qui sert d'outil méthodologique pour la validation sémantique d'une
ontologie produite à partir d'une modélisation semi-formelle. L’appendic F (Code
source) présente le code Java et OWL des principaux programmes et ontologies
utilisés par OntoCASE. L’appendice G (Évaluation expérimentale) présente le
protocole d'expérimentation et le certificat d'éthique utilisé pour réaliser
l'expérimentation d'OntoCASE, suivis du résumé des commentaires de chacun des
participants.
CHAPITRE 1
RECENSION DES ÉCRITS
Ce chapitre se divise en huit sections. La première section présente les fondements
théoriques du concept de représentation autant du point de vue des sciences de
l'information que de celui de la sémiotique et des sciences cognitives. Cette section
introduit aussi le concept de couche d'abstraction. La deuxième section aborde le
concept de modélisation des connaissances, dont celle des ontologies. La troisième
section présente diverses catégories de classification des ontologies, qu'il s'agisse de
la classification selon le spectre sémantique, selon le degré d'expressivité ou selon le
degré de généralité du domaine représenté. La section présente aussi quelques
exemples d'ontologies de différents degrés de généralité. Les sections 4 et 5
présentent respectivement les caractéristiques et des exemples de modèles de
connaissances représentés dans des formalismes semi-formel et formel. La section 6
présente le concept de métamodélisation en tant que technique pour la transformation
de modèles. La section 7 aborde les principaux sujets entourant l'ingénierie des
connaissances, tels que la structure d'une méthodologie, l'élicitation des
connaissances, la conception d'un système expert et l'ingénierie ontologique.
Finalement, la section 8 développe les principaux concepts qui sont liés aux fonctions
d’assistance à l’usager dans les environnements informatisés.
1.1 Concept de représentation
Le concept de représentation est au cœur de cette thèse. Il existe plusieurs façons
d'interpréter ce concept selon le contexte dans lequel il est employé. Par le biais de la
philosophie, de la psychologie et de la sémiotique, nous examinons la définition de ce
9
concept dans le domaine de la représentation des connaissances ainsi que dans le
domaine de la représentation dans les systèmes d'informations. Nous ferons aussi
appel à la sémiotique pour définir les concepts d'« abstraction », de « couche
d'abstraction », de « polysémie » et de « synonymie ». Ces notions sont utiles pour
orienter le design du processus de formalisation ainsi que du processus de
désambiguïsation nécessaire à la transformation d’un modèle semi-formel en
ontologie3.
1.1.1 Théorie des idées
On retrouve chez Platon (428-348 av. J.C.) les notions de monde des apparences et
de monde réel (voir la figure 1.1) par l'utilisation de l'abstraction entre un objet et son
idée. Pour Platon, l'objet fait partie du monde des apparences, des choses périssables
et éphémères. C'est l'idée qui définit la véritable nature des choses, qui, elle, fait
partie du monde réel. De manière contemporaine, nous pouvons remplacer la notion
d'idée par celle de concept (Jarrosson, 1992). La théorie des idées de Platon souligne
la polarisation entre entités objectives et entités subjectives.
Figure 1.1: L'objet et son abstraction: l'idée
Le pôle de la réalité subjective fait référence à des éléments de l'esprit humain alors
que les pôles de la réalité objective englobent les éléments observables de l'Univers,
résidant hors de l'esprit humain, qui existent en dehors de la présence ou de la non-
présence de l'humain (Dietz, 2006 p. 36).
3 Tout au long de cette thèse, nous considérons entre autres que l’ontologie est un modèle formel. Une définition
plus explicite d’ontologie sera donnée un peu plus loin dans ce chapitre.
est une abstraction
Idée Objet
Apparence
Réel
Subjectif Objectif
10
1.1.2 Représentation dans un système d'information
Schématisée à la figure 1.2, le modèle de la représentation dans un système
d'information a pour objectif d'établir une concordance représentationnelle entre les
éléments de la réalité et leur représentation dans le système d'information. En plus de
diviser la réalité entre objectivité et subjectivité, la représentation est aussi divisée
entre domaine (représentant l'Univers réel4) et système d'information (représentant
l'Univers virtuel). Dans cette représentation, la relation qui unit le concept et l'objet
est la relation d'instanciation. L'instanciation est une relation d'abstraction non
transitive qui associe un ou plusieurs objets concrets à une abstraction (le concept).
Le type et le symbole constituent les signes (cf. section suivante) qui représentent
respectivement le concept et l'objet dans le système d’information. Le modèle de la
représentation de la figure 1.2 ne représente pas la sémantique qui unit les éléments
du domaine aux éléments du système d'information. Le modèle de la représentation
qui intègre la sémantique relève de la sémiotique.
4 Dans ce contexte, tant les objets que leurs abstractions (les concepts) sont considérés comme faisant partie de
l'Univers réel.
Figure 1.2: Le modèle de la représentation d'un domaine dans un système
d'information. (Tirée et adaptée d'Olivé, 2007 p. 46)
11
1.1.3 Sémiotique
"Ceci n'est pas une pipe" est la célèbre phrase incluse par Magritte (1898-1967) dans
son tableau de 1929, intitulé La trahison des images et présenté à la figure 1.3. En
première approche, cette affirmation semble paradoxale mais elle permet de souligner
la différence existant entre un objet, son représenté et ce qu'il signifie. Normalement,
la signification d'une image est « située » entre l'image et l'objet qu'elle représente. En
incluant cette phrase dans le tableau, Magritte nous invite à déplacer la signification
entre le spectateur et la toile, laissant sous-entendre que ce qui est observé par le
spectateur n'est pas une pipe mais plutôt l'image d'une pipe.
Figure 1.3: Tableau La trahison des images, Magritte 1929. (Tirée de Paquet, 2006,
p. 9)
En philosophie, Charles Sanders Peirce (1839-1914) est considéré comme le père de
la sémiotique5 moderne. Les notions de base associées à l'activité de modélisation de
la connaissance tirent leurs origines de la sémiotique, dont le triangle sémiotique en
est la représentation (voir la figure 1.4). L'objet est un observable, une chose
proprement dite, par exemple: une personne, un animal ou une maison. L'objet
possède des caractéristiques propres et il peut devoir son existence à l'agrégation de
plusieurs autres objets. Par exemple, pour exister, une automobile se compose d'un
5 Selon le Dictionnaire Antidote RX, la sémiotique est la "science des modes de production, de fonctionnement et
de réception des différents systèmes de signes de communication entre individus ou collectivités".
m
d
e
d
D
c
l
r
L
u
n
d
d
6
7
8
s
F
m
oteur, de
d
iscuter so
n
e
st intrinsè
q
d
es émotio
n
D
es notions
c
omme des
l
icorne (He
r
éférent, "th
L
e signe est
u
n objet. P
a
n
otre chien
d
'immatricu
l
d
'informati
o
6
Le terme entre
7
Le terme entre
8
Puisque nous
n
s
ymboliser l’obj
F
igure 1.4:
L
Si
g
Subjectif
Objectif
quatre rou
e
n
t des objets
q
uement liée
n
s et des sen
t
comme la
v
o
bjets imm
a
lbig, 2006)
.
ing
"
peuve
n
aussi une c
h
a
r exemple,
familial [
b
l
ation repr
é
o
n, la donné
e
"< >" représen
t
"[ ]" représent
e
n
e pouvons pas
et.
L
e triangle s
Repr
é
Con
c
g
ne
e
s, d'une c
a
dits concr
e
à la nature
t
iments. No
u
v
itesse, la li
b
a
tériels, qui
p
.
Selon le
n
t remplacer
h
ose de la r
é
le nom <b
a
b
ahia]
7
-
8
, o
u
é
sente une
e
(data) est
u
t
e le signe assoc
e
l'objet concret.
inclure directe
m
émiotique.
é
sente
c
ept
O
b
a
rrosserie, e
t
e
ts ou maté
r
de l'existen
u
s parlons
a
b
erté ou enc
p
euvent par
f
contexte d'
le mot obje
t
é
alité object
i
a
hia>
6
est u
n
u
encore le
automobi
l
u
n signe qu
i
ié à un objet co
n
m
ent l’objet dan
s
Figur
e
sémi
o
du ch
i
b
jet
tc. Les obj
r
iels. Or, l'e
x
ce humaine
,
a
lors d'objet
s
ore la gran
d
f
ois être mê
m
'
utilisation,
t
.
ive qui a po
n
signe qui
r
signe <C
X
l
e spécifiq
u
i
sert à repr
é
n
cret.
s
le texte, nous
a
e
1.5: Exem
p
o
tique assoc
i
i
en Bahia.
ets dont n
o
x
istence de
,
que l'on p
e
s
abstraits
o
d
eur sont au
s
m
e imagina
i
des mots
c
ur fonction
représente
s
X
Q-511> s
u
u
e. Dans
é
senter une
o
a
vons placé l’i
m
p
le d'un tria
n
i
é à la conce
o
us venons
certains obj
e
e
nse au mo
n
o
u immatéri
e
s
si considér
é
i
res tels qu'
u
c
omme cho
s
de représen
t
s
pécifiquem
e
u
r une pla
q
les systè
m
o
bservation
m
age de l’objet
p
n
gle
ptualisation
12
de
e
ts
n
de
e
ls.
é
es
u
ne
s
e,
t
e
r
e
nt
q
ue
m
es
de
p
our
13
la réalité. Les termes tels que symbole, mot, representamen ou signifiant sont aussi
utilisés pour désigner le signe.
Le concept, quant à lui, fait partie de la réalité subjective : il est une abstraction qui se
rapporte à l'objet de la réalité objective et qui est symbolisé par le signe. Le concept
est une abstraction issue du travail de classification de l'esprit humain. À l'instar des
objets, il existe des concepts abstraits et des concepts concrets. La représentation
mentale de « Bahia »9 est un concept de type concret, car il renvoie à un objet de la
réalité objective. En revanche, les concepts tels que « tout », « au moins un » ou
encore « appartient à », sont des concepts de type abstrait. Des termes tels que
signifié, idée, interprétant, sens, image mentale peuvent être substitués au terme
concept.
La relation de représentation entre un signe et un objet existe grâce à la dynamique
qui existe entre le signe qui symbolise un concept et le concept qui se rapporte à
l'objet. En effet, la relation de représentation entre un signe et son objet n'existe que
par le sens que l'esprit lui accorde. Sans l'esprit, il n'existe aucun lien entre un objet et
son signe. C'est l'esprit qui associe une sémantique (un sens) à la représentation entre
un signe et son objet.
1.1.4 Abstraction et couche d'abstraction
C'est en 1966 que René Magritte peint la toile Les deux mystères (voir la figure 1.6).
On y voit en premier plan le tableau d'une pipe sur lequel est écrit « Ceci n'est pas
une pipe ». À l’arrière plan, est représentée une pipe peinte sur un mur. Dans cette
toile, le tableau du premier plan définit l'objet en arrière plan en indiquant que l'objet
peint n'est pas l'objet représenté. En réalité, l'objet peint est l'image d'une pipe. La
signification associée à chaque image se superpose ainsi pour former des couches
d'abstraction.
9 Le nom entre « .. » représente le sens associé à l'objet concret
14
Figure 1.6: Les deux mystères. (Magritte 1966)
La superposition de triangles sémiotiques est un procédé qui a été exploité par Sowa
(2000a) pour élaborer son concept de représentation des connaissances. Nous
utilisons le même procédé pour élaborer le concept de couche d'abstraction (voir la
figure 1.7). De manière pragmatique, nous considérons l'abstraction comme étant la
relation inverse de « se rapporte à » que l'on pourrait traduire par « est-conceptualisé-
par ». Elle est d'abord une relation non transitive entre les objets de l'Univers objectif
et les concepts de l'Univers subjectif relevant de la représentation mentale des objets.
En ce sens, nous dirons qu'un concept est une abstraction d'un objet, c'est-à-dire qu'il
est produit par le processus de la pensée humaine.
Une caractéristique importante de la pensée humaine est la propriété qu'elle possède a
classer les choses, par exemple en fonction des usages qu'elle désire en faire. Pour
elle, le concept émergeant d'un premier processus de classification peut très bien être
considéré en tant qu’objet dans un processus subséquent, ce qui est parfois nommé
l'autoréférencement (Jarrosson, 1992 ; Pitrat, 1990, 1993). Ce nouvel objet pourra
alors être désigné par un nouveau signe qui, lui-même, servira à représenter un
nouveau concept créant des couches d'abstraction. C'est ainsi qu'en traitant « Bahia »
en tant qu'objet, il est permis d'abstraire le concept « Chien » qui, à son tour, servira à
abstraire le concept « Classe ». On pourra aussi dire que « Chien » est le métaconcept
d
D
S
c
s
s
g
l
s
«
e
s
F
d
e « Bahia
»
D
ans cette s
t
1.1.5 Génér
a
S
oit A qui
e
c
onclure qu
s
ubsomptio
n
s
ubsomptio
n
g
énér
a
lisati
o
l
'énoncé de
s
orte de C,
a
«
Chien »,
B
e
st une sort
e
s
orte d'ani
m
F
igure 1.7:
L
»
et que « C
l
t
ructure, le
c
a
lisation et
a
e
st subsum
é
e
A est sub
n
qui nous
n
s'interprè
t
o
n entre co
n
début s'inte
r
a
lors il est p
e
B
par « Ma
m
e
de mamm
i
m
al. Ce qui e
s
L
e concept
d
l
asse » est l
e
c
oncept « B
a
a
bstraction
é
par B et
sumé pa
r
C
permet de
d
t
e par le
n
cepts qui a
p
r
prète de la
e
rmis de co
n
m
mifère » et
i
fère et ma
m
s
t un énonc
é
d
'abstraction
e
métaconce
p
a
hia » est dé
B qui est s
u
. C'est la p
r
d
éduire cet
t
terme « s
o
p
partiennent
façon suiva
n
n
clure que
A
C par « Ani
m
m
mifère est
u
é
vrai. Par c
o
représenté
à
p
t de « Chie
n
signé par <
C
u
bsumé pa
r
r
opriété de
t
t
e conclusio
o
rte-de » q
u
au même n
i
n
te: A est u
n
A
est une so
r
mal », alors
u
ne sorte d'
a
o
ntre, de l'é
n
à
partir du t
r
n
» ainsi qu
e
C
lasse:Chie
n
r
C, alors il
t
ransitivité
q
o
n. En lang
a
u
i est un
i
veau d’abs
t
n
e sorte de
B
r
te C. En re
m
l'énoncé s'
é
a
nimal, alor
s
n
oncé suiva
n
r
iangle sémi
o
e
de « Bahi
a
n
:Bahia>
est permis
q
ue possède
a
ge naturel,
processus
t
raction. Ai
n
B
et B est
u
m
plaçant A
p
é
crit: soit ch
i
s
chien est
u
n
t : « chien
e
o
tique.
15
a
».
de
la
la
de
n
si,
u
ne
p
ar
i
en
u
ne
e
st
u
p
à
c
p
c
r
d
L
d
m
M
d
L
s
u
ne sorte d
e
p
as permis
d
à
une disti
n
c
as, est uti
p
roposition
c
i. Lorsque
r
elation n'e
s
d
ire « chien
1.1.6 Modè
l
L
a polysém
i
d
e désamb
i
m
odèle de l
a
M
odélisatio
n
d
isponible
à
L
’objet (la
c
s
ymbolise l
e
e
mammifèr
d
e conclure
q
n
ction impo
r
lisée pour
f
ait référen
c
la proposi
t
s
t pas transi
t
est une sort
e
l
e sémiotiqu
e
i
e et la syn
o
guïsation
d
a
sémiotiqu
e
n
par Obje
t
à
l’appendic
e
Figure 1.
c
hose objec
t
e
sens (la sé
m
e
et mamm
i
q
ue chien es
r
tante entre
changer de
c
e à la défini
t
ion de gén
é
t
ive et on e
m
e
de mamm
i
e
de la syno
n
o
nymie sont
d
’OntoCAS
E
e
(voir la fi
g
t
s Typés (
M
e
A de cette
t
8 : Le mod
è
t
ivement ré
e
m
antique) q
u
i
fère est un
e
t
une sorte
d
g
énéralisati
o
couche d'
a
tion de ter
m
é
ralisation
e
m
ploie plut
ô
i
fère et ma
m
n
ymie et de
des notion
s
E
. À titre
d
g
ure 1.4) sc
h
M
OT) (Paq
u
t
hèse.
è
le sémiotiq
u
e
lle) est re
p
u
i se rappor
t
e
sorte de c
l
d
e classe bio
o
n et abstra
c
a
bstraction.
m
es et non à
u
e
st utilisée
p
ô
t le terme
«
m
mifère est
u
la polysémi
e
s
qui se tro
u
d
’exemple,
h
ématisé da
n
u
ette, 2002b
u
e représent
é
p
résenté par
t
e à l’objet.
l
asse biolo
g
logique. Ici
ction qui,
d
Dans ce
c
u
ne classifi
c
p
our défini
r
«
est un ». I
l
u
ne classe bi
o
e
u
vent au cœ
u
la figure 1.
n
s le langag
e
), dont la
d
é
en MOT.
un symbol
e
g
ique », il n'
e
nous touch
o
d
ans ce der
n
c
ontexte, c
e
c
ation de ce
u
r
un terme,
l
faudrait d
o
o
logique ».
u
r de l’acti
v
8 présente
e
graphique
d
escription
e
e
. Le symb
o
16
e
st
o
ns
n
ie
r
e
tte
u
x-
la
o
nc
v
ité
le
de
e
st
o
le
D
s
D
(
T
s
e
d
1
1
D
ans la per
s
s
ens) qui es
t
D
ans l’exe
m
(
=4)
10
est s
y
T
oujours d
a
s
ymbolise
d
e
xemple, la
d
’une part,
u
1
0
Définition ex
t
1
1
Ibid.
s
pective sé
m
t
symbolisé
e
m
ple de la f
i
y
mbolisé pa
r
Figure
1
a
ns le conte
x
d
eux sens
o
figure 1.10
u
ne source
d
Figur
t
raite du diction
n
m
iotique, no
u
e
par au moi
i
gure 1.9, le
r
les synony
m
1
.9 : Exempl
x
te du mod
è
o
u un sym
b
schématise
d
e chaleu
r
, e
e 1.10 : Exe
m
n
aire Antidote
H
u
s définisso
n
ns deux sy
m
sens un en
s
m
es quatre
e
e de synon
y
è
le sémioti
q
b
ole qui re
p
la polysém
i
t
d’autre pa
r
m
ple de pol
y
H
D.
n
s la synony
m
m
boles qui r
e
s
emble com
p
e
t 4.
y
mie entre 4
q
ue, la poly
p
résente d
e
ie associée
r
t, un décès
d
y
sémie du
m
m
ie par une
e
présentent
l
p
osé de tro
i
et quatre.
sémie est u
n
e
ux objets
d
au mot
f
eu
d
epuis peu
1
1
m
ot feu.
sémantique
l
e même ob
j
i
s X plus u
n
n
symbole
q
d
ifférents.
P
qui symbol
i
1
.
17
(le
j
et.
n
X
q
ui
P
ar
i
se
18
1.1.7 Donnée, information et connaissance
Nous pouvons associer les termes classiquement distingués en gestion des
connaissances de « donnée », « information » et « connaissance » aux trois pôles du
triangle sémiotique. En gestion des connaissances, Prax (2003) définit la
connaissance ainsi:
[…] Pour qu'une information devienne connaissance, il faut que le sujet puisse
construire une représentation qui fasse sens. Pour cela, l'information reçue subit
une série d'interprétations (filtre retraitements), liées aux croyances générales
(paradigmes), au milieu socioprofessionnel, au point de vue, à l'intention, au
projet de l'individu porteur. Contrairement à l'information, la connaissance n'est
pas seulement mémoire. Item figé en stock, mais toujours activable selon une
finalité, une intention, un projet. Il y a dans la connaissance une notion de
process, construction d'une représentation finalisante d'une situation en vue
d'une « bonne fin » […]12
Une analyse sémiotique de la connaissance (voir la figure 1.11) place à la base du
triangle sémiotique la relation de représentation entre information et donnée.
Figure 1.11: Donnée, information et connaissances dans le modèle sémiotique.
La donnée est le résultat d'un processus de perception de la réalité. Dans l'exemple de
la figure 1.11, l'objet [25] qui est une donnée devient une information lorsqu'elle est
12 Prax, Le manuel du knowledge management p.63.
Symbolise
Se rapporte
Représente
Connaissance
Information Donnée
(signe) (objet)
(concept)
25
25 C
La température est de 25 C
Subjectif
Objectif
19
contextualisée en degrés Celsius <25 °C>. L'information symbolise le concept « la
température est de 25 °C » ce qui peut, par exemple, amener un sujet à inférer qu'« il
faut assez beau pour faire un pique-nique ». Nous considérons la connaissance
comme étant la signification que l'on donne à une information. De manière
sémiotique, on pourrait dire que la connaissance est le signifié (ou la sémantique)
d'une information.
1.1.8 Représentation des connaissances
Du point de vue sémiotique (voir la figure 1.12), la représentation des connaissances
est un métaconcept (un concept décrivant un concept) qui se rapporte à une
connaissance (Sowa, 2000a). Dans cette superposition, la connaissance devient l'objet
se rapportant au concept de représentation des connaissances. Ainsi, la connaissance
est représentée par un symbole qui en devient le signe. C'est donc dire que le concept
de représentation des connaissances est un processus qui traite la connaissance
comme un objet représenté par un symbole.
Figure 1.12: Le métaconcept de représentation des connaissances.
Symbolise
Représentation de la
Connaissance
Symbole
(signe)
(méta-concept)
Symbolise
Se rapporte
Représente
Connaissance
Information Donnée
(signe) (objet)
(concept)
Se rapporte
Représente
20
1.1.9 Représentation des connaissances en sciences cognitives
Dans le processus de communication, Heldig (2006) positionne la représentation des
connaissances entre le modèle mental et le langage humain (voir la figure 1.13).
L'hypothèse du modèle mental (Johnson-Laird, 2004) postule qu'à l'intérieur de
chaque esprit, il existe une représentation mentale de la réalité qui est issue de la
perception que nous avons de notre environnement. Cette représentation forme un
modèle mental qui permet à chaque personne de réaliser des déductions nécessaires à
toute communication. La représentation des connaissances peut être définie comme
un processus d’extériorisation de ce modèle mental sous la forme d'un modèle
externe, mais qui ne lui est pas nécessairement fidèle. L'interprétation plus ou moins
formelle du modèle par des personnes ou des systèmes computationnels permet la
communication entre les agents cognitifs.
Figure 1.13: Modèle cognitif de la représentation des connaissances. (Tirée de
Helbig, 2006, p. 8)
La figure 1.13 représente les divers niveaux d'abstraction du modèle cognitif de la
représentation des connaissances. Le premier niveau, celui de la réalité, contient un
Percevoir Représenter Interpréter
Communiquer
Formaliser
21
certain nombre d'objets qui sont perçus par les sens ([la lune], [le soleil], etc.). Les
objets de la réalité perçus sont représentés sous une forme quelconque dans l'esprit
pour former un modèle mental. Dans le schéma de l'exemple, les modèles mentaux
sont représentés par une encapsulation dans des guillemets français (« ») pour en
faciliter la lecture. Il existe plusieurs hypothèses sur la nature des représentations dans
le modèle mental, dont les deux principales sont l'hypothèse connexionniste et
l'hypothèse symbolique. L’hypothèse connexionniste, que nous avons étudiée dans
des travaux antérieurs à cette thèse (Héon, 1998 ; Héon et al., 1998), postule que la
cognition est le résultat de l’interaction entre des entités élémentaires d’un système.
Le modèle couramment utilisé est celui du neurone (l’entité élémentaire) relié via la
synapse à un autre neurone (l’interaction) constituant ainsi un réseau de neurones (le
système). La force de l’interaction synaptique entre les neurones est pondérée par le
poids synaptique et la réponse du neurone aux stimulations intrants est modulée par la
fonction de réponse du neurone, qui dans le modèle classique est une fonction
sigmoïde. La modulation des poids synaptiques et la modulation des paramètres de la
fonction de réponse de chacun des neurones, suite à une stimulation, permettent de
reproduire certains aspects de la cognition. L’approche symbolique postule que la
cognition est le produit de la manipulation de symboles. Le langage naturel, la lecture
de la musique, l’utilisation des mathématiques sont autant de systèmes de codage qui
mettent en opération la cognition. Nous allons d’ailleurs traiter largement de ce sujet
dans cette thèse.
Le modèle mental peut être extériorisé sous la forme d'un modèle externe plus ou
moins formel de ses connaissances. Une des limites des langages de représentation de
connaissances est liée au type de connaissances qu'ils sont en mesure de représenter.
Par exemple, l'ontologie est spécialement dévolue à la représentation de
connaissances déclaratives de type Concept, alors que d'autres langages formels, tels
que le Business Process Modeling Notation (BPMN13), sont spécialisés dans la
13 OMG BPMN, Object Management Group/Business Process Management Initiative: http://www.bpmn.org/
22
représentation de connaissances procédurales. Notons finalement que la
représentation de connaissances stratégiques (Paquette, 2002b ; Paris et al., 1983)
associée à l'utilisation de conditions ou de contraintes14 est aussi couramment utilisée
par exemple dans les arbres de déduction ou de décision. Un avantage notoire du
langage MOT est qu'il peut représenter dans un même modèle, voire dans un même
schéma, l'un et l'autre des types de connaissances énumérées ci-haut. L'un des défis
de cette thèse réside dans la représentation de ces divers types de connaissances par
une ontologie qui, par définition, représente des connaissances déclaratives.
1.2 Modélisation des connaissances
De façon générale, la modélisation est l'activité de construction d'un modèle externe
de connaissances (Alhir, 2002). Pour réaliser cette activité, nous devons clarifier les
concepts de langage et de modèle. Nous les abordons dans cette section, de même que
ceux d'ontologie, de métamodélisation, d'abstraction et d'espace de modélisation. Les
principes de transformation de modèles sont également discutés. La discussion
concernant ces concepts permet de définir les notions théoriques nécessaires à la
transformation d'un modèle semi-formel en ontologie.
1.2.1 Langage
Le langage est un moyen d'expression utilisé pour exprimer et échanger de
l'information ou des connaissances. Pour Alhir (2002), la structure d'un langage se
divise en trois parties: la syntaxe, la grammaire et la sémantique (voir la figure 1.14).
La syntaxe définit le vocabulaire utilisé par le langage alors que la sémantique définit
le sens à donner aux différents mots composant le vocabulaire. La grammaire, quant à
elle, définit les règles d'utilisation du vocabulaire.
14 OMG OCL, Object Constraint Language Specification, version 2.0:
http://www.omg.org/technology/documents/formal/ocl.htm
F
L
(
m
p
D
o
e
é
d
f
m
f
r
q
p
e
s
F
igure 1.14:
L
es langag
e
(
MOT) son
t
m
odèles gr
a
p
ermet la c
o
1.2.2 Modè
l
D
ans nos ac
o
bjet. Nor
m
e
n relation
é
voluer da
n
d
ynamique
f
orment un
m
odèle est
f
ondamenta
u
r
envoie à l'
o
q
ue la relat
i
p
ermettent
d
e
ux. Pour q
u
s
ignes – q
u
Langage d
e
e
s Unified
M
t
des exemp
a
phiques. L
'
o
nception d'
u
l
e
t
ivités cou
r
a
m
alement, no
les uns av
e
n
s le temps
et les relat
i
système, c
e
une abstra
c
u
x compose
n
o
bjet (concr
e
i
on (ex : ap
p
d
e mettre e
n
u
'un modèl
e
u
i forment
u
e
modélisati
o
M
odeling La
n
les de lang
a
'
Ontology
W
u
n modèle d
e
a
ntes, il est
p
us sommes
e
c les autre
s
ou encore
i
ons qui ag
i
e
que Grub
e
c
tion qui pe
r
n
t le modèl
e
e
t ou abstrai
p
artient à,
e
n
relation de
s
e
soit interp
r
u
n langage
o
n.
n
guage (U
M
a
ges de mo
d
W
eb Langu
a
e
type ontol
o
p
lutôt rare q
u
confrontés
à
s
. Les cara
c
changer d'
é
i
ssent sur l
e
e
r (1993b)
a
r
met de re
p
e
, soit l'enti
t
t) par exem
p
e
st une sort
e
s
objets con
c
r
étable, les
s
– permette
n
M
L) et
M
od
é
d
élisation p
e
a
ge (OWL)
o
gique.
u
e nous trai
t
à
l'analyse
d
c
téristiques
d
é
tat en prés
e
e
s objets fo
r
a
ppelle l'«
U
p
résente
r
u
n
t
é et la rela
t
p
le une aut
o
e
de) renvo
i
crets ou d’a
u
s
ignes et les
n
t de décri
r
é
lisation
p
a
r
e
rmettant la
est aussi u
n
t
ions ou ana
l
d
'un ensemb
l
d
'un objet
d
e
nce d'un
a
r
ment un t
o
U
nivers du
n
système.
D
t
ion (Chen,
2
o
mobile ou
l
i
e aux obje
t
a
utres objets
règles d'uti
r
e le « rapp
r
Objets Ty
p
conception
n langage
q
l
ysions un s
e
l
e d'objets
m
d
onné peuv
e
a
utre objet.
o
ut global :
discours ».
D
eux conce
p
2
002). L'en
t
l
a vitesse al
o
t
s abstraits
q
abstraits e
n
lisation de
c
ort » entre
23
p
és
de
q
ui
e
ul
m
is
e
nt
La
ils
Le
p
ts
t
ité
o
rs
q
ui
n
tre
c
es
un
24
concept et son objet. Le modèle doit être vérifiable et véridique pour le système que
le modèle tente de représenter (Tarski, 1944). Le modèle est donc une abstraction
décrivant un système selon un certain point de vue exprimé avec un certain langage.
1.2.3 Classification des langages de représentation des connaissances selon leur degré
de formalisme
Uschold et Gruninger (1996) classifient les langages de représentation des
connaissances selon quatre degrés de formalisme:
- Le langage naturel, dont l’expressivité est très élevée, constitue ce que ces
auteurs appellent le degré hautement informel. Ce type de représentation des
connaissances présente un haut degré d’ambiguïté, que le cerveau humain
arrive à décoder en partie, mais que l’ordinateur arrive mal à traiter, comme
en témoignent les difficultés qui subsistent dans les efforts d’interprétation
automatisée du langage naturel.
- Le degré semi-informel s’exprime au moyen d’une forme restreinte et
structurée du langage naturel, telle que celle que l’on retrouve dans la
description d’algorithmes en langage stéréotypé appelé pseudocode. Ce
formalisme réduit la spontanéité et le degré d’expressivité de la
représentation, mais, en revanche, il en rehausse la clarté en réduisant
certaines ambiguïtés bien que de manière encore intraitable par un système
informatique.
- Le degré semi-formel fait référence au formalisme du langage artificiel
employé pour le traitement partiellement automatique des connaissances. Le
langage de modélisation MOT (Paquette, 2002b ; Paquette et al., 2007) de
même que le langage graphique UML (OMG UML, 1997-2006) largement
utilisé en informatique sont deux exemples de langages de représentation
semi-formels. Les représentations de ce type peuvent encore contenir des
ambigüités. En revanche, une certaine relâche des contraintes langagières,
25
comparativement aux langages formels, favorise et stimule l'expressivité des
connaissances et la communication entre humains.
- Finalement, le degré rigoureusement formel que l’on retrouve dans les
langages comme OWL (Martin, 2002 ; McGuinness et Harmelen, 2004) ou
encore les graphes conceptuels de Sowa (2000a) offre une représentation des
connaissances dont l'expressivité est certes réduite, par rapport au langage
naturel, mais qui en élimine les ambiguïtés ce qui permet un traitement
informatique des connaissances représentées.
1.2.4 Ontologies dans la perspective des sciences cognitives
Chez les Grecs anciens, le terme ontologie signifie : « étude de l’être en tant qu’être,
indépendamment de ses déterminations particulières »15 laissant sous-entendre un
discours indépendant d’un point de vue quelconque. Il importe donc de faire une
distinction entre l’ « observateur » des choses et les choses « observées ». En
philosophie, il existe trois hypothèses sur l’appréhension de la connaissance :
l’objectivisme, le subjectivisme et le constructivisme (Dietz, 2006). L’objectivisme
défend l’hypothèse selon laquelle le monde existe par lui-même, de façon
indépendante de l’observateur. L’observateur croit en la vérité d’une réalité objective.
Le subjectivisme défend l’hypothèse que la réalité n’existe pas en dehors du sujet qui
l’observe et qu’à la limite, chaque observateur a sa propre image de la réalité. Quant
au point de vue constructiviste, il admet l’hypothèse qu’il n’y a pas d’objectivité
absolue de la réalité, que la réalité existe aussi par l’interprétation de celle-ci. En
contrepartie, il admet aussi que les éléments interprétés font partie d’une réalité que
l’on pourrait qualifier de semi-objective. Pour Dietz, l’ontologie s’interprète selon un
point de vue constructiviste, qui est exprimé schématiquement à la figure 1.15.
L’ontologie est une composante particulière de la réalité qui sert de base de
communication au discours sur une partie de la réalité (objectivisme). En même
15 Dictionnaire Antidote RH
t
a
e
l
m
l
l
F
T
e
(
c
D
C
t
emps, l’on
t
a
gent intel
l
e
mpruntés
l
'encodage
f
m
émoire o
u
l
'ontologie
r
l
'interprète,
q
F
igure 1.15:
1.2.4.1 Ont
o
for
m
T
el que déj
à
e
st celle pr
o
(
1997) : «
c
onceptuali
z
D
u point d
C
alero, Rui
z
t
ologie est
l
l
igent (subj
e
au domai
n
f
ait en sor
t
le transpor
t
r
este véridi
q
u'il soit hu
m
Positionne
m
o
logies en t
a
m
el
à
mentionn
é
o
posée pa
r
G
an ontolo
g
z
ation ».
e vue de l
’
z
et Piattini
(
l
e résultat
d
e
ctivisme).
n
e de l'in
fo
t
e que l'on
t
t
sur un rés
e
que et vér
i
m
ain ou ma
c
m
ent constr
u
a
nt que systè
é
, une défini
G
rube
r
(199
3
g
y is a
f
’
ingénierie
(
2006)
de la
d
’une const
r
Les terme
s
fo
rmatique.
t
ologie peu
t
e
au. L'intero
p
i
fiable indé
p
c
hine.
u
ctiviste de l
mes de repr
tion du ter
m
3
a) et adapt
é
f
ormal, e
x
ontologique
façon suiva
n
r
uction issu
e
s
sérialisa
b
L'attribut
t
être utilis
p
érabilité e
s
p
endamme
n
l
a définition
r
ésentation
d
m
e « ontolo
g
é
e pour son
v
x
plicit spe
c
, cette défi
n
te :
e de l’inter
p
b
le et inter
o
sérialisable
ée pour l'e
n
s
t l'attribut
q
n
t de l'age
n
d’ontologie
d
es connaiss
a
g
ie » généra
l
v
olet conse
n
c
ification
o
nition est
i
p
rétation d’
o
pérable s
o
indique
q
n
treposage
q
ui indique
q
n
t cognitif
q
.
a
nces de de
g
l
ement adm
i
n
suel par B
o
o
f a sha
r
i
nterprétée
p
26
un
o
nt
q
ue
en
q
ue
q
ui
g
ré
i
se
o
rst
r
ed
p
ar
27
La « conceptualisation » fait référence au modèle abstrait d'un phénomène dont
les concepts pertinents ont été identifiés :
- le terme « explicite » fait référence au fait que les types de concepts
utilisés et les contraintes de leur utilisation sont explicitement définis;
- le terme « formelle » renvoie au fait que l'ontologie devrait être lisible ou
interprétable par la machine;
- le terme « partagée » associé à « conceptualisation » porte l'idée que
l'ontologie exprime une connaissance consensuelle, c’est-à-dire acceptée
par un groupe. 16
Gómez-Pérez et al. (1996) fournissent, pour leur part, une interprétation de la
définition de l’ontologie du point de vue de sa forme. Selon eux,
une ontologie définit le vocabulaire d'un domaine d'application ainsi que les
règles de combinaison des termes et des relations permettant de définir les
extensions à ce vocabulaire 17:
Pour l’essentiel, les ontologies, en tant que systèmes de représentation, peuvent être
considérées au même titre que des systèmes de modélisation conceptuelle, tels que le
modèle entité-relation de Chen (1976) ou le modèle UML de Rumbaugh, Jacobson et
Booch (1999). Cependant, l’ontologie se distingue de ces systèmes de représentation
par les points suivants (Oberle, 2006):
- l’idée primaire des ontologies est d’établir un consensus autour d’un
signifiant à attribuer à un vocabulaire afin de faciliter l’échange
d’informations entre applications ;
- les ontologies sont formalisées au moyen d’un système de représentation
logique dont la sémantique est spécifiée de façon non ambigüe ;
16 «A ‘conceptualization’ refers to an abstract model of some phenomenon in the world by having identified the
relevant concepts of that phenomenon. ‘Explicit’ means that the type of concepts used, and the constraints on their
use are explicitly defined. ‘Formal’ refers to the fact that the ontology should be machine readable. ‘Shared’
reflects the notion that ontology captures consensual knowledge that is, it is not private to some individual, but
accepted by a group »
17 «Defines the basic terms and relations comprising the vocabulary of a topic area as well as the rules for
combining terms and relations to define extensions to the vocabulary»
28
- l’ontologie est exprimée au moyen d’un langage de représentation qui, à
l’état d’exécution, sert de représentation à des applications de recherche et de
raisonnement.
1.2.4.2 Ontologies dans la perspective informatique
De façon contemporaine, le concept d’ontologie est réapparu vers les années quatre-
vingt par l’introduction des théories de la logique dans la construction de systèmes en
IA. La figure 1.16 présente sous forme schématique une synthèse des principales
définitions d’une ontologie du point de vue informatique (Gómez-Pérez et al., 2003;
T. Gruber, 1993; Guarino, 1995; Lacy, 2005; Studer et al., 1998).
En ingénierie informatique, une ontologie est un artéfact (parfois un fichier XML)
dont la structure permet de représenter des concepts, des relations, des axiomes et des
faits. Le concept est la représentation d’une entité abstraite de la réalité à décrire. Les
vocables de terme ou classe sont aussi parfois employés en tant que synonymes de
concept. À un niveau d’abstraction factuelle, on retrouve l’instance ou l’individu dont
le représenté est en lien avec un objet concret de la réalité observée. L’action de créer
un fait à partir d’un concept se nomme : instancier. Finalement, l’axiome, qui définit
le concept, est une assertion (c’est-à-dire un énoncé qui est supposé vrai dans le
domaine représenté) à propos des instances en relation avec les concepts de
l’ontologie.
De manière conceptuelle, une ontologie est la description d’une réalité et la
formalisation d’un modèle conceptuel, qui, selon Gruber, correspond à une
conceptualisation. Le processus d'interprétation est assumé par un agent intelligent
formel. L’agent a pour fonction de simuler la réalité par un mécanisme formel de
déduction dont l’ontologie est le sujet. L’ontologie est donc le résultat d’une double
activité de modélisation et de formalisation. La modélisation est un processus de
représentation de la réalité dont la résultante est un modèle de connaissances. La
formalisation est un processus « de mise en forme » de ce modèle conceptuel afin que
l
p
S
o
f
F
N
c
E
c
d
L
i
m
L
l
’artéfact ré
s
p
ar un agen
t
S
attler, 200
4
o
rdre est le
s
f
ormaliser l
e
F
igure 1.16:
1.3 Classifi
c
N
ous avons
c
onsidérée
c
E
n tant que
c
ertains attr
i
d
'expressivi
t
L
'interopér
ab
i
ndépenda
m
m
anipulent
─
L
e dévelop
p
s
ultant (l’on
t
t
informati
q
4
; Haarslev,
s
urensembl
e
e
s ontologie
s
Définition
d
c
ation des o
n
vu à la sect
i
c
omme un s
y
sujet d'étud
e
i
buts, qu'il
s
t
é, ou en
c
b
ilité des o
n
m
ment de l
a
─
est l'une
d
p
ement d'u
n
t
ologie) soit
q
ue (formel)
.
2005; Lutz
e
, est un sys
t
s
.
d
'une ontol
o
n
tologies
i
on 1.2.4.1
q
y
stème de r
e
e
, l'ontologi
s
'agisse de s
c
ore du
d
n
tologies
─
c
a
nature o
u
d
es propriét
é
n
e ontologi
e
interprétab
l
.
La logiqu
e
, 2007), do
n
t
ème de rep
r
gie en infor
m
q
ue, d'un ce
r
e
présentatio
n
e est un obj
e
on degré de
d
egré de
g
c
'est-à-dire l
a
u
du type
é
s que la ca
t
e
représent
a
l
e, de façon
e
de descrip
t
n
t la logiqu
e
r
ésentation
c
m
atique.
r
tain point d
e
n
de connai
et qu'il est
p
e
précision s
g
énéralité
d
a
propriété
q
de systèm
e
t
égorisation
a
nt un ense
m
cohérente e
t
t
ions (Baad
e
e
des prédic
a
c
ouramment
e
vue, l'ont
o
ssances, vo
i
p
ossible de
c
émantique,
du domai
n
q
u'elles pos
s
e
s informa
t
tente de m
e
m
ble de m
é
t
non ambig
ü
e
r, Horrocks
a
ts du pre
m
employé p
o
o
logie peut ê
i
re un langa
g
c
lassifier se
l
de son éch
e
n
e représe
n
s
èdent d'exis
t
iques qui
l
e
ttre en vale
u
é
tadonnées
29
ü
e,
et
m
ier
o
ur
tre
g
e.
l
on
e
lle
n
té.
ter
l
es
u
r.
ou
30
d'une ontologie cadre (que nous définissons plus loin) sont des exemples
d'implantation d'ontologies qui valorisent des aspects particuliers de l'interopérabilité.
Dans les pages qui suivent, nous traitons de ces différents critères de classification
des ontologies. Ces critères ont permis de classifier les diverses ontologies que nous
avons développées pour OntoCASE.
1.3.1 Classification des ontologies selon la précision sémantique
Une classification des ontologies selon leur précision sémantique a été proposée par
McGuiness (2003), qui les a placées sur un « spectre sémantique ». Selon cet auteur
et contrairement à ce qui a déjà été énoncé, la classification selon la précision
sémantique implique qu'une ontologie n'est pas nécessairement de degré formel.
Présenté à la figure 1.17, le spectre sémantique est composé de neuf degrés de
précision sémantique, allant du simple catalogue de termes à l'ontologie sophistiquée.
Les quatre premiers niveaux définissent une classification de termes selon une
sémantique exprimée en langage naturel. Le catalogue et le glossaire constituent des
regroupements de termes avec leur définition. Le thésaurus ajoute le concept
d'association permettant le référencement entre les termes. La catégorie "informal is-
a" fait référence à une classification informelle de termes, exprimée en langage
naturel, alors que la catégorie "formal is-a" fait plutôt référence à une classification
d'ordre taxonomique. Le frame est un modèle proposé par Minsky (1985) qui fait
référence aux concepts de classes, possédant des propriétés, des attributs et des
« cases » (slots). Finalement, le niveau ultime de classification est l'ontologie
formelle apte à représenter des restrictions, tel que le propose la logique du premier
ordre.
31
Figure 1.17: Échelle de classification d'ontologies en fonction du spectre sémantique
de McGuiness. (Tirée de Breitman et al., 2007, p. 26)
1.3.2 Expressivité d’un système de représentation de degré formel
Le tableau 1.1, inspiré de Hepp et al. (2008), présente l’échelle d’expressivité de
divers systèmes de représentation formels.
Tableau 1.1
Expressivité de divers systèmes de représentation formels
Échelle
d’expressivité
Système de représentation
Forte Logique d’ordre supérieur
Logique du premier ordre
Logique descriptive
Taxonomie
Entité/Relation
Faible Vocabulaire
L’expressivité associée à un système de représentation de degré formel est une
mesure de sa capacité à exprimer les parties de la réalité à représenter. Une
expressivité forte permet la mise en place de mécanismes de raisonnement
sophistiqués de l’interprétation. En contrepartie, elle nécessite un plus grand effort de
conception et d’interprétation et elle augmente le coût computationnel du
raisonnement (Hepp et al., 2008 ; Oberle, 2006).
32
1.3.3 Classification selon le degré de généralité du domaine représenté
Guarino (1998) a été le premier à proposer une classification des ontologies selon la
généralité du domaine qu'elles représentent:
- l'ontologie de haut niveau (upper level ontology) décrit les concepts de haut
niveau d'un domaine. Par exemple, des sujets tels que le temps ou l'espace
peuvent être décrits dans ce type d'ontologies;
- l’ontologie de domaine (domain ontology) sert à décrire le vocabulaire d'un
domaine spécifique. Les concepts qui la composent sont des spécialisations de
haut niveau;
- l’ontologie de tâche (task ontology) décrit le vocabulaire nécessaire à la
réalisation d'une tâche associée aux concepts définis dans l'ontologie de haut
niveau;
- l’ontologie d’application (application ontology) décrit le vocabulaire d'une
application spécifique.
Gómez-Pérez et al. (2003) proposent une échelle de généralité légèrement différente
pour la classification des ontologies qui est plus élaborée, précise et sans nul doute
plus complexe à utiliser que celle présentée par Guarino:
- l'ontologie de représentation des connaissances (Knowledge Representation
Ontology) décrit le vocabulaire associé aux éléments de modélisation d'un
système de représentation de la connaissance;
- l'ontologie d'usage générique (Generic and Common Use Ontology) décrit les
connaissances de sens commun utilisées dans un domaine particulier de
connaissances;
- l'ontologie de haut niveau (Upper Ontology) décrit les concepts généraux tels
que ceux de temps et d'espace;
33
- d'autres ontologies possèdent la spécificité portée par le sens de leur nom
telles que les suivantes : Domain Ontology, Task Ontology, "Domain-task
Ontology, Method Ontology et Application Ontology".
1.3.4 Ontologie et métadonnée
Une métadonnée est une donnée concernant une autre donnée. Par exemple, les
informations au sujet d'un document, telles que le nom de l'auteur, la date de parution,
le nom de la maison d'édition, etc., sont toutes des métadonnées. Dans le contexte du
Web sémantique, Berners-Lee (1997) définit ainsi la métadonnée : "a machine
understandable information about Web resources or other things". Les ontologies de
type métadonnées visent à définir le vocabulaire d'un domaine, mais pas
nécessairement la sémantique d'un domaine. Elles servent donc de base de
référencement à des systèmes de localisation et de recherche de ressources ou
d'informations. La norme Dublin Core (DC18) et son implantation en langage OWL
(DC-OWL19) est un exemple d'ontologie de type métadonnée. Structuré selon les
éléments présentés au tableau 1.2, le DC-OWL permet le référencement de
documents et son traitement par des applications compatibles avec OWL.
D'autres ontologies de type métadonnées ont été développées. Par exemple, le
Platform for Internet Content Selection (PICS20), mis au point en 1995 par le
consortium international W3C, est une ontologie dédiée au contrôle de l'accès au
contenu de pages Web. Quant au vCard file format, proposé par le consortium Versit
(Apple, IBM, AT&T et Siemens), il est dédié aux applications de type e-business
(Breitman et al., 2007).
18 Dublin Core Metadata Initiative (DCMI): http://www.dublincore.org/
19 Dubling Core - OWL: http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl
20 W3C PICS, Platform for Internet Content Selection (PICS): http://www.w3.org/PICS/
34
Tableau 1.2
Éléments du Dublin Core (tirée de Breitman et al., 2007, p. 178)
Dans OntoCASE, nous utilisons une ontologie de type métadonnée pour définir le
vocabulaire du langage semi-formel qui sera traité.
1.3.5 Ontologie cadre
Nous utilisons le terme d'ontologie cadre dans le même sens que celui que lui
attribuent Guarino (1998) et Gómez-Pérez et al. (2003), c'est-à-dire une ontologie qui
sert à décrire des concepts généraux. De par leur nature générique, certains projets ont
pour objectif de concevoir des ontologies cadres disponibles et partageables par
l'ensemble d'une communauté. Dans OntoCASE, nous avons construit une ontologie
de ce type pour décrire les concepts généraux associés à la représentation des
connaissances. Cette ontologie est au cœur du processus de formalisation.
35
Développée par le IEEE Standard Upper Ontology (SUO) Working Group,
l'ontologie Suggested Upper Merged Ontology (SUMO21), originalement conçue dans
la notation KIF (Knowledge Interchange Format), est aussi disponible en OWL (voir
la figure 1.18). SUMO contient les concepts généraux concernant les sujets suivants
(Niles et Pease, 2001):
- la structure liée au concept, telle que l'instance et la sous-classe;
- les types généraux comme l'objet et le processus;
- les abstractions incluant la théorie des ensembles, les attributs et les relations;
- les unités de mesure;
- les concepts liés au temps comme la durée;
- les relations de méronymie et d'holonymie
- les relations sémiotiques de base
Figure 1.18: Taxonomie des classes de haut niveau dans SUMO-OWL.
L'ontologie de la représentation des connaissances (KR Ontology) de Sowa (2000b)
se base sur la sémiotique de Charles Sanders Peirce et sur la catégorisation de
l'existence de Alfred North Whitehead (Breitman et al., 2007). Trois grands axes
21 IEEE Standard Upper Ontology Working Group, Suggested Upper Merged Ontology (SUMO):
http://www.ontologyportal.org/
36
structurent l'ontologie KR (voir le tableau 1.3), soit (1) les entités de catégorie
Physiques (qui existent dans l'espace et le temps) et de catégorie Abstraites (qui
existent mais qui ne sont pas dans l'espace et ne sont pas dans le temps.); (2) les
choses qui sont des Continuants (qui sont indépendantes du temps) ou des Occurants
(qui évoluent, changent dans le temps); (3) les choses qui peuvent être Indépendantes
(qui n'ont pas à être mises en relation avec d’autres choses pour exister), Relatives
(qui existent par rapport à quelque chose d'autre) ou Médiationnelles (qui existent
pour mettre en relation deux choses).
Tableau 1.3
L'ontologie de KR (Tirée de Sowa, 2003)
NeOn22, le projet de la communauté européenne de développement d'une
méthodologie et d'outils propres au Web sémantique, possède sa propre ontologie
cadre organisée sous la forme de patrons de conception ontologique (Ontology
Design Pattern-ODP). Proposé par Gamma et al. (1999), le concept de patron de
conception désigne une abstraction qui établit une structure afin d'encadrer les bonnes
pratiques associées aux activités d'un domaine d'application. Les ODP sont des
patrons de conception associés à la modélisation d'ontologies. La taxonomie de haut
niveau des divers types d'ODP est présentée à la figure 1.19. L'ODP offre un
catalogue de petites ontologies qui sont modulaires, évolutives et regroupées en
domaines d'application.
22 Motta, NeOn Project: http://www.neon-project.org/web-content/
37
Figure 1.19: Taxonomie de patrons de conception ontologique du projet NeOn. (Tirée de ODP.org, 2008)
38
Le projet CYC a pour objectif de créer une ontologie cadre qui contient la définition
de concepts couvrant une multitude de domaines d'application. Matuszek, Cabral,
Witbrock et Deoliveira (2006) indiquent qu’il a été évalué que pour ce projet, près de
900 jours-personnes ont été employés pour construire CYC pendant plus de vingt ans
et que près de 2,2 millions d'assertions, de faits et de règles ont été nécessaires pour
décrire les 250 000 termes de cette ontologie. Le projet OpenCYC23 est une version
de type OpenSource de CYC. Une version dans le formalisme OWL est aussi
disponible dans le projet OpenCYC. Sous Things, on retrouve les deux branches
Intangible Things (qui sont les choses qui ne sont pas physiques) et Individuals (qui
concerne la collecte de toutes les choses qui ne sont pas des ensembles ou
collections). Les choses peuvent être concrètes ou abstraites et inclure, entre autres,
des objets physiques, des événements, des nombres, des relations et des groupes
(Cycorp Inc., 2002).
1.4 Langages semi-formels de représentation de la connaissance
Un langage de degré semi-formel (Uschold et Gruninger, 1996) est un formalisme
d'expression de la connaissance dont la souplesse grammaticale et sémantique rend
conviviale son utilisation. Ce type de formalisme, qui fait généralement appel au
format graphique, est parfois employé pendant l'étape de conception d'un système
(Rumbaugh et al., 1999) ou encore pour favoriser le transfert d’expertise dans les
organisations (Basque et al., 2008b ; Basque et Pudelko, 2010b) ou encore
l’apprentissage dans des situations éducatives (Basque et Pudelko, 2010c ; Kinshuk et
al., 2008 ; Paquette, 2002a), ainsi que pour susciter les échanges pendant une séance
de remue-méninges, ou plus simplement pour représenter graphiquement un énoncé.
Point de départ pour l'utilisation d'OntoCASE, nous présentons dans les pages qui
suivent quelques langages semi-formels qui pourraient éventuellement tous être
intégrés à OntoCASE.
23 Cycorp Inc., Formalized Common Knowledge: http://www.opencyc.org/
39
1.4.1 MindMap
C'est dans les années 1970 que Tony Buzan développa une technique de
représentation de connaissances appelée Mind Mapping, qui fait appel à un langage
graphique combinant du texte, des images et des lignes pour représenter une idée ou
un thème (voir l'exemple de la figure 1.20). Les éléments graphiques d’une MindMap
ne possèdent aucune sémantique particulière sinon qu’une branche signifie une
ramification du concept se trouvant à la racine de la branche. C’est pourquoi ce type
de représentation est dit semi-formel. Au centre du graphique, est placé le concept à
développer. Chacune des branches concerne un thème à développer autour du concept
central. Chacun des thèmes peut aussi se développer en sous-thèmes. Le logiciel
MindMap24, développé pour la conception de ce type de représentation, permet
d'associer une image ou un document textuel à chaque thème et sous-thème. Le
langage du Mind Mapping est un formalisme qui possède très peu de contraintes et
d'exigences, laissant ainsi libre cours à la liberté d'expression et à la créativité. En
contrepartie, le manque de sémantique formelle associé à ce type de représentation
rend pratiquement impossible un traitement automatisé par un système informatique.
Figure 1.20: Exemple de schéma MindMap. (Tirée de Okada et al, 2008, p. xi)
24 ThinkBuzan.com, iMindMap software: http://www.thinkbuzan.com/uk
40
1.4.2 Carte conceptuelle (Concept map)
S’apparentant au graphe d'entités-relations de Chen (1976), la technique de la carte
conceptuelle ( concept mapping ) développée par Joseph Novak en 1972 (Novak et
Cañas, 2006) permet de représenter une hiérarchisation de concepts selon une lecture
du haut vers le bas (voir l'exemple de la figure 1.21). Les concepts sont reliés les uns
aux autres par des relations portant des étiquettes textuelles qui définissent les
propriétés unissant les concepts. Ici encore, la sémantique du concept et de la relation
n'est pas formellement définie. Un logiciel intitulé CMapTool25s a été développé sur
la base de la technique de Novak à l’Institute for Human and Machine Cognition
(IHMC).
Figure 1.21: Exemple de modèle représenté dans le formalisme Concept map. (Tirée
d'Okada et al, 2008, p.xi)
25 CmapTools, IHMC CmapTools knowledge modeling kit: http://cmap.ihmc.us/conceptmap.html
41
1.4.3 Thinking Maps
Les Thinking Maps (Hyerle, 2008) font référence à différentes représentations
graphiques associées chacune à une habileté cognitive différente telle que la
définition dans un contexte, la discrimination d'attributs, la comparaison, la
composition, la classification ou encore le raisonnement de cause à effet. La
figure 1.22 présente une synthèse des représentations utilisées dans les Thinking
Maps. On constate que pour une habileté cognitive particulière, il existe un
formalisme correspondant. Plus complexe dans son utilisation que les deux
formalismes précédents, le langage des Thinking Maps est un langage qui stimule le
raisonnement formel selon Hyerle.
Figure 1.22: Synthèse du langage des Thinking Maps. (Tirée de Hyerle 2008, p. 50)
1.4.4 Modèle orienté objet
À la frontière entre le degré semi-formel et formel, le modèle orienté objet encapsule
dans un objet (la classe) les abstractions concept, attribut et méthode. La classe est
ainsi un objet qui possède des attributs dont la dynamique est encapsulée dans la
m
p
e
m
G
e
c
f
c
F
(
L
2
S
m
éthode.
C
p
rédéfinies
d
e
ux par des
m
odélisatio
n
G
roup (O
M
e
n dévelop
p
c
onnaissanc
f
igure 1.23
p
c
lasse UML
F
igure 1.23:
(
Tirée de R
h
1.4.5 Modé
l
L
e langage
2
010) est a
u
S
pécialeme
n
C
ertaines re
l
d
ans la sém
a
associatio
n
n
orienté o
b
M
G UML, 19
9
ement de lo
es (Berardi
p
résente le s
.
Diagram
m
h
em 2006, p
.
l
isation par
o
de modélis
a
u
ssi un lang
a
n
t conçu po
u
l
ations telle
s
a
ntique du
l
n
s. Le Unifi
e
b
jet le plus
97
-2006).
B
giciels, l'U
M
et al., 200
5
chéma d'un
m
e de classe
.
181)
o
bjets typés
a
tion par ob
j
a
ge de repré
u
r l'ingénier
i
s
que la g
é
l
angage. Le
s
e
d Modelin
g
répandu et
B
ien que spé
M
L peut aus
s
5
; Martin,
2
arbre de dé
c
s UML po
u
j
ets typés (
M
sentation d
e
i
e pédagogi
q
é
néralisatio
n
s
objets peu
v
g
Language
normalisé
cialement c
o
s
i être utilis
é
2
002 ; Rhe
m
c
ision repré
s
u
r représen
t
M
OT) dével
o
e
connaissa
n
q
ue, ce lang
a
n
et la co
m
v
ent aussi ê
t
(UML) est
par l'Objec
t
o
nçu pour l
a
é
pour la re
p
m
, 2006). L'
s
enté par un
t
er un arbr
e
o
ppé par P
a
n
ces de degr
é
a
ge a aussi
é
m
position s
o
t
re reliés e
n
le langage
t
Managem
e
a
modélisat
i
p
résentation
exemple de
diagramme
e
de décisio
a
quette (200
2
é
semi-for
m
é
té utilisé d
a
42
o
nt
n
tre
de
e
nt
i
on
de
la
de
n.
2
a,
m
el.
a
ns
43
des projets visant le transfert d'expertise dans les organisations (Basque et al., 2008b ;
Basque et Pudelko, 2010b) et l’apprentissage dans des situations de formation
(Basque et Pudelko, 2010a). Ce langage permet la représentation de connaissances
déclaratives, procédurales, stratégiques et factuelles ainsi que la mise en relation de
ces connaissances par des relations typées (spécialisation, composition, instanciation,
intrant/produit, précédence, régulation et application). Des détails sur ce langage, qui
est le langage de représentation utilisé dans cette thèse, sont fournis à l'appendice A.
L'utilisation d'objets typés ainsi que la propriété de représenter des connaissances
selon un double niveau d'abstraction (factuel et abstrait) font de ce langage un
système de représentation apte à être traité par un système de raisonnement
automatique dans la mesure où la polysémie associée à certaines primitives est levée.
À titre d'exemple de modèle, la figure 1.24 présente le modèle descriptif (le
métamodèle) du langage MOT en langage MOT.
Figure 1.24: Métamodèle du langage MOT présenté dans le langage MOT. (Tirée de
Paquette 2002, p. 73)
Modèle par
objets typés
Connaissances
Liens
Application
A
« s'applique à »
Intrant-produit
I/P
« est-intrant-à ou
produit »
Précédence
P
« précède »
Instanciation
I
« a-pour-instance »
Spécialisation
S
« est-sorte-de »
Régulation
R
« régit »
Composition
C
« est-composé-de »
Origine
Destination
Relations
S
S
C
C
C
C
C
Faits Habiletés
Connaissances
abstraites
Exemple
Trace
Énoncé Principe
Procédure
Concept
Règles quant à
l'origine et à
la destination
des liens
Règles quant
aux cycles et à
la multiplicité
des liens
R R
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Expression
Symbole
Nom
C
C
C
Figure
Nom C
C
S
44
1.5 Langages formels de représentation de la connaissance
Un langage de degré formel (Uschold et Gruninger, 1996) est un formalisme dont la
sémantique sans ambiguïté autorise un traitement automatisé du modèle exprimé dans
ce langage. Pour Chein et Mugnier (2008), un système de représentation formel doit :
- comporter une sémantique formelle;
- posséder un fondement logique;
- permettre de représenter la connaissance de manière structurée;
- posséder de bonnes capacités computationnelles et
- permettre à un utilisateur de comprendre et avoir le contrôle de chacune des
étapes de construction d'une base de connaissances.
Dans les pages qui suivent, nous présentons quelques langages formels envisagés
pour servir de langages cibles à OntoCASE.
1.5.1 Taxonomie et le thesaurus
Dans le contexte de la théorie de l'information, Daconta et al (2003, p.146)
définissent une taxonomie en une classification hiérarchique de termes selon le
principe parent-enfant par l'utilisation de la relation de généralisation (is-a, type-of)26.
Par exemple, si l'on considère un fait a comme étant de type A et que le type A est un
sous-type de B, alors il est permis de conclure que a est aussi un fait de type B.
Le consortium ANSI/NISO (2005) définit un thésaurus comme suit:
“A controlled vocabulary in a known order and structured so that equivalence,
homographic, hierarchical, and associative relationship among terms are
displayed clearly and identified by standardized relationship indicator that
are:(a) to facilitate retrieval of document and (b) to facilitate consistency in the
26 the classification of information entities in the form of a hierarchy, according to the presumed relationship of a
real-world that they represent
45
indexing of written or otherwise recorded documents and other items, mainly for
post coordinate information storage and retrieval systems.”
Ainsi, en plus de posséder une structure de type taxonomique, le thésaurus permet de
relier les termes qui le composent par des relations de synonymie (équivalence) et des
relations associatives.
La taxonomie et le thésaurus sont des types d’ontologies. Ce sont des ontologies
restreintes toutefois, utilisant les propriétés de subsomption (pour la taxonomie et le
thésaurus), d'équivalence et d'association (pour le thésaurus), mais non les propriétés
d'axiomatisation, de quantification et de cardinalité propres aux ontologies.
1.5.2 Langage de descriptions pour la représentation de connaissances
La logique des descriptions (DL) est un système de représentation des connaissances
qui est un sous-ensemble de la logique du premier ordre. Représenter les
connaissances d’un domaine en DL implique un classement de celles-ci selon un plan
terminologique et un plan assertionnel (Gašević et al., 2006d, p.25). Dans une base
de connaissances, la terminologie est définie dans la TBox. La ABox, elle, permet la
définition des assertions selon le vocabulaire défini dans la TBox. Le vocabulaire se
compose de concepts et de rôles. Les concepts servent à définir un ensemble
d’individus, alors que les rôles, eux, servent à définir les relations binaires entre les
individus. Dans la TBox, les concepts et les rôles sont représentés de façon atomique
(le nom des concepts et des rôles) ou de façon complexe (termes de concepts et de
rôles). Le tableau 1.4 présente l’exemple d’une base de connaissances exprimée en
DL.
46
Tableau 1.4
Exemple d’une base de connaissances en DL (inspiré de Baader et al., 2004)
Représentation en DL Signification
La terminologie du domaine (TBox)
Une Femme est une Personne de sexe féminin
Un Homme est une personne qui n’est pas une Femme
Une Mère est une Femme pour laquelle il existe une
personne qui est son enfant.
Les assertions (ABox)
Marie est une Femme
Julie est une Mère
Julie a un enfant du nom de Marie
Point optimum entre expressivité et décidabilité, la DL est utilisée en tant que langage
abstrait pour la représentation ontologique d'un domaine. Le tableau 1.5 présente les
constructeurs en association avec les attributs27 langagiers de la DL.
Tableau 1.5
Constructeurs de la DL et leur correspondance langagière (tirée de Gómez-Pérez et
al., 2003, p. 17)
27 Par exemple, à l’OWL-DL est associé le DL-SHOIN Horrocks, OWL: A Description Logic Based Ontology
Language
Femme(MARIE)
Mère(JULIE)
aUnEnfant(JULIE, MARIE)
Femme Personne Féminin
Homme Personne ¬Femme
Mère Femme aUnEnfant.Personne
47
1.5.3 Graphe conceptuel
Inspiré des travaux de Pierce, c'est en 1976 que Sowa met au point une représentation
graphique de la logique du premier ordre : le Conceptual Graph (CG) (Sowa, 1976).
À la base du vocabulaire graphique du CG, on retrouve le rectangle pour représenter
un concept, l'ellipse pour représenter la propriété qui unit les concepts et le vecteur
pour représenter le flux de lecture du graphe. La représentation de l'instance d'un
concept est assurée par l'introduction du délimiteur deux-points ':' dans la
construction de l'étiquette d'un concept. À l'exemple de la figure 1.25, la
représentation Child:Paul indique que Paul est un enfant (Child). L'ellipse possess
indique que Paul possède (possess) une voiture (Car). Les chiffres posées sur les
vecteurs sert à guider l'ordre de lecture des éléments du graphe. Ainsi, autour de la
propriété play3, nous pouvons lire que « il y a Paul est une personne qui joue (play)
avec sa(possess) petite (attr Size :Small) voiture.
Figure 1.25: Illustration d’un graphe conceptuel tel que proposé par Sowa. (Tirée de
Chein et Mugnier, 2008, p. 26.)
48
1.5.4 Langage ontologique
Le concept d'ontologie en est un complexe que nous avons abordé aux sections 1.2 et
1.3. Dans la présente section, nous nous intéressons à des aspects tels que l'historique
de l'évolution des langages ontologiques et leurs particularités.
La figure 1.26 indique que c’est au début des années 1980 qu’est apparue la première
implantation d’un langage ontologique. Depuis lors, une variété d’implantations rend
accessible une multitude de langages comportant chacun leurs particularités propres.
Adapté de Gómez-Pérez et al. (2003, p. 286), le tableau 1.6 présente un bilan
comparatif, datant de janvier 2003, des principales particularités de plusieurs
langages ontologiques. Dans les cellules, un ‘+’ indique que le langage possède la
une particularité alors qu’un ‘-’ indique que la particularité n’appartient pas au
langage, et finalement, un ‘W’ indique que la particularité peut être réalisé de façon
détournée (« workaround »). On constate que les langages OCML, Ontolingua, et
LOOM semblent particulièrement intéressants, car ils possèdent de nombreuses
particularités. Certaines d'entre elles permettent la représentation de connaissances
procédurales et la représentation de règles. En ce sens, l'OWL est plus limité, d'autant
plus qu'aucun mécanisme de détournement (« workaround ») ne semble exister pour
la représentation de connaissances procédurales. Cependant, si on le compare au
RDF(S), qui est une alternative à OWL pour le Web sémantique, OWL offre une
meilleure expressivité, notamment pour l'expression des restrictions dans la
taxonomie de concepts. Combiné à SWRL, OWL permet la représentation de
connaissances à base de règles.
49
Figure 1.26: Évolution des langages ontologiques. (Tirée de Calero et al., 2006, p. 37)
50
Tableau 1.6
Sommaire des caractéristiques des langages ontologiques (adapté de Gómez-Pérez et al., 2003, p. 286)
swrl
51
1.5.5 Langage à base de règles
Les langages de représentation de connaissances, tels que OWL, sont conçus pour
décrire un domaine de connaissances par la construction de classes pour représenter
les concepts du domaine, d'individus pour en représenter les faits et de propriétés
pour représenter les relations entre les faits du domaine. En contrepartie, les langages
à base de règles sont conçus pour générer de nouvelles assertions à partir de faits
préalablement établies (Breitman et al., 2007). Les langages à base de règles, tels que
le PROLOG, sont développés selon les principes de la programmation logique
(Lloyd, 1987).
Dans la représentation de connaissances, une sous-classe de la DL, la Description
Logical Programming (DLP) (Grosof et al., 2003) permet l’addition de règles en
complément à la TBox et à la ABox. L’expression d’une règle dans sa forme logique
s’écrit comme suit: (« si un individu est une instance de C, alors l’individu
appartient aussi à D où C est un antécédent et D est le conséquent») ou encore dans sa
forme informatique elle s’écrit comme suit : « IF … THEN… » .
Au moment d’écrire ces lignes, le Semantic Web Rule Language (SWRL) en est à
l'étape de proposition au W3C. Ce langage à base de règles est un sous-ensemble de
RuleML28. Spécialement conçu pour s'intégrer à une base de connaissances en OWL,
le langage SWRL propose un formalisme à base d'implications entre un groupe
d'antécédents et une conclusion, qui sont en fait des agrégations d'atomes (voir le
métamodèle de la figure 1.27 tel que proposé par l'Ontology Definition Model
(ODM29)). Un atome se compose d'une liste de termes et/ou d'une composition de
prédicats. En voici quelques exemples : sameAs(x,y), où x et y sont des variables ou
28 Boley, The Rule Markup Initiative: http://ruleml.org/
29 OMG ODM, Ontology Definition Metamodel: OMG Adopted Specification:
http://www.omg.org/spec/ODM/1.0/Beta2/PDF/
CD
52
des individus OWL; différentFrom(x,y ), où x et y sont des variables ou des individus
OWL et builtIn(r, x, …) où r est un prédicat et x ainsi que chaque élément de la suite
sont des variables ou des données OWL. Le détail de la discussion concernant la
prédicat de type builtIn est présenté à la section 3.1.8.2 p. 154 et à la section 3.2.5, p
168.
53
Figure 1.27: Métamodèle UML du Semantic Web Rule Language. (Tirée de Brockmans et al., 2006,p. 9).
54
1.5.6 Business Process Modeling Notation
Le Business Process Modeling Notation (BPMN30) n’est pas un langage ontologique,
mais un langage de modélisation de degré formel orienté vers la représentation de
connaissances procédurales. Chaque élément de la notation (voir la figure 1.28)
possède une sémantique non ambigüe qui permet un traitement par un système
automatique.
Figure 1.28: Éléments d'un modèle BPMN. (Tirée de Weske, 2007, p. 209)
La computationnalité de ce langage réside en une transformation du modèle sous la
forme d'un réseau de Petri, où chacun des nœuds du réseau représente soit une
transition (le carré), soit une opération de contrôle du flux (le cercle), et où le vecteur
représente le flux de l'information. Dans l'exemple de la figure 1.29, une solution
possible de l'exécution de la transition t2 résulte de l'exécution de la transition t1 et t4.
30 OMG BPMN, Object Management Group/Business Process Management Initiative: http://www.bpmn.org/
55
Figure 1.29: Exemple de réseau de Pétri pour représenter un workflow. (Tirée de
Weske, 2007, p. 271)
1.6 Transformation de modèles par la technique de métamodélisation
La relation "méta" est utilisée en représentation pour relier deux entités d'un même
sujet, dont les niveaux d'abstraction diffèrent. Par exemple, une métaconnaissance est
une connaissance à propos d'une connaissance (Pitrat, 1990). De même, un
métamodèle est un modèle à propos d'un modèle. La relation 'à-propos-de' est une
relation de définition entre les objets reliés. Le métaobjet définit l'objet. Ainsi, l'objet
est une instance du métaobjet. En ce sens, un métamodèle est la définition des
symboles, de la syntaxe et de la sémantique des modèles qui servent à représenter un
domaine d'application (Kadima, 2005).
Dans les pages qui suivent, nous revenons sur les concepts d’abstraction et de
couches d’abstraction et présentons quelques applications liées à ces concepts. Dans
le développement d’OntoCASE, les concepts abstraction et couches d’abstraction
sont utilisés pour la définition du cadre théorique et pour l’implantation informatique
du processus de transformation de modèle.
1.6.1 Abstraction et couches d'abstraction
La métamodélisation est utilisée en développement logiciel (Gašević et al., 2006b ;
Kadima, 2005 ; OMG MDA, 2007 ; Steinberg et al., 2008) et en développement
d'ontologies (Đurić, 2004 ; Đurić et al., 2005b ; Đurić et al., 2005a ; Gašević et al.,
2006d, 2006a ; Gerbé et Mineau, 2008 ; IBM, 2007 ; OMG ODM, 2007 ; Yang,
2006). Cette technique permet la représentation d'un domaine sous la forme de
56
modèles de données du domaine, de modèles du domaine, de langage de modélisation
ainsi que de métalangages (voir la figure 1.30). Les données du domaine de la couche
M0 sont des représentations factuelles d'un domaine du discours, dont les modèles du
domaine de la couche M1 constituent l'abstraction. Le modèle de la couche M2, aussi
nommé métamodèle, définit le langage de modélisation utilisé pour modéliser le
domaine. Le modèle de la couche M3, nommé métamétamodèle, définit le langage de
la couche M2. Le modèle de la couche M3 est réflexif, c'est-à-dire qu'il a la propriété
de se définir lui-même.
Pour un métamétamodèle donné, l'architecture de métamodélisation assure une
interopérabilité entre les langages de modélisation (modèles de la couche M2). Cette
interopérabilité soutient la traduction d'un modèle de domaine représenté selon un
langage source vers un modèle de domaine représenté selon un langage cible. La
transformation de modèles de domaine entre langages est l'activité principale que
soutient cette architecture.
Figure 1.30: Couches d'abstraction de la métamodélisation.
Définit Définit Représente
57
1.6.2 Espace de modélisation
L'espace de modélisation (EM) (Gašević et al., 2006e) est une sttructure de
modélisation réalisée à partir d'un métalangage particulier. La figure 1.31 présente un
exemple de différents espaces de modélisation.
Figure 1.31: Espaces de modélisation EBNF, RDFS et MOF adaptée de Gašević et
al. (2006e p. 132).
Le premier EM présenté est l'Extended Backus-Naur Form (EBNF31), modèle qui
définit la grammaire du langage Java. Celui-ci sert de modèle aux programmes Java
qui, eux-mêmes, sont des modèles pour décrire une représentation de la réalité. Un
autre EM, le RDFS32, est le métalangage de l'Ontology Web Language (OWL33) qui
31 ISO-14977, The standard metalanguage Extended BNF: http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
32 Beckett et McBride, RDF/XML Syntax Specification (Revised): http://www.w3.org/TR/rdf-syntax-grammar/
58
permet de construire des ontologies, autres modèles représentant la réalité. À la
figure 1.31, le MOF Meta Object Facility (MOF34) sert d'EM pour le métamodèle
décrivant l’Unified Modeling Language (UML35) qui sert à la construction des
modèles UML. Pour réaliser la transformation entre modèles, il importe que chaque
métamodèle (ou langage de modélisation) soit dans le même espace de modélisation.
Si ce n'est pas le cas, une importation dans l'EM, supportant la transformation, doit
être réalisée.
1.6.3 Processus de transformation de modèles
La transformation d'un modèle est l'une des applications importantes de l'Architecture
Conduite par les Modèles (ACM36) de l'OMG-MDA (2007). Elle vise la production
automatique d'un modèle cible à partir d'un modèle source par l’exécution d'un
ensemble de règles de transformation qui régissent le déroulement du processus de
transformation. Ce processus de transformation (schématisé à la figure 1.32) produit
un modèle cible à partir des informations contenues dans le modèle source. Les règles
d'utilisation des informations du modèle source sont dictées par le métamodèle
(couche M2) du modèle source. Le métamodèle source est aussi un intrant au
processus de transformation. Les règles d'interprétation des informations du modèle
cible sont contenues dans le métamodèle cible. Le métamodèle cible est aussi un
intrant du processus de transformation. Remarquons que, même si les règles de
représentation changent d'un modèle à l'autre, les deux modèles servent à représenter
le même objet de la réalité.
33 W3C OWL, Ontology Web Language: http://www.w3.org/2004/OWL/
34 OMG MOF, OMG's MetaObject Facility: http://www.omg.org/mof
35 OMG UML, UML® Resource Page: http://www.uml.org/
36 Traduction de Model Driven Architecture (MDA); OMG MDA, OMG Model Driven Architecture:
http://www.omg.org/mda/
D
Q
p
l
c
p
l
3
v
3
h
F
D
u point
Q
uery/View
/
p
roduction
d
l
'Object C
o
c
ontraintes
p
rocessus d
e
l
'espace de
m
3
7
OMG MOF-
Q
v
1.0 http://ww
w
3
8
OMG
h
ttp://www.om
g
F
igure 1.32:
de v
u
/
Transform
a
d
e vues dan
s
o
nstraint L
sur des él
é
e
transform
a
m
odélisatio
n
Q
VT, Document
s
w
.omg.org/spec/
Q
OCL,
O
g
.org/technolog
y
Processus
d
u
e techno
l
a
tion (MOF
-
s
les méta
m
anguage (
O
é
ments de
m
a
tion entre d
n
MOF.
s
associated wi
Q
VT/1.0/
O
bject Co
n
y
/documents/for
m
d
e transfor
m
l
ogique,
l
-
QVT
37
) po
u
m
odèles et la
O
CL
38
) qu
i
m
odèle U
M
es modèles,
th Meta Object
n
straint L
a
m
al/ocl.htm
m
ation de mo
l
es outils
u
r la reche
r
transforma
i
permet
l
M
L, sont u
t
pourvu qu
e
t
Facility (MO
F)
a
nguage S
p
dèles dans l
comme
r
che dans l
e
a
tion de mo
d
l
'expression
t
ilisés pour
e
ces proces
s
F
) 2.0 Query/Vi
e
p
ecification,
’OMG-MD
A
le
MO
e
s modèles,
d
èles ainsi
q
formelle
conduire
d
s
us soient d
a
e
w/Transformat
i
version
2
A
.
59
O
F-
la
q
ue
de
d
es
a
ns
i
on,
2
.0:
L
e
c
f
t
(
r
O
U
t
d
F
1.6.4 Princi
p
L
e principe
e
t le modèl
c
onception
f
igure 1.33)
,
t
ransposées
(
2006) utili
s
r
estreignent
O
WL-DL.
U
ne limite
t
ransformat
i
d
ans la tr
a
F
igure 1.33:
p
e de transf
o
de transfor
m
e cible pos
s
de règles
d
,
une relati
o
en relation
s
ent cette ap
p
à une sous
importante
i
on est réali
s
a
nsformatio
n
Processus
d
o
rmation pa
r
m
ation paral
s
èdent une
d
e transfor
m
o
n R et u
n
R' et en en
t
p
roche pour
-classe de
m
de la tra
n
s
é sans teni
r
n
. En com
p
d
e transfor
m
r
allèle
lèle a com
m
structure d
e
m
ation de t
y
n
e entité E
t
ité E' dans
l
la concepti
o
m
odèles M
O
n
sformation
r
compte de
p
araison av
e
m
ation parall
è
m
e pré-cond
i
e
métamodè
y
pe "un à
u
du modèle
le modèle
c
o
n du langa
g
O
T proche
d
parallèle
e
la sémanti
q
e
c la trad
u
è
le.
i
tion que le
m
le similaire
u
n". Par ex
e
source so
n
c
ible. Paque
t
g
e MOT-O
W
d
u langage
d
e
st que le
q
ue des lan
g
u
ction en l
i
m
odèle sou
r
permettant
e
mple (voir
n
t directem
e
t
te et Rogo
z
W
L, mais ils
d
es ontolog
i
processus
g
ages en ca
u
i
nguistique,
60
r
ce
la
la
e
nt
z
an
se
i
es
de
u
se
la
t
m
d
L
g
d
t
a
a
N
c
F
t
ransformat
i
m
ot sans co
d
ésambiguï
s
1.6.5 Princi
p
L
e but spé
c
g
rammaire
d
d
ans le mo
d
t
ransformat
i
a
insi qu'un
m
a
u process
u
N
otons que
c
ible.
F
igure 1.34:
i
on parallèl
e
nsidérer le
s
s
ation auto
m
p
e de la tran
c
ifique de
l
d
u langage
d
èle source
.
i
on orthogo
n
m
odèle de t
r
u
s de transf
o
le modèle
s
Processus
d
e
est un pro
c
s
ens des mo
t
m
atique
sformation
o
l
a transfor
m
source afi
n
.
En plus d
u
n
ale a, en
e
r
ansformati
o
o
rmation de
s
ource est e
x
d
e transfor
m
c
essus qui p
r
t
s qui sont
t
o
rthogonale
m
ation ortho
g
de lever l
e
u
modèle s
o
e
ntrée, une
r
o
n qui comp
o
fonctionne
r
x
primé dans
m
ation ortho
g
r
oduit une t
r
t
raduits, lim
i
g
onale est
e
s ambiguït
é
o
urce à tra
n
r
eprésentati
o
o
rte un ens
e
r adéquate
m
s
la même s
y
g
onale.
r
aduction e
n
i
tant ainsi l
e
de prendre
é
s sémanti
q
n
sformer, l
e
o
n du méta
m
e
mble de rè
g
m
ent (voir l
a
y
ntaxe que
l
n
mode mot
-
e
s capacités
en compte
q
ues conten
u
e
processus
m
odèle sou
r
g
les permett
a
a figure 1.3
4
l
e métamod
è
61
-
à-
de
la
u
es
de
r
ce
a
nt
4).
è
le
S
p
d
c
r
l
m
r
c
s
F
A
e
r
S
chématisé
p
rocessus c
o
d
e désambi
g
c
ontrôlent
l
r
eprésentati
o
l
e sous-pro
c
m
odèle sou
r
r
éférence.
N
c
oncernant
l
s
ource sont
d
F
igure 1.35:
A
près l'exé
c
e
xécute l'ét
a
r
éférence a
fi
à la figur
e
o
ntrôlé par l
e
g
uïsation et
l
es sous-pr
o
o
n de la gra
m
c
essus de
d
r
ce et les cl
N
ous verron
s
l
e modèle
d
d
ésambiguï
s
Modèle du
c
ution de la
d
a
pe de conv
e
i
n de produi
r
e
1.35, le
p
e
modèle de
d'un modèl
e
o
cessus de
m
maire du
m
d
ésa
m
b
iguïs
assent en f
o
s
un peu pl
u
d
e référence
s
és.
processus d
e
d
ésambiguï
s
e
rsion des él
é
r
e le modèl
e
p
rocessus d
e
transforma
t
e
de référen
c
désambiguï
s
m
odèle sour
c
ation inter
p
o
nction des
c
u
s loin (voi
r
. Nous diro
n
e
transform
a
s
ation, le pr
o
é
ments désa
m
e
cible.
e
transform
a
t
ion. Ce mo
d
c
e, contient
u
s
ation et d
e
c
e (le modè
l
p
rète les él
é
concepts c
o
r
la section
ns alors qu
e
a
tion orthog
o
o
cessus de t
r
a
mbiguïsés c
a
tion ortho
g
d
èle, compo
s
un ensembl
e
e conversi
o
l
e du méta
m
é
ments con
o
ntenus dan
s
3.1.3.2, p.1
e
les éléme
n
o
nale.
r
ansformati
o
ontenus da
n
g
onale est
s
é d'un mod
è
e
de règles
q
o
n. Fort d'
u
m
odèle sour
c
n
tenus dans
s
le modèle
29) les dét
a
n
ts du mod
è
o
n orthogon
a
n
s le modèle
62
un
è
le
q
ui
u
ne
c
e),
le
de
a
ils
è
le
a
le
de
63
1.6.6 Transformation d'un modèle semi-formel en ontologie
Compte tenu de l’importance de la formalisation des connaissances dans le processus
de construction d’une ontologie, quelques auteurs proposent des solutions pour
formaliser un modèle semi-formel en ontologie.
1.6.6.1 Transformation d’un modèle de type Concept Map
La carte conceptuelle (voir la section 1.4.2) est un système de représentation composé
de nœuds pour représenter des entités et de liens pour représenter des relations entre
les entités. Pour la conception d’ontologies OWL à partir de ce type de représentation
semi-formelle, Eskridge, Hayes et Hoffman (2006) ont conçu l’application
CmapTools Ontology Editor (COE). Castro et al. (2006) utilisent la carte
conceptuelle pour l’élicitation semi-formelle de l’expertise avant de la formaliser en
ontologie OWL au moyen de COE. Quant à Park et Hunting (2003), plutôt orientés
vers le « TopicMaps », ils proposent un ensemble de méthodes, techniques et
technologies pour intégrer le référencement sémantique d’objets du Web par
l’intermédiaire d'un modèle de type ConceptMap de degré semi-formel.
1.6.6.2 Architecture conduite par les modèles et le développement d’ontologies
L’Ontology Definition Metamodel (ODM)39 est une application de la méthode
d’architecture conduite par les modèles qui est dédiée à la production d’ontologies
OWL à partir de modèles UML. La figure 1.36 présente le contexte de modélisation
d’une ontologie dans la perspective de l’architecture conduite par les modèles selon la
spécification de l’OMG40. Dans l’espace de modélisation du MOF, le métamodèle
39 OMG ODM, Ontology Definition Metamodel: OMG Adopted Specification:
http://www.omg.org/spec/ODM/1.0/Beta2/PDF/
40 OMG MDA, OMG Model Driven Architecture: http://www.omg.org/mda/
o
f
d
2
U
d
s
F
s
L
c
c
e
4
4
o
ntologique
f
ormalisme
d
e l’espace
2
006c, p. 2
1
U
ML est pr
o
d
u modèle
s
s
ection 1.6.
6
F
igure 1.36
s
émantique.
L
e projet d
e
c
onsacre s
e
c
onduite p
a
e
nsemble u
n
4
1
Le métamodè
l
4
2
Eclipse found
(ODM
41
)
MOF. Un
c
de modélis
a
1
8). À l’ori
g
o
duit pour
r
s
ont transfo
r
6
.
: La modél
(Tirée de
G
e
modélisat
i
e
s activités
a
r les modè
n
ifié de mé
t
l
e de l’ODM es
t
ation, Eclipse
M
définit la
c
onvertisseu
r
a
tion MOF
à
g
ine du pro
c
r
eprésenter l
r
més selon l
’
isation d’o
n
G
ašević et al.
i
on (MDT)
4
2
à la prom
o
les au sein
t
amodèles,
d
t
présenté à l’ap
p
M
odeling Project
structure i
n
r
XML/XS
L
à
l’espace d
e
c
essus de c
o
e domaine
d
’
une des m
é
n
tologie da
n
, 2006c, p.
1
2
de la co
m
o
tion des t
e
de la Co
m
d
’outils et
d
p
endice E.
: http://www.ec
l
n
terne du
d
L
T assure l
a
e modélisat
i
o
nstruction
d
d
u discours
é
thodes de t
r
n
s le conte
x
1
75)
m
munauté d
e
e
chnologies
m
munauté
E
d
e normes d
l
ipse.org/mo
d
el
i
d
ocument
O
a
traduction
i
on RDFS (
G
d
e l’ontolo
g
à modéliser
r
ansformati
o
x
te de l’AC
M
e
s développ
basées sur
E
clipse en
f
e mise en
œ
i
ng/
O
WL dans
de l’ontolo
g
G
ašević et
a
g
ie, un mod
è
. Les éléme
n
o
n décrites
à
M
et du
W
eurs d’Ecli
p
l’architect
u
f
ournissant
œ
uvre. L’E
M
64
le
g
ie
a
l.,
è
le
n
ts
à
la
W
eb
p
se
u
re
un
M
F
65
Ontology Definition Metamodel (EODM43), qui était jusqu’en 200844 un sous-projet
du projet de modélisation d’Eclipse, offre une représentation de l’ODM dans l’espace
de modélisation MOF-EMF45. Ma et al. (2004) ont développé l’IBM Integrated
Ontology Development Toolkit qui est une application Eclipse basée sur l’EODM qui
permet la construction d’une ontologie OWL à partir d’un modèle UML. Notre
évaluation personnelle de cette application nous a permis de constater qu’il s’agit
d’une approche prometteuse de formalisation de modèles en ontologies.
1.6.6.3 Transformation de modèles UML et de graphes entités-relations
Le Unified Modeling Language (UML46) et les graphes entités-relations sont des
systèmes de représentation couramment utilisés par les informaticiens. Brockmans et
al. (2006) proposent d’utiliser l’UML pour représenter de façon « méta » les
composantes ontologiques et les composantes à base de règles du vocabulaire d’un
domaine. Berardi et al. (2005) utilisent les modèles UML, notamment les propriétés
associées aux diagrammes de classes, pour réaliser des raisonnements par une
traduction des modèles en logique descriptive. Quant à eux, An, Borgida et
Mylopoulos (2005) proposent une méthode pour formaliser les graphes entités-
relations associés à des tables de bases de données en ontologies OWL pour un accès
aux tables à partir de systèmes à base de règles. Finalement, Faucher et al. (2008)
proposent une méthode de conception d’ontologies à partir d’un diagramme de
classes UML qui est annoté. Basé sur l’ODM, chaque composant du modèle est
annoté en utilisant la propriété de stéréotype intrinsèque à UML. Par exemple, une
classe est stéréotypée par rdfs:Class, la généralisation par rdfs:subCLassOf,
43 Yang, EMF Ontology Definition Metamodel:
http://www.eclipse.org/modeling/mdt/eodm/docs/articles/EODM_Documentation/
44 Hussey, MDT EODM Termination Review: http://www.eclipse.org/project-
slides/EODM%20Termination%20Review.pdf
45 Eclipse Graphical Modeling Framework (GMF): http://www.eclipse.org/modeling/gmf
46 OMG UML, UML® Resource Page: http://www.uml.org/
66
l’association par rdf:Property et ainsi de suite. La transformation est assumée par le
MOF QVT.
Fait étonnant, nous n’avons trouvé aucune recherche qui tente de formaliser des
diagrammes d’états, de séquences ou de cas d’utilisation, ce qui le cas échéant
permettrait de représenter des connaissances procédurales et stratégiques dans une
ontologie.
1.7 Ingénierie des connaissances
L’ingénierie des connaissances est la discipline des sciences appliquées qui vise le
développement des techniques, des méthodes et des outils nécessaires à l’élicitation,
la pérennisation et la diffusion de connaissances. Plusieurs éléments de l’ingénierie
des connaissances ont été utilisés pour, d’une part, structurer la démarche de
conception d’OntoCASE et, d’autre part, produire un modèle pour son usage. Nous
abordons dans cette section la notion de conception d’une méthodologie, puis nous
faisons un tour d’horizon des concepts liés à l’élicitation des connaissances et
finalement nous abordons le sujet de l’ingénierie ontologique afin d’identifier les
éléments méthodologiques qui serviront à l’élaboration du volet méthodologique
d’OntoCASE.
1.7.1 Structure de conception d'une méthodologie
Dans le dictionnaire Antidote, le terme méthodologie est défini de la manière
suivante : "l'étude des méthodes scientifiques ou techniques" et de manière plus
spécifique: "l'ensemble des méthodes d'un domaine donné". Une méthodologie est
donc, en quelque sorte, souvent décrite en tant que métaméthode, c'est-à-dire une
méthode qui sert à définir des méthodes ou encore en tant que mégaméthode qui se
compose de plusieurs méthodes. La définition standardisée par le IEEE (1990, 1996)
du terme méthodologie va dans le même sens : « ensemble de méthodes encadré par
des techniques créant une théorie générale systémique concernant la façon dont une
67
certaine catégorie de travail devrait être effectuée 47». Quant au terme méthode, il fait
« référence à un processus ou une procédure ordonné utilisé en ingénierie de produits
ou de services
48», alors qu’une technique est définie « en tant que procédure
technique et de gestion utilisée pour atteindre un objectif donné
49». C'est cette
dernière définition qui a inspiré Gómez-Pérez et al. (2003) pour la conception de la
méthodologie METHONTOLOGY.
Toujours selon le IEEE, un processus est une fonction devant être exécutée dans le
cycle de vie d'un logiciel et un processus est composé d’« activités et de fonctions
devant être exécutées dans le cycle de vie d'un logiciel
50» . Gómez-Pérez et al
(2003), citant le IEEE (1996), définissent une activité en tant que « tâche constitutive
d'un processus 51» et une tâche en tant que « directive de travail bien définie pour un
ou plusieurs membres d’un projet 52». Ces auteurs ajoutent que des tâches connexes
sont généralement regroupées pour former des activités. La figure 1.37 schématise en
langage MOT le concept de méthodologie tel que décrit par Gómez-Pérez et al.
(2003).
Dans notre projet, nous avons utilisé cette structure d’une méthodologie pour, d’une
part, structurer la démarche de recherche de la thèse, et d’autre part, structurer les
composants de l’objet de la thèse, soit la conception d'une méthodologie de
formalisation.
47 [...] a comprehensive, integrated series of techniques or methods creating a general systems theory of how a
class of thought intensive work ought be performed[...]
48 [...] orderly process or procedure used in the engineering of a product or performing a service[...]
49 [...] a technical and managerial procedure used to achieve a given objective[...]
50 […] function that must be performed in the software life cycle. A process is composed of activities
51 […] a constituent task of a process
52 […] a task a well defined work assignment for one or more project members. Related task are usually grouped
to form activities » (
F
M
L
d
q
t
c
q
f
U
l
P
F
igure 1.37:
M
OT de G
ó
1.7.2 Élicit
a
L
e process
u
d
omaine d’
a
q
ui existen
t
t
echniques
c
onnaissanc
q
uelques-u
n
f
ont appel à
U
ltimement
,
l
’élicitation
P
érez et al.,
- un d
i
con
c
- un
a
clas
s
- une
t
Modèle M
O
mez-Pérez
e
a
tion des co
n
u
s
d
’élicitat
i
a
pplication,
t
entre les
permettent
es et un ou
n
es aux secti
la modélisa
t
,
et spécia
l
a pour obj
e
1996):
i
ctionnaire
d
c
epts, instan
c
a
rbre de cla
s
s
ifier les co
n
t
able des m
a
O
T de la dé
f
e
t al., 2003,
p
n
naissances
i
on des co
n
les types de
types de
l’élicitatio
n
plusieurs e
x
ons 1.4 p.3
8
t
ion sous un
l
ement da
n
e
ctif de pr
o
d
e données
(
c
es, attribut
s
s
sification
d
n
cepts;
a
tières (Tabl
e
f
inition d'u
n
p
. 109)
n
naissances
connaissan
c
connaissan
c
n
de ces
c
x
perts du d
o
8
et 1.5 p.4
4
e forme sch
é
s la persp
e
o
duire les a
r
(
Data Dicti
o
s
et leurs val
e
d
es concept
s
e
of Consta
n
n
e méthodol
o
permet de
c
es manipul
c
es (Gerbé
c
onnaissanc
e
o
maine. No
u
4
qui, comm
e
é
matique.
e
ctive de
c
r
téfacts tra
n
o
nary) rasse
m
e
urs corres
p
s
(Concept
C
n
ts) pour la
d
o
gie. (Tirée
défini
r
le
v
l
ées ainsi q
u
et al., 20
0
e
s par un
u
s en avon
s
e
on l’a vu
p
c
onstruire
u
n
sitoires sui
v
m
blant l’id
e
p
ondantes;
C
lassificati
o
d
escription
d
et adaptée
e
v
ocabulaire
u
e les relati
o
0
3). Plusie
u
ingénieur
s
déjà prése
n
p
our certain
u
ne ontolo
g
v
ants (Góm
e
e
ntification
d
o
n Tree), p
o
d
es constant
e
68
e
n
du
o
ns
u
rs
de
n
té
es,
g
ie,
e
z-
d
es
o
ur
e
s;
69
- une table de faits (Table of Instances) et une table d’attributs (Tables of Class
attributes) pour décrire les attributs associés aux classes et à leurs faits;
- une table des formules (Table of Formulas) décrivant les formules utilisées
pour inférer de nouvelles valeurs numériques;
- une taxonomie des attributs (Attribute Classification Tree) détaillant les
attributs impliqués dans des inférences spécifiques;
- une table de faits du domaine (Table of Instances) décrivant des instances du
domaine d’application.
La structure de la représentation des connaissances est souvent influencée par la
manière dont elle est élicitée. Par exemple, la méthode MASK (Ermine et Matta,
2003) est une méthode visant la capitalisation et le partage de connaissances dans les
organisations, dont le cycle « vertueux » est schématisé à la figure 1.38. Le « livre de
connaissances » est l'artéfact concret issu du processus d'explicitation des
connaissances par les experts, qui permet le partage de la connaissance au sein de
l’organisation.
Figure 1.38: Le cycle des connaissances dans MASK. (Tirée d'Ermine et Matta,
2003, p. 8)
Le livre de connaissances est un agglomérat de plusieurs types de modèles, soit le
modèle de patrimoine des connaissances, le modèle des phénomènes, le modèle
d'activités, le modèle de concepts, le modèle de tâches, le modèle historique et le
modèle de lignées. Chacun de ces types de modèles possède une structure graphique
70
exprimée dans un langage semi-formel, qui permet d'exploiter de manière
partiellement automatique la connaissance qu'elle contient.
La modélisation semi-formelle telle qu’utilisée par Basque et al. (2004 ; 2010c,
2010b) est aussi une méthode d’élicitation de la connaissance. La méthode consiste à
faire produire des modèles MOT par des petits groupes de personnes composées
d’experts et de novices de domaine ciblé. Malgré le fait qu'un modèle semi-formel
peut comporter des éléments d'ambigüité, la souplesse et le caractère moins artificiel
d'un langage semi-formel permettent d’accéder plus facilement à l'expression de
connaissances tacites, car la spontanéité n’est pas bloquée par la charge cognitive
associée à une formalisation plus poussée (Basque et al., 2008b). L’usage d’un
système de représentation plus convivial permet aussi d’élargir le bassin des
personnes aptes à représenter leurs connaissances en même temps qu’il évite la
démobilisation des experts de leur tâche principale, laquelle coûte cher à une
organisation. L’élicitation dans un formalisme de degré semi-formel pourrait ainsi
représenter une économie de temps et surtout un gain de qualité dans la représentation
des connaissances. De plus, la convivialité du langage semi-formel fait en sorte que
des modèles de degré semi-formel peuvent être conçus par les experts du domaine
sans l’assistance d’un ingénieur de la connaissance, lequel peut ensuite les formaliser
avec la participation minimale des experts les ayant conçus ou encore d’autres
experts. Les opérations d’élicitation peuvent ainsi être intégrées de manière plus
souple dans les activités des experts du domaine.
Ainsi, tel que mentionné précédemment, nous pensons qu’une phase d’élicitation de
la connaissance dans un formalisme de degré semi-formel relativement évolué devrait
précéder celle de la formalisation des connaissances, où le modèle semi-formel est
transformé dans un formalisme ontologique.
71
1.7.3 Méthodologies d'ingénierie ontologique
L’ingénierie ontologique est la discipline des sciences appliquées responsable du
développement de méthodes et des outils nécessaires à la conception, la réalisation, la
mise en œuvre et la maintenance de systèmes informatiques à base d’ontologies
(Gómez-Pérez et al., 2003). Tel qu'illustré à la figure 1.39, le processus de
développement d'ontologies englobe des activités de gestion, de développement ainsi
que de support.
Figure 1.39: Processus de développement d'une ontologie. (Tirée de Gómez-Pérez et
al.2003, p. 110).
Pour Kendal et Creen (2007) et Uschold et Gruninger (1996), le développement d’une
ontologie est un processus linéaire divisé en six stades, soit les suivants: (1) l’étude
de faisabilité, (2) l’acquisition de connaissances, (3) la conception, (4)
l’implantation, (5) la validation et (6) l'élaboration de la documentation. Inspirés par
l'approche itérative couramment utilisée en développement de logiciels, Staab,
S
d
e
F
d
Q
(
p
d
c
i
d
L
d
d
r
S
tuder, Sc
h
d
’ontologie
s
e
t de maint
e
F
igure 1.40:
d
e Staab et
a
Q
uant à la
m
(
2003), elle
p
ar des a
c
d
éveloppe
m
c
oncept de
i
térations s
o
d
e qualité.
L
e projet
K
d
'ontologies
d
éveloppe
m
r
affinée. L
'
h
nurr et
S
s
qui inclut
d
e
nance (voi
r
Processus
d
a
l. 2001)
m
éthodolog
i
est basée s
u
c
tivités de
m
ent d'ontol
o
constructi
o
o
nt régulées
K
ACTUS (1
axée sur
l
m
ent de l'ap
p
'
ontologie,
S
ure (2001
)
d
es rétroact
i
r
la figure 1.
4
d
e développ
e
i
e METHO
N
u
r un cycle
d
gestion (
v
o
gies de g
r
o
n d'une o
n
par une pla
n
996) utilise
l
a réutilisati
p
lication, l'
o
produit d
e
présenten
t
i
ons entre l
e
4
0).
e
ment d’un
e
N
TOLOGY
,
d
e vie de d
é
v
oir la fig
u
r
ande enve
r
n
tologie pa
r
n
ification e
t
, pour sa p
on des co
n
o
ntologie s
e
e
l'itération
t
un proc
e
e
s phases d
e
e
ontologie
O
,
développé
e
é
veloppeme
n
u
re 1.41).
S
r
gure, cette
r
évolution
t
pilotées p
a
art, une ap
p
n
naissances.
e
rvant de b
courante,
e
ssus de
d
e
raffineme
n
O
n-To-Kno
w
e
par Góm
e
n
t d'ontolog
i
S
pécialeme
n
méthodolo
g
de protot
y
a
r des activi
t
p
roche de
d
À chacun
ase de con
n
est const
r
d
éveloppem
e
n
t, d'évaluat
i
w
ledge. (Tir
e
z-Pérez et
a
i
es qui est r
é
n
t adaptée
g
ie intègre
y
pes, dont
l
t
és de contr
ô
d
éveloppem
e
des cycles
n
aissances
e
r
uite à pa
r
72
e
nt
i
on
ée
a
l.,
é
gi
au
le
l
es
ô
le
e
nt
de
e
st
r
tir
73
d'ontologies construites lors des itérations précédentes et par l'intégration d'ontologies
déjà existantes.
Enfin, Grüninger et Fox (1995) proposent une méthodologie inspirée du
développement de systèmes à base de connaissances utilisant la logique du premier
ordre. La conception démarre par l'élaboration d'un scénario interrogatif entre un
expert et le futur système. Les concepts, les propriétés et les axiomes de l'ontologie
sont construits à partir des connaissances extraites pendant le déroulement du
scénario.
Figure 1.41: Cycle de vie du processus de développement d'ontologie de
METHONTOLOGY. (Tirée de Gómez-Pérez et al., 2003, p.127)
Le tableau 1.7 présente un sommaire comparatif des principales méthodologies que
nous venons de présenter. Le choix de l'une ou l'autre de ces méthodologies doit être
guidé par un questionnement concernant la disponibilité des experts, l'ampleur de
l'ontologie à développer, les processus déjà existants de développement de logiciels
déjà existants dans l’organisation ou encore les énergies à déployer pour la gestion du
74
risque lié à tout processus de développement. La valeur ‘NP’ signifie qu’en vertu de
la documentation disponible, cette activité n’est pas considérée.
75
Tableau 1.7
Sommaire comparatif du processus de développement d'ontologies (extrait de Gómez-Pérez et al., 2003, p.151)
76
Il existe d'autres méthodologies non répertoriées par Gómez-Pérez et al. (2003). Par
exemple, utilisant les langages OWL et F-Logic (Meštrović et Čubrilo, 2009), le
projet NeOn (2006) préconise l'utilisation d'une bibliothèque de patrons de
conception d'ontologies (Gangemi et al., 2008). Orienté sur la réutilisation, le
principe sous-jacent de la méthodologie NeOn est inspiré de la conception de
logiciels par les patrons de conception de Gamma et al. (1999). Le patron de
conception d'ontologies "Ontology Design Pattern (OP)" est une solution de
modélisation permettant de résoudre un problème de conception récurrent.
1.8 Environnements informatiques d'assistance à l’usager
Dans cette section, nous présentons les niveaux de caractérisation de la fonction
d'assistance d'un environnement informatisé.
Plusieurs formes d’assistance peuvent être fournies à l’usager dans un environnement
informatique. Paquette et al.(1994), citant Wenger (1987) et Jonassen (1991), divise
en quatre niveaux le degré d'aide qu'un système intelligent peut apporter à un
utilisateur. C’est ce qui va nous servir de guide pour classifier le niveau d'assistance
que l'application OntoCASE veut offrir.
Au premier niveau, on retrouve la rétroaction simple. Il s’agit d’un mécanisme d'aide
qui concentre son action dans la production de messages fondées sur les informations
fournies au système par les actions de l’usager. Celui-ci applique une action et le
système produit une réponse.
Le deuxième niveau, l'interventionnisme moyen, offre à l'utilisateur une aide
contextualisée et à la demande. L'aide fournie est toujours en lien avec le contexte
d'usage de la fonctionnalité sollicitée. Le contexte d'aide peut être interactif et cette
interaction avec le système est une séquence d'événements qui alterne entre actions
d'aide fournies par le système et actions posées par l'utilisateur.
77
Le troisième niveau, l'interventionnisme élevé, est un niveau d'assistance plus
intelligent que les précédents puisqu'en plus d'offrir une aide contextualisée, le
système peut appliquer des déductions à partir d’un modèle de l’usager dans le but
d’offrir des conseils sur l’utilisation du système.
Le quatrième niveau, le tutorat, est le plus intelligent des systèmes d'aide. À ce
niveau, le système est surtout dédié à l'apprentissage et l'utilisateur est principalement
un apprenant. C'est le système qui a l'initiative d'exercer un guidage de l'apprenant.
Les interventions du système sont impératives, les erreurs sont soulignées et
l'apprenant doit apporter les corrections nécessaires.
À titre d’exemple de système d’assistance de niveau moyen et que nous préconisons
pour OntoCASE, citons l'Atelier de Génie Logiciel (AGL), aussi appelé Computer
Aided Software Engineering (CASE), qui est un outil informatique qui assiste
l'ingénieur logiciel dans le développement de programmes informatiques en tenant
compte des paradigmes d'une méthodologie de développement de logiciels (les
phases génériques de planification, d'analyse, de conception, d'essais et de
maintenance). En plus d'assister l'ingénieur dans le développement de l'application
informatique proprement dite, l'AGL intègre des outils de gestion de projets,
d'assurance qualité et de documentation (Fuggetta, 1993). Les applications telles
qu'Eclipse53 et NetBeans54 sont considérées comme des outils AGL. À ce sujet,
notons que plusieurs applications concernant le Web sémantique sont développées
53 The Eclipse Foundation, The Eclipse home page: http://www.eclipse.org/
54 NetBeans home page: http://netbeans.org/
78
avec la plateforme Eclipse, notamment Protégé 4.055, TopBrain Composer56, NeOn
Toolkit57 et Eclipse Ontology Definition Metamodel (EODM) Workbench58.
1.9 En résumé
Ce chapitre nous a permis d’aborder les concepts liés à la sémiotique, le concept de
niveau d'abstraction ainsi que les concepts de synonymie et de polysémie qui ont
permis de définir un vocabulaire pour l'élaboration du cadre théorique d'OntoCASE.
De plus, cette recension des écrits a permis de cadrer le concept actuel de
modélisation des connaissances, notamment par la classification des langages de
représentation des connaissances et la classification des ontologies. Nous avons
également présenté un inventaire de quelques langages de représentation des
connaissances de degré semi-formel et formel qu’il nous apparaissait important
d’étudier en vue de produire une méthodologie générique. Nous avons également
exploré des techniques normalisées et dédiées à la transformation de modèles, que
nous comptons adapter pour le processus de transformation de modèles semi-formels
en ontologies à implanter dans OntoCASE. En ingénierie des connaissances, nous
avons identifié une structure métaméthodologique pour concevoir une méthodologie,
éliciter des connaissances et répertorier quelques méthodes d'ingénierie ontologique
existantes. Finalement, nous avons traité des environnements informatiques pour
l'assistance selon une classification des fonctions d'assistance. Dans cette thèse, nous
visons pour OntoCASE un niveau moyen d’assistance moyen à l’usager tel que défini
par Paquette et al. (1994).
55 Protégé Home Site, Welcome to protégé: http://protege.stanford.edu/
56 TopQuadrant, TopBraid Composer (TM): http://www.topquadrant.com/products/TB_Composer.html
57 NeOn project, Neon toolkit: http://neon-toolkit.org/wiki/Main_Page
58 IBM, IBM Integrated Ontology Development Toolkit: An ontology toolkit for storage, manipulation, query, and
inference of ontologies and corresponding instances.: http://www.alphaworks.ibm.com/tech/semanticstk
CHAPITRE 2
MÉTHODOLOGIE D’ONTOCASE
Ce chapitre décrit la méthodologie d’OntoCASE. La première section est consacrée à
la formulation de l'hypothèse de la recherche, alors que la deuxième section nous
permet d’en spécifier les objectifs. La troisième section présente les principales
contributions visées de la recherche. Les différents volets d'OntoCASE
(méthodologique, informatique, représentationnel), les fonctions et les structures de
l'ontologie de transformation ainsi que la structure de la méthodologie d'OntoCASE
sont autant de thèmes qui seront abordés dans cette section. La section quatre a pour
propos l'ontologie de référence. Sa structure interne, les entités et relations qui la
composent sont autant de sujets qui seront abordés. La section cinq, l'ontologie-
cadre, présente la définition et l'utilité de cette ontologie et elle en décrit les
ressources et propriétés. La section six, dont le sujet est la méthodologie OntoCASE
conçue dans le cadre de cette thèse, présente les composants de la méthodologie soit:
la méthode de conception d'un modèle semi-formel, la méthode de formalisation en
ontologie et la méthode de validation syntaxique et sémantique.
2.1 Hypothèse
L’hypothèse de cette recherche est la suivante : à partir d’un modèle de
connaissances exprimé dans un langage semi-formel qui représente des
connaissances de différents types, il est possible de procéder de manière automatique
ou semi-automatique, à sa formalisation en ontologie syntaxiquement et
sémantiquement valide.
80
Cette méthodologie de transformation assistée, appelée OntoCASE (voir la forme
ovoïde à la figure 2.1), dont l’intrant est un modèle de degré semi-formel et l’extrant
un modèle de degré formel, regroupe un ensemble de méthodes et de techniques qui
sont instrumentées par un assistant informatique intelligent. La figure 2.1 présente
aussi des exemples de systèmes de représentation classifiés selon le quantum des
degrés de formalisation. Ceux utilisés dans la présente recherche apparaissent en vert,
à savoir : le modèle de connaissances MOT (en tant que prototype de systèmes de
représentation de degré semi-formel) et l'ontologie OWL (en tant que prototype de
systèmes de représentation de degré formel).
Figure 2.1: Positionnement d'OntoCASE en fonction des degrés de formalisation et
classification d’exemples de formalisme.
2.2 Objectifs
De l'hypothèse, découlent ces trois objectifs:
- concevoir une méthodologie d'ingénierie ontologique intégrant une méthode
de modélisation semi-formelle, une méthode de formalisation en ontologie et
une méthode de validation syntaxique et sémantique de l’ontologie produite;
81
- développer un outil informatique intelligent et intégré, qui instrumente de
manière efficace, efficiente et satisfaisante les différentes méthodes et la
méthodologie;
- créer une ontologie offrant une représentation méta du domaine de la
représentation des connaissances qui opérationnalise les assistants
informatiques de la méthodologie et qui sert de représentation pour la
méthodologie.
2.3 Produits de la recherche
Dans le chapitre précédent, nous avons présenté plusieurs concepts théoriques à la
base d'OntoCASE. Cette section nous permettra de donner forme à ces concepts,
d'abord sur un plan descriptif par la présentation de l'architecture de haut niveau, puis
sur le plan procédural, par la présentation des éléments méthodologiques
d'OntoCASE.
2.3.1 Volets d'OntoCASE
OntoCASE, acronyme composé des mots "Ontologie" et « CASE » (Computer Aided
Software Engineering), se compose d'un volet méthodologique, d'un volet
informatique, aussi appelé volet computationnel, ainsi que d'un volet
représentationnel (voir la figure 2.2). Le volet méthodologique décrit l'ensemble des
éléments procéduraux, des acteurs et des ressources contribuant à la formalisation
d'un modèle semi-formel en ontologie. Le volet computationnel décrit, quant à lui, les
composants informatiques, ainsi que leurs utilisations, afin d'assister les acteurs dans
l'application de la méthode. À chacune des méthodes est associé un module
d'assistance informatique qui peut être utilisé par les acteurs humains de la méthode.
Finalement, le volet représentationnel comporte un ensemble de guides qui
permettent d'orienter le déroulement de chacune des méthodes ainsi qu'une ontologie
de transformation qui régit l'opérationnalité des composants du volet computationnel.
82
Trois composants de haut niveau forment le volet computationnel d'OntoCASE.
L'éditeur de modèle semi-formel (appelé eLi) est un éditeur de diagrammes offrant
les fonctionnalités nécessaires à la construction d'un modèle semi-formel, inspiré de
l’éditeur MOT (Paquette, 2002b, 2010) et de son langage MOT (voir l'appendice A).
Le système expert à la formalisation basé sur un catalogue de la sémantique formelle
de MOT (voir l'appendice B) offre les ressources permettant d'assister les acteurs de
la méthodologie dans le processus de désambiguïsation et de transformation d’un
modèle semi-formel en ontologie. Finalement, l'assistant à la validation, qui implante
le catalogue des cohérences de l’ontologie cadre et les bonnes pratiques de
modélisation semi-formelle en vue d’en faire une Ontologie (voir l'appendice C et E),
est une application informatique qui offre des fonctionnalités permettant à l'ingénieur
et à l'expert de valider syntaxiquement et sémantiquement l'ontologie produite au
cours de l’étape de formalisation.
La méthode intégrer un nouveau formalisme semi-formel à la méthodologie n'est pas
à proprement parler une méthode qui participe à la conception d'une ontologie du
domaine; elle a plutôt un rôle métaméthodologique qui assure l'intégration de
nouveaux formalismes à la méthodologie par le développement des entités
d'OntoCASE (les méthodes, les modules informatiques et les ontologies) permettant
de les traiter.
Figure 2.2: Volets mét
h
h
odologique, c
o
o
mputationnel
e
t représentatio
n
n
nel d'OntoCASE.
83
83
2
A
D
d
t
o
f
F
Q
s
s
d
l
l
d
5
2
.3.2 Ontol
o
A
u cœur d'
O
D
ans le vo
l
d
écrit aux
t
ransformat
i
o
pératoire p
f
ormalisatio
n
F
igure 2.3:
A
Q
uatre com
p
s
emi-formel
s
emi-forme
l
d
es ambigu
ï
l
'identificati
o
l
es diverse
s
d
ésambiguï
s
5
9
Les catégorie
s
o
gie de tran
s
O
ntoCASE,
l
et méthodo
sections 2
.
i
on (voir l
a
uisqu'elle c
o
n
.
A
rchitecture
p
osants for
m
représente
l
utilisé pou
r
ï
tés et des e
o
n des erre
u
s
catégorie
s
ation et de
t
s
mise en stéréo
t
s
formation d
l'ontologie
logique, ce
t
.
4 et 2.6.
a
figure 2.3
)
o
nstitue la b
de l'ontolo
g
m
ent l'ontol
o
les élément
r
construire
rreurs cont
i
u
rs de caté
g
s de con
n
t
ransformati
t
ype à chacune
d
'OntoCASE
de transfor
m
t
te ontologi
e
Dans le
v
)
, qui en e
ase de con
n
g
ie de transf
o
o
gie de tran
s
s
d
u vocab
u
les modèles
i
ent des règ
l
g
orisation; (
3
n
aissances
e
on; et final
e
d
es ontologies s
o
m
ation pos
s
e
a un rôle
v
olet comp
u
e
st une de
n
aissances d
e
fo
rmation.
s
formation:
u
laire et de
sources; (2
l
es servant
à
3
) l'ontolog
i
e
t opératio
n
e
ment (4) l'o
n
o
nt décrites en d
é
s
ède une d
o
représenta
t
u
tationnel,
l
haut nivea
u
e
l'assistant
(1) l'ontolo
g
la gramma
i
) l'ontologi
e
à
la désamb
i
e de référe
n
n
nalise le
ntologie ca
d
étail à la sectio
n
o
uble foncti
o
t
ionnel qui
e
l
'ontologie
u
59
, a un r
ô
intelligent
à
g
ie du lang
a
i
re du lang
a
e
de traitem
e
iguïsation e
t
n
ce représe
n
processus
d
re encadre
l
n
1.3.3, p. 32
84
o
n.
e
st
de
ô
le
à
la
a
ge
a
ge
e
nt
t à
n
te
de
l
es
85
éléments du modèle cible dans une structure qui supporte la représentation de
connaissances déclaratives, procédurales et stratégiques qu’elles soient concrètes ou
abstraites.
2.3.3 Portrait synthèse de la méthodologie d'OntoCASE
Le tableau 2.1 présente un portrait synthèse de la méthodologie en mettant en relation
les méthodes, techniques et outils qui la composent. La référence aux sections
concernées est indiquée entre parenthèse.
Tableau 2.1
Méthodes, techniques et outils de la méthodologie OntoCASE
OntoCASE
Méthodes Techniques Outils
Concevoir un
modèle semi-
formel
(2.7.1)
Modélisation
(2.7.1)
- eLi/Mot-plus/GMF-MindMap (3.2.1)
- Guide des bonnes pratiques à la
modélisation
- Guide du langage MOT
- Ontologie de MOT (2.4, 3.2.2, E.1 )
Modélisation assistée
(2.7.1)
- eLi
- Guide des bonnes pratiques à la
modélisation
- Guide du langage MOT
Co-modélisation
(2.7.1)
- eLi/Mot-plus/GMF-MindMap
- Guide des bonnes pratiques à la
modélisation
- Guide du langage MOT
Formaliser en
ontologie
(2.7.2)
MDA (Model Driven
Architecture) (1.6)
- Assistant à la formalisation
- Catalogue à la désambiguïsation
- Ontologie de référence (3.1.4)
ODM (Ontology Data Model)
(1.6.6.2, E.1 )
Valider
(2.7.3)
Rétroactions inférentielles
(3.2.7)
- Assistant à la validation
- Ontologie cadre (3.1.5)
Intégrer un
nouveau
formalisme semi-
formel à la
méthodologie
(4.4 )
Méthodologie Objets - Java
MDA/MDD-MOF - Eclipse PDE/EMF/GMF (3.1.7)
Ingénierie ontologique:
- Onto Dev Metamodel
(ODM)
- Ontology Dev
- Rules Dev (3.1.8.2)
- TopBraid (3.1.7)
- Protégé (3.1.7)
o Java code generation
o SWRLTab
86
2.4 Ontologie du langage semi-formel
L’ontologie du langage semi-formel (voir le tableau 2.2) contient la structure du
langage semi-formel et permet de classifier chacun des éléments du modèle. Pour le
langage MOT, les éléments du modèle sont répartis entre connaissance et relation
avant d’être sous-classifiés dans leur classe respective (par exemple, en concept).
Chaque langage semi-formel intégré à la méthodologie comporte sa propre ontologie
du langage semi-formel qui le caractérise.
Tableau 2.2
Structure de classes de l’ontologie du langage semi-formel
2.5 Ontologie de référence
Représentée à la figure 2.4, l'ontologie de référence, de type générique, est au cœur
du processus de transformation de la représentation semi-formelle à la représentation
formelle. Pour le système de transformation, l'ontologie de référence est un modèle de
travail; elle assure un entreposage temporaire des informations avant qu'elles ne
soient utilisées par le sous-processus de conversion en langage formel. L'étape de
désambiguïsation, spécifique à chaque langage de modélisation semi-formel,
catégorise chacun des éléments du modèle source dans l'ontologie de référence.
Chacun des formalismes possède son propre vocabulaire. Par exemple, en UML, un
holonyme est représenté par une relation d'agrégation, alors qu'en langage MOT, il est
représenté par un lien de composition. La désambiguïsation respective à chacun de
87
ces formalismes classera ces relations dans la classe « Holonyme » de l'ontologie de
référence.
Figure 2.4: Principe de transformation guidée par l'ontologie de référence.
Après la désambiguïsation, est exécutée la conversion. Cette étape sert à créer une
nouvelle ontologie dont la sémantique respecte celle du modèle semi-formel source.
Deux mécanismes d’inférence sont utilisés par le processus de conversion. À partir
des éléments du modèle source qui constituent la base de faits de l’ontologie de
référence, le premier mécanisme d’inférence classifie les éléments du modèle. À
partir de la classification, une inférence à base de règles est déclenchée créant ainsi,
pour chacun des faits de l’ontologie de référence, une entité ontologique
correspondante dans l’ontologie cible.
2.5.1 Structure interne de l'ontologie de référence
À sa base, la structure interne de l’ontologie de référence (voir le tableau 2.3 et le
tableau 2.6) se divise en entités et relations. Ce modèle de structure proposé par Chen
(1976, 2002) est utilisé par de nombreux systèmes de représentation. C’est le cas
Ontologie de référence
Modèle source
Ex: Modèle de
connaissances MOT Désambiguïsation
Modèle source
ex: UML diagramme de classes
Ontologie cible
Transformation
Désambiguïsation
Conversion
88
notamment des représentations de type TopicMap60, du Concept Mapping61 ou encore
de l'UML62.
2.5.2 Entités de l'ontologie de référence
Nous proposons six types d’entités de base pour l’ontologie de référence, qui se
distinguent selon le niveau de réalité (subjectif ou objectif) et le type de connaissances
(déclaratif, procédural ou stratégique) qu'elles représentent (voir le tableau 2.3 et le
tableau 2.4): le concept, la manifestation, l'action, l'acte, le principe et le facteur
d'influence. La manifestation et le concept sont des entités déclaratives qui
représentent respectivement les objets concrets et abstraits d'un domaine et font ainsi
référence aux deux niveaux de réalité du domaine de connaissances (objectif et
subjectif). Par exemple, « la 'chaise' de Paul » (une manifestation) ou « une 'chaise'
(un concept) est composée de quatre pattes ». L'action et l'acte sont des entités qui
représentent des connaissances procédurales de la réalité subjective et objective. À
titre d’exemples de ces deux types de connaissances, citons « exécuter la 'procédure
d'évacuation' » (action) et « Pierre 'utilise l'extincteur' pour maîtriser l'incendie »
(acte). Finalement, le principe et le facteur d'influence sont des entités utilisées pour
représenter des connaissances stratégiques abstraites et concrètes. Par exemple, « le
rôle d'un 'politicien', c'est de gouverner » constitue un principe alors que « 'si l'eau est
à 100 °C alors, elle bout' » constitue un facteur d'influence.
Chacune des entités est divisée en catégories selon le schème de couleur du
tableau 2.4. Les dénominations de primaire (vert), secondaire (beige) et tertiaire
(orange) ont été choisies de manière arbitraire. Elles permentent cependant d'établir
une catégorisation hiérarchique des niveaux des sous-entités. L'entité concept est
60 SC34/WG3 Home page of the Topic Maps ISO standards: http://www.isotopicmaps.org/
61 IHMC, IHMC CmapTools: Concept Mapping Home Site: http://cmap.ihmc.us/
62 OMG UML, UML® Resource Page: http://www.uml.org/
89
divisée en deux sous-entités: la classe représente des connaissances déclaratives
abstraites quelconques, alors que le schéma est utilisé pour représenter des
connaissances schématisées telles que les entiers (int), les chaînes de caractères
(string) ou les nombres réels (float). L'entité manifestation est aussi divisée en deux
sous-entités. D'une part, l'objet représente l'instance d'une classe, c'est-à-dire la
représentation de la manifestation d'une connaissance quelconque, alors que la
catégorie attribut est utilisée pour emmagasiner une valeur associée à un attribut. En
revanche, la classe et l'objet font partie de la même catégorisation primaire. De
même, le schéma et l'attribut font partie de la catégorie secondaire.
Tableau 2.3
Catégorie des entités du modèle de référence
ENTITÉ
Type de connaissance
Déclaratif
(quoi)
Procédural
(comment)
Stratégique
(pourquoi, qui, quand)
Niveau
de
réalité
Subjectif
(Abstrait)
Concept
Classe
Action
Opération
Principe
Agent
Schéma
String
Procédure
Condition
Int
Règle
Nom
Float
Antécédent
Non décomposée
Conclusion
Propriété
Objectif
(Concret)
Manifestation
Objet
Acte
Opération
Facteur d'influence
Agent
Attribut Procédure
Condition
Règle
Nom
Antécédent
Non décomposée
Conséquent
Assertion
Tableau 2.4
Catégorie des entités et leur couleur correspondante
Catégorie Correspondance des couleurs
Primaire
Secondaire
Règle nom
Règle antécédent
Non décomposée
Règle conséquent
Tertiaire
90
D'un point de vue procédural, chacune des entités action et acte est aussi
respectivement divisée en deux sous-entités, soit la procédure et l'opération. La
procédure est la connaissance procédurale qui fait référence à l'idée de mouvement.
Elle explique le comment de la réalisation d'une chose. L'opération est aussi associée
à l'idée de mouvement; cependant elle est spécialisée dans l'expression d'un comment
qui se réalise à la suite de la détermination d'une condition. Par exemple, l'opération
s'utilise dans une expression de la forme: « si 'une condition' alors 'une opération' ».
L'entité principe et son homologue concret, le facteur d'influence, sont divisés chacun
en sept sous-entités similaires. La première d'entre elle sert à représenter des
connaissances associées à des agents, des normes ou des contraintes. La deuxième
sous-entité assure la représentation de conditions telles que celles utilisées dans les
ordinogrammes. Les sous-entités nom, antécédent, non-décomposée63 et conséquent¸
sont des sous-entités associées à la représentation d'une règle. Ces sous-entités sont
utilisées pour la représentation d'énoncés de la forme :
« La règle de 'Nom' = Si 'antécédent' alors 'conséquent' »
ou encore:
« 'non-décomposée' = l'énoncé complet d'une règle ».
Le tableau 2.5 présente un exemple de la représentation d’une règle dans le langage
MOT. En a est représenté l’exemple d’une règle fragmentée en nom de la règle,
antécédent et conséquent. En b est représenté l’exemple d’une règle dont la
conclusion aboutie par l’exécution d’une opération, et en c, il est représenté
l’exemple d’une règle non-décomposée.
Finalement, quant aux sous-entités propriété et assertion, elles permettent de
représenter le prédicat dans les énoncés de type « sujet/prédicat/objet ».
63 Parfois, à certains endroits de la thèse, on utilise le terme « règle complète ».
2
L
s
d
p
L
s
c
c
r
a) « La
r
beau
»
b) « La
p
opu
l
c)
2
.5.3 Relati
o
L
e tableau
2
s
'utilise po
u
d
éclaratives
)
p
our représ
e
L
a relation
s
’agit d’une
c
ontraignan
t
c
onnaissanc
r
estriction s
u
Exe
m
r
ègle du beau
»
règle d'inocul
a
l
ation »
o
ns du mod
è
2
.6 présente
u
r représent
e
)
d'une con
n
e
nter une sé
q
d
'holonymi
e
relation tra
n
t
e des rela
t
es qui font
p
u
r les types
m
ple de repr
temps »: « S'i
l
a
tion générali
s
è
le de référe
n
les catégori
e
e
r les intra
n
n
aissance p
q
uence entre
e
représente
n
sitive (Lac
y
t
ions d'hol
o
p
artie d'un s
o
de connais
s
Tableau 2.
5
ésentation
d
l
fait entre 20°
s
ée »: « S'il y
n
ce
e
s associées
n
ts ou les
e
rocédurale.
deux conn
a
l'idée d'élé
m
y
, 2005 p.
3
o
nymie. Ell
o
us-modèle
d
s
ances qui
s
5
d
'une règle e
n
°
et 30° » et «
a pandémie
d
aux relatio
n
e
xtrants (q
u
La catégor
i
a
issances pr
o
m
ents faisa
n
3
9). La caté
g
l
e est utili
s
d
e connaiss
a
s
ont reliées
p
n
MOT
s'il ne pleut p
a
d
e grippe » a
l
n
s. La relati
o
u
i sont des
i
e
p
récéden
o
cédurales.
n
t partie d'u
n
g
orie englo
b
s
ée pour r
e
a
nces. Il n'y
p
ar une rel
a
a
s » alors « il
f
l
ors « inocule
r
o
n de type
fl
connaissan
c
ce est utili
s
n
ensemble
:
b
e est la mo
i
e
présenter
d
a donc auc
u
a
tion 'englo
b
91
f
ait
r
la
fl
ux
c
es
s
ée
:
il
i
ns
d
es
u
ne
b
e'.
92
Par exemple, une connaissance procédurale peut englober une ou plusieurs
connaissances déclaratives, procédurales ou stratégiques. Par contre, les relations
d'holonymie de catégories agrégation et composition ont une restriction sur le type
des connaissances qu'elles relient puisqu'elles doivent relier des connaissances de
même type. L’agrégation n'a aucun présumé concernant l'existence des objets qui
sont unis. Dans l'énoncé « l'automobile se compose de quatre roues », l'existence des
roues n'est pas liée à l'existence de l'automobile. En revanche, dans l'énoncé « un
corps humain se compose de 2 bras », l'existence des bras est conditionnée par
l'existence du corps humain. Nous parlerons alors d'une relation d'holonymie de type
composition.
Tableau 2.6
Catégorie des relations du modèle de référence
RELATION Catégorie
Flux Intrant
Produit
Précédence
Holonymie Agrégation
Composition
Englobe
Hyponymie Généralisation
Spécialisation
Méta Définition
Instanciation
Régulation
La relation d'hyponymie est une relation de classification des entités qu'elle relie.
L'hyponymie est transitive et elle est utilisée pour relier des connaissances de même
type. Dans notre catégorisation, hyponymie et spécialisation sont synonymes alors
que nous devrions utiliser le terme hyperonyme pour désigner la relation de
généralisation. Ainsi, généralisation et spécialisation sont tous les deux des
antonymes (de sens contraire). Nous avons tout de même pris la liberté de classer les
catégories généralisation et spécialisation sous la relation hyponymie en prenant bien
93
note qu'un traitement particulier devra être réalisé afin de tenir compte de leurs sens
contraire, tout comme c’est le cas pour intrant et produit dans les relations de flux.
Enfin, la relation Méta, qui est non transitive, est utilisée pour représenter le lien qui
existe entre la représentation de deux entités de même type (déclaratif, procédual ou
stratégique), mais de niveaux d’abstraction différents. Ainsi, l'instanciation
représente la relation entre une entité abstraite et une entité concrète. Quant à la
relation définit, surtout utilisée en métamodélisation, elle représente la relation entre
deux entités abstraites qui sont de niveaux d'abstraction différents. Finalement, la
relation de régulation, qui est une relation non-transitive, représente l'influence que
porte une connaissance stratégique sur une autre connaissance.
2.6 Ontologie cadre en représentation des connaissances d’OntoCASE
L'ontologie cadre est une ontologie dont la définition des concepts concerne plusieurs
disciplines. Les termes upper ontology, generic ontology, top-level ontology sont des
synonymes anglais du vocable « ontologie cadre » (Oberle, 2006 p. 46). De plus,
selon la catégorisation de Gómez-Pérez et al. (2003), l'ontologie cadre en est une de
type "Knowledge Representation" puisqu'elle permet de décrire un domaine selon une
typologie faisant référence à un système de représentation de connaissances. Cette
ontologie permet de définir les éléments de l'ontologie du domaine afin d’en élargir
l’expressivité. Outre l'expression de connaissances déclaratives, propre aux
ontologies, l’ontologie cadre permet l'expression de connaissances procédurales et
stratégiques dans l’ontologie du domaine.
L'exemple de la figure 2.5 illustre les niveaux des modèles de l'ontologie cadre dans
le domaine de la biologie. La métamodélisation divise le domaine en plusieurs
couches d'abstraction. Tel que déjà mentionné, les couches M0 et M1 représentent
respectivement le domaine du discours et la sémantique du domaine du discours.
Dans cet exemple, il est possible de conclure que <bahia> est un 'animal' puisque la
transitivité de la relation de généralisation permet de relier 'Berger Allemand' à
94
'Chien', puis à 'Canin' … jusqu'à 'Animal'. Les éléments des couches M2 et M3
permettent la définition des éléments de la couche M1. Ainsi, le métamodèle définit
'Berger Allemand'' comme étant une 'Race', puis 'Chien' en tant que 'Espèce', etc. La
relation non transitive qui relie les éléments de couches d'abstraction différentes est
appelée instance ontologique. En effet, cette relation est non transitive puisque, bien
que <bahia> soit un 'Berger Allemand', on ne peut pas conclure que <bahia> soit une
'Race'. Par contre, on peut affirmer que: 'bahia’ est un chien de race ‘Berger
Allemand'.
Figure 2.5: Ontologie cadre de la biologie.
Dans cette recherche, l'ontologie cadre d'OntoCASE encadre le modèle cible afin de
compenser les éléments de syntaxe et de grammaire qui sont manquants dans le
langage de modélisation cible. À titre d'exemple, supposons un modèle source conçu
en langage MOT et sa conversion (le modèle cible) en langage OWL : le vocabulaire
Ontologie cadre
M2
M1
Définit
M3
Définit
M0
Représente
Canin
Carnivore
Mammifère
Vertébré
Animal
Chien
Berger Allemand
Genre
Ordre
Classe RègneRace
Rang
Biologique
instance
Généralisation
EmbranchementEspèce
<bahia> représente
95
de MOT permet l'expression de relations de composition ou encore l'expression de
connaissances procédurales qui ne font pas partie d'OWL. Dans ce cas, le rôle de
l'ontologie cadre est de contenir une définition des éléments d'agrégation et de
connaissances procédurales et de préserver les propriétés sémantiques de ces
éléments par une représentation adéquate de celles-ci dans le langage de modélisation
cible.
La figure 2.6 présente un exemple de l’utilisation partielle de l’ontologie cadre
d’OntoCASE pour le modèle un berger allemand se compose de pattes. L’ontologie
cadre d’OntoCASE, au niveau M2, encapsule les éléments du modèle du niveau M1.
Figure 2.6: Exemple de classification avec L’ontologie cadre d’OntoCASE.
2.6.1 Ressources de l'ontologie cadre d’OntoCASE
Au tableau 2.7 sont présentées les ressources de l'ontologie cadre. On désigne par
ressources, les classes d'une ontologie exprimées dans un formalisme spécifique au
Web, par exemple l'Ontology Web Language (OWL). On y retrouve les types de
DéfinitDéfinit Représente
96
connaissances présentés dans l'ontologie de référence. En revanche, les niveaux de
réalités n'y figurent pas puisque cette particularité de représentation fait partie de
l'expressivité du formalisme ontologique. Les ressources de l'ontologie cadre sont en
fait des méta-classes qui définissent les classes associées au domaine de
connaissances à représenter.
Tableau 2.7
Ressources de l'ontologie cadre d’OntoCASE
Types de
connaissances
Catégorie
Déclarative Concept
Schéma Float
Int
String
Procédurale Procédure
Opération
Stratégique Agent_Contrainte_Norme
Condition
Entite_Regle Antécédent
Non
décomposée
Conclusion
Nom
2.6.2 Propriétés de l'ontologie cadre d’OntoCASE
De la même manière que pour les ressources, les propriétés de l'ontologie cadre sont
en fait des méta-propriétés qui permettent de catégoriser les propriétés associées à un
domaine de connaissances. Présentées au tableau 2.8, les propriétés de l'ontologie
cadre couvrent une partie importante des types de relations pouvant relier deux
connaissances entre elles. Les propriétés restantes étant fournies à même le langage
OWL.
97
Tableau 2.8
Propriétés de l'ontologie cadre d’OntoCASE
Nom de la propriété Nom de la propriété inverse
A-POUR-ATTRIBUT
A-POUR-COMPOSANT EST-LA-PARTIE-DE
PERMET-DE
ALORS
A-POUR-
DEPENDANCE
A-POUR-CONCLUSION EST-LA-CONCLUSION-DE
EST-ANTECEDENT-DE A-POUR-ANTECEDENT
EST-PRECEDENT-DE EST-LE-SUIVANT-DE
PUIS-EVALUER EVALUE-A-PARTIR-DE
PUIS-EXECUTER A-POUR-PREALABLE
ENGLOBE EST-ENGLOBE-PAR
INTRANT-
PRODUIT
A-POUR-INTRANT EST-L_INTRANT-DE
A-POUR-PRODUIT EST-LE-PRODUIT-DE
REGIT OBEIT-A
PROPRIETE
La propriété « PROPRIETE » est une super propriété qui permet d’encapsuler les
propriétés du domaine. INTRANT-PRODUIT, PERMET-DE et A-POUR-
DEPENDANCE sont aussi des super-propriétés.
2.6.3 L’ontologie cadre d’OntoCASE en OWL-N3
L’appendice F.11 à la p.367 presente l’ontologie cadre en représentation des
connaissances d’OntoCASE dans le notation N-3.
2.7 Méthodologie de conception d'une ontologie formelle à partir d'un modèle semi-
formel
Schématisé à la figure 2.7, la méthodologie de conception d'une ontologie formelle à
partir d'un modèle semi-formel se compose de trois méthodes, soit les suivantes:
concevoir un modèle semi-formel, formaliser en ontologie du domaine et valider
l'ontologie du domaine. Quatre artéfacts sont produits par la méthodologie, soit le
modèle semi-formel du domaine, l'ontologie du domaine, le rapport de validation
syntaxique et le rapport de validation sémantique. La méthodologie est itérative,
c
d
p
l
s
L
c
d
à
m
v
F
m
L
d
c
'est-à-dire
q
d
e réalisati
o
p
récédente
s
l
'itération e
n
s
ections sub
L
es acteurs
c
es acteurs
e
d
étient par l
a
à
son doma
m
éthodes d
e
v
alidation d
e
F
igure 2.7:
M
m
odèle sem
i
L
e deuxièm
e
d
e son expe
r
q
ue le résul
t
o
n. C'est
a
s
ervent d'in
t
n
cours. Le
séquentes.
qui agissen
t
e
st l'expert
d
a
productio
n
ine d'exper
t
e
conceptio
n
e
l'ontologi
e
M
odèle de
l
i
-formel.
e
acteur de
l
r
tise en con
c
t
at de l'itéra
t
a
insi que l
e
t
rants à la
m
détail de c
h
t
sur la mét
h
d
e contenu.
S
n
d’un modè
ise. Il est d
n
du modèl
e
e
du domain
e
l
a méthodo
l
l
a méthodol
o
c
eption d'o
n
t
ion précéd
e
e
s rapports
m
éthode de
c
h
acune de c
h
odologie s
o
S
on rôle pri
n
le semi-for
m
onc directe
m
e
semi-form
e
e
.
l
ogie de co
n
o
gie est l'in
g
n
tologies, ce
t
e
nte sert d'i
n
de valida
t
c
onception
d
c
es méthode
s
o
nt au nom
b
n
cipal est d'
e
m
el
d
u dom
a
m
ent impli
q
e
l du doma
i
n
ception d'u
n
g
énieur de l
a
t
acteur a u
n
n
trant à l'ité
r
t
ion réalisé
s
d
u modèle s
s sera déve
l
b
re de cinq.
e
xtérioriser
l
a
ine valide e
t
q
ué dans la
r
i
ne et dans
ne ontologi
e
l
a connaissa
n
rôle de su
p
r
ation en co
u
s
à l'itérat
i
s
emi-formel
l
oppé dans
l
Le premier
l
'expertise q
u
t
cohérent f
a
r
éalisation
d
la méthode
e
à partir d
'
a
nce. En rai
s
p
port à l'exp
98
u
rs
i
on
de
l
es
de
u
'il
a
ce
d
es
de
'
un
s
on
ert
d
l
m
v
L
c
l
s
2
S
d
F
d
e contenu
p
l
e novice p
e
m
éthode d
e
v
alidation d
e
L
es troisiè
m
c
omputatio
n
l
a formalis
a
s
ection 2.3.
2
.7.1 Méth
o
S
chématisé
e
d
eux spécia
l
F
igure 2.8:
M
p
our la form
e
ndant la c
o
formalisat
i
e
l'ontologi
e
m
e, quatriè
m
n
nel d'Onto
C
a
tion et l’as
1, p. 81.
o
de de conce
p
e
à la figur
e
l
isations : m
o
M
éthode de
alisation de
o
nception d
u
i
on, puis il
e
.
m
e et cinqui
C
ASE, soit l
sistant à la
p
tion d'un
m
e
2.8, la mé
t
o
délise
r
et
c
conception
d
son experti
s
u
modèle se
m
t
r
availle e
n
ème acteur
s
’éditeur de
m
validation
m
odèle semi
-
t
hode conc
e
c
omodélise
r
.
d
'un modèle
s
e. L'ingéni
e
m
i-formel;
i
n
collaborat
s
sont les o
u
m
odèle MO
qui sont r
e
-
formel
e
voir un mo
semi-form
e
e
ur guide l'e
x
i
l réalise l'e
x
ion avec l'
e
u
tils qui fo
r
T eLi, le sy
s
e
spectiveme
n
dèle semi-
fo
e
l.
x
pert et parf
o
x
écution de
e
xpert pour
r
ment le v
o
s
tème expe
r
n
t décrits à
o
rme
l
prése
n
99
o
is
la
la
o
let
r
t à
la
n
te
100
La modélisation, en vue de concevoir un système à base de connaissances, ou d’une
ontologie, passe par une étape d’identification, d’explicitation, de structuration et de
représentation de la connaissance avant qu’elle ne soit utilisée pour la conception du
système à base de connaissances (Hart, 1986 ; Paquette et Roy, 1990). À sa plus
simple expression, la modélisation est assumée par un ingénieur de la connaissance,
aussi appelé cogniticien, et un expert de domaine. Une méthode particulièrement
prometteuse appelée comodélisation (Basque et al., 2004 ; Basque et al., 2008b) est
proposée dans le cadre de la méthodologie d’OntoCASE. Cette méthode implique la
participation d’un ou plusieurs experts et éventuellement de personnes plus novices
(Basque et Pudelko, 2010b) dans le domaine de connaissances ciblé, assistées de
l’acteur ingénieur de la connaissance. Nous nous intéressons plus particulièrement à
cette méthode puisque, de notre point de vue, elle nous semble le plus correspondre
au caractère consensuel de toute ontologie selon Gruber (1993a) et Borst (1997).
La comodélisation vise à stimuler l’externalisation des connaissances par la mise en
présence de plusieurs intervenants dans l'activité de modélisation. L'ingénieur est
l'acteur responsable de l'animation de l’activité de comodélisation et s’occupe de
transposer les connaissances exprimées sous la forme d’une représentation graphique
structurée selon un certain langage. L'acteur novice (qui est un connaissant du
domaine sans en être un expert par manque d'expérience sur le terrain) et l'acteur
expert sont des rôles qui peuvent être tenus chacun par une ou plusieurs personnes. Le
rôle de novice peut aussi être tenu par l’ingénieur de la connaissance. Les échanges
entre les acteurs et les accords qu'ils établissent entre eux permettent la modélisation
de connaissances consensuelles. Les connaissances consensuelles ainsi exprimées
sont représentées dans un modèle semi-formel, qui, par la suite, sert de nouvelle base
de discussion pour la production de nouvelles connaissances consensuelles. Le cycle
d'expression et de modélisation se poursuit jusqu'à ce que les acteurs humains
décident par consensus de la complétude du modèle. Plusieurs artéfacts servent
d’intrants à la conception du modèle semi-formel, qu'il s'agisse des rapports de
validation sémantique et syntaxique obtenus à l’étape de validation de l’itération
p
n
D
d
d
2
L
p
l
i
c
F
d
p
récédente
(
n
ormes et c
o
D
es détails
d
’élicitation
d
ans Basqu
e
2
.7.2 Méth
o
L
a méthod
e
p
résentée s
o
l
'ingénieur
d
i
mporter d
a
c
onvertir en
F
igure 2.9:
d
omaine.
(
que nous
d
o
nt
r
aintes d
u
sur la mis
des connai
s
e
et al. (200
8
o
de de form
a
e
formalise
r
o
us la form
e
d
e la conn
a
a
ns
l
'espac
e
ontologie
d
Méthode d
e
d
iscuterons
u
système à
e en œuvr
e
s
sances sont
8
a)
a
lisation en
o
r
en ontolo
g
e
d’un exe
m
a
issance. T
r
e
de modé
l
d
u domaine.
e
formalisa
t
à la sectio
n
venir ou de
e
de la mé
t
fournis da
n
o
ntologie du
g
ie du do
m
m
ple à la se
c
r
ois proces
s
l
isation on
t
t
ion d'un
m
n
2.7.3, p.1
0
tout autre d
t
hode de c
o
n
s Basque et
domaine
m
aine (sché
m
c
tion 2.7.2.4
s
us compo
s
t
ologique,
(
m
odèle sem
i
0
9), des sp
é
ocument de
o
-modélisati
t
Pudelko (2
0
m
atisée à l
a
4
p. 104) es
t
s
ent la mét
h
(
2) désamb
i
i
-formel en
1
é
cifications
l'organisati
o
on à des f
i
0
08, 2010b
)
a
figure 2.9
t
contrôlée
p
h
ode, soit
(
i
guïser et
(
ontologie
01
de
o
n.
f
i
ns
)
et
et
p
ar
(
1)
(
3)
du
102
2.7.2.1 Importer dans l’espace de modélisation ontologique
Le processus d'importation « 2.1 » sert à la traduction d'un modèle semi-formel
employant le formalisme de l'éditeur de modèles semi-formel (par exemple le XMI)
vers un modèle employant le formalisme ontologique utilisé par le modèle cible (par
exemple le OWL). Il s’agit d’une représentation en OWL du modèle source. Quant au
lienC mis entre les deux modèles, le premier modèle OWL représente l’ontologie du
langage MOT et le second, les individus correspondant au modèle source. Un
exemple détaillé d’importation est présenté au tableau 2.9 a et b.
2.7.2.2 Désambiguïser le modèle semi-formel
Le processus de désambiguïsation « 2.2 », qui dans certains cas est assisté par l'expert
de contenu, consiste à supprimer les ambigüités contenues dans l’ontologie du modèle
semi-formel afin de produire l’ontologie du modèle semi-formel désambiguïsé. Pour
ce faire, le processus de désambiguïsation utilise la sémantique du langage source
(l’ontologie du langage semi-formel) pour identifier le type de désambiguïsation
appropriée du modèle semi-formel. L'ontologie du langage semi-formel en intrant de
ce processus détermine la sémantique des éléments de l'ontologie du modèle semi-
formel à désambiguïser. Trois catégories de désambiguïsation sont réalisées :
typologique, topologique et sémantique.
La désambiguïsation typologique est la plus automatique des désambiguïsations. Elle
associe le type d'un composant du modèle semi-formel à un élément ontologique. Par
exemple (voir le cas 1 du tableau 2.9 et du tableau 2.10), le composant lienS (sorte-
de) s'interprète comme une relation d'hyponymie (de type généralisation) et le
composant lienI (instance) s'interprète comme une relation d'instanciation.
La désambiguïsation topologique est plus complexe et peut, dans quelques cas, n'être
que semi-automatisée. Cette désambiguïsation s'établit en caractérisant les
composants du modèle par l'identification d'un patron de disposition. À l'exemple du
cas 2 du tableau 2.9 et du tableau 2.10, les concepts C4 et C5 sont interprétés comme
103
des classes et le principe P1 comme une propriété (binaire) mettant en relation ces
classes, grâce à l'identification du patron de disposition suivant: un principe est uni
par un lienR à un concept en intrant et est uni par un lienR à un concept extrant.
Également, les connaissances stratégiques P1 et A1 qui sont représentées par des
Principes dans le modèle semi-formel sont désambiguïsées en Propriétés pour P1 et
en connaissances stratégiques pour A1.
Du point de vue de l'ingénieur de la connaissance, l'étape de désambigüisation selon
la sémantique du domaine est délicate, car elle nécessite une compréhension du
domaine qui est modélisé, ce qui implique la collaboration de l'expert de contenu afin
de répondre aux questions de l'ingénieur. L'exemple d'interprétation du lien de
composition dans le langage MOT est une bonne illustration de ce type d'ambiguïté
(voir le cas 3 du du tableau 2.9 et du tableau 2.10). Le lien de composition s'interprète
de deux façons. La première interprétation possible est la composition entre concepts
(exemple: C7 a pour partie C8). La deuxième interprétation possible est l'utilisation
du lien de composition pour assigner des attributs à un concept (exemple : C7 a pour
attribut C9), c'est-à-dire que la relation unit une classe à un objet DataType. Seule
une connaissance adéquate du domaine de connaissances permet de lever l'ambiguïté
liée à cette double interprétation du LienC.
2.7.2.3 Convertir en ontologie du domaine
Finalement, à partir de l'ontologie du modèle semi-formel désambiguïsé, le processus
de conversion en ontologie du domaine « 2.3 » produit une nouvelle ontologie en
interprétant chacun des éléments de l'ontologie désambiguïsée en élément
correspondant dans l'ontologie du domaine. Par exemple, un concept dans le modèle
semi-formel sera transformé en classe dans l'ontologie du domaine. Dans sa forme
finale, l'ontologie du domaine importe l'ontologie cadre assurant ainsi une
caractérisation des éléments de l'ontologie du domaine (voir le tableau 2.9 et le
tableau 2.10).
104
2.7.2.4 Exemple de formalisation d’un modèle semi-formel
Le tableau 2.9 présente un cas de figure de modélisation semi-formelle à formaliser.
Les résultats de la réalisation des étapes de modélisation (voir le tableau 2.9 a et b);
d'importation (voir le tableau 2.9 c), de désambiguïsation (voir le tableau 2.9 d) et de
conversion (tableau 2.10) y sont respectivement représentés en langage MOT et OWL
dans la Notation 3 (N3) (Berners-Lee, 1998) (voir l’appendice E pour un aperçu de la
Notation 3).
/
Ét
u
/
…
Cas 1) Dé
s
typ
o
Relations d'i
n
sub
s
Cas 1)
<?xml
<mot:
xmlns
<co
<
onto
R
</c
<co
<co
<
onto
R
</c
<co
</mot
Cas 2)
<?xml
<mot:
xmlns
<co
<
onto
R
</c
<co
<
onto
R
</c
<co
<co
<co
<
</c
</mot
Cas 3)
<?xml
<mot:
xmlns
<co
<
targe
<
targe
</c
<co
<co
onto
R
</mot
u
des de cas
r
s
ambiguïsatio
n
o
logique
n
stanciation et
s
omption
b) Repré
s
version="1.0"
e
ModeleMot
:xsi="http://ww
w
nnaissances xsi:
relations x
s
R
efStereotype="N
O
onnaissances>
nnaissances xsi:
nnaissances xsi:
relations x
s
R
efStereotype="N
O
onnaissances>
nnaissances xsi:
:ModeleMot>
version="1.0"
e
ModeleMot
:xsi="http://ww
w
nnaissances xsi:
relations x
s
R
efStereotype="N
O
onnaissances>
nnaissances xsi:
relations x
s
R
efStereotype="N
O
onnaissances>
nnaissances xsi:
nnaissances xsi:
nnaissances xsi:
relations xsi:t
y
onnaissances>
:ModeleMot>
version="1.0"
e
ModeleMot
:xsi="http://ww
w
nnaissances xsi:
relations
t="//@connaissa
n
relations
t="//@connaissa
n
onnaissances>
nnaissances xsi:
nnaissances
R
efStereotype="E
n
:ModeleMot>
r
eprésentés
e
n
Ca
s
a) Dia
g
ram
m
de U
n
p
s
entation sem
i
e
ncoding="UTF-
8
"
?
xmi
:
w
.w3.org/2001/XM
L
type="mot:Conce
p
s
i:type="mot:Lie
n
O
N
_
DETERMINE"/>
type="mot:Exemp
l
type="mot:Conce
p
s
i:type="mot:Lie
n
O
N
_
DETERMINE"/>
type="mot:Conce
p
e
ncoding="UTF-
8
"
?
xmi
:
w
.w3.org/2001/XM
L
type="mot:Conce
p
s
i:type="mot:Lie
n
O
N
_
DETERMINE"/>
type="mot:Princ
i
s
i:type="mot:Lie
n
O
N
_
DETERMINE"/>
type="mot:Conce
p
type="mot:Conce
p
type="mot:Princ
i
y
pe="mot:LienR"
s
e
ncoding="UTF-
8
"
?
xmi
:
w
.w3.org/2001/XM
L
type="mot:Conce
p
xsi:type
=
"mot:
n
ces.1"/>
xsi:type="mot:
n
ces.2" ontoRefS
t
type="mot:Conce
p
xsi:type="mo
t
n
tite
_
Schema
_
Str
i
Tableau 2.
9
e
n langage
M
s
2) Désambig
u
topologiqu
e
m
e semi-form
e
n
principe en t
a
p
ropriété ou a
g
i
-formelle du
d
?
>
:
version="2.0"
L
Schema-
i
nstance
"
p
t" nom="C1" id=
"
n
I" sou
r
ce="
/
l
e" nom="I1" id=
"
p
t" nom="C2" id=
"
n
S" source="
/
p
t" nom="C3" id=
"
?
>
:
version="2.0"
L
Schema-
i
nstance
"
p
t" nom="C4" id=
"
n
R" source="
/
i
pe" nom="P1" id
=
n
R" source="
/
p
t" nom="C5" id=
"
p
t" nom="C6" id=
"
i
pe" nom="A1" id
=
s
ource="//@conna
i
?
>
:
version="2.0"
L
Schema-
i
nstance
"
p
t" messageErreu
r
LienC"
m
LienC"
m
t
ereotype="Attri
b
p
t" messageErreu
r
t
:Concept"
i
ng"/>
9
M
OT et en l
a
u
ïsation
e
e
lle du domai
n
a
nt que
g
en
t
d
omaine en n
o
"
xmlns:mot="www
.
"
C1
_
21">
/
/@connaissances
.
"
I1
_
22" ontoRefS
t
"
C2
_
23">
/
/@connaissances
"
C3
_
24"/>
"
xmlns:mot="www
.
"
C4
_
25">
/
/@connaissances
=
"P1
_
26">
/
/@connaissances
"
C5
_
27"/>
"
C6
_
50"/>
=
"A1
_
51">
i
ssances.4" targ
e
"
xmlns:mot="www
.
r
="" nom="C7" id
=
m
essageErreur=""
m
essageErreur=""
b
ut"/>
r
="" nom="C8" id
=
messageErreur=
"
a
ngage OW
L
Cas 3) Dés
a
sém
a
n
e
Relations de
d'att
r
o
tation XMI
xmlns:xmi="htt
p
.
cotechnoe.com/m
o
.0" target=
"
t
ereotype="NON
_
D
E
.2" target=
"
xmlns:xmi="htt
p
.
cotechnoe.com/m
o
.0" target=
"
.1" target=
"
e
t="//@connaissa
n
xmlns:xmi="htt
p
.
cotechnoe.com/m
o
=
"C7
_
0">
source=
"
source=
"
=
"C8
_
1"/>
"
" nom="
C
1
L
-N3.
a
mbiguïsation
a
ntique
composition o
u
r
ibution
p
://www.omg.org/
X
o
t">
"
//@connaissance
s
E
TERMINE"/>
"
//@connaissance
s
p
://www.omg.org/
X
o
t">
"
//@connaissance
s
"
//@connaissance
s
n
ces.3"/>
p
://www.omg.org/
X
o
t">
"
//@connaissance
s
"
//@connaissance
s
C
9" id="C
9
05
u
X
MI"
s
.1"
s
.3"
X
MI"
s
.1"
s
.2"
X
MI"
s
.0"
s
.0"
9_
2"
106
…/
/…
c) Représentation après importation dans l'espace de modélisation ontologique en notation -3
Cas 1)
:C1_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C1"^^xsd:string ;...
:C2_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C2"^^xsd:string ;...
:C3_3 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C3"^^xsd:string ;...
:I1_1 a metaMot:MOT_Exemple ;
metaMot:MOT_etiquette "I1"^^xsd:string ;...
:LienI_C1_0_I1_1 a metaMot:MOT_LienI ;
metaMot:MOT_connDestination :I1_1 ;
metaMot:MOT_connSource :C1_0 ;
metaMot:MOT_nomLien "LienI_C1_0_I1_1"^^xsd:string ;...
:LienS_C2_2_C3_3 a metaMot:MOT_LienS ;
metaMot:MOT_connDestination :C3_3 ;
metaMot:MOT_connSource :C2_2 ;
metaMot:MOT_nomLien "LienS_C2_2_C3_3"^^xsd:string ;...
Cas 2)
:A1_4 a metaMot:MOT_Principe ;
metaMot:MOT_etiquette "A1"^^xsd:string ; ...
:C4_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C4"^^xsd:string ; ...
:C5_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C5"^^xsd:string ; ...
:C6_3 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C6"^^xsd:string ; ...
:LienR_A1_4_C6_3 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :C6_3 ;
metaMot:MOT_lrConnSrc :A1_4 ; ...
:LienR_C4_0_P1_1 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :P1_1 ;
metaMot:MOT_lrConnSrc :C4_0 ; ...
:LienR_P1_1_C5_2 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :C5_2 ;
metaMot:MOT_lrConnSrc :P1_1 ; ...
:P1_1 a metaMot:MOT_Principe ;
metaMot:MOT_etiquette "P1"^^xsd:string ; ...
Cas 3)
:C7_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C7"^^xsd:string ;...
:C8_1 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C8"^^xsd:string ; ...
:C9_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C9"^^xsd:string ; ...
:LienC_C7_0_C8_1 a metaMot:MOT_LienC ;
metaMot:MOT_connDestination :C8_1 ;
metaMot:MOT_connSource :C7_0 ; ...
:LienC_C7_0_C9_2 a metaMot:MOT_LienC ;
metaMot:MOT_connDestination :C9_2 ;
metaMot:MOT_connSource :C7_0 ; ...
107
…/
Chacun des cas est associé à un type de désambiguïsation particulier. Ainsi, le
premier cas, qui présente un modèle composé de liens de subsomption et
d'instanciation, fait appel à une désambigüisation de type typologique qui classe: les
Concepts C1, C2, C3 en tant qu'owl:Class, avec C2 qui subsume C3; et l'Exemple I1
en tant qu'individu OWL appartenant à C1. Le deuxième cas, qui fait référence à une
d) Représentation après la désambiguïsation en notation-3
Cas 1)
:C1_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C1"^^xsd:string ; ...
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ; ...
:C2_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C2"^^xsd:string ; ...
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ; ...
:C3_3 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C3"^^xsd:string ; ...
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ; ...
:I1_1 a metaMot:MOT_Exemple ;
metaMot:MOT_etiquette "I1"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Observable_Objet ; ...
:LienI_C1_0_I1_1 a metaMot:MOT_LienI ;
metaMot:MOT_connDestination :I1_1 ;
metaMot:MOT_connSource :C1_0 ;
ot:OT_EntiteEstDeType oAmbig:Relation_Instanciation ; ...
:LienS_C2_2_C3_3 a metaMot:MOT_LienS ;
metaMot:MOT_connDestination :C3_3 ;
metaMot:MOT_connSource :C2_2 ;
ot:OT_EntiteEstDeType oAmbig:Relation_Specialisation ; ...
Cas 2)
:A1_4 a metaMot:MOT_Principe ;
metaMot:MOT_etiquette "A1"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Agent_Contrainte_Norme ;
:C4_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C4"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ;
:C5_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C5"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ;
:C6_3 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C6"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ;
:LienR_A1_4_C6_3 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :C6_3 ;
metaMot:MOT_lrConnSrc :A1_4 ;
ot:OT_EntiteEstDeType oAmbig:Relation_Regulation ;
:LienR_C4_0_P1_1 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :P1_1 ;
metaMot:MOT_lrConnSrc :C4_0 ;
ot:OT_EntiteEstDeType oAmbig:Relation_Regulation ;
:LienR_P1_1_C5_2 a metaMot:MOT_LienR ;
metaMot:MOT_lrConnDest :C5_2 ;
metaMot:MOT_lrConnSrc :P1_1 ;
metaMot:MOT_nomLien "LienR_P1_1_C5_2"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Relation_Regulation ;
:P1_1 a metaMot:MOT_Principe ;
metaMot:MOT_etiquette "P1"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Propriete ;
ot:OT_nomEntiteDestination "C5_2"^^xsd:string ;
ot:OT_nomEntiteSource "C4_0"^^xsd:string ;
Cas 3)
:C7_0 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C7"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ; ...
:C8_1 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C8"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Concept_Classe ; ...
:C9_2 a metaMot:MOT_Concept ;
metaMot:MOT_etiquette "C9"^^xsd:string ;
ot:OT_EntiteEstDeType oAmbig:Entite_Schema_String ; ...
:LienC_C7_0_C8_1 a metaMot:MOT_LienC ;
metaMot:MOT_connDestination :C8_1 ;
metaMot:MOT_connSource :C7_0 ;
ot:OT_EntiteEstDeType oAmbig:Holonyme ; ...
:LienC_C7_0_C9_2 a metaMot:MOT_LienC ;
metaMot:MOT_connDestination :C9_2 ;
metaMot:MOT_connSource :C7_0 ;
ot:OT_EntiteEstDeType oAmbig:Attribut ; ...
108
désambiguïsation topologique, permet de désambiguïser les Principes P1 et A1
respectivement en owl:ObjectProperty et owl:Class de catégorie
Agent_Contrainte_Norme. Finalement, le troisième cas nécessite une compréhension
du domaine afin de désambiguïser de façon sémantique l'interprétation du
LienDeComposition, qui, entre C7 et C8, se formalise par une owl:ObjectProperty de
catégorie A-POUR-COMPOSANT dont le domaine est l'owl:Class C7 et l'owl:Class
C8; et entre C7 et C9 qui se formalise par une owl:DatatypeProperty de catégorie A-
POUR-ATTRIBUT dont le domaine est l'owl:class C7 et l'image une xsd:string.
Tableau 2.10
Modèle semi-formel formalisé en OWL-N3
Cas 1)
:C1_0 a owl:Class ;
rdfs:label "C1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C2_2 a owl:Class ;
rdfs:label "C2"^^xsd:string ;
rdfs:subClassOf :C3_3 .
:C3_3 a owl:Class ;
rdfs:label "C3"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:I1_1 a :C1_0 ;
rdfs:label "I1"^^xsd:string .
Cas 2)
:A1_4 a owl:Class ;
rdfs:label "A1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme .
:A1_4_regit_C6_3 a owl:ObjectProperty ;
rdfs:domain :A1_4 ;
rdfs:label ""^^xsd:string ;
rdfs:range :C6_3 ;
rdfs:subPropertyOf metaDom:REGIT .
:C4_0 a owl:Class ;
rdfs:label "C4"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C4_0_P1_1_C5_2 a owl:ObjectProperty ;
rdfs:domain :C4_0 ;
rdfs:label "P1"^^xsd:string ;
rdfs:range :C5_2 ;
rdfs:subPropertyOf :P1_1 .
:C5_2 a owl:Class ;
rdfs:label "C5"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C6_3 a owl:Class ;
rdfs:label "C6"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:P1_1 a owl:ObjectProperty ;
rdfs:label "P1"^^xsd:string ;
rdfs:subPropertyOf metaDom:MD_PROPRIETE .
Cas 3)
:C7_0 a owl:Class ;
rdfs:label "C7"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C7_0_aPourAttribut_C9_2 a ObjectProperty ;
rdfs:domain :C7_0 ;
rdfs:label "C9"^^xsd:string ;
rdfs:range :C9_2 ;
rdfs:subPropertyOf metaDom:A-POUR-ATTRIBUT .
:C7_0_aPourComposant_C8_1 a owl:ObjectProperty ;
rdfs:domain :C7_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :C8_1 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:C8_1 a owl:Class ;
rdfs:label "C8"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C9_2 a owl:Class ;
rdfs:label "C9"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_String .
109
2.7.3 Méthode de validation de l'ontologie de domaine
En ingénierie ontologique, la validation est une étape essentielle à toute production
d'ontologies. Gómez-Pérez (2004) présente les critères selon lesquels l'ontologie
devrait être validée. La consistance concerne l’absence de contradictions entre les
éléments ontologiques. La complétude assure que tous les éléments ontologiques sont
soit explicitement déclarés, soit inférables. La concision est un principe qui stipule
que seuls les éléments à être définis doivent être définis. L’expansibilité est la
capacité d'ajouter de nouvelles connaissances sans modifier les anciennes.
Finalement, la sensibilité est la capacité de l'ontologie à réagir à des modifications.
En général, peu importe le domaine modélisé, il nous apparaît que les critères de
validation s'appliquent aux aspects syntaxique et sémantique des connaissances qui
sont représentées. Dans un modèle, qu'il soit semi-formel ou formel, on utilise un
vocabulaire, une grammaire et une sémantique pour représenter les connaissances
associées à un domaine. Le vocabulaire détermine les symboles qui sont utilisés pour
représenter. La grammaire stipule les règles d'utilisation des symboles. La sémantique
en définit le sens. Pendant la formalisation d'un modèle semi-formel, certaines
opérations peuvent modifier des éléments de vocabulaire (le critère syntaxique) ou
altérer le sens de la représentation (le critère sémantique). Il importe donc d'implanter
un mécanisme de validation qui assure qu'aucune altération de la syntaxe et de la
sémantique du modèle ne soit induite par le processus de transformation.
La méthode de validation, schématisée à la figure 2.10, régie par l'ingénieur, l'expert
et l'assistant informatique intelligent à la validation, comporte un processus de
validation syntaxique « 3.1 » et un processus de validation sémantique « 3.2 ». Pour
son accomplissement, la méthode nécessite en intrant le modèle semi-formel de
domaine et son correspondant ontologique, l'ontologie du langage de modélisation
semi-formel. Après son exécution, la méthode produit un rapport de validation
syntaxique ainsi qu'un rapport de validation sémantique.
F
2
L
d
l
L
r
c
f
C
l
L
d
s
i
f
s
s
F
igure 2.10:
2
.7.3.1 Proc
L
e but de l
d
étection d
e
l
'ontologie
c
L
'erreur de
r
egénératio
n
c
ausée par
f
ormalisatio
n
C
omme so
n
l
'inspection
L
'idée sout
e
d
'origine d
o
s
upposons
q
i
dentique a
u
f
igure 2.11,
s
emi-forme
l
s
emi-forme
l
Méthode d
e
essus de va
l
a
validatio
n
e
s erreurs
i
c
ible. Deux
regénératio
n
n
et doit êtr
une erreur
n
. Là encor
e
n
nom l'in
d
des compo
s
e
nant ce pr
o
ivent être r
e
q
u'un modèl
u
modèle d'
le sous-pr
o
l
reconstruit
l
d'origine
a
e
validation
idation synt
a
n
syntaxiqu
e
i
nformatiqu
e
types d'err
e
n
est causée
e corrigée
p
de progra
m
e
, l'erreur do
d
ique, la
v
s
ants de vo
ocessus est
e
présentés
d
e reconstru
i
origine en
t
o
cessus, gén
à partir de
a
vec le m
o
de l'ontolog
i
a
xique
e
est de fou
r
e
s qui peu
v
urs peuven
t
par une er
r
p
ar le dével
m
mation dan
it être rapp
o
v
alidation s
y
cabulaire e
t
que tous
l
d
ans l'ontol
o
i
t à partir d
e
t
ermes d'en
t
érer un mo
l'ontologie
d
o
dèle semi-
f
i
e du domai
n
r
nir au cog
n
v
ent surven
i
t
provoquer
r
eur de pro
g
l
oppeur. L'e
r
s un des
m
o
rtée au dév
e
y
ntaxique
c
t
de gramm
l
es élément
s
o
gie du do
m
e
l'ontologi
e
t
ités et de
r
dèle semi-
fo
d
u domaine
f
ormel reco
n
n
e.
n
iticien un
m
i
r dans la
p
une anoma
l
g
rammation
r
reur de fo
r
m
odules de
l
e
loppeur.
c
oncentre l
e
m
aire du mo
d
s et relatio
n
m
aine. De c
e
e
du domai
n
r
elations. S
c
fo
rmel, prod
u
. En compa
r
n
struit, le
s
1
m
écanisme
p
roduction
l
ie syntaxiq
u
du module
r
malisation
e
l
'assistant à
e
s efforts
s
d
èle d'origi
n
n
s du mod
è
e
tte idée, n
o
n
e devrait ê
c
hé
m
atisé à
u
it un mod
è
r
ant le mod
è
s
ous-proces
s
10
de
de
u
e.
de
e
st
la
s
ur
n
e.
è
le
o
us
tre
la
è
le
è
le
s
us
c
é
F
2
L
L
s
m
i
f
c
i
l
d
i
e
c
omparer l
e
é
ventuelles
a
F
igure 2.11:
2
.7.3.2 Proc
L
a validatio
n
L
e modèle
s
emi-formel
,
m
odèle se
m
i
l produit, à
f
aire, le so
u
c
onclusions
i
nterprétati
o
l
'expert de
c
d
e ce rapp
o
i
tération de
e
ncore pou
r
e
s modèles
p
a
nomalies s
y
Processus
d
essus de va
l
n
sémantiq
u
représente-t
,
régie par
i-formel. Q
u
partir de l'
o
u
s-processu
s
qui servi
o
ns. La co
m
c
ontenu, ser
t
o
rt que la d
é
formalisati
o
améliorer s
o
p
roduit un
r
y
ntaxiques
e
d
e validatio
n
idation sém
a
u
e est un pro
-il bien la
r
l'expert, pe
r
u
ant au pro
c
ntologie du
s
utilise u
n
ront d'intr
a
mp
araison de
s
t
à la produ
c
é
cision de
p
o
n sera prise
,
o
n correspo
n
r
apport de
v
e
ntre les mo
d
n
syntaxique
a
ntique
cessus qui s
'
r
éalité qu'il
r
met de pr
o
c
essus d'inte
r
domaine, u
n
n
moteur d'
i
a
nts au s
o
s
interprétat
i
c
tion du rap
p
p
oursuivre
o
,
soit pour
m
n
dant sous f
o
v
alidation s
y
d
èles.
.
'intéresse à
l
désigne?
L
o
duire une
i
r
prétation a
n
e interprét
a
i
nférence p
o
o
us-process
u
ions, qui es
t
p
ort d'inter
p
o
u non la d
é
m
odifier le r
a
o
rme d’onto
y
ntaxique q
u
l
a significat
i
L
'interprétat
i
i
nterprétatio
n
utomatique
a
tion autom
a
o
ur générer
u
s de co
mp
t
sous la re
s
p
rétation. C’
é
marche pa
r
a
pport semi
-
logie.
1
u
i exprime
l
i
on du mod
è
i
on du mod
è
n
humaine
de l'ontolo
g
a
tique. Pour
de nouvel
l
mp
araison
d
s
ponsabilité
est sur la b
a
r
une nouv
e
-
formel ou s
11
l
es
è
le.
è
le
du
g
ie,
ce
l
es
d
es
du
a
se
e
lle
oit
F
2
E
n
é
L
s
c
d
p
d
s
p
e
t
F
igure 2.12:
2
.7.3.3 Exe
m
E
xaminons
n
aturel don
t
é
tiquettes (
d
L
a validati
o
s
emi-forme
l
c
oncordanc
e
d
écompte
d
p
ermettent
d
d
ans l'ontol
s
ystème id
e
p
rincipes, 1
3
e
t 0 lienA,
0
t
ableau 2.1
2
Processus
d
m
ple de vali
d
le modèle
s
t
le sujet e
s
d
e a à g) est
d
o
n syntaxiqu
l
est repré
s
e
, un modèl
e
d
es élément
s
d
e vérifier
l
ogie du do
m
e
ntifie que
3
exemples,
0
lienCm,
e
).
d
e validatio
n
d
ation synt
a
s
emi-formel
s
t l’Objet c
é
d
étaillée à l
a
e a pour ob
j
s
enté dans
e
semi-form
e
s
de chacu
n
l
a représent
a
m
aine. Ain
s
le modèle
3 traces, 3
e
t 0 énonc
é
n
sémantiqu
e
xique et sé
m
suivant et
s
é
leste (voir
a
section 4.3
j
ectif de s'a
s
l'ontologie
e
l est généré
n
des mod
è
a
tion de ch
a
s
i, pour le
se compos
lienIP, 7 li
e
é
(voir le
r
e
.
m
antique
s
on interpré
t
le tableau
2
.6 p.198.
s
surer que
c
du doma
i
é
à partir de
l
è
les et la
c
a
que éléme
n
modèle pr
é
e de 11 c
o
e
nR, 5 lien
C
r
apport de
t
ation possi
b
2
.11). La si
g
c
haque élém
i
ne. Pour
m
l
'ontologie
d
c
omparaiso
n
n
t du modè
l
é
senté au t
a
o
ncepts, 4
C
, 9 lienS, 1
6
validation
1
b
le en lang
a
g
nification
d
ent du mod
è
m
esurer c
e
d
u domaine.
n
des résult
a
l
e semi-for
m
a
bleau 2.11,
procédures,
6
lienI, 2 lie
n
syntaxique
12
a
ge
d
es
è
le
e
tte
Le
a
ts
m
el
le
4
n
P
au
a
b
L
h
a
s
l
c
s
p
L’Objet
c
a
) Le modèle
s
b
) Interprétati
o
L’objet cé
attribut un
(FG). Cet
t
qui est de
9
et la quan
t
QV sont d
e
et les satel
s
atellites
n
Déimos,
P
s
atellites
n
existe aus
s
L
'idée maît
r
h
umaineme
n
a
utomatiqu
e
s
émantique
l
'ontologie.
c
éleste est
s
s
orte de Pl
a
p
rovient de
c
éleste: le
m
s
emi-formel
o
n possible en
l
leste est régi
e masse et est
t
e force est ca
l
9
.8 m/s
2
. D'au
t
t
ité de mouve
m
e
s exemples sp
é
lites naturels
s
n
aturels tourn
e
P
hobos sont de
s
n
aturels de S
a
s
i, quelque par
t
r
esse de la v
a
n
t à partir
e
ment à par
t
au tableau
Dans la ta
x
ubsumé par
a
nète, serait
l'inversion
d
odèle semi-
f
l
angage natur
e
par le princi
p
lié à d'autres
c
l
culée à parti
r
t
res paramètre
s
m
ent (QV). Un
c
é
cifiques de c
a
s
ont des corps
c
e
nt autour des
p
s
satellites na
t
a
turne. Finale
m
t
, un satellite
q
a
lidation sé
m
du modè
l
t
ir de l'ont
o
2.13). La
p
x
onomie de
celui d’Ét
o
considérée
d
e la directi
o
Tableau 2.
1
f
ormel et so
n
naturel
e
l
p
e de la loi
d
c
orps célestes
p
r
de la masse
e
s
physiques p
e
c
alcul de la F
G
a
lcul de param
c
élestes. Les p
p
lanètes. Satu
t
urels de Mar
s
m
ent, la Lune
q
uelconque.
m
antique es
t
l
e semi-for
m
o
logie du d
o
p
remière ph
a
classes de
c
o
ile, ce qui
v
comme un
e
o
n du LienS
1
1
n
interpréta
t
d
e la gravitat
i
p
ar la force d'
a
e
t de l'accélér
a
e
uvent être cal
c
G
suivi d'un c
a
m
ètres physiqu
e
lanètes tourne
n
u
rne, Mars et l
a
s
; Titan, Téth
y
est un satelli
t
t
de compar
e
r
mel avec
o
maine (voi
r
a
se de la
v
cette ontol
o
v
oudrait dir
e
e
Étoile. Ce
t
(étiquette c
t
ion possibl
e
i
on universell
e
a
ttraction gra
v
a
tion gravitat
i
c
ulés tels que
l
a
lcul de E et d'
u
e
s. Les étoiles,
nt autour des
é
a
Terre sont
d
y
s, Japet et R
h
te naturel de
e
r les concl
u
les conclu
s
r
le rappor
t
v
alidation e
s
o
gie, le con
c
e
que la Ter
r
t
te erreur d
e
de la figure
1
e
en langage
e
. Il a pour
v
itationnelle
i
onnelle (G)
l
'énergie (E)
u
n calcul de
les planètes
é
toiles et les
d
es planètes,
h
éa sont des
la Terre. Il
u
sions infér
é
s
ions infér
é
t
de validat
i
s
t l'analyse
c
ept de Obj
r
e, qui est
u
e
classificat
i
1). Le mot
e
13
é
es
é
es
i
on
de
et-
u
ne
i
on
e
ur
114
d’inférence appliqué à l’ontologie fera apparaître automatiquement cette incohérence
qui pourra être détectée par l’utilisateur. Ainsi, l’utilisateur pourra corriger le modèle
semi-formel initial.
Dans le cas de figure représenté par l'étiquette b, on pourrait interpréter que Phobos,
en tant que satellite naturel, se compose d'un satellite naturel de Saturne tel que Titan.
Or, une inférence automatique nous indiquera que Titan EST-LA-PARTIE-DE d’un
satellite naturel alors qu'il est plus exact de dire que Titan et Phobos sont tous les
deux des satellites naturels en remplaçant le lienC par un lienS.
Tableau 2.12
Bilan du rapport de validation syntaxique du modèle L’Objet Céleste
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 11, Reconstruit = 11, Différence = 0
Compte des Procedures: Original = 4, Reconstruit = 4, Différence = 0
Compte des Principes : Original = 4, Reconstruit = 4, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 3, Reconstruit = 3, Différence = 0
Compte des Exemples : Original = 13, Reconstruit = 13, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 16, Reconstruit = 16, Différence = 0
Compte des LienIP : Original = 3, Reconstruit = 3, Différence = 0
Compte des LienP : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienR : Original = 7, Reconstruit = 7, Différence = 0
Compte des LienS : Original = 9, Reconstruit = 9, Différence = 0
La formalisation du cas de figure présenté à l'étiquette a, indique que la classe Lune
est une sorte de satellite naturel de la Terre. Mécaniquement, nous pourrions
instancier des individus de type Lune, ce qui, en termes représentationnels, est faux
puisque la lune est un objet et non une classe d'objets.
L'étiquette d présente le cas où un lienC est formalisé en tant qu’attribut. Ce lien sera
désambigüisé grâce à la distinction entre les métaliens A-POUR-COMPOSANT et A-
POUR-ATTRIBUT.
115
L'étiquette e présente deux cas d'utilisation du Principe. Le premier des cas, Loi de la
gravitation universelle, est désambiguïsé sous la forme owl:class de catégorie
Agent_Contrainte_Norme. Le deuxième cas, tourneAutourDe, est formalisé en
owl:ObjectProperty dont le domaine et l'image correspondent à la classe source et
cible du Principe.
L'étiquette f indique que les entités « un calcul de FG », « un calcul de E » et « un
calcul de QV », sont des traces des connaissances procédurales « calculer la force
gravitationnelle », « calculer l'énergie » et « calculer la quantité de mouvement ».
L'étiquette g présente un cas de figure fort intéressant puisqu'il concerne le traitement
ontologique de connaissances procédurales. Après l'inférence, grâce aux méta-
propriétés définies dans l'ontologie de référence, on aura que, le calcul de la quantité
de mouvement A-POUR-DÉPENDANCE l'exécution des étapes « calculer la force
gravitationnelle » et « calculer l'énergie ».
Tableau 2.13
Rapport de validation sémantique généré par OntoCASE
----------Début du processus de validation sémantique-------------
Accélération en mètre par seconde carrée (G) est un intrant de Calculer des paramètres physiques
Accélération en mètre par seconde carrée (G) est une sorte de (metaDom:MD_Declarative_Concept)
Calculer des paramètres physiques est une sorte de (metaDom:MD_Procedurale_Procedure)
Calculer l'énergie est une sorte de (metaDom:MD_Procedurale_Procedure)
Calculer l'énergie est une sorte de Calculer des paramètres physiques
Calculer la force gravitationnelle est une sorte de (metaDom:MD_Procedurale_Procedure)
Calculer la force gravitationnelle est une sorte de Calculer des paramètres physiques
Calculer la quantité de mouvement est une sorte de (metaDom:MD_Procedurale_Procedure)
Calculer la quantité de mouvement est une sorte de Calculer des paramètres physiques
Force d'attraction gravitationnelle est une sorte de (metaDom:MD_Declarative_Concept)
Loi de la gravitation universelle est une sorte de (metaDom:MD_Strategique_AgentContrainteNorme)
Loi de la gravitation universelle régit Objet celeste
Lune est une sorte de Satellite naturel de la Terre
Masse est un intrant de Calculer des paramètres physiques
Masse est une sorte de (metaDom:MD_Declarative_Concept)
Objet celeste a pour attribut Masse
Objet celeste est lié à un corps celestre par Force d'attraction gravitationnelle
Objet celeste est une sorte de Étoile
Planète est une sorte de Objet celeste
Planète tourneAutourDe Étoile
Satellite naturel de Mars est une sorte de Satellite naturel
Satellite naturel de Saturne est une sorte de (metaDom:MD_Declarative_Concept)
Satellite naturel de la Terre est une sorte de Satellite naturel
Satellite naturel est une sorte de Objet celeste
Satellite naturel se compose de Satellite naturel de Saturne
Satellite naturel tourneAutourDe Planète
[9.8] est de catégorie (metaDom:MD_Declarative_Concept)
[9.8] est un ( :Accélération en mètre par seconde carrée (G) )
[Déimos] est de catégorie (metaDom:MD_Declarative_Concept)
[Déimos] est un ( :Satellite naturel de Mars )
[Force gravitationelle calculée] est de catégorie (metaDom:MD_Declarative_Concept)
[Force gravitationelle calculée] est un ( :Force d'attraction gravitationnelle )
[Japet] est de catégorie (metaDom:MD_Declarative_Concept)
[Japet] est un ( :Satellite naturel de Saturne )
[Mars] est de catégorie (metaDom:MD_Declarative_Concept)
[Mars] est un ( :Planète )
[Phobos] est de catégorie (metaDom:MD_Declarative_Concept)
[Phobos] est un ( :Satellite naturel de Mars )
[Rhéa] est de catégorie (metaDom:MD_Declarative_Concept)
[Rhéa] est un ( :Satellite naturel de Saturne )
a) Devrait être un fait
d) Devrait être lié par un lienS
c) Le lienC signifiant ‘attribut’
b) Le principe est une classe …
e) … et une propriété
116
[Saturne] est de catégorie (metaDom:MD_Declarative_Concept)
[Saturne] est un ( :Planète )
[Soleil] est de catégorie (metaDom:MD_Declarative_Concept)
[Soleil] est un ( :Étoile )
[Terre] est de catégorie (metaDom:MD_Declarative_Concept)
[Terre] est un ( :Planète )
[Titan] est de catégorie (metaDom:MD_Declarative_Concept)
[Titan] est un ( :Satellite naturel de Saturne )
[Téthys] est de catégorie (metaDom:MD_Declarative_Concept)
[Téthys] est un ( :Satellite naturel de Saturne )
[un calcul de E] est de catégorie (metaDom:MD_Procedurale_Procedure)
[un calcul de E] est un ( :Calculer l'énergie )
[un calcul de E] puis exécuter [un calcul de QV]
[un calcul de FG] a pour produit [Force gravitationelle calculée]
[un calcul de FG] est de catégorie (metaDom:MD_Procedurale_Procedure)
[un calcul de FG] est un ( :Calculer la force gravitationnelle )
[un calcul de FG] puis exécuter [un calcul de E]
[un calcul de QV] est de catégorie (metaDom:MD_Procedurale_Procedure)
[un calcul de QV] est un ( :Calculer la quantité de mouvement )
[un satellite quelconque] est de catégorie (metaDom:MD_Declarative_Concept)
[un satellite quelconque] est un ( :Satellite naturel )
Étoile est une sorte de (metaDom:MD_Declarative_Concept)
------------------Résultats après inférence-----------------------
[9.8] est un ( :Accélération en mètre par seconde carrée (G) :Type de connaissances :Connaissance déclarative
:Connaissance d'objet )
[Déimos] est un ( :Satellite naturel de Mars :Type de connaissances :Connaissance déclarative :Connaissance
d'objet :Étoile :Objet celeste :Satellite naturel )
[Force gravitationelle calculée] est le produit de [un calcul de FG]
[Force gravitationelle calculée] est un ( :Force d'attraction gravitationnelle :Type de connaissances
:Connaissance déclarative :Connaissance d'objet )
[Japet] est un ( :Satellite naturel de Saturne :Type de connaissances :Connaissance déclarative :Connaissance
d'objet )
[Mars] est un ( :Planète :Type de connaissances :Connaissance déclarative :Connaissance d'objet :Étoile :Objet
celeste )
[Phobos] est un ( :Satellite naturel de Mars :Type de connaissances :Connaissance déclarative :Connaissance
d'objet :Étoile :Objet celeste :Satellite naturel )
[Rhéa] est un ( :Satellite naturel de Saturne :Type de connaissances :Connaissance déclarative :Connaissance
d'objet )
[Saturne] est un ( :Planète :Type de connaissances :Connaissance déclarative :Connaissance d'objet :Étoile
:Objet celeste )
[Soleil] est un ( :Étoile :Type de connaissances :Connaissance déclarative :Connaissance d'objet )
[Terre] est un ( :Planète :Type de connaissances :Connaissance déclarative :Connaissance d'objet :Étoile :Objet
celeste )
[Titan] est un ( :Satellite naturel de Saturne :Type de connaissances :Connaissance déclarative :Connaissance
d'objet )
[Téthys] est un ( :Satellite naturel de Saturne :Type de connaissances :Connaissance déclarative :Connaissance
d'objet )
[un calcul de E] a pour dépendance [un calcul de FG]
[un calcul de E] est un ( :Calculer l'énergie :Type de connaissances :Connaissance d'actions :Procédure
:Calculer des paramètres physiques )
[un calcul de E] permet [un calcul de QV]
[un calcul de FG] est un ( :Calculer la force gravitationnelle :Type de connaissances :Connaissance d'actions
:Procédure :Calculer des paramètres physiques )
[un calcul de FG] permet [un calcul de E]
[un calcul de FG] permet [un calcul de QV]
[un calcul de QV] a pour dépendance [un calcul de E]
[un calcul de QV] a pour dépendance [un calcul de FG]
[un calcul de QV] est un ( :Calculer la quantité de mouvement :Type de connaissances :Connaissance d'actions
:Procédure :Calculer des paramètres physiques )
[un satellite quelconque] est un ( :Satellite naturel :Type de connaissances :Connaissance déclarative
:Connaissance d'objet :Étoile :Objet celeste )
2.8 En résumé
Dans ce chapitre, nous avons présenté la méthodologie OntoCASE de conception
d'une ontologie à partir d'un modèle semi-formel d’un domaine de connaissances. Les
volets méthodologique, représentationnel et computationnel de cette méthodologie
sont harmonisés afin d’offrir une méthodologie complète et supportée par un assistant
à la formalisation. Cet assistant appuie l'ingénieur dans le déroulement de la méthode
de formalisation et le supporte dans la validation syntaxique et sémantique de
l'ontologie du domaine. L’ontologie de transformation qui fait partie du volet
e) Déduction erronée à cause de
l’inversion du lien
S
f) Déduction d’un prérequis à une
séque
n
ce
Connaissances du domaine déduites
117
représentationnel et computationnel de la méthodologie se compose d’une ontologie
du langage semi-formel, d’une ontologie de référence et d’une ontologie cadre. Un
ensemble de documents qui servent de guides aux différents acteurs complète le volet
représentationnel de la méthodologie. La méthodologie intègre les principes de
consensualité et de formalité propres aux ontologies par l'utilisation de la méthode de
comodélisation pour la production de modèles semi-formels. L’éditeur de modèle
semi-formel eLi permet la conception d’un modèle semi-formel dans un langage
interopérable et utilisable par OntoCASE. Finalement, la méthodologie permet la
formalisation de connaissances déclaratives, procédurales, stratégiques et factuelles.
Le chapitre suivant présente la démarche de recherche qui a permis la construction
d’OntoCASE.
CHAPITRE 3
DÉMARCHE DE CONSTRUCTION D'ONTOCASE
Le présent chapitre décrit la démarche adoptée pour développer OntoCASE. Nous
avons vu dans le chapitre précédent qu'OntoCASE comporte un volet
méthodologique, un volet représentationnel et un volet informatique. De plus, les
composants procéduraux et architecturaux d'OntoCASE y ont été identifiés. La liste
qui suit spécifie les activités et les produits de la démarche de construction
d’OntoCASE:
- Déterminer :
o le contenu de l'ontologie de référence;
o le contenu de l'ontologie du langage semi-formel;
o le contenu de l'ontologie cadre;
o les règles de désambiguïsation;
o les règles de formalisation.
- Développer l'architecture et l’implantation des modules :
o d'édition de modèles semi-formels;
o d'importation;
o de désambiguïsation;
o de formalisation;
o de validation syntaxique;
o de validation sémantique.
- Concevoir :
o le manuel des principes de modélisation;
o le catalogue de désambiguïsation.
119
OntoCASE s’est avéré un produit complexe à développer pour plusieurs raisons.
D'abord, son développement devait être orienté dans la perspective de permettre de
confirmer ou non l'hypothèse de cette thèse. De plus, sa double vocation
méthodologique et informatique imposait un développement intégré et conjoint de ces
deux composants. Spécifiquement associé au volet informatique, le développement de
l'assistant exigait un processus de conception qui implique à la fois un volet déclaratif
(par le développement des ontologies nécessaires à la transformation) et un volet
procédural (par le développement du code nécessaire à l'exécution des éléments
méthodologiques). Les facettes déclarative et procédurale de l'assistant devaient être
développées en parfaite synergie.
Les étapes de la démarche de recherche ont été segmentées en trois phases. La
première phase, la mise en place, a pour objectif de fixer les composants
informatiques en lien avec les composants méthodologiques présentés au chapitre
précédent. La deuxième phase, l'agrégation, permet d'attacher les différents
composants entre eux et de valider les choix architecturaux et théoriques. La
troisième phase, la consolidation, permet de compléter la structure interne des
différentes ontologies agrégées par l'ontologie de transformation. Cette phase assure
aussi la mise en place des outils informatiques nécessaires à la validation
d’OntoCASE par l'implantation de mécanismes d'exécution de scénarios de tests.
Compte tenu des particularités de l'objet de la démarche, nous avons préconisé
l'utilisation d'une approche évolutive et itérative pour la réalisation de la démarche de
recherche. La première étape de la réalisation de cette approche est la généralisation
d'activités pouvant s'appliquer à de multiples phases de la démarche. La figure 3.1
schématise l'approche itérative de la démarche. En son centre, représenté dans la
forme rectangulaire, on retrouve l'objet de la démarche, soit OntoCASE avec ses
composants procéduraux et déclaratifs. Autour d'OntoCASE, figurent les activités
qui, au besoin, sont invoquées pendant les phases de réalisation de la démarche et qui
120
permettent la construction de l'objet de la démarche. Ces activités sont associées à
l’une ou l’autre des trois phases de la recherche que nous allons maintenant décrire.
Trois phases ont ponctué l'évolution de la démarche de construction d’OntoCASE:
- La phase 1, Mise en place des composants architecturaux, procéduraux et
informatiques de la méthodologie a permis d’esquisser la phase initiale de la
démarche. Pendant cette phase, nous esquissons le volet procédural et
architectural de la méthodologie. Concurremment au développement de ces
deux volets, nous avons identifié les technologies et outils informatiques apte
à supporter le développement de l'assistant informatique. À la fin de cette
phase, toutes les incertitudes concernant les aspects technologiques étaient
levées et une première esquisse des éléments architecturaux et procéduraux
était réalisée.
- La phase 2, Agrégation des composants ontologiques, procéduraux et
informatiques d'OntoCASE, a constitué la phase de développement des
modules de l'assistant, de la construction des ontologies liées à la
transformation et de la rédaction du catalogue des ambiguïtés ainsi que de
l'harmonisation de ces constituants avec les aspects procéduraux de la
méthodologie. Cette phase a constitué le cœur de la recherche. C'est pendant
son déroulement que la validité des aspects théoriques a été confirmée.
- La phase 3, Confirmation, a constitué l'étape de la démarche au cours de
laquelle la fonctionnalité d'OntoCASE fut testée et raffinée. Plusieurs modèles
semi-formels, comportant plusieurs cas de modélisation associés à des
sémantiques variées, furent alors soumis à OntoCASE. C'est aussi pendant
cette phase qu’ont été rédigés le document décrivant les éléments pour guider
la modélisation semi-formelle à l’aide de concepts ontologiques
(appendice E).
Figur
e
e
3.1: Objets et
a
a
ctivités de la d
é
é
marche de co
n
n
struction d’On
t
t
oCASE.
121
121
122
3.1 Phase 1: Mise en place des composants représentationnels, procéduraux et
informatique de la méthodologie.
Cette première phase a pour objectif de mettre en place les différentes composantes
de la méthodologie tel qu’indiqué en haut de la figure 3.1. L'élaboration du processus
de formalisation a pour but de déterminer la structure procédurale utilisée dans la
méthodologie pour formaliser une ontologie à partir d'une conceptualisation semi-
formelle. Le choix du langage source et du langage cible détermine le cadre langagier
utilisé par la méthodologie. La détermination du contenu de l'ontologie de référence,
de l'ontologie cadre et de l'ontologie du langage source (par exemple MOT) fixe le
volet représentationnel de la méthodologie. Finalement, le choix de l'environnement
informatique de développement et des outils d'ingénierie aptes à manipuler les
ontologies utilisées permettent de fixer le volet computationnel de la méthodologie.
3.1.1 Élaborer le processus de formalisation de l'ontologie
Tel qu’indiqué à la section 1.7.3 p.71 pour Kendal et Creen (2007) ainsi que pour
Uschold et Gruninger (1996), le développement d’une ontologie se divise en six
étapes : l’étude de faisabilité, l’acquisition de connaissances, la conception,
l’implémentation, la validation et la maintenance. Chez Gómez-Pérez et al (2003), la
méthodologie de développement d’ontologies intègre plusieurs composants de la
gestion de projets. Pour Davies et al (2003), le développement d’ontologies est un
processus instrumentalisé par l’utilisation de composants informatiques spécifiques.
La méthode d’ingénierie ontologique présentée à la figure 1.40 p.72, proposée par
Staab et al. (2001), présente un processus inspiré des méthodes itératives de
développement de logiciels. Dans tous les cas, les étapes importantes du processus de
conception d’une ontologie sont l’élicitation et la formalisation. En référence à ce
processus de développement d'ontologie, OntoCASE concentre ses éléments
méthodologiques sur les étapes de démarrage (Ontology kickoff), de raffinement et
d'évaluation. Pour OntoCASE, nous parlerons plutôt d’étapes centrées sur les
123
méthodes de conception d'un modèle semi-formel, de méthode de formalisation et de
méthode de validation (voir la section 2.7 p.97). La méthode de conception d'un
modèle semi-formel implique un processus de modélisation d'un modèle semi-formel
instrumenté par l'éditeur de modèle semi-formel eLi. La méthode de formalisation,
qui est au cœur de cette recherche, se divise en trois processus: l'importation, la
désambiguïsation et la transformation. L'assistant à la formalisation est l'application
informatique intelligente qui supporte la réalisation de cette étape. Finalement, la
méthode de validation permet d'évaluer la facette syntaxique et sémantique de la
formalisation. Là aussi, un assistant informatique supporte cette méthode.
3.1.2 Choix du langage cible : l'Ontology Web Language
Pour la réalisation de la démarche, nous avons choisi d'utiliser la saveur DL de
l'Ontology Web Language64 (OWL) normalisé par le World Wide Web Consortium
(W3C), en tant que langage cible à la méthodologie de formalisation. Le choix de
OWL-DL versus OWL-Lite ou OWL-Full se justifie, d'une part, par l'expressivité
OWL-DL qui est supérieure à celle OWL-Lite et, d'autre part, par la décidabilité
qu'assure OWL-DL et qui n'est pas nécessairement assurée par OWL-Full. Outre
OWL plusieurs autres formalismes ontologiques sont aussi disponibles (Ontolingua65
, LOOM66, FLogic67 OKBC68, OCML69, etc ). Cependant, notre choix s'est arrêté sur
OWL pour des raisons de standardisation et de grande disponibilité des outils
64 McGuinness et Harmelen, OWL Web Ontology Language Overview http://www.w3.org/TR/owl-features/; Patel-
Schneider, Hayes et Horrocks, OWL Web Ontology Language Semantics and Abstract Syntax
http://www.w3.org/TR/owl-semantics/; W3C OWL, Ontology Web Language: http://www.w3.org/2004/OWL/
65 Ontolingua Home Page: http://www.ksl.stanford.edu/software/ontolingua/
66 Loom Project Home Page: http://www.isi.edu/isd/LOOM/
67 Meštrović et Čubrilo, F-Logic Data and Knowledge Reasoning in the Semantic Web Context
68 Open Knowledge Base Connectivity (OKBC): http://www.ksl.stanford.edu/software/OKBC/
69 Operational Conceptual Modelling Language (OCML): http://technologies.kmi.open.ac.uk/ocml//
124
informatiques (voir la section 3.1.5 p.134) notamment associés au développement du
Web sémantique.
3.1.3 Choix du langage source: le langage de modélisation par objets typés MOT
Issu du domaine de l'ingénierie pédagogique, le langage de modélisation par objets
typés MOT, de degré semi-formel, est celui qui a été utilisé pour développer la
méthodologie proposée. Le langage et le logiciel qui l’implémente (MOTPlus) ont été
conçus par une équipe sous la direction de Paquette (2002b). Une version détaillée du
langage est présentée à l'appendice A de cette thèse. Notons que notre but est de faire
en sorte qu'OntoCASE puisse s’appliquer à d’autres langages semi-formels tels que
ceux utilisés pour les cartes conceptuelles, les réseaux sémantiques ou les
diagrammes UML.
Une caractéristique importante d’un langage semi-formel, est qu'il existe plus d'une
façon de représenter un même objet. C’est ce que nous avons appelé la synonymie
(voir la section 1.1.6 p.16). Une conséquence directe de la synonymie est que pour
une primitive du langage, il existe plusieurs significations possibles. C’est ce que
nous avons appelé la polysémie. Les tableaux qui suivent présentent quelques
situations de synonymies de MOT. De même, le tableau 3.6 présente la polysémie de
MOT.
3.1.3.1 Étude de la synonymie de MOT70
La synonymie d’agrégation intervient lorsque qu’une situation transporte l’idée
d’agglomérat ou de collection d’objets. L’idée d’agrégation peut s’exprimer de
plusieurs façons en langage MOT. Illustré au tableau 3.1, le texte en en-tête du
tableau se représente selon l'un des quatre modèles, soit par une composition selon le
niveau d'abstraction factuelle (voir le tableau 3.1a), soit par le changement de niveau
70 Cette section est extraite de l’appendice E
d
d
s
L
i
l
u
s
l
(
l
r
c
d
’abstractio
n
d
'abstractio
n
s
pécialisati
o
L’élimi
n
Représentations possibles en MOT
a)
c)
L
’exemple
d
i
nstrument.
l
’instrumen
t
u
n agent. S
e
s
ignificatio
n
l
'agent « F
o
(
en b), l’ins
t
l
ien I/P. Da
r
éalise » et
n
c
as.
n
(voir le ta
b
n
conceptu
e
o
n (voir le ta
b
n
ation des d
é
d
u tableau
3
L’instrume
n
t
, qui est rep
r
e
lon la défin
i
n
s possibles
u
r
» régit l
e
t
rument « F
o
n
s ce conte
x
n
on comme
b
leau 3.1b),
e
l (voir le
t
b
leau 3.1d).
Représente
r
é
chets se fa
i
l
3
.2 présente
n
t peut être
u
r
ésenté par
u
i
tion du lan
g
d’un princi
p
e
processus
o
u
r
» est un
x
te, le lien
l'intrant du
soit par l’u
t
ableau 3.1
c
Tableau 3.
r
une agrég
a
i
t de deux fa
ç
’enfouissem
b
d
une situati
o
u
n objet ou
u
n principe,
g
age MOT (
P
p
e (voir le t
a
de «
b
rûle
r
concept qui
I
/P doit êtr
e
processus «
u
tilisation de
c
), ou enco
r
1
a
tion en MO
ç
ons princi
p
ent
b
)
d
)
o
n où un pr
o
une person
n
est considé
r
P
aquette, 2
0
a
bleau 3.6).
r
». Dans l
a
est uni au
p
e
interprété
brûler » co
m
e
la composi
r
e par l’ut
i
O
T
p
ales: l’inci
n
ocessus est
n
e. Dans le
r
é dans ce c
o
0
02b), l’age
n
Dans cette
r
a
deuxième
p
rocessus «
b
par « est-l'i
n
m
me c'est
n
1
tion au niv
e
i
lisation de
n
ération et
réalisé par
premier cas
o
ntexte com
m
n
t est l’une
d
r
eprésentati
o
représentat
i
b
rûle
r
» par
n
strument-q
u
n
ormalemen
t
25
e
au
la
un
a,
m
e
d
es
o
n,
i
on
un
u
i-
t
le
L
L
u
m
v
d
g
(
e
c
g
m
7
l
7
f
7
Représentations possibles en MOT
a)
b
)
L
e tableau
3
L
ors d'une
a
u
ne connai
s
m
odèle (Al
l
v
ue de pro
d
'assurer la
g
uide quan
d
(
Mariot et
a
e
st-ce qu'il
e
c
e que a est
g
énéral de
D
m
odèle con
c
7
1
Nous entendo
n
l
a sémantique d'
u
7
2
Nous entend
o
f
ormel afin de p
r
7
3
L'interprétati
o
Repr
é
Le four (qu
i
Le four est
l
3
.3 présente
a
ctivité de
m
s
sance dépe
l
emang et
H
duire une
o
complétud
e
d
vient le ch
o
a
l., 2008): l
a
e
xiste des i
n
une instan
c
D
?). Si l'on
s
c
eptuel du
t
n
s par complét
u
u
n système.
o
ns par décidab
r
oduire des con
c
o
n formelle du
m
é
senter l'util
i
brûler l
e
i
est un age
n
l
'instrument
un modèle
s
m
odélisation
,
nd des rép
o
H
endler, 20
0
o
ntologie i
n
e
71
et la dé
c
o
ix du nive
a
a
question
d
n
stances de
C
c
e de C?) et
s
e réfère au
t
ableau 3.3
a
u
de la capacité q
u
ilité la propriét
é
c
lusions en un n
o
m
odèle a été réal
i
Tableau 3.
2
i
sation d'un
i
e
s déchets d
a
n
t) régit le p
r
qui réalise
l
s
elon le niv
e
le choix d
u
o
nses qui
s
0
8) surtout,
n
terprétable
c
idabilité
72
d
a
u d'abstract
i
d
e la satisfi
a
C
?); la ques
t
la question
tableau 3.4
a
, on consta
t
u
'un modèle pos
é
que possède
u
o
mbre fini d'op
é
i
sée par le mod
u
2
i
nstrument
e
a
ns un fou
r
r
ocessus de
b
l
e processus
e
au d'abstra
c
u
niveau d'a
b
s
ont attend
u
lorsqu'il s'
a
par un ag
e
d
u modèle,
t
i
on pour re
p
a
bilité (soit
C
t
ion de la v
é
de subsomp
a qui est l'i
n
t
e que tout
e
s
sède à représen
t
u
n modèle à êt
r
é
rations et dans
u
u
le de validation
e
n MOT
br
ûler
de brûle
r
c
tion conce
p
b
straction p
o
u
es par l'int
a
git d'une
m
e
nt cogniti
f
t
rois questi
o
pr
ésenter un
e
C
un conce
p
é
rification d
'
tion (est-ce
n
terprétatio
n
e
s les conna
i
t
er sans contrad
i
r
e interprété pa
r
u
n temps fini.
sémantique d'
O
1
p
tuel et fact
u
o
ur représe
n
erprétation
m
odélisation
f
formel. A
f
o
ns servent
e
connaissa
n
p
t quelconq
u
'
instances (
e
que C est p
l
n
formelle
73
issances et
l
i
ction l'ensembl
e
r
un agent cog
n
O
ntoCASE.
26
u
el.
n
ter
du
en
f
in
de
n
ce
u
e,
e
st-
l
us
du
l
es
e
de
n
itif
r
p
d
é
c
c
r
r
elations y
p
roduite. E
n
d
'une quant
i
é
tabli, cett
e
c
onceptuel.
c
omplétude
r
eprésentati
o
B
rûler les
d
Représentations possibles en MOT
a)
b
)
sont inter
p
n
revanche,
i
té importa
n
e
démonstr
a
Cependant,
que l'on
d
o
n selon le
n
Repré
d
échets … l
a
représentati
représentat
i
p
rétées. Ce
p
le modèle
n
te de nou
v
a
tion n'inv
a
quand on
d
ésire mai
n
n
iveau d'abs
t
senter selon
a
matière or
g
reste des d
é
on de nivea
u
i
on de nivea
u
p
endant, au
c
factuel du
v
elles conna
i
a
lide en ri
e
modélise,
i
n
tenir dans
t
raction adé
q
Tableau 3.
3
le niveau d'
g
anique est
a
é
chets devie
n
u
conceptue
l
u
factuel
c
une déduc
t
tableau 3.3
b
issances (v
o
e
n la mod
é
i
l faut gar
d
le modèle
q
uat.
3
'
abstraction
e
a
lors transf
o
n
t des cendr
e
l
tion autom
a
b
a permis
o
ir le table
a
é
lisation se
l
d
er à l'espr
i
et faire l
e
e
n MOT
o
rmée en ga
z
e
s
1
a
tique n'a
é
la product
i
a
u 3.4 b). C
e
l
on le niv
e
i
t le degré
e
choix de
z
tandis que
27
é
té
i
on
e
ci
e
au
de
la
le
128
Tableau 3.4
Interprétation formelle de la règle brûler des déchets
a) interprétation du niveau conceptuel
----------Début du processus de validation sémantique-------------
Si matière autre qu'organique a pour conclusion transformée en
cendre
Si matière organique a pour conclusion transformée en gaz
bruler les déchets se compose de Si matière autre qu'organique
bruler les déchets se compose de Si matière organique
bruler les déchets se compose de transformée en cendre
bruler les déchets se compose de transformée en gaz
------------------Résultats après inférence-----------------------
b) interprétation du niveau factuel
----------Début du processus de validation sémantique-------------
[Si matière autre qu'organique] a pour conclusion [transformée en
cendre]
[Si matière autre qu'organique] est de catégorie
(metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Si matière organique] a pour conclusion [transformée en gaz]
[bruler les déchets] est un ( :Nom d'une règle )
[bruler les déchets] se compose de [Si matière autre qu'organique]
[bruler les déchets] se compose de [Si matière organique]
[bruler les déchets] se compose de [transformée en cendre]
[bruler les déchets] se compose de [transformée en gaz]
------------------Résultats après inférence-----------------------
[Si matière autre qu'organique] alors [transformée en cendre]
[Si matière autre qu'organique] est une partie de [bruler les
déchets]
[Si matière autre qu'organique] permet [transformée en cendre]
[Si matière organique] alors [transformée en gaz]
[Si matière organique] est une partie de [bruler les déchets]
[Si matière organique] permet [transformée en gaz]
[transformée en cendre] a pour dépendance [Si matière autre
qu'organique]
[transformée en cendre] est la conclusion de [Si matière autre
qu'organique]
[transformée en cendre] est une partie de [bruler les déchets]
[transformée en gaz] a pour dépendance [Si matière organique]
[transformée en gaz] est la conclusion de [Si matière organique]
[transformée en gaz] est une partie de [bruler les déchets]
En langage MOT, l'association d'un attribut à un concept ne fait pas partie des
primitives atomiques de MOT. Il existe tout de même deux façons semi-formelles
pour représenter un attribut. La première, qui est présentée au tableau 3.5 a utilise un
concept associé par un lien C à un concept symbolisant l'attribut. Dans l'exemple
(en a) le concept « coût de la méthode » est un attribut du concept « Méthode
d
c
l
L
r
"
l
3
U
m
s
p
l
d
'incinérati
o
c
omposante
l
'attribut, il
n
L
'exemple
d
r
eprésenter
"
dataType"
p
l
’affectatio
n
L’incinér
a
Représentations possibles en MOT
a)
b
)
3
.1.3.2 Étu
d
U
ne consé
q
m
ultitude d
e
s
ymbole (c
e
p
olysémie
q
l
angage M
O
o
n » alors
q
de la «
M
n
'existe auc
u
d
u tableau
3
un attribut
.
p
ermet de f
a
n
d'un attrib
u
a
tion, qui c
o
attribut par
attribut par
d
e de la poly
s
q
uence très
e
contextes
e
que nou
s
q
ue nous a
v
O
T.
q
ue le conc
M
éthode d'i
n
u
ne manière
3
.5 b prése
.
L'utilisati
o
a
ire une dis
t
u
t à un conc
e
Représe
n
o
mprend un
e
l'utilisation
d
l'utilisation
s
émie de M
O
importante
est qu'il y
s
avons ap
p
v
ons identi
f
ept « Méth
o
n
cinération
»
formelle de
nte une al
t
o
n du prin
c
t
inction clai
r
e
pt.
Tableau 3.
5
n
ter un attri
b
e
méthode d
e
onéreuse
d
'un concep
t
d
'un princip
e
O
T
de l'utilis
a
a surcharg
e
p
elé la
p
o
ly
f
iée pour c
h
o
de de co
m
»
. Dans c
e
distinguer l
a
t
ernative u
n
c
ipe en ta
n
r
e entre la c
5
b
ut en MOT
e
combustio
n
t
lié par un l
e
a
tion d'un
m
e
de la sém
a
ly
sémie). L
e
h
acune des
m
bustion »
s
e
tte façon
d
a
compositi
o
n
peu plus
n
t que pro
p
omposition
n
, est la mét
h
l
ien C
m
ême sym
b
a
ntique sy
m
e
tableau 3.
primitives
1
s
ymbolise
u
d
e représe
n
o
n et l'attrib
u
formelle p
o
p
riété de t
y
de concepts
h
ode la plu
s
b
ole dans
u
m
bolisée par
6 présente
atomiques
29
u
ne
n
ter
u
t.
o
ur
y
pe
s
et
s
u
ne
le
la
du
C
d
s
3
L
s
g
Repr
é
Caonnaissacne abstraite Connaissance factuelle
C
omme no
u
d
ésambiguï
s
s
ymbole qu'
i
3
.1.4 Déter
m
L
a constru
c
s
ystèmes d
e
g
énérique p
o
E
N
é
sentation en
MOT
Connaissance
déclarative
Connaissance
procédurale
Connaissance
stratégique
Connaissance
déclarative
Connaissance
procédurale
Connaissance
stratégique
u
s le verro
n
s
ation est
d
i
l utilise da
n
m
ine
r
les cat
c
tion de l'
o
e
représenta
t
o
ssible, l'an
a
Po
N
TITÉ
Significati
o
Classe
Schéma
C
N
Actio
n
Opérati
o
Agent
Proprié
t
Classe de
r
Classe de co
n
Objet
Valeu
r
Acte
Instructi
o
Individ
u
Asserti
o
Conditi
o
Règle
n
s un peu
p
d
e permettr
e
n
s le modèle
égories de l'
o
ntologie d
e
t
ion. Afin
d
a
lyse doit i
n
Tableau 3.
6
lysémie de
M
o
n (s) R
e
Entier
C
aractère
N
aturel
n
o
n
t
é
r
ègle
n
dition
r
o
n
u
o
n
o
n
p
lus loin da
n
e
à l'utilisat
semi-forme
ontologie d
e
e
référence
d
e construir
e
n
clure l'étud
e
6
M
OT
R
E
e
présentation en
MOT
--C->
Composition
-IP->
Intrant/Produit
--R->
Régulation
--P->
Précédence
--I->
Instance
--S->
Spécialisation
--A->
Application
Icône
englobement
a
ns la thèse
,
t
eur de cho
i
e
l.
e
référence
implique
u
e
une ontol
e
d’un ense
m
E
LATION
Significa
t
Est com
p
A pour a
t
Est l’int
r
A pour p
Est l'instru
m
Rég
i
Puis ex
é
Puis év
a
Per
m
Évaluer à
p
A pour dé
p
A pour i
n
Est une s
o
A pour ap
p
Associatio
n
éléments d’
mod
è
,
le rôle d
u
isir le sens
u
ne analys
e
l
ogie de ré
fé
m
ble de lan
g
1
t
ion (s)
p
osé de
t
tribu
t
r
ant de
rodui
t
m
ent utilisé
i
t
é
cute
r
a
lue
r
m
et
p
artir de
p
endance
n
stance
o
rte de
p
lication
n
avec les
un sous-
è
le
u
processus
approprié
e
de plusie
u
fé
rence la p
l
g
ages serva
n
30
de
au
u
rs
l
us
n
t à
131
représenter des connaissances de type tant déclaratif que procédural et stratégique,
qui sont les trois types de connaissances que l’on retrouve dans tout domaine de
connaissances. Chacun des éléments de vocabulaire doit être étiqueté afin de faciliter
une classification ultérieure dans l'ontologie de référence. La nomenclature des
étiquettes divise le nom de l'étiquette en deux champs délimités par le caractère deux-
points (:). Le premier champ indique le nom du langage concerné et le deuxième
champ indique l'élément du vocabulaire. Ainsi, le lien de composition faisant partie
du vocabulaire du langage MOT serait étiqueté par le libellé suivant 'mot:lienC'.
3.1.4.1 Vocabulaire du langage de MOT
Le langage MOT (Paquette, 2002b p. 73) a pour vocabulaire les éléments présentés
au tableau 3.7. MOT est un langage important en représentation de connaissances, car
la modalité de ce langage permet la représentation de connaissances de type
procédural, déclaratif, stratégique et factuel. De ce fait, la structure de MOT s'impose
d'elle-même en tant que prototype de structure pour la construction de l'ontologie de
référence.
Tableau 3.7
Vocabulaire du langage MOT
Entité Relation
Connaissances
abstraites
Concept (mot:concept) Composition/Composition multiple
(mot:lienC)
Procédure (mot:procedure) Spécialisation (mot:lienS)
Principe (mot:principe) Instanciation (mot:lienI)
Connaissance
factuelle
Exemple (mot:exemple) Application (mot:lienA)
Trace (mot:trace) Régulation (mot:lienR)
Énoncé (mot:enonce) Précédence (mot:lienP)
Intrant/Produit (mot:lienIP)
Englobement (mot:lienE)
3.1.4.2 Vocabulaire du langage UML
Le tableau 3.8, le tableau 3.9 et le tableau 3.10 présentent respectivement le
vocabulaire des diagrammes UML de classes, de cas d'utilisation et du diagramme
d'état.
132
Tableau 3.8
Vocabulaire du diagramme UML de classes (tiré de Rhem, 2006)
Entité Relation
Classe (uml_class:classe) Héritage (uml_class:relHerit)
Attribut (uml_class:attrib) Composition (uml_class:relComp)
Opération (uml_class:oper) Agrégation (uml_class:relAgr)
Interface (uml_class:interface) Association (uml_class:relAss)
Dépendance (uml_class:relDep)
Tableau 3.9
Vocabulaire du diagramme UML de cas d'utilisation (tiré de Rhem, 2006)
Entité Relation
Acteur (uml_cu:acteur) Communication (uni et bi)directionnelle
(uml_cu:relComm)
Cas d'utilisation (uml_cu:cu) Inclusion (uml_cu:relIncl)
Extension (uml_cu:relExt)
Généralisation (uml_cu:relGen)
Tableau 3.10
Vocabulaire du diagramme UML d'état (tiré de Rhem, 2006)
Entité Relation
Action (uml_etat:action) Flux de contrôle (uml_etat:fluxControle)
État (uml_etat:etat) Flux d'objets (uml_etat:fluxObj)
Synchronisation de flux (uml_etat:sync)
État de départ (uml_etat:depart)
État de fin (uml_etat:fin)
Décision (uml_etat:decision)
Objet (uml_etat:objet)
3.1.4.3 Vocabulaire du langage BPMN
Le tableau 3.11 présente le vocabulaire du Business Process Management Notation
(BPMN). Chacune des entités d'un modèle BPMN peut représenter une entité
abstraite ou concrète.
Tableau 3.11
Vocabulaire du diagramme BPMN (tiré de OMG BPDM, 2007 ; Weske, 2007)
Entité Relation
Activité (bpmn:act) Flux de séquence (bpmn:relSeq)
Événement (bpmn:even) Flux de message (bpmn:relMess)
Commutateur [Décision] (bpmn:commut) Association (bpmn:relAss)
Couloir d'activité (bpmn:coul_act) Flux d'événement (bpmn:relEven)
Participant (bpmn:parti)
Artefact (bpmn:arte)
133
3.1.4.4 Classification du vocabulaire des langages dans l'ontologie de référence
Chacun des langages présentés ci-haut possède un vocabulaire qui lui est propre, dont
plusieurs propriétés peuvent être partagées par des éléments de vocabulaire
appartenant à d'autres langages. Cataloguées au tableau 3.12 et au tableau 3.13, les
entités et relations de chacun des langages sont classées dans une ou plusieurs
catégories qui, une fois synthétisés, contribuent à définir l'ontologie de référence.
Tableau 3.12
Classification des entités des divers langages pour chacune des catégories d'entités de
l'ontologie de référence
Catégories des entités de la réalité abstraite Catégories des entités de la réalité concrète
Classe mot:concept;
uml_class:classe;
uml_class:interface;
bpmn:even;
bpmn:coul_act;
bpmn:arité
Objet mot:exemple;
uml_class:classe;
uml_etat:objet;
bpmn:even;
bpmn:coul_act;
bpmn:arité
Schéma mot:concept;
uml_class:attrib
Attribut mot:exemple;
uml_class:attrib
Opération mot:procedure;
uml_class:oper;
uml_cu:cu
Opération mot:trace;
uml_class:oper;
uml_cu:cu;
uml_etat:etat;
uml_etat:sync;
uml_etat:depart;
uml_etat:fin
Procédure mot:procedure;
bpmn:act
Procédure mot:trace;
uml_etat:action;
bpmn:act
Agent mot:principe;
uml_cu:acteur;
bpmn:parti
Agent mot:enonce;
uml_cu:acteur;
bpmn:parti
Condition mot:principe;
bpmn:commut
Condition mot:enonce;
uml_etat:decision;
bpmn:commut
Règle nom mot:principe Règle nom mot:enonce
Règle antécédent mot:principe Règle antécédent mot:enonce
Règle conclusion mot:principe Règle conclusion mot:enonce
Règle non-
décomposée
mot:principe Règle non-
décomposée
mot:enonce
Propriété mot:principe;
uml_class:attrib;
uml_class:relAss;
bpmn:relAss
Assertion mot:enonce
134
Certains éléments de vocabulaire sont catalogués dans plus d'une catégorie. Il s'agit
alors d'éléments comportant une sémantique ambigüe et qui devront subir une
désambiguïsation.
Tableau 3.13
Classification des relations de divers langages pour chacune des catégories de langage
de l'ontologie de référence
Catégorie de relations
Intrant mot:lienIP;
uml_etat:fluxObj;
bpmn:relMess
Produit mot:lienIP;
uml_etat:fluxObj
Précédence mot:lienP;
uml_etat:fluxControle;
bpmn:relSeq;
bpmn:relEven
Agrégation uml_class:relAgr
Composition mot:lienC;
uml_class:relComp
Englobe mot:lienE;
uml_class:relDep;
uml_cu:relIncl
Généralisation uml_class:relHerit;
uml_cu:relGen
Spécialisation mot:lienS
Définit mot:lienA
Instance mot:lienI
Régulation mot:lienR;
uml_cu:relExt
3.1.5 Déterminer la structure de l'ontologie cadre
Tel que déjà mentionné, l'ontologie cadre est l'ontologie qui structure la
représentation des connaissances du domaine. Elle est utilisée en tant que composante
de l'ontologie de transformation pour le processus de transformation. Lors de
l'utilisation de l'ontologie du domaine, l'ontologie cadre est intégrée à l'ontologie du
domaine par importation (owl:imports). Présentée à la figure 3.2a, la taxonomie des
classes correspond à la structure du niveau subjectif de l'ontologie de référence (voir
le tableau 4-1). La figure 3.2b présente la structure hiérarchique des propriétés de
135
l'ontologie cadre. Certaines propriétés sont définies en tant que propriétés inverses.
Par exemple, la propriété EST-LA-PARTIE-DE est définie comme propriété inverse
de A-POUR-COMPOSANT.
a) Taxonomie des classes
b
) Taxonomie des propriétés
Figure 3.2: Représentation taxonomique des classes et propriétés de l'ontologie cadre.
3.1.6 Représenter de manière formelle le vocabulaire de MOT
Grâce à l'ontologie de référence et à l'ontologie cadre, il est alors possible de
représenter de manière formelle le vocabulaire du langage MOT. Ainsi, la
correspondance formelle de la représentation de connaissances déclaratives,
procédurales, stratégiques et mixtes (qui intègre plusieurs types de connaissances) est
respectivement présentée au tableau 3.15, au tableau 3.16, ainsi qu'au tableau 3.17.
136
On retrouve à l'appendice B la référence complète de la représentation formelle du
vocabulaire de MOT ainsi que les règles de désambiguïsation et de conversion
permettant cette formalisation.
3.1.6.1 Représentation formelle de connaissances déclaratives
Le tableau 3.14a présente la représentation formelle d'un mot:Concept. La ligne 01
indique que l'entité est de type owl:class et que son nom est A_0. Chacun des objets du
modèle semi-formel d'origine est représenté de manière unique dans l'ontologie cible.
Ainsi, pour plusieurs objets possédant le même étiquette, le processus de
transformation créera le même nombre de classes dans l'ontologie cible avec chacune
leur nom unique composé d'une première partie par l'étiquette de l'objet et d'une
deuxième partie par un nombre entier unique à l'ontologie cible. Les deux parties sont
séparées par le caractère "_". Pendant la transformation, l'étiquette du mot:Concept est
transposée dans la propriété rdfs:label de la classe cible (voir la ligne 02).
Finalement, la ligne 03 indique que la classe A_0 fait partie de la catégorie déclarative
(metaDom:MD_Declarative_Concept).
Pour la formalisation d'une relation d'instanciation (voir le tableau 3.14b), le
processus de transformation traduit le mot:LienI en rdf:type. De même, la
transformation du mot:LienS est traduit par rdfs:subClassOf (voir le tableau 3.14c ligne
03). Grâce à la propriété de transitivité de rdfs:subClassOf, il n’est pas nécessaire de
déclarer A_4 en tant que sous-classe de metaDom:MD_Declarative_Concept.
a
b
c
d
e
Correspo
n
Représenta
t
MOT
a
)
b
)
c
)
d
)
e
)
n
dance form
t
ion
01.
02.
03.
01.
02.
03.
04.
05.
01.
02.
03.
04.
05.
06.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
elle de repr
é
:
A
_
0 a
r
dfs
:
r
dfs
:
:
A
_
1 a
r
dfs
:
r
dfs
:
m
etaDom:
M
:
a
_
2 a
r
dfs
:
:
A
_
4 a
r
dfs
:
r
dfs
:
:
B
_
3 a
r
dfs
:
r
dfs
:
m
etaDom:
M
:
A
_
5 a
r
dfs
:
r
dfs
:
:
B
_
6 a
r
dfs
:
r
dfs
:
:
A
_
5
_
aPo
u
a
r
dfs
:
r
dfs
:
r
dfs
:
:
A
_
7 a
r
dfs
:
r
dfs
:
:
B
_
8 a
r
dfs
:
r
dfs
:
m
eta
D
:
A
_
7
_
aPo
u
a
r
dfs
:
r
dfs
:
r
dfs
:
r
dfs
:
:_2_9
a
r
dfs
:
Tableau 3.
1
é
sentations
M
Repré
s
owl:Cl
:
label "A"^^
:
subClassOf
owl:Cl
:
label "A"^^
:
subClassOf
M
D
_
Declarati
:A
_
1 ;
:
label "a"^^
owl:Cl
:
label "A"^^
:
subClassOf
owl:Cl
:
label "B"^^
:
subClassOf
M
D
_
Declarati
owl:Cl
:
label "A"^^
:
subClassOf
owl:Cl
:
label "B"^^
:
subClassOf
u
rComposant
_
o
wl:Obje
:
domain :A
_
5
:
range :B
_
6
:
subProperty
owl:Cl
:
label "A"^^
:
subClassOf
o
wl:Cl
:
label "B"^^
:
subClassOf
D
om:MD
_
isStr
u
rAttribut
_
B
owl:Obje
:
domain :A
_
7
:
label "B"^^
:
range :B
_
8
:
subProperty
:B
_
8 ;
:
label "2"^^
1
4
M
OT des co
n
s
entation for
m
ass ;
xsd:string ;
metaDom:MD
_D
ass ;
xsd:string ;
owl:Thing ,
ve
_
Concept .
xsd:string .
ass ;
xsd:string ;
:B
_
3.
ass ;
xsd:string ;
owl:Thing ,
ve
_
Concept .
ass ;
xsd:string ;
metaDom:MD
_D
ass ;
xsd:string ;
metaDom:MD
_D
_
B
_
6
ctProperty ;
;
;
y
Of metaDom:
A
ass ;
xsd:string ;
metaDom:MD
_D
ass ;
xsd:string ;
metaDom:MD
_D
r
ing "2"^^xs
d
B_
8
ctProperty ;
;
xsd:string ;
;
y
Of metaDom:
A
xsd:string .
n
naissances
m
elle
D
eclarative
_C
D
eclarative
_C
D
eclarative
_C
A
-POUR-COMPO
S
D
eclarative
_C
D
eclarative
_S
d
:int .
A
-POUR-ATTRI
B
1
déclarative
s
C
oncept .
C
oncept .
C
oncept .
S
ANT .
C
oncept .
S
chema
_
Int
B
UT .
37
s
138
La relation de composition (mot:LienC) est un premier cas d'ambiguïté de la
sémantique du langage MOT. Le mot:LienC est utilisé: soit pour représenter une
relation d'holonymie74 entre deux connaissances (voir le tableau 3.14d), soit pour
représenter une relation d'attribution (voir le tableau 3.14e). Lorsque désambiguïsé en
holonyme (voir le tableau 3.14e), le mot:LienC est interprété, dans l'ontologie cible, par
une propriété dont le libellé est constitué d'une partie contenant le nom de la
connaissance d'origine, le libellé "aPourComposant", suivi du libellé de la connaissance
cible (voir la ligne 07). Le domaine et l'image de la propriété sont respectivement
attribués à la connaissance source et à la connaissance cible de la relation (voir la
ligne 09 et la ligne 11). La propriété est une sous-propriété de la méta-propriété de
l'ontologie cadre (metaDom:A-POUR-COMPOSANT).
Lorsque la relation de composition est désambiguïsée en attribut (voir le
tableau 3.14f), la propriété d'attribution est classée sous la méta-propriété metaDom:-A-
POUR-ATTRIBUT (voir la ligne 13) et le concept définissant le type de l'attribut75 (entier,
réel, chaîne de caractères) est classé sous la méta-classe associée à son type (voir la
ligne 06). En MOT, la valeur associée à l'attribut est représentée par la relation
d'instanciation entre le concept et l'exemple. La représentation dans l'ontologie cible
est assumée par un individu dont le type correspond à l'attribut.
3.1.6.2 Représentation formelle de connaissances procédurales
La représentation formelle de connaissances procédurales est présentée au
tableau 3.15. En a), on observe que la classe associée à la procédure est une sous-
classe de metaDom:MD_Procedurale_Procedure (voir la ligne 04). La relation
d'instanciation (en b), la relation de spécialisation (en c), et la relation de composition
74 Terme lié à un autre de la même langue par une relation d’holonymie, c’est-à-dire de tout à partie. Un
holonyme A d’un mot B est un mot dont le signifié désigne un ensemble comprenant le signifié de B. Corps est un
holonyme de bras, de même que maison est un holonyme de toit. (extrait de
http://fr.wiktionary.org/wiki/holonyme, récupérée le 15 mars 2010).
75 Aussi appelé schéma dans l'ontologie de référence et l’ontologie cadre.
(
d
c
l
a
b
c
d
e
(
en d) sont
t
d
éclaratives
c
elle-ci est
f
l
a méta-pro
p
Correspo
n
Représenta
t
MOT
a
)
b
)
c
)
d
)
e
)
t
raitées de l
a
.
Pour ce q
u
f
ormalisée p
p
riété
metaDo
m
n
dance form
e
t
ion
01.
02.
03.
04.
01.
02.
03.
04.
05.
06.
07.
01.
02.
03.
04.
05.
06.
07.
08.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
a
même ma
n
u
i est de la
ar la propri
é
m
:PUIS-
E
XECU
T
e
lle de repré
:P1_0
a
r
dfs
:
r
dfs
:
:P1_1
a
r
dfs
:
r
dfs
:
:T1_2
a
r
dfs
:
:P1_5
a
r
dfs
:
r
dfs
:
:P2_6
a
r
dfs
:
r
dfs
:
:P1_5.
:P1_7
a
r
dfs
:
r
dfs
:
:
P1
_
7
_
aP
o
a
r
dfs
:
r
dfs
:
r
dfs
:
:P2_8
a
r
dfs
:
r
dfs
:
:P1_3
a
r
dfs
:
r
dfs
:
:P2_4
a
r
dfs
:
r
dfs
:
:
P1
_
3
_
pu
i
a
r
dfs
:
r
dfs
:
r
dfs
:
n
ière que les
relation de
é
té "
p
uisExec
T
ER
(voir la
l
Tableau 3.
1
sentations
M
Représ
e
owl:Clas
s
:
label "P1"^
^
:
subClassOf
m
owl:Clas
s
:
label "P1"^
^
:
subClassOf
m
:P1
_
1 ;
:
label "T1"^
^
owl:Clas
s
:
label "P1"^
^
:
subClassOf
m
o
wl:Clas
s
:
label "P2"^
^
:
subClassOf
m
owl:Clas
s
:
label "P1"^
^
:
subClassOf
m
o
urComposant
_
owl:Obje
c
:
domain :P1
_7
:
range :P2
_
8
:
subProperty
O
owl:Clas
s
:
label "P2"^
^
:
subClassOf
m
owl:Clas
s
:
label "P1"^
^
:
subClassOf
m
owl:Clas
s
:
label "P2"^
^
:
subClassOf
m
i
sExecuter
_
P
2
owl:Obje
c
:
domain :P1
_3
:
range :P2
_
4
:
subProperty
O
relations as
précédence
uter
" (voir
l
l
igne 10).
1
5
M
OT des co
n
e
ntation form
e
s ;
^xsd:string
metaDom:MD
_P
s ;
^xsd:string
metaDom:MD
_P
^xsd:string
s ;
^xsd:string
metaDom:MD
_P
s ;
^xsd:string
metaDom:MD
_P
s ;
^xsd:string
metaDom:MD
_P
_
P2
_
8
ctProperty ;
_
7 ;
;
Of metaDom:
A
s ;
^xsd:string
metaDom:MD
_P
s ;
^xsd:string
metaDom:MD
_P
s ;
^xsd:string
metaDom:MD
_P
2
_
4
ctProperty ;
_
3 ;
;
Of metaDom:
P
s
sociées aux
e
(voir le t
a
l
a ligne 08)
e
n
naissances
p
e
lle
;
P
rocedurale
_P
;
P
rocedurale
_P
.
;
P
rocedurale
_P
;
P
rocedurale
_P
;
P
rocedurale
_P
A
-POUR-COMPO
S
;
P
roced
u
rale
_P
;
P
rocedurale
_P
;
P
rocedurale
_P
P
UIS-
E
XECUTE
R
1
connaissan
c
a
bleau 3.15
e
t classée s
o
p
rocédu
r
ale
s
P
rocedure.
P
rocedure .
P
rocedure ,
P
rocedure,
P
rocedure.
S
ANT.
P
rocedure.
P
rocedure .
P
rocedure.
R
.
39
c
es
e),
o
us
s
3
R
t
l
d
u
l
R
M
a
b
3
C
i
d
p
r
c
3
.1.6.3 Rep
r
R
eprésenté
t
ableau 3.1
6
l
ien d'insta
n
d
e représen
t
u
tilisée ave
c
l
e tableau 3
.
14).
Correspo
n
R
eprésentatio
n
M
OT
a
)
b
)
3
.1.6.4 Rep
r
C
ertaines r
e
i
ntrant/prod
u
d
éclarative,
p
résente les
r
etrouve e
n
c
onnaissanc
r
ésentation
f
sous la m
é
a) ligne 04,
n
ciation, de
g
t
ation forme
l
c
le princip
e
.
16b ligne
0
n
dance form
n
Repré
01.
02.
03.
04.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
r
ésentation
f
e
lations unis
u
it peut
u
d'où le ter
m
principaux
n
langage
M
e procédura
l
f
ormelle de
c
ta-classe
m
e
le
mot:Princ
i
g
énéralisati
o
l
le que vu p
r
e
se formali
s
9), classée
s
elle de repr
é
sentation for
m
:Pr1_0
r
df:
t
r
dfs
:
r
dfs
:
m
etaDom:
M
:Pr1_3
r
df:
t
r
dfs
:
r
dfs
:
m
etaDom:
M
:Pr2_4
r
df:
t
r
dfs
:
r
dfs
:
m
etaDom:
M
:
Pr1
_
3
_
r
e
r
df:
t
r
d
fs
:
r
dfs
:
r
dfs
:
r
dfs
:
f
ormelle de
c
sent des co
n
u
nir une c
m
e de représ
e
scénarios d
e
M
OT. En
a
l
e à une co
n
c
onnaissanc
e
taDom:MD
_
St
r
i
pe
de type
a
o
n ou de co
m
r
écédemme
n
s
e par la co
n
s
ous la mét
a
Tableau 3.
1
é
sentations
M
m
elle
t
ype owl:Cla
:
label "Pr1"
:
subClassOf
M
D
_
Strategi
q
t
ype owl:Cla
:
label "Pr1"
:
subClassOf
M
D
_
Strategi
q
t
ype owl:Cla
:
label "Pr2"
:
subClassOf
M
D
_
Strategi
q
e
git
_
Pr2
_
4
t
ype owl:Obj
:
domain :Pr1
:
label ""^^x
:
range :Pr2
_
:
subPropert
y
c
onnaissanc
e
n
naissances
onnaissanc
e
e
ntation de
c
e
représenta
t
a
, le
m
ot:Li
n
naissance d
é
e
s stratégiq
u
r
ategique
_
Ag
e
a
gent/norm
e
m
position u
t
n
t. La relati
o
n
struction d
e
a
-propriété
m
1
6
M
OT des co
n
a
ss ;
^^xsd:strin
g
q
ue
_
AgentCon
t
a
ss ;
^^xsd:strin
g
q
ue
_
AgentCon
t
a
ss ;
^^xsd:strin
g
q
ue
_
AgentCon
t
ectProperty
_
3 ;
x
sd:string ;
_
4 ;
y
Of metaDom:
R
e
s mixtes
de type di
v
e
procédur
a
c
onnaissanc
e
t
ion de con
n
i
enIP
est u
n
é
clarative.
F
u
es
e
ntContraint
e
e
/contrainte
u
tilise les m
ê
o
n de régula
t
e
la propriét
m
etaDom:REGI
T
n
naissances
g
;
t
rainteNorme
g
;
t
rainteNorme
g
;
t
rainteNorme
;
R
EGIT .
v
ers. Par ex
e
a
le à une
es mixtes.
L
n
aissances
m
n
e relation
F
ormalisé, le
1
e
Norme
(voir
associé par
ê
mes princi
p
t
ion (
mot:Lie
n
é "
regit
" (v
o
T
(voir la li
g
stratégique
s
.
.
e
mple, un l
i
connaissa
n
L
e tableau 3.
m
ixtes que l
'
qui unit
u
mot:LienIP
q
40
le
un
p
es
n
R
)
o
ir
g
ne
s
i
en
n
ce
.
17
'
on
u
ne
q
ui
u
q
(
p
p
d
é
i
a
b
u
nit
P1
et
C1
q
u'entre
C1
e
(
voir les lig
n
p
arfois ent
r
p
rincipe est
d
'exécution.
é
valuer Pr
1
i
nterprété p
a
Corres
p
Représenta
MOT
a
)
b
)
,
s'interprèt
e
t
P2
, la rel
a
n
es 14 et 1
5
e une proc
é
interprété
c
Le
mot:Lie
n
1
(voir les
a
r: Pr1 puis
e
p
ondance fo
r
tion
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
e par l'éno
n
a
tion
m
ot:Li
e
5
). Pour un
m
é
dure et u
n
c
omme une
n
P
entre
P1
lignes 13
e
e
xécuter P1
r
melle de re
p
. :P1_0
.
r
df
:
.
r
df
s
.
r
df
s
.
:
P1
_
0
_
a
P
.
r
df
:
.
r
df
s
.
r
df
s
.
r
df
s
. :P2_1
.
r
df
:
.
r
df
s
.
r
df
s
.
:
P2
_
1
_
a
P
.
r
df
:
.
r
df
s
.
r
df
s
.
r
df
s
. :P1_0
.
r
df
:
.
r
df
s
.
r
df
s
. :P2_2
.
r
df
:
.
r
df
s
.
r
df
s
. :Pr1_1
.
r
df
:
.
r
df
s
.
r
df
s
.
:
P1
_
0
_
p
u
.
r
df
:
.
r
df
s
.
r
df
s
.
r
df
s
.
:
Pr1
_
1
_p
.
r
df
:
.
r
df
s
.
r
df
s
.
r
df
s
.
r
df
s
n
cé:
P1
prod
u
e
nIP
s'interp
m
odèle pro
c
n
principe (
v
condition à
et
Pr1
est
f
e
t 17); alor
s
(voir les lig
Tableau 3.
1
p
résentatio
n
Repré
s
:
type owl:Cl
a
s
:label "P1"
^
s
:subClassOf
P
ourProduit
_C
:
type owl:Ob
j
s
:domain :P1
_
s
:range :C1
_2
s
:subPropert
y
:
type owl:Cl
a
s
:label "P2"
^
s
:subClassOf
P
ourIntrant
_C
:
type owl:Ob
j
s
:domain :P2
_
s
:range :C1
_2
s
:subPropert
y
:
type owl:Cl
a
s
:label "P1"
^
s
:subClassOf
:
type owl:Cl
a
s
:label "P2"
^
s
:subClassOf
:
type owl:Cl
a
s
:label "Pr1
"
s
:subClassOf
u
isEvalu
e
r
_
P
r
:
type owl:Ob
j
s
:domain :P1
_
s
:range :Pr1
_
s
:subPropert
y
p
uisExecuter
_
:
type owl:Ob
j
s
:domain :Pr
1
s
:label ""^^
x
s
:range :P2
_2
s
:subPropert
y
u
it
C1
(voir
l
p
rète par l'é
n
c
édural, le l
i
v
oir tablea
u
résoudre a
v
f
ormelleme
n
s
qu'entre
P
g
nes 18 et 23
1
7
n
s MOT des
s
entation for
m
ass ;
^^xsd:strin
g
metaDom:MD
_
_
C1
_
2
jectPropert
y
_
0 ;
_
2 ;
yOf metaDom:
ass ;
^^xsd:strin
g
metaDom:MD
_
_
C1
_
2
jectPropert
y
_
1 ;
_
2 ;
yOf metaDom:
ass ;
^^xsd:strin
g
metaDom:MD
_
ass ;
^^xsd:strin
g
metaDom:MD
_
ass ;
"^^xsd:stri
n
metaDom:MD
_
r1
_
1
jectPropert
y
_
0 ;
_
1 ;
yOf metaDom:
_
P2
_
2
jectPropert
y
1
_
1 ;
xsd:string ;
_
2 ;
yOf metaDom:
l
es lignes 0
5
n
oncé
P2
a
p
i
en de préc
é
u
3.17b). D
a
v
ant de pou
r
n
t interprét
é
r1
et
P2
, l
e
3
).
connaissan
c
m
elle
g
;
_
Procedurale
_
y
;
A-POUR-PROD
U
g
;
_
Procedurale
_
y
;
A-POUR-INTR
A
g
;
_
Procedurale
_
g
;
_
Procedurale
_
n
g ;
_
Strategique
_
y
;
PUIS-
E
VALUE
R
y
;
PUIS-
E
XECUT
E
1
5
et 09). Al
o
p
our intrant
é
dence s'util
i
a
ns ce cas,
r
suivre le f
l
é
par: P1 p
u
e
mot:LienP
e
c
es mixtes
_
Procedure.
U
IT
_
Procedure.
A
NT
_
Procedure .
_
Procedure.
_
Condition .
R
.
E
R .
41
o
rs
C1
i
se
le
l
ux
u
is
e
st
L
(
a
b
c
A
m
r
L
a relation
m
(
voir le tabl
e
Corres
p
a
)
b
)
c
)
A
u tablea
u
m
etaDom:MD
_
S
t
r
eliée à la
o
w
m
ot:LienR
s'
u
e
au 3.18).
p
ondance fo
r
01
02
03
04
05
06
07
08
09
10
11
12
13
01
02
03
04
05
06
07
08
09
10
11
12
13
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
u
3.18 a, l
e
t
rategique
_
A
g
w
l:Class
pro
c
u
tilise aussi
a
r
melle de re
p
associées
p
. :Pr1_0
.
r
.
r
.
r
m
etaDo
m
. :C1_1
.
r
.
r
.
r
m
etaDo
m
.
:
Pr1
_
0
_
.
r
.
r
.
r
.
r
. :P1_1
.
r
.
r
.
r
o
wl:Th
i
. :Pr1_0
.
r
.
r
.
r
m
etaDo
m
.
:
Pr1
_
0
_
.
r
.
r
.
r
.
r
. :C1_6
.
r
df
:
.
r
df
s
.
r
df
s
. :C2_19
.
r
df
:
.
r
df
s
.
r
df
s
. :Pr1_7
.
r
df
:
.
r
df
s
.
r
df
s
.
:
C1
_
6
_
P
r
.
r
df
:
.
r
df
s
.
r
df
s
.
r
df
s
.
r
df
s
e
mot:Princ
i
g
entContrain
c
édurale
P1
a
vec une co
n
Tableau 3.
1
p
résentatio
n
p
ar un lien
d
r
df:type owl
:
r
dfs:label "
P
r
dfs:subClas
s
m
:MD
_
Strateg
i
r
df:type owl
:
r
dfs:label "
C
r
dfs:subClas
s
m
:MD
_
Declara
t
_
regit
_
C1
_
1
r
df:type owl
:
r
dfs:domain
:
r
dfs:range :
C
r
dfs:subProp
e
r
df:type owl
:
r
dfs:label "
P
r
dfs:subClas
s
i
ng .
r
df:type owl
:
r
dfs:label "
P
r
dfs:subClas
s
m
:MD
_
Strateg
i
_
regit
_
P1
_
1
r
df:type owl
:
r
dfs:domain
:
r
dfs:range :
P
r
dfs:subProp
e
:
type owl:Cl
a
s
:label "C1"
^
s
:subClassOf
:
type owl:Cl
a
s
:label "C2"
^
s
:subClassOf
:
type owl:Ob
j
s
:label "Pr1
"
s
:
subPropert
y
r
1
_
7
_
C2
_
19
:
type owl:Ob
j
s
:domain :C1
_
s
:label "Pr1
"
s
:range :C2
_1
s
:subPropert
y
i
pe
est fo
r
teNorme
(voi
et à la
o
wl:
C
n
naissance
d
1
8
n
s MOT des
d
e régulatio
n
:
Class ;
P
r1"^^xsd:st
r
s
Of owl:Thin
g
i
que
_
AgentCo
n
:
Class ;
C
1"^^xsd:str
i
s
Of owl:Thin
g
t
ive
_
Concept
:
ObjectPrope
r
:
Pr1
_
0 ;
C
1
_
1 ;
e
rtyOf metaD
o
:
Class ;
P
1"^^xsd:str
i
s
Of metaDom:
M
:
Class ;
P
r1"^^xsd:st
r
s
Of owl:Thin
g
i
que
_
AgentCo
n
:
ObjectPrope
r
:
Pr1
_
0 ;
P
1
_
1 ;
e
rtyOf metaD
o
ass ;
^^xsd:strin
g
metaDom:MD
_
ass ;
^^xsd:strin
g
metaDom:MD
_
jectPropert
y
"^^xsd:stri
n
yOf metaDom:
jectPropert
y
_
6 ;
"^^xsd:stri
n
_
19 ;
yOf :Pr1
_
7 .
r
malisé en
i
r la ligne 0
4
C
lass
déclar
a
d
éclarative
o
connaissan
c
n
r
ing ;
g
,
n
trainteNorm
e
i
ng ;
g
,
.
r
ty ;
o
m:REGIT
i
ng ;
M
D
_
Procedura
l
r
ing ;
g
,
n
trainteNorm
e
r
ty ;
o
m:REGIT .
g
;
_
Declarative
_
g
;
_
Declarative
_
y
;
n
g ;
MD
_
PROPRIET
E
y
;
n
g ;
une
owl:C
l
4
). Cette
ow
l
a
tive
C1
par
l
1
o
u procédur
a
c
es mixtes
e
.
l
e
_
Procedure
e
.
_
Concept .
_
Concept .
E
.
lass
de t
y
l
:Class Pr1
e
l
a propriété
42
a
le
,
y
pe
e
st
de
143
régulation régit (voir la ligne 13). En c, la situation est totalement différente. Le
positionnement du mot:Principe entre deux mot:Concept réunis par des relations de
régulation s'interprète par la formalisation du mot:Principe en une représentation
owl:ObjectProperty (voir la ligne 09), qui elle-même est une sous-propriété de la méta-
propriété metaDom:MD_PROPRIETE (voir la ligne 12) dont l’utilité est de regrouper les
propriétés du domaine. À la propriété Pr1_7, une sous-propriété (C1_6_Pr1_7_C2_19)
associée à la description de la situation est formalisée (voir la ligne 13). Cette
formalisation assure la spécificité de la représentation par la définition du domaine
(voir la ligne 15) et de l'image (voir la ligne 17) correspondant au mot:Concept
d'origine et de destination.
Le tableau 3.19 et le tableau 3.20 présentent un scénario d'utilisation du mot:LienC et
du mot:LienP en relation avec des mot:Principe et mot:Procedure qui permet la
représentation de règles. Au tableau 3.19, le mot:Principe Pr1 est formalisé en
Regle_Nom (voir la ligne 04), alors que les mot:Principe Pr2 et Pr3 sont formalisés en
Antécédent (voir les lignes 08 et 12). Pour sa part, Pr4 est formalisé en Conclusion (voir
la ligne 16). Chacun des mot:LienC est formalisé en propriété aPourComposant (voir les
lignes 22, 28 et 34). Quant au lien de précédence mot:LienP, il est formalisé d'une part,
en propriété estAntécédentDe pour le mot:LienP entre Pr2 et Pr3 (voir la ligne 40) et
d'autre part, en propriété aPourConclusion pour le mot:LienP entre Pr3 et Pr4 (voir la
ligne 46). En langage naturel, la règle représentée au tableau 3.19 s'interprète de la
façon suivante: la règle du nom Pr1 a pour antécédent Pr2 et Pr3; et pour conclusion
Pr476.
76 Dans cette représentation, nous avons déterminé de manière arbitraire que le dernier élément de la chaîne de
principes est une conclusion. Au besoin, Pr3 pourrait aussi représenter une conclusion.
L
p
e
Correspon
d
01. :Pr
1
02.
03.
04.
05. :Pr
2
06.
07.
08.
09. :Pr
3
10.
11.
12.
13. :Pr
4
14.
15.
16.
17. :Pr
1
18.
19.
20.
21.
22.
23. :Pr
1
24.
25.
26.
27.
28.
29. :Pr
1
30.
31.
32.
33.
34.
35. :Pr
2
36.
37.
38.
39.
40.
41. :Pr
3
42.
43.
44.
45.
46.
L
e traiteme
p
récédente
à
e
st représe
n
d
ance forme
l
form
a
1_
0
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
2_
1
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
3_
2
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
4_
3
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:label
"
rdfs:range
:
rdfs:subPro
p
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:label
"
rdfs:range
:
rdfs:subPro
p
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:label
"
rdfs:range
:
rdfs:subPro
p
2_
1
_
estAntec
e
rdf:type ow
l
rdfs:domain
rdfs:label
"
rdfs:range
:
rdfs:subPro
p
3_
2
_
aPourCon
c
rdf:type ow
l
rdfs:domain
rdfs:label
"
rdfs:range
:
rdfs:subPro
p
n
t de la re
p
à
l'exceptio
n
n
té par u
n
l
le de repré
s
a
tion d'une
r
l
:Class ;
"
Pr1"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
Pr2"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
Pr3"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
Pr4"^^xsd:s
s
sOf metaDo
m
p
osant
_
Pr2
_
1
l
:ObjectProp
:Pr1
_
0 ;
"
"^^xsd:stri
:
Pr2
_
1 ;
p
ertyOf meta
p
osant
_
Pr3
_
2
l
:ObjectProp
:Pr1
_
0 ;
"
"^^xsd:stri
:
Pr3
_
2 ;
p
ertyOf meta
p
osant
_
Pr4
_
3
l
:ObjectProp
:Pr1
_
0 ;
"
"^^xsd:stri
:
Pr4
_
3 ;
p
ertyOf meta
e
dentDe
_
Pr3
_
l
:ObjectProp
:Pr2
_
1 ;
"
"^^xsd:stri
:
Pr3
_
2 ;
p
ertyOf meta
c
lusion
_
Pr4
_
l
:ObjectProp
:Pr3
_
2 ;
"
"^^xsd:stri
:
Pr4
_
3 ;
p
ertyOf meta
p
résentatio
n
n
du traitem
e
n
e connaiss
Tableau 3.
1
s
entations
M
r
ègle produi
s
tring ;
:MD
_
Strategi
tring ;
:MD
_
Strategi
tring ;
:MD
_
Strategi
tring ;
:MD
_
Strategi
erty ;
ng ;
Dom:A-POUR-
C
erty ;
ng ;
Dom:A-POUR-
C
erty ;
ng ;
Dom:A-POUR-
C
_
2
erty ;
ng ;
Dom:EST-
A
NTE
_
3
erty ;
ng ;
Dom:A-POUR-
C
n
de la règ
l
e
nt de la re
p
ance procé
1
9
M
OT des con
n
s
ant une co
n
i
que
_
Entite
_R
i
que
_
Entite
_R
i
que
_
Entite
_R
i
que
_
Entite
_R
C
OMPOSANT .
C
OMPOSANT .
C
OMPOSANT .
E
CEDENT-DE .
C
ONCLUSION .
l
e du table
a
p
résentation
durale qui
n
aissances
m
n
clusion
R
egle
_
Nom .
R
egle
_
Antece
d
R
egle
_
Antece
d
R
egle
_
Conclu
s
a
u 3.20 dif
fè
du résultat.
est interp
r
1
m
ixtes pour
l
d
ent.
d
ent .
s
ion .
fè
re peu de
Ici, le résu
l
r
étée en t
a
44
l
a
la
l
tat
a
nt
q
p
4
n
7
q
q
u'opé
r
atio
n
p
ropriété "
A
l
4
1). En lan
g
n
om Pr1: si
Correspon
d
01. :Pr
1
02.
03.
04.
05. :Pr
2
06.
07.
08.
09. :Pr
3
10.
11.
12.
13. :P1
_
14.
15.
16.
17. :Pr
1
18.
19.
20.
21.
22. :Pr
1
23.
24.
25.
26.
27. :Pr
1
28.
29.
30.
31.
32. :Pr
2
33.
34.
35.
36.
37. :Pr
3
38.
39.
40.
41.
7
7
Ici encore, le
q
ue conclusion
d
n
77
(voir la
l
ors
" (voir l
a
g
age naturel
,
Pr2 et Pr3,
d
ance forme
l
formation
d
1_
0
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
2_
1
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
3_
2
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
_
3
rdf:type ow
l
rdfs:label
"
rdfs:subCla
s
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:range
:
rdfs:subPro
p
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:range
:
rdfs:subPro
p
1_
0
_
aPourCom
p
rdf:type ow
l
rdfs:domain
rdfs:range
:
rdfs:subPro
p
2_
1
_
estAntec
e
rdf:type ow
l
rdfs:domain
rdfs:range
:
rdfs:subPro
p
3_
2
_
alors
_
P1
_
rdf:type ow
l
rdfs:domain
rdfs:range
:
rdfs:subPro
p
terme opératio
n
d
'une règle de la
ligne 16).
L
a
ligne 37)
s
,
la représe
n
alors P1.
l
le de repré
s
d
'une règle r
é
l
:Class ;
"
Pr1"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
Pr2"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
Pr3"^^xsd:s
s
sOf metaDo
m
l
:Class ;
"
P1"^^xsd:st
s
sOf owl:Thi
p
osant
_
P1
_
3
l
:ObjectProp
:Pr1
_
0 ;
:
P1
_
3 ;
p
ertyOf meta
p
osant
_
Pr2
_
1
l
:ObjectProp
:Pr1
_
0 ;
:
Pr2
_
1 ;
p
ertyOf meta
p
osant
_
Pr3
_
2
l
:ObjectProp
:Pr1
_
0 ;
:
Pr3
_
2 ;
p
ertyOf meta
e
dentDe
_
Pr3
_
l
:ObjectProp
:Pr2
_
1 ;
:
Pr3
_
2 ;
p
ertyOf meta
_
3
l
:ObjectPr
o
p
:Pr3
_
2 ;
:
P1
_
3 ;
p
ertyOf meta
n
a été arbitrair
e
procédure qui
e
L
e
m
ot:Lien
P
s
ous la mét
a
n
tation de c
e
Tableau 3.
2
s
entations
M
é
sultant de l'
tring ;
:MD
_
Strategi
tring ;
:MD
_
Strategi
tring ;
:MD
_
Strategi
ring ;
ng , metaDo
m
erty ;
Dom:A-POUR-
C
erty ;
Dom:A-POUR-
C
erty ;
Dom:A-POUR-
C
_
2
erty ;
Dom:EST-
A
NTE
erty ;
Dom:ALORS .
e
ment choisi po
u
e
st exécutée dan
s
P
qui unit
P
a
-propriété
m
e
tte règle s'i
n
2
0
M
OT des con
n
'
exécution d
'
i
que
_
Entite
_R
i
que
_
Entite
_R
i
que
_
Entite
_R
m
:MD
_
Procedu
r
C
OMPOSANT .
C
OMPOSANT .
C
OMPOSANT .
E
CEDENT-DE .
u
r distinguer la
s
une séquence
d
P
r3
et
P1
es
t
m
etaDom:ALOR
S
n
terprète ai
n
n
aissances
m
'
une opérati
o
R
egle
_
Nom.
R
egle
_
Antece
d
R
egle
_
Antece
d
r
ale
_
Operati
o
procédure qui
e
d
e procédures.
1
t
formalisé
S
(voir la li
g
n
si: la règle
m
ixtes pour
l
o
n
d
ent
d
ent .
o
n.
e
st exécutée en
t
45
en
g
ne
du
l
a
t
ant
146
3.1.7 Choix de l'environnement informatique
Le volet informatique est une composante importante d'OntoCASE. Pour le
développement de l'assistant informatique, nous avons choisi l'environnement de
développement Eclipse78 qui intègre plusieurs outils à base de développement conduit
par les modèles tels que: l'Eclipse Modeling Framework (EMF79) pour la gestion de
la pérennisation des données et le Graphical Modeling Framework (GMF80) pour la
conception d'éditeurs graphiques.
3.1.7.1 Environnement Eclipse
Plusieurs applications concernant le Web sémantique sont développées avec la
plateforme Eclipse, notamment: Protégé 4.081, TopBraid Composer82, NeOn Toolkit83
et Eclipse Ontology Definition Metamodel (EODM) Workbench84.
Eclipse est une fondation à source ouverte, parrainée par IBM, qui regroupe un
ensemble d'acteurs segmentant leurs activités en projets. Un projet majeur d'Eclipse
est la conception d'environnements de développement d'applications écrites en
langage java, C, C++, Python, PHP, etc. L'architecture d'Eclipse est construite sur le
concept de plug-in. Le plug-in est un module greffé à un noyau. Le plug-in est conçu
pour accomplir une tâche de manière autonome ou en collaboration avec d'autres
plug-in. Le noyau d'Eclipse est une implémentation d'Equinox compatible avec la
78 The Eclipse Foundation, The Eclipse home page: http://www.eclipse.org/
79 Eclipse Modeling Framework Project (EMF): http://www.eclipse.org/modeling/emf/
80 Eclipse Graphical Modeling Framework (GMF): http://www.eclipse.org/modeling/gmf
81 Protégé Home Site, Welcome to protégé: http://protege.stanford.edu/
82 TopQuadrant, TopBraid Composer (TM): http://www.topquadrant.com/products/TB_Composer.html
83 NeOn project, Neon toolkit: http://neon-toolkit.org/wiki/Main_Page
84 IBM, IBM Integrated Ontology Development Toolkit: An ontology toolkit for storage, manipulation, query, and
inference of ontologies and corresponding instances.: http://www.alphaworks.ibm.com/tech/semanticstk
147
standardisation OSGi. À sa base, l'environnement de développement d'Eclipse est
divisé en trois couches (Gamma et Beck, 2003), soit la couche plateforme qui fournit
un accès de base aux fonctionnalités du noyau, la couche Java Development Tools
(JDT) qui intègre les fonctionnalités d'édition et d'exécution d'applications Java et la
couche Plug-in Development Environment (PDE) qui est une extension du JDT
dédiée au développement de Plug-In. Comme nous l'avons dit plus haut, la couche
plateforme offre des services de base au développeur.
L'architecture de ces services est divisée en une catégorie noyau et une catégorie
interface utilisateur (IU). La catégorie noyau comporte un composant runtime qui
définit l'infrastructure des plug-in et en gère l'instanciation au démarrage de
l'application. L'espace de travail (workspace) est aussi un composant du noyau.
L'espace de travail est un gestionnaire de haut niveau qui permet la gestion de projet.
Un projet est un objet Eclipse qui contient des fichiers et des dossiers et qui est
synchronisé avec le système de gestion de fichiers du système d'exploitation hôte.
Quant à la catégorie IU, elle comporte trois composants, soit le plan de travail
(workbench), le JFace et le Standard Widget Toolkit (SWT). Le SWT fournit les
éléments graphiques de base pour la construction de fenêtres. Le JFace fournit des
éléments graphiques de plus haut niveau dans lesquels sont implantées des
utilisations standardisées. Finalement, le plan de travail fournit les éléments
graphiques associés aux paradigmes de l'environnement Eclipse. Il offre les
primitives nécessaires à la gestion de perspectives, de vues et d'éditeurs. Les ouvrages
suivants sont particulièrement instructifs pour le développement de plug-in:
(Clayberg et Ribel, 2006 ; Daum, 2004 ; Gamma et Beck, 2003 ; McAffer et
Lemieux, 2006).
3
B
M
g
f
t
i
e
c
d
s
d
m
p
c
g
l
F
c
8
3
.1.7.2 Ecli
p
B
asé sur l'
a
M
odeling F
r
g
énération
a
f
ormat
X
M
L
t
ransformat
i
i
nterfaces n
é
e
xprimée d
a
c
ode d'élé
m
d
es projets
d
s
chématisat
i
d
'un éditeur
m
odèle UM
p
artir du m
o
c
ode sourc
e
g
énération
d
l
es outils de
F
igure 3.3:
M
c
onceptuali
s
8
5
OMG MDA,
O
p
se Modelin
g
a
rchitecture
r
amework (
E
a
utomatique
L
Metadata
I
i
on du mod
é
cessaires
à
a
ns le modè
l
ents graphi
q
d
'envergure
i
on détaillé
e
de modèle
L qui sert d
'
o
dèle ecore
q
e
Java néc
d
es modèles
génération
d
M
odèle pro
c
s
ation.
O
MG Model Dr
i
g
Framewo
r
conduite p
a
E
MF) (Stei
n
de code à
p
I
nterchang
e
èle en cod
e
à
la manipu
l
l
e. Les utili
t
q
ues essenti
e
d'Eclipse e
t
e
à la figure
UML (Ex:
'
intrant au p
r
q
ue le proc
e
essaire à l
a
ecore et le
d
'EMF.
c
édural EM
F
i
ven Architectu
r
r
k
a
r les modè
l
n
berg et al.,
2
p
artir de m
o
e
(XMI), l'E
M
e
source Ja
v
l
ation de d
o
t
aires assure
e
l à la mani
t
il sert de
b
3.3 indique
Rational R
o
r
ocessus de
e
ssus de gé
n
a
manipula
t
processus
d
F
de produc
t
r
e: http://www.o
m
l
es (OMG-
M
2
008) est u
n
o
dèles. À p
a
M
F fournit
v
a. Le cod
e
o
nnées dans
e
nt aussi la
g
i
pulation de
s
b
ase à de n
o
qu'à partir
o
se®), il est
génération
d
n
ération du
c
t
ion des d
o
d
e génératio
n
t
ion de code
mg.org/mda/
M
DA
85
), le
n
projet Ecli
p
a
rtir d'un m
o
les outils n
é
e
Java gén
é
le respect
d
g
énération
a
s
données.
L
o
mbreux aut
r
d'une conc
e
t
possible d
e
d
'un modèl
e
c
ode Java p
e
o
nnées. Le
n du code
s
source Jav
a
1
projet Ecli
p
p
se
b
asé su
r
o
dèle ecore
é
cessaires à
é
ré fournit
l
d
e la struct
u
a
utomatique
L
'EMF est l
'
r
es projets.
e
ptualisatio
n
e
concevoir
e
ecore. C'e
s
e
ut produir
e
processus
s
ource utilis
e
a
à partir d'
u
48
p
se
r
la
de
la
l
es
u
re
de
'
un
La
n
et
un
s
t à
e
le
de
e
nt
u
ne
149
L'EMF est à la base du mécanisme de pérennisation des données de l'éditeur de
modèles semi-formels, que nous appelons eLi. À partir d'une version UML du
métamodèle de MOT présenté à la section 3.1.3 p.124, nous avons généré le modèle
ecore (voir la figure 3.4) qui est à la base du code source Java de la couche de
pérennisation d'eLi.
Figure
86
Bien q
u
p
rimitive
s
3.4: Modèle ec
o
u
'eLi permette la rep
r
s
.
o
re de la struct
u
r
ésentation d'objets e
u
re de donnée d'
e
t de liens non-typés
a
e
Li pour la mo
d
a
insi que la composi
t
d
élisation en la
n
t
ion multiple (lienC
m
n
gage MOT
86
.
m
), notre travail ne c
o
o
nsidère pas le traite
m
150
m
ent de ces
150
151
3.1.7.3 Graphical Modeling Framework
Aussi basé sur l'architecture conduite par le modèle, le Graphical Modeling
Framework (GMF) (Gronback, 2008) fournit les composants nécessaires à la
construction d'éditeurs graphiques et schématiques à partir de modèles. Le GMF
intègre les fonctionnalités d'EMF et offre une représentation schématisée des données
contenues dans les documents XMI produits par EMF. Extrait du Tutoriel GMF87, la
figure 3.5 présente le processus de construction d'un éditeur conçu avec le GMF.
Cinq fichiers modèles sont nécessaires à la production du code Java pour l'utilisation
de GMF. Le modèle du domaine (fichier ecore) est produit par le processus EMF. La
définition des composants graphiques, ellipse, rectangle, polygone, etc, est modélisée
dans le fichier gmfgraph. La définition des outils, des actions à réaliser dans l'éditeur
à venir, est modélisée dans le fichier gmftool. L'étape de développement des
correspondances (mapping) entre le modèle du domaine, le modèle de définition
graphique et le modèle de définition des outils est représentée dans le fichier gmfmap.
Pour le générateur de code Java, le dernier fichier, le gmfgen, est le modèle complet
de la définition de l'éditeur.
Le GMF est utilisé dans cette thèse pour la conception de l'éditeur de modèles semi-
formels MOT (eLi). Cette plateforme de conception d'environnement graphique est
une composante importante de la méthodologie puisqu'elle offre les fonctionnalités
nécessaires au développement rapide et standardisé d'applications graphiques.
87 GMF Tutorial: http://wiki.eclipse.org/index.php/GMF_Tutorial
152
Figure 3.5: Processus de construction d'un éditeur graphique GMF. (Tirée du GMF Tutorial 2009d)
153
3.1.8 Choix des outils informatiques associés à l'édition des ontologies
La réalisation des ontologies et de la base de règles qui les accompagnent nécessite
l'utilisation d'outils d'édition permettant leur manipulation. Spécifiquement, les
éditeurs sélectionnés doivent être en mesure d'éditer les ontologies de langage OWL
et SWRL. De plus, une représentation Java de l'ontologie OWL doit être générable.
3.1.8.1 Éditeurs d’ontologies OWL
Protégé88 est une application de l'Université de Stanford qui est régie par la
convention de codes sources libres. Protégé est dédié à l'édition d'ontologies et il
offre une plateforme de développement de systèmes à base de connaissances.
Plusieurs composants de l'application OntoCASE sont construits à partir de Protégé.
Le Protégé-OWL API programmers guide89 est un constituant important du Protégé
Programming Development Kit (PDK)90 pour le développement d'applications Java
intégrant la manipulation d'ontologies. Le Protégé-OWL API fournit les classes et les
méthodes qui permettent la manipulation de fichiers OWL/RDFS. De plus, cette API
(Application Programming Interface) fournit les interfaces nécessaires à l'appel de
requêtes de recherche, à la manipulation de datamodel et assure l'appel à des
raisonneurs à base de logique de descriptions et à base de règles. Le code source de
cette API est facilement encapsulable dans un plug-in Eclipse afin de construire un
environnement autonome et indépendant dans l'éditeur de Protégé. De même, le
Protégé-OWL Reasoner API91 offre un ensemble d'interfaces permettant d'interagir
88 Protégé Home Site, Welcome to protégé: http://protege.stanford.edu/
89 protégé-owl api programmer's guide: http://protege.stanford.edu/plugins/owl/api/guide.html
90 Protégé Programming Development Kit (PDK): http://protege.stanford.edu/doc/dev.html
91 using the protégé-owl reasoner api: http://protege.stanford.edu/plugins/owl/api/ReasonerAPIExamples.html
154
avec les principaux moteurs d'inférences (Racer92, Fact93, Fact++94, Pellet95)
compatibles avec la logique de descriptions et le langage OWL.
TopBraid Composer ™96 (TBC) est un éditeur d’ontologie OWL disponible en trois
versions : la version gratuite, la version standard et la version Maestro. TBC est un
outil de modélisation graphique d'ontologies OWL. Il comprend principalement un
éditeur de classes, de propriétés, d'individus et de règles SWRL. TBC permet aussi
l'édition d'ontologies dans le formalisme N3, RDF/XML, N-TRIPLE, TURLE ainsi
qu'en représentation graphique UML. Il facilite le développement de multiples
ontologies par la synchronisation inter-ontologies des données ce qui est une
fonctionnalité importante en développement d’ontologies. De plus, TBC intègre les
principaux moteurs d’inférences disponibles. La version TBC standard est utilisée
pendant les différentes phases de la démarche de cette recherche puisqu’elle s’intègre
parfaitement à un environnement Eclipse déjà établi. Quant à la version gratuite, nous
avons intégré ses plug-ins à l'application OntoCASE fournissant ainsi un éditeur
d'ontologies à notre méthodologie.
3.1.8.2 Semantic Web Rule Language
Le Semantic Web Rule Language (SWRL)97 qui, au moment d’écrire ces lignes, en
est à l'étape de proposition auprès du W3C, est le langage proposé ici pour supporter
le paradigme à base de règles pour les ontologies OWL. L'éditeur SWRL de Protégé
92 Renamed Abox and Concept Expression Reasoner (RACER): http://www.sts.tu-harburg.de/~r.f.moeller/racer/
93 Horrocks, The FaCT System: The FaCT System
94 Horrocks, FaCT++: http://owl.man.ac.uk/factplusplus/
95 Pellet: The Open Source OWL Reasoner: http://clarkparsia.com/pellet
96 TopQuadrant, TopBraid Composer (TM): http://www.topquadrant.com/products/TB_Composer.html
97 Horrocks, Boley, Tabet, Grosof et Dean, SWRL: A Semantic Web Rule Language Combining OWL and RuleML:
http://www.w3.org/Submission/SWRL/
155
(SWRLTab98) est un environnement complet de développement de systèmes à base
de règles SWRL. En plus d'offrir un éditeur de règles, Protégé offre un API complet
de développement d'applications Java (Golbreich et Imai, 2004 ; Mei et Paslaru, 2005
; O'Connor et al., 2008a ; O'Connor et al., 2008b ; O’Connor et al., 2005a ; O’Connor
et al., 2005b). Du point de vue du moteur d'inférences SWRL, Protégé utilise le
langage à base de règles Jess99(Golbreich et Imai, 2004 ; O’Connor et al., 2005b).
Deux interfaces du SWRLTab retiendront particulièrement notre attention: le SWRL
Factory100 et le SWRL Built-in Bridge101. Le SWRL Factory fournit une API Java de
haut niveau qui permet la création et la modification de règles SWRL à l'intérieur
d'une ontologie. Le SWRL Built-in Bridge est un mécanisme permettant l'implantation
Java de prédicats SWRL Built-in102 utilisateurs. Cet environnement jouera un rôle
important dans la conception du module de transformation du modèle semi-formel en
ontologie du domaine (voir la section 3.2.4.2). TBC possède aussi un éditeur de
règles SWRL. Beaucoup moins sophistiqué que celui de Protégé, l'éditeur de TBC ne
permet pas l'intégration de Built-in commands. En revanche, TBC utilise le moteur
d'inférence Pellet.
3.2 Phase 2: Agrégation des composants ontologiques, procéduraux et informatiques
d'OntoCASE
Au sein de la démarche de recherche, la phase 2 est l'étape de construction des objets
de la recherche. La conception de l'assistant informatique servira de fil conducteur à
la construction de l'ontologie de transformation ainsi que de ses composants et à la
consolidation des éléments procéduraux de la méthodologie. Schématisée à la
98 O'Connor, SWRLTab: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab
99 Jess: the Rule Engine for the Java Platform: http://www.jessrules.com/jess/index.shtml
100 O'Connor, SWRL Factory FAQ: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLFactoryFAQ
101 O'Connor, SWRLBuilt In Bridge: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge
102 Horrocks, Patel-Schneider, Boley, Tabet, Grosof et Dean, SWRL Section 8. Built-Ins:
http://www.daml.org/rules/proposal/builtins.html
f
s
c
f
d
a
d
c
l
F
D
c
i
L
l
l
f
d
a
f
igure 3.6, l
'
s
e décomp
o
c
ommunica
t
f
ormel ou
d
d
'assurer la
a
ssociés au
t
d
e modèles.
c
ommunica
t
l
'utilisateur.
F
igure 3.6:
L
D
ans ce mo
d
c
onformém
e
i
nformatiqu
e
L
a figure 3.
7
l
es méthod
e
l
e module
d
f
ormalisatio
n
d
e fichiers
M
a
ssociés au
'
architectur
e
o
se en qu
a
t
ion. L'éditi
o
d
'une ontolo
g
traduction
d
t
raitement, i
Finalement
,
t
ion de l'inf
o
L
es compos
a
d
èle, nous a
v
e
nt au lang
a
e
s qui régis
s
7
présente
l
e
s de la mét
h
d
'édition eLi
n
utilise le
M
OT+. Le
p
traitement
e
de la plate
f
a
tre thème
s
o
n concerne
g
ie. Les mo
d
es modèle
s
l
s ont pour
f
,
les modul
e
o
rmation en
t
a
nts de l'app
v
ons représ
e
a
ge MOT,
c
s
ent les dive
r
l
es modules
h
odologie.
L
.
Le proces
s
module d'i
m
p
rocessus de
et à l'édit
i
f
orme de s
u
s
: l'édition,
les module
s
dules assoc
i
s
d'une nota
t
f
onction de
r
e
s associés à
t
re les diffé
r
lication Ont
e
nté les mo
d
c
es module
s
r
ses procéd
u
de l'applic
a
L
a méthode
s
us d'import
a
m
portation
X
désambigu
ï
i
on. Pour
l
u
pport à la
f
l'importat
i
s
dédiés à l'
é
i
és à la co
n
a
tion à une
a
r
éaliser la tr
a
la commun
i
r
ents modul
e
t
oCASE.
d
ules sous f
o
s
sont consi
u
res de la m
é
a
tion OntoC
A
de modélis
a
ation qui fa
i
X
MI/OWL o
u
ï
sation néce
s
l
’édition, e
L
f
ormalisatio
n
i
on, le tra
édition d'un
n
version ont
a
utre. Quan
t
a
nsformatio
n
i
cation serv
e
e
s ou entre
l
o
rme de pri
n
i
dérés com
m
é
thodologie.
A
SE mis e
n
a
tion semi-
f
it partie de
u
le modul
e
s
site des m
o
L
i et TBC
1
n
d'OntoCA
S
itement et
n
modèle se
m
pour fonct
i
t
aux modu
l
n
des éléme
n
e
nt à assure
r
l
es modules
n
cipes puisq
u
m
e des acte
u
n
relation a
v
f
ormelle util
i
la méthode
e
d'importat
i
o
dules qui s
o
permettent
56
S
E
la
m
i-
i
on
l
es
n
ts
r
la
et
u
e,
u
rs
v
ec
i
se
de
i
on
o
nt
la
p
s
r
a
c
F
L
l
l
p
l
d
d
q
c
g
p
résentatio
n
s
olliciter d'
é
r
esponsable
a
xiomatiqu
e
c
ommunica
t
F
igure 3.7:
R
L
a figure 3.
8
l
a
m
oitié su
p
l
a vue en g
r
p
résente un
l
'ingénieur
d
ésambiguï
s
d
éclenchem
e
q
u'une con
s
c
alepin des
g
auche, l'ut
i
n
des infor
m
é
ventuelles i
du traite
m
e
et à base
t
ion avec le
s
R
elations en
t
8
présente l'
p
érieure, o
n
aphe de co
m
tableau de
de lancer
s
er et con
v
e
nt du proc
e
ole de co
m
messages
d
i
lisateur a a
c
m
ations de
m
ntervention
s
m
ent des a
m
de règles
S
s
erveur We
b
t
re les mod
u
interface ut
i
n
trouve le s
c
m
posites en
p
bor
d
(sous
les proces
v
ertir) et
e
ssus. Une
m
mandes ex
é
d
'erreurs so
c
cès à des
u
m
anière se
m
s
de l'utilisa
t
m
biguïtés, s
e
S
WRL, qui
,
b
pour la pu
b
u
les de l'app
l
i
lisateur de
l
c
héma du
m
p
résente la
t
forme d’u
n
sus nécess
a
d'éditer au
vue permet
t
é
cutées, un
v
nt aussi ac
c
u
tilitaires tel
m
i-formelle
e
t
eur. Le mo
e
compose
,
eux-mêm
e
b
lication de
s
l
ication et l
e
l
'application
m
odèle semi
-
t
axonomie.
L
n
graphe d
e
a
ires à la
u
besoin c
h
t
ant le cont
r
v
olet des p
r
cessibles.
D
l
s qu'un cal
e
e
t ontologi
q
dule de dés
a
des modul
e
e
s, utilisent
s
ontologies.
e
s méthodes
OntoCAS
E
-
formel, alo
r
L
a moitié i
n
e
processus
)
formalisat
i
h
aque mo
d
r
ôle de la
v
r
opriétés d
e
D
ans la sec
t
e
pin de tâch
1
q
ue en vue
a
mbiguïsati
o
e
s d’infére
n
le module
d'OntoCAS
E
E
. Au centre
r
s qu'à gauc
h
n
férieure dr
o
)
permettan
t
i
on (impor
t
d
èle après
v
alidation ai
n
e
s objets et
t
ion inférie
u
es à faire,
u
57
de
o
n,
n
ce
de
E
.
de
h
e,
o
ite
t
à
t
er,
le
n
si
un
u
re
u
ne
158
structure SVN103 pour le contrôle de version des ontologies, une vue de manipulation
du serveur Web ainsi qu'une vue de structure facilitant la navigation dans de grands
modèles.
Figure 3.8: Interface utilisateur de l'application OntoCASE.
3.2.1 Développement du module d'édition
L'édition est assurée par deux modules, le module d'édition de modèles semi-formels
(eLi) et le module d'édition d'ontologies OWL (TopBraid Composer ™) qui
constituent l'instrumentation de la méthode de modélisation. TopBraid Composer ™
103 SubVersion, version control system, http://subversion.tigris.org/
f
s
à
s
l
a
b
c
D
s
f
ree edition
s
pécifiques
à
à
eLi, il s'
a
s
ection 3.1
l
'applicatio
n
Représenta
t
a
) modèle en
M
b
) modèle en
X
01. <?x
m
02. <mo
t
xml
n
xml
n
03. <co
n
04. <co
n
All
e
05. <re
l
tar
g
06. <re
l
tar
g
07. </c
o
08. <co
n
09. </m
o
c
) modèle en
O
01. @pr
e
02. @pr
e
03. @pr
e
<ht
t
04. @pr
e
05. @pr
e
06. @pr
e
07. @pr
e
08. @pr
e
09. @pr
e
10. @pr
e
11. <ht
t
12. owl
:
13. :Ba
h
14.
15. :Be
r
16.
17.
18. :Ch
i
19.
20.
D
e l'exemp
l
s
chéma en
a
est une a
p
à
l'édition d
'
a
git d'une a
p
.7.3). Le t
n
OntoCAS
E
t
ion MOT,
X
M
OT
X
MI
m
l version="
1
t
:ModeleMot
x
n
s:xsi="http
:
n
s:mot="www.
c
n
naissances
x
n
naissances
x
e
mand
_
1">
l
ations xsi:
t
g
et="//@conn
a
l
ations xsi:
t
g
et="//@conn
a
o
nnaissances
>
n
naissances
x
o
t:ModeleMot
>
O
WL-N3
e
fix :
e
fix rdfs:
e
fix metaDom
:
t
p://localho
s
e
fix swrl:
e
fix protege
:
e
fix xsp:
e
fix owl:
e
fix xsd:
e
fix swrlb:
e
fix rdf:
t
p://localho
s
:
imports <ht
t
h
ia_0 a :B
e
rdfs:label
"
r
ger-Alleman
d
rdfs:label
"
rdfs:subCla
s
i
en_2 a ow
l
rdfs:label
"
rdfs:subCla
s
l
e de la co
n
a
en représe
n
p
plication E
c
'
ontologies
p
p
plication d
e
ableau 3.21
E
.
X
MI et OW
L
s
1
.0" encodin
x
mi:version=
:
//www.w3.or
c
otechnoe.co
x
si:type=
"
mo
x
si:type=
"
mo
t
ype=
"
mot:Li
a
issances.2"
t
ype=
"
mot:Li
a
issances.0"
>
x
si:type=
"
mo
>
<http://lo
<http://ww
:
s
t/Ontologie
<http://ww
:
<
h
ttp://p
<http://ww
<http://ww
<http://ww
<http://ww
<http://ww
s
t/Ontologie
t
p://localho
e
rger-Allema
"
Bahia"^^xsd
d
_1
a
owl:
"
Berger Alle
s
sOf :Chien
_
l
:Class ;
"
Chien"^^xsd
s
sOf owl:Thi
n
ceptualisat
i
n
te le modè
l
c
lipse d'où
p
our les inté
e
type EM
F
présente
t
Tableau 3.
2
L
-N3 de
B
ah
s
orte de Chi
e
g="UTF-8"?>
"2.0" xmlns:
g/2001/XMLSc
m/mot">
t:Exemple"
n
t:Concept"
n
enS"
s
ource
=
/>
enI"
s
ource
=
/>
t:Concept"
n
c
a
lhost/Onto
w.w3.org/200
s/OntoCASE/o
w.w3.org/200
rotege.stan
f
w.owl-
o
ntolo
w.w3.org/200
w.w3.org/200
w.w3.org/200
w.w3.org/199
s/bahia.owl
>
st/Ontologie
nd_1 ;
:string .
Class ;
mand"^^xsd:s
_
2 .
:string ;
ng
,
metaDo
m
i
on Le Chi
e
l
e en langa
g
il est poss
i
grer à l'app
l
F
-GMF (voi
r
t
rois représ
2
1
h
ia est un Be
e
n.
xmi="http:/
/
c
hema-
i
nstan
c
n
om="Bahia"
i
n
om="Berger
A
=
"//@connais
s
=
"//@connais
s
n
om="Chien"
i
o
logies/bahi
a
0/01/rdf-
s
c
h
o
ntocasemeta
m
3/11/swrl#>
f
ord.edu/plu
g
o
gies.com/20
0
2/07/owl#> .
1/XMLSchema
#
3/11/swrlb#
>
9
9/02/22-rdf
-
>
a
owl:On
t
e
s/OntoCASE/
o
s
tring ;
m
:MD
_
Declara
t
e
n Bahia es
t
g
e MOT, al
o
i
ble d'extrai
r
l
ication Ont
o
r
la section
entations s
u
e
rger Allem
a
/
www.omg.org
/
c
e"
i
d="Bahia
_
0"
/
A
llemand" id
=
s
ances.1"
s
ances.1"
i
d="Chien
_
2"
/
a
.owl#> .
h
ema#> .
m
odele.owl#>
.
g
ins/owl/pro
t
0
5/08/07/xsp
.
#
> .
>
.
-
syntax-ns#>
t
ology ;
o
ntocasemeta
m
t
ive
_
Concept
t un Berge
r
o
rs que b et
1
re les Plug
-
o
CASE. Qu
a
3.1.7.2 et
u
pportées
p
a
nd qui est u
n
/
XMI"
/
>
=
"Berger-
/
>
.
t
ege#> .
.
owl#> .
.
m
odele.owl>
.
.
r
Allemand,
c représent
e
59
-
in
a
nt
la
p
ar
n
e
.
le
e
nt
160
respectivement le modèle dans le formalisme XMI et OWL-N3. Au tableau 3.21b, on
remarque que chacun des éléments du modèle présenté en a est traduit par un énoncé
dans le fichier XMI (voir les lignes 03 à 08). Ainsi, cinq énoncés XMI sont
nécessaires pour représenter les deux concepts (Chien et Berger Allemand), l'exemple
(Bahia) ainsi que le mot:LienS et le mot:LienI. L'ontologie de c contient les énoncés
formalisés. On y retrouve les deux classes Chien et Berger Allemand (voir les lignes
15 et 18). L'exemple Bahia et le mot:LienI sont transformés en individu (voir la ligne
23) dont le type est Berger Allemand (voir la ligne 24). Quant au mot:LienS, il est
transformé en énoncé rdfs:subClassOf (voir la ligne 29).
3.2.2 Développement du module d'importation
Les processus de formalisation et de validation sont réalisés dans l'espace de
modélisation OWL alors que l'édition est réalisée dans un autre espace de
modélisation (l’espace de modélisation XMI). Le premier processus de la
formalisation est le processus d'importation (voir la figure 2.9, p.101). Le programme
Eli2OWL.java104 est celui qui importe le modèle de format XMI pour produire un
modèle dans le format OWL, dont le processus de conception est schématisé à la
figure 3.9. La première étape est la génération du code Java de l'ontologie du langage
MOT en utilisant le générateur de code de Protégé (2009h). L'intrant de cette étape
est l'ontologie du langage semi-formel MOT qui est détaillée au tableau 3.22. L'étape
suivante est la génération du code Java correspondant au modèle EMF de MOT en
conformité avec le processus EMF détaillé à la section 3.1.7.2 p. 148.
La programmation du module d'importation qui produit le programme Eli2OWL.java,
utilise en intrant le code java de l'ontologie de MOT et le code java du modèle EMF
de MOT. Le programme réalise la traduction un à un des éléments et des relations de
104 Le détail du code d’Eli2OWL.java est présenté à la section 1 de l’appendice F
f
e
F
L
l
m
e
d
M
r
c
m
L
i
m
(
d
f
ormalisme
X
e
t sa corres
p
F
igure 3.9:
P
L
e tableau
3
l
'ontologie
d
m
étamodèl
e
e
t
MOT
_
conn
D
d
estination
M
OT
_
estLaSou
r
r
elations qu
i
c
ommence
m
ot:LienR
,
n
L
’attribut b
o
i
nforme l’as
m
odèle. S
i
(
metaMot:MOT
_
d
ésactivé p
o
X
M
I
vers l
e
p
ondance O
W
P
rocessus d
e
3
.22a et b
d
u vocabulai
de MOT te
l
D
estination
d'un lien (
v
r
ce
et
MOT
_
e
s
i
les pointe
n
par
MOT_lr
(
n
otamment
d
o
oléen
meta
M
sistant à la
d
i
l’utilisat
e
_
estNonDeter
m
o
ur cet élém
e
e
formalism
e
W
L au table
a
e
conceptio
n
présente la
re de MOT.
l
que défini
servent à
v
oir en c,
l
s
tLaDestinat
i
n
t (voir en
c
(
…) sont
s
d
ans le cas
M
ot:MOT
_
estN
o
d
ésambiguïs
e
ur désam
b
m
ine
=
fal
s
e
nt.
e
OWL (voi
a
u 3.22c).
n
du progra
m
structure
d
La taxono
m
à la section
faire réfé
r
l
es lignes
2
i
on
, sont util
, les lignes
s
pécifiquem
e
où le
m
ot
:
o
nDetermine
(
ation à savo
b
iguïse pr
é
s
e
), alors l’
i
r la représe
n
m
me Eli2O
W
d
étaillée de
s
m
ie des class
2.4 p.86. L
e
r
ence aux
2
2 et 23).
L
l
isées par le
s
10 et 16).
L
e
nt dédiées
:
Principe
e
s
(
voir c lign
e
o
ir s’il doit
d
é
alablement
assistant à
n
tation
X
M
I
W
L.java.
s
classes et
es présenté
e
e
s propriétés
connaissan
c
L
eurs propr
i
s
entités po
u
L
es propriét
é
s
à la ma
n
s
t formalisé
e
5) est un
d
ésambiguïs
e
l’élément
la désambi
1
I
tableau 3.2
propriétés
e
en a reflèt
e
MOT
_
connSou
r
c
es source
i
étés invers
u
r identifier
l
é
s dont le n
o
n
ipulation
d
en propri
é
indicateur
q
e
r l’élément
du mod
è
guïsation s
e
61
1b
de
e
le
r
ce
et
es,
l
es
o
m
d
es
é
té.
q
ui
du
è
le
e
ra
162
Tableau 3.22
Ontologie cadre (OWL) du vocabulaire de MOT [a) et b)], et exemple d'importation
en OWL-N3 d'un modèle MOT-XMI [c)]
a) c)
01. :Bahia_0
02. rdf:type metaMot:MOT_Exemple ;
03. metaMot:MOT_estLaDestination
04. :LienI_Berger-Allemand_1_Bahia_0 ;
05. metaMot:MOT_estNonDetermine "true"^^xsd:boolean ;
06. metaMot:MOT_etiquette "Bahia"^^xsd:string ;
07. metaMot:MOT_nomConnaissance "Bahia_0"^^xsd:string
.
08. :Berger-Allemand_1
09. rdf:type metaMot:MOT_Concept ;
10. metaMot:MOT_estLaSource :LienS_Berger-
Allemand_1_Chien_2 , :LienI_Berger-
Allemand_1_Bahia_0 ;
11. metaMot:MOT_estNonDetermine "true"^^xsd:boolean ;
12. metaMot:MOT_etiquette "Berger
Allemand"^^xsd:string;
13. metaMot:MOT_nomConnaissance "Berger-
Allemand_1"^^xsd:string .
14. :Chien_2
15. rdf:type metaMot:MOT_Concept ;
16. metaMot:MOT_estLaDestination :LienS_Berger-
Allemand_1_Chien_2 ;
17. metaMot:MOT_estNonDetermine "true"^^xsd:boolean ;
18. metaMot:MOT_etiquette "Chien"^^xsd:string ;
19. metaMot:MOT_nomConnaissance "Chien_2"^^xsd:string
.
20. :LienI_Berger-Allemand_1_Bahia_0
21. rdf:type metaMot:MOT_LienI ;
22. metaMot:MOT_connDestination :Bahia_0 ;
23. metaMot:MOT_connSource :Berger-Allemand_1 ;
24. metaMot:MOT_estNonDetermine "true"^^xsd:boolean ;
25. metaMot:MOT_nomLien "LienI_Berger-
Allemand_1_Bahia_0"^^xsd:string .
26. :LienS_Berger-Allemand_1_Chien_2
27. rdf:type metaMot:MOT_LienS ;
28. metaMot:MOT_connDestination :Chien_2 ;
29. metaMot:MOT_connSource :Berger-Allemand_1 ;
30. metaMot:MOT_estNonDetermine "true"^^xsd:boolean ;
31. metaMot:MOT_nomLien "LienS_Berger-
Allemand_1_Chien_2"^^xsd:string .
b)
3.2.3 Développement du module de traitement
Le traitement concerne les modules responsables de la manipulation de l'information,
soit la désambiguïsation du modèle semi-formel en modèle semi-formel
désambiguïsé, la conversion du modèle semi-formel désambiguïsé en ontologie du
domaine et la validation syntaxique et sémantique de l'ontologie du domaine. Les
t
d
3
L
c
l
r
a
l
d
l
d
F
3
L
l
1
t
rois sectio
n
d
e ces mod
u
3
.2.4 Dével
o
L
e process
u
c
onsiste en
l
’élaboratio
n
r
affinement
a
insi que la
l
'appendice
d
e ces cinq
l
a concepti
o
d
ont les co
m
F
igure 3.10:
3
.2.4.1 Ont
o
L
e dévelop
p
l
’ontologie
d
1
05
Représentée
p
n
s suivantes
p
u
les.
o
ppement d
u
u
s de conc
ep
: la créati
o
n
du catalog
u
de l'ontolo
g
réalisation
F.3) et top
o
artéfacts est
o
n de ce mo
d
m
posants de
l
Modèle du
o
logie de tra
i
p
ement des
b
d
e traiteme
n
p
ar les liens P e
n
p
résentent l
e
u
module de
ep
tion du m
o
n du prog
u
e de la sé
m
g
ie de référe
n
des bases
d
o
logique (vo
interrelié a
u
d
ule impliq
u
l
'ontologie
d
processus d
e
i
tement des
b
ases de rè
g
n
t des ambi
g
n
tre chacun de s
o
e
modèle pr
o
désambigu
ï
odule de d
é
ramme
R
eg
l
m
antique for
m
n
ce et de l'
o
d
e règles à l
ir l'appendi
c
u
développe
m
u
e un dével
o
d
e transform
a
e
conceptio
n
ambiguïtés
g
les de dés
a
g
uïtés sont
d
o
us-processus.
o
cédural de
ï
sation
é
sambiguïs
a
l
esDesamb.ja
v
m
elle de M
O
o
ntologie du
l
a désambig
u
c
e F.4). Le
ment des q
u
o
ppement d
e
ation sont l
e
n
du module
et règles de
a
mbiguïsati
o
d
eux proces
s
développe
m
a
tion (voir
l
v
a
(voir ap
p
O
T (voir l’a
p
traitement
d
u
ïsation typ
développe
m
u
atre autres;
e
type itérat
i
e
centre.
e
de désamb
i
désambigu
ï
o
n et le dév
e
s
us intrinsè
q
1
m
ent de cha
c
l
a figure 3.
1
p
endice F.
2
p
pendice B)
,
d
es ambiguï
t
ologique (v
o
m
ent de cha
c
c'est pourq
u
i
f et évoluti
f
i
guïsation.
ï
sation
e
loppement
q
uement reli
63
c
un
1
0)
2
.),
,
le
t
és
o
ir
c
un
u
oi
f
105
de
és.
164
Présentée de manière partielle au tableau 3.23 et de manière complète à l'appendice
F.11, l'ontologie du traitement des ambiguïtés (TA) est une composante de
l’ontologie de transformation. Le rôle de cette ontologie est d’offrir une structure de
classification des éléments du modèle semi-formel pour l’étape de désambiguïsation
assurée par les bases de règles de désambiguïsation. La structure de classes de
l’ontologie du traitement des ambiguïtés (voir la classe TA_Modele du tableau 3.23a)
englobe deux classes. La classe contenant la liste des ambiguïtés
(TA_ListeDesAmbiguites) est le contenant des éléments du modèle semi-formel qui
n’auront pas été désambiguïsés et qui seront identifiés par l’application de la
restriction représentée en b. Une action de l’expert de contenu sera nécessaire pour
désambiguïser les éléments du modèle semi-formel contenus dans cette classe. Quant
à la classe des types d'entités (TA_TypesDentites), elle regroupe un ensemble de classes
représentant les différentes entités semi-formelles du langage MOT. Les individus
associés à ces classes (voir le tableau 3.23c) représentent les interprétations possibles
de chacune des entités semi-formelles telles que définies au tableau des catégories
des entités du modèle de référence (voir le tableau 2.3 et le tableau 2.6 p.89).
Chacune des entités du modèle semi-formel est associée, par une règle de
désambiguïsation, à l'un de ces éléments par la propriété ot:OT_EntiteEstDeType de
l'ontologie de transformation (voir l'exemple de la ligne 17 du tableau 3.24). Dans ce
cas précis, le Principe ?p est désambiguïsé en Propriété, le Concept à la source
?connSrc et le Concept à la destination ?connDest sont désambiguïsés en
Concept_Classe, et finalement, les LienR qui relient les Concepts au Principe sont
désambiguïsés en Relation_Regulation.
165
Tableau 3.23
Structure de l'ontologie de traitement des ambiguïtés
a)
c)
b)
oAmbig:TA_ListeDesAmbiguites
owl:equivalentClass
[ a owl:Restriction ;
owl:hasValue oAmbig:ENTITE_AMBIGUE ;
owl:onProperty :OT_EntiteEstDeType
].
d)
Les propriétés, de l’ontologie de traitement des ambiguïtés, présentées en d
(TA_estNonDetermine(_type,_topo)) sont respectivement des owl:DatatypeProperty de type
booléen qui déterminent le type de désambiguïsation réalisé sur l'entité semi-
formelle. TA_etiquette et TA_identifiant permettant d'assigner des valeurs d'appellation
sur l'entité semi-formelle.
166
En ce qui concerne les règles de désambiguïsation typologique et topologique, les
appendices F.3 et F.4 présentent l'ensemble des règles utilisées par OntoCASE pour
réaliser la désambiguïsation. À titre d'exemple, le tableau 3.24 présente la règle de
désambiguïsation topologique de même que son interprétation associée à la
désambiguïsation d'un principe entre deux concepts (voir le scénario présenté au
tableau 3.18c, p. 142).
Tableau 3.24
Règle de désambiguïsation topologique dans le cas d’un principe lié par lien R d’un
concept (domaine) à un autre (codomaine)
a) Règle de désambigüisation
01. #Rule-08-a_desamb_Principe_entre_concept
02. metaMot:MOT_Principe(?p) ^
03. metaMot:MOT_lrEstLaSource(?p, ?lrSrc) ^
04. metaMot:MOT_lrEstLaDestination(?p, ?lrDest) ^
05. metaMot:MOT_lrConnSrc(?lrDest, ?connSrc) ^
06. metaMot:MOT_lrConnDest(?lrSrc, ?connDest) ^
07. metaMot:MOT_LienR(?lrSrc) ^
08. metaMot:MOT_LienR(?lrDest) ^
09. metaMot:MOT_Concept(?connSrc) ^
10. metaMot:MOT_Concept(?connDest) ^
11. metaMot:MOT_nomConnaissance(?connSrc, ?nomSrc) ^
12. metaMot:MOT_nomConnaissance(?p, ?nomProp) ^
13. metaMot:MOT_nomConnaissance(?connDest, ?nomDest)
14. oAmbig:TA_estNonDetermine(?p, true) ^
15. oAmbig:TA_estNonDetermine(?connSrc, true) ^
16. oAmbig:TA_estNonDetermine(?connDest, true) ^
ot:OT_EntiteEstDeType(?p, oAmbig:Propriete) ^
17. ot:OT_EntiteEstDeType(?connSrc, oAmbig:Concept_Classe) ^
18. ot:OT_EntiteEstDeType(?connDest, oAmbig:Concept_Classe) ^
19. ot:OT_EntiteEstDeType(?lrSrc, oAmbig:Relation_Regulation) ^
20. ot:OT_EntiteEstDeType(?lrDest, oAmbig:Relation_Regulation) ^
21. oAmbig:TA_estNonDetermine_topo(?p, false) ^
22. oAmbig:TA_estNonDetermine_topo(?connSrc, false) ^
23. oAmbig:TA_estNonDetermine_topo(?connDest, false) ^
24. oAmbig:TA_estNonDetermine_topo(?lrSrc, false) ^
25. oAmbig:TA_estNonDetermine_topo(?lrDest, false) ^
26. swrlbi:invoker("printf", "OBJET(%s) -R-> PROPRIETE(%s) -R-> OBJET(%s) )",
?nomSrc, ?nomProp, ?nomDest)
b) interprétation
Le nom de la règle est représenté à la ligne 1. Les lignes 2 à 13 représentent le
scénario topologique déclenchant l'exécution de la règle. Elles indiquent que le
scénario consiste en un principe ?p qui est la source et la destination de lienR et
que les connaissances aux extrémités de ces liens sont des concepts. Les lignes 14,
15 et 16 assurent que les entités concernées par l'exécution de cette règle n'ont pas
été préalablement déterminées par l'utilisateur. Les lignes 17 à 20 déterminent le
type de chacune des entités impliquées dans le scénario, soit une propriété entre
deux classes. Les lignes 21 à 25 spécifient que les entités du scénario ont été
désambiguïsées de manière topologique. Finalement, la ligne 26 envoie un message
au gestionnaire d'impression à la console.
167
3.2.4.2 Gestion de la désambiguïsation
L'objectif de la conception du module de désambiguïsation est de produire une
application informatique intelligente dont les inférences, orientées vers la
désambiguïsation, sont guidées par l'ontologie de désambiguïsation. Le contrôle des
éléments d'entrées/sorties de l'application intelligente, ainsi que l'ordre de
déclenchement des inférences, sont régis par le module ReglesDesamb.java, dont le
code complet est présenté à l'appendice F.2. ReglesDesamb.java importe la bibliothèque
de codes sources de l'ontologie de transformation produite à l'aide du générateur de
codes de Protégé. Cette bibliothèque offre les fonctionnalités de manipulation
d'ontologies de faits, qui est structurée en conformité avec l'ontologie de
transformation.
Les bases de règles de désambiguïsation typologique et topologique sont structurées
selon l'ontologie de transformation. L'exécution de ReglesDesamb.java se divise en
quatre phases. La première phase est l'initialisation de la structure de l'ontologie
résultant du processus de désambiguïsation. La deuxième phase est le déclenchement
des règles de désambiguïsation typologique et topologique sur l'ontologie résultant de
l’importation du modèle semi-formel. Lorsque la désambiguïsation est terminée, la
phase 3 déclenche une inférence fondée sur les bases de règles afin d'identifier les
éléments du modèle semi-formel qui n'ont pas été désambiguïsés et sauvegarde les
données dans l'ontologie du modèle semi-formel désambiguïsé. Finalement, la phase
4 met à jour le diagramme du modèle semi-formel qui est présenté à l'utilisateur afin
de marquer sur le diagramme les éléments du modèle qui sont encore ambigus.
3
S
l
2
E
c
c
3
L
c
c
r
l
n
F
f
3
.2.5 Dével
o
S
chématisé
l
'implantati
o
2
007 ; Ga
m
E
xecuteRegle
s
c
ommandes
c
adre.
3
.2.5.1 Patr
o
L
es patrons
c
lient une
m
c
onsidère l
a
r
éaliser une
l
e développ
e
n
e soit affe
c
F
igure 3.11:
f
ormel désa
m
o
ppement d
u
à la figure
o
n
d
es patro
n
m
ma et a
l
s
.java
, du
Built-ins e
t
o
ns de conc
e
de concept
i
m
éthode st
a
a
command
e
tâche. Jum
e
e
ment itérat
i
c
tée. La dyn
a
Développ
e
m
biguïsé en
u
module de
3.11, le dé
v
n
s de conce
p
l
., 1999),
l
développe
m
t
de l'ajuste
m
e
ption
I
nvoc
a
i
on
I
nvocat
e
a
ndardisée
e
e
comme un
e
lé à l'invoc
a
i
f et évoluti
f
a
mique d'uti
er
le modul
e
ontologie d
u
conversion
v
eloppemen
t
p
tion Comm
a
l
e dévelop
p
m
ent conjo
i
m
ent de l'o
n
a
teur et Co
m
e
ur et Com
m
e
t unique p
e
e action of
f
a
teu
r
, le pa
t
f
de comm
a
lisation de
c
e
de conve
r
u
domaine.
t
du modul
e
a
nde et
I
nv
o
p
ement du
i
nt des rè
g
n
tologie de
r
m
mande
m
ande ont
p
e
rmettant l'
a
f
erte par un
e
t
ron de con
c
a
ndes sans
q
c
e patron de
r
sion de l'o
n
e
de conve
r
o
cateur (Bu
s
gestionnair
e
g
les de c
o
r
éférence et
p
our intentio
a
ppel de co
e
boîte à o
u
c
eption Co
m
q
ue la signat
u
conception,
n
tologie du
1
r
sion impli
q
s
chmann et
a
e
d'ontolog
i
o
nversion,
d
de l'ontolo
g
o
n d'offrir à
o
mmandes.
O
u
tils en vue
m
mande per
m
ure des app
e
schématisé
e
modèle se
m
68
q
ue
a
l.,
i
es
d
es
g
ie
un
O
n
de
m
et
e
ls
e
à
m
i-
l
c
s
c
d
p
d
F
r
3
U
c
d
1
r
1
q
c
l
a figure 3.1
c
lient. Le n
o
s
ont passés
c
ommande,
d
ynamique
p
ermet au r
e
d
e l'exécuti
o
F
igure 3.12:
r
eceveur.
3
.2.5.2 Dév
e
S
W
U
n aspect
i
c
onstructio
n
d
'une ontol
o
1
06
Ici, le term
e
r
éférence à l'act
i
1
07
Le lien de c
o
q
ue le lien R es
t
c
rée
r
est exécut
é
2, démarre
a
o
m de la co
m
en paramèt
r
puis de la
n
de la boîte
e
ceveur de
p
o
n de la co
m
Relations
1
0
e
loppement
W
RL.
i
nnovateur
i
n
d'une onto
o
gie de trai
t
e
méthode est
u
i
on associée à u
n
o
mposition entr
e
utilisé pour ind
i
é
e par l’agent c
o
a
vec l'appel
m
mande à
e
r
e à la mét
h
n
cer l'exéc
u
à outils, re
ç
p
roduire le
r
m
mande.
0
7
et utilisa
t
du mécanis
m
i
mportant
d
logie cible
r
t
ement. Po
u
u
tilisé dans le
c
n
e classe.
e
un agent et un
e
i
quer que l’age
n
o
mmande lorsqu
e
de la méth
o
e
xécuter ain
s
h
ode. L'inv
o
u
tion de ce
l
ç
oit la req
u
r
ésultat. L'i
n
t
ions d'un
i
m
e d'appel
d
'OntoCAS
E
r
ésultant d
u
u
r ce faire,
c
ontexte inform
a
e
procédure indi
q
n
t déclenche l’e
x
e
l’agent invoca
t
o
de
106
invoq
u
s
i que les a
r
o
cateur a la
l
le-ci. Le r
e
u
ête d'action
n
vocateur re
t
i
nvocateur,
de comman
E
est sa bo
î
u
déclenche
m
le module
d
atique du déve
l
q
ue que la proc
é
x
écution de la pr
teu
r
en fait la d
e
u
er() de l'in
v
r
guments d
e
responsabil
e
ceveu
r
, qu
i
n
de la com
m
t
ourne au cl
d'une com
m
n
de Java à
p
î
te à outils
m
ent de règ
l
d
e conversi
l
oppement orie
n
é
dure est exécu
t
océdure. Par ex
e
e
mande
1
v
ocateur pa
r
e
la comma
n
ité de créer
i
est un o
bj
m
ande, ce
q
ient le résu
l
m
ande et d
'
p
artir de règ
l
permettant
l
es d'infére
n
on exploite
n
té objets et il
t
ée par l’agent a
l
e
mple, la procé
d
69
r
le
n
de
la
bj
et
q
ui
l
tat
'
un
l
es
la
n
ce
la
fait
l
ors
d
ure
170
propriété de modularité du SWRL Built-in108 jumelé avec SWRLBuiltInBridge109 qui
sert d'API entre la déclaration de l'atome SWRL et son implantation Java. Pour
l'exécution de règles SWRL, OntoCASE utilise l'interface SWRLRuleEnginBridge110
(Golbreich, 2004 ; O'Connor et al., 2008a ; O'Connor et al., 2008b ; O’Connor et al.,
2005b) qui est un pont, au sens de Gamma et al. (1999), entre un modèle OWL
contenant des règles SWRL et le moteur d'inférences à base de règles. C'est ce pont
qui encapsule l'invocateur de notre architecture (voir le tableau 3.25a) dont le code
est présenté à l'appendice F.16.3.
Comme présenté au tableau 3.25, le raccord d'une action Java à sa représentation en
SWRL se divise en trois parties. La première partie (voir le tableau 3.25a) est la
déclaration d'un invoker. La deuxième partie (voir le tableau 3.25b) présente un appel
en SWRL par l'invocateur de la commande OWLCreerUneClasseCmd implantée en Java. La
partie c du tableau 3.25 présente l'implantation Java de la commande
OWLCreerUneClasseCmd dont la partie fonctionnelle de la commande est encapsulée dans
la méthode action(). Pour cette commande, la méthode action() charge le singleton
owlModel qui est l'objet contenant l'ontologie cible. Lorsque l'ontologie cible est
disponible, la méthode associée createOWLNamedClass permet de créer une nouvelle
classe dont le nom est nomClasse qui a préalablement été passée en argument lors de
l'appel de l'invoker par la commande SWRL. Dans OntoCASE, des commandes telles
que CreerUneOntologieCmd, OWLCreerUneProprieteCmd, OWLCreerUneProprieteDatatypeCmd,
OWLProprieteSetFonctionelleCmd, OWLProprieteSetInverseOfCmd, OWLEstUneInstanceDeCmd,
OWLProprieteAjoutDunDomaineEtDuneImageCmd et plusieurs autres (voir le tableau 3.25d),
permettent la construction d'une ontologie à partir d'inférences sur des règles SWRL.
On trouvera à l'appendice F.16 le code source détaillé nécessaire à l'implantation des
commandes.
108 http://www.daml.org/rules/proposal/builtins.html#8.1
109 http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge
110 http://protege.cim3.net/cgi-bin/wiki.pl?SWRLRuleEngineBridgeFAQ#nid6PM
171
Tableau 3.25
Exemple d'implantation d'une commande Java appelée lors du déclenchement d'une
règle SWRL
a) Déclaration de l'atome invoke dans le fichier swrlbi.owl
<swrl:Builtin rdf:ID="invoker">
<swrlb:minArgs rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</swrlb:minArgs>
</swrl:Builtin>
b) Appel de la commande Java OWLCreerUneClasseCmd à partir d'une règle SWRL de création d'une
classe dans une ontologie de domaine
oRef:OR_Entite_Abstraite_Declaratif(?c) ∧
oRef:OR_identifiant(?c, ?nc)
→ swrlbi:invoker("OWLCreerUneClasseCmd", ?nc)
c) Implantation de l'action de créer une classe OWL de la commande Java OWLCreerUneClasseCmd
public Boolean action() {
owlModel = ontologieRegister.getOwlDomainModel();
OWLNamedClass sousClasse =
owlModel.createOWLNamedClass(nomClasse);
return new Boolean(true);
}
d) Liste des commandes de la boite à outils pour la construction d'une ontologie cible
ImprimeMessageCmd.java
OWLAjoutDuneProprieteEntreClasseEtIndividuCmd.java
OWLAjoutDuneProprieteEntreIndividuCmd.java
OWLAjoutDuneProprieteEntreResourceCmd.java
OWLAssignerRestrictionAPourValeur_FloatCmd.java
OWLAssignerRestrictionAPourValeur_IndividuCmd.java
OWLAssignerRestrictionAPourValeur_IntegerCmd.java
OWLAssignerRestrictionAPourValeur_StringCmd.java
OWLAssignerRestrictionExistencielCmd.java
OWLAssignerRestrictionUniverselCmd.java
OWLAssignerUneValeurAUnAttributCmd.java
OWLProprieteDatatype_AjoutDunDomaineEtDunRangeType
Cmd.java
OWLProprieteSetFonctionelleCmd.java
OWLPropriete_AjoutDunDomaineCmd.java
OWLPropriete_AjoutDunDomaineEtDuneImageCmd.java
OWLSupprimerLeTypeDeLinstanceCmd.java
OWLSupprimerSuperProprieteDeCmd.java
OWLCreerUneProprieteDatatypeCmd.java
OWLProprieteSetInvFonctionelleCmd.java
OWLCreerUneClasseCmd.java
OWLCreerUneClasseSousCmd.java
OWLCreerUneInstanceSousCmd.java
OWLCreerUneProprieteCmd.java
OWLEstDisjointDeCmd.java
OWLEstUneInstanceDeCmd.java
OWLEstUneSousClasseDeCmd.java
OWLEstUneSousProprieteDeCmd.java
OWLSupprimerSuperClasseDeCmd.java
printf.java
SauvegarderOntologieCmd.java
EnvoyerMessageDerreurCmd.java
OWLProprieteSetInverseOfCmd.java
OWLProprieteSetSymetricCmd.java
OWLProprieteSetTransitiveCmd.java
3.2.5.3 Développer le module de conversion
Le processus de conversion du modèle semi-formel désambiguïsé en ontologie
formelle est réalisé par un système expert (ExecuteRegles.java) utilisant des axiomes
issus de la définition de restrictions dans l’ontologie de transformation et de règles
SWRL contenues dans les bases de règles à la transformation. Schématisé à la
figure 3.13, le processus de conversion se décompose en cinq sous-processus.
L
l
d
l
c
L
d
s
s
F
d
L
e
s
l
p
r
L
e sous-pr
o
l
'ontologie
d
d
u modèle s
l
a transfor
m
c
lassificatio
n
L
es sous-pr
o
d
e règles
d
s
ervent, d'u
n
s
auvegarde
d
F
igure 3.13:
d
omaine.
L
e sous-pro
e
ntités de l'
o
s
ous-proces
s
l
'exemple d
e
p
résente la
r
eprésenter.
o
cessus
I
nfé
d
u modèle s
e
emi-formel
m
ation. Le
t
n
nécessaire
o
cessus Ap
p
d
e finalisati
o
n
e part, à
c
d
e l'ontolog
i
Sous-proc
e
cessus Appl
o
ntologie.
Q
s
us crée ch
a
e
la créatio
n
règle SW
R
re
r
, dont l
e
e
mi-formel
d
en vue du tr
t
ableau 3.2
6
s au traitem
e
p
liquer la b
a
o
n concréti
s
c
réer le fic
h
i
e du domai
n
ssus et onto
l
iquer la ba
s
Q
u'il s'agiss
e
a
cune des
e
n
d'une spé
c
R
L pour la
e
s intrants
s
d
ésambigüis
aitement ult
6
a) présente
e
nt d'une sp
é
a
se de règle
s
s
ent la stru
c
h
ier ontolo
g
n
e sur disqu
e
l
ogies impli
q
s
e de règles
e
des classe
s
ntités de l'
o
c
ialisation
e
création d
e
s
ont l'ontol
o
é, réalise u
n
érieur par l
e
, à titre d'
e
é
cialisation
e
e
s d'initialis
a
c
ture de l'
o
g
ique et, d'
a
e
.
qués dans l
a
de créatio
n
s
,
d
es prop
r
o
ntologie d
u
e
ntre deux
c
e
s classes
a
o
gie de tra
n
n
e classifica
t
e
s autres so
u
e
xemple, l
e
entre deux
c
a
tion et Ap
p
o
ntologie d
u
a
utre part,
à
a
création d
e
n
accomplit
l
r
iétés ou de
s
u
domaine.
T
c
oncepts, le
a
ssociées a
u
1
n
sformation
t
ion des enti
t
u
s-processus
e
s axiomes
c
oncepts.
p
liquer la b
a
u
domaine.
à
permettre
e
l'ontologie
l
a création
d
s
individus,
T
oujours d
a
tableau 3.2
u
x concept
s
72
et
t
és
de
de
a
se
Ils
la
du
d
es
ce
a
ns
6b
s
à
173
Tableau 3.26
Axiomes et règles impliqués dans la conversion d'une spécialisation entre deux
concepts
a) Axiome
(OWL-N3)
oRef:OR_Entite_Abstraite_Declaratif owl:equivalentClass
[ a owl:Restriction ;
owl:hasValue oAmbig:Entite_Declarative ;
owl:onProperty :OT_EntiteEstDeType
] .
oRef:OR_Relation_Hyponyme owl:equivalentClass
[ a owl:Restriction ;
owl:hasValue oAmbig:Relation_Specialisation ;
owl:onProperty :OT_EntiteEstDeType
] .
Interprétation de l’axiome :
Toutes les entités qui ont la propriété OT_EntiteEstDeType assignée
à oAmbig:Entite_Declarative sont des
oRef:OR_Entite_Abstraite_Declaratif.
De plus, toutes les relations qui ont la propriété OT_EntiteEstDeType
assignée à oAmbig:Relation_Specialisation sont des
oRef:OR_Relation_Hyponyme.
b) règle
SWRL de
création
oRef:OR_Entite_Abstraite_Declaratif(?c) ^
oRef:OR_identifiant(?c, ?nc)
→ swrlbi:invoker("OWLCreerUneClasseCmd", ?nc) ^
swrlbi:invoker("OWLEstUneSousClasseDeCmd", ?nc,
"metaDom:MD_Declarative")
Interprétation de la règle :
Soit une connaissance abstraite et déclarative (?c) ET son identifiant
(?nc) ALORS : Il faut créer dans l’ontologie du domaine une classe
du nom de ?nc et classer cette classe sous la classe
metaDom:MD_Declarative
c) Règle
SWRL de
classification
des entités
oRef:OR_Relation_Hyponyme(?ls) ^
oRef:OR_connSource(?ls, ?src) ^
oRef:OR_connDestination(?ls, ?dest) ^
oRef:OR_Entite_Abstraite_Declaratif(?src) ^
oRef:OR_Entite_Abstraite_Declaratif(?dest) ^
oRef:OR_identifiant(?src, ?nomSrc) ^
oRef:OR_identifiant(?dest, ?nomDest)
→ swrlbi:invoker("OWLEstUneSousClasseDeCmd", ?nomSrc,
?nomDest) ^
swrlbi:invoker("OWLSupprimerSuperClasseDeCmd",
"owl:Thing", ?nomSrc) ^
swrlbi:invoker("OWLSupprimerSuperClasseDeCmd",
"metaDom:MD_Declarative", ?nomSrc)
Interprétation de la règle :
Soit un lienS (?ls) qui est relié à sa source par une connaissance
source (?src) et relié à sa destination par une connaissance
destination (?dest) ET ?src et ?dest sont des connaissances abstraites
et déclarative dont les identifiants sont respectivement ?nomSrc et
?nomDest ALORS : il faut indiquer dans l’ontologie du domaine que
la classe du nom ?nomSrc est une sous classe de ?nomDest ET
indiquer que ?nomSrc n’est plus une sous classe directe de owlThing
ni une sous classe directe de metaDom:MD_Declarative
Finalement, le sous-processus Appliquer la base de règles de classification permet de
classer adéquatement les entités qui ont été préalablement créées en fonction de
174
l’ontologie cadre. C'est à cette étape que les domaines et codomaines seront associés
aux propriétés. De même, les classes et les propriétés seront ordonnées selon la
structure taxonomique représentée dans le modèle semi-formel. La règle SWRL du
tableau 3.26c représente la règle de classification taxonomique entre deux concepts
qui ont été unis par la relation de spécialisation.
3.2.6 Développement du module de validation
Tel que vu à la figure 2.10, p.110, la validation de l'ontologie du domaine comporte
les deux sous-processus de validation syntaxique et sémantique. L'assistant comporte
trois artéfacts à développer, dont les processus de développement sont schématisés à
la figure 3.14. Au cœur de la validation sémantique, la classe
OntologyToInterpretation.java est le programme qui produit le rapport d'interprétation
sémantique. La construction de cette classe nécessite l'utilisation de l'ontologie cadre
ainsi que la bibliothèque Java de manipulation de l'ontologie cadre précédemment
conçue (voir la section 3.2.3 p.162). Deux classes Java sont nécessaires à la
réalisation d'une validation syntaxique. La première classe OwlToMot.java reconstruit
un modèle semi-formel à partir de l'ontologie du domaine. Pour ce faire, la classe
utilise la bibliothèque Java de manipulation de l'ontologie cadre pour la lecture de
l'ontologie du domaine, et la bibliothèque de code Java EMF de MOT pour la
génération du modèle semi-formel reconstruit. À la fin de la reconstruction, la classe
réalise une inférence sur l'ontologie cadre et inclut les résultats dans le modèle semi-
formel reconstruit pour une consultation ultérieure par l'expert et l'ingénieur.
L’appendice C présente le catalogue des axiomes et des règles qui permettent la
génération des erreurs de cohérence.
F
F
v
m
l
r
À
r
t
é
l
p
m
é
u
r
d
r
s
F
igu
r
e 3.14:
F
inalement,
v
alidation s
y
m
odèle se
m
l
'identificati
o
r
apport de v
À
titre d’e
x
r
apport d
e
t
ableau 3.27
é
vidence l
e
l
ignes 02 et
p
remière s
e
m
odèles (
v
é
léments du
u
niques au
m
r
econstitué
(
d
es relatio
n
r
espectivem
s
pécifique
n
Modèle pr
o
la classe
y
ntaxique, r
é
m
i-formel
r
o
n des com
p
alidation sy
n
x
emple de r
e
validatio
n
a et b). Le
s
e
s différen
t
03 indique
n
e
ction a po
u
v
oir les lig
n
modèle qui
m
odèle d’o
r
(
voir les li
g
n
s entre le
ent les rel
a
n
e possède
o
cédural du
d
Comparaison
M
é
alise la co
m
r
econstruit.
p
osants de
m
n
taxique.
apport de
v
n
syntaxi
q
s
modèles
s
t
es section
s
n
t le nom
d
u
r sujet la
n
es 05 à 17
i
sont partag
é
r
igine (voir
l
g
nes 16 et 1
7
s deux m
o
a
tions com
m
aucune rela
t
d
éveloppem
e
M
odeles.java,
m
paraison e
n
Les résul
t
m
odèles no
n
v
alidation s
y
q
ue de d
e
s
ont volont
a
s
du rapp
o
d
es fichiers
comparaiso
i
nclusiveme
é
s par les de
l
es lignes 1
2
7
). La deux
i
o
dèles (voi
r
m
unes aux
t
ion comm
u
ent du mod
u
qui sert
à
n
tre le modè
l
t
ats de la
n
équivalent
y
ntaxique, l
e
e
ux modè
l
a
irement di
f
o
rt de va
l
concernés
o
n des con
n
e
nt). Il pré
s
ux modèles
2
et 13) et q
u
i
ème sectio
n
r
les lign
e
deux modè
u
ne aux de
u
u
le de valid
a
à
produire
l
e semi-for
m
comparais
o
t
s) sont entr
e
e
tableau 3.
2
l
es différe
n
f
férents afin
l
idation sy
n
dans la co
m
n
aissances
e
sente resp
e
(voir la lig
n
u
i sont uniq
u
n
présente l
a
e
s 19 à 29).
les (qui p
o
u
x modèles
)
1
a
tion.
le rapport
m
el source e
t
o
n (à sav
o
e
posés dans
2
7 présente
n
ts (voir
de mettre
n
taxique.
L
m
paraison.
e
ntre les d
e
e
ctivement
l
n
e 09), qui s
o
u
es au mod
è
a
comparai
s
Elle prése
n
o
u
r
ce rapp
o
)
, les relati
o
75
de
t
le
o
ir,
le
le
le
en
L
es
La
e
ux
l
es
o
nt
è
le
s
on
n
te
o
rt
o
ns
u
m
(
a
c
0
1
0
2
0
3
0
4
0
5
0
6
0
7
0
8
0
9
1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
2
0
2
1
2
2
2
3
2
4
2
5
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
u
niques au
m
odèle rec
o
(
voir les lig
n
a
)
c
)
1
. Comparais
o
2
. Orig =
C
3
. Recons =
C
4
. Comparais
o
5
. ---------
-
6
. ---------
-
7
. ---------
-
8
. ---------
-
9
. Con
c
0
. ---------
-
1
. ---------
-
2
. Con
c
3
. Pro
c
4
. ---------
-
5
. ---------
-
6
. Con
c
7
. Pri
n
8
. ---------
-
9
. ---------
-
0
. ---------
-
1
. ---------
-
2
. ---------
-
3
. ---------
-
4
. Lie
n
5
. Lie
n
6
. ---------
-
7
. ---------
-
8
. Lie
n
9
. Lie
n
0
. ---------
-
1
. ---------
-
2
. ---------
-
3
. ---------
T
4
. Compte de
s
5
. Compte de
s
6
. Compte de
s
7
. Compte de
s
8
. Compte de
s
9
. Compte de
s
0
. Compte de
s
1
. Compte de
s
2
. Compte de
s
3
. Compte de
s
4
. Compte de
s
5
. Compte de
s
6
. Compte de
s
7
. Compte de
s
modèle d’
o
o
nstitué (voi
r
n
es 31 à 47)
Exemp
l
o
n des documents
C
:/Developpement
/
C
:/Developpement
/
o
n des documents
-
---------------
-
-
----------- Les
-
---------------
-
-
--------- Commu
n
c
ept : C
_
2
-
---------------
-
-
-------Unique a
u
c
ept : C2
_
0
c
édure : Pr2
_
1
-
---------------
-
-
------Unique au
c
ept : C1
_
0
n
cipe : P1
_
1
-
---------------
-
-
------------- L
e
-
---------------
-
-
--------- Commu
n
-
---------------
-
-
-------Unique a
u
n
IP: source C2
_
0
n
S: source C2
_
0
:
-
---------------
-
-
------Unique au
n
R: source C1
_
0
:
n
S: source C1
_
0
:
-
---------------
-
-
------------- B
I
-
---------------
-
T
otaux des diver
s
s
Concepts : Or
i
s
Procedures: Or
i
s
Principes : Or
i
s
Enonces : Or
i
s
Traces : Or
i
s
Exemples : Or
i
s
LienA : Or
i
s
LienC : Or
i
s
LienCm : Or
i
s
LienI : Or
i
s
LienIP : Or
i
s
LienP : Or
i
s
LienR : Or
i
s
LienS : Or
i
o
rigine (voi
r
r
les lignes
2
présente le
b
e de rappor
t
:
/
OntoCASE
_
these
_
/
OntoCASE
_
these
_
:
-
---------------
connaissances
-
---------------
n
aux
d
eux modèl
-
---------------
u
modèle d'origi
-
---------------
modèle reconsti
-
---------------
e
s relations
-
--
-
---------------
n
aux
d
eux modèl
-
---------------
u
modèle d'origi
: dest Pr2
_
1
:
dest C
_
2
-
---------------
modèle reconsti
:
dest P1
_
1
:
dest C
_
2
-
---------------
I
LAN
-
----------
-
---------------
s
composants des
i
ginal = 2, Reco
i
ginal = 1, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 0, Reco
i
ginal = 1, Reco
i
ginal = 0, Reco
i
ginal
=
0, Reco
i
ginal = 1, Reco
r
les lignes
2
8 et 29). Fi
n
b
ilan de la c
Tableau 3.
2
t
complet de
b)
_
260/runtime-
O
nt
o
_
260/runtime-
O
nt
o
----------------
-
---------------
----------------
es
-
------------
----------------
ne--------
-
-----
----------------
tué
-
------------
----------------
----------------
----------------
es
-
------------
----------------
ne
-
-------------
-----
-
----------
tué
-
------------
----------------
----------------
----------------
modèles
-
------
nstruit = 2, Di
f
nstruit = 0, Di
f
nstruit = 1, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit =
0
, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit = 0, Di
f
nstruit = 1, Di
f
nstruit = 1, Di
f
24 et 25) e
t
n
alement, l
a
omparaison
2
7
validation
s
o
CASE
_
these.prod
u
o
CASE
_
these.prod
u
-
-------
-
-------
-
-------
-
--------
-
-------
-
-------
-
-------
-
-------
-
-------
-
-------
-
-------
-
--------
-
-------
-
-------
-
-------
-
-------
-
-------
-
-------
-
-------
-
-------
f
férence = 0
f
férence = 1
f
férence = 1
f
férence = 0
f
férence = 0
f
férence = 0
f
férence = 0
f
férence = 0
f
férence = 0
f
férence = 0
f
férence = 1
f
férence = 0
f
férence = 1
f
férence = 0
t
les relatio
n
a
dernière p
a
entre les de
u
s
yntaxique
u
ct/tst/mod2.mot
u
ct/tst/mod1
_
res
t
1
n
s uniques
a
rtie du rapp
o
u
x modèles.
t
.mot
76
au
o
rt
177
3.2.7 Développement des interfaces utilisateurs
Le dernier module d'importance d'OntoCASE est le module de communication avec
l'utilisateur. En plus d'informer l'utilisateur sur l'état du déroulement des applications,
le module de communication offre les interfaces nécessaires au pilotage de la
méthodologie (les tableaux de bord). Les tableaux de bord sont directement connectés
aux fonctionnalités d'édition et de traitement des modèles et ils sont les représentés
fonctionnels du processus de formalisation et de validation de la méthodologie.
3.2.7.1 Fonctionnalités de communication avec l'utilisateur
L'assistant informatique d'OntoCASE offre plusieurs fonctionnalités de
communication avec l'utilisateur. Certaines d'entres elles utilisent des modèles
graphiques comme médium de communication (voir la figure 3.15 a) alors que
d'autres utilisent le mode caractère (voir la figure 3.15 b et c).
a)
b)
c)
Figure 3.15: Interfaces de communication avec l'utilisateur.
178
L'exemple schématisé à la figure 3.15a illustre une situation d'ambiguïté et une
situation d'erreur. Indiqué par l'icône , la situation d'ambiguïté survient lorsque
l'assistant à la désambiguïsation ne peut pas désambiguïser l'élément de manière
automatique. Dans cet exemple, l'assistant à la désambiguïsation ne peut pas
identifier si le LienC est un attribut ou une composition. C'est alors à l'utilisateur de
désambiguïser le cas. Les situations d'erreurs, qui sont indiquées par l'icône ,
surviennent lorsqu'une situation, apparemment valide selon le langage semi-formel,
ne l'est pas selon la sémantique du langage représenté par l'ontologie cadre. Dans
l'exemple, cette situation peut survenir si C3 est désambigüisé en classe et que C2 est
désambigüisé en schéma. Il n'est donc pas permis de mettre un LienS entre ces deux
concepts puisqu’une relation de spécialisation ne peut pas unir une classe et un
schéma111.
Tel que présenté à la figure 3.15b et c, l'assistant informatique utilise aussi la
communication en mode caractère pour informer l'utilisateur. La console (en b)
informe l'utilisateur pendant l'exécution du module d'importation, de traitement et de
validation. Le journal d'exécution des modules ainsi que la trace d'exécution des
règles de désambiguïsation et de formalisation y figurent aussi. Après l'exécution d'un
module, certains composants du modèle peuvent être altérés. Les onglets Erreur et
Propriété, présentés en c, permettent de consulter les altérations. Un clic sur un
élément d'erreur permet au système de focaliser sur l'élément du modèle concerné et
de faire apparaître la propriété correspondante. Les ajustements au modèle sont
directement réalisés sur le modèle ou dans l'onglet des propriétés.
3.2.7.2 Tableau de bord à la formalisation
Le module de formalisation, dont l'interface est un tableau de bord (voir la
figure 3.16), est un module qui assiste l'ingénieur dans la tâche de formalisation du
111 Bien que la classe et le schéma soient tous les deux représentés par un concept, ceux-ci sont définis dans deux
catégories distinctes dans l'ontologie cadre (voir le tableau 2.2, p.86).
179
modèle semi-formel en ontologie selon les étapes présentées à la section 4.4.6. Les
trois étapes d'importation, de désambiguïsation et de conversion qui composent la
réalisation de cette tâche y sont représentées. À chacune des étapes, l'ingénieur a la
possibilité d'éditer le modèle résultant. La sélection d'Importer, de Désambiguïser et
Convertir active directement les modules de traitements associés à l'importation (voir
la section 3.2.2), de la désambiguïsation (voir la section 3.2.4) à la conversion (voir la
section 3.2.4.2).
Figure 3.16: Le tableau de bord à la formalisation.
3.2.7.3 Tableau de bord à la validation
Le module de validation permet à l'ingénieur et à l'expert de contenu d'accéder aux
outils nécessaires à la réalisation d'une validation syntaxique et sémantique telle que
décrite à la section 3.2.6. Ainsi, les acteurs de cette activité ont accès à des outils
permettant la production de conclusions automatiques nécessaires à l'évaluation
sémantique de l'ontologie. Ils ont aussi accès à des outils de génération d'un modèle
semi-formel à partir de l'ontologie de domaine ainsi qu'à des outils de comparaison
entre le modèle d'origine et le modèle généré afin d'assumer la validation syntaxique
de l'ontologie du domaine. L'appel à ces outils est assuré par le tableau de bord à la
validation (voir la figure 3.17) qui guide l'utilisateur dans la méthode de validation.
180
Figure 3.17: Le tableau de bord à la validation.
3.3 Phase 3: Consolidation
La phase de consolidation a pour sujet la validation de la démarche de recherche. La
première étape de cette phase est la détermination des facettes d’OntoCASE qui
doivent être validées par des cas de test. L’exécution automatique des cas de test est
assurée par la mise en place d’un banc d’essais. Finalement, en fonction des facettes à
évaluer, une méthode de conception et d’exécution des tests est élaborée.
3.3.1 Cas de test
Couramment utilisés en ingénierie logicielle, les cas de test "testCase" (Burnstein,
2003 ; Jacobson et al., 1999) sont des applications informatiques qui mesurent les
réponses d'un système par la comparaison des résultats obtenus versus les résultats
attendus. Les cas de tests sont regroupés en scénarios de test pour évaluer des
systèmes selon des perspectives contextuelles particulières. Les tests sont appliqués à
des niveaux spécifiques des applications.
181
Le test de niveau unitaire (unit test) s'adresse au premier niveau des applications,
c'est-à-dire aux fonctions, procédures, classes et méthodes. Il a pour objectif d'évaluer
les réponses des entités de base d'un système et de signaler tout changement dans ses
fonctionnalités élémentaires. Le test de niveau intégration (integration test) mesure la
réponse d'un système lorsque ses divers composants sont en interrelation les uns avec
les autres. Finalement, le test de niveau systémique (system test) évalue le système
avec des cas de test se rapprochant davantage des situations d'usage de l'application.
Les tests de ce niveau sont utilisés pour mesurer les fonctions d'usage du système,
évaluer ses performances, sa capacité à réagir au stress ou à toute autre caractéristique
de niveau système telles que la sécurité, la configuration ou la restauration
d'informations.
3.3.2 Concevoir le banc d'essais
Le banc d'essais d'OntoCASE est une application JUnit112 intégrée à Eclipse qui
permet l'exécution de scénarios de test. Composé de plusieurs cas de test, le scénario
de test permet de valider de manière systématique et automatique les fonctionnalités
d’un système. Pour chacune des fonctionnalités à tester, l’ingénieur responsable du
test produit un résultat attendu qui servira de point de comparaison au résultat
produit par l’appel de la fonction à tester. Les dispositions prises à la suite de la
comparaison sont programmées dans l’application qui exécute le cas de test. La
figure 3.18 présente le modèle procédural associé à l’exécution des scénarios de test
réalisé pour valider OntoCASE. Dans cette optique, le scénario de cas de test se
compose de plusieurs cas de test dont la première étape d'exécution est la
formalisation d'un modèle semi-formel attendu en ontologie de domaine. Selon les
spécificités à évaluer par le scénario de test, le modèle semi-formel attendu pourra
avoir subi une désambiguïsation manuelle si nécessaire. En revanche, dans le cas
d'ambiguïté sémantique, le modèle semi-formel attendu devra être systématiquement
112 JUnit.org, Resources for Test Driven Development: http://www.junit.org/about
d
d
p
L
s
m
d
a
d
r
e
F
d
ésambiguï
s
d
euxième é
t
p
our génére
r
L
a compar
a
s
'effectue p
a
m
odèles. L
a
d
u modèle
a
ssuré que l
e
d
es élément
s
r
apports de
t
e
t permet la
F
igure 3.18:
s
é manuelle
m
t
ape consist
e
r
, à partir de
a
ison des m
o
a
r une com
p
a
comparais
o
attendu da
n
e
s deux mo
d
s
. C'est aprè
t
otaux est r
é
rédaction d
u
Exécution
d
m
ent avant
l
e
à utiliser
l
l'ontologie
o
dèles semi
-
p
araison cro
i
o
n croisée c
o
n
s le modèl
e
d
èles sont id
e
s l'exécutio
n
é
alisée. Ce r
a
u
bilan de c
o
d
'un cas de t
l
e déclenche
m
l
e module
d
de domaine
,
-
formels at
t
i
sée des ent
i
o
nsiste à fa
i
e
produit e
t
e
ntiques en
n
n
des comp
a
a
pport indiq
u
o
mparaison
e
est pour la
m
ment du ca
s
d
e validatio
n
,
le modèle
s
t
endu et
p
r
o
i
tés et des r
e
i
re une rech
e
t
vice-versa.
n
ombre et e
n
a
raisons croi
q
ue les entit
é
e
ntre les mo
m
esure d'eff
i
s
de test cor
r
n
syntaxiqu
e
s
emi-formel
o
duit (réalis
é
e
lations co
n
e
rche de to
u
.
De cette
m
n
équivalen
c
sées que la
p
é
s de modèl
e
dèles.
i
cacité d'On
t
1
r
espondant.
e
d'OntoCA
S
produit.
é
e à l'étape
n
tenus dans
l
u
s les éléme
n
m
anière, il
e
c
e pour cha
c
p
roduction
d
e
s qui diffèr
e
t
oCASE.
82
La
S
E
3)
l
es
n
ts
e
st
c
un
d
es
e
nt
183
3.3.3 Concevoir et exécuter les cas de test
Afin de consolider OntoCASE, nous avons conçu une série de scénarios de test que
nous avons catégorisés en vue de tester des aspects spécifiques. La première
catégorie, le scénario de cas de test unitaire, est conçue pour valider l'étape de
conversion du processus de formalisation. Pour ce faire, chacun des modèles du cas
de test est préalablement désambiguïsé par le concepteur. Le scénario de test
d'intégration vise la validation de l'étape de désambiguïsation topologique et
typologique. Le scénario de test système est conçu afin de valider la capacité
d'OntoCASE à formaliser des modèles complexes contenant des représentations de
type mixte. Finalement, le scénario de test d'incohérence est conçu pour évaluer la
capacité d'OntoCASE à identifier et communiquer des erreurs de modélisation à
l'utilisateur. L’appendice C présente le catalogue des axiomes et des règles qui
permettent la génération des erreurs de cohérence. Au chapitre suivant, nous verrons
plus en détail les scénarios de test qui ont servi à valider OntoCASE.
CHAPITRE 4
VALIDATION D’ONTOCASE
Tel que vu précédemment, la méthodologie d'OntoCASE se compose de trois volets :
un volet méthodologique, un volet représentationnel et un volet computationnel. Ce
chapitre présente les résultats des activités réalisées en vue de vérifier l'hypothèse
présentée au chapitre 2, à savoir qu’il est possible de soutenir la formalisation de
connaissances procédurales, stratégiques et déclaratives, exprimées de manière semi-
formelle, en connaissances déclaratives dans un formalisme formel, et plus
spécifiquement en ontologie, et ce, par l'exécution d'un ensemble de méthodes
soutenues de manière automatique ou semi-automatique.
Pour vérifier cette hypothèse, nous avons procédé à une validation d’OntoCASE
selon les trois axes suivants:
- Généralité des types de connaissances à formaliser
Il s’agit de démontrer que les connaissances de divers types (déclaratives,
procédurales, stratégiques et factuelles) présentes dans le modèle semi-formel
sont représentées dans l'ontologie produite.
- Ergonomie d’OntoCASE
La validation ergonomique a pour objectif de valider la capacité d’OntoCASE
à être utilisé par des utilisateurs autres que son concepteur. L’ergonomie
d'OntoCASE sera démontrée par une expérimentation en laboratoire où des
185
utilisateurs seront mis en situation de formalisation ontologique de modèles
semi-formels.
- Généricité des langages semi-formels utilisés pour la formalisation
Cette dimension sera démontrée en appliquant le scénario de transformation
d’OntoCASE à partir d’un modèle semi-formel construit à l’aide d’un autre
langage que MOT, à savoir le langage MindMap (Buzan et Buzan, 1994).
Nous présentons les résultats relatifs à chacun de ces axes dans ce chapitre selon le
modèle de l’utilisabilité tel que défini par Brangier et Barcenilla (2003).
4.1 Modèle d’utilisabilité
Pour Brangier et Barcenilla (2003), l'utilité d'un dispositif technique concerne sa
capacité à répondre aux besoins réels des utilisateurs alors que l'utilisabilité concerne
sa facilité à être utilisé par une personne donnée de façon à accomplir la tâche pour
laquelle cet objet a été conçu. Trois critères sont proposés pour évaluer l’ergonomie
d’un logiciel:
- l'efficacité, qui est le degré de réalisation des objectifs visés par le logiciel;
- l'efficience, qui est la capacité de réaliser une tâche donnée avec le minimum
d'effort;
- la satisfaction, qui est le niveau de confort ressenti par l’usager du logiciel.
Nous allons appliquer ces trois critères à la validation d’OntoCASE.
La mesure de l'efficacité est le plus mécanique des mesures. Elle doit déterminer si le
dispositif accomplit la tâche pour laquelle il a été conçu. Nous appliquons cette
mesure aux premier et troisième axes, généralité des types de connaissances à
formaliser et généricité des langages semi-formels utilisés pour la formalisation de la
validation d’OntoCASE. Dans chacun de ces deux axes, il s’agit de mesurer la
capacité d'OntoCASE à formaliser en ontologie un modèle semi-formel contenant
186
divers types de connaissances par la mesure de l'efficacité du logiciel à exécuter cette
tâche. Pour ce faire, une série de cas de tests unitaires, d'intégration et de système
sont développés et mécaniquement appliqués. Un premier ensemble de scénarios de
test (les tests de véracité) démontre la capacité du logiciel à désambiguïser et à
transformer correctement des modèles qui sont syntaxiquement valides. Le deuxième
ensemble de scénarios de test (les tests d'erreurs) valide le logiciel dans son efficacité
à identifier des situations de modélisation erronées.
La mesure de l'efficience est une évaluation plus subjective que la mesure de
l'efficacité, qui comporte tout de même des indicateurs objectifs tels que « […] le
taux et la nature des erreurs d'utilisation; le temps d'exécution d'une tâche donnée; le
nombre d'opérations requises […]; la charge de travail » 113. Des techniques
d'évaluation telles que l'analyse en situation d'utilisation, les groupes de discussions,
l'entretien structuré, le questionnaire, l'observation, le monitorage de l'utilisation et les
retours d'expériences permettent d'obtenir des indicateurs de mesure de l'efficience.
La satisfaction est la composante de l'utilisabilité qui fait référence à la dimension du
confort d'utilisation du dispositif, à la réaction affective d'agrément ou de
désagrément d'utilisation. Les aspects émotionnels de l'utilisation sont modulés par la
stabilité de l'application, la facilité d'apprentissage, le sentiment que l'application
permet de sauver du temps de travail et même la stimulation de la créativité de
l'utilisateur. Les techniques d'évaluation décrites dans la mesure de l'efficience
peuvent aussi servir à la mesure de la satisfaction.
L’efficacité, l’efficience et la satisfaction sont des mesures importantes de
l’ergonomie d’OntoCASE
113 Brangier et Barcenilla, Concevoir un produit facile à utiliser p. 47.
187
4.2 Généralité des types de connaissances à formaliser et mesure de l'efficacité
d'OntoCASE
L'évaluation de la généralité des types de connaissances à formaliser est réalisée par
l'implantation de cas de tests unitaires, d'intégration et de système (Burnstein, 2003 ;
Dirk, 2008). D'un point de vue méthodologique, ces cas de tests valident de manière
systématique chacune des règles de formalisation appliquée à chacun des scénarios
possibles de modélisation. Du point de vue applicatif, les cas de test valident la
mécanique informatique qui réalise la formalisation de chacun des scénarios de
modélisation. Les scénarios et cas de tests décrits plus bas sont réalisés grâce au banc
d'essai réalisé à la phase 3 de la démarche de construction d’OntoCASE décrite au
chapitre 3 et les résultats détaillés sont présentés à l'appendice D.
4.2.1 Scénario de tests unitaires
Le test unitaire consiste à introduire dans le processus de test des modèles
préalablement désambiguïsés. Cette caractéristique des modèles permet de focaliser
les tests sur la validation du processus de conversion. Le tableau 4.2 (dont la structure
est présentée au tableau 4.1) présente quelques-uns des cas de tests unitaires qui ont
été appliqués à OntoCASE.
Tableau 4.1
Structure de présentation des divers cas de test unitaires.
Nom du test Représentation en MOT
Description
En plus de ceux-ci, le scénario de tests unitaires comporte des tests pour l'évaluation
des liens de MOT ainsi que pour la construction d'entités ontologiques de type
propriétés, de classes et d'individus dans le contexte de l'ontologie cadre. Le scénario
de tests unitaires comporte dix-sept cas de tests différents (voir l’appendice D.1).
a
C
m
s
d
l
a
b
C
m
d
e
c
r
c
C
m
l
a
e
c
d
C
e
M
e
L
v
c
a
) Lien d'attri
b
C
e test vali
d
m
ot:LienC
po
s
chéma ou u
n
d
'un concept.
l
'assignation
a
ttribut.
b
) L'holonym
e
C
e test val
i
m
ot:LienC
po
d
'une compos
i
e
st validée po
u
c
onnaissances
r
eprésentation
c
) L'instanciat
i
C
e test val
i
m
ot:LienI
et
l
'instanciation
a
bstraite en c
o
e
t pour la
c
onnaissances
d
) Les entités
C
e test vali
e
ntités abstra
i
M
OT pour dé
s
e
ntités de l'ont
L
es tests u
n
v
ocabulaire
c
hacun des
é
b
ution
d
e l'utilisatio
n
o
ur désigner
n
concept est
a
Ce test valid
e
d
'une valeur
e
i
de l'utilisati
o
o
ur la dési
g
i
tion. La com
p
u
r plusieurs t
y
de nivea
u
abstrait et con
i
on et hypony
m
i
de l'utilisati
o
du
mot:lien
S
d'une conna
i
o
nnaissance c
o
subsomption
abstraites.
de l'utilisati
o
i
tes et concr
è
s
igner les dif
f
o
logie cadre.
n
itaires ainsi
et à celle
d
é
léments so
n
Quelq
u
n
d'un
qu'un
a
ttribut
e
aussi
à un
o
n du
g
nation
p
osition
y
pes de
u
x de
cret.
m
e
o
n du
S
pour
i
ssance
o
ncrète
entre
o
n des
è
tes de
fé
rentes
que les tes
t
d
e la gram
m
n
t sémantiq
u
Tableau 4.
2
u
es cas de te
s
t
s d'intégrat
m
aire du la
n
u
ement peu
s
2
s
t unitaire
t
ion qui sui
v
n
gage. C'es
t
s
ignificatifs.
v
ent s'adres
s
t
pourquoi
1
s
ent à la pa
r
les libellés
88
r
tie
de
4
L
l
l
l
t
L
p
a
C
d
d
l
u
p
L
d
b
c
C
r
a
c
c
c
C
p
c
N
e
4
.2.2 Scéna
r
L
es modèle
s
l
es tests un
i
l
es modèle
s
l
'efficacité
d
t
opologique
m
L
e tableau
4
p
remiers ca
s
a
) Propriété et
C
e test d'intég
d
'une connais
d
eux connais
s
l
a représentat
i
u
nit deux cla
s
p
ropriété entr
e
L
a désa
m
b
igu
ï
d
e type topolo
g
b
) Construc
t
c
onclusion un
i
C
e test valide
r
ègle de typ
e
'conclusion
u
a
lors 'opérati
o
c
ompose de rè
g
c
) Régulation
e
c
oncrètes
C
e test valide
p
ropriété d
c
onnaissances
N
otons qu
e
e
xemple, le
s
r
io de tests
d
s
utilisés p
o
taires, à ce
c
s
à tester.
C
d
u système
(
m
ent les m
o
4
.3 présente
s
) une désa
m
assertion
r
ation valide l
'
sance stratég
i
s
ances déclara
t
i
on d'une pro
s
ses et l'asser
t
e
deux individ
u
ï
sation de ce
m
g
ique.
t
ion d'une
i
que
la représent
a
e
s
i 'antécéd
e
u
nique', si '
a
o
n' et la pro
g
le.
e
ntre entités a
b
la représent
a
e régulatio
n
abstraites et c
o
e
les cas
d
s
représenta
t
d
'intégration
o
ur les tests
c
i près qu'a
u
C
e scénari
o
(
méthode et
dèles semi-
f
quelques c
a
m
biguïsation
Quelques
'
utilisation
i
que entre
t
ives pour
priété qui
t
ion d'une
u
s.
m
odèle est
règle à
a
tion d'une
e
nt' alors
a
ntécédent'
cédure se
b
straites et
a
tion d'une
n
entre
o
ncrètes.
d
e tests né
c
t
ions utilisa
n
d'intégratio
n
u
cune désa
m
o
de test
m
application
)
f
ormels.
a
s de tests d
'
topologiqu
e
Tableau 4.
3
cas de tests
d
c
essitant un
e
n
t le
m
ot:L
i
n
sont iden
t
m
biguïsation
m
et donc l'
a
)
à désambi
g
'
intégration
e
.
3
d'intégratio
n
e
désambi
g
i
enC
) sont i
n
t
iques à ceu
x
n'est réalis
é
a
ccent sur l
g
uïser typo
l
nécessitant
n
g
uïsation sé
m
n
clus dans
l
1
x
utilisés p
o
é
e a priori
s
'évaluation
l
ogiquement
(dans les d
e
m
antique (
p
l
e scénario
d
89
o
ur
s
ur
de
et
e
ux
p
ar
d
es
190
tests unitaires. Le scénario de cas de tests d'intégration comporte au total dix-neuf cas
de tests différents (voir appendice D.2).
4.2.3 Scénario de tests systèmes
Principalement orienté sur la sémantique des modèles, ce scénario de test met l'accent
sur la formalisation de modèles sémantiquement significatifs. Pour ce faire, nous
avons utilisé la majeure partie des exemples de modèles MOT présentés aux chapitres
2 et 3 de l’ouvrage de Paquette (2002b). Une désambiguïsation sémantique a été
réalisée pour les modèles dont la sémantique l'exigeait. Pour tous les autres modèles,
aucune désambiguïsation sémantique n'a été réalisée laissant ainsi la réalisation de
cette tâche au système.
Le tableau 4.4 présente quelques cas de test systèmes. En plus de ceux présentés
(taxonomie, procédure et définition d'une loi), le scénario teste des cas tels que
contrôle de procédure; arbre de décision, procédure séquentielle. Au total, le scénario
de tests systèmes comporte vingt-et-un cas de tests différents (voir l’appendice D.3).
a
C
v
d
c
l
i
b
C
v
d
p
c
p
c
v
r
p
u
c
C
l
d
d
L
m
m
c
m
a
m
d
d
d
a
) Taxonomie
C
e cas de tes
t
v
alider la re
p
d
'une
c
omplétée
l
'instanciation
i
ndividus.
b
) Procédure
C
e cas de tes
t
v
alider la re
p
d
e la re
l
p
récédence
c
ontexte a
v
p
rocédures
c
onditions.
D
v
alide l'utilis
a
r
elation d'int
r
p
roduit entre
u
u
ne procédure
.
c
) Définition
d
C
e cas de
t
l
'utilisation d
u
d
ans le co
d
éfinition d'
u
L
'utilisation
d
m
ot:LienC
m
ot:LienP
c
onjonction
m
ot:Princi
p
a
djacents per
m
m
odule
d
ésambiguïsat
i
d
'identifier de
s
d
éfinition de r
è
t
permet de
p
résentation
taxonomie
par
de deux
t
permet de
p
résentation
l
ation de
mise en
v
ec des
et des
D
e plus, il
a
tion de la
r
ant et de
u
n objet et
.
d
'une loi
t
est valide
u
principe
ntexte de
u
ne règle.
d
es divers
et
en
avec les
p
e
m
ettent au
de
i
on
s
patrons de
è
gles.
Quelqu
e
Tableau 4.
4
e
s cas de tes
t
4
t
s systèmes
191
192
4.2.4 Scénario de tests du mécanisme de détection d'incohérence
Les scénarios de tests unitaires, d'intégration et de systèmes utilisent des modèles qui
sont sémantiquement et syntaxiquement valides. Ils sont spécialement conçus pour
valider le processus de désambiguïsation et de conversion des modèles semi-formels.
En revanche, les scénarios de tests d'incohérence ont pour objectif de tester le
système de détection des incohérences d'OntoCASE. Pour OntoCASE, l’incohérence
est une erreur qui survient lorsque certains éléments de l’ontologie cible ne respectent
pas la grammaire de l’ontologie cadre. Ces erreurs sont souvent engendrées par une
mauvaise désambiguïsation des éléments du modèle semi-formel. Par exemple, dans
un modèle semi-formel, la représentation d’une relation d’instanciation entre un
principe et un énoncé pourrait être désambiguïsée par erreur en instanciation entre un
oRef:OR_Entite_Principe_Agent et un oRef:OR_Entite_Principe_Condition, ce qui est une
incohérence puisque dans la grammaire de l’ontologie cadre, une condition ne peut
pas être l’instance d’un agent. Ces erreurs ne peuvent pas être identifiées par l'éditeur
de modèles semi-formels puisque la catégorisation des éléments du modèle semi-
formel est traitée à l’étape de la formalisation. Il importe donc d'implanter un
mécanisme d'identification d'erreurs qui soit actif pendant l'étape de formalisation.
C'est la mesure de l'efficacité de ce mécanisme qui est prise par le scénario de tests
d'incohérence. L’appendice D.4 présente les quatre scénarios de tests d’incohérence
qui sont appliqués pour valider la cohérence de l’ontologie cible. L’appendice C
présente le catalogue des axiomes et des règles qui permettent la génération des
erreurs de cohérence.
4.3 Ergonomie d’OntoCASE
L’évaluation de l’ergonomie d’un dispositif est une activité complexe puisqu’elle doit
considérer des aspects objectifs et subjectifs de l’utilisation d’un dispositif. La mesure
de l’efficience et de la satisfaction est une façon d’obtenir des informations sur la
qualité de l’ergonomie. Dans cette section, nous présentons d’abord les mécanismes
193
qui sont mis en place dans OntoCASE dans le but d’offrir un logiciel efficient à son
utilisateur. Quant à la mesure de l’efficience et de la satisfaction, elle est réalisée à
partir d’une évaluation en laboratoire dont nous présenterons le protocole et le
résultat à la section 4.3.4.
4.3.1 Mécanismes visant à assurer l'efficience d'OntoCASE et la satisfaction de
l’usager
La volonté de maintenir l'efficience et la satisfaction à un haut niveau est une qualité
importante d'OntoCASE . Pour ce faire, nous proposons une application informatique
intelligente, soutenant la méthodologie de formalisation, puis l'implantation de
mécanismes de rétroaction conviviaux qui informent l'ingénieur sur l'état de la
formalisation pendant son déroulement.
4.3.2 Mécanisme de rétroaction d'OntoCASE
Le mécanisme de rétroaction est un ensemble de dispositifs qui informent l'utilisateur
sur l'état des processus en cours à l’aide d’une application qui se veut conviviale.
Deux dispositifs visuels sont présentés à l'utilisateur d'OntoCASE. Une console de
présentation des messages générés lors de la phase de désambiguïsation et de
formalisation constitue le premier dispositif de rétroaction. La lecture des messages
fournit notamment des informations sur les règles qui ont été déclenchées pour
réaliser la formalisation ainsi que sur leur contenu. Le deuxième dispositif de
rétroaction est la fenêtre d'édition du modèle semi-formel. En plus de présenter le
modèle sous une forme graphique, l'éditeur identifie les ambiguïtés directement dans
le modèle au moyen d'icônes spécifiques (voir le tableau 4.5).
194
Tableau 4.5
Icônes de rétroaction des ambiguïtés et des erreurs d’incohérence
Signification d'ambiguïtés et d'erreurs et leur
représentation
Dans cet exemple, l'assistant indique que le
mot:lienC et le mot:Concept(C2) sont en
ambiguïtés et que le mot:Concept(C3) et le
mot: Liens sont en erreur.
4.3.3 Mécanisme de pilotage de l'ingénieur
Un autre dispositif que nous estimons important dans le but d'accroître l'efficience
d'OntoCASE est l'utilisation de tableaux de bord qui guident l'utilisateur dans la
méthodologie. L'assistant d'OntoCASE comporte deux tableaux de bord, soit le
tableau de bord à la formalisation (voir la figure 3.16 p.179) et le tableau de bord à
la validation (voir la figure 3.17, p.180). Il est à remarquer que les fonctionnalités des
tableaux de bord sont présentées dans le formalisme graphique et semi-formel MOT
du fait de sa simplicité et de sa facilité d’interprétation. Le tableau de bord à la
formalisation guide l'ingénieur dans le processus de formalisation aux étapes
d'importation, de désambiguïsation et de transformation. À chacune des étapes,
l'utilisateur peut éditer les fichiers concernés ou sélectionner d'autres fichiers en
intrants aux processus. Puis, il n’a qu’à cliquer sur chacun des processus représentés
pour en déclencher le déploiement. L'utilisateur suit alors l'évolution de la
formalisation par l'intermédiaire des mécanismes de rétroaction.
Un aspect important de l'efficience est la possibilité pour l'ingénieur et l'expert de
valider le résultat produit. Le tableau de bord à la validation vise à les assister pour ce
faire. La génération des rapports de validation syntaxique et sémantique peut y être
produite et éditée de façon intuitive.
195
4.3.4 Évaluation expérimentale de l’ergonomie d’OntoCASE
Il est difficile d'établir des indicateurs objectifs sans point de comparaison avec des
données préalablement établies. Cependant, il est possible d'obtenir des indicateurs de
temps de réalisation d'une tâche, de temps d'apprentissage, de calcul d'erreur et de
charge de travail pour réaliser une tâche ainsi qu’une appréciation globale sur
l’utilisation. Ces indicateurs ont été vérifiés par une expérimentation en laboratoire.
Dans cette section, nous décrivons d’abord le protocole expérimental utilisé et
brossons ensuite un bilan des résultats de cette expérimentation.
4.3.4.1 Objectif général de l'évaluation expérimentale
L'évaluation expérimentale a donc pour objectif de valider l’ergonomie d'OntoCASE
en termes d'efficacité (degré de réalisation des objectifs poursuivis en matière
d'utilisation), d'efficience (capacité de produire une tâche donnée avec le minimum
d'effort) et de satisfaction (niveau de confort ressenti en utilisant le logiciel).
De plus, l’expérimentation vise à évaluer la capacité d'OntoCASE à résister à des
situations non prévues qui surviennent en situation réelle de formalisation.
4.3.4.2 Objectifs secondaires
Du point de vue de l'efficacité, l'évaluation d'OntoCASE vérifie que l'utilisateur peut :
- éditer (créer, modifier, sauvegarder) des modèles semi-formels dans le
formalisme du langage MOT;
- éditer (créer, modifier, sauvegarder) des ontologies en OWL;
- formaliser en ontologie des connaissances déclaratives, procédurales et
stratégiques à partir d'un modèle semi-formel;
- identifier les connaissances ambiguës et assister l’usager pour la
désambiguïsation;
- réaliser une validation syntaxique et sémantique de l'ontologie cible.
196
Du point de vue de l'efficience, l'évaluation d'OntoCASE doit permettre de:
- mesurer le temps nécessaire à:
o réaliser une formalisation ne contenant aucune ambiguïté;
o réaliser une formalisation contenant des ambiguïtés;
o réaliser une validation syntaxique et sémantique;
- quantifier le nombre d'opérations nécessaires pour réaliser des opérations de
formalisation et de validation;
- mesurer la capacité à être découvert de manière intuitive;
- quantifier les bonnes et les mauvaises utilisations.
Du point de vue de la satisfaction, l'évaluation d'OntoCASE doit permettre
d’identifier :
- des aspects d’OntoCASE qui peuvent être frustrants pour l’usager ;
- les aspects d’OntoCASE jugés satisfaisants du point de vue de représentants
d’usagers cibles ;
- d’autres champs potentiels d’utilisation.
4.3.4.3 Méthode d'évaluation
En ce qui concerne la méthode d'évaluation, nous ferons appel à l'analyse en situation
d'utilisation ainsi qu’au monitorage de l'utilisation. Quatre participants familiers avec
la modélisation par objets typés ont été sollicités pour participer, de manière
individuelle, à l’expérimentation. Chaque séance d'expérimentation a été enregistrée
en audio. Les principaux éléments du verbatim de chacune des séances, le détail du
protocole d'expérimentation ainsi qu’une copie du certificat d’éthique sont présentés à
l'appendice G.
197
4.3.5 Déroulement du test d'utilisabilité
Le test d'utilisabilité consiste à mettre des participants en situation d'utilisation plus
ou moins contrôlée selon des scénarios prédéfinis afin de mesurer l'utilisabilité du
produit (Brangier et Barcenilla, 2003 p. 218). L'exécution du test d'utilisabilité est
guidée par les objectifs d'évaluation de l'efficacité, de l'efficience et de la satisfaction
d'OntoCASE.
La séance d’expérimentation se divise en quatre phases:
- la première phase, la familiarisation, a pour objectif d'initier le participant aux
aspects méthodologiques et informatiques d'OntoCASE. Cette initiation a été
faite par l’expérimentateur;
- la deuxième phase, la formalisation, a pour objectif d'initier le participant au
processus de formalisation et de validation de modèles et de permettre à celui-
ci de réaliser une première manipulation. Un modèle semi-formel
d'expérimentation déjà conçu est alors présenté au participant (voir la
figure 4.1) afin qu'il soit formalisé en ontologie. Cette phase est aussi animée
par l'expérimentateur et les manipulations sont réalisées par le participant;
- au cours de la troisième phase, la modélisation et la formalisation libres, le
participant est invité à modéliser un court texte en langage semi-formel puis à
le formaliser en ontologie à l’aide d’OntoCASE, et ce, avec guidage
uniquement sur demande. Cette phase permet de mesurer la capacité du
logiciel et de la méthodologie à résister aux différentes approches des
participants;
- finalement, la quatrième phase, le debriefing, est consacrée au recueil des
commentaires du participant après son expérimentation d’OntoCASE au cours
d’une courte entrevue semi dirigée.
198
4.3.6 Modèle semi-formel d'expérimentation
Le modèle semi-formel d'expérimentation de la figure 4.1, portant sur le thème du
système solaire, présente le modèle employé lors de la phase 2 de l'expérimentation.
Certaines erreurs de modélisation ainsi que quelques particularités de modélisation
ont été volontairement introduites dans le modèle afin de mesurer l'efficience
d'OntoCASE.
- L'étiquette a illustre un exemple d'erreur de modélisation couramment
observée. Il s'agit d'une erreur de classification du niveau d'abstraction des
"choses" représentées. Il arrive qu'un modélisateur confonde la représentation
d'un objet concret avec l'abstraction de l'objet. Il est vrai que le concept de
Lune est une sorte de Satellite naturel de la Terre, mais, de manière formelle,
ce qui est représenté ici devrait se lire l’objet de type Lune est un exemple (une
instance par le lien I) des "satellites naturels" de la Terre.
- L'étiquette b illustre une autre erreur de représentation, soit la confusion dans
l'utilisation du LienS (sorte de [is-a]) et du LienC (composé ou [part-of]).
Nous pourrions être tentés d’exprimer dans le modèle la proposition que les
Satellites naturels se composent de Satellite naturel de Saturne pour indiquer
la relation de composition entre ces deux concepts, alors qu’il s’agit plutôt
d’une relation de spécialisation, car les satellites naturels de Saturne forment
un sous-ensemble de la classe de tous les satellites naturels.
- Finalement, une autre erreur commise est l'inversion de l'orientation du LienS
(voir l'étiquette c). Les étiquettes d à g soulignent, quant à elles, des points de
précisions qui seront traités plus loin.
Les particularités de ce modèle permettront de mesurer l'efficience d'OntoCASE à:
- repérer les erreurs de subsomption (étiquette c);
- générer de nouvelles connaissances (étiquette f et g);
F
4
L
c
m
u
c
q
l
d
- inter
p
[is-a
]
- séle
c
- désa
m
- cons
t
F
igure 4.1:
M
4
.3.7 Texte
L
e texte à
m
c
onnaissanc
m
atériel d’
u
u
tilisé dans
l
c
onnaissanc
q
ue des p
a
l
'épreuve le
s
d
e ce texte.
p
réter différ
]
(étiquette
b
c
tionner les
n
m
biguïser l
e
t
ruire des p
r
M
odèle sem
i
à
modéliser
m
odéliser d
es déclarati
v
u
n cours en
s
l
e cadre d’a
u
es (Basque
a
rticipants
c
s
différents
c
emment le
s
b
);
n
iveaux d'a
b
e
langage (ét
r
opriétés et
d
i
-formel d'e
x
en MOT et
à
e la figure
4
v
es, procéd
u
s
ciences de
l
u
tres recher
c
et Pudelko,
c
onvenable
m
c
omposants
s
liens de co
m
straction (é
t
iquette c);
d
es normes (
é
x
périmentat
i
à
formalise
r
4
.2 contien
t
u
rales et stra
t
l
’environne
m
c
hes portant
2004). Si
m
m
ent formé
s
procédurau
x
m
position [
p
t
iquette a);
étiquette e).
i
on: l’Objet
r
t
des énonc
é
t
égiques. C
e
m
ent offe
r
t
à
sur la mod
é
m
ple, précis
e
s
à OntoC
A
x
et d'assist
a
p
art-of] et d
e
céleste.
é
s faisant r
é
e
texte est u
n
à
la Télé-uni
é
lisation se
m
et court, il
n
A
SE pourr
a
a
nce d'Onto
1
e
classificat
i
é
férence à
d
n
extrait tiré
versité et a
é
m
i-formelle
d
n
ous a sem
b
a
ient mettre
CASE à pa
r
99
i
on
d
es
du
é
té
d
es
b
lé
à
r
tir
200
Élimination des déchets
L’élimination des déchets se fait de deux façons principales:
l’incinération et l’enfouissement. L’incinération, qui est la méthode la
plus onéreuse, consiste à brûler les déchets dans un four à des
températures de 500 à 1000 degrés Celsius. La matière organique est alors
transformée en gaz tandis que le reste des déchets devient un résidu
(cendres). Cette technique permet d’éliminer entre 85 et 90 % du volume
initial des déchets, mais les résidus doivent obligatoirement être éliminés
dans un lieu d’enfouissement sanitaire.
Figure 4.2: Texte présenté lors de la phase 3 de l’expérimentation.
4.3.8 Bilan et commentaires
En moyenne, les expérimentations ont été d'une durée de deux à trois heures chacune.
Après la séance, chacun des participants a déclaré qu'il serait apte à utiliser
OntoCASE avec un minimum de soutien de l’expérimentateur. Il est à noter que les
principaux points de difficultés dans l’utilisation d’OntoCASE sont associés à
l’ergonomie d’Eclipse. Il est à supposer qu’un utilisateur déjà familier avec
l’environnement Eclipse acquerrait plus aisément les réflexes nécessaires à
l’utilisation d’OntoCASE. Par exemple, les utilisateurs surtout familiers avec le
logiciel MotPlus avaient tendance à réaliser des manipulations d’éléments graphiques
selon l’ergonomie d’utilisation prescrit par le logiciel MotPlus (façon de déplacer les
objets, de varier leur taille) alors que dans OntoCASE ces manipulations doivent être
réalisées de manière différente ce qui pouvait générer une certaine confision chez
l’utilisateur.
Du point de vue de la convivialité, les participants ont particulièrement apprécié le
tableau de bord à la formalisation et à la validation en tant que support au
déploiement de la méthodologie. Ils ont aussi apprécié le mécanisme de rétroaction
des erreurs. Suite aux remarques du premier participant, l'expérimentateur a ajusté
l'étape de formation afin d'y inclure une explication détaillée de la structure de
l'ontologie de référence et la structure de l'ontologie cadre. Cet ajout a été très
201
apprécié des participants subséquents, lesquels ont largement accru leur rapidité à
acquérir de l'autonomie face à l'usage de l'assistant, notamment à l'étape de
désambiguïsation du modèle semi-formel.
Tous les participants ont réussi à formaliser le modèle étalon. Cependant, aucun
d'entre eux n'a pu compléter la modélisation du texte sur l'élimination des déchets.
Bien que court, ce texte contient beaucoup de « pièges » de modélisation, ce qui exige
une longue réflexion. Devant ce constat et pour ne pas retarder indûment la séance
d’expérimentation, nous avons demandé aux participants de formaliser leur modèle
incomplet afin d'utiliser OntoCASE pour produire des interprétations transitoires de
leur modèle. Cet exercice fut très apprécié des utilisateurs puisqu'il faisait déjà
ressortir des erreurs de modélisation, ce qui a servi de guide pour la poursuite de la
modélisation. Par exemple, à l'énoncé "L’élimination des déchets se fait de deux
façons principales: l’incinération et l’enfouissement", trois participants ont modélisé
cet énoncé par l'utilisation de la composition (LienC) entre la procédure élimination
des déchets et les procédures incinération et enfouissement. La formalisation du
modèle et l’interprétation du rapport de validation sémantique ont permis de
déterminer que ces procédures doivent être unies par des liens de spécialisation
(lienS). En effet, l'incinération et l'enfouissement sont bel et bien des sortes de
procédures pour éliminer des déchets et non des sous-procédures.
Un aspect important a été soulevé par l'un des participants concernant l'une des
fonctionnalités de l'assistant. Pendant la modélisation, il est possible de dérouler un
menu à partir d'un objet du modèle afin d'en déterminer le type pour une
désambiguïsation manuelle. Pour ce participant, cette fonctionnalité est très
instructive dans la démarche de réflexion sur l'utilisation de cet objet. Par exemple, le
principe est un objet qui peut se désambiguïser en agent ou en condition. En
déroulant le menu associé, le participant peut désambiguïser cet objet par la sélection
de l'un au l'autre de ces types. La réflexion menant à la sélection du type génère une
foule de questionnements sur le modèle lui-même et sur le contexte d'utilisation de
202
cet objet. Pour ce participant, cette réflexion est une occasion de pousser plus loin
l'expressivité du langage pour ainsi créer de nouvelles façons d'exprimer une
situation. Par exemple, l'association d'un principe à une procédure incite le participant
à se questionner pour déterminer si le principe agit en tant que contrainte ou en tant
que condition.
Cette étude a démontré qu’après une brève introduction, un utilisateur déjà familier
avec la modélisation par objets typés arrivait en une dizaine de minutes à utiliser
l’éditeur de modèles. De plus, tous les participants ont su utiliser correctement les
tableaux de bord à la formalisation et à la validation. Pendant les séances, le logiciel a
réalisé les tâches de manières attendues et aucun imprévu, ou défaillance logiciels
n’est survenu. Pendant les séances, les commentaires des participants étaient plutôt
positifs et plusieurs des commentaires concernaient les différents contextes
d’utilisation potentielle du logiciel.
4.4 Généricité de la méthode de formalisation des systèmes semi-formels
Le dernier volet de la validation est le test de généricité de la formalisation des
systèmes semi-formels. Il s'agit d'un test qui permet de valider le fait que la
méthodologie et l'architecture informatique de l'assistant permettent la formalisation
en ontologies de modèles semi-formels autres que des modèles exprimés en langage
MOT. Nous comptons démontrer la généricité d'OntoCASE par l'intégration du
langage MindMap (Buzan et Buzan, 1994) à OntoCASE.
4.4.1 Métamodèle de MindMap
Tel que déjà mentionné au chapitre 1, le langage MindMap est un langage graphique
semi-formel qui combine des lignes, des images et du texte afin de représenter des
idées et des concepts en vue d'élaborer un discours par l'éclatement d'un thème en
sous-thèmes. Un métamodèle possible de ce langage est présenté à la figure 4.3. Pour
le déroulement de la validation de la généricité, et pour ne pas alourdir initilement
203
l’implantation, seuls les éléments en gris foncé du métamodèle seront traités. À partir
de cette contrainte, la définition d'un modèle (Map) se compose d'un thème (Topic)
qui peut se relier à d'autres thèmes par une association de type sous-thème (subtopic).
Fig
u
u
re 4.3: Métam
o
o
dèle ecore du langage
M
indM
a
a
p. (Tirée de R
e
e
itsma et al., 20
0
0
8).
204
204
4
L
s
F
L
d
d
d
é
r
l
d
d
l
L
4
.4.2 Méth
o
L
e modèle
p
s
emi-forme
l
F
igure 4.4:
M
L
'étape 1, l
a
d
u modèle
d
éfinition d
u
d
éveloppe
m
é
tapes à ve
n
r
eprésentati
o
l
angage se
m
d
'intrant a
u
d
'importatio
l
'import/exp
L
'étape 5
e
o
de d'intégra
t
p
rocédural
d
l
est intégré
à
M
éthode d'i
n
a
conception
semi-forme
u
langage, l'
é
m
ent. Le scé
n
n
ir. L'étape
3
o
n de la dé
fi
m
i-formel
r
u
processus
n
XML-O
W
ort du mod
e
st consac
r
t
ion du lang
a
d
e la figure
4
à
OntoCAS
E
n
tégration d'
d'un éditeu
r
l produisan
t
é
tape 2 sert
n
ario de test
3
, concevoir
i
nition du l
a
r
eprésentée
de l'étap
e
W
L serva
n
èle semi-fo
r
r
ée à la c
o
a
ge
M
indM
a
4
.4 représen
t
E
.
u
n nouveau
r
de modèle
,
t
des docu
m
à produire
u
peut être u
t
l'ontologie
a
ngage semi
-
dans l’ont
o
e
4, leque
l
n
t à la p
r
r
mel du for
m
o
nception
d
a
p à OntoC
A
te la métho
d
langage so
u
,
est réalisé
e
m
ents inter
o
u
n scénario
d
t
ilisé ou mo
du langage
s
-
formel en
o
o
logie du
l
l
consiste
r
oduction
d
m
alisme X
M
d
es règles
A
SE
d
e par laqu
e
u
rce à Onto
C
e
s'il n'exist
e
o
pérables.
À
d
e test qui
g
difié à l'un
e
s
emi-forme
l
o
ntologie. L
a
l
angage se
m
à concevo
i
d
u code
J
M
L au for
m
de désamb
2
e
lle un lang
a
C
ASE.
e
aucun édit
e
À
partir de
g
uidera le fu
t
e
ou l'autre
d
l
, est l'étape
a
définition
m
i-formel s
i
r un mod
u
J
ava dédié
m
alisme O
W
iguïsation,
2
05
a
ge
e
ur
la
t
ur
d
es
de
du
e
r
t
u
le
à
W
L.
de
f
l
e
4
N
l
u
u
p
p
l
(
c
f
ormalisatio
n
l
angage se
m
e
st assurée
p
4
.4.3 Défini
t
N
ous avon
s
l
’associatio
n
u
nissent. Sa
u
n éclatem
e
p
as de sym
b
p
rocédural
(
l
a distincti
o
(
généralisat
i
c
omporte u
n
a) Un
e
mote
u
b
) Po
u
comp
r
rédige
n
ainsi qu
e
m
i-formel. F
i
p
ar l'exécuti
o
t
ion du lang
s
vu que
l
n
de sous-t
h
grammaire
e
nt du thèm
e
b
ole particul
i
(
voir la figu
r
o
n entre u
n
i
on) ou d'h
o
n
plus grand
e
automobil
e
u
r peut être
d
u
r écrire un
e
r
ises dans l
a
r, corriger e
t
e
de l'ontol
o
i
nalement, l
o
n du scéna
r
age semi-fo
r
l
e vocabul
a
h
èmes pour
impose une
e
principal
e
i
er faisant r
é
r
e 4.5). De
m
n
e associati
o
o
lonymie (
c
niveau d’a
m
e
se compos
e
d
iesel, à esse
n
e
thèse, il f
a
a
procédur
e
t
réviser.
o
gie de tra
n
'étape 6, la
r
io de tests.
r
mel et pro
d
a
ire du lan
g
représenter
lecture du
m
e
n sous-thè
m
é
férence à d
e
m
ême, auc
u
o
n d'hypon
y
c
omposition
)
m
biguïté que
e
de 4 roues
n
ce ou élect
r
ut faire une
e
d’écriture
n
sformation
validation
d
d
uction du s
c
g
age
M
ind
M
des conce
p
m
odèle de la
m
es. Le lan
g
es connaiss
a
u
ne symboli
q
y
mie (spéc
i
)
. En ce s
e
e
le langage
M
, d'une carr
o
t
rique.
recherche
e
d'un docu
m
selon les
d
u processu
s
c
énario de t
e
M
ap utilise
p
ts et les re
l
gauche ver
s
g
age
M
ind
M
a
nces de ty
p
q
ue particul
i
i
alisation),
d
e
ns, le lang
M
OT.
o
sserie et d'
u
e
t aussi fair
e
m
ent, soit
f
2
définitions
s
d'intégrati
o
e
st
e
le thème
l
ations qui
l
s
la droite a
v
M
ap ne poss
è
p
e déclaratif
i
ère ne per
m
d
'hyperony
m
age
M
ind
M
u
n moteur.
U
e
des activit
é
f
ai
r
e un pl
a
2
06
du
o
n,
et
l
es
v
ec
è
de
ou
m
et
m
ie
M
ap
U
n
é
s
a
n,
207
Figure 4.5: Modèles MindMap sur le thème de l'automobile et le thème de la
rédaction d'une thèse.
Dans le contexte de la présente démonstration, les exemples de la figure 4.5 servent
de scénarios de tests pour l'intégration du langage MindMap dans OntoCASE. Les
composants d'OntoCASE devront être en mesure d'assister l'utilisateur dans la
désambiguïsation des connaissances procédurales et déclaratives associées à un thème
ou un sous-thème, ainsi qu'à la désambiguïsation des associations d'hyponymie,
d'hyperonymie et d'holonymie.
4.4.4 Concevoir l'ontologie du langage semi-formel
Nous avons vu dans la définition du langage que le métamodèle comporte un Thème
pouvant se développer en Sous-thèmes. En termes de métamodèle d'entité-relation, la
structure d'un modèle comporte le thème (l'entité) et le sous-thème lié par
l'association (la relation) (voir le tableau 4.6 lignes 1, 4 et 7).
Tableau 4.6
Ontologie du langage MindMap dans le formalisme OWL-N3
01. :MM_Structure
02. rdf:type owl:Class ;
03. rdfs:subClassOf owl:Thing .
04. :MM_Association
05. rdf:type owl:Class ;
06. rdfs:subClassOf :MM_Structure.
07. :MM_Theme
08. rdf:type owl:Class ;
09. rdfs:subClassOf :MM_Structure.
10. :MM_estLaDestination
11. rdf:type owl:ObjectProperty ;
12. rdfs:domain :MM_Theme ;
13. rdfs:range :MM_Association ;
14. owl:inverseOf
:MM_themeDestination.
15. :MM_estLaSource
16. rdf:type owl:ObjectProperty ;
17. rdfs:domain :MM_Theme ;
18. rdfs:range :MM_Association ;
19. owl:inverseOf :MM_themeSource.
20. :MM_estNonDetermine
21. rdf:type owl:FunctionalProperty
, owl:DatatypeProperty ;
22. rdfs:domain :MM_Structure ;
23. rdfs:range xsd:boolean .
24. :MM_etiquette
25. rdf:type owl:FunctionalProperty
, owl:DatatypeProperty ;
26. rdfs:domain :MM_Structure ;
27. rdfs:range xsd:string .
28. :MM_identifiant
29. rdf:type owl:FunctionalProperty
, owl:DatatypeProperty ;
30. rdfs:domain :MM_Structure ;
31. rdfs:range xsd:string .
32. :MM_ontoRefStereotype
33. rdf:type owl:DatatypeProperty;
34. rdfs:domain :MM_Structure ;
35. rdfs:range xsd:string .
36. :MM_themeSource
37. rdf:type owl:FunctionalProperty
, owl:ObjectProperty ;
38. rdfs:domain :MM_Association ;
39. rdfs:range :MM_Theme ;
owl:inverseOf :MM_estLaSource .
40. :MM_themeDestination
41. rdf:type owl:FunctionalProperty
, owl:ObjectProperty ;
42. rdfs:domain :MM_Association ;
43. rdfs:range :MM_Theme ;
44. owl:inverseOf
:MM_estLaDestination.
208
En plus de ces trois classes, l'ontologie comporte un ensemble de propriétés
définissant les relations existantes entre le thème et l'association. Ainsi les propriétés
MM_estLaDestination, MM_estLaSource, MM_themeSource MM_themeDestination (voir les
lignes 10, 15, 36, 40) définissent les thèmes qui sont à la source et à la destination
d'une association. Les propriétés MM_etiquette et MM_identifiant (voir les lignes 24 et
28) sont de type chaîne de caractères et permettent d'entreposer le nom et l'identifiant
unique associé à chacun des thèmes et associations. Les propriétés MM_estNonDetermine
et MM_ontoRefStereotype (voir les lignes 20 et 32) sont utilisées à l'étape de
désambiguïsation.
4.4.5 Conception du module d'import/export
Tel qu'indiqué à la section 3.2.2, p.160, la conception du module d'importation
implique l'utilisation du code Java de l'ontologie du langage semi-formel ainsi que le
code Java EMF généré à partir du modèle ecore du langage semi-formel. Le
tableau 4.7 présente un exemple de conversion XMI à OWL des modèles de la
figure 4.5. La ligne 3 de a représente la définition du thème automobile associé aux
sous-thèmes; 4 roues (à la ligne 4), un moteur (à la ligne 5) et une carrosserie (à la
ligne 6). Converti en OWL (voir le tableau 4.7b), le triplet
Automobile/subtopics/4_roues est traduit par la création des deux classes Automobile_1
(voir la ligne 1) et _4-roues-2 (voir la ligne 7) qui sont de type MM_Theme, puis en une
classe Automobile-1_association__4-roues-2 (voir la ligne 13) de type MM_Association. Il
en va de même pour le reste des composants du modèle.
209
Tableau 4.7
Représentation XMI (a) et OWL (b) du modèle MindMap sur le thème de l'automobile
a)
01. <?xml version="1.0" encoding="UTF-8"?>
02. <mindmap:map xmlns:mindmap="http://www.example.org/mindmap" title="un test">
03. <rootTopics name="Automobile" subtopics="#//@map/@rootTopics.1
#//@map/@rootTopics.2 #//@map/@rootTopics.6"/>
04. <rootTopics name="4 roues"/>
05. <rootTopics name="un moteur" subtopics="#//@map/@rootTopics.4
#//@map/@rootTopics.3 #//@map/@rootTopics.5"/>
06. <rootTopics name="Moteur diésel"/>
07. <rootTopics name="Moteur à essence"/>
08. <rootTopics name="Moteur électrique"/>
09. <rootTopics name="une carrosserie"/>
10. ...
11. </mindmap:map>
b)
01. :Automobile-1
02. rdf:type metaMM:MM_Theme ;
03. metaMM:MM_estLaSource :Automobile-1_association_un-moteur-3 , :Automobile-
1_association_une-carrosserie-7 , :Automobile-1_association__4-roues-2 ;
04. metaMM:MM_estNonDetermine "true"^^xsd:boolean ;
05. metaMM:MM_etiquette "Automobile"^^xsd:string ;
06. metaMM:MM_identifiant "Automobile-1"^^xsd:string .
07. :_4-roues-2
08. rdf:type metaMM:MM_Theme ;
09. metaMM:MM_estLaDestination :Automobile-1_association__4-roues-2 ;
10. metaMM:MM_estNonDetermine "true"^^xsd:boolean ;
11. metaMM:MM_etiquette "4 roues"^^xsd:string ;
12. metaMM:MM_identifiant "_4-roues-2"^^xsd:string .
13. :Automobile-1_association__4-roues-2
14. rdf:type metaMM:MM_Association ;
15. metaMM:MM_estNonDetermine "true"^^xsd:boolean ;
16. metaMM:MM_etiquette "Automobile est associé(e) à 4 roues"^^xsd:string ;
17. metaMM:MM_identifiant "Automobile-1_association__4-roues-2"^^xsd:string ;
18. metaMM:MM_themeDestination :_4-roues-2 ;
19. metaMM:MM_themeSource :Automobile-1 .
4.4.6 Adapter les ontologies
L'ajout d'un nouveau langage semi-formel à traiter dans OntoCASE implique une
adaptation de l'ontologie de transformation et de ses sous-ontologies. Présentée à la
figure 4.6, l'intégration du nouveau langage impose des changements structurels de
classes (voir en a les classes qui sont surlignées), l'ajout de nouveaux stéréotypes de
désambiguïsation (voir en b) dans l'ontologie de traitement des ambiguïtés, ainsi que
l’ajout de nouvelles propriétés (voir en c).
Pour terminer l'intégration du formalisme de MindMap, il est nécessaire d'ajuster les
règles de conversion à la sémantique du langage. Dans le formalisme de MindMap,
une association entre deux thèmes peut représenter une composition (holonyme), une
210
spécialisation (hyponyme) ou encore une généralisation (hyperonyme). Les relations
d'holonymie et d'hyponymie ont déjà été définies à l'étape de définition du langage
MOT. Il reste donc à intégrer les règles nécessaires à la conversion de l'aspect
sémantique de l'hyperonyme. Le tableau 4.8 présente la règle SWRL de conversion,
entre deux connaissances déclaratives, d'un hyperonyme en propriété owl:subClassOf
d'OWL. Une règle du même genre a été conçue pour le traitement d'une connaissance
procédurale.
a) les classes b) les individus
b) les propriétés
Figure 4.6: Structure de l'ontologie de transformation après l'intégration des éléments
structurels nécessaires à la transformation d'un modèle MindMap.
211
Tableau 4.8
Règles de conversion pour un hyperonyme
01. Rule-02-d_Creation_subClassOf_INV_Declaratif
02. oRef:OR_Relation_Hyperonyme(?lg) ^
03. oRef:OR_connSource(?lg, ?src) ^
04. oRef:OR_connDestination(?lg, ?dest) ^
05. oRef:OR_Entite_Concept_Classe(?src) ^
06. oRef:OR_Entite_Concept_Classe(?dest) ^
07. oRef:OR_identifiant(?src, ?nomSrc) ^
08. oRef:OR_identifiant(?dest, ?nomDest) ->
09. swrlbi:invoker("OWLEstUneSousClasseDeCmd", ?nomDest, ?nomSrc) ^
10. swrlbi:invoker("OWLSupprimerSuperClasseDeCmd", "owl:Thing", ?nomDest) ^
11. swrlbi:invoker("OWLSupprimerSuperClasseDeCmd",
"metaDom:MD_Declarative_Concept", ?nomDest)
4.4.7 Exécuter le scénario de test
La validation est la dernière étape de l'intégration d'un nouveau formalisme. La
conception d'un scénario de test permet de mesurer l'efficacité du dispositif à réaliser
la tâche. Bien que normalement beaucoup plus élaboré que dans une modélisation en
situation réelle, le scénario proposé ici permet de tirer plusieurs conclusions. Tout
d'abord, à la lecture du tableau 4.9 et de la figure 4.7, il est constaté que la sémantique
du modèle d'origine (voir la figure 4.5) est préservée. Ensuite, l'intégration d'une
nouvelle sémantique (l'hyperonyme pour le présent cas) à traiter par l'ontologie de
transformation s'implante assez facilement par la conception d'une nouvelle règle
SWRL et par quelques ajouts aux ontologies associées à l'ontologie de
transformation.
212
Tableau 4.9
Rapport de validation sémantique
a) validation sémantique du modèle descriptif
----------Début du processus de validation sémantique-------------
4 roues est une sorte de (metaDom:MD_Declarative_Concept)
Automobile est une sorte de (metaDom:MD_Declarative_Concept)
Automobile se compose de 4 roues
Automobile se compose de un moteur
Automobile se compose de une carrosserie
Moteur diésel est une sorte de un moteur
Moteur à essence est une sorte de un moteur
Moteur électrique est une sorte de un moteur
un moteur est une sorte de (metaDom:MD_Declarative_Concept)
une carrosserie est une sorte de (metaDom:MD_Declarative_Concept)
b) validation sémantique du modèle procédural
----------Début du processus de validation sémantique-------------
Corriger est une sorte de (metaDom:MD_Procedurale_Procedure)
Faire un plan est une sorte de (metaDom:MD_Procedurale_Procedure)
Faire une recherche est une sorte de (metaDom:MD_Procedurale_Procedure)
Faire une recherche est une sorte de Rédiger une thèse
Rédiger est une sorte de (metaDom:MD_Procedurale_Procedure)
Rédiger une thèse est une sorte de (metaDom:MD_Procedurale_Procedure)
Rédiger une thèse est une sorte de Écrire un document
Réviser est une sorte de (metaDom:MD_Procedurale_Procedure)
Écrire un document est une sorte de (metaDom:MD_Procedurale_Procedure)
Écrire un document se compose de Corriger
Écrire un document se compose de Faire un plan
Écrire un document se compose de Rédiger
Écrire un document se compose de Réviser
Dans le présent contexte, le module de validation syntaxique ne peut pas être
intégralement utilisé, car il a été conçu pour la validation de modèle MOT.
Cependant, le module de validation peut être utilisé pour restaurer le modèle source
dans le formalisme de MOT (voir la figure 4.7) offrant ainsi une interprétation en
langage MOT du modèle d'origine.
a
b
F
d
4
D
v
a
) restauration
b
) restauration
F
igure 4.7:
R
d
e la rédact
i
4
.5 Conclus
i
D
ans ce ch
a
v
érifiée en
s
La
g
qu’
O
strat
é
métr
tests
coh
é
L’er
g
utili
s
info
r
for
m
du modèle de
s
du modèle pr
o
R
estauratio
n
i
on d'une th
è
i
on
a
pitre, nous
oumettant
O
g
énéralité
d
O
ntoCASE
é
giques, dé
iques d’effi
c
unitaires,
d
é
rence ;
g
onomie, a
f
s
ateurs autr
e
r
matique of
f
m
alisation, et
s
criptif
o
cédural
n
dans le for
m
è
se (b).
avons voul
u
O
ntoCASE à
d
es types
d
permet la
claratives
e
c
acité ont é
t
d
e tests d’i
n
f
in de valid
e
e
s que le c
o
f
re toutes le
s
ce, de man
i
m
alisme de
u
démontre
r
une validat
i
d
e connaiss
a
formalisati
o
e
t factuelle
s
t
é matériali
s
n
tégrations,
e
r que la
m
o
ncepteur
d
s
fonctionna
l
i
ère convivi
a
MOT du th
r
que l’hyp
o
i
on selon :
a
nces à fo
r
on de co
n
s
. Pour eff
e
s
és par la p
r
des tests s
y
m
éthodologi
e
d
e la métho
d
lités nécess
a
a
le. La vali
d
ème de l'au
t
o
thèse de c
e
r
maliser, a
fi
n
naissances
fe
ctuer la
v
ro
d
uction d
e
y
stémiques
e
soit expl
o
dologie et
q
a
ires à la ré
a
d
ation de l’e
r
2
t
omobile (a
)
e
tte thèse a
é
fi
n de véri
f
procédural
v
alidation,
d
e
scénarios
et de tests
o
itable par
d
q
ue l’assist
a
a
lisation d’
u
r
gonomie a
é
2
13
)
et
é
té
f
ier
es,
d
es
de
de
d
es
a
nt
u
ne
é
té
214
réalisée par la mesure de l’efficience et de la satisfaction lors d’une
expérimentation en laboratoire ;
La généricité des langages semi-formels utilisés pour la formalisation, afin de
valider que la méthodologie permet le passage du degré semi-formel au degré
formel d’une représentation sans altérer la sémantique qui lui est associée.
Cette validation a été établie en intégrant un autre langage semi-formel, le
langage MindMap, à OntoCASE.
Chapitre 5
CONCLUSION ET DISCUSSION
Le but de cette thèse était de produire une méthodologie d'ingénierie ontologique se
composant de méthodes et d'outils informatiques intelligents afin d'assister l'ingénieur
de la connaissance et l'expert de contenu à concevoir une ontologie à partir d‘une
conceptualisation semi-formelle d'un domaine contenant des représentations de
connaissances déclaratives, procédurales, stratégiques et factuelles.
Dans ce chapitre, nous rappelons d’abord les principales réalisations issues de notre
travail afin d’atteindre ce but. Nous poursuivons par la présentation des contributions
scientifiques et des limites de cette recherche. Nous concluons ce chapitre par une
discussion sur les perspectives de recherche entrouvertes par cette thèse.
5.1 Réalisations
Les principaux concepts nécessaires à la réalisation de la thèse ont été présentés au
premier chapitre. Ceux-ci concernent les fondements théoriques en représentation des
connaissances, en modélisation des connaissances, en classification des ontologies et
en assistance logicielle. Nous avons notamment présenté quelques langages semi-
formels et formels utilisés en représentation des connaissances et avons discuté de
concepts liés à la métamodélisation et à la transformation de modèles, de méthodes
d'ingénierie ontologique ainsi que de principes de conception d’un système
d’assistance informatique.
La méthodologie d'OntoCASE développée dans le cadre de la thèse inclut des
constituants méthodologiques, représentationnels et computationnels. Au cœur du
216
volet représentationnel de la transformation des modèles, réside l'ontologie de
transformation, composée elle-même de deux ontologies, soit l'ontologie de référence
responsable de la conversion des modèles semi-formels en ontologie et l'ontologie
cadre qui élargit l'expressivité de l'ontologie du domaine pour y inclure la
représentation de connaissances déclaratives, procédurales et stratégiques. D'autres
ontologies de même que des bases de règles composent l'ontologie de transformation,
telles que l'ontologie du langage semi-formel, la base de règles de transformation, la
base de règles à la désambiguïsation et la base de règles à l'identification des erreurs.
Quant au volet méthodologique d’OntoCASE, il comprend quatre méthodes : une
méthode d’intégration d’un nouveau langage semi-formel à la méthodologie, une
méthode de modélisation d’un modèle semi-formel, une méthode de transformation
du modèle semi-formel en ontologie et une méthode de validation syntaxique et
sémantique de l’ontologie cible. Chacune de ces méthodes, sauf la première, est
assistée par une application informatique et représentée par l’ontologie de
transformation.
La démarche de construction d'OntoCASE que nous avons adoptée a été divisée en
trois phases. La phase 1, la mise en place des composants d'OntoCASE, avait pour
objectif l'élaboration des outils, processus et ontologies nécessaires au
fonctionnement d’OntoCASE. La phase 2, l'agrégation des composants, a consisté à
construire l’architecture du système de support à la méthodologie d’OntoCASE.
Finalement, la phase 3, la consolidation, a été marquée par la construction de bancs
d’essais permettant l’exécution de scénarios de tests unitaires, d’intégration, de
systèmes et d’incohérences nécessaires à la vérification du bon fonctionnement des
composants informatiques. Ces tests ont aussi été utilisés pour la validation de
l'efficacité, de l'efficience et de la satisfaction d'OntoCASE.
Les résultats concernant la méthodologie d’OntoCASE ont été présentés au chapitre
2, alors que ceux relatifs à la validation d’OntoCASE l’ont été au chapitre 4. Ces
résultats ont permis de confirmer l'hypothèse de cette thèse à savoir qu’à partir d’un
217
modèle de connaissances exprimé dans un langage semi-formel représentant des
connaissances déclaratives, procédurales, stratégiques, au niveau abstrait et concret,
il est possible de formaliser ce modèle en ontologie de manière automatique ou semi-
automatique d’une manière syntaxiquement et sémantiquement valide. La
confirmation de cette hypothèse a été rendue possible grâce à l'implantation de
scénarios de tests visant à évaluer l’efficacité d’OntoCASE et à une expérimentation
en laboratoire ayant permis d’évaluer l'efficience et la satisfaction auprès d’usagers
représentant le public cible. L’intégration d’un autre langage semi-formel (MindMap)
à OntoCASE tend à démontrer que la méthodologie comporte une certaine généricité.
Trois outils documentaires ont été produits par ces travaux. Un guide du langage de
modélisation par objets typés (voir l’appendice A) apporte un support à l'activité de
modélisation semi-formelle MOT pour l'ingénieur de la connaissance et pour l'expert
de domaine. Le deuxième document, le catalogue de la sémantique formelle (voir
l’appendice B), sert de guide de désambigüisation et de formalisation d'un modèle
MOT en ontologie OWL. Il permet donc à l’ingénieur de documenter la façon dont
cette étape permet de codifier le modèle semi-formel en ontologie et peut servir, le
cas échéant, à supporter une codification manuelle du modèle semi-formel advenant
une indisponibilité de l’assistant informatique. Finalement, les éléments pour guider
la modélisation semi-formelle à l’aide de concepts ontologiques (voir l’appendice E)
est un outil mis à la disposition de l'ingénieur et de l'expert afin de les guider à l’étape
de la conception du modèle semi-formel en vue d'en faire une ontologie
représentative et opérationnelle du domaine conceptualisé.
En résumé, du point de vue des sciences cognitives, les réalisations de cette thèse sont
les suivantes :
- une ontologie représentationnelle et opérationnelle du domaine de la
représentation des connaissances;
218
- une méthode de transformation de modèles de connaissances semi-formels en
ontologies;
- une méthode de représentation de connaissances tant déclaratives,
procédurales que stratégiques en ontologie selon le niveau abstrait et le niveau
factuel;
- une méthode qui, lors du processus de formalisation, gère les ambiguïtés
intrinsèquement contenues dans la sémantique du modèle semi-formel;
- un ensemble de documents qui servent de guide à la conception d'un modèle
semi-formel dans la perspective de sa transformation subséquente en
ontologie.
Du point de vue informatique, les réalisations de cette thèse sont les suivantes:
- un outil intelligent et intégré dans l'environnement Eclipse apte à assister un
ingénieur ontologique et un ou des experts du domaine dans la conception
d'une ontologie à partir d'un modèle semi-formel;
- un mécanisme de construction automatique d'ontologies à partir d'une base de
connaissances de type OWL et SWRL;
- un éditeur de modèles MOT (eLi) dans l'environnement Eclipse selon les
principes de l'architecture conduite par les modèles et d’EMF/GMF;
- l’intégration dans Eclipse des bibliothèques de codes sources de Protégé pour
la manipulation d'ontologies, de règles SWRL et d’interfaces aux engins
d'inférences Pellet et Jess;
- des outils d'importation/exportation de modèles de l'espace de modélisation
MOF dans l'espace de modélisation OWL;
- la substitution avec succès du MOF par OWL/SWRL en tant que méta-
métamodèle dans l'utilisation de l’architecture conduite par les modèles pour
la transformation de modèles semi-formels;
219
- un outil intelligent qui automatise la conversion et la validation du modèle
semi-formel en ontologie et qui semi-automatise le processus de
désambiguïsation des connaissances exprimées de manière semi-formelle;
- un outil intelligent de production de texte informel à partir d'une
conceptualisation exprimée de manière semi-formelle.
5.2 Contributions
Nous allons maintenant présenter les contributions de cette thèse aux domaines
suivants: la représentation des connaissances, l'ingénierie ontologique et la gestion
des connaissances.
5.2.1 Apports en représentation des connaissances
Notre recherche a permis de mettre au point une ontologie de transformation qui, sur
le plan représentationnel, présente une conceptualisation possible du domaine de la
représentation de la connaissance et qui, sur le plan opérationnel, permet la réalisation
d'inférences automatiques dédiées à la formalisation en ontologie de divers types de
connaissances. La structure de l'ontologie de transformation, quoique développée de
manière empirique, révèle par son opérationnalité confirmée (voir les mesures de
l'efficacité d’OntoCASE à la section 4.2 et à l'appendice D), que les éléments qui la
composent sont une représentation possible du domaine de la représentation des
connaissances. La multitude et la variété de scénarios de tests réalisés ont permis de
démontrer que l'ontologie de transformation est opérationnellement valide.
Basée sur un métamodèle de type entité-relation, l'ontologie de référence, qui est une
composante de l’ontologie de transformation, a une structure qui représente la réalité
selon les niveaux objectif (concret) et subjectif (abstrait), chacun catégorisé selon les
trois types de connaissances: déclaratif, procédural et stratégique. Il a été démontré
par l'intégration d’un formalisme de type MindMap que la structure interne de
220
l'ontologie de référence résiste bien à l'incorporation d’un nouveau langage semi-
formel à la méthodologie.
En outre, notre recherche a permis de mettre au point une ontologie de transformation
permettant d’opérationnaliser l’activité de désambiguïsation, de classification et de
formalisation en ontologie d’un modèle exprimé en langage semi-formel. La structure
interne de l’ontologie de référence et de l’ontologie cible, composants de l’ontologie
de transformation, s’inspire des travaux réalisés pour la conception du langage MOT
dont l’un des objectifs est d’intégrer en un seul langage la possibilité de modéliser
divers types de modèles, tels que des modèles factuels, conceptuels, procéduraux,
prescriptifs ainsi que des modèles de type processus et méthodes. Ainsi, la
classification du vocabulaire à la base de la modélisation de modèles UML (de type
diagrammes de classe, de cas d’utilisation, d’état) ou encore, la classification du
vocabulaire du langage BPMN (voir la section 3.1.4.3), ainsi que l’implantation du
langage MindMap dans la méthodologie OntoCASE (voir la section 4.4), constituent
une validation supplémentaire, et ce de manière formelle, que le langage MOT
possède réellement les qualités d’intégration de plusieurs types de modèles dont la
représentation est assurée par un langage unifié. Cette conclusion est un apport
important à la représentation des connaissances puisqu’elle garantit que MOT tient
une place privilégiée dans l’arsenal des outils disponibles pour la représentation
unifiée de connaissances de type hétérogène.
En ce qui a trait à l’activité de modélisation des connaissances, OntoCASE est un
outil d’assistance à la modélisation et à la réflexion sur le domaine modélisé. Il
permet de réaliser une validation de nature sémantique et syntaxique du modèle semi-
formel et facilite ainsi la détection d’ambigüités ou d’erreurs de modélisation. La
rétro-génération du modèle semi-formel et la génération du contenu du modèle sous
forme textuelle à partir de l’ontologie sont des caractéristiques de rétroaction qui sont
innovantes en termes d’instrumentation de l’activité de modélisation des
connaissances. Finalement, la méthodologie permet à un concepteur de modèles
221
semi-formels, qui serait peu familier avec OWL et les représentations de type
ontologiques, de contribuer activement à la construction d’ontologies.
5.2.2 Apports en ingénierie ontologique et aux applications du Web sémantique
Du point de vue de l'ingénierie ontologique, ce travail de thèse aura permis de
produire une méthodologie permettant d'exprimer, dans un langage déclaratif et
formel comme OWL, des connaissances déclaratives, procédurales, stratégiques et
factuelles issues d’une conceptualisation exprimée en langage semi-formel.
Rappelons qu’un gain de qualité provient de la méthode d'élicitation privilégiée dans
OntoCASE, qui utilise une représentation semi-formelle de la connaissance, et qui,
comme il a été démontré dans d'autres recherches, stimule la créativité et libère la
charge cognitive pour l'expression de l'expertise du domaine plutôt que de l'occuper à
formaliser la connaissance. De plus, un gain de productivité nous semble acquis par
l'automatisation de la formalisation et du mécanisme de validation d'OntoCASE.
Assurément, l'automatisation simplifie le processus de formalisation qui, exécuté en
quelques secondes ou minutes, facilite le travail de l'ingénieur de la connaissance.
Cette qualité est importante pour un ingénieur qui aurait à formaliser plusieurs
dizaines de modèles semi-formels. Comme il a été mentionné par un des participants
à l’expérimentation « Pour avoir des ontologies de domaines, on doit soit les faire
nous-mêmes, soit les transformer de modèles semi-formels déjà existants. Et c’est là
qu’OntoCASE se positionne. »
En outre, basé sur une architecture conduite par les modèles, OntoCASE offre une
méthode pour intégrer des formalismes autres que celui de MOT à la méthodologie.
Bien sûr, l'intégration d'un nouveau formalisme implique toutefois une connaissance
approfondie en ingénierie ontologique, notamment dans la conception de systèmes à
base de règles SWRL ainsi que dans la programmation de l'environnement de
développement Eclipse demandant l’intervention d’un spécialiste en développement
informatique.
222
La manière dont est exécutée la création automatique d'ontologies est aussi une
caractéristique innovante d’OntoCASE. L'architecture de commandes de type builtIn
permet l'utilisation de commandes SWRL aptes à créer des ontologies, ce qui d’après
notre revue de littérature, n’était pas disponible avant OntoCASE. Ce catalogue de
commandes interopérables peut être réutilisé et complété dans un contexte autre que
celui d'OntoCASE. En effet, l’interopérabilité de SWRL et du langage Java qui sert à
implanter les commandes builtIn font de ce catalogue un outil pouvant être réutilisé
dans n’importe quel environnement utilisant le langage SWRL.
Du point des vues des applications pour le Web sémantique, notre travail nous semble
également apporter une contribution significative. Par exemple, pour l’environnement
TeleLearning Operating System TELOS (www.lornet.ca), qui est un système
d’exploitation à base d’ontologies, OntoCASE pourrait permettre de produire des
ontologies dans le cadre de la conception de cours, notamment pour faire le
référencement sémantique des ressources d’enseignement et d’apprentissage (REA)
par une modélisation semi-formelle. Il pourrait aussi permettre la récupération de
modèles semi-formels déjà existants afin d’assurer une formalisation et une
pérennisation des connaissances déjà élicitées
5.2.3 Apports en gestion des connaissances
En gestion des connaissances, la semi-automatisation du processus de transformation
de modèles semi-formels de connaissances et le mécanisme de désambiguïsation
intégrés dans OntoCASE permettent à l'ingénieur ontologique d'offrir aux experts de
domaine un outil d'élicitation des connaissances qui possède une expressivité souple,
intuitive et adaptée à une réalité de terrain parfois complexe, telle que peut l’être un
contexte d’entreprise par exemple. De plus, cette méthodologie permet le traitement
de modèles semi-formels qui seraient déjà existants dans une organisation, permettant
ainsi une incorporation aux systèmes de gestion de connaissances déjà en place.
223
Le mécanisme de validation d’OntoCASE apporte également une contribution
significative au domaine de la gestion des connaissances. Il permet de pré-valider de
manière opérationnelle l'ontologie conçue. Dans le cadre d’une gestion de projets de
systèmes à base de connaissances, par exemple, cette pré-validation permettrait ainsi
d'entamer de manière plus précoce l'étape d'élicitation de la connaissance et de
repousser à plus tard l'étape d'implantation informatique de l'ontologie de domaine,
sachant que les ontologies produites sont déjà pré-validées de manière opérationnelle,
minimisant ainsi les risques liés à l'opérationnalisation des ontologies. Cela permet
une distribution plus équilibrée dans le temps des ressources humaines et matérielles,
ce qui, en termes de gestion de projets, est un réel gain.
En élicitation des connaissances, le mécanisme de validation peut s’avérer aussi très
utile comme assistant à la validation du contenu du domaine auprès des experts,
notamment par le réaménagement par l’ingénieur du modèle semi-formel sur la base
des résultats du processus de validation, ce qui lui permet de mieux cibler les
questions à poser aux experts en entrevue.
5.3 Limites de la recherche
Nous discutons de trois limites de la recherche : des limites en représentation des
connaissances, des limites informatiques et des limites liées au volet méthodologique
d’OntoCASE.
5.3.1 Limites en représentation des connaissances
Il est à anticiper que la structure interne de l'ontologie de référence subirait des
changements plus importants advenant l'intégration d’un langage semi-formel plus
complexe, par exemple le BPMN, ou encore d’un langage qui serait construit selon un
métamodèle autre que l'entité-relation comme pourraient l'être des systèmes de
représentation de connaissance à base de règles, de schémas ou de scripts. De même,
un langage qui représenterait des connaissances en utilisant des logiques d’ordre
224
supérieur, modales, probabilistes ou floues imposerait de sortir du cadre de la logique
de descriptions et donc de la cible OWL-DL développée dans cette thèse.
L'opérationnalité des ontologies constituantes de l'ontologie de transformation a été
démontrée. Cependant, la terminologie employée pour l'identification des classes et
des propriétés de l'ontologie de référence et de l'ontologie cadre gagnerait à être
comparée à d'autres ontologies de haut niveau telles que SUMO, CYC ou l'ontologie
KR de Sowa, ce qui aurait dépassé le cadre de nos travaux.
Certaines règles de « bonnes pratiques » de la DL ne sont pas respectées dans la
construction de l’ontologie cible. Pour l’harmoniser aux bonnes pratiques, il faudrait
utiliser rdf:typeOf au lieu de rdf:subClassOf pour relier les classes de l’ontologie
cible aux classes l’ontologie cadre et utiliser, pour des cas précis, l’owl:Restriction
au lieu de rdfs:subPropertyOf pour définir le domaine et l’image des
sous-propriétés.
5.3.2 Limites informatiques du prototype
Certaines limites d'OntoCASE ont été observées. Bien qu’il ait été validé par une
expérimentation en laboratoire, le logiciel n’a pas subi l’épreuve d’un déploiement à
large échelle. Pour l’heure, nous pouvons le considérer comme un prototype stable et
opérationnel. Même s’il a été utilisé et amélioré durant toute la période de la
recherche, certains aspects ergonomiques, notamment pour l’édition des modèles,
sont à améliorer. L’ergonomie de l’édition des modèles, si elle était améliorée,
offrirait une réelle valeur ajoutée à eLi, notamment en ce qui concerne la
manipulation des fichiers modèles, l’accès au contenu du modèle afin qu’il soit
réutilisé dans de multiples diagrammes, l’édition des propriétés associées à un objet
du modèle, la manipulation des objets dans les sous-modèles et l’accès au
référencement de ressources externes en lien avec un objet du modèle.
225
Concernant le volet computationnel, une certaine lenteur de l'application à exécuter
les règles de désambiguïsation et de conversion a été observée qui pourrait sans nul
doute être améliorée. De plus, des fuites de mémoire (memory leak) dans l'utilisation
des bibliothèques de code source de Protégé nécessitent que l'application soit
occasionnellement redémarrée. L'ajout de fonctionnalités permettant de corriger ces
problèmes nécessiterait une connaissance approfondie de l'environnement de
développement Eclipse et des produits PDE, EMF et GMF, dont la courbe
d'apprentissage est assez lente.
5.3.3 Limites du volet méthodologique d’OntoCASE
Le volet méthodologique est difficilement exécutable sans l'utilisation de l'assistant
informatique. Bien que conçues dans cette optique et soutenues par la rédaction des
divers guides de la méthodologie, les règles et les situations de transformation et de
désambiguïsation qui doivent être éclaircies par l’assistant logiciel sont nombreuses
et nécessitent un traitement informatique important pour minimiser les erreurs de
transformation. Un tel traitement manuel est tout à fait réalisable, mais il nécessite un
temps et des efforts non négligeables.
5.4 Perspectives
Dans cette section, nous identifions les perpectives qui nous semblent les plus
prometteuses pour OntoCASE.
5.4.1 Perspectives de développement et d’utilisation
Dans le cadre de projets industriels associés au Web sémantique, OntoCASE pourrait
être utilisé pour formaliser des processus d'affaires ou encore être intégré à des
projets de référencement sémantique de documents. Une évaluation des
fonctionnalités et des aspects ergonomiques d'OntoCASE serait à réaliser dans cette
perspective.
226
5.4.2 Perspectives en recherche sur la modélisation
Le mécanisme de validation par l’interprétation en langage naturel de l’ontologie
cible est un mécanisme qui pourrait facilement être exploité pour la modélisation
semi-formelle autre que celle de MOT comme par exemple le langage UML, et ce,
non seulement pour le diagramme de classes, mais aussi pour le diagramme d’états,
de séquences ou encore, de cas d’utilisation. Il pourrait aussi être exploité pour
l’interprétation de modèle BPMN, MindMap, CMap et autres. L’avantage notoire de
l’utilisation des ontologies dans une telle perspective est que le volet opérationnel des
ontologies permet la production de conclusions de domaine, qui peuvent être
exploitées pour produire du texte ou encore des modèles semi-formels dans un
langage différent de celui du modèle semi-formel source. Ainsi, un modèle semi-
formel, qui est à l’origine écrit en MOT, pourrait être traduit en modèle semi-formel
cible de type UML. OntoCASE pourrait donc être exploité comme traducteur de
modèles.
Pour l’heure, le module de validation génère un texte de la forme: sujet prédicat objet.
Des améliorations pourraient être développées afin d’offrir des fonctionnalités de tri
selon le sujet, le prédicat ou l’objet. De plus, si un sujet et un objet sont identiques, ils
pourraient être concaténés pour former une phrase plus complète du type :
sujet1→prédicat1→(objet1/sujet2)→prédicat2→(objet2/sujet3)→prédicat3→objet3,
ainsi par exemple, trois énoncés du style : Bahia est un chien; chien est un canin;
canin est un carnivore serait formé par Bahia est un chien qui est un canin qui est un
carnivore. Autrement, des techniques de génération de texte pourraient offrir une
meilleure présentation des résultats générés par l’assistant à la validation.
5.4.3 Perspectives en représentation des connaissances
Dans le domaine de la représentation des connaissances, certains éléments
d'expressivité des ontologies ou d’autres types de langages ne peuvent pas être
227
représentés dans le langage MOT. Par exemple, la propriété owl:inverseOf n'a pas
de correspondant en langage MOT. Certaines fonctionnalités de "stéréotypage"
pourraient être implantées dans OntoCASE pour permettre la représentation de
l'ensemble des éléments d'expressivité d'OWL à partir de l'édition semi-formelle de la
conceptualisation d'origine.
En revanche, l'intégration de nouveaux formalismes à la méthodologie permettrait de
généraliser davantage l'ontologie de transformation ce qui, à une ultime limite,
pourrait être unifiant pour le domaine de la représentation des connaissances.
5.4.4 Perspectives en gestion des connaissances
En élicitation de connaissances, la capacité que possède OntoCASE de produire une
interprétation objective et normalisée en langage naturel d'un modèle semi-formel
pourrait être exploitée pour stimuler la créativité des experts à exprimer leurs
connaissances. Une amélioration de l'assistant informatique à produire une
interprétation textuelle du modèle graphique en temps réel pendant l'activité de
modélisation pourrait être une contribution intéressante à ce type de recherche. En
science cognitive, l'apprentissage des mécanismes structurants de la pensée est
parfois ardu. Des recherches sur l’utilisation d'OntoCASE en tant qu'EIAH seraient à
explorer dans cette perspective.
Bien qu’il faille valider ce qui suit par une expérimentation, nous pouvons tout de
même présumer qu'à la lumière des résultats obtenus, l'assistant informatique
d'OntoCASE peut favoriser le passage de connaissances tacites en représentations
déclaratives de degré formel, soit une ontologie.
228
5.4.5 Perspective de recherche pour les Environnements Informatiques pour
l'Apprentissage Humain (EIAH)
En EIAH, OntoCASE pourrait fournir un outil d’ingénierie ontologique convivial
pour la production d’ontologies dans des domaines d’enseignement variés (par
exemple en mathématique, français, philosophie, etc.). Comme indiqué par l’un des
participants à l’expérimentation, l'utilisation d'un langage de modélisation semi-
formel pour la conception d'ontologies serait un réel gain pour le concepteur
pédagogique responsable de la conception et de la diffusion de ce contenu pour les
EIAH à base d’ontologies. Par ailleurs, pour la rédaction d’un texte didactique, la
modélisation ontologique et sa validation avec OntoCASE pourraient permettre de
relever des contradictions dans le texte. Des recherches en ce sens pourraient aboutir
à la mise en place d’une méthodologie de développement de contenu pédagogique
dont la représentation serait formelle et qui serait utilisable par les enseignants.
En considérant OntoCASE comme EIAH pour l’apprentissage de la modélisation, les
dispositifs de rétroaction, qu'il s'agisse de menus contextuels qui limitent le choix des
objets de modélisation à des possibilités valides, ou encore des messages liés à la
désambiguïsation ou à la gestion des erreurs de modélisation, ou même de l'utilisation
des outils de validation syntaxique et sémantique, offrent à l’apprenant en
modélisation un outil efficace d'interprétation automatique du modèle semi-formel
initialement produit. L'interprétation automatique de ce modèle à travers un processus
de désambigüisation et de formalisation ontologique procure les avantages suivants:
elle guide l'activité de modélisation pendant l'étape d'explicitation de la connaissance;
elle permet une auto-évaluation de la démarche de modélisation; elle permet une
validation objective du modèle conçu. L’usage d’OntoCASE en tant qu’EIAH
pourrait avoir des effets sur la conceptualisation interne (mentale) des sujets, mais
cela serait à vérifier avec des recherches faisant appel à des mesures cognitives.
229
Par ailleurs, dans une perspective pédagogique, la production automatique d'une
validation à la suite de la production d'un modèle semi-formel est une propriété
d'OntoCASE qui pourrait être utilisée par un enseignant pour évaluer la performance
d'un étudiant. Enfin, pour l’apprentissage de la compréhension de texte, la structure
logique du langage de modélisation et les fonctionnalités de validation du modèle
semi-formel permettraient une auto-évaluation de l'étudiant et amènerait celui-ci à se
poser les bonnes questions pour s'auto corriger.
L
2
d
t
n
A
C
d
F
GUIDE
L
e langage
2
010) est u
n
d
'abord la s
t
t
ypes de co
n
n
ous présen
t
A
.1 Structu
r
C
omme la
p
d
’une gram
m
F
igure A.1 :
DU LAN
G
de Modéli
s
n
langage d
e
t
ructure de
n
naissances
t
ons la sém
a
r
e du langag
e
p
lupart des
m
aire et d’u
n
Structure g
é
A
P
G
AGE DE
M
ation par
O
e
représenta
t
c
e langage
e
et les relat
i
a
ntique de c
h
e
MOT
langages, l
a
n
e sémantiq
u
é
nérale d’u
n
P
PENDI
C
M
ODÉLI
S
MOT
O
bjets Typé
s
t
ion graphiq
u
e
t son alph
a
i
ons qui so
n
h
acune des
p
a
structure
u
e (voir la f
i
n
langage.
C
E A
S
ATION P
A
s
(MOT) c
o
u
e des conn
a
bet. Par la
n
t exprima
b
p
rimitives d
u
de MOT s
e
i
gure a.1).
A
R OBJE
T
o
nçu par Pa
q
n
aissances.
N
suite, nous
b
les en MO
T
u
langage.
e
compose
d
T
S TYPÉS
q
uette (200
2
N
ous décriv
o
présentons
l
T
. Finaleme
d
’un alpha
b
2
b,
o
ns
l
es
e
nt,
b
et,
L
l
l
c
s
s
e
u
r
c
a
d
A
A
L
e
L
s
c
F
1
d
e
L
’alphabet
e
l
angage (ce
l
angue fran
ç
c
onsonnes.
s
ymboles.
L
s
ymboles.
L
e
xemple, d
a
u
n concept
r
ègle de gra
m
c
omme ori
g
a
ssociée à
c
d
ans la fig
u
A
lphabet, G
A
.2 Alphab
e
L
’alphabet
d
e
t les conso
n
L
es conna
is
s
ymbole de
c
onnaissanc
F
igure A.2 :
1
14
Le lien S qu
i
d
e désigner un
e
ncore « la relat
i
e
st constitu
é
que l'on a
p
ç
aise, l’alp
h
La gramm
a
L
’applicatio
n
L
a sémantiq
u
a
ns la figure
e
t la flèche
m
maire util
i
g
ine un con
c
c
ette règle e
s
u
re a.1 on
p
r
ammaire e
t
e
t du langag
e
d
u langage
M
n
nes dans l
e
s
sances pe
u
MOT est
e factuelle (
v
Structure d
e
i
relie des Conc
e
sous-ensemble.
i
on est une sort
e
é
de symbo
p
pelle parf
o
h
abet se co
m
a
ire, quant
à
n
des règle
s
u
e est la dé
f
a.1, deux s
y
traversée d
’
i
sée ici s’én
c
ept relie à
s
s
t : un conc
e
p
eut lire :
«
t
Sémantiqu
e
e
MOT
M
OT inclut
e
langage n
a
u
vent être
soit une r
e
v
oir la figur
e
e
l’alphabet
e
pts en est un d
e
On peut donc l
e
d’alphabet de
M
les, d’icône
o
is les pri
m
m
pose de c
a
à
elle, sert
s
est indép
e
f
inition du
s
y
mboles son
’
un « C » q
u
o
nce comm
e
s
a destinati
o
e
pt A est c
o
«
le concept
e
».
deux types
a
turel) qui s
o
« abstraites
e
lation, soi
t
e
a.2
114
).
de MOT.
e
spécialisation
q
ire que
R
elatio
n
M
OT »
s ou de la
r
m
itives du l
a
a
ractères re
g
à définir l
e
e
ndante du
s
ens qui est
n
t utilisés so
i
u
i indique
u
e
suit : « un
o
n un autre
o
mposé d’u
n
langage s
e
d’entités (c
o
o
nt les con
n
» ou « fa
c
t
une conn
a
q
ui se lit «
s
orte
n
est un sous-e
n
r
eprésentati
o
a
ngage). Pa
r
g
roupés en
v
e
s règles d’
sens que r
e
donné aux
i
t le rectang
l
u
n lien de c
o
lien de co
m
concept ».
L
n
concept B
.
e
compose
d
o
mme le so
n
n
aissances e
t
c
tuelles ».
A
a
issance ab
s
e
de ». Le lien S
n
semble de l’
A
l
p
2
o
n de base
r
exemple,
v
oyelles et
utilisation
d
e
présentent
l
symboles.
P
l
e représent
a
o
mposition.
m
position qu
L
a sémanti
q
.
Par exem
p
d
es concep
t
n
t les voyel
l
t
les relatio
n
A
insi, cha
q
s
traite ou
u
est aussi une fa
p
habet de MO
T
2
31
du
en
en
d
es
l
es
P
ar
a
nt
La
i a
q
ue
p
le,
t
s :
l
es
n
s.
q
ue
u
ne
çon
T
ou
232
La relation unit deux connaissances. La connaissance abstraite représente quelque
chose ressemblant à une idée. Par exemple, dans la phrase « le chien est le meilleur
ami de l’Homme », le mot « chien » fait référence à un concept, à une idée que l’on
se représente de ce qu’est un « chien ». C’est ce qui est appelé une « connaissance
abstraite ». En contrepartie, s’il est dit « Fido est le meilleur ami de l’Homme »,
alors le mot « Fido » fait référence à quelque chose qui existe, qu’il est possible de
toucher. On dira alors que le mot « Fido » est une connaissance factuelle. La
connaissance factuelle fait référence à une entité tangible, qu’on peut aussi nommer
« objet concret ».
A.3 Types des connaissances en MOT
A.3.1 Alphabet de MOT associé aux types de connaissances
Le langage semi-formel MOT différencie les types de connaissances au moyen de
symboles graphiques (voir le tableau a.1 et le tableau a.2). Les connaissances peuvent
être combinées au sein d’un même schéma de manière à produire des modèles mixtes
de connaissances. Tel que déjà mentionné, à l'instar des théories sur la représentation
des connaissances, le langage MOT offre la possibilité de représenter des
connaissances selon deux niveaux d'abstraction: conceptuel (ConnaissanceAbstraite)
et factuel (Fait). La figure a.3 présente le vocabulaire de MOT sous une forme
taxonomique mettant ainsi en relation les différents éléments du vocabulaire de MOT.
F
A
D
t
d
r
L
o
f
p
s
d
u
l
F
igure A.3:
A
.3.2 Séma
n
D
u point de
t
ableau a.2)
.
d
e classe o
u
r
eprésente l
’
L
a
p
rocéd
u
o
pérations,
d
f
aits concre
t
p
ourquoi »,
s
tratégique
q
d
es concept
u
ne conditi
o
l
’instanciati
o
Représentat
i
n
tique de M
O
vue de la s
é
Il sert à dé
c
u
de catégori
e
’
un de ces o
u
re permet
d
es actions
t
s obtenus l
o
« le quand
»
q
ui permet
d
s,
d
es proc
é
o
n pouvant
o
n d'un prin
c
i
on des con
n
O
T associé
e
é
mantique,
l
e
c
rire l’esse
n
e
. En ce sen
bjets en én
o
de décrire
p
ouvant êtr
e
o
rs de l’exé
»
ou le « q
u
d
e nommer
u
é
dures ou d
’
s’appliquer
c
ipe à prop
o
n
aissances e
n
e
aux types
d
e
concept re
p
n
ce d’un obj
e
s, il est l'ab
s
o
nçant un ce
r
« le com
m
e
accomplie
cution d’un
e
u
i » associ
é
u
ne relation
’
autres prin
c
à l’exécuti
o
o
s d’objets c
o
n
langage
M
d
e connaissa
n
p
résente « l
e
e
t concret. I
s
traction d’
u
rtain nombr
m
ent » des
c
s. La trace
e
procédure
é
à une cho
s
qui existe e
n
c
ipes. Il ser
t
o
n d’une a
c
o
ncrets.
M
OT.
n
ces
e
quoi » des
l peut être
a
u
n objet con
c
r
e de faits q
u
c
hoses. Ell
e
représente
l
. Le
p
rinci
p
s
e. Il est un
e
n
tre des obj
e
t
notammen
t
c
tion. L'éno
n
2
choses (voi
r
a
ssocié à l’i
d
c
ret. L'exem
p
u
i le décriv
e
e
désigne
d
l
’ensemble
d
p
e désigne
«
e
connaissa
n
e
ts, que ce s
t
à représen
n
cé représe
n
2
33
r
le
d
ée
p
le
e
nt.
d
es
d
es
«
le
n
ce
oit
n
ter
n
te
A
L
d
d
(
m
c
p
s
F
A
A
L
u
r
r
d
Ty
p
T
y
p
L
e
Le
c
Le p
o
A
.3.3 Stéré
o
L
e stéréoty
p
d
éfini par
d
éfinition d
u
(
Alhir, 200
2
m
odélisateu
r
c
onnaissanc
p
ar une tâ
c
s
téréotype e
F
igure A.4:
A
.4 Type d
e
A
.4.1 Alph
a
L
a relation
e
u
n ensembl
r
elation d’i
n
r
eprésente
d
'applicatio
n
p
e de connai
s
e de connaiss
a
Déclarative
e
quoi des cho
s
Action
c
omment de ch
o
Stratégique
o
urquoi, le qua
n
qui
o
type
p
e ne fait p
a
P
aquette (
2
u
langage
M
2
), le stéré
o
r
d'associe
r
es. Par exe
m
c
he, une p
r
s
t encapsul
é
Représentat
i
e
relations d
a
a
bet des rela
t
e
st un lien
d
e
de liens
q
n
stanciation
,
une relati
o
n
, le lienP
r
s
sances dan
s
a
nce Co
n
s
es Co
n
o
ses Proc
é
n
d, le Pri
n
a
s partie d
e
2
002b). Ce
p
M
OT. Large
m
o
type est
u
r
un élé
m
m
ple, une co
n
r
océdure o
u
é
par les sy
m
i
on de la pr
o
a
ns MOT
t
ions
d
irectionnel
q
q
ui sont ty
p
,
le lienS r
e
o
n de rég
u
r
eprésente l
a
Tableau A.
s
le langage
M
n
naissance ab
s
n
cep
t
é
dure
n
cipe
e
la définiti
o
p
endant, no
u
m
ent utilisé
u
ne extensi
o
m
ent d’un
n
naissance
p
u
encore u
n
m
boles « ».
o
cédure P d
o
q
ui unit des
p
és (voir l
a
e
présente u
n
u
lation, le
a
préséance
,
.
1
MOT et leu
r
s
traite C
o
Ex
e
T
É
n
o
n de base
d
u
s l'avons
et standar
d
o
n du voc
a
modèle à
p
rocédurale
n
e méthode
o
nt le stéréo
t
connaissan
c
a
figure a.5)
n
e relation
d
lienA re
p
,
le lienIP
r
r
symbole a
s
o
nnaissance f
a
emple
T
race
n
oncé
d
u langage
intégré da
n
d
isé en mod
é
a
bulaire qui
un autre
P pourrait ê
t
e
(voir la
f
t
ype une mé
t
c
es. Le lang
a
. Le lienI
r
d
e spécialis
a
p
résente u
n
r
eprésente
u
2
s
socié.
a
ctuelle
MOT, tel
q
n
s la prése
n
é
lisation U
M
permet à
domaine
t
re stéréoty
p
f
igure a.4).
t
hode.
a
ge MOT o
ff
r
eprésente
u
a
tion, le lie
n
n
e associat
i
u
ne associat
i
2
34
q
ue
n
te
M
L
un
de
p
ée
Le
ff
re
u
ne
n
R
i
on
i
on
d
c
F
r
A
C
d
S
d
d
'intrant/pr
o
c
ompositio
n
F
igure A.5:
r
eprésentati
o
A
.4.2 Séma
n
C
haque typ
e
d
es règles d
S
) unit deu
x
d
e ces règle
s
o
duit, le l
i
n
multiple et
,
Hiérarchie
o
n dans l'on
t
n
tique des r
e
e
de lien po
s
’intégrité (v
o
x
connaissa
n
s
d’intégrité
i
enC/C* re
p
,
enfin, le li
e
des relati
o
t
ologie du l
a
e
lations
s
sède une s
é
o
ir le tablea
u
n
ces abstrai
t
sont décrite
p
résente l'
a
e
nE représe
n
o
ns typées
a
ngage semi
-
é
mantique p
r
u
a.3). Par e
t
es, qui doi
v
s dans Paqu
a
ssociation
n
te une rela
t
utilisées e
n
-
formel.
r
opre (voir l
e
xemple, un
v
ent être de
u
ette (2002b
)
de comp
o
t
ion d’englo
b
n
langage
l
e tableau a.
2
lien de spé
c
même natu
r
)
.
2
o
sition et
b
ement.
MOT et l
e
2
) qui respe
c
c
ialisation (l
i
r
e. L'ensem
b
2
35
de
e
ur
c
te
i
en
b
le
236
Tableau A.2
Sémantique des relations typées dans MOT (adapté de Paquette 2002b, 2010)
Type
de lien
Signification
S
Le lien de spécialisation associe deux connaissances abstraites de même type dont la
première est une spécialisation de la seconde. Ce lien est notamment utile dans la
description des taxonomies. Le lien de spécialisation est une relation transitive.
I
Le lien d'instanciation associe à une connaissance abstraite un fait qui caractérise une
instance de cette connaissance. Le lien d'instanciation n'est pas une relation
transitive.
I/P
Le lien intrant/produit sert à associer une connaissance procédurale à une
connaissance conceptuelle afin de représenter l'intrant ou le produit d'une procédure.
Ce lien est notamment utile dans la description des algorithmes, des processus et des
méthodes. Le lien intrant/produit n'est pas une relation transitive.
P
Le lien de précédence associe une connaissance à une autre qui la suit dans une
séquence temporelle de procédures ou de règle de décision (principes). Le lien de
précédence est une relation transitive.
R
Le lien de régulation associe une connaissance stratégique (un Principe ou un
Énoncé) à une autre connaissance afin de préciser une contrainte, une restriction ou
une règle qui régit la connaissance. Le lien de régulation est une relation non-
transitive.
C, C*
Les liens de composition et de composition multiple permettent de représenter
l’association entre une connaissance et des connaissances qui la composent. Le lien
de composition est une relation transitive.
E
Le lien englobe ne possède pas de symbolique particulière dans le langage MOT
original. Il s'agit d'une relation qui unit l'élément d'un modèle aux éléments d'un
sous-modèle. Le lien englobe est une relation transitive.
Certaines règles d’association entre des connaissances sources et des connaissances
destinations sont appliquées à chacun des types de relation. Ces règles définissent les
relations considérées valides entre les différents types de connaissances du point de
vue de la sémantique MOT.
Voici les quelques règles générales d’utilisation :
- Règle 1 : une relation ne peut pas exister seule; elle doit, à son origine et à sa
destination, référer à une connaissance (factuelle et/ou abstraite selon le cas).
- Règle 2 : il est possible qu’une relation possède la même connaissance
d’origine et de destination.
- Règle 3 : une connaissance peut exister seule, sans qu’elle soit l’origine ou la
destination d’une relation.
237
Plus spécifiquement, il existe un ensemble de règles secondaires qui régissent
chacune des relations en fonction de la nature des connaissances d’origine et de
destination qu’elles associent. Le tableau a.3 présente, en format condensé,
l’ensemble des règles d’union des relations et des connaissances de MOT.
Tableau A.3
Grammaire des relations MOT (adapté de Paquette 2002b)
Destination Connaissances abstraites Connaissances factuelles
Origine Concept Procédure Principe Exemple Trace Énoncé
Concept C, S I/P R115 I, C
Procédure I/P C, S, P C, P I, C
Principe R C, R, P C, S, P, R I, C
Exemple A A A A, C A, I/P A
Trace A A A A, I/P A, C, P A, C, P
Énoncé A A A A, R A, C, R, P A, C, R, P
Le tableau a.3 s’interprète de la façon suivante : prenons par exemple la première
case du haut à gauche. On y lit « C, S ». L’interprétation, sous forme de règle,
s’inscrit comme suit :
- Règle C1 : si l’origine d’un lien est un concept et que la destination est un
concept, alors la relation peut être de type « C » (qui est un lien de
composition);
- Règle S1 : si l’origine d’un lien est un concept et que la destination est un
concept, alors la relation peut être de type « S » (qui est un lien de
spécialisation);
Chacune des cases du tableau s’interprète selon la même lecture impliquant un
ensemble de cas d’utilisation pour chacun des liens.
115 La relation « R » entre un Concept et un Principe est un ajout de notre part. Elle ne fait pas pas partie de la
grammaire originale de MOT proposée par Paquette (2002).
A
N
d
n
A
L
l
d
A
.5 Sémant
i
N
ous veno
n
d
es élémen
t
n
ous attard
o
A
.5.1 Com
p
L
e lien « C
l
es constit
u
d
’indiquer
q
E
x
Origine/
Destination
Concept /
Concept
Procédure/
Procédure
Principe/
Principe
i
que des élé
m
n
s de définir
t
s de vocab
u
o
ns sur la sé
m
p
osition
», qui se lit
u
ants d’une
q
u’une conn
a
x
emple de r
e
Une « Au
t
« Moteur »
,
« retirer de
débit », « e
carte et l’ar
g
Le « statut
d
« reconnais
m
ents gram
m
les constit
u
u
laire ainsi
q
m
antique de
s
: « lien de
c
connaissa
n
a
issance se
c
e
présentatio
n
t
omobile » s
e
,
de « Roue »
l’argent au
g
ntrer le NIP
»
g
en
t
».
d
e citoyen » s
e
sance d’immi
g
m
aticaux du
u
ants du vo
c
q
ue de la g
r
s
éléments
g
c
ompositio
n
n
ce (voir l'
c
ompose d’
u
Tableau A.
n
d'une com
p
E
x
Représen
t
e
compose
d
g
uichet autom
a
»
, « choisir un
e
compose des
g
ration ».
langage M
O
c
abulaire, d
e
r
ammaire d
e
g
rammatica
u
n
», sert à r
e
exemple d
u
u
ne ou plusi
e
.
4
p
osition ent
r
x
emple/
tation en MO
d
e
a
tique » se co
m
compte », «
e
règles de « re
c
O
T
e
la sémanti
q
e
MOT. M
a
u
x de MOT.
e
présenter l
e
u
tableau a.
e
urs autres c
o
r
e connaiss
a
T
m
pose de : »
e
e
ntrer le mon
t
c
onnaissance
d
2
q
ue du cha
c
a
intenant, n
o
e
s composa
n
4). Il per
m
o
nnaissance
a
nces
e
ntrer la carte
t
an
t
», « retire
r
d
e naissance »
,
2
38
c
un
o
us
n
ts,
m
et
s.
de
r
la
,
de
A
L
d
d
l
A
.5.2 Spéci
a
L
e lien « S
»
d
’une conn
a
d
e désigner
l
iées par un
E
Origine/
Destination
Concept /
Concept
Procédure/
Procédure
Principe/
Principe
a
lisation
»
, qui se lit
a
issance par
des cas pa
r
lien de spéc
i
E
xemple de
r
Un « Sapin
« Payer un
e
marchandis
La « défini
t
: « lien de s
p
rapport à u
n
r
ticuliers de
i
alisation so
r
eprésentati
o
» est une sort
e
e
marchandise
e »
t
ion d’un sapi
n
p
écialisatio
n
n
e autre (vo
connaissa
n
nt des conn
a
Tableau A.
o
n de la spé
c
E
x
Représen
t
e
de « Conifèr
e
par carte de
c
n
» est une sort
e
n
», sert à r
e
ir l'exemple
n
ces concep
t
a
issances de
.
5
c
ialisation d
e
x
emple/
tation en MO
e
»
c
rédi
t
» est un
e
e
de « définiti
o
e
présenter l
a
e
du tableau
t
uelles. Les
même type
.
e
connaissa
n
T
e
sorte de faç
o
o
n de conifère
2
a
spécialisat
i
a.5). Il per
m
connaissan
c
.
n
ces
o
n de «
p
ayer
u
».
2
39
i
on
m
et
c
es
u
ne
A
L
p
t
c
o
D
A
.5.3 Régul
L
e lien « R
p
rincipe et
t
ableau a.6)
.
c
onjonction
o
bjet par un
Ex
e
Origine/
D
estination
Principe /
Concept
Principe/
Procédure
Principe/
Principe
ation
», qui se li
t
l'une ou
En tant
q
avec un lie
n
autre.
e
mple de re
p
« La force gr
a
« La situation
La « Loi de
N
t
: « lien de
l'autre de
s
q
u'agent, n
o
n
de régulat
i
p
résentation
a
vitation » régi
t
économique
»
N
ewton » régit
l
régulation
»
s
connaissa
n
o
rme ou c
o
i
on pour in
d
Tableau A.
d'une régul
a
Exem
p
R
eprésentati
o
t
« le mouvem
»
régit l'action
«
l
e «
p
rincipe
d
»
, est une r
n
ces abstr
a
o
ntrainte, l
e
d
iquer une s
i
.
6
a
tion entre
d
p
le/
o
n en MOT
m
ent des astres
»
«
de dépenser
p
d
u calcul de la
v
elation qui
a
ites (voir
e
principe
i
tuation de
r
d
es connaiss
a
»
.
p
our les achat
s
vitesse d'un o
b
2
met en jeu
l'exemple
est utilisé
r
égulation d
'
a
nces
s
de Noël ».
b
je
t
».
2
40
un
du
en
'
un
A
L
a
r
A
.5.4 Insta
n
L
e lien « I
»
a
bstraite et
r
eprésenter
l
Exemple
d
Origine/
Destination
Concept /
Exemple
Procédure /
Trace
Principe /
Énoncé
n
ciation
»
, qui se li
t
la connaiss
l
a relation e
n
d
e représent
a
Le « Rapp
o
« Calculer
L'énoncé
«
instanciati
o
t
: « lien d’i
n
ance factue
l
n
tre un obje
t
a
tion de l'in
s
con
n
o
rt d’impô
t
» a
10 + 12 » est
u
«
t est de 5°
o
n de la règle
«
n
stanciatio
n
l
le de mêm
t
concret et l
Tableau A.
s
tanciation e
n
n
aissance fa
c
E
x
Représen
pour instance
u
n calcul de ty
p
alors il faut
m
«
Si t>0° alors
n
», met en
r
e type (voi
r
l
’abstraction
.
7
n
tre une co
n
c
tuelle
x
emple/
n
tation en M
O
« le rapport d’
p
e « calculer
X
mettre le pro
d
mettre le pro
d
r
elation un
e
r
le tableau
qui lui est
a
n
naissance a
b
O
T
’
impôt de Pier
r
X
+ Y »
d
uit au congé
d
uit au congéla
t
2
e
connaissa
n
a.7). Il ser
t
a
ssociée.
b
straite et u
n
r
e »
lateur » est
u
t
eur »
2
41
n
ce
t
à
n
u
ne
A
L
t
c
p
A
L
p
d
A
.5.5 Intra
n
L
e lien « I/
P
t
ype procéd
u
c
omposants
p
ar la procé
d
Exem
p
Origine/
Destination
Concept /
Procédure
Procédure/
Concept
A
.5.6 Précé
d
L
e lien « P
»
p
rincipes (v
d
es procédu
r
Origine/
Destination
Procédure/
Procédure
Principe/
Procédure
n
t et le prod
u
P
», qui se li
t
u
re et de ty
p
nécessaires
d
ure.
p
le représen
t
pro
c
L’ » Essen
c
Le process
u
d
ence
»
, qui se lit
oir l'exemp
l
r
es ou l’ord
o
E
x
le processu
s
montant »
q
« On retir
e
compte »
u
it
t
: « lien intr
p
e concept (
v
à la réalisa
t
t
ation d'un i
n
c
édurale et
u
c
e » est l’intra
n
u
s d’ » extracti
o
« lien de pr
é
l
e du tablea
u
o
nnanceme
n
x
emple de r
e
s
: » entrer la
c
q
ui précède « r
e
e
l'argent du
g
ant/produit
»
v
oir l'exemp
l
t
ion de la p
r
Tableau A.
n
trant et d'u
n
u
ne connais
s
E
x
Représen
t
n
t du processu
s
o
n du pétrole
»
é
cédence »
m
u
a.9). Il se
r
n
t de l’appli
c
Tableau A.
e
présentatio
n
E
x
Représen
t
c
arte »
p
récèd
e
e
tirer la carte
e
g
uichet » à co
»
, met en re
l
l
e du tablea
u
rocédure ai
n
.
8
n
produit en
t
s
ance conce
p
x
emple/
tation en MO
s
de « faire ro
u
»
produit des
«
m
et en relat
r
t à ordonn
e
c
ation de pri
n
.
9
n
de la présé
x
emple/
tation en MO
e
» choisir un
c
e
t l’argen
t
»
o
ndition que «
l
ation une c
o
u
a.8). Il ser
t
n
si que les
o
t
re une con
n
p
tuelle
T
u
ler une autom
o
«
Gaz à effet d
e
t
ion des pro
c
e
r la séquen
c
n
cipes.
é
ance
T
c
ompte » qui p
l'argent soit
d
2
o
nnaissance
t
à désigner
l
o
bjets prod
u
n
aissance
o
bile »
e
serre »
c
édures ou
d
c
e d’exécut
i
p
récède » entre
r
d
isponible dan
s
2
42
de
l
es
u
its
d
es
i
on
r
le
s
le
A
L
f
m
e
v
O
m
A
L
c
A
.5.7 Lien
d
L
e lien «
A
f
actuelle av
e
m
ajorité de
s
e
ntités qui
v
ocabulaire
O
n dira a
l
m
étaconnai
s
Origine/
Destinatio
n
Connaissan
c
factuelle/
Connaissan
c
Abstraite
A
.5.8 Propr
i
L
'attribut e
t
c
onnaissanc
d
’applicatio
n
A
», qui se
l
e
c une con
n
s
situations,
u
composent
d’un doma
i
l
ors que l
e
s
sance du v
o
Exe
m
n
c
e
c
e
Dans c
e
l’ « Esp
è
« Espèc
e
Biologi
q
i
été et l'attri
b
t
la propri
é
es abstraite
s
n
l
it « lien d’
n
aissance a
b
u
n modèle
M
un domain
e
i
ne d’applic
a
e
vocabula
i
o
cabulaire d
u
m
ple de repr
é
e
t exemple, «
B
è
ce » des « C
h
e
», le « Gen
r
q
ue ».
b
ut
é
té sont d
e
s
(voir l'ex
e
application
»
b
straite (voi
r
M
OT sert à
r
e
d’applicat
i
a
tion sert à
i
re du pre
m
u
deuxième
d
Tableau A.
1
é
sentation d'
u
E
Représ
e
B
ahia » qui e
s
h
ien » … qui
e
r
e », …, le «
R
e
ux associa
t
e
mple au t
a
», met en
r
r
l'exemple
r
eprésenter l
i
on spécifi
q
la représen
t
m
ier doma
d
omaine d’
a
1
0
u
n lien d'ap
p
E
xemple/
e
ntation en M
O
st de la « Ra
c
e
st du « Règn
e
R
ègne » sont
t
ions qui
m
a
bleau a.11)
.
r
elation un
e
du tableau
a
e vocabulai
r
q
ue. Dans c
e
t
ation d’un
a
a
ine d’appl
i
a
pplication.
p
lication
O
T
c
e » des « Be
r
e
» « Animal
»
des entités d
u
m
ettent en
.
La représ
e
2
e
connaissa
n
a
.10). Dans
r
e ainsi que
l
ertains cas,
a
utre domai
n
i
cation est
r
ge
r
», qui est
»
. La « Race
»
u
concept « R
a
relation d
e
e
ntation d’
u
2
43
n
ce
la
l
es
le
n
e.
la
de
»
, l’
a
ng
e
ux
u
ne
r
L
d
d
P
L
d
a
s
«
a
b
«
A
L
d
r
elation d'at
t
L
ienC crée
u
d
omaine re
p
d
u LienC.
P
ar ailleurs,
L
ienR, qui
d
'inclure u
n
a
lors le rôl
s
'appliquer
p
«
La pomme »
a
) « La pomm
e
b
) de manière
p
«
la pomme »
«
A
.5.9 Règle
L
a règle e
s
d
'antécéden
t
t
ribut est ex
p
u
ne ambigu
ï
p
résenté, qui
la représe
n
ne fait pas
n
principe e
n
e
de propr
i
p
our la défi
n
Exemple
d
se compose d
e
e
» a pour attri
b
p
lus formelle:
«
est de coule
u
s
t un énon
c
t
s mis en co
n
p
rimée par
l
ï
té avec l'int
e
permet de
d
n
tation de la
partie de
l
n
tre deux c
o
i
été qui un
i
n
ition de pro
p
d
e représen
t
Rep
r
e
« pépin » et
b
ut « Rouge
»
» la pomme »
ur
» « rouge »
c
é qui se c
n
jonction p
o
l
e LienC en
t
e
rprétation
d
d
éterminer l
'
propriété n
é
l
a définitio
n
o
ncepts reli
é
i
t deux con
p
riétés entr
e
Tableau A.
1
t
ation d'un a
t
Exemple/
r
ésentation e
n
»
;
a pour attribu
t
ompose du
o
ur produir
e
t
re deux co
n
d
e composit
i
'
interprétati
o
é
cessite une
n
initiale d
u
é
s par des
L
n
cepts. Cett
e
e
des connai
s
1
1
t
tribut et d'u
n
MOT
t
« couleur » q
u
nom de l
a
e
une concl
u
n
cepts. Cett
e
i
on. C'est la
o
n adéquate
e
utilisation
p
u
langage
M
L
ienR. Le
p
e
combinai
s
s
sances pro
c
u
ne propriét
é
u
i a la valeur
d
a
règle et
d
u
sion ou un
e
2
e
utilisation
sémantique
du l'utilisat
i
p
articulière
M
OT. Il s'a
p
rincipe pr
e
s
on peut a
u
c
édurales.
é
d
'être « rouge
»
d
'un ensem
b
e
opération.
E
2
44
du
du
i
on
du
a
git
e
nd
u
ssi
»
b
le
E
n
M
t
p
s
«
«
A
N
r
(
m
p
c
u
M
OT, il est
t
opologie p
p
rocédures.
s
téréotype.
«
La règle du
b
«
La règle d'in
o
A
.6 Résum
é
N
ous avon
s
r
eprésentati
o
(
Procédure
m
ises en
r
p
récédence,
c
haque rela
t
u
ne sémanti
q
possible de
articulière
d
La signifi
c
E
b
eau temps »:
«
o
culation gén
é
é
s
vu que
o
n de con
n
et Trace) e
t
r
elation par
intrant/pro
d
t
ion est régi
e
q
ue propre.
représenter
d
ans l'utilis
a
c
ation de c
h
E
xemple de
«
S'il fait entre
é
ralisée »: « S'i
le langage
n
aissances
d
t
stratégiqu
e
l’utilisatio
n
d
uit, d’inst
a
e
par des rè
g
une règle (
v
a
tion de p
r
h
acun de c
e
Tableau A.
1
représentat
i
20° et 30° » e
t
l y a pandémi
e
de Modé
l
d
éclaratives
e
s (Principe
n
des lien
s
a
nce et de
r
g
les d’utilis
a
v
oir l'exemp
l
r
incipes, de
e
s élément
s
1
2
i
on d'une rè
g
t « s'il ne pleu
t
e
de grippe » a
l
l
isation par
(Concept e
t
et Énoncé
)
s
typés : co
m
r
égulation.
N
a
tion et que
c
l
e du tablea
u
LienC, d
e
s
du modèl
e
g
le
t
pas » alors «
i
l
ors « inoculer
Objet Ty
p
t
Exemple)
,
)
. Les conn
m
position,
N
ous avons
c
es règles s
o
2
u
a.12) par
u
e
LienP et
e
est mise
i
l fait beau »
la population
p
é permet
,
procédura
l
aissances s
o
spécialisati
o
aussi vu
q
o
nt associée
s
2
45
u
ne
de
en
»
la
l
es
o
nt
o
n,
q
ue
s
à
APPENDICE B
CATALOGUE DE LA SÉMANTIQUE FORMELLE DE MOT
B.1 Utilisation du catalogue
Le catalogue de la sémantique formelle de MOT présente la signification formelle de
l'utilisation de MOT. Chaque section est divisée selon la structure présentée au
tableau b.1. Le titre du l'élément du catalogue concerne l'interprétation possible d'un
contexte d'utilisation des éléments du langage. Certaines sections présentent le
métamodèle de l'utilisation de l'élément présenté. Pour chaque section, est présenté un
exemple de représentation en langage MOT. Cet exemple est présenté de manière
formelle en langage OWL-N3. Le nom des règles de désambiguïsation et de
conversion utilisées fait référence aux règles détaillées à l'appendice F. Finalement,
les rapports de validation syntaxique et sémantique concluent la section.
Tableau B.1
Structure de chaque élément du catalogue
Titre de l’élément du catalogue
Méta-modèle de la règle d'utilisation
Exemple de représentation en langage MOT
Sémantique formelle
Règles de désambiguïsation
Règles de conversion
Rapport de validation syntaxique
Rapport de validation sémantique
247
Le tableau b.2 a la fonctionnalité de servir d'index pour les éléments du catalogue.
Chaque règle valide de liaison entre connaissances MOT est accompagnée du numéro
de page correspondant à son interprétation.
Tableau B.2:
Tableau des règles concernant chaque relation légale en MOT combiné au numéro de
page de l'interprétation
Destination Connaissances abstraites Connaissances factuelles
Origine Concept Procédure Principe Exemple Trace Énoncé
Concept C(265,
271),
S(251)
I/P(255) R(258, 262,
264)
I(253,
271),
C(269)
Procédure I/P(255) C(266),
S(251),
P(274)
C(278),
P(275)
I(253),
C(269)
Principe R(258, 262) C(278),
R(258),
P(275, 278)
C(265, 278),
S(251),
P(275, 278),
R(258)
I(253),
C(269)
Exemple C(267) I/P(257) R(262)
Trace I/P(257) C(267,
281),
P(274)
C(), P(275)
Énoncé R(260,
262)
C(281),
R(260),
P(275, 281)
C(267,
281),
R(260),
P(275, 281)
B.2 Entités atomiques d’OntoCASE
Chaque élément du vocabulaire de MOT comporte une sémantique dont certains sont
ambigües. La figure b. présente l'interprétation possible de chacun de ces éléments de
vocabulaire et la figure b.2 présente un exemple préalablement désambiguïsé de ces
éléments de vocabulaire.
F
d
E
F
d
F
igure B.1:
L
d
’OntoCAS
E
E
xemple de r
e
F
igure B.2 :
d
e désambi
g
L
a représen
t
E
.
e
présentation
Exemple d
e
g
uïsation po
s
t
ation en U
M
en lan
g
a
g
e
M
e
définition
s
sible.
M
L des di
ff
M
OT
des entités
ff
érentes val
atomiques
d
eurs possib
l
d
e MOT et
l
2
l
es des enti
t
l
eur stéréot
y
2
48
t
és
y
pe
249
Sémantique formelle après l’étape de formalisation
:Concept_0
rdf:type owl:Class ;
rdfs:label "Concept"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:Enonce-de-type-OBSERVABLE_16
rdf:type metaDom:MD_Strategique_Entite_Regle_Conclusion ;
rdfs:label "Énoncé de type OBSERVABLE"^^xsd:string .
:Enonce-de-type-OBSERVABLE_AGENT_13
rdf:type metaDom:MD_Strategique_AgentContrainteNorme ;
rdfs:label "Énoncé de type OBSERVABLE_AGENT"^^xsd:string .
:Enonce-de-type-OBSERVABLE_CONDITION_14
rdf:type metaDom:MD_Strategique_Condition ;
rdfs:label "Énoncé de type OBSERVABLE_CONDITION"^^xsd:string .
:Enonce-de-type-OBSERVABLE_PROPRIETE_15
rdf:type owl:ObjectProperty ;
rdfs:label "Énoncé de type OBSERVABLE_PROPRIÉTÉ"^^xsd:string ;
rdfs:subPropertyOf metaDom:MD_ASSERTION .
:Enonce-de-type-OBSERVABLE_REGLE_ANTECEDENT_19
rdf:type metaDom:MD_Strategique_Entite_Regle_Antecedent ;
rdfs:label "Énoncé de type OBSERVABLE_RÈGLE_ANTÉCÉDENT"^^xsd:string .
:Enonce-de-type-OBSERVABLE_REGLE_COMPLETE_18
rdf:type metaDom:MD_Strategique_Entite_Regle_Complete ;
rdfs:label "Énoncé de type OBSERVABLE_RÈGLE_COMPLÈTE"^^xsd:string .
:Enonce-de-type-OBSERVABLE_REGLE_NOM_17
rdf:type metaDom:MD_Strategique_Entite_Regle_Nom ;
rdfs:label "Énoncé de type OBSERVABLE_RÈGLE_NOM"^^xsd:string .
:Exemple-de-type-OBJET_OBSEERVABLE_10
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Exemple de type OBJET_OBSEERVABLE"^^xsd:string .
:Principe-de-type-AGENT_3
rdf:type owl:Class ;
rdfs:label "Principe de type AGENT"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme .
:Principe-de-type-ANTECEDENT_6
rdf:type owl:Class ;
rdfs:label "Principe de type ANTÉCÉDENT"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Antecedent , owl:Thing .
:Principe-de-type-CONCLUSION_7
rdf:type owl:Class ;
rdfs:label "Principe de type CONCLUSION"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Entite_Regle_Conclusion .
:Principe-de-type-CONDITION_5
rdf:type owl:Class ;
rdfs:label "Principe de type CONDITION"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Condition .
:Principe-de-type-NOM_REGLE_8
rdf:type owl:Class ;
rdfs:label "Principe de type NOM_RÈGLE"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Nom , owl:Thing .
:Principe-de-type-PROPRIETE_4
rdf:type owl:ObjectProperty ;
rdfs:label "Principe de type PROPRIÉTÉ"^^xsd:string ;
rdfs:subPropertyOf metaDom:MD_PROPRIETE .
:Principe-de-type-REGLE_COMPLETE_9
rdf:type owl:Class ;
rdfs:label "Principe de type RÈGLE_COMPLÈTE"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Complete , owl:Thing .
:Procedure-de-type-OPERATION_2
rdf:type owl:Class ;
rdfs:label "Procédure de type OPÉRATION"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Procedurale_Operation .
:Procedure-de-type-PROCEDURE_1
rdf:type owl:Class ;
rdfs:label "Procédure de type PROCÉDURE"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Trace-de-type-OBSERVABLE_OPERATION_12
rdf:type metaDom:MD_Procedurale_Operation ;
rdfs:label "Trace de type OBSERVABLE_OPÉRATION"^^xsd:string .
:Trace-de-type-OBSERVABLE_PROCEDURE_11
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Trace de type OBSERVABLE_PROCÉDURE"^^xsd:string .
:UnString_20
rdf:type owl:Class ;
rdfs:label "UnString"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_String .
:unEntier_21
rdf:type owl:Class ;
rdfs:label "unEntier"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_Int .
:unFloat_22
rdf:type owl:Class ;
rdfs:label "unFloat"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_Float .
:uneValeur_23
rdf:type metaDom:MD_Declarative_Schema ;
rdfs:label "uneValeur"^^xsd:string .
250
Liste des règles de conversion utilisée
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2-5k_Creation_AssertionDeDomaine]
[Rule-01-2a_Creation_Individu_objet]
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2c_Creation_Individu_operation]
[Rule-01-2d_Creation_Individu_Principe_Agent]
[Rule-01-2e_Creation_Individu_Principe_Regle_Nom]
[Rule-01-2f_Creation_Individu_Principe_Regle_Complete]
[Rule-01-2g_Creation_Individu_Principe_Antecedent]
[Rule-01-2h_Creation_Individu_Principe_Conclusion]
[Rule-01-2i_Creation_Individu_Principe_Condition]
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-c_Creation_class_Action_Operation]
[Rule-01-d_Creation_class_agent]
[Rule-01-e_Creation_class_condition]
[Rule-01-f_Creation_class_regle_nom]
[Rule-01-g_Creation_class_regle_complete]
[Rule-01-h_Creation_class_regle_antecedent]
[Rule-01-i_Creation_class_regle_conclusion]
[Rule-01-k_Creation_ProprieteDeDomaine]
[Rule-13-b_Creation_class_Schema_Int]
[Rule-13-c_Creation_class_Schema_Float]
[Rule-13-d_Creation_class_Schema_String]
[Rule-13-e-Creation_Dun_Individu_dattribut]
etat_classification.owl
etat_final.owl
[Rule-00_Sauvegarde]
etat_validation.owl
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
Concept est une sorte de (metaDom:MD_Declarative_Concept)
Enonce-de-type-OBSERVABLE_PROPRIETE_15([],[]) est une assertion de la propriété (metaDom:MD_ASSERTION)
Principe de type AGENT est une sorte de (metaDom:MD_Strategique_AgentContrainteNorme)
Principe de type ANTÉCÉDENT est une sorte de (metaDom:MD_Strategique_Entite_Regle_Antecedent)
Principe de type CONCLUSION est une sorte de (metaDom:MD_Strategique_Entite_Regle_Conclusion)
Principe de type CONDITION est une sorte de (metaDom:MD_Strategique_Condition)
Principe de type NOM_RÈGLE est une sorte de (metaDom:MD_Strategique_Entite_Regle_Nom)
Principe de type RÈGLE_COMPLÈTE est une sorte de (metaDom:MD_Strategique_Entite_Regle_Complete)
Procédure de type OPÉRATION est une sorte de (metaDom:MD_Procedurale_Operation)
Procédure de type PROCÉDURE est une sorte de (metaDom:MD_Procedurale_Procedure)
UnString est une sorte de (metaDom:MD_Declarative_Schema_String)
[Exemple de type OBJET_OBSEERVABLE] est de catégorie (metaDom:MD_Declarative_Concept)
[Exemple de type OBJET_OBSEERVABLE] est un ( :Connaissance d'objet )
[Trace de type OBSERVABLE_OPÉRATION] est de catégorie (metaDom:MD_Procedurale_Operation)
[Trace de type OBSERVABLE_OPÉRATION] est un ( :Opération )
[Trace de type OBSERVABLE_PROCÉDURE] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Trace de type OBSERVABLE_PROCÉDURE] est un ( :Procédure )
[uneValeur] est un ( :Connaissance constantes (Schéma) )
[Énoncé de type OBSERVABLE] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Conclusion)
[Énoncé de type OBSERVABLE] est un ( :Conclusion d'une règle )
[Énoncé de type OBSERVABLE_AGENT] est de catégorie (metaDom:MD_Strategique_AgentContrainteNorme)
[Énoncé de type OBSERVABLE_AGENT] est un ( :Agent-Contrainte-Norme )
[Énoncé de type OBSERVABLE_CONDITION] est de catégorie (metaDom:MD_Strategique_Condition)
[Énoncé de type OBSERVABLE_CONDITION] est un ( :Condition )
[Énoncé de type OBSERVABLE_RÈGLE_ANTÉCÉDENT] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Énoncé de type OBSERVABLE_RÈGLE_ANTÉCÉDENT] est un ( :Antécédent d'une règle )
[Énoncé de type OBSERVABLE_RÈGLE_COMPLÈTE] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Complete)
[Énoncé de type OBSERVABLE_RÈGLE_COMPLÈTE] est un ( :Règle complète )
[Énoncé de type OBSERVABLE_RÈGLE_NOM] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Nom)
[Énoncé de type OBSERVABLE_RÈGLE_NOM] est un ( :Nom d'une règle )
unEntier est une sorte de (metaDom:MD_Declarative_Schema_Int)
unFloat est une sorte de (metaDom:MD_Declarative_Schema_Float)
------------------Résultats après inférence-----------------------
[Exemple de type OBJET_OBSEERVABLE] est un ( :Connaissance d'objet :Type de connaissances :Connaissance
déclarative )
[Trace de type OBSERVABLE_OPÉRATION] est un ( :Opération :Type de connaissances :Connaissance d'actions )
[Trace de type OBSERVABLE_PROCÉDURE] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
[uneValeur] est un ( :Connaissance constantes (Schéma) :Type de connaissances :Connaissance déclarative )
[Énoncé de type OBSERVABLE] est un ( :Conclusion d'une règle :Type de connaissances :Connaissance stratégique
:Élément d'une règle )
[Énoncé de type OBSERVABLE_AGENT] est un ( :Agent-Contrainte-Norme :Type de connaissances :Connaissance
stratégique )
[Énoncé de type OBSERVABLE_CONDITION] est un ( :Condition :Type de connaissances :Connaissance stratégique )
[Énoncé de type OBSERVABLE_RÈGLE_ANTÉCÉDENT] est un ( :Antécédent d'une règle :Type de connaissances
:Connaissance stratégique :Élément d'une règle )
[Énoncé de type OBSERVABLE_RÈGLE_COMPLÈTE] est un ( :Règle complète :Type de connaissances :Connaissance
stratégique :Élément d'une règle )
[Énoncé de type OBSERVABLE_RÈGLE_NOM] est un ( :Nom d'une règle :Type de connaissances :Connaissance
stratégique :Élément d'une règle )
R
B
B
M
E
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
Comparaison de
s
--------------
-
--------------
-
--------------
-
--------------
-
Concept
Concept
Concept
Concept
Enonce
Enonce
Enonce
Enonce
Enonce
Enonce
Enonce
Exemple
Exemple
Principe
Principe
Principe
Principe
Principe
Principe
Principe
Procédur
e
Procédur
e
Trace
Trace
--------------
-
--------------
-
--------------
-
--------------
-
--------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
B
.3 Spécial
i
B
.3.1 Spéci
a
M
éta-modèle
E
xemple de r
e
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
s
documents :
-
---------------
-
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: Concept
_
0
: UnString
_
20
: unEntier
_
21
: unFloat
_
22
: Enonce-de-ty
p
: Enonce-de-ty
p
: Enonce-de-ty
p
: Enonce-de-ty
p
: Enonce-de-ty
p
: Enonce-de-ty
p
: Enonce-de-ty
p
: Exemple-de-t
y
: uneValeur
_
23
: Principe-de-
t
: Principe-de-
t
: Principe-de-
t
: Principe-de-
t
: Principe-de-
t
: Principe-de-
t
: Principe-de-
t
e
: Procedure-de
-
e
: Procedure-de
-
: Trace-de-typ
e
: Trace-de-typ
e
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
i
sation et l’i
n
a
lisation ent
r
de la rè
g
le d'
u
e
présentation
a
xique
/
workspace/Carré
/
workspace/Carré
-
---------------
a
issances
-
----
-
-
---------------
deux modèles -
--
p
e-OBSERVABLE_16
p
e-OBSERVABLE
_
AG
p
e-OBSERVABLE
_
CO
p
e-OBSERVABLE
_
PR
p
e-OBSERVABLE
_
RE
p
e-OBSERVABLE
_
RE
p
e-OBSERVABLE
_
RE
y
pe-OBJET
_
OBSEER
t
ype-AGENT_3
t
ype-
A
NTECEDENT
_6
t
ype-
C
ONCLUSION
_7
t
ype-CONDITION_5
t
ype-NOM_REGLE_8
t
ype-PROPRIETE_4
t
ype-
R
EGLE
_
COMPL
E
-
type-
O
PERATION
_2
-
type-
P
ROCEDURE
_1
e
-OBSERVABLE
_
OPE
e
-OBSERVABLE
_
PRO
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
-
---------------
-
---------------
-
---------------
p
osants des modè
l
= 4, Reconstru
l
= 2, Reconstru
l
= 7, Reconstru
l
= 7, Reconstru
l
= 2, Reconstru
l
= 2, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
n
stance
r
e deux con
c
u
tilisation
en lan
g
a
g
e
M
D
eSable/ENTITE
_A
D
eSable/ENTITE
_A
-
---------------
-
---------------
-
---------------
-
---------------
E
NT
_
13
N
DITION
_
14
O
PRIETE
_
15
G
LE
_
ANTECEDENT
_
1
G
LE
_
COMPLETE
_
18
G
LE
_
NOM
_
17
V
ABLE
_
10
6
7
E
TE
_
9
2
1
R
ATION
_
12
C
EDURE
_
11
-
---------------
-
---------------
-
---------------
-
---------------
-
-----------
-
---
-
---------------
-
---------------
l
es
-
-----------
i
t = 4,
D
iffére
n
i
t = 2, Différe
n
i
t = 7, Différe
n
i
t = 7, Différe
n
i
t = 2, Différe
n
i
t = 2, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0,
D
iffére
n
i
t = 0, Différe
n
i
t = 0, Différe
n
c
epts, deux
p
M
OT
A
TOMIQUE
_
ONTOCAS
E
A
TOMIQUE
_
ONTOCAS
E
-
--
-
--
-
--
-
---
1
9
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
p
rocédures
e
E
.mot
E_
rest.mot
e
t deux prin
c
2
c
ipes
2
51
S
R
R
S
émantique f
o
:C1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:C2_1
rdf:type
rdfs:lab
e
rdfs:sub
C
:P1_2
rdf:type
rdfs:lab
e
rdfs:sub
C
:P2_3
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr1_4
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr2_5
rdf:type
rdfs:lab
e
rdfs:sub
C
R
è
g
les de dés
a
[Rule-02-a
_
des
a
[Rule-02-b
_
de
s
[Rule-02-c
_
de
s
Rè
g
les de co
n
etat_init.owl
[Rule-00
_
Cree
r
[Rule-00
_
Impo
r
etat
_
creation.
o
[Rule-01-a
_
Cr
e
[Rule-01-b
_
Cr
e
[Rule-01-d
_
Cr
e
etat
_
classific
a
[Rule-02-a
_
Cr
e
[Rule-02-b
_
Cr
e
[Rule-02-c
_
Cr
e
etat_final.owl
[Rule-00
_
Sauv
e
etat
_
validatio
n
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
Comparaison de
s
--------------
-
--------------
-
--------------
-
--------------
-
Concept
Concept
Principe
Principe
Procédur
e
Procédur
e
--------------
-
--------------
-
--------------
-
--------------
-
LienS: s
o
LienS: s
o
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
owl:Class ;
e
l "C2"^^xsd:str
i
C
lassOf :C1
_
0 .
owl:Class ;
e
l "P1"^^xsd:str
i
C
lassOf metaDom:
M
owl:Class ;
e
l "P2"^^xsd:str
i
C
lassOf metaDom:
M
owl:Class ;
e
l "Pr1"^^xsd:st
r
C
lassOf owl:Thin
g
owl:Class ;
e
l "Pr2"^^xsd:st
r
C
lassOf :Pr1
_
4 ,
a
mbi
g
uïsatio
n
a
mb
_
lienS-entre
_C
s
amb
_
lienS
_
entre
_
s
amb
_
lienS
_
entre
_
n
version
r_
ontologie
_
du
_
d
o
r
ter
_
metaOnto
_
du
_
o
wl
e
ation
_
class
_
obj
e
e
ation
_
class
_
Act
i
e
ation
_
class
_
age
n
a
tion.owl
e
ation
_
subClassO
f
e
ation
_
subClassO
f
e
ation
_
subClassO
f
e
garde]
n
.owl
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
s
documents :
-
---------------
-
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: C1
_
0
: C2
_
1
: Pr1
_
4
: Pr2
_
5
e
: P1
_
2
e
: P2
_
3
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
o
urce C2
_
1 : des
t
o
urce P2
_
3 : des
t
i
ng ;
g
, metaDom:MD
_
D
i
ng ;
i
ng ;
M
D
_
Procedurale
_
P
i
ng ;
M
D
_
Procedurale
_
P
r
ing ;
g
, metaDom:MD
_
S
r
ing ;
metaDom:MD
_
Stra
n
t
y
polo
g
ique
C
oncepts]
_
Procedures]
_
Principes]
o
maine]
_
domaine]
e
t
_
Concept]
i
on
_
Procedure]
n
t]
f_
Declaratif]
f_
Procedurale]
f_
Strategique]
a
xique
/
workspace/Carré
/
workspace/Carr
éD
-
---------------
a
issances
-
----
-
-
---------------
deux modèles
-
-
-
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
t
C1
_
0
t
P1
_
2
e
clarative
_
Conce
r
ocedure , owl:T
r
ocedure , :P1
_
2
t
rategique
_
Agent
t
egique
_
AgentCo
n
D
eSable/SPECIALI
D
eSable/SPECIALI
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
e
pt .
T
hing .
.
t
ContrainteNorm
e
n
trainteNorme .
I
SATION
_
ENTRE
_
CO
N
I
SATION
_
ENTRE
_
CO
N
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
---
.
N
CEPTS
_
PROCEDURE
_
N
CEPTS
_
PROCEDURE
_
2
_
PRINCIPE.mot
_
PRINCIPE
_
rest.m
o
2
52
o
t
R
B
M
E
S
LienS: s
o
--------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
C1 est une sor
t
C2 est une sor
t
P1 est une sor
t
P2 est une sor
t
P2 est une sor
t
Pr1 est une so
r
Pr2 est une so
r
Pr2 est une so
r
--------------
-
B
.3.2 Insta
n
M
éta-modèle
E
xemple de r
e
S
émantique f
o
:C1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:En1_5
rdf:type
rdfs:lab
e
:Ex1_3
rdf:type
rdfs:lab
e
:P1_1
rdf:type
o
urce Pr2
_
5 : de
s
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
t
e de (metaDom:M
D
t
e de C1
t
e de (metaDom:M
D
t
e de (metaDom:M
D
t
e de P1
r
te de (metaDom:
M
r
te de (metaDom:
M
r
te de Pr1
-
---Résultats ap
r
n
ciation entr
e
de la rè
g
le d'
u
e
présentation
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
:Pr1
_
2 ;
e
l "En1"^^xsd:st
r
:C1
_
0 ;
e
l "Ex1"^^xsd:st
r
owl:Class ;
s
t Pr1
_
4
-
---------------
-
---------------
-
---------------
p
osants des modè
l
= 2, Reconstru
l
= 2, Reconstru
l
= 2, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 3, Reconstru
a
ntique
e
validation
s
ém
a
D_
Declarative
_
Co
D_
Procedurale
_
Pr
D_
Procedurale
_
Pr
M
D
_
Strategique
_
A
M
D
_
Strategique
_
A
r
ès inférence
-
--
-
e
une abstra
c
u
tilisation
en lan
g
a
g
e
M
i
ng ;
g
, metaDom:MD
_
D
r
ing .
r
ing .
-
---------------
-
---------
-
-----
-
---------------
l
es
-
-----------
i
t = 2, Différe
n
i
t
=
2, Différe
n
i
t = 2, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Di
f
fére
n
i
t = 3, Différe
n
a
ntique
-
--------
n
cept)
o
cedure)
o
cedure)
g
entContrainteNo
g
entContrainteNo
-
---------------
c
tion et son
o
M
OT
e
clarative
_
Conce
-
--
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
o
rme)
o
rme)
-
----
o
bservable
e
pt .
2
2
53
254
rdfs:label "P1"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Pr1_2
rdf:type owl:Class ;
rdfs:label "Pr1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme .
:Tr1_4
rdf:type :P1_1 ;
rdfs:label "Tr1"^^xsd:string .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
[Rule-00-b-desamb_LienI]
[Rule-03-a_desamb_LienI_Concept_Exemple-OBJET]
[Rule-03-aa_desamb_exemple_Concept_Instance]
[Rule-03-b_desamb_LienI_Principe_Enonce]
[Rule-03-c_desamb_LienI_Procedure_Trace-PROCEDURE]
Le principe et l’énoncé sont désambiguïsés de manière manuelle
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2a_Creation_Individu_objet]
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2d_Creation_Individu_Principe_Agent]
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-d_Creation_class_agent]
etat_classification.owl
[Rule-03-a_Creation_typeOf_OBJET]
[Rule-03-b_Creation_typeOf_ACTION-PROCEDURE]
[Rule-03-c_Creation_typeOf_PRINCIPE-AGENT]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/INSTANCE_ENTRE_CONN_ABSTRAITES_CONN_FACTUELS.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/INSTANCE_ENTRE_CONN_ABSTRAITES_CONN_FACTUELS_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_0
Enonce : En1_5
Exemple : Ex1_3
Principe : Pr1_2
Procédure : P1_1
Trace : Tr1_4
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienI: source C1_0 : dest Ex1_3
LienI: source P1_1 : dest Tr1_4
LienI: source Pr1_2 : dest En1_5
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 1, Reconstruit = 1, Différence = 0
Compte des Procedures: Original = 1, Reconstruit = 1, Différence = 0
Compte des Principes : Original = 1, Reconstruit = 1, Différence = 0
Compte des Enonces : Original = 1, Reconstruit = 1, Différence = 0
Compte des Traces : Original = 1, Reconstruit = 1, Différence = 0
Compte des Exemples : Original = 1, Reconstruit = 1, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 3, Reconstruit = 3, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
R
B
B
M
E
S
R
apport de v
a
----------Débu
t
C1 est une sor
t
P1 est une sor
t
Pr1 est une so
r
[En1] est de c
a
[En1] est un (
[Ex1] est de c
a
[Ex1] est un (
[Tr1] est de c
a
[Tr1] est un (
--------------
-
[En1] est un (
[Ex1] est un (
[Tr1] est un (
B
.4 Intrant
e
B
.4.1 Intran
t
M
éta-modèle
E
xemple de r
e
Les obs
e
observa
b
S
émantique f
o
:C1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:C2_1
rdf:type
rdfs:lab
e
rdfs:sub
C
:P1_2
rdf:type
rdfs:lab
e
rdfs:sub
C
:P1
_
2
_
aPourInt
r
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:P2_3
rdf:type
rdfs:lab
e
rdfs:sub
C
:P2
_
3
_
aPourPro
d
a
lidation sém
a
t
du processus d
e
t
e de (metaDom:M
D
t
e de (metaDom:M
D
r
te de (metaDom:
M
a
tégorie (metaDo
m
:Pr1 )
a
tégorie (metaDo
m
:C1 )
a
tégorie (metaDo
m
:P1 )
-
---Résultats ap
r
:Pr1 :Type de c
o
:C1 :Type de co
n
:P1 :Type de co
n
e
t le produit
t
-produit en
t
de la rè
g
le d'
u
e
présentation
e
rvables de C
b
les procédural
e
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
owl:Class ;
e
l "C2"^^xsd:str
i
C
lassOf owl:Thin
g
owl:Class ;
e
l "P1"^^xsd:str
i
C
lassOf metaDom:
M
r
ant
_
C1
_
0
owl:ObjectPrope
r
a
in :P1
_
2 ;
e
l ""^^xsd:strin
g
g
e :C1
_
0 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "P2"^^xsd:str
i
C
lassOf metaDom:
M
d
uit
_
C2
_
1
a
ntique
e
validation
s
ém
a
D_
Declarative
_
Co
D_
Procedurale
_
Pr
M
D
_
Strategique
_
A
m
:MD
_
Strategique
m
:MD
_
Declarative
m
:MD
_
Procedurale
r
ès inférence
-
--
-
o
nnaissances
:
Co
n
n
naissances :Con
n
naissances :Con
t
re connaiss
a
u
tilisation
en lan
g
a
g
e
M
1 sont les in
t
e
s de P1
i
ng ;
g
, metaDom:MD
_
D
i
ng ;
g
, metaDom:MD
_
D
i
ng ;
M
D
_
Procedurale
_
P
r
ty ;
g
;
o
m:A-POUR-
I
NTRAN
T
i
ng ;
M
D
_
Procedurale
_
P
a
ntique
-
--------
n
cept)
o
cedure)
g
entContrainteNo
_
AgentContrainte
_
Concept)
_
Procedure)
-
---------------
n
naissance strat
n
aissance décla
r
n
aissance d'acti
a
nces d’acti
o
M
OT
t
rants des L
e
o
b
e
clarative
_
Conce
e
clarative
_
Conce
r
ocedure ,
o
wl:T
T
.
r
ocedure , owl:T
-
----
o
rme)
e
Norme)
-
----
t
égique :Agent-
Co
r
ative :Connaiss
a
i
ons :Procédure )
o
n et d’obje
t
es observable
s
b
servables pro
c
e
pt .
e
pt .
T
hing .
T
hing .
o
ntrainte-Norme
)
a
nce d'objet )
t
de niveau
a
s
de C1 sont
cédurales de P
2
)
a
bstrait
les produits
d
P
1
2
55
d
es
256
rdf:type owl:ObjectProperty ;
rdfs:domain :P2_3 ;
rdfs:label ""^^xsd:string ;
rdfs:range :C2_1 ;
rdfs:subPropertyOf metaDom:A-POUR-PRODUIT .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
[Rule-04-a_desamb_Relation_A-POUR-INTRANT]
[Rule-04-b_desamb_Relation_A-POUR-PRODUIT]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-03-a_Creation_Propriete_A-POUR-INTRANT]
[Rule-03-b_Creation_Propriete_A-POUR-PRODUIT]
etat_classification.owl
[Rule-04-a_Ajout_Image_Domaine_A-POUR-INTRANT]
[Rule-04-b_Ajout_Image_Domaine_A-POUR-PRODUIT]
etat_final.owl
[Rule-00_Sauvegarde]
etat_validation.owl
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/INTRANT_PRODUIT_CONCEPT_PROCEDURE.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/INTRANT_PRODUIT_CONCEPT_PROCEDURE_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_0
Concept : C2_1
Procédure : P1_2
Procédure : P2_3
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienIP: source C1_0 : dest P1_2
LienIP: source P2_3 : dest C2_1
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 2, Reconstruit = 2, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 0, Reconstruit = 0, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
C1 est un intrant de P1
C1 est une sorte de (metaDom:MD_Declarative_Concept)
C2 est une sorte de (metaDom:MD_Declarative_Concept)
P1 est une sorte de (metaDom:MD_Procedurale_Procedure)
P2 a pour produit C2
P2 est une sorte de (metaDom:MD_Procedurale_Procedure)
------------------Résultats après inférence-----------------------
B
M
E
S
R
R
R
B
.4.2 Intran
t
M
éta-modèle
E
xemple de r
e
S
émantique f
o
:Ex1_0
rdf:type
rdfs:lab
e
:Ex2_3
rdf:type
rdfs:lab
e
:Tr1_1
rdf:type
rdfs:lab
e
metaDom:
A
:Tr2_2
rdf:type
rdfs:lab
e
metaDom:
A
R
è
g
les de dés
a
regles
_
desambi
g
regles
_
desambi
g
[Rule-05-a
_
de
s
[Rule-05-b
_
de
s
R
è
g
les de con
v
etat_init.owl
[Rule-00
_
Cree
r
[Rule-00
_
Impo
r
etat
_
creation.
o
[Rule-01-2a
_
C
r
[Rule-01-2b
_
C
r
etat
_
classific
a
[Rule-05-a
_
Cr
e
[Rule-05-b
_
Cr
e
etat_final.owl
[Rule-00
_
Sauv
e
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
Comparaison de
s
--------------
-
--------------
-
--------------
-
--------------
-
Exemple
t
-produit en
t
de la rè
g
le d'
u
e
présentation
o
rmelle
metaDom:MD
_
Decl
a
e
l "Ex1"^^xsd:st
r
metaDom:MD
_
Decl
a
e
l "Ex2"^^xsd:st
r
metaDom:MD
_
Proc
e
e
l "Tr1"^^xsd:st
r
A
-POUR-INTRANT :
E
metaDom:MD
_
Proc
e
e
l "Tr2"^^xsd:st
r
A
-POUR-PRODUIT
:
a
mbi
g
uïsatio
n
g_
topologique.ow
l
g_
typologique.ow
l
s
amb
_
Relation
_
A-
P
s
amb
_
Relation
_
A-
P
v
ersion
r_
ontologie
_
du
_
d
o
r
ter
_
metaOnto
_
du
_
o
wl
r
eation
_
Individu
_
r
eation
_
Individu
_
a
tion.owl
e
ation
_
propriete
_
e
ation
_
propriete
_
e
garde]
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
s
documents :
-
---------------
-
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: Ex1
_
0
t
re des conn
a
u
tilisation
en lan
g
a
g
e
M
a
rative
_
Concept
r
ing .
a
rative
_
Concept
r
ing .
e
durale
_
Procedur
r
ing ;
E
x1
_
0 .
e
durale
_
Procedur
r
ing ;
:
Ex2
_
3 .
n
l
l
P
OUR-
I
NTRANT
_
obs
e
P
OUR-
P
RODUIT
_
obs
e
o
maine]
_
domaine]
_
objet]
_
procedural]
_
A-POUR-
P
RODUIT
_a
_
A-POUR-
I
NTRANT
_a
a
xique
/
workspace/Carré
/
workspace/Carré
-
---------------
a
issances
-
----
-
-
---------------
deux modèles
-
-
-
a
issances d’
M
OT
;
;
e
;
e
;
e
rvables]
e
rvables]
a
ssertion]
a
ssertion]
D
eSable/INTRANT
_
D
eSable/INTRANT
_
-
---------------
-
---------------
-
---------------
-
---------------
action et d’
o
_
PRODUIT
_
TRACE
_
E
X
_
PRODUIT
_
TRACE
_
E
X
-
--
-
--
-
--
-
---
o
bjet observ
a
X
EMPLE.mot
X
EMPLE
_
rest.mot
2
a
bles
2
57
-
R
B
B
M
E
Exemple
Trace
Trace
--------------
-
--------------
-
--------------
-
--------------
-
LienIP:
s
LienIP:
s
-
-------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
[Ex1] est de c
a
[Ex1] est un (
[Ex2] est de c
a
[Ex2] est un (
[Tr1] a pour i
n
[Tr1] est de c
a
[Tr1] est un (
[Tr2] a pour p
r
[Tr2] est de c
a
[Tr2] est un (
--------------
-
[Ex1] est l'in
t
[Ex1] est un (
[Ex2] est le p
r
[Ex2] est un (
[Tr1] est un (
[Tr2] est un (
B
.5 Régulat
i
B
.5.1 Régul
a
M
éta-modèle
E
xemple de r
e
: Ex2
_
3
: Tr1
_
1
: Tr2
_
2
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
s
ource Ex1
_
0 : d
e
s
ource Tr2
_
2 : d
e
-
--------------
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
a
tégorie (metaDo
m
:Connaissance d
'
a
tégorie (metaDo
m
:Connaissance d
'
n
trant [Ex1]
a
tégorie (metaDo
m
:Procédure )
r
oduit [Ex2]
a
tégorie (metaDo
m
:Procédure )
-
---Résultats ap
r
t
rant de [Tr1]
:Connaissance d
'
r
oduit de [Tr2]
:Connaissance d
'
:Procédure :Typ
e
:Procédure :Typ
e
i
on
a
tion entre
c
de la rè
g
le d'
u
e
présentation
-
------------
-
--
-
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
e
st Tr1
_
1
e
st Ex2
_
3
--------------
-
-
---------------
-
---------------
p
osants des modè
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 2, Reconstru
l
= 2, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 2, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
a
ntique
e
validation
s
ém
a
m
:MD
_
Declarative
'
objet )
m
:MD
_
Declarative
'
objet )
m
:MD
_
Procedurale
m
:MD
_
Procedurale
r
ès inférence
-
--
-
'
objet :Type de
'
objet :Type
d
e
c
e
de connaissanc
e
de connaissanc
c
onnaissanc
e
u
tilisation
en lan
g
a
g
e
M
-
---------------
-
---------------
-
---------------
-
---------------
-
-------------
-
-
---------------
-
---------------
l
es
-
-----------
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 2, Différe
n
i
t = 2, Différe
n
i
t =
0
, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 2, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
a
ntique
-
--------
_
Concept)
_
Concept)
_
Procedure)
_
Procedure)
-
---------------
c
onnaissances :C
c
onnaissances :C
e
s :Connaissance
e
s :Connaissance
e
s abstraites
M
OT
-
--
-
--
-
--
-
---
-
------
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
-
----
C
onnaissance déc
l
C
onnaissance déc
l
e
d'actions )
e
d'actions )
l
arative )
l
arative )
2
2
58
S
R
R
S
émantique f
o
:C1_1
rdf:type
rdfs:lab
e
rdfs:sub
C
:P2_3
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr1
_
0
_
regit
_
C
1
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:Pr2_2
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr2
_
2
_
regit
_
P
2
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:Pr3_4
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr3
_
4
_
regit
_
P
r
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:Pr4_5
rdf:type
rdfs:lab
e
rdfs:sub
C
R
è
g
les de dés
a
regles
_
desambi
g
regles
_
desambi
g
[Rule-06-a
_
de
s
[Rule-06-b
_
de
s
[Rule-06-c
_
de
s
Rè
g
les de co
n
etat_init.owl
[Rule-00
_
Cree
r
[Rule-00
_
Impo
r
etat
_
creation.
o
[Rule-01-a
_
Cr
e
[Rule-01-b
_
Cr
e
[Rule-01-d
_
Cr
e
[Rule-06-a
_
Cr
e
[Rule-06-b
_
Cr
e
[Rule-06-c
_
Cr
e
etat
_
classific
a
[Rule-06-a
_
Aj
o
[Rule-06
_
b
_
Aj
o
[Rule-06
_
c
_
Aj
o
etat_final.owl
[Rule-00
_
Sauv
e
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
owl:Class ;
e
l "P2"^^xsd:str
i
C
lassOf metaDom:
M
owl:Class ;
e
l "Pr1"^^xsd:st
r
C
lassOf owl:Thin
g
1_
1
owl:ObjectPrope
r
a
in :Pr1
_
0 ;
e
l ""^^xsd:strin
g
g
e :C1
_
1 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "Pr2"^^xsd:st
r
C
lassOf owl:Thin
g
2_
3
owl:ObjectPrope
r
a
in :Pr2
_
2 ;
e
l ""^^xsd:strin
g
g
e :P2
_
3 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "Pr3"^^xsd:st
r
C
lassOf owl:Thin
g
r
4
_
5
owl:ObjectPrope
r
a
in :Pr3
_
4 ;
e
l ""^^xsd:strin
g
g
e :Pr4
_
5 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "Pr4"^^xsd:st
r
C
lassOf owl:Thin
g
a
mbi
g
uïsatio
n
g_
topologique.ow
l
g_
typologique.ow
l
s
amb
_
LienR
_
Princ
i
s
amb
_
LienR
_
Princ
i
s
amb
_
LienR
_
Princ
i
n
version
r_
ontologie
_
du
_
d
o
r
ter
_
metaOnto
_
du
_
o
wl
e
ation
_
class
_
obj
e
e
ation
_
class
_
Act
i
e
ation
_
class
_
age
n
e
ation
_
Propriete
_
e
ation
_
Prop
_
Regi
r
e
ation
_
Prop
_
Regi
r
a
tion.owl
o
ut
_
ImgDom
_
Prop
_R
o
ut
_
ImgDom
_
Prop
_R
o
ut
_
ImgDom
_
Prop
_R
e
garde]
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
i
ng ;
g
, metaDom:MD
_
D
i
ng ;
M
D
_
Procedurale
_
P
r
ing ;
g
, metaDom:MD
_
S
r
ty ;
g
;
o
m:REGIT .
r
ing ;
g
, metaDom:MD
_
S
r
ty ;
g
;
o
m:REGIT .
r
ing ;
g
, metaDom:MD
_
S
r
ty ;
g
;
o
m:REGIT .
r
ing ;
g
, metaDom:MD
_
S
n
l
l
i
pe
_
Concept]
i
pe
_
Procedure]
i
pe
_
Principe]
o
maine]
_
domaine]
e
t
_
Concept]
i
on
_
Procedure]
n
t]
_
Regit]
r_
une
_
procedure]
r_
un
_
autre
_
princ
R
EGIT]
R
egit
_
Procedure]
R
egit
_
Principes]
a
xique
/
workspace/Carré
/
workspace/Carré
e
clarative
_
Conce
r
ocedure , owl:T
t
rategi
q
ue
_
Agent
t
rategique
_
Agent
t
rategique
_
Agent
t
rategique
_
A
gent
i
pe]
D
eSable/REGULATI
D
eSable/REGULATI
e
pt .
T
hing .
t
ContrainteNorme
t
ContrainteNorme
t
ContrainteNorme
t
ContrainteNorme
I
ON
_
PRINCIPE
_
CON
C
I
ON
_
PRINCIPE
_
CON
C
.
.
.
.
C
EPT.mot
C
EPT
_
rest.mot
2
2
59
R
B
p
M
E
Comparaison de
s
--------------
-
--------------
-
--------------
-
--------------
-
Concept
Principe
Principe
Principe
Principe
Procédur
e
--------------
-
--------------
-
--------------
-
--------------
-
LienR: s
o
LienR: s
o
LienR: s
o
--------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
C1 est une sor
t
P2 est une sor
t
Pr1 est une so
r
Pr1 régit C1
Pr2 est une so
r
Pr2 régit P2
Pr3 est une so
r
Pr3 régit Pr4
Pr4 est une so
r
--------------
-
B
.5.2 Interp
r
p
rocédures
e
M
étamodèle
d
E
xemple de r
e
s
documents :
-
---------------
-
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: C1
_
1
: Pr1
_
0
: Pr2
_
2
: Pr3
_
4
: Pr4
_
5
e
: P2
_
3
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
o
urce Pr1
_
0 : de
s
o
urce Pr2
_
2 : de
s
o
urce Pr3
_
4 : de
s
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
t
e de (metaDom:M
D
t
e de (metaDom:M
D
r
te de (metaDom:
M
r
te de (metaDom:
M
r
te de (metaDom:
M
r
te de (metaDom:
M
-
---Résultats ap
r
r
étation de
l
e
t de princip
d
e l’utilisatio
n
e
présentation
-
---------------
a
issances
-
----
-
-
---------------
deux modèles
-
-
-
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
s
t C1
_
1
s
t P2
_
3
s
t Pr4
_
5
-
---------------
-
---------------
-
---------------
p
osants des modè
l
= 1, Reconstru
l
= 1, Reconstru
l
= 4, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0,
R
econstru
i
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 3, Reconstru
l
= 0, Reconstru
a
ntique
e
validation
s
ém
a
D_
Declarative
_
Co
D_
Procedurale
_
Pr
M
D
_
Strategique
_
A
M
D
_
Strategique
_
A
M
D
_
Strategique
_
A
M
D
_
Strategique
_
A
r
ès inférence
-
--
-
l
a régulatio
n
es.
n
de la règle
en lan
g
a
g
e
M
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
-------------
-
-
-
---------------
-
---------------
-
---------------
l
es
-
-----------
i
t = 1, Différe
n
i
t = 1, Dif
f
ére
n
i
t = 4, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 3, Différe
n
i
t = 0, Différe
n
a
ntique
-
--------
n
cept)
o
cedure)
g
entContrainteNo
g
entContrainteNo
g
entContrainteNo
g
entContrainteNo
-
---------------
n
entre un é
n
M
OT
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
o
rme)
o
rme)
o
rme)
o
rme)
-
----
noncé et des obse
r
vabl
e
2
e
s d’objets,
2
60
de
S
R
R
S
émantique f
o
:En1_0
rdf:type
rdfs:lab
e
metaDom:
R
:En2_1
rdf:type
rdfs:lab
e
metaDom:
R
:En3_2
rdf:type
rdfs:lab
e
metaDom:
R
:En4_5
rdf:type
rdfs:lab
e
:Ex1_3
rdf:type
rdfs:lab
e
:Tr2_4
rdf:type
rdfs:lab
e
R
è
g
les de dés
a
regles
_
desambi
g
regles
_
desambi
g
[Rule-07-a
_
de
s
[Rule-07-b
_
de
s
[Rule-07-c
_
de
s
Rè
g
les de co
n
etat_init.owl
[Rule-00
_
Cree
r
[Rule-00
_
Impo
r
etat
_
creation.
o
[Rule-01-2a
_
C
r
[Rule-01-2b
_
C
r
[Rule-01-2d
_
C
r
etat
_
classific
a
[Rule-07-a
_
Cr
e
[Rule-07-b
_
Cr
e
[Rule-07-c
_
Cr
e
etat_final.owl
[Rule-00
_
Sauv
e
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
Comparaison de
s
--------------
-
--------------
-
--------------
-
--------------
-
Enonce
Enonce
Enonce
Enonce
Exemple
Trace
--------------
-
--------------
-
--------------
-
--------------
-
LienR: s
o
LienR: s
o
LienR: s
o
--------------
-
--------------
-
--------------
-
---------Totau
x
o
rmelle
metaDom:MD
_
Stra
t
e
l "En1"^^xsd:st
r
R
EGIT :Ex1
_
3 .
metaDom:MD
_
Stra
t
e
l "En2"^^xsd:st
r
R
EGIT :Tr2
_
4 .
metaDom:MD
_
Stra
t
e
l "En3"^^xsd:st
r
R
EGIT :En4
_
5 .
metaDom:MD
_
Stra
t
e
l "En4"^^xsd:st
r
metaDom:MD
_
Decl
a
e
l "Ex1"^^xsd:st
r
metaDom:MD
_
Proc
e
e
l "Tr2"^^xsd:st
r
a
mbi
g
uïsatio
n
g_
topologique.ow
l
g_
typologique.ow
l
s
amb
_
LienR
_
Enonc
e
s
amb
_
LienR
_
Enonc
e
s
amb
_
LienR
_
Enonc
e
n
version
r_
ontologie
_
du
_
d
o
r
ter
_
metaOnto
_
du
_
o
wl
r
eation
_
Individu
_
r
eation
_
Individu
_
r
eation
_
Individu
_
a
tion.owl
e
ation
_
propriete
_
e
ation
_
Regit
_
eno
n
e
ation
_
Regit
_
ent
r
e
garde]
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
s
documents :
-
---------------
-
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: En1
_
0
: En2
_
1
: En3
_
2
: En4
_
5
: Ex1
_
3
: Tr2_4
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
o
urce En1
_
0 : de
s
o
urce En2
_
1 : de
s
o
urce En3
_
2 : de
s
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
t
egique
_
AgentCon
r
ing ;
t
egique
_
AgentCon
r
ing ;
t
egique
_
AgentCon
r
ing ;
t
egique
_
AgentCon
r
ing .
a
rative
_
Concept
r
ing .
e
durale
_
Procedur
r
ing .
n
l
l
e_
Exemple]
e_
Trace]
e_
Enonce]
o
maine]
_
domaine]
_
objet]
_
procedural]
_
Principe
_
Agent]
_
regit
_
entre
_
eno
n
ce
_
trace]
r
e
_
deux
_
enonces]
a
xique
/
workspace/Carré
/
workspace/Carré
-
---------------
a
issances
-
----
-
-
---------------
deux modèles
-
-
-
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
s
t Ex1
_
3
s
t Tr2
_
4
s
t En4
_
5
-
---------------
-
---------------
-
---------------
p
osants des modè
t
rainteNorme ;
t
rainteNorme ;
t
rainteNorme ;
t
rainteNorme ;
;
e
;
n
ce
_
exemple]
D
eSable/REGULATI
D
eSable/REGULATI
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------
-
-----
-
---------------
-
---------------
-
---------------
l
es
-
-----------
I
ON
_
ENONCE
_
OBSER
V
I
ON
_
ENONCE
_
OBSER
V
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
--
V
ABLES.mot
V
ABLES
_
rest.mot
2
2
61
R
B
B
E
S
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
[En1] est de c
a
[En1] est un (
[En1] régit [E
x
[En2] est de c
a
[En2] est un (
[En2] régit [T
r
[En3] est de c
a
[En3] est un (
[En3] régit [E
n
[En4] est de c
a
[En4] est un (
[Ex1] est de c
a
[Ex1] est un (
[Tr2] est de c
a
[Tr2] est un (
--------------
-
[En1] est un (
[En2] est un (
[En3] est un (
[En4] est un (
[En4] obéit à
[
[Ex1] est un (
[Ex1] obéit à
[
[Tr2] est un (
[Tr2] obéit à
[
B
.6 Proprié
t
B
.6.1 Défin
i
E
xemple de r
e
S
émantique f
o
:C1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:C1
_
0
_
Pr1
_
1
_
C2
_
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:C2_2
rdf:type
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
a
tégorie (metaDo
m
:Agent-Contrain
t
x
1]
a
tégorie (metaDo
m
:Agent-Contrain
t
r
2]
a
tégorie (metaDo
m
:Agent-Contrain
t
n
4]
a
tégorie (metaDo
m
:Agent-Contrain
t
a
tégorie (metaDo
m
:Connaissance d
'
a
tégorie (metaDo
m
:Procédure )
-
---Résultats ap
r
:Agent-Contrain
t
:Agent-Contrain
t
:Agent-Contrain
t
:Agent-Contrain
t
[
En3]
:Connaissance d
'
[
En1]
:Procédure :Typ
e
[
En2]
t
é
i
tion d’un d
o
e
présentation
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
_
2
owl:ObjectPrope
r
a
in :C1
_
0 ;
e
l "Pr1"^^xsd:st
r
g
e :C2
_
2 ;
P
ropertyOf :Pr1
_1
owl:Class ;
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 4, Reconstru
l
= 1, Reconstru
l
= 1,
R
econstru
i
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 3, Reconstru
l
= 0, Reconstru
a
ntique
e
validation sém
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Declarative
'
objet )
m
:MD
_
Procedurale
r
ès inférence
-
--
-
t
e-Norme :Type d
t
e-Norme :Type d
t
e-Norme :Type d
t
e-Norme :Type d
'
objet :Type de
e
de connaissanc
o
maine et d’
u
en lan
g
a
g
e
M
i
ng ;
g
, metaDom:MD
_
D
r
ty ;
r
ing ;
1
.
i
t = 0, Différe
n
i
t = 0, Di
f
fére
n
i
t = 0, Différe
n
i
t = 4, Différe
n
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 3, Différe
n
i
t = 0, Différe
n
a
ntique
-
--------
_
AgentContrainte
_
AgentContrainte
_
AgentContrainte
_
AgentContrainte
_
Concept)
_
Procedure)
-
---------------
e
connaissances
e
connaissances
e
connaissances
e
connaissances
c
onnaissances :C
e
s :Connaissance
u
ne image
à
M
OT
e
clarative
_
Conce
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
e
Norme)
e
Norme)
e
Norme)
e
Norme)
-
----
:Connaissance s
t
:Connaissance s
t
:Connaissance s
t
:Connaissance s
t
C
onnaissance déc
l
e
d'actions )
à
une propri
é
e
pt .
t
ratégique )
t
ratégique )
t
ratégique )
t
ratégique )
l
arative )
é
té entre des
2
objets
2
62
263
rdfs:label "C2"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:En1_4
rdf:type owl:ObjectProperty ;
rdfs:label "En1"^^xsd:string ;
rdfs:subPropertyOf metaDom:MD_ASSERTION .
:Ex1_3
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Ex1"^^xsd:string ;
:En1_4 :Ex2_5 .
:Ex2_5
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Ex2"^^xsd:string .
:Pr1_1
rdf:type owl:ObjectProperty ;
rdfs:label "Pr1"^^xsd:string ;
rdfs:subPropertyOf metaDom:MD_PROPRIETE .
Règles de désambiguïsation
regles_desambig_topologique.owl
[Rule-08-a_desamb_Principe_entre_concept]
[Rule-08-b_desamb_Enonces_entre_exemple]
regles_desambig_typologique.owl
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2-5k_Creation_AssertionDeDomaine]
[Rule-01-2a_Creation_Individu_objet]
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-k_Creation_ProprieteDeDomaine]
[Rule-08_Creation_dune_propriete_objet_DECLARATIF]
etat_classification.owl
[Rule-08-a_Ajout_ImgDom_a_une_propriete_objet]
[Rule-08-b_Creation_propriete_entre_deux_individus]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PROPRIETE-ENTRE-OBJETS.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PROPRIETE-ENTRE-OBJETS_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_0
Concept : C2_2
Enonce : En1_4
Exemple : Ex1_3
Exemple : Ex2_5
Principe : Pr1_1
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienR: source C1_0 : dest Pr1_1
LienR: source En1_4 : dest Ex2_5
LienR: source Ex1_3 : dest En1_4
LienR: source Pr1_1 : dest C2_2
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 2, Reconstruit = 2, Différence = 0
Compte des Procedures: Original = 0, Reconstruit = 0, Différence = 0
Compte des Principes : Original = 1, Reconstruit = 1, Différence = 0
Compte des Enonces : Original = 1, Reconstruit = 1, Différence = 0
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 4, Reconstruit = 4, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
B
B
S
----------Débu
t
C1 Pr1 C2
C1 est une sor
t
C2 est une sor
t
En1_4([],[]) e
s
[Ex1] est de c
a
[Ex1] est un (
[Ex2] est de c
a
[Ex2] est un (
--------------
-
[Ex1] est un (
[Ex2] est un (
B
.6.2 Propr
i
B
.6.3 Exem
p
S
émantique f
o
:C1_2
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
:C2_3
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
:LienR
_
C1
_
2
_
Pr
1
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
:LienR
_
Pr2
_
1
_
C
2
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
:Pr1_0
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
ot:OT
_
es
t
ot:OT_no
m
:Pr2_1
rdf:type
metaMot:
M
metaMot:
M
metaMot:
M
metaMot:
M
ot:OT
_
En
t
ot:OT
_
es
t
ot:OT
_
no
m
t
du processus d
e
t
e de (metaDom:M
D
t
e de (metaDom:M
D
s
t une assertion
a
tégorie (metaDo
m
:Connaissance d
'
a
tégorie (metaDo
m
:Connaissance d
'
-
---Résultats ap
r
:Connaissance d
'
:Connaissance d
'
i
étés unaires
p
le de repré
s
o
rmelle
metaMot:MOT
_
Con
c
M
OT
_
estNonDeterm
i
M
OT
_
etiquette
M
OT
_
lrEstLaSourc
e
M
OT
_
nomConnaissa
n
t
iteEstDeType
metaMot:MOT
_
Con
c
M
OT
_
estNonDeterm
i
M
OT
_
etiquette
M
OT
_
lrEstLaDesti
n
M
OT
_
nomConnaissa
n
t
iteEstDeType
1_
0
metaMot:MOT
_
Lie
n
M
OT
_
estNonDeterm
i
M
OT
_
lrConnDest
M
OT
_
lrConnSrc
M
OT
_
nomLien
t
iteEstDeType
2_
3
metaMot:MOT
_
Lie
n
M
OT
_
estNonDeterm
i
M
OT
_
lrConnDest
M
OT
_
lrConnSrc
M
OT
_
nomLien "Lie
n
t
iteEstDeType
metaMot:MOT
_
Pri
n
M
OT
_
estNonDeterm
i
M
OT
_
etiquette
M
OT
_
lrEstLaDesti
n
M
OT
_
nomConnaissa
n
t
iteEstDeType
t
LaDestinationDu
n
m
EntiteSource
metaMot:MOT
_
Pri
n
M
OT
_
estNonDeterm
i
M
OT
_
etiquette
M
OT
_
lrEstLaSourc
e
M
OT
_
nomConnaissa
n
t
iteEstDeType
t
LaSourceDuneReg
u
m
EntiteDestinati
o
e
validation
s
ém
a
D_
Declarative
_
Co
D_
Declarative
_
Co
de la propriété
m
:MD
_
Declarative
'
objet )
m
:MD
_
Declarative
'
objet )
r
ès inférence
-
--
-
'
objet :Type de
'
objet :Type de
s
entation en
c
ept ;
i
ne "false"^^xs
"C1"^^xsd:s
e
:LienR
_
C1
_
2
n
ce "C1
_
2"^^xsd
oAmbig:Conc
c
ept ;
i
ne "false"^^x
"C2"^^xsd:
n
ation :LienR
_
Pr
n
ce "C2
_
3"^^x
oAmbig:Co
n
R ;
i
ne "false"^
:Pr1
_
0 ;
:C1
_
2 ;
"LienR
_
C1
_
2
_
Pr1
oAmbig:Relation
n
R ;
i
ne "false"^^
:C2
_
3 ;
:Pr2
_
1 ;
n
R
_
Pr2
_
1
_
C2
_
3"^^
oAmbig:Relatio
n
cipe ;
i
ne "false"^^x
"Pr1"^^xsd
n
ation :LienR
_
C
n
ce "Pr1
_
0"^
oAmbig:Proprie
n
eRegulation "t
"C1
_
2"^^xsd:str
n
cipe ;
i
ne "false"^^x
"Pr2"^^xsd
e
:LienR
_
Pr2
n
ce "Pr2
_
1"^^x
oAmbig:Pro
u
lation "true"^^
o
n "C2
_
3"^^xsd:
a
ntique
-
--------
n
cept)
n
cept)
(
metaDom:MD
_
ASS
_
Concept)
_
Concept)
-
---------------
c
onnaissances :C
c
onnaissances :C
langage M
O
d
:boolean ;
t
ring ;
_
Pr1
_
0 ;
:
string ;
e
pt
_
Classe .
s
d:boolean ;
s
tring ;
2_
1
_
C2
_
3 ;
s
d:string ;
n
cept
_
Classe .
^
xsd:boolean ;
_
0"^^xsd:string
_
Regulation .
x
sd:boolean ;
x
sd:string ;
n_
Regulation .
s
d:boolean ;
:
string ;
1_
2
_
Pr1
_
0 ;
^
xsd:string ;
t
e
_
Unaire ;
r
ue"^^xsd:boole
a
i
ng .
s
d:boolean ;
:
string ;
_
1
_
C2
_
3 ;
s
d:string ;
p
riete
_
Unaire ;
x
sd:boolean ;
s
tring .
-
----
S
ERTION)
-
----
C
onnaissance déc
l
C
onnaissance déc
l
O
T
;
a
n ;
l
arative )
l
arative )
2
2
64
265
Règles de désambiguïsation
Une désambiguïsation manuelle doit être réalisée pour que ceux-ci soient interprétés
en tant que propriété
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-a_Creation_class_objet_Concept]
[Rule-09-a_Creation_SuperPropriete_unaire]
[Rule-09-b_Creation_propriete_unaire_Image]
[Rule-09-c_Creation_propriete_unaire_Domaine]
etat_classification.owl
[Rule-09-a_Ajout_Image_Propriete_Unaire]
[Rule-09-b_Ajout_Domaine_Propriete_Unaire]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PROPRIÉTE_UNAIRE.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PROPRIÉTE_UNAIRE_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_2
Concept : C2_3
Principe : Pr1_0
Principe : Pr2_1
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienR: source C1_2 : dest Pr1_0
LienR: source Pr2_1 : dest C2_3
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 2, Reconstruit = 2, Différence = 0
Compte des Procedures: Original = 0, Reconstruit = 0, Différence = 0
Compte des Principes : Original = 2, Reconstruit = 2, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
C1 est une sorte de (metaDom:MD_Declarative_Concept)
C2 est une sorte de (metaDom:MD_Declarative_Concept)
------------------Résultats après inférence-----------------------
B.7 Composition entre connaissances
B.7.1 Holonyme entre deux abstractions
Méta-modèle de la règle d'utilisation
E
S
R
L
m
E
xemple de r
e
S
émantique f
o
:C1_0
rdf:type
rdfs:lab
e
rdfs:sub
C
:C1
_
0
_
aPourCom
p
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:C2_1
rdf:type
rdfs:lab
e
rdfs:sub
C
:P1_2
rdf:type
rdfs:lab
e
rdfs:sub
C
:P1
_
2
_
aPourCom
p
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:P2_3
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr1_4
rdf:type
rdfs:lab
e
rdfs:sub
C
:Pr1
_
4
_
aPourCo
m
rdf:type
rdfs:dom
a
rdfs:lab
e
rdfs:ran
g
rdfs:sub
P
:Pr2_5
rdf:type
rdfs:lab
e
rdfs:sub
C
R
è
g
les de dés
a
L
e lien de c
o
m
anière ma
n
regles
_
desambi
g
regles
_
desambi
g
[Rule-10-a
_
ho
l
[Rule-10-b
_
ho
l
[Rule-10-c
_
ho
l
[Rule-16-a
_
De
s
Rè
g
les de co
n
e
présentation
o
rmelle
owl:Class ;
e
l "C1"^^xsd:str
i
C
lassOf owl:Thin
g
p
osant
_
C2
_
1
owl:ObjectPrope
r
a
in :C1
_
0 ;
e
l ""^^xsd:strin
g
g
e :C2
_
1 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "C2"^^xsd:str
i
C
lassOf owl:Thin
g
owl:Class ;
e
l "P1"^^xsd:str
i
C
lassOf metaDom:
M
p
osant
_
P2
_
3
owl:ObjectPrope
r
a
in :P1
_
2 ;
e
l ""^^xsd:strin
g
g
e :P2
_
3 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "P2"^^xsd:str
i
C
lassOf metaDom:
M
owl:Class ;
e
l "Pr1"^^xsd:st
r
C
lassOf owl:Thin
g
m
posant
_
Pr2
_
5
owl:ObjectPrope
r
a
in :Pr1
_
4 ;
e
l ""^^xsd:strin
g
g
e :Pr2
_
5 ;
P
ropertyOf metaD
o
owl:Class ;
e
l "Pr2"^^xsd:st
r
C
lassOf owl:Thin
g
a
mbi
g
uïsatio
n
o
mposition
e
n
uelle.
g_
topologique.ow
l
g_
typologique.ow
l
l
onyme
_
entre
_
deu
x
l
onyme
_
entre
_
deu
x
l
onyme
_
entre
_
un
_a
s
amb
_
LienC
_
Entre
_
n
version
en lan
g
a
g
e
M
i
ng ;
g
, metaDom:MD
_
D
r
ty ;
g
;
o
m:A-POUR-CO
M
POS
A
i
ng ;
g
, metaDom:MD
_
D
i
ng ;
M
D
_
Procedurale
_
P
r
ty ;
g
;
o
m:A-POUR-
C
OMPOS
A
i
ng ;
M
D
_
Procedurale
_
P
r
ing ;
g
, m
e
taDom:MD
_
S
t
r
ty ;
g
;
o
m:A-POUR-
C
OMPOS
A
r
ing ;
g
, metaDom:MD
_
S
n
e
ntre les co
n
l
l
x_
concepts]
x_
procedures]
a
gents
_
condition
_
Principe-et-
i
nc
o
M
OT
e
clarative
_
Conce
A
NT .
e
clarative
_
Conce
r
ocedure , owl:T
A
NT .
r
ocedure , owl:T
t
rategique
_
Agent
A
NT .
t
rategique
_
Condi
n
naissances
]
o
nnu]
e
pt .
e
pt .
T
hing .
T
hing .
t
ContrainteNorme
i
tion .
déclaratives
.
s
doit être d
é
2
é
sambiguïsé
2
66
de
267
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-d_Creation_class_agent]
[Rule-01-e_Creation_class_condition]
[Rule-10-a_Creation_Propriete_aPourComposant]
[Rule-10-b_Creation_Propriete_aPourComposant_Procedurale]
[Rule-10-d_Creation_Propriete_aPourComposant_Strategique_Condition]
etat_classification.owl
[Rule-10-a_Ajoute_Image_Domaine_a_la_Propriete_aPourComposant]
[Rule-10-b_Ajoute_Image_Domaine_a_la_Propriete_aPourComposant_ConnProcedurale]
[Rule-10-d_Ajoute_ImgDom_aPourComposant_Agent_Condition]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/COMPOSITION_ABSTRACTION.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/COMPOSITION_ABSTRACTION_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_0
Concept : C2_1
Principe : Pr1_4
Principe : Pr2_5
Procédure : P1_2
Procédure : P2_3
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienC: source C1_0 : dest C2_1
LienC: source P1_2 : dest P2_3
LienC: source Pr1_4 : dest Pr2_5
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 2, Reconstruit = 2, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 2, Reconstruit = 2, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 3, Reconstruit = 3, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
C1 est une sorte de (metaDom:MD_Declarative_Concept)
C1 se compose de C2
C2 est une sorte de (metaDom:MD_Declarative_Concept)
P1 est une sorte de (metaDom:MD_Procedurale_Procedure)
P1 se compose de P2
P2 est une sorte de (metaDom:MD_Procedurale_Procedure)
Pr1 est une sorte de (metaDom:MD_Strategique_AgentContrainteNorme)
Pr1 se compose de Pr2
Pr2 est une sorte de (metaDom:MD_Strategique_Condition)
------------------Résultats après inférence-----------------------
B.7.2 Composition entre deux connaissances observables
Méta-modèle de la règle d'utilisation
E
S
R
R
E
xemple de r
e
S
émantique f
o
:En1_4
rdf:type
rdfs:lab
e
metaDom:
A
:En2_5
rdf:type
rdfs:lab
e
:Ex1_0
rdf:type
rdfs:lab
e
metaDom:
A
:Ex2_1
rdf:type
rdfs:lab
e
:Tr1_2
rdf:type
rdfs:lab
e
metaDom:
A
:Tr2_3
rdf:type
rdfs:lab
e
R
è
g
les de dés
a
regles
_
desambi
g
regles
_
desambi
g
[Rule-11-a
_
ho
l
[Rule-11-b
_
ho
l
[Rule-11-c
_
ho
l
[Rule-17-b
_
Li
e
Rè
g
les de co
n
etat_init.owl
[Rule-00
_
Cree
r
[Rule-00
_
Impo
r
etat
_
creation.
o
[Rule-01-2a
_
C
r
[Rule-01-2b
_
C
r
[Rule-01-2d
_
C
r
[Rule-01-2i
_
C
r
etat
_
classific
a
[Rule-11
_
Crea
t
etat_final.owl
[Rule-00
_
Sauv
e
R
apport de v
a
Comparaison de
s
Orig = C:/De
v
Recons = C:/De
v
Comparaison de
s
--------------
-
e
présentation
o
rmelle
metaDom:MD
_
Stra
t
e
l "En1"^^xsd:st
r
A
-POUR-COMPOSANT
metaDom:MD
_
Stra
t
e
l "En2"^^xsd:st
r
metaDom:MD
_
Decl
a
e
l "Ex1"^^xsd:st
r
A
-POUR-COMPOSANT
metaDom:MD
_
Decl
a
e
l "Ex2"^^xsd:st
r
metaDom:MD
_
Proc
e
e
l "Tr1"^^xsd:st
r
A
-POUR-COMPOSANT
metaDom:MD
_
Proc
e
e
l "Tr2"^^xsd:st
r
a
mbi
g
uïsatio
n
g_
topologique.ow
l
g_
typologique.ow
l
l
onyme
_
entre
_
deu
x
l
onyme
_
entre
_
deu
x
l
onyme
_
entre
_
deu
x
e
nC
_
entre
_
deux
_
e
n
n
version
r_
ontologie
_
du
_
d
o
r
ter
_
metaOnto
_
du
_
o
wl
r
eation
_
Individu
_
r
eation
_
Individu
_
r
eation
_
Individu
_
r
eation
_
Individu
_
a
tion.owl
t
ion
_
propriete
_
a
P
e
garde]
a
lidation s
y
nt
a
s
documents :
v
eloppement/DATA
/
v
eloppement/DATA
/
s
documents :
-
---------------
-
en lan
g
a
g
e
M
t
egique
_
AgentCon
r
ing ;
:En2
_
5 .
t
egique
_
Conditio
r
ing .
a
rative
_
Concept
r
ing ;
:Ex2
_
1 .
a
rative
_
Concept
r
ing .
e
durale
_
Procedur
r
ing ;
:Tr2
_
3 .
e
durale
_
Procedur
r
ing .
n
l
l
x_
eno
n
ces
_
Agents
_
x_
traces]
x_
exemples]
n
onces]
o
maine]
_
domaine]
_
objet]
_
procedural]
_
Principe
_
Agent]
_
Principe
_
Condit
P
ourComposant
_
in
a
xique
/
workspace/Carré
/
workspace/Carré
-
---------------
M
OT
t
rainteNorme ;
n
;
;
;
e
;
e
;
_
Condition]
i
on]
d
ividu]
D
eSable/HOLONYME
D
eSable/HOLONYME
-
---------------
E_
ENTRE
_
OBSERVAB
L
E_
ENTRE
_
OBSERVAB
L
-
--
L
E.mot
L
E
_
rest.mot
2
2
68
R
B
M
--------------
-
--------------
-
--------------
-
Enonce
Enonce
Exemple
Exemple
Trace
Trace
--------------
-
--------------
-
--------------
-
--------------
-
LienC: s
o
LienC: s
o
LienC: s
o
--------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
[En1] est de c
a
[En1] est un (
[En1] se compo
s
[En2] est de c
a
[En2] est un (
[Ex1] est de c
a
[Ex1] est un (
[Ex1] se compo
s
[Ex2] est de c
a
[Ex2] est un (
[Tr1] est de c
a
[Tr1] est un (
[Tr1] se compo
s
[Tr2] est de c
a
[Tr2] est un (
--------------
-
[En1] est un (
[En2] est un (
[En2] est une
p
[Ex1] est un (
[Ex2] est un (
[Ex2] est une
p
[Tr1] est un (
[Tr2] est un (
[Tr2] est une
p
B
.7.3 Comp
M
éta-modèle
-
------ Les conn
a
-
---------------
-
-
---- Commun aux
: En1
_
4
: En2
_
5
: Ex1
_
0
: Ex2
_
1
: Tr1
_
2
: Tr2
_
3
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
o
urce En1
_
4 : de
s
o
urce Ex1
_
0 : de
s
o
urce Tr1
_
2 : de
s
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
a
tégorie (metaDo
m
:Agent-Contrain
t
s
e de [En2]
a
tégorie (metaDo
m
:Condition )
a
tégorie (metaDo
m
:Connaissance d
'
s
e de [Ex2]
a
tégorie (metaDo
m
:Connaissance d
'
a
tégorie (metaDo
m
:Procédure )
s
e de [Tr2]
a
tégorie (metaDo
m
:Procédure )
-
---Résultats ap
r
:Agent-Contrain
t
:Condition :Typ
e
p
artie de [En1]
:Connaissance d
'
:Connaissance d
'
p
artie de [Ex1]
:Procédure :Typ
e
:Procédure :Typ
e
p
artie de [Tr1]
osition entr
e
de la rè
g
le d'
u
a
issances
-
----
-
-
---------------
deux modèles
-
-
-
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
s
t En2
_
5
s
t Ex2
_
1
s
t Tr2
_
3
-
---------------
-
---------------
-
---------------
p
osants des modè
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 2, Reconstru
l
= 2, Reconstru
l
= 2, Reco
n
stru
i
l
= 0, Reconstru
l
= 3, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
a
ntique
e
validation
s
ém
a
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Strategique
m
:MD
_
Declarative
'
objet )
m
:MD
_
Declarative
'
objet )
m
:MD
_
Procedurale
m
:MD
_
Procedurale
r
ès inférence
-
--
-
t
e-Norme :Type d
e
de
c
onnaissanc
e
'
objet :Type de
'
objet :Type de
e
de connaissanc
e
de connaissanc
e
des connai
s
u
tilisation
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
--------------
-
-
---------------
-
---------------
-
---------------
l
es
-
-----------
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 2, Différe
n
i
t = 2, Différe
n
i
t = 2, Différe
n
i
t = 0, Différe
n
i
t = 3, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
a
ntique
-
--------
_
AgentContrainte
_
Condition)
_
Concept)
_
Concept)
_
Procedure)
_
Procedure)
-
---------------
e
connaissances
e
s :Connaissance
c
onnaissances :C
c
onnaissances :C
e
s :Connaissance
e
s :Connaissance
s
sances de
n
-
--
-
--
-
---
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
e
Norme)
-
----
:Connaissance s
t
e
stratégique )
C
onnaissance déc
l
C
onnaissance déc
l
e
d'actions )
e
d'actions )
n
iveau d’abs
t
t
ratégique )
l
arative )
l
arative )
t
raction dif
fé
2
fé
rent
2
69
270
Exemple de représentation en langage MOT
Sémantique formelle
:C1_0
rdf:type owl:Class ;
rdfs:label "C1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept ;
metaDom:A-POUR-COMPOSANT :Ex1_3 .
:En1_5
rdf:type metaDom:MD_Strategique_AgentContrainteNorme ;
rdfs:label "En1"^^xsd:string .
:Ex1_3
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Ex1"^^xsd:string .
:P1_1
rdf:type owl:Class ;
rdfs:label "P1"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing ;
metaDom:A-POUR-COMPOSANT :Tr1_4 .
:Pr1_2
rdf:type owl:Class ;
rdfs:label "Pr1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme ;
metaDom:A-POUR-COMPOSANT :En1_5 .
:Tr1_4
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr1"^^xsd:string .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
[Rule-16-a_Desamb_LienC_Entre_Principe-et-inconnu]
[Rule-XX-05-2-3_holonyme_concept_exemple]
[Rule-XX-06-2-3_holonyme_procedure_trace]
[Rule-XX-07-2-3_holonyme_principe_enonce]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2a_Creation_Individu_objet]
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2d_Creation_Individu_Principe_Agent]
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-d_Creation_class_agent]
etat_classification.owl
[Rule-12-a_Creation_propriete_aPourComposant_entre_Concept_Exemple]
[Rule-12-b_Creation_propriete_aPourComposant_entre_Procedure_Trace]
[Rule-12-c_Creation_propriete_aPourComposant_entre_principe_enonce]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/HOLONYME_ABS_OBS.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/HOLONYME_ABS_OBS_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C1_0
Enonce : En1_5
Exemple : Ex1_3
R
B
E
Principe
Procédur
e
Trace
--------------
-
--------------
-
--------------
-
--------------
-
LienC: s
o
LienC: s
o
LienC: s
o
--------------
-
--------------
-
--------------
-
---------Totau
x
Compte des Con
c
Compte des Pro
c
Compte des Pri
n
Compte des Eno
n
Compte des Tra
c
Compte des Exe
m
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
Compte des Lie
n
R
apport de v
a
----------Débu
t
C1 est une sor
t
P1 est une sor
t
Pr1 est une so
r
[En1] est de c
a
[En1] est un (
[Ex1] est de c
a
[Ex1] est un (
[Tr1] est de c
a
[Tr1] est un (
--------------
-
[En1] est un (
[En1] est une
p
[Ex1] est un (
[Ex1] est une
p
[Tr1] est un (
[Tr1] est une
p
B
.8 Attribut
E
xemple de r
e
: Pr1
_
2
e
: P1
_
1
: Tr1
_
4
-
---------------
-
-
-------- Les re
l
-
---------------
-
-
---- Commun aux
o
urce C1
_
0 : des
t
o
urce P1
_
1 : des
t
o
urce Pr1
_
2 : de
s
-
---------------
-
-
-------- BILAN
-
-
---------------
-
x
des divers com
p
c
epts : Origina
l
c
edures: Origina
l
n
cipes : Origina
l
n
ces : Origina
l
c
es : Origina
l
m
ples : Origina
l
n
A : Origina
l
n
C : Origina
l
n
Cm : Origina
l
n
I : Origina
l
n
IP : Origina
l
n
P : Origina
l
n
R : Origina
l
n
S : Origina
l
a
lidation sém
a
t
du processus d
e
t
e de (metaDom:M
D
t
e de (metaDom:M
D
r
te de (metaDom:
M
a
tégorie (metaDo
m
:Agent-Contrain
t
a
tégorie (metaDo
m
:Connaissance d
'
a
tégorie (metaDo
m
:Procédure )
-
---Résultats ap
r
:Agent-Contrain
t
p
artie de [Pr1]
:Connaissance d
'
p
artie de [C1]
:Procédure :Typ
e
p
artie de [P1]
de connais
s
e
présentation
-
---------------
l
ations
-
-------
-
-
---------------
deux modèles
-
-
-
t
Ex1
_
3
t
Tr1
_
4
s
t En1
_
5
-
---------------
-
---------------
-
---------------
p
osants des modè
l
= 1, Reconstru
l
= 1, Reconstru
l
= 1, Reconstru
l
= 1, Reconstr
ui
l
= 1, Reconstru
l
= 1, Reconstru
l
= 0, Reconstru
l
= 3, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
l
= 0, Reconstru
a
ntique
e
validation sém
D_
Declarative
_
Co
D_
Procedurale
_
Pr
M
D
_
Strategique
_
A
m
:MD
_
Strategique
t
e-Norme )
m
:MD
_
Declarative
'
objet )
m
:MD
_
Procedurale
r
ès inférence
-
--
-
t
e-Norme :Type d
'
objet :Type de
e
de connaissanc
s
ances décla
r
en lan
g
a
g
e
M
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
-
---------------
l
es -----------
-
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 1, Différe
n
i
t = 0, Différe
n
i
t = 3, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
i
t = 0, Différe
n
a
ntique
-
--------
n
cept)
o
cedure)
g
entContrainteNo
_
AgentContrainte
_
Concept)
_
Procedure)
-
---------------
e
connaissances
c
onnaissanc
e
s :C
e
s :Connaissance
r
atives
M
OT
-
--
-
--
-
--
-
---
-
--
-
--
-
--
-
--
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
n
ce = 0
-
----
o
rme)
e
Norme)
-
----
:Connaissance s
t
C
onnaissance déc
l
e
d'actions )
t
ratégique )
l
arative )
2
2
71
272
Sémantique formelle
:A_6 rdf:type owl:Class ;
rdfs:label "A"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:A_6_aPourAttribut_unString_0
rdf:type owl:ObjectProperty ;
rdfs:domain :A_6 ;
rdfs:label "unString"^^xsd:string ;
rdfs:range :unString_0 ;
rdfs:subPropertyOf metaDom:A-POUR-ATTRIBUT .
:B_7 rdf:type owl:Class ;
rdfs:label "B"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:B_7_aPourAttribut_unInt_1
rdf:type owl:ObjectProperty ;
rdfs:domain :B_7 ;
rdfs:label "unInt"^^xsd:string ;
rdfs:range :unInt_1 ;
rdfs:subPropertyOf metaDom:A-POUR-ATTRIBUT .
:C_8 rdf:type owl:Class ;
rdfs:label "C"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:C_8_aPourAttribut_unFloat_2
rdf:type owl:ObjectProperty ;
rdfs:domain :C_8 ;
rdfs:label "unFloat"^^xsd:string ;
rdfs:range :unFloat_2 ;
rdfs:subPropertyOf metaDom:A-POUR-ATTRIBUT .
:D_9 rdf:type owl:Class ;
rdfs:label "D"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:D_9_aPourAttribut_E_10
rdf:type owl:ObjectProperty ;
rdfs:domain :D_9 ;
rdfs:label "E"^^xsd:string ;
rdfs:range :E_10 ;
rdfs:subPropertyOf metaDom:A-POUR-ATTRIBUT .
:E_10
rdf:type owl:Class ;
rdfs:label "E"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:_10_4
rdf:type :unInt_1 ;
rdfs:label "10"^^xsd:string .
:_3-146_5
rdf:type :unFloat_2 ;
rdfs:label "3.146"^^xsd:string .
:allo_3
rdf:type :unString_0 ;
rdfs:label "allo"^^xsd:string .
:unFloat_2
rdf:type owl:Class ;
rdfs:label "unFloat"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_Float ;
metaDom:MD_isString "3.146"^^xsd:float .
:unInt_1
rdf:type owl:Class ;
rdfs:label "unInt"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_Int ;
metaDom:MD_isString "10"^^xsd:int .
:unString_0
rdf:type owl:Class ;
rdfs:label "unString"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Schema_String ;
metaDom:MD_isString "allo"^^xsd:string .
Règles de désambiguïsation
Tous les éléments doivent êtres désambiguïsés de manière manuelle
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-a_Creation_class_objet_Concept]
[Rule-13-a_Creation_Propriete_aPourAttribut_Schema]
[Rule-13-b_Creation_class_Schema_Int]
[Rule-13-c_Creation_class_Schema_Float]
[Rule-13-d_Creation_class_Schema_String]
[Rule-13-e-Creation_Dun_Individu_dattribut]
273
[Rule-13-f_Creation_Propriete_aPourAttribut]
etat_classification.owl
[Rule-01-d_Creation_subClassOf_SchemaString]
[Rule-01-e_Creation_subClassOf_SchemaInt]
[Rule-01-f_Creation_subClassOf_SchemaFloat]
[Rule-13-a_Ajoute_Image_Domaine_a_la_Propriete_aPourAttribut]
[Rule-13-e_Ajoute_Image_Domaine_a_la_Propriete_aPourAttribut_Int]
[Rule-13-f_Ajoute_Image_Domaine_a_la_Propriete_aPourAttribut_Float]
[Rule-13-g_Ajoute_Image_Domaine_a_la_Propriete_aPourAttribut_String]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/13_CompositionAPourAttribut.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/13_CompositionAPourAttribut_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : A_6
Concept : B_7
Concept : C_8
Concept : D_9
Concept : E_10
Concept : unFloat_2
Concept : unInt_1
Concept : unString_0
Exemple : _10_4
Exemple : _3-146_5
Exemple : allo_3
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienC: source A_6 : dest unString_0
LienC: source B_7 : dest unInt_1
LienC: source C_8 : dest unFloat_2
LienC: source D_9 : dest E_10
LienI: source unFloat_2 : dest _3-146_5
LienI: source unInt_1 : dest _10_4
LienI: source unString_0 : dest allo_3
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 8, Reconstruit = 8, Différence = 0
Compte des Procedures: Original = 0, Reconstruit = 0, Différence = 0
Compte des Principes : Original = 0, Reconstruit = 0, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 3, Reconstruit = 3, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 4, Reconstruit = 4, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 3, Reconstruit = 3, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
A a pour attribut unString
A est une sorte de (metaDom:MD_Declarative_Concept)
B a pour attribut unInt
B est une sorte de (metaDom:MD_Declarative_Concept)
C a pour attribut unFloat
C est une sorte de (metaDom:MD_Declarative_Concept)
D a pour attribut E
D est une sorte de (metaDom:MD_Declarative_Concept)
E est une sorte de (metaDom:MD_Declarative_Concept)
[10] est de catégorie (metaDom:MD_Declarative_Schema_Int)
[10] est un ( :unInt )
[3.146] est de catégorie (metaDom:MD_Declarative_Schema_Float)
[3.146] est un ( :unFloat )
[allo] est de catégorie (metaDom:MD_Declarative_Schema_String)
[allo] est un ( :unString )
unFloat est une sorte de (metaDom:MD_Declarative_Schema_Float)
unInt est une sorte de (metaDom:MD_Declarative_Schema_Int)
unString est une sorte de (metaDom:MD_Declarative_Schema_String)
------------------Résultats après inférence-----------------------
!!! Erreur :Cannot do reasoning with inconsistent ontologies!
274
B.9 Lien de précédence
B.9.1 Relation de précédence entre connaissances d’actions
Exemple de représentation en langage MOT
Sémantique formelle
:P1_0
rdf:type owl:Class ;
rdfs:label "P1"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:P1_0_puisExecuter_P2_1
rdf:type owl:ObjectProperty ;
rdfs:domain :P1_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :P2_1 ;
rdfs:subPropertyOf metaDom:PUIS-EXECUTER .
:P2_1
rdf:type owl:Class ;
rdfs:label "P2"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Tr1_2
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr1"^^xsd:string ;
metaDom:PUIS-EXECUTER
:Tr2_3 .
:Tr2_3
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr2"^^xsd:string .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
[Rule-00_ConnaissancesNonAmbigue_LienP]
[Rule-14-a_Procedure-P-Procedure_Procedure-Procedure]
[Rule-14-b_Trace-P-Trace_Procedure-Procedure]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-14_Creation_Propriete_puisExecuter_Procedure_Procedure]
etat_classification.owl
[Rule-14-a_Ajout_ImgDom_Prop_puisExecuter_Procedure_Procedure]
[Rule-14-b_Creation_Individu_Procedural_puisExecuter_Procedural]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ENTRE_ACTION.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ENTRE_ACTION_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Procédure : P1_0
275
Procédure : P2_1
Trace : Tr1_2
Trace : Tr2_3
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienP: source P1_0 : dest P2_1
LienP: source Tr1_2 : dest Tr2_3
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 0, Reconstruit = 0, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 0, Reconstruit = 0, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Traces : Original = 2, Reconstruit = 2, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
P1 est une sorte de (metaDom:MD_Procedurale_Procedure)
P1 puis exécuter P2
P2 est une sorte de (metaDom:MD_Procedurale_Procedure)
[Tr1] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr1] est un ( :Procédure )
[Tr1] puis exécuter [Tr2]
[Tr2] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr2] est un ( :Procédure )
------------------Résultats après inférence-----------------------
[Tr1] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
[Tr1] permet [Tr2]
[Tr2] a pour dépendance [Tr1]
[Tr2] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
B.9.2 Précédence entre connaissances d’actions et stratégique
Exemple de représentation en langage MOT
Sémantique formelle
:En1_6
rdf:type metaDom:MD_Strategique_Condition ;
rdfs:label "En1"^^xsd:string .
:En2_7
rdf:type metaDom:MD_Strategique_Condition ;
rdfs:label "En2"^^xsd:string ;
metaDom:PUIS-EXECUTER :Tr2_5 .
:En3a_10
rdf:type metaDom:MD_Strategique_Condition ;
rdfs:label "En3a"^^xsd:string ;
metaDom:PUIS-EVALUER :En3b_11 .
:En3b_11
rdf:type metaDom:MD_Strategique_Condition ;
276
rdfs:label "En3b"^^xsd:string .
:P1_0
rdf:type owl:Class ;
rdfs:label "P1"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:P1_0_puisEvaluer_Pr1_1
rdf:type owl:ObjectProperty ;
rdfs:domain :P1_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Pr1_1 ;
rdfs:subPropertyOf metaDom:PUIS-EVALUER .
:P2_3
rdf:type owl:Class ;
rdfs:label "P2"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Pr1_1
rdf:type owl:Class ;
rdfs:label "Pr1"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Condition .
:Pr2_2
rdf:type owl:Class ;
rdfs:label "Pr2"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Condition .
:Pr2_2_puisExecuter_P2_3
rdf:type owl:ObjectProperty ;
rdfs:domain :Pr2_2 ;
rdfs:label ""^^xsd:string ;
rdfs:range :P2_3 ;
rdfs:subPropertyOf metaDom:PUIS-EXECUTER .
:Pr3a_8
rdf:type owl:Class ;
rdfs:label "Pr3a"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Condition .
:Pr3a_8_puisEvaluer_Pr3b_9
rdf:type owl:ObjectProperty ;
rdfs:domain :Pr3a_8 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Pr3b_9 ;
rdfs:subPropertyOf metaDom:PUIS-EVALUER .
:Pr3b_9
rdf:type owl:Class ;
rdfs:label "Pr3b"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Condition .
:Tr1_4
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr1"^^xsd:string ;
metaDom:PUIS-EVALUER :En1_6 .
:Tr2_5
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr2"^^xsd:string .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
[Rule-00_ConnaissancesNonAmbigue_LienP]
[Rule-15-a_Procedure-P-Principe_Procedure-Condition]
[Rule-15-b_Principe-P-Procedure_Condition-Procedure]
[Rule-15-c_Principe-P-Principe_Condition-Condition]
[Rule-15-c_Trace-P-Enonce_Procedure-Condition]
[Rule-15-d_Enonce-P-Enonce_Condition-Condition]
[Rule-15-e_Enonce-P-Trace_Condition-Procedure]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2i_Creation_Individu_Principe_Condition]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-e_Creation_class_condition]
[Rule-15-a_Creation_Propriete_puisEvaluer_Procedure_Condition]
[Rule-15-b_Creation_Propriete_puisExecuter_Condition_Procedure]
[Rule-15-c_Creation_Propriete_puisEvaluer_Condition_Condition]
etat_classification.owl
[Rule-15-a_Ajout_ImgDom_Prop_puisEvaluer_Procedure_Condition]
[Rule-15-b_Ajout_ImgDom_Prop_puisExecuter_Condition_Procedure]
[Rule-15-c_Ajout_ImgDom_Prop_puisEvaluer_Condition_Condition]
[Rule-15-d_Creation_Individu_Procedural_puisEvaluer_Condition]
[Rule-15-e_Creation_Individu_Condition_puisExecuter_Procedural]
[Rule-15-f_Creation_Individu_Condition_puisEvaluer_Condition]
etat_final.owl
[Rule-00_Sauvegarde]
277
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ACTION_STRATEGIQUE.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ACTION_STRATEGIQUE_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Enonce : En1_6
Enonce : En2_7
Enonce : En3a_10
Enonce : En3b_11
Principe : Pr1_1
Principe : Pr2_2
Principe : Pr3a_8
Principe : Pr3b_9
Procédure : P1_0
Procédure : P2_3
Trace : Tr1_4
Trace : Tr2_5
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienP: source En2_7 : dest Tr2_5
LienP: source En3a_10 : dest En3b_11
LienP: source P1_0 : dest Pr1_1
LienP: source Pr2_2 : dest P2_3
LienP: source Pr3a_8 : dest Pr3b_9
LienP: source Tr1_4 : dest En1_6
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 0, Reconstruit = 0, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 4, Reconstruit = 4, Différence = 0
Compte des Enonces : Original = 4, Reconstruit = 4, Différence = 0
Compte des Traces : Original = 2, Reconstruit = 2, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 6, Reconstruit = 6, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
P1 est une sorte de (metaDom:MD_Procedurale_Procedure)
P1 puis évaluer Pr1
P2 est une sorte de (metaDom:MD_Procedurale_Procedure)
Pr1 est une sorte de (metaDom:MD_Strategique_Condition)
Pr2 est une sorte de (metaDom:MD_Strategique_Condition)
Pr2 puis exécuter P2
Pr3a est une sorte de (metaDom:MD_Strategique_Condition)
Pr3a puis évaluer Pr3b
Pr3b est une sorte de (metaDom:MD_Strategique_Condition)
[En1] est de catégorie (metaDom:MD_Strategique_Condition)
[En1] est un ( :Condition )
[En2] est de catégorie (metaDom:MD_Strategique_Condition)
[En2] est un ( :Condition )
[En2] puis exécuter [Tr2]
[En3a] est de catégorie (metaDom:MD_Strategique_Condition)
[En3a] est un ( :Condition )
[En3a] puis évaluer [En3b]
[En3b] est de catégorie (metaDom:MD_Strategique_Condition)
[En3b] est un ( :Condition )
[Tr1] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr1] est un ( :Procédure )
[Tr1] puis évaluer [En1]
[Tr2] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr2] est un ( :Procédure )
------------------Résultats après inférence-----------------------
[En1] a pour dépendance [Tr1]
[En1] est un ( :Condition :Type de connaissances :Connaissance stratégique )
[En1] évalué à partir de [Tr1]
[En2] est un ( :Condition :Type de connaissances :Connaissance stratégique )
[En2] permet [Tr2]
[En3a] est un ( :Condition :Type de connaissances :Connaissance stratégique )
[En3a] permet [En3b]
278
[En3b] a pour dépendance [En3a]
[En3b] est un ( :Condition :Type de connaissances :Connaissance stratégique )
[En3b] évalué à partir de [En3a]
[Tr1] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
[Tr1] permet [En1]
[Tr2] a pour dépendance [En2]
[Tr2] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
B.10 Règle
B.10.1 Règle à partir de connaissances abstraites
Exemple de représentation en langage MOT
Sémantique formelle
:Antecedent-1a_1
rdf:type owl:Class ;
rdfs:label "Antécédent 1a"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Antecedent , owl:Thing .
:Antecedent-1a_1_estAntecedentDe_Antecedent-1b_2
rdf:type owl:ObjectProperty ;
rdfs:domain :Antecedent-1a_1 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-1b_2 ;
rdfs:subPropertyOf metaDom:EST-ANTECEDENT-DE .
:Antecedent-1b_2
rdf:type owl:Class ;
rdfs:label "Antécédent 1b"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Antecedent , owl:Thing .
:Antecedent-1b_2_aPourConclusion_Conclusion-1a_3
rdf:type owl:ObjectProperty ;
rdfs:domain :Antecedent-1b_2 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Conclusion-1a_3 ;
rdfs:subPropertyOf metaDom:A-POUR-CONCLUSION .
:Antecedent-2a_4
rdf:type owl:Class ;
rdfs:label "Antécédent 2a"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Antecedent , owl:Thing .
:Antecedent-2a_4_estAntecedentDe_Antecedent-2b_6
rdf:type owl:ObjectProperty ;
rdfs:domain :Antecedent-2a_4 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-2b_6 ;
rdfs:subPropertyOf metaDom:EST-ANTECEDENT-DE .
:Antecedent-2b_6
rdf:type owl:Class ;
rdfs:label "Antécédent 2b"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Antecedent , owl:Thing .
:Antecedent-2b_6_alors_Operation-2_7
rdf:type owl:ObjectProperty ;
rdfs:domain :Antecedent-2b_6 ;
279
rdfs:label ""^^xsd:string ;
rdfs:range :Operation-2_7 ;
rdfs:subPropertyOf metaDom:ALORS .
:Conclusion-1a_3
rdf:type owl:Class ;
rdfs:label "Conclusion 1a"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_Entite_Regle_Conclusion .
:Nom-1_0
rdf:type owl:Class ;
rdfs:label "Nom 1"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Nom , owl:Thing .
:Nom-1_0_aPourComposant_Antecedent-1a_1
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-1_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-1a_1 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Nom-1_0_aPourComposant_Antecedent-1b_2
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-1_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-1b_2 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Nom-1_0_aPourComposant_Conclusion-1a_3
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-1_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Conclusion-1a_3 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Nom-2_5
rdf:type owl:Class ;
rdfs:label "Nom 2"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Nom , owl:Thing .
:Nom-2_5_aPourComposant_Antecedent-2a_4
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-2_5 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-2a_4 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Nom-2_5_aPourComposant_Antecedent-2b_6
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-2_5 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Antecedent-2b_6 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Nom-2_5_aPourComposant_Operation-2_7
rdf:type owl:ObjectProperty ;
rdfs:domain :Nom-2_5 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Operation-2_7 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Operation-2_7
rdf:type owl:Class ;
rdfs:label "Opération 2"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Procedurale_Operation .
:Proc-3_8
rdf:type owl:Class ;
rdfs:label "Proc 3"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Proc-3_8_aPourComposant_Regle-3a_9
rdf:type owl:ObjectProperty ;
rdfs:domain :Proc-3_8 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Regle-3a_9 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Proc-3_8_aPourComposant_Regle-3b_10
rdf:type owl:ObjectProperty ;
rdfs:domain :Proc-3_8 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Regle-3b_10 ;
rdfs:subPropertyOf metaDom:A-POUR-COMPOSANT .
:Regle-3a_9
rdf:type owl:Class ;
rdfs:label "Règle 3a"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Complete , owl:Thing .
:Regle-3a_9_estPrecedentDe_Regle-3b_10
rdf:type owl:ObjectProperty ;
rdfs:domain :Regle-3a_9 ;
rdfs:label ""^^xsd:string ;
rdfs:range :Regle-3b_10 ;
rdfs:subPropertyOf metaDom:EST-PRECEDENT-DE .
:Regle-3b_10
rdf:type owl:Class ;
rdfs:label "Règle 3b"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Strategique_Entite_Regle_Complete , owl:Thing .
Règles de désambiguïsation
280
regles_desambig_topologique.owl
[Rule-16-a_RegleNom-Antecedent_Principe-Principe-Principe]
[Rule-16-b_RegleNom-Antecedent_Principe-Principe-Procedure]
[Rule-19-c_Procedure-LienC-Principe-Procedure_RegleComplete]
regles_desambig_typologique.owl
[Rule-00_ConnaissancesNonAmbigue_LienP]
[Rule-16-a_Desamb_LienC_Entre_Principe-et-inconnu]
[Rule-16-b_Principe-P-Principe_Antecedent-Conclusion]
[Rule-16-c_Principe-P-Procedure_Antecedent-Operation]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-c_Creation_class_Action_Operation]
[Rule-01-f_Creation_class_regle_nom]
[Rule-01-g_Creation_class_regle_complete]
[Rule-01-h_Creation_class_regle_antecedent]
[Rule-01-i_Creation_class_regle_conclusion]
[Rule-16-b_Creation_Propriete_aPourComposant_Regles_Nom-Antécédent]
[Rule-16-c_Creation_Propriete_aPourComposant_Regles_Nom-Consequent]
[Rule-16-d_Creation_Propriete_aPourComposant_Regles_Nom-Operation]
[Rule-16-e_Creation_Propriete_aPourComposant_Procedurale_Strategique]
[Rule-16-f_Creation_Propriete_EstPrecedentDe_Entre_RegleComplete]
[Rule-16-g_Creation_Propriete_estAntecedentDe_Antecedent_Antecedent]
[Rule-16-h_Creation_Propriete_ALORS_Antecedent_Operation]
[Rule-16_i_Creation_Propriete_aPourConclusion_Antecedent_Conclusion]
etat_classification.owl
[Rule-16-a_Ajoute_Image_Domaine_aPourComposant_entre_RegleNom_Consequence]
[Rule-16-b_Ajoute_Image_Domaine_aPourComposant_entre_RegleNom_Antecedent]
[Rule-16-c_Ajoute_Image_Domaine_aPourComposant_entre_RegleNom_Operation]
[Rule-16-d_Ajoute_Image_Domaine_a_la_Propriete_aPourComosant_ConnProceduraleEtConnStrag]
[Rule-16-e_Ajout_ImgDom_Prop_estAntecedentDe_Entre_Principes]
[Rule-16-f_Ajout_ImgDom_Prop_alors_Condition_Procedure]
[Rule-16-g_Ajout_ImgDom_Prop_estPrecedentDe_RegleNom_RegleNom]
[Rule-16-h_Ajout_ImgDom_Prop_aPourConclusion]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ET_COMPOSITION_REGLE.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE_ET_COMPOSITION_REGLE_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Principe : Antecedent-1a_1
Principe : Antecedent-1b_2
Principe : Antecedent-2a_4
Principe : Antecedent-2b_6
Principe : Conclusion-1a_3
Principe : Nom-1_0
Principe : Nom-2_5
Principe : Regle-3a_9
Principe : Regle-3b_10
Procédure : Operation-2_7
Procédure : Proc-3_8
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienC: source Nom-1_0 : dest Antecedent-1a_1
LienC: source Nom-1_0 : dest Antecedent-1b_2
LienC: source Nom-1_0 : dest Conclusion-1a_3
LienC: source Nom-2_5 : dest Antecedent-2a_4
LienC: source Nom-2_5 : dest Antecedent-2b_6
LienC: source Nom-2_5 : dest Operation-2_7
LienC: source Proc-3_8 : dest Regle-3a_9
LienC: source Proc-3_8 : dest Regle-3b_10
LienP: source Antecedent-1a_1 : dest Antecedent-1b_2
LienP: source Antecedent-1b_2 : dest Conclusion-1a_3
LienP: source Antecedent-2a_4 : dest Antecedent-2b_6
LienP: source Antecedent-2b_6 : dest Operation-2_7
LienP: source Regle-3a_9 : dest Regle-3b_10
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 0, Reconstruit = 0, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 9, Reconstruit = 9, Différence = 0
Compte des Enonces : Original = 0, Reconstruit = 0, Différence = 0
281
Compte des Traces : Original = 0, Reconstruit = 0, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 8, Reconstruit = 8, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 5, Reconstruit = 5, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
Antécédent 1a est antécédent de Antécédent 1b
Antécédent 1a est une sorte de (metaDom:MD_Strategique_Entite_Regle_Antecedent)
Antécédent 1b a pour conclusion Conclusion 1a
Antécédent 1b est une sorte de (metaDom:MD_Strategique_Entite_Regle_Antecedent)
Antécédent 2a est antécédent de Antécédent 2b
Antécédent 2a est une sorte de (metaDom:MD_Strategique_Entite_Regle_Antecedent)
Antécédent 2b alors Opération 2
Antécédent 2b est une sorte de (metaDom:MD_Strategique_Entite_Regle_Antecedent)
Conclusion 1a est une sorte de (metaDom:MD_Strategique_Entite_Regle_Conclusion)
Nom 1 est une sorte de (metaDom:MD_Strategique_Entite_Regle_Nom)
Nom 1 se compose de Antécédent 1a
Nom 1 se compose de Antécédent 1b
Nom 1 se compose de Conclusion 1a
Nom 2 est une sorte de (metaDom:MD_Strategique_Entite_Regle_Nom)
Nom 2 se compose de Antécédent 2a
Nom 2 se compose de Antécédent 2b
Nom 2 se compose de Opération 2
Opération 2 est une sorte de (metaDom:MD_Procedurale_Operation)
Proc 3 est une sorte de (metaDom:MD_Procedurale_Procedure)
Proc 3 se compose de Règle 3a
Proc 3 se compose de Règle 3b
Règle 3a est précédent de Règle 3b
Règle 3a est une sorte de (metaDom:MD_Strategique_Entite_Regle_Complete)
Règle 3b est une sorte de (metaDom:MD_Strategique_Entite_Regle_Complete)
------------------Résultats après inférence-----------------------
B.10.2 Règle à partir de connaissances factuelles
Exemple de représentation en langage MOT
Sémantique formelle
:Ant1a_1
rdf:type metaDom:MD_Strategique_Entite_Regle_Antecedent ;
rdfs:label "Ant1a"^^xsd:string ;
metaDom:EST-ANTECEDENT-DE :Ant1b_2 .
:Ant1b_2
rdf:type metaDom:MD_Strategique_Entite_Regle_Antecedent ;
rdfs:label "Ant1b"^^xsd:string ;
metaDom:A-POUR-CONCLUSION :Concl1_3 .
:Ant2a_5
282
rdf:type metaDom:MD_Strategique_Entite_Regle_Antecedent ;
rdfs:label "Ant2a"^^xsd:string ;
metaDom:EST-ANTECEDENT-DE :Ant2b_6 .
:Ant2b_6
rdf:type metaDom:MD_Strategique_Entite_Regle_Antecedent ;
rdfs:label "Ant2b"^^xsd:string ;
metaDom:ALORS :Oper2_8 .
:Concl1_3
rdf:type metaDom:MD_Strategique_Entite_Regle_Conclusion ;
rdfs:label "Concl1"^^xsd:string .
:Nom1_0
rdf:type metaDom:MD_Strategique_Entite_Regle_Nom ;
rdfs:label "Nom1"^^xsd:string ;
metaDom:A-POUR-COMPOSANT :Ant1a_1 , :Concl1_3 , :Ant1b_2 .
:Nom2_4
rdf:type metaDom:MD_Strategique_Entite_Regle_Nom ;
rdfs:label "Nom2"^^xsd:string ;
metaDom:A-POUR-COMPOSANT :Ant2b_6 , :Ant2a_5 , :Oper2_8 .
:Oper2_8
rdf:type metaDom:MD_Procedurale_Operation ;
rdfs:label "Oper2"^^xsd:string .
:Rg1_10
rdf:type metaDom:MD_Strategique_Entite_Regle_Complete ;
rdfs:label "Rg1"^^xsd:string ;
metaDom:EST-PRECEDENT-DE :Rg2_7 .
:Rg2_7
rdf:type metaDom:MD_Strategique_Entite_Regle_Complete ;
rdfs:label "Rg2"^^xsd:string .
:Tr1_9
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr1"^^xsd:string ;
metaDom:A-POUR-COMPOSANT :Rg2_7 , :Rg1_10 .
Règles de désambiguïsation
regles_desambig_topologique.owl
[Rule-17-a_RegleNom-Antecedent_Enonce-Enonce-Enonce]
[Rule-17-b_RegleNom-Antecedent_Enonce-Enonce-Trace]
[Rule-17-d_Enonce-LienC-Trace-RegleComplete_Procedure]
[Rule-17-e_RegleNom-Antecedent_Enonce-Enonce-trace]
regles_desambig_typologique.owl
[Rule-00_ConnaissancesNonAmbigue_LienP]
[Rule-17-b_LienC_entre_deux_enonces]
[Rule-17-c_Enonce-P-Trace_Antecedent-Operation]
[Rule-17-d_LienC_entre_EnonceEtTrace]
[Rule-17-e_Enonce-P-Enonce_Antecedent-Conclusion]
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2c_Creation_Individu_operation]
[Rule-01-2e_Creation_Individu_Principe_Regle_Nom]
[Rule-01-2f_Creation_Individu_Principe_Regle_Complete]
[Rule-01-2g_Creation_Individu_Principe_Antecedent]
[Rule-01-2h_Creation_Individu_Principe_Conclusion]
etat_classification.owl
[Rule-11_Creation_propriete_aPourComposant_individu]
[Rule-17-a_Creation_Individu_Antecedent_aPourConclusion_Conclusion]
[Rule-17-b_Creation_Individu_Antecedent_estAntecedentDe_Antecedent]
[Rule-17-c_Creation_Individu_EstPrecedentDe_Entre_RegleComplete]
[Rule-17-d_Creation_Individu_Antecedent_Alors_Action]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE-ET_COMPOSITION_REGLE_OBSERVABLES.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/PRECEDENCE-ET_COMPOSITION_REGLE_OBSERVABLES_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Enonce : Ant1a_1
Enonce : Ant1b_2
Enonce : Ant2a_5
Enonce : Ant2b_6
Enonce : Concl1_3
Enonce : Nom1_0
Enonce : Nom2_4
Enonce : Rg1_10
Enonce : Rg2_7
Trace : Oper2_8
283
Trace : Tr1_9
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
LienC: source Nom1_0 : dest Ant1a_1
LienC: source Nom1_0 : dest Ant1b_2
LienC: source Nom1_0 : dest Concl1_3
LienC: source Nom2_4 : dest Ant2a_5
LienC: source Nom2_4 : dest Ant2b_6
LienC: source Nom2_4 : dest Oper2_8
LienC: source Tr1_9 : dest Rg1_10
LienC: source Tr1_9 : dest Rg2_7
LienP: source Ant1a_1 : dest Ant1b_2
LienP: source Ant1b_2 : dest Concl1_3
LienP: source Ant2a_5 : dest Ant2b_6
LienP: source Ant2b_6 : dest Oper2_8
LienP: source Rg1_10 : dest Rg2_7
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 0, Reconstruit = 0, Différence = 0
Compte des Procedures: Original = 0, Reconstruit = 0, Différence = 0
Compte des Principes : Original = 0, Reconstruit = 0, Différence = 0
Compte des Enonces : Original = 9, Reconstruit = 9, Différence = 0
Compte des Traces : Original = 2, Reconstruit = 2, Différence = 0
Compte des Exemples : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 8, Reconstruit = 8, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 5, Reconstruit = 5, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
[Ant1a] est antécédent de [Ant1b]
[Ant1a] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Ant1a] est un ( :Antécédent d'une règle )
[Ant1b] a pour conclusion [Concl1]
[Ant1b] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Ant1b] est un ( :Antécédent d'une règle )
[Ant2a] est antécédent de [Ant2b]
[Ant2a] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Ant2a] est un ( :Antécédent d'une règle )
[Ant2b] alors [Oper2]
[Ant2b] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Antecedent)
[Ant2b] est un ( :Antécédent d'une règle )
[Concl1] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Conclusion)
[Concl1] est un ( :Conclusion d'une règle )
[Nom1] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Nom)
[Nom1] est un ( :Nom d'une règle )
[Nom1] se compose de [Ant1a]
[Nom1] se compose de [Ant1b]
[Nom1] se compose de [Concl1]
[Nom2] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Nom)
[Nom2] est un ( :Nom d'une règle )
[Nom2] se compose de [Ant2a]
[Nom2] se compose de [Ant2b]
[Nom2] se compose de [Oper2]
[Oper2] est de catégorie (metaDom:MD_Procedurale_Operation)
[Oper2] est un ( :Opération )
[Rg1] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Complete)
[Rg1] est précédent de [Rg2]
[Rg1] est un ( :Règle complète )
[Rg2] est de catégorie (metaDom:MD_Strategique_Entite_Regle_Complete)
[Rg2] est un ( :Règle complète )
[Tr1] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr1] est un ( :Procédure )
[Tr1] se compose de [Rg1]
[Tr1] se compose de [Rg2]
------------------Résultats après inférence-----------------------
[Ant1a] est un ( :Antécédent d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle
)
[Ant1a] est une partie de [Nom1]
[Ant1a] permet [Ant1b]
[Ant1a] permet [Concl1]
[Ant1b] a pour antécédent [Ant1a]
[Ant1b] a pour dépendance [Ant1a]
[Ant1b] alors [Concl1]
[Ant1b] est un ( :Antécédent d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle
)
284
[Ant1b] est une partie de [Nom1]
[Ant1b] permet [Concl1]
[Ant2a] est un ( :Antécédent d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle
)
[Ant2a] est une partie de [Nom2]
[Ant2a] permet [Ant2b]
[Ant2a] permet [Oper2]
[Ant2b] a pour antécédent [Ant2a]
[Ant2b] a pour conclusion [Oper2]
[Ant2b] a pour dépendance [Ant2a]
[Ant2b] est un ( :Antécédent d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle
)
[Ant2b] est une partie de [Nom2]
[Ant2b] permet [Oper2]
[Concl1] a pour dépendance [Ant1a]
[Concl1] a pour dépendance [Ant1b]
[Concl1] est la conclusion de [Ant1b]
[Concl1] est un ( :Conclusion d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle
)
[Concl1] est une partie de [Nom1]
[Nom1] est un ( :Nom d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle )
[Nom2] est un ( :Nom d'une règle :Type de connaissances :Connaissance stratégique :Élément d'une règle )
[Oper2] a pour dépendance [Ant2a]
[Oper2] a pour dépendance [Ant2b]
[Oper2] est la conclusion de [Ant2b]
[Oper2] est un ( :Opération :Type de connaissances :Connaissance d'actions )
[Oper2] est une partie de [Nom2]
[Rg1] est un ( :Règle complète :Type de connaissances :Connaissance stratégique :Élément d'une règle )
[Rg1] est une partie de [Tr1]
[Rg1] permet [Rg2]
[Rg2] a pour dépendance [Rg1]
[Rg2] est la suivant de [Rg1]
[Rg2] est un ( :Règle complète :Type de connaissances :Connaissance stratégique :Élément d'une règle )
[Rg2] est une partie de [Tr1]
[Tr1] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
B.11 Connaissance qui englobe des connaissances
Exemple de représentation en langage MOT
Sémantique formelle
:C_Englobant_0
rdf:type owl:Class ;
rdfs:label "C_Englobant"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept ;
metaDom:ENGLOBE :C_Englobe_1 .
:C_Englobant_0_englobe_C_Englobe_1
rdf:type owl:ObjectProperty ;
rdfs:domain :C_Englobant_0 ;
rdfs:label ""^^xsd:string ;
rdfs:range :C_Englobe_1 ;
rdfs:subPropertyOf metaDom:ENGLOBE .
:C_Englobe_1
rdf:type owl:Class ;
rdfs:label "C_Englobé"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Declarative_Concept .
:En_Englobant_10
rdf:type metaDom:MD_Strategique_AgentContrainteNorme ;
rdfs:label "En_Englobant"^^xsd:string ;
metaDom:ENGLOBE :En_Englobe_11 .
285
:En_Englobe_11
rdf:type metaDom:MD_Strategique_AgentContrainteNorme ;
rdfs:label "En_Englobé"^^xsd:string .
:Ex_Englobant_6
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Ex_Englobant"^^xsd:string ;
metaDom:ENGLOBE :Ex_Englobe_7 .
:Ex_Englobe_7
rdf:type metaDom:MD_Declarative_Concept ;
rdfs:label "Ex_Englobé"^^xsd:string .
:PR_Englobe_5
rdf:type owl:Class ;
rdfs:label "PR_Englobé"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme .
:P_Englobant_2
rdf:type owl:Class ;
rdfs:label "P_Englobant"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing ;
metaDom:ENGLOBE :P_Englobe_3 .
:P_Englobant_2_englobe_P_Englobe_3
rdf:type owl:ObjectProperty ;
rdfs:domain :P_Englobant_2 ;
rdfs:label ""^^xsd:string ;
rdfs:range :P_Englobe_3 ;
rdfs:subPropertyOf metaDom:ENGLOBE .
:P_Englobe_3
rdf:type owl:Class ;
rdfs:label "P_Englobé"^^xsd:string ;
rdfs:subClassOf metaDom:MD_Procedurale_Procedure , owl:Thing .
:Pr_Englobant_4
rdf:type owl:Class ;
rdfs:label "Pr_Englobant"^^xsd:string ;
rdfs:subClassOf owl:Thing , metaDom:MD_Strategique_AgentContrainteNorme ;
metaDom:ENGLOBE :PR_Englobe_5 .
:Pr_Englobant_4_englobe_PR_Englobe_5
rdf:type owl:ObjectProperty ;
rdfs:domain :Pr_Englobant_4 ;
rdfs:label ""^^xsd:string ;
rdfs:range :PR_Englobe_5 ;
rdfs:subPropertyOf metaDom:ENGLOBE .
:Tr_Englobant_8
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr_Englobant"^^xsd:string ;
metaDom:ENGLOBE :Tr_Englobe_9 .
:Tr_Englobe_9
rdf:type metaDom:MD_Procedurale_Procedure ;
rdfs:label "Tr_Englobé"^^xsd:string .
Règles de désambiguïsation
regles_desambig_topologique.owl
regles_desambig_typologique.owl
Règles de conversion
etat_init.owl
[Rule-00_Creer_ontologie_du_domaine]
[Rule-00_Importer_metaOnto_du_domaine]
etat_creation.owl
[Rule-01-2a_Creation_Individu_objet]
[Rule-01-2b_Creation_Individu_procedural]
[Rule-01-2d_Creation_Individu_Principe_Agent]
[Rule-01-a_Creation_class_objet_Concept]
[Rule-01-b_Creation_class_Action_Procedure]
[Rule-01-d_Creation_class_agent]
[Rule-18-a_Creation_Propriete_Englobe_EntAbstraite_EntAbstraite]
etat_classification.owl
[Rule-18-b_Englobe-Declaratif-Declaratif]
[Rule-18_Ajout_ImgDom_Prop_englobe]
etat_final.owl
[Rule-00_Sauvegarde]
Rapport de validation syntaxique
Comparaison des documents :
Orig = C:/Developpement/DATA/workspace/CarréDeSable/ENGLOBE.mot
Recons = C:/Developpement/DATA/workspace/CarréDeSable/ENGLOBE_rest.mot
Comparaison des documents :
----------------------------------------------------------------
--------------------- Les connaissances -----------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
Concept : C_Englobant_0
Concept : C_Englobe_1
Enonce : En_Englobant_10
Enonce : En_Englobe_11
Exemple : Ex_Englobant_6
Exemple : Ex_Englobe_7
286
Principe : PR_Englobe_5
Principe : Pr_Englobant_4
Procédure : P_Englobant_2
Procédure : P_Englobe_3
Trace : Tr_Englobant_8
Trace : Tr_Englobe_9
----------------------------------------------------------------
----------------------- Les relations --------------------------
----------------------------------------------------------------
------------------- Commun aux deux modèles ---------------------
----------------------------------------------------------------
----------------------- BILAN ----------------------------------
----------------------------------------------------------------
---------Totaux des divers composants des modèles --------------
Compte des Concepts : Original = 2, Reconstruit = 2, Différence = 0
Compte des Procedures: Original = 2, Reconstruit = 2, Différence = 0
Compte des Principes : Original = 2, Reconstruit = 2, Différence = 0
Compte des Enonces : Original = 2, Reconstruit = 2, Différence = 0
Compte des Traces : Original = 2, Reconstruit = 2, Différence = 0
Compte des Exemples : Original = 2, Reconstruit = 2, Différence = 0
Compte des LienA : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienC : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienCm : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienI : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienIP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienP : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienR : Original = 0, Reconstruit = 0, Différence = 0
Compte des LienS : Original = 0, Reconstruit = 0, Différence = 0
Rapport de validation sémantique
----------Début du processus de validation sémantique-------------
C_Englobant est une sorte de (metaDom:MD_Declarative_Concept)
C_Englobé englobe C_Englobant
C_Englobé est une sorte de (metaDom:MD_Declarative_Concept)
PR_Englobé englobe Pr_Englobant
PR_Englobé est une sorte de (metaDom:MD_Strategique_AgentContrainteNorme)
P_Englobant est une sorte de (metaDom:MD_Procedurale_Procedure)
P_Englobé englobe P_Englobant
P_Englobé est une sorte de (metaDom:MD_Procedurale_Procedure)
Pr_Englobant est une sorte de (metaDom:MD_Strategique_AgentContrainteNorme)
[En_Englobant] englobe [En_Englobé]
[En_Englobant] est de catégorie (metaDom:MD_Strategique_AgentContrainteNorme)
[En_Englobant] est un ( :Agent-Contrainte-Norme )
[En_Englobé] est de catégorie (metaDom:MD_Strategique_AgentContrainteNorme)
[En_Englobé] est un ( :Agent-Contrainte-Norme )
[Ex_Englobant] englobe [Ex_Englobé]
[Ex_Englobant] est de catégorie (metaDom:MD_Declarative_Concept)
[Ex_Englobant] est un ( :Connaissance d'objet )
[Ex_Englobé] est de catégorie (metaDom:MD_Declarative_Concept)
[Ex_Englobé] est un ( :Connaissance d'objet )
[Tr_Englobant] englobe [Tr_Englobé]
[Tr_Englobant] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr_Englobant] est un ( :Procédure )
[Tr_Englobé] est de catégorie (metaDom:MD_Procedurale_Procedure)
[Tr_Englobé] est un ( :Procédure )
------------------Résultats après inférence-----------------------
[En_Englobant] est un ( :Agent-Contrainte-Norme :Type de connaissances :Connaissance stratégique )
[En_Englobé] est englobé par [En_Englobant]
[En_Englobé] est un ( :Agent-Contrainte-Norme :Type de connaissances :Connaissance stratégique )
[Ex_Englobant] est un ( :Connaissance d'objet :Type de connaissances :Connaissance déclarative )
[Ex_Englobé] est englobé par [Ex_Englobant]
[Ex_Englobé] est un ( :Connaissance d'objet :Type de connaissances :Connaissance déclarative )
[Tr_Englobant] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
[Tr_Englobé] est englobé par [Tr_Englobant]
[Tr_Englobé] est un ( :Procédure :Type de connaissances :Connaissance d'actions )
APPENDICE C
CATALOGUE DES COHÉRENCES DE L'ONTOLOGIE CADRE
D'ONTOCASE
C.1 Axiomes d'identification des erreurs de cohérences
L'ontologie cadre d'OntoCASE est une métastructure qui permet de représenter les
connaissances d'un domaine. Certains axiomes régissent la représentation du domaine
afin d'assurer la cohérence. La stratégie employée pour assurer la cohérence en est
une de type contrainte. Plutôt que d'identifier les conditions qui sont correctes, la
stratégie par contrainte détermine les conditions qui sont incorrectes. Par exemple,
l'axiome116 a du tableau c.1 identifie qu'il y a une erreur d'hyponymie entre la
catégorie primaire si une relation est classée comme hyponyme et que la
connaissance source de la relation est de catégorie primaire et que la connaissance
destination est de catégorie règle, secondaire ou tertiaire.
116 Les axiomes sont dans la notation Manchester OWL (Horridge, Drummond, Goodwin, Rector, Stevens et
Wang, The Manchester OWL Syntax )
288
Tableau C.1
Axiomes d'identification des incohérences
a) ot:OT_ERREUR_HYPONYME_CategoriePrimaire
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire)))
b) ot:OT_ERREUR_HYPONYME_CategorieRegle_ANTECEDENT
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Complete)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Conclusion)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Nom)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
c) ot:OT_ERREUR_HYPONYME_CategorieRegle_COMPLETE
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Antecedent)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Conclusion)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Nom)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
289
d) ot:OT_ERREUR_HYPONYME_CategorieRegle_CONCLUSION
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Antecedent)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Complete)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Nom)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
e) ot:OT_ERREUR_HYPONYME_CategorieRegle_NOM
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Antecedent)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Complete)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Conclusion)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Nom)))
f) ot:OT_ERREUR_HYPONYME_CategorieSecondaire
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire)))
g) ot:OT_ERREUR_HYPONYME_CategorieTertiaire
(oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
or (oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
290
h) ot:OT_ERREUR_HYPONYME_Schema
oRef:OR_Relation_Hyponyme
and ((oRef:OR_connDestination some oRef:OR_Entite_Schema)
and (oRef:OR_connSource some oRef:OR_Entite_Schema))
i) ot:OT_ERREUR_INSTANCE_Agent
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire_Declaratif)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire_Procedural)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Entite_FacteurInfluence_Condition)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Strategique)))
j) ot:OT_ERREUR_INSTANCE_CategoriePrimaire
oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire))
k) ot:OT_ERREUR_INSTANCE_CategorieSecondaire
oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire))
l) ot:OT_ERREUR_INSTANCE_Complete
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Antecedent)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Conclusion)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Nom)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Complete)))
291
m) ot:OT_ERREUR_INSTANCE_Condition
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire_Declaratif)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire_Procedurale)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Strategique)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Strategique)))
n) ot:OT_ERREUR_INSTANCE_Operation
(oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Primaire_Declaratif)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Procedural))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Primaire_Strategique)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Procedural))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Procedural))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Procedural))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Primaire_Procedural))
o) ot:OT_ERREUR_INSTANCE_Procedure
(oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Procedurale))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Procedurale))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Secondaire_Declaratif)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Procedurale))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Secondaire_Strategique)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Procedurale))
or (oRef:OR_Relation_Instance
and (oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Secondaire_Procedurale))
p) ot:OT_ERREUR_INSTANCE_Propriete
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Tertiaire)))
292
q) ot:OT_ERREUR_INSTANCE_RegleAntecedent
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Complete)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Conclusion)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Regle_Nom)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Secondaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
or (oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Tertiaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Antecedent)))
r) ot:OT_ERREUR_INSTANCE_RegleConclusion
(oRef:OR_Relation_Instance
and ((oRef:OR_connDestination some oRef:OR_Categorie_Primaire)
and (oRef:OR_connSource some oRef:OR_Categorie_Regle_Conclusion)))
or