Présents:

Ordre du jour

Intro

Modifs de l'été:

• import CHARA (CLIMB-CLASSIC) a partir de données CSV (reste à pousser les dernieres années 2010-2012 (en cours))
• affichage des collections (Vizier, autres)
• backoffice (cf points ci-dessous)
• commentaires sur granules
• tri table de resultats par colonnes
• formulaire de recherche amélioré pour les dates
• modifs techniques des soumissions de granules par fichiers metadonnées (xml)
• reste a mettre en place l'upload avec la reflexion sur le rangement des données et multiversions (meme noms pour des données differentes, etc ...)

en bref : toutes les briques du portail sont la et attentent un retour du groupe pour finalisation et validation

organisation des tickets

Patrick finissant son CDD fin Novembre, il serait bien de faire le point sur les actions en cours. Une solution pourrait consister à créer deux milestones sous trac avec comme dates butoires mi-octobre et mi-novembre. Dans le meilleur des cas le milestone mi-novembre pourrait correspondre a ce que l'on attend d'un version publique. Le milestone intermediaire devrait clore les points principaux. Si ok, on cree les milestones et il faudra trier les tickets Ceux ne correspondant a aucun deux milestones pourrait par defaut tomber vers OIDB_FUTURE.

Debrief rapide sur la journée TAP du 17/09/2014 à Paris

• confirmation de la pérenité de la librairie TAP : TAPlib
  • une V2 (non retro-compatible) va arriver et devra etre intégrée avant la mise en production d'oidb
• quelques infos pour le futurs enregistrement dans les registry (via TAPHandle)
• identification de problemes avec le service TAP

Retour sur le formulaire de soumission de catalogue VizieR

• ticket #636
• ok pour la reprise dans un deuxieme temps.
• qui peut modifier
• cette notion represente trop de travail pour des L < 3 ( recouverture avec la base bibdb )
• voir comment reexploiter les infos deja presentes au CDS voir discuter avec eu
• -> pas prioritaire ?

• instrument name doit oligatoirement correspondre. Le nom de l’instrument pas normalisé dans INSNAME donc

Faire une règle qui match le INSNAME avec la liste des instruments qu’on connaît.

