*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
On Friday 19 May 2006 03:50 am, Eleanor Dodson wrote:
>
> Working format does NOT have the same requirments as an archival one.
I regret that this discussion has become sidetracked on the issue
of formats. My original s/parrot/PDB format/ quip was a cheap
shot made while trying to point out that the PDB's internal
database is more complete than what you see in a PDB format
file generated from it.
The real issue I would like to see a resolution for is
that there is currently no standard interpretation of the
"temperature factor" field, whether it is extracted from a PDB
format file or from an mmCIF file.
Virtually all existing programs assume that this field contains
a crystallographically-refined isotropic B factor, one that
constitutes the entire crystallographic model for displacement
of this atom. This is not true for
(1) models refined anisotropically - in this case it contains
Beq, which is a well-defined quantity but is not identical
to a refined Biso value
(2) structures refined with TLS, in which case it is anyone's
guess what got stuffed in this field
(3) a non-zero fraction of the PDB for which people used this
field to store somethine else entirely.
> The problem with TLS is that it is not used by many programs.
> A partial solution is to run TLSANL before deposition - this means
> that the output Biso and ANISOB records are consistent with the PDB
> definitions
The problem remains - how should one note this fact in the deposited
PDB file? The few programs that *are* TLS-aware need somehow to
detect whether the "TempFactor" field already contains the TLS
contribution, or whether it is a separate incremental term to be
applied on top of the TLS contribution.
The goals I propose that we should work toward are
- The appropriate body (RCSB? IUCr?) should define a new PDB
record that states the meaning of the values stored in the
TempFactor field of the current file
- ADIT and other deposition tools should require that this
record is provided in the case of TLS or anything other
than good-old-Biso-only refinement
- It should be a policy that structures refined with TLS
should *always* contain the refined TLS parameters,
whether or not they have been applied to the TempFactor
field entries. This is the true refined model, so the
archival file should record it.
- All the various programs should gradually be made TLS-aware.
We'll never get there 100%, but it would at the least be
nice not to have SFCHECK or the EDS server raising red
flags about B distributions due to misunderstanding the
meaning of the quantities being validated
Ethan
> Eleanor
>
> Clemens Vonrhein wrote:
> >*** For details on how to be removed from this list visit the ***
> >*** CCP4 home page http://www.ccp4.ac.uk ***
> >
> >On Thu, May 18, 2006 at 10:58:52AM -0700, Ethan Merritt 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.
> >
> >Formats exists to make a specific task easy and understandable. To
> > me there is a distinction between a working format and a
> > storage/archival format - since archival of data (consisting of
> > coordinates as well as a lot of meta-information) is a very
> > different task from working with X, Y, Z, OCC, B (and a few other
> > things).
> >
> >I don't think the 'one size fits all' approach works well in this
> >case: PDB might be bad for archival but it is easy as a working
> >format, whereas mmCIF is probably great for databases (I'm no expert
> >there) but I find it difficult to use as a working format.
> >
> >Cheers
> >
> >Clemens
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
