A data, tools, and compute resource

A clearer path from brain recordings to reusable science.

NEMAR (the Neuroelectromagnetic Data Archive and Tools Resource) helps researchers find, understand, assess, cite, and reuse human EEG, MEG, iEEG, and EMG data.

NEMAR is supported by the National Institutes of Health and NIMH under award NIMH R24MH120037, and our partnership with the San Diego Supercomputer Center (SDSC) (opens in a new tab) is central to closing the loop between open data and practical computation. The Neuroscience Gateway (NSG) (opens in a new tab) gives the neuroscience community an established path to tools and high-performance computing resources; NEMAR aims to make the dataset, version, and workflow connection seamless. See the NIH project record (opens in a new tab) .

NEMAR at a glance current platform + roadmap
SOURCE BIDS datasets researcher contributions
+ OpenNeuro mirrors
CONTRACTS NEMAR catalog · manifests · DOI
nemar.org browser shell
nemar-cli repeatable workflows
zarr.nemar.org derived chunk reads
COMPUTE BRIDGE SDSC + NSG partnership NEMAR aims to connect its dataset, version, and workflow contracts to these established compute resources. PLANNED NEMAR INTEGRATION · Tapis + OneSciencePlace → national HPC resources

BIDS remains authoritative · derived access stays labeled

Why NEMAR exists

Make reuse feel like part of the research, not an afterthought.

A recording is more useful when another researcher can find it, tell what it contains, check how it was prepared, access the files without guesswork, and cite the exact state they used. NEMAR brings those pieces together around community standards such as BIDS, reviewable metadata, quality information, and open interfaces.

Mission

Make human neuroelectromagnetic data findable, understandable, citable, and reusable.

We do that by combining community standards with trustworthy metadata, quality checks, open interfaces, and practical paths to computation.

Vision

Let a researcher inspect, analyze, and cite the right version without moving everything first.

Sharing data should open the next experiment: a better question, a more reproducible analysis, or a useful derivative that can be shared in turn.

This is open science as infrastructure: preserve publicly useful research data, make its context legible, and improve the resource in public while keeping released versions citable.

The NEMAR mental model

One system, many doors.

NEMAR is not only the website. The browser is a friendly shell around a command-line client, shared backend contracts, canonical BIDS data, derived streaming stores, and durable citation records. Each layer has a job, so a person or an agent can use the surface that fits the work.

Diagram showing people and research agents using nemar-cli and the NEMAR web shell, which connect to the API and canonical data plane; data then feeds derived Zarr streaming, GitHub and S3 storage, and DOI records.
Figure 1. NEMAR keeps the browser and future research agents close to the same API, data, version, and citation contracts used by the CLI.

Why CLI-first?

The strongest foundation is a repeatable one.

A command-line workflow can live in a script, run on a laptop or an HPC login node, resume an interrupted transfer, inspect versions, and be reviewed alongside code. That makes nemar-cli more than an upload utility: it is the durable research workflow and the reference client for the platform.

Why a web shell?

Discovery should not require installation.

The website is the fastest place to search, preview, assess, manage collaborators, and start an exploration. It consumes the established backend rather than silently creating a second source of truth. The CLI and web app share accounts, permissions, and dataset state; they simply serve different moments in a research workflow.

Which NEMAR surface answers which question?
Surface Use it when you want to… What it owns
nemar.org discover, inspect, visualize, and manage data in a browser the human-facing shell
nemar-cli script upload, validation, download, versioning, and publication the repeatable terminal workflow
api.nemar.org search the catalog or use accounts, permissions, and workflow APIs the control plane
data.nemar.org read the canonical BIDS-shaped tree, metadata, manifests, and files the data plane and source view
zarr.nemar.org stream selected chunks of a converted recording for responsive analysis a derived access layer, where conversion is available
docs.nemar.org learn the contracts, commands, policies, and machine-facing routes shared explanations and reference

A dataset is a living scholarly object

Review first. Cite clearly. Improve in public.

NEMAR treats publication as a checkpoint, not a finish line. A dataset can be private while its authors prepare it, reviewed before release, and then improved through a visible versioned change.

