Réalisation d un moteur de recherche en langage naturel.

Texte intégral

(1)IUT Nancy Charlemagne Université de Lorraine 2 ter boulevard Charlemagne BP 55227 54052 Nancy Cedex Département informatique. Réalisation d’un moteur de recherche en langage naturel.. Rapport de stage de DUT informatique Entreprise : Centre de Données astronomiques de Strasbourg. Aymon DesaintAcheul Tuteur : André Schaaff, Sébastien Derrière et Thomas Boch Année universitaire 2016–2017. 1.

(2) Remerciements Tout d'abord, je tiens à remercier l'ensemble du personnel de l'Observatoire de Strasbourg pour son accueil chaleureux, et plus particulièrement André Schaaff, mon tuteur, dont les indications et conseils m'auront été précieux tout au long de mon stage, ainsi que Mark Allen, directeur du Centre de Données Astronomiques (CDS), pour m'avoir accepté en tant que stagiaire. Je tiens aussi à remercier les membres du CDS, en particulier les cotuteurs Thomas Boch, ingénieur logiciel du CDS, qui m’a fourni un grand nombres de données et d’outils qui m’ont grandement aidé dans mon travail et Sébastien Derrière, astronome pour le CDS qui m’a permis de mieux comprendre les besoins des utilisateurs et les ambiguïtés liées à l’astronomie et à son vocabulaire. Enfin, je remercie PierreAlain Duc, actuel directeur de l'Observatoire, pour m'avoir permis d'assister aux nombreuses conférences qui y ont eu lieu durant la période de mon stage.. 2.

(3) Introduction. 4. Présentation de l’entreprise. 5. 1. L’observatoire de Strasbourg. 5. 2. Le CDS. 6. 3. Ma mission au sein du CDS. 7. Présentation du travail fourni. 8. 1. L’étude préalable. 8. a) L’interface déjà présente sur VizieR et SIMBAD. 8. b) Étude du langage naturel. 9. c) Le vocabulaire astronomique. 10. d) Les premières idées de conception. 13. 2. Le système de reconnaissance de vocabulaire. 14. a) Extraction de listes et implémentation Java. 14. b) Création d’une interface en ligne. 15. c) Les limites de la reconnaissance de Vocabulaire. 16. 3. Les Librairies et service intégrées au projet. 17. a) Le POSTagger de NLP Stanford. 17. b) L’application DJIN du CDS. 19. c) Le traitement des UCD. 21. 4. Le générateur d’ADQL. 22. a) La théorisation du SQL. 22. b) L’implémentation JAVA. 23. 5. La création des requêtes ADQL. 25. a) La création de la requête pour SIMBAD. 25. b) La création de la requête pour VizieR. 26. 6. Évolutions possibles du projet. 28. a) Corrections et ajouts mineurs. 28. b) Réutilisation du projet. 29. c) Vision sur le long terme. 29. Conclusion. 30. Annexe 1 : Gantt. 31. Annexe 2 : Capture du site. 32. Annexe 3 : Capture du site (suite). 33. Annexe 4 : Schéma de SIMBAD. 34. Annexe 5 : Un extrait de VizieR. 35. 3.

(4) Introduction Le CDS est un centre de données astronomiques reconnu par l’ensemble de la communauté astronomique international. Le CDS propose, au travers de ses services, des formulaires Web comportant des critères sur lesquels les scientifiques peuvent se baser pour effectuer leurs recherches. Ma mission est d’étudier une nouvelle manière de formuler une requête aux bases SIMBAD et VizieR : Un moteur de recherche en langage naturel. Le langage naturel est le langage courant, utilisé pour communiquer dans la vie de tous les jours. Dans notre cas le langage naturel utilisé sera l’Anglais, langue fondamentale de la communauté scientifique. Le but du projet n’est donc pas un produit fini, mais un début de réflexion portant sur un produit minimum viable1 (MVP), qui pourra être étendu par la suite. Ma mission se déroule donc ainsi : Etat de l’art concernant le langage naturel et les bases de données Création d’un prototype. de base concernant le lien entre langage naturel et la base de. données. Réalisation d’un MVP permettant d’avoir des réponses à certains types précis de question.. Le résultat étant une réflexion, le plan suit l’ordre chronologique des évènements afin de montrer l’évolution de la réalisation et les réactions face aux problèmes rencontrés. Le MVP est une stratégie de développement de produit, utilisée pour de rapides et quantitatifs tests de mise sur le marché d'un produit ou d'une fonctionnalité. Dans notre cas, pouvoir répondre à des questions simples. 1. 4.

