Transformation of Semi-formal Models into Ontologies According to a Model Driven Architecture

Michel Héon Télé-Université du Québec

100 rue Sherbrooke ouest, Montréal, H2X 3P2

michel.heon@licef.teluq.uqam.ca

Gilbert Paquette Télé-Université du Québec

100 rue Sherbrooke ouest, Montréal, H2X 3P2 (bureau 1755)

paquette.gilbert@teluq.uqam.ca

Josianne Basque Télé-Université du Québec

100 rue Sherbrooke ouest, Montréal, H2X 3P2

basque.josianne@teluq.uqam.ca

ABSTRACT The construction of an ontology implies three main activities which are generally conducted by a knowledge engineer: (1) knowledge elicitation, (2) formalization of the elicited knowledge into an ontology and (3) syntactic and semantic validation of the ontology. The whole process is complex and requires high competencies from the knowledge engineer, whose goal is to reduce as much as possible the gap between the richness of the actual expertise of the domain experts and its formal ontological representation. Our approach is (1) to have the domain experts participate directly to the elicitation operation though semi-formal visual knowledge modeling. Then, (2) the engineer transforms this semi-formal model to a formal one taking the form of an ontology. The goal of our project is to develop an expert system which will support the engineer in this transformation process. A “transformation ontology” will serve as a knowledge base for the transformation service to be carried out by the expert system. Finally, (3) the knowledge engineer validates the result with the domain experts.

Categories and Subject Descriptors

I.6.5 [Model Development]: Modeling methodologies; E.4 [Coding and Information Theory]: Formal models of communication; D.3.1 [Formal Definitions and Theory]: Semantics --- Syntax; I.2.2 [Automatic Programming]: Program transformation; J.6 [Computer-Aided Engineering]: Computer-aided design (CAD)

General Terms

Design, Algorithms

Keywords Formalization, Ontology, Ontological Engineering, Ontology Development, Expert System, Model Driven Architecture

1. INTRODUCTION Cet article s’inscrit dans la mouvance des développements en ingénierie des connaissances, notamment dans les domaines des processus d’acquisition des connaissances et de la conception

d’ontologies. Nous proposons d’introduire, dans le processus de conception d’ontologies, une étape de modélisation de degré semi-formel offrant à la fois aux experts de domaine un langage souple et intuitif pour exprimer leur expertise, et à l’ingénieur des connaissances les éléments formels de base requis pour sa transformation subséquente en ontologie formelle.

Plus spécifiquement, nous émettons l'hypothèse qu'il est possible d'extraire de manière semi-automatique une somme importante de connaissances à partir d'un modèle semi-formel de connaissances, dans le but de les formaliser sous la forme d’une ontologie, et ce, indépendamment qu'elles soient de type déclaratif, procédural stratégique ou factuelle.

Pour vérifier cette hypothèse, nous utilisons l'architecture conduite par les modèles (ACM)1 en tant qu'outil conceptuel pour structurer la démarche. Deux aspects particuliers de l'ACM retiennent notre attention, soit la structure architecturale, fragmentée en niveau d'abstraction de langage (présentée à la section 2.2), et le principe de transformation entre modèles (présenté à la section 2.4).

La section 3 présente de façon plus spécifique l'hypothèse de travail avancée dans cet article ainsi que le positionnement de l'hypothèse par rapport au processus de conception d'une ontologie tel que nous l'envisageons.

Les règles de transformation qui régissent l'exécution du processus de transformation permettent la création d'une ontologie de domaine (modèle cible) à partir de la transformation d'un modèle semi-formel source. Les sections 4 et 5 présentent la structure du système de représentation semi-formel, soit le langage de Modélisation par Objets Typés (MOT), ainsi que le système de représentation d’ontologies, soit l'Ontology Web Language (OWL)

La transformation d'un modèle semi-formel en ontologie est une activité délicate et complexe. D'une part, la différence entre les degrés de formalisation du modèle source et du modèle cible implique un traitement non trivial pour la transformation des connaissances. D'autre part, la nature variée des connaissances (déclarative, procédurale, stratégique, factuelle) du modèle semi-formel implique un traitement particulier pour leur donner un format déclaratif commun, qui est intrinsèque aux ontologies OWL. Inspirés du principe d'espace de domaine, nous proposons à la section 6 deux architectures de transformation soit la transformation parallèle et la transformation orthogonale.

1 Traduction de l'anglais de "Model Driven Architecture" (MDA)

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. JFO 2008, December 1-2, 2008, Lyon, France. Copyright 2008 ACM 978-1-60558-373-0/08/0003.$5.00.

