Discussion List Archives

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

Re: _atom_site_aniso_label is broken

On Mon, 20 Jun 2005, James Hester wrote:

> As the Bearded One is maintaining a Delphic silence, let me summarize
> where I think we're at:
>
> I state that a (any?) reading of the DDL1.4 spec implies that
> _atom_site_aniso_label is broken.
>
> Nick explains that the parent/child relationship between
> _atom_site_aniso_label and _atom_site_label means that they can be used
> as keys to join/split loops even during validation, consequently solving
> the list_mandatory and _list_reference problem.

Operationally whether your validator does any joining or splitting is an 
application level decision. What it must do is accept either joined or 
split lists as valid alternatives provided they meet the syntactic and 
structure requirements.

> Now I pick up the ball again:
>
> 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).

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

I think list_reference came about so that individual h k and l (3 items) 
could be used as a key. A huge error in the first place because [h, k, 
l] is unique (so use that data item - but you can't because it doesn't 
exist). But what is it about h and k and l that is unique in the 
definition? It is never made explicit.

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.

>
> ================
> data_category
>    _definition
> ;              Character string which identifies the natural grouping of data
>               items to which the specified data item belongs. If the data
>               item belongs in a looped list then it must be grouped only with
>               items from the same category, but there may be more than one
>               looped list of the same category provided that each loop has its
>               own independent reference item (see _list_reference).
>
>
> data_list_link_child
>    _definition
> ;              Identifies data item(s) by name which must have a value which
>               matches that of the defined item. These items are referred to
>               as "child" references because they depend on the existence
>               of the defined item.
> ;
>    _name                      '_list_link_child'
>    _category                    list_link_child
>    _type                        char
>    _list                        both
>
>
> data_list_link_parent
>    _definition
> ;              Identifies a data item by name which must have a value which
>               matches that of the defined item, and which must be present in
>               the same data block as the defined item. This provides for a
>               reference to the "parent" data item.
> ;
>    _name                      '_list_link_parent'
>    _category                    list_link_parent
>    _type                        char
>    _list                        both
>
> data_list_mandatory
>    _definition
> ;               Signals if the defined item must be present in the loop
>                structure containing other items of the designated _category.
>                This property is transferrable to another data item which is
>                identified by _related_item and has _related_function set as
>                'alternate'.
>
> data_list_reference
>    _definition
> ;              Identifies the data item, or items, which must be present
>               (collectively) in a looped list with the defined data item
>               in order that the loop structure is valid. The data item(s)
>               identified by _list_reference provides a unique access code
>               to each loop packet. Note that this property may be trans-
>               ferred to another item with '_related_function alternate'.
> ;
> _______________________________________________
> cif-developers mailing list
> cif-developers@iucr.org
> http://scripts.iucr.org/mailman/listinfo/cif-developers
>

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