Meeting notes 2026.01.29

[m-miedema]

Attendees:
@m-miedema @me-pic @smoia @ShiyuBelleWang @neuromechanist @rgbayrak

Agenda:

• Response Naming conventions for EDA data #38
• Re-base on eyetracking BEP?
• Concurrently acquired data Metadata field to clarify relative timing of concurrently-acquired data groups #23 Comments regarding “ConcurrentWith” and "StartTime" metadata field #8 and Google doc
• Response to sparse data issue

Outcomes:

• We will discuss adopting a scans.tsv approach to concurrency and making a PR for this; main targets would be changing: requirement level for scans.tsv, for acq_time, adding duration to scans.tsv if it is not there, adding a sentence under the duration definition
• We understand schema entries a little better (__{sense} is useful for entities that need to be validated differently)

[smoia]

Concurrent data:

• Going through the scan.tsv way:
  • changing requirement of scan.tsv
  • changing requirement of acq_time
  • adding a RECOMMENDED duration column to scan.tsv
    • adding a sentence under the "duration" definition so that it's clear that in scan.tsv, "duration" means the full length of the data, OR
    • if we need a different schema requirement check we need to add a new "sense" of duration instead.
  • (Alternatively: adding a RECOMMENDED acq_end column?)

[m-miedema]

Potential handling for sparse/nonuniformly sampled data: can require either SamplingFrequency or Latency column!

Can recommend that if data is recorded on the same device/file, it should be one file (avoid segregating).

[smoia]

Non-constant fs:

• Adding latency from motion BEP as column would solve this issue staying with physio data, however latency was not invented to do so (but IMHO it makes much more sense).
• Then we need to make sure physioevents is always just for labels and not for non-continuous recordings
• Then we make both fs metadata and latency column RECOMMENDED but at least one of the two (not important which one) REQUIRED

[smoia]

Also look for EHR data domain