Discussion List Archives

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

Re: Transfer from msCIF: refine_ls_class category

  • To: Multiple recipients of list <coredmg@iucr.org>
  • Subject: Re: Transfer from msCIF: refine_ls_class category
  • From: Brian McMahon <bm@iucr.org>
  • Date: Wed, 9 Dec 1998 09:17:28 GMT
>> (3) Is the Group happy with the proposed handling of overlapping bins
>> through application-specific compound codes?
> 
> 	I do not understand the question.  What are the overlapping bins
> 	and what are the application-specific compound codes? 

I apologise for being obscure. Howard made a comment to accompany his 
proposed scheme:

H>  (2) One may well wish to bin reflections simultaneously according to
H> several criteria. If a criterion for binning is very simple, (e.g.
H> resolution shell, parity or index group) it is not worth the bother of
H> using the parent/child code which links the individual reflection to the
H> class. _code is thus optional. On the other hand, the _code is very
H> useful in cases where the criteria for the bins is more complicated
H> (e.g. the reflections chosen for an R free calculation.). How many
H> _codes are really necessary? I have put in just one.

I interpreted this through a possible example:

B> The question also arose of overlapping bins. It's possible to set up some
B> compound codes such as
B>     loop_
B>      _diffrn_reflns_class_code
B>      _diffrn_reflns_class_description
B>            A    'reflections matching criterion A'
B>            B    'reflections matching criterion B'
B>            AB   'reflections matching criteria A and B'
B> although interpreting these would perhaps need to be programmed explicitly
B> into an application.

My question to the Group was whether this was considered an appropriate way
to handle reflections that conform to different classification criteria, and
so might be binned differently according to the criterion of choice.
Alternatives that come to mind are:

(i) introduce explicit classification codes:
        loop_ _diffrn_reflns_class_parity_code
              _diffrn_reflns_class_parity_description
         A  'h odd, h+k even'   B  'h, k even'
        loop_ _diffrn_reflns_class_index_code
              _diffrn_reflns_class_index_description
         A  'm=0; main reflections'   B  'm=q; first-order satellites'

        loop_ _diffrn_refln_index_h
              _diffrn_refln_index_k
              _diffrn_refln_index_l
              _diffrn_refln_class_parity_code
              _diffrn_refln_class_index_code
                1  0  0   C  A     1  1  0   A  A
                2  0  0   A  A     2  1  0   D  B

(ii) similar, but with more general code names:
        loop_ _diffrn_reflns_class_code_A
              _diffrn_reflns_class_description_A
         A  'parity grouping: h odd, h+k even'   B  'parity grouping: h, k even'
        loop_ _diffrn_reflns_class_code_B
              _diffrn_reflns_class_description_B
         A  'incommensurate satellite class: m=0; main reflections'
         B  'incommensurate satellite class: m=q; first-order satellites'

        loop_ _diffrn_refln_index_h
              _diffrn_refln_index_k
              _diffrn_refln_index_l
              _diffrn_refln_class_code_A
              _diffrn_refln_class_code_B
                1  0  0   C  A     1  1  0   A  A
                2  0  0   A  A     2  1  0   D  B

(iii) display a many-to-many relationship in a separate table
        loop_
         _diffrn_reflns_class_code
         _diffrn_reflns_class_description
            A    'parity grouping: h odd, h+k even'
            B    'parity grouping: h, k even'
            C    'incommensurate satellite class: m=0; main reflections'
            D    'incommensurate satellite class: m=1; first-order satellites'

        loop_ _diffrn_refln_class_refln_index_h
              _diffrn_refln_class_refln_index_k
              _diffrn_refln_class_refln_index_l
              _diffrn_refln_class_refln_class_code
                1  0  0   C
                1  0  0   A
                1  1  0   A
                1  1  0   B
                2  0  0   A
                2  0  0   D

(i) involves the introduction of new datanames for new (possibly quite
arbitrary) classifications; (ii) is inelegant and always offers a finite
and arbitrary number of choices; (iii) carries the overhead of a separate
table, and to make this a more tightly relational model (e.g. to conform to
the DDL2 core representation) we should properly describe it in a new
category. My original suggestion (to merge single-letter codes, so that AB
flags reflections satisfying both criteria A and B) is simpler, but does not
explicitly convey the dual relationship - it is a convention that 'AB' means
'satisfies A and B', and thus a convention that needs to be programmed
explicitly into any applications software.

Does that make things any clearer?

Regards
Brian

[Send comment to list secretary]
[Reply to list (subscribers only)]