v2: Combining experiment and condition tables

Nobody has claimed this yet.

Problem: The current condition table only allows entry of the conditionId, targetId and targetValue. In v1, multiple targets could be specified for each condition. This allowed description of a whole experiment in one line, but the changes had to occur at time = 0.

v2 allows different conditions to occur at different times. This is an improvement as this reflects experimental protocols better. It also allows introduction of a 'forcing function' of sorts with stepwise changes in the parameters.

I propose that the change from wide condition tables to long condition tables obviates the need for the condition table and experiment tables should have the following columns:
experimentId, time, targetId, targetValue

Example:
v1 Alkan_SciSig2018 condition table (first two entries):
conditionId | Dox_level | Gem_level | SN38_level
model1_data1 | 0.0 | 0.0 | 0.0
model1_data2 | 0.0 | 0.0003 | 0.0

which would introduce two unneeded events or a new condition. Because the conditionId is used nowhere else besides the experiment table, you will be creating a bunch of conditionIds for minor benefits. I agree that the benefits would be greater if the condition table was still wide.

Start by reviewing the current v2 condition table and experiment table definitions described in the issue, then compare them with the proposed long experiment-table examples. Resolve whether conditionId can be removed and how timed target changes should be represented. Done means the schema decision is agreed and its implications for existing v2 data are documented.

Written by the indexing model from the issue text.

Description

Contributor guide

First steps

Research direction

Assessment