Comment valider une ontologie : entre rigueur logique et besoins métier
Dans la bonne pratique précédente (le pragmatisme philosophique), je rappelais qu’une ontologie résulte de choix de modélisation justifiés par l’usage et la réalité. Si le résultat de la représentation choisie ne permettait pas de répondre aux questions qui ont présidées à sa création, l’ontologie s’avérait insatisfaisante.
Comment valider qu’une ontologie satisfait ses exigences ? En vérifiant que l’interrogation de la base de connaissances qu’elle structure produit non seulement les réponses attendues, mais aussi des réponses logiquement cohérentes.
D’un point de vue usage, il faut valider qu’on peut obtenir des réponses contenant de la connaissance utile, dès lors qu’on dispose d’informations factuelles. D’un point de vue logique, l’objectif est de vérifier que les assertions factuelles (ABox) se réfèrent correctement aux concepts, liens et règles définis dans l’espace terminologique (TBox).
Grâce à un raisonneur, on peut déduire de nouvelles informations en combinant ces deux espaces. Ces déductions seront vraies au sens des axiomes de départ. Encore faut-il pour raisonner correctement, disposer d’une ontologie valide.
Questionner et raisonner dans un monde ouvert
Une même TBox peut servir à plusieurs ABoxes différentes. C’est d’ailleurs le principe des Knowledge Graphs RDF avec des schémas OWL. On peut réconcilier plusieurs graphes dans un quad store, regroupant les triplets par graphes nommés pour étendre la base avec des sources multiples.
Une même TBox peut servir à plusieurs ABoxes différentes. C’est d’ailleurs le principe des Knowledge Graphs RDF avec des schémas OWL. On peut réconcilier plusieurs graphes dans un quad store, regroupant les triplets par graphes nommés pour étendre la base avec des sources multiples. Contrairement aux bases de données classiques où l’absence d’information implique le faux, dans un Knowledge Graph, tout peut être vrai tant qu’il n’est pas prouvé faux (hypothèse du monde ouvert).
Il faut donc explicitement formaliser ce que l’on sait être impossible.
Selon les auteurs de « LOVMI: vers une méthode interactive pour la validation d’ontologies » [1], la validation des ontologies demeure une question centrale de l’ingénierie des connaissances. Elle s’articule autour de deux problématiques complémentaires : (1) la validation structurelle et (2) la validation sémantique (de l’adéquation au domaine modélisé). Dans cet article, c’est essentiellement du deuxième point qu’il est question et de la nécessaire interaction humaine.
Les deux piliers de la validation
La validation repose sur deux piliers :
-
1. La qualité de la construction: Gruber[2] a déterminé un premier jet de critères à vérifier pour la bonne conception des ontologies en 1993. Depuis, la pratique et la recherche ont pu mettre en avant d’autres critères de qualité pour la maintenabilité et aussi des aspects logiques pas toujours vérifiés par les raisonneurs. Un outil comme NEOntometrics propose de nombreuses métriques de qualité structurelles issues de la littérature (dont OntoQA[3]) et des métriques de cohésion et de complexité. Cet outil est associé à une ontologie[4] de définition desdites métriques. L’évaluation de la qualité technique structurelle de l’ontologie est une activité à part entière qui, pour être bien traité, fera l’objet d’un autre billet de bonnes pratiques.
-
2. L’usage recherché: L’ontologie doit répondre aux questions de ses futurs usagers (experts métier), et non seulement aux critères techniques des ontologues. C’est la distinction classique, dans le développement logiciel, entre vérification (le code fonctionne-t-il ?) et validation (la solution répond-elle au besoin ?).
Dans l’ingénierie du logiciel, il a fallu de nombreuses années et de nombreux échecs de projets pour s’apercevoir que la formulation des exigences était une condition sine qua non pour construire des solutions efficaces et de qualité. Il en est de même pour les ontologies.
Formaliser les exigences : les CQ et l'ORSD
Les Questions de Compétence (CQ) sont une technique clé pour définir les exigences fonctionnelles d’une ontologie (Grüninger & Fox, 1995). Elles consistent à élaborer un ensemble de requêtes informelles que l’ontologie devra pouvoir résoudre. Ces questions peuvent être accompagnées de réponses ou de résultats attendus.
Pour guider la conception, les CQ doivent s’accompagner d’une compréhension claire du périmètre d’usage. La méthodologie « Neon »[5] a introduit l’ORSD(Ontology Requirement Specification Document) pour formaliser ces exigences de conception, d’usage et de maintenabilité.
Les questions de compétences sont incluses dans l’ORSD et mises en avant dans la plupart des méthodologies de construction d’ontologies telles que LOT [6] comme un moyen de clarifier les exigences. Par la suite, on pourra évaluer la satisfaction des exigences fonctionnelles à l’aide de requêtes SPARQL. Mais on ne peut pas s’en passer : les phases de conception et d’implémentation de l’ontologie utilisent la logique descriptive.
La formalisation logique : une réflexion, pas une traduction
La formalisation logique n’est pas une traduction du langage naturel en SPARQL, ni un simple exercice d’extraction de termes pour créer des concepts. L’objectif n’est pas de convertir mot à mot les questions de compétences en requêtes, ni de lister les termes pour les transformer en classes. Il s’agit d’une phase de spécification formelle exigeant une réflexion approfondie sur les implications logiques des questions et des réponses souhaitées. Cette étape soulève des interrogations cruciales
-
Quels sont les liens d’hyponymie, méronymie ou synonymie ?
-
Comment éviter les cycles hiérarchiques ?
-
Un terme désigne-t-il une instance ou un concept ?
-
Faut-il une propriété pour une énumération ou une classe dédiée pour plus de richesse sémantique ?
Le niveau de granularité dépend de l’usage. Si je veux une ontologie des vins, je n’irai pas au même niveau de granularité selon qu’il s’agisse de choisir un type de vin pour un plat, ou de gérer une cave avec la parcelle exacte de l’exploitant, l’année de chaque bouteille et les particularités de chaque année selon les régions. Voire je pourrais vouloir faire le distinguo entre régions et terroirs dans le second cas sans forcément en avoir besoin dans le premier.
Par ailleurs si dans le premier cas je peux me satisfaire d’une propriété pour lier un vin à une énumération de couleurs, pour répondre à une question du type «est-ce qu’un vin particulier est classé comme vin rouge », dans le second je peux vouloir créer une classe de couleurs de vin pour expliquer, par exemple, les propriétés des vins bleus ou oranges et répondre à une question du type: «à partir de quelles grappes sont constitués les vins de telle couleur»? Ou «quel procédé donne cette couleur à un vin ? ».
Une construction itérative continue
De manière itérative, on peut rechercher des représentations existantes (ontologies réutilisées ou design patterns) au moment de la conception, qui peuvent souligner des aspects ignorés et pourtant nécessaires sous-estimés au départ. Différentes structures peuvent répondre aux mêmes CQ. L’objectif est de représenter la réalité au plus près du besoin, sans ajouts inutiles ni oublis.
Si la réutilisation permet de gagner du temps sur certains aspects de conception, elle nécessite également une réflexion approfondie sur ses implications logiques et le périmètre d’évolution. Car dans un projet industriel, il faut toujours pouvoir maîtriser le domaine modélisé et son évolution. Importer une ontologie dont on ne maîtrise pas l’évolution est ainsi à éviter.
Dans l’implémentation, le développement de l’ontologie et son codage dans un langage de Logique descriptive (tel OWL) se fera également de manière itérative selon la priorisation des exigences. Le résultat de chaque itération est une nouvelle version de l’ontologie et à chaque version, la problématique de validation revient. Comme dans une approche logicielle, il faut éviter la régression. De nouveaux axiomes peuvent mettre à mal la cohérence logique, aussi bien que l’adéquation au domaine.
D’où l’importance, à chaque étape du développement, de maintenir vivant le processus de formulation des exigences pour garantir une solution pérenne, créant de la valeur. Comme en ingénierie logicielle, l’itérativité ne dispense pas des exigences — elle les remet au centre à chaque cycle. C’est pourquoi la collaboration avec les experts métier n’est pas un préalable ponctuel, mais une activité continue tout au long du développement.
La collaboration indispensable avec les experts
L’ontologue ne travaille pas seul. Les CQs nécessitent l’expertise des domaines concernés pour décrypter les concepts sous-jacents. Ce n’est pas une traduction automatique mais un creusement des implications de chaque question, où l’interaction humaine est clé. Car il s’agit d’éliciter une connaissance qui n’est pas, souvent, encore formalisée. De plus, il faut toujours se rappeler de l’usage qui est visé, pour éviter les écueils de la sur spécification ou sous-spécification qui ont si souvent miné les développements logiciels. Et les garants de l’usage sont ceux qui peuvent exprimer «à quoi ça sert», plutôt que «comment ça marche».
Le projet Beyond2022 pour la mise en place d’un Knowledge Graph en lien avec l’héritage culturel de l’Irlande [7] l’illustre bien. Les instructions aux historiens pour exprimer leurs attentes sous forme de questions auxquelles le KG devait répondre ont été délibérément maintenues vagues. «II a été estimé que cela était nécessaire, car beaucoup des historiens n’avaient pas travaillé avec des KG auparavant. Leur accorder un large degré de liberté a aidé l’équipe d’informatique non seulement à concevoir la structure du KG, mais aussi à percevoir comment les historiens le considéraient comme un outil de recherche. »
Dans ce cas d’usage 54 questions de compétences sont sorties de cette collaboration, qui ont ensuite été raffinées et priorisées … comme des exigences de projet logiciel.
Ce qui veut dire en d’autres termes que se poser les bonnes questions de compétences avec les parties prenantes plutôt que se fier aux compétences de l’ontologue seul reste toujours un préalable à toute solution pérenne.
Sabine Bohnké.
Références
[1] Marion Richard, Xavier Aimé, Marie-Odile Krebs, Jean Charlet. LOVMI: vers une méthode interactive pour la validation d’ontologies. 26es journées francophones d’Ingénierie des Connaissances (IC), Jul 2015, Rennes, France. hal-01166359
[2] Tom Gruber est le premier à formuler un ensemble de critères de "bonne modélisation" pour la conception des ontologies dans le document de 1993 Toward Principles for the Design of Ontologies Used for Knowledge Sharing.
[3]Tartir, Samir & Arpinar, Ismailcem & Moore, Michael & Sheth, Amit & Aleman-Meza, Boanerges. (2005). OntoQA: Metric-Based Ontology Quality Analysis.
[4] Reiz, Achim; Sandkuhl, Kurt (2022 - 2022): An Ontology for Ontology Metrics: Creating a Shared Understanding of Measurable Attributes for Humans and Machines. In : Proceedings of the 14th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management. 14th International Conference on Knowledge Engineering and Ontology Development. Valletta, Malta, 10/24/2022 - 10/26/2022: SCITEPRESS - Science and Technology Publications, pp. 193–199.
[5] Baonza, María. (2010). NeOn Methodology for Building Ontology Networks: Specification, Scheduling and Reuse.
[6] Poveda-Villalón, María & Fernández-Izquierdo, Alba & Fernández-López, Mariano & García Castro, Raúl. (2022). LOT: An industrial oriented ontology engineering framework. Engineering Applications of Artificial Intelligence. 111. 104755. 10.1016/j.engappai.2022.104755.
[7] Christophe Debruyne, Gary Munnelly, Lynn Kilgallon, Declan O’Sullivan, and Peter Crooks. 2022. Creating a Knowledge Graph for Ireland’s Lost History: Knowledge Engineering and Curation in the Beyond 2022 Project. J. Comput. Cult. Herit. 15, 2, Article 25 (April 2022), 25 pages.