A semantic regression test, as used in this guide, is a repeatable check that a change to words, labels, definitions, mappings or navigation has not unexpectedly changed the meaning or decisions that a knowledge system should preserve. Imagine a vocabulary editor renames a subject from ‘Fraction Equivalence’ to ‘Equivalent Fractions’. The new title may look clearer, but can readers still find the same lesson, do historic links point to the right concept, and does the search avoid incorrectly merging it with every type of fraction calculation? A semantic regression check asks these questions before treating the edit as finished.
Vocabulary is a technology that can fail quietly. One short synonym added to search can pull in an unrelated meaning. One renamed status can make a draft appear approved. One updated definition can invalidate older examples. A regression check tests meaningful behaviour, not just whether the page loads or the markup is well formed. It takes a small set of known information needs, correct matches, wrong matches and important boundaries, then compares what happens before and after an edit. It does not assume software can determine every subtle question of meaning without human judgement.
This article explains why regression tests matter in vocabulary publishing, how to define baseline expectations, positive and negative test cases, scope and identity invariants, structural validation and human review. It draws on W3C SKOS and the W3C SHACL Recommendation, alongside practical information-retrieval evaluation concepts. All examples are original, and the term semantic regression test is used here for an editorial testing approach rather than presented as the name of a single formally standardised W3C procedure.
Editorial note: All searches, scores, concepts and site behaviours in the examples are hypothetical teaching illustrations. This article does not claim an audit of the real eduKateSG website or that SHACL validation establishes educational truth.
Contents: tests that protect meaning after changes
Open 69 chapters, tests and worked cases
- The first example: one synonym breaks a school search
- What the word regression means here
- Why call the check semantic?
- This is a practical editorial term, not a W3C-defined product
- The W3C SKOS foundation
- The W3C SHACL foundation
- Structural validation is necessary but not sufficient
- Write the intended invariant
- Not every property must remain fixed
- Define the before state
- Define the after state
- One positive test
- One negative test
- One boundary test
- Identity preservation after a rename
- Scope preservation after a rename
- A test for an accidental synonym merge
- A test for a false split
- A test for a broken parent relationship
- A test for cycles in hierarchy
- A test for a contradictory mapping
- A test for transitive errors
- A test for a deprecated term
- A test for the concept split
- A test for a concept merge
- One canonical page does not mean one article
- Test an exact query and a natural query
- Test an ambiguous term
- Test the user journey, not just metadata
- Test source claims separately from taxonomy
- Test current official terminology where needed
- Test time-sensitive records
- A reader’s old bookmark matters
- Test multilingual labels with the right scope
- A useful baseline includes negative cases
- Relevance judgements can be part of the baseline
- A relevance score is not a universal truth score
- Human judgement remains necessary
- An automated validator has a defined scope
- The difference between syntactic and semantic checks
- A test ID and expected outcome
- An expected result should be evidence-based
- Positive, negative and boundary tests as a set
- Tests can be too closely tailored to one article
- The changed thing may be a status word
- The changed thing may be a redirect
- The changed thing may be a translation
- The changed thing may be a crosswalk
- The changed thing may be the navigation menu
- The changed thing may be a source reference
- The changed thing may be a teaching example
- A complete miniature test plan
- Interpreting a failed test
- Interpreting a passed test
- When to stop testing
- A simple regression report
- A no-change baseline helps detect false alarms
- A source change can invalidate the baseline
- A second editor can catch a hidden assumption
- A reader test measures actual comprehension
- Testing multiple languages is a separate obligation
- Regression tests and change impact analysis
- Regression tests and provenance
- Regression tests and a controlled vocabulary
- A small class workshop
- Six mistakes to diagnose
- Twelve quick questions
- Frequently asked questions
- References and the next action
1. The first example: one synonym breaks a school search
A fictional library already finds Equivalent Fractions when a pupil searches ‘fractions with the same value’. An editor adds ‘same-sized pieces’ as a broad new alias.
After the change, queries about dividing a cake equally may begin appearing beside fraction-equivalence lessons even when the reader’s question concerns physical portions rather than numerical representations.
A semantic regression test compares the expected result before and after the alias update. The change is not successful merely because the original intended page still appears somewhere in a larger list.
2. What the word regression means here
In testing, a regression is a previously satisfactory behaviour that fails after a change. The failure can be obvious, such as a broken link, or subtler, such as a correct URL now representing the wrong concept.
The test asks whether important properties of the system remain valid after the edit. It should be repeatable across successive revisions.
Do not confuse regression testing with a learner’s temporary decline in exam performance. This article concerns the behaviour of an information system’s meanings and navigation.
3. Why call the check semantic?
A structural test may show that a page has a title, valid HTML and working links. A semantic test asks whether the page still means and does what the reader needs.
For example, a link to Comparing Fractions can be live while wrongly labelled Equivalent Fractions. A technical status check would pass; the meaning is wrong.
The adjective semantic points to interpretation, concept identity, scope and intended decision, rather than surface syntax alone.
4. This is a practical editorial term, not a W3C-defined product
W3C maintains formal specifications such as SKOS and SHACL. Neither defines one universal feature called ‘semantic regression test’ that automatically verifies every educational article.
This guide combines ordinary before-and-after testing with vocabulary governance, retrieval judgements and data-shape validation. The method is a suggested workflow, not a claim about a specific certification standard.
Naming the limits matters: the word semantic cannot make an automated checker understand every source, curriculum boundary or learner intention.
5. The W3C SKOS foundation
The W3C SKOS Reference defines preferred and alternative labels, concept identities, broader and narrower relationships, mappings and documentary notes.
These properties provide concrete things to test when a vocabulary changes. A preferred label should remain appropriately linked to its concept; a mapping should not become contradictory; an alias should not be confused with a different concept.
The standard supplies a semantic model. Editors still need to write the specific reader and data tests relevant to their scheme.
6. The W3C SHACL foundation
The W3C SHACL Recommendation defines a language for validating RDF data graphs against shapes expressing constraints.
A SHACL check can inspect properties such as allowed values, cardinalities or required relationships when an appropriate shapes graph has been written. That can expose some structural and data-model problems after changes.
SHACL conformance does not automatically prove that an article teaches correct Mathematics or that an exact-match mapping is pedagogically justified. The constraints must be specified and relevant.
7. Structural validation is necessary but not sufficient
A concept record might satisfy a rule requiring one preferred English label. The chosen label can still be misleading or too broad.
Similarly, a graph can pass datatype checks while connecting Evaporation and Boiling as exact synonyms under an incorrect editorial decision.
Use automated constraint checks to find model violations, then apply meaning-aware review and reader tests to properties the constraints cannot establish.
8. Write the intended invariant
An invariant is a property that should remain unchanged under a specified transformation. In a label-only rename, the concept’s identity and scope may be intended invariants.
The editor can write, ‘After renaming the preferred label, every resource previously classified under this concept should still refer to the same scoped idea unless a separate approved classification change occurs.’
That sentence makes the test meaningful. Without naming what should stay the same, a change can look successful simply because something changed.
9. Not every property must remain fixed
A genuine concept split intentionally changes the number of active subject identities. A test requiring exactly one concept forever would fail for the intended good change.
The right baseline distinguishes expected differences from unwanted regressions. For a split, new IDs and narrower scopes may be correct while historic references should retain a truthful route.
Test what the approved change was supposed to alter and what it was supposed to preserve.
10. Define the before state
Record the concept ID, label, scope note, mappings and representative search results before an important edit. Where meaningful, retain a version or snapshot.
If the starting state is unknown, reviewers cannot reliably identify whether an unexpected result came from the new edit or an earlier problem.
A baseline may be incomplete, but the limitation should be visible instead of being hidden by an invented past result.
11. Define the after state
Record what was actually saved and published after the update. An editor’s intended new label is not proof that the site accepted the change.
Some publishing systems can strip unsupported markup or save only part of a request. Reading back the saved record is part of verification.
Compare the live or persisted output against the approved change. A plan and an implemented result are different things.
12. One positive test
A learner searches the new preferred label and retrieves the intended concept page. That establishes one observed successful route under the test conditions.
It does not show that the old label still works, the scope is unchanged or the neighbouring concept remains separate.
Positive tests are valuable but narrow. Use enough of them to cover the important ways readers enter the system.
13. One negative test
A learner searches for a related but distinct subject that should not map to the changed concept. The test passes if the system preserves that distinction under the stated retrieval rule.
For example, the new Equivalent Fractions aliases should not make every Percentage Conversion page an exact synonym.
A negative case catches false equivalence that a positive query may miss. It is often the first test to add when a change broadens the allowed words.
14. One boundary test
A boundary case lies near the line between included and excluded concepts. A lesson comparing two fractions by converting them to a common denominator could involve both equivalence and comparison.
The test should specify the local classification rule, possibly allowing a primary concept with a secondary tag rather than forcing one universal answer.
A boundary test is useful when its expected outcome has been reviewed, not when the editor simply invents the desired answer after the system produces it.
15. Identity preservation after a rename
Suppose a topic changes its public title but retains exactly the same subject definition and examples. Its stable concept ID should normally continue to identify that same idea under the scheme’s chosen policy.
A test can inspect the ID, alias and article-to-concept links before and after the rename.
The Concept Identifier guide explains why identity and display wording require separate checks.
16. Scope preservation after a rename
A title update might accidentally imply a broader learning outcome. An article originally limited to recognising equivalent fractions becomes titled ‘Everything About Fractions’.
Even if its ID is unchanged, the reader-facing promise no longer matches the existing scope. A semantic regression review should flag the mismatch.
Check the title, first explanation, scope note and principal examples together. Words in several places may carry the intended boundary.
17. A test for an accidental synonym merge
A search editor adds ‘boiling’ as a synonym for ‘evaporation’ because the topics often appear together. The vocabulary now sends a pupil searching one process to the other.
The test needs a known case in which the distinction matters, such as evaporation at temperatures below the boiling point under appropriate conditions.
A correct result should preserve distinct concepts and perhaps show them as related topics, not declare them identical.
18. A test for a false split
Two concept records are created for identical topics solely because one title says Mathematics and the other Maths. A search may return near-duplicate subject entries.
The regression test can check whether the same learner need now generates an unnecessary choice or scattered resource lists.
Use a reviewed alias or single concept identity when the intended scope really is the same. Separate subject articles can still remain distinct for their own content purposes.
19. A test for a broken parent relationship
An editor removes one broader link from a polyhierarchical concept. The subject remains available through another route, but readers entering from the removed branch can no longer find it.
The test should include a browsing journey starting at each legitimate parent. A simple concept-record count would not detect this navigation regression.
The Polyhierarchy guide explains why one concept can have several valid broader paths.
20. A test for cycles in hierarchy
An accidental update adds an ancestor as the narrower child of its own descendant. Depending on the scheme and browsing implementation, navigation can become circular.
A graph validation or explicit cycle-detection routine can flag such unintended paths. The editorial policy must state whether cycles are forbidden under the hierarchy’s meaning.
Do not claim every RDF graph is required to be acyclic. The test is specific to the intended hierarchical relation.
21. A test for a contradictory mapping
An external scheme is linked by a reviewed exact mapping, but a later change gives the local concept a narrower scope. The mapping may no longer be justified.
Test representative examples on both sides and inspect whether inherited exactness still holds. If not, downgrade or revise the mapping through the authorised process.
The Semantic Crosswalk guide explains the strength of SKOS mapping relations.
22. A test for transitive errors
SKOS exactMatch is transitive. If one exact link is wrong, an inferred chain can produce additional incorrect correspondences.
Include one end-to-end mapping test, not only individual direct link checks, when the system actually performs such inference.
Do not assume all crosswalk implementations reason transitively. First determine what the software does, then test the effects it really produces.
23. A test for a deprecated term
An old label is retired. Historic articles should still be interpretable while new resources should use the current concept where applicable.
Test the old URL, an old search term and the new preferred term. Verify that the notice does not falsely claim a one-to-one replacement after a split.
The Deprecation Notice guide explains why retirement and deletion are different.
24. A test for the concept split
One old category becomes two narrow concepts. The positive tests should find the appropriate new resource for both learning needs.
The negative tests should ensure recall exercises are not systematically presented as paragraph-writing applications and vice versa. Historic links need an honest broader or choice route.
The Concept Split guide details the different identity and migration decisions.
25. A test for a concept merge
Two truly duplicated concept entries are consolidated. The old names should continue to locate the surviving scoped idea where appropriate.
Test one intentionally different near-neighbour to ensure the merge did not erase a useful distinction or inflate a subject category.
The Concept Merge guide shows why fewer records is not always the right outcome.
26. One canonical page does not mean one article
A subject concept can be represented by a stable canonical record while multiple distinct resources teach it through different explanations, levels and exercises.
A regression test should not delete useful lessons simply because they share the same subject concept.
Check the intended document identity separately from the topic’s identity. The test concerns meaningful retrieval and classification, not mechanically reducing post counts.
27. Test an exact query and a natural query
A controlled vocabulary may use ‘Equivalent Fractions’ as the preferred label. A parent may type ‘fractions that have the same value’.
After an edit, test both expressions and inspect whether the intended page is returned. The second route matters because readers do not always know the canonical term.
Query expansion and synonym rings may supply the connection only when the implementation uses them. A successful metadata edit does not guarantee real search behaviour.
28. Test an ambiguous term
The bare query ‘scale’ has several possible meanings in a mixed educational collection. A change to one concept should not make the system force every such query toward that sense.
A disambiguation route or subject-sensitive results may be more honest than a hidden default that implies one meaning is universal.
Use the Ambiguous Label guide for a sense-selection test.
29. Test the user journey, not just metadata
A concept entry may be correctly labelled in a database but linked from the wrong hub card. A learner can still be sent to an irrelevant article.
Follow the route from a realistic query or navigation entry to the final explanatory resource. Inspect whether the destination actually answers the question.
An end-to-end test reveals semantic errors that are invisible in a single field validation.
30. Test source claims separately from taxonomy
A Science article may remain correctly classified under Evaporation while containing an inaccurate explanation of the process.
A taxonomy regression test can pass without proving the factual content. A content-review workflow should still verify meaningful claims against appropriate sources.
Keep classification consistency, factual truth, link integrity and accessibility as distinct evaluation dimensions.
31. Test current official terminology where needed
An educational article may cite a current assessment term. Renaming a local index should not change that official term or imply a new examination requirement.
Use the applicable current primary authority when the claim affects real pupils and parents. A local regression test checks whether the meaning was preserved, not whether a policy was created.
Do not infer real curriculum changes from a renamed site category.
32. Test time-sensitive records
A historic worksheet may use a title that was correct under the earlier scheme. A rewrite can make that title look current without explaining the date or version.
Include at least one historic reference in the test set when the change affects old names or status definitions.
An accurate historical record need not use today’s preferred terminology to remain valid.
33. A reader’s old bookmark matters
A renamed or split concept can leave an old URL pointing to a page that no longer answers the original question.
Test the saved path and any redirect. The destination should preserve a truthful explanation or route to the intended current topic.
A working link to a semantically different page can be more misleading than an explicit explanation that the subject has changed.
34. Test multilingual labels with the right scope
An editor updates the English preferred label but leaves a translated label whose meaning is now too broad.
A test should compare the current scope with the language-specific label and one positive and negative example where suitable review resources exist.
Do not infer exact semantic equivalence from a machine translation or a matching string length.
35. A useful baseline includes negative cases
If all stored tests are positive, a change can pass by making search more permissive until almost every document is returned.
Include examples that must not map, must not be classified as the topic and must not inherit an obsolete approval status.
Negative cases protect precision and semantic boundaries. They often reveal problems that broad success counts conceal.
36. Relevance judgements can be part of the baseline
A test collection can identify which resources serve a given information need, perhaps with binary or graded relevance labels.
After an indexing change, compare how the system retrieves those documents. New results should be assessed against the same question and criteria.
The Relevance Judgement guide explains why keyword overlap and factual correctness are different matters.
37. A relevance score is not a universal truth score
A page can be highly relevant to a question but wrong on one important fact. Another page can be accurate but too advanced for the intended reader.
An evaluation dataset needs a clear relevance task and ideally separate quality checks when reliability affects the user’s decision.
Do not report that a site is ‘100 percent accurate’ simply because all tested queries found an article with the right title.
38. Human judgement remains necessary
Some differences involve classroom meaning, nuanced translation or legitimate variations in how writers explain an idea. A program may find matching words without judging whether a sentence communicates the correct pedagogical relation.
Use human review for disputed boundaries or potentially consequential edits. Record the rationale and source evidence so the result can be challenged or improved.
Automation can reduce repetitive checking, but it cannot confer authority or replace subject expertise simply by generating a confident score.
39. An automated validator has a defined scope
A SHACL data graph may conform to a shapes graph because required labels and allowed relation types are present.
That result means the data satisfied those declared constraints under the processor’s relevant semantics. It does not prove a broader claim about its learning quality or its external source accuracy.
State which constraints were tested. ‘Passed SHACL’ is useful information when accompanied by the actual shapes and validation context.
40. The difference between syntactic and semantic checks
A syntactic check can ask whether a title field is present or a URL is well formed. A semantic check might ask whether an alternative label accidentally collapses two distinct mathematical concepts.
Some semantic constraints can be formally encoded, such as preventing certain incompatible relation combinations. Others require a reader to inspect definitions, examples and task outcomes.
A robust pipeline uses both rather than assuming one type of test covers all failures.
41. A test ID and expected outcome
Give each test a stable label such as TEST-Q01 and record its input query, applicable concept version, expected result and rationale. These are fictional IDs used for the classroom exercise.
After the change, run the same test and record Pass, Fail or Needs Review. If the intended scope has deliberately changed, update the expected outcome with a documented decision.
Stable test records allow later editors to understand why a revision was accepted or rejected instead of reconstructing the history from memory.
42. An expected result should be evidence-based
A test that merely expects the editor’s favourite article to rank first is not necessarily a valid test of the learner’s need.
Define which feature makes a result appropriate: a beginner-level explanation, a valid method, a correct stage or an accurate conceptual boundary.
Have a second reader examine a borderline test. A meaningful expected outcome needs reasons, not simply a green check mark.
43. Positive, negative and boundary tests as a set
Select one case that must fit the concept, one that must remain separate and one near the boundary whose outcome has been decided under the local policy.
For Equivalent Fractions, the positive case can compare 1/2 and 2/4, while a negative case concerns an unrelated addition lesson. A borderline case may combine equivalence with a comparison strategy.
This set exposes different failure modes without requiring the editor to test every possible resource manually.
44. Tests can be too closely tailored to one article
If the only baseline consists of exact excerpts from an article written by the same editor, the tests may reward the existing wording rather than the intended reader task.
Include natural questions, legitimate synonyms and new examples that use the same concept differently. Otherwise, an automated test may pass while real readers remain confused.
The purpose is transfer to new cases, not memorising the previous page’s phraseology.
45. The changed thing may be a status word
A project replaces Done with Draft Complete and Approved for Release. The new labels are intended to prevent an unreviewed file from appearing publishable.
Test whether an old Done record is now interpreted only according to its known events. It must not automatically become Approved without the required review evidence.
The regression check protects an action boundary, not just the spelling of a status badge.
46. The changed thing may be a redirect
An old concept URL is pointed to a successor. The HTTP request succeeds, but the successor covers only half the former subject.
A link checker will see no technical error, while the semantic route has broken for historic readers who sought the other half.
Use a test grounded in each former information need. A choice or archive page can be the correct destination when no single replacement preserves the old scope.
47. The changed thing may be a translation
An English learning article is translated into another language. The target phrase for ‘required’ is mistakenly written as ‘recommended’.
The page can be well formatted and grammatically fluent while conveying an incorrect obligation. A semantic check compares the practical consequence of both versions.
Use qualified language and subject reviewers where necessary. Literal word count cannot establish semantic preservation.
48. The changed thing may be a crosswalk
Two concepts are newly mapped as exact equivalents. A test should ask whether both definitions and example sets support that strong relation.
An approximate overlap may warrant close or related mapping rather than exact. A negative case can identify a point where substitution would fail.
The test should also examine derived matches if the actual graph system performs transitive inference.
49. The changed thing may be the navigation menu
A vocabulary topic moves from English Writing to a different hub. The article remains live, but pupils searching through the original route may lose it.
A semantic navigation test starts from the user’s likely entry point, not just the final article URL.
An editor can retain a legitimate cross-link or adjust the hierarchy while preserving the concept’s actual definition.
50. The changed thing may be a source reference
A linked external authority changes its definition or retires an identifier. A local page may continue displaying the old source as if it were current.
The regression test can check whether the current source still supports the article’s claim and whether historic claims remain correctly dated.
An external link that technically loads does not establish that its content is unchanged or still relevant.
51. The changed thing may be a teaching example
A writer swaps a Mathematics example in a vocabulary article without changing the surrounding explanation. The new numbers may violate the rule the text is meant to illustrate.
Check the example’s actual calculation and its relationship to the target concept. A valid old explanation does not guarantee a new example is correct.
Example regression tests belong alongside label and navigation checks when the educational meaning depends on worked cases.
52. A complete miniature test plan
Create a fictional change: rename ‘Fraction Equivalence’ to ‘Equivalent Fractions’ while preserving the concept’s scope. Test 1 confirms the new label points to the existing concept ID.
Test 2 searches the old label and checks the preserved route. Test 3 verifies a natural phrase ‘fractions with the same value’. Test 4 confirms that an unrelated fraction-addition query is not treated as an exact synonym.
Test 5 follows the hub card to the right worked explanation. Test 6 checks a historic bookmark and Test 7 inspects a translated label if one exists. Record actual results and uncertainties before concluding the change succeeded.
53. Interpreting a failed test
A failed test does not necessarily mean the whole concept scheme is broken. It identifies a mismatch between a stated expectation and observed behaviour.
Determine whether the new edit caused the mismatch, the expectation was wrong or the baseline contained an older error. Evidence from versions and change logs can help.
Fix the specific problem and rerun the relevant tests. Avoid mass deletion or uncontrolled rewrites based on one unexplained failure.
54. Interpreting a passed test
A passed test shows one expected outcome occurred under the tested conditions. It does not certify all readers, queries or languages.
State the coverage honestly: ‘Seven named navigation and concept tests passed for this version’ is more useful than ‘The entire knowledge base is proven correct’.
A test report should be specific enough that another editor can repeat it or investigate later.
55. When to stop testing
Testing cannot exhaust every possible sentence or user interpretation. The team needs a stopping rule appropriate to the scope, risk and approved change.
Complete the required high-impact tests, record unresolved issues and decide whether those issues block publication. A risky policy implication deserves more scrutiny than a cosmetic heading update.
The Stopping Rule guide explores how to end a review without claiming perfect certainty.
56. A simple regression report
Record Change ID, Before Version, After Version, Affected Concepts, Test ID, Expected Result, Observed Result, Status and Reviewer.
Include a short note when the expected behaviour deliberately changed. A documented exception is different from a silent failure that nobody noticed.
Keep the report proportionate to the work. A classroom exercise can use a small table; a multi-site publishing workflow may require more detailed provenance.
57. A no-change baseline helps detect false alarms
Before modifying anything, run the tests against the current system. If one already fails, record that fact rather than later blaming the new edit.
This avoids confusing an existing problem with a new regression. The edit might still be worth publishing if it fixes some issues and does not worsen critical behaviour.
Compare observed states accurately, not remembered impressions of what the earlier site supposedly did.
58. A source change can invalidate the baseline
If a curriculum authority legitimately changes a published requirement, an older expected result may no longer be current.
The test should be updated only after verification of the new authoritative source, with a clear note about which version applies.
Do not treat all test changes as suspicious. The relevant question is whether the revised expectation is justified and recorded.
59. A second editor can catch a hidden assumption
The writer of the new label may understand exactly why it means the same thing as the old label. Another editor might reasonably interpret it as broader.
Give that editor a positive, negative and boundary case without coaching them toward the expected answer. Compare their interpretation with the intended scope.
A disagreement may reveal ambiguous wording or a flawed baseline. The result can improve the test rather than be dismissed as a nuisance.
60. A reader test measures actual comprehension
A learner searching for a particular skill reaches the newly labelled page. Ask whether they can identify the relevant lesson and distinguish it from a close neighbour.
Successful navigation is evidence about that interaction, not proof that the student mastered the subject. A separate practice task would be needed for learning outcomes.
The distinction keeps retrieval evaluation and educational performance assessment honest.
61. Testing multiple languages is a separate obligation
A vocabulary scheme can have labels in several languages. Passing English search tests does not establish that the same concept’s translated labels are accurate or findable.
Use suitable native-language or specialist review for high-impact mappings and run the relevant language-specific queries.
Keep unreviewed versions explicitly pending rather than silently report full multilingual completion.
62. Regression tests and change impact analysis
Change impact analysis asks which dependent resources might be affected. Semantic regression tests check whether specified behaviours and meanings remain correct after the change.
The Change Impact Analysis guide provides the upstream and downstream dependency questions.
Used together, impact analysis selects the relevant test targets, and regression checks provide evidence about the saved or live outcome.
63. Regression tests and provenance
A provenance record can explain who changed a concept, which sources supported the decision and which version was tested.
Without that history, it can be difficult to determine whether a failure came from the latest edit, a historic alias or a revised external definition.
The Provenance Trail guide shows how to preserve the change’s origin and evidence.
64. Regression tests and a controlled vocabulary
A controlled vocabulary provides concepts, labels and relations that can be validated or reviewed. A regression suite helps protect those distinctions across maintenance edits.
Together they reduce the chance that new synonyms, migrations or navigation changes introduce contradictions. Neither solves every factual or teaching error automatically.
Read the Controlled Vocabulary guide for the governed model being tested.
65. A small class workshop
Give pupils a fictional index with five concepts and one proposed label update. Write six short queries, including a positive example, a related but non-equivalent topic and an ambiguous term.
Ask learners to predict the expected results before making the change. Then simulate the revised index and compare each route.
Require explanations for failures: wrong synonym, missing alias, broken identity, confusing navigation or unchanged content error. This makes test vocabulary useful outside programming.
66. Six mistakes to diagnose
One: only testing that pages load. Two: checking the new name but not the old one. Three: omitting a near-neighbour that must remain separate.
Four: treating a passed data-shape validation as proof of factual truth. Five: changing expected results after seeing outputs without an approved reason. Six: reporting complete success without identifying which queries and versions were checked.
Each mistake can be corrected by making the intended meaning, test scope and evidence more explicit.
67. Twelve quick questions
1. Is a semantic regression test about meaning preservation? Yes, under this editorial usage. 2. Does valid HTML prove the right concept was returned? No. 3. Should a baseline be recorded? Yes.
4. Are positive tests enough? No. 5. Are boundary cases useful? Yes. 6. Is a concept rename the same as a concept split? No. 7. Can a change intentionally alter expected results? Yes.
8. Does SHACL prove every educational claim correct? No. 9. Can an old bookmark need checking? Yes. 10. Does a test pass guarantee universal correctness? No. 11. Is human review sometimes necessary? Yes. 12. What is the goal? Detect unintended changes to meaning and reader action.
68. Frequently asked questions
Is semantic regression testing an official W3C method? Not under that single name. This guide combines before-and-after editorial tests with standards that model and validate certain data constraints. Can a school do it without code? Yes, using a small test table and repeatable reader tasks.
Do all meaning changes need to be rejected? No. Approved changes should produce intended new results while preserving agreed invariants. Can automated validation replace teachers? No; claims about subject correctness and learning outcomes need appropriate evidence.
Why is this vocabulary technology? It makes the meanings attached to shared terms testable across revisions instead of hoping a cleaner label preserved everything important.
69. References and the next action
The W3C SKOS Reference defines concept labels, mappings, notes and their relationships. The W3C SHACL Recommendation specifies RDF graph constraint validation. The Stanford Introduction to Information Retrieval explains query evaluation and relevance judgements.
The test suites and school outcomes here are invented educational examples. Neither a conforming RDF graph nor a passing local regression checklist should be described as proof that all content or external policies are correct.
Before your next vocabulary edit, write down what should change and what must remain true. Test the new preferred expression, an old alias, a relevant near-neighbour and a saved reader path. Inspect the actual published result, record failures and only then call the migration verified. That makes vocabulary a maintainable information system, not just a collection of new words.