(5) Présentation de l’entreprise 1. L’observatoire de Strasbourg L'Observatoire astronomique de Strasbourg est un Observatoire des Sciences de l'Univers2 (OSU) , une école interne et UFR de l’Université de Strasbourg, ainsi qu’une Unité Mixte de Recherche entre l’Université et le CNRS . Il est actuellement dirigé par PierreAlain Duc. Il est structuré en trois équipes de recherche et deux Services d’Observation de l’Institut National des Sciences de l’Univers3 (INSU), le Survey Science Centre d’XMMNewton (SSCXMM) et le CDS.. L'Observatoire a été construit en 1881 sur le campus historique de l'Université de Strasbourg et héberge la 3ème plus grande lunette de France par sa taille ainsi que le Planétarium de Strasbourg dont il a eu la responsabilité de 1986 à 2008 avant qu’il ne soit intégré au Jardin des Sciences de l'Université de Strasbourg.. L'Observatoire Astronomique de Strasbourg se doit de contribuer aux progrès de la connaissance par : ● l'acquisition de données d'observation ● le développement et l'exploitation de moyens appropriés ● l'élaboration des outils théoriques nécessaires Il est également chargé : ● de fournir des services liés à son activité de recherche ● d'assurer la formation des étudiants et des personnels de recherche ● d'assurer la diffusion des connaissances ● des activités de coopération internationale. 2 3. Définition et liste des OSU : http://www.insu.cnrs.fr/osu Statut et mission de l’INSU : http://www.insu.cnrs.fr/node/387. 5.

(6) 2. Le CDS Le CDS est labellisé depuis 2008 « Grande Infrastructure de Recherche » par le Ministère de l'Enseignement Supérieur et de la Recherche. Son statut d'OSU place l'Observatoire astronomique au cœur du dispositif national mis en œuvre par l'INSU.. Le CDS gère une des plus grandes base de données astronomiques au monde, avec en moyenne 400 000 requêtes par jour. Trois services forment le coeur du CDS :. Aladin, qui est un atlas interactif du ciel, permet de visualiser la voûte céleste grâce à des recoupements d'images provenant de diverses observations astronomiques, à l’heure actuelle il y a 50 TeraByte de pixels provenant de plus de 250 HiPS4.. VizieR, qui permet d'effectuer des requêtes non plus en se focalisant sur un objet précis mais en prenant comme base un ou plusieurs catalogues (comme le Sloan Digital Sky Survey5 par exemple). L'avantage offert par rapport à un système classique est qu'en se focalisant sur un catalogue, toutes les données que l'on récupère sont au même format. Il faut en effet savoir que la même information, voir le même objet, peuvent porter plusieurs dizaines de noms si l'on désire couvrir l'ensemble des catalogues. A ce jour le nombre de catalogues répertoriés dépasse 16000... SIMBAD est un service proposant une base de données centrée sur les objets astronomiques (comètes, nuages de gaz, etc...), permettant d'effectuer des requêtes sur cette base en se basant sur le nom, la position, ou certaines propriétés physiques de ces objets. Actuellement le nombre d'objets répertoriés dépasse 9 millions, et le nombre d'identifiants qui leur est associé approche les 23 millions. Hierarchical Progressive Survey : Un système de «carrelage» hiérarchique qui permet d’accéder, de visualiser et de parcourir les données et les images sans coupure visible. 4. Le Sloan Digital Sky Survey (ou SDSS) est un programme de relevé des objets célestes utilisant un télescope optique dédié de 2,5 mètres de diamètre situé à l'observatoire d'Apache Point. Site officiel : http://www.sdss.org/ 5. 6.

(7) 3. Ma mission au sein du CDS Les chercheurs du monde entier sont amenés à interroger VizieR et SIMBAD fréquemment, le CDS leur fournit donc des services en ligne pour effectuer des recherches,. Le but du sujet est de proposer une autre alternative pour les chercheurs : Un moteur de recherche en langage naturel, à la manière d’un Wolfram|Alpha6 mais spécialisé sur VizieR et SIMBAD. Ce dernier permettrait une recherche plus simple et ergonomique que ce qui existe déjà. A long terme, cela pourrait aussi être couplé avec un logiciel de reconnaissance vocale pour faciliter la recherche, pour les personnes handicapées ou pour faire des recherches en portant des lunettes de Réalité Virtuelle.. Le moteur de recherche étant destiné à la communauté scientifique, le langage impératif est donc l’Anglais, ce qui va aussi faciliter la recherche des librairies sur le langage naturel, car le monde scientifique Anglophone est bien plus présent sur Internet.. Je travaille dans la bibliothèque du CDS, sur un poste équipé de Linux, branché à un réseau interne avec un accès à Internet. Pour des soucis de réutilisation et de compréhension, le programme est entièrement réalisé en Java et en JavaScript.. Toutes les semaines une réunion avec mes tuteurs permet de faire le point sur les avancées de la semaine, des difficultés rencontrées et la direction du projet dans l’immédiat. Ce qui explique la forme hebdomadaire que le projet prend quand on fait son Gantt.7. 6. Moteur de recherche en langage naturel qui permet de chercher des informations sur un nombre de domaines très étendu, lien du site : https://www.wolframalpha.com/ 7 Voir Annexe 1. 7.

