Feltételezve, hogy az "ember által olvasható", a "könnyen értelmezhető" és a "gyorsan lekérdezhető" elemeket objektíven jó tulajdonságoknak tekintjük (és ha nem, akkor aggódom a jövő miatt):

1. Szöveg- alapú: Abszurd módon gyakori, hogy a grep vagy az awk elemeket szeretné használni a kommentárokban. Persze lehetne ezeknek bináris formátumú változatait ismerni, de miért kellene újból feltalálni a kereket. Természetesen a szöveges fájlok nem engedik meg a tartalmuk régióalapú lekérdezését, így tovább a 2. pontra ...
   • Ennek kifejezetten vonal-alapúnak kell lennie. A mezőket tabulátorral kell elválasztani (ideális esetben az ascii rekord elválasztó karaktert használja, de attól tartok, hogy a hajó már régen hajózott).
2. Szigorúan meghatározott sorrend: Ez az egyik személyes kedvencem a BED / GFF / GTF fájlokkal kapcsolatban. Ha szöveges kommentár formátumot szeretne készíteni, mindenki előrébb kerül, ha az említett formátum egyértelművé teszi, hogy rendezni kell. Ez lehetővé teszi például a tabix használatát, így a "lekérdez egy régiót" probléma megoldódik. De ennél tovább mennék. A GFF-hez hasonló kérdés az, hogy több, egymástól függő vonal létezik, és nincs szigorú szabály arra vonatkozóan, hogy a szülői vonalnak feltétlenül a gyermeksor elé kell-e kerülnie. Ez csak rémálommá teszi a dolgok végrehajtását, és egy véletlenszerűen rendezett fájl gyakran csak széttöri az eszközöket. Mivel a GTF vagy GFF stílusú, egymástól függő vonalak valószínűleg minden kommentárformátum működését mutatják, ezt az azonos kezdő pozícióval rendelkező sorok közötti sorrendet a formátumban kell egyértelművé tenni.

A probléma az, hogy a GFF alapvetően relációs formátum: olyan címkéket biztosít, amelyek az egyes sorokat egymás elleni kapcsolatokon keresztül (pl. gén – exon) kapcsolják össze. Ez közvetett módon kiemeli a második bonyodalmat: az egyes sorok különböző típusúak, ezért különböző attribútumokat tárolnak a 9. oszlopban.

Az elmúlt évtizedekben (!) Rengeteg elméletet és eszközt gyűjtöttünk a munkához. ilyen adatokkal. A szokásos megoldás pedig egy adatbázis-séma létrehozása egy relációs adatbázis számára, valamint az adatbázis-illesztőprogramok és az adatbázis-lekérdezési nyelvek használata (pl. SQL, de egyre inkább olyan adat-relációs leképezők is, mint a LINQ és a dplyr). a szöveges formátum sok okból vonzó, amelyeket Devon említ, de alapvetően ellentmond a relációs adatok sok elméletének és eszközének. Ez impedancia eltérést eredményez.

Meggyőződésem, hogy hosszú távon a megoldást a relációs adatbázisok komplex annotációkhoz történő felhasználása jelenti. Azt mondom, hogy „visszavonás” annak ellenére, hogy ezek az adatbázisok már léteznek, a bioinformatikusok napi munkájában egyszerűen figyelmen kívül hagyják őket ( soha nem használom őket). Mert objektíven ez a legjobb technikai megoldás, és ezt alátámasztó kutatások állnak rendelkezésünkre.

Nagyon szeretem a BED-et és a GFF3-at (a GTF / GFF2-t viszont nem szeretem). Szövegalapú formátumokként nem hiszem, hogy sok fejlődési lehetőséget hagynának számunkra. Egyébként, ha új formátumot szeretne, itt van egy. Az alábbiakban a GFF3 és a BED hibridje látható. Ez egy TAB-elhatárolt szöveges formátum, a következő mezőkkel:

1. chr, kötelező
2. start (0-alapú), kötelező
3. vége, kötelező
4. szál
5. azonosító
6. típusa (lásd alább)

A BED-hez hasonlóan csak az első 3 oszlop szükségesek, a többi opcionális. Ami más, a "type" mezővel kezdődik, mint a GFF-ben. Ez a "típus", ha van, meghatározza az azt követő oszlopokat. Például, ha type == kódolás, akkor lehet cdsStart, cdsEnd, blockCount, blockSizes és blockStarts, mint a BED; ha type == exon, akkor a 7. oszlop lehet egy "fázis", jelezve az első bázis fázisát. Így a "type" teszi ezt a formátumot nagyon kibővíthetővé, ugyanakkor viszonylag könnyen elemezhetővé az opcionális címkék teljes használatához képest. Ezenkívül lehet, hogy az egyes sorok végén féligbél elválasztott "kulcs" = "érték" párok vannak, mint a GFF3-ban. Példa:

  chr1 10000 50000 - x1 kódolás 10100 40800 2 1000,2000 10000,48000chr1 10000 11000 - * exon * foo1 = bar1; foo2 = bar2chr1 48000 50000 - * exon 2chr2 10000 50000  kód> 

