HDTenEightyP/NetNews huggingface dataset:
From: CLARK@SALK-SC2.SDSC.EDU
Newsgroups: bionet.molbio.genbank
Subject: Re: Author errors and omissions.
Date: 16 Apr 92 02:54:32 GMT
Article-I.D.: genbank.9204160152.AA05571
Distribution: bionet

Larry Moran writes:

/
/  [diatribe against Keith Robinson deleted]
/
/Keith, can you give me some
/examples of datasets that you would like to prepare over coffee but cannot
/because of limitations in the sequence entries? How would you fix this?
/

I would be delighted if I could get datasets containing ALL the variable gene 
segments for the T-cell receptor alpha, beta, gamma and delta families 
without having to worry about:

1) contamination with members from the other families
2) joining regions (or 20 bp from V at the 5' end of a J sequence)
3) duplicate entries with different accession numbers and locus names
4) digging through the Unannotated section for sequences from 1986 that 
haven't made it to the Primate section yet.
5) checking the sequences to make sure they are the same as the literature 
they purport to represent
6) figuring out the reading frame myself it the sequence starts in the 
middle of the coding region.
7) missing some
8) etc.
9) etc.

Let's face it, Larry, there are major problems with the annotation. Some of 
these could be fixed by the kinds of things that Keith suggests. Just 
because they can't all be fixed is no reason to say we shouldn't fix the 
ones that are possible. Something else that would help would be to come up 
with standardized descriptions of the sequences and use them in a 
consistant manner.

Just so there is no misunderstanding, I am not blaming the current GenBank 
staff for the problems in the database. Despite it's flaws, it is wonderful 
compared to what it was like with a previous contractor. I think the blame 
should go to the NIH who lets the GenBank contract. If they specified that 
the quality of the annotation should be improved on the old loci, then 
something might happen. Perhaps if the muckamucks at the NIH knew how 
people felt about this they might try to do something about it.

Just my two cents worth.


Steve Clark

clark@salk-sc2.sdsc.edu  (Internet)
clark@salk               (Bitnet)
From: toms@fcs260c2.ncifcrf.gov (Tom Schneider)
Newsgroups: bionet.molbio.genbank
Subject: Re: (none)
Date: 17 Apr 92 17:18:24 GMT
Distribution: bionet
Organization: NCI Supercomputer Facility, Frederick, MD

In article <A58E856B48B28440@UK.AC.CAMBRIDGE.PHOENIX> MA11@PHX.CAM.AC.UK writes:

>I am strongly of the opinion
>that such entries should never be merged, each AC should represent an
>"unit" of experimental data. These different sequences of the "same" gene

Your argument is the most cogent one I've heard for keeping the raw data
separate.  It is what NLM calls the backbone database.  They are working also
on merging tools, but it would be a lot better if they joined this conversation
and told us directly what they are up to!  (They have a policy of lying low so
as not to get hit in the face.  When September rolls around they are going to
get an enormous amount of flak if they keep this up!)

>I am not sure what is the "meta-sequence" in Robison's sense - the
>description or the sequence constructed with this description - but I am
>sure that these tools are needed. I would see it as a function of
>specialized curators or genetic database curators to write and maintain
>the descriptions of the virtual sequence. However before they (we)
>can do so they (we) need (a) the syntax for the descriptions, (b) the
>programs to read the descriptions and output the annotated virtual
>sequences and (c) a workbench for writing/maintaining the descriptions.

Such a syntax already exists for GenBank, but the political and policy will
to use it is weak (non existant?).

