Discussion List Archives

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

Re: Minutes - Action item (1) merging dictionaries

  • To: Multiple recipients of list <comcifs-l@iucr.org>
  • Subject: Re: Minutes - Action item (1) merging dictionaries
  • From: Brian McMahon <bm@iucr.org>
  • Date: Tue, 15 Feb 2000 15:09:40 GMT
> Brian and Gotzon: I suspect it would help all of us if you could 
> each give an abbrieviated example of what you consider is needed
> wrt AUDIT_CONFORM usage, and why. 

Here's an example to show my thinking. The assumption is that you want to
validate a CIF using a piece of software that is entirely dictionary-driven.
The question is, which dictionary to use, and how to use it?

Example: The core dictionary permits an atom type oxidation number to
range from -8 to +8. Suppose you are loading structures into a database and
want to reject any with oxidation number greater than 4 or less than -4. 
You might write a local dictionary containing the entry
   _name                 '_atom_type_oxidation_number'
   _enumeration_range    -4:4

and then validate using the notional tool "dictcheck" with a command such as 

   dictcheck -mode OVERLAY -A my.dic test.cif

where "-mode OVERLAY" means that you replace the existing enumeration range
with the new one; "-A" means that you append my.dic to the dictionaries
specified in the AUDIT_CONFORM list of test.cif.

What Gotzon is saying (I think) is that instead of freely choosing such a
validation procedure, the CIF should declare its own conformance internally as

      'cif_core.dic'       1             .
      'my.dic'             2             OVERLAY

Advantage: the validation process is driven solely by the contents of the
CIF (and the accessible dictionaries).

Disadvantage: the CIF itself cannot now be said to conform to the Core
dictionary. In this example, in fact, it does still conform, because the
local enumeration range is more restrictive than the official one; but one
could well imagine the converse case.


The more I think about this, the more I incline to the view that there
is a distinction in intent between concatenating dictionaries (which simply
makes more definitions available), and overlaying them (which actually
modifies the attributes that the data values are allowed to possess). I
still think that overlaying is useful for local validation and for local
extension (e.g. the CCDC CIF editor might add examples to the example text
in the CIF dictionary to give a more user-friendly help commentary in pop-up
windows). And so I think that a well defined overlay protocol is worth
having. But perhaps I am less persuaded than I was at first by Gotzon's
suggestion to describe overlay procedures in the AUDIT_CONFORM loop.