Discussion List Archives

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

Re: Seattle Discussions

  • To: Multiple recipients of list <imgcif-l@bnl.gov>
  • Subject: Re: Seattle Discussions
  • From: Andy Hammersley <hammersl@esrf.fr>
  • Date: Wed, 18 Sep 1996 06:41:59 -0400 (EDT)

Concerning my point 3.

Thanks to Peter Keller for precision on his suggestion for the
file identifier.

>From Peter:

> My suggestion was to define a particular format of data block header,
> maybe something like:
>
> data_image0001(type=CBF_v1.0)

etc.

The main point is for the file identifier to be standard for all
cbf files, so easy to parse for system utilities and programs alike; the
version number is a secondary issue. 

Could this idea be sensibly re-ordered to make more of the initial
bytes invariant ? e.g.

data_cbf_image0001

where the 'data_cbf_' (or similar characters) are ALWAYS the first 9
characters of a CBF.

The version number could follow in a CIF data name as suggested. e.g.:

   _image_file.version   1.0

( The file type item, is probably better to avoid, since it would imply
a choice !)

Concerning the end of header marker, I certainly agree that there is no
reason it couldn't be my original suggestion, however, my sense of
aesthetics would prefer some sort of matched pair, and my feeling is 
that there is a practical advantage in that a matched pair is easier 
to remember than two delimiters with entirely different syntax. e.g. 
Some formats use "{" and "}" to delimit the header. This has a certain 
elegance.

e.g. Changing slightly the above suggestion there could be matched pair
like:

data_cbf_begin_image0001

..

data_cbf_end_image0001

This would fulfill my "matched pair" requirement, but perhaps causing
problems, in that 'data_*' is a standard CIF method for introducing
a data block. We could of course filter out the
'data_cbf_end_image0001' before writing to a CIF, but maybe someone 
has better/ alternative ideas ?

Whilst I accept that practically CIF works without an "end of CIF"
marker, it seems to be that an optional (but perhaps recommended), 
"end of CIF" marker could be introduced to standard CIF. (Clearly, 
such an addition would have to be optional.)


Concerning my point 6., John Westbrook wrote:

> I would be happy to try to translate your CBF definition into 
> a DDL-2 compliant dictionary.. 

I think that would be a very useful and appreciated contribution.
(You'll probably spot some inconsistencies.)

I have some questions which maybe could be answered in this context.
Syd Hall introduced, in his CIF workshop talk, the STAR concept of 
defining dependencies of one data item on another.

Can this be included, based on the data item values ? 

e.g. If we have the following:

_array_intensities.linearity linear # Simple linear intensity scaling

Then no extra data items are needed to define the scaling of pixel
element values, but if the data item had a different value e.g.

_array_intensities.linearity scaling_offset # Zero Offset and scale factor

then two data items would have to be defined (unless default values were
considered appropriate) e.g.

_array_intensities.offset 201 # Detector offset value
_array_intensities.scaling 2 # Double intensity range

(I think, from talking to Syd, that the answer is yes, but I don't 
know how to do this.)

Similarly, would it be possible to define a strict ordering of certain
data items. I don't think this occurs in CIF, but it would make writing
CBF software much easier if certain restrictions on the ordering of data
items could be imposed. e.g. in the above example the 
'_array_intensities.offset' and '_array_intensities.scaling' could be
restricted to occur only after the '_array_intensities.linearity' item
has "introduced" them. Can these sort of restrictions be defined ?
Or maybe there are better suggestions for how to enbody these requirements
in a CIF format.

   Andy

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