Also, writing such tools depends on having a precise AND COMPLETE definition of
the database (not just the feature tables).  I have yet to see one, though I've
asked for it... :-(

Let me introduce a delila concept:  that the merged sequence should have
exactly the SAME form as the original database (as far as a user is
concerned).  This allows one to use all the same tools on the merged data as on
the original data.

  Tom Schneider
  National Cancer Institute
  Laboratory of Mathematical Biology
  Frederick, Maryland  21702-1201
  toms@ncifcrf.gov
Xref: sparky bionet.molbio.genbank:277 bionet.info-theory:432
From: goldman@mbcl.rutgers.edu
Newsgroups: bionet.molbio.genbank
Subject: Re: NCBI wants to discontinue VAX/VMS GenBank tapes....
Date: 7 Apr 92 15:51:25 GMT
Article-I.D.: mbcl.1160.29e18cbd

In article <1992Apr6.142028.7080@mcclb0.med.nyu.edu>, smith@mcclb0.med.nyu.edu writes:
> I just got a letter from Dennis Benson, Chief of the Information Resources 
> Branch of NCBI saying that NCBI wants to discontinue the VAX/VMS 6250bpi
> backup tape GenBank distribution, and replace it with a CD-ROM distribution.
> 
> The price will be <$60 for bi-monthly updates for a year of the CD-ROM (sounds
> good!) vs. $700-$1,000 for the tapes for a year (lousy deal).
Yeah, we got the same letter; I had actually heard about this earlier.
> 
> Despite the very attractive price of the CD_ROM version, it is not clear that 
> this will really be usefull to us: not the least of the problems is that 
> VAXes, ours anyway, does not have CD-ROM and even if we did it would not 
> (yet) 
> read ISO 9660.

We currently have a CD-ROM on the VAXen.  I suppose, even if you didn't
& you had one on a unix box & nfs client the VAXen, you could use that?

There is currently an "unsupported" ISO 9600 driver available from DEC for
relatively little money (?a few hundred bucks?).  It will *not* read native
ISO 9660 cleanly; the files all come in as "unknown" I believe.
Consequently, you have to write a  program (or use CONVERT ?) to generate a
file that VMS can understand.  If you're doing this, you have to read it
off CD-ROM onto disk, which is (IMHO) fairly grungy.  There's a program by
Peter Stockwell in NZ (available from the EMBL fileserver) which does a
good  job of reading ISO-9660; indeed, we currently use it to read the EMBL
CD-ROM.  If DEC's  commercial driver (when it comes) doesn't do a better
job of reading ISO-9660 than their current driver, we'll probably use
Peter's program.

I have sent a message to GCG explaining what we want (ISO-9660 --> GCG w/o
an intermediate step on disks).  It seems to me that this is really
necessary, as it is getting a little difficult to make sure that we can
transiently keep three copies of the database on disk: (1 GCG current, 1
copied from CD-ROM/decompressed from tape, 1 new GCG being built).

	That's my 2 c.

			Adrian
-- 
Adrian Goldman                         |  Internet:  Goldman@MBCL.Rutgers.Edu
Molecular Biology Computing Laboratory |  Bitnet:    Goldman@BioVAX
Waksman Insitute,                      |  Phone:     (908) 932-4864
Rutgers University,                    |  Fax:       (908) 932-5735
Piscataway, NJ 08855 USA               |
From: kristoff@GENBANK.BIO.NET (Dave Kristofferson)
Newsgroups: bionet.molbio.genbank
Subject: Authorin Growth
Date: 17 Apr 92 00:49:37 GMT
Distribution: bionet


There has been a lot of discussion on the GenBank newsgroup about
automating data entry and lots of other "good stuff" that could be
done, but it might be useful to get a simple grasp of the magnitude of
just one task.  Authorin was conceived and developed to help
accomplish the automation of data entry.  LANL, EMBL, and DDBJ now all
acknowledge its usefulness despite the fact that many improvements
have been discussed in this forum.  Its availability has freed up
resources at LANL to allow them to go back and begin to address some
of the quality issues raised here.

During the last quarter alone, Yuki Abe's group here at GenBank/IG and
the IntelliGenetics production department processed and shipped about
4000 copies of Authorin to scientists all around the world.  Averaged
over the entire quarter, this works out to be over 7 copies an hour, 8
hours a day, 5 days a week, for 14 weeks!!  The actual work was
accomplished in much **less** time while they were also answering all
of your phone calls, e-mail, and processing GOS account applications,
renewals, tape, CDROM, floppy orders, and billings.

The overall database effort is composed of many such unsung tasks that
researchers might not stop to consider.  These necessities should not
be lost sight of before one asks why everything was not finished and
corrected in GenBank yesterday.  Frankly, I think the community at
large owes these usually unrecognized workers a **tremendous** debt of
thanks.  The principal people involved were Yuki Abe, Mary Jo
Faulkner, Marianne Rocha in the GenBank office and Mark Good, Greg
Young, and Wade Hogue in Production and Shipping.  My thanks to them
and to others at IG who have also lent a hand when needed.

The developers of Authorin at IG have included at various times over
the last five years David Benton, Julie Lawrence, John Rice, Steve
Barnhouse, Tan Nguyen, Conrad Lynch, Sherry Tomboulian, and Will
Nelson.  QA has been performed by Tanya Zimmerli, Rhonda Hoffman, Lisa
Schaechter, Nancy Bigham, Janet Lynch, and others.  Kate Hutchison has
handled documentation and manuals assisted at times by Karen Shostak,
John Moore, and Cynthia Garb.  Some of this work occurred some time
back while I was still associated with BIONET, so my apologies if I
have overlooked any names.  Kudos to all of you.

				Sincerely,

				David Kristofferson, Ph.D.
				GenBank Manager

				kristoff@genbank.bio.net
From: toms@fcs260c2.ncifcrf.gov (Tom Schneider)
Newsgroups: bionet.molbio.genbank
Subject: More Fundamental Problems With GenBank
Date: 10 Apr 92 18:52:45 GMT
Organization: NCI Supercomputer Facility, Frederick, MD

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!

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
Newsgroups: bionet.molbio.genbank
From: broe@aardvark.ucs.uoknor.edu (Bruce Roe)
Subject: Re: on vector checking
News-Software: VAX/VMS VNEWS 1.41    
Organization: University of Oklahoma - University Computing Services
Distribution: bionet
Date: Thu, 16 Apr 1992 21:56:00 GMT

In article <9204161719.AA03338@histone.lanl.gov>, pgil@HISTONE.LANL.GOV (Paul Gilna) writes...
>
	[stuff deleted]
> 
>At this point the searchable file contains about 445 sequences from
>GenBank, including lambda. Chances are there is some redundancy here
>that could be cured to make the utility even more worthwhile, but we
>would like to try it out, so that we can get a clearer idea of the work
>that might be required to winnow out sibling sequences.
> 
>We would appreciate some feedback on its usefulness and any suggestions
>for improvement will be entertained.
>--paul
>Paul Gilna 
>GenBank, Los Alamos

Paul,
	How's about putting this database of vector sequences
someplace where we could obtain it via ftp and maybe even in
the GCG or other popular format?   VecBase, as Dan J. said in
a subsequent posting is very out of date.  Please don't just
keep this data base for in-house use.  The world NEEDS an up-to
date VecBase which also includes some cosmid sequences.
	Thanks........bruce
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 \  Bruce A. Roe                     Dept. Chemistry and Biochemistry /
 /  BROE@aardvark.ucs.uoknor.edu     University of Oklahoma           \
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From: kristoff@GENBANK.BIO.NET (Dave Kristofferson)
Newsgroups: bionet.molbio.genbank
Subject: Re: Author errors and omissions.
Date: 16 Apr 92 06:03:06 GMT
Article-I.D.: genbank.CMM.0.90.2.703404186.kristoff
Distribution: bionet

> Just so there is no misunderstanding, I am not blaming the current GenBank 
> staff for the problems in the database. Despite it's flaws, it is wonderful 
> compared to what it was like with a previous contractor.  I think the blame 
> should go to the NIH who lets the GenBank contract. If they specified that 
> the quality of the annotation should be improved on the old loci, then 
> something might happen. Perhaps if the muckamucks at the NIH knew how 
> people felt about this they might try to do something about it.

As I am in the lame duck state at this point I have tended to avoid
this debate and leave it to those who will be in a position to
contribute something in the future.  While I appreciate Steve's
message about the current contractors above, I must take issue with
the comments about NIH.  I have not run into anyone at NIH who is
involved with the project, whether at NIGMS or NCBI, that is not
concerned with the issues raised.  While we at times have differences
over the best ways to resolve them, I don't agree that anyone can be
accused of ignorance or indifference.  This is an enormous and often
thankless undertaking.  If it wasn't for the efforts at NIH there
*wouldn't be* a GenBank for people to kick around.

				Sincerely,

				Dave Kristofferson
				GenBank Manager

				kristoff@genbank.bio.net
From: kristoff@GENBANK.BIO.NET (Dave Kristofferson)
Newsgroups: bionet.molbio.genbank
Subject: RE: [Resent-MM Mail] Re: Author errors and omissions.
Date: 16 Apr 92 06:26:30 GMT
Article-I.D.: genbank.CMM.0.90.2.703405590.kristoff
Distribution: bionet

> update it. If the NIH doesn't determine directly or indirectly (through the
> value of the contract) how many people work on the project, I would
> appreciate hearing otherwise. 

