Tags:
create new tag
, view all tags

Stage de Lucas Holzmann - ENSIIE - [4/06/18 au 10/08/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter François-Xavier, Mireille

Sujet

Stage (Juin - Août 2018)

Juin

  • SEMAINE I

  • 4.
    • Arrivée
    • Présentation de l'environnement de travail et installation
    • Recherches et lectures sur la documentation de RDF et du web sémantique (wikipédia, w3.org: RDF Schema, RDF Concepts and Abstract Syntax, Turtle, Linked Data Platform)
    • Début de lecture de la documentation de SPARQL (page wikiversité, début de la page w3.org)

  • 5.
    • Poursuite des lectures sur SPARQL
    • Création d'un compte wikidata: lecture de la documentation et tests concrets de requêtes SPARQL
    • Tentative d'installation de Blazegraph: échec

  • 6.
    • Lecture de la documentation sur ProvenanceDM
    • Débrief avec Mireille Louys: contexte et outils du CDS (Vizier, Aladin, Simbad), RDF, ProvenanceDM
    • Retour sur Blazegraph: installation réussie, Blazegraph semble fonctionnel -> premières manipulations

  • 7.
    • Prise en main de Blazegraph
    • Lecture de divers documents sur Blazegraph, ProvenanceDM, R2RML (lecture rapide)
    • Tests Blazegraph et Wikidata
    • Test de mise en place d'un git: unistra pas adapté car je n'ai pas de compte unistra

  • 8.
    • Réception et étude de 2 documents VOTable pour voir comment ceux-ci sont organisés et les possibilités de conversion en RDF
    • Lecture de la documentation sur les VOTable
    • Etude du travail effectué par un précédent groupe d'étudiants s'étant intéressé au même sujet
    • Débrief avec Mireille Louys: VOTable to RDF, parallèle IVOA/W3C, quelle stratégie adopter, recours à Wikidata qui peut servir de modèle pour certaines relations (rôle(s) d'un agent par exemple)
    • Stratégie intéressante: passer de VOTable à xml/csv puis convertir ce format intermédiaire en un format RDF (RDF/XML ou turtle)
    • Petite recherche sur les façons (librairies, api) de convertir un fichier sous format VOTable en xml ou csv, puis de ce format intermédiaire vers un format compatible avec RDF

  • SEMAINE II

  • 11.
    • Réunion de débrief de la première semaine avec Mireille Louys & François-Xavier Pineau: voir notes
    • Création d'un projet sur le git du cds
    • Comparaison des différents formats de sérialisation RDF supportés pas Blazegraph
    • Installation de Topcat
    • Réception de certains scripts utilisant lxml.etree, écrits par des étudiants ayant travaillé sur le même sujet: début de lecture de la documentation

  • 12.
    • Choix du format RDF utilisé: Turtle pour le moment
    • Lecture sur les qualifiers et sur foaf
    • Etude des scripts python des précédents étudiants: je n'arrive pas à les faire tourner -> fichiers manquants ?
    • Conversion de toutes les tables données en tant qu'exemple en csv à l'aide de Topcat

  • 13.
    • Lecture sur différentes ontologies pouvant être utiles pour notre modèle et tests sur Blazegraph: prov, dcterms, scoro
    • PRO ontologie similaire à notre modèle au niveau du rôle des agents
    • Poursuite de l'étude des scripts python
    • Invitation à une séance au Planétarium

  • 14.
    • Etude du document RDF fourni par les précédents étudiants, ainsi que des ontologies utilisées
    • Poursuite du test d'un document RDF sur Blazegraph : un certain nombre d'ontologies utilisées sont des ontologies SPAR (voir également Silvio Peroni)
    • Ecriture de requêtes SPARQL non triviales
    • Ajout de toutes les classes au document test pour Blazegraph, sauf ActivityFlow, wasInformedBy, Collection, Parameter (+description) et wasDerivedFrom
    • Rôle des agents: comparaison de ma solution et de celle des étudiants précédents -> conclusion: la nouvelle solution me semble plus adaptée

  • 15.
    • Ajout des relations Parameter & ParameterDescription à mon document test
    • Point sur l'avancement avec François-Xavier & Mireille
    • Etude du problème des mariages sur Wikidata: comment Wikidata associe-t-il des paramètres à des mariages (date de début et de fin, lieu du mariage, etc.) ? Il semble procéder à deux déclarations explicites du mariage et des paramètres qui lui sont associés

  • SEMAINE III

  • 18.
    • Réunion avec Mireille & François-Xavier: à faire:
    • continuer à étudier Wikidata pour comprendre sa gestion des relation (symétrie, règles, etc.): téléchargement d'un dump de la database pour l'étudier
    • faire des recherches sur la portée de la description d'une ontologie: est-il possible d'y définir des règles sur les classes/propriétés ?
    • écrire un script python permettant de passer d'un fichier .csv à un fichier .ttl
    • Lecture d'un article traitant du passage de la database Wikidata en RDF
    • Exploration de Wikidata pour trouver un forum ou une page de contact

  • 19.
    • Lecture de documentation sur OWL: 1, 2
    • Edition d'onthologies: utiliser Protégé ? ou plutôt le faire directement en turtle ?
    • Téléchargement de Protégé et test de l'implémentation d'une onthologie très basique: utiliser Prov-O et l'étendre avec Protégé ?
    • Tutoriel de Protégé

  • 20.
    • Fin du tutoriel de Protégé
    • Téléchargement et étude des codes OWL des ontologies PRO & Prov-O: s'inspirer de ces ontologies et les combiner pour en créer une adaptée à notre modèle de provenance ?
    • Tests pour voir comment Blazegraph gère la symétrie et la fonctionnalité d'une propriété définie en OWL: pas de création réciproque pour la symétrie, pas de message d'erreur/interdiction pour une relation non valable à cause de la fonctionnalité
    • Création d'une ontologie Prov adaptée à notre modèle sur Protégé
    • Début de modification du fichier de test Blazegraph afin qu'il ne soit définit qu'à l'aide de notre ontologie Prov

  • 21.
    • Modification de l'ontologie Prov: ajout des dernières classes et relations manquantes, ajout de rôles en tant qu'instances, ajout d'une relation refersTo permettant de référencer un agent dans une relation où il a un rôle
    • Fin de la conversion du fichier de test Blazegraph: il ne nécessite désormais que notre ontologie pour être lu
    • Modification des quelques requêtes SPARQL déjà écrites afin qu'elles soient conformes à la nouvelle ontologie
    • Début de l'écriture du script Python permettant de passer d'un document csv à un document Turtle
    • Ecriture de requêtes SPARQL additionnelles

  • 22.
    • Ecriture de requêtes SPARQL
    • Réunion avec Mireille & F-X: débrief sur l'ontologie, absence d'interprétation des règles de l'ontologie du côté de Blazegraph, exposé de l'ontologie/des requêtes SPARQL/du script, pb dans requêtes (ancêtres de rang k notamment)
    • Séminaire Deep Learning & Astronomie
    • Lecture de la documentation Blazegraph sur l'inférence

  • SEMAINE IV

  • 25.
    • Suite des recherches sur la gestion de l'inférence par Blazegraph: expérimentation: domain, range, functionalProperty et inverseFunctionProperty ne semblent pas être compris par Blazegraph. Le contraire est spécifié sur leur site: comment activer/modifier les règles d'inférence de Blazegraph ?
    • Recherches sur l'état actuel de Blazegraph: ne semble plus être en développement, support sur SourceForge, nombreux liens morts sur le site: Blazegraph racheté par Amazon en 2017 et son équipe recrutée pour travailler sur Amazon Neptune, un triplestore Amazon
    • Ecriture du reste des scripts pour convertir les fichiers csv en fichiers ttl. A faire encore: régler le problème d'encoding, implémenter la relation derivesFrom (+ changer describedBy en describes dans wGb & used ?)
    • Scripts fonctionnels et documents de sortie compris par Blazegraph

  • 26.
    • Ajout de la relation wasDerivedFrom dans le modèle et les scripts
    • Fin de l'écriture des scripts convertissant le csv en ttl
    • Création d'un script et d'un fichier de sortie uniques
    • Traduction de requêtes en SPARQL

  • 27.
    • Implémentation de wasDerivedFrom en tant que super-property de wasGeneratedBy et de used dans l'ontologie prov
    • Problème des ancêtres: méthode proposée ne fonctionne pas si plus d'un chemin relient deux entités
    • Recherches sur l'ajout de règles dans Blazegraph + ses modes de gestion de l'inférence
    • Repas du Solstice

  • 28.
    • Suite des recherches sur l'ajout de règles d'inférence sur Blazegraph -> abandon (liens morts, plus bcp de réponses depuis 2016, github java dense et obscur)
    • Début de l'étude du modèle de données de Simbad: exploration de la base de données, lecture de la doc

  • 29.
    • Etude du modèle de données de Simbad, création d'une ontologie correspondante
    • Réunion: objectifs proches:
    • - implémenter des requêtes SPARQL supplémentaires
    • - s'intéresser à une représentation graphique de nos résultats des requêtes
    • - écrire la première partie du rapport sur Provenance

Juillet

  • SEMAINE V

  • 2.
    • Résolution d'un problème de compatibilité entre mon fichier OwlAndData.ttl et Protégé
    • Recherches sur la visualisation graphique des objets dans Protégé: NavigOwl permet de visualiser tous les objets s'ils proviennent d'une entrée en RDF/XML (possibilité de restreindre au résultat d'une requête SPARQL sans exporter puis réimporter ?)
    • Réflexion avec Mireille sur la traduction des templates dans mon modèle d'ontologie, et révision de certaines classes/relations
    • Début de rédaction de la première partie du rapport de stage

  • 3.
    • Mise à jour de l'ontologie: Prov_2 remplace les relations describedBy et hasParameter par used et type de manière plus détaillée les classes. Ce changement est motivé par une plus grande compatibilité avec le modèle du W3C
    • Mise à jour des scripts pour qu'ils utilisent Prov_2 correctement
    • Recherches sur la notion de Bundle: voir la doc du W3C sur Prov-O
    • Installation de Texmaker et début de lecture d'un cours sur LaTeX
  • 4.
    • Ecriture de requêtes supplémentaires
    • Adaptation des requêtes à la deuxième version de l'ontologie
    • Validation des requêtes avec Mireille

  • 5.
    • Ecriture de requêtes supplémentaires
    • Fin de lecture du cours d'introduction à LaTeX et début de rédaction du rapport de stage

  • 6.
    • Rédaction du rapport
    • Validation de requêtes avec Mireille

  • SEMAINE VI
  • 9.
    • Correction d'une requête avec filtre sur la durée des activités
    • Ecriture du rapport

  • 10.
    • Ecriture du rapport
    • Validation de requêtes avec Mireille

  • 11.
    • Ecriture du rapport - fin de la première partie
    • Validation de requêtes avec Mireille
    • Réunion pour parler de la suite du stage: Simbad:
    • écrire des scripts similaires
    • tester des requêtes en position
    • tester les performances avec ~1000 objets dans un dataset de test (temps des requêtes + nombre de triplets générés)
    • éventuellement exploiter la notion de hiérarchie du modèle (si assez de temps)

  • 12.
    • Recherches sur les annexes en LaTeX: que mettre en annexe + comment les intégrer concrètement ?
    • -> ontologies: Prov & Prov_2 ?
    • -> scripts : Probablement pas tous, script_full + entity/activity ?
    • -> requêtes: Toutes les requêtes ? Avec les deux versions de l'ontologie ?
    • -> validation des requêtes
    • Reprise et extension de l'ontologie Simbad créée précédemment
    • lecture d'une doc sur Simbad

  • 13.
    • Fin de l'écriture de l'ontologie: modèle Simbad réduit implémenté sous forme d'ontologie Simbad.owl: BasicData, Flux, Filter, BibRef, Author, Keywords, MesPM, MesPlx, MesVelocities
  • SEMAINE VII

  • 16.
    • Ecriture des requêtes SQL de récupération des données

  • 17.
    • Correction de l'ontologie: suppression de la classe OTypes, changement des relations entre BasicData, OType et OTypeDef: relation entre BasicData et OType, et entre OType et OTypeDef
    • Correction des requêtes SQL de récupération de données: jointures avec toutes les classes associées à la bibliographie (Author, HasBibRef, BibRef et Keywords) quand on récupère les tables de données de Flux, de MesPlx, de MesPM et de MesVelocities
    • Limitation du nombre de données sur oid4: jointure sur BasicData.oid4 dans toutes les requêtes et oid4 séquentiel -> filtrage possible, par exemple oid4 < 500 pour commencer
    • Problème: dans la récupération des parties biblio associées à des mesures, beaucoup de lignes similaires (1 seule donnée change, ex liste d'auteurs) -> quelle solution ?
    • Ecriture d'un script de test, convertissant uniquement la table BasicData, sans aucune relation: script_basic_data.py

  • 18.
    • Lecture de documentation sur l'indexation spatiale dans un triplestore: 1, 2 (pas très digeste)
    • Recherche d'un triplestore ayant des capacités spatiales incluses: Strabon par exemple
    • Modification de la manière de récupérer les données (jointure pour récupérer les bibliographies des mesures notamment)
    • Modification de l'ontologies Simbad: inversion du sens de la plupart des relations (sera probablement plus pratique à utiliser dans les scripts, puisque les différentes tables pointent toutes vers basic_data à travers oid4)

  • 19.
    • Modifications du modèle d'ontologie
    • Ecriture des scripts de traduction csv vers ttl
    • Modification des requêtes SQL de récupération des données
    • Tests sur Blazegraph: plusieurs problèmes:
    • 1. certaines IRI possèdent un espace, ce qui est interdit
    • 2. certains attributs (abstract notamment) contiennent des " ou des \ , ce qui ferme l'objet

  • 20.
    • Correction des scripts afin qu'ils ne causent plus de problèmes:
    • 1. Les espaces dans les IRIs sont remplacées par des underscores par un script annexe
    • 2. De même, les " sont remplacés par des ' et les \ par des / par un script annexe
    • Lecture de la documentation Blazegraph sur son support Geospatial

  • SEMAINE VIII

  • 23.
    • Modification des scripts et de l'ontologie afin d'intégrer le healpix à basic_data
    • Ecriture d'un script permettant d'exécuter les autres scripts: scrit_full.py renvoit ouptu_full.ttl
    • Lecture de documentation sur Healpix

  • 24.
    • Ajout de la table identifiers à l'ontologie et aux scripts
    • Explications sur Healpix
    • Ecriture de requêtes SPARQL
    • Problème d'installation d'astropy_healpix -> résolu

  • 25.
    • Ecriture d'un script Python de récupération des HEALPix d'une région
    • Calcul du HEALPix d'une donnée fait en entrée du fichier de conversion
    • Ecriture de requêtes SPARQL
    • Perte du fichier des requêtes SQL: début de réécriture

  • 26.
    • Fin de la réécriture des requêtes SQL
    • Modification des données afin de n'avoir que des caractères ne posant pas de problème à Blazegraph (en particulier utilisation de '$' comme délimiteur dans les fichiers csv)
    • Modification du script position: renvoie la requête SPARQL complète
    • test avec 10 000 entités: fichier de 95Mo, environ 1,4 millions de triplets dans Blazegraph

  • 27.
    • Essai de test avec 100 000 entités: bug avec le calcul de HEALPix
    • Modification du script de recherche en cône, avec conversion appropriée arcsec/radian
    • Optimisation de script_basic_data.py: utilisation d'un dictionnaire pour les identifiants secondaires

  • SEMAINE IX

  • 30.
    • Review du rapport de stage avec Mireille
    • Correction de mes scripts
    • Tests:
    • 100 000 entités: fichier de 1 Go, 14,5 millions de triplets
    • 1 000 000 entités: fichier de 13,5 Go
    • Traduction de requêtes SQL en SPARQL

Août

  • 1.
    • Amélioration du rapport
    • Correction des scripts: filtrage sur les caractères non autorisés sur toutes les tables

  • 2.
    • tests avec 1 million d'entités: 170 millions de triplets -> plus rapide d'upload les tables séparément plutôt qu(un unique fichier contenant toutes les tables
    • Amélioration du rapport

  • 3.
    • Correction du script permettant de faire une recherche dans un cône
    • Lancement de la récupération de toute la base SQL
    • Ajout des attributs sp_type et des relations de hiérarchie (childOf)
    • Test de requêtes SPARQL

  • SEMAINE X

  • 6.
    • Ajout des liens de parenté et des sp_type
    • Tests sur la manière d'implémenter les id_princ
    • Amélioration de la recherche dans un cône (profondeur adaptée au rayon souhaité)
    • Fin de la récupération de la base de données SQL

  • 7.
    • Toutes les données ont été récupérées et converties
    • Tests sur la manière d'implémenter l'héritage
    • Modification de la recherche dans un cône: 4 profondeurs différentes indiquées sur une BasicData, et profondeur choisie selon le rayon entré dans la requête
    • Ecriture du rapport

  • 8,9. & 10.
    • Upload des tables sur Blazegraph
    • Ecriture du rapport
    • Ecriture de la présentation
    • Derniers tests: héritage, nombre de triplets

Liens

  • ...

Versions testables

  • ...

Documentation

  • ...

Travail post stage éventuel

  • ...

Liste des améliorations à envisager

  • ...

Bugs connus

  • ...
Topic attachments
I Attachment Action Size Date Who Comment
Texttxt formats.txt manage 13.8 K 2018-06-12 - 06:48 UnknownUser Comparaison entre les formats de sérialisation RDF supportés par Blazegraph
PDFpdf reunionprovenanceRDF20180611_.pdf manage 12.0 K 2018-06-12 - 12:41 UnknownUser compte rendu première réunion
Topic revision: r82 - 2018-08-10 - LucasHolzmann
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback