New data name _exptl_absorpt.special_details

[Herbert J. Bernstein]

Harmless to add it, a problem if you don't.  Sounds like a good idea to add
it.

On Mon, Aug 2, 2021 at 11:02 PM James H via coreDMG <coredmg at iucr.org>
wrote:

> Dear Core DMG,
>
> Antanas Vaitkus has discovered that _exptl_absorpt_special_details has
> never been defined in an official dictionary although it appears over 1000
> times in the Crystallographic Open Database. There is an obvious use case,
> as shown in a "SHELX for neutrons" tutorial that contains an example using
> this tag to record how absorption values for neutrons are calculated.
> Antanas' description of the issue can be read at
> https://github.com/COMCIFS/cif_core/issues/234 , and the slide show with
> example of use of this tag is at
> https://chemistry.harvard.edu/files/chemistry/files/tutorial_using_shelx_for_neutrons.pdf
>
> Note that the dictionary already defines a
> tag _exptl_absorpt_process_details, which is defined as
>
>     Description of the absorption correction process applied to the
>     measured intensities. A literature reference should be supplied
>     for psi-scan or multi-scan techniques.
>
> As Antanas notes, many of those 1000 files include values both for this
> data name as well as _exptl_absorpt_special_details, meaning that this is
> not a coding mistake.
>
> Please comment on whether or not you agree with this data name being added
> to the core dictionary. I believe the definition is self-evident, along the
> lines of "Information not covered by other data names in the exptl_absorpt
> category, for example, details of the calculation of the absorption
> correction factor mu". Please note that silence means that you consent to
> the data name being added!
>
> Of course, we would rather not be playing catch-up with definitions, as we
> are in this case, so I would encourage any of you who see a deficit in our
> suite of definitions to take the lead in discussing adding them to the
> dictionaries. I'd also note that commandeering a data name in the core CIF
> namespace in this way is undesirable, as it could lead to complete
> breakdown in our processes (such as they are) and lack of clarity on the
> meaning of data names in a given CIF file. Fortunately this seems to be an
> isolated case.
>
> thanks,
> James.
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> coreDMG mailing list
> coreDMG at iucr.org
> http://mailman.iucr.org/cgi-bin/mailman/listinfo/coredmg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iucr.org/pipermail/coredmg/attachments/20210803/699a6887/attachment.htm>