Foundation to surface,
read like a core sample.
Four strata carry the taxonomy. Four veins carry meaning, context, measurement, and recognition across every stratum. One ruler dates each addition. The surface layer is the only place company-specific terms attach.
Build a class live, saved to your account
An ontology is a formal, shared specification of what kinds of things exist in a domain and how they relate. You are building one here for product development. The classes you add become a knowledge base that can be shared across teams, checked for logical consistency, and evolved as understanding changes.
Getting started, five steps
-
Define your organization's contextsOpen the Contexts tab and add at least one Context: a named domain of use (Automotive, Aerospace, Consumer Electronics) with a plain-English description of what it covers and excludes for your org. Context is what makes org-specific terms findable without cluttering the shared tree.
-
Add domain-neutral classes at Layer 03On the New class tab, pick a Layer 01 primitive as the parent (Structure, Function, Task, Assessment, or Agent). These classes will be shared across all orgs and should be named in terms anyone in product development would recognize, not your company's internal vocabulary.
-
Add org-specific classes at Layer 04Pick a Layer 03 class as parent. Set the Org / unit field. These are your company's terms, underneath a shared parent that any other org can recognize. If two orgs independently add similar terms, the Semantic vein's closeMatch relation handles alignment, not tree duplication.
-
Assign Roles for context-dependent functionsOn the New Role tab, assign a Role to an Agent or Structure. Use this instead of subclassing when the classification is context-dependent. Job titles, operator types, and reviewer positions are always Roles, never subclasses of Human_Agent.
-
Browse, flag, and exportThe right panel shows everything you have built, filterable by name, label, exemplar, or facet. Contested classes show a red border and a flag reason; click clear to dismiss after reviewing. When ready, expand Export JSON or open How to access for format documentation and download options.
Export JSON (human-friendly)
Human-readable, reloadable, valid input for Python json.load(). Internal IDs, not persistent URIs.
Export Turtle / OWL (machine-readable)
Persistent URIs, BFO grounding, SKOS labels, OWL class axioms, RO/IAO/OBI relation assertions. Valid input for Protege, OWL API, rdflib, and any SPARQL endpoint.
How to access your ontology, three formats
JSON format
Three arrays of plain objects. Good for human inspection, Python scripting, and reloading into this tool. Uses internal slugs (seed_component), not persistent URIs, so it is not safe to share across systems without URI translation.
{ "classes": [...], "roles": [...], "contexts": [...] }
Turtle / OWL format
A valid OWL 2 ontology in RDF Turtle syntax. Every class gets a persistent URI at https://pdo-ontology.org/class/ClassName. Every Layer 01 primitive is declared as a subclass of its real BFO URI (BFO_0000004, BFO_0000015, etc.). The twelve Layer 02 relations are resolved to their source URIs from BFO, RO, IAO, OBI, and PROV-O. PDO-specific relations (has_agent, has_assessor, supersedes) are declared as OWL ObjectProperties with formal domain and range. SKOS prefLabel, altLabel, and definition annotations are included on every class. Role classes are declared as subClassOf obo:BFO_0000023 (BFO Role) with bearer_of (obo:RO_0000053) assertions. Contexts are serialized as a SKOS ConceptScheme.
@prefix pdo: <https://pdo-ontology.org/class/> .
@prefix pdor: <https://pdo-ontology.org/relation/> .
@prefix obo: <http://purl.obolibrary.org/obo/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
pdo:Component a owl:Class ;
rdfs:subClassOf pdo:Structure ;
skos:prefLabel "Component"@en ;
skos:definition "Component is a discrete physical or logical part..."@en .
Using in a reasoning engine
Load the .ttl file into Protege, OWLTools, or ROBOT. The file imports obo:bfo.owl for full BFO axioms. In Python: rdflib.Graph().parse("ontology.ttl"). In SPARQL: query by rdfs:subClassOf chains to retrieve all subclasses of a primitive. The owl:imports declaration enables automatic BFO axiom loading in supporting tools.
SPARQL example
PREFIX pdo: <https://pdo-ontology.org/class/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?class ?def WHERE {
?class rdfs:subClassOf* pdo:Structure ;
skos:definition ?def .
}
Bedrock BFO top level
What this is: the two most fundamental categories from Basic Formal Ontology, the shared spine every class in this tool ultimately traces back to. Why it matters: anchoring here means this ontology speaks the same language as other BFO-grounded instruments in engineering, medicine, and science, making cross-domain alignment possible rather than accidental.
An entity that endures through time while potentially gaining and losing properties. Structure, Function, and Agent all descend from here.
An entity that happens rather than persists. Task descends from here. An Assessment, though a record created at a point in time, is also an Occurrent in the strict BFO sense.
Core engineering primitives 5 object types
What this is: five BFO-grounded primitives that cover every kind of thing a product-development ontology needs to represent. Why five and not four: Agent was added because humans and automated systems initiate actions, complete and assess tasks, bear functional roles, and become bottlenecks. Without a first-class Agent, none of that is formally representable, only nameable. Why these five and not more: every other candidate (Application, Requirement, Stakeholder) decomposes into combinations of these five plus relations, meaning they are compositions, not new kinds of things.
A physical or logical artifact that persists: a part, a subsystem, a material, a software module.
An intrinsic capacity a Structure or Agent bears, regardless of context. What something is inherently for or capable of.
Bounded work that realizes one or more Functions, initiated or executed by an Agent. Ordered through sequence relations, not just composed.
A measurement or judgment made by an Agent. Only valid once grounded to a Quality or Realizable Entity via is_quality_measurement_of. Always carries an assessor via has_assessor.
Any entity that initiates, executes, or assesses a Task. Includes humans, automated systems, and composite groups. Shares a BFO root with Structure but is fundamentally different: a Structure can only participate in a process; an Agent can originate one.
The Agent rule
No org-specific subclasses of Agent are permitted at Layer 04. Every job title, operator type, and team role is context-dependent, which means it is a Role borne by an Agent, not a new kind of Agent. Adding "Senior_Reliability_Engineer" as a subclass of Human_Agent would be a violation. The correct model is Human_Agent bearing a "Senior_Reliability_Engineer_Role" in a specific org Context. The Workbench enforces this and will block the attempt with an explanation.
Where Application went
Application is not a sixth primitive. It is a composition: a Structure + bearer_of + Role, realized within a Context tag through occurs_in. A deployed artifact, not a new kind of thing.
Relations closed set of 12, borrowed not invented
What this is: every relation permitted in this ontology. No org may invent a new relation; any relation needed that is not here must be defined as a subtype of one of these twelve. Why a closed set: an open relation vocabulary makes cross-company comparison impossible. Where they come from: BFO, the OBO Relation Ontology (RO), the Information Artifact Ontology (IAO), OBI, and PROV-O. Nothing is invented here.
Domain-neutral extensions reusable vocabulary
What this is: product-development vocabulary that belongs to no single company. Any org may use these terms without modification. Why this layer exists: without it, every company puts its terms directly under a Layer 01 primitive, and there is no shared ground for cross-org comparison. Layer 03 is that shared ground. How it grows: by consensus, not by any single org's decision.
A human participant who initiates, executes, or assesses Tasks. Job titles are Roles on this class, never subclasses of it.
A system, pipeline, or model that initiates or assesses Tasks without human initiation. Covers CI systems, ML inference, and automated measurement.
A context-dependent function borne by a Human_Agent or Automated_Agent. Includes reviewer, approver, operator, and end user. Always attached via bearer_of, never via is_a.
A Task whose output is an Assessment that supersedes prior Assessments on the same Quality. Used to resolve authority disagreement formally. The Agent with a Final_Authority_Role has_agent this Task.
Org / unit surface where it changes most
What this is: the only layer where company-specific vocabulary belongs. How it works: each org adds leaf subclasses beneath Layer 03 without modifying anything above. Two orgs can both add a "Heat_Dissipation_Component" here without conflict; that is what the semantic vein's closeMatch relation handles, not a tree collision. The one hard rule: no Layer 04 class may subclass Agent or any Agent descendant. Everything that looks like a kind of person or system is a Role, not a new class.
| Org | Adds at Layer 04 | Layer 03 parent | Correct because |
|---|---|---|---|
| Org A | Torque_Sensor | Component | A specific physical kind of Component |
| Org B | DO-178C_Compliance_Check | Test_Case | A specific kind of test defined by a standard |
| Org C | Heat_Dissipation_Component | Component | A specific physical kind of Component |
| Any org | Senior_Reliability_Engineer | BLOCKED | Job titles are Roles on Human_Agent, not Agent subclasses |
Logical grounding BFO / IAO / OBI
What this is: the constraint that makes Assessments mean something rather than just existing. Why it matters: without it, a measurement can claim to be about anything or nothing, and the knowledge base degrades into a collection of opinions with no traceable object. How it works: every Assessment must name the Quality or Realizable Entity it grounds in before it can be saved.
An Assessment never attaches directly to a Structure, Task, or Agent. It attaches to the Quality or Realizable Entity that thing bears, via is_quality_measurement_of. If the Quality's definition changes, every Assessment pointing to it inherits the update rather than going stale. Every Assessment also carries a typed assessor via has_assessor, making authorship a formal property, not a comment field.
Information science facets, authority control, findability
What this is: the layer that makes the ontology findable and comparable, not just logically correct. A tree that can only be navigated by traversal is unusable in practice. Why information science and not just more relations: findability and authority control are not ontological claims about what things are; they are claims about how humans access information. Mixing them into the is_a tree would conflate two separate questions.
Faceted classification
Context, Lifecycle Stage, Discipline, and Sequence are facets in Ranganathan's sense: independent dimensions for filtering that never touch the is_a tree. A class can be found through any combination of facets without any of them creating a new parent. This is also what lets future dimensions be added without taxonomy proliferation.
Authority control
The semantic vein's Label Set carries thesaurus relations from ISO 25964 and ANSI/NISO Z39.19 alongside denotes: broader_than, narrower_than, related_to, use_for. These are browse relations for humans navigating the tool, kept strictly separate from the closed Layer 02 logical relation set. They never become axioms.
Findability sequence
Search in this tool is built on facets plus exemplars, not tree traversal. An engineer filters by Context, scans exemplars to recognize the right class, then reads the formal genus-differentia definition to confirm. That order, filter, recognize, confirm, is what a usable knowledge instrument requires that a published taxonomy never had to provide.
Cognitive science two tracks
What this is: two distinct cognitive questions, both real, that this ontology needs to answer. They are not the same question and should not be collapsed. Track 1 asks how an engineer recognizes and navigates classes inside this tool. Track 2 asks how a human operator actually uses the things the ontology describes, physical components, software applications, automated systems, and complex task sequences. Track 1 was built in earlier versions. Track 2 is the missing piece.
How engineers find and recognize classes in this tool. Grounded in Rosch's basic-level category theory and working-memory research.
Marks the level a person names first, sensor before transducer or capacitive proximity sensor. The interface defaults to basic-level terms.
1 to 3 prototypical examples attached alongside the formal definition. The definition governs reasoning; the exemplars govern recognition.
4 to 7 basic-level siblings per view. Beyond 7, create an intermediate grouping class. This is the justification for progressive disclosure in the UI, not a visual preference.
How Agents actually use the Structures and Systems the ontology describes. Physical ergonomics, HCI usability, and operator workload are all formally representable here.
A Disposition (not a Quality) borne by a Structure or Agent. Learnability, grip accessibility, error recovery. Only realized when an Agent actually interacts with the artifact.
A Task that realizes a Human Factors Disposition. Has a Human_Agent via has_agent. Different Agents produce different Assessments of the same Disposition under the same Usage_Task.
An Assessment grounding in a Human Factors Disposition via is_quality_measurement_of. Examples: NASA-TLX score, SUS score, grip force measurement. Same mechanism as any other Assessment.
A physical Component bears an ergonomic Disposition (ISO 6385). A software Application bears a learnability Disposition (ISO 9241-11). A machine interface bears an error-recovery Disposition. None of this requires a new mechanism, only a new category of Disposition.
Provenance & evolution the dating ruler
What this is: not a stratum and not a vein. It is the dimension along which every stratum was deposited. Every class, relation, and Assessment carries a record of when it was added and why. Why this matters: knowledge changes. An ontology without provenance cannot evolve without breaking the instances that depend on it. The dating ruler makes change traceable and reversible.
Every class and relation carries a timestamp of when it was added or last revised.
Why this term exists, traceable per class. A term without a justification fails the competency question test.
The question each class must be able to answer to justify its existence. If no competency question can be written, the class should not exist.
Field completeness, circular-inheritance check, parent resolution, sibling disjointness, and Agent-subclassing rule. Run against every term before it is marked stable.
Terms are superseded, not deleted. Existing instances never break because the old term remains in the record, marked deprecated with a pointer to its successor.
Role mechanism not a second parent
What this is: the answer to "this thing seems to belong to two categories at once." Why it is not a second is_a parent: BFO requires single inheritance because an entity's category is supposed to reflect what it fundamentally is, not every role it plays. Adding a second parent mixes two questions together. The rule: if a second classification is only true in some context, it is a Role. If it is always true with no context dependency, there is a missing common ancestor in the tree.
↳ always true, regardless of context
↳ only true in Automotive, active suspension Context
↳ only true in Org A, structural review cycle
| Second classification is… | Correct model |
|---|---|
| Always true, no context dependency | Not a Role. There is a missing common ancestor. Find it and add it to Layer 03. |
| Only true in some context of use | Attach as a Role via bearer_of with an occurs_in Context. Leave is_a untouched. |
| A job title or team function | Always a Role on Human_Agent. Never a subclass of Human_Agent or Automated_Agent. |
Disagreement four kinds, one resolution mechanism
What this is: the formal treatment of the most common real-world engineering problem, multiple Agents reaching different conclusions about the same thing. Why it matters: an ontology that cannot represent disagreement forces all disputes into comments and email chains, making the knowledge base appear more settled than it is. The key insight: only one of the four kinds of disagreement requires a formal resolution mechanism inside the model. The other three have better treatments elsewhere.
Two Agents measure the same Quality on the same Structure and get different numbers. Different instruments, different conditions, different operators.
Both Agents agree on the number but disagree on whether it passes. The threshold is what is actually contested, not the measurement.
Two orgs disagree about what the Quality or class even means. This is the sibling disjointness problem.
Resolution mechanism for authority disagreement
A Review_Task takes one or more prior Assessments as has_participant. An Agent bearing a Final_Authority_Role is the has_agent. The Review_Task produces a new Assessment that carries supersedes, pointing at the Assessments it replaces. Superseded Assessments remain in the record as the audit trail. They are not deleted.
| Step | What happens | Relation used |
|---|---|---|
| 1 | Engineer A submits an Assessment of weld tolerance | has_assessor → Engineer A (Human_Agent) |
| 2 | Engineer B submits a conflicting Assessment | has_assessor → Engineer B (Human_Agent) |
| 3 | Chief Engineer initiates a Review_Task | has_agent → Chief_Engineer (Human_Agent bearer_of Final_Authority_Role) |
| 4 | Review_Task takes both prior Assessments as input | has_participant → Assessment A, Assessment B |
| 5 | Review_Task produces a final Assessment | supersedes → Assessment A, Assessment B |
| 6 | Prior Assessments remain, marked superseded | Audit trail intact. Nothing deleted. |
Note: a superseded Assessment that was correct and overridden by authority looks identical in this model to one that was genuinely wrong. Distinguishing those two cases requires the Proposed / Validated / Contested epistemic status layer, which is planned for a future version.
Sibling disjointness within an org vs. across orgs
What this is: the validation rule for catching duplicate or conflicting classes under the same parent. Why it branches by org: a near-identical definition from the same org is a real violation (duplication). The same situation across two different orgs is expected and correct (two companies independently recognizing the same thing). Treating them the same way produces too many false positives to be useful.