Test an ontology in Workbench

Attach or import the project ontology, make the intended copy Live, and exercise it in native annotation editors.

A schema can be structurally valid and still fail the operator. Workbench testing proves that the intended project ontology is actually available, Live, understandable, editable by the correct roles, and compatible with every source modality and release consumer.

Add the ontology to the project

Create or switch a Project Ontology

Project Ontologies list with a Live ontology

Project Ontologies owns the independent ontology copies used by this project and identifies the single Live selection.

Open the project and choose Ontologies. Use New Ontology to create a project-owned schema, or open the row action on an existing copy to make the tested ontology Live. A project can retain several copies for controlled evolution, but annotation uses the Live selection.

Import from Global Ontologies

Global Ontologies catalog inside a project

Importing a Global Ontology creates an independent project copy that can be tested and governed without silently following later catalog changes.

Choose Global Ontologies, find the approved workspace schema, import it, return to Project Ontologies, inspect the copy, and make it Live only after the acceptance test.

Confirm the ontology in Workbench

Annotation Workbench Classes panel

The Classes panel is the operator-facing proof that the project's Live ontology loaded into the native editor. The source canvas, class list, item controls, and workflow action must agree.

1. Attach a representative dataset version to the project and wait for Project Data to be ready.

2. Open Project › Data and enter a representative item in Workbench.

3. Confirm the Classes panel contains the expected names, order, colors, geometry icons, required classes, and hotkeys.

4. Create one annotation for every class and supported annotation type.

5. Select an object and set every property; use Add property only when the test includes Workbench-side schema authoring.

6. Open Item properties, set each static and Dynamic Item Property, and verify the correct item or timeline scope.

7. Create each relation and confirm source, target, direction, and target restrictions.

8. Traverse every conditional branch and trigger every validation error intentionally.

9. Save, route to review, reject or return representative errors, and confirm role-specific visibility and editability.

Test temporal properties

For video or medical work, use a sequence containing a real state change:

• create a track and set a Dynamic class property at its first authoritative frame;

• move later and change the value;

• expand the object row and verify property ranges and transition points;

• add a Dynamic Item Property, change it later, and confirm it appears as its own timeline row rather than beneath one object;

• adjust a range boundary and verify the intended frames only;

• confirm static properties remain one value across the item.

Workbench-side schema authoring

Use Quick Create Class for a missing compatible class. Use Manage Classes to add or configure lightweight classes, Item Properties, and relations. Use Manage Ontologies to open the full builder when the change needs advanced types, JSON, Logic Map, version history, or broader review. Changes made during testing are still schema changes and must re-enter the Draft review and publication process.

Acceptance matrix

Area	Evidence required
Project wiring	Intended ontology copy is present and the correct one is Live.
Classes and geometry	Every class is visible and produces the required native annotation type.
Properties	Types, defaults, help text, Required state, Dynamic state, and values behave as designed.
Conditional logic	Every branch is reachable; irrelevant children stay hidden.
Validation	Invalid input remains visible, understandable, and recoverable.
Relations	Direction and allowed targets are correct in Workbench and output.
Item Properties	Static and dynamic whole-item values use the correct scope.
Roles and workflow	Annotators and reviewers see only valid controls and routes.
Downstream contract	Sample JSON or release output matches field IDs, types, coordinates, relations, and temporal ranges.

Record each defect with the ontology version, project, source item, role, expected behavior, observed behavior, owner, correction, and retest evidence. Publish only after the acceptance matrix passes.

---

Continue with Unitlab: AI training-data annotation