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 firstname.lastname@example.org ***************************************************** 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.
Copyright © International Union of CrystallographyIUCr Webmaster