Translation to DDLm fails strict COD checks

[jamesrhester]

See error messages generated when checking combined PD/imgCIF dictionary. See also COMCIFS/cif_pd#234.

Most errors are of the form

WARNING, incorrect type purpose -- data item is defined as having the 'key' type purpose while only 'SU' and 'Link' type purposes are allowed for data items that contain the '_name.linked_item_id' attribute in their definition.

WARNING, content type 'integer' should be accompanied by the '_units.code' attribute -- it is recommended to assign units of measurement to all data items with numeric content types.

Also, some non-unique data names.

[vaitkus]

@jamesrhester Indeed, issues reported by cif_ddlm_check deal more with the style and consistency of the dictionary rather than the formal DDLm requirements. Therefore, please let me know if some of them seem too strict or non-nonsensical.

I looked a bit into the non-unique name issue yesterday and its not a translation error per se. The issue arises since the same concepts/data names are defined in save frames that are called differently in imgCIF and coreCIF dictionaries even though the names/alias overlap. As a result, when the coreCIF dictionary is imported into imgCIF, the save frames get duplicated rather than overwritten. The simplest and most consistent approach would be to rename the save frames (either in coreCIF or imgCIF) to match their counterparts since doing the save frame renaming mid translation would be asking for trouble.

There is also another set of stricter formal checks run by the ddlm_validate script which there not yer triggered in the repository checks due to cif_ddlm_check checks failing. I could run these check locally, summarise the issues and report them in the corresponding repositories if that would be useful. Which ddlm imgCIF should be viewed as the authoritative one:

1. https://github.com/yayahjb/cbf_imgcif_dictionary
2. https://github.com/COMCIFS/imgCIF
3. https://github.com/dials/cbflib/tree/main/doc

Or somewhere else?

[jamesrhester]

The ddlm dictionary in 1. is the most recent/authoritative. I can adjust the save frame names that are written to avoid those problems.

[rowlesmr]

Is it worth updating 2 with 1? I can do a PR. Probably need to wait until the update of ddl_to_ddl.

[vaitkus]

@rowlesmr I think that the two dictionaries were also generated with slightly different commands as the one (1) does not contain the coreCIF import statements while the one in (2) does.

[vaitkus]

@jamesrhester Ok, so I ran the formal validation checks and found some additional irregularities, some in the conversion, some in the dictionaries. See the following issues:

• Definitions translated from DDL2 to DDLm are missing the mandatory _definition.update #2
• Definitions translated from DDL2 to DDLm may contain invalid _name.object_id attribute values #3
• Incorrect content type conversion between DDL2 and DDLm #4
• DDL2 to DDLm conversion results in invalid _alias.dictionary_uri attribute values #5
• DDL2 to DDLm conversion results in invalid version numbers #6
• DDL2 to DDLm conversion may result in invalid ranges #7
• https://github.com/yayahjb/cbf_imgcif_dictionary/issues/4
• https://github.com/yayahjb/cbf_imgcif_dictionary/issues/5
• https://github.com/yayahjb/cbf_imgcif_dictionary/issues/6
• ddl.dic: are empty enumeration ranges allowed? COMCIFS/cif_core#538
• ddl.dic: add missing measurement units from the imgCIF dictionary COMCIFS/cif_core#539

Also the dictionary is missing an URL and DOI, but these can probably be ignored (we do ignore the missing DOI in the PR checks).