"İnsan tarafından okunabilir", "kolayca çözümlenebilir" ve "hızlı bir şekilde sorgulanabilir" nitelikleri objektif olarak iyi nitelikler olarak kabul ettiğimizi varsayarsak (ve değilse, gelecek için endişeleniyorum):

1. Metin- tabanlı: Ek açıklamalarda grep veya awk kullanmak çok yaygın bir durumdur. Elbette, bunların ikili format farkındalığı olan varyantları yapılabilir, ancak neden tekerleği yeniden icat edin. Elbette metin dosyaları, içeriklerinin bölge bazlı sorgulamalarına doğal olarak izin vermez, bu yüzden 2. noktaya kadar ...
   • Bu, ayrıca açıkça satır temelli olmalıdır. Alanların sekmeyle ayrılması gerekir (ideal olarak bunun yerine ascii kayıt ayırıcı karakterini kullanırdı, ancak geminin çoktan kalktığından korkuyorum).
2. Kesinlikle tanımlanmış satır sırası: Bu, BED / GFF / GTF dosyalarıyla ilgili kişisel evcil hayvanımdan biridir. Metin tabanlı bir açıklama formatı yapacaksanız, söz konusu formatın sıralanması gerektiğini açıkça belirtmesi durumunda herkes ileride olacaktır. Bu daha sonra tabix gibi şeylerin kullanılmasına izin verir, böylece "bir bölgeyi sorgulama" problemi çözülür. Ama ben bundan daha ileri giderdim GFF gibi şeylerle ilgili sorun, birden fazla birbirine bağlı satır olması ve bir üst satırın kesinlikle bir alt satırdan önce gelmesi gerekip gerekmediğine dair kesin bir kural olmamasıdır. Bu, bir şeyleri uygulamayı bir kabusa dönüştürür ve rastgele sıralanan bir dosya çoğu zaman araçları bozar. GTF veya GFF tarzı birbirine bağlı satırlar büyük olasılıkla herhangi bir ek açıklama formatının çalışma şekli olduğundan, aynı başlangıç ​​konumuna sahip satırlar arasındaki bu sıralama, formatta açıkça belirtilmelidir.

Sorun, GFF'nin temelde ilişkisel bir format olmasıdır: tek tek satırları bire çok ilişkiler (ör. gen-ekson) aracılığıyla ilişkilendiren etiketler sağlar. Bu, dolaylı olarak ikinci zorluğun altını çiziyor: ayrı satırların farklı türleri vardır ve bu nedenle 9. sütunda farklı nitelikler depolar.

Son birkaç on yılda (!), Çalışmak için çok sayıda teori ve araç biriktirdik. bu tür verilerle. Ve genel çözüm, ilişkisel bir veritabanı için bir veritabanı şeması oluşturmak ve veritabanı sürücülerini ve veritabanı sorgu dillerini (örneğin SQL, ancak LINQ ve dplyr gibi veri ilişkisel eşleştiricileri de giderek daha fazla kullanmaktır) kullanmaktır.

Kullanma Metin tabanlı bir format, Devon'un bahsettiği birçok nedenden dolayı caziptir, ancak temelde ilişkisel verilere yönelik birçok teori ve araçla çelişmektedir. Bu bir empedans uyumsuzluğu yaratıyor.

Uzun vadede çözümün karmaşık ek açıklamalar için ilişkisel veritabanları kullanmaya döneceğine ikna oldum. Bu veritabanları zaten mevcut olsa da "geri dön" diyorum, bunlar genellikle biyoinformatisyenlerin günlük çalışmalarında göz ardı ediliyor ( Ben asla kullanmam). Çünkü nesnel olarak en iyi teknik çözüm bu ve bunu destekleyecek araştırmalarımız var.

BED ve GFF3'ü çok seviyorum (yine de GTF / GFF2'yi sevmiyorum). Metin tabanlı formatlar olarak, bize iyileştirme için fazla alan bıraktıklarını düşünmüyorum. Her neyse, yeni bir format istiyorsanız, işte bir tane. Aşağıdaki GFF3 ve BED arasında bir melezdir. Aşağıdaki alanlara sahip, TAB ile ayrılmış metin tabanlı bir biçimdir:

1. chr, gerekli
2. start (0 tabanlı), gerekli
3. end, gerekli
4. strand
5. ID
6. type (aşağıya bakın)

BED gibi, sadece ilk 3 sütun gereklidir, gerisi isteğe bağlıdır. Farklı olan, GFF'deki gibi "tür" alanıyla başlar. Bu "tip", mevcut olduğunda, onu takip eden sütunları tanımlar. Örneğin, tür == kodlama ise, BED gibi cdsStart, cdsEnd, blockCount, blockSizes ve blockStarts'a sahip olabiliriz; tür == ekson ise, sütun 7, birinci tabanın aşamasını gösteren bir "aşama" olabilir. Bu şekilde, "tür", bu biçimi oldukça genişletilebilir hale getirirken, isteğe bağlı etiketleri tamamen kullanmaya kıyasla ayrıştırması nispeten daha kolaydır. Ayrıca, GFF3'te olduğu gibi her satırın sonunda noktalı virgülle ayrılmış "anahtar" = "değer" çiftleri olabilir. Örnek:

  chr1 10000 50000 - x1 kodlama 10100 40800 2 1000,2000 10000,48000chr1 10000 11000 - * exon * foo1 = bar1; foo2 = bar2chr1 48000 50000 - * exon 2chr2 10000 50000  

