Eviter les développements monolithiques ...d’ontologies

Matti Blume (CC BY-SA or GFDL), via Wikimedia Commons

Les ontologies sont des spécifications exécutables par une machine, à ce titre on peut les voir aussi comme des composants logiciels. Les bonnes pratiques d’architecture recommandent de les concevoir réutilisables. On a vu précédemment (cf article sur bonne pratique n°3) que cette réutilisabilité était au cœur des ontologies du Web sémantique, pour tenir la promesse de l’interopérabilité sémantique. Les ontologies sont aussi au cœur des échanges numériques entre organisation, pour tenir cette même promesse (cf. [1]).

L’approche modulaire via des patrons de conception (Ontology Design Patterns (ODPs) : la modularité comme principe de réutilisabilité) se focalise sur des questions de conception récurrentes. Toutefois les ODPs ne suffisent pas à borner la réflexion sur la modularisation et l’interopérabilité. Ils ne sont pas la solution unique aux besoins d’alignement d’ontologies ou de matching des entités qu’elles contiennent (cf. glossaire Neon [2]). En outre, des années d’expérience ont pu démontrer qu’il était illusoire de développer de grosses ontologies pour la représentation de domaines de connaissances.

Ces grosses ontologies soulèvent de multiples difficultés pour obtenir un consensus fort sur les entités représentées, maintenir la cohérence en cas de réutilisation, en assurer l’évolution, paralléliser les efforts, etc. En somme, les ontologies monolithiques reproduisent exactement les écueils bien connus du développement logiciel non modulaire.

Entre monolithisme et prolifération : le besoin d'une architecture

Leaflet, CC BY-SA 3.0 , via Wikimedia Commons

A contrario, laisser les ontologies proliférer dans de multiples domaines connexes, adjacents ou se recouvrant, de manière hétérogène et non coordonnée, conduit à un nouveau problème de silos sémantiques, et donc à un nouvel échec de l’intégration et de la réutilisation des données.

Dès lors qu’un domaine recouvre plusieurs perspectives métier et cas d’usage, la modélisation exige deux activités complémentaires : décomposer en composants distincts, puis fédérer ces composants de manière cohérente. Ce qui nous mène à questionner l’architecture idéale pour que la construction d’un tel système de représentation soit satisfaisante.

L’objectif est que les graphes de connaissance structurés par ces ontologies puissent répondre à des questions métier tout en garantissant cohérence logique et interopérabilité sémantique avec d’autres graphes partageant les mêmes engagements ontologiques.

Pour s‘approcher de cette cible, on peut choisir une approche d’ontologies en réseau qui seront connectées via plusieurs niveaux. Cela, grâce au partage d’ontologies spéciales qui fourniront le moteur des alignements entre niveaux : ontologie noyau d’un domaine, ontologie « mid-level» et ontologies de fondation, dites aussi TLO/ULO.

Neon et les réseaux d’ontologies : un développement distribué

Cette figure extraite de « NeOn Methodology for Building Ontology Networks: a Scenario-based Methodology » montre (sous forme de boîtes pointillées) les ressources de connaissances existantes à réutiliser et les résultats possibles (réseaux ontologiques et alignements) qui résultent de l'exécution de certains des scénarios.

L’approche de réseau d’ontologies a été formalisée dès 2006 par le projet européen NEON (Networked Ontologies), qui définit un réseau d’ontologies comme « une collection finie d’ontologies interconnectées par un ensemble de mappings sémantiques » (Deliverable D1.1.1, 2006 [3]).

Comme le soulignent Gómez-Pérez et Suárez-Figueroa (2009), [4] « un réseau d’ontologies est nécessaire car la connaissance du monde réel ne peut être capturée adéquatement par une seule ontologie monolithique « puis cela permet notamment l’intégration de domaines hétérogènes, la réutilisation de ressources existantes, et un développement distribué sans efforts coûteux d’intégration globale. »

Le projet Neon fait bien le distinguo entre un réseau et un ensemble d’ontologies simples interconnectées car dans le réseau « les méta-relations entre les ontologies sont explicitement modélisées et gérées tout au long de leur cycle de vie.». Cette distinction est fondamentale : sans gestion explicite des méta-relations, un réseau d’ontologies se dégrade en simple collection hétérogène. Les alignements peuvent être de différentes natures et on peut se référer à des patrons d’alignement tels que ceux proposés par l’ODPA (Ontology Design Pattern Association). La question reste toutefois de maintenir dynamiquement et durablement cet alignement. C’est précisément à cette question que répond l’architecture multi-niveau présentée ci-après.

Une architecture multi-niveau pour améliorer l’alignement

