Author labelling scheme

• Messages sorted by: [ date ][ subject ][ author ]
• Previous message: herbert_bernstein: "author lists"
• In reply to: herbert_bernstein: "Helix Classification"

Hello everyone,

I'm having a few problems with the items in the mm_atom_site_auth_label
subcategory - I think that the difficulty is that the relationship between
these items and the mm_atom_site_label subcategory isn't defined strictly
enough. 

As an extreme example, say that both _atom_site.label_asym_id and
_atom_site.auth_asym_id are defined in the ATOM_SITE category of a data
block. If each atom had a different value of _atom_site.auth_asym_id, this
would clearly be nonsense, but I don't think that there is anything in the
dictionary to say that this should be forbidden.

We all know that the relationship is something like:

Each value of:  _atom_site.auth_asym_id 
   corresponds to one value of: _atom_site.label_asym_id

Each value of:  _atom_site.auth_comp_id
   corresponds to one value of: _atom_site.label_comp_id

[I think that this is right? Parallel compound naming schemes should be
consistent with each other - if you use your own name for ABA, say, you
should be made to use it consistently.]

Each value of: _atom_site.auth_seq_id
   corresponds to one unique pair of: _atom_site.label_asym_id and
_atom_site.label_seq_id

Each value of: _atom_site.auth_atom_id
   corresponds to one unique pair of: _atom_site.label_comp_id and
_atom_site.label_atom_id

However, as far as I can see, there is nothing in the dictionary to
enforce this, other than the general text descriptions of the items, which
cannot be interpreted by software, in general.

For three of these author items, I think that the solution is fairly
straightforward, namely:

_atom_site.auth_asym_id should have a parent _struct_asym.auth_id
_atom_site.auth_comp_id should have a parent _chem_comp.auth_id
_atom_site.auth_atom_id should have a parent _chem_comp_atom.atom_auth_id

The three new parent items can then be specified as alternatives to
appropriate items in their categories, namely:

save__struct_asym.id
   ...
     item_related.related_name   '_struct_asym.auth_id'  
     item_related.function_code  'alternate'
   ...
   save_


save__chem_comp.id
   ...
     item_related.related_name   '_chem_comp.auth_id'
     item_related.function_code  'alternate'
   ...
   save_

and:

save__chem_comp_atom.atom_id

   ...
     item_related.related_name   '_chem_comp_atom.atom_auth_id'
     item_related.function_code  'alternate'
   ...
   save_

By making the new parent items non-mandatory, and non-key items, their
presence or absence depends only on the presence of their children in the
ATOM_SITE category, which is what is required.

It is less obvious what to do with _atom_site.auth_seq_id - making it
point to an item in CHEM_COMP would make it too restrictive to be useful
(consider what would happen with assemblies of two or more identical
chains - you could quite legitimately use different sequence id's for
corresponding residues in the different chains). 

Does anyone else have any thoughts on this?

Regards,
Peter.

========================================================================
Peter Keller.            \ 
Dept. of Biology and      \       "...nothing works, but
    Biochemistry,          \       everything survives...." 
University of Bath,         \ 
Bath, BA2 7AY, UK.           \        --- Carlos Fuentes
------------------------------\-----------------------------------------
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: herbert_bernstein: "author lists"
• In reply to: herbert_bernstein: "Helix Classification"