Semantic ontology · guided practice

Build a model that answers real questions.

A useful domain model makes language explicit enough to coordinate people, data, and software. Begin with the questions the model must answer, then define only the concepts and relationships needed to answer them.

Concept

An ontology is a commitment about meaning.

A model decides which distinctions matter in a bounded context. It may distinguish a class from an instance, a role from a person, a current state from an event, or a source assertion from a verified fact. Those choices shape what can be recorded and queried.

A small ontology is successful when intended users interpret it consistently and it answers its competency questions without inventing certainty. More classes do not automatically make a better model.

Exercise

Move from source language to a testable model.

1. State the domain

Complete: “This model helps ___ answer ___ about ___.” Name the audience, records, system boundary, and decisions the model will not support.

Purpose before vocabulary

2. Write competency questions

Write three to five questions a future dataset should answer. Example: “Which decision used evidence from a source that has since been revised?”

Questions become tests

3. Collect source terms

Gather words from real documents and conversations. Record definitions, synonyms, conflicting uses, exclusions, and the source context for each.

Do not normalize too early

4. Identify entities and concepts

Separate kinds of things from individual things. Distinguish stable identity, role, state, event, measurement, assertion, and source when the domain needs it.

Name the distinctions

5. Define relationships

Use clear directional statements: evidence supports claim; reviewer evaluates artifact; decision affects system. Name cardinality or constraints only when justified.

Prefer verbs with meaning

6. Add provenance and lifecycle

Represent who asserted a value, where it came from, when it applied, what confidence or status it carries, and how replacement or correction works.

Meaning changes over time

7. Create sample records

Make at least one normal example, one edge case, and one counterexample. Avoid examples that only prove the model you already drew.

Reality tests structure

8. Run the questions

Trace each competency question through the model. Mark missing concepts, ambiguous paths, and answers the model should explicitly refuse.

Revise with evidence

Worked example

Model the difference between a source and an assertion.

A public record system needs to answer: “Which claims depend on a source that has been replaced?” Treating a source URL as the claim itself cannot answer that question reliably. The model distinguishes Source, SourceVersion, Assertion, and Claim. A Source has versions; a SourceVersion contains an Assertion; an Assertion supports or contradicts a Claim; a newer version may replace an earlier version.

A sample record tests the structure: version two replaces version one, while a claim still cites an assertion from version one. The query should identify the claim for review without automatically declaring it false. Provenance records who entered the relationship and when. The example reveals a boundary: replacement signals review need, not truth or invalidity. Domain participants must still define what “replaced” means in their publishing context.

Artifact structure

Publish the model with its limits.

# Domain model

Purpose and audience:
Domain boundary:
Questions this model must answer:
Questions it must not answer:

## Vocabulary
Preferred term | definition | synonyms | exclusions | source

## Concepts and entities
Name | kind | identifier rule | lifecycle states

## Relationships
Subject | relationship | object | constraint | source

## Provenance
How assertions, sources, authorship, dates, confidence, and corrections are represented:

## Test records
Normal example:
Edge case:
Counterexample:

## Review
Questions answered:
Known gaps and ambiguity:
Next reviewer or evidence needed:

Review

Invite the people whose language you modeled.

Ask at least one domain participant and one prospective data or software user to interpret the same sample records. Record where they disagree. Do not resolve disagreement by silently choosing the modeler's preferred definition.

Boundary: this exercise does not create a universal ontology or guarantee interoperable data. Formal implementation requires technical validation, governance, versioning, and agreement among the people and systems expected to use it.

Source shelf

Continue with open semantic-web standards.

Use the W3C SKOS Primer for concept schemes and controlled vocabularies, the RDF 1.1 Concepts specification for graph-based data, and the OWL 2 Primer for more expressive ontology modeling. Choose the least complexity that meets the domain's tested need.

Next: steward the workflow Use the review rubric