Newsgroups: bionet.molbio.genbank
Subject: Re: GenBank error?! (brain damage?)
From: robison1@husc10.harvard.edu (Keith Robison)
Date: 13 Aug 92 03:31:25 GMT
Distribution: bionet

michael@TEMIN.LANL.GOV (Michael J. Cinkosky) writes:

>> Well, I wrote a program to fish out coding exons from GenBank by looking
>> at the 'CDS join...' entry in the feature table and came out with this 
>> interesting entry which appears to contain a 3 bp internal exon 
>> (and an intron of length zero!)...  
>> 
>>
>> What is the point of 'joining' the sig_pep separately?  I would have liked 
>> to think that the purpose of 'join' was to link segments which are 
>> non-contiguous... 
>> 
>> Are signal peptides always treated this way or is this just an odd ball case?
>> ...
>> Eric E. Snyder                            



>Eric,

>Like any complex language, there are many ways of making any
>one statement in the GenBank/EMBL/DDBJ feature table format.
>This assumption that you made that a join() would only be
>used to join non-contiguous segments together (most notably,
>exons), is not a requirement of either the syntax of the language
>or of its preferred usage.  (Essentially, there is no statement
>about this in our standard usage guides here.)

>Further, while one might certainly propose a guideline such as
>this for future annotation, I am not sure that it would be a good
>idea.  It is often the case that annotators (including those who
>submit their data to us directly through Authorin) find it very
>convenient to create larger features (such as the CDS in the entry
>you mentioned) out of smaller pieces (such as the sig_peptide
>and mat_peptide).  This saves considerable effort, both in
>original annotation as well as in maintenance (e.g., if we
>later detect that the sig_peptide is incorrect, whatever changes
>we make will be automatically reflected in the CDS). 

>So, while it does mean that one needs to check to make sure that
>the next piece of a join() is non-contiguous with the current piece,
>I would argue that this is a small price to pay for the ability to
>build larger features from smaller ones.

>Michael Cinkosky
>GenBank / Los Alamos

	I would like to respectfully disagree with Dr. Cinkosky on this
point.  Any data storage/presentation design should attempt to 
maximize information density while minimizing ambiguity. 
Furthermore, a guiding principle of biological databases should be that
data is represented in a manner which maps tightly onto the
underlying biology.  Therefore, each element in a join statement
for a nucleotide sequence should consist of one unit which the cell joins 
at the DNA or RNA level (even better would be to distinguish DNA joins
from RNA joins!).  The recognition of the signal-mature peptide 
junction does not occur until the protein level, and so it should
be annotated at that level.  In fact, the failure to represent the
inherent DNA-->RNA-->protein hierarchy is one of the major flaws
in the GenBank feature table language.   
	In the end ambiguities such as the one cited serve only
to confuse.  Allowing multiple representations of the same
concept impairs the ability to search for and use concepts in the
database.  Rather, a single internal representation should be enforced,
with multiple external representations.  This would also
eliminate the confusion about how to represent certain concepts,
which has led to numerous errors.  For example, it is not infrequent
to find an entry encoding a single protein with three CDS keys --
one for the unprocessed protein, one for the transit/signal peptide,
and one for the mature protein.  If these subfeatures were
represented as segments of the original mRNA/CDS, rather than
as features with equal standing, then it would be far more
obvious that this is a mistake.


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

robison@ribo.harvard.edu 



Newsgroups: bionet.molbio.genbank