Fonction Sans représentation
explicite du méta-modèle Avec représentation explicite du méta-modèle
F1 - Définition du modèle logique de représentation des ontologies.
Définition manuelle du schéma (ou génération par programme externe)
− Définition de règles de représentation logique (R1) pour toute instance du méta-modèle (exemple: tout schéma XML pour OWL, ou tout modèle EXPRESS pour PLIB).
− Programme de génération qui interprète les instances du méta-modèle correspondant au modèle courant et met en œuvre (R1).
F2 - API à liaison
différée Tout le modèle doit être codé dans l’API (cf. algorithme 2) L’API devient un interprète des instances du méta-modèle (cf. algorithme 3) en exploitant (R1)
F3 - API à liaison
préalable Toute l’API doit être codée à la main
− Définition de règles génériques (R3) de représentation d’un modèle EXPRESS ou d’un schéma XML dans le langage cible (Par exemple java).
− Programme de génération interprétant le méta-modèle en exploitant (R1) et (R3)
F4-F5 - Lecture / extraction des concepts d’ontologie dans la BD
Ecriture d'un programme spécifique
− Des règles génériques (R2) de
représentation externe existent déjà (par exemple: document XML pour OWL, fichier d'instances EXPRESS pour PLIB)
− Programme générique qui interprète les instances du méta-modèle correspondant au modèle courant en exploitant (R1) et (R2)
2.6.1 Structure pour la représentation des modèles d’ontologies
La structure du méta-modèle nécessaire pour permettre la représentation des modèles d’on-tologies va dépendre du fait que le SGBD utilisé : (1) est un SGBD Objet, et (2) permet de représenter tous les mécanismes existant dans le formalisme de définition du modèle d’ontologie (par exemple, si besoin est, l’héritage multiple). Si ces deux conditions sont vérifiées, alors le méta-modèle préexiste en général dans le SGBD utilisé et s’identifie avec la méta-base du sys-tème. Dans les autres cas, il s’agit d’une partie nouvelle pour une base de données et qui est nécessaire dans une BDBO. Nous nommerons méta-schéma cette partie dans la suite de la thèse. Représenter le modèle d’ontologie dans la base de données sous forme d’instances d’un méta-modèle, peut se ramener à la problématique de définition de la structure de tables nécessaire pour la représentation d’ontologies. Ce point a été discuté à l’occasion de la fonction F1 (cf. section 2.1) :
– le méta-modèle est lui-même défini par un formalisme de modélisation orienté-objet comme le modèle d’ontologie,
– le modèle d’ontologie doit pouvoir se représenter comme un ensemble d’instances du méta-modèle, comme c’est le cas des ontologies pour le modèle d’ontologie,
– le méta-modèle et le modèle d’ontologie seront exprimés dans le même formalisme de mo-délisation (XML pour RDFS, OWL ou DAML+OIL, EXPRESS pour PLIB).
Dans le cas de la fonction F1, nous avons préconisé d’utiliser les techniques de correspondance objet-relationnel pour la définition de la structure des tables permettant la représentation des ontologies. Vu que le méta-modèle est défini dans le même formalisme que le modèle d’ontologie, on pourrait envisager d’utiliser la même technique pour définir la structure de tables permettant la représentation des modèles ontologie dans la base de données.
Notons que si le formalisme utilisé pour définir le modèle d’ontologie et le méta-modèle est le même, alors le même code générique pourra être réutilisé pour la mise en œuvre des mêmes besoins concernant les modèles d’ontologies. Ceci s’applique aux fonctions F1 (pour définir des tables), F2 et F3 (pour accès aux modèles d’ontologies), F4 (pour lire les modèles d’ontologies). Nous présentons, dans la figure 3.7a, un exemple simplifié de méta-modèle UML. La figure 3.7b présente la représentation du modèle d’ontologie de la figure 3.1b dans des tables issus du méta-modèle UML de la figure 3.7a par transformation objet-relationnel en utilisant les règles de correspondance définies dans l’exemple 1 (cf. section 2.1).
Notons que la représentation du modèle d’ontologie dans la base de données offre la possi-bilité de représenter au sein d’une même base de données plusieurs ontologies issues de modèles d’ontologies différents. Il suffit dans ce cas d’appliquer sur chacun des modèles d’ontologies, les traitements mis en oeuvre pour le déploiement d’un modèle d’ontologie particulier (PLIB) sur la BDBO OntoDB. Ceci n’est néanmoins possible que sous deux conditions :
1. Tous les modèles d’ontologies doivent être définis dans un même et unique formalisme de modélisation (celui sur lequel les programmes de déploiement se basent). Pour le proto-type que nous avons implémenté, le formalisme utilisé fut le langage EXPRESS [143].
2. Analyse de besoins et propositions pour la représentation des ontologies
UML_class
OID name superclasses abstract
1 class false
2 property true
3 data_property 2 false
4 object_property 2 false
UML_attribute
OID name of_class is_of_type …
5 name 1 10 6 name 2 11 7 value_type 3 12 UML_data_type OID name 10 String 11 String 12 String UML_relation
OID name source target s_min s_max t_min t_max
8 properties 1 2 1 1 0 null 9 superclass 2 1 0 1 0 null 21 target_class 4 1 1 1 0 null U UMMLL__ccllaassss n naammee::ssttrriinngg U UMMLL__aattttrriibbuuttee n naammee::ssttrriinngg a abbssttrraacctt::bbooooll U UMMLL__ttyyppee U UMMLL__ddaattaa__ttyyppee s suuppeerrccllaasssseess * * * * * * o off__ccllaassss 1 1 i iss__ooff__ttyyppee 1 1 1 1....** c caarrdd__mmiinn__ssoouurrccee::iinntt c caarrdd__mmiinn__ttaarrggeett::iinntt c caarrdd__mmaaxx__ssoouurrccee::iinntt c caarrdd__mmaaxx__ttaarrggtt::iinntt U UMMLL__rreellaattiioonn ssoouurrccee 1 1 * * * * t taarrggeett 11 (a) (b)
Fig. 3.7 – (a) Un exemple de méta-modèle d’ontologie et (b) son utilisation pour représenter le modèle de la figure 3.1b.
Par exemple, supposons que nous souhaitons créer/insérer des ontologies PLIB, RDF Schema, DAML+OIL et OWL dans OntoDB, alors les modèles d’ontologies RDF Schema, DAML+OIL, OWL doivent être "re-modélisés"’ dans le formalisme EXPRESS.
2. Pour pouvoir importer des ontologies RDF Schema, DAML+OIL, OWL, un convertisseur, i.e., un programme, qui servira à faire migrer les ontologies dans leur format d’origine (XML pour RDF Schema, DAML+OIL, OWL) dans le format d’instances du formalisme sur lequel se base les programmes de déploiement, doit être défini. Dans notre prototype, ce sera donc des instances de fichiers physiques EXPRESS [79].
Cette approche automatique a néanmoins l’inconvénient de ne pas factoriser les éléments communs de tout modèle d’ontologie (i.e., les classes, les propriétés et les types). Une autre approche possible consiste à étendre manuellement, dans le langage OntoQL (cf. section 4.2.5 du chapitre 4) le modèle d’ontologie existant (PLIB) pour y introduire de nouvelles spécifications. Dans la section qui suit, nous discuterons de la représentation des instances dans la base de données à base ontologique.
2.6.2 Méta-schéma réflexif
Les exigences existant jusqu’alors sur le méta-schéma, étaient d’être capable de représenter l’ensemble des variantes des modèles d’ontologies envisagés. Si nous imposons alors au méta-schéma d’être, de plus, réflexif, c’est-à-dire de pouvoir se représenter lui-même, on pourra re-présenter le méta-modèle lui-même comme instance de sa propre structure (cf. figure 3.8). Nous illustrons ci-dessous le besoin de représenter ainsi le méta-modèle dans la base de données à travers un exemple.
Reprenant le méta-modèle de la figure 3.7a et supposons que nous souhaitons appliquer une action spécifique suivant le type d’un attribut d’une classe de l’ontologie. Soit oidatt, l’oid de l’attribut représenté en tant que UML_attribute. Dans l’exemple suivant, nous présentons un extrait de programme qui fait appel à quelques fonctions de l’API à liaison différée (cf. section 2.2). Le fragment de programme de l’algorithme 10 vise à exécuter une action spécifique suivant le type d’un attribut.
La fonction get_final_type est sensée donner le type (i.e., le domaine de valeur) de l’attribut ayant l’oid oidattqui doit normalement être l’une des sous-classes de UML_type : UML_data_type, UML_relation ou UML_class. On devrait donc dans tous les cas, faire des requêtes sur chacune des tables UML_data_type et UML_relation et UML_class pour déterminer dans laquelle le type se trouve. La question qui se pose est donc comment déterminer ces tables ?
Deux solutions sont possibles :
– soit on code tout le méta-modèle dans la fonction. Dans ce cas, le corps de la fonction get_final_type se présentera comme dans l’algorithme 11.
Le corps de la fonction get_final_type peut être écrit manuellement mais nécessitera mal-heureusement de décrire toutes les hiérarchies des entités du modèle dans celui-ci.
2. Analyse de besoins et propositions pour la représentation des ontologies
Algorithme 10 Exécution d’une action spécifique suivant le type d’un attribut.
...
oidi :=get_value_attribute(oidatt,"UML_attribute","is_of_type") IF get_final_type (oidi, "UML_type") == "UML_data_type THEN"
doSomeThing ... ELSE ...
IF get_final_type (oidi, "UML_type") == "UML_relation THEN" doSomeThing ...
ELSE ...
IF get_final_type (oidi, "UML_type") == "UML_class THEN" doSomeThing ...
END IF ; ...
Algorithme 11 Codage du méta-modèle dans la fonction get_final_type.
FUNCTION get_final_type : oid x nom_entité -> nom_entité ; ...
IF nom_entité = ’UML_Type’ THEN ExecQuery :
SELECT "UML_data_type" FROM UML_data_type WHERE OID = oid
UNION
SELECT "UML_relation" FROM UML_relation WHERE OID = oid
UNION
SELECT "UML_class" FROM UML_class WHERE OID = oid
IF nom_entité = ’UML_XXX’ THEN ...
– Soit en représentant toutes les entités méta-modèle sous forme d’instances dans les tables du méta-schéma (cf. figure 3.8). Ainsi celles-ci pourront être parcourues pour déterminer toutes les sous-classes de la classe UML_type. Grâce à la représentation du méta-schéma dans la base de données, l’on pourra utiliser l’API à liaison différée définie précédemment (cf. section 2.2) dans l’écriture de la fonction get_final_type peut être réalisé comme dans l’algorithme 12.
Algorithme 12 Codage de la fonction get_final_type en accédant au méta-schéma.
FUNCTION get_final_type : oid x nom_entité -> nom_entité ; BEGIN
...
Retrouver l’oid de l’instance de UML_class qui pour nom "nom_entité" dans la table UML_class. soit oidclass
// On récupère toutes les sous-classes de la classe dont l’oid est donné en paramètre. Array subclasses := used_in(oidclass,’UML_class’,’superclasses’) ;
// On parcourt toutes les classes récupérées FOREACH c IN subclasses DO
On génère la requête de l’algorithme 11 END FOREACH ;
On exécute la requête générée. ...
END FUNCTION ;
UML_class
OID name superclasses abstract
1 class false 2 property true 3 data_property 2 false 4 object_property 2 false 13 UML_type true 14 UML_class 13 false 15 UML_data_type 13 false 16 UML_attribute false 21 UML_relation 13 false UML_attribute
OID name of_class is_of_type …
5 name 1 10 6 name 2 11 7 value_type 3 12 17 name 13 20
UML_relation
OID name source target s_min s_max t_min t_max
8 properties 1 2 1 1 0 null 9 superclass 2 1 0 1 0 null 21 target_class 4 1 1 1 0 null 18 is_of_type 16 13 1 1 0 null 19 of_UML_class 16 14 1 1 0 null UML_data_type OID name 10 String 11 String 12 String 20 String
Fig. 3.8 – Auto-représentation du méta-modèle réflexif.
L’autoreprésentation du méta-modèle réflexif au sein de sa propre structure constitue donc un avantage significatif pour l’écriture de programmes plus simple. L’accès à un niveau "méta" en base de données pouvant avoir pour effet de ralentir les programmes, il convient de noter que la représentation explicite du méta-modèle dans la base de données n’empêche pas d’optimiser