Discussion List Archives

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

File identifier (was Re: Seattle Discussions)

  • To: Multiple recipients of list <imgcif-l@bnl.gov>
  • Subject: File identifier (was Re: Seattle Discussions)
  • From: Peter Keller <bsspak@bath.ac.uk>
  • Date: Thu, 19 Sep 1996 05:31:11 -0400 (EDT)


On Wed, 18 Sep 1996, Andy Hammersley wrote:

> 
> 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.

My understanding is that IUCr/COMCIFS approval would be necessary to
reserve something like this for CBF use (i.e. disallow the use of data
block headers beginning 'data_cbf_' for other purposes. (Perhaps David
could comment on this, or correct me if I am wrong?) 

There is no technical reason why it could not be done this way, as far as
I can see.

> 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 ?

>From the point of view of STAR/CIF, this would imply a second, empty, data
block. In the STAR syntax as published in JCICS, empty data blocks are not
allowed. In more recent (uncirculated) discussions between myself,
Brian McMahon and Nick Spadaccini, we have agreed that there is, in fact,
nothing wrong with an empty data block, so doing it this way should work. 

I hope that I will be in a position to circulate the results of these
discussions on the STAR syntax soon, but there are still a couple of
issues to be resolved. 

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]
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.