Discussion List Archives

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

Re: _atom_site_aniso_label is broken

On Fri, 2005-06-17 at 16:25 +0800, Nick Spadaccini wrote:
> 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.

In my ideal world, you could work straight off the published specs for
DDL1.4 to interpret the cif_core dictionary - am I asking too much?.
There is *absolutely nothing* in the _list_link_child and
_list_link_parent DDL1.4 entries to indicate any semantics other than
that the child can only take values that the parent takes (although you
did suggest how this could be enhanced, in, what, 1993?).  And
_atom_site_aniso does not exist as a category in cif_core 2.3.

[...]

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

Yes, it is minor, but it would be so nice to have a program that took
the cif_core.dic and did full validation tests with no built-in special
cases (yes, still the idealist to this very day).  And lo! I have such a
program, except it keeps finding invalid CIFs in the IUCr archives, with
this being the main reason (and people writing "not measured" instead
of ? for enumerated values).

So, to present Brian with his choices as I see them...

(1) a transparent fix in the spirit of DDL1.4 which makes current
behaviour valid (use _list_reference instead of _list_mandatory)

(2) a perhaps more controversial fix: create an _atom_site_aniso
category - this breaks previous cifs where everything was looped
together, but they are technically broken already.

(3) a single line fix: use _related_function 'alternate' - not sure if
this is really in the spirit of DDL1.  

I can't find any direct discussion of this on the mailing lists - surely
it can be hashed out quickly pretty quickly. 

What have other validating CIF programmers done in this case??

James.
> _______________________________________________
> cif-developers mailing list
> cif-developers@iucr.org
> http://scripts.iucr.org/mailman/listinfo/cif-developers
_______________________________________________
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