Variants

David Brown idbrown at mcmaster.ca
Thu Nov 26 16:52:51 GMT 2009


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:

          _diffrn_radiation_wavelength_variant

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.

David

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:                         
>     
>
>                  _diffrn_radiation_wavelength_nominal,
>
> 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
>
>         _diffrn_radiation_wavelength_determination 
>
> 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:
>
>          loop_
>              _diffrn_radiation_wavelength_id
>              _diffrn_radiation_wavelength
>              _diffrn_radiation_wavelength_determinaton
>                 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.
>
> data_diffrn_radiation_wavelength_determination
>   _name                      '_diffrn_radiation_wavelength_determination'
>   _category                    diffrn_radiation_wavelength
>   _type                        char
>   _list                        both
>   _list_reference            '_diffrn_radiation_wavelength_id'
>  loop_
>    _enumeration
>    _enumeration_detail
>   'fundamental'           
>        'Wavelength that is a fundamental property of matter e.g. 
> MoK\alpha'
>   'estimated'               
>        'Estimated from secondary information e.g. monochromator angle 
> or time of flight'
>   'refined'                 
>        'Based on refinement using a standard material with known cell 
> parameters'
>
>
>   _definition
> ;              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 at bernstein-plus-sons.com <mailto:yaya at 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
>
>                     +1-631-244-3035
>                     yaya at dowling.edu <mailto:yaya at dowling.edu>
>     =====================================================
>
>     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
>
>          _diffrn_radiation_wavelength_determination
>
>         you would add
>
>          _diffrn_radiation_wavelength_variant
>
>         and a new variant category
>
>                _variant_variant
>                _variant_role
>                _variant_timestamp
>                _variant_variant_of
>                _variant_details
>
>         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:
>
>                _variant_variant
>
>                      The value of _variant_variant must uniquely identify
>                      each variant for the given diffraction experiment
>         and/or
>                      entry
>
>                _variant_role
>
>                      The value of _variant_role  specifies a role
>                      for this variant.  Possible roles are null,
>         "preferred",
>                      "raw data", and "unsuccessful trial".
>
>                _variant_timestamp
>
>                      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.
>
>                _variant_variant_of
>
>                      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.
>
>                _variant_details
>
>                      A description of special aspects of the variant
>
>
>              An example of how this might be used is:
>
>                      loop_
>                          _diffrn_radiation_wavelength_id
>                          _diffrn_radiation_wavelength
>                          _diffrn_radiation_wavelength_determinaton
>                             1   1.23456   fundamental
>                             2   1.25      estimated
>
>
>
>         would become
>
>                  loop_
>                      _diffrn_radiation_wavelength_variant
>                      _diffrn_radiation_wavelength
>                         final   1.23456
>                         pelim   1.25
>                  loop_
>                      _variant_variant
>                      _variant_role
>                      _variant_timestamp
>                      _variant_variant_of
>                      _variant_details
>                      final preferred 2007-08-04T01:17:28 prelim refined
>                      prelim .        2007-08-03T23:20:00 . .
>
>                  loop_
>                     _cell_variant
>                     _cell_length_a
>                     _cell_length_b
>                     _cell_length_c
>                     _cell_angle_alpha
>                     _cell_angle_beta
>                     _cell_angle_gamma
>                     final  22.5 22.5 22.5 90. 90. 90.
>                     prelim 22.3 22.3 22.3 90. 90. 90.
>
>
>          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 <mailto:yaya at dowling.edu>
>         =====================================================
>
>
>
>     _______________________________________________
>     comcifs mailing list
>     comcifs at iucr.org <mailto:comcifs at iucr.org>
>     http://scripts.iucr.org/mailman/listinfo/comcifs
>
>
>
>
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>comcifs mailing list
>comcifs at iucr.org
>http://scripts.iucr.org/mailman/listinfo/comcifs
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://scripts.iucr.org/pipermail/comcifs/attachments/20091126/ccb0d357/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idbrown.vcf
Type: text/x-vcard
Size: 298 bytes
Desc: not available
Url : http://scripts.iucr.org/pipermail/comcifs/attachments/20091126/ccb0d357/attachment-0001.vcf 


More information about the comcifs mailing list