Formats ouverts
Wikipédia considère comme "ouvert" « un format de données interopérable et dont les spécifications techniques sont publiques, sans restriction d'accès ni de mise en oeuvre ».
Cette expression des formats ouverts exclue clairement les formats sous brevets, ou impliquant l'utilisation de logiciels sous brevets.
A l'inverse un format "propriétaire" ou "fermé" est « un format dont les spécifications sont gardées secrètes par celui l'ayant développé, ou dont les spécifications sont accessibles mais dont la mise en oeuvre reste restreinte juridiquement ou techniquement ».
Il semble cependant exister un flou entre l'appelation format "libre", qui sous-entendrait, non payant, et effectivement "ouvert", c'est-à-dire libre de contrainte de license.
Dans ce contexte, Wikipédia considère logiquement qu'un format tel que le DOC de Microsoft Word est clairement propriétaire alors que le format Open Office est ouvert.
Dans le contexte Eros, les courbes de lumière, les catalogues et les fichiers de description des champs et des programmes sont naturellement ouverts, étant entièrement en ASCII, et raisonablement documentés.
A l'inverse, les fichiers binaires semblent plutôt tombés dans le camp non-ouverts - ou comme on dit au jeu d'échecs, ‟semi-fermés”. Le souci étant clairement la grande difficulté à relire ces fichiers binaires. Un effort conséquent a été consenti pour l'accès aux suivis et à la description de leur structure interne, mais il reste encore de nombreuses zones d'ombre. En particulier en ce qui concerne la description des différents attributs. Quant aux fichiers de références, ils résistent encore et toujours.
A titre de démonstration de la description du format des suivis, des outils pour permettre de les relire ont été écrits pour des langages autres que le C et sans devoir faire appel à des librairies "propriétaires" (aka, appartenant à l'expérience Eros). Le travail a été fait en Java, mais il aurait tout aussi bien pu être entrepris en Python ou autre.
Ces outils se déclinent sous deux formes. Le premier, RawCurve, permet de présenter les mesures brutes d'une étoile telles qu'elles sont enregistrées dans les différents blocs de suivis rouges et bleus. Idéalement, pour valider l'accès aux données, il faudrait pouvoir recalculer les magnitudes correspondantes afin de les comparer aux courbes de lumière. A défaut, la comparaison des mesures magnitudes valides et invalides dans les courbes de lumière avec les flux semblent montrer que le décodage est correct.
Le second, SuiviConvert, convertit un suivi binaire en Json, ou Json compressé.
Le choix s'est porté naturellement sur Json car c'est le type même du format ouvert. Il ne suppose aucune licence d'utilisation, il est supporté par de nombreux langages de programmation, dont Python, langage actuellement cher aux physiciens, et étant de type texte, il est très facile de relire les données, même sans avoir recours à une quelconque librairie – bien que cela soit tout de même plus pratique.
Certes ce n'est pas le format le plus adapté pour des opérations de traitement de masse, mais il constitué une solution pour une conservation pérenne des données de l'expérience.
La taille des fichiers est certainement un handicap à une opération de conversion de masse. Un fichier de suivi converti en Json est environ 10 fois plus volumineux que le fichier binaire original. Mais après compression Gzip, le fichier résultant est plus petit que le fichier binaire.
Le principal inconvénient reste toutefois le temps de lecture qui peut atteindre plusieurs dizaines de secondes en Python. Mais un pythoniste aguerrit pourrait sans aucun doute imaginer des optimisations lumineuses.
BSON
Il existe une variante de Json permettant la conservation des données dans un format binaire nommée Bson. On pourrait donc penser que cette approche éviterait les handicaps de la taille du fichier et du temps d'accès, mais les quelques tentatives réalisées ne vont pas dans ce sens. Le fichier Bson est certes environ deux fois plus petit que le fichier Json, mais il reste 5 fois plus volumineux que le fichier Json comprimé. Quant aux temps d'accès, ils ne sont pas meilleurs que ceux de Json, loin s'en faut. Et le support en Python semble terriblement limité et très inefficace.
Mais Bson est supposé être utilisé en interne dans la base de données MongoDb. On peut donc légitimement penser que ces soucis viennent plutôt soit d'une bibliothèque inadaptée ou plus vraisemblablement d'une utilisation incorrecte.
à suivre donc ...
FITS
Le format FITS n'est pas limité à la conservation d'images. Il peut supporter tout type de données, mais il semble plus particulièrement orienté vers des données de type tabulaire. La complexité interne des suivis semblent donc peu adaptée à ce type de format.
Autres formats
La recherche d'autres candidats ouverts, assurant à la fois de bonnes performances en termes de temps d'accès et de volume, et garantissant la pérennité des données à longs termes, restent d'actualité.
Comparaisons
à venir