Documentation

Introduction

The RSEc version-controlled repository federates metadata for research software, predominantly within the life sciences domain. These metadata cover a wide spectrum of use cases, spanning software discovery, evaluation, deployment, and execution.

Centralised in an open and version-controlled repository, the metadata enable cross-linking between services, facilitate curation, and provide insights through aggregation and analysis. This page collects key links to access and understand the software metadata provided by the Research Software Ecosystem, plus contribution guidelines and support channels.

What the RSEc provides

The RSEc is a federated metadata commons rather than a replacement for the registries, package repositories, container infrastructure, workflow platforms, or benchmarking services that contribute to it. Each community remains responsible for its own source of truth; the RSEc aligns and links those sources so that they can be used together.

This approach is deliberately format-agnostic. Source metadata can be preserved in its native JSON, YAML, or other representation while the RSEc builds tool-centred bundles and interoperable views for downstream use. Persistent identifiers and cross-links connect software with versions, packages, containers, workflows, publications, authors, licences, usage information, and scientific concepts such as EDAM topics and operations.

The repository is useful to three audiences:

• Researchers can find tools, compare available ways to run them, and follow links to documentation, publications, training, workflows, Galaxy instances, Bioconda packages, or containers.
• Developers and curators can improve one metadata record and make that improvement available to several consuming services, subject to source-specific validation and synchronisation rules.
• Service developers can reuse versioned metadata programmatically instead of building and maintaining a separate catalogue of overlapping tool descriptions.

Browse the RSEc Atlas

The RSEc Atlas is the interactive entry point for exploring the aggregated metadata. Search by tool name, description, tags, EDAM topic, or bio.tools collection, then filter by options such as Galaxy or Bioconda availability, licence, or favourites. Tool pages can expose installation strings, container commands, Galaxy launch links, DOI references, usage statistics, related workflows, and training materials.

The Atlas is a presentation layer over the metadata commons: use it for human-friendly discovery, and use the content repository or the RSEc utilities when you need reproducible or programmatic access.

Quick start

How to use the metadata

Metadata Repository contents

The RSEc metadata can be accessed on the GitHub dedicated repository. The main folders to access metadata are: the imports folder, which contains one subfolder per metadata source, and the data folder, which contains one subfolder for each of the bio.tools entries, combining bio.tools tools and metadata files which are directly linked to it. An example of this organisation is illustrated in Fig. 1.

Each software entry is organised as a tool-centred metadata bundle. This makes it possible to inspect the native source files alongside the cross-linked files contributed by other providers. A bundle may include descriptions, versions, dependencies, identifiers, publications, packaging or container information, workflow relationships, monitoring metrics, and semantic annotations. The imports/ tree is source-oriented; the data/ tree is designed for following one tool across sources.

Fig. 1: Example organisation of the metadata files imported in the RSEc metadata repository

Supported Formats

Details about the specific formats for each of the federated resources can be found in the following places:

Resource Description	Link
Bio.tools API Reference	Bio.tools API Reference
OpenEBench	OpenEBench Technical metrics and endpoints description Tool JSON Schema Metrics JSON Schema
Bioconda	Bioconda contribution guidelines
Biocontainers	WIP
Galaxy Codex	Documentation work-in-progress
Debian Med	The YAML files describing the packages are based on information extracted from the Ultimate Debian Database using a custom import script
BIII	The metadata describing the software are serialized as Bioschemas-based JSON-LD files, using a custom import script
Bioconductor	Release metadata are collected from the Bioconductor package release API and citation records, then merged with RSEc metadata while preserving curated annotations such as EDAM terms.

The RSEc also generates linked-data representations using schema.org, Bioschemas profiles such as ComputationalTool, JSON-LD, and RDF Turtle. These exports are useful when a catalogue, search service, semantic-web application, or other automated agent needs a standardised view without discarding the original source metadata.

Most metadata formats for a given source include cross-links to other sources:

