[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: Peter Keller <bsspak@bath.ac.uk>
• Date: Thu, 12 Sep 1996 12:52:53 -0400 (EDT)

> 3. With Peter Keller and Syd Hall the idea of an file identifier 
> (magic number) was discussed. (This was a case where face to face
> discussions were most useful.) Here I had proposed something like:
> 
> ###_CRYSTALLOGRAPHIC_BINARY_FILE: VERSION 1.0
> 
> but the point was made that his information would be lost (in 
> general) if the header were extracted and made into a CIF, and
> processed into another CIF, etc. (as some programs strip out
> comment lines).
> 
> Peter suggested using a specially defined 
> 
> data_
> 
> opening block.
> 
> Syd suggested a similar construct, but using a 
> 
> save_
> 
> block.
> 
> (But since this part of STAR, but not presently part of CIF, I think
> Peter's suggestion is probably more appropriate.)
> 
> Perhaps I could ask Peter to submit his suggestion to the group.
> 
> If we use this to define the start of the ASCII header section, it's
> then not clear to me what we should use to signal the end. Previously
> I suggested:
> 
> ###_END_OF_CBF_HEADER
>  
> to give some sort of \begin \end pair. Any suggestions ?

Hm, OK.

The problem with Andy's original suggestion, is that a STAR-style comment
(which begins with #'s), is a purely lexical construct. In other words, it
is equivalent to whitespace, and any CIF or STAR application is perfectly
free to treat it as such. It is not a good idea to put any useful
information into a comment. 

My suggestion was to define a particular format of data block header,
maybe something like:

data_image0001(type=CBF_v1.0)

and to insist that nothing appears before the header in the file. 
According to the STAR rules, the data block identifier includes the
'(type=CBF_v1.0)' part, but software which is CBF-aware can always extract
it. The data block header format could presumably be reserved for this
kind of use by COMCIFS. To conform to CIF rules, the whole line must be no
longer than 80 characters (including the 'data_' part).

If this kind of 'psuedo-attribute' is thought to be inappropriate for a
true CIF file, the header extraction tool which we have decided is needed
could extract the type, and turn it into a true STAR data item. So, the
above example might become

data_image0001

   _image_file.type      CBF
   _image_file.version   1.0

etc.

This would require the CIF category IMAGE_FILE to be defined in the
appropriate dictionaries. I don't really think that this kind of thing is
strictly necessary, though. 

As for the end of header, there is no problem with using something like
'###END_OF_HEADER', because:

   (1) A CBF is not a CIF, and is very unlikely to have been
'reverse-engineered' from one. There is no reason to insert a true CIF
into the top of an image file in order to make a CBF, and good reasons why
this should be strongly discouraged. You are therefore free to use
comments for purely CBF purposes, and the initial extraction of the header
is one such purpose.

   (2) There is no semantic information in an end-of-header marker.

I don't think that bracketing the header with a pair of 'begin' and 'end'
markers is really necessary. CIF itself has this asymmetry, in that a data
block doesn't have a special end of block marker, and it doesn't seem to
cause any problems, in practice.

Regards,
Peter.

========================================================================
Peter Keller.            \ 
Dept. of Biology and      \       "...nothing works, but
    Biochemistry,          \       everything survives...." 
University of Bath,         \ 
Bath, BA2 7AY, UK.           \        --- Carlos Fuentes
------------------------------\-----------------------------------------
Tel. (+44/0)1225 826826 x 4302 | Email: P.A.Keller@bath.ac.uk (Internet)
Fax. (+44/0)1225 826779        |   P.A.Keller%bath.ac.uk@UKACRL (BITNET)
========================================================================

Reply to: [list | sender only]

• Prev by Date: Seattle Discussions
• Next by Date: Re: Seattle Discussions
• Prev by thread: Seattle Discussions
• Next by thread: Re: Seattle Discussions
• Index(es):
  • Date
  • Thread