Microelectrode Electrophysiology

Support for Microelectrode Electrophysiology was developed as a BIDS Extension Proposal BEP032: Animal electrophysiology (ephys). Please see Citing BIDS on how to appropriately credit this extension when referring to it in the context of the academic literature.

This BEP has been initiated by members of the INCF Working Group on Standardized Data Structures, that was initiated in 2020 to develop a set of specifications and tools that would allow the standardization of a directory structure for experimental data recorded with animal models in neuroscience, and its associated metadata.

Most core principles of the original BIDS and particulars of BIDS-iEEG specification are adopted for this modality as well, though some special considerations and additional fields were added.

Example datasets

Several example Microelectrode Electrophysiology datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.

Primary data file formats

Microelectrode electrophysiology (microephys) modality data (of icephys or ecephys datatypes) must be stored in an open file format, while the native format, if different, can be stored in an optional sourcedata/ directory. The native file format is used in case conversion elicits the loss of crucial metadata specific to manufacturers and specific acquisition systems. Metadata should be included alongside the data in the .json and .tsv files. The current list of allowed data file formats:

Format	Extension(s)	Description
Neuroscience Information Exchange Format	.nix	A generic and open framework with an hdf5 backend and a defined interface to many microephys formats via the Neo library. The .nix file has to contain a valid Neo structure.
Neurodata Without Borders	.nwb	An open data standard for neurophysiology, including data from intracellular and extracellular electrophysiology experiments.

Both of these formats can also store essential metadata of the datasets. Some of this metadata needs to be duplicated in BIDS .tsv and .json sidecar files. Even though the duplication requires additional effort to ensure the consistency of the data, it provides several advantages: - It makes the dataset easier for humans to scan, as essential information is easily accessible without loading the data files. - The dataset adheres to the BIDS standard and can benefit from tools built on top of this standard, such as bids-validator. - It simplifies the separation of data and basic metadata, enabling, for example, the publication of a dataset in a lightweight fashion with access to the data files on request (as implemented by DataLad).

icephys

Template:

sub-<label>/
    [ses-<label>/]
        icephys/
            sub-<label>[_ses-<label>][_sample-<label>]_task-<label>[_acq-<label>][_run-<index>]_channels.json
            sub-<label>[_ses-<label>][_sample-<label>]_task-<label>[_acq-<label>][_run-<index>]_channels.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_space-<label>]_coordsystem.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_icephys.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_icephys.nix
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_icephys.nwb
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_probes.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_probes.tsv

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

ecephys

Template:

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_sample-<label>]_task-<label>[_acq-<label>][_run-<index>]_channels.json
            sub-<label>[_ses-<label>][_sample-<label>]_task-<label>[_acq-<label>][_run-<index>]_channels.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_space-<label>]_coordsystem.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_ecephys.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_ecephys.nix
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_ecephys.nwb
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_probes.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>][_split-<index>]_probes.tsv

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

Participant information

The participants.tsv file is located at the root of the data set directory. Its presence is RECOMMENDED in order to describe information about the individual subjects (animals) from which the data was recorded. It follows the general BIDS specifications to describe participants.

On top of the existing columns that can be present in this file and that are described in the BIDS specifications (participant_id, species, strain, strain_rrid, sex, handedness, and age), we propose to allow adding the following ones:

Microephys specific files

The following metadata files are REQUIRED for a given microephys session:

1. [_ses-<session_label>]_probes.tsv: A REQUIRED file listing information on the device used to acquire the electrophysiology data, such as implant or probe specification, location, material, and others.
2. [_ses-<session_label>]_electrodes.tsv: A REQUIRED file listing information on the points of electrical contact to the tissue, such as impedance, names, relative positions, and others.
3. [_ses-<session_label>]_channels.tsv: A REQUIRED file listing information on the recorded signals, such as preprocessing, filtering, ids, and others.

As with all tsv-based metadata files in BIDS the probes, electrodes and channels tsv files can be accompanied by json sidecar files.

Coordinate System JSON (*_coordsystem.json) & Photos of electrode positions (_photo.jpg)

This file provides metadata on the coordinate system in which the electrodes are placed. This file is RECOMMENDED, and the listed required fields below must be included if a *_coordsystem.json file is provided.

The coordinate system can be defined using reference pictures, anatomical landmarks, brain images, or a reference atlas. For more details, see the BIDS Coordinate Systems specifications.

Fields relating to the microephys probe and electrode positions:

Key name	Requirement Level	Data type	Description
MicroephysCoordinateSystem	REQUIRED	string	Defines the coordinate system for the microelectrode probes. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in "MicroephysCoordinateSystemDescription". If positions correspond to pixel indices in a 2D image (of either a volume-rendering, surface-rendering, operative photo, or operative drawing), this MUST be "Pixels". For more information, see the section on 2D coordinate systems. For a list of valid values for this field, see the associated glossary entry. For a list of valid values for this field, see the associated glossary entry.
MicroephysCoordinateSystemDescription	RECOMMENDED	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.
MicroephysCoordinateUnits	REQUIRED	string	Units of the coordinates of "MicroephysCoordinateSystem". Must be one of: "m", "mm", "cm", "pixels".
MicroephysCoordinateSystemPhoto	OPTIONAL	string	A link to a photo or drawing of the microelectrode probe system.

Allowed 2D coordinate systems

If electrodes are localized in 2D space (only x and y are specified, and z is "n/a"), then the positions in this file MUST correspond to the locations expressed in pixels on the photo, drawing, or rendering of the electrodes on the brain.

In this case, MicroephysCoordinateSystem MUST be defined as "Pixels", and MicroephysCoordinateUnits MUST be defined as "pixels" (note the difference in capitalization).

Furthermore, the coordinates MUST be (row,column) pairs, with (0,0) corresponding to the upper-left pixel and (N,0) corresponding to the lower-left pixel.

Photos of the electrode positions (*_photo.jpg)

These can include photos of the electrodes on the brain surface, photos of anatomical features or landmarks (such as sulcal structures), and fiducials. Photos can also include an X-ray picture, a flatbed scan of a schematic drawing made during surgery, or screenshots of a brain rendering with electrode positions.

The photos may need to be cropped and/or blurred to conceal identifying features or entirely omitted prior to sharing, depending on the obtained consent.

If there are photos of the electrodes, the _acq-<label> entity should be specified with:

• *_photo.jpg for an operative photo.
• *_acq-xray#_photo.<extension> for an X-ray picture.
• *_acq-drawing#_photo.<extension> for a drawing or sketch of electrode placements.
• *_acq-render#_photo.<extension> for a rendering.

The file <extension> for photos MUST be either .jpg, .png, or .tif.

The ses-<label> entity may be used to specify when the photo was taken.

Multiple coordinate systems

The optionalspace-<label> entity (*[_space-<label>]_coordsystem.json) can be used to indicate how to interpret the electrode positions. The space <label> MUST be taken from one of the modality specific lists in the Coordinate Systems Appendix. For example for iEEG data, the restricted keywords listed under iEEG Specific Coordinate Systems are acceptable for <label>.

Probes (*_probes.tsv)

Probes are physical devices used for recording microephys data. They can be permanently implanted (chronic recordings) or inserted temporarily for the recording (acute recordings).

The probe positions and properties are stored in a .tsv file. This file contains the probe ID, the type of recording (acute/chronic), and the probe coordinates. The surgical coordinates of the probe can be described using AP, DV, LR, yaw, pitch, and roll.

These measurements follow the convention of the Pinpoint software for surgical planning and are intended to describe the surgical plan:

Translational Coordinates

• (0,0,0) is assumed to be Bregma when working with rodents.
• It may optionally be defined differently and must be defined for other species.
• x, y, z represents posterior, ventral, and right directions, respectively, in micrometers (µm).

Rotation

• (0,0,0) corresponds to the probe facing up with the tip pointing forward.
• Rotations are measured in degrees, clockwise, and around the tip.
• For multi-shank probes, the “tip” of the probe is defined as the end of the left shank when facing the electrodes.

Rotation Definitions:

• Yaw: Clockwise rotation when looking down.
• Pitch: Rotation in the direction of the electrode face.
• Roll: Clockwise rotation when looking down at the probe.

ProbeInterface Library

ProbeInterface is a library that defines a standard for specifying electrode layouts on probes. The ProbeInterface library includes layouts for many common probes.

The ProbeInterface model corresponding to your probe can be referenced using:

• probeinterface_manufacturer
• probeinterface_model

If provided, these should point to a ProbeInterface model in the ProbeInterface library, at the location:

Column name	Requirement Level	Data type	Description
probe_id	REQUIRED	string	A unique identifier of the probe, can be identical with the device_serial_number. (expected to match probe_ids listed in *_eletrodes.tsv). Values in probe_id MUST be unique. This column must appear first in the file.
type	REQUIRED	string	The type of the probe. This column must appear second in the file.
x	RECOMMENDED	number	Probe position along the global coordinate system x-axis. This column must appear third in the file.
y	RECOMMENDED	number	Probe position along the global coordinate system y-axis. This column must appear fourth in the file.
z	RECOMMENDED	number	Probe position along the global coordinate system z-axis. This column must appear fifth in the file.
manufacturer	RECOMMENDED	string	Manufacturer of the probes system (for example, 'openephys', 'alphaomega','blackrock'). This column may appear anywhere in the file.
device_serial_number	RECOMMENDED	string	The serial number of the probe (provided by the manufacturer). This column may appear anywhere in the file.
electrode_count	OPTIONAL	number	Number of miscellaneous analog electrodes for auxiliary signals (for example, '2'). This column may appear anywhere in the file.
width	OPTIONAL	number	Physical width of the probe, for example, '5'. This dimension corresponds to the x’axis of the Euler transformation defined by alpha, beta and gamma rotations values. This column may appear anywhere in the file.
height	OPTIONAL	number	Physical height of the probe, for example, '5'. This dimension corresponds to the y’axis of the Euler transformation defined by alpha, beta and gamma rotations values below. This column may appear anywhere in the file.
depth	OPTIONAL	number	Physical depth of the probe, for example, '0.3'. This dimension should be omitted or set to 0 for two-dimensional (shank-type) probes. This dimension corresponds to the z’axis of the Euler transformation defined by alpha, beta and gamma rotations values. This column may appear anywhere in the file.
dimension_unit	OPTIONAL	string	Units of the physical dimensions 'width', 'height' and 'depth' of the probe. For example, mm. This column may appear anywhere in the file.
yaw	RECOMMENDED	number	Rotation clockwise when looking down. This column may appear anywhere in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
pitch	RECOMMENDED	number	Rotation in the direction of the electrode face, in degrees. This column may appear anywhere in the file. Must be a number greater than or equal to -90 and less than or equal to 90.
roll	RECOMMENDED	number	Clockwise rotation when looking down at the probe. This column may appear anywhere in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
coordinate_reference_point	RECOMMENDED	string	Point of the probe that is described by the probe coordinates and on which the alpha, beta and gamma rotations are applied. This column may appear anywhere in the file.
hemisphere	RECOMMENDED	string	Hemisphere in which the probe is placed. This column may appear anywhere in the file. Must be one of: "L", "R".
associated_brain_region	RECOMMENDED	string	A textual indication on the location of the probe, preferably species-independent terms as obtained, for example from Uberon. This column may appear anywhere in the file.
associated_uberon_brain_region_id	RECOMMENDED	number	An identifier of the associated brain region based on the Uberon ontology for anatomical structures in animals, for example "UBERON:0010415" This column may appear anywhere in the file.
associated_brain_region_quality_type	RECOMMENDED	string	The method used to identify the associated brain region (estimated
reference_atlas	RECOMMENDED	string	Name of reference atlas used for associated brain region identification, preferably an ebrains supported atlas. This column may appear anywhere in the file.
material__probes	OPTIONAL	string	A textual description of the base material of the probe. This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Example of _probes.tsv:

probe_id	hemisphere	x	y	z	type	material	location
p023	left	-11.87	-1.3	-3.37	utah-array	iridium-oxide	V1
p023	left	-11.64	0.51	-4.2	utah-array	iridium-oxide	V2
p021	left	-12.11	-3.12	-2.54	utah-array	iridium-oxide	V4
p021	left	-9.94	-1.19	-2.86	utah-array	iridium-oxide	V3

Electrodes (*_electrodes.tsv)

Electrodes describe the points of contact between the electrodes and the tissue used for recording electrophysiological signals.

The electrode positions and properties are stored in a .tsv file (amplifier information is in channels.tsv).

This file contains the following information: - The electrode name - The electrode coordinates in 3 columns (xyz) (use n/a for values if a dimension is absent) - The ID of the probe the electrode is located on

The coordinates are relative to the position on the probe.

Column name	Requirement Level	Data type	Description
electrode_id	REQUIRED	string	A unique identifier of the electrode. (expected to match electrode_ids listed in *_channels.tsv). Values in electrode_id MUST be unique. This column must appear first in the file.
probe_id	REQUIRED	string	A unique identifier of the probe, can be identical with the device_serial_number. (expected to match probe_ids listed in *_eletrodes.tsv). This column must appear second in the file.
hemisphere	RECOMMENDED	string	The hemisphere in which the electrode is placed. This column must appear third in the file. Must be one of: "L", "R".
x	RECOMMENDED	number	Recorded position along the local width-axis relative to the probe origin and rotation (see _probes.tsv) This column must appear fourth in the file.
y	RECOMMENDED	number	Recorded position along the local height-axis relative to the probe origin and rotation (see _probes.tsv) This column must appear fifth in the file.
z	RECOMMENDED	number	Recorded position along the local depth-axis relative to the probe origin and rotation (see _probes.tsv) This column must appear sixth in the file.
impedance	RECOMMENDED	number	Impedance of the electrode, units MUST be in kOhm. This column may appear anywhere in the file.
shank_id	OPTIONAL	string	A unique identifier to specify which shank of the probe the electrode is on. This is useful for spike sorting when the electrodes are on a multi-shank probe. This column may appear anywhere in the file.
size	OPTIONAL	number	Surface area of the electrode, units MUST be in mm^2. This column may appear anywhere in the file.
electrode_shape	OPTIONAL	string	Description of the shape of the electrode (for example, square, circle). This column may appear anywhere in the file.
material	OPTIONAL	string	Material of the electrode (for example, Tin, Ag/AgCl, Gold). This column may appear anywhere in the file.
location	RECOMMENDED	string	An indication on the location of the electrode (for example, cortical layer 3, CA1). This column may appear anywhere in the file.
pipette_solution	OPTIONAL	string	The solution used to fill the pipette. See also [openMINDS Pipette] (https://github.com/openMetadataInitiative/openMINDS_ephys/blob/v1/schemas/device/pipetteUsage.schema.tpl.json). This column may appear anywhere in the file.
internal_pipette_diameter	OPTIONAL	number	The internal diameter of the pipette in micrometers. This column may appear anywhere in the file.
external_pipette_diameter	OPTIONAL	number	The external diameter of the pipette in micrometers. This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Example of * _electrodes.tsv:

probe_id	impedance	x	y	z	material	location
p023	1.1	-11.87	-1.3	-3.37	iridium-oxide	V1
p023	1.5	-11.64	0.51	-4.2	iridium-oxide	V2
p021	3.5	-12.11	-3.12	-2.54	iridium-oxide	V4
p021	7	-9.94	-1.19	-2.86	iridium-oxide	V3

Channels (*_channels.tsv)

Channels are virtual sources of recorded signals. These may be of neuronal origin (for example, online filtered LFP signals) or generated by the recording setup (for example, synchronization or behavioral signals).

The channel properties are stored in a .tsv file. This file contains the following information:

• channel_id
• electrode_id (in the case of neuronal signals)
• Amplifier information
• …

For more information about the distinction between electrodes and channels, see the corresponding section in iEEG.

Columns in the *_channel.tsv file are:

Column name	Requirement Level	Data type	Description
channel_id	REQUIRED	string	Unique identifier of the channel, only containing letters and numbers. This id must be reflected in the data files, for example, as signal annotations in the nix file. When inserting existing nwb files into a BIDS structure, one can combine the nwb record_id and channel_index to create this unique identifier. Values in channel_id MUST be unique. This column must appear first in the file.
reference	REQUIRED	string	Name of the electrode used as physical reference. For example, electrode_id, physical location (subdural, chamber screw). This column must appear second in the file.
type	REQUIRED	string	Type of channel; MUST use the channel types listed below. Note that the type MUST be in upper-case. This column must appear third in the file. For a list of valid values for this column, see the associated glossary entry.
units	REQUIRED	string	Physical unit of the value represented in this channel, for example, V for Volt, or uV for micro Volt (see Units). This column must appear fourth in the file.
sampling_frequency	OPTIONAL	number	Sampling rate of the channel in Hz. This column must appear fifth in the file.
channel_label	OPTIONAL	string	Human readable identifier. Use this name to specify the content of signals not generated by electrodes. For example, 'DAQ internal synchronization signals', 'behavioral signals', 'behavioral cues'. This column may appear anywhere in the file.
stream_id	OPTIONAL	string	Data stream of the recording the signal. This column may appear anywhere in the file.
description	OPTIONAL	string	Brief free-text description of the channel, or other information of interest. This column may appear anywhere in the file.
hardware_filters	RECOMMENDED	string or "n/a"	List of hardware (amplifier) filter keys applied. Note that parameters should be defined in the general microephys sidecar .json file. Indicate n/a in the absence of hardware filters applied. This column may appear anywhere in the file.
software_filters	RECOMMENDED	string	List of temporal and/or spatial software filters applied (for example, SSS, SpatialCompensation). Note that parameters should be defined in the general MEG sidecar .json file. Indicate n/a in the absence of software filters applied. This column may appear anywhere in the file.
status	OPTIONAL	string	Data quality observed on the channel. A channel is considered bad if its data quality is compromised by excessive noise. If quality is unknown, then a value of n/a may be used. Description of noise type SHOULD be provided in [status_description]. This column may appear anywhere in the file. Must be one of: "good", "bad".
status_description	OPTIONAL	string	Freeform text description of noise or artifact affecting data quality on the channel. It is meant to explain why the channel was declared bad in the status column. This column may appear anywhere in the file.
gain	RECOMMENDED	number	Amplification factor applied from signal detection at the electrode to the signal stored in the data file. If no gain factor is provided it is assumed to be 1. This column may appear anywhere in the file.
time_offset	OPTIONAL	number	Time shift between signal of this channel to a reference channel in seconds. This column may appear anywhere in the file.
time_reference_channel	OPTIONAL	string	Name of the channel that is used for time alignment of signals. This column may appear anywhere in the file.
ground	OPTIONAL	string	Information on the ground. For example, 'chamber screw', 'head post', 'ear clip'. Only should be used to OPTIONALly override the global ground in the _ecephys.json or _icephys.json file. This column may appear anywhere in the file.
recording_mode	RECOMMENDED	string	The mode of recording for patch clamp datasets (for example, voltage clamp, current clamp). This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Example of * _channels.tsv:

channel_id	electrode_id	gain	type	units	sampling_frequency	status
c0123	con0123	30	EXT	mV	30000	good
c234	con234	30	EXT	mV	30000	good
c934	con934	50	EXT	mV	30000	bad
c234	n/a	1	SYNC	mV	1000	good

Note: In many datasets multiple sets of identifiers are used for probes, electrodes and channels. We RECOMMEND to include alternative sets of identifiers, for instance identifiers that enumerate electrodes according to their spatial arrangement, as additional custom columns in the .tsv file.

Recommended Channel Type Values

For the type column we recommend to use the following terms (adopted from iEEG)

Keyword	Description
LFP	Low-pass filtered extracellular voltage signal that represents local field potentials
HP	High-pass filtered extracellular voltage signal as used for spike sorting
MUA	High-pass filtered and rectified or thresholded extracellular voltage signal that represents an estimate of multi-unit activity
BB	Unfiltered (broadband) extracellular voltage signal
SPIKES	Discrete signal indicating spike events as derived from spike detection or spike sorting
VM	Membrane voltage
IM	Membrane current
SYNC	Signal used for synchronization between different recording systems / channels
STIM	Electrical stimulation
EEG	Electrode channel from electroencephalogram
ECOG	Electrode channel from electrocorticogram (intracranial)
SEEG	Electrode channel from stereo-electroencephalogram (intracranial)
DBS	Electrode channel from deep brain stimulation electrode (intracranial)
VEOG	Vertical EOG (electrooculogram)
HEOG	Horizontal EOG
EOG	Generic EOG channel if HEOG or VEOG information not available
ECG	ElectroCardioGram (heart)
EMG	ElectroMyoGram (muscle)
TRIG	System Triggers
AUDIO	Audio signal
PD	Photodiode
EYEGAZE	Eye Tracker gaze
PUPIL	Eye Tracker pupil diameter
BEH	Behavioral signals
MISC	Miscellaneous
SYSCLOCK	System time showing elapsed time since trial started
ADC	Analog to Digital input
DAC	Digital to Analog output
REF	Reference channel
OTHER	Any other type of channel

General microephys metadata (*_{i,e}cephys.json)

We propose to store all metadata that is not directly related to one of the other metadata files (probe/electrode/channel information) into a single JSON file: _ephys.json.

There should be one such JSON file for each data file.

The *_ephys.json file can be used to store any microephys-specific metadata for the dataset. We recommend storing all setup-related metadata in a dedicated node of the JSON file called Setup. We recommend using the following keys to describe the setup:

Data origin metadata

Key name	Requirement Level	Data type	Description
InstitutionName	RECOMMENDED	string	The name of the institution in charge of the equipment that produced the measurements.
InstitutionAddress	RECOMMENDED	string	The address of the institution in charge of the equipment that produced the measurements.
InstitutionalDepartmentName	RECOMMENDED	string	The department in the institution in charge of the equipment that produced the measurements.

Setup metadata

Key name	Requirement Level	Data type	Description
PowerLineFrequency	REQUIRED	number or "n/a"	Frequency (in Hz) of the power grid at the geographical location of the instrument (for example, 50 or 60).
Manufacturer	RECOMMENDED	string	Manufacturer of the equipment that produced the measurements. For example, "TDT", "Blackrock".
ManufacturersModelName	RECOMMENDED	string	Manufacturer's model name of the equipment that produced the measurements.
ManufacturersModelVersion	RECOMMENDED	string	Manufacturer's model version of the equipment that produced the measurements.
RecordingSetupName	RECOMMENDED	string	Custom name of the recording setup.
SamplingFrequency	REQUIRED	number	Sampling frequency (in Hz) of all the data in the recording, regardless of their type (for example, 2400). Internal (maximum) sampling frequency (in Hz) of the recording (for example, "24000").
DeviceSerialNumber	RECOMMENDED	string	The serial number of the equipment that produced the measurements. A pseudonym can also be used to prevent the equipment from being identifiable, so long as each pseudonym is unique within the dataset. The serial number of the components of the setup, RECOMMENDED to add serial numbers and versions of ALL components constituting the setup.
SoftwareName	RECOMMENDED	string	Name of the software that was used to present the stimuli. The name of the software suite used to record the data.
SoftwareVersions	RECOMMENDED	string	Manufacturer's designation of software version of the equipment that produced the measurements.

Processing metadata

Key name	Requirement Level	Data type	Description
SoftwareFilters	REQUIRED	object of objects or "n/a"	Object of temporal software filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs (for example, {"Anti-aliasing filter": {"half-amplitude cutoff (Hz)": 500, "Roll-off": "6dB/Octave"}}).
HardwareFilters	RECOMMENDED	object of objects or "n/a"	Object of temporal hardware filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs. For example, {"Highpass RC filter": {"Half amplitude cutoff (Hz)": 0.0159, "Roll-off": "6dB/Octave"}}.

Additional recording procedure

Furthermore, additional information can be stored about the recording procedure. We RECOMMEND to use a dedicated Procedure node with the following keys:

• Pharmaceuticals
• Sample
• Supplementary

Pharmaceuticals

For each pharmaceutical we RECOMMEND to use a dedicated node with the name of the Pharmaceuticals containing the following administration details:

Key name	Requirement Level	Data type	Description
PharmaceuticalName	RECOMMENDED	string	Name of pharmaceutical coadministered with tracer.
PharmaceuticalDoseAmount	RECOMMENDED	number or array of numbers	Dose amount of pharmaceutical coadministered with tracer.
PharmaceuticalDoseUnits	RECOMMENDED	string	Unit format relating to pharmaceutical dose (for example, "mg" or "mg/kg").
PharmaceuticalDoseRegimen	RECOMMENDED	string	Details of the pharmaceutical dose regimen. Either adequate description or short-code relating to regimen documented elsewhere (for example, "single oral bolus").
PharmaceuticalDoseTime	RECOMMENDED	number or array of numbers	Time of administration of pharmaceutical dose, relative to time zero. For an infusion, this should be a vector with two elements specifying the start and end of the infusion period. For more complex dose regimens, the regimen description should be complete enough to enable unambiguous interpretation of "PharmaceuticalDoseTime". Unit format of the specified pharmaceutical dose time MUST be seconds.

Sample

Key name	Requirement Level	Data type	Description
BodyPart	RECOMMENDED	string	Body part of the organ / body region scanned.
BodyPartDetails	RECOMMENDED	string	Additional details about body part or location (for example: "corpus callosum").
BodyPartDetailsOntology	OPTIONAL	string	URI of ontology used for BodyPartDetails (for example: "https://www.ebi.ac.uk/ols/ontologies/uberon").
SampleEnvironment	RECOMMENDED	string	Environment in which the sample was imaged. MUST be one of: "in vivo", "ex vivo" or "in vitro". Must be one of: "in vivo", "ex vivo", "in vitro".
SampleEmbedding	OPTIONAL	string	Description of the tissue sample embedding (for example: "Epoxy resin").
SliceThickness	OPTIONAL	number	Slice thickness of the tissue sample in the unit micrometers ("um") (for example: 5). Must be a number greater than 0.
SampleExtractionProtocol	OPTIONAL	string	Description of the sample extraction protocol or URI (for example from protocols.io).

Supplementary

Key name	Requirement Level	Data type	Description
SupplementarySignals	OPTIONAL	string	Description of the supplementary signal (additional modalities) recorded in parallel and are also stored in the data file.

Probes

It is RECOMMENDED to use the following structure to provide more metadata for each probe:

"ProbeContours": {
   "probe_infoid": {
      "<my_probe_id>": {
         "Contour": "<list of contour points>",
         "Unit": "<my spatial unit>"
      }
   }
}

Whereas <my_probe_id> has to exist also in the probes.tsv file and <list of contour points> is a list of x, y(, z) tuples providing the contour of the probe in the same reference frame as the electrode coordinates (see electrodes.tsv). In case of different units used than in the electrodes.tsv, the key Unit can be used here to provide the spatial unit of the coordinate points.

Task (see also iEEG.json)

If the OPTIONAL task-<label> is used, the following metadata SHOULD be used.

Key name	Requirement Level	Data type	Description
TaskName	RECOMMENDED	string	Name of the task. No two tasks should have the same name. The task label included in the filename is derived from this "TaskName" field by removing all non-alphanumeric characters (that is, all except those matching [0-9a-zA-Z]). For example "TaskName" "faces n-back" or "head nodding" will correspond to task labels facesnback and headnodding, respectively. A RECOMMENDED convention is to name resting state task using labels beginning with rest.
TaskDescription	RECOMMENDED	string	Longer description of the task.
Instructions	RECOMMENDED	string	Text of the instructions given to participants before the recording. This is especially important in context of resting state recordings and distinguishing between eyes open and eyes closed paradigms.
CogAtlasID	RECOMMENDED	string	URI of the corresponding Cognitive Atlas Task term.
CogPOID	RECOMMENDED	string	URI of the corresponding CogPO term.

Example of * _ephys.json:

{
  "PowerLineFrequency": 50,
  "Manufacturer": "OpenEphys",
  "ManufacturerModelName": "OpenEphys Starter Kit",
  "ManufacturerModelVersion": "OEPS-9031",
  "SamplingFrequency": 30000,
  "SamplingFrequencyUnit": "Hz",
  "Location": "Institut de Neurosciences de la Timone, Faculté de Médecine, 27, boulevard Jean Moulin, 13005 Marseille - France",
  "Software": "Cerebus",
  "SoftwareVersion": "1.5.1",
  "Creator": "John Doe",
  "Maintainer": "John Doe jr.",
  "Procedure": {
    "Pharmaceuticals": {
      "isoflurane": {
        "PharmaceuticalName": "isoflurane",
        "PharmaceuticalDoseAmount": 50,
        "PharmaceuticalDoseUnit": "ug/kg/min"
      },
      "ketamine": {
        "PharmaceuticalName": "ketamine",
        "PharmaceuticalDoseAmount": 0.1,
        "PharmaceuticalDoseUnit": "ug/kg/min"
      }
    },
    "Sample": {
      "BodyPart": "BRAIN",
      "BodyPartDetails": "Motor Cortex"
    },
    "ProbeContours": {
      "p021": {
        "Contour": [
          [0, 0, 0],
          [0, 10, 0],
          [1, 11, 0],
          [2, 10, 0],
          [2, 0, 0]
        ],
        "Unit": "mm"
      }
    },
    "TaskName": "Reach-to-Grasp",
    "TaskDescription": "A task that involves the reaching of an object and holding it for a specific time"
  }
}

Recording Events (*_events.tsv)

The *_events.tsv and corresponding *_events.json sidecar files are OPTIONAL and can be used to indicate time points of recording events. Each task events file requires a corresponding task data file. These events can be internal recording system events, task-related events, or events triggered by the experimentalist (for example, manual reward). Note that these events must share a common clock with the corresponding microephys recording data. For more details, see the Task Events documentation. Note that this file can also be used to describe stimulation performed during the recording. For this, please follow the iEEG stimulation documentation.

Multi-part recordings

Two different procedures are supported to handle multi-part recordings. The two options are:

1. each recording is stored in an independent data file, and the corresponding metadata is described in the *_scans.tsv file; or
2. several recordings are stored in a single data file, and the corresponding metadata is described in the *_events.tsv file.

These two options are made available to support different usages and habits of the experimenters, as well as to benefit from the capability of the supported data formats (NWB and NIX). They are described in the following subsections, and made explicit through some of the example data sets.

Multiple tasks / runs in separate files (*_scans.tsv)

The *_scans.tsv should be used to provide information about multiple parts of an acquisition session (for example, recording start times in case the recording was paused and restarted) when the data from each of these different recordings is stored in separate files. Each data file should have a name that contains a _task-XX and/or _run-XX suffix, and should be described by at most one row in the *_scans.tsv file. See also the BIDS Scans specification. Relative paths to files should be used under a compulsory “filename” header. If acquisition time is included, it should be with the “acq_time” header. Datetime should be expressed in the following format 2009-06-15T13:45:30 (year, month, day, hour (24h), minute, second; this is equivalent to the RFC3339 “date-time” format, time zone is always assumed as local time). The run and task keywords and the corresponding *_scans.tsv file are OPTIONAL and can be ignored if the dataset consists of only one continuous recording and a single or no task.

Optional: Yes

Example of * _scans.tsv:

filename	acq_time
ephys/sub-P001_task-pull_run-01_ephys.nix	2018-07-15T09:45:30
ephys/sub-P001_task-pull_run-02_ephys.nix	2018-07-15T13:24:00
ephys/sub-P001_task-push_run-01_ephys.nix	2018-07-15T14:24:00
ephys/sub-P001_task-push_run-02_ephys.nix	2018-07-15T15:24:00

It is recommended to accompany the *_scans.tsv file with a corresponding *_scans.json sidecar file, as described in the BIDS specifications.

Multiple recordings in a single data file (*_events.tsv)

The *_events.tsv should be used to provide information about multiple parts of an acquisition session when the data from each of these different recordings is stored in a single data file. In such a case, this file is REQUIRED. This allows benefiting from the capability of the supported data formats (NIX and NWB) to store multiple recordings in a single file, which can be convenient when these recordings share numerous characteristics (for example, for subsequent recordings obtained on a single cell in intracellular electrophysiology). In such case, the information about these recordings should be stored in columns added in the *_events.tsv file, which are listed now.

Optional column names in events.tsv to support multiple recordings in a single data file:

Microelectrode Electrophysiology Examples

Toy datasets

Extracellular Electrophysiology

This dataset contains data from a single subject (subject A), that was recorded on two days (2022-01-01 and 2022-01-02). On the first day it performed two tasks (nose-poke & rest), and on the second day only a rest task was performed. Detailed information about these tasks can be found in the tasks.tsv and tasks.json files. The electrophysiology data for each of the three recordings are stored in the corresponding session and microephys directories in the nix format. Metadata about the probes, their electrodes and the corresponding recording channels are stored in tsv format. Note that in this case, this information is shared between data files (see BIDS Inheritance Principle): in the first session, the probe, electrode and channel files apply to both data files of that session, as they do not contain a task entity in their name. For the nose-poke task, additional behavioral timestamps (events) were recorded and stored in an additional events.tsv file.

├─ dataset_description.json 
├─ tasks.tsv 
├─ tasks.json 
├─ participants.tsv 
└─ sub-A/
   ├─ ses-20220101/
   │  └─ ecephys/
   │     ├─ sub-A_ses-20220101_task-nosepoke_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-nosepoke_ecephys.json 
   │     ├─ sub-A_ses-20220101_task-nosepoke_events.tsv 
   │     ├─ sub-A_ses-20220101_task-rest_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-rest_ecephys.json 
   │     ├─ sub-A_ses-20220101_channels.tsv 
   │     ├─ sub-A_ses-20220101_electrodes.tsv 
   │     └─ sub-A_ses-20220101_probes.tsv 
   └─ ses-20220102/
      └─ ecephys/
         ├─ sub-A_ses-20220102_task-rest_ecephys.nix 
         ├─ sub-A_ses-20220102_task-rest_ecephys.json 
         ├─ sub-A_ses-20220102_channels.tsv 
         ├─ sub-A_ses-20220102_electrodes.tsv 
         └─ sub-A_ses-20220102_probes.tsv 

Intracellular Electrophysiology (Patch)

This dataset contains intracellular data from slices acquired from two subjects (20220101-A and 20220101B). Details about the subjects and the sample generation are documented in the samples (tsv/json) files. Data of each subject is stored in separate subject directories (top level directories), each of which contains an ‘icephys/’ subdirectory. Note that there is no session-level directory in this case. Here, we choose the option of having “multiple tasks/runs in separate files” as described in 3.81., to demonstrate the high level of readability offered by the filenames in this case.

For the first subject only a single sample (a cell for patch-clamp terminology) was extracted (sample-cell001), on which two recordings (runs 1 and 2) were performed. Here, the scans.tsv file can be used to store information such as the starting recording times. The detailed information on the recording channel (such as the recording mode used) is stored in the channels.tsv which, in this case, is common to all available recordings. The probes and electrodes files provide information on the pipette and solutions used for the recordings and are also shared for the two data files.

For the second subject two samples (sample-cell003 and sample-cell004) were extracted and a single recording performed on each of them. Each recording was performed using a different probe (listed in the probes.tsv) having specific electrode and channel information. Therefore, each data file has a dedicated channel and electrode file with the same name as the data file.

├─ samples.tsv 
├─ samples.json 
├─ participants.tsv 
├─ dataset_description.json 
├─ sub-20220101A/
│  ├─ sub-20220101A_sample-cell001_scans.tsv 
│  └─ icephys/
│     ├─ sub-20220101A_sample-cell001_run-1_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_run-1_events.tsv 
│     ├─ sub-20220101A_sample-cell001_run-2_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_run-2_events.tsv 
│     ├─ sub-20220101A_channels.tsv 
│     ├─ sub-20220101A_electrodes.tsv 
│     ├─ sub-20220101A_probes.tsv 
│     ├─ sub-20220101A_icephys.json 
│     └─ sub-20220101A_events.json 
└─ sub-20220101B/
   ├─ sub-20220101B_sample-cell001_scans.tsv 
   └─ icephys/
      ├─ sub-20220101B_sample-cell002_icephys.nwb 
      ├─ sub-20220101B_sample-cell002_events.tsv 
      ├─ sub-20220101B_sample-cell002_channels.tsv 
      ├─ sub-20220101B_sample-cell002_electrodes.tsv 
      ├─ sub-20220101B_sample-cell003_icephys.nwb 
      ├─ sub-20220101B_sample-cell003_events.tsv 
      ├─ sub-20220101B_sample-cell003_channels.tsv 
      ├─ sub-20220101B_sample-cell003_electrodes.tsv 
      ├─ sub-20220101B_probes.tsv 
      ├─ sub-20220101B_icephys.json 
      └─ sub-20220101B_events.json 

This toy data set can be found in this repository, with the content of the metadata files. The other option available to organize such data consists in storing several recordings in a single data file (as described in 3.8.2); the same data set is presented using this latter option in this other repository, so that both options can be compared for the same data set.

Examples of real datasets

Multiple datasets have been converted to follow this BEP proposal. These datasets typically have pruned data files to reduce the data file size, but are accompanied by the full set of metadata. 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) 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 here:

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