Réunion du 28/06/2022

Présents : Marianne B., Ana F., Coralie F., Gilles L., Emmanuelle P., Alicia V., Patricia V.

Renouvellement de l'architecture d'ingestion pour VizieR

Fichier JSON unique

Alicia travaille actuellement à la fusion des deux "parseurs" ReadMe et .status en un seul. Le format utilisé est le JSON, pratique pour les manipulations informatiques.

Le fichier global permet d'afficher l'entièreté des informations du ReadMe avec l'ajout des UCDs, des dates, des filtres, des colonnes calculées (ex. Obs.date et Obs.time dans le ReadMe est transformé en une seule colonne "Obs" dans VizieR), etc.

Exemple de fichier JSON "vizin" pour un merge:

Si c'est utile pour les documentalistes, une sortie plus lisible pourrait être créée afin de voir toutes les informations qui seront entrées dans la base : filtres, types de données, colonnes calculées, etc.
Ce serait bien d'avoir le format/unité des données stockées aussi...

N.B. flag VO_COLORCOL pour les colonnes ajoutées:
Actuellement, les colonnes ajoutées ou calculées dans VizieR qui ne faisaient pas partie des données d'origine sont affichées en rouge dans l'interface Web (ex : \vizSimbad , \vizSimbadName , \vizNED , \vizLEDA , \vizAddColumn , \vizAddFKflag , \vizPosition , colonnes calculées pour les positions (ICRS/J2000) & dates, colonne "Full"...)

Si on veut mettre une colonne en rouge pour spécifier qu'il s'agit d'une colonne ajoutée (sans être passé par \vizAddColumn -- par exemple, ajout d'une colonne directement dans la table FTP), on peut utiliser la commande \vizSet et flags|=VO_COLORCOL qui mettra toute la colonne en rouge sans passer par la commande LaTeX \fg ...

Pour voir la liste des flags VO_ disponibles, voir dans METAcol et cliquer sur "Flag".

"Build data"

L'étape actuelle est la fusion des deux fichiers JSON mais on peut déjà réfléchir à la suite.

Schéma des étapes de la nouvelle ingestion VizieR:

Les API sont les modules déjà existants qui seront conservés.

Le nouveau fichier JSON "vizin" permettra :

• de stocker différents types de données calculées : les noms SIMBAD, les positions ICRS, le temps (transformé en MJD) et toute autre information que l'on voudrait stocker...

Les noms traduits pour le dictionnaire par exemple ? Ou bien ?
=> A réfléchir.

• de construire les métadonnées de la base de données

Passage aux ucd1+

Pour les UCDs, il faudra passer aux ucd1+ puisque les UCD1 sont devenus obsolètes. Il faut reconstruire un outil équivalent à setUCD mais en mieux.

L'outil devra tenir compte :

• des descriptions, unités et labels du ReadMe ; le programme colmeta de F-X sera sans doute précieux pour cela
• des \vizUCD du .status
• des solutions proposées par ucd-finder -- (Attention : petit bug à corriger ; actuellement "Blue differential magnitude" propose phot.mag;em.IR.60-100um --em.IR.60-100um étant "undefined"-- alors que "B differential magnitude" est presque ok -- on s'attendrait à avoir un arith.diff proposé pour le "differential" ?...)
• des recherches dans d'autres catalogues VizieR -- cf. équivalent de getUCD.

N.B. : l'outil UCD Explorer développé au cours du stage de Louis Demange est abandonné car il reposait sur une base Elastic Search trop compliquée à maintenir.

Gilles proposait de sortir un "ReadMe" avec la liste des ucd1+ suggérés que l'on aurait pu supprimer du fichier pour conserver les bons UCDs.
Différentes remarques :

• Il peut y avoir de nombreuses propositions ! Cela paraît fastidieux d'avoir à supprimer chaque suggestion non-souhaitée. Ce serait sans doute plus judicieux de pouvoir sélectionner celle que l'on veut dans la liste.
• Reprendre la structure du ReadMe risque de ne pas être très ergonomique...
• Attention aussi, si le programme ne propose qu'une seule solution, cela ne veut pas dire que ce soit forcément la bonne. Il faut que l'on puisse vérifier et ajuster le cas échéant.

F.X. proposait plutôt une interface qui permettrait de sélectionner l'ucd1+ colonne par colonne

• Attention au fait que le setUCD actuel permet de n'assigner que certains UCDs erronés ou non-retrouvés ; les autres sont attribués automatiquement et ne font pas l'objet d'un travail particulier.
• Si la table fait plus de cent colonnes, cela risque d'être très fastidieux de devoir passer en revue les cent colonnes...

=> Alicia verra avec Emmanuelle lorsque ce sera d'actualité pour voir comment sont attribués les UCDs actuellement et quel type d'interface pourrait convenir pour le nouvel outil d'attribution.

Peut-être une interface Web qui permettrait de sélectionner certaines propositions et d'afficher plus de suggestions si nécessaire ?

Dans tous les cas, le résultat du travail permettrait d'inclure automatiquement les \vizUCD dans le .status

Pour les ucd1+, ce serait probablement une bonne idée de suivre ce qui se passe au niveau du VO pour avoir les dernières mises à jour. Emmanuelle veut bien faire partie du groupe avec Mireille et Seb...(Voir CR du 26/03/2019 pour lequel il y a toujours le fichier de correspondance UCD1/ucd1+ de 2005 sur la page IVOA (mais on doit avoir plus récent ailleurs) et je ne suis pas sûre que les ucd1+ demandés aient été ajoutés dans la dernière version de 2018 du coup ?).

Em (29/06/2022) : Mireille vient de m'ajouter à l'"UCD Science board" de l'IVOA qui discute des demandes pour les nouveaux UCDs (demandes reçues via la liste semantics@ivoa.net).
Les dernières listes d'ucd1+ valides sont sur le Git : https://github.com/ivoa-std/UCDList (fichier ucd-list.txt et ucd-list-deprecated.txt pour faire la différence avec les anciennes versions).
Grégory Mantelet a développé la librairie ucidy pour vérifier la cohérence d'une liste d'ucd1+ avec les dernières versions valides (cet outil est utilisé pour TOPCAT).

Voir aussi CR du 27/02/2018 pour les premières discussions sur le passage UCD1 vers ucd1+ et CR du 21/03/2018 où on rappelait que setUCD ne sert pas seulement à l'attribution des UCDs mais fait des vérifications via la commande vizcat .

-- EmmanuellePerret - 2022-06-28