Forutsatt at vi anser "menneskelig lesbar", "lett å tolke" og "raskt spørbar" som objektivt gode egenskaper (og hvis ikke, bekymrer jeg meg for fremtiden):

1. Tekst- basert: Det er absurd vanlig å ønske å bruke grep eller awk på merknader. Visst, man kan lage varianter av disse som er oppmerksom på binært format, men hvorfor gjenoppfinne hjulet. Selvfølgelig tillater ikke tekstfiler medfødte regionbaserte spørsmål om innholdet, så videre til punkt 2 ...
   • Dette bør videre eksplisitt være linjebasert. Felter må skilles fra tabulatorer (ideelt sett bruker den ascii-skilletegnet i stedet, men jeg frykter at skipet for lengst har seilt).
2. En strengt definert linjebestilling: Dette er en av mine personlige kjæledyrdeksler om BED / GFF / GTF-filer. Hvis du skal lage et tekstbasert kommentarformat, ville alle havne foran hvis formatet ble eksplisitt at det skulle sorteres. Dette gjør at ting som tabix kan brukes, slik at problemet "spør en region" løses. Men jeg vil gå lenger enn det. Problemet med ting som GFF er at det er flere innbyrdes avhengige linjer, og det er ingen streng regel om en foreldrelinje absolutt må komme før en underordnet linje. Dette gjør bare implementering av ting til et mareritt, og oftere enn ikke vil en tilfeldig bestilt fil bare ødelegge verktøy. Siden GTF- eller GFF-innbyrdes avhengige linjer sannsynligvis er hvordan et kommentarformat fungerer, bør denne bestillingen mellom linjer med samme startposisjon gjøres eksplisitt i formatet.

Problemet er at GFF i utgangspunktet er et relasjonelt format: det gir koder som relaterer individuelle rader via en-til-mange relasjoner (f.eks. gen – exon). Dette fremhever indirekte den andre komplikasjonen: enkelte rader har forskjellige typer, og lagrer derfor forskjellige attributter i 9. kolonne.

I løpet av de siste tiårene (!) Har vi samlet en mengde teori og verktøy for å jobbe med denne typen data. Og den vanlige løsningen er å lage et databaseskjema for en relasjonsdatabase, og å bruke databasedrivere og databasespørsmål (f.eks. SQL, men i økende grad også datarelasjonskartleggere som LINQ og dplyr).

et tekstbasert format er attraktivt av mange grunner som Devon nevner, men det er fundamentalt i strid med mye av teorien og verktøyene for relasjonsdata. Dette skaper en impedansavvik.

Jeg er overbevist om at løsningen på sikt vil være å gå tilbake til å bruke relasjonsdatabaser for komplekse merknader. Jeg sier "tilbakestill" selv om disse databasene allerede eksisterer, blir de rett og slett ofte ignorert i bioinformatikernes daglige arbeid ( Jeg bruker dem aldri). Fordi dette er objektivt sett den beste tekniske løsningen, og vi har forskningen for å sikkerhetskopiere dette.

Jeg liker BED og GFF3 (jeg liker ikke GTF / GFF2, skjønt). Som tekstbaserte formater, tror jeg ikke de gir oss mye rom for forbedringer. Uansett, hvis du vil ha et nytt format, er det ett. Følgende er en hybrid mellom GFF3 og BED. Det er et TAB-avgrenset tekstbasert format med følgende felt:

1. chr, obligatorisk
2. start (0-basert), obligatorisk
3. slutt, obligatorisk
4. streng
5. ID
6. type (se nedenfor)

Som BED, bare de tre første kolonnene kreves, resten er valgfritt. Hva som er annerledes starter med "type" -feltet som i GFF. Denne typen definerer kolonnene som følger den når den er tilstede. For eksempel, hvis type == koding, kan vi ha cdsStart, cdsEnd, blockCount, blockSizes og blockStarts som BED; Hvis type == exon, kan kolonne 7 være en "fase", som indikerer fasen til den første basen. På denne måten gjør "type" dette formatet svært utvidbart, mens det fortsatt er relativt enkelt å analysere i forhold til å bruke valgfrie koder hele veien. I tillegg kan det hende at vi har semikolonseparerte "nøkkel" = "verdi" -par på slutten av hver linje som i GFF3. Eksempel:

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

