LogoLogo

The Open Neuroscience landscape

  • Researchers & engineers create open knowledge with data standards & data repositories
  • Lawyers & ethicists protect the individual, creating regulations such as the GDPR and HIPAA
  • Nations & regions defend security & sovereignty with national & regional laws
  • Working groups try to align and translate between these forces
graph TD

  wg([working groups]) .-> r
  wg .-> l
  wg .-> s
  
  r([researchers, engineers]) -->|open knowledge| fair([data standards<br/>& repositories])
  l([lawyers, ethicists]) -->|protect the individual| dp([GDPR, HIPAA,<br/>health codes])
  s([nations, regions]) -->|security & sovereignty| nat([national &<br/>regional laws])

  fair .-> net([network of rules,<br/>standards & infrastructures])
  dp .-> net
  nat .-> net

Note

Researchers and engineers need to share knowledge and make data and methods accessible. That gives us FAIR principles, and bottom-up data standards, repositories, and tools for sharing.

Lawyers, ethicists, and data-protection authorities shield people from misuse of a person’s data, especially with health and biometric data that cannot be recalled once leaked. That gives us GDPR, HIPAA, consent frameworks, and controlled access.

Nations and regions keep (sensitive) data within trusted borders for security, sovereignty, and protecting economic interest. This force is increasingly visible, and a reason why parts of the landscape are diverging, for example between the EU and the US.

You probably agree with all three. However, they push and pull in the same and different directions, leaving a single complex network of standards, tools, and repositories, within rules, regulations, and policies.

Working groups, committees, and joint actions try to align rules, tools, and practices, and translate between domains. Examples are CoSO, EHDS joint actions, and standards bodies such as GA4GH and INCF.

  • Sharing data: Where, and what, can or must I share data, and on what terms?
  • Reuse data: What data is out there, where can I find it, and how can I use it?
  • Shape policy: On which rules and practices do we agree, where not, and how can I participate?
  • Always: What is true, up to date, and what does it mean?

Note

As a result, similar questions face anyone working with neuroscience data.

If you produce data: where, and what, may or must you publish, and on what terms?

If you reuse data: what is out there, where is it, in what format, and under which conditions for use?

If you shape policy: where do we (dis)agree and who is making the decisions? If you want to change something, where do you engage?

And underneath all of them, the hardest one: how do you know that what you are reading is true, current, and that it means what you think it means? Especially when the network keeps shifting, with new tools and new rules. Navigating it with confidence is a challenge.

The Open Science Graph

  1. Curated nodes of actors, standards, resources and governing entities
  2. Explanations in plain readable language for all audiences
  3. Connections showing meaningful relationships with standardized vocabulary
  4. Verified by primary sources and experts
  5. Maintained openly in line with FAIR principles and practices
  6. Editorial perspectives (next slide)

Note

The Open Neuroscience Graph is a response to these challenges, by provided a map, built around six pillars.

  1. It is curated: nodes for the actors who do the research, the standards that encode the data, the resources that store and process it, and the governing entities that regulate it. Not everything, but the entities that matter and connect and are relevant for neuroscience.

  2. Each node is explained in plain language, readable by a newcomer and a policymaker, not only by a specialist already inside one corner of the field.

  3. The nodes are joined by named connections that state a concrete relationship: which repository implements which standard, which mandatTe routes to which platform, which body governs which standard. You can follow the relations rather than infer them.

  4. It is verified against primary sources and, increasingly, by the experts in each community, so the claims can be trusted and the source is on the node.

  5. It is maintained openly by design: a living map that knows where its own edges are, corrected in the open as the field moves. That is also the honest limit, it is semi-complete on purpose, and it improves by being used and challenged.

On top of them sits an editorial layer that slices the graph into perspectives, which is where we point the reader next.

Editorial perspectives on the landscape

  • practical, e.g. sharing your data
  • domain, e.g. genomics, neuroimaging
  • regional, e.g. France, Europe, Japan
  • general, e.g. Open access publishing

Note

Open Neuroscience Graph provides curated views on the network that discuss the nodes in context that matter. A practical guide such as Sharing your data, a domain such as Genomics or Neuroimaging, or a country or region such as France, Europe, or Japan.