(8) Présentation du travail fourni 1. L’étude préalable a) L’interface déjà présente sur VizieR et SIMBAD. Pour commencer il faut faire un état des lieux des moyens de recherches déjà existant pour savoir lesquels peuvent être intéressants pour nous. Il existe plusieurs moyens différents d’interroger Simbad et VizieR.. Pour Simbad il existe : ● Recherche par Identifiant; ● Recherche par Coordonnées; ● Recherche par Critères (262 critères actuellement, mais seul 5 sont utilisables en même temps); ● Recherche par référence dans un journal, une étude; ● Recherche via une requête basique (Identifiant, coordonnées simple, ou bibcode); ● Script; ● Requête TAP8 en ADQL; ● VizieR marche sur un modèle analogue : ● Recherche par Mission; ● Recherche par longueur d’onde; ● Recherche par domaine astronomique; ● Recherche par description des colonnes; ● Recherche par données additionnelles; ● Requête TAP en ADQL;. 8. TAP : (Table Access Protocol), nom donné à un service permettant d’accéder à une base de données. La définition officielle a été posée par l’IVOA a ce lien : http://www.ivoa.net/documents/TAP/. 8.

(9) C’est la requête TAP qui nous intéresse, étant donné qu’elle nous permet de rechercher sur virtuellement n’importe quel critère, et permet de traiter de manière analogue les requêtes sur VizieR et SIMBAD. De plus le système TAP permet d’exprimer les requêtes dans un langage simple, l’ADQL, qui dérive du SQL. Le but du projet est donc désormais simplifié et vise à créer une requête SQL à partir d’une phrase entière en langage naturel.. b) Étude du langage naturel. Le traitement du langage naturel est un domaine aussi vieux que l’informatique, en effet la recherche concernant le langage naturel a débuté vers les années 1950, avec un article de Alan Turing9.. Le traitement des données en langage naturel a fait de grandes avancées récemment, avec notamment Siri ou Cortana qui traitent des questions posées en langage naturel et y répondent, ce n’est toutefois pas ces exemples qui nous intéressent ici, notre but étant de programmer un « traducteur » qui passe du langage naturel à l’ADQL. Il y’a eu deux grandes sources d’information qui m’ont aidé à comprendre la problématique du sujet.. La première est l’ensemble des travaux du groupe NLP (Natural Language Processing) de l’Université de Stanford qui propose, d’une part une large collection de vidéos en ligne sur les différents aspects du langage naturel. 10. , et d’autre part différentes librairies JAVA. permettant de faire d’extraire des informations d’une phrase en Langage Naturel. J’ai notamment utilisé leur POSTagger, je reviendrai dessus plus tard. Le groupe NLP a aussi mis en ligne sur Youtube un certain nombre de cours que j’ai suivi lors de la première semaine, on y apprend le sens de certains mots que j’ai mis en annexe.. 9. Mathématicien et cryptologue britannique, pionnier de la théorie scientifique de l’informatique. https://fr.wikipedia.org/wiki/Alan_Turing 10 Lien de la playlist sur le NLP : https://www.youtube.com/watch?v=nfoudtpBV68&list=PL6397E4B26D00A269. 9.

(10) La deuxième source est une étude de Benoît Couderc et Jérémy Ferrero11, portant sur un traducteur du français au SQL appelé « fr2sql ». Ce traducteur bénéficie d’une conception ne le limitant pas à une base de données et lui permettant d’être fonctionnel sur n’importe quelle base de données, la «faille» de leur système étant la gestion des synonymes et le fait que les tables doivent avoir un nom concret en langage naturel. Ce système est donc applicable mais pas sur une base aussi immense que celle du CDS, qui n’est pas prévue pour cela.. c) Le vocabulaire astronomique Pour pouvoir effectuer des recherches astronomiques, il faut savoir comment les formaliser. Pour commencer je me suis informé sur le système de coordonnées utilisé en astronomie. Le système de coordonnées le plus utilisé en astronomie est le système de coordonnées dit équatoriales. Un schéma est fourni en annexe pour aider à la compréhension. Ce système est formé de deux composantes : L’ascension droite (α) et la déclinaison (δ).. L’ascension droite est l'angle mesuré sur l'équateur céleste à partir d'un point de référence, le. point vernal, correspondant à une intersection entre l'équateur céleste et l'écliptique. À partir de ce point, l'angle est mesuré vers l'Est et comporte 24 divisions principales de 15 degrés(°) chacune, nommées « heures ». Chacune des heures se divise en minutes et en secondes.. La déclinaison est l'angle mesuré perpendiculairement entre l'équateur céleste et l'objet céleste observé. Elle se mesure en degrés, positifs pour les objets situés dans l'hémisphère nord et négatifs pour ceux de l'hémisphère sud. La déclinaison varie ainsi de 90° (pôle sud) à +90° (pôle nord) en passant par 0° à l'équateur céleste.. Lien vers la publication, « fr2sql : Interrogation de bases de données en français» par Benoît Couderc et Jérémy Ferrero, juin 2015 : 11. https://hal.archivesouvertes.fr/hal01165914/document. 10.

