Soit ils ont la science infuse, soit ils savent calibrer par qu'ils ont les données, le temps et la connaissance, rien ne dit qu'un type dans son garage n'en est pas au même point (ou a la capacité d'y arriver, pour le fun par exemple).
Déjà, définissons clairement ce qui est fait, vu que je ne suis pas sur que tu saches de quoi on parle. Les conditions de tout les capteurs ne peuvent pas être connus (car sinon, c'est que tu utilises un capteur pour mesurer les conditions du capteur, mais qui mesure les conditions du capteur de capteur ?).
Il faut donc créer une calibration sur base des données elles-mêmes, intégrées à des simulations qui en général constituent une quantité de donnée bien plus importante. En d'autres termes: on ne peut pas connaitre la calibration des données avant d'avoir analysé les données, ce qui prend le temps qui a été pris ici avant de rendre les données publiques.
Tout démontre que le type dans son garage n'en est pas au même point. Le type dans son garage n'a pas étudié le problème 40h par semaine durant des années, sur base de résultat eux-même "work in progress" et donc pas encore publiable et donc public (à moins que tu considères que toutes les semaines, il faut passer une semaine à faire du reviewing pour publier un work-in-progress qui peut s'avérer faux une semaine plus tard, de l'argent bien dépensé, ou bien qu'il faut publier sans reviewing et donc s'en foutre de la qualité des conclusions qu'on est payé pour produire).
Si quelqu'un est au même point qu'eux, pourquoi ne fait-il pas partie de la collaboration ? Il suffit d'aller dans l'université collaboratrice la plus proche et parler à un chef de projet.
S'ils n'ont même pas pris la peine de faire ça, c'est surement qu'ils n'en sont pas au même point. Comment pourraient-ils en être au même point s'ils n'ont aucun contact avec les personnes qui ont conçus le détecteur et qui connaissent les détails nécessaires pour comprendre les données ?
Mais lequel ? Que des gens jouent avec et se trompent ? Je ne vois pas en quoi c'est un problème.
Déjà, les gens ne peuvent que se tromper, vu qu'ils leur manquent des pièces fondamentales pour comprendre les données. Ces pièces ne peuvent être apportées que par les experts après que ceux-ci aient vu les données. Et à ce moment-là, ils donnent les pièces (sous forme du texte d'un article), et les données.
Ensuite, si les gens en tirent des conclusions forcément fausses, pourquoi ont-ils besoin des données ? Pourquoi ne pas s'amuser avec /dev/random directement ?
Ce que tu proposes, c'est de distribuer publiquement un fichier généré à partir de /dev/random (car c'est totalement équivalent) et de dire que ce sont les données (même si on rajoute un gros tampon "non exploitables"). C'est donc bel et bien de la confusion inutile.
De nouveau, personne n'empêche les gens de jouer avec les données. Au contraire, les données leur sont même donnée calibrée. Pourquoi pleurnicher sur le fait que les scientifiques t'ont fait patienter 2 semaines pour te donner des données qui sont 1000x plus intéressantes pour jouer avec ?
Non, c'est un des gros problème de la recherche actuel, on ne publie pas assez de résultat en sortant toujours une excuse. Mais dans 10 ans, on se rendra compte qu'on a besoin des données non-calibrées pour d'autres analyses et plus personne ne les aura.
Donc, t'es en train de dire: "dans 10 ans, tout les disques privés de ces projets seront effacés, mais dans 10 ans, on voudra utiliser ces données alors qu'on aura perdu toutes les informations nécessaires à faire une calibration correcte".
Les données brutes sont conservées le mieux possibles, mais c'est sans doute les éléments les moins importants à conserver, vu que sans toutes les informations de calibration, ces données ne sont pas plus informatives que /dev/random (c'est en réalité pire, vu qu'on peut y mesurer une valeur, mais que cette valeur est fausse avec un décalage d'on ne sait absolument pas combien).
Au pire, si tu veux les données brutes, pourquoi ne pas appliquer la fonction inverse de la calibration ?
[^] # Re: Données renvoyées par philae
Posté par j-c_32 . En réponse au journal Les premières photos de Philae. Évalué à 3.
Déjà, définissons clairement ce qui est fait, vu que je ne suis pas sur que tu saches de quoi on parle. Les conditions de tout les capteurs ne peuvent pas être connus (car sinon, c'est que tu utilises un capteur pour mesurer les conditions du capteur, mais qui mesure les conditions du capteur de capteur ?).
Il faut donc créer une calibration sur base des données elles-mêmes, intégrées à des simulations qui en général constituent une quantité de donnée bien plus importante. En d'autres termes: on ne peut pas connaitre la calibration des données avant d'avoir analysé les données, ce qui prend le temps qui a été pris ici avant de rendre les données publiques.
Tout démontre que le type dans son garage n'en est pas au même point. Le type dans son garage n'a pas étudié le problème 40h par semaine durant des années, sur base de résultat eux-même "work in progress" et donc pas encore publiable et donc public (à moins que tu considères que toutes les semaines, il faut passer une semaine à faire du reviewing pour publier un work-in-progress qui peut s'avérer faux une semaine plus tard, de l'argent bien dépensé, ou bien qu'il faut publier sans reviewing et donc s'en foutre de la qualité des conclusions qu'on est payé pour produire).
Si quelqu'un est au même point qu'eux, pourquoi ne fait-il pas partie de la collaboration ? Il suffit d'aller dans l'université collaboratrice la plus proche et parler à un chef de projet.
S'ils n'ont même pas pris la peine de faire ça, c'est surement qu'ils n'en sont pas au même point. Comment pourraient-ils en être au même point s'ils n'ont aucun contact avec les personnes qui ont conçus le détecteur et qui connaissent les détails nécessaires pour comprendre les données ?
Déjà, les gens ne peuvent que se tromper, vu qu'ils leur manquent des pièces fondamentales pour comprendre les données. Ces pièces ne peuvent être apportées que par les experts après que ceux-ci aient vu les données. Et à ce moment-là, ils donnent les pièces (sous forme du texte d'un article), et les données.
Ensuite, si les gens en tirent des conclusions forcément fausses, pourquoi ont-ils besoin des données ? Pourquoi ne pas s'amuser avec /dev/random directement ?
Ce que tu proposes, c'est de distribuer publiquement un fichier généré à partir de /dev/random (car c'est totalement équivalent) et de dire que ce sont les données (même si on rajoute un gros tampon "non exploitables"). C'est donc bel et bien de la confusion inutile.
De nouveau, personne n'empêche les gens de jouer avec les données. Au contraire, les données leur sont même donnée calibrée. Pourquoi pleurnicher sur le fait que les scientifiques t'ont fait patienter 2 semaines pour te donner des données qui sont 1000x plus intéressantes pour jouer avec ?
Donc, t'es en train de dire: "dans 10 ans, tout les disques privés de ces projets seront effacés, mais dans 10 ans, on voudra utiliser ces données alors qu'on aura perdu toutes les informations nécessaires à faire une calibration correcte".
Les données brutes sont conservées le mieux possibles, mais c'est sans doute les éléments les moins importants à conserver, vu que sans toutes les informations de calibration, ces données ne sont pas plus informatives que /dev/random (c'est en réalité pire, vu qu'on peut y mesurer une valeur, mais que cette valeur est fausse avec un décalage d'on ne sait absolument pas combien).
Au pire, si tu veux les données brutes, pourquoi ne pas appliquer la fonction inverse de la calibration ?