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) ========================================================================