Une fois que la hi´erarchie de concepts a ´et´e construite, au moins partiellement, nous avons pu concevoir la hi´erarchie de relations, qui permet de connecter les concepts entre eux afin d’exprimer les connaissances de CdC sous forme de graphes conceptuels. Trois grandes ´etapes similaires `a celles qui ont compos´e la conception de la hi´erarchie de concepts ont structur´e la conception de la hi´erarchie de relations : la cr´eation et la cat´egorisation des relations par une d´emarche ascendante et it´erative, le compl´ement et la pr´ecision de la hi´erarchie obtenue par une d´emarche descendante, la finalisation de la hi´erarchie par un travail de formalisation, d’op´erationnalisation et de comparaison avec d’autres mod`eles et enfin, la validation formelle de la hi´erarchie.
• Etapes ascendantes
Les premi`eres ´etapes de conception de la hi´erarchie ont ´et´e «ascendantes» et structur´ees autour d’aller-retour entre la conception du mod`ele et son utilisation : nous avons com- menc´e par lister les relations dont nous avions besoin pour repr´esenter les «instances de connaissances» recueillies lors de notre ´etude de terrain (voir p. 133) `a partir des concepts pr´ec´edemment identifi´es. Nous avons ´egalement v´erifi´e que les utilisateurs de l’ontologie pouvaient se construire les principales «repr´esentations projet» (RP) recens´ees `a la p. 147. Par exemple, il est possible de se forger une «repr´esentation des fonctions des entit´es» `a partir de la mise en relation d’une [organisation] avec une [action] par la relation (fonction). Nous ferons autant que possible le lien entre la typologie des RP et l’ontologie au fil des d´efinitions de relations.
Nous avons interrompu ce processus it´eratif quand le besoin de cr´eer de nouvelles relations s’est fait plus rare. Nous avons alors regroup´e les diff´erentes relations rep´er´ees en grandes cat´egories («description», «outil», etc.).
• Etapes descendantes
Nous avons ensuite compl´et´e la hi´erarchie obtenue en r´epertoriant les relations possibles entre chaque paire de concepts.
Nous avons par ailleurs tent´e d’identifier les ´eventuels sous-types manquants de chaque grande cat´egorie de relation : par exemple, n’avions-nous pas oubli´e d’identifier une relation de type «source» qui aurait ´et´e pertinente pour notre objectif ? Ce type de question nous a permis de d´eduire la relation (d´etenteur) `a partir de la relation (source).
Enfin, nous avons compl´et´e la hi´erarchie de relations obtenue en cherchant ce qui pouvait ˆ
3 M´ethode de conception de l’«Ontology for Change Management» (OCM) 183
existantes. Cette ´etape nous a conduit `a cr´eer non seulement des relations, mais aussi un nouveau concept pour chaque valeur de la propri´et´e trouv´ee. Par exemple, le fait qu’un [projet] puisse ˆetre caract´eris´e par un certain degr´e de changement nous a conduit `a cr´eer la relation (degr´e de changement) et le concept [valeur du degr´e de changement] avec pour instances [´evolution] et [r´evolution]. Tous les concepts tels que [valeur du degr´e de changement] ont ´et´e group´es sous le concept [qualit´e] et toutes les relations telles que (degr´e de changement), sous la relation (propri´et´e).6Les couples de [qualit´e]/(propri´et´e) permettent d’exprimer des informations de type «attribut/valeurs». La diff´erence formelle entre les relations de type (propri´et´e) et les autres types de relations est qu’aucune (propri´et´e) n’a de relation inverse (voir p. 195). Il en r´esulte qu’il est possible d’acc´eder `a une [qualit´e] `a partir d’un concept mais pas l’inverse. Car la fonction d’une [qualit´e] se limite `a fournir des infor- mations sur un autre concept qu’elle-mˆeme. Il n’y a donc pas de sens `a caract´eriser ce type de concept et `a en faire un point d’entr´ee pertinent pour la recherche dans la base de graphes.
Une fois que cet inventaire a ´et´e r´ealis´e, il a ´et´e n´ecessaire de sp´ecifier et v´erifier la validit´e des relations h´erit´ees au niveau des concepts de bas niveau.7 Par exemple, la relation (´etape compatible), d´efinie pour relier deux [perdurants] entre eux, n’est pas pertinente pour le sous-type [principe g´en´eral] de [perdurant] dans la mesure o`u un principe g´en´eral ne peut faire partie d’un processus.
• Finalisation de la hi´erarchie
Comme la hi´erarchie de concepts, la hi´erarchie de relations a ´et´e finalis´ee `a partir de l’harmonisation de l’ontologie avec d’autres mod`eles, d’une part, et du travail r´ealis´e autour de son op´erationnalisation, d’autre part.
• Validation formelle de la hi´erarchie
Enfin, nous avons v´erifi´e la validit´e formelle des relations hi´erarchiques entre relations par le crit`ere suivant : soit une relation r d´efinie par la signature {c, c’} et une relation R d´efinie par la signature {C, C’} ; si r est un sous-type de R, alors il faut que c soit un sous-type ou un ´equivalent de C et que c’ soit un sous-type ou un ´equivalent de C’.
6
Sowa (2000) definit une propri´et´e comme «what cannot exist without some substrat » (Sowa 2000).
7La v´erification des h´eritages de relations s’est faite `a partir d’une matrice disposant tous les concepts en
R´esultats : l’ontologie du partage
des connaissances de CdC «OCM»
Ce chapitre d´ecrit l’ontologie OCM par la pr´esentation de :– sa hi´erarchie de concepts (p. 184) ; – sa hi´erarchie de relations (p. 195) ;
– un graphe conceptuel repr´esentant l’ontologie de fa¸con synth´etique (p. 203), dans une derni`ere section qui contient ´egalement l’ensemble des figures auxquelles se r´ef`erent les sections pr´ec´edentes (pp. 204 `a 209).
1
La hi´erarchie de concepts
Nous commen¸cons par pr´esenter la hi´erarchie de concepts dans sa globalit´e (types de concepts et arborescence globale) puis d´efinissons chacun de ses niveaux sup´erieurs.