Discussion List Archives

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

Re: _atom_site_aniso_label is broken

On Tue, 2005-06-21 at 15:45 +0800, Nick Spadaccini wrote:
> On Tue, 21 Jun 2005, James Hester wrote:
> 
> > I read this as meaning that the quick fix has broken the explicit
> > semantics, and we must now fall back on the intention (as given in the
> > _atom_site_aniso_label description) to guide us in making valid/not
> > valid decisions.  I'm afraid I don't understand why implied semantics
> > can't be made explicit.
> 
> You had to be there when all this was going on. Since then it goes to my 
> comment in a previous message on this thread about what developers did (1) 
> ent to another DDL, (2) waited for someone else to solve the problem and 
> (3) went away to create a you-beaut all encompassing DDL and forgot to 
> come back.
> 
> Much of DDl1.4 resulted from a flurry of ideas in a time when there was a 
> vacuum of knowledge in these approaches. The semantics weren't made 
> explicit and people haven't bothered to return to the problem - rather 
> developing systems based on their interpretation. Is this correct or even 
> adequate - hell no but it is the way it is.

OK, I'll try to be sanguine about it all.

> >>> document describing DDL1.4 completely silent on these implicit joins?  I
> >>> attach some relevant paragraphs from the DDL1.4 spec
> >>> ftp://ftp.iucr.ac.uk/pub/ddldic.c95 - where would we expect to see an
> >>> explanation of this behaviour?
> 
> I rectified (clarified) the idea of JOINs in my last message replying to 
> John. I am correct in stating that _atom_site and _atom_site_aniso lists 
> could (and do) appear in one list. It is not true that all lists related 
> by link_list_parent/_child relationships can (or should) be joined. A 
> _geom_bond list would be a case in point.

Sure, but my original formulation would still do the trick:
 
"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."

or you could restate it in database terms.  The trick is to specify that
parent and child are in the same category, which catches only
_atom_site_aniso_label and _atom_site_label and no others (but I can
check the other DDL1 dictionaries for similar cases if anyone is
actually taking this seriously).

> ... If it occurs in a loop it must have a unique 
> value (in the column row). Specifically for _atom_site and 
> _atom_site_aniso lists they can appear in separate lists each with a 
> unique identfier or in the same list with only one of the labels necessary 
> to uniquely identify the records. What I am describing here is (was) 
> accepted behaviour you won't find stated in any DDL definition.

My reading of the definition was that ideally reference items would be
unique, but that wasn't a condition for validity.  Hey, whatever, I'll
check uniqueness if that's what it takes.  

> I think this particular case is made difficult because 
> link_list_parent/_child can't be uniquely used to decide whether two lists 
> can be JOINed or not.

Unless you restrict this joining behaviour for validation to
same-category items (see above).  Data processing applications are free
to do whatever they want, including JOINs wherever they see fit, of
course.

> Macquarie Dictionary - maintain: to preserve.

Well a bit of cage-rattling by the <irony>unwashed masses of CIF
developers</irony> might be in order then, especially as some sentiments
have been expressed about applications making automated use of DDL
dictionaries.  
_______________________________________________
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