[ENH]: BEP032 formal review

[CodyCBakerPhD]

BEP 032: Under review

This BEP is currently under review: #2406

Please post significant discussion to that thread. Minor issues, such as typos or clarifications, may be posted as suggestions to this PR. These suggestions may be accepted or rejected without discussion, so do not make substantial proposals in this way.

---

Original post

To all @bids-standard/maintainers

In line with the penultimate steps outlined in the Proposed BEP Review process, the BEP032 team would like to submit our pull request for formal review by the maintainers and community!

This PR adds a specification for microelectrode electrophysiology datasets based on the BEP032 proposal.

We happily welcome all enhancements, fixes, suggestions, requests, and critiques by the broader community.

This work is the result of some enormous efforts over the last year by @ree-gupta @bendichter @yarikoptic @twachtler @robertoostenveld @lzehl @apdavison and many others whose full work history has been squashed as an extended description on this commit and can be seen in the original draft PR, a copy of which will be kept on a branch in perpetuity on my personal fork (https://github.com/CodyCBakerPhD/bids-specification/tree/backup-bep032-work).

Quick links

• HTML preview of this BEP
• Working overleaf manuscript project with source and git history here
• Example dataset
• Another example dataset

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.09%. Comparing base (5b2cf70) to head (3f661db).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2307   +/-   ##
=======================================
  Coverage   83.09%   83.09%           
=======================================
  Files          22       22           
  Lines        1698     1698           
=======================================
  Hits         1411     1411           
  Misses        287      287           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bendichter]

@effigies it looks like there are minor merge conflicts. Should we resolve these?

[effigies]

Yes. They look easy to resolve.

[ree-gupta]

Hey! @CodyCBakerPhD Thanks again for the PR. I found a potential issue/improvement in the spec:

I missed adding ecephys and icephys datatypes to the allowed datatypes for physio suffix.

Reference:

bids-specification/src/schema/rules/files/raw/task.yaml

Lines 10 to 14 in 4b40578

	datatypes:
	- beh
	- eeg
	- ieeg
	- nirs

This would allow physiological recordings (cardiac, eye tracking) and stim to be stored alongside microelectrode electrophysiology data.

I am still not sure if we can push to this PR branch or collect all the reviews for the end, hence not making changes yet.

[robertoostenveld]

@bids-maintenance can we get this announced to the community through the mailing list for formal review, and get a few experts explicitly assigned/invited as potential reviewers?

[lzehl]

@bids-maintenance could you help us with the question: "can we get this announced to the community through the mailing list for formal review, and get a few experts explicitly assigned/invited as potential reviewers?"

[julia-pfarr]

Hi, we have two scheduled BEP community review periods per year, the next one is in April. We put you on the list for this review period! Before that, some maintainers would like to meet with all of you and go through the BEP, to make sure everything is ready for the community review. @effigies and @rwblair, can you post a when2meet with your availabilities here? Thank you!

[ree-gupta]

While curating a set of resting-state ecephys datasets (NHP, no pharmacology, no stimuli), I noticed that the pharmaceutical fields introduced as recommended don't accept "n/a" as a value. Other fields types like HardwareFilters (objects/metadata.yaml:1750-1756) and SoftwareFilters (objects/metadata.yaml:3964-3970) handle this by including {type: string, enum: [n/a]} in their anyOf, but these don't have that escape.

Since they're recommended, omitting them still triggers SIDECAR_KEY_RECOMMENDED warnings.

Two possible fixes:

1. Add "n/a" to the type definitions in objects/metadata.yaml (like HardwareFilters and SoftwareFilters do). But since these definitions are shared with other modalities, this would also allow "n/a" there, which may be undesirable.
2. Downgrade from recommended to optional in microephys.yaml:62-71. This suppresses the warning while keeping the fields available for experiments that do use pharmacology, but loses the signal that they should be provided when applicable.

[yarikoptic]

I think there is no specific rule, but @effigies struggled to move many RECOMMENDs into OPTIONAL for MRI since there was too much noise from validator.