Of course it does in part, but so does the contractor who submits the
proposal including staffing in the first place.  NCBI will be doing
the work themselves, so it will be even more directly under their
control.  But they have to get their budget from other sources too,
i.e., Congress.  As usual there are trade-offs in everything.
However, as Paul has mentioned on numerous occasions, staffing can not
possibly be increased sufficiently to keep up with the database
growth.  All of the government regulations in the world will produce
nothing if not enough suitable people can be found to do the work that
*can* be done.


> /Steve, why not be part of the solution? Sign on as a curator, and come
> /help us all.
> /
> /
> /--paul
> /
> 	I have a previous commitment for the next few years. However, if I
> can ever find the time, I would like to put together some FAQ sheets for
> some of the biosci groups.
> 

I might take you up on it, but BIOSCI will no longer be a part of
GenBank so this is not much comfort to Paul.  I should point out
though that BIOSCI did not die with BIONET because NIH recognized its
value 8-).

Dave
From: pgil@HISTONE.LANL.GOV (Paul Gilna)
Newsgroups: bionet.molbio.genbank
Subject: on vector checking
Date: 16 Apr 92 17:19:27 GMT
Distribution: bionet

As has been mentioned in the past, we have software that checks for the
presence of vector contamination in submitted sequences and are working
on methods of automating the detection and facilitating the
author-driven interpretation and data correction.

