Discuss BEP021 derivatives for electrophys

[robertoostenveld]

This continues the issue started here https://github.com/bids-standard/bids-specification/issues/733. This BEP021 is a better place to continue the discussion, as we can also use projects and share files here which would not fit under bids-specification directly.

[smakeig]

@SaraStephenson https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SaraStephenson&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=86RU_LLZNnz0ZLS5ZIsPZWQQtmp4t-SUcTJCWGYmRHU&e=, I think we'll try moving away from "annotations" - perhaps recording-marks_amica.tsv.gz could work?

Sara - What is it you propose to label 'marks' ? To me, this term would most naturally suggest individual time markers (event onset markers, etc). -Scott

On Tue, May 10, 2022 at 10:26 AM Jessica Callegaro @.***> wrote:

Hi BEP021 community, I'm looking to move forward on a few points from @SaraStephenson https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SaraStephenson&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=86RU_LLZNnz0ZLS5ZIsPZWQQtmp4t-SUcTJCWGYmRHU&e= 's thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bids-2Dstandard_bep021_issues_5-23issuecomment-2D1075728495&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=TPEL-pdsH6UQdCQVoXYg4Mu9rAlvuXubuSbMB4NVTQs&e= above:

The formatting of our current annotations.tsv files (that contains component, channel, and binary time annotations in one file) are based on a combination of Examples 2 and 3 in Section 5.1: Sidecar TSV Document in the BEP 021 google doc https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1PmcVs7vg7Th-2DcGC-2DUrX8rAhKUHIzOI-2DuIOh69-5Fmvdlw_edit-23heading-3Dh.begtazq5lz86&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=yNfbQQApcRO4KOrkh0XOQ38gfV1yWAG-TJzCwwGyndw&e= .

[...] To store them in separate files, a few questions/concerns pop up: a. This creates a large number of annotation files - multiplied by pipeline (EEG-IP-L) and QC outputs (desc-qc). b. Naming all these files - Currently we find it Very useful to use desc-qc to indicate the annotations are associated with QC'ed data, but would this be possible with the convention of desc-chan, desc-comp and desc-task?

@robertoostenveld https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_robertoostenveld&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=uTzusaRQTvzNN514zBR8G-ZQ07BZHg8GflQ3Uh-BOUc&e= What are your thoughts on this? Should this be revisited?

We'd like to avoid unnecessary complexities in file naming, and Sara's example https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_BUCANL_bids-2Dexamples_tree_bep021-5Fephys-5Fderivatives_eeg-5Fface13_derivatives_BIDS-2DLossless-2DEEG&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=5mmHPsq7n_mmoXVsW-fupmP1k_W0z8Fk8ptSbfMn8Xg&e= follows examples 2 and 3 of BEP021 5.1: Sidecar TSV https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1PmcVs7vg7Th-2DcGC-2DUrX8rAhKUHIzOI-2DuIOh69-5Fmvdlw_edit-23heading-3Dh.begtazq5lz86&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=yNfbQQApcRO4KOrkh0XOQ38gfV1yWAG-TJzCwwGyndw&e= .

...

Second,

I wonder if it would be productive to call what you refer to as 'continuous time annotations' as, rather, 'continuous time data measures' -

@smakeig https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smakeig&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=bEVYdqVmyVWAfe_3Azow8ZTPaPDPbtgYKErZUw_CRnk&e= thank you -- calling them "measures" rather than annotations can address this nicely, and works with @robertoostenveld https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_robertoostenveld&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=uTzusaRQTvzNN514zBR8G-ZQ07BZHg8GflQ3Uh-BOUc&e= and @CPernet https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CPernet&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=zsD4GmuKI0rlbZ8WURxsV5C45cjNupS8pdhCND9sxVg&e='s prior comments on storing in TSV files as continuous recordings. see spec here https://urldefense.proofpoint.com/v2/url?u=https-3A__bids-2Dspecification.readthedocs.io_en_stable_04-2Dmodality-2Dspecific-2Dfiles_06-2Dphysiological-2Dand-2Dother-2Dcontinuous-2Drecordings.html&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=QL_roe4OTgoAVQF19bO-AMFQOHa5ZH4okQrxI8GrB40&e= in previous comments.

@SaraStephenson https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SaraStephenson&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=86RU_LLZNnz0ZLS5ZIsPZWQQtmp4t-SUcTJCWGYmRHU&e=, I think we'll try moving away from "annotations" - perhaps recording-marks_amica.tsv.gz could work?

— Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bids-2Dstandard_bep021_issues_5-23issuecomment-2D1122470176&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=zGS3O1_-XaCePqQeMOHJgQ5emdfsGErcoLbrmCkTnXQ&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKN2SFQWUTHCCON4ROTSI6LVJJWY7ANCNFSM4XUNFFSA&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP912y1yQ0q05CJ14uAvMNdNQ&m=B0p-o128i25Ju_i50YAxnA9QpGJt_qRFdoRVsVkT6piETXz2z95aHIaiobZG9UgD&s=-t3gwbgynbiXxcWKUCWF-JU96BZGtYL6ehHSJ00gsZc&e= . You are receiving this because you were mentioned.Message ID: @.***>

-- Scott Makeig, Research Scientist and Director, Swartz Center for Computational Neuroscience, Institute for Neural Computation, University of California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott

[jesscall]

Hi all!

@robertoostenveld @CPernet @arnodelorme I'm hoping to move the discussion forward for EEGNet for the first point in this comment. We'd appreciate your thoughts on avoiding file splitting to this extent.

Thanks!

CC @SaraStephenson @christinerogers

PS: @smakeig we're happy to workshop the naming of those TSV files - you're right that marks still suggests an individual time marker.

[arnodelorme]

It is unclear to me how the annotation file differs from the event.tsv file.

[CPernet]

Have you tried @robertoostenveld proposal for the continuous measurement/annotation?

[jesscall]

Have you tried @robertoostenveld proposal for the continuous measurement/annotation?

@CPernet Yes, @SaraStephenson has already committed the suggested changes here.

Can we go ahead and make the necessary adjustments to the BEP021 spec to reflect this suggestion? This paragraph in section 5.1 of the doc still proposes the alternative method of creating a synthetic data channel. Perhaps it can be updated with information on storing continuous recordings as described here?

[robertoostenveld]

It is unclear to me how the annotation file differs from the event.tsv file.

I don't think they technically differ (except for the name), but conceptually I see it like this

• events is for the observable things that happened during acquisition independent of the EEG data (like stimuli, button presses) and that could also have happened and be observed if the EEG were not recorded at all
• annotations is for things that are observed specifically in the EEG data and hence requires (re)viewing the data

For many things this works, although I realize that there are some situations where it might not be clear. But as long as it covers 80% of the use-cases, I think it is useful. No need to get 99.99% coverage.

[jesscall]

Hi all,

I made a suggestion in the BEP021 document in order to reflect the discussion in this thread (RE: continuous annotations / data measures). The suggestion is based on feedback from @CPernet and @robertoostenveld.

Please have a look and let me know if further amendments are needed.

[smakeig]

Robert and all -

In HED-3G we have made a deliberate choice to include 'data feature' events as a primary event type (along with 'sensory presentation', 'agent action', etc.). The SCORE library schema for neurophysiologist annotation of events in clinical data annotates data feature events noted in events.tsv.

As I understand it (correctly?) the EEGNet project proposed use of 'annotation.tsv' files is to apply flags to each EEG frame - therefore out of the event framework - which requires that an 'event' is something that unfolds over a definite time period in the experiment.

Events are marked in events.tsv by 'event onset markers' - plus possibly other 'event phase markers' -- foremost, 'event offset markers', but also possibly markers of other critical points in the event process, for example 'max volume', 'motion course correction','seizure process shift', etc.

I would not support the term 'annotations' for the proposed purpose of flagging, e.g., data frames for rejection, etc. A more specific term should be used - for example 'data_flags.tsv' or other ...

Scott

On Thu, Jun 2, 2022 at 12:18 PM Robert Oostenveld @.***> wrote:

It is unclear to me how the annotation file differs from the event.tsv file.

I don't think they technically differ (except for the name), but conceptually I see it like this

• events is for the observable things that happened during acquisition independent of the EEG data (like stimuli, button presses) and that could also have happened and be observed if the EEG were not recorded at all
• annotations is for things that are observed specifically in the EEG data and hence requires (re)viewing the data

For many things this works, although I realize that there are some situations where it might not be clear. But as long as it covers 80% of the use-cases, I think it is useful. No need to get 99.99% coverage.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/bids-standard/bep021/issues/5*issuecomment-1145225333__;Iw!!Mih3wA!GlxM8tl6qtOmomxPCAriXw-Nqrxbw5kDjmKLK4okV9rtldg4AnZa9B4bZXoVFUEHl6kIFdj2E_P6ebJOP-8BBIsY$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKN2SFXYOMSQQI3PDKG5KD3VNECH7ANCNFSM4XUNFFSA__;!!Mih3wA!GlxM8tl6qtOmomxPCAriXw-Nqrxbw5kDjmKLK4okV9rtldg4AnZa9B4bZXoVFUEHl6kIFdj2E_P6ebJOP0qpMMVZ$ . You are receiving this because you were mentioned.Message ID: @.***>