Destination / Source	bio.tools	OpenEBench	Bioconda	Biocontainers	Galaxy Codex	Debian Med	BIII	Bioconductor
bio.tools	n/a		url entries of the download key where url starts with "https://anaconda.org/bioconda/", the remainder of the url being the Bioconda package name			url entries of the download key where url starts with "https://tracker.debian.org/pkg/", the remainder of the url being the Debian package name
OpenEBench	List elements that have and @id key starting with "https://openebench.bsc.es/monitor/metrics/biotools"	n/a	List elements that have and @id key starting with "https://openebench.bsc.es/monitor/metrics/bioconda"		List elements that have and @id key starting with "https://openebench.bsc.es/monitor/metrics/galaxy"
Bioconda	YAML list extra.identifiers, CURIEs starting with "biotools:"		n/a			For usegalaxy.eu, YAML list extra.identifiers, CURIEs starting with "usegalaxy-eu:"
Biocontainers				n/a
Galaxy Codex	‘bio.tool_id’ key in the JSON file		‘Conda_id’ key in the JSON file		n/a
Debian Med	YAML list registries, CURIES are in entry key when name is "bio.tools"		YAML list registries, CURIES are in entry key when name is "conda:bioconda"			n/a
BIII							n/a
Bioconductor								n/a

Metadata Import Workflow

The metadata is imported and updated using a GitHub actions workflow which runs weekly, importing the updated metadata from all sources. Each import task (listed in the table below) is an independent Github action that queries a specific source and updates the metadata in the git repository. It is usually running a python script that:

• cleans all the data from the source from the existing repository checkout
• retrieves the latest version of the metadata, using e.g. an HTTP API, a git repository checkout, or a database access.
• formats these metadata in a format which is as close as possible to the source format, yet compatible with git (e.g. YAML or JSON reformatting is sometimes required).
• commits this version of the metadata. The outline of this workflow is illustrated in Fig. 2.

Fig. 2: CI Import workflows in the repository

Integration model

RSEc integrations fall into two broad categories. The distinction is about how closely the RSEc participates in a source’s metadata lifecycle, not simply how much data a source contributes.

Lightweight integrations

Lightweight integrations retrieve source metadata with minimal transformation, preserve its native structure, and place it in the appropriate tool bundle. Examples include scheduled imports from Bioconda, BioContainers, Debian Med, and Galaxy Codex. These jobs keep the commons current while leaving source-specific semantics and governance with the originating community.

Deep integrations

Deep integrations add validation, schema transformation, semantic export, cross-resource matching, or synchronisation back to an upstream service. The bio.tools integration, for example, supports a bidirectional bridge with protected-field checks. Bioconductor metadata can be merged with RSEc records while preserving curated annotations such as EDAM terms. OpenEBench contributes monitoring and quality indicators that extend the metadata commons from findability and access towards evidence-based comparison and sustainability.

Quality, validation, and provenance

Every import is associated with a source, an automated workflow, and a commit in the repository history. Continuous-integration jobs validate source files, generate repository reports, and export downstream formats. This gives users a reproducible way to see what changed and why a particular version of a record is present.

Validation happens at several levels:

• Syntactic checks detect malformed JSON/YAML and schema violations.
• Semantic checks verify controlled terms where a source provides them, including EDAM concepts.
• Cross-resource checks identify possible links between records, such as a Galaxy tool and its bio.tools entry.
• Community review remains important for equivalence mappings and other cases where automated matching cannot be trusted on its own.

The RSEc therefore combines automation with human curation. Upstream quality, availability, and identifier stability still affect the quality of the resulting commons; when you find a mismatch, report it with the relevant source record and tool identifier.

Reuse in other services

The RSEc is intended to be consumed by services that add their own context rather than duplicate the underlying curation. Examples described in the manuscript include:

• ToolFinder combines RSEc descriptions, EDAM topics, publications, and licences with local installation and availability information across Australian infrastructures.
• WorkflowHub uses bio.tools identifiers and EDAM terms when workflows are registered and can annotate Galaxy workflows with the tools they use.
• Galaxy uses shared tool identifiers and EDAM annotations to improve discovery and interoperability, while RSEc-linked metadata can add packaging, container, documentation, and usage context.

For machine-readable reuse, start with the repository’s raw JSON/YAML files and commit history. For maintained import and conversion logic, see the utils repository. For a human-facing catalogue, use the RSEc Atlas.

Contributing guidelines

We welcome any contribution to the project. Please refer to the governance document, and get in contact with us (see the Contacts page).