The same node can appear in several perspectives at once. EGA, for example, sits in the Genomics perspective, the France perspective, and the Sharing your data guide, discussed each time in the context that matters there, while a node like VCF belongs only to genomics. Open any of these pages to see it for yourself.

This layer is editorial. The perspective pages can grow and change as the field develops, without changing the underlying nodes.

How the graph is built and maintained

A node is a plain text file

  • Every node originates as one Markdown file in Obsidian
  • Frontmatter: name, website, status, parent, type/ and domain/ tags, verified
  • Body: Overview, Connections (labelled edges), Resources
  • Anyone who can edit text can contribute a node
---
name: Brain Imaging Data Structure
aliases:
  - BIDS
website: https://bids.neuroimaging.io
status: active
founded: 2016
parent_org: BIDS Steering Group
tags:
  - type/datamodel       # directory + graph colour
  - domain/neuroimaging  # research area, used for filtering
verified: true
last_reviewed: 2026-06-01
---

Note

Every node is a single Markdown file, in the Obsidian standard: a YAML frontmatter header and a short body.

The frontmatter in YAML holds name and aliases, website, status and founding year, parent organisation, the type/ and domain/ tags, and a verified flag with the date last checked against primary sources. The type/ tag places the node in one of four families: Actors that do research, Standards that encode data, Resources that store and process it, and Governance that coordinates and regulates it.

The body has three sections:

  • Overview (a 3-6 sentence plain-language summary)
  • Connections (the labelled edges, e.g. governedBy: BIDS Steering Group)
  • Resources (primary-source URLs).

Nodes and edges

  • Every entity is a node with labelled connections (edges) to other nodes
  • The edge is written once, in the dependent node, pointing up to the authority
  • Labels come from a controlled vocabulary (FAIRsharing, schema.org, and custom)
  • Reverse connections show automatically as backlinks
graph BT
  on([OpenNeuro]) -->|requires| bids([BIDS])
  nidm([NIDM]) -->|extends| bids
  bids -->|governedBy| sg([BIDS Steering Group])
  bids -->|endorsedBy| incf([INCF])
  bids -.->|backlink, automatic| on

Note

Each node carries labelled connections (edges) to other nodes. A node requires at least one real significant edge: an unconnected node says nothing about how the field is organised.

An edge has a direction and a label. It is written in the more specific or dependent node, pointing up to the authority, standard, or parent it depends on. The authority doesn’t point down to those that depend on it, to prevent accumulation upwards. However, these backwards connections (backlinks) are shown automatically on the site (and in Obsidian)

The label comes from a controlled vocabulary composited from FAIRsharing (data-flow terms), schema.org, Dublin Core (structural terms), and custom governance terms. Reusing established terms where they exist, and minting our own only where open-neuroscience governance has no standard equivalent, is what makes this an application profile rather than a private vocabulary. The Vocabulary page shows the full list and names each term’s source.

Inclusion criteria

  • 1. Domain scope: Does the entity operates in a neuroscience data domain?
  • 2. Type-appropriate function: Does it fit a clear type/ tag (see Vocabulary)
  • 3. Edge generation: Does it have at least one significant (strong) labelable connection
  • 4. Participation is not enough: Endorsing or belonging is not enough
  • 5. Precedent: Would adding the entity commit the vault to include all of its kind? (if yes, exclude)
  • 6. Removal: Would deleting it leave a dangling link? (if no, exclude)
graph TD
  start([candidate]) --> t1([in scope?])
  t1 -->|no| out([not included])
  t1 -->|yes| t2([existing type?])
  t2 -->|no| out
  t2 -->|yes| t3([1+ edge?])
  t3 -->|no| out
  t3 -->|yes| t4([precedent ok?])
  t4 -->|no| out
  t4 -->|yes| node([node])

Note

A node must pass six tests, in order:

  1. Domain scope: operates in a neuroscience data domain.
  2. Type-appropriate function: clears the bar for its kind (a repository holds data; an institute operates open infrastructure, not just research).
  3. Edge generation: produces at least one labelable connection.
  4. Participation is not enough: endorsing or belonging does not substitute for tests 1-3.
  5. Precedent: would adding it commit the vault to every other entity of the same kind?
  6. Removal: if deleted, would any node be left with a dangling link?