Cette approche est promue par les auteurs (dont Barry Smith) du livre blanc «Best practices for ontology development» [5], dans la section «principes de conception» pour concevoir un réseau d’ontologies répondant aux besoins d’une entreprises guidée par les données. Cette architecture donne au réseau la capacité d’adaptation aux changements et à la croissance inévitables de l’entreprise.

Les trois niveaux de l'architecture

  • Une ontologie de niveau supérieur unique, petite et neutre en termes de domaine
  • Des ontologies de niveau intermédiaire couvrant des domaines larges, ayant des nœuds racines qui sont soit des enfants directs de classes de l’ontologie de niveau supérieur, soit d’un terme tiré d’une autre ontologie de niveau intermédiaire au sein du réseau
  • Des ontologies de niveau inférieur représentant des domaines spécialisés, ayant des nœuds racines qui sont soit des enfants directs de classes d’une des ontologies de niveau intermédiaire, soit d’un terme tiré d’une autre ontologie de niveau domaine au sein du réseau
Le contenu des ontologies de niveau supérieur est plus général que celui des ontologies des niveaux inférieurs. Quant à délimiter la portée horizontale des ontologies cela nécessite des lignes directrices selon l’axe du contenu. Les notions de noyau et de spécialisation peuvent fournir ces lignes directrices pour le niveau inférieur.
Cette figure extraite du document « Best Practices for ontology Development » illustre les trois niveaux pour l’oBO (Open Biological and Biomedical Ontologies) foundry.

Le niveau supérieur : les ontologies de fondation

Les ontologies visent à formaliser les connaissances d’un domaine selon une perspective donnée. Si deux ontologies traitent du même domaine, elles peuvent différer significativement en raison de leurs cas d’usage, de leur granularité ou de leurs engagements théoriques. Cependant, lorsqu’elles partagent une ontologie de niveau supérieur commune (comme BFO), elles devraient idéalement hériter d’axiomes fondamentaux au niveau des catégories de base, tandis que les axiomes de niveau domaine peuvent varier selon les besoins applicatifs.

On désigne ce type d’ontologies de niveau supérieur par les acronymes TLO (Top Level Ontology) ou ULO (Upper Level Ontology), pour refléter leur haut niveau d’abstraction de concepts largement partagés dans de nombreux domaines. L’ISO, avec le standard ISO/IEC 21838-1:2021-PartI [6] a cherché à définir les exigences, sous forme de caractéristiques précises, auxquelles devait souscrire une telle ontologie. Afin de fournir « le contenu ontologique global qui favorisera l’interopérabilité des ontologies de domaine et soutiendra ainsi la conception et l’utilisation de suites d’ontologies conçues à cet effet ».

Le principe d’une TLO est d’être agnostique de tout domaine et de pouvoir être « utilisée en tandem avec des ontologies de domaine à des niveaux inférieurs pour soutenir l’échange de données, la récupération, la découverte, l’intégration et l’analyse ».  Le standard ISO/IEC 21838-Partie I a été suivi à ce jour par la standardisation de trois TLO qui lui sont conformes : BFO (Basic Formal Ontology), DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) et TUpper.

Des fondations différentes pour des besoins différents

En effet, il existe plusieurs ontologies de fondation : BFO, DOLCE, GFO, GUM, UFO, YAMATO, Tupper, pour citer les principales. Si elles peuvent présenter des similarités, elles ont aussi des différences d’approches structurantes.

Pour exemple, si on prend BFO, on y trouvera le concept de «continuant», qui regroupe l’ensemble des entités persistantes dans le temps (exemple voiture, patient) et celui de «occurrent», qui rassemblent des processus ou événements qui se déroulent au fil du temps (la conduite, la prise de médicament). Une séparation similaire existe dans DOLCE entre Endurant et Perdurant.

Cependant, DOLCE enrichit la base minimaliste et réaliste de BFO avec des notions linguistiques et des qualités détaillées. Tandis que TUpper choisit une approche différente (non monolithique), pour satisfaire aux exigences du standard TLO en regroupant un ensemble de modules ontologiques répondant eux-mêmes à des besoins de standardisation internationale.

Le prochain article approfondira ces différences et comment elles influencent la façon dont vous modéliserez des scénarios concrets (voiture, patient, arbre, etc.).

