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

Re: Variants

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@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@dowling.edu
> =====================================================
> 
> 
>
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs

Reply to: [list | sender only]