May be rule of thumb could be simple: What % of studies use some pharmacology worth adding? if majority (over 50%) -- keep in RECOMMENDED, otherwise - go for OPTIONAL. Eventually, with all the LLMing, and after underlying papers are associated with the dataset for mining and informed metadata editing like with WiP by @bendichter https://medit.dandiarchive.org for DANDI, those OPTIONAL could be auto-filled out or requested based on the study background mined from the extra materials.

[effigies]

Another approach could be to add a required boolean field like "PharmacologicalIntervention". If False, then fields are OPTIONAL; if True, they are REQUIRED/RECOMMENDED (as appropriate).

[effigies]

Forgot to send a when2meet. @CodyCBakerPhD and anybody who wants to meet with us: https://www.when2meet.com/?35364181-QNHek

[ree-gupta]

While curating a set of resting-state ecephys datasets (NHP, no pharmacology, no stimuli), I noticed that the pharmaceutical fields introduced as recommended don't accept "n/a" as a value. Other fields types like HardwareFilters (objects/metadata.yaml:1750-1756) and SoftwareFilters (objects/metadata.yaml:3964-3970) handle this by including {type: string, enum: [n/a]} in their anyOf, but these don't have that escape.

Since they're recommended, omitting them still triggers SIDECAR_KEY_RECOMMENDED warnings.

Two possible fixes:

1. Add `"n/a"` to the type definitions in `objects/metadata.yaml` (like `HardwareFilters` and `SoftwareFilters` do). But since these definitions are shared with other modalities, this would also allow `"n/a"` there, which may be undesirable.

2. Downgrade from `recommended` to `optional` in [microephys.yaml:62-71](https://github.com/bids-standard/bids-specification/blob/bep032-review/src/schema/rules/sidecars/microephys.yaml#L62-L71). This suppresses the warning while keeping the fields available for experiments that do use pharmacology, but loses the signal that they _should be_ provided when applicable.

Decision on 2026.03.04: Make it optional for this BEP.

[CodyCBakerPhD]

The other follow-up from the meeting with the BIDS maintainers related to very basic file content validation: bids-standard/bids-validator#369

[ree-gupta]

Hi, we have two scheduled BEP community review periods per year, the next one is in April. We put you on the list for this review period

Hi BIDS-maintainers :) do we have an update in which review period would this proposal fall in? Are there any more open questions or changes pending on our end?
Thanks!

Tagging to notify: @julia-pfarr @effigies

[effigies]

Was just going to send out emails. We're planning to open review on Monday.

[effigies]

This PR is under review: #2406

Please post significant discussion to that thread. Minor issues, such as typos or clarifications, may be posted as suggestions to this PR. These suggestions may be accepted or rejected without discussion, so do not make substantial proposals in this way.

[effigies]

Still working on a final review. These are my comments from reading the text. I haven't yet gone through the schema closely.

[effigies]

I don't understand this TODO. Apologies if I missed a discussion.

[effigies]

Missing table here. Looks like the following, rendered:

[effigies]

This TODO appears undone. If it is not ready, I would remove this section and open an issue to add it later.

[yarikoptic]

I think it came from good old times when also @JuliaSprenger was involved in this BEP, so that https://gin.g-node.org/sprenger/multielectrode_grasp/src/bep_animalephys was created. But overall it was left as TODO since it is a chicken-egg issue. We can't have this until we finalize BEP since otherwise those datasets might not be valid ones. I wonder also if we could/should just point to https://github.com/bids-dandisets/ which would have many of such examples. I would not bother with https://gin.g-node.org/NeuralEnsemble/BEP032-examples though since those are largely replaced with bids-examples. But I would leave in smth like

