eduKateSG · Why Science?
Give a data object one portable retrieval story—even when its storage system, access method or cloud location changes
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. The GA4GH Data Repository Service, or DRS, is a read-only API that maps a logical object identifier to metadata and one or more ways to retrieve the represented bytes. GA4GH lists DRS as a current product and version 1.4 as the last approved version. DRS can make data access portable across repositories and infrastructure, but it does not interpret the file, grant permission by itself or guarantee that a downstream scientific analysis is correct. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: GA4GH Beacon v2 and federated genomic discovery; GA4GH VRS and computable variant representation; GA4GH Phenopackets and computable case representation; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Data Repository Service product page, approved v1.4; Official GA4GH DRS 1.4.0 specification; Official GA4GH DRS specification repository; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, implementations and recommendations can change, so preserve the version, access date and documentation used.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Identify | Which immutable object is intended? | DRS ID, self URI, aliases and version context | A resolvable logical reference |
| Describe | What can a client verify before retrieval? | Size, MIME type, checksums and timestamps | A bounded object description |
| Access | Which approved route returns the bytes? | Access methods, URLs, IDs, regions and headers | A usable retrieval plan |
| Govern | Who may retrieve it and how is use audited? | Authentication, authorisation, logs and purpose limits | A permitted, traceable transfer |
Inside this guide
1–12 · Foundations and design
- 1. Start with the object, not the bucket
- 2. Understand the approved product
- 3. Keep DRS read-only
- 4. Treat the DRS ID as immutable
- 5. Allow multiple IDs cautiously
- 6. Know the limits of version semantics
- 7. Resolve hostname-based DRS URIs
- 8. Resolve compact-identifier DRS URIs
- 9. Read the DrsObject
- 10. Use self_uri for portable citation
- 11. Verify object size
- 12. Read MIME type as a hint
13–24 · Models and estimation
- 13. Use checksums for integrity
- 14. Keep aliases human-friendly
- 15. Choose an access method
- 16. Distinguish access_url from access_id
- 17. Protect returned headers
- 18. Respect regions and data residency
- 19. Do not confuse discovery and retrieval
- 20. Connect workflows to data
- 21. Understand atomic objects
- 22. Handle compound objects carefully
- 23. Discover authentication modes
- 24. Separate authentication from authorisation
25–36 · Diagnostics and interpretation
- 25. Use Passports in their proper role
- 26. Treat signed URLs as secrets
- 27. Handle delayed responses
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready access report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the object, not the bucket
DRS gives a client a standard object view while the repository keeps control of its physical storage and access policy.
Working checkpoint — Data Repository Service: Write the object, intended use and authorised caller before choosing a retrieval route. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 2 of 36
2. Understand the approved product
GA4GH describes DRS as a standardised set of retrieval methods that works regardless of repository architecture; its product page lists v1.4 as the last approved version.
Working checkpoint — DRS ID: Record DRS 1.4.0 when that specification governs the exchange. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 3 of 36
3. Keep DRS read-only
The DRS 1.x specification exposes retrieval, not repository upload, editing, deletion or version-management workflows.
Working checkpoint — DrsObject: Document the separate system that creates or updates objects. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 4 of 36
4. Treat the DRS ID as immutable
The specification requires one DRS ID always to return the same object data, or the same set for a collection, which supports reproducibility.
Working checkpoint — access method: Issue a new ID when the represented bytes change. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 5 of 36
5. Allow multiple IDs cautiously
A repository may expose more than one DRS ID for the same object, so identifier equality and byte equality are different questions.
Working checkpoint — checksum: Compare checksums before declaring two IDs equivalent. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 6 of 36
6. Know the limits of version semantics
DRS 1.x does not define “latest version” or enumerate all versions, although an implementation may encode version hints in IDs.
Working checkpoint — authorisation: Never infer freshness from an opaque ID. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 7 of 36
7. Resolve hostname-based DRS URIs
A hostname-based drs:// URI combines a DRS server hostname with an object ID and resolves through the standard HTTPS endpoint.
Working checkpoint — Data Repository Service: Percent-encode IDs and test the exact URI with a compliant client. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 8 of 36
8. Resolve compact-identifier DRS URIs
Compact DRS URIs use registered resolver namespaces, adding durable indirection but also a resolver dependency and security surface.
Working checkpoint — DRS ID: Record the resolver response and cache policy. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 9 of 36
9. Read the DrsObject
A successful object response can include ID, name, self URI, size, MIME type, timestamps, checksums, aliases and access methods.
Working checkpoint — DrsObject: Validate required fields before following an access route. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 10 of 36
10. Use self_uri for portable citation
The self URI is the object’s DRS reference, not necessarily the final storage URL that returns bytes.
Working checkpoint — access method: Preserve both the DRS URI and retrieved access method. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 11 of 36
11. Verify object size
Size helps plan transfer and detect truncation, but the count is meaningful only for the represented object and version.
Working checkpoint — checksum: Compare advertised and received byte counts. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 12 of 36
12. Read MIME type as a hint
MIME type can guide handling, but DRS intentionally treats each atomic object as an opaque blob rather than interpreting scientific semantics.
Working checkpoint — authorisation: Validate the actual file format with a domain tool. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 13 of 36
13. Use checksums for integrity
Checksum records let a client test whether retrieved bytes match the described object. Algorithm type must travel with the digest.
Working checkpoint — Data Repository Service: Recompute the stated checksum after transfer. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 14 of 36
14. Keep aliases human-friendly
Aliases can aid recognition, but they do not replace the DRS ID and may be reused or changed by local systems.
Working checkpoint — DRS ID: Resolve workflows by ID, not display name. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 15 of 36
15. Choose an access method
An object may advertise several routes such as HTTPS or cloud-native locations, each with its own region and authorisation requirements.
Working checkpoint — DrsObject: Select a supported route deliberately and log the choice. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 16 of 36
16. Distinguish access_url from access_id
A direct access URL may be returned immediately, while an access ID can require a second call to generate an expensive or short-lived mechanism such as a signed URL.
Working checkpoint — access method: Do not treat an access ID as downloadable content. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 17 of 36
17. Protect returned headers
An access URL can include headers needed for retrieval; those values may contain credentials or other secrets.
Working checkpoint — checksum: Keep them out of logs, screenshots and published bundles. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 18 of 36
18. Respect regions and data residency
A cloud access method may specify a region, which affects latency, egress cost and sometimes governance obligations.
Working checkpoint — authorisation: Check permitted processing location before moving data. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 19 of 36
19. Do not confuse discovery and retrieval
Beacon can help discover that relevant data exist; DRS describes how an authorised client may retrieve a specific object.
Working checkpoint — Data Repository Service: Keep discovery identifiers linked to the selected DRS object. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 20 of 36
20. Connect workflows to data
A workflow system can receive a DRS URI rather than being rewritten for each repository’s proprietary storage interface.
Working checkpoint — DRS ID: Test resolution in the real execution environment. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 21 of 36
21. Understand atomic objects
DRS can represent BAM, VCF, CSV or other files as opaque bytes; applications, not DRS, supply their scientific meaning.
Working checkpoint — DrsObject: Store domain metadata in an appropriate complementary service. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 22 of 36
22. Handle compound objects carefully
The v1.4 specification documents compound-object best practices and deprecates earlier folder-like bundles.
Working checkpoint — access method: Avoid designing new dependencies on deprecated bundle behaviour. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 23 of 36
23. Discover authentication modes
An implementation can expose options describing whether object or access calls use none, Basic, Bearer or Passport-based authentication.
Working checkpoint — checksum: Probe the advertised mode before retrying with credentials. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 24 of 36
24. Separate authentication from authorisation
Credentials establish or convey caller identity; repository policy decides whether that caller may access this object.
Working checkpoint — authorisation: Test least-privilege accounts and denied paths. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 25 of 36
25. Use Passports in their proper role
The specification allows a GA4GH Passport in authorised requests, but issuing a Passport belongs to a broker outside DRS.
Working checkpoint — Data Repository Service: Document the trust chain and token issuer. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 26 of 36
26. Treat signed URLs as secrets
A signed URL may grant temporary access to object bytes even without another prompt.
Working checkpoint — DRS ID: Use short lifetimes and prevent referrer or log leakage. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 27 of 36
27. Handle delayed responses
A 202 response can signal asynchronous preparation with a Retry-After header. Repeated immediate calls can waste resources.
Working checkpoint — DrsObject: Use bounded backoff and preserve the object ID. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A library call number that still works after books move shelves is a safe analogy for logical IDs and physical locations.
Working checkpoint — access method: Use fictional objects and verify the returned item against a checksum card. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 29 of 36
29. Connect to Secondary Science
Genomic files, identifiers and integrity checks show that reproducibility depends on retrieving the same evidence, not merely a similarly named file.
Working checkpoint — checksum: Trace one toy object from logical ID to verified bytes. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 30 of 36
30. Connect to mathematics
Byte counts, checksum comparisons, retry intervals and transfer costs turn infrastructure choices into measurable quantities.
Working checkpoint — authorisation: Estimate transfer time only after defining file size and bandwidth. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 31 of 36
31. Connect to computing
REST APIs, URIs, JSON, HTTPS, redirects and credentials make DRS a practical study in abstraction and secure systems.
Working checkpoint — Data Repository Service: Write tests for malformed IDs, expired URLs and checksum failure. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Section 32 of 36
32. Connect to pathways
Portable research data access links biology, cloud engineering, cybersecurity and data stewardship and can illuminate STEM pathways.
Working checkpoint — DRS ID: Check current official course and professional requirements separately. Read each retrieved object beside its checksum, size and domain-format validation.
For future study, connect cloud data to biology, computing and security while checking official pathways separately.
Section 33 of 36
33. Did you know?
DRS deliberately does not need to know whether an opaque object is a genome, an image or a table; the receiving application interprets the bytes.
Working checkpoint — DrsObject: Keep transport metadata and scientific metadata in their proper layers. Preserve denied, delayed and failed requests; a successful shortlist is not a complete access record.
For scientific writing, name the DRS version, object identity and checksum.
Section 34 of 36
34. Write a reader-ready access report
Name the DRS version, object ID, self URI, checksum, access type, authorisation context, retrieval time and validation result.
Working checkpoint — access method: Redact secrets while preserving an auditable path. Separate portable retrieval from scientific interpretation and permission to reuse.
For students, ask whether the logical object and physical storage location are being confused.
Section 35 of 36
35. Build a validation ladder
Resolve the URI, inspect metadata, authorise retrieval, verify size and checksum, then validate the domain format and intended scientific use.
Working checkpoint — checksum: Stop at the first failed rung. Treat object IDs, checksums and access headers as scientific and security data.
For parents, ask who authorises retrieval and how the returned bytes are verified.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver the permitted DRS references, manifest, checksums, retrieval log, software versions, validation report and governance notes—not copied restricted data by default.
Working checkpoint — authorisation: Make every retrieved result traceable to an immutable object. Keep the DRS version, object ID, metadata, access method and retrieval result together.
For a classroom model, use fictional library objects rather than real research data.
Contents · Previous section · Continue to the Science Learning Hub