[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Specifying values 'less than something' in CIFs?
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIF Standard (COMCIFS)" <firstname.lastname@example.org>
- Subject: Re: Specifying values 'less than something' in CIFs?
- From: Nick Spadaccini <email@example.com>
- Date: Mon, 30 Apr 2012 00:02:29 +0800
- In-Reply-To: <4F9D48F9.firstname.lastname@example.org>
Which takes us back to Saulius' original question what to do with _refine_ls_shift/su_mean <0.001 The answer is it is meaningless given the definition of _refine_ls_shift/su_mean which is "The average ratio of the final least-squares parameter shift divided by the final standard uncertainty." Even this is not correct since it is the ABSOLUTE value of the shift divided by su. Hence less than has no more meaning than more than. The answer is a number. There is often a view in this community that you should let the depositors deposit whatever and then remediate later. CIFCHECK is there to stop/warn on these errors to send the data back to be remediated by the author PRIOR to final deposition. In this way Saulius's problems should never arise, but I guess Saulius is validating a warehouse of CIF depositions that were NEVER properly checked and hence needs these heuristics. Herb is correct in his observation that DDLm provides for a wide range of types, and as I spoke in Madrid, you have the ability to extend types. Hence in my example I created two extensions to the String type, in which in one type \t -> tab and \n -> newline and in the other \t -> tau and \n -> nu. This mechanism can also be used to remediate existing unofficial types that have been created such as "1,2,3,4,5,6,7,8,9" being a 3X3 matrix when there was no direct support for the matrix data structure (there is now). OFFICIALLY - ? means the data value is unknown and the default defined in the dictionary for that data item can be used. . means the value has no meaning in the current context, more often used in loops. For example if you have a loop of atomic data, _id _x _y _z _u11 _u22 _u33 _u12 _u13 _u23 C1 .5 .4 .6 .03 .02 .03 .001 .002 -.002 O1 .1 .2 .3 .02 .02 .02 .001 ? ? H1 .5 .4 .8 . . . . . . In O1 the values u13, u23 are missing and unknown. In H1 the values u11-u23 have no meaning because it was isotropically refined OR no thermals were refined. Herb's reference to "real" problems in database access like is value(a)<.005 when a is recorded as a number versus a string like a < .004 are really fascinating issues. Especially if a is the string a , .006, then the answer is partially true ... possibly! As for real validation, Syd is presenting in Boston our final - final work where we create validation methods within definitions. The simplest self-validation method for a data item would be does the deposited string match the value generated by the dREL method (obvious validation). However other validation that can be done is given the space group symmetry (Hall symbol say) and the generated crystal lattice type are the a, b, c, alpha, beta and gamma values consistent. Once you are able to include evaluation and validation methods within the domain dictionary most bases are covered. On 29/04/12 9:58 PM, "Herbert J. Bernstein" <email@example.com> wrote: > You are absolutely right -- I missed it. It is already there. My > apologies. -- Herbert > > On 4/29/12 9:43 AM, Saulius Grazulis wrote: >> On 04/29/2012 04:33 PM, Herbert J. Bernstein wrote: >> >>> Sounds like a good way to "park" the problem, pending a more general >>> future solution. Formally, until the new tag is approved, you should use >>> a prefix. >>> >> Well, the _refine_ls_shift/su_mean_lt tag is already in the cif_core.dic >> dictionary >> (http://www.iucr.org/__data/iucr/cifdic_html/1/cif_core.dic/Irefine_ls_shift= >> over=su_mean_lt.html), >> and I guess has the same semantics as I am intended to use. So it seems >> that the problem is already solved, that I can use the >> _refine_ls_shift/su_mean_lt tag from the IUCr core dictionary, and that >> all I need to do is to fix the COD CIF collection, doesn't it? >> >> Regards, >> Saulius >> >> > > _______________________________________________ > comcifs mailing list > firstname.lastname@example.org > http://mailman.iucr.org/mailman/listinfo/comcifs cheers Nick -------------------------------- Associate Professor N. Spadaccini, PhD. Adjunct Research Fellow The University of Western Australia 35 Stirling Highway CRAWLEY, Perth, WA 6009 AUSTRALIA MBDP M002 CRICOS Provider Code: 00126G e: Nick.Spadaccini@uwa.edu.au _______________________________________________ comcifs mailing list email@example.com http://mailman.iucr.org/mailman/listinfo/comcifs
Reply to: [list | sender only]
- RE: Specifying values 'less than something' in CIFs?. . (Bollinger, John C)
- Re: Specifying values 'less than something' in CIFs? (Herbert J. Bernstein)
- Prev by Date: Re: Specifying values 'less than something' in CIFs?
- Next by Date: RE: Specifying values 'less than something' in CIFs?. .
- Prev by thread: Re: Specifying values 'less than something' in CIFs?
- Next by thread: RE: Specifying values 'less than something' in CIFs?. .