Comme pour la représentation des ontologies, deux approches principales ont été suivies pour repré-senter les données, l’une dépendant des ontologies stockées dans une BDBO et l’autre non.
4.3.1 Représentation générique
Deux propositions de représentation, indépendantes des ontologies stockées, ont été faites. La pre-mière, qualifiée de verticale, consiste en une table à trois colonnes (sujet, prédicat, objet) où l’ensemble des informations de niveau données (instances des classes et valeurs de propriétés) est dé-composé en triplets. Dans cette représentation, chaque instance i d’une classe est définie par les triplets suivants :
– les triplets (i, rdf:type, C) qui permettent d’indiquer les classes auxquelles l’instance i ap-partient ;
– les triplets (i, propriété, valeur) qui permettent de caractériser l’instance en lui assignant des valeurs de propriétés.
L’approche verticale est en particulier suivie par les BDBO Jena, 3Store et RStar.
Exemple. La figure 1.9 présente une représentation verticale d’instances de la classe Post.
Triplet
sujet prédicat objet
http://lisi.../post-sioc rdf:type http://rdfs.org/sioc/ns#Post http://lisi.../post-sioc http://rdfs.org/sioc/ns#title Creating connections … http://lisi.../post-sioc http://rdfs.org/sioc/ns#has_container http://lisi.../weblog http://lisi.../post-sioc http://rdfs.org/sioc/ns#has_creator http://lisi.../author/cloud http://lisi.../post-sioc http://rdfs.org/sioc/ns#content SIOC provides a unified … http://lisi.../post-sioc http://rdfs.org/sioc/ns#has_reply http://lisi.../comment-928
… … …
F. 1.9 – Représentation verticale des données décrites par l’ontologie SIOC
instance de la classe Post. Les triplets suivants décrivent cette instance par des valeurs pour les propriétés title, has_container, has_creator, content et has_reply.
La seconde approche qualifiée de binaire consiste à utiliser une table unaire par classe pour repré-senter les instances de cette classe et une table binaire par propriété pour reprérepré-senter les valeurs de propriétés des instances. Ainsi, les deux types de triplets identifiés dans la représentation verticale sont séparés. Les triplets indiquant le type des instances sont représentés dans les tables unaires qui corres-pondent aux classes des ontologies et les triplets indiquant la valeur des propriétés sont représentées dans les tables binaires qui correspondent aux propriétés des ontologies. L’approche binaire est suivie par Sesame, RDF-Suite, DLDB et PARKA.
Exemple. La figure 1.10 présente une représentation binaire d’instances de la classe Post.
Post URI
http://lisi.../post-sioc
Title
sujet objet
http://lisi.../post-sioc Creating connections … Has_container sujet objet http://lisi.../post-sioc http://lisi.../weblog Has_creator sujet objet http://lisi.../post-sioc http://lisi.../author/cloud
F. 1.10 – Représentation binaire des données décrites par l’ontologie SIOC
Explication. La représentation binaire comporte 4 tables. La table Post permet de stocker les instances de la classe du même nom. L’appartenance de la ressource dont l’URI se termine par post-sioc à cette table permet ainsi d’indiquer que cette ressource appartient à la classe Post. Les autres tables permettent de stocker les valeurs des propriétés title, has_container et has_creator. Par exemple, la présence du tuple (post-sioc, weblog) dans la table title indique que cette instance à la valeur weblog pour la propriété title.
Que ce soit dans la représentation verticale ou binaire, une instance donnée ayant un certain nombre de propriétés est décomposée en plusieurs tuples dans différentes tables (approche binaire) ou dans la table de triplets (approche verticale). Ces instances sont ainsi directement liées à une ontologie sans être structurées par un schéma significatif pour un utilisateur de la base de données. La notion de schéma de données au sens usuel des bases de données classiques n’est donc pas présente. Ces choix de stockage qui reviennent à décomposer chaque instance en la séparant de ses valeurs de propriétés sont dictés par
la souplesse de représentation des données à base ontologique que permettent les langages de définition d’ontologies RDF-Schema et OWL. Les instances dans ces langages ne sont pas fortement typées. Elles peuvent appartenir à un nombre quelconque de classes non liées par la relation de subsomption et peuvent même initialiser des propriétés non définies dans le contexte de leurs classes.
Néanmoins, dans bien des cas, les instances d’une ontologie RDF-Schema ou OWL respectent des hypothèses de typage : elles appartiennent à une seule classe de base et n’ont une valeur que pour les propriétés définies sur cette classe. C’est par exemple, le cas des applications qui se basent sur les données et les schémas d’une base de données pour construire des ontologies OWL et leurs instances [de Laborda and Conrad, 2006]. Dans ce cas, la représentation des données à base ontologique peut se rapprocher de la structure relationnelle. C’est ce que proposent les approches de représentation présentées dans la section suivante.
4.3.2 Représentation spécifique
Les BDBO OntoMS et OntoDB proposent une représentation des données à base ontologique dé-pendant de l’ontologie qui décrit ces données. Cette représentation consiste à stocker les instances d’une classe ainsi que ses valeurs de propriétés dans une table relationnelle. Elle est ainsi qualifiée de repré-sentation horizontale. La table associée à une classe possède une colonne pour chaque propriété utilisée pour décrire au moins une instance de cette classe. Lorsque qu’une propriété est multivaluée, ses valeurs peuvent être représentées soit en utilisant les types tableaux introduits dans SQL99 (approche suivie par OntoDB), soit en utilisant de nouvelles tables pour ces propriétés (approche suivie par OntoMS).
Exemple. La figure 1.11 présente une représentation horizontale d’instances de la classe Post.
Post
URI title has_container has_creator content has_reply post-sioc Creating connections … weblog cloud Sioc … comment-928
F. 1.11 – Représentation horizontale des données décrites par l’ontologie SIOC
Explication. La table Post permet de stocker l’ensemble des instances appartenant à la classe Post. Dans cet exemple, nous supposons que seules les propriétés URI, title, has_container, has_crea-tor, content et has_reply sont utilisées pour décrire les instances de cette classe. La table contient donc une colonne pour chacune de ces propriétés.
Les évaluations de performances menées sur OntoMS [Park et al., 2007] et OntoDB [Dehainsala et al., 2007a] ont montré que cette représentation permet d’obtenir les meilleurs temps de réponse pour la plupart des requêtes typiques sur les données. Les hypothèses permettant ce gain de performance sont explicitées dans [Dehainsala et al., 2007a]. Les données à base ontologique respectent des hypothèses de typage ontologique fort: (1) chaque instance appartient à exactement une classe, appelée sa classe de base, qui correspond à la classe minimum pour la relation d’ordre définie par la relation de subsomption (2) chaque propriété est définie dans le contexte d’une classe qui définit son contexte d’application (3) seules les propriétés applicables dans le contexte d’une classe peuvent être utilisées pour décrire les instances de cette classe.
Outre, le gain de performance obtenu, l’approche horizontale présente l’avantage de conserver la notion de schéma des données. En effet, dans cette représentation, les tables utilisées représentent ex-plicitement la structure des données. Cet aspect a été utilisé dans OntoDB pour permettre l’intégration automatique de bases de données en utilisant cette BDBO [Nguyen-Xuan, 2006]. L’exploitation de cette architecture pour résoudre d’autres problèmes de bases de données tels que la conception de modèles conceptuels ou l’indexation sémantique de bases de données est actuellement en cours.