Newsgroups: bionet.molbio.genbank
Subject: Re: More Fundamental Problems With GenBank
From: robison1@husc10.harvard.edu (Keith Robison)
Date: 13 Apr 92 13:28:55 GMT

toms@fcs260c2.ncifcrf.gov (Tom Schneider) writes:

>Here is a problem I just came across.  Two entries contain binding sites for
>Gal4, K02115 has

>     misc_binding    368..384
>                     /note="binding site for GAL4 (positive control  protein)

>M81879 has

>     misc_feature    217..233
>                     /note="GAL4 site"

>This means that no program can treat these the same way.  Are there no rules on
>how to enter things in GenBank?  Why don't these things have NAMES?   You can't
>parse notes.  (That is, no program can be smart enough to read these notes and
>automatically extract the sites.)  If this kind of problem continues to be
>ignored, there will be a terrible price to pay later on!

>I think that the problem is that notes are being used too freely.  Authorin
>(and all other entry programs) should be altered so that using a note is a
>royal pain in the fingers.  The programs should put out a message that explains
>that notes are essentially useless appendages to the data, and that a specific
>datatype associated with the information is needed.  The programs should also
>FORCE the user to give a name to the feature!

I'm not so sure either one of these is a good idea.  First, it is better
(IMHO) to have unparsable information in the databanks than no 
information at all.  If you make it hard for people to enter
information, many will just not bother to.  Second, names are
only useful if they are unique.  Instead of trying to name 
everything, just give them a unique "handle" based on the
locus' acession number.


>Isn't it absolutely clear that there is a big problem here?
		
>  Tom Schneider
>  National Cancer Institute
>  Laboratory of Mathematical Biology
>  Frederick, Maryland  21702-1201
>  toms@ncifcrf.gov


Actually, there's two problems.  First, we have the parsing problem -- finding
all GAL4 sites in GenBank cannot be done in a straightforward manner.
Second, the one site is not labelled with the most specific qualifer
(it has misc_feature instead of misc_binding).

I believe that the only solution to these problems is to have
electronic curators -- programs which constantly search for
problems in the databases.  

Really, this problem can be divided into several components:

1)  Information not being entered correctly the first time.

	This includes all errors initially entered, including typos,
errors in delineation of features, errors in assigning sequences to
GenBank divisions.
Most errors of this type CAN be caught automatically.  Spell-checking
all entries (using a standard dictionary augmented with biological
terms) will eliminate typos and make keyword searching reliable (currently
only the ORGANISM field has any sort of restricted vocabulary).  Most feature
span delineations can be checked -- CDS's can be checked to see if they
translate, functional sites can checked against their consensus, etc.
Note that I am NOT suggesting that sites be _assigned_ automatically, just
that they be _verified_ automatically.  I know from experience that the
majority of non-consensus mRNA splice sites represent discrepancies 
between GenBank and the literature, but some are really non-consensus sites.

		    

2)  Information just not being entered
	
	In a sense, this is a subset of #1, but these are cases where
important information is missing.  One obvious example is vector
sequence contamination -- very little is marked, yet this could be
done in a virtually completely automatic fashion.  A significant percentage
of new CDS's are missing /codon_start qualifiers, and /codon
qualifiers for exceptional codons are virtually unfindable.  Another
frequent problem is the failure to mark nuclear-encoded organelle proteins
as such -- they often end up in division ORG.  Since complete sequences for
representatives of the major organelles are known, it would be simple
to BLAST every sequence for organelle proteins against these complete
sequences -- if no hits are encountered, it is probably from the nucleus
(transit peptides are another warning flag; so are polyA signals on 
chloroplast mRNAs).


So, every new entry would be run against an ever-expanding array of 
checks to ensure that the information is accurate and complete.  
Many of these could be put into AUTHORIN, and many others done upon 
receipt of an entry by the database staff.  Most of these suggestions
are dreadfully easy to do using the flatfile and UNIX, so if you can easily
interchange data between flatfile and relational forms, there's little
start-up cost encountered.  However, as I said above this would be
an ever-expanding array of checks, so one last level is critical...


3) Information not being upgraded

	A serious flaw with the current databases is that the information
already there is rarely checked.  There's no consistent level of annotation
quality (completeness, accuracy, parsability) -- entries for 1984 are
at an entirely different level than entries from 1992.  The only way to
tackle this is to have programs constantly analyzing the databanks, looking
for under-specified features (such as the misc_feature -- misc_binding above),
incorrectly specified features, unmarked features, etc.  These programs
should also be keeping close tabs on those /note qualifiers Tom hates --
if a particular word appears frequently in them for a particular class of
qualifier, than it may well be time to create a new qualifier.  And, such
programs could constantly be on the lookout for possible 
merges and duplications, and report them to the human curators for 
further action.


	If such measures are not implemented soon, the resultant mess will
be staggering.  Not only is sequence acquisition growing phenomenally, but
the expectations of the database-user community are increasing as well.
When people were just FASTAing their new sequence to see what it looked
like, the reliance on annotation quality was low.  But now, people want to
be able to ask questions such as "what is the information content of binding
sites for X", or "how many exon types are there" or "what is the rRNA tree
for all eukaryotes" or "how do I build a bacterium", and it's appalling that
we can't just pull the information from GenBank and TRUST it.  
Too much time is spent by we end users doing the quality checks 
(and corrections) which should be performed by the keepers of the databases.



Keith Robison
Harvard University
Program in Biochemistry, Molecular, Cellular, and Developmental Biology

robison@ribo.harvard.edu