 |
 |
Can I ask a dumb question? Just curious... Why are we now limited to 80 "columns"? In the old days, that was a limit with Fortran and punched cards. Can a "record" (whatever it's called now) be as long as we wish? Instead of compressing a lot on a PDB record line, can we lengthen it to 130 columns? Bernie Santarsiero On Fri, August 10, 2007 10:10 am, Warren DeLano wrote: > Correction: Scratch what I wrote -- the PDB format does now support a > formal charge field in columns 79-80 (1+,2+,1- etc.). Hooray! > > Thus, adoption of the CONECT valency convention is all it would take for > us to be able to convey chemically-defined structures using the PDB > format. > > I'll happily add two-letter chain IDS and hybrid36 to PyMOL but would > really, really like to see valences included as well -- widespread > adoption of that simple convention would represent a major practical > advance for interoperability in structure-based drug discovery. > > Cheers, > Warren > > >> -----Original Message----- >> From: CCP4 bulletin board [mailto:[log in to unmask]] On >> Behalf Of Warren DeLano >> Sent: Thursday, August 09, 2007 5:53 PM >> To: [log in to unmask] >> Subject: Re: [ccp4bb] PDB format survey? >> >> Joe, >> >> I feel that atom serial numbers are particularly important, >> since they, combined with CONECT records, provide the only >> semi-standard convention I know of for reliably encoding bond >> valences information into a PDB file. >> >> single bond = bond listed once >> double bond = bond listed twice >> triple bond = bond listed thrice >> aromatic bond = bond listed four times. >> >> This is a convention long supported by tools like MacroModel >> and PyMOL. >> For example, here is formaldehyde, where the bond between >> atoms 1 and 3 is listed twice: >> >> HETATM 1 C01 C=O 1 0.000 -0.020 0.000 0.00 0.00 >> C >> HETATM 2 N01 C=O 1 1.268 -0.765 0.000 0.00 0.00 >> N >> HETATM 3 O02 C=O 1 0.000 1.188 0.000 0.00 0.00 >> O >> HETATM 4 H01 C=O 1 1.260 -1.775 0.000 0.00 0.00 >> H >> HETATM 5 H02 C=O 1 2.146 -0.266 0.000 0.00 0.00 >> H >> HETATM 6 H03 C=O 1 -0.946 -0.562 0.000 0.00 0.00 >> H >> CONECT 1 2 >> CONECT 1 3 >> CONECT 1 3 >> CONECT 1 6 >> CONECT 2 1 4 5 >> CONECT 3 1 >> CONECT 3 1 >> CONECT 4 2 >> CONECT 5 2 >> CONECT 6 1 >> >> I second the proposal of treating this field as a unique >> string rather than a numeric quantity. >> >> Two letter chain IDs would be fine with me, but I do think we >> could also make better use of SEGI and/or MODEL to break >> things up while still preserving the utility of certain other >> records (SHEET, HELIX, etc.) within their existing column definitions. >> >> However, we are still lacking a standard way of designating >> formal charges, So maybe that free column could be better >> used for encoding a formal charge, such as ["q" "t", "d", >> "-", "+", "D", "T", "Q"] over the formal charge range of >> [-4,-3,-2,-1,0,1,2,3,4] -- just an idea :)... >> >> With valences plus formal charges along with expansion of the >> cap on atom counts, I think we could support >> chemically-complete PDB files and push back the date of PDB >> demise for a few more years! >> >> A Wiki dedicated to practical PDB file hacks and extensions >> is a superb idea -- of course, the goal should be to >> ultimately come up with a single well-defined standard set of >> hacks we all agree upon by supporting them in our code. >> >> Cheers, >> Warren >> >> -----Original Message----- >> From: CCP4 bulletin board [mailto:[log in to unmask]] On >> Behalf Of Joe Krahn >> Sent: Thursday, August 09, 2007 1:15 PM >> To: [log in to unmask] >> Subject: Re: [ccp4bb] PDB format survey? >> >> Edward A. Berry wrote: >> > Ethan A Merritt wrote: >> >> On Wednesday 08 August 2007 20:47, Ralf W. Grosse-Kunstleve wrote: >> >>> Implementations to generate intuitive, maximally backward >> compatible >> >>> numbers can be found here: >> >>> >> >>> http://cci.lbl.gov/hybrid_36/ >> >> >> >> From that URL: >> >> >> >> ATOM 99998 SD MET L9999 48.231 -64.383 -9.257 1.00 >> >> 11.54 S >> >> ATOM 99999 CE MET L9999 49.398 -63.242 -10.211 1.00 >> >> 14.60 C >> >> ATOM A0000 N VAL LA000 52.228 -67.689 -12.196 1.00 >> >> 8.76 N >> >> ATOM A0001 CA VAL LA000 53.657 -67.774 -12.458 1.00 >> >> 3.40 C >> >> >> >> Could you please clarify this example? >> >> Is that "A0000" a hexidecimal number, or is it a decimal >> number that >> >> just happens to have an "A" in front of it? >> >> [A-Z][0-9999] gives a larger range of values than 5 bytes of >> hexadecimal, >> >> so I'm guessing it's the former. But the example is not clear. >> >> >> > I'm guessing the former also. A 5-digit hex number would not be >> > backwards compatible. With this system legacy programs can >> still read >> > the files with 99999 atoms or less, and anything more than >> that they >> > couldn't have handled anyway. Very nice! >> > >> > Ed >> I still prefer the idea of just truncating serial numbers, >> and using an alternative to CONECT for large structures. >> Almost nobody uses atomSerial, but it still may be parsed as >> an integer, where the above idea could cause errors. >> Furthermore, non-digit encoding still results in another >> maximum, whereas truncating the numbers has no limit. The >> truncated serial number is ambiguous only if taken out of >> context of the >> >> complete PDB file, but PDB files are by design sequential. >> >> Another alternative is to define an "atom-serial offset" >> record. It can define a number which is added to all >> subsequently parsed atom serial numbers. Every ATOM/HETATM >> record is then perfectly valid to an older program, but may >> only be able to handle one chunk of atoms at once. >> >> Likewise, I like the idea of a ChainID map record, which maps >> single-letter chainID's to larger named ID's. Each existing >> PDB record can then be used unchanged, but files can then >> support very long ChainID >> >> strings. The only disadvantage is that old PDB readers will >> get confused, but at least the individual record formats are >> not changed in a way that makes them crash. >> >> I think that keeping the old record definitions completely >> unchanged are >> >> an important feature to any PDB format revisions. Even if we >> continue to >> >> use it for another 20 years, it's primary advantage is that >> it is a well-established "legacy" format. If we change >> existing records, we break that one useful feature. >> Therefore, I think that any changes to existing records >> should be limited to using characters positions that are >> currently. (The one exception is that we need to make the HEADER Y2K >> >> compatible by using a 4-digit year, which means the existing >> decade+year >> >> characters have to be moved.) >> >> Of course, the more important issue is that the final >> decision needs community involvement, and not just a decision >> by a small group of RCSB or wwPDB administrators. >> >> Maybe it would be useful to set up a PDB format "Wiki" where >> alternatives can be defined, along with advantages and >> disadvantages. If >> >> there was sufficient agreement, it could be used as a >> community tool to put together a draft revision of the next >> PDB format. With any luck, some RCSB or wwPDB people would >> participate as well. >> >> Joe Krahn >> >> >> >> >