Data Model

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.

Design Decisions

We are starting with a read-only API due to potentially different views and approaches to registration/security.

Multiple formats for descriptors such as CWL and WDL are permitted.

TRS URIs

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 <server>.

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.

Misc

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.

Outstanding Questions

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.

Other
  • 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.