Discussion List Archives

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

Re: Powder CIF Proposals

  • Subject: Re: Powder CIF Proposals
  • From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
  • Date: Fri, 29 Sep 2000 08:25:33 +0100 (BST)
On Thu, 28 Sep 2000, ROBIN SHIRLEY (USER) wrote:

> 00-2-11.1) _pd_proc_quadr_Q  (or _pd_index_quad_Q - see discussion
> below)
> 
> I accept that if this could be derived directly from
> _pd_peak_d_spacing, then the case for including it would be weak,

The fact that a quantity may be directly derivable from another is NOT an
argument for its exclusion. Such an argument would (strictly) see
structure coordinates (as an extreme example) not defined since these are
derivable from intensity measurements.

The STAR developers have spent the last three years working on the
definition and semantics of the method attributes supported by STAR and by
inference CIF. This is the mechanism by which the exact relationships
between data items may be specified (algorithmically). Hence in our
prototype the dictionary (which is the MOST important component of the
STAR and CIF systems) is literally compiled into a suite of Java and
Python objects. A request for a data item results in the value if stored
in the data file or an invocation of the objects which will eventually
result in a value by evaluation. 

My point here is that, the fact that some quantity is derivable from
another is an important INCLUSION to be made into the dictionary rather
that a reason to exclude it.

> 00-2-11.2) _pd_index_appendix

> The sort of indexing history envisaged in my original proposal can
> now be captured and updated automatically in the form of the Crysfire
> logfile for that dataset - an example is attached.

My main concern with these proposals is that I would like to see the
dictionary definitions for these data items. Until then I accept that all
of these proposed items are reasonable but I would like to know how I
would parse their contents. For instance how will an indexed history be
represented and parsed?

> Thus this would become:
>    _pd_index_merit M FOM program
> 
>    (e.g. _pd_index_merit 21.7 M20 ITO12,
>    or _pd_index_merit 54.215 M1 CRYS934h).

This is syntactically incorrect, and it begs the question are these 3
components of one object (a list) or 3 separate objects?

I also have a general comment concerning worries of the potential size of
data files and looped items. I think many are increasingly coming around
to the idea that it is important to retain "primitive" (read
non-derivable) data as much as possible. If these trial cells are
"relevant" to the discipline then there should be a mechanism for
retaining such information.

cheers

Nick

PS any comments on that CIF BNF yet?

--------------------------------
Dr Nick Spadaccini
Department of Computer Science              voice: +(61 8) 9380 3452
University of Western Australia               fax: +(61 8) 9380 1089
Nedlands, Perth,  WA  6907                 email: nick@cs.uwa.edu.au
AUSTRALIA                        web: http://www.cs.uwa.edu.au/~nick

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