Etat des lieux, nouvelles stratégies

I.Etat des lieux

La liste actuelle des types d'objets de Simbad est consultable par tous, CDS et utilisateurs, sur la page :

http://simbad.u-strasbg.fr/simbad/sim-display?data=otypes

Elle est décrite comme : " The Object Type in Simbad is defined as a hierarchical classification, which emphasizes the physical nature of the object ...". Le principe de cette liste repose sur un concept hiérarchique unique utilisable et utilisé pour tout.

De fait elle est utilisée dans les 4 cas suivants :

• Utilisateurs et CDS : documentation
• Utilisateurs : recherche par critères sur maintypes et otypes
• CDS : contrôle de la compatibilité des types d'objets par la mise à jour
• CDS : calcul d'un score dans Raccord et Cosim servant à la cross-identification

La liste qui est disponible sur le web est en réalité l'algorithme lui-même. Le niveau de hiérarchie est indiqué par le nombre de "." précédent le type d'objet. Par exemple, la grande catégorie IR contient FIR et NIR. Rigoureusement, dans cette hiérarchie un type d'objet est incompatible avec tous les autres types d'objet ayant le même niveau de hiérarchie. Par exemple, le type IR, et a fortiori les deux sous-types qu'il contient, est incompatible avec Star et Galaxy. Inversement, un type d'objet est considéré compatible avec tous les types d'objet qu'il contient. Par exemple NIR et FIR sont compatibles avec IR,; Seyfert et Blazar sont compatibles avec AGN, lui-même compatible avec Galaxy. Pour Raccord/Cosim, la recherche se fait du bas de la liste vers le haut de la liste. C'est à dire que les types en bas sont les plus prioritaires, tandis que les types tout en haut ont la plus faible priorité. C'est pourquoi la liste commence avec ?, puis avec les domaines de longueur d'onde, pourquoi la catégorie des candidats est en haut, et pourquoi il arrive que certains candidats ne soient pas mis dans la catégorie dédiée mais juste au-dessus du type confirmé équivalent (voir par exemple Pl? et Pl).

II.Difficultés

Bien que le concept soit intellectuellement satisfaisant par son caractère synthétique et unique, il pose néanmoins de grosses difficultés.

II.1. Documentation : La logique de l'algorithme ne correspond pas à celle des utilisateurs. D'une part, il est préférable pour la documentation de commencer par les grandes catégorie définies comme Star et Galaxy, et de finir par le moins précis comme les domaines de longueur d'onde. D'autre part, à l'intérieur d'une catégorie l'ordre des types d'objets ne suit pas toujours une logique physique ou reflétant l'état d'évolution. Par exemple dans les étoiles on trouve les naines blanches avant les pre-main sequence stars. Même pour certaines personnes de l'équipe habituées à consulter cette liste, on passe parfois beaucoup de temps à retrouver ce que l'on cherche (surtout les candidats).

II.2. In-compatibilités : La reconnaissance de deux types d'objets compatibles par l'algorithme est juste. Par contre, elle est extrèmement incomplète. Ce qui ne fonctionne pas dans ce principe hiérarchique linéaire est la reconnaissance des incompatibilités vraies : elles sont très excessivement détectées. Par exemple, nous savons que NIR est parfaitement compatible avec toutes les étoiles, et que IR, X, et Rad sont compatibles avec les Galaxies. Des ajouts dans le programme ont été faits dans certains cas pour enlever le message d'incompatibilité. Mais en pratique il y en aurait tellement que ce n'est pas gérable. Parmi les problèmes les plus sévères :

• les galaxies ne sont pas compatibles avec Radio, IR, X
• toute source 2MASS est déclarée incompatible avec une étoile
• toutes les binaires serrées sont incompatibles avec star (théoriquement juste, mais observationnellement faux)
• YSO et pre-main sequence star sont incompatibles
• les classes d'étoiles variables sont incompatibles avec tous les autres types d'étoiles.
  • e.g.: AGB star est incompatible avec Long Period Variable, Mira, et semi-regular
  • e.g.: YSO est incompatible avec Orion variable
• planète candidate est incompatible avec planète (je viens de le tester le 30/05/14)).
• en fait tous les candidats sont incompatibles avec leur type défini

En pratique, les message d'incompatibilité envoyés par la mise à jour (### Les 2 types d'objets ne sont pas compatibles) sont tellement incohérents dans la plupart des cas que plus personne n'en tient compte. Nous mettons tous un "!" à la fin d'une commande "c o" pour ne pas être embêté ... D'autre part le score sur les types d'objets calculé par Raccord/Cosim est souvent inapproprié et fait manquer un grand nombre de cross-identifications.

