Refactoring the SampleAssayPlan to a graph structure

[Zigur]

The SampleAssayGraph is embedded in a graph

• ProductNode
• ProtocolNode

A ProductNode can only be chained to a ProtocolNode
A ProtocolNode can also be chained to one or more other ProductNode

This must be serialized to JSON

[Zigur]

To generate a SampleAndAssayPlan from a minimal configuration we need:

• A JSON structure that defines the template nodes and the links among them (something along the lines of https://github.com/ISA-tools/ISAdatasets/blob/tests/json/create/matabolite-profiling-ms.json)
• A dictionary that for each ProductNode specifies a list of triples (product_type, product_size, is_product_input_to_next_protocols=True). the triples could be stored either as tuples or dictionaries.
• A dictionary for each ProtocolNode where for each `ProtocolParameter' we specify the values that are going to be used (e.g. the different types of instruments and the different acquisition or injection modes for MS)

[Zigur]

More thorough specifications on the basis of the draft document, as redacted by Philippe.

I will represent the SampleAndAssay plan as an OrderedDict that we can call for now sample_and_assay_plan_dict where each key represents either a ProcessNode or a ProductNode.

For a ProductNode we are to provide the following information. This can be provided as a nested dictionary or as a tuple, to be determined soon (I guess a dict is a better option:

• product_type: this is to be a string or a isatools.model.Characteristic specifying the type of product (e.g. 'organism_part'/'liver', or 'extract_type'/'RNA' or 'extract_type'/'polar fraction' and so on
• product_size: the number of outputs of that PrductNode for each input ProcessNode
• technical_replicates: if it makes sense having them
• is_product_input_to_next_protocol: a boolean: True if yes, False if not

For a ProcessNode we will provide the following information in a dictionary:

• params: a dictionary of parameters. They keys will be the ParameterName while the values (one or more than one) are the ParameterValues that will be used. A cartesian product of all the possible combinations of parameter values will be computed when creating the full plan and the full isatools.model.Investigation object. We will need somehow configuration files containing the possible ParameterValues for each ParameterName that is somehow standardized
  Just as an example from the document above, possible parameter keys are:

1. 'instrument' (values: 'Illumina Genome Analyzer', 'Illumina HiSeq 4000', ...) and 'library layout' (values: 'single', 'paired') for transcription profiling,
2. 'instrument' (values: 'Agilent QTOF §', 'Shimadzu xyz', ...), 'injection mode' (values: 'FIA', 'LC', 'GC'), 'acquisition_mode' (values: 'positive', 'negative', 'positive/negative') and 'derivatization' (values: 'oxymation', 'acetylation', etc..., optional only if GC=True) for (GC)MS profiling. Checks on parameters can only be done if a validation_template is provided (more of this later)

• technical_replicates: an int. If not provided it defaults to 1.

More details and a full dictionary/JSON example to follow

The full graph of the Sample and assay plan will be produced from a dedicated metod that will take the sample_and_assay_plan_dict discussed above and an optional validation_template, a JSON or dict that specifies the rules for the current workflow. The signature of the method will then be:

• generate_sample_and_assay_graph(sample_and_assay_plan_dict, validation_template=None)

Then from the SampleAndAssayGraph object we can create the full ISA study + assays

[Zigur]

The work on the SampleAndAssayPlans has been completed. The following work on the StudyDesign will be tracked using issues