(11) Figure 1. Représentation des coordonnées équatoriales12 On peut voir sur la figure 1. la manière dont est situé le point vernal, cette figure permet aussi de mieux comprendre en quoi l’ascension droite et la déclinaison sont les équivalents astronomiques de la latitude et la longitude.. On notera aussi que dans le vocabulaire de l’astronomie, un identifiant peut avoir un sens différent si il est suivi par un nom de type d’objet astronomique. Par exemple : T Tauri est une étoile, mais le terme T Tauri stars fait référence à toutes les étoiles de type T Tauri. Il existe beaucoup de cas comme celuici, un autre exemple étant la constellation de la Vierge et l’amas de la Vierge, partageant le même identifiant : Virgo.. 12. Source : https://upload.wikimedia.org/wikipedia/commons/thumb/6/6a/Coordonnees_equatoriales.svg/495p xCoordonnees_equatoriales.svg.png. 11.

(12) Afin de mieux comprendre ce qui était attendu du programme, M. Derrière m’a fourni une liste de 17 questions qui seraient potentiellement posées :. 1. What is the redshift of 3C273? What is the redshift of the Virgo Cluster? 2. What is the parallax of Barnard's star? What is the distance of Barnard's star? What is the proper motion of Barnard's star? 3. What is the effective temperature of Sirius? 4. What are the galactic coordinates of Geminga? 5. Which galaxy interacts with NGC 4038? 6. Show me an image of the Pleiades in the K band 7. How many QSOs are there at redshift larger than 6? How many QSOs are there at z>6? 8. What is the redshift of galaxies members of the Virgo cluster? 9. Find globular clusters within 3° of M31. Find globular clusters in M31. 10. Query the latest Veron catalogue 11. What is the period of Algol? List of periods of Algoltype stars. 12. What is the effective temperature of T Tau? What is the effective temperature of T Tauri stars? 13. Find supernovae in galaxies brighter than V=12 14. How many planets orbit Kepler 20? 15. List of catalogues measuring surface gravity of giant stars 16. Get color thumbnails of Messier objects 17. List of galactic Xray supernova remnants. Parmi ces questions, j’ai essayé de trouver une structure qui revenait souvent. Les questions demandant une mesure donnée pour un identifiant donné sont au nombre de 7. Ce sont les questions 1, 2, 3, 4, 8, 11 et 12. J’ai mis en gras les couples identifiant/mesure de ces phrases. 12.

(13) d) Les premières idées de conception. Dans un premier temps nous avons décidé d’approcher le sujet comme un traducteur d’une langue à une autre, un peu à la manière de fr2SQL. Dans notre cas, la traduction s’effectue de l’anglais à l’ADQL. Toutefois c’est là que la comparaison s’arrête avec fr2SQL, en effet la méthode avancée par leur publication n’est pas réutilisable sur les bases de SIMBAD et VizieR. L’idée est donc venue de faire un «compilateur», en considérant l’anglais comme un langage source et l’ADQL comme un langage cible. Le problème de cette conception est que cela rend le traducteur très rigide. Une phrase sans point pourrait être considérée invalide par exemple, de fait l’utilisateur serait très contraint et il serait difficile de traiter tous les cas. Nous nous sommes donc concentré sur le cas particulier du CDS. L’outil que nous allons développer ne fonctionnera ainsi que sur les bases SIMBAD et VizieR, et a pour unique visée le domaine de l’astronomie. Cette contrainte nous permet de faire des choses plus spécifiques, comme faire une liste des différents vocabulaires utilisés en astronomie. 13.

(14) 2. Le système de reconnaissance de vocabulaire a) Extraction de listes et implémentation Java La base du système est composée de plusieurs fichiers textes de vocabulaire, contenant chacun un type de mot lié à l’astronomie. À l’heure de l’écriture il y’a: ● Les Auteurs dans Simbad ● Les Auteurs dans Vizier ● Les Missions (Vizier) ● Les Wavelength (Vizier) ● Les Objets Astronomiques (Simbad) Les Identifiants sont traités à part et ce avant même le traitement de la requête, grâce à un service en ligne que l’on abordera plus tard. Pour les bibcodes13 ou les coordonnées on a à disposition des expressions régulières que j’ai produites, voici celle pour les bibcodes : [09]{4}([Az.]|[09.]){5}[Az09.]{4}[Az09.]{6} 1974AJ.....79..819H : bibcode de W. D. Heintz, «Astrometric study of four visual binaries», The Astronomical Journal, vol. 79, 1974, p. 819825 1924MNRAS..84..308E : A. S. Eddington, « On the relation between the masses and luminosities of the stars », Monthly Notices of the Royal Astronomical Society, vol. 84, 1924, p. 308332. Ces listes sont directement extraites des sites de SIMBAD et VizieR, ou directement des bases de données. Les listes d’auteurs m’ont été fournies par M. Thomas Boch. J’ai dû les reformuler afin de les simplifier. 13. Code spécial utilisé pour référencer les ouvrages portant sur l’astronomie. Utilisé dans SIMBAD à l’origine, voir : https://fr.wikipedia.org/wiki/Bibcode. 14.

