eduKateSG · Why Science?
A suggested term is a helpful starting point for a decision you can explain
Choose the closest question, or read the guide from the beginning. Each chapter keeps its explanation, example and next step visible.
A fictional observation table contains “leaf length”, “leaf len.” and “size”. An annotation service can help propose consistent vocabulary for the first two, but the third may need information that the table never recorded. ZOOMA makes text-to-ontology annotation a useful subject for Science learning: how do we benefit from suggestions while keeping evidence and judgement visible?
The official ZOOMA2 development README describes mapping free-text property values to ontology terms using curated mappings, lexical matching and embedding similarity search. That is a description of the development project, not a claim that every public deployment exposes identical methods or controls. EMBL-EBI's BioSamples curation guidance documents a concrete use of ZOOMA for automatic ontology annotation with a high-confidence acceptance policy.
This article focuses on reviewing annotation suggestions for source text. It complements eduKate's existing EFO, CMO and measurement-method guides, which explain what particular scientific fields mean. Primary Science and PSLE Science learners can begin with clear observation notes; Secondary Science and computing learners can examine a fictional annotation batch. All phrases, scores, test results and reviewer decisions below are invented for teaching and are not reported outputs or performance measurements of ZOOMA.
Follow the connected evidence: Experimental Factor Ontology; Clinical Measurement Ontology; Measurement Method Ontology. For education and school-choice guidance, use the Education Hub; for possible work directions, continue to Careers by Subject Capability. These routes are separate from the specialist topic here.
| Layer | Question | Record | Boundary |
|---|---|---|---|
| Original text | What was actually written? | Exact phrase and field context | Not a cleaned replacement alone |
| Suggestion | Which concept was proposed? | Candidate, source and returned evidence | Not an accepted fact |
| Review | Does it fit this record? | Decision, rationale and missing context | Not a score-only rule |
| Evaluation | How did the workflow perform? | Reference decisions and counted errors | Not an invented universal accuracy |
Inside this guide
Chapters 1–10 · Meaning and evidence
- 1. Did You Know? A consistent label can still describe the wrong thing
- 2. Separate candidate generation from acceptance
- 3. Understand the documented project without guessing deployment details
- 4. Preserve source text before normalising it
- 5. Field context can matter as much as the phrase
- 6. Build a small fictional annotation batch
- 7. Read the candidate definition before the confidence field
- 8. A high-confidence policy belongs to a defined workflow
- 9. Repeated wording should not erase different contexts
- 10. Protect negation and uncertainty
Chapters 11–20 · Comparison and learning
- 11. Keep unavailable, unresolved and negative records distinct
- 12. Create reference decisions for evaluation
- 13. Work through fictional precision and recall
- 14. Review error types before adjusting a policy
- 15. Keep human review accountable and revisable
- 16. Version the input, suggestion and accepted annotation
- 17. A Primary Science activity on clearer observation notes
- 18. A Secondary Science project on evaluating suggestions
- 19. Frequently asked questions about annotation suggestions
- 20. Finish with one accepted, one rejected and one unresolved record
CHAPTER 1 OF 20 · Understand annotation suggestions
1. Did You Know? A consistent label can still describe the wrong thing
Standardisation improves consistency only when the chosen concept fits the source. If “size” is interpreted as length in every row, the table may look wonderfully tidy while misrepresenting rows that meant mass or count. The practical lesson is to preserve original wording and field context before adding a controlled annotation. A tidy output is not sufficient evidence of a correct interpretation.
Our fictional record has a field headed “observation” and a value “large”. Without a definition of the comparator, object or property, several interpretations remain possible. A suggested term can be useful for review, but it should not become an accepted fact merely because the service returned one. The missing context belongs to the source record, not to the software's confidence in its candidate.
Try an annotation exercise with three outcomes: accept, reject and ask for clarification. Make the reason visible for each outcome. This changes the task from “fill every blank” to “improve meaning without inventing detail”. It is a positive scientific habit because it leaves the next reviewer a clear route to continue, even when the current evidence cannot support a precise term.
CHAPTER 2 OF 20 · Understand annotation suggestions
2. Separate candidate generation from acceptance
Candidate generation asks which terms might fit a phrase. Acceptance asks whether a particular candidate is supported by this record and suitable for the intended use. Keep the two stages separate in a recommended workflow. This allows a helpful suggestion to remain available without presenting it as a completed human judgement.
For the fictional phrase “leaf len.”, a candidate referring to leaf length may be plausible when the field documentation confirms the abbreviation. For “size”, the same candidate is not justified without more detail. The candidate can be recorded in both cases, but the acceptance decisions should differ. Identical software suggestions do not require identical decisions when the source evidence differs.
Use fields for original text, candidate identifier, returned evidence, reviewer decision and rationale. Mark generated and accepted annotations clearly. A future reader should not have to infer which stage a row reached. This makes review easier to organise and lets teams revise a decision without losing the original suggestion, input or reasoning that led to the earlier state.
CHAPTER 3 OF 20 · Understand annotation suggestions
3. Understand the documented project without guessing deployment details
ZOOMA2's development README names curated mappings, lexical matching and embedding similarity as approaches for proposing ontology terms. Source: official ZOOMA2 README. These approaches offer different routes to candidates, but the README alone does not establish a public instance's precise configuration, active version or performance on a particular dataset. Consult the documentation of the actual deployment before depending on specific controls.
For teaching, curated prior decisions suggest a useful starting point; lexical similarity compares wording; embedding similarity can propose candidates beyond identical text. None of these descriptions proves that a candidate fits an underspecified observation. The reviewer still needs the source's meaning and the candidate's definition. Keep the explanation conceptual rather than inventing undocumented scoring formulas.
Avoid claims such as “this service always understands abbreviations” or “this method guarantees the correct term”. A reproducible workflow records the returned evidence and the configuration actually used, where available. Students can simulate the three routes with local cards before using a live service. The exercise should teach how evidence differs, not pretend that a classroom simulation measures the professional project's algorithms.
CHAPTER 4 OF 20 · Understand annotation suggestions
4. Preserve source text before normalising it
Text cleaning can make lookup easier, but it can also remove meaning. Keep the exact original phrase and a separate normalised form, with a record of any transformation. Recommended cleaning rules should be justified by the field's documentation rather than chosen solely because they increase match rates. A transformation that improves retrieval can still damage interpretation.
Imagine fictional phrases “no increase”, “increase” and “possible increase”. Removing short words would collapse important differences. Similarly, expanding an abbreviation without checking its project-specific meaning could replace uncertainty with an invented assertion. Preserve negation, uncertainty and qualifiers, and inspect whether a proposed annotation carries the same meaning as the original phrase.
A small cleaning log may be enough: trimmed surrounding whitespace, expanded a documented abbreviation, retained the source phrase unchanged. Do not overwrite the raw column. This gives reviewers a route back when a candidate seems wrong. It also helps students understand why scientific writing matters: a few careful words can distinguish an observation from its absence, a possibility or a conclusion the evidence does not yet support.
CHAPTER 5 OF 20 · Understand annotation suggestions
5. Field context can matter as much as the phrase
A phrase has a role within a record. “Length” in a quantity field, a method description and a free-text comment may not be used in the same way. A recommended annotation review preserves the field name, data dictionary and relevant record context beside the value. Do not send or interpret a phrase as if its surrounding structure were always irrelevant.
In a fictional table, the value “ruler” appears under method, while “centimetres” appears under unit. Mapping either into a quantity field would confuse different layers of the measurement. The recently published eduKate CMO and MMO guides help readers distinguish what was measured from how it was measured. A term suggestion becomes easier to evaluate once the field's scientific job is clear.
Define the target annotation field before reviewing candidates. Is it intended to describe an organism, a structure, a quantity, a process or another concept? If several layers are mixed in one source column, separate them through a documented review rather than forcing one annotation to carry all meanings. This improves consistency by clarifying the record, not by erasing its important distinctions.
CHAPTER 6 OF 20 · Review a fictional batch
6. Build a small fictional annotation batch
Our worked batch contains eight invented records. Two explicitly say “leaf length in centimetres”. Two say “leaf mass in grams”. One says “leaf count”. One says “size”. One says “no increase in length”. One says “measurement unavailable”. The batch is deliberately small enough that every decision can be reviewed by a learner and challenged by a partner.
Create local candidate cards for length, mass, count and an increase observation, each with a clear definition and a clearly local identifier. Keep unresolved and unavailable states separate. A candidate for length may fit the first two records, while the ambiguous “size” record needs clarification. The negated phrase and unavailable measurement should not be converted into positive observations merely to complete the annotation column.
Store source text, field context, candidates and final decision in separate columns. This classroom exercise does not call ZOOMA or report its output. It demonstrates the structure of a review that could be applied to service suggestions. The aim is to make each decision inspectable, including cases where the most scientifically useful outcome is to preserve uncertainty.
CHAPTER 7 OF 20 · Review a fictional batch
7. Read the candidate definition before the confidence field
A candidate should fit the record's entity, property and qualifiers. Begin with its definition, then inspect the returned evidence and any confidence information. Reversing the order can make a persuasive number dominate the review before the learner understands what the candidate actually means. The highest-ranked suggestion is a candidate, not a substitute for the source definition.
Suppose a fictional candidate for “size” has a score of 0.95 but concerns length only. The source note does not specify length. The score cannot supply the missing qualifier. A reviewer should mark the record unresolved or request clarification, even if the candidate looks likely. The example illustrates a decision principle and is not a claim about ZOOMA's score scale or calibration.
Use a short candidate checklist: correct kind of entity, matching property, supported specificity and preserved qualifiers. Reject candidates that fail a necessary condition. Keep the reason concrete. “Too specific for the source” tells the next reviewer more than “low quality”. This makes review useful even when the team disagrees about how plausible a candidate appears.
CHAPTER 8 OF 20 · Review a fictional batch
8. A high-confidence policy belongs to a defined workflow
EMBL-EBI's BioSamples curation guidance states that ZOOMA is used for automatic ontology annotation and that only high-confidence mappings are accepted. Source: BioSamples curation guidance. This is a documented policy for that workflow. It should not be presented as proof that every high-confidence suggestion is correct in every dataset or as a universal threshold for a different project.
Our fictional class can adopt a local policy that requires a clear source definition and a matching candidate, regardless of a displayed score. Another teaching task might use scores only to prioritise review. State the policy and evaluate it on examples relevant to the task. Do not invent a numerical threshold and attribute it to the service when current documentation does not specify it.
Separate the service's returned category from the team's acceptance rule. Record both when they matter. This allows reviewers to see whether a decision followed the policy and whether the policy itself needs revision. A policy becomes scientifically useful when its meaning, scope and observed consequences are visible, not merely when it carries the reassuring word “high”.
CHAPTER 9 OF 20 · Review a fictional batch
9. Repeated wording should not erase different contexts
Repeated phrases can help organise a batch, but they do not always justify one decision for every record. A phrase may have different meanings in different fields or projects. Grouping by text alone can therefore spread an initial error across many rows. A recommended review includes the context needed to determine whether grouped records share meaning.
In a fictional combined table, Class A defines “size” as leaf length, while Class B defines it as mass. One shared text-based annotation would misrepresent at least one group. Keep the project and data dictionary attached, and review the groups separately. If the definitions genuinely match, a shared decision may be efficient; if not, preserve the distinction.
Track how decisions propagate. Record whether a review applies to one row, all rows with the same documented definition or a broader set. A future correction should identify which records need revisiting. This is an especially useful lesson for computing students: deduplication of text is a technical operation, while deduplication of meaning requires evidence about the records being grouped.
CHAPTER 10 OF 20 · Review a fictional batch
10. Protect negation and uncertainty
A phrase can mention a concept without asserting that the concept was observed. “No increase”, “possible increase” and “increase observed” should not become one unqualified positive annotation. A recommended workflow stores the concept mention and the assertion status separately where the task requires that distinction. Reviewers should explain what the source actually supports.
Return to our fictional batch's “no increase in length”. A length-related concept may describe the quantity under discussion, but an annotation indicating an observed increase would reverse the note's meaning. The reviewer must know what the target field is meant to represent. A quantity annotation and an observation-state annotation have different jobs and may require different treatment.
Use counterexamples during validation: negated findings, conditional statements, historical observations and uncertain notes. The workflow should retain the qualifiers rather than silently flatten them. This is not a claim that a named service necessarily makes those errors. It is an editorial recommendation for evaluating any annotation process whose output might later be interpreted as scientific evidence.
CHAPTER 11 OF 20 · Evaluate the decisions
11. Keep unavailable, unresolved and negative records distinct
An unavailable measurement means no usable value is present. An unresolved annotation means the available wording cannot yet be mapped confidently. A negative observation means a defined feature was assessed and not observed under the stated rule. These are different record states. A term suggestion should not collapse them into one blank, zero or reassuring “normal” category.
Our fictional batch includes “measurement unavailable”. It should retain that status rather than be assigned a positive quantity result. The ambiguous “size” phrase is different: some observation may exist, but its meaning needs clarification. The negated increase note is different again because it contains a stated observation claim. Review each state in the context of its source.
Define local status codes and explain their use in the report. Count unresolved annotations separately from missing measurements. This keeps evaluation honest and prevents a completeness metric from rewarding invented detail. Students can see the practical effect by comparing a table that preserves the three states with one that replaces all of them with zero; the latter changes both meaning and any subsequent calculation.
CHAPTER 12 OF 20 · Evaluate the decisions
12. Create reference decisions for evaluation
Before measuring a workflow's performance, establish what counts as a correct decision for the task. A recommended reference set uses source definitions, candidate definitions and documented reviewer judgement. Include straightforward and difficult cases. Keep disagreements visible rather than pretending every phrase has an obvious answer. The reference is a reasoned evaluation aid, not unquestionable ground truth.
For our fictional eight-record batch, two reviewers independently inspect the data dictionary and local term cards. They agree on the five explicit quantity records, retain “size” as unresolved, preserve the negated observation and keep unavailable status. If they disagree, record the reason and resolve it through the definitions or retain an unresolved case. This gives evaluation an inspectable foundation.
Avoid evaluating only easy examples that resemble earlier accepted mappings. A realistic teaching set should include ambiguity, abbreviations, negation and context differences. Document which kinds of records were tested. A high success rate on one narrow set does not establish universal accuracy. The useful question is whether the evidence supports the workflow's intended scope and reveals where human review remains necessary.
CHAPTER 13 OF 20 · Evaluate the decisions
13. Work through fictional precision and recall
Suppose an invented annotation process proposes six positive quantity matches for the eight-record exercise. Five are correct under the class's reference decisions, while one assigns length to the ambiguous “size” record. Precision for those proposed matches is five divided by six, about 83.3%. These are fictional counts used to teach arithmetic, not measured ZOOMA performance.
If the reference set contains five supported positive quantity matches and the process finds all five, recall for that defined category is five divided by five, or 100%. The extra incorrect proposal lowers precision even while recall remains high. Both values depend on the task definition and reference set. They do not evaluate whether the underlying measurements are accurate.
Report the denominators and review policy alongside the percentages. Unresolved, negative and unavailable records may need separate evaluation categories rather than being forced into a binary metric. A model can achieve an attractive number while handling an important boundary poorly. The lesson is to read metrics as answers to explicitly defined counting questions, with the mistakes visible enough for someone to inspect.
CHAPTER 14 OF 20 · Evaluate the decisions
14. Review error types before adjusting a policy
A single overall metric can hide different problems. Recommended error review separates incorrect entity type, unsupported specificity, missed qualifier, wrong field context and identifier mismatch. These categories are editorial suggestions for the learning exercise. They help the team choose a useful repair instead of simply demanding a higher score or replacing the whole workflow.
In the fictional batch, the incorrect “size” match is a specificity error caused by missing context. Raising a score threshold might remove it, but it could also remove correct proposals. A better repair may be a rule that ambiguous source fields require clarification. The decision should be justified by the source meaning and tested on relevant examples.
Keep the original error and the revised outcome in the evaluation record. If a correction is applied to similar rows, inspect whether their contexts actually match. This prevents one repair from creating another mistake. Students learn an optimistic approach to failure: an error is useful evidence when it identifies a specific weakness and leads to a change whose consequences can be checked.
CHAPTER 15 OF 20 · Evaluate the decisions
15. Keep human review accountable and revisable
Human review is not automatically perfect. Reviewers can misunderstand a definition, overlook a qualifier or copy the wrong identifier. A recommended record names the decision, evidence and review date so another person can challenge it. The purpose is shared reasoning, not treating a human approval as a final stamp that ends all scientific questions.
For a fictional disputed phrase, one reviewer selects a narrow term while another retains a broad category. Compare what each believes the source supports. If a missing qualifier caused the disagreement, seek the original documentation. If the candidate definition was read differently, inspect its boundaries together. Keep unresolved uncertainty when the available evidence cannot settle the issue.
Record revisions without erasing the earlier decision. A clear history helps explain why an older report used a different annotation and which records need updating. This also strengthens collaboration: reviewers can disagree about a concrete claim rather than about each other's competence. The outcome is a decision process that can improve through evidence, with both machine suggestions and human judgements remaining inspectable.
CHAPTER 16 OF 20 · Connect learning and reuse
16. Version the input, suggestion and accepted annotation
An annotation workflow has several histories: source records, vocabulary releases, service or tool versions and local review decisions. They can change independently. Recommended records preserve the versions that materially affect the result, along with dates and configuration where available. A current label should not overwrite the meaning used in an earlier analysis without a documented review.
Imagine our fictional source dictionary changes “size” to “leaf length”. A new annotation may now be justified. That improvement comes from clarified source evidence, not necessarily a change in the annotation software. Keep the old and new records separate so a reader can understand why the decision changed. The same principle applies when a term is revised or a local acceptance policy changes.
For small projects, use dated files and a short change note. For larger work, follow the appropriate versioned data process. Do not claim a live deployment's exact release merely from the current development README. The important learning habit is to state what was actually used and to identify whether a changed result comes from data, vocabulary, software or judgement.
CHAPTER 17 OF 20 · Connect learning and reuse
17. A Primary Science activity on clearer observation notes
Start with a safe observation task using paper shapes. Ask learners to write a note that another person can classify without guessing. “Big” is a useful first attempt, but it invites the next question: big in which way and compared with what? Help the learner replace vague wording with a defined property, such as longer than a provided reference strip.
Offer fictional candidate cards and ask the learner which fits the note. Include one tempting but unsupported card. Then improve the source note rather than simply adding more candidates. This shows how clear observation can make later classification easier. The exercise is an editorial learning activity, not an official ontology requirement or a substitute for the current school syllabus.
Families looking for Primary Science tuition or PSLE Science practice can focus on explanation and evidence. Ask the child to name the words that support the choice and the detail needed for an unresolved note. The encouraging outcome is a more precise question or clearer sentence. Specialist service names are optional at this stage; the scientific habit is already present in the careful description.
CHAPTER 18 OF 20 · Connect learning and reuse
18. A Secondary Science project on evaluating suggestions
Secondary Science learners can extend the eight-record batch into a small project. Prepare a local vocabulary, preserve raw notes, generate fictional candidates and review them independently. Define the acceptance policy before counting success. Computing students can write a simple lookup simulation; Science students can inspect meanings and qualifiers. Both contributions are needed for an understandable evaluation.
Create a report with the source definitions, reference decisions, confusion cases and calculated metrics. Explain at least one accepted annotation, one rejected suggestion and one unresolved record. Use the precision and recall example only after defining what counts as a positive match. A report should show enough detail for a partner to reproduce the arithmetic and challenge the interpretation.
Advanced learners may then inspect a documented live annotation service using appropriate non-sensitive examples and its current instructions. Keep actual service outputs separate from the invented exercise. Do not publish private records or claim that a classroom evaluation establishes professional clinical suitability. The achievable goal is strong data literacy: a clear distinction between a proposed term, a reviewed decision and the evidence used to evaluate the workflow.
CHAPTER 19 OF 20 · Connect learning and reuse
19. Frequently asked questions about annotation suggestions
Does a suggested term prove the observation? No. It proposes a vocabulary connection, while the observation still needs its own evidence. Should original text be replaced? Preserve it and record any cleaned form separately. Is high confidence enough? Review the field's meaning and the workflow's documented policy; confidence cannot supply missing source information.
What if a phrase has several meanings? Keep the relevant context, compare candidate definitions and mark unresolved cases. Can repeated phrases share one decision? Only when their documented meanings and review scope match. Does a perfect score on a small test settle reliability? No. The metric applies to the defined reference set and categories, and difficult cases still deserve inspection.
Where should readers continue? The EFO guide explains experimental variables; CMO explains measurement types; MMO explains measuring processes. The Science Learning Hub connects these ideas to broader study, while the Education Hub and career capability page support learning and pathway exploration. Formal qualifications, school requirements and professional eligibility need their own current official checks. This article makes no admission or career-outcome promise from completing an annotation exercise.
CHAPTER 20 OF 20 · Connect learning and reuse
20. Finish with one accepted, one rejected and one unresolved record
The final challenge is deliberately small. Select three fictional source phrases and show the full review trail for each. One should support a candidate clearly, one should contradict an attractive suggestion and one should lack a necessary qualifier. Preserve original wording, context, candidate meaning and decision rationale. This demonstrates understanding more effectively than filling every annotation cell.
Ask another learner to review the trail. Can they see why the decisions differ and what information would resolve the uncertain case? Check the arithmetic if you report performance, and state that the examples are invented. If a reader cannot reconstruct the decision, improve the evidence record before adding more technical features or a larger dataset.
Why Science? Because it helps us use useful suggestions with curiosity and judgement. ZOOMA provides an opportunity to explore annotation, while the learner keeps meaning attached to the source and uncertainty attached to the decision. Start with a clear observation note and a review another person can inspect. That is a practical foundation for better learning, more responsible data reuse and thoughtful work with computational tools.
Back to contents · Previous chapter · Continue to the Science Learning Hub
Sources and scope
Official and primary sources checked on 15 October 2026: ZOOMA2: official development README; EMBL-EBI BioSamples: curation guidance; EMBL-EBI: ontology data-management training; EMBL-EBI: OLS training for inspecting candidates. Project descriptions above are attributed to their named sources. Worked datasets are fictional; record designs, review checklists and teaching activities are editorial recommendations, not official ontology requirements. No search-volume, clinical, admission or career-outcome claim is made.