Réunion du 10/01/2023

Présents : Marianne B., Ana F., Coralie F., Gilles L., Giacomo M., Pierre O., Emmanuelle P., François-Xavier P., Alicia V., Patricia V.

Alicia

Cas d'utilisation d'un \vizMerge (fusion de plusieurs tables) pour une seule table ?

Exemples : J/AJ/133/2464 pour Table 7 qui devient CNO dans VizieR, J/ApJS/168/213 pour Table 2a qui devient ion_CIE dans VizieR, J/A+A/544/A155 pour Table g351 qui devient foc dans VizieR, J/MNRAS/448/3167 pour la table a4 qui devient xdata dans VizieR, etc. Pour une trentaine de catalogues...

Le \vizMerge (syntaxe : \vizMerge{ tables }{ new_name }{ Explanation of the union } ) est normalement réservé aux fusions de plusieurs tables. Cela complique le programme lorsqu'il n'est utilisé que pour une seule.

Néanmoins, il est utilisé ici dans le cas où on veut modifier un nom de la table dans VizieR pour le rendre plus significatif et/ou l'homogénéiser avec les noms des autres tables, tout en conservant le nom de la table d'origine dans le ReadMe+FTP -- ce qui permet de rester cohérent avec ce qui est indiqué dans la publication. Actuellement, la seule commande possible pour modifier un nom de table dans VizieR est cette commande \vizMerge .

=>Gilles va conserver cette possibilité pour le \vizMerge .

Pierre

Problème avec les yCat pour Gaia remonté par Cécile - Comment fait-on ?

Pour Gaia DR3, il y a eu 6 catalogues produits avec 6 bibcodes yCat différents correspondants à ces différents catalogues. Le catalogue I/355 - Part I: main sources (2022yCat.1355....0G) a été utilisé pour la mise à jour des sources Gaia dans SIMBAD mais certaines données ne venaient pas de ce catalogue "main sources" mais des suites : Part II (I/356) = extragalactique jusqu'à IV (I/358)...

=> Cécile a fait faire les modifications aux COSIMistes pour que les données extragalactiques mises dans SIMBAD viennent bien de I/356 et pas du I/355, etc. pour les autres cat. Les références yCat correspondantes ont été créées dans SIMBAD.

=> Il n'y a pas de solution automatisable. Ce cas est très particulier et il faut simplement faire attention à associer le bon bibcode correspondant aux données récupérées dans SIMBAD.

Le problème est sans doute lié à la définition du bibcode "yCat".
Pour rappel :
Un bibcode yCat est systématiquement créé par ADS pour indexer tous les catalogues de VizieR
Par exemple : 2020ApJ...888...30F dans ADS est lié à 2021yCat..18880030F qui est le catalogue VizieR correspondant. 2021 est l'année de création du ReadMe, "1" est le journal ApJ, 8880030F correspond au volume, page, première lettre de l'auteur (comme dans le bibcode "classique").

Pour les grands catalogues (et certains cas particuliers), il peut n'y avoir qu'un seul bibcode yCat et pas d'autre référence (pas de publication associée).
Par exemple, 2022yCat.1356....0G correspond au nom du catalogue (2022 pour l'année de création du ReadMe et 1356 = I/356, G = première lettre premier auteur -- ici Gaia col.). Dans ce cas, le seul nom de catalogue utilisable pour un bibcode SIMBAD est le yCat.

=> Si la référence catalogue n'est pas dans SIMBAD, il est tout à fait possible de créer la page SIMBAD correspondante avec le bibcode yCat afin que ce bibcode, utilisé pour certaines données SIMBAD, aient un lien actif. On peut les créer à la demande.

Question subsidiaire (Gilles) : comment indiquer dans VizieR les DOIs qui pointent vers l'origine des données ?

Pour rappel :
Le DOI correspondant au bibcode donc à la publication est automatiquement récupéré par l'un des programme de Gilles et ajouté au .status.
Un DOI correspondant au catalogue VizieR est également automatiquement créé.

Dans le cas des grands catalogues, il faudrait aussi ajouter le DOI correspondant à l'origine des données.

=> Pour l'instant, il n'y a pas vraiment d'endroit défini dans le ReadMe ou le .status pour ajouter ce DOI particulier.

Emmanuelle

Politique avec l'AAS : ce qu'on peut prendre comme liberté par rapport à la publication, ce qu'il faut leur retransmettre comme info... ?

1. Si les auteurs nous envoient des données supplémentaires...
=> On prend.

2. Si on doit faire des corrections, pour les corrections lourdes, on ajoute une ligne dans la Section History du ReadMe.
=> Comme l'AAS aimerait savoir quand on fait des corrections, Gilles pourrait ajouter la possibilité de recherche sur cette section via ElasticSearch pour qu'ils puissent récupérer la liste des catalogues ayant subi des modifications (Section History > 1 row).

=> Si la section History comporte plus d'une seule ligne, cela signifie qu'il y a eu un update/correction à un moment donné après la publication du catalogue. Gilles pourrait aussi ajouter un onglet dans la landing page pour signaler ces modifications.

N.B. : Les modifications sont aussi parfois indiquées sous forme de notes, directement dans les colonnes concernées pour plus de visibilité (cas des misprints en particulier) mais on ne peut rien en faire pour un process automatique.

=> Remonter la discussion à Mark : s'ils sont demandeurs de davantage de service/feedback, ils pourraient y mettre les moyens... Les retours de correction sont trop lourds à gérer manuellement.

=> Emmanuelle écrit à Gus pour lui remonter les deux idées concernant les retours de correction.

J/ApJ/913/60 : cat 10yrs of Fermi-GBM GRBs mais un sous-échantillon dans la table et pas de spectre ?

=> Modifier le titre et la description pour dire qu'il s'agit d'un sous-ensemble avec une analyse spectro.
=> Recréer les URLs qui permettent de télécharger les spectres FITS correspondants sur https://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/ - lien vers le fichier ou bien plot si on peut...

Photometry viewer pas terrible pour HD 42 à cause de la Table 7 de J/AJ/161/234 qui fait des cross-matchs avec sources proches

En fait, le problème est que la position de HD42 est prise pour tous les cross-matches.
=> Ajouter un \vizPosition pour la table 7 afin qu'elles soient basées sur les différents noms SDSS et pas sur l'unique source Gaia correspondante... !

N.B. : Il reste le fait que le Photometry viewer est dépendant du \vizFilter et que dans certains cas on aimerait conserver le \vizFilter pour les métadonnées du catalogue (min-max des flux par ex. ; tracé ~SED pour les sources) mais ne pas ploter ces données dans le Photometry viewer (car flux SDSS ou Gaia redondants avec ce qu'il y a déjà par ex.). Pour l'instant, soit on enlève un \vizFilter afin qu'il n'apparaisse pas dans le Photometry viewer, soit on l'ajoute et il apparaît dans le Photometry viewer ; ce n'est pas possible de distinguer les deux.

2021ApJ...916...50F : on prend les spectres de Zenodo ? Si oui, lesquels et quelle table ?

=> Prendre la table du ReadMe de Zenodo qui liste les différents spectres et l'ensemble de ~20 spectres avec tracé des plots.

N.B. : On peut décrire plusieurs tables MRTs ensemble même si elles n'ont pas nécessairement le même format... Il faut un format E qui permettent de contenir l'ensemble des formats dans ce cas.

-- EmmanuellePerret - 2023-01-10