Discussion List Archives

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

(68) pdCIF categories still lack proper keys

  • To: COMCIFS@iucr.ac.uk
  • Subject: (68) pdCIF categories still lack proper keys
  • From: bm
  • Date: Fri, 23 May 1997 16:21:46 +0100
Dear Colleagues

Thanks to those of you who have already registered your votes for the two
dictionaries under review. To those who have not yet, please consider an early
response for either or both cases if you have already made up your minds. I
remind you that you may approve each dictionary independently of the other.

D61.1. pdCIF categories
-----------------------
Paula's critique of the handling of categories in pdCIF has already brought
some recognition of a need to clean up certain minor anomalies, and this
will be attended to in the final working of the pdCIF dictionary.  Two
issues remain which bother her, and which she has posted below.

P> The discussion of the powder dictionary in its current form has focused on
P> two issues - the naming conventions, in which data names do not necessarily
P> begin with the category name, and the loose category construction of the
P> dictionary.
P> 
P> Let me begin by saying that while I personally don't like the practice of
P> data names not beginning with the category name, and while I feel it does
P> a great disservice to the user community (who are never going to understand
P> why _pd_meas_intensity_total cannot appear in the same loop as 
P> _pd_meas_rocking_axis - they can't because they are in different categories)
P> at the end of the day I consider this a question of style, and not one on 
P> which I am willing to be resolutely dogmatic.

On this I think we would agree that the '.' notation in DDL2 does clarify
the taxonomy of categories, but the shortcoming Paula identifies is also
apparent in the core dictionary, where the data name alone doesn't give
unambiguous information about whether or where the data should be located.

P> The category issue is something else again.  I will preface my remarks with
P> quotes from Brian Toby and Brian McMahon.
P> 
P>BT> I have no quibble with categories. They could serve a valuable purpose.
P>BT> I object to the restriction on mixing categories in a loop since it either
P>BT> makes categories useless, as Paula so correctly points out for pdCIF,
P>BT> or requires very complex dictionaries with lots of inter-loop pointers and
P>BT> professional computer programmers to create software.
P> 
P>BM>                                                  It seems to me that Brian
P>BM> T. is adopting the role of the man with the pencil; the mmCIF requirements
P>BM> are those of a multinational fruit wholesaler. Nothing I've seen so far
P>BM> convinces me that it would be death to the CIF effort to proceed with a
P>BM> DDL1.4 pdCIF dictionary - essentially the one we now have - and migrate
P>BM> later to a DDL2 formulation if it's demonstrated to be necessary.
P> 
P> My bottom line here is that despite Brian McMahon's folksy greengrocer
P> analogy, and despite Brian Toby's objection to the restriction on mixing
P> categories within a loop, we are left the the fact that this is a restriction
P> of DDL1.4, and not a requirement of DDL2.  I quote the definition of category
P> in DDL1.4:
P> 
P> data_category
P>    _definition
P> ;           Character string which identifies the natural grouping of data
P>             items to which the specified data item belongs. If the data
P>             item belongs in a looped list then it must be grouped only with
P>             items from the same category, but there may be more than one
P>             looped list of the same category provided that each loop has its
P>             own independent reference item (see _list_reference).
P> ;
P>     _name                      '_category'
P>     _category                    category
P>     _type                        char
P> 
P> In the absence of _list_reference specifiers for each of the categories that
P> are in dispute, I simply don't think that the powder dictionary as it now
P> stands is DDL1.4 compliant.  If Brian Toby can provide consistent list
P> identifiers for each of the looped data items in the PD_DATA and PD_INSTR
P> categories, then I will be willing to approve the dictionary.  Failing that,
P> I will have to vote no.

The issue here is that the pd_data category permits the collection of data
points in an experiment (raw and processed) to be tabulated in one or
multiple tables, depending really on whether there is a direct relation
between each raw and processed point. If such a relationship exists for all
(or almost all) points, then a tabulation like this is appropriate (I
borrow Brian T.'s example from circular 66):

loop_   _pd_meas_angle_2theta
        _pd_meas_counts_total
        _pd_proc_intensity_net
        _pd_calc_intensity_net
                 10     131   101   100
                 10.05  127    97   100
                 10.1   153   128   150

whereas, if there is a more sparse relationship, separate tables are
appropriate:

loop_   _pd_meas_angle_2theta
        _pd_meas_counts_total
                   10     131
                   10.05  127
                   10.1   153


loop_   _pd_proc_2theta_corrected
        _pd_proc_intensity_net
        _pd_calc_intensity_net
                   10     101   100
                   20      21    32

In this listing, the human reader infers that the two rows with
_pd_meas_angle_2theta equal to 10 and _pd_proc_2theta_corrected equal to 10
relate to the same data point; but there is nothing explicit in the
machine-readable dictionary formalism to allow software to make this
identification. The two loops should each have their own _list_reference
identifiers. In this example that could be _pd_meas_angle_2theta and
_pd_proc_2theta_corrected respectively, and the two shoule be related as
parent/child (compare how the core dictionary handles the _atom_site_
and _atom_site_aniso_ components of the ATOM_SITE category). Since Brian
may wish to use either of the 2theta angle identifiers in an amalgamated
table, or since there might be other identifiers for the data point
collected, it might be necessary to introduce additional arbitrary codes
(say _pd_data_id, _pd_meas_id, _pd_calc_id) whose sole function is to link
and identify points that match across multiple tables.

Note that in DDL1.4 a category may be described without a reference item
(see REFLNS_SHELL in the core for an example); but if the category may be
split across multiple tables, the _list_reference identifiers *must* be
provided to relate the entries in the separate tables to each other, as
Paula points out by drawing the definition of _category to our attention
above.

Regards
Brian