logo OVNI-SCIENCES

[OVNI-SCIENCES] Catalogue

Gross, Patrick patrick.gross at roche.com
Mer 30 Nov 11:51:03 CET 2005


Désolé, je pensais répondre Lundi mais je n'ai pas pu le faire.

Proposition

Pour un projet d'étude portant sur les formes décrites dans les rapports d'observation des objets volants non identifiés.


1. Ressources

Il n'y a probablement pas besoin d'argent, et probablement besoin de gens qui prennent du temps, et de compétences dans divers domaines.

Le projet peut probablement être répartis entre les gens regroupés autour de tâches clairement définies, du type:

- ceux qui s'occupent d'outils informatiques (s'il en faut)
- ceux qui s'occupent de rédiger les hypothèses (voir plus loin)
- ceux qui définissent les structures des données (indices
de fiabilité, format des dates, "classifications", glossaires,
définition des "formes des OVNIS" etc. etc.
- ceux qui récoltent les données (qui "remplissent la base de donnée")
- ceux qui gèrent la "list of issues" (j'expliquerai)
- ceux qui rédigent les papiers avec les réponses aux hypothèses

etc ...

Cela ne veut pas dire que le travail est cloisonné, les
review devraient être faites pas tous et pratiquement
en continu "pendant la construction."

Une des première choses à faire est de rédiger une
liste des tâches.

Une chose à faire ensuite est de collecter les bonnes volontés,
et que chacun prenne quelque chose en charge ou participe à
quelque chose de précis. Le workflow, les rôles, sont à définir.

2. Déontologie

Un code de déontologie doit être fixé. Cela ne doit pas être un roman,
mais un certain nombre de principes doivent être formulées,
communiqués et respectés.

Exemples:

- Aucune attaque personnelle, seulement les travaux sont soumis à critique, pas les personnes.

- Aucun procès d'intention. Seule la validité des hypothèse est en jeu, pas des "buts soupçonnés" ou attribués aux participants. Aucun participant n'est refusé pour des question de position statement.

- Jamais de reproches, seulement des demandes.

- Aucune fraude dans les données (je sais, cela irait sans dire, mais
c'est mieux quand c'est dit).

- Aucun "pillage" des documents et données encore en construction. Quand quelque chose est fini, tout le monde peut "piller", quand quelqu'un rédige un document et le met sous révision des autres, ou a fait quelque chose, on n'en fait pas de plagiat ou de diffusion sauvage.

- Aucune critique de la quantité de travail fournie par l'un ou l'autre. Si un participant ne fait pas grand chose, on l'aide ou on cherche comment il peut être aidé, et on accepte que les disponibilités des uns et des autres et les capacités de travail des uns et des autres ne sont pas identiques.
Les parts de travail effectuées par les uns et les autres sont apparentes dans la documentation (GUP et j'expliquerai). Pas d'émotions. On ne dit pas "c'est nul", on dit "je voudrais compléter" ou "il y a une erreur ici je crois". On ne dit pas "ça ne sert à rien" on dit "à quoi ça sert?" etc.

- Pas de chef (Mais il faut un coordinateur, un modérateur etc.).
Pas d'arguments d'autorité. Pas de spéculation.

- Un langage clair et précis respectant des définitions claires des termes convenus entre les parties. Par exemple, "OVNI" n'est pas à utiliser pour remplacer "rapport d'observation d'OVNI" ni pour remplacer "engin extraterrestre".

Les recommandations GUP (j'expliquerai) sont proposées comme base de travail.

2. Formulation des hypothèses

Le projet ne doit surtout pas commencer par un remplissage d'une base de données et des extractions de "résultats".

Le projet doit d'abord avoir rédigé ses HYPOTHESES AVANT toute exploitation
de données.

Une hypothèse est toujours de la forme:

"Si (ceci) alors (cela), sinon (pas cela)."

Le projet n'est probablement pas utile à trancher seulement une hypothèse, au contraire, un grand nombre d'hypothèses peuvent probablement être rédigées et tranchées à la suite du gros du travail.

En français de tous les jours: d'abord, nous devons poser clairement les questions auxquelles des réponses sont recherchées. En aucun cas il ne faudrait faire une collection de "cas d'OVNIS" et après faire des simples comptages du type "30% des OVNIS sont carrés".

3. Les données brutes

Les données brutes sont nécessairement les rapports d'observations d'OVNI.

Il n'est probablement pas possible d'avoir les ressources nécessaires pour utiliser la totalité des rapports d'observations d'OVNIS comme matériel de base pour l'étude, ce qui pose un problème: les données retenues doivent néanmoins être représentatives de la totalité des rapports d'observation d'OVNIS. Des solutions doivent être trouvées pour garantir au mieux cette représentativité.

Le projet peut néanmoins fonctionner dans un premier temps à partir d'un ou plusieurs jeux d'essais. Des jeux d'essais modestes mais raisonnablement représentatifs de la diversité des rapports d'observations d'OVNIS permettront de définir et entreprendre la formalisation des différentes phases du projet et de construire et tester les outils et concepts requis.

3.1 Constitution ou choix de catalogues

Je propose de prendre plusieurs portions temporellement et géographiquement circonscrites des rapports d'observations d'OVNIS. A titre d'exemple je propose comme jeux d'essai:

- les rapports d'observations d'OVNIs en France du 15 septembre 1954 au 15 octobre 1954 à partir de mon listing. Facile à faire rentrer dans une structure, documentation déjà largement rassemblée,

- le "catalogue Weinstein": peu de cas, ils sont souvent bien connus, facile à faire rentrer dans uen structure, probablement peu de controverses en  perspective

- les airships: prendre une semaine d'airship de 1897. J'ai les données  brutes sous la main, je fais de toute façon les traductions.

Rappel: je propose ces exemple comme jeu d'essai, pas en tant que
"représentatifs" ou quoi que ce soit d'autre.

3.2 Définitions des données significatives

Utiliser GUP, définir, sélectionner, rédiger les explications et modes d'emploi.

Exemple: à priori on peut penser que les "arrêts de moteur de voitures" n'ont rien à voir avec les "forme de l'OVNI". Mais des hypothèses là-dessus pourraient être formulées. Il faut, si c'est le cas, savoir comment formaliser la notion "arrêts de moteur" dans les données brutes. Juste noter "arrêts de moteur: Oui/Non" peut être totalement insuffisant.

3.3 Contraintes portant sur les critères

Est-ce qu'un rapport d'OVNI en vaut un autre? Certainement pas. Des indices bien formalisés doivent être trouvés. Chaque indice doit avoir un poids dynamique. Si par exemple l'un d'entre nous décide que cela n'a qu'une petite importance que le témoin ait 10 ans ou 40 ans doit pouvoir diminuer le poids de ce critère, celui qui pense que c'est très différent si le témoin à 10 ans ou 40 ans doit pouvoir donner plus du poids à ce critère. Mais la notion "âge du témoin" est dans tous les cas à ne pas omettre d'utiliser.

Il faut définir les critères de manière complète et fiable.
Le moindre oubli peut réduire fortement ou totalement l'utilité du travail effectué.

4.4 Il y a bien d'autres points. Faire en sorte que le travail sur les données puisse resservir pour d'autres projets. Faire en sorte que tout soit vérifiable par des tiers. Les sauvegardes. etc. etc.

4. Rédaction

La documentation devrait être faite sous GUP. Ma proposition est de vous montrer ce que cela veut dire au fur et à mesure des besoins, puisque GUP est en construction. GUP est évidemment révisable, et ce n'est pas un "carcan", voir GUP comme des moyens de ne pas faire d'erreur, ce n'est pas autre chose.

5. Révisions

Avec GUP, les révisions sont clairement notées. Les documents ont un historique des changements. Les auteurs, les co-auteurs, les reviewers sont indiqués, les raisons de changements sont données. Les critiques, les problèmes, les difficultés, sont gérés via une "list of issues" qui évite les foires d'empoignes.

6. Publication

6.1 Je propose que les publications ne soient pas commerciales mais libre d'utilisation, qu'elles soient publiables sur le web par qui veut le faire, sur les sites des uns et des autres, avec comme seule contrainte que les contenus ne soit pas altérés, ni "revendiqués" de manière inappropriés. Pour faire court, si "Jean Dupont" est l'auteur d'un des documents, et que "Marcel durant" souhaite le publier sur son site ou dans sa revue, il ne supprime pas le nom de "Jean Dupont".

6.2 Je propose de tout faire en TXT ou HTML ou Word pour les brouillons mais en HTML pour les documents finaux, en séparant l'aspect "contenu" et "éléments de structure" des aspects "la taille des titres" et autres "couleurs". L'idée est que n'importe qui puisse adapter le document à son ou ses média sans trop risquer de perdre contenu et structure.

Cordialement
Patrick Gross




Plus d'informations sur la liste de diffusion Debat