Public Hub Guidelines
This page is intended to lay out guidelines for those who are trying to create Public Hubs. If you’ve created a hub that you feel meets these requirements and is of general interest to the research community, please contact us at firstname.lastname@example.org to have it added to the list.
(As a reference for interpreting trackDb.txt setting use the Hub Track Database Definition glossary)
The following guidelines must be met before your hub will be added to our public list:
- Required for both track and assembly hubs:
- You must have a description page for every configuration page (composite, superTrack or stand alone track). Note that multiple tracks and/or composites can use the same description page with the “html” setting.
- All of your description pages MUST have a contact email address prominently displayed.
- Have no more than 10 tracks with visibility set to display (in full, pack, dense, or squish) as default upon first connecting your hub.
- A descriptionUrl html page specified in your hub.txt. This should a URL to a description page for your entire hub and should include key search terms for the hub contents or a full-text paper that describes that the data in your hub. The descriptionUrl webpage is indexed to enable users to find your hub with our hub search function, so the more terms on your descriptionUrl page the more likely interested users will find your hub.
- Required for only assembly hubs:
- Add a gateway page for each assembly by having a htmlPath line for each genome not already hosted by UCSC in genomes.txt. Assembly Hubs Wiki
- The following settings should properly set in your genomes.txt (The last 3 settings will make it easier to find assembly hub species in hgGateway by UI search):
These guidelines in the following sections are recommended to improve user experience, but are not required to be implemented before the hub is added to our list of Public Hubs.
Track organization recommendations
Related tracks can be grouped in a few different ways, namely superTracks, multiWigs, and composites. If your hub includes a large number of tracks, the grouping of tracks may be necessary. This will prevent your hub’s track group from being an overwhelming mess of individual tracks and can make user configuration of your tracks easier.
Related tracks of the same data type (e.g. a set of related bigBed tracks) should be combined into composites where appropriate.
- Have multi-view only when there is more than one view. Views ideally give alternate access to the same data (e.g. signals and called peaks). Keep in mind that the value of views is that they allow for more than one data/configuration type (e.g. bigBed and bigWig) in a single composite. All subtracks of a view must have the same data type. Likewise, all subtracks of a non-multi-view composite must be the same type.
- Recommendations for using dimensions with your composite tracks:
- There should be no dimensions with a single entry (do not have only one cell line represented in dimX=cell), unless data growth is expected to fill in additional entries.
- Using only one dimension: preferably use dimX (e.g. dimensions dimX=cell). This saves vertical User Interface space, but is not always the best choice.
- Using two dimensions: use dimX and dimY (e.g. dimensions dimX=cell dimY=mark)
- Using more than two: use dimX, dimY on the most important dimensions. Then use dimA,B,C as needed on lesser dimensions. (e.g. dimensions dimX=cell dimY=mark dimA=donor_id)
- The A,B,C.. dimensions should probably use filterComposite (e.g. filterComposite dimA)
- Each dimension and views should be represented in sortOrder, ideally in order of dimX, dimY, dimA,B,C, view (e.g. sortOrder cell_type=+ mark=+ donor_id=+ view=+). But the hub user may wish for a different sortOrder, which is fine.
- Tags of subGroup/dimension should be short and sweet with no special chars. Also labels can have HTML codes embedded (e.g. NOT CPG_methylation_%=CPG_methylation_% RATHER mpct=CPG_methylation_&_#37)
- Never represent the same subgroup in both view and as a dimension (e.g. NOT dimensions dimX=view). For that matter a subgroup should never be in two dimensions (e.g. NOT dimensions dimX=cell dimY=mark dimA=cell). The composite will appear to function but multiple ways of selecting the same thing will create a confusing and inconsistent User Interface.
Extremely large hubs may use superTracks as well to achieve a meaningful hierarchy. Super tracks can be used to group together any type of related tracks; for example, you could combine a multiWig, a composite and a bigBed track together into a single superTrack.
Track display recommendations
- Avoid setting a composite track and all of its subtracks to the same visibility. When you have composite tracks that are hidden by default, it is best to still designate some subtracks to display when the composite track is turned on (visibility dense, versus the default of hide). This provides an example of your track data to users who turn on your composite track. If no subtracks are turned on by default, a user who changes your composite track visibility to "show" won't see anything.
- The shortLabel text should be under 17 characters, or meaningful information may be cut off from display when tracks are set to "dense" visibility.
- The length for a longLabel should be limited to around 75 characters.
Track description page recommendations
- The description page should preferably contain UCSC's standard Description, Methods, Contacts... sections as defined here under "html" and here is an example template.
- Please note that hosting hub files on HTTP tends to work even better than FTP because of the difference in the number of open tcp connections needed.
- The use of metadata lines can be supported, users need to be well aware that support may be replaced by another system in the future.
Sometimes the servers hosting public hubs will experience administrative changes and no longer successfully serve up hub files. In most cases it is likely that new firewalls are limiting the access at the institution and are causing these connection problems. One can please ask their institution's admins to add this IP range as exceptions that are not limited:
These IP addresses are currently used by official genome browser mirrors:
- 128.114.119.* = genome.ucsc.edu
- 18.104.22.168 = european mirror, genome-euro.ucsc.edu
- 22.214.171.124 = asian mirror, genome-asia.ucsc.edu
- 126.96.36.199 = genome-test.ucsc.edu, used by developers and for debugging
Although our site is creating many requests to an institution, each is small and quickly satisfied by the server, so the total load on your webserver should be limited and system administrators will likely not have an issue with adding this exception.
Public Hub Examples
The browser's public hubs provide excellent resources to see how others have created hub structures. As a reference for interpreting trackDb.txt lines use the Hub Track Database Definition glossary. For an example of hub configuration and documentation, one example is the ENCODE Analysis hub:
Regarding creating meaningful html documentation, if you are creating a hub based on a paper, we suggest the paper's abstract as a useful start for your track's Description section. The Methods section should have more detail, and please include a contact for questions. Lastly, it is best to assume a broad audience of students as well as researchers. For example, it is best to spell out common acronyms for those who may be new to genomics.