COMCIFS / MultiBlock_Dictionary

Definitions describing data stored in multiple containers
1 stars 3 forks source link

Add `AUDIT_CONFORM` category loops to the revelant files under `examples/` #11

Open vaitkus opened 3 months ago

vaitkus commented 3 months ago

CIF users are generally encouraged to explicitly specify the CIF dictionary that their CIF files conform two. The same approach should be used in the example CIF files provided in this repository.

The AUDIT_CONFORM loop could look something like this, although the dictionary location could be changed to point to a more stable resource :

loop_
_audit_conform.dict_name
_audit_conform.dict_version
_audit_conform.dict_location
MULTIBLOCK_DIC 1.1.0
https://raw.githubusercontent.com/COMCIFS/MultiBlock_Dictionary/main/multi_block_core.dic

Also, it is not yet completely clear if the AUDIT_CONFORM loop should be placed in all data blocks in a file or if it is sufficient to only place it in one of the files.

This suggestion was originally raised in a discussion thread of PR #6 (see https://github.com/COMCIFS/MultiBlock_Dictionary/pull/6/files#r1479649381).

jamesrhester commented 3 months ago

This does require a decision on how the AUDIT_CONFORM category behaves when blocks are combined. The choices I see are:

  1. We invent an identifier for an AUDIT_CONFORM domain to which every single data name can be associated. This would allow mixing data name conformance from different versions of the same dictionary at the cost of a new data name for every category
  2. We make AUDIT_CONFORM special, e.g. it applies to the data block it appears in and vanishes when blocks are merged
  3. We do nothing, in which case AUDIT_CONFORM appearing in one data block applies to all data blocks.

I strongly favour (3). Users are welcome (strongly encouraged, even) to put an AUDIT_CONFORM loop in every data block, but the contents must not contradict the AUDIT_CONFORM loops in other data blocks. That means the same version for each named dictionary, as _audit_conform.dict_name is the key data name. This seems like a reasonable base constraint.

vaitkus commented 3 months ago

I am also in favour of option (3). Handling and merging data blocks that conform to different versions of the same dictionaries does not seem feasible in practice. Should this additional constraint be formally written down somewhere, e.g. in the multiblock dictionary?

jamesrhester commented 3 months ago

Option (3) is the "no special behaviour" option, so I think the best place to describe how AUDIT_CONFORM works is in the examples and material in Volume G covering this dictionary, which would also advise putting it into all data blocks as good practice.

vaitkus commented 3 months ago

Understood. By "additional constraint" I mainly meant the requirement that the contents of the AUDIT_CONFORM loops are compatible between different blocks. This definitely means that there cannot be several dictionaries with the same name and differing parameters (e.g. different version numbers), but what about dictionaries, that override some data names? For example, could we have two blocks, one in conformance to CIF_CORE and one in conformance to PD_CIF, both of which contain the looped _refln.f_squared_meas data item (_refln.f_squared_meas is originally defined in CIF_CORE and then redefined in PD_CIF)?

jamesrhester commented 3 months ago

I intended only compatibility in the relational sense, as for any other loop.

Your question is, however, a fine one and I think opens up a whole can of worms that deserves its own discussion.