Re: New data name _exptl_absorpt.special_details

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
_______________________________________________
coreDMG mailing list
coreDMG@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/coredmg