In addition to all of this, It strikes us that it would be useful if
one could check for the precence of vector sequence *before* submitting
one's data.

One thought we have had which we can implement fairly quickly here is
to set up a specific FASTA/(BLAST?) searchable file on the GOS that
would contain only vector sequence data, allowing the similarity search
servers to act as specific checks for vector sequences. We would
maintain the file and add any new vectors as they came along.

At this point the searchable file contains about 445 sequences from
GenBank, including lambda. Chances are there is some redundancy here
that could be cured to make the utility even more worthwhile, but we
would like to try it out, so that we can get a clearer idea of the work
that might be required to winnow out sibling sequences.

We would appreciate some feedback on its usefulness and any suggestions
for improvement will be entertained.


--paul


Paul Gilna 
GenBank, Los Alamos
From: toms@fcs260c2.ncifcrf.gov (Tom Schneider)
Newsgroups: bionet.molbio.genbank
Subject: Re: Author errors and omissions.
Date: 14 Apr 92 22:56:28 GMT
Distribution: bionet
Organization: NCI Supercomputer Facility, Frederick, MD

In article <robison1.703256561@husc10> robison1@husc10.harvard.edu
(Keith Robison) writes:

>If you can state a rule,
>then you can write a program to test whether any entries break that
>rule.  Most of the rule-breakers will be errors, and those which aren't
>are likely to hold some interesting biology.

Here you have hit the nail on the head!  As we demonstrate more cases of
intersting biology discovered by careful analysis of the GenBank data, more
folks will want to see a clean data set to make even more discoveries.  But, as
a friend of mine pointed out by email, these discoveries are hard to make today
because of the enormous mess one must sort through.  So it's hard to show all
the neat things one could do IF ONLY GENBANK were clean.  But GenBank isn't
clean because people don't know what it would lead to.  My friend pointed out
that it is a catch-22 situation!  Some people don't know how to deal with, and
appear to be rather worried about the huge flood of data, but don't realize
that the answer is in getting all the little annotation details done right.
But once we show a few cases, there should be more interest in having a
database where one can have an idea and test it within minutes rather than
months or years.

  Tom Schneider
  National Cancer Institute
  Laboratory of Mathematical Biology
  Frederick, Maryland  21702-1201
  toms@ncifcrf.gov
From: CZJ@CU.NIH.GOV
Newsgroups: bionet.molbio.genbank
Subject: Re:  Author errors and omissions.
Date: 16 Apr 92 14:17:30 GMT
Distribution: bionet

Steve writes:

