Discussion List Archives

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

(42) Submission for approval of Core dictionary version 2.0

  • To: COMCIFS@iucr.ac.uk
  • Subject: (42) Submission for approval of Core dictionary version 2.0
  • From: bm
  • Date: Fri, 28 Jun 1996 13:13:24 +0100
Dear Colleagues

I am heedful of the need to formalise the Union's approval for the extended
Core dictionary, which has been promised for years. It would seem appropriate
to be able to announce at Seattle that the new Core dictionary has been
approved.  Consequently, I have been going through my working version, trying
to reconcile the various requests and suggestions that have been put forward
over the course of our discussions, and I now circulate the result in an
accompanying email to the Committee, with a request that they give formal
approval to it within the month allocated in our rules of procedure. Indeed,
I would welcome any comments on a shorter timescale. Consultants who also
receive this version are welcome also to review it and submit their comments.

I have prepared a formatted version which is annotated in a way designed
to make it easier to discern deifferences from the original dictionary -
new sections are in italic font, and revisions to existing sections are
highlighted in the margin. I hope you will find this useful. That version
will be mailed from Chester at the beginning of next week, and I hope it
will be with you soon.

I have a request - I have failed to find examples for (I think) five of
the category overview sections among the CIFs archived in Chester. I would
appreciate some kind person inventing a few examples - they can illustrate
hypothetical cases, but should have values "reasonable" to the subject in
hand. I don't know, for instance, the order of magnitude of scale factors
in typical experiments.

Other than this, there are only a few comments from David Brown on the
last mailing:

Ongoing discussions
===================
D> D40.1 F(000)
D> ------------
D> 	I agree with your definition
D> 
D> D40.3 U(eq)
D> -----------
D> 	I approve the definitions of _*_U_equiv_geom except that I do not 
D> see the need for an upper limit in _ennumeration_range.  The number must 
D> (should?) be positive, but there is no intrinsic fixed upper limit, 
D> though there is a practical limit.  I favour not including an upper limit 
D> unless it represents a rigorous cut-off above which it is physically 
D> impossible for the number to occur (this may be the case for U=10, but it 
D> is probably also true for U=5 or even U=1).  I would also like to see a 
D> definition of this in terms of the usual U(ij)'s that people report.  It 
D> is useful to have these definitions for reference purposes.  I can see 
D> people using cif definitions as a place to learn their 
D> crystallography (or at least find correct definitions and useful 
D> expressions).
 
I shall try to find an expression involving the Uij's. Has anyone got it
to hand?

D> D40.4, 40.5, 41.1 and 41.4
D> --------------------------
D> A number of these items seem to overlap and can best be treated together 
D> (at least in my discussion).  You raise the prospect of a cif using 
D> datanames from other dictionaries such as mif or local dictionaries, but 
D> add a caution that they two dictionaries should not contain duplicate 
D> names.  A local dictionary can be designed in such a way, but we have no 
D> control over the names used by mif, nor they over the names used by cif.  
D> It is easy enough to see that by accident two names may be used with 
D> different definitions (probably only subtly different which would be all 
D> the more dangerous).  More likely they may elect to use exactly the same 
D> dataname with the same definition for the ease of the community that uses 
D> both dictionaries.  Thus I see that it is dangerous to invoke two or more 
D> dictionaries within the same datablock if these have not been carefully 
D> constructed to exclude common datanames.
D> 
D> 	If this is the case, then one might consider including a mif and a
D> cif as different data blocks in the same file.  It would be necessary to
D> have an introductory block (the structure of this block would have to be
D> agreed to at a high level that comcifs, perhpas in DDL) along the lines of
D> the audits that you have defined in 41.4.  That is, the first datablock in
D> the file would not only indicate the contents of the subsequent
D> datablocks, but could also identify the type of file (cif or mif) and give
D> the mapping that you have included as an example in D40.5.  I like the
D> idea of a datablock at the beginning of a file that explains what the
D> subsequent datablocks are doing.  It acts as a kind of index.  It would be
D> handy to have such an index in the dictionaries so that one could locate a
D> particular data item in the printed copy more easily, or get some idea of
D> the scope of the dictionary.  We will be seeing more multiblock files in
D> the future.  In listings of space groups in symcif it will be necessary to
D> give each space group its own block, so that a file that includes all 230
D> space groups will have at least 230 different datablocks. 

I propose to leave in the _audit_conform_* and _audit_link_* datanames
I introduced last time, because I think they are quite workable and can be
used in schemes such as David suggests. I am leaving the _audit_join_*
issue open for further discussion.

D> D41,3 CIFs for non Acta Cryst. C papers
D> ---------------------------------------
D> 	This looks like a good start.  Presumably this is SGML compatible.

Yes.


---------------------------------------
Please enjoy your new reading material!

Best wishes
Brian