Add the `_cheminfo_components_stdinchi` property

[vaitkus]

During the OPTIMADE 2025 workshop it was agreed that we should have not only the _cheminfo_stdinchi property that describes the whole compound/entire crystal, but also a separate properly that contains the list of individual components that make up the entire crystal.

The following points were agreed upon:

• The property should be called something similar to _cheminfo_components_stdinchi.
• A component is described as a set of chemically bonded atoms. In a SMILES string, such components would be separated using the '.' symbol.
• All components in the list must be distinct. That is, each compound appears in the list only once regardless of the stoichiometry observed in the compound.
• There could be another OPTIONAL property called something like _cheminfo_components_inchi_ratio which records the stoichiometry. This field should be defined as a non-negative ratio, that is, non-integer ratios are explicitly allowed (e.g. to more easily support hemihydrates, etc.).

[a-e-day]

Could I clarify - is this intended to capture e.g. cocrystals where there are more than one molecule in a crystal cell and how this would work in practice? So if I have a database with e.g. a caffeine + paracetamol cocrystal e.g. I would not populate _cheminfo_stdinchi but instead populate _cheminfo_components_stdinchi
with ["InChI=1S/C8H10N4O2/c1-10-4-9-6-5(10)7(13)12(3)8(14)11(6)2/h4H,1-3H3", "InChI=1S/C8H9NO2/c1-6(10)9-7-2-4-8(11)5-3-7/h2-5,11H,1H3,(H,9,10)"? And if someone was doing a query for the caffeine standard inchi they would need to search both fields? I'm just wondering if it is worth making _cheminfo_stdinchi and the other molecule identifier fields into arrays in the first place (which just have one item for pure compound crystals)? Then you just populate and search on one field which seems a bit simpler...

[vaitkus]

@a-e-day

Could I clarify - is this intended to capture e.g. cocrystals where there are more than one molecule in a crystal cell and how this would work in practice? So if I have a database with e.g. a caffeine + paracetamol cocrystal e.g. I would not populate _cheminfo_stdinchi but instead populate _cheminfo_components_stdinchi with ["InChI=1S/C8H10N4O2/c1-10-4-9-6-5(10)7(13)12(3)8(14)11(6)2/h4H,1-3H3", "InChI=1S/C8H9NO2/c1-6(10)9-7-2-4-8(11)5-3-7/h2-5,11H,1H3,(H,9,10)"?

That is a valid point. In this case you could populate both fields (and we probably would): the _cheminfo_stdinchi would contain both molecular entities while _cheminfo_components_stdinchi would contain two components. The benefit of this, that that user can search both for individual components and specific salts/cocrystals/etc. by using InChI as simple text strings (running text matching).

And if someone was doing a query for the caffeine standard inchi they would need to search both fields?

As is currently imagined, a database would populate either both or one of these fields fully, depending on their capabilities.

I'm just wondering if it is worth making _cheminfo_stdinchi and the other molecule identifier fields into arrays in the first place (which just have one item for pure compound crystals)? Then you just populate and search on one field which seems a bit simpler...

I think that the reasoning for having both fields (the text one and the array one) is to enable a direct text match of crystals that contain several different molecular entities.

Does that make sense?

[a-e-day]

yes thanks for the clarification...