eduKateSG · Why Science?
Turn varied consent language into computable data-use terms—while keeping people, policy and lawful review in the decision loop
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 Use Ontology (DUO) is a controlled, machine-readable ontology for describing conditions on secondary use of human biomedical data. GA4GH lists DUO as current with Active Engagement and DUO v1.0, approved on 23 February 2021, as the last approved version. Its terms fall into permissions and modifiers, and disease-specific conditions can map to the Mondo Disease Ontology. Repositories can tag datasets, researchers can express an intended purpose, and matching software can help screen compatibility. DUO supports discovery and access review; it does not replace the original consent, applicable law, ethics oversight, a data access committee or scientific judgement. 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: Mondo Disease Ontology and harmonised disease concepts; GA4GH Data Connect and federated dataset queries; GA4GH Passports, Visas and portable researcher access; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Data Use Ontology product page, current DUO v1.0; Official Data Use Ontology repository and documentation; Official machine-readable DUO release; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, service interfaces and recommendations can change, so preserve the dated documentation and versions used.
A deeper reading route
DUO begins with a language problem. Consent forms and data-use statements can express similar conditions in different prose, making large catalogues difficult to search consistently. An ontology gives repositories stable identifiers, definitions and relationships for recurring concepts. That structure helps computers compare a stated research purpose with dataset conditions, while the original documents remain the authoritative context for responsible interpretation.
Permissions and modifiers play different roles. A permission describes a broad allowed research scope; a modifier adds a condition such as a disease focus, population restriction or limitation on commercial use. The combination matters. Reading one code in isolation can reverse the intended policy, so systems should preserve the full set, its version, provenance and any explanatory text supplied by the data steward.
Ontology matching uses hierarchy, not word resemblance. A disease-specific purpose can be compared through Mondo relationships, and a more specific research question may match a broader permitted category under a defined algorithm. That convenience is also a risk: hierarchy direction, negation and missing terms must be tested with examples approved by policy experts. A plausible automatic result is not automatically an authorised result.
DUO is designed to aid discovery and access review. It can narrow a catalogue to datasets that appear compatible and help a data access committee process requests more consistently. The committee still evaluates who is asking, the stated project, jurisdiction, agreements and any conditions not captured by the ontology. Computation makes review more legible; it does not dissolve accountability.
Versioning is part of the evidence. DUO releases are dated, identifiers are not silently deleted, and deprecated concepts remain traceable. A dataset tagged years ago may therefore require interpretation against both its recorded release and the current ontology. Repositories should preserve the exact term identifiers, release, mapping process and date rather than keeping only human-friendly abbreviations.
For students, DUO is a vivid example of how science, language and ethics meet. Classification can make a large library searchable, but categories are built for a purpose and carry assumptions. Asking who defined the term, what document it summarises and which decision remains human is excellent training for PSLE Science process skills, Secondary Science evidence evaluation and later work in biology, computing or research governance.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Describe | What uses and conditions apply to the dataset? | DUO permission and modifier identifiers | A computable policy summary |
| Propose | What does the researcher intend to do? | Structured purpose plus project context | A reviewable request |
| Match | Which tagged datasets appear compatible? | Ontology hierarchy and declared matching rules | A screened candidate set |
| Decide | May this use proceed responsibly? | Consent, law, ethics, agreements and DAC review | A governed access decision |
Inside this guide
1–12 · Foundations and design
- 1. Start with the consent and use question
- 2. Understand the current product
- 3. Use stable ontology identifiers
- 4. Keep the original wording
- 5. Separate permissions from modifiers
- 6. Treat no restriction carefully
- 7. Represent health and biomedical scope
- 8. Represent disease-specific use
- 9. Connect disease concepts to Mondo
- 10. Read hierarchy direction
- 11. Represent commercial-use limits
- 12. Represent population conditions
13–24 · Models and estimation
- 13. Represent age or research-setting conditions
- 14. Represent methods-development limits
- 15. Structure the research purpose
- 16. Match with explicit rules
- 17. Treat a match as screening
- 18. Keep the DAC in the loop
- 19. Explain negative conditions
- 20. Handle multiple tags together
- 21. Preserve curator provenance
- 22. Version ontology releases
- 23. Respect deprecation
- 24. Review updates and withdrawals
25–36 · Diagnostics and interpretation
- 25. Connect identity evidence separately
- 26. Connect discovery without exposure
- 27. Audit automated decisions
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics and logic
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready use record
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the consent and use question
A data-use tag should answer a defined question about permitted secondary research, not decorate a catalogue. Begin with the participant-facing consent, the data-use limitation statement and the decision process that must respect them.
Working checkpoint — Data Use Ontology: Write the authoritative document, decision owner and intended secondary use before selecting a term. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 2 of 36
2. Understand the current product
GA4GH lists DUO as a current, Active Engagement data model and ontology. The product page identifies DUO v1.0, approved on 23 February 2021, as the last approved version.
Working checkpoint — permission term: Record the product status, ontology release and access date. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 3 of 36
3. Use stable ontology identifiers
A DUO concept has a persistent identifier, label, definition and place in an ontology. The identifier—not an improvised abbreviation—is what lets machines and institutions refer to the same concept.
Working checkpoint — modifier: Store the full identifier and resolve it against the recorded release. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 4 of 36
4. Keep the original wording
A structured term summarises a policy condition; it is not a replacement for the consent form or data-use statement from which the condition was interpreted. Nuance can live outside the available vocabulary.
Working checkpoint — research purpose: Link every tag to the source wording and curator note. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 5 of 36
5. Separate permissions from modifiers
DUO groups terms into permissions and modifiers. A permission supplies the main research scope, while modifiers add constraints that must travel with it.
Working checkpoint — ontology hierarchy: Validate the entire tag set rather than displaying one headline code. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 6 of 36
6. Treat no restriction carefully
A broad permission does not mean public data, unlimited disclosure or freedom from privacy and security duties. Access method and permitted purpose remain separate questions.
Working checkpoint — data access committee: State access controls and disclosure rules beside the use category. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 7 of 36
7. Represent health and biomedical scope
A health, medical or biomedical permission can be broader than one disease while still excluding unrelated research. The stated purpose needs enough detail for a meaningful comparison.
Working checkpoint — Data Use Ontology: Describe the scientific aim, population and analysis rather than choosing a vague label. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 8 of 36
8. Represent disease-specific use
Disease-specific conditions need a disease concept as well as the DUO relationship that makes the restriction computable. Free-text disease names alone are difficult to compare reliably.
Working checkpoint — permission term: Record the mapped disease identifier and mapping evidence. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 9 of 36
9. Connect disease concepts to Mondo
GA4GH states that DUO incorporates inward and outward mapping to Mondo for disease-specific permissions. That lets matching systems use a maintained disease hierarchy.
Working checkpoint — modifier: Preserve both DUO and Mondo identifiers with their versions. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 10 of 36
10. Read hierarchy direction
A broad disease category and a narrower subtype are related but not interchangeable in every query direction. The official DUO documentation gives examples in which a specific purpose can retrieve broadly consented datasets while a broad purpose must not silently claim a narrower consent.
Working checkpoint — research purpose: Test parent-child cases with policy-approved fixtures. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 11 of 36
11. Represent commercial-use limits
DUO documentation includes conditions concerning commercial use and use by for-profit entities. These ideas are related but can support different policy questions.
Working checkpoint — ontology hierarchy: Do not collapse distinct modifiers into one commercial flag. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 12 of 36
12. Represent population conditions
A dataset can carry a population-related restriction, which needs more context than a bare group label. Population, ancestry, residence and recruitment are not synonyms.
Working checkpoint — data access committee: Preserve the curator wording and avoid inferring identity from a research label. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 13 of 36
13. Represent age or research-setting conditions
DUO documentation includes specialised conditions such as paediatric research. A tag should be applied only when its definition matches the governing statement.
Working checkpoint — Data Use Ontology: Check the official term definition before adding a modifier. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 14 of 36
14. Represent methods-development limits
A project developing an algorithm or assay may not match a disease study in the same way. DUO includes concepts used to distinguish methods research from other purposes.
Working checkpoint — permission term: Declare whether the work is method development, biological investigation or both. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 15 of 36
15. Structure the research purpose
Matching needs a structured description of the proposed research, not only dataset tags. The purpose can include disease, method, organisation and other facts relevant to conditions.
Working checkpoint — modifier: Collect the minimum truthful purpose fields needed for review. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 16 of 36
16. Match with explicit rules
An ontology supplies relationships; an application still chooses an algorithm for compatibility. Different systems can implement different assumptions or handle missing information differently.
Working checkpoint — research purpose: Version and publish the matching rules alongside the result. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 17 of 36
17. Treat a match as screening
A compatible result identifies a candidate for review. It does not create a legal right to the data or prove that every condition has been satisfied.
Working checkpoint — ontology hierarchy: Label outputs candidate, incompatible or unresolved rather than approved by default. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 18 of 36
18. Keep the DAC in the loop
GA4GH describes DUO as facilitating data access committee decisions. The committee can examine consent, credentials, agreements and context beyond the code set.
Working checkpoint — data access committee: Route ambiguous and high-impact cases to the accountable reviewer. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 19 of 36
19. Explain negative conditions
Restrictions are easy to mishandle when a system treats absence as permission. A missing modifier may mean false, unknown, not curated or not applicable.
Working checkpoint — Data Use Ontology: Use explicit states and forbid unknown-to-allowed coercion. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 20 of 36
20. Handle multiple tags together
A dataset can have several simultaneous conditions. Matching each independently and then taking a union can admit projects that violate the combined policy.
Working checkpoint — permission term: Test conjunction, precedence and contradiction handling. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 21 of 36
21. Preserve curator provenance
A trustworthy tag record names who mapped the wording, when, with which procedure and from which document. Later reviewers need to reconstruct the interpretation.
Working checkpoint — modifier: Keep curator, date, source and quality status with every assignment. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 22 of 36
22. Version ontology releases
The official repository publishes dated releases and maintains persistent identifiers. Labels, definitions and relationships can still evolve.
Working checkpoint — research purpose: Pin the exact OWL release used for tagging and matching. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 23 of 36
23. Respect deprecation
The DUO project states that identifiers are not deleted and that meaning-changing replacements receive new identifiers. Deprecated terms therefore remain historical evidence but should not silently drive new decisions.
Working checkpoint — ontology hierarchy: Resolve deprecation links and log any migration. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 24 of 36
24. Review updates and withdrawals
Consent status, agreements or institutional policy can change after initial cataloguing. An ontology release alone cannot express every operational update.
Working checkpoint — data access committee: Define refresh, withdrawal and urgent-block procedures. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 25 of 36
25. Connect identity evidence separately
DUO describes intended and permitted uses, while GA4GH Passports can carry researcher attributes or grants. Combining them requires an explicit policy engine, not string matching.
Working checkpoint — Data Use Ontology: Evaluate purpose conditions and researcher credentials as separate evidence sets. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 26 of 36
26. Connect discovery without exposure
Data Connect or Beacon can help find candidate datasets, but search responses must respect the catalogue’s disclosure and access policy. DUO compatibility does not make sensitive metadata public.
Working checkpoint — permission term: Apply discovery controls before returning records. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 27 of 36
27. Audit automated decisions
A screening service should preserve inputs, releases, rule version, intermediate matches and final human disposition. Otherwise errors cannot be diagnosed or appealed.
Working checkpoint — modifier: Create a decision record without exposing sensitive request details. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
Sorting fictional experiments by allowed purpose shows why classification needs definitions and why one label cannot answer every safety question.
Working checkpoint — research purpose: Use non-personal examples and ask pupils to explain each category. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 29 of 36
29. Connect to Secondary Science
Evidence evaluation asks whether a dataset can answer the proposed question and whether the planned reuse respects its conditions. Technical availability is not scientific suitability.
Working checkpoint — ontology hierarchy: Compare two fictional purposes against one transparent rule set. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 30 of 36
30. Connect to mathematics and logic
Ontology matching uses sets, hierarchy, conjunction, negation and three-valued states such as true, false and unknown. Small logical mistakes can change access outcomes.
Working checkpoint — data access committee: Draw a decision table and test boundary cases. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 31 of 36
31. Connect to computing
OWL, persistent identifiers, graph relationships, APIs and policy engines show how formal knowledge representation supports research infrastructure.
Working checkpoint — Data Use Ontology: Inspect one term in both human-readable and machine-readable form. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Section 32 of 36
32. Connect to pathways
DUO sits at the intersection of genomics, ontology engineering, data stewardship, ethics and cybersecurity and can illuminate STEM education and career pathways.
Working checkpoint — permission term: Check current official course and professional requirements separately. Read every automated compatibility result beside consent, law, ethics, agreements and accountable human review.
For future study, connect ontology work to biology, logic, computing and ethics while checking official pathways separately.
Section 33 of 36
33. Did you know?
The official DUO documentation describes a melanoma-purpose query that can use disease hierarchy to find broadly compatible datasets. The useful result comes from relationships, not from searching for the same word.
Working checkpoint — modifier: Teach the hierarchy rule before trusting the search result. Preserve unresolved and rejected cases; approved access is not the complete decision history.
For scientific writing, cite the ontology release, source limitation and decision boundary.
Section 34 of 36
34. Write a reader-ready use record
A clear report names the source statement, DUO and disease identifiers, releases, curator, purpose, matching rules, result and accountable decision.
Working checkpoint — research purpose: Separate machine recommendation from final authorisation. Separate computable discovery and screening from final authorisation and scientific suitability.
For students, ask who defined the category, what wording it summarises and which decision remains human.
Section 35 of 36
35. Build a validation ladder
Resolve identifiers, inspect definitions, test permission-modifier combinations, test disease hierarchy direction, review unknowns, then compare with human decisions.
Working checkpoint — ontology hierarchy: Stop automation when policy experts disagree with the fixture outcome. Treat term, release, disease and policy identifiers as decision inputs: a silent mismatch can change the result.
For parents, ask how consent, privacy and accountability remain visible when data discovery is automated.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver source wording, tag assignments, ontology files or hashes, disease mappings, purpose record, rule version, test cases, decision log and review notes.
Working checkpoint — data access committee: Make every access recommendation traceable to evidence and ownership. Keep source wording, DUO and disease identifiers, ontology releases, purpose, rules and decision provenance together.
For a classroom model, use fictional datasets and transparent purpose cards rather than personal information.
Contents · Previous section · Continue to the Science Learning Hub