Add `_atom_site_fract_symmform`, `_atom_site_aniso_symmform` and other symmform data items

[vaitkus]

It seems that were are several data items which were agreed upon by the magCIF commission, but were never properly added to any of the official IUCr dictionaries. Citing an email exchange with @brantonc:

In my 2016 magCIF documentation, I see that our commission planned for _atom_site_fract_symmform and _atom_site_aniso_symmform to be established in parallel with _atom_site_moment.symmform and _atom_site_rotation.symmform. The plan at that time was to ask the coreCIF and modulatedCIF dictionaries to include them. It appears we forgot to do that.

@brantonc also sent a doc file which further details a possible set of parallel entries for the missing non-magnetic symmforms and even provides some formal DDLm definitions (see symmform-summary.docx).

It would be nice to add these items since they are already used by some pieces of software (i.e. ISOTROPY Software Suite) and consequently appear in the COD (i.e. see entry 1568391).

Should these data items be suggested for addition to the appropriate dictionaries (coreCIF, modulatedCIF) as originally planed or would it be better to add them directly to the current version of the magCIF dictionary given that it already imports coreCIF and modulatedCIF dictionaries in full and could thus add these items to the desired categories (i.e. ATOM_SITE)? In other words, is it expected that the_atom_site_fract_symmform data item will be used in scenarios which do not involve the magCIF dictionary?

@jamesrhester, do you have any opinion on this?

[jamesrhester]

My first concern is that these datanames define values that have internal structure that is equally-well expressed using a CIF2 list. We should not be accepting data names that define their own little mini-syntax that duplicates something our own syntax provides.

An auxilliary concern is that information is embedded inside the more complex values e.g. 2*Dxp2. Normally we discourage embedding information, but I see this as equivalent to e.g. the Hall space group symbols, which economically describe a complete space group in a single symbol, so that concern is not substantial.

As to where they belong, the dictionary in which the parent category is defined is the best place. So only the atom_site_moment.*_symmform ones belong in the magnetic dictionary.

We should probably define a special symmform type in the same way as we have a symop type to save space. All of the examples seem to conform to a uniform specification, except the aniso ones, which introduce the 11,22,33 etc values following the A.

[vaitkus]

@james wrote:

My first concern is that these datanames define values that have internal structure that is equally-well expressed using a CIF2 list. We should not be accepting data names that define their own little mini-syntax that duplicates something our own syntax provides.

Since _atom_site_moment.symmform is already defined in this dictionary and _atom_site_fract_symmform (and potentially other items) already appear in the wild, we are somewhat stuck with the current semantics of these items. We could, however, also add another set of items which would record the same information in a list form.

An auxilliary concern is that information is embedded inside the more complex values e.g. 2*Dxp2. Normally we discourage embedding information, but I see this as equivalent to e.g. the Hall space group symbols, which economically describe a complete space group in a single symbol, so that concern is not substantial.

As to where they belong, the dictionary in which the parent category is defined is the best place. So only the atom_site_moment.*_symmform ones belong in the magnetic dictionary.

Ok, I raised a PR in the CIF_CORE dictionary repo for the addition of the _atom_site_*_symmform items (https://github.com/COMCIFS/cif_core/pull/473). I will prepare a similar one for theModulated Structures dictionary in the future, currently the validation of that dictionary produces a bit too much noise. :)

We should probably define a special symmform type in the same way as we have a symop type to save space. All of the examples seem to conform to a uniform specification, except the aniso ones, which introduce the 11,22,33 etc values following the A.

I think that we can try this is parallel, i.e. add/develop the definitions in one PR and the symmform type in a different PR. Alternatively, we might move common definitions to the templ_attr.cif file and import them from there. A single description that properly details all of the provided symmform types might be a bit too complex even if we leave out the ANISO items.