*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
Dear Eleaonor and CCP4ers,
I also thought about publishing coordinates after TLSANL because I
observe quite often that the TLS part is ignored by both users and
programs, although it could make up the main part of the total
individual B-factors. However, depositing a structure, say, at 2.8
Angstrom with individual ANISOU cards would look so strange (at least to
me) that I would really shy away from doing this. The situation would be
somewhat better if one could split the TLS into isotropic components
that could then be added to the individual isotropic Bs upon deposition,
and remaining anisotropic components, such that the total information
would still correctly reflect the refinement protocol. Unfortunately, I
don't look through the mathematics behind this enough ... Maybe, the TLS
experts could comment on this idea?
Best regards,
Dirk.
Eleanor Dodson wrote:
Pleae note - all format police.
Working format does NOT have the same requirments as an archival one.
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
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
--
****************************************
Dirk Kostrewa
Paul Scherrer Institut
Biomolecular Research, OFLC/110
CH-5232 Villigen PSI, Switzerland
Phone: +41-56-310-4722
Fax: +41-56-310-5288
E-mail: [EMAIL PROTECTED]
http://sb.web.psi.ch
****************************************
