Après avoir étudié les méthodes de transformation de thésaurus, nous allons maintenant
nous intéresser aux méthodes de transformation des bases de données. Notre volonté
étant de réutiliser des sources non-ontologiques existant sur le Web, il nous est apparu
important de considérer les bases de données au vu de leur place centrale dans les
systèmes d’informations actuels. Cette section décrit et analyse les méthodes permettant la
transformation d’une base de données (structure et contenu) en une base de connaissances.
L’étude de la littérature sur ce domaine a fait apparaître deux familles de techniques :
— Transformation par règles
— Transformation par un langage intermédiaire
1.2.1. Transformation par règles
Cette famille de méthodes propose de définir des règles permettant d’identifier les actions
pour la transformation. Nous pouvons par exemple définir que toutes les tables deviennent
des classes dans l’ontologie finale. Les travaux [Sequeda et al., 2011b, Astrova, 2004,
Tirmizi et al., 2008,Cerbah, 2008,Arenas et al., 2012] appliquent ce principe de règles
de transformation. D’après l’étude [Sequeda et al., 2012], les travaux les plus aboutis
sont ceux présentés dans [Tirmizi et al., 2008] grâce à la complétude des règles définies.
Cette complétude est étudiée en fonction des caractéristiques des bases de données
prises en compte par les règles. Il a été montré dans [Sequeda et al., 2011b] que les
travaux présentés dans [Tirmizi et al., 2008] respectent cette complétude, contrairement
aux autres travaux de l’état de l’art.
Nous pouvons remarquer que cette famille de méthodes est similaire à la définition de
patrons de transformation présentés dans [Villazon-Terrazas et al., 2010].
Règles de transformations [Tirmizi et al., 2008] Les travaux de [Tirmizi et al., 2008]
définissent six règles pour transformer une base de données relationnelle. Ces six règles
sont définies de la façon suivante :
Régle 1 : détecte une table binaire qui servira à la mise en place des règles suivantes.
Ce type de table spécifie une relation entre deux autres tables. Elle ne contient donc
que deux attributs (ou ensembles d’attributs) qui sont des clefs étrangères vers
deux autres tables. Elle ne contient aucune autre clef étrangère ou autre attribut.
Elle permet donc de spécifier les relations [0..n] entre deux tables.
Règle 2 : pose la condition selon laquelle si une table n’est pas une table binaire,
alors une classe OWL est créée.
Règle 3 : définit la génération d’une propriété d’objet entre deux classes s’il existe
une table binaire définissant une relation entre les deux tables qui ont servi à la
création des deux classes.
Règle 4 : est composée de plusieurs sous-règles pour définir les propriétés
(Object-Property) provenant de clefs étrangères mais sans tables binaires :
Règle 4.a : conduit à la définition d’une propriété fonctionnelle s’il existe une
clef étrangère vers une table non binaire sans la contrainte NOT NULL, ni
UNIQUE.
Règle 4.b : est la même que laa, seulement avec la contrainte NOT NULL sur la
clef étrangère. Cette contrainte ajoute le fait que la cardinalité de la propriété
est forcément égale à 1. Chaque instance de cette classe aura nécessairement
cette relation.
Règle 4.c : est la même que la a, avec la contrainte UNIQUE. Cette contrainte
ajoute le fait que la propriété inverse est aussi fonctionnelle.
Règle 4.d : est la même que laa, avec les contraintes NOT NULL et UNIQUE.
Les cardinalités de la propriété générée et de son inverse sont égales à 1.
Règle 5 : définit les conditions pour la génération de propriétés de type de données
avec plusieurs sous-règles :
Règle 5.a : indique que tout attribut qui n’est pas une clef étrangère sera traduit
par une propriété de données. Cette propriété de données est fonctionnelle en
raison de la structure des attributs dans les bases de données.
Règle 5.b : est la même que laaavec la condition NOT NULL. Celle-ci ajoute la
cardinalité 1 à la propriété de données.
Règle 5.c : est la même que laaavec la condition CHECK. Cette condition ajoute
le fait que la valeur de la propriété de données doit être dans la liste définie en
base de données.
Règle 6 : définit les conditions nécessaires pour la génération d’une relation de type
"subClassOf" (spécialisation) entre deux classes de l’ontologie. Il faut pour cela que
deux tables soient reliées par une clef étrangère qui est aussi considérée comme clef
primaire de la table source.
Les travaux présentés dans [Tirmizi et al., 2008] présentent quatre propriétés qui
doivent être respectées pour que les règles définies permettent une transformation
consi-dérée comme valide :
Conservation des informations : Possibilité de transformer la base de connaissances
générées pour retrouver la base de données initiale.
Conservation des requêtes : Toutes les requêtes possibles sur la base de données le
sont aussi sur la base de connaissances.
Monotonie : Une modification sur la base de données peut être incluse dans la base
de connaissances finale sans refaire tout le processus de transformation.
Conservation sémantique : Si la base de données est inconsistante, alors la base de
connaissances le sera aussi.
Ces règles ont été étendues [Sequeda et al., 2011a] et proposées dans une recommandation
du W3C
59[Arenas et al., 2012].
1.2.2. Transformation par un langage intermédiaire
La deuxième famille de méthodes de transformation est la transformation par
l’utilisa-tion d’un langage intermédiaire. Pour cela, nous pouvons citer deux travaux représentatifs
[Auer et al., 2009,Das et al., 2012].
Les méthodes de cette famille ne sont pas directement des méthodes de transformation
mais plutôt une proposition d’implémentation des transformations. Néanmoins, certains
travaux cherchent à transformer des bases de données en exploitant directement un
langage intermédiaire défini. C’est notamment le cas de [Auer et al., 2009] qui a proposé
des transformations de bases de données d’applications très utilisées sur le Web
60.
Le projet Triplify [Auer et al., 2009] propose d’étendre le langage SQL en ajoutant des
informations concernant la transformation à effectuer. Nous pouvons prendre l’exemple
suivant :
SELECT id,
price AS ’price^^xsd:decimal’,
desc AS ’rdfs:label@en’,
cat AS ’belongsToCategory->category’
FROM products
Cette requête permet de spécifier que l’attribut "price" de la table "products" est une
propriété de données de type décimal, l’attribut "desc" est un label en anglais et l’attribut
"cat" est une propriété nommée "belongsToCategory" vers une instance de "category".
Le projet R2RML [Das et al., 2012] est également une recommandation du W3C
61sur l’utilisation de JSON comme langage intermédiaire pour définir la transformation à
effectuer sur la base de données. Nous pouvons prendre l’exemple suivant :
@prefix rr: <http://www.w3.org/ns/r2rml#>.
@prefix ex: <http://example.com/ns#>.
<#TriplesMap1>
rr:logicalTable [ rr:tableName "EMP" ];
rr:subjectMap [
rr:template "http://data.example.com/employee/{EMPNO}";
rr:class ex:Employee;
];
rr:predicateObjectMap [
rr:predicate ex:name;
rr:objectMap [ rr:column "ENAME" ];
].
Cet exemple prend en compte une table "EMP" qui permet la création de la classe
"Employee". Cette table a l’attribut "EMPNO" qui est utilisé pour la génération de
60. Par exemple PhpBB -http://triplify.org/About