Variants
Herbert J. Bernstein
yaya at bernstein-plus-sons.com
Thu Nov 26 17:21:18 GMT 2009
Dear David,
With all due respect, I must differ. We now have two half-way
measures related to variants for the core dictionary relating to
wavelengths. The problem you raised in considering the change
for wavelengths is real, and as you recognized from Nicks partial
implementation, use of variants truly addresses the issue. This
would be a good time to solve it completely, while be have people
paying at least some slight attention to gaps in the logic of CIF.
Certainly, it would also be nice if people really came to grips
with the lexical issues of CIF strings as well, but let us not
compound one mistake (walking away from the string issues) with
another (walking away from the variant issues). The fact that
we cannot get a consensus to solve one problem, which is
actually somwwhat removed from crystallogrpahic concerns, should
not mean that we have no hope of getting a consensus on solving
a more important issue that impacts important scientific issues
in doing and reporting crystallographic experiments.
Let me answer your third point first: Are variants allowed in
imgCIF as well as in CBF. Certainly. However, we seem to marching
rapidly back to the unfortunely situation in 1996-1997, when there
were religious reasons why imgCIF was then called imgNCIF (not for
not) because the thinks we need to do to actually collect data
seemd to violate some of the formalities to which one must bow
to rightfully call a dataset a CIF. So, I suspect, in deference
to those formalities I will have to call the ascii versions of
a CIF2 style CBF (which certainly will continue to allow
variants) something other than CIF until we can arrange another
face-to-face peace conference the way we did to change from imgNCIF
to imgCIF. It is sad to see this same thing happening again, but
until we get everybody together in the ame room to make peace, I
don't see an alternative.
On your dREL interaction issue -- actually it is a much broader and
fundamental issue having to do with row selection from tables
for the application of functions. It is easily solved by adding
some SQL-like selection functions, which accept values for a key
and a table name and return the appropriate row.
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 Thu, 26 Nov 2009, David Brown wrote:
> 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> 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
> =====================================================
>
> 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
> =====================================================
>
>
>
> _______________________________________________
> comcifs mailing list
> 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
>
>
>
>
>
More information about the comcifs
mailing list