Retour SPIE / Interferometry forum

• très bon retour suite au talk de Xavier pdf en ligne
  • changement de mentalité vis-à-vis de l'ouverture des données réduites.
• sondage ~35 reponses (voir pdf ci-dessous) : intéret pour déposer et télécharger, soucieux des aspects de citation, souhait de données > L1, interet pour des outils de quicklook, moins pour un lien vers l'analyse. Opposition sur la diffusion des donnes de type image, ok pour des modèles. Retours ok sur le proto. Les utilisateurs sont pret a passer le temps necessaire pour que les données soient publiées.demande d'une demande d'embargo ajustable.
• discussion database
  • C54 propose de "recommender a l'ensemble des 1er auteurs qui publient d'associer leurs données"
  • ACTION: relayer ce message sur le site oidb
  • Chara n'aura pas la bourse pour les archives
    • prochaine action en octobre en les rencontrant
  • La condition pour diffuser des images reconstruites est qu'elles aient été publiées.
  • INSU EII ESO JMMC vont discuter de nouveau des aspects VLTI/interferometry Node center

• nouveaux contacts etablis :
  • OK: NPOI (Anderson)
  • a discuter: SUSI/PAVO (Ireland) ont des fichiers (pas au standard dont des FITS) disposant des principales informations -> viser un log au moins ?
  • le Keck dispose de données (contacter Raphael Millan Gabet?)

Statut actions notées depuis la dernière réunion de juin

Fait:

• Uploader les OIFITS au lieu de l'URL est à implémenter assez vite.
• Page d'accueil à rendre plus esthétique: bannières, logo, champ de recherche par objet, statistiques générales de la base (Guillaume)
• Preparer le formulaire de sondage de l"OIDB en 10 questions (XAvier)
• Documentation sur le wiki (à valider avec le backoffice) : bien décrire la soumission (notamment qu'un OIFITS produira une ou plusieurs granules) , les 3 niveaux de calibrations et interoperabilité (Xavier)
• Travail sur la récupération des meta-données de catalogue VIZIER qui sont non-standards/non-homogènes (Patrick)
• Resoumettre les catalogues VIZIER avec la nouvelle (ou l'ancienne si pas operationnelle)
  • ceux deja présent J/A+A/545/A130 J/A+A/559/A111 J/A+A/558/A24 J/A+A/558/A149 J/A+A/544/A91
  • ceux problématiques J/A+A/493/L17 J/A+A/536/A55 J/A+A/565/A71
• Mail Théo L0 CHARA a été envoyé, discussion avec lui au SPIE des metadata et de leur format (http://www.jmmc.fr/twiki/bin/view/Jmmc/Software/OiDbColumnsL0)

Reste a faire:

• Les keywords astronomiques définis pour la soumission sont constitués des 6 grandes catégories inspirées d'ArXiv et des sous-catégories utilisées dans bibdb
  • Il reste à laisser une ouverture (2-3 champs de texte) pour des keywords supplémentaires. envisager un nettoyage depuis le backoffice
• Hébergement est à discuter prochainement après les retours sur la soumission : problématique des doublons, de l'évolution des données dans la DB
• Le rôle du backoffice est aussi à spécifier, que va-t-on traiter au cas par cas ? Dans quelle mesure peut-on demander aux dataPI de modifier leurs données pour qu'ils soient parfaitement ingestibles pour l'OIDB ? Il permettra cependant de declencher des mises de doc ou source de données et d'obtenir avoir un suivi de l'historique de ces opérations.
• Consultation : requête par dataPI name est-elle à conserver ?
• Affichage des résultats :
  • montrer comment un OIFITS est éclaté en granules plutôt que d'avoir le même fichier OIFITS répété à plusieurs lignes.
  • organiser les résultats en différents tableaux: L0, L2, L3
  • Triage des granules par instrument, etc
  • OU rajouter la colonne calibration_level ? quid instrument_mode (vide pour l'instant dans la base)
  • Donner à l'utilisateur la possibilité de configurer les colonnes lui-même

Mise en ligne version beta : http://oidb-beta.jmmc.fr

Version "bac a sable" de données / fonctions en vue des prochains tests

• pas encore de detection de doublons (deux soumissions-> deux granules)
  • pas bloquant pour l'instant, on peut revenir facilement à l'état initial
• soumission avec validation pour les données de catalogues CDS operationnelle pour tests
  • l'utilisateur peut 'corriger' des infos sur les targets / instrument (pas de backoffice)
  • un retour est demandé pour trouver le meilleur chemin qui permettra de normaliser certaines informations tout en conservant les informations d'origines importantes.
  • par ex. c'est le bon moment pour remettre l'ensemble des granules liées et deja connues
  • Faire le point sur la soumission d'URL

Autres points

• les tags stylés et leur saisie avec suggestion depuis une liste.
• backoffice remanié pour démarrage des actions en tache de fond one-shot (surtout utile pour VEGA pour l'instant). Avec affichage de l'état de la tache. À terme on pourra utiliser la même base pour les vérifications automatiques sur les données.
• accès à la page backoffice limité aux seules personnes identifiées. À terme seulement quelques personnes privilégiées. Mécanisme à voir.
• le selecteur visible/near IR/mid IR.
• correction a revoir du problème remonté par Gilles (rev 1683).
• calibration level cochées pour la recherche par défaut (suggestion de Jean-Baptiste)
• correction bug target unknown #624 remonté par Myriam (pas encore comité)

Liste des nouvelles demandes / priorités

Urgent

• indiquer les dataPI/run ID PIONIER (JB)
  • et rajouter si possible un lien vers l'archive ESO qui donne la description du programme (abstract)
• au niveau technique, une fois les premiers tests réalisés, faire un point sur l'architecture d'oidb, identifier ce qui est fait, reste a faire en le rattachant aux fonctions demandées
• veiller a la protection des données de contact 'emails', système anti-spams.

Moyen terme

• Documentation technique des outils utilisés par OiDb, détail sur la façon de regénérer la base, communication cache-server
• decrire ce que l'on veut afficher comme infos (large program ?, objectif scientifiques ? résultats ?) sur la page des collections et mise en place niveau base de données / affichage web.
• Comment citer correctement les collections (acknowledgments) ?
• fournir la source de données des granules. Probablement a ratacher aux collections.
• fournir les stats de telechargement -> pas encore fait
• embargo : pour les soumissions manuelles l'oidb peut proposer une durée ajustable avec date limite bornée à 1 an à partir de la date de soumission des données sur OiDb.
  • indiquer au dataPi lorsqu'ils choisissent une date > periode d'embargo + date de l'obs
  • indiquer la date de disponibilité des données brutes (ESO=obs+1an, CHARA=obs+18mois).

Long terme

• offrir une notification automatique (flux RSS) pour avertir l'utilisateur des updates d'OiDb