Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: _atom_site_aniso_label is broken

On Fri, 17 Jun 2005, James Hester wrote:

> In a nutshell:
>
> Both _atom_site_label and _atom_site_aniso_label have the following
> lines in their dictionary definitions:
>
> ...
> _category atom_site
> _list_mandatory  yes
> ...
>
> meaning that they must be included in any list containing items from the
> atom_site category.  As an item name can only appear once in any data
> block, this means that there can only be one list containing _atom_site
> items in a data block (as _atom_site_label and _atom_site_aniso_label
> would otherwise appear more than once).  As _atom_site_aniso_label is a
> child of _atom_site_label, it must have values drawn from the
> _atom_site_label values, so we have a single list, with these two _label
> data names taking identical values.

In DDL 1.4 the semantics of child-parent related labels were never 
explicitly defined as far as I recall. There is a lot of hand waiving one 
does because the categories are actually _atom_site and _atom_site_aniso 
and the parent-child relationship is between the categories, the semantics 
of that meaning they can be collapsed into one if you so choose.

> Also, to be valid a CIF must contain *both* these data items in any loop 
> containing atom_site values.  This is not true for many CIFs out there.

That would be the correct interpretation of what DDL1.4 is saying.

> What was intended (as indicated by the comments in the 
> _atom_site_aniso_label definition) was to allow anisotropic temperature 
> factors to appear in a separate loop.  This could be accomplished by 
> setting _list_mandatory to 'no' for both items, and then setting 
> "_list_reference" to either _atom_site_label or _atom_site_aniso_label 
> for all items in the atom_site category, or else by creating a separate 
> _atom_site_aniso category (as was done in the mmCIF).

Have they NOT created a separate _atom_site_aniso category? I have been 
working with StarDDL for so long I can't recall the (albeit vague) 
semantics of DDL1.4.

> I'm sure the dictionary developers have been aware of this for at least 
> 10 years, judging by a cursory search in the archives.  What are the 
> reasons it has been left as-is?  And should we programmers write in a 
> special exception for these labels?


<tongue in="cheek">

The excuse one uses is that the split between DDL1.4 and DDL2.X made it 
very difficult to resolve some of the problems. The developers split into 
three camps, (1) those that didn't think there was a problem (the "other 
guys") (2) those that waited for a solution to be developed (and are still 
waiting) and, (3) those who went off to develop a new all encompassing DDL 
(and forgot to come back - ala yours truly and Syd). I think Florence will 
see something finally bring together the prodigal DDLs. On the other hand 
this minor problem has taken on such biblical proportions, that maybe we 
need Brian (who has always looked like Moses) to smite something!

</tongue>

cheers

Nick

--------------------------------
Dr N. Spadaccini, Head of School

School of Computer Science & Software Engineering
The University of Western Australia
35 Stirling Highway
CRAWLEY, Perth,  WA  6009 AUSTRALIA

CRICOS Provider Code: 00126G

voice: +(61 8) 6488 3452
fax:   +(61 8) 6488 1089
w3:    www.csse.uwa.edu.au/~nick

email: head@csse.uwa.edu.au
(Mail to "head" is for official correspondence and is accessible to 
several others, in particular my Administration Officer/PA).

email: nick@csse.uwa.edu.au
(Mail to "nick" is for confidential, personal and trivial correspondence,
and is accessible only to me).


_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links