Pour conclure, avec l'amélioration de la connaissance, et de la sensibilté et de la résolution des instruments, ces 20 dernières années, il n'est tout simplement plus possible de tenir compte de la complexité des relations entre les types d'objet et du niveau de priorité entre eux avec ce modèle hiérarchique linéaire.

III.Nouvelles stratégies

III.1. Documentation

La liste des type d'objets de Simbad à destination des utilisateurs et de l'équipe a été entièrement réorganisée. Elle est basée sur des considérations physiques, et pour les étoiles sur leur stade d'évolution. La recherche d'un type d'objet est donc logique du point de vue de l'astronomie, et non plus du point de vue de l'algorithme. Les grande catégories sont :

• I. STARS, CIRCUMSTELLAR MATTER, PLANETS
• II. SETS OF STARS
• III. INTERSTELLAR MEDIUM
• IV. GALAXIES
• V. SETS OF GALAXIES
• VI. GRAVITATION
• VII. GENERAL SPECTRAL PROPERTIES
• VIII. VARIOUS ...

Cette liste réorganisé est consultable ici : http://cds.u-strasbg.fr/twiki/bin/view/Astronome/ObjectDescription

Bien qu'il y ait évidement des hiérarchies dans cette liste, ce n'est plus un algorithme. Les candidats ne sont plus séparés dans une catégorie à part mais indiqué avec chaque type d'objet défini. Les étoiles variables ne sont plus dans une catégorie à part non plus; soit leur variabilité définit leur nature, soit c'est une propriété d'un objet dont on connait (plus ou moins) la nature. Les Outflow, dont HH est un sous-type, sont classés avec les YSOs, et non plus dans le milieu interstellaire. Les nébuleuses planétaires, qui dans Simbad contiennent la nébuleuse elle-même et l'étoile centrale sont également sorties du MIS et mises avec les étoiles évoluées. Les QSOs ont été sortis de la hiérarchie des AGNs.

Une révision complète des types d'objets manquants dans Simbad a été effectuée. Ont été ajoutés en particulier : les A Cyg variables et les Luminous Blue Variables dans la catégorie des étoiles massives; les grands stades d'évolution Main sequence, evolved star (post-MS), et Red Clump; un sous-type général pour les binaires serrées Close binary system; le domaine de longueur d'onde MIR; et les Ultra Compact Dwarf Galaxy. Les candidats ont été vérifiés systématiquement. Il en manquait beaucoup, en particulier pour les classes d'étoiles variables (bien qu'ils existent dans le GCVS). En attendant que ces nouveaux types d'objets soient effectivement codés, le type d'objet existant le moins inapproprié est indiqué entre accolades.

Il existe aussi des types d'objets inutiles. Ils ne seront plus attribués et disparaitront progressivement de la base : Peculiar star car il ne signifie rien; *i* devenu totalement obsolète avec la hiérarchie et ajoutant plutôt de la confusion qu'autre chose (souvent faux de toute façon); ISM qui ne signifie rien et indique seulement qu'on n'a pas su quoi mettre; Optically Violently Variable object dont le nombre total dans Simbad est égal à 0; Galaxy with high redshift car il n'a aucune définition sachant que la limite des grands redshifts est sans cesse repoussée, et qui est redondant avec les données fondamentales; Very red source qui ne signifie rien. Par contre Extremely Red Object est maintenu car il est encore utilisé dans la littérature (à noter qu'il ne s'applique que aux galaxies, jamais aux étoiles).

Finalement, que ce soit pour les utilisateurs ou pour nous-mêmes, les types d'objets ont maintenant une définition courte (cliquer sur le code du type d'objet). [Travail encore en cours mais il y en déjà beaucoup de faites]. Exemple pour les Be stars : http://cds.u-strasbg.fr/twiki/bin/view/Astronome/BestarDef.

Pour les étoiles variables, une liste de tous les types du GCVS dans l'ordre alphabétique, avec le(s) type(s) d'objet équivalent dans Simbad, leur type phenoménologique, le(s) nom(s) de la classe de variable, et les domaines de longueur d'onde inhabituels où elles sont emettrices (X, IR en particulier) est donné ici : http://cds.u-strasbg.fr/twiki/bin/view/Astronome/VariableTable. Si vous vous demandez ce que sont les "magnetic stars" ou "helium variables" vous y trouverez la réponse.

