[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Standard uncertainties (SU) in the DDLm dictionary
- Subject: Re: Standard uncertainties (SU) in the DDLm dictionary
- From: Antanas Vaitkus <antanas.vaitkus90@xxxxxxxxx>
- Date: Thu, 13 Apr 2017 13:33:02 +0300
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-transfer-encoding;bh=ovgCa3Lhbn+wmXq5YtHhFDzWTuFP6+WiTQGnLH98W5k=;b=qkj6yODsZQ5udRC/RIUs/3tVLRqazyFkLjEQxVt649qkSHYP5DgH16750WGX9Sv1kYWsToCMLN45sn7Gk79a2WGuc5cdcpfq+e2A83/aM9XgS52xJI1OB1nxrzkmY8fJX6fOYQSBeXFLv/sqSzEJHxLJfi5z+36cSy3XWh/PA+lBQKZJ9jkW62xnKcAoNifVXq17VNXayFiJzNxtWgrNur5uK0i7PtH8jhOuXW5eaoa5aocCk+18TB9ARfBjMEzFPd4hK41GXu+sG+21A85BSQ4WVMuFMicysJt0LUZs5WuAc9QYfZzoebbADVs22zVCDwOIpsSxzLBTecFH2B5ZHw==
- In-Reply-To: <DM5PR04MB0508295878FCDE6EE8EA7829E0030@DM5PR04MB0508.namprd04.prod.outlook.com>
- References: <CALHYoX7EA0gVURSG1t2gELOKyFSd5+oSVtbSpi8jSaV3ekCpPw@mail.gmail.com><DM5PR04MB0508295878FCDE6EE8EA7829E0030@DM5PR04MB0508.namprd04.prod.outlook.com>
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]
- Follow-Ups:
- RE: Standard uncertainties (SU) in the DDLm dictionary (Bollinger, John C)
- References:
- Standard uncertainties (SU) in the DDLm dictionary (Antanas Vaitkus)
- RE: Standard uncertainties (SU) in the DDLm dictionary (Bollinger, John C)
- Prev by Date: Re: Draft JSON specification for CIF
- Next by Date: Re: Draft JSON specification for CIF
- Prev by thread: RE: Standard uncertainties (SU) in the DDLm dictionary
- Next by thread: RE: Standard uncertainties (SU) in the DDLm dictionary
- Index(es):