Domain tags

  • Each data-facing node carries a domain/ tag for its research area
  • Cross-domain governance and regulatory entities carry none
  • Tags allow filtering
graph TD
  repo([OpenNeuro])
  t1(["#type/repository"]) -.- repo
  t2(["#domain/neuroimaging"]) -.- repo

Note

Each data-facing node carries a domain/ tag for the research area it serves. Cross-domain governance and regulatory entities carry none. Tags drive filtering: every perspective and domain view is a query over them. Domains: neuroimaging, electrophysiology, genomics, biosamples, bioimaging, behavior, clinical, health, computational, reproducibility.

Built to be found

  • Registered for discovery: FAIRsharing, bio.tools, w3id, Zenodo DOI
  • Two targets are themselves nodes (registries the vault catalogues)
  • The graph’s own discoverability uses the same registeredIn predicate
graph TD
  ong([Open Neuroscience Graph]) -->|registeredIn| fs([FAIRsharing])
  ong -->|registeredIn| bt([bio.tools])
  ong -->|registeredIn| w3([w3id])
  ong -->|registeredIn| zen([Zenodo DOI])

Note

The graph is registered for Findability (FAIR): a FAIRsharing record, a bio.tools entry, a permanent [[openneuroscience|w3id identifier]], and a Zenodo DOI for citation. Two targets are themselves nodes (FAIRsharing and bio.tools are registries the vault catalogues), so the graph’s own discoverability uses the same registeredIn predicate it applies to any dataset or identifier.

How it is built and run

  • Plain text and open tooling, fully transferable by design
  • Maintainer writes notes in Obsidian, Claude structures and harmonizes them following CONTRIBUTING.md
  • Maintainer reviews and curates in VS Code using Git
  • Site build with Quartz, hosted on Gitlab Pages, with Matomo analytics
graph TD
  maint([Maintainer]) -->|writes raw notes| notes([Obsidian<br/>Raw notes])
  notes -->|scope & evaluate| claude([Claude])
  contrib([CONTRIBUTING.md<br/>rules, gates, criteria]) -->|governs| claude
  claude -->|write nodes| nodes([Obsidian<br/>Structured node])
  nodes -->|harmonize| claude
  nodes -->|review| vsc([VS Code<br/>any maintainer curates])
  vsc -->|commit| gl([GitLab])
  gl -->|change log| vsc
  gl -->|build| quartz([Quartz])
  quartz -->|deploy| pages([GitLab Pages])
  pages -->|measure| matomo([Matomo analytics])

Note

Openneuroscience Graph is build and maintained by me (Stephen Whitmarsh). I build a system that works for me, allows me to maintain and scale this work, while anticipating future contributions and maintenance by the community. The following is therefor written in the first-person, but I explain it because it might be useful for you - as future contributor - as well.

I use Obsidian when I can, or write directly in TODO.md. I’ve installed Claude MCP, so that it can directly read and write within the vault. I then use it to scope and evaluate new notes against the inclusion criteria, write them up, and harmonize formatting, all following the rules, gates, and criteria set out in CONTRIBUTING.md. The end result is structured in the real vault format, including the YAML frontmatter. Through git integration in Visual Studio Code, it is easy for me to review, curate and validate new nodes. From each commit the site is automatically build with Quartz, hosted through GitLab Pages, and measured with Matomo (no cookies). For more details see CONTRIBUTING.md.

Because everything (vault and the build) is shared in Git, any maintainer, on any machine, can clone or pull the vault.

Finally, Quartz is also heavily customized. This is done with custom code in such a way that a rebase of Quartz can be done without problems. This is documented in QUARTZ.md.

Where it lives

Note

The database and code are part of the open neuroscience ecosystem itself, and effort is keep it FAIR. This is important because standards, tools and actors all change continuously. Contributions, corrections, and suggestions are therefore essential, especially anything that makes this graph (and the field) more inclusive. Editing conventions, inclusion criteria, frontmatter fields, and Dataview query examples are in CONTRIBUTING.md and DATAVIEW.md, or get in touch via the repository or by email.

Citing

Creating and maintaining this resource requires real time and effort, so please acknowledge this in your work by citing: Whitmarsh, S. (2026). Open Neuroscience Graph. Zenodo. https://doi.org/10.5281/zenodo.20181900.

Backlinks