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

RE: _atom_site_aniso_label is broken

• Subject: RE: _atom_site_aniso_label is broken
• From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
• Date: Tue, 21 Jun 2005 15:17:28 +0800 (WST)
• In-Reply-To: <E88024C0BA8052478C717D472F978C1803164DB9@iu-mssg-mbx05.exchange.iu.edu>
• References: <E88024C0BA8052478C717D472F978C1803164DB9@iu-mssg-mbx05.exchange.iu.edu>

Mon, 20 Jun 2005, Bollinger, John Clayton wrote:

> Your position, then, is that all the items in a particular category that
> appear in lists should be considered to be in a single logical list,
> regardless of whether they are in the same physical list?  Is this a
> practical suggestion, or an interpretation of the DDL?  The DDL is

----> Aside

I have JUST have gone to the iucr.org archive to look at the original 
dictionaries. What I have said in these previous threads is partially 
correct. I have just realised that the use of _list_link_parent is 
overloaded. Yes it is used to relate the _atom_site_aniso_label to the 
_atom_site_label where a joining of the lists does make sense. However it 
is also used in the definition of the _geom_bond_atom_site_label_1/2/3 
where joining doesn't make sense. In the latter case it is strictly a 
reference pointer to where you can find the atomic information.

In StarDDL we have overcome this problem with subcategories. In that case 
we can compress the lists explicitly.

<-----

So I guess the best way to look at it is that from a validation point of 
view, the validation requires the existance of a matching key in the 
parent list for each key in the child list end of story. HOW you use those 
lists and keys becomes application dependent. For me (personally) it makes 
sense to (if only logically) JOIN into one list the contents of 
_atom_site_aniso_ and _atom_site_ lists through the parent/child keys. It 
also make sense to keep the  _geom_bond and the _atom_site_ lists 
completely separate and to use the parent/child keys as reference pointers 
to the records containing the data you need to access.

> All the more reason to look critically at the definition.  I assert that
> it _is_ broken, if only because having attribute list_mandatory means
> that it MUST appear among the list data for the atom_site category, even
> if there was no anisotropic refinement.  I suppose you could argue that
> the value can be assumed based on the parent link to _atom_site_label,
> but if you waved your arms that fast I'd feel the breeze here.

Read the entire DDL and core dictionary. A breeze would quickly turn into 
a force 5 hurricane :)

> Even the validity of splitting the atom_site_aniso_* stuff into a
> separate physical list depends on this idea of an implied join unifying
> multiple physical lists into one logical one for validation purposes.  I

See my point above for what is necessary for validation.



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]

• References:
  • RE: _atom_site_aniso_label is broken (Bollinger, John Clayton)

• Prev by Date: Re: _atom_site_aniso_label is broken
• Next by Date: Re: _atom_site_aniso_label is broken
• Prev by thread: RE: _atom_site_aniso_label is broken
• Next by thread: RE: _atom_site_aniso_label is broken
• Index(es):
  • Date
  • Thread