(15) En effet un ouvrage scientifique a un auteur, mais aussi des coauteurs, ainsi j’ai dû passer par la commande. «grep» du Terminal Linux afin de mettre chaque nom sur une ligne. séparée. Aussi, un auteur peut avoir écrit plusieurs ouvrages, j’ai donc utilisé à nouveau cette commande afin de filtrer dans la liste les doublons. On passe donc un à un les mots dans une série de méthodes qui déterminent si le mot appartient à une des listes ou non. Pour comparer des String on serait tenté d’utiliser la méthode «String.equals(String s)», toutefois j’ai décidé d’utiliser le système de calcul de distance de Levenshtein14. Cette distance est égale au nombre de permutations (ajout ou suppression) de caractères nécessaires pour partir d’un mot et en arriver à un autre. Par exemple, prenons le mot A = «examen», et le mot B = «examan», alors LD(A,B) = 1, car il faut remplacer le «a» par un «e». Ce système permet de ne pas pénaliser l’utilisateur s’il fait une petite erreur de frappe, il faut cependant faire attention à ne pas accepter de distance trop grande. Selon le type de vocabulaire, le programme accepte 1, ou 2 comme seuil maximum.. b) Création d’une interface en ligne Afin de pouvoir suivre et essayer le projet plus facilement, mes tuteurs m'ont demandé de réaliser une interface en ligne afin de tester le projet. Pour ce faire j’utilise un système d’AJAX qui fait le lien entre le code Java et un script JavaScript via un Servlet. J’utilise aussi NetBeans qui gère automatiquement la mise en ligne d’un projet sur un serveur GlassFish. Il est à noter que l’interface en ligne n’est disponible que depuis le réseau du CDS, c’est à dire qu’on ne peut pas y accéder depuis un point de connection externe au CDS. L’interface est composée d’une barre de texte pour écrire sa requête et d’un bouton pour valider sa requête. Une fois la requête traitée, les différents résultats apparaissent en dessous de la barre de texte sous forme d’un tableau présentant la requête ADQL effectuée avec les réponses obtenues.15 Vladimir Levenshtein : scientifique russe. Ses travaux portent en grande partie sur la théorie des codes, il est l’inventeur de la Distance de Levenshtein voir : https://fr.wikipedia.org/wiki/Vladimir_Levenshtein 15 Voir Annexe 2 et 3 14. 15.

(16) c) Les limites de la reconnaissance de Vocabulaire La reconnaissance de vocabulaire fonctionne très bien en principe, mais en pratique elle comprend un certain nombre de défauts.. D’une part, cette méthode ne peut pas être généralisée. Pour chaque catégorie de vocabulaire, il faut faire une liste précise de tous les mots pouvant y être compris. Faire une liste exhaustive est une tâche difficile en soit, et certains type de vocabulaires ne peuvent pas être listés. Par exemple les identifiants ne peuvent pas être listé car il en existe un nombre trop important.. D’autre part cette méthode pose un problème concernant l’ordre dans lequel on teste les vocabulaires. En effet un nom d’auteur peut être aussi un nom de mission ou d’objet à une lettre près. Dans ce cas on est obligé de faire un choix. Soit on abandonne la distance de Levenshtein mais dans ce cas on exige une grande précision de l’utilisateur, soit on décide de comprendre un mot de deux façons différentes, ce qui pousse un mot à tester tous les vocabulaires et ce même si on l’a déjà repéré. Ce qui veut dire que chaque mot de la phrase serait forcé de passer par les 1733066 lignes de vocabulaire pour les auteurs. Ce qui représente un temps de calcul bien trop important.. Il existe des moyens pour effectuer la seconde solution (comprendre de deux manières différentes) de manière beaucoup plus optimisée : lier les vocabulaires à leurs nature grammaticales. En effet, un verbe ne peut pas être un objet spatial. Cette amélioration permet de raccourcir grandement le temps de calcul, mais il faut alors trouver un moyen de déterminer la nature grammaticale de chaque mot.. 16.

(17) 3. Les Librairies et service intégrées au projet a) Le POSTagger de NLP Stanford Le POS (acronyme pour PartofSpeech) est l’équivalent anglais de la nature grammaticale. Le POSTagger fixe donc un tag (deux ou trois lettres) sur les mots d’une phrase, selon leur nature grammaticale. Voici le tableau des tags utilisés.. 17.

(18) Ce tableau est directement tiré du Penn TreeBank16. Un TreeBank est un grand corpus parsé et annoté sur sa sémantique et ses schémas grammaticaux, qui permet de relever des données sur une langue en particulier.17. La bibliothèque est facilement utilisable, il suffit de l’installer dans son projet avec l’IDE de son choix et de l’appeler correctement. Voici un exemple d’appel à la librairie :. Le String tagged correspond à la phrase dans laquelle derrière chaque mot on a mis «_TAG». Par exemple, la phrase. «What is a star?» deviendra «What_WP is_VBZ a_DT star_NN. ?_. » Il est donc facile de créer une liste avec un type contenant le String et son Tag, en effectuant un «String.split(” ”)» puis un «String.split(”_”)» sur chaque mot de la phrase. On peut ainsi déterminer des informations supplémentaires pour la recherche et optimiser les vocabulaire comme expliqué plus haut. Toutefois ces améliorations ne permettent toujours pas de gérer les identifiants de manière viable.. 16. Lien du guide pour les tags du Penn Treebank : http://www.cis.unimuenchen.de/~schmid/tools/TreeTagger/data/PennTreebankTagset.pdf 17 Le Penn Treebank est disponible à cette adresse, et coûte 1700$ : https://catalog.ldc.upenn.edu/ldc99t42# Pour plus d’exemples, dont certains sont libre de droit, voici la page wikipédia référençant les TreeBank pour diverses langues https://en.wikipedia.org/wiki/Treebank. 18.