-- Scott Makeig, Research Scientist and Director, Swartz Center for Computational Neuroscience, Institute for Neural Computation, University of California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott

[Andesha]

Hello community!

It's been awhile since I have been involved in these discussions, but I am once again contributing to some BIDS EEG efforts on behalf of EEGNet.

I've taken some time to read over this thread and want to state here as part of my post what I believe to be the current understanding of annotations so that I can update Face13 (and its various example repositories) as necessary once again.

If there's anything wrong with my broad statements of the current efforts, please let me know and hopefully it can restart some discussion here.

• @robertoostenveld's definition here of events being acquisition time versus annotations being specific data properties after recording is what sets the two apart.
• The AMICA log likelihood is the only "continuous annotation" being put forward by Face13, and isn't used for segmentation, and rarely for decision making during review. As such, it is being handled similar to eye tracking data and kept an external zipped tsv.
  • Open to discussion from others if the names of these files need any review.
• Annotations are currently (in Face13) being kept all in one file so as to not overpopulate the derivative folders. In the case of the Lossless Pipeline, a dozen or more could be created. I believe having one larger file as opposed to numerous small ones benefits the standard best.
• @smakeig raised the point of if these are just additional "flags", why are we using the term "annotations". I have personally inherited the term from working with @jadesjardins. If what has previously been discussed as "continuous annotations" become standardized to be stored much like eye tracking data, I feel like this may be a positive change to broaden understanding of what their use is at a first glance.
  • Changing this may require broader community discussion, the name may have stuck in some places...

I'll be coordinating offline with @SaraStephenson and @jadesjardins as necessary for changes to Face13, so no worries. I think I own a few of the commits too...

CCing @jesscall and @christinerogers as well.

Thanks!

[CPernet]

we can raise those points at OHBM2022

• @jesscall please make the suggestion on the google doc
• @.all I think annotations as in continuous annotation via tsv.gz works great
• any other 'events' that work with HED should be marked that way not creating new data type

[christinerogers]

Some updates to move forward - First, our team (thanks @jesscall) added a suggestion to the BEP021 spec here - Thanks for integrating or responding.

