Gestion de données complexes

Master 2 Informatique Spécialité AIGLE Gestion de données complexes Amayas ABBOUTE Gilles ENTRINGER

SOMMAIRE Sommaire i 1 - Introduction 1 2 - Technologies utilisées 2 2.1 API Jena........................................ 2 2.2 D2RQ.......................................... 2 2.3 TDB........................................... 2 2.4 SDB........................................... 2 2.5 Outils NoSQL...................................... 2 2.5.1 Neo4J...................................... 3 2.5.2 HBase...................................... 3 3 - Ontologies utilisées 4 3.1 Ontologie INSEE COG................................. 4 3.2 Ontologie INSEE Population.............................. 4 3.3 Ontologie GeoNames.................................. 5 3.4 ISF (Mapping D2RQ).................................. 5 3.5 Liaison des ontologies................................. 5 4 - Jeux de données utilisés 6 4.1 Données issues de l INSEE - Code Officiel Géographique (COG)........... 6 4.1.1 Format tabulaire : CSV............................. 6 4.1.2 Format RDF.................................. 7 4.2 Données issues de GeoNames............................. 8 4.3 Données issues de INSEE - Population......................... 8 4.4 Données relatives à l ISF (Impôts de solidarité sur la fortune)............. 9 5 - Réalisation 10 5.1 Architecture de l application.............................. 10 5.2 Génération dynamique du modèle........................... 11 5.2.1 Hbase...................................... 11 5.2.2 Neo4j...................................... 12 5.2.3 TDB...................................... 13 5.2.4 SDB....................................... 14 i

5.2.5 D2RQ...................................... 15 5.3 Présentation de l interface utilisateur.......................... 16 5.3.1 Génération dynamique des préfixes...................... 16 5.3.2 Exemple de requêtes Sparql.......................... 17 5.3.3 Affichage des résultats............................. 21 6 - Conclusion 22 6.1 Difficultés rencontrées................................. 22 6.2 Expériences apportées................................. 22 ii

PARTIE 1 - INTRODUCTION Conçues il y a quelques années pour enrichir la recherche et l exploitation des résultats sur le web, les technologies derrière le web sémantique poursuivent leur ascension. Dans ce projet, nous avons voulu associer ce concept de Web sémantique aux différentes technologies de stockage de données ainsi qu à l approche NoSQL qui est plutôt populaire en ce moment. Pour cela, nous avons développé une application ayant pour but principal de manipuler plusieurs technologies de stockage de données, de les lier entre eux par un lien sémantique et de les interroger. Nous avons choisi les jeux de données suivants : INSEE COG Geonames INSEE Population ISF (impôts) Ce rapport s organise comme suit : Dans un premier temps, nous allons commencer par présenter les différentes technologies (partie 2) et ontologies utilisées (partie 3), puis, les jeux de données cités précédemment ainsi que leur utilisation au sein de notre projet (partie 4). Nous allons présenter dans la partie 5 l architecture générale de notre application, la façon dont on génère le modèle, l interface utilisateur ainsi que quelques exemples de requêtes Sparql. Enfin, nous allons clore ce rapport par une conclusion (partie 6) dans laquelle nous allons détailler les difficultés rencontrées ainsi que les expériences apportées. 1

PARTIE 2 - TECHNOLOGIES UTILISÉES 2.1 API Jena D un point de vue technique, le web sémantique introduit plusieurs standards dont le RDF qui est un modèle permettant de décrire toute donnée suivant une syntaxe particulière proche de XML. Jena 1 est une API Java qui peut être utilisée pour créer et manipuler des modèles RDF. Elle possède des classes permettant de représenter tous les concepts du modèle RDF à savoir : les graphes, les ressources, les propriétés et les littéraux. 2.2 D2RQ Le langage d association D2RQ est un langage déclaratif pour l association des schémas d une base de données relationnelle aux vocabulaires RDFS et ontologies OWL. Le langage est implémenté dans la plate-forme D2RQ 2. L association définit un graphe RDF virtuel qui contient des informations provenant de la base de données utilisée (dans notre cas Oracle). Cette association est décrite dans un fichier de mapping qui doit être généré par l utilisateur. 2.3 TDB TDB est un composant de l API Jena décrite précédemment, il est principalement utilisé pour le stockage à grande échelle et l interrogation de bases de données RDF (Triplestore). 2.4 SDB SDB à l instar de TDB est aussi un composant de l API Jena, il fournit un système de stockage de triplets RDF qui utilise une base de données relationnelle : MySQL, PostgreSQL, etc. 2.5 Outils NoSQL NoSQL désigne une catégorie de systèmes de gestion de base de données (SGBD) qui n est plus fondée sur l architecture classique des bases relationnelles. En effet, il ne vient pas remplacer les bases de données relationnelles mais proposer une alternative ou compléter les fonctionnalités des SGBDR pour donner des solutions plus intéressantes dans certains contextes. Le premier besoin fondamental auquel répond NoSQL est la performance. 1. http ://jena.apache.org/ 2. http ://d2rq.org/ 2