A fentiek csak csupasz formát adnak. Finom kérdések vannak, például: 1) az azonosítás egyedisége / hatóköre; 2) van-e rögzített mezőként vagy típus-specifikus mezőként szülőazonosító; 3) hová kell tenni a megjelenített nevet; 4) rendezési sorrend. Ezek fontosak a gyakorlatban is. A formátumok hasznosak a sorosításhoz és az adatátvitelhez. Kevesebb készségre van szükségük a munkavégzéshez és kevesebb szoftver / hardver erőforrás telepítéséhez. A formátumok gondosan megtervezett bináris ábrázolása sok felhasználási esetben sokkal hatékonyabb lehet.

Csak eldobni ezt, mivel a legjobb dolgok már elhangzottak, de miért kell meghatározni a bioinformatikai adatformátum szigorú specifikációját? Ahogy mondod, általában az történik, hogy minden művelet az opcionális mezőkbe kerül.

Sok mindent el lehet mondani a libertariánus értékekért, ha csak hagyod, hogy az emberek maguk találják ki. Vegye ki az opcionális mezőket a BAM tag specifikációban. például. Itt lehet saját címkéje, de ezeknek „X”, „Y” vagy „Z” betűkkel kell kezdődniük, és utánuk kell lenniük az „[A-Za-z0-9]” kifejezéssel. Miért? Miért nem használhatják az emberek a saját címkéiket, például "egyedi olvasás", "a genom távolságának szerkesztése" vagy bármi más, amit akarnak. Nem bíznak-e bennünk a dolgok megnevezésének és a dolgok önkényes felidézésének ereje? Ennek eredményeként meg kell keresni a címke nevének tényleges jelentését az azt létrehozó eszköz kiadványában, vagy meg kell kérdeznie bizonyos fórumokon stb. És ez azt feltételezi, hogy ismeri az eszközt, amely az olvasásokat készítette - ha nem, akkor ki tudja a wtf ' Az XT 'jelentése.

Lényegében az opcionális mezők későbbi olvasói már bíznak abban, hogy az' XT 'az, aminek gondolja. Tehát, ha szívesen használunk opcionális mezőket bármilyen kapacitással, miért állunk meg a mezőknél?

Kiterjessze ezt a logikát az adatformátum oszlopaira. Hagyja, hogy a felhasználók meghatározzák az oszlopok nevét. Előfordulhat, hogy egy kék holdban egyszer találkozik egy fájllal, amelynek a kromoszóma oszlopának neve "chr", nem pedig "kromoszóma", de legtöbbször azt fogja keresni, hogy "read kvantum-radioaktív", és észleli és rögzíti a A hibák nem jelentenek akkora problémát, mint egy olyan adatformátum használata, amely nem tárolja azt, amit tárolni szeretne. Vagy ami még rosszabb, tárolni tudja, de valóban logikátlan módon, ami azt eredményezi, hogy mindenkinek, aki az adatformátumot használja, legalább 3 kérdést kell feltennie itt vagy más fórumokon, mielőtt megértenék, mi is történik valójában.

Tehát egy általános megoldást talál a táblázatos információk kompatibilis tárolásának problémájára számos különféle szoftverben, más néven SQL-ben (vagy bármilyen más általános célú adatbázisban, például REDIS, Neo4J, Numpy) stb.). Valójában egyáltalán számít, mi az az adattár, mindaddig, amíg táblázatos, és minden elemhez tartozik a "kromoszóma" és a "pozíció" értéke?

TL; DR - Nem a holnap legjobbjára gondolunk adatformátum ma, mert a holnap adatainak jellege még nem ismert. A kevesebb rendfenntartás ezen a területen valószínűleg robusztusabb szoftvert eredményezne, ahol semmi sem magától értetődő, és az adatokkal kapcsolatban sem lehet feltételezni, amíg a sémát nem elemezték.

Valójában csak ezért úgy gondoljuk, hogy meg kell adnunk az adatformátumokat, mert tudjuk, hogy ha nem tettük meg, akkor más emberek olyat fognak tenni, amire nem gondoltunk - és szerintem hamisan feltételezzük, hogy ez rossz lesz.