*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
<flame> Shouldnt we adopt XML as a new standard to replace both PDB and mmCIF, to have finally a flexible but universal format? </flame> Flip (Pinin' for the Fjords) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ethan Merritt Sent: Thursday, 18 May, 2006 19:59 To: [EMAIL PROTECTED] Cc: Julien Lafrance-Vanasse; [email protected]; [EMAIL PROTECTED] Subject: Re: [ccp4bb]: 2 questions: *** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk *** On Thursday 18 May 2006 10:31 am, [EMAIL PROTECTED] wrote: > > A question for the group: is there any push to get TLS parameters > incorporated into the standard PDB data format? The PDB format is dead, it's passed on! This format is no more! It has ceased to be! It's expired and gone to meet its maker! If you hadn't wired it into the code of many programs it would be pushing up the daisies! No, really. Extensions to the PDB format itself are highly unlikely. It exists as a legacy intermediate to the underlying archival mmCIF-derived database info. The TLS parameters are correctly described there, and are correctly translated into PDB format (yes, in a REMARK record) on demand. > Right now, the data > gets thrown into a comment record where no program really uses it. The fact that very few programs handle TLS is a real problem. But I am afraid there is no simple universal solution. Programs will need to be updated one by one. > Even CCP4 programs don't read that information, and refmac has to be > given the data in a separate file. Garib may speak to that, but my understanding is that the input of TLS information to refmac5 had been/will soon be modified. The biggest problem is that the meaning of the "B" field in a PDB file that has been refined with TLS is not well-defined. In practice, refmac fills it with the incremental Biso to be added to the TLS description. I.e. if you have a pure TLS model (no individual ADP refinement) the Biso values will all be 0. Or rather, they will all be some arbitrary constant that may or may not be 0, since the TLS model itself can incorporate an arbitrary constant. But the PDB format itself does not mandate this, or even hint at how you can indicate that this is the case. All older programs, including SFCHECK, assume that this data field contains the *total* ADP for the atom. So basically SFCHECK cannot handle B factor checks in the presence of TLS models. What we *really* need is a community-driven agreement on what to store in this field. The "correct" thing to do is teach all older programs to understand TLS models. But that will be difficult at best. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA
