Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreCIF.dic-2.4 Discussion List #8

Dear Colleagues,

   As an outside observer of the core discussions, may I suggest that
that you may be considering a false trichotomy:

   1.  Deferring detailed restraint and constraint information until CIF3; or
   2.  Incorporating the restraint and constraint information now; or
   3.  Sidestepping by incorporating the .res information from
SHELX or similar parsable-but-not-yet-CIF-parsed information
from other refinement programs.

Why not do all three?

   Certainly, the features of CIF3, allowing methods will facilitate the
presentation of complex constraints, and, when CIF3 is available, this would
be an area in which to use methods effectively.  However, there is no
reason not to include as much as can be included now under fully parsed
CIF tokens, _and_ to carry the "raw" constraint information in, say, a
"...details" tags immediately.

   We are facing a similar problem in the imgCIF dictionary.  Images come
from the vendors with wonderfully detailed headers containing essential
information.  We have tags to carry much of the same information, but
things evolve and things are missed.  So we have proposed to add a new
tag to our dictionary (in this case _diffrn_data_frame.details, described
as "A description of special aspects of each frame of data.

     This is an appropriate location in which to record
     information from vendor headers as presented in those
     headers, but it should never be used as a substitute
     for providing the fully parsed information within
     the appropriate imgCIF/CBF categories.")

   This is being done in response from a vendor to carry the "raw"
header information in a comment.  Giving it a tag preserves the
information in a form that allows it to be examined both by
users and by software and which encourages the use of existing
tags for the detailed information and encourages the creation of
the necessary new tags to carry what has not been handled yet.

   While this may lead to the same information being presented in
more than one place, that is just what we already do with various
"...details" tags, and having information in multiple places in
a CIF is a lot better than having the information lost.

   Therefore, I suggest that you:

   3a.  Immediately add a "...details" tag to carry detailed
refinement program settings and values in as close to "raw" form
as possible and in particular to carry the .res information
from SHELX; and
   2a.  As time permits that you add and update CIF tags for
constraints and restraints to whatever extent you can achieve
agreement, but without removing information from the "...details"
tag; and
   1a.  When we have CIF3, that you use its powerful features to
carry even more of the constraint/restrain information in detailed
parsable and executable form.


Perhaps you might consider using, say, _atom_sites_refinement_details
for item 3a, as

     "A description of special aspects of the refinement.

     This is an appropriate location in which to record
     information from refinement programs as presented in
     .res files, etc, but it should never be used as a substitute
     for providing the fully parsed information within
     the appropriate CIF categories."

Alternatively, you could use _atom_sites_special_details,
which already exists, but which does not seem to have a clear
purpose in life.  This would give it such a purpose.

   Regards,
     Herbert





At 12:28 PM +0200 6/29/06, George M. Sheldrick wrote:
>My term doesn't finish until July 21st, but since restraints and 
>constraints have come up again I cannot resist commenting. The main 
>reason why it is not possible to reproduce a crystal structure 
>refinement from the data in CIF file is that most of the information 
>about the restraints and constraints that were applied in the 
>refinement has been lost or degraded. It is no secret that the 
>majority of small molecule structures are refined with a program 
>called SHELX. The last time a change was made to the definitions of 
>the restraints and constraints used by that program was 1993. In 
>fact many of them date back to the 1976 version. Surely we have had 
>enough time to find a way of incorporating this information properly 
>into a CIF file? Otherwise I may feel obliged in the next version of 
>SHELX (if there is one) to embed the .res file - which contains all 
>this information in a concise and unambiguous form - into the CIF 
>file, as many users have requested.
>
>George
>
>Howard Flack wrote:
>>Term has finished.
>>
>
>--
>Prof. George M. Sheldrick FRS
>Dept. Structural Chemistry,
>University of Goettingen,
>Tammannstr. 4,
>D37077 Goettingen, Germany
>Tel. +49-551-39-3021 or -3068
>Fax. +49-551-39-2582
>
>_______________________________________________
>coreDMG mailing list
>[email protected]
>http://scripts.iucr.org/mailman/listinfo/coredmg


-- 
=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

               Office:  +1-631-244-3035
            Lab (KSC 020): +1-631-244-3451
                  [email protected]
=====================================================
_______________________________________________
coreDMG mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/coredmg

[Send comment to list secretary]
[Reply to list (subscribers only)]