> staff for the problems in the database. Despite it's flaws, it is wonderful
> compared to what it was like with a previous contractor. I think the blame
> should go to the NIH who lets the GenBank contract. If they specified that
> the quality of the annotation should be improved on the old loci, then
> something might happen. Perhaps if the muckamucks at the NIH knew how
> people felt about this they might try to do something about it.
>
> Just my two cents worth.
>
>
> Steve Clark
>
> clark@salk-sc2.sdsc.edu  (Internet)
> clark@salk               (Bitnet)
>

Steve's comments imply that somehow the previous contractor
was responsible for all of the early problems in GenBank.

I think this a bit unfair.  While I think the current GenBank contractor
is doing a superb job, I would point out that the award of the new
contract was accompanied by a four-fold increase in funding.  I would
also point out that the subcontractor responsible for data collection and
annotation did not change.

I also have to comment on those "muckmucks" at NIH.  None of this
discussion would be taking place if the database were incomplete and lagging
a year behind the literature.  The fact that the database is current
means that discussions on how to improve the quality of the
database are now meaningful.  This kind of discussion
is exactly what is now going on at advisors meetings and among the
database staff.  The kinds of discussion now ongoing
is in fact very helpful.

Jim Cassatt
From: CLARK@SALK-SC2.SDSC.EDU
Newsgroups: bionet.molbio.genbank
Subject: RE: [Resent-MM Mail]   Re: Author errors and omissions.
Date: 16 Apr 92 06:34:32 GMT
Article-I.D.: genbank.9204160533.AA14068
Distribution: bionet


/> Just so there is no misunderstanding, I am not blaming the current GenBank 
/> staff for the problems in the database. Despite it's flaws, it is wonderful 
/> compared to what it was like with a previous contractor. I think the blame 
/> should go to the NIH who lets the GenBank contract. If they specified that 
/> the quality of the annotation should be improved on the old loci, then 
/> something might happen. Perhaps if the muckamucks at the NIH knew how 
/> people felt about this they might try to do something about it.
/
/I have to admit, Steve, that I take exception to the above. it appears to
/imply that those working in the GenBank contract do little else than
/serve to appease the contractual deities at NIH, by doing only what we
/are told to do.
/
/
/   [rest deleted - you've already read it anyway]
/

Paul,

	Sorry if I worded that poorly so that it could be misunderstood. 
Now that I read your quoted passage a few hours after I originally wrote 
it, I can see that it could be taken the way you did. Look, I know you guys 
are busting your asses over GenBank - the fact is that the project is 
overwhelming. Even if there were a lot more of you, it would still be 
overwhelming. I like Keith's suggestion to automate as much of the 
consistancy checking as possible, but that is a long-term solution since it 
takes a *lot* of manpower and time to implement something like that, and 
especially to check it to make sure it works properly, and to continually 
update it. If the NIH doesn't determine directly or indirectly (through the
value of the contract) how many people work on the project, I would
appreciate hearing otherwise. 

/Steve, why not be part of the solution? Sign on as a curator, and come
/help us all.
/
/
/--paul
/
	I have a previous commitment for the next few years. However, if I
can ever find the time, I would like to put together some FAQ sheets for
some of the biosci groups.


Steve

clark@salk-sc2.sdsc.edu  (Internet)
clark@salk               (Bitnet)
Newsgroups: bionet.molbio.proteins
From: merritt@milton.u.washington.edu (Ethan Merritt)
Subject: Re: protein ribbon diagrams
Followup-To: bionet.molbio.proteins
Organization: University of Washington, Seattle
Date: Fri, 10 Apr 1992 23:28:14 GMT

In article <1992Apr10.152724.28248@fccc.edu> laub@castor.fccc.edu (Paul Laub) writes:
>	I am interested in generating a Jane Richardson-style ribbon
>diagram of cytochrome C including the heme. In the past, with simple
 [...]
>	Does anyone know whether modifications of this (or other programs)
>exist to handle the heme? I use an SGI Personal Iris 4D25TG with Irix 3.3.

	You could try picking up RASTER3D for the Iris via anonymous ftp
from stanzi.bchem.wwashington.edu.   I don't know whether the ribbon variants
it draws are exactly what you want, but it would certainly allow you to
compose a figure which contained both a ribbon and selected residues, 
prosthetic groups, etc.
					Ethan A Merritt
					merritt@u.washington.edu

Newsgroups: bionet.molbio.proteins