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>][_acq-<label>]_channels.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_channels.tsv
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.nix
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.nwb
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.tsv

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:

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

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 *_icephys.json and *_ecephys.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"
    },
    "TaskName": "Reach-to-Grasp",
    "TaskDescription": "A task that involves the reaching of an object and holding it for a specific time"
  }
}

Microephys Specific Files

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

1. [_ses-<session_label>]_channels.tsv: A REQUIRED file listing information on the recorded signals, such as preprocessing, filtering, ids, 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>]_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.

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

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. This file contains the following information:

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

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 *_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 *_channels.tsv

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

electrode_id	probe_id	impedance	x	y	z	material	location
e0123	p01	1.1	-11.87	-1.3	-3.37	iridium-oxide	V1
e234	p01	1.5	-11.64	0.51	-4.2	iridium-oxide	V2
e934	p02	3.5	-12.11	-3.12	-2.54	iridium-oxide	V4
e234	p02	7	-9.94	-1.19	-2.86	iridium-oxide	V3

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_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.
AP	RECOMMENDED	number	Probe position along the Anterior-Posterior axis. Positive values are anterior to the reference point. This column may appear anywhere in the file.
DV	RECOMMENDED	number	Probe position along the Dorsal-Ventral axis. Positive values are ventral. This column may appear anywhere 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 may appear anywhere 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.
nan	nan	nan	nan
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 yaw, pitch, and roll 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.
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 may appear anywhere 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 may appear anywhere in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
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.
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

probe_id	hemisphere	AP	ML	DV	AP_angle	ML_angle	rotation_angle	material	location	manufacturer	model
p023	left	-11.87	-1.3	-3.37	0	0	0	iridium-oxide	V1	neuronexus	A1x32
p023	left	-11.64	0.51	-4.2	0	0	0	iridium-oxide	V2	neuronexus	A1x32
p021	left	-12.11	-3.12	-2.54	0	0	0	iridium-oxide	V4	neuronexus	A1x32
p021	left	-9.94	-1.19	-2.86	0	0	0	iridium-oxide	V3	neuronexus	A1x32

Surgical Coordinates System

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

Anatomical Reference Points

In neurosurgery or in 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: 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 coordinate_reference_point, and must be defined for other species.

Stereotaxic Coordinate System Conventions

Basic Coordinate System

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

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

Angle Measurement System

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)

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

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

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

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json
        icephys/
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json

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 electrode positions are probe-relative (default case). This file is REQUIRED when electrode positions are expressed in an absolute coordinate system. When provided, the space-<label> entity is REQUIRED in the filename to specify the coordinate system reference.

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

Microelectrode electrophysiology allows for electrode positions to be specified without an accompanying *_coordsystem.json file. In this case, electrode positions in *_electrodes.tsv are assumed to be probe-relative coordinates:

• The origin (0, 0, 0) is at the probe tip or a standard reference point on the probe

• The x, y, and z coordinates describe electrode positions relative to this probe reference
• This the most common case for in-vivo recordings where electrodes are not localized in a 3D anatomical space

Recommended 3D coordinate systems

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. Units are specified in *_coordsystem.json.

Coordinate system requirement

If a *_space-<label>_coordsystem.json file exists, a corresponding *_space-<label>_electrodes.tsv file with the same space label MUST also be present.

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

Template:

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.jpg
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.png
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.tif
        icephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.jpg
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.png
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.tif

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 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 a *_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 .

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 on GIN .

We will also publish another dataset using the NWB data format in the near future, and a dataset acquired