>
> Single letter chain IDs cause me a bit of pain in buccaneer.
>
> Kevin
>

In general I think that the 'improvements' in the new PDB format are 
sensible, especially the tidying up of the DNA and RNA names. However 
the new way of naming hydrogen atoms will break many vintage programs 
such as my SHELXPRO when it is converting a PDB file to SHELX .ins
format. This is because I had not yet gotten around to reading the 
element symbol first from the end of the card (like Refmac and other 
modern programs) and only if it is not there trying to extract the 
element symbol from the atom name. As it is, SHELX users should be
warned that if the PDB file contains hydrogen atoms, they will find 
some mercury atoms in the Ile and Thr residues in their .ins file! 

The biggest current problem is how to deal with very large 
strucutures. I thought that this would not affect me until I ran into 
exactly the same problem as Kevin with the single letter chain IDs - 
autotracing noisy maps inevitably results in chain breaks and so many 
more chain IDs are required than for the final structure. However 
there is a simple solution that I would like to propose, since the 
side-effects for vintage programs etc. would be no worse than what 
the new PDB has already done. It seems to me that column 21 of an 
ATOM or HETATM instruction is always blank, and column 22 is the chain 
ID. So if we put a two-character chain ID right justified in columns 
21 and 22, for the vast majority of structures there would be no
change, and it would be relatively easy to change MMDB, Coot etc.
to accomodate the increase in the possible number of chains from 26 to 
(say) 36^2 = 1296 (if digits are allowed too).

The next problem is of course the 5-digit atom serial number in columns 
7 to 11, which limits the total number of atoms in the structure to a 
paltry 99999. Many programs ignore this number, but it is used by the 
CONECT, SSBOND and CISPEP records in the PDB. However column 12 also 
appears to be blank, I think that using it (e.g. with A for atoms 
100000 to 199999, B for atoms 200000 to 299999 etc.) would enable the 
sequence numbers to be recycled and would again require no change for 
the vast majority of PDB files. I personally think that this is a much 
better solution than what the PDB currently does for more than 99999 
atoms (they spread the structure over several PDB files with different 
PDB-IDs!). 

George

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry, 
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-2582


On Thu, 2 Aug 2007, Kevin Cowtan wrote:

> Does it matter what the PDB use? They will export PDB and mmCIF for us to use,
> so what they use internally doesn't matter. (IIUC the EBI uses SQL).
> 
> From my perspective as a developer I am not bothered in the slightest whether
> we use PDB or mmCIF, because I read everything through MMDB which handles
> both. Currently I write out PDB, but I can put in a switch trivially. Any
> other alternative would require a certain amount of coding work in MMDB.
> 
> Single letter chain IDs cause me a bit of pain in buccaneer.
> 
> Kevin
> 
> Joe Krahn wrote:
> > So, I am thinking about putting up a survey somewhere to get a measure
> > of the user-communities interests, because RCSB and wwPDB seem
> > uninterested in doing so. Maybe a group result would be more useful in
> > influencing the standards. I am hoping that the wwPDB can become a
> > better place for format standards instead of RCSB which keeps busy
> > handling new data.
> > 
> > In addition to questions about the PDB standard, it is probably
> > important to consider mmCIF. One thing I don't like about it is that
> > columns can be randomized (i.e. X, Y, and Z can be in any column), but
> > the mmCIF standards people have no interest in defining a more strict
> > standard that would require files to be as human readable as RCSB's
> > mmCIF files.
> > 
> > Does this sound useful, or have most people given up on having any
> > influence on standards? Or, should the structural biology software
> > developers get together and just make our own OpenPDB format?
> > 
> > Joe Krahn
>