Avant de présenter les résultats des tests réalisés, nous présentons les composantes du banc d’essai que nous avons utilisé : (1) la configuration de la machine des tests, (2) le serveur de bases de données, (3) le générateur d’instances des classes dans les bases de données (4) la structure des schémas de données selon les approches de représentation existantes et (5) les types de requêtes que nous avons considérés pour nos tests sur les différentes approches de représentation.
1.1 Description du banc d’essai
1.1.1 Présentation générale
Comme pour les bancs d’essai antérieurs réalisés sur le sujet [67, 69], nous avons utilisé une approche de génération d’instances de classe d’ontologies ce qui permettait de générer des conte-nus de taille et de structures diverses.
Par contre nous n’avons pas utilisé de générateurs existants, et ce pour deux raisons. D’abord la plupart des bancs d’essai existants [22, 67, 69] utilisent des ontologies RDF Schéma, DAML+OIL ou OWL et visent tout particulièrement à faire des inférences et à mesurer le degré de complétude des inférences. Compte tenu du fait que nous souhaitons mesurer les performances d’exécution de requêtes et que notre prototype est basé sur le modèle d’ontologie PLIB, l’utilisation de ces bancs d’essai n’était guère adaptée. La deuxième raison est que ceux-ci portent souvent sur des jeux de tests simples sans aucun lien avec la réalité. Or, un de nos domaines cibles est celui de la gestion des composants industriels. Dans ce domaine précisément, il existe des ontologies qui sont à la fois réelles et de grande taille que nous avons utilisées pour évaluer nos travaux.
Ce sont les deux raisons qui nous ont incitées à utiliser des ontologies PLIB et à programmer notre propre générateur. De plus, définir notre propre générateur, nous a permis de contrôler finement le volume de données générées et la structure des données manipulées. Les bases de
1. Évaluation des performances de la partie données données que nous manipulons sont caractérisées par :
1. un nombre variable de classes,
2. un nombre variable de propriétés par classe, 3. un nombre variable d’instances par classe.
Ceci permettra de couvrir des domaines d’application divers caractérisés par le fait, d’une part, qu’ils manipulent des ontologies ayant des structures diverses, et, d’autre part, que les popu-lations d’instances sont elles aussi diverses. L’avantage de notre approche est de nous permettre d’utiliser une ontologie réaliste : l’ontologie de référence IEC 61360-4 qui décrit l’ensemble des composants électroniques ainsi que leurs propriétés caractéristiques. Elle est normalisée au ni-veau international à l’IEC19 (International Electronic Commision).
Dans la littérature, plusieurs critères d’évaluation des approches de représentation ont été proposées [157]. On peut ainsi citer : (1) le temps de chargement des bases de données, (2) la taille des bases de données et (3) le temps de réponse d’exécution de requêtes. Dans notre travail, nous évaluons les performances de ces approches selon le critère le temps de réponse des requêtes. Remarquons que les résultats obtenus sur nos ontologies PLIB semblent raisonnablement ex-trapolables à d’autres domaines. En effet, dans [104], on trouve une étude quantitative d’une tren-taine d’ontologies réalistes définies en RDF Schéma dans des domaines très variés (e-commerce, géospatial, éducation, biologie, médecine, etc.). Les auteurs ont constaté que ces constructions non supportées par PLIB ou non utilisées dans nos données de test étaient en fait peu utilisées. – Subsomption de propriétés. Très peu d’ontologies hiérarchisent des propriétés (SubPro-pertyOf ). Dans les rares cas où cela est utilisé, c’est dans un but très limité afin d’établir une relation sémantique (composition ou agrégation) entre des classes et non dans un but de caractérisation d’instances.
– La multi-instanciation. La multi-instanciation n’est pas utilisée dans la majorité des ontologies20.
– Co-domaine. Les types collections (Sequence, Bag, Alternative) non utilisées dans nos données de test ne sont pas non plus utilisés dans la plupart des ontologies étudiées. D’après cette étude, il semble donc que bon nombre d’ontologies définies dans le cadre du Web Sémantique pourraient être représentées dans OntoDB sans perte d’information et que les résultats de nos essais leur seraient également applicables.
1.1.2 Choix des approches alternatives à évaluer
Les approches table par propriété, triplets et table universelle ont déjà fait l’objet d’une éva-luation dans d’autres travaux [5, 24, 42, 58, 156, 157]. En particulier, Agrawal et al. [5] ont montré, sur un domaine similaire au notre à savoir celui du commerce électronique que les ap-proches de représentation par table par propriété et triplets étaient beaucoup plus performantes
19
http://dom2.iec.ch/iec61360?OpenFrameset
20
Ils précisent toutefois dans leur article qu’ils n’ont pas trouvé une quantité significative de population d’ins-tances d’ontologies.
que l’approche par table universelle. Compte tenue de la complétude de ces tests, il nous parait inutile de nous intéresser à nouveau à la table universelle.
Theoharis et al. [157] ont montré, en testant différent types de requêtes que l’approche table par propriété était plus performante que l’approche triplets. Nous confirmerons ce fait sur quelques tests, puis nous nous concentrerons donc sur la comparaison table par classe d’une part, et table par propriété, d’autre part, puisqu’il s’agit de la plus efficace des approches préexistantes. 1.1.3 Description du générateur d’instances
Notre générateur se base donc sur une ontologie PLIB réelle : l’ontologie IEC 61360-4 :1998. Cette ontologie décrit les composants usuels dans le domaine de la conception électronique ainsi que toutes les propriétés techniques qui les caractérisent. IEC 61360-4 est constituée de 190 classes et 1026 propriétés. La profondeur de la hiérarchie de classes est en moyenne de cinq classes et elle comporte 134 classes feuilles. Pour contrôler plus facilement la taille effective des bases de données, nous avons modifié tous les co-domaines des propriétés de l’ontologie en des chaînes de 255 caractères (soit 255 octets).
Nous avons programmé un générateur (cf. figure 5.1) qui permet de créer des populations d’instances pour les classes de l’ontologie de IEC 61360-4 représentée dans la base de données. Celui-ci est programmé indépendamment d’une ontologie particulière. Il reçoit en entrées une ontologie PLIB quelconque et trois autres paramètres de configuration de la base de données à générer : (1) le nombre de propriétés (NP) à initialiser pour chaque classe, (2) le nombre d’instances (NI) à générer, et (3) le type de représentation choisi pour les instances : table par propriété, triplets ou table par classe. La génération d’instances se réalise en deux étapes :
(1) Une première étape construit le modèle conceptuel (MC) de la base de données, puis génère les schémas de tables en fonction du type de représentation choisi. Pour chaque classe, NP propriétés sont sélectionnées de façon aléatoire dans les propriétés applicables de chaque classe.
(2) La deuxième étape génère les NI instances de la table de classes.
Nous avons généré différentes bases de données en faisant varier le nombre de propriétés (NP) et le nombre d’instances (NI) par classe. dans le reste du chapitre, nous noterons par :
– TC : l’abréviation de l’approche Table par Classe, – TP : l’abréviation de l’approche Table par Propriété,
– BD_<NombreInstances>K_<NombreProprietes>P : un contenu de base de données gé-nérée contenant NombreInstanceK instances par classe et NombrePropriété propriétés pour chacune de ces classes. Par exemple : BD_10K_10P est un contenu de base de données ayant 10K instances et 10 propriétés par classe et qui sera générée pour chacun des types de représentation d’instances que nous souhaitons évaluer.
Comme cela apparaît dans les figures 5.2 et 5.3, nous avons créé 6 populations d’instances différentes se divisant en deux séries.
1. Évaluation des performances de la partie données
Ontologie MC
(1) Génère le modèle conceptuel et le modèle logique à partir de NP et du type de représentation souhaité (2) Génère les populations d’instances des classes à partir
du MC et de NI (1) (2) Ontologie Ontologie Générateur d’instances Paramètres •Nombre de propriétés/Classe (NP) •Nombre instances/Classe (NI) •Type de représentation
Fig. 5.1 – Générateur d’instances du banc d’essai
différentes représentations. Nous avons les bases de données : BD_1K_10P, BD_1K_25P et BD_1K_50P. Ces bases de données sont caractérisées par un nombre fixe d’instances (1K) et avec un nombre croissant de propriétés dans chaque table de classe.
BD_1K_10P BD_1K_25P BD_1K_50P
Nombre de propriétés par classe feuille (NP) 10 25 50
Nombre d'instances par classe feuille (NI) 1K 1K 1K
Nombre de classe feuille 134 134 134
Nombre total d'instances dans la BD 134K 268K 134K
Volume des bases de données 341 MO 0,84GO 1,68GO
Fig. 5.2 – Caractéristiques des bases de données du banc d’essai pour les tests de passage à l’échelle
2. Serie 2 : La deuxième série (cf. figure 5.3) nous permet d’étudier l’impact de la variation du nombre de propriétés (N P ) et du nombre d’instances (N I) des tables des classes, tel que le produit N P × N I est constant. Nous avons les bases de données : BD_10K_10P, BD_4K_25P et BD_2K_50P. Le nombre d’instances varie entre 100.000 et 1,5 millions environ.
1.1.4 Configuration de la machine des tests Nous décrivons le serveur et la machine de nos tests : 1. Serveur de base de données
– PostgreSQL-7.4 émulé sur cygwin21 – taille du buffer : 50MO
21