Managing Track Hubs with the Registry - An Overview

This section of the documentation is for track hub creators who want to register their data hubs with the Registry. Go to search documentation if you only intend to explore interesting data hubs.

Client Registration

You must have an account with the registry before submitting and managing any data. To create an account, go to the registration page.

The client registration interface captures basic contact information (i.e. first/last name, institute, email) of the person responsible of managing the track data hubs with the registry, together with credentials necessary to use the REST API to register and update track data hubs with the registry, and to sign in and access the registry web dashboard. The interface also asks to configure some options that control automatic track hub monitoring by the registry.

Upon registration, you're immediately logged in into the system and presented the dashboard.

Track Hub Management

Once you Sign Up, you can start using the Registration API, which allows you to use RESTful workflows to manage your track data hubs with the Registry.

Using this API, you can:

Register track data hubs with the registry;
List the all your registered track hubs or data bases;
Get/Update/Delete a given track hub in the registry

Alternatively, you can use the dashboard on the registry web interface to query the status of your registered track hubs, or view and delete them from the registry.

The Submission Process

The figure below highlights the main steps involved when submitting a track data hub to the Registry.

The process begins with your client authenticating itself and submitting the URL of a remote, publicly accessible track hub using one of the Registry REST APIs.

The server then runs the hubCheck program from UCSC to check that the files in the hub are correctly formatted. It is indeed a good idea to test your hub with this program before submitting it in order to avoid an unnecessary rejection.

If the hub passes the validation above, it is parsed into its various components, mainly the various assembly names and the corresponding data configuration and directories. In order to correctly identify each assembly, the Registry tries to map their names (as declared in the genomes.txt file) to valid INSDC accession numbers. See Genome Assembly Support for a discussion about the motivation and details of this approach.

If all genomes are mapped, the different genome assembly database configuration files (i.e. trackDb.txt) are converted each one into a separate JSON document. This is an important aspect of the whole submission process. The Registry does not store a representation of a track hub as a whole; a track hub is implicitly represented by its set of trackDbs which store configuration/visualisation options for the different assemblies managed by the hub. See Modelling Track Hubs for more information about the design principles.

Each one of these trackDB JSON documents is validated against a schema describing the structure and content of valid trackDb JSON documents. If validation succeeds for all of them, the documents are finally stored in the Registry and are immediately available for search.