Re: Coping with the units extension on core dictionary data names.

• Messages sorted by: [ date ][ subject ][ author ]
• Previous message: Murray-Rust Dr P: "Re: Coping with the units extension on core dictionary data names."

> > 
> > ### _item_aliases.name is determined implicitly for each row:
> > loop_
> >     _item_aliases.alias_name
> >     _item_aliases.units_code
> >     _item_aliases.dictionary
> >     _item_aliases.version
> >           '_cell_length_a'     'angstroms'   'cifdic.c94' '2.0'
> >           '_cell_length_a_pm'  'picometres'  'cifdic.c94' '2.0'
> >           '_cell_length_a_nm'  'nanometres'  'cifdic.c94' '2.0'
> > 
> 	When developing code for core CIF I used to expand the 
> possibilities out like this.  Note that this means 9 names for cell 
> lengths (as _cell_length_ is used as a single 'parent' in the dictionary).
> The 'parent' and the units, when combined can lead to a large number of 
> additional terms.  This makes it potentially difficult unless there are 
> levels of indirection as suggested here.

Exactly - all of the indirection needed is already in mmCIF - all that was
missing was a pointer from alias names to units. The conversion methods in
ITEM_UNITS_CONVERSION is, in effect, a 2x2 table which gives the operator
and constant necessary to do the conversion - two 'dereference' operations
from each of _item_aliases.alias_name and _item.name (via
_item_units_list.code in each case) will get to the appropriate entry.
There is no need to store the conversions multiple times - just pointers
to them, and the expansion is only one level deep (i.e. under control!). 

This is one area in which mmDDL scores very highly when compared to the 
core ddl, in which each _units_conversion has to be stored along with its 
corresponding _units_extension.

[snip]

> This seems workable - again I hacked something along these lines.  
> However, this is a very specific instance of associating methods with 
> items.  

True, but specifying methods for an alias -> mmCIF item conversion would,
in the general case, result in nested loops in the dictionary [one level
of loop_ to specify the list of aliases of an item, and another level to
specify all the methods associated with each alias]. This is not a problem
in principle (dictionaries are not CIF data files after all), but it may
best be left to a later stage of development of the DDL. This is something
which can added at a later stage, if necessary, without messing up what
has been done before. 

It would be very elegant to implement general methods for this kind of
thing, but I think that what I've suggested gets mmCIF out of this
specific problem with a minimum of disruption. Roll on mmDDL version
3 (if that doesn't have John in complete despair.... :-) ).

> One problem I have had in core CIF (I don't know about mmCIF) is the lack of 
> attributes, and this clearly shows in the current example.  It would be 
> nice to write something like: 
>
>   _cell_length_a(units=pm) 1490.3 

The specific issue here, was compatability with the core cif dictionary. 
I like the idea of attributes like this as well, but we can't leave the 
small-molecule people _too_ far behind (or can we.....?). Again, this is 
an issue for the next stage of development, I think. 

Cheers,
Peter.

========================================================================
Peter Keller.            \  "Having beguiled with fiction until I had
Dept. of Biology and      \    none left I resorted to facts, which
    Biochemistry,          \     also ran out."
University of Bath,         \          - Alisdair Gray
Bath, BA2 7AY, UK.           \ 
------------------------------\-----------------------------------------
Tel. (+44/0)1225 826826 x 4302 | Email: P.A.Keller@bath.ac.uk (Internet)
Fax. (+44/0)1225 826449        |   P.A.Keller%bath.ac.uk@UKACRL (BITNET)
========================================================================

• Previous message: Murray-Rust Dr P: "Re: Coping with the units extension on core dictionary data names."