---
tags: BIDS
---
# BEP020 Meetings and discussion notes

::: info

## Important links

- [Render of the BEP, section of physio recordings](https://bids-specification--1128.org.readthedocs.build/en/1128/modality-specific-files/physiological-recordings.html)
- [BEP020 PR](https://github.com/bids-standard/bids-specification/pull/1128)
- [BIDS-Examples PR](https://github.com/bids-standard/bids-examples/pull/514)
- [Companion paper draft](https://docs.google.com/document/d/1SRxyt3Yc92m8lBSlgX-bLIYeIE8VYhtL/edit?usp=sharing&ouid=117694035315596007623&rtpof=true&sd=true)
- [Converter repo](https://github.com/bids-standard/eye2bids)

:::

::: warning

## Home stretch TODO

- [X] [Mutating metadata in `events.json`](https://github.com/bids-standard/bids-specification/pull/1128/files#r1916696816) <- original conversation disappeared (??)
- Schema [conversation](https://github.com/bids-standard/bids-validator/issues/143)
- [Resolution `bids-standard/bids-specification@abe6036`](https://github.com/bids-standard/bids-specification/commit/abe6036d364b53fca313d750f4234dc71e805762)
- PENDING: Implement the new association in the BIDS-Validator.
- [x] Remove [HTML blocks](https://github.com/bids-standard/bids-specification/pull/1128/files#r1567924284)
- [x] -> OE [moved `bids-standard/bids-specification#1781` forward](https://github.com/bids-standard/bids-specification/pull/1781) so HTML blocks can be replaced when that PR is merged.
- [x] [Potential conflict `SampleCoordinatesUnits`](https://github.com/bids-standard/bids-specification/pull/1128/files#r1712953676)
-> OE will take care
- [x] [`onset` column of `physioevents` should allow definition of units other than the default (s)](https://github.com/bids-standard/bids-specification/pull/1128/files#r1693909512)
- [x] [Potentially missing example](https://github.com/bids-standard/bids-specification/pull/1128/files#r1700397120)
- [x] [Make `SampleCoordinateSystem` an enum](https://github.com/bids-standard/bids-specification/pull/1128#discussion_r1873318839)?
- [x] [`CalibrationPosition` assumption](https://github.com/bids-standard/bids-specification/pull/1128/files#r1657184218)
- [x] Revise the `CalibrationUnits` & `CalibrationPosition` definition: looks like having the columns require units this metadata should not be present anymore.
- [x] description of [AverageCalibrationError](https://bids-specification--1128.org.readthedocs.build/en/1128/glossary.html#objects.metadata.AverageCalibrationError) needs to be changed; left over from the time when we didn't split two eyes in two separate files.
- [x] MS will draft an email for the BIDS maintainer to mention the idea of inviting the community to the manuscript and the soon PR of the BEP
- [x] updates converter May 9th 2025:
- [x] updates example datasets:
- [x] https://github.com/julia-pfarr/natImSac_BIDSexample
- [x] doi:10.18112/openneuro.ds004158.v2.0.6
- [x] there are some character issues in the physioevents.json example on the spec-website
- [x] we discussed previously that EnvironmentCoordinates should be moved from `physio.json` to the `events.json` but on the rendered spec it is still in the example for `physio.json`

:::

:::info
## Opening PR for review

- [x] Validator and Examples PR must be solved.
- [ ] Open a BIDS discussion to announce the review and to collect new comments outside the currently messy PR. Example: https://github.com/bids-standard/bids-specification/discussions/1846
- [ ] Email to BIDS mailing list with request to review PR. [Join mailing list](https://groups.google.com/g/bids-discussion). This is an example email from the BIDS email list:

Subject: [BEP042] EMG-BIDS Call for Comments, Please review by April, 30th 2025

Dear BIDS Community,

The EMG-BIDS Extension Proposal (BEP042) provides a standardized framework for organizing and describing electromyography (EMG) data, including high-density EMG recordings, within the BIDS format. This BEP addresses the need for consistent representation of EMG data to enhance reproducibility and data sharing.

Key features of the proposal include:

Standardized directory structure for EMG data organization
Comprehensive metadata schema for EMG acquisition parameters
Support for both conventional and high-density EMG recordings
Specifications for sensor/electrode positions and channel information
Integration with existing BIDS modalities and annotations
The full proposal is available for review at:

Pull Request: https://github.com/bids-standard/bids-specification/pull/1998
HTML Preview: https://bids-specification--1998.org.readthedocs.build/en/1998/modality-specific-files/electromyography.html
Example Implementation: https://github.com/bids-standard/bids-examples/pull/480 (The examples are work in progress and may not be updated to the latest changes in the specifications)
We welcome feedback from the community in any of the following ways:

Comment directly on the GitHub pull request (or the corresponding issue)
Email the moderators ([e-mail])
Respond to this thread
Your input is crucial in ensuring that this specification meets the needs of researchers working with EMG data across various disciplines.

:::
## Meeting tba

**Julia:**
- updates converter done:
- delete SampleCoordinateUnits from eyelink_metadata.yml
- insert Units for x-/y-coordinate in eyelink_metadata.yml as required metadata; user needs to enter them manually because I can only read it from eyelink-asc if there was a validation and not everyone does validation
- delete function to read calibration positions from asc, since these are not the actual calibration positions and user should enter them manually
- insert CalibrationPosition in eyelink_metadata.yml as recommended metadata for the user to enter manually
- check confirmed: all messages including extra calibrations are saved in physioevents.tsv
- update metadata descriptions in physio.json
- update README, because it is mandatory to pass a metadata.yml file
- updates example datasets done
- there are some character issues in the physioevents.json example on the spec-website
- we discussed previously that EnvironmentCoordinates should be moved from `physio.json` to the `events.json` but on the rendered spec it is still in the example for `physio.json`

## Meeting 2025/05/01

- [CalibrationPosition issue](https://github.com/bids-standard/eye2bids/issues/120)
- can someone explain to me what I need to do regarding SampleCoordinateSystem for the converter? How it is right now:
- SampleCoordinateSystem is in the metadata yaml file as required metadata to fill manually by the user
- "Units" for x/y coordinates is not yet integrated as being updated but will always be "a.u" after conversion run

## Meeting 2025/04/03

- [CalibrationPosition issue](https://github.com/bids-standard/eye2bids/issues/120) --> Julia and Oscar will meet next week
- [SampleCoordinateSystem issue](https://github.com/bids-standard/eye2bids/issues/119):
- will it still exist as required or recommended metadata?
- "x/y-coordinate needs to have an entry for „Units“ (=required)" means the SampleCoordinateUnits, right? --> right, only for x/y coordinate not for pupil size
- Email for inviting the community to the manuscript: BIDS maintainers are ok with it
- Chris suggested to open a fresh PR before opening PR to community review because there are a lot of discussion in the current PR already --> Julia will ask Chris what exactly he meant by that and if we should just open a new one or what
- verify examples PR (using the new schema) and Schema pr if needed; these should be passing the validator
- MS/JP/SH discussed about CalibrationPosition issue, we postoned to next meeting that we try to arrange for Thursday 11th April

## Meeting 2025/03/13

- MS/OE/JP discussed the possibility to send soon an email to the BIDS community to invite them to read our paper about the BEP and get ready to discuss its aspect when the Push Request will become public
- JP mention a list (see above) of things missing in the converter and with the example dataset that are missing.
- OE presented the latest change he made to allow the requiredness of visual screen settings when eye tracking data is available as as well as change in the template of the html rendered file.
- MS mention the fact that he would like to make the change done before going to Vision Science Society in order to establish discussion with vendors and with future users.
- Next meeting is planned to 2025/04/03

## Meeting 2025/02/13

MS made a mistake on the github header and put that the meeting was on the 14th while it was actually on thursday 13 as we agreed, only Martin and Julia was present.

**TODO**

MS should change the html render to point towards the latest openneuro dataaset (https://openneuro.org/datasets/ds004158/versions/2.0.5)
MS should put the BIDS example in html file when it get pushed
JP will write to OE to see what's going on with the validator (file naming issue)

- JP still needs to take care of this for Converter:
- everything is merged and up-to-date, except [this](https://github.com/bids-standard/eye2bids/issues/69)
- SampleCoordinateSystem will be deleted as required metadata. For this, the description of x/y-coordinate needs to have an entry for „Units“ (=required) --> delete SampleCoordinateSystem from metadata in converter as well as in example datasets and make units required in physio.json
- calibration positions: you cannot have more than one array; if there are more than 1 calibration split this asc in different runs for separate physio.tsv
- calibration positions: always the same for the kind of calibration, like if CalibrationType = HV9 then the calibration positions will be always the same for HV9 calibrations

**Other points**
- We have no news of the EEG example (?)
- We are waiting for the latest change of OE on the bids empty example to included it in the rendered document and to propose the BEP to review to the community.
- We didn't make a new appointment but as a function of the reply of OE, we will send a round email.

## Meeting 2025/01/23

- Change of the example
https://github.com/bids-standard/bids-specification/pull/1128/commits/77fd56722dbf090d9d5f53b6a4dff74e4714509c

~~Do we have a new dataset example with EEG, if yes we need a link to it and a brief explanation alike the one used here.~~
Scott is dealing with it.

~~Should we put the link the the empty datasets or the real one, or both ?~~
We will use both, but we need to merge the example first to have the link.

- Example datasets PR: [bids-standard/bids-examples#478](https://github.com/bids-standard/bids-examples/pull/478).
- ~~Q: It feels this should be accompanied by a PR to BIDS-Validator because all tests are (understandably) failing. @YhHdXTcuRDac-GPev3pRkQ (<- this is a mention to Remi)~~ [Responded](https://github.com/bids-standard/bids-examples/pull/478#issuecomment-2592276237)
- natImSac example has some JSON files [with formatting issues](eyetracking1/sub-12/ses-01/func/sub-12_ses-01_task-rest_run-01_bold.json)
- --> Julia took care of errors in example datasets in their original repos

- Some resolved issues:
- `EnvironmentCoordinates` -> `StimulusPresentation.ScreenOrigin`
- [Pending conversation about the schema](https://github.com/bids-standard/bids-specification/pull/1128/files#r1916612102) about how to change the RECOMMENDED/REQUIRED status of metadata fields in the `events.json` files iff there are `physio.json` files defining `PhysioType`=`eyetrack`
- OE's implementation: Instead of "Environment" do not make any assumption about 3D to simplify. Let's leave 3D for a future BEP.
- [Pupil type measured](https://github.com/bids-standard/bids-specification/pull/1128/files#r1916646141)
- [Missing columns in example](https://github.com/bids-standard/bids-specification/pull/1128/files#r1562261040)
- [Empty task-rest_events.tsv](https://github.com/bids-standard/bids-specification/pull/1128/files#r1668339191)

- Home stretch TODO--moved to the top (OE)

- Converter:
- everything is merged and up-to-date, except [this](https://github.com/bids-standard/eye2bids/issues/69)
- SampleCoordinateSystem will be deleted as required metadata. For this, the description of x/y-coordinate needs to have an entry for „Units“ (=required) --> delete SampleCoordinateSystem from metadata in converter as well as in example datasets and make units required in physio.json
- calibration positions: you cannot have more than one array; if there are more than 1 calibration split this asc in different runs for separate physio.tsv
- calibration positions: always the same for the kind of calibration, like if CalibrationType = HV9 then the calibration positions will be always the same for HV9 calibrations
## Meeting 2024/12/19

::: info
Next meeting will be discussed on Element.
:::

- Manuscript
- Looks quite ready for next steps (feels like finalizing BEP020)
- Example dataset
- https://github.com/julia-pfarr/natImSac_BIDSexample
- https://doi.org/10.18112/openneuro.ds004158.v2.0.3
- Oscar will create empty dataset for BIDS example
- It says here [6e787b6](https://github.com/bids-standard/bids-specification/commit/6e787b6d6d129383038d4d4a87683285760c01f2) that "min items" are 3 but if someone chooses to not use XYZ it would be a single number or is "min items" not what I think it is and it doesn't matter?
- Converter: https://github.com/bids-standard/eye2bids
- Scott comments in Github
- https://github.com/bids-standard/bids-specification/pull/1128#pullrequestreview-2512695453
- OE `EnvironmentCoordinates` > make part of `events.json`?
- Yes (OE will take care of this)
- Julia will change this in example datasets and converter
- MS: Change the rendered text to put links to the newly worked datasets examples
- MS: Join Remi to invite next meeting
- Next meeting: January 23rd 2025

## Meeting 2024/10/31
- Follow up on EyeGeometry
- Add description in the manuscript
- Review and accept change in Github
- Full example dataset (with data)
- Change in specification "Example datasets" to refer to the good ones
- Include EyeGeometry
- Empty example dataset (without data)
- publish the empty dataset
- BIDS validator

## Meeting 2024/10/03
- Next meeting
- Discuss paper/figure
Everybody is welcome to read/review the paper, we add a figure to showcase the BEP...
- Discuss eye2bids
- Create csv rather than yml ?
- https://github.com/bids-standard/eye2bids/blob/main/eye2bids/config/metadata.yml
- We will keep yml and say it to ezbids
- Incorporate EyeGeometry
- waiting last change
- Discussion about epoch/trials and discontinuous recording
- We decided to not change this, Oscar has refer to a discussion about this in other BIDS part. For us we keep nan if timestamps is missing.
- timestamp documentation: https://github.com/bids-standard/bids-specification/pull/1128/commits/09b40d70240d7460f71a85a8eebc32b9d88281ec
- Discuss example dataset (real and empty)
- Missing EyetrackingGeometry to finish real dataset and then Oscar will take care of empty dataset
- Discuss EyetrackingGeometry:
- https://github.com/bids-standard/bids-specification/pull/1128/commits/6e787b6d6d129383038d4d4a87683285760c01f2
- Everyone can review the change now

## Meeting 2024/09/04

- discuss [comment](https://github.com/bids-standard/bids-specification/pull/1128#issuecomment-2304246574) on defining a unit for timestamp
- OE will take care of this :+1: (clarify examples and respond to comment on GH)

- did we already decide that the "EyetrackingGeometry" as proposed by Sourav will be implemented? (it's already in the paper, I thought we wanted to first ask in the BIDS-PR; need to know for the converter)

- https://github.com/bids-standard/bids-specification/pull/1128#pullrequestreview-2215145700
- OE will take of this one too - edit `EyeTrackerDistance` (and possibly rename) to also allow a list of three values

> Example of dependency between metadata
> https://github.com/bids-standard/bids-specification/blob/7c93b9c67188f5c5d496a250a8cbaf37f475ebf6/src/schema/rules/checks/func.yaml#L82

- did anyone look at the [example dataset](https://github.com/julia-pfarr/natImSac_BIDSexample)? If it's fine like this I can go on and take care of the bigger dataset on OpenNeuro

- if anyone has more testfiles to share (eyelink edfs), please put them on [OSF](https://osf.io/jdv7n/) (eyelink folder -> make new folder -> put edf file)

- started to write some doc for the converter: https://eye2bids.readthedocs.io/en/latest/

## Meeting 2024/08/01
- Discuss about "EyetrackingGeometry" information with Sourav K.
- Discuss about the manuscript

## Meeting 2024/07/04

- under which data_type does eyetracking data go if it is ONLY eyetracking without any other modality like MRI. Does it go then under beh or func? In one of the last meetings it was said it always goes under func ->
- Answer: seems we miscommunicated and there seems to be full agreement on having this under `beh/`
- Example datasets:
- one is finished on openneuro: doi:[10.18112/openneuro.ds004158.v2.0.2](https://doi.org/10.18112/openneuro.ds004158.v2.0.2)
- eyetrack bit?
- perhaps better: run the validator (without adding to `.bidsignore`) and see how it breaks.
- another one is on GitHub: https://github.com/julia-pfarr/natImSac_BIDSexample --> need to include events.tsv/.json for trial informations besides the physioevents.tsv/.json?
- yes, tasks require events.tsv files.
- do we need a third example dataset for the github bids-examples?
- open pull requests on converter:
- please merge
- metadata.yml
- when can the spec be merged?

### Paper draft
- Martin shared a paper draft and described the structure
- Orientation toward physio? (we've sorted out a lot of BIDS beyond eye tracking)
- BIDS-Apps drive / EyeTrackingQC?
- Eye tracking data is on the rise
- OE proposed inspiration by https://www.axonlab.org/hcph-sops/data-management/eyetrack-qc/ for some figures.
- Julia shared two relevant links:
- https://doi.org/10.31234/osf.io/f6qcy
- https://ecobidas-ui.onrender.com/en/protocol/eyetracking

## Meeting 2024/04/18

- Julia would like to discuss:
- How proceed with other eyetrackers?
- Is there a recommendation on how to save video files in the dataset? (question form a colleague who does free-moving eyetracking plus video recordings) --> maybe there will be a separate spec for this in the future; right now there is nothing on it
- What about this comment https://github.com/bids-standard/bids-specification/issues/1788? I need to know for the converter. --> leave compression
- ezBIDS

- 3D eye-trackers
- Update admonition so that those metadata are mandatory only with gaze-on-screen ETs.

## Meeting 2024/03/31

- work to do:
- update converter to split by eye, handle eye 3, physioevents.tsv
- scope:
- vergence not "explicitly" covered
- revise spec: currently entries for the "eye3" stuff is not clear -> there are two different paragraphs on it:
- "it is REQUIRED that recordings corresponding to each eye (and merged signals for binocular eye-trackers providing a third recording) are split into files with different recording-<label>. Therefore, the recording-<label> is REQUIRED with eye-tracking data."
- "The labels "eye1", "eye2", and "eye3" for the recording-<label> entity are RECOMMENDED"
-> Julia was confused; maybe change it to "the use of labels...recommended"

## Update OE - 2024/03/01

The PR including both [old `eyetrack` suffix](https://bids-specification--1128.org.readthedocs.build/en/1128/modality-specific-files/eye-tracking.html) and [new `PhysioType`](https://bids-specification--1128.org.readthedocs.build/en/1128/modality-specific-files/physiological-and-other-continuous-recordings.html) is now available.

Oscar is holding off some changes, until after the "old" eyetrack can be removed if everyone signs off.
This is the TODO list:

- [ ] Add metadata and optional column definitions for EyeLink based on OE's dataset (shared privately with MS, JP, and RG).
Perhaps this would not be an exhaustive representation of all possible metadata and columns, but complete what we have now.
- [x] Revise metadata of events files (see [Remi's comment](https://github.com/bids-standard/bids-specification/pull/1128/files#r1252720336)).
- [ ] Investigate some eye-trackers other than EyeLink:
- [ ] Tobii: Openness of the eye (distance between eyelids) [by @dcnieho](https://github.com/bids-standard/bids-specification/pull/1128/files#r1044281428).
Material for Tobii: https://osf.io/jdv7n/ and https://docs.google.com/spreadsheets/d/1XsIh9QFeQY0QX8x2Wn2yn1ysM9FPZI6r18xrRrz7rTU/edit?usp=sharing
- [ ] Arrington Research Viewpoint (https://www.biopac.com/wp-content/uploads/viewpoint_eyetracker_manual.pdf, page 54 and following):
- [ ] TotalTime
- [ ] DeltaTime
- [ ] X_Gaze, Y_Gaze
- [ ] Region
- [ ] PupilWidth
- [ ] PupilAspect
- [ ] Quality
- [ ] Fixation
- [ ] Torsion
- [ ] Count
- [ ] Mark
- [ ] Cyclopean eyetrackers
- [ ] vergence
- [ ] version
- [x] Confirm with @Lucrezia1011 that we have addressed [her question](https://github.com/bids-standard/bids-specification/pull/1128/files#r1411228722).
- [ ] [Update examples](https://github.com/bids-standard/bids-specification/pull/1128/files#r1407591015)
- [ ] Write an abstract for the BEP PR so that it is very well justified why we needed to rework the specs of physio (they are a bit abandoned) before going ahead and specifying eye-tracking data.
Highlight that everything is backward-compatible :)
- [x] Discuss whether the "duration" column of physioevents should be mandatory as for events.
- [x] Clarify motion parameters by the scanner vs. BIDS-Motion ([bids-standard/bids-specification#1719](https://github.com/bids-standard/bids-specification/issues/1719))
- [ ] Retracted paper (https://github.com/bids-standard/bids-specification/pull/1128/files#r1510016997)
- [ ] BIDS-Validator (OE will work with CM and RB on this)

## Meeting 2024/02/29

Discussion of OE's pull request to introduce PhysioType and physioevents.tsv

ACTIONS:

---
- [x] **Oscar** to finish his PR with the "old" eyetracking and the "new" physio-eyetrack
- [x] Let github CI build the pages
- [x] **Everyone** to compare the "new" and "old" to make sure nothing was lost on the way
- [x] Remove the "old" eyetrack
---

- **Remi** opens an issue to motivate and discuss the introduction of physioevents

## E-mail 2024/02/27

:::info
UPDATE 2024/02/29: OE submitted a PR jotting down these ideas https://github.com/mszinte/bids-specification/pull/8/files
:::

OE sent an email proposing a simple idea that could (i) allow this BEP set limitations such as separating eyes and, at the same time, (ii) keep legacy datasets compatible and passing new versions of the validator.

**Proposal**: the definition of a new OPTIONAL metadata field for `_physio.json` files called `"RecordingType"`.

**Implementation**:

* The default value of `"RecordingType"` would be `"custom"` (or `"unspecified"` or `"n/a"`, whichever majority likes the most). If not explicitly defined in the metadata, `"RecordingType"` is `"custom"` (this is important for tools like pybids as querying for `"custom"` or `None`/null should return the same).
* This BEP would introduce `"eyetrack"` as a new `"RecordingType"`. Future BEPs may introduce other values (e.g., `"ecg"`), but that would be defined as out of the scope for us.

**Advantages**: Now, by having a `"_physio.json"` file with `{ "RecordingType": "eyetrack" }`, all the aspects we have been discussing become *active*:

- Eye tracking and corresponding measurements (e.g., pupil size/area) MUST be stored in separate `_physio.tsv.gz` files (see [the notes of the previous meeting](https://hackmd.io/DoCMOU7DSEONDz7BT6GmjQ#Separating-recordings-by-eye)).
In other words, the `_physio.tsv.gz` file corresponding to the `_physio.json` file can hold data for one and only one eye/merged signal.
- The metadata fields defined in this BEP and their OPTIONAL/RECOMMENDED or MANDATORY statuses are enforced. This is **critical** because of what [Taylor mentions here](https://github.com/bids-standard/bids-specification/issues/1675#issuecomment-1924034458) -- we cannot change the RECOMMENDED/MANDATORY status of fields unless something *special* is introduced.
- Permits opinionated individuals who want more than one eye per file to keep using the current specs. However, this choice will come at a cost of software tools having it harder to interpret the data (i.e., it is really not a wise or a *FAIR* choice).
- Defines a sandbox where we could propose nonregular sampling in `_physio` files, by enabling a new special value in `"SamplingFrequency"` ONLY for specific `RecordingType`s such as `"eyetrack"` (i.e., this way we can keep the old `tsv.gz` files *untouched*).

**Context**: This idea, in addition to adding the new `_physioevents.[tsv.gz|json]` files we set out to draft would put together a very solid framework that:
- permits a rigorous specification for eyetracking files, and
- lays the groundwork for future BEPs working on specific physio signals that have their own domain of key metadata fields

### Response 1 by RG

In addition to some general comments to the proposal above, RG also noted:

> probably worth checking existing BIDS datasets with alledgedly valid eyetracking/physio data to see if they do not already suffer from this "non continuous sampling", which very well may be the case if they used the approach of record ON / record OFF approach that we mentioned last meeting.

### Response 2 by RG

Remi also shared two related efforts:

* A [BEP for "physio derivatives"](https://docs.google.com/document/d/1h5eOwPYBdKbsCFQ8fcDZr0BDZWQ6nWZu4HOrG6JAnco/edit#heading=h.qyie8v2icc6c).
* A corresponding issue where some current issues of physio in BIDS are [listed](https://github.com/bids-standard/bids-specification/issues/1675#issuecomment-1864084244).

OE has posted this document and the BEP in the Physiopy slack channel.

## Meeting 2024/02/22

### Suffix (`_eyetrack`) or keep the old (`recording-eyetrack_physio`)

Pro:

* Quickly tells you there's ET data in the dataset

  dataset.get_eyetracks()
  > gives you a number of files
  > 

* Lifts the limitations to add entities: without new suffix, separating recordings by eye (e.g., `eye-1_eyetrack`) is *perhaps* less straightforward to implement in the specs.

Cons:

* What happens with "old" `_physio` data? Deprecation?
* Risk of new `_eyetrack` worked-around to lower the requirements to get a dataset get the BIDS-valid seal of approval.

### Separating recordings by eye

Separating metadata for each eye:
* `eye-1_eyetrack.ext`, or
* `recording-eye1_physio.ext`

Mandatory or Recommended?
* Julia - mandatory
* Martin - mandatory
* Let's go with mandatory

### Non-regularly sampled data ("physioevents?")

- `_physio.tsv.gz` files MUST be regularly sampled in BIDS, that is, eye tracking and all other physio recordings struggle with this. This brings two problems:
- missing timepoints (e.g., when switching recording off) can only be encoded with `n/a` (a lot of rows filled with them in every column)
- cannot have two rows for a single sample - this forces "unraveling" all columns (e.g., the standard gaze position columns plus all the parameters of the saccade model in the case of eyelink)
- A new suffix (`_eyetrack`) could drop the requirement of regurlarly sampled data / but it doesn't resolve the issue of spawning huge numbers of columns (i.e., having "triggers"/messages and saccade model on a separate file).
- This will likely be frowned upon since it resolves a general problem for a single data type, while the spirit of BIDS is that we need homogeneous specs across datatypes.

- A separate file `_physioevents.tsv.gz` (or `_eyetrackevents`?) would be a neat solution to this problem, while being representative of what people are doing today (keeping the eyetracking primary information separate from other metadata such as messages).
- while trying to move `_physio` away from enforcing regular sampling seems a bit of a heavy lift from this BEP (as it affects BIDS more widely), proposing `_physioevents` could actually be relatively straightforward with zero backward compatibility issues.
- A problem with this new file may emerge when we want to have two different `recording-eye1_physioevents.tsv.gz` annotating a single `recording-eye1_physio.tsv.gz` file (e.g., with EyeLinks you get two of these files, one would be "events" with the saccade/blink model and "messages" with calibration, validation, triggers, etc.).
Having "events" and "messages" together doesn't seem like a crazy restriction, though (it would require an extra column "message" filled with `n/a` for "events").

### Naming of these "triggers"

- This discussion seems something we will need to address as part of the above point.

### Tobii

reply to https://github.com/bids-standard/bids-specification/pull/1128#issuecomment-1851492412