feature request: have a attribute (Characteristics[] or Measurement[]) on Assay Name

[proccaserra]

• request made during the BH2022
• using 'Measurement[]"
• pattern could look like this:

Assay Name	Measurement[plant height]	Unit	Measurement[mean leaf area]	Unit	Raw Data File
observation1	10	cm	0.03	sqm	null

Measurement[] could be used in lieu of 'Raw Data File' but could also be used to provide a summary value over numerical values found in a data file.

Assay Name	Raw Data File	Measurement[median power]	Unit
observation1	https://www.example.org/datafile_1	25	mW

[ptth222]

This doesn't make sense to me. "Assay Name" is essentially just the "name" field for a process. Something like "plant height" should already be a "characteristic" of a source, sample, or otherMaterial. It wouldn't make sense to associate the measurement of an individual entity with a whole process.

Having summary values for data in a file might be reasonable, but that could also just be in the file itself. It's a fine line when trying to determine what should be in the file and what should be in the specification. Simply outsourcing all the details of measurements and data to separate files with their own formats and structures is reasonable. Going a route similar to what the Metabolomics Workbench did is also reasonable, where they have a whole measurements section.

[proccaserra]

@ptth222 , for additional context, the request came from the following needs:

• [ ] to provide the result of assays with a single response variable (ie non-massively parallel assays) where using an 'Data File' to store 1 record was deemed unpractical, using "Measurement[]. The issue becomes formally defining the threshold for switchiing from "Measurement" to "Data File". If number of Measurement fields > 2, move values to Data File
• [ ] to allow annotations to be associated to 'Data File' other than by relying on ISA Comment[ ] , which are akin to name-value-types entries. In that instance, ISA.Characteristics[] would be the preferred option to specify file attributes such as 'format', 'checksum type', 'checksum',

you are right about the distinction between "Process Name" (e.g. "Assay Name") and "Data File". The true Nodes are "Data File" which should bear the 'ISA.Characteristic' annotation. But if deciding to add 'Measurement []', that would be an output of the Process. So these are 2 distinct cases/requirements, each with its consequences on the stack.

Implementing 'Characteristics' on Data Files would be more straightforward (famous last words...)

[ptth222]

We have the same first need. There is an assay that measures the protein content of a sample, but it only has milligrams of protein as an output. I was handling this by simply adding that as a characteristic to the sample and leaving the protocol output empty.

The measurement might be a result or output of a process, but I would argue that not all measurements make sense to associate with the process, or at least only the process. In the example here with "plant height" that really needs to be associated with the specific plant. If there is only 1 entity as input then that measurement could be inferred to be associated with that entity, but it's not a direct link like a characteristic.

The way we did it in MESSES was to have a "measurement" table and that has pointers to entities and protocols so you know which entity it is associated with and which protocol created the measurement. This makes it so you don't have to choose between putting the measurement on the process or the entity.

'Characteristics' on Data Files does seem more straightforward and readily useful. It shouldn't be too difficult to change the internals to support that either since the machinery for handling characteristics is already there, but it is a lot to run down since there are different validators and converters and such to consider that a change like this would have to propagate through.