Redefine some of the key items as Related

[vaitkus]

The Key items in question are definitely not Derived or Recorded.

The _type.source attribute for such Key items is usually either Assigned or Related. The Assigned source seems to dominate, especially in other dictionaries, however, I would argue that Related should be used instead. Specifically, the definition of Related in the DDLm reference dictionary states:

This state indicates that the item was used to record the SU value of a related measurand item or that the item was used in the construction of looped lists of data. In the latter case, it typically identifies an item whose unique values are used as the reference key for a loop category and/or an item which has values in common with those of another loop category and is considered a Link between these lists.

The Assigned source could technically also work, but I would say it represents a more deliberate choice than the assignment of arbitrary identifier values:

Data value (numerical or otherwise) was assigned as part of the data collection, analysis or modelling required for a specific domain instance.

These assignments often represent a decision made that determines the course of the experiment (and therefore the data item may be deemed primitive) or a particular choice in the way the data was analysed (and therefore the data item may be considered non-primitive).

[rowlesmr]

I have a confusion; not about your changes, but about the existence of the data names.

All of those data names have a purpose Key, but only _database_related.id is an actual category key.

Why do they exist if not to act as a category key?

[vaitkus]

I think that (most of) these data names are leftovers from an approach used in DDLm versions prior to 4.0.0 that had two attributes for specifying keys. The now removed _category.key_id attribute was used to specify a single artificial key item whereas the _category_key.name was used to specify a collection of data names that could serve as a natural key. Data items referenced in _category.key_id sometimes even contained dREL snippets that constructed a unique value based on the values of data items from _category_key.name (thus it making sense to describe those items as Derived).

Nowadays these data items seem like rudimentary leftovers that may still be referenced in some dREL code. They could be updated to proper category keys instead of the natural keys (e.g. _geom_angle.id instead of the six items that refer to atoms and symmetry operations), however, we would then lose information on what collection of items should be considered a natural category key.