[Date Prev][Date Next][Date Index]
(58) pdCIF categories; pdCIF minutiae; mmCIF remarks
- To: COMCIFS@iucr.ac.uk
- Subject: (58) pdCIF categories; pdCIF minutiae; mmCIF remarks
- From: bm
- Date: Tue, 18 Feb 1997 15:15:37 GMT
Dear Colleagues This circular contains comments on the powder and mmCIF dictionaries from Syd Hall, and some small points relating to the pd dictionary from the Acta staff. I am trying to keep up the momentum on these reviews! D56.2 Categories in pdCIF ------------------------- S> All in all I am most impressed by the effort that has gone into the S> definitions, they are detailed and clear. But [some] matters S> are of fundamental importance...and the category assignations S> in particular must be assessed carefully to avoid long term problems. S> I note that the _category names do not correspond to the data S> names in that group. e.g. S> S> data_pd_meas_number_of_points S> _name '_pd_meas_number_of_points' S> _category pd_meas_method S> _type numb S> _enumeration_range 1: S> _definition S> ; The total number of points in the measured S> diffractogram. S> ; S> S> data_pd_meas_datetime_initiated S> _name '_pd_meas_datetime_initiated' S> _category pd_meas_method S> S> S> Has this matter been OK'd in the past? If so, I think that the S> conversion of this dictionary to DDL2 is going to be very difficult. S> See also below. S ...> S> I return to the category naming conventions. These serve to S> designate which items reside in the same lists or loops. Judging S> from the wide use of categories pd_data and pd_instr, this S> function has been abandoned? S> S> E.g. S> data_pd_proc_d_spacing S> _name '_pd_proc_d_spacing' S> _category pd_data S> _type numb S> S> data_pd_meas_counts_ S> loop_ _name '_pd_meas_counts_total' S> '_pd_meas_counts_background' S> '_pd_meas_counts_container' S> '_pd_meas_counts_monitor' S> _category pd_data S> _type numb I believe that the practice followed here (and commented upon in earlier circulars) is permissible, and allows for a more flexible data structure than is available under DDL2. However, it does indeed make a migration to DDL2 more difficult. Is it necessary for COMCIFS to rule on whether such a migration will in future be imposed on pdCIF and other dictionaries currently in preparation under DDL1.4? D57.1 E.s.d. -> s.u. -------------------- Howard Flack indicated that he thought my suggested rewordings were appropriate, and so I've posted a modified dictionary (version 0.993) that includes these changes. ============================================================================== D58.1 Enumeration constraints on various pd items ------------------------------------------------- S> I am a bit puzzled by the enumeration constraints on some values. S> E.g. S> data_pd_meas_angle_ S> loop_ _name '_pd_meas_angle_chi' S> '_pd_meas_angle_omega' S> '_pd_meas_angle_phi' S> '_pd_meas_angle_2theta' S> _category pd_data S> _type numb S> _list both S> _enumeration_range -180.0:360.0 S> S> If one is going to permit positive and negative values....why not S> a full circle in both directions? E.g. S> S> _enumeration_range -360.0:360.0 S> S> Surely some geometry will allow for this in the future. S> S> Why not negative values for _pd_meas_rocking_angle? S> S> May one assume that the shapes in this definition are the only S> ones permitted in the future? S> data_pd_spec_shape S> _name '_pd_spec_shape' S> _category pd_spec S> _type char S> loop_ _enumeration cylinder S> flat_sheet S> irregular S> _definition S> ; A description code of the specimen shape. S> ; D58.2 Example for _pd_calib_conversion_eqn ------------------------------------------ S> An example is really needed for this definition: S> S> data_pd_calib_conversion_eqn S> _name '_pd_calib_conversion_eqn' S> _category pd_instr S> _type char S> _definition S> ; The calibration function to convert a channel number S> supplied in _pd_meas_detector_id for a position sensitive S> or energy dispersive detector or the distance supplied in S> _pd_meas_distance_value to Q, energy, angle... S> Use _pd_calib_std_external_* to define a pointer S> to the file or data block containing the information used S> to define this function. S> ; D58.3 Systematic data naming ---------------------------- S> I would have thought that the data names.... S> '_pd_proc_intensity_calc_bkg' S> '_pd_proc_intensity_fix_bkg' S> would be more systematic as... S> '_pd_proc_intensity_bkg_calc' S> '_pd_proc_intensity_bkg_fix' D58.4 R factor nomenclature --------------------------- My Acta colleagues point out that the symbol for the Bragg R factor should be R~B~ and not R~b~ (see J. Appl. Cryst. (1982) 15, 357-359); this is also the nomenclature used in the core dictionary. Acta also uses R~exp~ instead of R~e~ for the expected R factor, and "exp" seems more expressive than "e" here. I've made both these changes in version 0.993. Other symbols for R factors are in accordance with the JAC note. D58.5 Name in example --------------------- We also spotted that "Lachlan Cranswick" should be "Cranswick, Lachlan" in the example for _pd_meas_[pd]. D58.6 General remarks on mmCIF ------------------------------ S> The organisation of this data ... represents a true "tour de force" on the S> subject. S> S> Some minor matters that I am sure have been picked up by others. S> S> (1) The use of "esd" is unfortunate but probably easily changeable S> without causing delay. In fact a global change of "_esd" to S> "_su" may even suffice. I don't consider this a critical S> matter.....but to introduce names with "esd" is probably S> unwise at a time when the IUCr has agreed to go over to "su". S> S> (2) I have always been puzzled by the enumeration S> S> loop_ S> _item_range.maximum S> _item_range.minimum . 0.0 S> 0.0 0.0 S> S> I am sure that there is a simple explanation....just what is it? As I understand it, the occurrence of the same value in both _item_range.minimum and _item_range.maximum indicates that the value itself is within the eunumeration range, i.e. it's an inclusive range. S> My only other comment is really for the future and not pertinent S> to this review. It is that clearly we must at the earliest opportunity S> separate out the core definitions from the mmcif dictionary. This will S> mean of course that there needs to be a DDL2 core dictionary but that S> seems logical and has several obvious advantages over the amalgamation S> that we currently have. S> S> Paula and her colleagues have done a mighty job with this dictionary S> and are to be well and truly congratulated. Regards Brian
- Prev by Date: (57) Further review of pdCIF
- Next by Date: (59) Powder indexing; closing on pdCIF
- Index(es):