Standardisé par l'Object Management Group (OMG), le Meta Object Facility (MOF) est le langage abstrait pour la spécification des métamodèles. Le langage MOF-Query/View/Trasnformation (MOF-QVT) est aussi un standard OMG dédié à la transformation des informations entre les modèles. À la section 7, nous utiliserons le Resource Definition Framework (RDF) en tant que méta-métamodèle pour la spécification des métamodèles MOT et OWL. De même, nous présentons l'architecture du processus de transformation dont le composant principal est un système expert, dont la base de connaissances est une ontologie de transformation.

À titre d’exemple, la section 8 présente le cas d'une transformation de connaissances déclaratives d'un modèle MOT en une ontologie OWL.

Un aperçu des travaux en cours et à venir est présenté à la section 9.

2. ARCHITECTURE CONDUITE PAR LES MODÈLES

Proposée par l’Object Management Group2 (OMG), l'architecture conduite par les modèles (ACM) "Model Driven Architecture" offre un cadre méthodologique et architectural de développement de logiciels qui vise à découpler le développement des spécificités métiers des contraintes technologiques liées à l'implantation de la solution [1, 2].

2.1 Modèle, métamodèle et méta-métamodèle Les concepts de modèle, métamodèle et méta-métamodèle composent la structure de l'ACM.

Un modèle est une abstraction qui, selon un point de vue spécifique, représente une partie de la réalité. Le modèle se construit à partir d'éléments qui répondent à une syntaxe et à une sémantique cohérente formant un système de représentation des connaissances.

Un métamodèle3 est une abstraction qui sert à définir la syntaxe et la sémantique d’un système ou langage de modélisation.

Un méta-métamodèle est une abstraction qui sert à définir la syntaxe et la sémantique d’un système de représentation de métamodèles. Le trait particulier d’un méta-métamodèle est qu'il assure la comparaison et l'interopérabilité entre les différents métamodèles, facilitant ainsi la transposition entre des modèles qui n'ont pas le même système de représentation. C’est le cas lorsqu’on désire transposer une modèle semi-formel représenté en langage MOT, en un modèle formel représenté en OWL.

2.2 Les niveaux d'abstraction de l'ACM Le cadre de l'ACM, tel que défini par l'OMG. est divisé en quatre niveaux (voir la figure 1):

- Le niveau M0 contient les instances du modèle de niveau M1. Chacune des instances est le représentant d'un objet de la réalité observable.

- Le niveau M1 est le modèle de la couche M0 exprimé dans le système de représentation UML. Chaque élément

2 http://www.omg.org/ 3 Le préfixe "méta" est employé pour indiquer le niveau supérieur d'abstraction pour la désignation de quelque chose. Par exemple, une métadonnée est une donnée à propos d'une donnée.

du langage UML est une instance du métamodèle du niveau M2.

- Le niveau M2 ou métamodèle exprime la syntaxe et la sémantique du système de représentation de la couche M1 (dans ce cas-ci l’UML). Chacun des éléments du métamodèle est une instance du niveau M3.

- Le niveau M3 ou méta-métamodèle est le modèle du niveau M2. Il permet de définir la structure syntaxique et sémantique de tous les métamodèles du niveau M2 et donc de tout langage ou système de représentation. Le langage de représentation du niveau M3 est le MOF, qui a la propriété d'être réflexif, c'est-à-dire qu'il peut servir à se définir lui-même.

Figure 1: Les niveaux d'abstraction de l'architecture conduite

par les modèles À l'exemple de la figure 1, notre chien familial (qui fait partie de la réalité observable) est représenté par une photo4. Au niveau M0, il est représenté par un identifiant. Le niveau M1 présente le modèle UML de cet objet, soit la classe "Berger Allemand", qui possède l'attribut "nom" de type "string" et de valeur "Bahia". Le niveau M2 présente le métamodèle du système de représentation du niveau M1. Il décrit la structure du modèle UML utilisé au niveau M1. Cette structure se compose d’une classe "Classe" et d’une classe "Attribut", ainsi que d’une relation de "composition". Le méta-métamodèle du niveau M3 décrit les composants du système de représentation UML utilisé au niveau M2. Il indique que le métamodèle UML contient une classe "Classe", une classe "Attribut" ainsi qu’une classe "Association" qui a pour source la classe "Classe" et pour destination la classe "Attribut".

4 Nous admettons qu'une image n'est pas un symbole reconnu

dans les systèmes de représentation. Cependant, nous avons choisi ce type de représentation pour mettre en évidence le fait que les identifiants du niveau M0 sont indépendants du langage qui les représente.

2.3 Espace de modélisation L'espace de modélisation (EM) [3] est une architecture de modélisation réalisée à partir d'un méta-métamodèle particulier (par rapport à la réalité).

