Most következő bejegyzésem nem kifejezetten bioinformatikai témájú, sokkal inkább abban próbál segíteni, hogyan készítsünk olyan táblázatokat, amelyeket egy bioinformatikus is tud használni. A cél, hogy ne abból álljon a közös munka, hogy készítünk egy táblázatot, majd továbbadva azt munkatársunknak, az szintén egy csomó munkát beleöljön szükségtelenül.
Az itt leírtakat inkább iránymutatónak szánom, mint konkrét szabályoknak, mert el tudok képzelni olyan eseteket, amelyek felülírhatják az itt vázoltakat. Sőt, olyan helyzet is akadt már munkám során, amikor többen együtt sem tudtuk eldönteni, melyik táblázat lenne nekünk megfelelő.
Az azonosító maradjon azonosító
A legtöbb laborban dolgozó ember eleve használ táblázatokat, jóllehet ennek nincsenek is tudatában. Ezek egy oszlopos táblázatok szoktak lenni, ahol egyetlen oszlop tartalmaz minden információt. Például: MutMale2007A, MutMale2007B, stb. Ismerős? Biztos vagyok benne. Személy szerint nem szeretem ezt a megoldást, de mint említettem, van létjogosultsága, ha valaki az eppendorf csöveket gyorsan átnézve akarja egy gélen megfuttatni csak a férfi mintákat. Hátránya, hogy nagyon sok információt kell minden egyes alkalommal leírni. Előnye, hogy nem kell egy lapot is böngészni, ha egy kezelést csak egy csoporton kell alkalmazni.
Személy szerint az egyszerű, minimális információval rendelkező azonosítókat kedvelem. Nem az azonosítónak kell hordoznia az összes információt. Az információ száma úgyis növekedni fog a kísérletek és eredmények számával. Arról nem is beszélve, hogy hibák mindig előfordulnak. Csak képzeljük el, ha kiderül, hogy az egyik csövet már az elején rosszul cimkéztük és nem férfiból származik. Közben már futott négy PCR, két különböző kezelés, stb. Mindegyik lépésből tettünk el kis csöveket a mélyhűtő leghátsó zugába. Átcimkézünk mindent, ami többnyire lehetetlen, vagy inkább csak megcsillagozzuk, hogy tudjuk, hogy igaz, hogy ez férfi mintának van jelölve, de valójába más. Ezzel el is indultunk a káosz felé vezető úton.
Egy személytelen és minimális információval rendelkező azonosító esetén ilyen gond nincs. A táblázatot kell csak korrigálni, ahol az azonosítót hozzárendeljük az információhoz.
A másik ok, ami miatt a minimalista azonosító hasznos lehet, ha vakon akarunk dolgozni. Mivel emberek vagyunk, a prekoncepció tudat alatt módosíthatja a mintákhoz való hozzáállásunkat. PhD hallgató koromban emlékszem, én is nagy figyelemmel mértem az enzimet (a drága enzimet, mint erre minden alkalommal felhívták a figyelmemet), szemben a vak mintánál, ahol csak deszt vizet kellett hozzáadni (nem baj, ha kicsit több megy bele, hiszen ez csak a vak). De a bioinformatikai munka elején is szívesen dolgozok vakon, segít, hogy objektívebben lássam az adatot.
Ha ennek ellenére is az információ dús azonosítók mellett döntünk, akkor legalább legyenek következetesek az elnevezések. Mit értek ezalatt? Ha a fenti példánál maradva MutMale2007A jelölést használunk, akkor ne váltsunk át 2007Female1-re félúton. Az információ tartalom ugyan az, de mikor számítógépre kerülnek az adatok, roppant nehéz lesz kódot írni rá. A helyzet akkor szokott bonyolódni, ha a nem várt események történnek. Ismét csak a fenti példa okán. Kiderül, hogy MutMale2007-ből van 50 darab. Először elfogynak az angol ABC betűi, majd azon kezdünk el gondolkodni, hogy a Lineáris B vagy a Klingon karakterek felhasználásával nevezzük el a többit. Mivel mindkettő nehéz, maradnak az emoji-k.
Egy oszlop, egy információ
Ha megvan az azonosító, a táblázat többi oszlopa plusz információkkal tölthető fel. Egy oszlop egy féle információt tartalmazzon. Ezek lehetnek kategorikus változók vagy folytonosak. A folytonos látszólag nem igényel magyarázatot, de itt is akadhatnak problémák. Például a mértékegység. Egy féle mértékegységet használjunk és bár fizika órán megkövetelik, hogy írjuk ki minden szám után (Öt micsoda? Krumpli? Ahogy tiszteletre méltó tanáraim mondták.), táblázatoknál ne tegyük, mert ez után a lépés után a cella megszűnik szám lenni és szöveg lesz. Arról nem is beszélve, milyen frusztráló, ha néha kis betűvel, néha nagy betűvel van kiírva a mértékegység. Néha space-el, néha anélkül, csak, hogy szép legyen az élet.
A kategórikus változóknál is igyekezzünk elkerülni a hasonló elírásokat. Személy szerint itt is az egész számokat részesítem előnybe a kiírt nevek helyett. Habár a kiírt nevek könnyebben értelmezhetőek, ha ábrázolunk valamit, legtöbbször hiba forrásai. Ha mégis a nevek mellett döntünk, csak alfanumerikus karaktereket használjunk és minden esetben ellenőrizzük, nem történet-e elgépelés.
Természetesen itt is van kivétel. Ha a táblázatot DESeq2-ben akarjuk használni csoport képzésre, akkor előfordulhat, hogy meg kell szegnünk ezt a szabályt. A DESeq2 ugyanis csak egy oszlopban található kategóriákat használ fel a differenciál expresszióhoz. Ha tehát több kategória (oszlop) alapján akarunk géneket keresni, kénytelenek leszünk összevonni azokat.
Ne legyen túl sok oszlop
Kinek mi a sok, igaz? A Sangerben volt egy csoportvezető, akinek 107 oszlopos táblázatot kellett generálni. De ő mindig csak az utolsó hármat nézte, ami azt jelezte, hogy a mutáció képes-e tumort indukálni. Ennek ellenére ha nem kapta meg a 107 oszlopot, akkor meg sem nézte az utolsó hármat. Ha a vizsgálatainkhoz fel kell használni egy információt, akkor annak oszlopként szerepelni kell a táblázatban. Ne vigyünk be olyan adatokat, amelyeket úgysem használunk. Ne vigyünk fel olyan oszlopokat, amelyek két vagy több korábbi oszlopból kinyert adat módosulatai. A fenti esetben az utolsó három oszlop a következő volt: tumor indukáló A szerző szerint, tumor indukáló B szerző szerint, tumor indukáló A vagy B szerző szerint.
Redundancia: gondoljuk át
A redundancia kérdése elég nehéz. Alapból a redundancia mentes táblázatokat szeretem, de egyes esetekben nem ilyen egyszerű a válasz. Vegyük például a mutációs táblázatokat. Minden sor egy mutáció, tehát egy kromoszóma pozíción adott nukleotid csere. A táblázatban jelölni akarjuk, hogy melyik génben található meg. Mivel elsajátítottuk az "egy oszlop egy információ" elvet, csak egy gént viszünk fel. De mi van az átfedő génekkel? Egy mutáció ilyenkor két gént ront el. Valamelyik szabályt meg kell szegni!
Másik eset: A Variant Effect Predictorral megnézzük, hogy a mutációnk milyen változást okoz aminosav szinten. A program a gén összes transzkriptjére meghatározza ezt. Tehát egy mutációhoz több hatás is tartozhat. Itt én a redundancia mellett döntöttem, még akkor is, ha ezzel olyan triviális információt vesztek, mint a mutációk száma.
Sokszor látni olyan táblázatokat, ahol ilyen esetben a táblázattól független elválasztó karakterrel felsorolják az összes lehetséges változatot. Ez jó megoldás, ha az oszopot csak szűrésre használjuk. Amennyiben statisztikai számításhoz kívánjuk felhasználni, rögtön egy sor problémába futunk.
Az egyik megoldás két táblázat használata, a másik, hogy feltételeket szabunk Például a VEP táblázat esetén úgy döntöttünk, a leghosszabb transzkriptet nézzük csak. Mint később kiderült, ez nagyon rossz döntés volt, mert a TP53 esetén, ami a rákos elváltozások döntő többségéért felelős, egyetlen aminosav cserét sem találtunk. Mert a leghosszabb transzkript nem kódol fehérjét! Remélem ez a kis példa is mutatja, hogy egy hibásan felépített táblázat mennyi problémát okozhat.
Hiányzó értékek, kerüljük el
Természetesen nem tudjuk elkerülni őket. Mindig van hiányzó adat. A hiányzó adatnál már csak a bizonytalan adat a rosszabb. Egy szám és mögötte egy kérdőjel. Ha hiányzó érték van, az egyérteműen látszódjon. Ne úgy, hogy pirossal kiszínezzük a cellát! Folytonos változóknál az NA tökéletes, még az R is megérti. A 0 csak akkor jó, ha 0 nem lehet egyébként a táblázatban, tehát nem keverhetjük össze értékkel.
Amikor egy táblázat nem elég
Ha a komplexitás nagyon megnő, felesleges egy táblázatba préselni mindent. Inkább legyen több, kisebb táblázat, mint egy monolitikus, de használhatatlan. Ha a táblázatok száma kezd nagyon megszaporodni, inkább használjunk adatbázisokat. Felépítésük időigényes, de után kinyerhetjük az adatokat mindenki ízlése szerint. Természetesen egy adatbázist elfogadtatni egy Excel központú világban nagyon nehéz. A legjobb, ha nem is borzoljuk vele mások idegeit, csak használjuk. Ha pedig sürgősen szüksége van az adatok más formában való prezentálására, csak írjunk egy lekérdezést 10 másodperc alatt.
