From: pgil@HISTONE.LANL.GOV (Paul Gilna)
Newsgroups: bionet.molbio.genbank
Subject: (long) Re: More fundamental Problems With Genbank
Date: 14 Apr 92 14:20:38 GMT
Distribution: bionet


Tom and Keith

I passed the specific occurrance to our annotation staff, if it is an
error, it will be corrected--misc_feature is (in spirit) intended to be
very sparingly used when no other feature covers the entity being
described.

/note has a tattered history, and as has been mentioned before, was
used to "park" features that could not readily be parsed, either in
conversion from Genbank flatfile to RDBMS or translation from other
flatfile formats. Here we figured that if we treated them in this
manner, we had a better chance of going back and fixing them in a
systematic manner, and at the very least, did not loose the data in
conversion.

We do not defend the somewhat ugly consequences of this step and are
trying where we can to correct the situation.  In a number of cases, we
have been doing just that, however we face the same problems Tom and
everyone else does, /notes are not easily parsed (they were never meant
to be). We will plug away resiting /note information to its proper
home.

However I think there are broader issues at stake than just naming
everything or fixing Authorin so it checks everything it can.

Sooner or later, if the databases have to even "look" at the data in
order to get them out to the community, we are going to get ourselves
in trouble. Today, we spend a portion of our time reviewing and
correcting submissions to get them out to distribution, a portion of
time effecting error corrections and updates passed to us by authors of
their data, and a portion of time correcting, what we call "global"
errors in the database--correcting the results (manually or
computationally) of database-wide integrity checks.

It is our view that the role of the database staff must move
increasingly towards the latter task, without negatively effecting the
other two. In the past, we attacked the latter issues to the detriment
of the former, this time we intend to do the right thing.

The first phase is well in hand--automation of data submissions.

The second phase will be crucial. Today, if we spot an error in a
submission, an incorrect usage of authorin, a misspelt item, we correct
it ourselves. If we run checking software on the data, we impart needed
fixes ourselves, communicating with the author only if we hit real
trouble. Finally, we send the data back for review to the author as we
release the data. Again, if corrections come about from this iteration,
we impart them ourselves.

We are taking a number of approaches to improve the execution of this task.

First, we must automate as much as possible not only detection, but
correction of errors. Authorin is a great tool and is singly
responsible for automating much of step 1, and without it we would
still be spending all of our time just processing submissions. However
as long as it is designed to operate as a remote stand-alone tool, it
cannot expect to keep pace with the ever-increasing scope of integrity
checks that one would like to see applied to the data.

On the other hand the author can benefit directly if the results of
those checks are passed back directly to him or her at the point of
processing.

Take the following scenario (already in the development stages):
Instead of, as we do today, our running a vector contamination check,
evaluating the results, and flagging the entry, simply port that
functionality to the submitting author; for example when authorin
transactions are run in, the vector check, along with many others are
run that night, and the results are mailed directly to the author, with
enough information to allow his or her evaluation of our software's
findings.

Second, we believe that ultimately, we will have to provide that same
author with the capability of effecting the correction to their data
themselves, in other words we must move to transfer the capability (and
responsibility) for data maintenance to the author. Today, the update
address plays that role, and we are seeing a strong increase in the
number of "data maintenance" messages coming in: but that's not enough.

With the workload we have today, and thanks to Authorin, we have time
to address inconsistencies within the database--the time spent on
submissions is mostly that of reviewing the data, not entering them;
though not perfect yet, CDS's database-wide are translating
considerably better than before; Keywords and Duplicate sequences are
next on the list. The fact is we are making significant and steady
progress (perhaps not at the rate that Tom would desire) and that the
challenge before us now is to ensure that we can keep and increase that
rate. To do that we must change our approach to data management.

I think Keith is correct, no matter ho hard we have tried, we have not
had consistent annotation conventions over the ten-or-so year life of
the project--thing is, I doubt anyone would be happy if we were
annotating to the same conventions we had ten years ago! At least the
paths we are taking are targeted towards determining consistency of
annotation across the database, including retroactively, while allowing
for changes in convention dictated by changes in biology.

If we can accomplish this (and it is by no means a trivial task), then
(and only then) can we focus on the database itself; fixating on todays
errors is not enough, we must also bring yesterday's data into a
consistent line.

Understand this; our primary mission is in the processing of
submissions in as accurate and as timely manner as we can--we do
everything in our power to provide a consistent, professional and
efficient service to the community. Our goals are to sustain that
consistency AND move to increase the quality of the database.


Regards to all


--paul


Paul Gilna
GenBank, Los Alamos