Alias definitions and implicitly defined items.

• Messages sorted by: [ date ][ subject ][ author ]
• Previous message: John Westbrook: "Re: _item.mandatory_code can be undefined! (plus other development"

Hi all,

This mail is in response to a question which Herb asked Paula (who posted
an answer to the mmCIF list). I think that it would be useful to go into
this in a little more detail, since it takes in a couple of basic points
about how dictionaries work. First the original question: 

Herb Bernstein writes:

I've run across another issue which I don't think is a problem,
but which confused me.  For the following blocks, you have
a loop of names and such with an unlooped alias:
     _atom_site.id, _atom_type.symbol, _chemical_conn_atom.number,
     _diffrn_radiation.wavelength_id, _diffrn_scale_group.code,
     _diffrn_standard_refln.code, _exptl_crystal.id,
     _reflns_scale.group_code
You explicitly say in the comments for _atom_site.id that the
intention is to link the alias to _atom_site.id, which is the
first name in the loop, so I am assuming that for all the rest
the intention is to link an unlooped alias to the first name when
the names are looped, and not to link that alias to any of the
other names.  My apologies if this is more properly a DDL
documentation question, but may I suggest adding an explict
comment about the intended linking to the blocks which don't
have such a comment, to avoid confusion for novices like me.

To which Paula answered:

I think I understand what Herb is asking here - in the save_ frames that
describes _atom_site.symbol (for instance) the data item is aliased to its
equivalent in the original cif core dictionary (_atom_site_symbol).  However,
the save_ frames also includes the tree of all data items that are children
of _atom_site.symbol, and it is *not* our intention that they all be assumed
to be alised to _atom_site_symbol.  I think that this is probably more a
DDL issue than a content issue, and perhaps John ans the other who think
carefully about DDL might want to give this some thought.  

---------

The first place to look in answering this question is at the DDL 
definitions of the ITEM_ALIAS category and its members. This category has 
two key items, _item_aliases.name and _item_aliases.alias_name. The first 
is defined in the save frame of its parent _item.name, and has a 
mandatory code of 'implicit'. The second (which is not a child of any 
item) is defined in its own save frame, and has a mandatory code of 'yes'

What this is basically saying, is that to define an alias, both the true 
name and the alias name are required. A full specification of a single 
alias might look something like this:

save__atom_type.symbol
    .....
    _item_aliases.name          '_atom_type.symbol'
    _item_aliases.alias_name    '_atom_type_symbol'
    ....
    save_

However, since the mandatory code of _item_aliases.name is 'implicit', it 
can be determined from context, if it is not explicitly specified. What 
this generally means, for items which themselves contain names of data 
items, is that the first five characters are removed from the save_.... 
header of the enclosing save frame. So, _item_aliases.name can be omitted 
from this specification, without changing the meaning. 

This is the answer to part of what Herb was asking - the alias is linked
to the item whose name is implicitly derived from the save frame header,
and does not depend on any other loops in the save frame. In fact, the
order of the rows in these loops is quite irrelevant. 

Where _item_aliases.name MUST be given, is if you are defining the alias 
for a name other than the one which appears in the save frame header. So, 
for example, _atom_type.symbol has a child item _atom_site.type_symbol, 
which needs to have an alias _atom_site_type_symbol . Now, in mmCIF, 
Paula has done this in the save frame definition for the child item, but 
this is basically a question of style (I think). It could equally well be 
defined in the save frame for its parent item, which would then look like 
this:

save__atom_type.symbol
   ....
   loop_
   _item_aliases.name
   _item_aliases.alias_name
   '_atom_type.symbol'        '_atom_type_symbol'
   '_atom_site.type_symbol'   '_atom_site_type_symbol'
   ....
   save_

Herb's alternative interpretation, that one alias refers to several
items, would be done like this: 

save__atom_type.symbol
   ....
   loop_
   _item_aliases.name
   _item_aliases.alias_name
   '_atom_type.symbol'        '_atom_type_symbol'
   '_atom_site.type_symbol'   '_atom_type_symbol'
   ....
   save_

However, I hope that there are no dictionary developers out there who are
thinking of doing this - assuming that this is permitted, it would
severely cripple CIF verification. 

Another possibility, that one item has several aliases, could be expressed
as: 

save__atom_type.symbol
   ....
   loop_
   _item_aliases.name
   _item_aliases.alias_name
   '_atom_type.symbol'        '_atom_type_symbol'
   '_atom_type.symbol'        '_atom_site_type_symbol'
   .... 
   save_

or even, in this case, as:

save__atom_type.symbol
   ....
   loop_
   _item_aliases.alias_name    # _item_aliases.name derived implicitly
       '_atom_type_symbol'     # for each loop packet
       '_atom_site_type_symbol'
   ....
   save_

You may ask, after all this, why not make things clearer by putting 
everything into one loop:

save__atom_type.symbol
   ....
   loop_
   _item.name
   _item.category_id
   _item.mandatory_code
   _item_aliases.alias_name
   ....
   save_

Well, for good reasons, which I am not going to go into, ALL the items in
a loop MUST be in the same category. (This applies equally to dictionaries
and CIF's.) This is stated in the DDL document, in the CATEGORY section. 
But that, as they say, is another story.

I hope that this helps.
Peter.

========================================================================
Peter Keller.            \ 
Dept. of Biology and      \ "It is a pity that people are being killed
    Biochemistry,          \  by my guns"
University of Bath,         \ 
Bath, BA2 7AY, UK.           \          --- Mikhail Kalashnikov
------------------------------\-----------------------------------------
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: John Westbrook: "Re: _item.mandatory_code can be undefined! (plus other development"