• L3 on accepte des données invalides (si un bibcode est fourni) mais on met un warning ( L1 L2 les coordonnées doivent etre valides, si les coordonnées sont nulles l'oifits est refusé ). Mettre en place la règle puis test.
• Si pbm de coordonnées dans les collections VIZIER, renvoyer un ticket au CDS avec le bibcode.
• instrument_mode on accepte en L3 des valeurs vide, on propose qd meme ce qui existe
• rajouter em_min em_max + nb_channels associés a chaque granule + calcul de la resolution spectral
• peut-etre ameliorer la logique pour amber
• on conserve l'ensemble des granules valides

Définir la notion de doublons L{0,1,2,3}

Cette definition doit pouvoir aider à refuser ce qui est deja dans la base ou simplement informer que des données sont partagées entre plusieurs sources.

• quelles sont les conditions de remplacement des granules pour chaque niveau de calibration ?

cas L0 : on remplace tout cas L2 perso : une granule soumise deja detectée (avec Checksum ?) avec de même meta-donnée doit etre justifiée : quelle difference, est-ce que ca invalide la version precedente. meta/données identique indepandant de la collection

cas L3 : si même bibcode, on peut imaginer qu'on vérifie (au moment de la soumission) les métadonnées suivantes:

temps a quelques secondes positions a quelques secondes lmin lmax quelques % instrument, le meme

cas L2 auto : mener ds le futur une reflexion (action J.B en s'appuyant sur des use cases PIONIER)

Cas pressentis:

• nouvelle version de reduction de données
• passage L2 vers L3 ?
• rechargement de nouveaux logs d'observation (cf echange de Denis sur log VegaObs le 02/09/2014 18:22 sur la mailingliste)

Il y a actuellement certaines données qui se recouvrent partiellement sans toujours partager les mêmes metadata.

Dans les deux exemples suivant les deux granules sont probablement issues de la même obs, mais les données différent (nb_oi_vis différent):

• cas1 : données publiées au CDS et présentes dans la collection pionier
• cas 2: collection pionier , JB quelle es l'explication ?

cas L2 individuel : deux granules partagent les mêmes metadata mais les data sont differentes, il faut imposer la redaction de commentaires pour qu’on explique la différence ou changer quelque chose dans les métadata qui definissent la granule.

• Un remplacement de granule doit donner lieu à une notification dans le backoffice

Test backoffice (au moins par Xavier et Myriam) :

maj. documentation

update VEGA

Suite au message de Denis du 02/09/2014, la mise a jour se passe bien. Il manquait des enregistrements qui n'avaient pas de status dans la base vegaobs.

update CHARA

Theo nous a envoyé ( à quelques uns ) des fichiers pour test cet été. Moyennant une petite adaptation de format, les données sont poussée sur oidb cf collection chara sur oidb-beta. reste à faire:

• création d'un compte sur la machine chara pour récupération des fichiers de log ou ils nous envoient leur fichiers .csv sur notre serveur (fréquence à décider).
• jmmc-obslog AT ujf... rajouté a la mailing liste obschara pour recupération des rapports de fin de nuit: ok. Mais comment prend-on en compte ces observations report ? leur
• table de correspondance pour identification des dataPi demandé (en attente)
• discussion sur les programmes associés aux granules

état des soumissions

affichage ok/ko

statistiques telechargement

• nb de telechargement par granules (nbr distinct d'utilisateurs meme si les requetes sont essentiellement anonymes)

Définition des nouvelles actions backoffice:

édition granule, suppression

reprise soumissions incomplètes

nettoyage granules

• instrument-name/instrument-mode
• coordonnées (si vraiment besoin, mais non a priori)
• id tout passer en HD > HR > HIP > BD > USNO > 2MASS > ... (cf mail de Gilles du 09 sept 2014) ? (ce point a faire d'abord lors de la soumission)
  • sous Simbad, le main-id (nom principale) est défini a partir du nom décrit dans la première publication qui le cite. Il peut être mis à jour lorsque de nouvelles publications apportent un modification du type de l'objet et qu'un autre nom est plus approprié. Il peut également être mis à jour à la discretion des Astronomes du CDS. Le CDS nous autorise à garder trace d'un id interne a Simbad, s'il reste interne à notre gestion de données.

gestion/selection des keywords a mettre a dispo

• Est-ce que ca a un sens en L0, L2 ou juste L3 ? est-ce que les gens vont effectuer ce genre de recherche par keywords astro ?

ESt-ce qu’on peut donner des resultats serieux (exhaustifs en prenant ça).

• L0,L1 : keywords peut venir d’un lien avec CDS
• L3 -> keywords viennent des publis

statistiques consultation ?

prévoir de quoi exploiter dans le futur (basse priorité)

Specs à completer/modifier

Soumission de données par upload de fichiers

• doit-on supporter des archives tgz ou zip en entrée ou seulement des oifits (cf ticket #635 )?
• il est relativement aisé (moins de 2 semaines) de mettre en place les briques techniques pour pouvoir uploader ses oifits depuis son disque local.

Mais il faut d'abord decider des règles du backoffice.

• on devra supporter les fits.gz
• on ne supporte pas les archives -> mettre un message d'erreur

metadonnées ?

• T0/R0 (harmoniser T0 VEGA/CHARA)
• programid
• instrument-mode
• quid colonnes vides ?
• verifier que toutes les dates sont bien entre 2000 et aujourd'hui (ex données CDS avec MJD datés en 8058) + autres régles de ce style

Actions non formalisées

• recuperer les dataPi des donnees Pionier (J.B.) : fait
• rajouter une landing page pour les données observation logs (actuellement bug avec : -/-) : page URL de CHARA, VEGA,
• pouvoir ajouter des commentaires sur collection/instruments... et surtout identifier ou les afficher
• flux RSS à garder en tête, notamment pour diffuser l'ajout de collection VIZIER et les update de l'OIDB
• interface d'administration à créer avec un soft (manuelle pour l'instant) pour la gestion des droits utilisateurs, comptes, accès privé aux données, accès au backoffice.
• rajouter une collection "contribution" par defaut pour les soumissions L2

Faire vivre olbin.vo, préparer l'appel à beta-testeurs ?