From: sauruggerpn@PHIBRED.COM (Peter N. Saurugger)
Newsgroups: bionet.molbio.bio-matrix
Subject: Re: Beyond GenBank.
Date: 16 Dec 92 17:07:13 GMT
Distribution: bionet

>
>>Thus there is a wealth of information about DNA sequences that
>>is not getting into GenBank.
>
>YES!  This is why I have the middle name I do.  This huge loss of data is going
>to catch up with us sooner or later (I'd say within 5 years) and people will
>not be able to track down all the data.  It's just about impossible NOW! 
>
Dear Cassandra!

It's good to have you - but don't be worried too much: progress tends to be 
problem-driven, and usually follows a chaotic path. People will actually start to 
realize the importance of all-encompassing information systems once a 
considerable percentage of scientific work is found to be repeat effort - or if 
it can be proven by infopreneurs that experiments and projects by some major labs 
were futile efforts because data analysis would have shown that the question 
asked was rather dumm in light of existing evidence, etc. ...

By the way, the frustration here with accumulations of data which are 
inconsistent and generelly of little use has led to a new term being coined:

WORN databases (Write once - read never) ...

>The reason that GenBank was formed was to prevent people all over the world
>from duplicating their efforts at getting sequences in the computer.  Now we
>have EXACTLY THE ANALOGOUS SITUATION with the so-called features.
>
Features *are* much more complicated because they need an agreed upon definition, 
which is not as simple as the sequence notations - and the volume is much larger.

In general, a rather flexible approach would have to be taken, which allows the 
expansion of definitions od features without invalidating data which are already 
in the databank.

>But NCBI refuses to acknowledge and deal STRONGLY with this growing disaster,
>and until more people recognize the problem (as you did, congratulations!) it
>will only become worse.  ("Strong" means to have a policy in effect which
>will lead to the assured capture of all experimentally supported data
>on sequence features.  Guesses should not be in the database.)
>
Here I don't agree with you: guesses (AND the procedures which led to them *need* 
to be in the database, too). Of course, it needs to be clear HOW a particular 
data item was arrived at. And while I may have a higher BELIEVE in experimentally 
elucidated data then in those obtained through "guesses" or computational 
procedures, experimental data surely do not have a believe (~~probability) of 
1.0!!

Of course, you know this anyway - sequence errors for example ...


>Here I disagree.  The information should be integrated directly into
>the same database.  There is no reason for a separation, and doing
>so would cause delays, taking up researcher's time.
>
>Also, your proposal will fail.  The trouble is that cross reference indexes are
>all wrecked or poor.
>
Agree fully with Cassandra.

>LOCUS name changes at the whim of the moment, and is no longer meaningful
>for any long term storage.  It really should be eliminated.
>
We may need it for back-referencing - some people may still use the old name. Of 
course, the system would have to inform the user about the ambiguities.

>ACCESSION number keeps being updated and altered.  At least the old one is
>there, but there are not ABSOLUTE names in sequences to which one can refer.
>So the locations of mutations are FORCED by this (excuse me) stupid system to
>be numbers.  That means that when the sequence numbering changes (eg, merge of
>sequences - which HAS to be done!!! or error correction) the pointers in the
>secondary database will be blown away.  There is no assured mechanism to give
>coordinates RELATIVE to standard marks in the sequence.  (The folks who
>followed last years row on this subject will see that the ideas never change.
>The database doesn't improve.  Only the date changes and the time to disaster
>shortens.)
>
Of course there is a way: a pointer right to the e.g. nucleotide in the original 
sequence, instead of an index.


	--	Peter N. Saurugger
		pns@phibred.com