Discussion List Archives

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

Re: Variants

The idea of including variants is fascinating, but the implications for CIF are fearsome and we need to tread carefully.  At the very least this is not the time to launch into something of this size, particularly when we can't even decide what a reverse solicus means.  I have a couple of observations to make to put the issue into focus.

1. The proposal I made is for the coreCIF DDL1 dictionary and I would have to be convinced that we can easily graft 'variants' into DDL1.  This would require giving the implications of introducting variants a great deal more thought and my proposal would no longer be fast-track.  The wavelength items are already looped in the DDL1 version of coreCIF, since powder patterns often have to deal with the prsence of multiple wavelengths.  Since there is no dREL in DDL1, it is up to the application to decide what to do if more than one wavelength is given.

2. If we want to introduce variants, CIF2 would be the place to do so.  With dREL, CIF2 has a more dynamic structure which better allows for a CIF to evolve as a structure is determined.  CIF1.1 was conceived as a static representation of the results of a crystallographic experiment.

3. If variants are being introduced into CBF, are they also allowed in imgCIF?  This would need to come before COMCIFS for approval, but if it is approved by COMCIFS it would automatically become part of the DDL2 protocol and so presumably could be merged into other DDL2 dictionaries.

4. However, its spread can be limited because it can only be used if items such as:


are defined in the dictionary.  Thus if Herbert wants to introduce this into imgCIF, it can easily be confined to that dictionary, until such time as COMCIFS is ready to define the necessary datanames to implement it in other parts of the system.

5. Variants have important implications for dREL which currently has no mechanism for selecting which value of
_diffrn_radiation_wavelength to use.  There are other aspects of dREL that still need to be clarified, such as are multiple definitions of the same item allowed and if so which will be executed.  Let's not get into that until we know what "\" means.

The implications of variants are many and interesting, but they repesent a change in the philosphy of CIF.  I am not against variants, the idea is quite exciting, but we need to give careful thought about where we see CIF going over the next decades.  Is a CIF a fixed archive, a place where we entomb a fact of nature, or is it an evolving document that carries it own history along with it?  Now is not the time to get distracted by such far reaching discussions, we just need to keep the options open.


James Hester wrote:
I include David's original message below for reference.

(from David Brown)
Dear Colleagues,

Last September I circulated for fast track approvel a recommendation for adding a new item:                         


to the core dictionary (see below for details).  The intent was that this could be used for giving a nominal wavelength calculated e.g., from the paparmeters of a diffractometer.  It was proposed tht this might be needed for completeness even though it was not accurate enough for calculating  lattice parameters, etc.  This proposal was passed by the core CIR dictionary maintenance group by default (no one raised any objection).  When this proposal was subsequently presented for final approval to COMCIFS, Nick Spadaccini suggested a more elegant alternative, namely that by adding instead the item


we could loop the nomiinal wavelength with the  refined (and any other interesting) wavelengths.  This would be more informative and allow for future expansion.

An example of how this might be used is:

                1   1.23456   fundamental
                2   1.25      estimated

According to our rules, this proposal is being posted for comment to the coreCIF dictionary maintenance group for the next six weeks.  At the end of this time, if there are no unresolved issues, the core dictionary maintenance group will be deemed to have accepted the proposal.

David Brown


The proposal is to add the following item to the coreCIF dictionary:

2009-09-25 Proposal from the Nick Spadaccini on the COMCIFS dicsussion list to replace a withdrawn proposal.

  _name                      '_diffrn_radiation_wavelength_determination'
  _category                    diffrn_radiation_wavelength
  _type                        char
  _list                        both
  _list_reference            '_diffrn_radiation_wavelength_id'
       'Wavelength that is a fundamental property of matter e.g. MoK\alpha'

       'Estimated from secondary information e.g. monochromator angle or time of flight'

       'Based on refinement using a standard material with known cell parameters'

;              The method of determination of incident wavelength. Further information may be provided in _diffrn_radiation_special_details

On Thu, Nov 26, 2009 at 1:14 PM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote:
You removed David's original message from mine.  Please add that to
the thread as well.

 Herbert J. Bernstein, Professor of Computer Science
  Dowling College, Kramer Science Center, KSC 121
       Idle Hour Blvd, Oakdale, NY, 11769


On Thu, 26 Nov 2009, James Hester wrote:

I'm reposting Herbert's message in a new thread to aid organisation. 
Herbert wrote:

Dear Colleagues,

 While you are revisiting this item, I would suggest you consider the more
complete (and, I believe, more elegant and general) solution of defining
"variants", that we have introduced into the imgCIF dictionary to handled
quantities that may be determined in different ways.

 Instead of adding


you would add


and a new variant category


which would allow you with complete generality to manage any number
a refined or redefined quantities, such as wavelengths.  This would
then allow you to us the same variant identifier, for, say cell
dimensions, which could be expected to change in a coupled manner
with the changes in wavelength.

 If you are interested in this more complete approach, I can provide
you with the full item definitions, but the short form is:


             The value of _variant_variant must uniquely identify
             each variant for the given diffraction experiment and/or


             The value of _variant_role  specifies a role
             for this variant.  Possible roles are null, "preferred",
             "raw data", and "unsuccessful trial".


             The date and time identifying a variant.  This is not
             necessarily the precise time of the measurement or
             calculation of the individual related data items, but a
timestamp that
             reflects the order in which the variants were defined.


             The value of _variant.variant_of gives the variant
             from which this variant was derived.  If this value is not
             given, the variant is assumed to be derived from the default
             null variant.


             A description of special aspects of the variant

     An example of how this might be used is:

                    1   1.23456   fundamental
                    2   1.25      estimated

would become

                final   1.23456
                pelim   1.25
             final preferred 2007-08-04T01:17:28 prelim refined
             prelim .        2007-08-03T23:20:00 . .

            final  22.5 22.5 22.5 90. 90. 90.
            prelim 22.3 22.3 22.3 90. 90. 90.


 Herbert J. Bernstein, Professor of Computer Science
  Dowling College, Kramer Science Center, KSC 121
       Idle Hour Blvd, Oakdale, NY, 11769


comcifs mailing list

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

_______________________________________________ comcifs mailing list comcifs@iucr.org http://scripts.iucr.org/mailman/listinfo/comcifs

fn:I.David Brown
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773

Reply to: [list | sender only]