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