2.5.1 Neo4J Neo4j 3 est un système de gestion de base de données orienté graphes, complètement compatible avec les transactions ACID, écrite en Java. Les données sont stockées sur disque sous la forme d une structure de données optimisée pour les réseaux de graphes. Parmi les cas d utilisations d une base de données NoSQL, nous pouvons cité le domaine du Web sémantique et RDF ainsi que la modélisation de données de réseaux sociaux. 2.5.2 HBase HBase 4 est un système de gestion de base de données non-relationnel orienté colonnes, écrit en Java, disposant d un stockage structuré pour les grandes tables. Parmi ses points forts, très bonne montée en charge et excellente tolérance au partitionnement. Il est utilisé par de grands acteurs du Web comme le célèbre réseau social Facebook pour stocker tous ses messages. 3. http ://www.neo4j.org/ 4. http ://hbase.apache.org/ 3

PARTIE 3 - ONTOLOGIES UTILISÉES Avant de commencer la présentation des ontologies utilisées, une petite explication sur ce qu est une ontologie s impose. Nous pouvons concevoir une ontologie comme une structuration de divers concepts spécifiques à un domaine. Ces concepts sont rassemblés pour fournir les éléments de base et exprimer les connaissances dont on dispose dans ce domaine. Ces concepts sont reliés entre eux par des relations. 3.1 Ontologie INSEE COG L INSEE a publié des données RDF issues du code officiel géographique. Les données sont modélisées conformément à une ontologie OWL. Dans cette ontologie, les concepts définies sont les classes, leurs sous-classes, les liens d appartenance des différentes classes ainsi que les différentes propriétés (par exemple pour le code INSEE). Cette ontologie est utilisée pour l ensemble des données sur les territoires français (régions, départements, cantons, arrondissements et communes) que nous traitons et que nous avons récupérées à partir du site de l INSEE. Du fait que la plupart des données que nous traitons provient de l INSEE, nous allons utiliser cette ontologie comme ontologie centrale et nous allons lier les autres ontologies utilisées à celle-ci. Nous expliquons dans les différentes parties ci-dessous, comment nous lions les différents vocabulaires à l ontologie INSEE COG. A noter que nous utilisons la version de l ontologie datant de l année 2006. 3.2 Ontologie INSEE Population L INSEE nomme cette ontologie idemo, c est une ontologie très légère et toujours en cours de développement. FIGURE 3.1 Schéma de l ontologie INSEE Population (cf. rdf.insee.fr/def/index.html) Nous avons dû légèrement modifier ce vocabulaire afin de le rendre compatible avec l ontologie des Codes Officiels Géographiques (INSEE COG). L ontologie de la population définie une propriété idemo :population qui prend comme rdfs :domain ce qu on appelle dans la dernière version de l ontologie de l INSEE igeo :TerritoireFrançais (année 2012). Néanmoins, cette classe n existe pas dans l ontologie COG que nous utilisons (version de l année 2006). Nous étions donc obligés d identifier 4

