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 16:57 +0800, Nick Spadaccini wrote:

> > This database joining behaviour is obviously desirable, and I'm happy to
> > go with whatever is standard, but *where* is this described?  Shouldn't
> > this be mentioned in a standards document somewhere?  Why is the
> 
> It isn't I don't think. You are making the mistake of believing the 
> "implied semantics" are something you develop from a set of "explicit 
> semantics". As far as I can recall CIF/DDL were originally syntactic 
> constructs and semantics were argued on the fly. Whether or not they were 
> ever agreed on is another matter. However much of CIF/DDL1.4 is simple and 
> obvious, but there are the occasional contradictions like the "quick fix" 
> construction of _atom_site_aniso_label to meet rapidly evolving 
> requirements (at the time).

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.

> > 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?
> 
> Where do you read ANY behaviour definitions in the contents below? Where 
> are the "behaviours" given in the entire dictionary? For instance look at 
> list_reference - what exactly does it MEAN? Item or items which MUST be 
> present and presumably unique? What is unique? Also the property (which 
> isn't clearly stated) can be transferred via _related_function!

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

[...]

> If you want explicit James, you are not going to find it in any 
> description of DDL1.4 or any dictionary constructed from DDL1.4. Any the 
> deafening silence on this list should indicate why it may not be 
> important. As always I suspect that as powerful as the concept of a data 
> dictionary is, VERY FEW people utilise it. They are more likely to 
> hard-wire what they need into the code.

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?  

The IUCr has this idea of "valid" CIFs relative to a dictionary.
So it sounds like I'm able to conclude that (for DDL1) this only applies
to item-level checking (existence, type, range checks) and that the
loop-level checks (_list_*) are purely non-binding guidelines?
 
As for the importance of it all, I agree that it is an issue on the
margins, as most programmers will write general code which will check
for the existence of data names rather than assume that they are there
just because _audit_conform_dict implies that they should be.  And on
output, programmers are obviously reading between the lines as to what
was "really" meant.  In which case, what is the point of these
attributes? 

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