Discussion List Archives

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

Re: CoreCIF revision 2.3

  • To: Multiple recipients of list <coredmg@iucr.org>
  • Subject: Re: CoreCIF revision 2.3
  • From: "I. David Brown" <idbrown@mcmail.cis.mcmaster.ca>
  • Date: Thu, 26 Jun 2003 17:12:45 +0100 (BST)
	Thank you Brian for such a careful check through the items that we
have (supposedly) approved.  It is a real joy to get some feed back
finally.  I feel as if I have been ploughing a lonely furrow!

	I have built up a cumulative list of the revisions so far approved
and I am making changes to this in response to the comments received.  On
July 4 I will pass this list on to Brian for posting on the web.  Below I
give my response to Brian's various suggestions.

			David


*****************************************************
Dr.I.David Brown,  Professor Emeritus
Brockhouse Institute for Materials Research,
McMaster University, Hamilton, Ontario, Canada
Tel: 1-(905)-525-9140 ext 24710
Fax: 1-(905)-521-2773
idbrown@mcmaster.ca
*****************************************************

I have corrected all the misspellings, etc. as noted.

> _chemical_properties_biological
> _chemical_properties_physical
>
> Since these were both requested by CCDC I wonder whether our
> friends there can find us some suitable examples from the CSD?

I await suggestions from CCDC.

> _diffrn_source_take-off_angle
>
> The definition seems a little sparse, but might be adequate. I wondered
> whether it should say "The angle between the normal to the surface of the
> target and the X-ray beam..."? This still assumes that the area of the
> target illuminated by the X-ray beam is perfectly flat. If not, should it
> say further "... and the midline of the X-ray beam..."? Pedantic, perhaps,
> but it's better to be explicit.

Brian's new definition (which I have adopted) gives a take-off angle of
around 90 degrees, my definition gives a take-off angle of around zero.
Which of these is the correct definition?  I need some guidance from the
equipment specialists.

> _diffrn_reflns_measured_fraction_resolution_full
> _diffrn_reflns_measured_fraction_resolution_max
> _diffrn_reflns_resolution_full
> _diffrn_reflns_resolution_max
>
> (2) I wonder whether these should properly have
> "_related_function   replace" since they're not strictly replacements
> (i.e. they describe different quantities). "alternate" may be better.

I have changed these to alternate

> SPACE_GROUP and SPACE_GROUP_SYMOP items
>
> The category example for SPACE_GROUP needs to omit the following lines:
>
>            _space_group_name_Schoenflies   C2h.6
>            _space_group_Bravais_type       mS
>            _space_group_Laue_class         2/m
>            _space_group_centring_type      C
>            _space_group_Patterson_name_H-M 'C 2/m'
>
> The entry  _space_group_name_H-M           'C 2/c'
> in this example block is wrong - should be _space_group_name_H-M_alt

Done

> In _space_group_name_H-M_alt you need to omit the reference to
> _space_group_name_H-M_alt_description in the definition and omit the
> use of _*_description in the example loop.

I have made these changes and also removed the reference to
_*_reference_settings.
I have also made the other corrections resulting from the restricted
number of items that are extracted from the symCIF dictionary.

> I wonder whether _space_group_id (and its remaining child
> _space_group_symop_sg_id) are needed at all in this core version. If it is
> supposed that the DDL1 version is used only for reporting a space group
> assigned to a structure (which seems to be implied by the items from the
> full dictionary that you have selected), will there ever be cases when
> you need to loop data items in the SPACE_GROUP category?
>
> On the other hand, the insertion of a formal category key for each new
> category introduced may make it easier to carry this onwards to
> applications such as mmCIF that do use DDL2. I don't feel strongly about
> this.

I have retained these items following the philosophy of the last paragraph
(which was the reason for including them in the first place).  I am trying
to look forward to future versions of the dictionaries and also trying to
educate users into good CIF practice.

> _exptl_crystal_colour_ items
>
> Delete the _enumeration_detail column altogether - the enumeration values
> are self-explanatory.

Done

> ATOM_TYPE_SCAT category
>
> I don't have any quibble with the individual definitions that David has
> proposed, but I am concerned about the name collision with existing
> _atom_type_scat_* items that so far have been looped with other
> _atom_type_ data names.

I have started to look at the problem of including more than one
diffraction experiment in a data block (in response to concerns raised by
Brian Toby).  As this would also provide for the use of more than one
wavelength, I have decided to withdraw these items from the 2.3 revision,
because it may be better to combine multiwavelength and
multi-diffraction-experiment in a single more elegant formalism.  I will
bring these items forward for discussion later.


> REFINE category
>
> When I read through the proposal, it seemed to me eminently sensible.
> However, when I scanned through a few hundred CIFs in our production
> directories, I found the situation in practice to be less clear. In the
> sample of files I tested are found the following distinct entries for
> _refine_ls_extinction_method: ......

In view of the mess that the extinction reports seem to be in (which has
worried me in the past) I have withdrawn these items from version 2.3 to
allow us to give the matter more careful thought.

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