la classe équivalente dans l ancienne version de l ontologie qui est Territoire_FR. 3.3 Ontologie GeoNames L ontologie GeoNames fournit des éléments de description pour des caractéristiques géographiques pour des millions de lieux géo-référencés dans le monde et qui sont définies dans la base de données de Geonames.org. Pour lier l ontologie de Geonames à celle de l INSEE COG, nous utilisons la propriété rdfs :subclassof pour indiquer que la classe geo :departement est une sous-classe de la classe geonames nommé A.ADM2. 3.4 ISF (Mapping D2RQ) Afin de pouvoir établir un lien entre le fichier de mapping D2RQ et l ontologie de l INSEE COG, nous ajoutons une propriété supplémentaire d2rq :additionalpropertydefinitionproperty à la propriété IMPOT_CODEINSEE dans le fichier de mapping. Cette propriété est map :InseeEquivalence qui définit l équivalence (owl :equivalentproperty) avec la propriété geo :code_insee de l ontologie INSEE COG. 3.5 Liaison des ontologies FIGURE 3.2 Liaison des ontologies utilisées 5

PARTIE 4 - JEUX DE DONNÉES UTILISÉS Pour ce projet, nous utilisons diverses sources de données, à savoir : INSEE COG INSEE Population GeoNames ISF pour les impôts. 4.1 Données issues de l INSEE - Code Officiel Géographique (COG) Ce sont les données provenant du site 1 de l INSEE (COG) au format tabulaire et au format RDF. Ces données concernent le découpage administratif du territoire français (régions, départements, arrondissements, communes) et le lien sémantique qui les unis. 4.1.1 Format tabulaire : CSV 4.1.1.1 INSEE Communes Format initial :.csv Ontologie : INSEE COG Stockage dans : HBAse Toutes les données "communes de France" sont stockées dans une base de données NoSQL Hbase. Pour cela, nous parsons le fichier "cog.csv" en Java ce qui nous permet de récupérer chaque ligne du fichier (cf. fichier ReadCSV_Communes.java), puis, nous créons une table sous Hbase pour stocker les informations qui nous intéressent, à savoir : le code des communes, leur noms, le code du département auquel appartient la commune ainsi que le code de la région à laquelle appartient la commune. A partir des données stockées dans Hbase, nous créons, sur demande de l utilisateur un modèle en respectant l ontologie définie par l INSEE pour ces données. Par exemple geo :nom pour le nom des communes ou encore geo :code_insee pour les codes INSEE des communes. 4.1.1.2 INSEE Départements Format initial :.csv Ontologie : INSEE COG Stockage dans : Neo4J Comme pour les communes, nous parsons en JAVA le fichier "departements.csv" et stockons les différentes données dans une base de données Neo4J. Pour chaque département, un nœud est créé et comporte les informations suivantes : le code du département,son nom, son chef lieu et le code de la région d appartenance. 1. http ://rdf.insee.fr/ 6