Yukarıdakiler, yalnızca biçimin çıplak bir eklemini verir. Şunlar gibi ince sorular vardır: 1) kimliğin benzersizliği / kapsamı; 2) sabit bir alan veya türe özgü bir alan olarak ana kimliğe sahip olunması; 3) görünen adın nereye koyulacağı; 4) sıralama düzeni. Bunlar pratikte de önemlidir.

Not: SQL'i çok seviyorum ve biyoenformatikte daha sık kullanılması gerektiğini düşünüyorum, ancak metin formatlarının yerini tamamen aldığını düşünmüyorum. Formatlar, serileştirme ve veri aktarımı için kullanışlıdır. Çalışmak için daha az beceri ve konuşlandırmak için daha az yazılım / donanım kaynağı gerektirirler. Biçimlerin dikkatlice tasarlanmış ikili gösterimleri, birçok kullanım durumunda çok daha verimli olabilir.

En iyi şeylerin zaten söylendiği gibi bunu oraya atıyorum, ancak neden biyoinformatik veri formatı için katı bir spesifikasyon belirtmek gerekiyor? Sizin de söylediğiniz gibi, tipik olarak olan şey, tüm eylemin isteğe bağlı alanlarda sona ermesidir.

Özgürlükçü değerler için insanların kendi başlarına çözmelerine izin vermenin söylenecek çok şeyi var. BAM etiketi spesifikasyonundaki isteğe bağlı alanları alın. Örneğin. Burada kendi etiketleriniz olabilir, ancak "X", "Y" veya "Z" ile başlamalı ve ardından "[A-Za-z0-9]" gelmelidir. Neden? İnsanlar neden "okumak benzersizdir" veya "genoma olan mesafeyi düzenle" gibi kendi etiket adlarını veya ne isterlerse kullanamıyor? Bir şeyleri isimlendirme ve keyfi olarak hatırlama gücüne güvenilmeyecek mi? Sonuç, etiket adının onu üreten aracın yayınındaki gerçek anlamına bakmalı veya belirli forumlarda sormalı, vb. Ve bu, okumaları üreten aracı bildiğini varsaymaktır - değilse o zaman wtf'yi kim bilir ' XT'nin kısaltmasıdır.

Esasen, isteğe bağlı alanların aşağı akış okuyucuları, zaten "XT" nin düşündüğü şey olduğuna güveniyor. Öyleyse, herhangi bir kapasitede isteğe bağlı alanları kullanmaktan memnunsak, neden alanlarda duralım?

Bu mantığı veri formatının sütunlarına kadar genişletin. Kullanıcıların sütun adlarını belirlemesine izin verin. Mavi ayda bir kez kromozom sütununu "kromozom" yerine "chr" olarak içeren bir dosyaya rastlayabilirsiniz, ancak çoğu zaman "okumak kuantum radyoaktiftir" ve adlandırma tespit ve sabitleme arayacaksınız. hataları saklamak istediğiniz şeyi saklamayan bir veri formatı kullanmak kadar sorun olmayacaktır. Ya da daha kötüsü, onu depolayabilir, ancak gerçekten mantıksız bir şekilde, veri biçimini kullanan herkesin gerçekte neler olup bittiğini anlamadan önce burada veya diğer forumlarda en az 3 soru sormasına neden olur.

Sonuç olarak, SQL olarak da bilinen birçok farklı yazılım türünde (veya REDIS, Neo4J, Numpy gibi diğer herhangi bir tür genel amaçlı veritabanı) uyumlu bir şekilde tablo şeklindeki bilgileri depolama sorununa genel bir çözüm bulursunuz. , vb). Aslında, tablo halinde olduğu ve her bir öğe için "kromozom" ve "konum" değerlerine sahip olduğu sürece, veri deposunun ne olduğu önemli mi?

TL; DR - Yarının en iyisini düşünmeyeceğiz bugün veri biçimi, çünkü yarının verilerinin doğası henüz bilinmemektedir. Bu alanda daha az polislik, büyük olasılıkla, hiçbir şeyin kesin olarak kabul edilmediği ve şema ayrıştırılıncaya kadar veriler hakkında hiçbir varsayımda bulunulamayacağı daha sağlam bir yazılımla sonuçlanır.

Gerçekte, biz veri biçimlerimizi belirtmemiz gerektiğini düşünüyorum çünkü yapmazsak başkalarının düşünmediğimiz bir şeyi yapacağını biliyoruz ve bence yanlış bir şekilde bunun kötü olacağını varsayıyoruz.