[OVNI-SCIENCES] Catalogue

[lexav]

Approbation a 120%.

Je n'ai pas beaucoup de temps, je fais probablement partie de
"ceux qui s'occupent des outils informatique".
Je peux suggérer des outils, je suis assez bon pour donner en général
des conseils: et je privilégie le plus possible l'approche
    - outils gratuits mais de qualité (logiciel libre, etc.. et en général
d'un bon niveau
technique, ce qui ne veut (surtout)pas dire "compliqué a utiliser".
    - outils utilisables par (presque) tout un chacun.
Bon, c'est tout pour le moment.
a+


----- Original Message -----
From: "Gross, Patrick" <patrick.gross at roche.com>
To: <debat at ovni-sciences.net>
Sent: Wednesday, November 30, 2005 11:51 AM
Subject: RE: [OVNI-SCIENCES] Catalogue



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


_______________________________________________
Debat mailing list
Debat at ovni-sciences.net
http://www.ovni-sciences.net/mailman/listinfo/debat