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:

> I can see that without an implied JOIN there would be little point
> having a parent-child relation, however, at what level is the joining
> supposed to occur?  Are we really supposed to join at the level of the
> DDL-specified semantics of the data items (e.g. merge categories, merge
> list_references etc.), or are we talking about a join at the application
> level, that is, an application using the data from the CIF can
> confidently merge data from separate loops using the parent/child values
> as join keys?  If the latter (which seems more natural to me and can

The latter, but equally the user may choose to have the joined loops in 
the CIF data file. In actual fact the whole thing is just text, so the 
"application" can actually do whatever it wants. In the context of the 
dictionary definition what we are saying is that atom_site and 
atom_site_aniso data items in one loop OR split across two loops (with 
appropriate keys) are synonymous.

Small molecule people tend to use one loop. Macromolecular people tend to 
split across two loops. I thought the original semantics of DDL1.4 was to 
allow the two cases equally. In DDL1.X (x<4) I think it had only one 
category (even though they didn't exist) and the aniso stuff was lumped in 
there (remember CIF was developed by small molecule people).

> indeed be application dependent), we are back at square one, as the
> definitions as they stand don't work.   If the former, something really,
> really, should be stated in the DDL1.4 language spec for the meaning of
> _list_link_parent.  For example:

The application needs to be aware of the fact that it can JOIN the two 
loops into one, OR EQUALLY it may be presented with a JOINED loop!

> The _list_reference attribute states one or more data names which must
> co-occur with the defined data name.  In DDL2 this behaviour disappeared
> into _category_keys which was shifted into the category definition.  The
> side-effect that I can see is that the _atom_site_aniso_ data names must
> now either occur in a separate loop, or else the single _atom_site loop
> must include both labels (an improvement, but it still means that normal
> usage is broken as both labels must be present if a single loop is used
> for _atom_site data).

It doesn't have to include both labels, again an implied semantics. You 
can think of this as a NATURAL JOIN on the keys (deleting the redundant 
key column). An another implied preference is that you would prefer to 
keep the key from the parent category - ie _atom_site_label

>> No it wouldn't break them. The semantics of this structure in StarDDL is
>> that you can execute a JOIN on split loops in different (parent-child)
>> categories or it can be stored in that form (think of it as a pre-JOIN,
>> with you being able to execute a SPLIT, if you so wanted).
>
> Not sure I understand you here. Where does this JOIN take place?  At the
> level of CIF validation?  Or in an application which is using the data?

At the level of CIF validation, it is that the data can be in one loop or 
in two loops and they are equally valid. Hence your validator should 
handle it.

> And does this mean that a StarDDL-conformant CIF file could contain a
> multi-category loop, with parent-child keys generated on the SPLIT?

Again this would occur at the application level. But a multicategory loop 
(provided the categories have a parent-child relationship) is allowed.

> Anyway, regardless of StarDDL, does that really mean that a CIF which is
> supposed to conform to a DDL1.4 dictionary can have multi-category
> loops??

As in my previous statement immediately above.

Oh Bearded one, am I misleading the masses (singular mass?) with this 
recount of what DDL1.4 should allow for?

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