Recommandation : l'équipe devrait le plus tôt possible se mettre à consulter ces deux listes même avant leur implémentation sur les pages web, Liste réorganisée et définitions et Table des étoiles variables et correspondances GCVS, à la place de l'ancienne. Elle permettent une meilleure recherche et une attribution argumentée des types d'objets.

III.2. Mise à jour et Raccord/Cosim

Les deux listes décrites ci-dessus ne répondent pas directement à la question : comment tenir compte à la fois des compatibilités, incompatibilités, niveaux de priorité et de hiérarchie, pour optimiser les cross-identifications avec Raccord/Cosim et la mise à jour manuelle ? Mais ce travail de réorganisation et de définitions était indispensable pour pouvoir trouver une solution. Un travail proche a été fait pour l'ontologie. Malheureusement l'ontologie est trop complexe au niveau de la programmation. Elle n'est pas non plus suffisamment pragmatique pour une application directe.

Les principes de gestion des types d'objets sont les suivants :

• A chaque type d'objet est associé un code numérique (c'est aussi le cas actuellement). La grande catégorie Stars a des valeurs 10000-19999, la classe des étoiles massives 11000-11999, celle des YSOs 12000-12999, les Galaxies 40000-49999, etc... Les types d'objets définis ont un code pair, les candidats un code impair (code du type défini +1). Il y a une grande marge de manoeuvre pour pouvoir ajouter des types d'objets dans le futur sans perturber ce qui est déjà en place.

• A chaque type d'objet est attribué un niveau de priorité pour le Main object type de Simbad, ceci afin d'éviter de remplacer par exemple le type bien défini BY Dra variable par le type plus général rotating variable lors du traitement des tables avec Raccord. On distingue 5 grands niveaux de priorité :
  • Premier niveau, 1-10 : objets dont la nature est bien définie. A l'intérieur de cette catégorie il y aussi des priorités. Par exemple les céphéides et les classical céphéides ont des priorités de premier niveau, mais classical céphéides est proritaire sur céphéides car plus précis. Pour les candidats on ajoute 10 à la priorité du type défini correspondant.
  • Second niveau, 30-50 : les classes d'objets plus générales qui ne déterminent pas totalement la nature de l'objet, entre autres les grands stades d'évolution des étoiles. Dans cette catégorie il y a à nouveau des priorités, par exemple evolved star, RGB, HB, red clump, AGB, sont dans cette catégorie, mais RGB, HB, red clump, et AGB, sont plus prioritaires que evolved star. Même règle que précédemment pour les candidats, ce qui signifie que les candidats des types d'objets classés en haute priorité sont plus prioritaires que les types définits de second niveau.
  • Troisième niveau, 80-100 : types d'objets qui sont en fait une propriété spectrale, cinématique, ou de variabilité, mais qui ne définissent pas la nature de l'objet. Exemples : emission-line star (qui peut être une supergéante, un YSO, une AGB, une PN, une symbiotique, etc...); *iC qui peut être n'importe quelle étoile; ou encore emission-line galaxy.
  • Quatrième niveau, 200 : grandes catégories d'objets (star, galaxy, etc...)
  • Cinquième niveau, 500 : domaines de longueur d'onde
  • Sixième niveau, 1000 : type d'objets obsolètes amenés à disparaitre, et ?

• A chaque type d'objet est associé une liste de type d'objets compatibles et incompatibles, ainsi que les types d'objets à rechercher pour les sélections par maintypes/otypes. Le codage est fait dans une table ascii en clair, c'est à dire en utilisant l'abbréviation des types d'objets; ils peuvent être listés individuellement séparés par des virgules (par exemple : Al*,bL*,WU*), ou bien sous forme d'intervalle (par exemple : Al*-WU* ou EB*-<RS*). Cette table sera interprétée par Anais pour la transformer en codes chiffrés et l'intégrer dans les programmes de Simbad. L'idée est de permettre une maintenance la moins lourde possible et avec le moins de sources d'erreurs possible. Il n'y a de fait pas d'algorithme, c'est codé en dur basé sur des ouvrages divers et sur l'expertise des astronomes de l'équipe.

IV. Mise en oeuvre

La table des codages sera bientôt disponible ici : http://cds.u-strasbg.fr/twiki/bin/view/Trash/AstronomeObjectCompatibilite. Elle est sous forme ascii. Elle ne devrait pas poser de problème de programmation. Elle remplacera totalement la hiérarchie actuelle à tous les niveaux : mise à jour, Raccord/Cosim, maintypes et otypes queries.

