Discussion List Archives

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

Re: _atom_site_aniso_label is broken

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.

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

> So there are two alternative interpretations [must occur in loop; must
> occur in loop with unique value], which is not the same as no behaviour.

I don't think I said that. 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.

> I maintain that it is possible to come up with a consistent
> interpretation for all of the DDL1 definitions which can be programmed
> into a validity checking program, and while this interpretation might
> not be a unique interpretation, it is consistent with the standard.

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.

> I'm not a standards-type guy, but the idea of implicit behaviour being
> part of a standard doesn't sound right, especially if a single paragraph
> could be added to the DDL1.4 spec for _list_link_child to make things
> explicit - and if it is so unimportant then why doesn't someone just add
> in this paragraph and we can all go home?

As above, you can't define it in _list_link_child because that isn't the 
tag that uniquely identifies whether you JOIN or not. Again that is the 
tag to point to _geom_bond lists, and in that case you WOULDN'T join it to 
its _atom_site list.

> Anyway, I get the picture and will soldier on.  It'd be nice to hear
> what the dictionary maintenance group have to say for themselves.

Macquarie Dictionary - maintain: to preserve.


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