Discussion List Archives

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

Re: New data name _exptl_absorpt.special_details

Formal "aye" to accepting this data name, with an acknowledgement thatprocedures for inviting/proposing/accepting new data names should berevisited, formalised as necessary, and streamlined.
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 listcoreDMG@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/coredmg

[Send comment to list secretary]
[Reply to list (subscribers only)]