[Imgcif-l] CBF file templates
Herbert J. Bernstein
yaya at bernstein-plus-sons.com
Wed Sep 30 12:28:27 BST 2009
The unquoted question mark and period are reserved for "null" (i.e.
unspecicifed) values in a CIF, with the convention having been
adopted that the question mark get used when there is a suggestion
to fill it in later, while the period get used when there is
no need to fill it in later.
=====================================================
Herbert J. Bernstein, Professor of Computer Science
Dowling College, Kramer Science Center, KSC 121
Idle Hour Blvd, Oakdale, NY, 11769
+1-631-244-3035
yaya at dowling.edu
=====================================================
On Wed, 30 Sep 2009, harry powell wrote:
> Hi
>
> Yes, this would be in the template (a ? i a field in a finished CIF
> says something unspecfied about the user or the experiment); for
> example, have a look at the CIFs that SHELX generates - quite a few ?
> in things that should be edited by the submitter...
>
> On 30 Sep 2009, at 10:50, Winter, Graeme (DLSLtd,RAL,DIA) wrote:
>
>> Indeed.
>>
>> The *isolated* in here is key: if the user has named their
>> experiment ?
>> I expect that this says more about them than the sample under
>> study :o)
>>
>> More seriously though, I guess that any title would have some
>> furniture
>> like quotes ("?" not ?) around it.
>>
>> Finally, this is not in the final CIF file, this is in the template,
>> which may or may not be a CIF file.
>>
>> No worries.
>>
>> Graeme
>>
>>
>>
>> -----Original Message-----
>> From: imgcif-l-bounces at iucr.org [mailto:imgcif-l-bounces at iucr.org] On
>> Behalf Of harry powell
>> Sent: 30 September 2009 10:47
>> To: The Crystallographic Binary File and its imgCIF application to
>> image
>> data
>> Subject: Re: [Imgcif-l] CBF file templates
>>
>> Hi
>>
>> single, isolated "?" is the CIF standard - don't start re-inventing
>> the
>> wheel!
>>
>> See - http://www.iucr.org/__data/iucr/cif/standard/cifstd11.html -
>>> "Note that the missing items in this example are flagged with a `?'.
>>> Programs such as CIFIO can only output the data items present in
>>> their
>>
>>> internal files and the `?' flag represents a simple mechanism for
>>> identifying missing items.
>>>
>>> The use of a `?' as a missing data flag is important for two
>>> reasons: it signals the inaccessibility of a data item to the
>>> generating software, and it satisfies the STAR File requirement that
>>> each data name must be matched with a data value. The use of a `?'
>>> enables data items from other sources to be added later either
>>> manually or by software. "
>>>
>>
>>
>> i.e. if there's only a single "?" there, you know there's something
>> missing. If there's anything else, you don't know that, and you also
>> break all the CIF parsers that expect a single "?" to represent
>> missing
>> information.
>>
>> So "I04?" would not represent a field with a missing item, it would
>> be a
>> valid string saying something along the lines that you thought you
>> were
>> collecting on I04, but got confused while walking around the ring and
>> ended up in the wrong hutch (but hopefully, the beamline software
>> would
>> put the right value in anyway...).
>>
>> You may have a better way, but don't call the result CIF (or CBF).
>> CIF has its limitations, as we all know.
>>
>> On 30 Sep 2009, at 10:16, Ashton, Alun (DLSLtd,RAL,DIA) wrote:
>>
>>>
>>> I don't like a single ? It could be a part of a title for a beamline
>>> session, would that confuse it? While multiple ? would be unlikely,
>>> unless they were really unsure what they were doing :).
>>>
>>> Alun
>>> ___________________________________________________________
>>> Alun Ashton, alun.ashton at diamond.ac.uk Tel: +44 1235 778404
>>> Data Acquisition Group, http://www.diamond.ac.uk/
>>> Diamond Light Source, Chilton, Didcot, Oxon, OX11 0DE, U.K.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: imgcif-l-bounces at iucr.org
>>>> [mailto:imgcif-l-bounces at iucr.org] On Behalf Of harry powell
>>>> Sent: 30 September 2009 10:09
>>>> To: The Crystallographic Binary File and its imgCIF application to
>>>> image data
>>>> Subject: Re: [Imgcif-l] CBF file templates
>>>>
>>>> Hi
>>>>
>>>> a single "?" in an empty field is allowed under CIF rules, as I
>>>> understand. ISTR it from the days when I deposited CIFs for small
>>>> molecule structures, and CBF is supposed to be conformant to the
>>>> normal CIF rules (apart from the binary section, about which people
>>>> may argue).
>>>>
>>>> d*Trek has to be the model of being comprehensive apropos its use of
>>>> the header.
>>>>
>>>> I don't think HKL is an issue, to be honest - I think I'm right in
>>>> saying that Wladek has said that "CBF is just another image
>>>> format" -
>>
>>>> they will use what they see as useful and/or necessary.
>>>>
>>>> On 30 Sep 2009, at 09:45, Winter, Graeme (DLSLtd,RAL,DIA) wrote:
>>>>
>>>>> Dear Herbert & list,
>>>>>
>>>>> One template per beamline is probably, in reality, the way it would
>>>>> work. We would just make sure that they are all the same.
>>>> Adding ????
>>>>> For the detector software to fill in sounds like good
>>>> sense. Is this
>>>>> kind of thing supported? An alternative is to have some
>>>> boiler plate
>>>>> which needs to be copied in, then work on getting the
>>>> format for the
>>>>> detector produced bit the same. These are essentially the same
>>>>> problem.
>>>>>
>>>>> What's the consensus on the best approach? Does everyone
>>>> support the
>>>>> use of templates?
>>>>>
>>>>> At the other end, I assume that the contents of the current
>>>> ADSC CBF
>>>>> header represent the minimum which should be in place for e.g.
>>>>> Mosflm to
>>>>> make sense of the image, and anything we add will be ignored. XDS
>>>>> ignores the header anyway. D*TREK, HKL - any comments?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Graeme
>>>>>
>>>>> -----Original Message-----
>>>>> From: imgcif-l-bounces at iucr.org
>>>> [mailto:imgcif-l-bounces at iucr.org] On
>>>>> Behalf Of Herbert J. Bernstein
>>>>> Sent: 29 September 2009 11:34
>>>>> To: The Crystallographic Binary File and its imgCIF application to
>>>>> image data
>>>>> Subject: Re: [Imgcif-l] CBF file templates
>>>>>
>>>>> Dear Colleagues,
>>>>>
>>>>> Right now the utilities in the library use templates that are
>>>>> intended to be for just one beamline per template, so they
>>>> are set up
>>>>> with tags with zero values for the items that they know will be
>>>>> populated from the detector and known specific values for
>>>> the beamline
>>>>> for items that come from the beamline geometry. If we are going to
>>>>> have master templates, there would seem to be more cases:
>>>>>
>>>>> 1. Items that will be supplied by every detector.
>>>>> 2. Items that will be supplied by some detectors but not
>>>>> others
>>>>> 3. Items that will be supplied by every beamline
>>>>> 4. Items that will be supplied by some beamlines but not
>>>>> others
>>>>>
>>>>> I would suggest using "?", rather than "0" values for all
>>>> items that
>>>>> are know known for sure in writing the master template. Then in
>>>>> specializing for a given beamline (e.g. in setting up the
>>>> axes), all
>>>>> of the "?" for 3, hopefully a lot for 4 could be removed
>>>> and replaced
>>>>> with known values.
>>>>> When the detector data is merged with the beam-line
>>>> specific tempate,
>>>>> hopefully all "?" for 1 and a lot for 2 would be replaced with data
>>>>> from the detector. The "?" that are left would then be
>>>> clear markers
>>>>> of what was supplied neither by the beamline nor by the
>>>> detector. I
>>>>> am working on the code to allow comments to be preserved and copied
>>>>> along with data, so we could carry remarks such as:
>>>>>
>>>>> # This item should be supplied by every beamline
>>>>> # This item should be supplied on beamlines ..., ... ...
>>>>> # This item should be supplied by every detector
>>>>> # This item should be supplied by detectors ..., ... ...
>>>>>
>>>>> or is people, prefer, we can add CIF tags with the same info
>>>>>
>>>>> Regards,
>>>>> Herbert
>>>>> =====================================================
>>>>> Herbert J. Bernstein, Professor of Computer Science
>>>>> Dowling College, Kramer Science Center, KSC 121
>>>>> Idle Hour Blvd, Oakdale, NY, 11769
>>>>>
>>>>> +1-631-244-3035
>>>>> yaya at dowling.edu
>>>>> =====================================================
>>>>>
>>>>> On Tue, 29 Sep 2009, Winter, Graeme (DLSLtd,RAL,DIA) wrote:
>>>>>
>>>>>> Dear CBF'ers,
>>>>>>
>>>>>> I'm working on trying to establish a "Diamond standard"
>>>> template for
>>>>>> our CBF files across a number of detectors, and I was
>>>> wondering how
>>>>>> this is best specified. What would be ideal would be to set up a
>>>>>> template which contains those things that the beamline "knows" but
>>>>>> the
>>>>>
>>>>>> detector does not, then have the detector software
>>>> populate the other
>>>>> fields (e.g.
>>>>>> exposure time, integration time, maximum trusted pixel,
>>>> oscillation
>>>>>> start / end) to give a full description.
>>>>>>
>>>>>> Now, has anyone done something like this? If so, how do
>>>> you specify
>>>>>> the fields which are to be replaced? If not, does anyone have an
>>>>>> opinion on how this should be done?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Graeme
>>>>>>
>>>>>> Graeme Winter
>>>>>> Software and MX Support Scientist
>>>>>> Diamond Light Source
>>>>>>
>>>>>> +44 1235 778091 (work)
>>>>>> +44 7786 662784 (work mobile)
>>>>>>
>>>>>>
>>>>>>
>>>>>> This e-mail and any attachments may contain confidential,
>>>> copyright
>>>>>> and or privileged material, and are for the use of the intended
>>>>>> addressee only. If you are not the intended addressee or an
>>>>>> authorised
>>>>>
>>>>>> recipient of the addressee please notify us of receipt by
>>>> returning
>>>>>> the e-mail and do not use, copy, retain, distribute or
>>>> disclose the
>>>>>> information in or attached to the e-mail.
>>>>>>
>>>>>> Any opinions expressed within this e-mail are those of the
>>>> individual
>>>>>> and not necessarily of Diamond Light Source Ltd.
>>>>>>
>>>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>>>>> attachments are free from viruses and we cannot accept
>>>> liability for
>>>>>> any damage which you may sustain as a result of software viruses
>>>>>> which
>>>>>
>>>>>> may be transmitted in or with the message.
>>>>>>
>>>>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>>>>> England and Wales with its registered office at Diamond House,
>>>>>> Harwell
>>>>>
>>>>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11
>>>> 0DE, United
>>>>>> Kingdom
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> imgcif-l mailing list
>>>>>> imgcif-l at iucr.org
>>>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>>>
>>>>> _______________________________________________
>>>>> imgcif-l mailing list
>>>>> imgcif-l at iucr.org
>>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>> This e-mail and any attachments may contain confidential, copyright
>>>>> and or privileged material, and are for the use of the intended
>>>>> addressee only. If you are not the intended addressee or an
>>>> authorised
>>>>> recipient of the addressee please notify us of receipt by returning
>>>>> the e-mail and do not use, copy, retain, distribute or disclose the
>>>>> information in or attached to the e-mail.
>>>>> Any opinions expressed within this e-mail are those of the
>>>> individual
>>>>> and not necessarily of Diamond Light Source Ltd.
>>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>>>> attachments are free from viruses and we cannot accept
>>>> liability for
>>>>> any damage which you may sustain as a result of software
>>>> viruses which
>>>>> may be transmitted in or with the message.
>>>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>>>> England and Wales with its registered office at Diamond
>>>> House, Harwell
>>>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11
>>>> 0DE, United
>>>>> Kingdom
>>>>>
>>>>> _______________________________________________
>>>>> imgcif-l mailing list
>>>>> imgcif-l at iucr.org
>>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>
>>>> Harry
>>>> --
>>>> Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre,
>>>> Hills Road, Cambridge, CB2 0QH
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> imgcif-l mailing list
>>>> imgcif-l at iucr.org
>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>
>>> This e-mail and any attachments may contain confidential, copyright
>>> and or privileged material, and are for the use of the intended
>>> addressee only. If you are not the intended addressee or an
>>> authorised
>>
>>> recipient of the addressee please notify us of receipt by returning
>>> the e-mail and do not use, copy, retain, distribute or disclose the
>>> information in or attached to the e-mail.
>>> Any opinions expressed within this e-mail are those of the individual
>>> and not necessarily of Diamond Light Source Ltd.
>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>> attachments are free from viruses and we cannot accept liability for
>>> any damage which you may sustain as a result of software viruses
>>> which
>>
>>> may be transmitted in or with the message.
>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>> England and Wales with its registered office at Diamond House,
>>> Harwell
>>
>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
>>> Kingdom
>>>
>>> _______________________________________________
>>> imgcif-l mailing list
>>> imgcif-l at iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>
>> Harry
>> --
>> Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre,
>> Hills
>> Road, Cambridge, CB2 0QH
>>
>>
>>
>>
>> _______________________________________________
>> imgcif-l mailing list
>> imgcif-l at iucr.org
>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>> This e-mail and any attachments may contain confidential, copyright
>> and or privileged material, and are for the use of the intended
>> addressee only. If you are not the intended addressee or an
>> authorised recipient of the addressee please notify us of receipt
>> by returning the e-mail and do not use, copy, retain, distribute or
>> disclose the information in or attached to the e-mail.
>> Any opinions expressed within this e-mail are those of the
>> individual and not necessarily of Diamond Light Source Ltd.
>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>> attachments are free from viruses and we cannot accept liability
>> for any damage which you may sustain as a result of software
>> viruses which may be transmitted in or with the message.
>> Diamond Light Source Limited (company no. 4375679). Registered in
>> England and Wales with its registered office at Diamond House,
>> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11
>> 0DE, United Kingdom
>>
>> _______________________________________________
>> imgcif-l mailing list
>> imgcif-l at iucr.org
>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>
> Harry
> --
> Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills
> Road, Cambridge, CB2 0QH
>
>
>
>
> _______________________________________________
> imgcif-l mailing list
> imgcif-l at iucr.org
> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>
More information about the imgcif-l
mailing list