Phase de spécification avec la méthode LOT​

La phase de spécification consiste à indiquer pourquoi le vocabulaire est construit et à identifier et définir les exigences auxquelles il doit répondre. Elle constitue la première étape de la méthode Linked Open Terms (LOT). 

Dans la méthode LOT, la phase de spécification précède la phase d’implémentation. 

Le schéma ci-dessous présente les acteurs impliqués, l’enchainement des activités, et les livrables de chaque activité de la phase de spécification.

En s’appuyant sur la documentation et les données fournies par les experts du domaine et les utilisateurs, l’équipe de développement de l’ontologie génère une première proposition des exigences ontologiques rédigées sous la forme de questions ou d’énoncés. Au cours de cette étape, l’engagement d’experts dans le domaine spécifique en question est nécessaire.

Choix des cas d'usage

Les cas d’usage (use case) permettent d’avoir une vision de l’utilisation potentielle de l’ontologie. Cette activité implique des experts du domaine, des utilisateurs et des ingénieurs en ontologie. Le résultat de cette activité est une liste de cas d’utilisation.

Identification et description des données à sémantiser

L’objectif de cette activité est de fournir à l’équipe de développement de l’ontologie la documentation nécessaire sur le domaine à modéliser dans une approche basée sur les données (bottom-up). La documentation à partager peut correspondre à des ensembles de données, des réglementations, des normes, formats de données, spécifications d’API, schémas de base de données, etc.

Définition du champ d'application et des objectifs de l'ontologie

Au cours de cette activité, l’équipe de développement de l’ontologie travaille en collaboration avec les utilisateurs et les experts du domaine pour produire un document qui comprend des exigences non fonctionnelles telles que la langue dans laquelle l’ontologie doit être lexicalisée, si elle doit fournir des lexicalisations multilingues, la langue d’implémentation de l’ontologie ou le profil dans lequel elle doit être formalisée, etc.

Proposition d'exigences ontologiques fonctionnelles

L’activité consistant à élaborer la proposition d’exigences fonctionnelles relatives à l’ontologie est réalisée principalement par les ingénieurs en ontologie, mais elle peut être soutenue par les utilisateurs et les experts du domaine.

Cette activité a pour but de produire un ensemble d’exigences fonctionnelles qui peuvent être matérialisées sous une ou plusieurs des formes suivantes :

  • Questions de compétence (QC) : cette technique a été proposée par Grüninger et Fox (1995) et suggère d’élaborer un ensemble de questions auxquelles l’ontologie à développer devrait répondre lors de requêtes informatiques.
  • Enoncés en langage naturel : le domaine à représenter dans l’ontologie est décrit en rédigeant des déclarations affirmatives ou négatives en langage naturel. Cette technique est similaire à la technique de spécification des logiciels, où chaque exigence définit sans ambiguïté un besoin qui doit être inclus dans le produit logiciel (IEEE, 1998).
  • Informations tabulaires : Cette technique a été proposée dans METHONTOLOGY (Fernandez et al, 1997)  et consiste à créer 3 types de tableaux, un tableau pour lister les concepts, un tableau des relations entre les concepts, et un tableau des propriétés ou attributs des instances des différents concepts.

Validation des exigences ontologiques fonctionnelles

Au cours de cette activité, les experts du domaine et les utilisateurs, en collaboration avec l’équipe de développement de l’ontologie, vérifient si les exigences de l’ontologie définies à l’étape précédente sont valides et complètes.

Les critères suivants, dont la liste n’est pas exhaustive, peuvent être utilisés dans cette tâche de validation :

  •  Un ensemble d’exigences est correct si chaque exigence fait référence à certaines caractéristiques de l’ontologie à développer.
  • Un ensemble d’exigences est complet si les utilisateurs et les experts du domaine examinent les exigences et confirment qu’ils n’ont pas connaissance d’exigences supplémentaires.
  • Un ensemble d’exigences est cohérent sur le plan interne s’il n’existe aucun conflit entre elles.
  • Un ensemble d’exigences est vérifiable s’il existe un processus fini, d’un coût raisonnable, qui permet de vérifier si l’ontologie finale satisfait à chaque exigence.
  • Un ensemble d’exigences est compréhensible si chacune d’entre elles est compréhensible pour les utilisateurs et les experts du domaine.
  • Un ensemble d’exigences est sans ambiguïté si chacune d’entre elles n’a qu’une seule interprétation possible, c’est-à-dire si elle ne laisse place à aucun doute ou malentendu.
  • Un ensemble d’exigences est concis si chacune d’entre elles est pertinente et s’il n’existe pas d’exigences redondantes ou non pertinentes.

Formalisation du document de spécification des besoins (ORSD)

Une fois que l’équipe de développement de l’ontologie dispose de toutes les informations sur les besoins, obtenues grâce aux activités précédentes, le document de spécification des besoins de l’ontologie (ORSD : Ontology Requirements Specification Document) est créé. Ce document de spécification contient toutes les exigences fonctionnelles et non fonctionnelles identifiées et les informations qui leur sont associées. 

LOT propose un modèle pour l’ORSD, en formats docx et tex, qui est stocké dans un dépôt GitHub pour être utilisé par les utilisateurs.

Le document de spécification des besoins sera utilisé pendant toute la phase d’implémentation. 

 

Principes de la méthode LOT
Linked Open Terms
GitHub LOT
Phase d'implémentation LOT
  • María Poveda-Villalón, Alba Fernández-Izquierdo, Mariano Fernández-López, Raúl García-Castro (2022) LOT: An industrial oriented ontology engineering framework, Engineering Applications of Artificial Intelligence, Volume 111, 104755, ISSN 0952-1976,
    https://doi.org/10.1016/j.engappai.2022.104755 
  • Grüninger, M., and Fox, M.S. (1995). The Role of Competency Questions in Enterprise Engineering. In: Rolstadås, A. (eds) Benchmarking — Theory and Practice. IFIP Advances in Information and Communication Technology. Springer, Boston, MA. https://doi.org/10.1007/978-0-387-34847-6_3
  • Gruninger, M., and Fox, M.S. (1995),  Methodology for the Design and Evaluation of Ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal.
  • IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998, pp. 1–40. http://dx.doi.org/10.1109/IEEESTD.1998.88286
  • Fernandez, M., Gómez-Pérez, A., Juristo, N. (1997), METHONTOLOGY: From ontological art towards ontological engineering, AAAI97 Technical Report SS-97-06.
Retour en haut