Présents: Johan, Gilles, Guillaume, Laurent, Patrick, Xavier
Installation
- Librairie TAP en cours d'évolution: suivi de la V2.0 par Laurent + collegues IVOA (nouvelles fonctions, plus de maturité, meilleurs description des méta-données)
- Migration système sur une machine virtuelle OSUG-DC
- reflexion pour la migration des données d'une instance vers une autre:
- pour l'instant, l'idée est de cloner la production puis appliquer des scripts de MAJ.
- a considerer: passage du portail en read-only avec affichage d'un message generale pour avertir de la MAJ...
Data Model (DM)
- DM pas rigoureusement VO-compliant pour le moment: manque utype et description dans notre DM, tableau à compléter et à implémenter
- Une vérification de la bonne application d'ObsCore et de ses metadata (ex. obs_creator_name, publisher_id) serait très utile dans le contexte d'OIDB 2.0 et de ses fonctionnalités VO. Pas priorotaire pour OIDB 1.0.
- Rdv avec le CDS (Mireille ?) dans les mois à venir (Guillaume)
Soumission: ce qu'il reste à mettre en place
- Vérification contenu ticket 636 et 648
- L'adresse email du dataPI doit être accessible pour l'utilisateur (non-identifié) mais doit être codée (image, captcha, etc...). Cette information est spécifique au portail (pas stockée sur la base de données, n'est pas une metadata du DM).
- Embargo:
- L2 automatiques: c'est au PI de l'instrument de définir quel est l'embargo sur les données. La valeur par défaut doit être d'un an après les obs. Maximum: 2 ans après les obs ?
- L2 individuelles: durée d'embargo ajustable, entre 0 et un max de 18 mois. La valeur par défaut est d'un an.
- L3 : durée d'embargo ajustable, entre 0 et un max de 18 mois après soumission.
- Keywords: voir dernière réunion
- Quality flag: voir ticket 579 pour les 6 différentes catégories (boîtes à cocher)
- Rapport de soumission sera visible à la prochaine mise à jour
- Quelle pratique encourager pour le passage d'un oifits L2 a L3 après publication ?
Conditions d'utilisation
- l'idéal serait de forcer à faire accepter les conditions d'utilisation (pour les utilisateurs et dataPIs) à travers un cookie à la première connexion.
- un bordereau sur le site peut être aussi utilisé d'ici la mise en place du cookie (comme celui déjà utilisé pour la version de démonstration).
- la règle de citation pour les L2 individuelles est à convenir avec le dataPI.
- la règle de citation pour les L2 automatiques sont décidés par les instrument PI.
- la règle de citation pour les L3 est de, au minimum, remercier le dataPI et de citer la publication correspondante.
- revoir les informations de licence et droits sur les données partagées sur le module INIST (cf. mail de GILLES du 2/10/14): Xavier
Définition
- Besoin de plus de contraintes sur la validité d'une granule L2, définir ce qu'on exige au minimum d'une granule pour qu'elle soit valide. Sinon, elle sera rejetée (pas de modification manuelle via le backoffice à envisager pour l'instant). Ex: accepte-t-on des OIFITS qui n'ont des V2 nulles et des CP non-nulles, etc... Il s'agit donc de faire vivre et aboutir le ticket 607 : Xavier.
- Si une granule est non-valide, le fichier OIFITS sera rejeté (dans sa totalité) même si il contient 50 autres granules valides.
- Pour L3 on garde tout à partir du moment où on a un bibcode.
Environnement
- L0 ESO en cours de discussion avec Isabelle, Christian et JP. L'idée est de récupérer les infos par ftp comme le fait le CDS. On peut même envisager de passer par le CDS qui a déjà fait ce travail si l'ESO est d'accord. Ce serait un autre point à discuter lors de la réunion avec le CDS. (Guillaume)
- Rapport sur l'analyse des données L0 CHARA envoyé par Guillaume à Chris et Theo pour clarifier le contenu des metadata.
Backoffice
- mise à jour visible ce vendredi (Guillaume + Patrick)
Staffing
- Création de post-docs SN0, rester à l'écoute pour savoir comment proposer un service OIDB (Gilles).
Calendrier
- Fin janvier: toutes les fonctionalités de OiDB 1.0 sont opérationnelles.
- Conseil du JMMC le 28 janvier 2015.
- Fin février: tests totalement ou quasiment finis, annonce publique de OIDB 1.0 dans la foulée.
Rythme
- Prochaine réunion vers le 15-20 janvier.
- Tous les vendredi midi, une mise à jour doit-être faite pour que les changements soient testés la semaine suivante.