Quoiqu’il en soit, si les ontologies de fondation assurent une interopérabilité interdisciplinaire plus large, elles requièrent de comprendre, voire d’être formé à l’approche conceptuelle desdites ontologies. Cette difficulté conduit les auteurs de « Coming to Terms with FAIR Ontologies » [7] à qualifier de trop restrictive la recommandation P-REC10 du projet FAIRsFAIR [8] (« Use a Foundational Ontology to align semantic artefacts »). Ainsi si les auteurs reconnaissent «les bénéfices que les ontologies de fondation peuvent apporter au développement d’ontologie, nous considérons que ceci est une exigence très forte à cette étape considérant que beaucoup de développeurs d’ontologie de domaine peuvent avoir des difficultés à comprendre comment aligner leurs artefacts sémantiques à ces ontologies, pour preuve le petit pourcentage d’ontologies publiées qui sont actuellement alignées avec elles. »

MLO : le niveau intermédiaire comme passerelle pragmatique

Face à la courbe d’apprentissage des TLO, il est souvent plus judicieux de s’aligner d’abord sur des ontologies de niveau intermédiaire bien établies, qui auront déjà effectué le travail d’alignement avec la TLO.

Pour surmonter le fossé cognitif entre les abstractions des TLO (comme BFO) et les besoins spécifiques des domaines, l’initiative Common Core Ontologies (CCO) [9] propose une réponse pragmatique en tant qu’ensemble coordonné d’ontologies de niveau intermédiaire (MLO). Le CCO ne se limite pas à une seule ontologie, mais constitue une bibliothèque de modules spécialisés. On y trouvera Time Ontology, Quantity and Unit Ontology, Measurement Ontology, Unit Ontology, ou encore Event Ontology. Toutes ces ontologies sont systématiquement alignées avec BFO, tout en offrant une sémantique plus granulaire et opérationnelle.

En fournissant ces briques intermédiaires pré-alignées, le CCO permet aux développeurs d’ontologies de domaine de ne plus avoir à effectuer le lien direct et complexe avec les catégories de haut niveau. Au lieu de cela, ils peuvent mapper leurs concepts métier vers les termes du CCO (ex: mapper une « mesure de température » vers l’ontologie Quantity), sachant que la connexion vers la TLO est déjà établie et validée. Cette approche transforme l’alignement en une tâche modulaire et réutilisable, réduisant la barrière à l’entrée et améliorant l’interopérabilité sémantique des ontologies publiées.

Une ontologie noyau pour les ontologies de domaine

Architecture multiniveaux avec suite d'ontologies alignées et cohérentes grâce à un noyau et la réutilisation d'ODPs.

Si les ontologies de fondation (ULO/TLO) et les ontologies de niveau intermédiaire (MLO) offrent un socle de concepts généraux standardisés pour éviter la redondance, la question de la modularisation au sein d’un domaine métier demeure cruciale pour atteindre une interopérabilité sémantique effective au sein d’une communauté (entreprise, alliance industrielle, organisme de normalisation).

La réponse réside en organisant l’architecture de niveau inférieur autour d’un noyau ontologique minimal (Core Ontology) capturant les entités et relations de sens commun, strictement nécessaires à l’interopérabilité, mais dénué de toute spécificité métier excessive. Ce noyau remplit deux fonctions : servir de point d’ancrage sémantique commun à toute la suite, et assurer l’alignement avec les ontologies de niveau intermédiaire. Il constitue ainsi le pivot de la construction du réseau d’ontologies (au sens du projet NeOn) du domaine, réseau composé de modules de spécialisation, chacun développé par une communauté d’experts pour couvrir un cas d’usage précis ou un sous-domaine technique et chacun important le noyau.

Les deux bénéfices stratégiques de l’architecture noyau

  1. Contrôle centralisé et léger: Le noyau, étant petit et stable, nécessite un consensus rapide et facile à maintenir sur un nombre restreint de concepts critiques.
  2. Agilité distribuée : Les modules spécialisés peuvent évoluer indépendamment, adaptés aux besoins spécifiques de leurs communautés respectives, tout en garantissant l’alignement sémantique par leur dépendance explicite au noyau.

SAREF : un exemple de suite modulaire en action

Le modèle SAREF(Smart Appliances REFerence ontology), standardisé par l’ETSI pour l’Internet des Objets (IoT), illustre parfaitement ce principe. SAREF définit un noyau générique (SAREF Core) modélisant les concepts universels de l’IoT (Appareil, Fonction, Commande, État, Mesure). Autour de ce noyau, une suite d’ontologies de domaine (SAREF4…) a été développée pour des secteurs spécifiques :
  • SAREF4BLDG (Building) : pour la gestion énergétique et technique des bâtiments ;
  • SAREF4ENER (Energy) : pour les réseaux électriques intelligents et la production d’énergie ;
  • SAREF4SMARTHOME : pour les appareils domestiques connectés ;
  • SAREF4AGRI (Agriculture) : pour l’agriculture de précision ;
  • SAREF4CITY : pour les villes intelligentes.