Second, to get unstuck on annotation nomenclature, @sappelhoff could you confirm / advise on best BIDS practice /other specs? (We've looked at cardio but would appreciate more eyes on this, as previously discussed.)

• Non-continuous annotations could be renamed flags per @smakeig's suggestion (above)
• Continuous annotations could be retained as "annotations"

Thanks - and cc Tyler @andesha Collins, @SaraStephenson

@CPernet to your last bullet above - I can shoot you the latest on events/HED creation next week.

[smakeig]

Christine - Before studying the attachment (it's bedtime...), I don't agree with appropriating the term 'annotation' for such a specialized part of HED/BIDS annotation per se. Flags or markers can easily be understood as pointing to single time points on the exp timeline. But continuous measures for each time point, however derived from the data, are derived data channels - here might be called 'indicator channels' as they hold statistical indicators of data quality or etc.

Scott

On Fri, Jul 15, 2022 at 5:28 PM christinerogers @.***> wrote:

Some updates to move forward - First, our team (thanks @jesscall https://urldefense.com/v3/__https://github.com/jesscall__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_aUui5Gs$) added a suggestion to the BEP021 spec here https://urldefense.com/v3/__https://docs.google.com/document/d/1PmcVs7vg7Th-cGC-UrX8rAhKUHIzOI-uIOh69_mvdlw/edit*bookmark=id.q79okdqnpbzn__;Iw!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_dZ_OuUz$

• Thanks for integrating or responding.

Second, to get unstuck on annotation nomenclature, @sappelhoff https://urldefense.com/v3/__https://github.com/sappelhoff__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_dtzePh3$ could you confirm / advise on best BIDS practice /other specs? (We've looked at cardio but would appreciate more eyes on this, as previously discussed.)

• Non-continuous annotations could be renamed flags per @smakeig https://urldefense.com/v3/__https://github.com/smakeig__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_R_h-wT9$'s suggestion (above)
• Continuous annotations could be retained as "annotations"

Thanks - and cc Tyler @Andesha https://urldefense.com/v3/__https://github.com/Andesha__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_Vjqe1s7$ Collins, @SaraStephenson https://urldefense.com/v3/__https://github.com/SaraStephenson__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_Y9opfSH$

@CPernet https://urldefense.com/v3/__https://github.com/CPernet__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_cP-QIUi$ to your last bullet above https://urldefense.com/v3/__https://github.com/bids-standard/bep021/issues/5*issuecomment-1159719385__;Iw!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_XTJjGQO$

• I can shoot you the latest on events/HED creation next week.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/bids-standard/bep021/issues/5*issuecomment-1185957558__;Iw!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_VPV9sCM$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKN2SFUTFQ2XWLEXSBKVIODVUHJW3ANCNFSM4XUNFFSA__;!!Mih3wA!GXzzl9XjjG0DcSqGtfcmGftp0yM91FbGnwOo0EVSOHvfigM3emC5sWGh6vqAoJKz6KdO79FFRazN7aXZ_cjBop03$ . You are receiving this because you were mentioned.Message ID: @.***>

-- Scott Makeig, Research Scientist and Director, Swartz Center for Computational Neuroscience, Institute for Neural Computation, University of California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott

[dorahermes]

Another important point for discussion here is that it will be necessary to have a recommendation for how to indicate a list in a .tsv file, here for the channels. This is not specified in BIDS now. Similar point raised in BEP021 spec

Would there be any issue with a simple comma separated list? (e.g. O1, Oz, O2)

[CPernet]

'Would there be any issue with a simple comma separated list?' just that BIDS has stuck with tsv :-;
now that I am back in a country that uses commas in numbers I appreciate tsv more ...

[sappelhoff]

Can somebody briefly summarize what the issue is with the two terms "annotations" versus "flags", please? From my perspective, we are talking about data and event annotations.

---

Re: "continuous annotations", I would (as many others already have) advise to follow the specification on physio and stim data. That entails:

• data is saved in a .tsv.gz file without headers
• headers and additional metadata are desribed in an accompanying .json file
• different kinds of continuous annotations may be distinguished via entities such as recording
• This last point leads me to the "problem": the terminology ("physio" and "stim" suffixes, "recording" entity) is not very much in line with annotations. We may consider:
  • adding a new suffix to "physio"+"stim", which however would follow the same rules
  • just reusing "physio" or "stim" for our purposes at the expense of the term being confusing
  • same deliberations go for the "recording" entity

---

Alternative: Not sure if Scott proposed this above, but we could also specify that continuous annotations must be formatted as a data channel and included in the (derivative) neural data file (BrainVision, EDF, ...). In that case all we might have to do is to come up with a good way of how to specify such "channel types" (e.g., see table in this section)

I find this alternative very attractive, because it makes the "name finding" issue easier (see "problem" / 3 "considerations" above)

---

Re: specifying which particular "channels" a given event pertains to --> there is a discussion thread in the Gdoc draft: https://docs.google.com/document/d/1PmcVs7vg7Th-cGC-UrX8rAhKUHIzOI-uIOh69_mvdlw/edit?disco=AAAAc8E_W-g

Incorporating comments in that thread, my suggestion is to:

• have two columns: "channels" and "electrodes", because events may pertain to either channels or electrodes
• all events that happen may pertain to either:
  • a channel in the data and/or
  • an electrode used in the recording (part of the metadata / data)
  • neither
• For example if an event pertains to a bipolar channel "C3-F3", then that channel must be included in the data
• the format of specifying channels and electrodes in their respective TSV columns is "pythonic", that is, we have a list of comma-separated, double-quoted strings, see the example below. I formulate it with "channels" in mind, but suggest the same principles for electrodes:

# two channels are affected
["Cz", "Fpz"]

# no channel is affected 
[]

# the notion of channel is not applicable for this data point
"n/a"

# all channels are affects
"all"

# a channel with the name "all" is affected
["all"]

# a channel that contains double quotes in its name is affected
# note the backslash as escape character
["my_weird\"channel_name", "FCz", "C3"]

# channel names MUST NOT contain "tab characters"
# this would break the TSV format / make it uncomfortable

:point_up: depending on the event to be annotated, the above format may be used to indicate channels and/or electrodes in their respective columns

---

Finally, re: non-continuous annotations --> I am fine with both: including them in the standard *_events.tsv or a separate *_desc-annotations_events.tsv. I think it'd be a good idea to not invent a new datatype / suffix for this (we may already need to do that for continuous annotations, see above)

[Andesha]

Thanks for the input @sappelhoff - I'm going to respond in order to your sections...

For my lab, "annotations" vs "flags" is mostly just terminology. We used annotations as a term to encompass all post processed derivative data properties like bridged channels (computationally discovered), rejected ICs, or ICA breakdown quality. Flags to me implies things that are just boolean. I believe on this point we're simply just discussing phrasing.

I believe at this point we can lock in the idea of the continuous annotations being in the external files. There appears to be significant agreement. I would however suggest the adding of a new term as it will likely age better in the long term and may help inform inform the process.

As above, we are likely past packaging things into the data as either "status" channels or other. I'm fine with the external personally.

I am in favour of the idea of adding this information of channel/electrode as an optional column. It would allow our process to fairly easily encode whatever "annotation" (or your chosen term) fairly simply, as long as there's no notion of a "simplest form" requirement. I'm not sure, but how would you envision this extending to ICs @sappelhoff ?

Lastly, I agree. Inventing a new datatype/suffix is not strictly needed.

Some extra thoughts as I was responding:

How does this relate to the provenance (lifecycle?) of a file within BIDS. Does it work naturally or is there things we should be considering from BEP028? Consider the case of a pipeline doing processing, going back and marking up events, adding reaction time info, marking study things, etc... thoughts @christinerogers ?

Thanks!

[smakeig]

It is best not to try to give a more generally applied term in widespread/longstanding use ('annotation') in a quite more limited meaning in the same application (e.g., BIDS). The continuous measures you introduce in LP are in a broader sense like any other continuous data measure (say, RMS, likelihood of x, etc.). I suggest the term in BIDS should be chosen to apply equally to all these that users may want to include in the dataset in an external file. Perhaps 'derived data'?

Scott

On Mon, Aug 8, 2022 at 11:08 AM Tyler Collins @.***> wrote:

Thanks for the input @sappelhoff https://urldefense.com/v3/__https://github.com/sappelhoff__;!!Mih3wA!CXjZZ_eofzmLug6NdUwXhUi0ggwEDEYc1NYVItTR7esBTOzvVGZbcx13Bi8RyWR5iTv2tNzaEbwCrTGPUGEz9MQI$

• I'm going to respond in order to your sections...

For my lab, "annotations" vs "flags" is mostly just terminology. We used annotations as a term to encompass all post processed derivative data properties like bridged channels (computationally discovered), rejected ICs, or ICA breakdown quality. Flags to me implies things that are just boolean. I believe on this point we're simply just discussing phrasing.

I believe at this point we can lock in the idea of the continuous annotations being in the external files. There appears to be significant agreement. I would however suggest the adding of a new term as it will likely age better in the long term and may help inform inform the process.

As above, we are likely past packaging things into the data as either "status" channels or other. I'm fine with the external personally.

I am in favour of the idea of adding this information of channel/electrode as an optional column. It would allow our process to fairly easily encode whatever "annotation" (or your chosen term) fairly simply, as long as there's no notion of a "simplest form" requirement. I'm not sure, but how would you envision this extending to ICs @sappelhoff https://urldefense.com/v3/__https://github.com/sappelhoff__;!!Mih3wA!CXjZZ_eofzmLug6NdUwXhUi0ggwEDEYc1NYVItTR7esBTOzvVGZbcx13Bi8RyWR5iTv2tNzaEbwCrTGPUGEz9MQI$ ?

Lastly, I agree. Inventing a new datatype/suffix is not strictly needed.

Some extra thoughts as I was responding:

How does this relate to the provenance (lifecycle?) of a file within BIDS. Does it work naturally or is there things we should be considering from BEP028? Consider the case of a pipeline doing processing, going back and marking up events, adding reaction time info, marking study things, etc... thoughts @christinerogers https://urldefense.com/v3/__https://github.com/christinerogers__;!!Mih3wA!CXjZZ_eofzmLug6NdUwXhUi0ggwEDEYc1NYVItTR7esBTOzvVGZbcx13Bi8RyWR5iTv2tNzaEbwCrTGPUNceXHV5$ ?

Thanks!

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/bids-standard/bep021/issues/5*issuecomment-1208252806__;Iw!!Mih3wA!CXjZZ_eofzmLug6NdUwXhUi0ggwEDEYc1NYVItTR7esBTOzvVGZbcx13Bi8RyWR5iTv2tNzaEbwCrTGPUOfRmH-2$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKN2SFWGSSNZW72UBXVSI3TVYEPF5ANCNFSM4XUNFFSA__;!!Mih3wA!CXjZZ_eofzmLug6NdUwXhUi0ggwEDEYc1NYVItTR7esBTOzvVGZbcx13Bi8RyWR5iTv2tNzaEbwCrTGPUKz1AVxO$ . You are receiving this because you were mentioned.Message ID: @.***>

-- Scott Makeig, Research Scientist and Director, Swartz Center for Computational Neuroscience, Institute for Neural Computation, University of California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott