> > 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 >
