Discussion List Archives

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

Re: _atom_site_aniso_label is broken

On Mon, 2005-06-20 at 10:21 +0800, Nick Spadaccini wrote:
> On Fri, 17 Jun 2005, James Hester wrote:
> 
> > 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?). 

> Even in what you say above there must be "implied" semantics (or 
> pragmatics). To require the keys must have the same values is meaningless 
> without the implication you can do a JOIN. Almost all of the operational 
> aspects of DDL1.4 was implied - you will recall at the time the term in 
> response to specific questions was universally "that would be application 
> dependent". STAR/CIF/DDL1.4 were essentially container framework detailing 
> a syntax and a loose structure. What you did with its content was up to 
> you given a you included a limited set of "implied" semantics for the DDL.

I can see that without an implied JOIN there would be little point
having a parent-child relation, however, at what level is the joining
supposed to occur?  Are we really supposed to join at the level of the
DDL-specified semantics of the data items (e.g. merge categories, merge
list_references etc.), or are we talking about a join at the application
level, that is, an application using the data from the CIF can
confidently merge data from separate loops using the parent/child values
as join keys?  If the latter (which seems more natural to me and can
indeed be application dependent), we are back at square one, as the
definitions as they stand don't work.   If the former, something really,
really, should be stated in the DDL1.4 language spec for the meaning of
_list_link_parent.  For example:

"When the _list_link_parent data name is of the same category as the
defined data name, the _list_link_parent data name and the defined name
may be considered as a single combined definition which can be referred
to by either of the original data names for the purposes of resolving
_list_reference and _list_mandatory requirements."

This becomes choice (4) for the Bearded One, and breaks nothing, as the
_atom_site_aniso_label case is the only situation in which it applies in
the official dictionaries.

> > 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)
> 
> I don't recall the details of DDL1.4 so the meaning of _list_reference is 
> hidden in the depths of (my failing) memory. I wouldn't be surprised if 
> your perceived fix had some other side-effect.

The _list_reference attribute states one or more data names which must
co-occur with the defined data name.  In DDL2 this behaviour disappeared
into _category_keys which was shifted into the category definition.  The
side-effect that I can see is that the _atom_site_aniso_ data names must
now either occur in a separate loop, or else the single _atom_site loop
must include both labels (an improvement, but it still means that normal
usage is broken as both labels must be present if a single loop is used
for _atom_site data).
 
> > (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.
> 
> No it wouldn't break them. The semantics of this structure in StarDDL is 
> that you can execute a JOIN on split loops in different (parent-child) 
> categories or it can be stored in that form (think of it as a pre-JOIN, 
> with you being able to execute a SPLIT, if you so wanted).

Not sure I understand you here. Where does this JOIN take place?  At the
level of CIF validation?  Or in an application which is using the data?
And does this mean that a StarDDL-conformant CIF file could contain a
multi-category loop, with parent-child keys generated on the SPLIT?
Anyway, regardless of StarDDL, does that really mean that a CIF which is
supposed to conform to a DDL1.4 dictionary can have multi-category
loops?? 

> > What have other validating CIF programmers done in this case??
> 
> <tongue in="cheek">
> 
> Which other CIF programmers?
> 
> </tongue>

Hmm, it's awfully quiet.  A quick check of DDL1 CIF software reveals
that "validation" often means "is in the dictionary with the right type
and has the same category".
_______________________________________________
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