Observable/Noise parameter naming

[FFroehlich]

Currently, noise and observable parameter placeholders require _${observableId} as suffix. This suffix appears to be redundant and superfluous to me, as they need to be specified in the measurements table and in the measurements table you can only specify the parameter for the same observable.

I can see how adding the suffix could make it more explicit that these variables are different across observables, but that should already by evident from the fact that they have to be specified in the measurements table. Neither the linter nor simulators appear to check for correctness anyways (see https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab)

[dweindl]

I think, the suffix was intended to reduce the chances of collision with already exiting parameters with a different purpose. (Not saying that it would be a good idea to name your parameters observableParameter1, ..., but you never know).

I am open to changing that, but I would prefer not just dropping the suffix, but instead, introducing a column placeholders (or similar), where one can specify the parameter Ids and the expected order for overriding via the measurements table. This way, one can use more descriptive parameter IDs.

Concrete example:

Current:

observableId	observableFormula	…
obs1	observableParameter1_obs1 * X + observableParameter2_obs1	…

Proposed:

observableId	observableFormula	observablePlaceholders	…
obs1	scale * X + offset	scale;offset	…

Neither the linter nor simulators appear to check for correctness anyways (see https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab)

I don't think so. It will not complain about the name as such, but it will not consider it as a placeholder. Whether that results in an error will depend on the rest of the petab files. (If not, please post an example/issue). (EDIT: Okay, I think you were referring to Benchmarking-Initiative/Benchmark-Models-PEtab#261)

[FFroehlich]

I think, the suffix was intended to reduce the chances of collision with already exiting parameters with a different purpose. (Not saying that it would be a good idea to name your parameters observableParameter1, ..., but you never know).

Well if it's only about collisions they could just universally be renamed to observableParameter1_placeholder.

[dweindl]

Well if it's only about collisions they could just universally be renamed to observableParameter1_placeholder.

In principle, yes. (Or even shorter, placeholder$n.)

However, the problem remains, that those IDs aren't very descriptive and that certain IDs have special meaning. If we change the way these placeholders are handled/specified, I'd prefer directly addressing these issues as well.

[FFroehlich]

Well if it's only about collisions they could just universally be renamed to observableParameter1_placeholder.

In principle, yes. (Or even shorter, placeholder$n.)

However, the problem remains, that those IDs aren't very descriptive and that certain IDs have special meaning. If we change the way these placeholders are handled/specified, I'd prefer directly addressing these issues as well.

Sounds reasonable. How about using non-PEtab IDs, i.e. placeholder1.scale and placeholder2.offset`? Avoids introducing an additional column and simplifies parsing.

[dweindl]

Sounds reasonable. How about using non-PEtab IDs, i.e. placeholder1.scale and placeholder2.offset`? Avoids introducing an additional column and simplifies parsing.

It would definitely be more descriptive.

However, I'm not so sure about the simpler parsing. I could imagine that not every symbolic engine will allow dots in their symbols. (Could use placeholder1(scale) instead. Not sure.) For parsing, the separate column would probably be the easiest. No reserved names, no changes in the current math expression grammar, ...

[dilpath]

Another suggestion is to allow arbitrary columns like scale and offset in the measurements table. These are treated as PEtab IDs and cannot appear anywhere else in the PEtab problem, except the observables table formulae.

Overall this is much nicer for the user and for tools I guess, but arbitrary columns are suboptimal.

Example of a single problem with two measurement tables, one per observable

Measurement table 1

observableId	time	measurement	scale
obs1	0	0	1
obs1	0	0	2
obs1	0	0	3
obs1	0	0	4

Measurement table 2

observableId	time	measurement	offset
obs2	0	0	1
obs2	0	0	2
obs2	0	0	3
obs2	0	0	4

Observable table

observableId	observableFormula	noiseFormula
obs1	scale * x1	1
obs2	x2 + offset	1

I split this into two measurement tables, since scale is empty for all obs2 measurements, and similarly offset and obs1. Otherwise the measurement table can get sparse/large.

[dilpath]

Another suggestion is to support labels in the observableParameters column, where the labels cannot be reused for other observables nor appear anywhere else in the PEtab problem.

Measurements table

observableId	time	measurement	observableParameters
obs1	0	0	scale=1
obs2	0	0	offset=4
obs3	0	0	scale_obs3=1;offset_obs3=2

Observables table

observableId	observableFormula	noiseFormula
obs1	scale * x1	1
obs2	x2 + offset	1
obs3	scale_obs3*x2 + offset_obs3	1

[dweindl]

Thanks for the suggestions. What would be important for me when we change the current measurement-specific parameters approach:

• It should be evident from the observables table which parameters are meant to be measurement-specific (i.e. overridable via the measurements table)
• It should be evident from the observables table which parameters are shared across observables. So I'd be careful with allowing some, e.g., parameter scaling that is used in several observableFormulas, but is in fact different for each. Not really a technical constraint, but I think it might be misleading.
  Somewhat related, if we don't require unique parameter names and have a something like {observableId=y, observableFormula=scaling * x, noiseFormula=scaling * y where scaling is a placeholder in both cases, then substituting the observable formula for the observable symbol in the noise formula would have potentially unexpected effects.
• We shouldn't have to change the math expression grammar
• Having well-defined column names that are relevant for the handling of the parameter estimation problem (now that we just got rid of the wide conditions table, I wouldn't want to introduce additional parameter-id-based columns in the measurements table.
• Ideally, we could avoid any use of reserved names (or as currently, even worse, context-specific reserved patterns)

Seeing directly from the measurement table which parameters are overridden would be nice and more robust, but is probably inconvenient to write. This would also be inconsistent with other cases, such as priorParameters, where we have lists of parameters. Either keyword parameters everywhere or nowhere, but that's probably a separate discussion.

[dilpath]

It should be evident from the observables table which parameters are meant to be measurement-specific (i.e. overridable via the measurements table)

I'm fine with this, but: it's not evident which parameters are experiment/condition-specific, so why care about measurement-specific parameters? To make life a bit easier for tools?

Apart from that I agree on all points.

So I would vote first for your observablePlaceholders column (perhaps rather observableParameterIds).

[dweindl]

it's not evident which parameters are experiment/condition-specific, so why care about measurement-specific parameters? To make life a bit easier for tools?

For me there is a slight difference: other parameters may be overridden in a condition-specific way, but those placeholders must be overridden for any measurements of the respective observable. (At least, that is how it used to be.) Therefore, I'd prefer seeing easily which ones have to be specified with the measurements.

[matthiaskoenig]

I definitely like the suggestion by @dweindl much better then what we have right now.

observableId	observableFormula	observablePlaceholders	…
obs1	scale * X + offset	scale;offset	…

[dweindl]

@FFroehlich @fbergmann @sebapersson : Do you have any thoughts on this? Keep it as it was in v1? Change? (How?)

[sebapersson]

I definitely like the suggestion by @dweindl much better then what we have right now.

I agree on this. This is something that should be straightforward to parse for an importer.

[dweindl]

Follow-up question: would the placeholder parameter IDs have to be globally unique or would the following be allowed (scale & offset used as placeholders in different observables)?

observableId	observableFormula	observablePlaceholders	…
obs1	scale * X + offset	scale;offset	…
obs2	scale * Y + offset	scale;offset	…

At first glance, it might be confusing that obs1 and obs2 seemingly use the same scale & offset parameters (which in fact are completely independent). However, this is pretty much the same thing as with experiment/period-specific changes. So I'd say this should be allowed and implementations will have to take care of handling their namespaces properly.