La figure 2 présente un exemple de différents espaces de modélisation (adapté de [3] p. 132). Le premier EM présenté est l'Extended Backus-Naur Form (EBNF), le modèle qui sert à la définition de la grammaire du langage Java. Celle-ci sert de modèle aux programmes Java qui, eux-mêmes, sont des modèles pour décrire une représentation de la réalité. Un autre EM, le RDFS, est le méta-métamodèle du langage OWL qui permet de construire le modèle d'une ontologie OWL.

Dans la figure 2, le MOF sert à la fois d'EM pour le métamodèle UML et le métamodèle MOT. Le premier définit le langage de représentation pour la construction des modèles UML, le second représentant le langage qui permet de construire des modèles de connaissances MOT. Le fait d’utiliser le même EM permet de comparer deux modèles utilisant des systèmes de représentation différents.

Figure 2: Espace de modélisation MOF, EBNF et RDFS

2.4 La transformation de modèle selon l'ACM La transformation de modèle est l'une des applications importantes de l'ACM. Elle vise la production automatique d'un modèle cible à partir d'un modèle source par l'interprétation d'un ensemble de règles de transformation qui régissent le déroulement du processus de transformation.

Schématisé à la figure 3, le processus de transformation produit un modèle cible à partir des informations contenues dans le modèle source. Les règles d'utilisation des informations du modèle source sont dictées par le métamodèle (niveau M2) du modèle source. Le métamodèle source est aussi un intrant au processus de transformation. Les règles d'interprétation des informations du modèle cible sont contenues dans le métamodèle cible. Le métamodèle cible est aussi un intrant du processus de transformation. Remarquons que, même si les règles de représentation changent d'un modèle à l'autre, les deux modèles servent à représenter le même objet de la réalité.

Du point de vue technologique, les outils comme le MOF-Query/View/Trasnformation (MOF-QVT) [4] pour la recherche dans les modèles, la production de vues dans les métamodèles et

la transformation de modèles ainsi que l'Object Constraint Language (OCL) [5] qui permet l'expression formelle de contraintes sur des éléments de modèle UML, sont utilisés pour construire des processus de transformation entre des modèles, pourvu que ces processus soient dans l'espace de modélisation MOF.

Figure 3: Architecture générique du principe ACM de

transformation inter modèles

3. HYPOTHÈSE DE TRAVAIL 3.1 Le processus de transformation Il est possible de concevoir un processus de transformation instrumenté par un système expert qui rend plus efficace la formalisation des connaissances résultant en une représentation de degré formel à partir d'une représentation de degré semi-formel.

Figure 4 : Positionnement du processus de transformation en

fonction des degrés de formalisation et classification d’exemples de formalisme

Ce processus de transformation (voir la forme ovoïde à la figure 4), dont l’intrant est une représentation de degré semi-formel et l’extrant une représentation de degré formel, est un système expert alimenté par une base de connaissances prenant la forme d'une ontologie de transformation. La figure 4 présente aussi des exemples de systèmes de représentation classifiés selon le quantum des degrés de formalisation proposé par Uschold & Gruninger [6]. Les systèmes de représentation utilisés pour cet article apparaissent en vert, à savoir MOT (en tant que prototype de système de représentation de degré semi-formel) et OWL (en tant que prototype de système de représentation de degré formel)

3.2 Le processus de conception d'une ontologie utilisant le processus de transformation

Inspirée de la définition d'ontologie de Gruber [7] qui stipule qu’une ontologie est une « explicit specification of a shared conceptualization », la figure 5 présente le processus incrémental de conception d'une ontologie. L'originalité de notre approche consiste à le dissocier en trois activités: éliciter, formaliser, valider. Réalisé par l’ingénieur de la connaissance en collaboration avec un expert, la "conceptualisation" est un modèle semi-formel issu de l'activité éliciter. Il est à noter, que la dénomination d' "expert" peut aussi faire référence à un groupe d'experts dont l'élicitation est réalisée par co-modélisation [8]. L'activité formaliser, instrumentée par un système expert, est réalisée par l'ingénieur de la connaissance. Cette activité consiste à transformer le modèle semi-formel en ontologie formelle syntaxiquement valide. C'est à l'activité valider que l'élément consensuel "share" de la conceptualisation est étendu au-delà de l'expertise du domaine puisque l'expert et l'ingénieur collaborent afin de faire concorder la sémantique de l'ontologie avec celle du modèle semi-formel.

Figure 5: Représentation en MOT du processus incrémental

