Object structure examples

It could be useful looking at some examples of how the data might be organised and stored. We would not have to follow this hierarchy for our format - the Pydantic classes we end up with could be merged from some of the classes in these diagrams - but it does support a discussion of what kinds of data belong where, and what kind of distinctions we might want to make. Also this might be more relevant for data storage than for a LIMS interface.

There is a pretty obvious mapping between the objects in these diagrams and ICAT classes. For example:

• MXExperimentRun : Job
• MXExperiment : DataCollection
• MXScan, XRayCentring : DataSet
• MeshScan, LineScan, RotationData : DataFile

Some points to note

Diagram 1 - MX experiment

• The Run has only one Diffraction plan and one MXExperiment, to hold respectively input and output that apply to the Run as a whole. Parameters from the DiffractionPlan do not necessarily match the same values in the Experiment. E.g. the predicted and observed (from characterisation) space_group differ. At the DataSet level you need a 'role' attribute, that tells you how the DataSet plugs into the Experiment or calculation. This is not something you can put in the DataCollection of DataFile level.
• The same MXScan class can be used both for the DiffractionPlan and the experiment result.
• We should note that the DataFile level does not necessarily correspond to an actual file. Images might be in individual files, or multiple scans might be combined in a single HDF5 file.

Diagram 2 MX Processing

• This diagram is less well thought through than the Experiment diagram, but should at least give a starting point for thought.
• MXProcessingtInfile does not in general match MXProcessignOutfile. Unlike for experiments, the input level consists of independent data rather than just specifrications for how to generate the output.
• An important point is that the ProcessingInput points to the RotationData class but not directly to the MXScan class. The same RotationData could be used for multiple processings, and we need the MXProcessingInfile or something equivalent to store the role attribute and any other parameters specific to a specific data file in the context of a specific processing. In a LIMS it could be done by linking the objects. In the API we might have to copy the RotationData parameters into each new message, and possibly copy MXScan parameters into the MXProcessingInfile if they are needed for the processing.