Ovennevnte gir bare et bare bein av formatet. Det er subtile spørsmål som: 1) identiteten / omfanget av ID; 2) om du skal ha foreldre-ID som et fast felt eller et typespesifikt felt; 3) hvor du skal vise visningsnavn; 4) sorteringsrekkefølge. Disse er også viktige i praksis.

PS: Jeg liker SQL mye og synes det burde bli vant oftere i bioinformatikk, men jeg tror ikke det erstatter tekstformater helt. Formater er nyttige for serialisering og dataoverføring. De krever mindre dyktighet å jobbe med og mindre programvare / maskinvare ressurs å distribuere. Omhyggelig konstruerte binære representasjoner av formater kan være mye mer effektive i mange brukssaker.

Bare å kaste dette der ute, som alle de beste tingene allerede er blitt sagt, men hvorfor trenger man å spesifisere en streng spesifikasjon for et bioinformatisk dataformat? Som du sier, det som vanligvis skjer er at all handling havner i de valgfrie feltene.

Det er mye å si for de libertariske verdiene ved å bare la folk finne ut av det alene. Ta valgfrie felt i BAM-tagspesifikasjonen. for eksempel. Her kan du ha dine egne koder, men de må starte med et "X", et "Y" eller et "Z" og følges av "[A-Za-z0-9]". Hvorfor? Hvorfor kan ikke folk bruke sine egne taggenavn som "lese er unik" eller "redigere avstand til genom" eller hva de vil. Skal vi ikke stole på kraften til å navngi ting og huske ting vilkårlig? Resultatet er at man må slå opp kodenavnets faktiske betydning i publiseringen av verktøyet som produserte det, eller spørre på visse fora osv. Og dette forutsetter at man kjenner verktøyet som produserte lesningene - hvis ikke, hvem vet wtf ' XT 'står for.

I hovedsak stoler allerede nedstrøms lesere av valgfrie felt på at' XT 'er hva den mener det er. Så hvis vi gjerne bruker valgfrie felt i en hvilken som helst kapasitet, hvorfor stoppe ved felt?

Utvid denne logikken til kolonnene i dataformatet. La brukerne bestemme kolonnenavn. Du kan en gang i en blåmåne komme over en fil med kromosomkolonnen som "chr" i stedet for "kromosom", men mesteparten av tiden vil du lete etter "lese er kvante-radioaktiv", og oppdage og fikse navngivning- feil vil ikke være så mye av et problem som å bruke et dataformat som ikke lagrer det du vil lagre. Eller verre, det kan lagre det, men på en veldig ulogisk måte som resulterer i at alle som bruker dataformatet må stille minst 3 spørsmål her eller på andre fora før de forstår hva som egentlig skjer.

Så du ender opp med en generell løsning på problemet med å lagre tabellinformasjon på en kompatibel måte på tvers av mange forskjellige typer programvare, også kjent som SQL (eller en hvilken som helst annen generell database som REDIS, Neo4J, Numpy , etc). Faktisk, spiller det noen rolle hva datalageret er, så lenge det er tabellformet og har "kromosom" og "posisjons" verdiene for hvert element?

TL; DR - Vi vil ikke tenke på morgendagens beste dataformat i dag, fordi arten av morgendagens data ennå ikke er kjent. Mindre politiarbeid på dette området vil mest sannsynlig resultere i mer robust programvare, hvor ingenting blir tatt for gitt og ingen antakelser om dataene kan gjøres før skjemaet er analysert.

I sannhet, den eneste grunnen til at vi tror vi trenger å spesifisere dataformatene våre er fordi vi vet at hvis vi ikke gjorde det, vil andre mennesker gjøre noe vi ikke tenkte på - og vi, tror jeg falskt, antar at det vil være dårlig.