Use cases to consider for sample upload API

[katesmith280]

Non-exhaustive starting list to test against current proposed API draft:

• [ ] Standard single crystal rotational collection
• [ ] Unattended collection strategies
• [ ] Multi-orientation collections e.g. pre-defined chi,phi offsets
• [ ] Temperature (K) - room temperature vs. cryogenic conditions
• [ ] Anomalous scatterers - element identification is important for dose budget calculations and phasing pipelines
• [ ] Energy/energies for collection
• [ ] PDB models for molecular replacement
• [ ] Fragment screening - smiles
• [ ] Serial crystallography - separate mesh loops containing multiple crystals of the same protein
• [ ] Multi-sample holders (one sample multiple crystals) e.g. Diamond multi-crystal pin supports, Crystal Direct multi-crystals on loop
• [ ] Plates with multiple wells and drops
• [ ] Batch crystallisation for sample delivery - e.g. for extruder, levitation, tape drive or fixed target supports
• [ ] Comments section to outline details for non-standard experiment

@ejd53 @rhfogh - thank you for looking at these, if anyone can think of other use cases please add them to this thread.

[rhfogh]

Missing: temperature

Question: Do we want a temperature in K, or (also) choice of 'room' 'cryo'? Should this be for the Experiment of for the Dataset?

[rhfogh]

Acquisition modes; Single multi, unattended. Should be OK.

• We use the same objects for diffraction plans, instructions to the acquisition queue, and description of the acquired data. In all three cases we have a CrystallographicExperiment object containing one or more CollectionSweep objects.
• The CrystallographicExperiment contains experiment_strategy, a string that serves as an instruction to the beamline as to which experiment to set up (attended) or execute (unattended). The beamline will then know how to interpret the CollectionSweep records that are included.
• When you are passing messages to the acquisition queue they will be fully populated with all parameters, lists of scans that describe interleaving (if any), etc. etc. and should be executable directly. NB still missing: Schemas for mesh scans, characterisation images (if not a CollectionSweep), centring operations. This will take care multiple wavelengths, as well as interleaving and single/multi-sweep.
• At the diffraction plan stage you can either send a fully populated Experiment schema for direct execution, a partially populated schema where missing parameters are filled in by default, or a set of templates to be interpreted by a workflow or other strategy-executing program. For e.g. Global Phasing workflow you could have two CollectionSweep records, one with role 'Characterisation', and one with role 'Acquisition' or 'Result'. These would contain minimal input parameters, which the workflow would expand. Ultimately a single CollectionSweep record (or one per energy) would be expanded by the workflow into a (possibly interleaved) executable multi-sweep data collection.

[rhfogh]

Missing: Comments section for annotations.

We should probably add that, though it does give the risk that people will use it to add additional parameters that might better dealt with as extensions, either namespaced or at worst generic.

[rhfogh]

PDB model for molecular replacement

Ultimately these would be connected to a Processing job as reference_data. At the diffraction plan stage this could be done by adding also a processing plan with input parameters and instructions for processing, as well as the connected reference data. For that we would ned a Dataset record that described PDB models (TBD). This Dataset would contain attributes that described the location of the file. It is an open question how the file would be uploaded or presented to the synchrotron or whatever computer ran the processing - that seems to be an operational problem beyond the scope of MXLIMS.

[rhfogh]

Do we need a humidity attribute? If for the Dataset or the Experiment?

[rhfogh]

Missing: Anomalous scatterers and Fragment screening - smiles.

These would be dealt with in the Ligand class, which (as noted by Ed Daniel) "needs to be fleshed out by someone competent"

[rhfogh]

Sample types: Separate mesh loops, multi-sample holders, plates with multiple wells and drops, batch crystallisation.

In principle this can be dealt with, though some bits are still missing.

The core model allows for nested holders, with the preparation link to PreparedSample allowed at multiple levels. This could give a PreparedSample for each crystal in a multi-crystal holder, or for an entire grid (or shared between several grids). The detailed Sample shipping model only allows for the Sample link at the lowest (crystal) level, so this part of the model needs to be harmonised.

Further, there would have to be a specific schema made for the various SSX-specific holders, as the detailed modelling only covers MX so far.