de conception d'une ontologie de domaine L'activité de validation sémantique a pour objectif de produire une ontologie conforme aux spécifications fonctionnelles (qui ont été préalablement établies) du domaine d'application. L'expert du domaine et l'ingénieur évaluent, d'un commun accord, la qualité de concordance entre la sémantique du modèle semi-formel et l'ontologie. Si le degré de concordance est suffisant, alors le processus se termine. Si non, le processus est repris pour une nouvelle itération.

4. SYSTÈME DE REPRÉSENTATION D’ORIGINE DE DEGRÉ SEMI-FORMEL

4.1 La modélisation par objets typés Issue du domaine de l'éducation, la Modélisation par Objets Typés MOT [9] est un système de représentation graphique qui permet la représentation de connaissances conceptuelles, procédurales, stratégiques et factuelles. De degré semi-formel, le langage MOT est tout indiqué pour supporter des activités de modélisation pour les spécialistes de domaine qui n'ont pas l'expertise d'utilisation de langages formels comme l'UML et l'OWL et qui ont besoin de représenter des connaissances de type divers dans un même schéma. Bien qu'il soit de degré semi-formel, le langage MOT

possède une structure typée qui permet d'associer une sémantique aux entités et aux relations du langage.

4.2 Métamodèle de MOT Le métamodèle de MOT représenté en UML aux figures 6, 7 et 8 se divise en trois éléments principaux: le premier regroupe les constituants de haut niveau; le second décrit les types de Connaissances ; et le troisième décrit les types de Relations.

Figure 6: Représentation UML des composantes de haut

niveau du langage MOT

4.2.1 Composantes de haut niveau du langage MOT Un Modèle MOT (voir la figure 6) se compose d'au moins une ou plusieurs connaissances et d'aucune ou de plusieurs relations. Une Relation se compose d’une association source et d’une association destination qui affirme que deux connaissances sont connectées entre elles par la Relation. Par généralisation, la Connaissance est une sorte de ModèleMOT. En effet, une connaissance peut être considérée comme le regroupement de sous-éléments de connaissances et de relations, appelés « sous-modèles ».

4.2.2 Types des connaissances en MOT À l'instar des théories sur la représentation des connaissances, le langage MOT offre la possibilité de représenter des connaissances selon deux niveaux d'abstraction: conceptuel (ConnaissanceAbstraite) et factuel (Fait) (voir la figure 7).

Figure 7: Représentation UML des connaissances en langage

MOT De niveau abstrait, la classe Concept est utilisée pour représenter des connaissances conceptuelles, c'est-à-dire le «quoi» des choses. De même, la classe Procédure, qui est aussi une connaissance abstraite, sert à la représentation de connaissances procédurales : elle représente le «comment» des choses. Finalement, le Principe est une connaissance abstraite de type stratégique qui désigne le «pourquoi» et le «quand» des choses.

À chaque connaissance abstraite (Concept, Procédure, Principe) peut correspondre une connaissance factuelle (Exemple, Trace, Énoncé).

4.2.3 Type des relations en MOT En langage MOT, les connaissances sont reliées entre elles par des liens typés (voir la figure 8).

Connaissance

Relation

0..1source 0..1 0..1 destination0..1

ModeleMot

1..n

connaissances

1..n

0..*

relations

0..*

Concept Procedure

Connaissance

Principe

Fait

EnonceTraceExemple

ConnaissanceAbstraite

Figure 8: Représentation UML des relations typées utilisées en

langage MOT Le LienIP (lien Intrant/Produit) définit une relation qui sert à associer une connaissance procédurale à une connaissance conceptuelle afin de représenter l'intrant ou le produit d'un processus.

Le LienC et le LienCm (lien de Composition et de Composition Multiple) permettent de représenter l’association entre une connaissance et des connaissances qui la composent.

Le LienR (lien de Régulation) associe une connaissance stratégique (un Principe ou un Énoncé) à une connaissance afin de préciser une contrainte, une restriction ou une règle qui régit la connaissance.