(19) b) L’application DJIN du CDS DJIN est un service permettant aux documentalistes de traiter plus facilement les publications scientifiques. Dans le cadre de mon sujet, il existe une fonctionnalité intéressante du service : Une requête vers le serveur permet d’extraire un identifiant dans un texte. Par exemple cette requête :. nous renvoie la réponse suivante en JSON:. C’est donc un moyen parfait de gérer les identifiants sans avoir à gérer un dictionnaire d’identifiant, qui serait invraisemblable avec l’implémentation actuelle.. L’essai de l’implémentation JS : J’ai d’abord essayé de placer l’appel au service juste avant l’envoi de la chaîne de caractères du JS au JAVA. Un appel au service juste avant de faire l’appel au serveur GlassFish donc. Le principal problème attendu étant la synchronisation des deux requêtes puisque la requête au JAVA doit contenir des informations venant de la requête à DJIN. Ce n’est pas ce problème qui a finalement été le plus gênant. Un autre problème s’est posé : le programme fait une requête Cross−Domain. On dit d’une requête qu’elle est CrossDomain quand elle part d’une adresse HTML pour aller vers une autre adresse qui ne fait pas partie du même domaine. Or, ce type de requête est par défaut bloquée par les serveurs, celui de M. Kaestle ne fait pas exception, au vu de mes essais. Je n’ai trouvé aucun moyen de faire une requête CrossDomain sur son serveur mais peutêtre y atil une solution que je n’ai pas trouvée.. 19.

(20) L’implémentation JAVA et l’encodage des requêtes : J’ai donc décidé de faire la requête dans le code JAVA via la classe «HttpURLConnection» de la librairie «java.net». Le problème principal de cette méthode réside dans la complexité de l’encodage des adresse url demandée par JAVA. Par exemple, voici la même requête que plus haut encodée de manière conforme pour JAVA.. Il existe donc naturellement des méthodes pour effectuer la traduction, il faut cependant faire attention à la proportion de la requête qu’on envoie à cette méthode. En effet donner le nom de domaine en entier avec la requête marche mal, car le nom de domaine est alors réencodé et n’est plus lisible. Enfin il reste à traiter le résultat obtenu. C’estàdire, transformer le String en un objet JSON exploitable et retirer les identifiants détectés de la phrase. J’ai mis cidessous le code JAVA effectuant le traitement.. 20.

(21) La question des identifiants étant maintenant réglée, la deuxième priorité en terme de traitement particulier est le vocabulaire des mesures et des types de valeurs.. c) Le traitement des UCD. Lorsqu’ils posent une question au portail, les scientifiques demandent souvent une mesure, comme une température ou un angle par exemple. Il est crucial de savoir quelle est la mesure demandée, et où la trouver. Il faut aussi avoir un système de nomenclature qui soit identique entre les services sinon les cas particuliers seraient trop nombreux à traiter. Ce système existe au CDS, il s’agit des UCD (Unified Content Descriptors). Un UCD est une étiquette composée de plusieurs mots qui permet d’identifier un type de valeur. Les UCD sont au nombre de 473, ils sont rangés dans un arbre catégorie par catégories. La température effective par exemple a pour UCD «phys.temperature.effective» , cela veut dire que la valeur est une mesure physique, que c’est une température et qu’elle est effective. Cela marche ainsi pour tous les types de valeurs que l’on peut retrouver dans les bases de données du CDS.. Ainsi, chaque colonne, de chaque table, de chaque base de donnée a un UCD qui lui est attribué, en fonction de la valeur que représente cette colonne. Il existe déjà en ligne un service qui permet de passer d’une description à un UCD à cette adresse : http://cds.unistra.fr/UCD/cgibin/WS_suggest Le problème de ce système réside dans les mots «parasites» que l’on lui donne. Par exemple la phrase «What is the effective temperature of Sirius?» ne contient comme mesure que «effective temperature» le reste ne peut pas être une mesure, cela peut être mis en évidence par leur nature grammaticale. En effet, un verbe, un Whpronoun ou un déterminant, par exemple, ne peuvent pas être des mesures. De même un identifiant ne peut pas être une mesure, donc les deux librairies susmentionnées nous permettent d’assurer la viabilité de la reconnaissance de la mesure, en ne donnant dans la requête que «effective temperature» les autres mots étant ‘éliminés’ au préalable.. 21.

