VizieR 2 - ingestion des données tables

Réunion préparatoire VizieR2

Slides de la réunion CDS (20 mars 2018): vizier2.pdf

But de la nouvelle version: framework plus intégré au service du CDS et plus modulable!
On se focalise aujourd'hui sur le coeur de VizieR: l'ingestion des données.

De quoi il s'agit ?

• Refonte de l'ingestion des données table dans VizieR
• Il s'agit principalement d'une migration technique

• Il ne s'agit PAS de l'accès aux données (service, page web…)
• Ce n'est PAS dans le but d'améliorer le travail de documentation
• Il ne s'agit PAS de révolutionner les méthodes d'ingestion
  Commentaires: les methodes actuelles sont bien rodées et les documentalistes sont a l'aise avec les outils en cours.
  
  • le fichier de configuration en LaTeX est conservé: il constitue un langage permettant de manipuler les tables
  • l'utilisation de macro LaTeX en formattage des données en sorties (ex: customization des textes: couleurs, gras...) n'est pas compatible avec les technologies d'aujourd'hui (javascript, CSS..)

• Adopter les nouveaux standards
  • Domaine temporel : ajouter le temps comme nouvel axe de recherche et proposer des sorties VizieR avec le futur modèle VO
    Commentaires:il s'agit d'un sujet ou VizieR est attendu et deviendra prioritaire une fois un standard VO adopté.
    
    • forte implication du CDS (A.Neubot)
    • une sortie utilisant des metadonnees temporelles pour Gaia est en cours
      
  • Passer en Full TAP (VO)
    Commentaires: la fragilité de TAP en tant qu'architecture a ete mis en question -
    Sans aller juqu'a utiliser TAP en ebackground, il s'agirait de donner un acces SQL au programme VizieR pour toutes les tables.
    La derniere version VizieR est un pas dans ce sens puisqu'elle connecte la base TAPVizieR pour interroger les grands catalogues.
    L'idée est de pousser plus loin : intégration d'un index positionel pour chaque table, possibilite d'interroger les grandes tables y compris sur les mirroirs...
    Cela permettrait de rendre la base VizieR "compatible ADQL" en interne.
  • Passer en UCD1+
    Commentaires: cela ne pourra se faire que si des outils similaires a ceux existant pour les UCD1 sont développés!
  • DOI/ORCID
    Commentaires: les ORCID peuvent etre récupérés dans les formats XML des journaux de l'AAS
• Amélioration du système d'information
  • Conservation de la précision originale en base avec formatage
    Commentaires: sujet critique et demandant encore reflexion.
    • On a bien noté la différence entre données stockées (en base de données) , données affichées (page web) et données pour le calcul (avec plus de précision)
    • Une sdistinction remarquée aussi dans les journaux ou il existe des preview de tables avec des precisions tronquées par rapport aux données telechargeable pour le meme journal
    • Quelques remarques pour les tables FITS ou l'infromation de precision n'est que rarement précisé dans les headers
    • proposition d'ajouter 3 decimales supplémentaires aux données en base pour les calculs
  • Rationalisation de la gestion des données originales
    Commentaires:
  • indexation globale positionelle avec prise en compte des époques
    Commentaires: problématique plus large que le cas VizieR - quelque pistes (recherche) dans le service de crossmatch mais rien de concret encore...
  • Statistiques sur les data
    Commentaires: projet de TAP (VO) dans le futur, il s'agirait de remonter des infos minimales : min, max, moyenne.
    Certaines de ces informations sont presentes dans le ReadMe mais non remonté en base et le programme VizieR.
    Le service grand catalogue est pris comme exemple pour ses extractions de statistiques
  • Revoir la gestion des mots clés
    Commentaires: 3 niveaux de mots clés : mots clés editeurs +ADC keywords standard + mots clés VizieR
    la gestion des mots clés n'est pas prioritaire - attente de feedback de la recherche intuitive si elle est revue!
