Discussion List Archives

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

Re: Standard uncertainties (SU) in the DDLm dictionary

Hello John,
thank you for the clarification. I do understand that the DDLs are usedto write dictionaries, but doesn't this in turn also implies that theyexplain the way these dictionaries should be interpreted whilevalidating CIF files?
On 04/12/2017 04:12 PM, Bollinger, John C wrote:
> This particular freedom accommodates the variety of current practices.> DDL2 dictionaries, especially mmCIF, define separate data names forstandard> uncertainties, and documents must use that mechanism to convey them inorder> to be valid with respect to those dictionaries.  DDL1 dictionariessuch as Core CIF,> on the other hand, generally do not define separate data names forstandard uncertainties,> and documents must therefore use the parenthesized form in order to bevalid with respect> to *those* dictionaries.  The DDLm versions of the Core and mmCIFdictionaries do not afford> any different options to data files than the original DDL1 and DDL2 dictionaries do.
I fully understand the reasoning behind allowing both of the options.However, in DDL1 and DDL2 the distinction between the parentheses "()"notation and the separate "*_su" data item was made clear:1) both DDL1 and DDL2 had a way of specifying that the appended   parentheses are allowed (using the "esd/su" as the value of the   _type_conditions and _item_type_conditions.code data items   respectively). That did not affect the existence of "*_su" data   items in any way;2) DDL2 had the '_item_related.function_code' data item which allowed   one to specify which data item should hold the standard uncertainty.   This in turn did not affect the parentheses "()" notation in any way.
Following this logic, formally the mmCIF dictionary v2.0.09 allows boththe "()" and the "*_su" notations to specify the standard uncertaintyfor multiple data items. For example, the _cell.length_a data item hasboth the "esd" property and a separate "*_su" data item:
### Example 1 begin ###save__cell.length_a    _item_description.description;              Unit-cell length a corresponding to the structure reported in              angstroms.;    _item.name                  '_cell.length_a'    _item.category_id             cell    _item.mandatory_code          no    _item_aliases.alias_name    '_cell_length_a'    _item_aliases.dictionary      cif_core.dic    _item_aliases.version         2.0.1    loop_    _item_dependent.dependent_name                                '_cell.length_b'                                '_cell.length_c'    loop_    _item_range.maximum    _item_range.minimum            .    0.0                                  0.0   0.0    _item_related.related_name  '_cell.length_a_esd'    _item_related.function_code   associated_esd    _item_sub_category.id         cell_length    _item_type.code               float    _item_type_conditions.code    esd    _item_units.code              angstroms     save_
save__cell.length_a_esd    _item_description.description;              The standard uncertainty (estimated standard deviation)               of _cell.length_a.;    _item.name                  '_cell.length_a_esd'    _item.category_id             cell    _item.mandatory_code          no#    _item_default.value           0.0    loop_    _item_dependent.dependent_name                                '_cell.length_b_esd'                                '_cell.length_c_esd'    _item_related.related_name  '_cell.length_a'    _item_related.function_code   associated_value    _item_sub_category.id         cell_length_esd    _item_type.code               float    _item_units.code              angstroms     save_### Example 1 end ###
The DDLm has the 2) mechanism, but seems to lack the 1). As a result,there seems to be no explicit way to allow (or disallow) the parenthesisnotation in DDLm. Should it be assumed that these two ways of specifyingstandard uncertainty are mutually exclusive for any given data item --that is, if a separate data item is defined in the dictionary is the"()" notation then disallowed? The question is about how the*dictionary* file should be interpreted for the CIF validation purposes.
For example, how should this excerpt from the DDLm cif_core.dic(https://github.com/COMCIFS/cif_core) should be interpreted:
### Example 2 begin ####save__cell.length_a
_definition.id                          '_cell.length_a'loop_  _alias.definition_id         '_cell_length_a'         '_cell.length_a'_import.get [{'save':cell_length  'file':templ_attr.cif}]_name.category_id                       cell_name.object_id                         length_a
save_

save__cell.length_a_su
_definition.id                          '_cell.length_a_su'loop_  _alias.definition_id         '_cell_length_a_su'         '_cell.length_a_esd'_import.get [{'save':cell_length_su  'file':templ_attr.cif}]_name.category_id                       cell_name.object_id                         length_a_su_name.linked_item_id                    '_cell.length_a'
save_
# excerpt from the templ_attr.cifsave_cell_length
    _definition.update           2014-06-08    _description.text;     The length of each cell axis.;    _type.purpose                Measurand    _type.source                 Recorded    _type.container              Single    _type.contents               Real    _enumeration.range           1.:    _units.code                  angstroms     save_### Example 2 end ###
a) Would a CIF with the following value be valid according to thisdictionary?
### Example 2.1 begin ####_cell.length_a 	13.3(2)### Example 2.1 end ###
b) And how about a CIF file with the values?
### Example 2.2 begin ###_cell.length_a 	13.3(2)_cell.length_a_su 0.3 # the su mismatch is on purpose### Example 2.2 end ###
Also, is it correct to assume that the policy toward specifying theSU is stricter in DDLm? Previous DDLs specified that the number *might*be accompanied by its SU and the word *must* is used in this context inthe DDLm (as in "This value must be accompanied by its standarduncertainty")._______________________________________________cif-developers mailing listcif-developers@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links