(22) 4. Le générateur d’ADQL a) La théorisation du SQL. Afin de générer du SQL il faut d’abord comprendre le squelette basique d’une requête. Le squelette du SQL : J’ai trouvé un modèle de requête SQL dans un document de présentation de l’ADQL disponible en ligne, le voici.. Ici, 3 motsclés vont beaucoup nous intéresser.. Le mot SELECT permet de cibler les données retransmises par la requête,notre générateur devra donc se baser sur le type de données voulues dans la question.Donc c’est grâce aux UCD que l’on va pouvoir le générer. Le mot FROM est plus complexe que les deux autres, en effet produire une correspondance entre la question posée et une table en particulier semble assez problématique, nous nous baserons donc sur les besoins du SELECT uniquement, pour le moment le FROM se base toujours sur la table «basic» de Simbad, avec différentes jointures.. 22.

(23) Le mot WHERE permet de cibler des conditions mises sur les colonnes du select. Dans notre cas, le where va servir à retranscrire les différentes conditions de la question. Par exemple, la phrase «What is the effective temperature of Sirius?» se découpera ainsi :. b) L’implémentation JAVA J’ai décidé de faire une implémentation assez basique, ne comportant aucun lien d’héritage, afin de simplifier au maximum la compréhension et la lisibilité du code.. 23.

(24) Le but de cette implémentation est de faciliter la génération d’un String, par conséquent chacune des classes crées possède une méthode «String toString()» personnalisée. Voici un schéma UML de mon générateur.. Nous avons donc une classe ADQLQuery qui comporte un SELECT, un FROM et un WHERE. Cette manière de découper le travail permet de se concentrer sur chacun des mots clé indépendamment. Une classe pour formuler des conditions s’est avérée importante dès lors que l’on s’intéresse à la jointure des tables sur FROM. Cette classe permet alors de factoriser le code entre Where et From, qui utilisent tout deux des conditions.. 24.

(25) 5. La création des requêtes ADQL Comme expliqué plus haut, les trois mots clé importants sont SELECT, FROM et WHERE, je vais donc expliquer la génération de ces trois parties, toutefois la génération est différente pour SIMBAD et pour VizieR.. a) La création de la requête pour SIMBAD. Le select est basé sur les types de valeurs demandées donc c’est grâce aux UCD que l’on va pouvoir le générer. Un XML comprenant la ‘carte’ de toutes les tables de SIMBAD est disponible sur le site du CDS. Sur cette ‘carte’, chaque colonne de chaque table, contient l’UCD qui leur est assigné, ainsi par une recherche sur l’UCD de la valeur demandée on peut récupérer la colonne nécessaire. On ajoute au Select l’id de l’objet observé afin de rendre la lecture plus simple, et on limite aux premières 100 réponses, afin de ne pas prendre trop de temps. Le FROM se gère donc grâce au SELECT, car si l’on a repéré la colonne, on a aussi la table qui va avec. De plus SIMBAD étant articulé autour d’une table centrale nommée basic, qui permet de faire la jointure entre la majorité des tables sur «oid=oidref»18 on l’ajoute, ainsi que la table Ident qui permet d’avoir un identifiant lisible pour l’utilisateur. Le WHERE ici va servir à filtrer les résultats, ce sera principalement utilisé pour filtrer sur l’identifiant, et pour filtrer les lignes n’ayant pas de valeur pour la colonne demandée. Par exemple; la phrase «What is the effective temperature of Sirius?» nous donnera cette requête :. 18. Voir Annexe 4. 25.

(26) b) La création de la requête pour VizieR La requête pour VizieR est bien plus problématique à formuler. En effet VizieR n’est pas articulé autour d’une table centrale, et la taille de Vizier est trop grande pour avoir un XML détaillé des tables. En revanche M.Thomas Boch m’a fourni une table reliant toute les colonnes de toutes les tables de Vizier à leur UCD. Pour donner un ordre de grandeur, l’XML de SIMBAD contenant toutes les colonnes de toutes les tables prends 3946 lignes. Le fichier csv faisant le lien entre Table UCD et Colonne pour VizieR fait 529 926 lignes, ce qui est plus de 130x plus grand.. Toutefois le lien logique UCD=>Colonne utilisé pour les recherches dans SImbad ne fonctionne plus dans Vizier. Le seul moyen de trouver la colonne se fait par le lien UCD,Table=>Colonne. En effet chaque table peut contenir la mesure voulue, il faut donc savoir de quel table nous avons besoin avant de faire la requête.. C’est ici qu’interviennent deux services du CDS. Le premier est Sesame, qui permet d’obtenir les coordonnées d’un objet astronomique à partir de son identifiant. Le deuxième service permet de trouver toutes les tables de VizieR qui contiennent des objets aux alentours d’une coordonnée donnée. En combinant ces deux services, on parvient alors à trouver le nom de la table nécessaire pour chercher le nom de la colonne. Toutefois on peut avoir un nombre de tables correspondantes assez grandes. On fera alors une requête par table, car les jointures sont impossibles à automatiser dans VizieR.. Nous avons désormais la colonne pour le SELECT, et la table pour le FROM, il nous reste maintenant à déterminer un critère pour ne récupérer que l’objet recherché. Les colonnes ‘id’ des tables VizieR n’étant que rarement égales aux identifiants utilisés, l’identifiant n’est pas utilisable tel quel. On décide alors d’effectuer un filtrage sur les coordonnées, en effet ces coordonnées peuvent être trouvées grâce à la table csv, car elles ont un UCD précis. 26.

