New data name _exptl_absorpt.special_details

[Brian McMahon]

Formal "aye" to accepting this data name, with an acknowledgement that
procedures for inviting/proposing/accepting new data names should be
revisited, formalised as necessary, and streamlined.

Brian

On 03/08/2021 04:02, James H via coreDMG 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 
> <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 
> <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