Critique des méthodes présentées

L’aspect positif des méthodes présentées est qu’elles dressent toutes un plan général des étapes à accomplir pour développer une ontologie. En particulier, elles présentent une première phase de spécification du problème et des buts recherchés par l’ontologie, suivi d’étapes qui permettent de passer de cette spécification à une ontologie implémentée. Cependant, elles sont trop générales pour nous aider concrètement dans le processus de développement. La raison à cela est à notre avis le grand nombre d’utilisations possibles de l’ontologie, de l’enseignement à son utilisation dans des systèmes automatisés. Par exemple, dans notre contexte, il est nécessaire de spécifier de quelle manière l’ontologie sera peuplée, étant donné que nous gérons plusieurs sources de données dynamiques. Malheureusement, seule la méthode Methontology présente cette étape comme faisant partie du processus.

À notre avis, certaines étapes proposées dans ces méthodes sont problématiques. La liste ci-dessous présente ces étapes.

— L’énumération des termes importants : Bien que cette étape puisse être utile jusqu’à un certain point, elle doit être plus élaborée que la simple génération d’une

liste de mots. Par exemple, on pourrait s’attendre à ce qu’une ontologie de la sécu- rité informatique ait un concept “Attaque”. Cependant, cela n’est pas certain, car on pourrait décider de modéliser les attaques dans l’ontologie sous la forme de requêtes au système, rendant inutile la modélisation du concept en tant que tel.

— La réutilisation d’ontologies existantes : On l’a déjà écrit, l’ontologie peut être utilisée dans plusieurs contextes et, même pour un contexte et un domaine précis, il existe un très grand nombre de possibilités de modélisation. De plus, il n’existe pas de manière simple d’évaluer la qualité des ontologies existantes. Pour ces raisons, sans indication supplémentaire, cette étape nous semble difficile à mettre en oeuvre concrè- tement. Ces problèmes ne concernent cependant pas la réutilisation d’ontologies ou de vocabulaires plus larges qui sont très utilisés dans la communauté du web séman- tique, comme par exemple Dublin Core. Ils concernent uniquement la réutilisation d’ontologies spécialisées. Par exemple, il ne nous a pas été possible de réutiliser la taxonomie AVOIDIT que nous présentons plus tard. En effet, bien que les concepts qui y soient présentés sont pertinents dans le domaine de la sécurité informatique, ils ne convenaient pas à notre utilisation de l’ontologie dans un contexte de système expert.

— Définition des hiérarchies de classes et leurs propriétés : Le problème principal avec cette étape est qu’aucune des méthodes proposées ne donne d’indice en ce qui concerne la justification des choix de modélisation. Cela semble être laissé à l’imagina- tion des développeurs en ce qui concerne les utilisations potentielles de l’ontologie. Par exemple, lorsque vient le temps de modéliser concrètement la requête HTTP, les mé- thodes existantes sont de peu de secours pour nous permettre de décider s’il vaut mieux la modéliser sous la forme d’une instance de type “Requête” avec “HTTP” comme va- leur de la propriété “aProtocole” ou comme une instance de type “RequêteHTTP”. La raison à cela est qu’il n’existe pas de théorie de modélisation d’ontologies en fonction des besoins, contrairement à la modélisation des bases de données relationnelles, par exemple. Ce problème n’est pas abordé par les méthodes existantes.

— Évaluation de l’ontologie : En général, on ne conteste pas l’idée qu’il est nécessaire de tester tout modèle. Cependant, il n’est pas aussi simple de tester un modèle de données qu’un algorithme. Par exemple, on peut se questionner au sujet des tests d’une ontologie qui a pour but de faciliter l’enseignement de concepts d’un domaine spécifique. Les méthodes existantes offrent peu de secours à ce sujet.

Ensuite, on trouve quelques problèmes aux méthodes qui les rendent difficiles à utiliser. Nous les énumérons ci-dessous.

expliqué plus haut, cette étape est inexistente dans la plupart des méthodes de déve- loppement d’ontologies alors qu’elle est nécessaire à notre contexte.

— Découplage entre l’étape d’acquisition des connaissances et la formalisa- tion de l’ontologie : Lorsque l’étape d’acquisition des connaissances existe, elle est considérée à part de l’étape de modélisation alors qu’elle devrait avoir une influence majeure sur celle-ci. Par exemple, le fait que le système d’exploitation n’encode pas directement la signification de ses événements devrait influencer notre modélisation. Dans ce cas-ci, il faudra choisir si on modélise une classe “EvenementSystemeDexploi- tation” pour stocker directement les événements ou plutôt des classes plus abstraites comme “InsertionMediaExterne”. Cette modélisation dépend fortement de la source d’information.

— Flou sur l’utilisation du raisonnement : Les méthodes ne permettent pas d’ex- pliquer naturellement de quelle manière le raisonnement possible dans l’ontologie est utilisé. Cela a pour conséquence que plusieurs ontologies développées semblent plus être des graphes orientés avec une sémantique implicite associée aux termes plutôt qu’un système logique permettant à un raisonneur de répondre à des questions dans un monde ouvert.

— Absence de formalisme pour les étapes de spécification : Bien que toutes les méthodes soulignent l’importance de bien spécifier les requis de l’ontologie avant son développement, le formalisme à utiliser pour ce faire n’est pas clair et le lien entre cette spécification et les modélisations semble être laissé à l’improvisation des développeurs. Bref, bien que les méthodes donnent une idée générale théorique du processus de développe- ment d’ontologies, elles sont limitées lorsqu’on accomplit concrètement le travail de modéli- sation. Cela a pour conséquence l’improvisation des développeurs d’ontologies qui se basent sur leur logique, leur intuition et leur expérience. Il est possible que cette généralisation soit volontaire pour englober le plus de contextes possibles. Cependant, cela entraîne les difficultés de modélisation que nous avons évoquées et nous force à définir plus en détail un processus de développement appliqué à notre contexte.