Currently, the data model is built around two main models, the Tool and the ToolVersion. A Tool describes one pairing of a tool and one Docker image. A ToolVersion describes a particular iteration of a tool as fixed by a reference to a specific image id, a Dockerfile (which was used to build an image) as fixed by a URL, and a descriptor for the tool in either CWL or WDL.
We are starting with a read-only API due to potentially different views and approaches to registration/security.
For convenience, including potentially when passing content references to a WES server, we define a URI syntax for TRS-accessible content. Strings of the form
trs://<server>/<id> mean “you can fetch the content with TRS id
<id> from the TRS server at
For example, if a WES server was asked to process
trs://trs.example.org/123456323, it would know that it could issue a GET request to
https://trs.example.org/api/ga4gh/trs/v2/tools/123456323 to learn how to fetch that object.
This recommendation is intended to mirror the discussion that went into the DRS URI scheme.
For informational purposes, we recommend that TRS implementations add themselves to https://github.com/ga4gh/tool-registry-service-schemas/blob/develop/registry.json to provide for the possibility of creating a global indexing service and to allow others to more easily discover a TRS implementation.
The entire schema is shown below, but a more useful form is the Swagger editor to view our schema in progress
Note that the swagger editor itself can kickstart a project by generating servers and clients in a variety of languages.
Authentication and Authorization
GA4GH recommends the use of the OAuth 2.0 framework (RFC 6749) for authentication and authorization. It is also recommended that implementations of this standard implement and follow the GA4GH Authentication and Authorization Infrastructure (AAI) standard.
While the TRS standard itself does not define any behaviour specific to authorization, given that it hosts and shares publicly available workflows. For future expansion, we recommend that if authorization is needed, that it follows the OAuth 2.0 recommendations as defined above.
- How do we track authorship? Should we track authorship of the tool metadata, the Docker image, or the underlying algorithm, or all of above?
- What do we need to provide to allow for indexing and external services like an external sparql service.