OiDbReunion26June2013 < Jmmc/Software

-- Main.XavierHaubois - 29 Jun 2013



---+ Objectifs de la réunion du 26/05/2013

   * Définir les metadonnées pour les données L0 et L2
   * Définir le formulaire que les PI vont remplir pour archiver leurs données L3 et L2 et metadonnées L0.
   * Avancer sur la condition d'accès aux données : toutes les données sont-elles visibles ou visiblilité restreinte aux données gérée par le PI ?
   * Décider du ou des critères de qualité des données : commentaire du dataPI + web 2.0 ?
   * Avoir itérer sur un document à envoyer aux PI des instruments (PIONIER, VEGA, MIRC,MIDI, NPOI,SUSI, IOTA) : re-présenter l'intérêt du projet, détailler le fonctionnement de la base de données, aborder les notions de dataPI, de droits d'accès aux données, de diffusion en temps réel des métadonnées L0. Voir draft du document ci-joint :
   

---+ Compte rendu de la réunion

Présents : Laurent Bourgès, Gilles Duvert, Xavier Haubois, Guillaume Mella, Nicolas Nardetto, Johan Olofsson

Excusés : Olivier Chesneau, Sylvestre Lacour, Denis Mourard, Myriam Benisty, Jean-Baptiste LeBouquin, Philippe Berio, Sylvain Lafrasse

But : Définition du projet d'archivage et mise en place d'un cahier des charges de solutions techniques pour que l&#8217;équipe technique puisse débuter en septembre. 


   * Question du stockage des données L2 remis en question. S'il est difficile d'estimer leur qualité, il faut se laisser la possibilité de les diffuser pour susciter les collaborations. A terme, toutes les données AMBER L2 devraient se trouver sur la base de données.

   * Informations de citation à inclure dans la base.


Des questions importantes restent à discuter plus amplement (sur le twiki ou échange sur la mailing liste) et à mettre par écrit :

   * Confidentialité/gestion des droits d'accès aux données et métadonnées.  

   * Définition PI instrument/dataPI:  qui décide de partager les données et métadonnées sur notre base ? Il y a-t-il besoin de l'accord du PI de l'instrument pour diffuser les données L2 ? Il faut peut-être laisser la liberté à chaque équipe de choisir qui fait quoi de leur côté. De notre côté (base de données), nous devons préciser ce à quoi s'engage celui qui nous fournit les données. C'est la notion de dataPI que nous devons clarifier -> itération sur les paragraphes correspondant dans le draft du document ci-dessous.

--> Pour ces deux premiers points, il faudra sans doute aboutir à une charte d'utilisation de la base de données à laquelle tout data provider et utilisateur devra agréer. Faut-il avoir une même charte pour tous ou avoir droits spécifiques pour chaque instrument (ex : la période propriétaire des données peut-elle être la même pour l'ESO que pour MIRC) ?


   * Notion de cycle de vie d'une archive dans la base : 
Après réduction et calibration, des données L0 vont engendrer des données L2 et plus tard L3/L4. Comment faire apparaître cette évolution, ce lien entre archives dans la base de données ?
Pour une observation, les métadonnées correspondant à l'étape de réduction (sélection en canaux spectraux, en intervales temporels,critère de qualité, version du logiciel de réduction, etc) peuvent venir préciser les métadonnées L0 pour constituer les métadonnées L2. Bien sûr, ce ne sera pas toujours possible d'avoir les métadonnées L0 correspondant aux archives L2.Par ailleurs, les métadonnées issues des keywords des fichiers oifits sont parfois écrasées, altérées. Différents scénarios sont à mettre à plat -> notion de qualité des métadonnées (bonne qualité = métadonnée vérifiée/complétée) : critère de A à D.



---+ Actions
 
Avant de démarrer le détail des spécifications, s'assurer que notre projet va correspondre aux besoins de la communauté.
Un sondage peut être intéressant mais peu pratique pour le nombre d'idées et concepts à sonder.

--> Envoyer un document de ~10 pages d'ici fin juillet/début août aux PI des instruments interféro + membres de la commission interféro 54 de l'IAU + olbin.vo  
Le retour devrait aider à bien figer les besoins, avoir des commentaires sur des potentiels problèmes techniques et rallier les collaborateurs.

Chacun itère sur ce document qui décrit le projet :
   * 1) Présentation des objectifs du projet, dire quelles sont nos priorités dans un premier temps (L0 et L3).
   * 2) les besoins -> définir quelques use cases
   * 3) les concepts clés de la base : le dataPI, les droits d'accès, la charte d'utilisation, qualité des métadata
   * 4) les spécifications : solutions techniques pour répondre aux besoins principaux et plan d'amélioration 

Mettre un paragraphe sur les concepts et outils VO qui vont être probablement mis en place. 
http://www.jmmc.fr/twiki/bin/view/Jmmc/Software/OiDb#Mod_le_de_donn_es

Illustrer l'approche avec les bases déjà existant de VEGA et du prototype de Guillaume.

Pour le document, partir du draft ci-dessous et s'inspirer de la doc existante ivoa (www.ivoa.net) dont notamment :

Observation data model (ObsCore): http://www.ivoa.net/documents/ObsCore/20111028/REC-ObsCore-v1.0-20111028.pdf

VO Resource (how to describe dataset): http://www.ivoa.net/documents/REC/ResMetadata/RM-20070302.pdf


   * [[%ATTACHURL%/definition_oidb.pdf][definition_oidb.pdf]]: Draft of the design document (pdf).
   * [[%ATTACHURL%/definition_oidb.doc][definition_oidb.doc]]: Draft of the design document (doc).
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
doc	definition_oidb.doc	r6 r5 r4 r3 r2	manage	821.5 K	2013-10-15 - 07:44	XavierHaubois	Draft of the design document (doc).
pdf	definition_oidb.pdf	r6 r5 r4 r3 r2	manage	872.0 K	2013-10-15 - 07:45	XavierHaubois	Draft of the design document (pdf).
This topic: Jmmc/Software > WebHome > OiDb > OiDbReunion26June2013
Topic revision: r10 - 2013-11-27 - XavierHaubois