Five-stage dataset lifecycle: prepare BIDS files, validate structure and metadata, publish after review with a DOI, reuse through search and analysis, and improve through a pull request that creates a new version. The publish step creates concept and version DOIs.
Figure 2. A release creates a citable state; later improvements are reviewable changes that become a new state rather than a silent rewrite.

Why NEMAR mints its own DOI

A stable handle for the dataset, plus a precise handle for every release.

NEMAR mints identifiers in its own 10.82901/NEMAR namespace through EZID and publishes a DataCite record. The concept DOI identifies the dataset as a continuing scholarly object. A version DOI identifies one released state, including its version number, landing page, and immutable file manifest.

That record is meant to be much fuller than a bare pointer to a repository. When the source metadata supports it, the citation can connect authors, ORCIDs, and affiliations; an abstract and acknowledgement text; MeSH-validated keywords; funding; related identifiers; license; issued and collection dates; formats; sizes; and the relations between a concept and its versions. The DOI stays stable while the landing page and structured metadata can be corrected or enriched.

After a DOI release, changes go through a reviewed pull request and become a new citable version. This is how FAIR practice and continuous improvement reinforce one another: old analyses keep a precise reference, while the community gets a public path to make the data clearer and more useful.

Compute without moving everything

From canonical files to in-browser analysis.

The canonical archive is BIDS-shaped. For large signal files, NEMAR can create a derived Zarr store: a chunked representation that lets the reader request a small window instead of downloading an entire recording. An edge Worker at zarr.nemar.org provides the browser-facing gateway, CORS handling, and caching, so the viewer can ask for only the chunks it needs.

The original BIDS file remains authoritative. Zarr conversion can be pending or fail for an individual recording, and the index should make that coverage visible. This separation lets us build lightweight in-browser inspection now while preserving a trustworthy source archive underneath.

Flow diagram from the canonical BIDS source archive through Zarr conversion and an edge worker to browser analysis; a planned NEMAR integration would use Tapis through OneSciencePlace to launch reproducible HPC jobs near the data and return versioned BIDS derivatives with their own DOI.
Figure 3. Zarr is a derived streaming layer for partial reads. A planned NEMAR integration with Tapis through OneSciencePlace is a route for larger reproducible jobs near national HPC resources, not a shipped one-click feature today.

The compute roadmap

Move the computation closer to the data.

This loop closes through partnership, not through a generic cloud promise. NEMAR contributes structured, open, citable data; SDSC contributes the compute partnership and operational expertise; and the Neuroscience Gateway (NSG) (opens in a new tab) gives researchers an established route to neuroscience tools and high-performance computing resources.

Our next direction is to connect NEMAR to Tapis through OneSciencePlace (opens in a new tab) . OneSciencePlace is a platform developed by teams at UCLA, SDSC, and TACC that uses Tapis for job and data lifecycle management. For NEMAR, this remains a planned API bridge to national HPC infrastructure: a reproducible path from a dataset page to a described job and, eventually, a versioned derivative that can be cited in its own right.

Roadmap: planned, in development

Built for people and agents

Open science should be legible to software, too.

Agentic research is not only about publishing code. It means making code repositories, webpages, metadata, manifests, and each dataset understandable to scripts and LLM-based research agents. NEMAR therefore pairs a human browser with stable URLs, machine-readable JSON, BIDS paths, checksums, schema.org Dataset metadata, markdown mirrors, and /llms.txt.

Readable by default

A dataset page explains what it is, links to its files and version, exposes structured metadata, and tells a reader how to cite and license it. The same page has a markdown mirror for tools that do not need a visual browser.

AI assistance with boundaries

Models may help propose descriptions, methods, keywords, related identifiers, or validation findings from README files and structural metadata. Human and administrative review remains authoritative; AI output does not publish data by itself or replace controlled vocabularies.

Useful at the edge

APIs, manifests, stable BIDS paths, and derived Zarr chunks let an agent or a browser ask for the smallest useful piece of a dataset before choosing whether to download or compute more.