Getting started

A short, practical walkthrough of the African DSI DataBank as an actual researcher experiences it — browsing, searching, requesting access to a gated record, running a compute job across the Hub and its connected nodes, and downloading a result. If you're building against the API directly instead, see the API guide; unfamiliar terms are explained in the glossary.

Prefer to explore live? Take an interactive tour of the homepage → — a short, click-through spotlight walkthrough, complementary to the written steps below, not a replacement for them.

Continental Hub: The single top-level aggregation point for the whole federation — the catalog, admin/curation, mirroring, and access/consent tracking all live here.
Sub-regional Hub: Aggregates every National Hub in one AU region.
National Hub: Aggregates every Spoke in one country.
Spoke: An individual institution's own data holder — where a genome or other record is actually captured.

More terms, including these four in more depth, are in the glossary.

1. Browse the species catalog

The homepage is a live, searchable catalog of every species this federated Hub currently holds data for — aggregated from every connected Sub-regional, National, and Spoke node across the continent, not just the Hub's own local holdings. Search by scientific name, or filter by genome type (whole assembly, organellar, virus/prokaryote, or individual sequence) using the form above the results. Each result card links to that species' own detail page.

2. Explore a species page

A species page (/species/[id]) is the single place everything this platform knows about that species comes together, in the order the data actually flows: local/ indigenous names, an embedded genome browser (when a real assembly file is available), sequence records (genomes, transcriptomes, proteins, proteomes), geographic range, chemical and metabolic profiles, predicted protein structures, and field/specimen and cellular/ molecular imaging — each section only appears when that species actually has that kind of data, so a page never shows an empty placeholder. Every citable record carries a real, durable citation id (AFDSI-...) with a one-click copy/BibTeX export — look for the small "Cite" chip next to a record.

3. Browse by data type

Beyond a single species' own page, every major data type also has its own dedicated, filterable listing: Genomes (with country/license/assembly-quality filters and a bulk CSV/Darwin Core Archive export), Protein Structures (an interactive 3D viewer per structure), and the rest of the Biomolecular Data and Imaging menus in the top navigation. The Data Dashboard gives a per-species matrix of exactly which data types the platform actually holds — useful for spotting real gaps at a glance before searching for something that isn't there yet.

4. Create an account

Every page above is fully browsable without an account — search, read, and explore freely. An account is only needed to request gated data, submit a compute job, or (if you operate a node) manage that node's own settings. Two separate applications exist, and it matters which one you want: Apply for an account is for someone who already knows which node they'll be operating (or wants access to gated records); Register a new node is for standing up a brand-new node in the federation in the first place. If you're unsure which applies to you, start with Apply — its own form explains the distinction and cross-links to the other one.

5. Request access to a gated record

Most records are fully public. A record tagged regional_researcher or restricted needs an approved access request first — from that record's own page, or via Access requests, submit a request naming the specific record and your purpose. regional_researcher-tier requests may involve an automated identity check against a third-party ABS (Access and Benefit-Sharing) service; restricted-tier requests are always reviewed by hand and are never auto-approved. You can track the status of your own requests from the same page at any time. Building against the API directly instead of the GUI? The API guide's "A full worked example" section has a complete, runnable script driving this exact search → request access → download flow end to end.

6. Run a compute search

From Compute requests, you can run a real query — a similarity search, a phylogenetic tree build, or (for nodes that offer it) a specific containerized bioinformatics tool — against the Hub's own aggregated holdings and/or any number of real connected nodes at once, in a single submission. The form is fully explorable while logged out; only clicking Submit actually requires an account. If a target node has published its own participation terms (e.g. an attribution request), they appear right below that node once you select it — worth a read before submitting.

7. Download your results

Once every target in a submission finishes, you'll see each one's own outcome inline on the same page — matched hits, a real Newick tree, or a tool run's exit code and output. Where a real output file was produced, a "Download output" button fetches it directly. If you're logged in with a real email on file, you'll also get a short email the moment the whole submission finishes running, so there's no need to keep the tab open.

8. Get help

Check the FAQ first — or the small "Help" chat button in the bottom-right corner of any page, which answers common questions right where you are. Still stuck, or found a bug? Use the Contact Us form (Operations → Contact Us, or the same form on the homepage) and choose "Testing feedback, bug report, request new feature" (or the category that best matches what you're reaching out about) — most submissions are automatically tracked as a real, referenceable ticket, and the confirmation email includes a direct link back to the same conversation thread, with no account needed to reply on it.