4.1.1.3 INSEE Régions Format initial :.csv Ontologie : INSEE COG Stockage dans : Neo4J Nous avons suivi le même principe que pour les départements. Pour chaque région, un nœud est créé qui comporte les informations suivantes : le code de la région, son nom et le chef lieu de la région. 4.1.1.4 Liaison des départements aux régions Par définition, un département appartient à une région. Ainsi, pour chaque nœud département, une relation est créée avec le nœud région auquel il appartient. (departementnode.createrelationshipto(regionnode, RelTypes.BELONGSTO ). Ceci permet par la suite de récupérer facilement tous les départements d une région. 4.1.2 Format RDF Les données de l INSEE sont également disponibles au format RDF. Nous avons décidé de stocker ces données à l aide de l outil Jena TDB décrit précédemment. 4.1.2.1 INSEE Départements Format initial :.rdf Ontologie : INSEE COG Stockage dans : TDB Pour chaque département, l INSEE propose par exemple les informations suivantes : le code du département (geo :code_departement), son nom, les arrondissement du département ou encore la commune chef-lieu du département. 4.1.2.2 INSEE Régions Format initial :.rdf Ontologie : INSEE COG Stockage dans : TDB Pour les régions, l INSEE propose les informations suivantes : le code de la région (geo :code_region), son nom ou encore son chef-lieu (geo :chef-lieu). 4.1.2.3 INSEE Arrondissements Format initial :.rdf Ontologie : INSEE COG Stockage dans : TDB L ensemble des arrondissement français sont également stockés dans un triplestore TDB. Les informations disponibles sont les cantons des arrondissements et les communes de l arrondissement départemental (propriété geo :subdivision). 4.1.2.4 INSEE Cantons Format initial :.rdf Ontologie : INSEE COG Stockage dans : TDB Tous les cantons français sont également stockés dans un triplestore TDB. Les informations disponibles sont les chefs-lieu des cantons ainsi que les communes appartenant au canton. 7

4.2 Données issues de GeoNames Format initial :.rdf (téléchargé à partir de l API GeoNames) Ontologie : Geonames Stockage dans : TDB Pour télécharger les départements français à partir de la base de données GeoNames, nous avons utilisé un WebService proposé par GeoNames (cf. http ://www.geonames.org/export/geonames-search.html). Il suffit de passer en paramètre d une URL le nom du département ou son code postal. En utilisant les données de l INSEE, nous avons créé une requête pour sélectionner les noms de tous les départements et pour chaque département nous avons pu enregistrer l ensemble des informations disponibles en RDF et stocker les résultats dans des fichiers RDF. Ces fichiers ont par la suite été rassemblé dans un seul modèle, stocké à l aide de l outil Jena TDB. Pour l ensemble des données, Geonames propose les informations suivantes qui peuvent être considérées comme étant complémentaires aux données de l INSEE comme la longitude, la latitude, le nombre d habitants ou encore le nom des départements dans différentes langues. 4.3 Données issues de INSEE - Population Format initial : Fichier Turtle (ttl) Ontologie : INSEE Population Stockage : SDB / MySQL L INSEE publie en RDF, en plus des données sur les entités géographiques, des données sur les populations légales issues du recensement de la population. Nous avons choisi d utiliser les données de 2011. Les données sont disponibles sous forme d un fichier Turtle (format.ttl) qui contient les populations légales, les populations comptées à part et les populations totales pour les différents territoires français. Nous avons stocké les données contenues dans ce fichier à l aide de Jena SDB (Base de données : MySQL). Les données publiées par l INSEE contiennent des liens avec des ressources définies par rapport à la dernière version de l ontologie INSEE COG (2012). Nous étions donc amenés à modifier ces données manuellement. Par exemple, l URI qui décrit une ressource de type commune dans la version originale ressemble à ceci : http ://id.insee.fr/geo/commune/30241 Par contre, dans la version de l ontologie INSEE COG que nous utilisons, l URI décrivant une ressource de type commune doit ressembler à cela : http ://rdf.insee.fr/geo/2011/com_30241. 8

4.4 Données relatives à l ISF (Impôts de solidarité sur la fortune) Format initial :.csv Fichier de Mapping D2RQ Stockage : d2rq / Oracle Les informations sur les impôts de solidarité sur la fortune concernent les villes de plus de 20000 habitants dont plus de 50 habitants sont soumis à l ISF. Les données qui y sont proposées comportent les informations suivantes : Code impôt Code INSEE du territoire Nombre de redevables du territoire Impôt moyen du territoire 9

PARTIE 5 - RÉALISATION 5.1 Architecture de l application FIGURE 5.1 Architecture générale de l application L application est implémenté suivant le patron de conception MVC. Pour faciliter la mise en forme de la partie "View", nous avons utilisé le framework CSS Bootstrap 1. Nous utilisons également le serveur Apache Tomcat 2 pour récupérer les modèles générés à partir des différentes sources de données, pour exécuter les requêtes Sparql et pour traiter les requêtes AJAX envoyées par la "View". 1. http ://getbootstrap.com/ 2. http ://tomcat.apache.org/ 10

5.2 Génération dynamique du modèle En fonction du choix de l utilisateur, l application développée génère dynamiquement le modèle utilisé pour exécuter la requête Sparql (appelé par la suite "modèle global"). Cette génération diffère selon la technologie de stockage des données (Hbase, Jena TDB etc.). Pour chaque exécution d une requête, un modèle Jena est généré au niveau de la servlet. L application utilise ce modèle pour exécuter la requête Sparql. Pour chaque source de données sélectionnée par l utilisateur, le modèle correspondant est ajouté à ce modèle, que nous appelons modèle global par la suite. 5.2.1 Hbase Lorsque l utilisateur souhaite interroger les données (communes) stockées dans Hbase le code suivant est exécuté au niveau de la servlet responsable de la génération du modèle : FIGURE 5.2 Ajout du modèle comportant les données stockées dans HBase Nous récupérons les données de HBase et les stockons dans une ArrayList. (cf. CreateTable.java) FIGURE 5.3 Récupération des données stockées dans la base de données HBase Afin de générer le modèle, nous nous basons sur l ontologie INSEE COG et créons pour chaque commune une nouvelle ressource avec les propriétés correspondantes. Le modèle généré ("communemodel") sera retourné à la Servlet qui va l ajouter au modèle global de l application. FIGURE 5.4 Génération du modèle des communes (cf. HBase_Model_Commune.java) 11

5.2.2 Neo4j Si l utilisateur veut interroger les données stockées dans Neo4J, les étapes suivantes sont exécutées pour générer le modèle des départements (par exemple) et l ajouter au modèle global de l application. 1. Sélection des noeuds départements dans la base de données et création d objets de type "Departement" pour chaque noeud. Dans la classe "ConsultNeo4J.java" nous retournons ainsi une liste de départements (nommée listdepartement) que nous utilisons par la suite pour générer le modèle RDF de ces données. FIGURE 5.5 Requêtage de la base de données Neo4J 2. Dans la classe Neo4j_Model_Departements.java nous créons le modèle en nous basant sur l ontologie INSEE COG. Pour chaque département, une ressource de type département est créé avec ses propriétés. FIGURE 5.6 Neo4J - Génération du modèle des départements 12

3. Finalement, le modèle des départements est ajouté au modèle global de l application. FIGURE 5.7 Neo4J - Ajout du modèle des département au modèle global 5.2.3 TDB Nous avons mis en place 5 triplestores (Arrondissements, Cantons, Régions, Départements, Départements- Geonames) à l aide de l outil TDB Jena. Suivant le choix de l utilisateur, l application ajoute au modèle global le modèle correspondant au choix en question. Les figures 5.8 et 5.9 montrent les différentes étapes de chargement du modèle correspondant aux régions à partir de Jena TDB. 1. Création du modèle : FIGURE 5.8 TDB - Création du modèle pour les régions (Model_tdb_Regions.java) 2. Ajout du modèle généré au modèle global de l application. FIGURE 5.9 TDB - Ajout au modèle global dans la Servlet Geonames Comme expliqué précédemment, nous avons téléchargé à partir d un WebService les données RDF pour tous les départements français référencés dans Geonames. Les différents fichiers peuvent être consultés dans le répertoire "WebContent/geonames-data/ de l application. Afin de garantir un traitement efficace et rapide des requêtes, nous avons stocké l ensemble de ces données dans un triplestore TDB (nommé "geonamesdepartements"). 13

5.2.4 SDB Les données relatives à la population (COG Population) sont stockées dans un triplestore SDB lié à une base de données MySQL. L application se connecte à ce triplestore, récupère le modèle qui y est stocké et l ajoute au modèle global de l application. 1. Création du triple store SBD (SDBCreation.java) FIGURE 5.10 SDB - Création du triplestore 2. Chargement du modèle et ajout au modèle global de l application FIGURE 5.11 SDB - Ajout au modèle global dans la Servlet 14

5.2.5 D2RQ Les informations relatives aux impôts de solidarité sur la fortune sont stockées dans une base de données relationnelle en l occurrence Oracle. Le système D2RQ nous permet d interroger cette base de données en tant que graphe RDF via un fichier de mapping. 1. Récupération du modèle des données : FIGURE 5.12 D2RQ - Chargement du modèle à partir de la BDD Oracle 2. Ajout du modèle généré au modèle global FIGURE 5.13 D2RQ - Ajout au modèle global dans la servlet 15

5.3 Présentation de l interface utilisateur FIGURE 5.14 Aperçu de l interface utilisateur Nous avons développé une interface utilisateur qui propose les fonctionnalités suivantes : Sélectionner les sources de données que l on souhaite interroger Saisir la requête Sparql et l envoyer au serveur Afficher les résultats Consulter les ontologies utilisées Dans cette partie du rapport nous expliquons brièvement le fonctionnement de l interface. 5.3.1 Génération dynamique des préfixes Dans l onglet "Sources" (cf figure 5.15), l utilisateur peut sélectionner les sources de données qu il veut interroger en Sparql. Nous avons stocké les différents préfixes (namespaces) qui peuvent être utilisées pour chaque source de données dans un fichier json (cf. fichier /WebContent/data/prefixes.json). Lorsque l utilisateur sélectionne une source de données, les préfixes sont ajoutés automatiquement dans la zone de saisie de l application et dans la partie "prefixes" pour que l utilisateur puisse consulter directement les ontologies (via un lien). FIGURE 5.15 Sélection des sources de données 16

La figure 5.16 montre l exemple des préfixes générés pour interroger les départements récupérés à partir de Geonames. A noter que l application veille à ce qu un préfixe ne soit ajouté qu une seule fois, même s il est disponible pour plusieurs sources de données sélectionnées. FIGURE 5.16 Préfixes générés automatiquement 5.3.2 Exemple de requêtes Sparql 5.3.2.1 Nombre d habitants de la commune de Montpellier Source de données : Hbase + SDB Jeux de données utilisés : Communes (Hbase), Population (SDB) 1. Exécution de la requête : FIGURE 5.17 Exécution de la requête 2. Affichage des résultats : FIGURE 5.18 Affichage des résultats 17

5.3.2.2 Nombre d habitants par département de la région Languedoc-Roussillon Source de données : TDB + SDB Jeux de données utilisés : Département, Régions (TDB), Population (SDB) 1. Exécution de la requête : FIGURE 5.19 Exécution de la requête 2. Affichage des résultats : FIGURE 5.20 Affichage des résultats 18

5.3.2.3 Nombre d habitants, longitude, latitude de chaque département Source de données : TDB Jeux de données utilisés : Département (Geonames TDB), Département (TDB) 1. Exécution de la requête : FIGURE 5.21 Exécution de la requête 2. Affichage des résultats : FIGURE 5.22 Affichage des résultats 19

5.3.2.4 Communes comptant entre 500 et 900 redevables ISF Source de données : SDB, HBase Jeux de données utilisés : Population (SDB), Commune (Hbase) 1. Exécution de la requête : FIGURE 5.23 Exécution de la requête 2. Affichage des résultats : FIGURE 5.24 Affichage des résultats 20

5.3.2.5 Nom de toutes les communes des départements de la région Languedoc-Roussillon Source de données : Hbase, Neo4J, TDB Jeux de données utilisés : Communes (Hbase), Départements (Neo4J), Régions (TDB) 1. Exécution de la requête : FIGURE 5.25 Exécution de la requête 2. Affichage des résultats : FIGURE 5.26 Affichage des résultats 5.3.3 Affichage des résultats Comme vu précédemment, les résultats sont affichés dynamiquement dans l onglet "Résultats". L application s occupe de générer un tableau HTML en tenant compte du nombre d éléments retournés par le serveur (résultat de la requête). 21

PARTIE 6 - CONCLUSION 6.1 Difficultés rencontrées Lors de la réalisation de ce projet, nous avons été confronté à plusieurs difficultés que nous allons détaillées dans ce qui suit : Difficulté à comprendre les différentes ontologies proposées par l INSEE et Geonames et de les lier entre elles. Incompatibilité des versions proposés par l INSEE concernant l ontologie INSEE COG. Génération incorrecte du fichier de mapping D2RQ ce qui nous a poussé à le modifier manuellement. Lenteur de Neo4J lors de l interrogation de la base de données d où l utilisation du langage de requêtes Cypher. 6.2 Expériences apportées Ce projet nous a permis de découvrir différentes nouvelles technologies, notamment l API Jena, les systèmes de stockage NoSQL (HBASE, Neo4J) et la plateforme D2RQ. Nous avons également appris à décrire la relation entre le schéma d une base de données relationnelle et des vocabulaires RDF et / ou des ontologies OWL. De plus, le projet nous a permis d évaluer les faiblesses et les points forts des différentes technologies. Par exemple, nous avons remarqué que Jena SDB est beaucoup plus lent que Jena TDB en terme de vitesse d exécution. Les bases de données NoSQL permettent d optimiser la gestion de données complexes (BigData). Finalement, ce projet nous a permis de lier différentes ontologies suivant un lien sémantique et d interroger avec une seule requête Sparql des données issues de plusieurs sources (TDB, Hbase etc.). 22