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

Re: Specifying values 'less than something' in CIFs?

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

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).

? 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

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" <yaya@bernstein-plus-sons.com>

> 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
> comcifs@iucr.org
> http://mailman.iucr.org/mailman/listinfo/comcifs



Associate Professor N. Spadaccini, PhD.
Adjunct Research Fellow
The University of Western Australia
35 Stirling Highway
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au

comcifs mailing list

Reply to: [list | sender only]