Skip to content

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 was initiated by members of the INCF Working Group on Standardized Data Structures in 2020 to develop specifications and tools for standardizing experimental data recorded with animal models in neuroscience and its associated metadata.

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.

Terminology: Modality and Datatypes

The Microelectrode Electrophysiology modality encompasses recordings made with micrometer-scale electrodes, distinguishing it from related BIDS modalities (EEG, MEG, iEEG) that use larger electrodes. This modality is primarily used in animal research.

Within this modality, BIDS defines two datatypes based on fundamentally different recording techniques (see Issue #1800):

  • ecephys (Extracellular Electrophysiology): Electrodes remain in the extracellular space, measuring field potentials (μV) from nearby neurons without membrane penetration. Examples: Neuropixels probes, tetrodes, multi-electrode arrays.

  • icephys (Intracellular Electrophysiology): Electrodes penetrate or attach to cell membranes to directly measure intracellular potentials (mV) and cellular dynamics. Examples: cell-attached patch clamp, whole-cell patch clamp, sharp electrode recordings.

These datatypes differ in recording technique, signal amplitude, required metadata (for example, pipette_solution and recording_mode for icephys; probe geometry for ecephys), and analysis pipelines. The terms are established and used in Neurodata Without Borders (NWB).

Both datatypes share a unified BIDS structure (probes, electrodes, channels) with technique-specific optional metadata fields. Files are organized into ecephys/ or icephys/ subdirectories with corresponding file suffixes.

Primary Data File Formats

Microelectrode electrophysiology 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:

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

  • <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

  • <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

  • 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:

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

  • <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

  • <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

  • 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.

Sidecar JSON (*_icephys.json and *_ecephys.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 corresponding to the datatype: _icephys.json or _ecephys.json for intracellular and extracellular correspondingly.

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:

Institution Information

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 Information

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 Information

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 Procedure Information

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.

Task Information

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 MAY be derived from this "TaskName" field by removing all non-alphanumeric or + characters (that is, all except those matching [0-9a-zA-Z+]), and potentially replacing spaces with + to ease readability. For example "TaskName" "faces n-back" or "head nodding" could correspond to task labels faces+n+back or facesnback and head+nodding or 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 *_ecephys.json

{
  "InstitutionName": "Example University",
  "InstitutionAddress": "123 Main St, City, State 12345, Country",
  "InstitutionalDepartmentName": "Neuroscience Department",
  "PowerLineFrequency": 60,
  "Manufacturer": "ExampleManufacturer",
  "ManufacturersModelName": "Model-XYZ",
  "SamplingFrequency": 30000,
  "SoftwareName": "RecordingSoftware",
  "SoftwareVersions": "1.0.0",
  "SoftwareFilters": {
    "LowpassFilter": {
      "Half-amplitude cutoff (Hz)": 300,
      "Roll-off": "6dB/Octave"
    }
  },
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "PharmaceuticalName": ["anesthetic1", "anesthetic2"],
  "PharmaceuticalDoseAmount": [1.5, 10],
  "PharmaceuticalDoseUnits": ["percent", "mg/kg"],
  "BodyPart": "BRAIN",
  "BodyPartDetails": "Motor Cortex",
  "SampleEnvironment": "in-vivo",
  "TaskName": "ExampleTask",
  "TaskDescription": "Description of the experimental task"
}

Example *_icephys.json

{
  "InstitutionName": "Example Institute",
  "InstitutionAddress": "456 Science Ave, City, State 67890, Country",
  "PowerLineFrequency": 60,
  "Manufacturer": "PatchClampManufacturer",
  "ManufacturersModelName": "Amplifier-ABC",
  "SamplingFrequency": 20000,
  "SoftwareName": "PatchSoftware",
  "SoftwareVersions": "2.1.0",
  "SoftwareFilters": {
    "BesselFilter": {
      "Half-amplitude cutoff (Hz)": 10000,
      "Roll-off": "12dB/Octave"
    }
  },
  "BodyPart": "BRAIN",
  "BodyPartDetails": "Visual Cortex",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "TaskName": "MembraneProperties",
  "TaskDescription": "Characterization of intrinsic properties"
}

Coordinate Systems for Electrode Positions

Microelectrode electrophysiology supports two approaches for specifying electrode positions:

Default: Probe-Relative Coordinates

By default, when no space-<label> entity is used:

  • *_electrodes.tsv: Electrode positions (x, y, z) are relative to the probe origin
  • *_coordsystem.json: NOT REQUIRED (probe-relative is the default)
  • The probe origin (0, 0, 0) is typically at the probe tip or a standard reference point
  • The reference point can be specified in the coordinate_reference_point column of *_probes.tsv
  • Units can be specified in the dimension_unit column of *_probes.tsv

This is the most common case for in-vivo recordings where absolute anatomical localization is not available.

Optional: Anatomical Coordinate Systems

When electrode positions are known in anatomical or stereotaxic space:

  • *_space-<label>_electrodes.tsv: Electrode positions in the specified coordinate system
  • *_space-<label>_coordsystem.json: REQUIRED to define the coordinate system
  • Examples of <label> values include StereoTaxic, AllenCCFv3, PaxinosWatson, individual, or other standard spaces listed in the Coordinate Systems Appendix

Multiple coordinate systems can coexist in the same dataset.

Example file structure with both probe-relative and stereotaxic coordinates:

└─ sub-01/
   └─ ses-01/
      └─ ecephys/
         ├─ sub-01_ses-01_electrodes.tsv 
         ├─ sub-01_ses-01_space-StereoTaxic_electrodes.tsv 
         ├─ sub-01_ses-01_space-StereoTaxic_coordsystem.json 
         └─ sub-01_ses-01_probes.tsv 

Channels description (*_channels.tsv)

Channels are 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. It should contain information about reference electrodes, amplifier, filtering, time alignment and other metadata pertinent to the data for each channel.

This table stores information about the recorded signals, not the electrodes. The distinction is particularly important in cases where multiple signals are recorded from a single electrode (such as Neuropixel probes). For more information about the distinction between electrodes and channels, see the corresponding section in iEEG.

Columns in the *_channels.tsv file are:

Column name Requirement Level Data type Description
name REQUIRED string Label of the channel.

Values in name 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 *_channels.tsv

Extracellular electrophysiology example:

tsv name reference type units sampling_frequency hardware_filters software_filters gain status status_description ch001 ref01 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a ch002 ref01 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a ch003 ref01 HP uV 30000 HighpassFilter n/a 500 good n/a ch004 ref01 HP uV 30000 HighpassFilter n/a 500 bad high_noise ch005 ref02 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a ch006 n/a SYNC V 30000 n/a n/a 1 good n/a

Intracellular electrophysiology example:

tsv name type units sampling_frequency recording_mode gain ground status patch01 VM mV 20000 current-clamp 10 AgCl good patch02 VM mV 20000 current-clamp 10 AgCl good patch03 IM pA 20000 voltage-clamp 5 AgCl 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.

For the type column we recommend to use the following terms (adapted 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

Electrodes description (*_electrodes.tsv)

Electrodes are the physical recording sites that make electrical contact with neural tissue to capture 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). By default, this is the position on the probe (not the brain).
  • The ID of the probe the electrode is located on
Column name Requirement Level Data type Description
name REQUIRED string Name of the electrode contact point.

Values in name MUST be unique.

This column must appear first in the file.
probe_name REQUIRED string A unique identifier of the probe, can be identical with the device_serial_number. (expected to match probe_name listed in *_electrodes.tsv).

This column must appear second in the file.
hemisphere REQUIRED string The hemisphere in which the electrode is placed.

This column must appear third in the file.

Must be one of: "L", "R".
x REQUIRED number Recorded position along the x-axis.

This column must appear fourth in the file.
y REQUIRED number Recorded position along the y-axis.

This column must appear fifth in the file.
z REQUIRED number Recorded position along the z-axis.

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 *_electrodes.tsv

Extracellular electrophysiology example (probe-relative coordinates):

tsv name probe_name hemisphere x y z impedance shank_id size material location e001 probe01 L 0 0 0 1.2 0 15 iridium-oxide MOp e002 probe01 L 0 0 25 1.1 0 15 iridium-oxide MOp e003 probe01 L 0 0 50 1.3 0 15 iridium-oxide MOp e004 probe01 L 0 0 75 1.4 0 15 iridium-oxide MOp e005 probe02 R 0 0 0 2.1 n/a 12 tungsten CA1 e006 probe02 R 0 0 15 2.3 n/a 12 tungsten CA1 e007 probe02 R 0 0 30 1.9 n/a 12 tungsten CA1 e008 probe02 R 0 0 45 2.0 n/a 12 tungsten CA1

Intracellular electrophysiology example:

tsv name probe_name hemisphere x y z impedance pipette_solution internal_pipette_diameter external_pipette_diameter material location patch01 pipette01 L 0 0 0 5.2 K-gluconate 1.5 2.5 borosilicate-glass VISp2/3 patch02 pipette02 R 0 0 0 4.8 K-gluconate 1.5 2.5 borosilicate-glass VISp2/3 sharp01 pipette03 L 0 0 0 80 3M KCl 0.5 1.0 borosilicate-glass PL5

Probes description (*_probes.tsv)

Probes are electrode-bearing devices that interface with neural tissue to record electrophysiological activity, ranging from multi-electrode arrays to single recording pipettes. 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.

ProbeInterface Library

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

Probe information is specified in the probes.json sidecar file using the model field with Levels to define each probe model.

For probes listed in the ProbeInterface library, use TermURL to reference the probe definition:

"model": {
    "Levels": {
        "A1x32": {
            "Description": "A1x32-Poly3-10mm-50-177, a 1-shank probe",
            "TermURL": "https://raw.githubusercontent.com/SpikeInterface/probeinterface_library/refs/heads/main/neuronexus/A1x32-Poly3-10mm-50-177/A1x32-Poly3-10mm-50-177.json"
        }
    }
}

If the probe is not listed in the ProbeInterface library, you SHOULD define it using the ProbeInterface format and include it in a directory called probes/ in the root of the dataset. Custom probe files MUST comply with the ProbeInterface specification and JSON schema.

For custom probes, reference them using a BIDS URI with the bids:: prefix in the TermURL field:

"model": {
    "Levels": {
        "customprobe1": {
            "Description": "Custom experimental probe",
            "TermURL": "bids::probes/customprobe1.json"
        }
    }
}

Example file structure:

└─ probes/
   ├─ customprobe1.json 
   ├─ customprobe2.json 
   └─ ... 
Column name Requirement Level Data type Description
probe_name REQUIRED string A unique identifier of the probe, can be identical with the device_serial_number. (expected to match probe_name listed in *_electrodes.tsv).

Values in probe_name 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.
AP RECOMMENDED number Probe position along the Anterior-Posterior axis. Positive values are anterior to the reference point.

This column must appear third in the file.
ML RECOMMENDED number Probe position along the Medial-Lateral axis. Positive values are to the right (as seen from behind).

This column must appear fourth in the file.
DV RECOMMENDED number Probe position along the Dorsal-Ventral axis. Positive values are ventral.

This column must appear fifth in the file.
AP_angle RECOMMENDED number Anterior-Posterior rotation angle measured as rotation from the vertical axis in the sagittal plane. 0° represents vertical along DV axis. Positive values indicate anterior rotation.

This column must appear sixth in the file.

Must be a number greater than or equal to -180 and less than or equal to 180.
ML_angle RECOMMENDED number Medial-Lateral rotation angle measured as rotation from the vertical axis in the coronal plane. 0° represents vertical along DV axis. Positive values indicate rightward/clockwise rotation (as seen from behind).

This column must appear seventh in the file.

Must be a number greater than or equal to -180 and less than or equal to 180.
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.
nan nan nan nan
height OPTIONAL number Physical height of the probe, for example, '0.3'. This dimension should be omitted or set to 0 for one-dimensional (linear) probes. This dimension corresponds to the y-axis of the probe's local coordinate frame.

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 probe's local coordinate frame.

This column may appear anywhere in the file.
dimension_unit OPTIONAL string Spatial units for a position or a physical dimension of electrodes, such as 'width', 'height' or 'depth' of the probe. For example, um.

This column may appear anywhere in the file.
rotation_angle RECOMMENDED number Rotation angle around the probe axis. 0° when probe features align with the coronal plane. Positive rotation is clockwise when viewed from above.

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 yaw, pitch, and roll rotations are applied.

This column may appear anywhere in the file.
anatomical_reference_point OPTIONAL string Anatomical reference point for stereotaxic coordinates (for example, Bregma, Lambda). If not specified, Bregma is assumed for rodents. MUST be defined for species other than rodents.

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 *_probes.tsv

Extracellular electrophysiology example:

tsv probe_name type AP ML DV AP_angle ML_angle rotation_angle hemisphere manufacturer device_serial_number electrode_count width height depth dimension_unit coordinate_reference_point anatomical_reference_point associated_brain_region associated_brain_region_id reference_atlas material probe01 silicon-probe -2.5 1.5 -4.0 15 0 0 L IMEC NP1100-2205 384 70 20 10000 um tip Bregma Primary Motor Cortex MOp Franklin-Paxinos silicon probe02 tetrode -1.2 -2.1 -3.5 0 10 45 R Neuralynx TT-12345 4 n/a n/a n/a um tip Bregma Hippocampus CA1 CA1 Paxinos-Watson tungsten

Intracellular electrophysiology example:

tsv probe_name type AP ML DV AP_angle ML_angle rotation_angle hemisphere manufacturer electrode_count coordinate_reference_point associated_brain_region associated_brain_region_id reference_atlas pipette01 patch-pipette -1.8 0.5 -2.2 30 0 0 L Sutter 1 tip Visual Cortex Layer 2/3 VISp2/3 AllenCCFv3 pipette02 patch-pipette -1.8 -0.5 -2.2 30 0 0 R Sutter 1 tip Visual Cortex Layer 2/3 VISp2/3 AllenCCFv3 pipette03 sharp-electrode -3.2 1.2 -3.8 20 5 0 L WPI 1 tip Prefrontal Cortex Layer 5 PL5 Franklin-Paxinos

Surgical Coordinates System

The surgical coordinates system provides a standard way to describe the placement of an intracranial probe implantation during surgery.

Anatomical Reference Points

In neurosurgery and research, it is important to define coordinates for where in the brain a surgical intervention will take place. These coordinates rely on anatomical markers that are uniform across individuals. There are two major anatomical markers on the dorsal surface of the brain that are formed when the plates of the skull fuse during development, and these markers are often used to identify the location of various anatomical structures of the brain.

Bregma and Lambda anatomical reference points

Bregma: the anatomical point on the skull at which the coronal suture (between frontal and parietal bones) is intersected perpendicularly by the sagittal suture (between left and right parietal bones).

Lambda: the meeting point of the sagittal suture (between left and right parietal bones) and the lambdoid suture (between parietal and occipital bones).

Both points serve as standard reference points for stereotaxic coordinates in neuroscience research. (0,0,0) is assumed to be Bregma when working with rodents. It may optionally be defined differently using anatomical_reference_point, and MUST be defined for other species.

Stereotaxic Coordinate System Conventions

All stereotaxic coordinate systems follow a right-handed coordinate system with the following conventions:

AP_ML_DV coordinate system

  • AP (Anterior-Posterior) axis: Positive values are anterior to reference point
  • ML (Medial-Lateral) axis: Positive values are to the right (as seen from behind)
  • DV (Dorsal-Ventral) axis: Positive values are ventral (following right-hand rule). For humans, this is the superior-inferior axis, and positive values point to inferior.

Proper understanding and application of these angles is critical for accurate probe placement and experimental reproducibility. All stereotaxic measurements use three angles to specify orientation:

AP angle (Anterior-Posterior rotation)

AP angle rotation diagram

  • Measured as rotation from the vertical axis in the sagittal plane
  • 0° represents vertical along DV axis
  • Range: -180° to +180°
  • Positive values indicate anterior rotation
  • Example: +15° indicates probe tilted 15° anteriorly from vertical

ML angle (Medial-Lateral rotation)

ML angle rotation diagram

  • Measured as rotation from the vertical axis in the coronal plane
  • 0° represents vertical along DV axis
  • Range: -180° to +180°
  • Positive values indicate rightward/clockwise rotation (as seen from behind)
  • Example: +20° indicates probe tilted 20° to the right from vertical

Rotation angle (around probe axis)

Rotation angle diagram

  • 0° when probe features align with the coronal plane
  • Range: -180° to +180° (or 0° to 360°)
  • Positive rotation is clockwise when viewed from above

Source Attribution

The coordinate system conventions and angle definitions presented in this section are adapted from the BrainSTEM documentation.

Coordinate System JSON (*_coordsystem.json)

Template:

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

  • <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

  • <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

  • 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.

This *_coordsystem.json file contains the coordinate system in which electrode positions are expressed. The associated MRI, CT, X-Ray, or operative photo can also be specified.

This file is OPTIONAL when using default probe-relative coordinates (no space-<label> entity). This file is REQUIRED when the space-<label> entity is used in the filename to specify electrode positions in an anatomical or stereotaxic coordinate system. When a *_space-<label>_coordsystem.json file is present, the corresponding *_space-<label>_electrodes.tsv file with the same space label MUST also be present.

General fields:

Key name Requirement Level Data type Description
IntendedFor OPTIONAL string or array The paths to files for which the associated file is intended to be used. Contains one or more BIDS URIs. Using forward-slash separated paths relative to the participant subdirectory is DEPRECATED. # TODO

Fields relating to the microelectrode electrophysiology 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.
MicroephysCoordinateUnits REQUIRED string Units of the coordinates of "MicroephysCoordinateSystem".

Must be one of: "m", "mm", "cm", "pixels".
MicroephysCoordinateSystemDescription RECOMMENDED, but REQUIRED if MicroephysCoordinateSystem is "Other" 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.
MicroephysCoordinateSystemPhoto OPTIONAL, but REQUIRED if MicroephysCoordinateUnits is "pixels" string A link to a photo or drawing of the microelectrode probe system.

*_coordsystem.json files SHOULD NOT be duplicated for each data file, for example, across multiple tasks. The inheritance principle MUST be used to find the appropriate coordinate system description for a given data file. If electrodes are repositioned, it is RECOMMENDED to use multiple sessions to indicate this.

Default probe-relative coordinate systems

When no space-<label> entity is specified in the filename, electrode positions in *_electrodes.tsv are probe-relative coordinates:

  • The origin (0, 0, 0) SHOULD be at the probe tip or a standard reference point on the probe
  • The reference point SHOULD be specified in the coordinate_reference_point column of *_probes.tsv
  • The x, y, and z coordinates describe electrode positions relative to this probe origin
  • The x, y, z axes correspond to the probe's local coordinate frame (width, height, depth)
  • This is the most common case for in-vivo recordings where electrodes are not localized in anatomical space
  • No *_coordsystem.json file is required for probe-relative coordinates

It is preferred that electrodes are localized in a 3D coordinate system (with respect to anatomical reference images, stereotactic coordinates, or in a standard space as specified in the BIDS Coordinate Systems Appendix about preferred names of coordinate systems, such as StereoTaxic).

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/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.

Multiple coordinate systems

If electrode positions are known in multiple coordinate systems (for example, probe-relative, StereoTaxic, and AllenCCFv3), these spaces can be distinguished by the optional space-<label> field, see the *_electrodes.tsv-section for more information. Note that the space-<label> fields must correspond between *_electrodes.tsv and *_coordsystem.json if they refer to the same data.

For examples: - *_space-StereoTaxic (electrodes are localized in stereotactic coordinate system with bregma origin)

  • *_space-individual (electrodes are localized in subject-specific anatomical coordinate system)
  • *_space-AllenCCFv3 (electrodes are mapped to Allen Common Coordinate Framework v3)
  • *_space-PaxinosWatson (electrodes are mapped to Paxinos-Watson rat brain atlas coordinates)

When referring to the *_electrodes.tsv file in a certain space as defined above, the space-<label> of the accompanying *_coordsystem.json MUST correspond.

For example:

└─ sub-01/
   ├─ sub-01_electrodes.tsv 
   ├─ sub-01_space-StereoTaxic_electrodes.tsv 
   ├─ sub-01_space-StereoTaxic_coordsystem.json 
   └─ ... 

The order of the required columns in the *_electrodes.tsv file MUST be as listed below. The x, y, and z columns indicate the positions of the center of each electrode in Cartesian coordinates.

Coordinate system specification

By default, *_electrodes.tsv contains probe-relative coordinates:

  • No *_coordsystem.json file is required
  • Units SHOULD be specified in the dimension_unit column of *_probes.tsv
  • The probe origin SHOULD be defined in the coordinate_reference_point column of *_probes.tsv

When electrode positions are expressed in anatomical or stereotaxic space:

  • Use *_space-<label>_electrodes.tsv with the appropriate space label
  • A corresponding *_space-<label>_coordsystem.json file MUST be present
  • Units are specified in the coordsystem.json file

Multiple coordinate systems MAY coexist in the same dataset.

Photos of the electrode positions (*_photo.<extension>)

Template:

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

  • <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

  • <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

  • 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.

These can include photos of the electrodes on the brain surface, photos of anatomical features or landmarks (such as cortical vasculature, stereotactic coordinates), and fiducials. Photos can also include histological sections showing electrode tracks, microscope images of electrode placements, or screenshots of a brain atlas 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 obtained consent and institutional protocols.

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

  • *_photo.<extension> in case of an operative or in-vivo photo
  • *_acq-<label>_photo.<extension> where <label> describes the acquisition type (for example: histology for histological sections showing electrode tracks, microscopy for microscope images of electrode placements, atlas for screenshots showing electrodes overlaid on brain atlas)
  • *_acq-drawing#_photo.<extension> in case of a drawing or sketch of electrode placements

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

The sample-<label> entity may be used to specify the tissue sample for histological photos.

The space-<label> entity may be used to specify the coordinate system for atlas overlay photos.

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 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 RFC3339 "date-time" format, for example 2009-06-15T13:45:30 (year, month, day, hour (24h), minute, second). 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 a *_scans.tsv:

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 the subject performed three tasks (nose-poke, reach-to-grasp, and rest), and on the second day only a rest task was performed. The electrophysiology data for each of the four recordings are stored in the corresponding session and ecephys 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 all data files of that session, as they do not contain a task entity in their name. For the behavioral tasks (nose-poke and reach-to-grasp), additional behavioral timestamps (events) were recorded and stored in task-specific events.tsv files.

├─ dataset_description.json 
├─ participants.tsv 
└─ sub-A/
   ├─ sub-A_sessions.tsv 
   ├─ ses-20220101/
   │  ├─ sub-A_ses-20220101_scans.tsv 
   │  └─ 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-reachtograsp_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-reachtograsp_ecephys.json 
   │     ├─ sub-A_ses-20220101_task-reachtograsp_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/
      ├─ sub-A_ses-20220102_scans.tsv 
      └─ 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 

Example sub-A_ses-20220101_task-nosepoke_ecephys.json:

{
  "TaskName": "Nose Poke Task",
  "TaskDescription": "Subject performs nose-poke responses to visual cues for reward",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

Example sub-A_ses-20220101_task-reachtograsp_ecephys.json:

{
  "TaskName": "Reach to Grasp Task",
  "TaskDescription": "Subject reaches and grasps objects of different shapes and sizes",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

Example sub-A_ses-20220101_task-rest_ecephys.json:

{
  "TaskName": "Resting State",
  "TaskDescription": "Spontaneous activity recording with no task",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

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" 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 three different protocol recordings were performed: two runs of current injection to characterize intrinsic properties, and one run of synaptic stimulation. The scans.tsv file stores 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 across data files.

For the second subject two samples (sample-cell002 and sample-cell003) were extracted and recordings of different tasks (current injection and synaptic stimulation) were 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_task-IVcurve_run-1_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-1_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-1_events.tsv 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_events.tsv 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_events.tsv 
│     ├─ sub-20220101A_channels.tsv 
│     ├─ sub-20220101A_electrodes.tsv 
│     ├─ sub-20220101A_probes.tsv 
│     └─ sub-20220101A_events.json 
└─ sub-20220101B/
   ├─ sub-20220101B_scans.tsv 
   └─ icephys/
      ├─ sub-20220101B_sample-cell002_task-IVcurve_icephys.nwb 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_icephys.json 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_events.tsv 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_channels.tsv 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_electrodes.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_icephys.nwb 
      ├─ sub-20220101B_sample-cell002_task-synaptic_icephys.json 
      ├─ sub-20220101B_sample-cell002_task-synaptic_events.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_channels.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_electrodes.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_icephys.nwb 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_icephys.json 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_events.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_channels.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_electrodes.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_icephys.nwb 
      ├─ sub-20220101B_sample-cell003_task-synaptic_icephys.json 
      ├─ sub-20220101B_sample-cell003_task-synaptic_events.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_channels.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_electrodes.tsv 
      ├─ sub-20220101B_probes.tsv 
      └─ sub-20220101B_events.json 

Example sub-20220101A_sample-cell001_task-IVcurve_run-1_icephys.json:

{
  "TaskName": "IV Curve Characterization",
  "TaskDescription": "Current injection protocol to characterize intrinsic membrane properties and generate current-voltage curves",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Visual Cortex",
  "CellType": "pyramidal"
}

Example sub-20220101A_sample-cell001_task-synaptic_icephys.json:

{
  "TaskName": "Synaptic Stimulation",
  "TaskDescription": "Electrical stimulation to evoke synaptic responses and characterize synaptic properties",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Visual Cortex",
  "CellType": "pyramidal"
}

Example sub-20220101B_sample-cell002_task-IVcurve_icephys.json:

{
  "TaskName": "IV Curve Characterization",
  "TaskDescription": "Current injection protocol to characterize intrinsic membrane properties and generate current-voltage curves",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 350,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Hippocampus",
  "CellType": "interneuron"
}

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

Several real-world datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.