Discussion List Archives

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

Re: _atom_site_aniso_label is broken

> There is also the _list_reference problem, whereby _atom_site_aniso_
> items have _atom_site_aniso_label as their _list_reference, which would
> mean that when _atom_site_aniso items appear in a single loop with
> _atom_site_items _atom_site_aniso_label still has to be in the loop.  

I consider this "less" of a problem inasmuch as it seems more plausible to
me to pass along the _list_reference function through redirection via
_related_function. Even so, the semantics still need to be made specific,
as you have argued before.

> There are a number of alternative resolutions to the
> _atom_site_aniso_label problem - would it be useful to talk about them
> here, or would doing it on the spot (if considered necessary) in
> Florence be more effective?

Well, I think it's useful to have preliminary discussions on the list so
people have some awareness in advance of what the issues are. For me, the
real issue is not whether the perhaps one-off problem of the atom site list
can be cleanly solved, but whether the hybrid data model of DDL1.4 is useful
in real life for particular classes of data set.

As Herbert said, if one needs (or is content with) a representation that is
isomorphous to a normalized relational database model, DDL2 is the model of
choice. In what circumstances is that not an appropriate representation?
Brian Toby has examples in pdCIF where he wants the freedom to overlay
listings of raw, processed and calculated intensities in the same table or
in different tables or listings. Is this the mark of a lazy programmer, or
of a distinct need?

> "Un"supporting DDL1.4 is a topic that should provoke plenty of spirited
> discussion... is 7 days enough?

I would argue that without complete DDL1 validators, DDL1.4 never has been
*fully* supported, but the argument can become somewhat circular: one must
assume that before now there haven't been full validators because there
wasn't sufficient perceived need for them. Presumably programmers have felt
they understood the intentions behind CIF well enough to write adequate
software, either for writing CIFs, which is easy, or for reading CIFs, which
can be relatively easy if you're interested only in pulling out rather
specific items. It's arguable to what extent that's true, and it is an
approach that won't scale to much larger applications.

However, if the community feels that DDL1.4 remains a valuable model, that
demonstrable flaws can be fixed (i.e. it isn't fundamentally broken)
and that working tools based on it can be made available, then that
is something COMCIFS must take into account when it debates future
directions. We also need an understanding of how Syd and Nick's StarDDL
developments will cover the flaws in the DDL1 model - I understand that it
is pretty robust in handling relational data, but can it accommodate cleanly
the non-relational needs that DDL1.4 still tries to meet?

I'll probably go quiet on this topic for the next couple of weeks while
I put Volume G to bed, but by all means let's hear what people have to say.

Best wishes
Brian
_______________________________________________
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