Naming conventions for EDA data

[dominikbach]

Describe your problem in detail.

It is currently proposed for EDA data to make the following channel names mandatory: EDA_tonic, EDA_phasic, EDA_total.

There are two problems with that:

1. EDA is a catch-all for various data types (skin conductance, skin resistance, skin susceptance, skin admittance) that come in different units. It would be better to clearly specify what one is measuring. The most common data type is skin conductance, which could be abbreviated "SC" or "SCR" (for skin conductance response). See for background Tronstad et al. 2022 or Boucsein et al. 2013

2. "_phasic" and "_tonic" components are never raw, they are filtered versions of the raw data (sometimes computed in the recording software). In contrast, "_total" is the raw signal, and should not have the qualifier "_total".

Describe what you expected.

No response

BIDS specification section

https://bids-specification.readthedocs.io/en/latest/...

[m-miedema]

Thank you for opening this issue, @dominikbach ! We had discussed these options for EDA somewhat in the past (for context you can see our previous issue #4 if you are curious, although a lot of discussion took place during our BEP meetings and is not fully reflected there). I'll try to summarize:

1. We are aware of some of the differences in terminology for types of EDA, but without direct experience with any other than skin conductance in our working group, had thought that using a catch-all 'EDA' value for MeasureType made our BEP more accessible to the general user. We RECOMMEND naming columns as desired to reflect particularities of a signal, e.g. EDA_phasic, EDA_tonic, EDA_SCL, EDA_SCR, extending to things like PPG_SPO2 or PPG_L, PPG_R.

2. I believe the above point addresses your concerns about phasic or tonic, although we believe it is necessary to imagine a use case where these filtered versions of EDA signals are included as 'raw' data. This is because a BIDS derivatives dataset is data that derives from an existing BIDS dataset, rather than necessarily data that derives from raw data. Thus, since it is common to calculate these kinds of data at scan time (another example is heart rate), we wish to allow users the possibility to treat these data within our BEP.

Please share your thoughts with us, your feedback is very helpful!

[dominikbach]

I understand the argument that splitting EDA into different physical measurement methods might be too fine-grained, and users can add a suffix ("EDA_SCR").

However, in light of this, the phasic/tonic/total suffix seems a bit confusing/contradictory.

It is NOT standard in the field to record tonic and phasic responses separately, so we can assume that 90% of users will just record one EDA channel.

However, table 2.3 does not list "EDA" as a potential MeasureType, only "EDA-total". It's not clear to me whether this is actually mandatory, but at least it looks like it is recommended. The "-total" suffix does not exist for any other physio modality, though, which is contradictory.