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 la a, 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 la a, 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 la a avec 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 la a avec 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 W3C59 [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 Web60.
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 W3C61 sur 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
l’URI d’une instance. Elle contient aussi l’attribut "ENAME" qui est transformé en une propriété de données de "Employee" nommée "ex :name". Un exemple de résultat est : <http://data.example.com/employee/7369> rdf:type ex:Employee.
<http://data.example.com/employee/7369> ex:name "SMITH".
1.2.3. Analyse
En plus de ces deux familles, il existe d’autres travaux qui présentent des approches dédiées à une base de données spécifique [Dhombres et al., 2012, Krivine et al., 2009]. Ces travaux montrent que les méthodes génériques ne sont pas forcément pertinentes dans un cas réel. Les méthodes présentées précédemment montrent toutes des limites dans le cas des bases de données complexes. C’est particulièrement le cas pour la gestion des relations de spécialisation entre classes (subClassOf) qui n’est pas suffisamment explicite dans les bases de données. Les approches à base de règles peuvent découvrir certaines de ces relations mais peuvent aussi apporter du bruit, alors que les méthodes utilisant un langage intermédiaire permettent de mettre en place la transformation directement au niveau des éléments de la base de données.