Le LienA (lien d'Application) permet l’association d’une métaconnaissance à une connaissance.

Le LienI (lien d'Instanciation) associe à une connaissance abstraite l’ensemble des faits qui caractérisent une instance de cette connaissance.

Le LienS (lien de Spécialisation) associe deux connaissances abstraites de même type dont la première est une spécialisation de la seconde. Ce lien est utile pour représenter une catégorisation de connaissances afin de produire une taxonomie.

Le LienP (lien de Préséance) associe une connaissance à une autre qui la suit dans une séquence temporelle de procédures ou de règle de décision (principes).

Certaines règles d’association des connaissances sources à des connaissances destinations sont appliquées à chacun des types de relation. Ces règles définissent les relations considérées valides entre les différents types de connaissances du point de vue de la sémantique MOT. Elles sont présentées au tableau 1. Le sens de l'application de l'action est toujours de la connaissance source (ou origine) vers la connaissance destination. Schématiquement, ce sens est indiqué par une flèche.

Tableau 1: Règles d'utilisation des liens

5. L’ONTOLOGY WEB LANGUAGE (OWL/SWRL)

Plusieurs implémentations de langage ontologique sont disponibles pour représenter des connaissances de degré formel. Mentionnons KIF et FLogic, qui sont des langages ontologiques basés sur la logique du premier ordre ou encore, Loom qui est basé sur le langage des descriptions [10]. Pour notre étude, nous avons choisi l'Ontology Web Language (OWL) combiné au Semantic Web Rules Languages (SWRL) en tant que langage ontologique formel pour les raisons suivantes :

- Standardisation : En tant que système de représentation du projet du Web Sémantique, l’OWL est le langage ontologique normalisé par le World Wide Web Consortium (W3C5).

- Disponibilité : La standardisation du langage par le W3C mobilise actuellement la communauté scientifique pour le développement et l’entretien des applications utilisant l’OWL, offrant ainsi une grande disponibilité pour l’utilisation de ce langage.

- Interopérabilité : L’interopérabilité du langage OWL est assurée par une définition reposant sur la structure XML [11]. De ce fait, de multiples outils informatiques sont disponibles pour l’importation/exportation des ontologies. À titre d’exemple, le logiciel intégré Jena [12, 13] offre un ensemble de classes Java permettant l’importation/exportation d’une ontologie OWL à l’intérieur d'une application Java.

L'Ontology Definition Metamodels (ODM) [14], standardisé par l'OMG, est le projet qui définit les métamodèles de RDF/S et d'OWL dans l'espace de modélisation MOF. Toujours dans cet EM, l'OMG préconise l'utilisation du MOF-QVT et d'OCL pour la transformation de modèles. Pour le Web sémantique, l'EM privilégié par le W3C est le RDF/S, et c'est dans cet espace que les métamodèles d'OWL et de SWRL sont définis. À terme, pour la conception de règles transformation, nous remplacerons le MOF-QVT par les technologies issues du projet du Web sémantique. Nous mettrons à profit les capacités de représentation des ontologies (OWL/SWRL) ainsi que la puissance de déduction des engins d'inférences pour représenter et exécuter les règles de transformation.

6. PRINCIPE DU PROCESSUS DE TRANSFORMATION

Nous avons vu à la section 2.4 que la conception d'un processus de transformation entre modèles est une activité importante de l'ACM. Dans le cas qui nous occupe, nous sommes intéressés par la conception d'un processus de transformation qui permet de formaliser des connaissances exprimées de façon semi-formelle et de représenter des connaissances de nature déclarative, procédurale, stratégique et factuelle en connaissances de nature déclarative propre aux ontologies OWL. Ces spécifications exigent une étude sur les principes de transformation.

6.1 Principe de transformation parallèle Le principe de transformation parallèle a comme pré-condition que le modèle source et le modèle cible possèdent une structure de métamodèle similaire permettant la conception de règles de

5 http://www.w3.org/

Relation

LienC LienR LienS

LienPLienIP LienA

LienI

LienCm

transformation de type "un à un". Par exemple (voir la figure 9), la métaclasse Concept du métamodèle MOT peut être transposée en métaclasse Class dans le métamodèle OWL ou encore la métaclasse LienS, de type relation, est transposée en métaclasse subClassOf. Paquette et Rogozan [15] utilisent cette approche pour la conception du langage MOT-OWL mais ils se restreignent à une sous-classe de modèles MOT proche du langage des ontologies OWL-DL.

Une limite importante de la transformation parallèle est que le processus de transformation est réalisé sans tenir compte de la sémantique des langages en cause dans la transformation. En corollaire avec la traduction en linguistique, la transformation parallèle est un processus qui produit une traduction en mode mot-à-mot sans considérer le sens des mots qui sont traduits.

Compte tenu de la nature diverse des connaissances qui sont traitées par MOT et du changement de degré de formalisation des connaissances qui sont traduits par le processus de transformation, nous pensons qu'il serait bénéfique de considérer la sémantique du langage MOT lors de la transformation.

Figure 9: Processus de transformation parallèle

6.2 Principe de transformation orthogonale Dans le but spécifique de considérer la sémantique du modèle source lors de la transformation, l'idée maîtresse du principe de la transformation orthogonale est de considérer les niveaux architecturaux du modèle MOT en tant que constituant de la réalité observable (voir la figure 10). Le modèle du métamodèle source (l’ontologie du métamodèle MOT) et un modèle du modèle source (l’ontologie du modèle MOT), ainsi que le modèle MOT (le modèle source du domaine à représenter), servent d'intrants au processus de transformation.

Une particularité intéressante de ce principe de transformation est que le modèle MOT du domaine est représenté en tant qu'élément factuel de l'ontologie du modèle MOT et que la sémantique du modèle semi-formel (le modèle source) est représentée par l'ontologie du métamodèle MOT. Cette particularité de combinaison des éléments sémantiques et factuels permet de produire des règles de transformation qui sont appliquées à partir de déductions et d'inférences contextualisées par le modèle source, permettant la conception d'un système expert à la transformation.

Figure 10: Processus de transformation orthogonale

7. SYSTÈME EXPERT À LA TRANSFORMATION

Comme présenté à la section 3, le système expert à la transformation a pour objectif d'assister l'ingénieur de la connaissance dans l'activité de transformation d'un modèle semi-formel en ontologie. La présente section présente l'architecture conceptuelle et informatique du système expert et de l'ontologie de transformation qui compose sa base de connaissances.

7.1 ACM du système expert à la transformation

La figure 11 représente le positionnement du système expert à la transformation (SET) en tant qu'agent de transformation orthogonale situé dans l'espace de modélisation RDFS. Le SET utilise l'ontologie de transformation comme base de connaissances pour la transformation du modèle MOT de domaine en un modèle OWL de domaine. Le SET est une application dont les modèles sont définis par le métamodèle OWL et le métamodèle SWRL.

Figure 11: Système expert à la transformation dans l'espace

de modélisation RDFS

7.2 Structure de l'ontologie de transformation L'ontologie de transformation (voir la figure 12) est une base de connaissances qui importe une ontologie du métamodèle de MOT et comporte un ensemble de règles de transformation. Ces règles concernent, d'une part, la transformation des connaissances de l'espace semi-formel en connaissances dans l'espace formel et, d'autre part, l'ajout d'atomes SWRL et de règles pour la création et la manipulation d'ontologies de domaine.

Figure 12: Sous-éléments constituants l'ontologie de

transformation présentée en MOT

7.3 Architecture informatique du système expert à la transformation

Le modèle de déploiement du système expert à la transformation, présenté à la figure 13, positionne les différents constituants du SET. Les capacités de raisonnement et de déduction sont assumées conjointement par l'application Racer [16] et Jess [17-19]. Les fonctions d'import/export d'ontologies OWL/SWRL sont réalisées par la bibliothèque Jena [13]. La manipulation (création/modification) de l'ontologie de domaine est supportée par la construction d'une bibliothèque de commandes "built-in"[20] de SWRL.

Figure 13: Modèle UML de déploiement du système expert à

la transformation

8. EXPÉRIMENTATION Dans la perspective de confronter notre hypothèse de travail, nous avons réalisé une expérimentation permettant la transformation d'un modèle semi-formel source en une ontologie cible. Nous présentons ici quelques règles qui ont été implantées dans l'ontologie de transformation. Nous présentons aussi le détail du processus de transformation tel que réalisé. Pour finir, des résultats préliminaires viennent appuyer la validité de notre démarche.

8.1 Règles de transformation Pour la construction des règles de transformation (voir le tableau 2), nous avons choisi la logique des descriptions "Descriptive Logic (DL)"[21] en tant que langage abstrait à OWL[22]. Afin de faciliter la lecture, les règles de transformation sont présentées en langage naturel.

8.2 Processus de transformation détaillé De façon détaillée, la figure 14 présente le processus de transformation orthogonale en présentant le parcours de l'information à partir de l'étape d'édition du modèle semi-formel jusqu'à la production de l'ontologie de domaine.

Étape 1: Exporter le modèle semi-formel source À partir d'un modèle conceptuel de domaine représentant un élément de la réalité, l'étape d'exportation du modèle produit un document contenant les données représentant le modèle conceptuel de domaine. Ce document est un artéfact qui fait partie de la réalité observable, il peut s'agir par exemple d'un fichier XML ou de type RDF.

Étape 2: Importer le modèle de domaine sous une forme ontologique À partir du fichier obtenu à l’étape 1 et de l'ontologie du métamodèle MOT, l'étape d'importation du modèle sous une forme ontologique, produit l'ontologie du modèle MOT, qui est un modèle du niveau M1. Cette ontologie contient l'ensemble des éléments du modèle de domaine qui sont représentés sous la forme d'individus de l’ontologie du métamodèle MOT.

Étape 3: Transformer l'ontologie du modèle MOT en ontologie cible À partir des individus de l'ontologie du modèle MOT (de niveau M0) et par l'interprétation de l'ontologie de transformation (laquelle contient le métamodèle de MOT et un répertoire de règles de transformation), l'étape de transformation vise la production de l'ontologie cible de niveau M0, exprimée en OWL.

Figure 14: Processus détaillé de la transformation entre un

modèle semi-formel source en une ontologie cible

8.3 Résultats préliminaires Les présents résultats ont été obtenus à partir de l'application du processus détaillé de la figure 14. Compte tenu de la nature préliminaire des résultats, l'implantation de l'étape 4 est réalisée à partir d'une application Java qui est à base de commandes (tel que défini par Gamma [23]) plutôt que par un système à base de règles tel que présenté ici. L'implantation du système à base de règles fait partie des travaux qui sont en cours de réalisation.

Inspiré des articles de Golbreich [24, 25], un modèle MOT a été construit sur le thème de "la famille" (voir la figure 15).

Figure 15: Modèle semi-formel du domaine "la famille"

On peut y lire qu'une famille est composée de Parent et d'Enfant. Le Père et la Mère sont des Parents, de même, le Fils et la Fille sont des Enfants. On y lit aussi que la mère a la propriété estMèreDe Fils et de Fille. Quant à lui, le père a la propriété estPèreDe Fils et de Fille.

Dans une autre partie du modèle de la figure 16, les individus pierre, andré, sophie et marie sont associés par instanciation aux concepts Père, Fils, Mère et Fille.

Figure 16: Modèle semi-formel du domaine "la famille"

incluant des faits Pour présenter les ontologies, nous avons choisi d'utiliser le logiciel d'édition d'ontologies Protégé [26]. De mode semi-graphique, Protégé présente les taxonomies de classes sous la forme d'arbre de composites. La figure 17 présente une partie du métamodèle de MOT. On y distingue les deux métaclasses principales (Connaissance et Relation) ainsi que les sous-métaclasses identifiées à la section 4.

Figure 17: Représentation dans Protégé de l'ontologie du

métamodèle MOT Protégé permet aussi la présentation d'individus de l’ontologie. À la figure 18, on voit la représentation des éléments du modèle MOT. L'individu focalisé représente l'élément du modèle qui sert à représenter le Fait(pierre).

Tableau 2: Règles de transformation de représentation MOT en représentation DL

Figure 18: Représentation dans Protégé de l'ontologie du

modèle MOT La figure 19 présente l'ontologie de domaine produite à partir du processus de transformation. On y retrouve des aperçus de la structure taxonomique représentée dans le modèle MOT. On peut distinguer qu'une famille est composée, de manière nécessaire et suffisante, de Parents et d'Enfants.

Figure 19: Représentation dans Protégé du concept Famille

dans l'ontologie de domaine La figure 20 présente le résultat de la transformation du Fait marie indiquant que marie est un individu de la classe Fille dans l'ontologie de domaine

Figure 20: L'individu « marie » dans l'ontologie de domaine

Le lien de composition (LienC) appartenant à la sémantique de MOT n'a pas de représentation directe en OWL. La solution choisie est de créer la propriété estComposeDe dont le Domaine et le Codomaine correspondent respectivement au Concept source et

au Concept destination, désignée par le LienC. La figure 21 présente en OWL la représentation du LienC qui unit le Concept Famille et le Concept Parent. On remarque que le Domaine et le Codomaine font référence respectivement à la Classe Famille et à la Classe Parent.

Figure 21: Propriété estComposeDe représentant le LienC

9. CONCLUSION À l'heure actuelle, le processus de transformation est assumé par une application Java et nous en sommes à implanter une version prenant la forme d'un système expert dont la base de connaissances est une ontologie de transformation qui devra être développée plus avant.

Les règles de transformation présentées au tableau 2 concernant la transformation de connaissances de type déclaratif restent à développer pour des connaissances procédurales, stratégiques ou factuelles.

Dans le but de construire un outil informatique intelligent pour la formalisation de modèles semi-formels en ontologies, nous avons émis l'hypothèse que par l'utilisation des technologies associées à l'ACM, il est possible de concevoir un système expert à la transformation. Dans le processus incrémental de conception d'une ontologie, le système expert supporte l'ingénieur dans sa tâche de transformation de modèles semi-formels en ontologies.

Par une application spécifique de l'ACM dédiée à la transformation de modèles semi-formels MOT en ontologie OWL, nous avons présenté une architecture dont le système expert est doté d’une base de connaissances composée d'une ontologie du métamodèle MOT et d'une base de règles de transformation en langage SWRL.

Finalement, des résultats préliminaires prometteurs valident l'architecture et l'énoncé des règles.

10. BIBLIOGRAPHIE [1] H. Kadima, MDA: Conception orientée objet guidée par les

modèles, Paris: Dumond, 2005. [2] D. Gašević, D. Djurić, and V. Devedžić, "The Model Driven

Architecture (MDA)," Model Driven Architecture and Ontology Development, pp. 109-126, 2006.

[3] D. Gašević, D. Djurić, and V. Devedžić, "Modeling Spaces," Model Driven Architecture and Ontology Development, pp. 127-141, 2006.

[4] Object Management Group. "Documents associated with Meta Object Facility (MOF) 2.0 Query/View/Transformation, v1.0 "; http://www.omg.org/spec/QVT/1.0/.

[5] Object Management Group. "Object Constraint Language Specification, version 2.0," http://www.omg.org/technology/documents/formal/ocl.htm.

[6] M. Uschold, and M. Gruninger, “Ontologies: Principles, Methods and Applications,” Knowledge Engineering Review, vol. 11, no. 2, pp. 69, June 1996, 1996.

[7] T. R. Gruber, “A translation approach to portable ontology specification,” Knowledge Acquisition, vol. V. 5, no. 2, pp. pp. 199-220 1993, 1993.

[8] J. Basque, G. Paquette, B. Pudelko et al., "Collaborative Knowledge Modeling with a Graphical Knowledge Representation Tool: A Strategy to Support the Transfer of Expertise in Organizations.," Knowledge Cartography. Mapping Techniques and Software Tools., A. Okada, S. B. Shum and T. Sherborne, eds., London: Springer-Verlag, 2008.

[9] G. Paquette, Modélisation des connaissances et des compétences, Montréal: Presses de l'Université du Québec, 2002.

[10] O. Corcho, M. Fernández-López, and A. Gómez-Pérez, "Ontological Engineering: Principles, Methods, Tools and Languages," Ontologies for Software Engineering and Software Technology, pp. 1-48, 2006.

[11] T. Berners-Lee. "Web Stack," http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html.

[12] J. Cardoso, "Programming The Semantic Web," Semantic Web Services, Processes and Applications, pp. 351-380, 2006.

[13] Jena Home Page. "Jena, A Semantic Web Framework for Java " 26 sept., 2006; http://jena.sourceforge.net/index.html.

[14] OMG ODM. "Ontology Definition Metamodel: OMG Adopted Specification," 26/05/2008; http://www.omg.org/spec/ODM/1.0/Beta2/PDF/.

[15] G. Paquette, and D. Rogozan, Correspondance avec le langage graphique MOT-OWL et le langage des prédicats du premier ordre, LICEF, Montréal, 2006.

[16] V. Haarslev, R. Möller, K. Hidde et al. "Racer; Renamed Abox and Concept Expression Reasoner," http://www.sts.tu-harburg.de/~r.f.moeller/racer/.

[17] E. Freidman-Hill, Jess in action; Rule-Based Systems in Java, Greenwich: Manning, 2003.

[18] Jess Home Page. "Jess: the Rule Engine for the JavaTM Platform," 27 mars, 2008; http://www.jessrules.com/jess/index.shtml.

[19] M. O’Connor, H. Knublauch, S. Tu et al. "Writing Rules for the Semantic Web Using SWRL and Jess," 29 mai, 2006; http://www.med.univ-rennes1.fr/~cgolb/Protege2005/SWRLJessOConnor.pdf.

[20] I. Horrocks, H. Boley, S. Tabet et al. "SWRL: A Semantic Web Rule Language Combining OWL and RuleML," 29 mai, 2006; http://www.w3.org/Submission/SWRL/.

[21] F. Baader, D. Calvanese, D. L. McGuinness et al., The Description Logic Handbook: Cambridge University Press, 2007.

[22] K. Bhoopalam, “Fire – A Description Logic Based Rule Engine for OWL Ontologies with SWRL-like Rules,” Faculty of Engineering and Computer Science, Concordia University, Montréal, 2005.

[23] E. Gamma, R. Helm, R. Johnson et al., Catalogue de modèles de conception réutilisables: Vuibert, 1999.

[24] C. Golbreich, "Combining Rule and Ontology Reasoners for the Semantic Web," Rules and Rule Markup Languages for the Semantic Web, pp. 6-22, 2004.

[25] C. Golbreich, and A. Imai. "Combining SWRL rules and OWL ontologies with Protégé OWL Plugin, Jess, and Racer," 29 mai, 2007; http://protege.stanford.edu/conference/2004/abstracts/Golbreich.pdf.

[26] Stanford Medical Informatics. "Protégé home page," 29 Mai, 2006; http://protege.stanford.edu/.