How do I build an ontology from workflow evidence?

Start where a wrong answer changes work

Ask what the analyst, agent, or operator is deciding. Collect examples of the records used, including cases that were rejected or escalated. A noun list often contains broad labels such as customer and product but omits the state or exception that determines the actual decision. Make the smallest decision boundary the unit of discovery.

Use competency questions as acceptance tests

Write questions the ontology must answer, such as which accounts were eligible at a particular time and why. For each question, identify required entities, relations, provenance, and missing-data behavior. Include a counterexample that resembles an eligible case but must be excluded. These tests constrain modeling choices more effectively than an abstract preference for a graph technology.

An eligibility exception changes the model

In a fictional subscription service, an account appears active and owns the right plan, but its contract excludes a trial offer in one region. A generic Account–Plan link cannot explain the refusal. The workflow evidence reveals contract scope, effective date, region, and exception authority. The ontology adds only the relationships needed to answer the eligibility question with a reviewable reason.

Map each concept to evidence

A mapping sheet keeps semantic commitments tied to inspected records.

Question element	Candidate concept	Evidence and owner
Active account	State with effective interval	Billing record and finance owner
Eligible plan	Contract relation	Product catalog owner
Regional exception	Scoped exclusion	Contract policy owner
Decision reason	Provenance of applied rule	Eligibility service

Validate shapes and examples together

Use constraints to catch missing identifiers, impossible state combinations, and wrong relation targets. A passing shape check only proves a data graph satisfies the written shape, not that the shape captures the right business rule. Review the positive and negative examples with domain owners. Record which questions remain outside the first slice and how an agent should respond to them.

Choose representation after the commitment is clear

RDF and OWL offer standardized graph and inference machinery; relational tables or a property graph may also represent a bounded contract. Pick the form that supports the required identity, validation, update, and query work. Do not expand into open-ended inference when the workflow needs a small explicit decision. Version the concepts and mappings so a later exception can be tested without silently changing historical answers.

Evidence boundary for workflow ontologies

• W3C RDF concepts: W3C defines RDF graphs and datasets as a representation framework. The data model does not choose the business concepts for this workflow.
• W3C SHACL: SHACL specifies constraint validation against data graphs. Passing constraints does not establish business-rule correctness.

The eligibility case is constructed. A real ontology needs domain-owner examples and inspected source evidence.