Skip to content

ga4gh/tool-registry-service-schemas

Repository files navigation

ga4gh logo

DOI

release_badge

Schemas for the GA4GH Tool Registry API

This repository is the home for the schema for the GA4GH Tool Registry API. The goal of the API is to provide a standardized way to describe the availability of tools and workflows. In this way, we can have multiple repositories that share tools and workflows of various types that are described in workflow languages (e.g. WDL, CWL, Nextflow, Galaxy, Snakemake), have their dependencies embedded as containers (e.g. Docker, Singularity) or suitable alternatives (e.g., Conda), and have a consistent way to interact, search, and retrieve information from these various registries. The end goal is to make it much easier to share scientific tools and workflows, enhancing our ability to make research reproducible, sharable, and transparent.

See the human-readable Reference Documentation. You can also explore the specification in the Swagger Editor. Manually load the JSON if working from a non-develop branch version. Preview documentation from the gh-openapi-docs for the development branch here

The Global Alliance for Genomics and Health (GA4GH) is an international coalition, formed to enable the sharing of genomic and clinical data.

Cloud Work Stream

The Cloud Work Stream is focused on creating specific standards for defining, sharing, and executing portable workflows and self-contained tasks, and accessing data across clouds.

We work with many different Driver Projects to develop, enhance, test, and use the Cloud Work Stream APIs.

What is the Tool Registry API Schema?

This is the home of the schema for the GA4GH Tool Registry API. The GA4GH Tool Registry API is a standard for listing and describing available tools (both stand-alone, self-contained tools and workflows in CWL, WDL, Nextflow, Galaxy or Snakemake) in a given registry. This defines a minimal, common API describing tools that we propose for support by multiple tool/workflow registries like Dockstore, BioContainers, and Agora for the purposes of exchange, indexing, and searching.

This repo uses the HubFlow scheme which is closely based on GitFlow. In practice, this means that the master branch contains the last production release of the schema whereas the develop branch contains the latest development changes which will end up in the next production release. As of February 2022, the master branch contains the last production release (currently release_badge)) whereas the develop branch contains work which will accumulate and evolve into a 2.1 production release.

Our current iteration focuses on a read-only API due to potentially different views and approaches to registration/security.

Key features of the current API:

  • Read-only API
  • Serve tool and workflow resources via specifically designed schemas that encourage rich metadata annotation and help enable software FAIRification
  • Download individual workflow descriptor files or an archive of all workflow and accessory files (e.g., test files)
  • Allow integrators to interrogate the language versions of these workflows (e.g. CWL 1.1, CWL 1.2 or Nextflow DSL2) to identify compatible workflows
  • Get specific versions of workflows and tools, potentially with immutable versions with checksums on their files
  • Assign globally unique TRS URIs to specific versions of tool and workflow resources
  • Provides more structure than a simple unformatted list of tools but it is also a standard for registries to implement as opposed to a registry implementation itself

Open questions:

Questions TRS currently does not (comprehensively) address include the following:

  • How do we track authorship? Should we track authorship of the tool metadata, the Docker image, or the underlying algorithm, or all of above?
  • How to describe indexing and external services like an external SPARQL service?
  • How to better interoperate with the GA4GH Workflow Execution Service (WES) and Task Execution Service (TES) APIs for triggering workflow and tool runs

How to view

See the swagger editor to view our schema in progress.

How to contribute changes

Take cues for now from the CONTRIBUTING.md document.

At the very least, create an issue in our GitHub tracker.

Even better, fork the codebase, fix the issue, and create a pull request back to the project along with your ticket.

Adding registries

To add a registry that supports the GA4GH Registry API:

  1. fork the repo
  2. modify registry.json
  3. submit a pull request back to the project
  4. we will confirm the site is valid then accept your pull request

Cross indexing Tool Registry sites

See our registry.json for a list of known registries that conform to the Tool Registry API standard.

License

See the LICENSE

For more information