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: Gotzon Madariaga <wmpmameg@lg.ehu.es>
  • Date: Wed, 16 Feb 2000 14:32:34 GMT
On Tue, 15 Feb 2000, Brian McMahon wrote:

> > 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
>    
>    data_my_oxidation_number
>    _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
> 
> loop_
>   _audit_conform_dict_name
>   _audit_conform_dict_order
>   _audit_conform_dict_merge_mode
>       'cif_core.dic'       1             .
>       'my.dic'             2             OVERLAY
> 

That was exactly my idea.



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

True. But I was thinking in two official dictionaries. For example
modulated structures share items of two dictionaries cif_core.dic and
cif_ms.dic. Imagine that naming of data blocks is in cif_ms.dic more
restrictive that in cif_core.dic. An overlay within the AUDIT_CONFORM loop
would be the best solution.

The converse case a generalisation of a cif_core.dic item could be also
interesting. As it is proposed in the document, future changes in official
dictionaries could be done through some (official?) fragments that would
be eventually merged (overlaid?) with the current dictionaries. Hence a
CIF could be automatically validated with a loop as the one you suggest:

  loop_
    _audit_conform_dict_name
    _audit_conform_dict_order
    _audit_conform_dict_merge_mode
        'cif_core.dic'                                  1           .
        'cif_fragment_before_a_new_core_release.dic'    2           OVERLAY

After the new release the CIF would be automatically compliant with the
new official dictionary. 

That is only an idea that points towards the ideal automatic handling of
CIF,s.


Best regards

Gotzon


-----------------------------------------------------------------------------
Gotzon Madariaga                          |   E-mail: wmpmameg@lg.ehu.es
Dpto. Fisica de la Materia Condensada     |
Facultad de Ciencias                      |   Phone: 34 946012467 
Universidad del Pais Vasco                |   FAX  : 34 944648500
Apdo. 644                                 |
48080 Bilbao (SPAIN)                      |
-----------------------------------------------------------------------------