(27) Toutefois cette méthode met trop de temps, la recherche sur VizieR selon des critères dans une table est bien trop longue, en effet pour la question: «What is the effective temperature of Sirius?» une des tables trouvée grâce à la méthode énoncée plus haut fait 2 143 475 885 lignes. Un exemple du contenu d’une de ces tables est disponible en annexe.. 19. Pour cette. question la requête suivante :. Met plus d’une dizaine de minutes à s’effectuer, ce qui met le programme en attente. Cette durée est dûe à une formulation inadaptée de la requête. En effet l’avantage de l’ADQL par rapport au SQL est l’ajout de nombreuses fonction de géométries, VizieR a été conçu dans le but d’optimiser l’utilisation de ces fonctions.. Ainsi, si la requête précédente met 10 minutes à aboutir, la requête suivante elle, ne met pas plus de 10 secondes pour se compléter.. 19. voir Annexe 5. 27.

(28) 6. Évolutions possibles du projet a) Corrections et ajouts mineurs Une modification à court terme serait d’utiliser plus le système de Vocabulaire mis en place. Dans le MVP, le code est déjà présent mais n’est pas utilisé, en effet nous avons concentré les efforts sur les questions comprenants un identifiant et une mesure. Les types d’objets astronomiques, les missions, les types d’émissions sont autant de vocabulaires qui existent déjà dans le projet mais ne sont pas utilisés. De même la liste des auteurs contenus dans SIMBAD et VizieR pourrait permettre d’implémenter simplement une recherche de catalogue par auteur en quelques semaines.. La mise en forme de la réponse est très brute mais contient beaucoup d’information nécessaire au débuggage. On pourrait mettre en place une disposition plus confortable des informations récupérées pour l’utilisateur.. Enfin un système pour laisser l’utilisateur lever lui mêmes les ambiguïtés quand il y’en a. Ce système devrait être réalisable en quelques semaines. En découpant la méthode «Main» en deux, juste avant la construction des requêtes, et en demandant à l’utilisateur ce qu’il souhaitait chercher avant de lancer une quelconque recherche.. 28.

(29) b) Réutilisation du projet Un nouveau stagiaire est arrivé lors des dernières semaines du stage, son sujet prends en quelques sortes la suite du mien, ainsi j’ai commenté mon projet pour permettre une relecture plus simple. Ce dossier lui servira aussi afin de comprendre les choix effectués dans le projet. Son but envisagé pour le moment est de réaliser un «chatbot», une interface à la manière d’une messagerie mais l’interlocuteur sera, à la place d’un humain, une version révisée de mon projet. Le premier but envisagé par l’équipe lors de la réunion de transition entre les deux projet, est la création d’une «base de transformation» qui permettra de combler le manque de certaines mesures dans les bases, en les calculant à la volée grâce à des mesures existantes.. c) Vision sur le long terme. Sur le long terme le projet a pour but d’implémenter un portail intelligent qui ferait gagner beaucoup de temps aux chercheurs en leur donnant une manière simple, ergonomique et efficace d’effectuer leurs recherches.. L’exemple qui a donné l’inspiration pour ce projet est Wolfram|Alpha, en effet ce moteur de recherche intelligent se forme lui même. C’estàdire qu’en fonction des recherches des utilisateurs il modifie son fonctionnement, cela peut être simplement la mise en avant des résultats plus populaires dans le cadre d’une ambiguïté, mais aussi une mise à jour des données en fonction des résultats trouvés par le calcul afin de ne pas avoir à recalculer.. Le but du CDS est d’arriver à une version fiable, utilisable avec un système de reconnaissance vocale afin d’expérimenter le portail avec les nouvelles technologies telles que la Réalité virtuelle.. 29.

(30) Conclusion En conclusion, ce stage a été plus complexe d’un point de vue conception que d’un point de vue technique. Le sujet était assez large et une des problématiques principales que j’ai eu à traiter était le choix de l’angle d’approche du problème. Ce choix a été motivé par les outils et les solutions qui étaient à ma disposition.. Au niveau personnel, j’ai appris à chercher des informations et à faire le tri des choses superflues, en effet le langage naturel est un domaine très complexe avec beaucoup d’études, mais seul une petite partie de ce que j’ai appris m’a servi réellement dans la programmation. Le même chose est valable pour les différentes options que les services du CDS m’offraient.. 30.

(31) Annexe 1 : Gantt. 31.

(32) Annexe 2 : Capture du site. 32.

(33) Annexe 3 : Capture du site (suite). 33.

(34) Annexe 4 : Schéma de SIMBAD. 34.

(35) Annexe 5 : Un extrait de VizieR. 35.

(36)