• Intégrer VizieR dans le framework du CDS
  Commentaires: prioritaire
  • Améliorer l'indexation spatiale
    Commentaires: le niveau QBox 8 utilisé dans VizieR est trop faible!
    • le passage à HEALPix est une evidence pour une prochaine version
    • l'indexation globale pourra etre basé sur les MOCS: service CDS MOC? transposition des tables METAcell VizieR Qbox en Healpix? utilisation de la librairie postgreSQL MOC de M.Nullmeyer?
      Quelques doutes sur la librairie postgreSQL MOC ont ete soulevées
  • Interfacage grands catalogues
    Commentaires: des librairies notamment pour l'extraction de statistiques peuvent être intéressante à généraliser
  • partage des moyens (librairies) et ouverture du code
    Commentaires: voir dans la section technique
  • Points additionnels: nécessité d'homogénéiser les différentes "sorties" des données VizieR (noms des colonnes, ordre, liste par défaut, liens associés aux colonnes,etc) (PF)
    
• Evolutions technologiques
  • Migrer la “recherche intuitive” vers une nouvelle technologie : il s'agit ici des utilitaires parfile et findcat utilisé dans le "moteur de recherche" VizieR
    Commentaires: quelques recherches deja effectués avec ElasticSearch - c'est un bon candidat pour remplacer les fichier parfile
  • migration langage pour améliorer la maintenance:
    Commentaires: voir dans la section technique

Evolution techniques

De manière générale:

• il est important que VizieR ne s'isole pas: une contribution interne (participation d'autres ingenieurs du CDS) et complémentaire (contractuel?) est primordiale
  Commentaires: VizieR2 ne se fera pas avec une seule personne!
• il a été souligné qu'il serait bien d'uniformiser les méthodes d'accés VizieR en évitant les segmentations rendant l'utilisation de VizieR "floue"
• l'utilisation du langage est au coeur du débat!
  plusieurs langages peuvent ils etre envisagés?
  Commentaires: l'idée d'utiliser plusieurs langages pour l'ingestion n'a pas ete pour le moment envisagée; elle demande reflexion.
  L'avantage etant d'utiliser le langage le plus adapte pour chaque spécialisation. Cela permet aussi plus de souplesse pour les developpeurs souhaitant s'impliquer.
  Mais cette segmentation du travail d'ingestion est elle faisable ? - ceci n'est pas évident.
  exemple; une segmentation en 2 parties : generation des tables (jointure/concatenation/ajout de colonne calculees) et la mise en place des metadonnées?

• Base de données:
  • rationnalisation des schémas (technique) VizieR; viz1, viz2, ....en schemas fonctionnels
    Commentaires: par exemple reprendre comme schémas la hierarchie VizieR http://vizier.u-strasbg.fr/vizier/welcome/vizierbrowse.gml?designation
  • passer FULL TAP:
    Commentaires: recherche envisagée pour utiliser les Foreign Data Wrapper PostgreSQL pour interroger les données binaires grand catalogue
    l'utilisation de la librairie MOC PostgreSQL (M.Nullmeyer) est critiquée
  • UCD1+:
    Commentaires: nécessite des outils similaires à ceux utilisés pour attribuer les UCD1; qui s'en charge?
• La principale question est le choix du/des langages

• il a été souligné l'interet d'utiliser le même langage pour l'ingestion et l'exploitation des données: partage de librairie -
  en particulier les librairies d'astronomies (conversion unité, système de coordonnées..) et la couche META permettant de générer des requetes à partir des METAdonnées en base
• python a été comparé à Perl - effet de mode etc. ( un peu d'histoire (PF): en fait, ESIS - précurseur de VizieR développé entre autres par l'ESO et le CDS (94-95) - avait été entièrement écrit en Perl car à l'époque très bien coté dans la communauté astro. La réécriture complète en C (en 96) a été décidée par le CDS lors de sa reprise sous le nom VizieR car François F. et autres dév. du CDS se perdaient dans les modules de scripts Perl, les appels aux libs natives (Fortran, C), et que c'était trop lent)
  Commentaires: Python est plus strutcuré que PERL (un vrai langage objet) et est plus ancré dans la société scientifique. Le succès des librairies astropy, numpy l'illustre.

Utilisation au CDS

Disponibilité des librairies

Demande aussi de reflexions commune pour proposer une architecture de développement VizieR et prévoir un "debut" UML de l'application. Qui est interessé?