Re: _atom_site_aniso_label is broken

[James Hester <jrh@xxxxxxxxxxxx>]

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