I was present at the creation of what is called the "PDB"
format in the mid-1970's and HOH was always HETATM. The only
thing special about HOH was that we felt that it was not
necessary to include a HET record in (virtually) every entry
to define HOH.
We felt that it would be useful to be able to compute
the total number of each type of atom in an entry and this
can be done by summing the residues listed on SEQRES, subtracting
the appropriate number of waters, and then adding in the formulae
for the HETATMs.
[For those of you interested in ancient history there
actually was a format before the "PDB" format that was used
for the first 100 or so entries. It was based on the output
format of Bob Diamond's real space refinement program.]
Frances Bernstein
=====================================================
**** Bernstein + Sons
* * Information Systems Consultants
**** 5 Brewster Lane, Bellport, NY 11713-2803
* * ***
**** * Frances C. Bernstein
* *** [EMAIL PROTECTED]
*** *
* *** 1-631-286-1339 FAX: 1-631-286-1999
=====================================================
On Wed, 1 Aug 2007, Eric Pettersen wrote:
> Well, you're right that originally water was in the list of standard
> residues that supposedly would use ATOM records. But water has been
> in HETATM records for many years now, and for that same amount of
> time ATOM records have been used exclusively for standard polymer
> residues and HETATM for everything else (including MSE). So my point
> is that this particular complaint isn't a v2.3 vs. v3 issue per se.
> It wasn't really directed at the main thrust of your post, the
> opportunity for feedback.
>
> --Eric
>
> On Aug 1, 2007, at 1:50 PM, Joe Krahn wrote:
>
> > Eric Pettersen wrote:
> >> On Jul 21, 2007, at 11:12 AM, Joe Krahn wrote:
> >>
> >>> Another problem is that the original meaning of HET groups
> >>> continues to
> >>> be corrupted. ATOM records are for commonly occurring residues
> >>> from a
> >>> list of standard residues.
> >>
> >> No, they're for commonly occurring _polymer_ residues. Two
> >> consecutive
> >> residues contained in ATOM records are implied to connected to each
> >> other barring an intervening TER card. I imagine this is the
> >> principal
> >> reason that water residues use HETATM records.
> >>
> >> --Eric
> >>
> >
> > The idea that ATOM is only for _polymer_ residues was not part of the
> > original format, and is specifically one of the changes that I am
> > asserting as wrong. The original PDB format stated that ATOM is for
> > "standard residues" which are defined by a list of residue names given
> > in the PDB format documentation, and the "list of standard residues"
> > included water. Non-standard residues must define themselves with
> > extra
> > HET records. With RCSB's database, HETs must be completely defined as
> > well, which makes it easy for them to forget that the whole idea of
> > HETATM is to allow unknown residue types to be displayed.
> >
> > RCSB has added the concept of HET's being non-polymers, but also keeps
> > this concept mixed up by not including Se-Met (MSE) which is certainly
> > enough not to be a HET group. So, the idea that ATOM implies some
> > polymerization linkage is dysfunctional. What the PDB format should
> > include is an INIT record that is the counterpart of the TER record.
> >
> > The bigger point of my post, however, was that the interests of the
> > non-database user community are, in my opinion, being ignored,
> > particularly with the PDB format. Structural biology is so diverse
> > that
> > it really needs input from the whole community to do the right thing.
> >
> > The problem is that when the PDB 3.0 format was announced 3 months
> > ago,
> > it was done with the intent of intentionally not allowing time to
> > consider problems and alternatives posed by the user community.
> >
> > Joe Krahn
> >
> > TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION OPTIONS, please see
> > https://lists.sdsc.edu/mailman/listinfo.cgi/pdb-l .
>
>
> TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION OPTIONS, please see
> https://lists.sdsc.edu/mailman/listinfo.cgi/pdb-l .
>
