Strange filename

[lecorguille]

Some exchange with @melpetera

[lecorguille]

@lecorguille - 15/02/16

Salut,

Par acquis de conscience, j’ai été plus loin dans la workflow avec ton jeu de données NawakName.

Je t’ai partagé l’historique.

Le dataset 3 correspond au sampleMetadata.tsv

sampleMetadata
class
PI'jom_V3
GP1
PI-lf _V1
GP1
PI@pu=_V2
GP1
59QC_1
GP2
QC$ge_2
GP2
QC&jji2_3
GP2

Le dataset 20 correspond à la dataMatrix en sortie de Camera.

name
PI.jom_V3
PI.lf._V1
PI.pu._V2
X59QC_1
QC.ge_2
QC.jji2_3
M104.1066T25
29802600.403425
50582118.1635
34393965.3052187
59992724.267
59665119.0867667
40202179.359
M115.0363T25
16612064.429925
13030380.0487438
10346312.6916187
21226893.373
19698261.7257667
12842090.2440667

On voit bien que ça ne va pas coller.

Faut-il que je fasse un make.names sur sampleMetadata ou que je force les noms (si c’est possible) dans la dataMatrix ?

Je pense que la première solution est la mieux si on prévient bien du changement de nom dans les logs et dans le report !?

Quant penses-tu ? Est-ce que finalement tes scripts savent gérer ça ?

Gildas

[lecorguille]

@melpetera - 16/02/16

Bonjour Gildas,

A la base, suite aux discussions que nous avions tenus sur les caractères spéciaux l'année dernière, nous avions convenu de prendre en charge les caractères spéciaux (a minima les plus courant). Du coup, j'aurais plutôt tendance à prendre la solution 2. Mais par contre du coup, il faut éviter de le faire sans vérification : normalement c'est dans le même ordre, mais comme on n'est jamais trop prudent j'aurais tendance à placer quelques checks avant, on ne sait jamais.

Du coup, ce que je conseille c'est que juste avant d'exporter le fichier dataMatrix tu fasses comme suit :

1. Vérifier que le make.names sur les sample names donne un identifiant unique (sinon renvoyer une erreur)
   => Il est assez peu probable que ça bug à cet endroit, mais s'il y a un problème il faudra de toute façon y faire quelque chose car sinon le résultat renvoyé n'est pas bon (voir Nawak 2 que je t'ai partagé : un des deux identifiants donnant le même make.names reste dans le variableMetadata). Du coup, ce que je préconise c'est de renvoyer une erreur ici, comme ça si jamais ce cas de figure venait à arriver à quelqu'un un jour, le plus simple sera de lui demander de renommer un des échantillons concernés dans ses noms de raw pour le rendre make.names-unique.

2. Vérifier que le make.names sur les sample names soit identique (i.e. dans le même ordre) que les noms en header de la dataMatrix (normalement c'est bon, mais là encore un message d'erreur si ce n'est pas le cas est le bienvenu)

3. Remplacer les noms dans la dataMatrix par les sample names (sans make.names).

Est-ce que cette solution te convient ? Si tu as des questions ou veut un coup de main niveau ligne de code n'hésite pas.

Mélanie

[lecorguille]

@lecorguille - 16/02/16

Salut,

Je pense que ça fera l’objet d’une autre mise à jour. Il faut vraiment déployer la version en attente au plus vite.

3. Est-ce que des noms colonnes à la Nawak poseront problème par la suite (batch_correction, ...) ?

• la présence de chiffres en début de nom de colonne
• la présence de $, ', =

Est-ce qu’on considère que la protection dans des "" garanties une bonne compatibilité par la suite avec tous les outils possibles et imaginables ? Sachant que nos outils W4M ne sont pas une finalité et qu’il est envisageable que d’autres développements viennent compléter le workflow ?

Sinon, quels caractères devons nous vraiment bannir ?
Sachant l’imagination débordante des users, quels caractères autoriser ?

Je suis d’accord que nous revenons à un vieux débat mais vu tes Nawaks :)

Gildas

[lecorguille]

@melpetera - 17/02/16

Bonjour Gildas,

Et bien, même si actuellement tout le monde n'a pas encore intégré easyRLibrary, normalement si la chose était faite tous les caractères de Nawakname seraient bien gérés. Mais en un an, malgré la décision prise en commun et l'accès pour tous à easyRLibrary, à part moi personne n'a pris le temps d'intégrer le truc à ses outils (pourtant ce ne sont que quelques micro lignes).

Si on veut s'assurer la compatibilité avec d'autres modules hors W4M, c'est simple : R ne tolère de base en nom de colonne QUE le point et l'underscore en caractère non alphanumérique, et ne tolère pas les chiffre en début de nom. Et la protection via des guillemets est assez illusoire, car dans tout un tas de fonctions de base de R on est pris en traître à moins d'avoir une vigilance constante à ce niveau (et à ce compte là, c'est carrément plus simple d'intégrer un truc comme les fonctions de easyRlibrary en amont et aval de son code). Donc s'il faut banir, c'est tout sauf "." et "_" tout simplement (+ pas de chiffre en début évidemment).

Ça me va si cette question est reportée à une prochaine mise à jour, et que pour l'instant tu fais juste une solution rapide (make.names sur le sampleMetadata par exemple), mais il faudra bien y penser par la suite.

Si tu as d'autres questions n'hésite pas.

Bonne journée,
Mélanie

[lecorguille]

@lecorguille - 17/02/16

Salut,

Je comprend ton désarrois concernant easyRLibrary. A l’époque, à tord, je me disais que nous ne manipulions pas de tableaux. C’est en effet faux puisque nous en générons :)

Je vais regarder ça de plus près dès que possible.

En attendant, au plus cours, je vais faire un make.names sur les sampleMetadata et vérifier à minima la présence de doublons. Je vais aussi essayer d’intégrer un truc du genre dans le report.

Merci

Gildas

[lecorguille]

@lecorguille

Salut,

J’ai appliqué le make.names à SampleMetadata et vérifié les doublons (error)

Merci pour ta revue de beta sérieuse et complète.

Gildas