Initial draft proposal, version 0.0.1

Herewith a draft model proposal, to get things started.

• This first attempt aims for simplicity, a minimal number of classes, and uses only a tree structure without crosslinks. We may well need to make things more complex later in order to represent data accurately.

• The class and attribute names given here were chosen quickly and serve to illustrate the nature of the data. They shall surely need to be renamed once we start discussing the vocabulary.

• The model is made out of DataClasses and not objects, which means that there is no such thing as keys, links or object identity. DataClasses compare by value. Attributes are generally optional, so you can use half-empty objects e.g. to pass in partial data to override a default setup.

• The model is designed for an API / messages / input-output. How things are stored inside a LIMS, or how to deal with duplication between e.g. experiment input, experiment output, processing input, and processing output, is the problem of the LIMS. The same goes for how to store list attributes or more complex data structures.

• Messages consist of a DataSetGroup, which contain a number of DataSets. Every experiment and calculation job can have one input DataSetGroup (containing parameters) and one output DataSetGroup (containing results). The DataSetGroups and DataSets come in various types, and the types must be consistent (no EM input data for MX experiments, or mesh scan input for MX processing). DataSetGroups and DataSets are expected to match the ICAT DataCollection and Dataset classes.

• There is a slot for namespaced program-specific extension data; these can be given their own specification schema elsewhere.

• For simplicity I have assumed that we can use the same classes for both input and output, e.g. that the diffraction plan uses the same classes and attributes as the experiment description. That cuts down the number of attributes and classes, at the cost of having some attributes that cannot always be populated, e.g. result attributes in input data. The number of DataSets or the parameter values need not be the same for input and output. For e.g. a workflow-driven multi-sweep data collection you might have two input DataSets (not pointing at any actual data) that specify parameters for resp. characterisation and acquisition. The actual experiment may have rather more DataSets, including for centring and multiple sweeps, and may modify and override input parameter values as appropriate.

• The current draft contains only two DataSetGroups, MXExperiment and MXProcessing, and one DataSet, MXScan, plus abstract superclasses and utility classes. It is extremely rudimentary on processing and says nothing at all about sample shipment; other people can hopefully provide for these things. This will need a lot of expansion and additional modelling.

• One niggling detail: We shall need to agree a convention for which is the first and second axis for beam position (on the detector), beam shape etc. I gather that the new standard convention is the McSTAs convention.

The draft model is shown in this spreadsheet file, which contains all the classes and attributes, and includes some documentation Model_v0_0_1.xlsx

The draft is also shown (with all attributes and classes, but in less detail) in the UML diagram below.