IV.1. Programmation

Essentièlement Anais en interaction avec Cécile.

• Mise à jour, commande c o : lorsque l'on veut modifier le type principal d'un objet existant, le programme de mise à jour devra consulter la table des codages pour vérifer les priorités et in-compatibilités.
  • Si le nouveau type d'objet est prioritaire sur l'ancien, il sera mis en type principal. Dans le cas contraire, il sera ajouté en type secondaire. Si le nouveau et l'ancien type d'objet ont exactement la même priorité, c'est le nouveau type qui doit être choisit. Néanmoins ce cas de figure est le plus souvent un signe d'incompatibilité qui sera donc géré.
  • Si les deux types d'objet sont incompatibles, la mise à jour doit envoyer un message spécifique, et ne pas exécuter la commande. Le message actuel est : ### Les 2 types d'objets ne sont pas compatibles. Nous avons tous pris l'habitude de le zapper, c'est devenu un automatisme. Il faut donc le changer, par exemple en : ### Objets incohérents ---> expertise requise , suivi des deux types d'objets concernés.
  • Corollaire : il doit être possible de changer un type d'objet sans mettre de bibcode (car c'est un cas de figure qui arrive dans certains cas) ni de "!". En effet à l'heure actuelle, si on ne met pas de bibcode, la mise à jour n'exécute pas la commande et envoie le message : ### Erreur sur le type d'objet : vous devez preciser un bibcode. Cela ne fonctionne pas non plus en mettant un "~" à la place du bibcode, on doit vraiment mettre un "!". Pour éviter la collision avec les tests de compatibilité, je suggère que l'absence de bibcode soit autorisée en le remplaçant par un "~", avec un message d'avertissement mais sans blocage de la commande.

• Mise à jour, commande mp : même principes que c o.

• Mise à jour, commandes a o et merge : ces deux commandes ne doivent rien tester et juste être appliquées. La commande merge doit faire ce que l'on attend d'elle, c'est à dire garder tous les paramètres de l'objet cible sans les remplacer par ceux de l'objet source.

• Score de Raccord/Cosim : le score de Raccord/Cosim sur la comparaison des types d'objets devra également consulter la table des codages pour les in-compatibilités. Deux types incompatibles se traduisent par un score -1, deux types compatibles par un score +1, et 0 pour le reste (défaut). La différence entre le traitement des types définis et des candidats réside uniquement dans les incompatibilités : les candidats ne sont incompatibles avec rien; par contre ils ont les mêmes compatibilités que les types définis.

• Collisions idprinc versus objet type : à l'heure actuelle la mise à jour vérifie la "cohérence" entre le type d'objet et le nom principal de l'objet via la table idsort. L'ajout d'un nom entraine automatiquement une vérification dans idsort. Si le nouveau nom n'est pas dans la liste du type d'objet dans idsort, la mise à jour met le message : ### Identificateur pas coherent avec type d'objet, puis le message : o Modif effectuee : .... Etant donné que la liste des catalogues par type d'objet dans idsort est nécessairement extrèmement incomplète, et qu'il n'y a en pratique pas de lien strictement logique entre le nom d'un objet et sa nature, je suis d'avis de supprimer totalement ces vérifications et ces messages. Ce qui n'empêche pas bien sur de continuer à utiliser idsort pour chosir un nom principal automatiquement quand il n'est pas fixé.

IV.2. Impact pour les documentalistes et tous ceux qui font de la mise à jour

La commande "c o" ne devra plus être forcée systématiquement avec un "!" sans réflexion !!!*. La règle sera d'utiliser la commande c o normalement sans la forcer, et de laisser le programme gérer les priorités et les compatibilités. Le message d'incompatibilité entre deux objets sera modifié pour éviter de le zapper par habitude. Il devra nécéssairement entrainer une expertise. Ce n'est qu'à l'issue de l'expertise que la commande pourra éventuellement être forcée (misclassifications entre autres). C'est l'un des enjeux principaux de ce travail : que les messages d'incompatibilités soient pertinents. Ils seront beaucoup moins fréquents qu'à l'heure actuelle. Par contre, c'est le deuxième enjeu principal, les propositions de cross-identifications par Raccord/Cosim seront nettement plus nombreuses.

La commande mp doit être préférée à la commande merge, sauf cas exceptionnel, car la commande merge n'effectue aucun test (c'est son rôle, conserver tous les paramètres de l'objet cible).

IV.3. Phase de tests

-- CecileLoup - 2014-05-30