hunter-moseley
commented
1 year ago We should talk this out, but here are my suggestions after first reading these issues.
-
Do we limit protocols to 1 per entity for ISA submissions, or come up with something else? Suggestion: We could create a composed protocol to list one per entity, but that it refers to a list of protocols. Not exactly sure how this would work. It depends on how protocols are described.
-
Do we add analytical type protocols or keep that as part of the measurement? Suggestion: We can create the analytical protocols from measurement protocols. I think this is really about how to convert the measurement protocol into ISAtab format.
-
Is the simple 3 column assay good enough? Suggestion: Probably not. I think we would include sample prep protocols that create extracts (derivative samples) and then the analytical/measurement protocol that creates/measures the data. At least that more closely matches the original example.
ptth222
You may want to view this on GitHub since I have embedded tables and such. https://github.com/MoseleyBioinformaticsLab/MESSES/issues
I am going to start with a short description of how ISA assays work. I am going to work from the tab format because it is easier to understand, but the issues exist in the JSON version as well.
Here is an example ISA assay tab file:
The order of the columns matter. The very first column must be a Sample Name column, and there can be no other Sample Name columns. If you have multiple entities deriving from each other they are called "extracts" in an assay. You can see in this example it goes from a sample to an extract after the "protein extraction" protocol, and then to a labeled extract after the "ITRAQ labeling" protocol. They call the "Protocol REF" columns "process nodes", but there are also other process nodes. The "MS Assay Name", "Normalization Name", and "Data Transformation Name" columns are also process nodes, but there is a difference. Protocol process nodes have a protocol, but the other ones don't, the names underneath of them just name the process, not the protocol. It seems to me like they essentially make a distinction between actions done on physical entities and actions done on data. Actions done on physical entities have an associated protocol, but actions done on data don't. They don't expressly say that, but that's what it looks like based on the example. I also think it would be valid to change "MS Assay Name" to a "Protocol REF" and create a "MS Assay" protocol if someone wanted. That would be the only way to give a description of the "MS Assay" process.
An important thing to note about all of this is that each sample/extract can have only 1 process/protocol applied to it at a time. This is an issue because we allow "protocol.id" to be a list field for entities. I think we might have to enforce 1 protocol for entities for ISA conversions. This restriction isn't just for assays, it applies to study processes as well.
Also note that they actually show analysis type process steps where as we typically don't. It isn't required, but we may want to think about adding some "analytical" type protocols or something if people do want to specify it similarly to what ISA shows here.
One issue is deciding where in the sample/extract chain to create the assay. This example starts just before protein extraction, but we could make one as simple as 3 columns. For example:
This is simple to do and would just require looking at the measurement protocol, but if we wanted to start sooner we would have to go to the measurement entity and then just go back up the lineage to some point. Deciding where to stop could be difficult. Maybe just 1 hop up the lineage.
To summarize: