Modèle de stockage des ontologies

Le problème de représentation des ontologies dans une base de données consiste à définir l’ensemble des tables nécessaires pour stocker les concepts ontologique et leurs relations. Dans la littérature, deux approches principales ont été proposées : la représentation générique et la représentation spécifique.

5.1.1.1 Représentation générique. Cette représentation appelée aussi représentation

verti-cale utilise une unique table à trois colonnes (sujet, prédicat, objet) dite table de triplets pour

stocker l’ontologie. Cette représentation est générique par rapport au modèle d’ontologie. En effet, l’ontologie est donc décomposée en un ensemble de triplets. Chaque élément E d’une ontologie est défini par des triplets de l’une des formes suivantes :

Université ^{sousOrganisationDe Département} personne Etudiant Salarié membreDe subclassof subclassof DiploméDe

ID3 ^{sousOrganisationDe ID2 membreDe ID1 ID4} DiploméDe

type Valeur de propriété Propriété Légende : ^{Classe ou} instance I n s t a n c e s O n t o l o g i e

Figure 1.6 – Fragment de l’ontologie LUBM

– la forme (E, rdf:type, entité) : ces triplets permettent d’indiquer le type de l’élément. Ce type est une des entités définies en RDF-Schéma comme par exemple rdfs:Class ou

rdfs:Property ;

– la forme (E, attribut, valeur) : ces triplets permettent de caractériser les éléments définis en leur assignant des valeurs d’attributs RDF-Schéma comme par exemple rdf:label ou

rdf:comment. Exemple 1

Soit le fragment de l’ontologie LUBM présenté sur la figure 1.6. Sa représentation générique est présentée sur la figure 1.7.

5.1.1.2 Représentation spécifique. Cette représentation dépend du modèle d’ontologies supporté. Elle consiste à représenter le modèle d’ontologies en utilisant le modèle

relation-nel ou relationrelation-nel-objet supporté par le SGBD sous-jacent à la BDBO. Le schéma de tables

est défini de façon ad hoc (non systématique) d’une implémentation à une autre. Il est fonction des détails des informations qu’on veut capturer et du lien établi avec la partie concernant les

données. ChaqueBDBO définit son propre schéma en fonction des concepts du modèle

d’onto-logies qu’elle supporte. Pour une ontologie RDFS, le schéma contient généralement les tables ;

class, subclass, domain, range, property, subproperty.

Cette représentation est adoptée par lesBDBO Sesame, RDFSuite, RSTAR, OntoDB,

On-toMS, DLDB, PARKA et KAON. La représentation spécifique de notre fragment d’ontologie de la figure 1.6 est illustrée par la figure 1.8

Dans cet exemple, la représentation comporte les tables Class, Property et Subclass. La table

sto-Triplet

sujet prédicat objet

http://lias.fr#Université rdf:type rdfs:Class http://lias.fr#Département rdf:type rdfs:Class http://lias.fr#Personne rdf:type rdfs:Class http://lias.fr#Etudiant rdf:type rdfs:Class http://lias.fr#Salarié rdf:type rdfs:Class

http://lias.fr#Etudiant rdfs:suclassOf http://lias.fr#Personne http://lias.fr# Salarié rdfs:suclassOf http://lias.fr#Personne http://lias.fr#estMembreDe rdf:type rdf:Property

http://lias.fr#estMembreDe rdfs:domain http://lias.fr#Etudiant http://lias.fr#estMembreDe rdfs:range http://lias.fr#Département http://lias.fr#sousOrganisation

De

rdf:type rdf:Property

http://lias.fr# Université rdfs:comment C’est une université de ...

… … …

Triplet

sujet prédicat objet

http://lias.fr#Université rdf:type rdfs:Class http://lias.fr#Département rdf:type rdfs:Class http://lias.fr#Personne rdf:type rdfs:Class http://lias.fr#Etudiant rdf:type rdfs:Class http://lias.fr#Salarié rdf:type rdfs:Class

http://lias.fr#Etudiant rdfs:suclassOf http://lias.fr#Personne http://lias.fr# Salarié rdfs:suclassOf http://lias.fr#Personne http://lias.fr#estMembreDe rdf:type rdf:Property

http://lias.fr#estMembreDe rdfs:domain http://lias.fr#Etudiant http://lias.fr#estMembreDe rdfs:range http://lias.fr#Département http://lias.fr#sousOrganisation

De

rdf:type rdf:Property

http://lias.fr# Université rdfs:comment C’est une université de ...

… … …

Figure 1.7 – Représentation générique du fragment d’ontologie LUBM

Class

Id URI label comment

1 http://lias.fr#Université Université C’est une université de ... 2 http://lias.fr#Département Département

3 http://lias.fr#Personne Personne 4 http://lias.fr#Etudiant Etudiant 5 http://lias.fr#Salarié Salarié

Class

Id URI label comment

1 http://lias.fr#Université Université C’est une université de ... 2 http://lias.fr#Département Département 3 http://lias.fr#Personne Personne 4 http://lias.fr#Etudiant Etudiant 5 http://lias.fr#Salarié Salarié … … SubClassOf sub sup 4 3 5 3 … … SubClassOf sub sup 4 3 5 3 Property

id URI comment domain range

11 http://lias.fr#estMembreDe appartenance ... 4 2 12 http://lias.fr#sousOrganisationDe Sous-organe 2 1

Property

id URI comment domain range

11 http://lias.fr#estMembreDe appartenance ... 4 2 12 http://lias.fr#sousOrganisationDe Sous-organe 2 1

cker l’identifiant externe d’une classe. Afin d’optimiser les traitements, un identifiant interne à la base de données (id) est également associé aux classes. Cette table permet également de sto-cker les noms (label) associés aux classes. Notons que si nous souhaitons associer plusieurs noms et/ou plusieurs commentaires à une même classe, la normalisation de cette table néces-site de définir deux nouvelles tables pour stocker ces informations. La table Property stocke les propriétés. Comme les classes, les propriétés sont associées à un identifiant interne (id) et externe (URI) et à des noms (label) et des commentaires (comment). Le domaine (domain) et co-domaine (range) des propriétés sont également spécifiés dans cette table par de références aux classes. La table SubClassOf permet de stocker la hiérarchie des classes en indiquant pour chaque classe ses superclasses.