Chaque extension importe le noyau SAREF, hérite de ses définitions et y ajoute les spécificités métier. Ainsi, un capteur de température dans un bâtiment (SAREF4BLDG) et un capteur dans une ferme (SAREF4AGRI) partagent automatiquement la même sémantique de base (« mesure de température »), assurant une interopérabilité immédiate sans nécessiter de réconciliation complexe entre les modules.

La leçon de SAREF : quand l'adoption prime sur la rigueur

En utilisant TLO, MLO et suite de modules ontologique spécialisés chacun important un noyau commun, l’architecture multi-niveau d’une suite d’ontologies est une réponse au besoin d’interopérabilité entre organisations multiples, hétérogènes, vouées à collaborer sans forcément se connaître.

Néanmoins, force est de reconnaître que le niveau de maturité de l’ingénierie ontologique, s’il est élevé au niveau académique, n’a pas encore vraiment pénétré le domaine industriel.

Ce qui est notable également dans le cas de SAREF, c’est l’adoption puis l’abandon de l’alignement à DUL (DOLCE+DnS Ultralite) [10]. Les versions initiales de SAREF avaient choisi l’alignement à DUL, partageant en cela l’approche SSN/SOSA. Par la suite, l’équipe SAREF a choisi de ne pas maintenir cet alignement explicite dans les versions récentes, suivant une tendance observée également dans l’évolution de l’ontologie SSN/SOSA du W3C. Cette décision s’explique par la volonté de privilégier un modèle léger et pragmatique, plus facilement adoptable par l’industrie IoT, tout en conservant un alignement indirect avec DUL via les mappings vers SOSA/SSN.

Ce choix illustre une tension structurelle de l’ingénierie ontologique : plus un alignement est formellement rigoureux, moins il est adopté spontanément par les praticiens industriels. Un compromis que toute architecture doit anticiper.

Références

[1] “An ontology can help to achieve sharing of meaning because its terms are associated with formal definitions specifying their meanings in a way that can be processed computationally. If an ontology can be shared across participating organizations, then data can be exchanged in such a way that meaning is preserved if the data can be associated with corresponding shared ontology terms.”  ISO/IEC 21838-1:2021(en) Information technology — Top-level ontologies (TLO) — Part 1: Requirements
[2] Source Gómez-Pérez, A., Montiel-Ponsoda, E., & Suárez-Figueroa, M.C. (2008) « NeOn Glossary of Activities” https://oeg.fi.upm.es/files/pdf/NeOnGlossary.pdf . Ce glossaire a été développé par une équipe de 25 personnes issues de 9 institutions pour unifier la terminologie utilisée par les partenaires du projet NEON dans le domaine de l'ingénierie des ontologies. L’alignement d’ontologies y est décrit comme  the activity of finding the correspondences between two or more ontologies and storing/exploiting them." Et le matching “the activity of finding or discovering relationships or correspondences between entities of different ontologies”
[3] Source définition réseau d’ontologies : NEON Deliverable D1.1.1 (2006) - "Updated Version of the Networked Ontology Model
[4] Source : Gómez-Pérez, A., & Suárez-Figueroa, M. C. (2009). "NeOn Methodology for Building Ontology Networks: A Scenario-Based Methodology" Auteurs : Asunción Gómez-Pérez, Mari Carmen Suárez-Figueroa. Conférence : EKAW 2008 (Knowledge Engineering and Management). Lien  https://oa.upm.es/5475/1/INVE_MEM_2009_64399.pdf
[5] Best Practices of Ontology Development (Robert Rudnicki, Barry Smith,Tanya Malyuta, William Mandrick, 2016) –A CUBRC/NCOR ontology white paper (Oct 25, 2016)
[6] ISO/IEC 21838-1:2021Information technology — Top-level ontologies (TLO)Part 1: Requirements
[7] Poveda-Villalón, María & Espinoza-Arias, Paola & Garijo, Daniel & Corcho, Oscar. (2020). Coming to Terms with FAIR Ontologies. 10.1007/978-3-030-61244-3_18.
[8] Le projet européen FAIRsFAIR (Grant Agreement No. 831558, 2019-2022), recommande que les ontologies utilisent des vocabulaires qui suivent les principes FAIR et soient alignées avec des ontologies de niveau supérieur pour garantir l'interopérabilité sémantique . Cependant, comme le montre l'analyse du projet, seulement environ 30% des ontologies publiées sont actuellement alignées avec des TLO, ce qui souligne le défi pratique de cette recommandation.
[9] https://github.com/CommonCoreOntology/CommonCoreOntologies
[10]https://github.com/odpa/patterns-repository/blob/master/EEP/DUL.owl
top
error: Content is protected !!