Suggested change

	Several real-world datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.
	<!-- TODO: Update with current real datasets. A current version of these datasets [can be found on GIN](https://gin.g-node.org/NeuralEnsemble/BEP032-examples) .
	For a complete dataset including all data samples the extracellular microelectrode dataset published in [Brochier (2018)](https://doi.org/10.1038/sdata.2018.55) has been reorganized according to the current version of this BEP, using the NIX data format.
	The up-to-date version of the dataset [can be found on GIN](https://gin.g-node.org/sprenger/multielectrode_grasp/src/bep_animalephys) .
	We will also publish another dataset using the NWB data format in the near future, and a dataset acquired -->
	Several real-world datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.
	<!-- TODO: Upon finalization of the BEP032, update with current real datasets if they are updated to the spec and pass bids-validator.
	For a complete dataset including all data samples the extracellular microelectrode dataset published in [Brochier (2018)](https://doi.org/10.1038/sdata.2018.55) has been reorganized according to the current version of this BEP, using the NIX data format and [hosted on GIN](https://gin.g-node.org/sprenger/multielectrode_grasp/src/bep_animalephys) .
	Also numerous datasets from the [DANDI Archive](https://dandiarchive.org) have been converted to BIDS using [nwb2bids]() and shared [on GitHub](https://github.com/bids-dandisets/).
	>

[SylvainTakerkart]

I think it came from good old times when also @JuliaSprenger was involved in this BEP, so that https://gin.g-node.org/sprenger/multielectrode_grasp/src/bep_animalephys was created. But overall it was left as TODO since it is a chicken-egg issue. We can't have this until we finalize BEP since otherwise those datasets might not be valid ones. I wonder also if we could/should just point to https://github.com/bids-dandisets/ which would have many of such examples. I would not bother with https://gin.g-node.org/NeuralEnsemble/BEP032-examples though since those are largely replaced with bids-examples. But I would leave in smth like

I confirm this historical point! The use of GIN to host such example datasets is probably obsolete now and any reference to it, at least the ones created by Julia Sprenger, should be removed... The TODO list is also outdated (same timeframe / investigator)...

[SylvainTakerkart]

from what I know, the data available at https://gin.g-node.org/sprenger/multielectrode_grasp/src/bep_animalephys is old (last change 4 years ago), and therefore not compliant with the current state of the specs... I think @ree-gupta has produced a version of the same dataset (from Brochier 2018) that should be compliant with the current specs... we could simply replace the old link with the one that's up-to-date...

[effigies]

The sample-<label> entity is first introduced here and only described in the photos section. As a reader it came out of nowhere.

This appears to have been taken from microscopy. I would reuse text from there to the extent that it's applicable.

Is samples.tsv required if the sample-<label> entity is used? Is it permitted?

[bendichter]

Hey BEP032 team, let's discuss @effigies 's point about sample-<label> coming out of nowhere. He's right that it's under-explained, and digging in I found the requirement level is inconsistent between the prose and the examples, plus a schema gap. Here's what I'd suggest, but curious what you all think:

Introduce the entity up front. Right now its only real definition is buried in the Photos section, framed as just for histological photos, but the intracellular examples use it on every file (sample-cell001, etc.). I'd propose adding a definition near the top in "Terminology: Modality and Datatypes," adapted from the microscopy text.

Split the requirement level by datatype rather than making it uniformly optional or copying microscopy's blanket REQUIRED:

• ecephys (in-vivo extracellular): OPTIONAL, and typically absent, since there's no tissue sample. Requiring it here would be wrong.
• icephys (patch): REQUIRED. A patched cell effectively is a sample, and the datatype inherently deals in discrete cells/slices. This matches what our intracellular example already does (every file is sample-cellNNN) and mirrors how micr treats it.

In the schema this is just leaving sample: optional for ecephys and changing it to sample: required in the icephys block of microephys.yaml.

One sub-question: micr does not exempt the single-sample case (one sample per subject still gets sample-01). I'd suggest we follow that, since a single-sample exemption causes filename churn if a second cell is added later and forces tools to special-case it. So: required for icephys even when there's only one sample.

samples.tsv. Chris also asked whether it's required when the entity is used. It currently isn't enforced at all for microephys, since SamplesTSVMissing only triggers on "micr" in dataset.modalities. I'd suggest requiring samples.tsv whenever the sample- entity is present (which, with the split above, means always for icephys and only-if-used for ecephys), and adding a check keyed on entity-presence rather than modality.

samples.tsv columns we inherit. These are modality-agnostic, so microephys gets them for free: sample_id (required), participant_id (required), sample_type (required), pathology (recommended), derived_from (recommended). They all fit microephys fine, so I don't think we need to define anything new. Two things worth a quick look:

• sample_type is a required enum, and its full value list is broader than just cell types: tissue, whole organisms, organoid, technical sample, plus cell line / in vitro differentiated cells / primary cell / cell-free sample / cloning host. So an acute slice maps cleanly to tissue and organoid recordings to organoid — no missing values. The only thing to settle is a granularity convention: for patch clamp, is the "sample" the slice or the individual cell? If it's the cell, tissue is still the closest sample_type. We could also register both and use derived_from to link sample-cell001 back to sample-slice01. I'd suggest we pick one convention and document it.
• sample_id labels are restricted to ^sample-[0-9a-zA-Z+]+$ (no underscores/hyphens), so sample-cell001 is fine but keep that in mind for examples.

Cleanup. Trim the Photos-section mention down to a back-reference to the new definition.

If the per-datatype split (optional ecephys / required icephys) and the entity-presence trigger for samples.tsv sound right, I'm happy to put up the edits. The main thing I'd want to settle first is the sample granularity convention (cell vs. slice) for patch data.

[yarikoptic]

nice dig! I do not know much about icephys, but is it really that there would be multiple samples per each subject? ATM we do mandate sub- entity already, so if it is actually typical to have multiple samples - people would just use it if/where needed to disambiguate within subject, so we do not even need to make it RECOMMENDED.

And yes, I would recommend having samples.tsv if _sample- entity is used.

NB/backref -- this will add one more "consistent" case for samples.tsv to be inconsistent' in having dual-index for a single plural entity filename as mentioned in #2283

[bendichter]

Yes, multiple samples per subject is normal for icephys. A single animal commonly yields several slices, and several cells are patched per slice, so >1 sample per subject is the rule, not the exception.

On the requirement level: sub- alone can't disambiguate samples within a subject, and as you note people would reach for sample- to do that anyway. So the real choice is whether sample- is present inconsistently (only when >1) or always. The problem with "only when needed" is churn: collect one cell → sub-X_..., collect a second later → you now have to rename the first file to add sample-, and tools have to special-case the single-sample form. micr avoids this by requiring sample- even for a single sample, and I'd lean toward icephys following it for the same reason.

Agreed on requiring samples.tsv whenever sample- is used.

That said, the required-vs-optional call (and the related cell-vs-slice granularity convention) has real trade-offs in both directions, so I think it warrants input from the larger BEP032 team before we settle it.

[lzehl]

Hey. Here my feedback.

Introduce the entity up front. I agree with your suggestion.

Split the requirement level by datatype It's good to make it OPTIONAL for ecephys (although "since there's no tissue sample" is not correct, just not the typical case). It should indeed be required for icephys.

requiring samples.tsv whenever sample- is used I would agree to that (I think this is the case already no?). From a metadata management point of view this is very annoying that this is not the case for subjects. Even if there is only one subject (or sample) you want to have structured information on that subject (or sample).

From my point of view all those cases can be true and should be possible to model in BIDS: one sample per subject, multiple samples per subject, one sample from multiple subjects, sample with no subject.

sample_type the enum list is indeed insufficient and should be extended/revised. We encountered this problem already for the atlas/microscopy people that started to use BIDS. However I'm not sure if they ever raised that issue officially. As inspiration, here is the list we use in openMINDS (which was usage driven so most likely also not complete).

[SylvainTakerkart]

sample_type the enum list is indeed insufficient and should be extended/revised. We encountered this problem already for the atlas/microscopy people that started to use BIDS. However I'm not sure if they ever raised that issue officially. As inspiration, here is the list we use in openMINDS (which was usage driven so most likely also not complete).

Hi, I jump in a little bit (yes, I'm still around and following ;) ). Wanted to attend the meeting yesterday but finally couldn't...

I've had the same experience with the definition and use of sample for some microscopy data recently... With two issues:

• the enum list (I concurr with @lzehl , it should be extended/revised)
• the granularity question, which is in fact, if I'm not mistaken, not formally settled in the microscopy specs, leading to potential different interpretations of the micr specs (a case I encountered)

So I agree and support what you're doing here, in particular the addition of the text to define the granularity!

[effigies]

This appears to be vestigial, as there is no Procedure metadata defined in the schema, and PharmaceuticalName is shown directly in the top-level metadata. (I'm assuming "node" means a field in a JSON structure.)

[lzehl]

Hey BEP032 team, @effigies is right that this it is very unclear what "node" refers to and I honestly don't remember. Prior to this we say "The *_ecephys.json or *_icephys.json file can be used to store any microephys-specific metadata for the dataset. All setup-related metadata should be stored in a dedicated node of the JSON file called Setup.". For me this reads as if we intended the *_ecephys.json or *_icephys.json to be nested jsons, that provide information of setup and procedure under highlevel keys"setup" and "procedure", but I think this is not true. Except for the filter metadata *_ecephys.json or *_icephys.json are supposed to be flat.

My suggestion: The node reference is confusing I would just delete it. Setup, Procedure (with Pharmaceuticals, Sample, Supplementary) are just subheaders to structure all possible keys of the *_ecephys.json and *_icephys.json sidecars.

This brings up though another general issue I see: for me the sample metadata in the *_ecephys.json and *_icephys.json sidecars (and actually in the microscopy sidecar JSON files) compared to what is/should be provided in the samples.tsv and samples.json is a bit unclear. I would have assumed that all in samples.tsv and samples.json refers to the unprocessed sample (so all that is true always for sample X, such as sample type, slice thickness, extraction protocol, etc) while the sample keys in the *_ecephys.json, *_icephys.json and microscopy JSON sidecars cover additional processes applied sequentially (such as staining, pharmaceuticals, etc) or sample related acquisition variables (such as deformation, etc) or information on tissue structures when there is no sample (such as examined body part in a typical ecephys case,or intravital microscopy settings). This seems to be not the logic though. Sorry to raise this now... I guess we cannot do much about this now, but maybe we can deliver good examples of what to define where and when for samples?

[effigies]

Suggested change

	suffixes:
	- channels
	extensions:
	- .json
	- .tsv

[effigies]

Got through columns.yaml. Working my way in lexical order.

[effigies]

This (estimated|proof) is causing truncation:

I don't understand this sentence in any case. Could it be rewritten not to use (x|y) notation and edited for clarity?

[lzehl]

@bendichter I think we just expect an enum here "estimated" or "proof". I would suggest to reformulate to:

    The quality type of the method used to identify the associated brain region.
    MUST be 'estimated' or 'proof'.

In openMINDS we call this criteria quality types and our terms here are 'asserted' (claim/subjective) vs 'processive' (repeatable process/objective).

[effigies]

One of these seems to require Uberon, one uses Uberon as an example. If I were to read this as a curator, I would assume Uberon is required, and associated_brain_region is just vaguely worded.

What is the intent here?

[lzehl]

I think associated_brain_region and the corresponding associated_brain_region_id should not be limited to UBERON (which is only a generic cross species ontology). There are species specific anatomical atlas brain regions and their corresponding IDs out there which should be used if fitting (I don't understand why we say cross-species is preferred... not really a good advise). UBERON should just be an example. So the text needs revision. My sugestion:

associated_brain_region:
  name: associated_brain_region
  display_name: Associated brain region
  description: |
    A textual indication on the location of the probe,
    preferably ontology-based, for example from UBERON.
  type: string
associated_brain_region_id:
  name: associated_brain_region_id
  display_name: Associated brain region identifier
  description: |
    The corresponding persistent identifier of the associated brain region, 
    for example "UBERON:0010415".
  type: string

[effigies]

The examples seem to match more with what I would think of as a description than an identifier. How does this differ from description?

[lzehl]

@effigies human readable identifiers or maybe use better the term label here (?) differ from descriptions in multiple ways: shorter (best actually one word, max two words) and not necessarily explanatory. Descriptions should be fully formulated sentences actually explaining the thing or the content.

I think channel label rather corresponds to channel type. So I would remove channel label.

[bendichter]

I was inspired by @effigies's questions about the brain region columns to look more closely at how anatomical location is represented in this BEP, and I think there is a structural issue worth discussing as a group.

Current Situation

Anatomical location is annotated in two separate places. In probes.tsv there are four recommended columns: associated_brain_region, a textual label (for example, primary visual cortex), associated_brain_region_id, an ontology identifier (for example, UBERON:0010415), associated_brain_region_quality_type, indicating whether the region was established by anatomical evidence or estimated, and reference_atlas, naming the atlas used. In electrodes.tsv there is a single recommended column, location, described as "An indication on the location of the electrode (for example, cortical layer 3, CA1)", with no accompanying identifier column and no ontology mapping.

Why This Is a Problem

There are three issues, and they compound.

First, a probe frequently spans multiple regions. A single shank can pass through cortex, hippocampus, and thalamus in one insertion, so one brain region per probe cannot describe where the recording actually happened.

Second, localization really happens at the electrode level. Once you have histology or an atlas registration, what you recover is a region assignment per contact. The probe-level annotation is better understood as the intended target of the insertion than as the result of localization.

Third, electrodes.tsv has no ontology support. So the one table where per-contact localization can be recorded is also the place where the annotation is least machine readable, while the ontology columns sit on the coarser of the two tables.

The third point is the one I would emphasize, because it is not only a matter of granularity. If the ontology term lives on the electrode, we can support different ontologies for different localizations, since different rows can carry identifiers from whichever atlas was actually used for that assignment. That flexibility is not really available at the probe level, where a single value has to stand for the whole insertion.

Proposed Changes

For probes.tsv, redefine the existing region columns as the target brain region rather than the observed one. This can be done in the column descriptions without renaming anything, so it is a low-cost change: associated_brain_region and associated_brain_region_id become the region the probe was aimed at, which is genuinely useful information and is what a probe-level annotation can honestly express.

For electrodes.tsv, rename location to brain_region and add a companion brain_region_id column holding an ontology identifier, allowing UBERON as well as species-specific atlases such as the Allen Mouse Brain Atlas. The naming would then parallel the probes table, and the distinction between the two would be target versus observed rather than two unrelated concepts.

Once the columns are split this way, associated_brain_region_quality_type should move to electrodes.tsv as well. A quality or evidence qualifier on a stated target is not meaningful, since the target is declared in advance by the experimenter and there is nothing about it to have been estimated or verified. The qualifier only makes sense attached to an observed localization, so it should follow brain_region to the electrodes table rather than stay behind on the probes table.

I anticipate the objection that the evidence method is usually constant across a probe's contacts, since there is typically one histological reconstruction per track, so the value would repeat down the whole column. I do not find that persuasive. Constant columns are routine in BIDS tabular files, and the method does vary in real data: contacts near a region boundary versus contacts deep inside a structure, contacts whose slice was damaged or lost, and assignments that were directly observed versus interpolated between two observed points. Per-contact seems like the safer granularity to me. If the group would rather avoid the repetition, the alternative worth considering is a sidecar JSON field, not leaving the column on probes.tsv.

I would also take the opportunity to fix two things about that column, which is the subject of @effigies's open thread on it. The name suggests a quality grade, but the concept is really how the region assignment was established, so something like brain_region_localization_method or brain_region_evidence describes it more directly. And the permitted values are currently written into the prose as (estimated|proof) rather than declared as an enum, which is what is causing the rendered table to truncate. Making it a real enum would fix the rendering and the ambiguity together.

I think this also resolves the question @effigies raised about whether Uberon is required or merely an example, since we would need to state the intent explicitly for the new electrode columns in any case.

A few things I do not have a strong opinion on and would like input on:

• Which ontologies do we allow, and do we express that as prefixed identifiers (UBERON:0010415, MBA:385) so a single column can carry more than one source?
• Should reference_atlas also become an electrodes.tsv column, or is a prefix on the identifier sufficient to say where a term came from?
• What should the enum values for the localization method be? I read the current "proof" as meaning histologically verified, so something like histology, imaging, estimated, and possibly interpolated seems closer to the real distinctions, but this is a domain question and I would rather the group set the list.

[bendichter]

Following up on @effigies's question about anatomical_reference_point, I looked into what it would take to enforce the current language, and I do not think the conditional as written can be implemented.

Current Situation

The column is optional in microephysProbes, but its description says "If not specified, Bregma is assumed for rodents" and "MUST be defined for species other than rodents". So an optional column carries a conditional MUST, and both the requirement and the default depend on knowing the subject's species.

Why the Species Condition Cannot Be Enforced

The validator context does not expose species at all: context.dataset.subjects provides only sub_dirs and participant_id, so a rule evaluating probes.tsv cannot read the species column of participants.tsv without first extending the context. species is itself only RECOMMENDED and is assumed to be homo sapiens when absent, so the condition rests on a frequently missing column whose fallback would make the reference point required by default. And deciding rodent versus non-rodent needs taxonomic reasoning rather than string comparison, since Rodentia contains thousands of species and the expression language has no notion of taxonomy. None of this seems worth solving for one column.

Proposed Change

@effigies asked whether it would be easier to just make the column required. That is close, but microephysProbes covers icephys as well, and a patch clamp recording in an acute slice has no stereotaxic reference point, so a flat requirement would force those datasets to write n/a.

Instead, I propose requiring anatomical_reference_point when stereotaxic coordinates are present, meaning when any of AP, ML, or DV are given in the same file. That is the condition that actually matters, since the reference point exists to anchor those coordinates, and it handles the slice case correctly. Unlike the species condition it is expressible today: checks can reference columns.<name> of the file under validation, as EMGCoordSysMatch in rules/checks/emg.yaml already does with columns.coordinate_system.

I would also drop "If not specified, Bregma is assumed for rodents". It has the same species-detection problem, and if coordinates are present the column is required, so no default is needed.

[bendichter]

@effigies asked how channel_label differs from description, and looking at the table I do not think it does.

Current Situation

microephysChannels already carries columns that cover this ground. name is required and serves as the index, defined as "Label of the channel". type is required and takes an enum. description is optional, defined as "Brief free-text description of the channel, or other information of interest". channel_label sits alongside them as optional, defined as "Human readable identifier" and intended to specify the content of signals not generated by electrodes.

The examples in its description are the clearest sign of the overlap: DAQ internal synchronization signals, behavioral signals, and behavioral cues. Each of those is already a type value. This BEP itself added SYNC and BEH to the channel type enum, and SYSCLOCK, TRIG, STIM, and MISC were there before it. So the categorical content of those examples belongs in type, and whatever is left over is free text, which is description.

Calling it an identifier makes the overlap worse rather than better, since the identifier for a channel is name, which is required and indexed.

Proposed Change

Remove channel_label. A channel not generated by an electrode sets electrode_name to n/a, takes an appropriate type such as SYNC or BEH, and uses description for anything the type does not capture. That path is already fully specified and needs no additional column.

The one reading that might justify a dedicated column is an alternative identifier that does not fit name. That does not hold up either. name is an unconstrained string with no pattern or character restrictions, so there is nothing to escape from, and the spec already recommends carrying alternative identifier sets as custom columns just below the example tables. That approach also handles datasets with more than one alternative scheme, which a single channel_label column cannot.