Ontology Development & Knowledge Representation
Formal, standards-based ontologies capture knowledge in a form that is at once machine-computable and reasoning-ready, and human-readable and auditable. Our craft is striking that balance — a model a reasoner can act on that an engineer, analyst, or auditor can still read and trust.
The Challenge: Why Schemas and Data Models Are Not Enough
Relational schemas, object models, and JSON or XML structures describe how data is shaped. They carry no shared, formal meaning.
A column named status or a field called target means whatever the team that wrote it decided it means; nothing in the model lets a machine — or a partner system — reason about that meaning. When two systems must interoperate, the mapping between their structures is written by hand, breaks whenever either side changes, and encodes assumptions no one can query. Structure without semantics does not scale to knowledge.
An ontology is different. It states, in a logic with formal semantics, what the concepts are, how they relate, and what must follow. That yields three things a schema cannot:
- Shared meaning that multiple systems, tools, and organizations can agree on, because it is defined once and formally.
- Machine reasoning that derives new, entailed facts rather than only retrieving stored ones.
- Durable interoperability that survives change, because it is grounded in meaning rather than in brittle field-to-field wiring.
Two problems make this genuinely hard, and are where careful knowledge representation earns its keep:
- Knowledge that must stay auditable and trustworthy. In mission and compliance settings an answer is not enough — you must be able to show why it holds. A well-built ontology keeps every derived fact traceable to the axioms and rules that produced it, so results are explainable rather than opaque.
- Knowledge that changes over time, with uncertainty. The world is not a static snapshot. Attribute and relation values evolve, arrive at different rates from different sensors, and are rarely known with certainty. Representing time-varying, uncertainty-tagged facts — without freezing the model into rigid snapshots or losing the pedigree of what was known when — is one of the central design problems of applied knowledge representation.
Our Approach
Good ontology work is engineering, not just modeling. We begin by questioning whether a formal ontology is even the right tool, scope it deliberately, ground it on a shared foundation, and build the full pipeline needed to populate, reason over, and query it.
Start with Candidacy and Scope
Not every problem needs a formal ontology, and building one where a database or a schema would do is a costly mistake. Every engagement therefore starts with candidacy — deciding whether the questions being asked actually require shared formal semantics and machine inference, or whether simpler structure suffices. When an ontology is warranted, we scope it precisely: which concepts, relations, and rules must be captured, which are out of scope, and how far the reasoning has to reach. A small, well-justified model that answers the real questions is worth far more than an exhaustive one no one can maintain.
A Shared Foundation, and the Right Kind of Ontology
Domain and application ontologies do not start from a blank page. They are grounded on NuVio, VIStology's own foundational ontology, which supplies the upper-level concepts and distinctions reused across every effort. Building on a common foundation keeps otherwise-separate ontologies mutually consistent and lets knowledge move between them.
On that foundation we build two complementary kinds of ontology. Application-focused ontologies target a specific use case — the concepts and rules a particular system needs to do its job. General domain ontologies capture a whole field in reusable form; our Cognitive Radio Ontology, developed as a community standard, is a representative example — a shared vocabulary that lets heterogeneous radios, policy engines, and reasoners describe capabilities and negotiate configurations. Deciding where a project sits on that spectrum, and how much to generalize, is part of the design work.
The Engineering Stack: From Source to Query
An ontology is only useful inside a pipeline that fills it with real data, draws the conclusions that data entails, and answers questions against the result. VIStology builds and operates that whole stack.
Source
Ontology data is sourced and lifted from wherever it already lives: relational databases, UML and SysML models, and structured documents in XML, JSON, or YAML. Unstructured text is handled by custom lifters with LLM support that extract entities and relations into the ontology.
Deriving an ontology from UML models — an approach our principals helped pioneer — is one such path, though an uncommon one.
Model
Concepts, relations, and constraints are modeled in W3C OWL and RDF and grounded on the NuVio foundation. This is where the dual nature is engineered in: the model is precise enough for a reasoner to act on, and clear enough for a person to read, review, and audit.
Validate
Before anything is reasoned over, we check that data conforms to the shapes the model requires — cardinalities, datatypes, value ranges, required relationships — using W3C SHACL. Where OWL infers what could be true under an open world, SHACL enforces what must actually be present: it catches malformed data at the door and turns the ontology into an auditable contract.
Rules
Where OWL's description logic runs out of expressiveness — composing properties, joining across relations — we encode user-defined semantic rules in BVR, VIStology's XML-based rule syntax. Rules capture the domain logic that turns raw assertions into meaningful conclusions.
Reason
BaseVISor, VIStology's forward-chaining inference engine for RDF/OWL triples, runs over the ontology and the BVR rules to derive new facts. Because relations are rarely observed directly, this step is what makes an ontology powerful: it makes implicit knowledge explicit — soundly and traceably.
Query
Questions are answered with W3C SPARQL, which returns inferred facts alongside asserted ones — so a query sees everything the reasoner could conclude, not only what was stored. To confirm a reasoner or triple store honors the ontology's semantics, we generate large, coverage-driven query sets with SQG.
Anatomy of an Ontology: The Core-and-Extend Method
The clearest way to see how VIStology builds ontologies is to look at one. The Core SAW Ontology — our core ontology for situation awareness, first published at FUSION 2003 — is a textbook example of the core-and-extend method: design a small, rigorously justified core, then specialize it to any domain by sub-classing.
A small, reusable core
At the center are just a handful of classes — Situation, SituationObject, Relation, Attribute, and Event — from which ontologies for arbitrary situations can be derived. Keeping the core small is a deliberate discipline: it is what makes the model implementable, extensible, and reusable, rather than an unmaintainable catalog of special cases. Arriving there meant weighing several alternative designs against each other, with the trade-offs made explicit — the kind of principled modeling decision every serious ontology requires.
Extension by sub-classing
A domain is added by specializing the core, not rebuilding it. In a battlefield scenario, PhysicalObject is sub-classed into military units and obstacles and new domain relations are introduced — the same technique by which this core has been specialized into the family of situation-awareness and domain ontologies VIStology maintains.
Time-varying, uncertain facts
The hardest part of the design was representing attributes and relations whose values change over time and are known only with uncertainty. The core solves this without freezing the world into snapshots: a PropertyValue carries a value together with a certainty, valid over an interval of time, and EventNotice instances — the reports arriving from sensors — mark when a PropertyValue begins and ends. A DynamicSystem can even predict a PropertyValue forward in time, such as projecting position from velocity. The result is an event-driven model of a changing world in which every fact stays time-stamped and traceable.
Proof Points
VIStology's principals have spent more than two decades building ontologies — and helping formalize the standards behind them. A few representative results:
Situation Theory Ontology
An OWL formalization of Barwise's situation theory that turns an informal theory into an implementable, queryable knowledge base. Situations, the objects and relations within them, and the inferences over them are expressed in standardized OWL, reasoned over with BaseVISor, and queried with SPARQL — a candidate community-standard ontology for computer-based situation awareness.
Core SAW → Domain Ontologies
The Core SAW Ontology showed that a small, well-justified core can be specialized to arbitrary domains by sub-classing, with a principled, event-driven treatment of time-varying, uncertain facts. It became the foundation for a family of situation-awareness and domain ontologies.
UML for Ontologies → OMG ODM
Our principals were early contributors to bridging UML and ontology languages, proposing the first-class properties and class constructors that UML lacked. That work was an intellectual precursor to the OMG Ontology Definition Metamodel (ODM) standard — expertise at the level of the modeling standards themselves, not only their use.
SQG & RODG
The SPARQL Query Generator (SQG) and its companion RDF Object Description Generator (RODG) — DARPA-funded and open-sourced — automatically produce OWL-semantics-aware query and data sets for testing reasoners and triple stores. SQG has been run at up to 2,000,000 queries across six ontologies, including VIStology's own SDR ontology.
Ontology Consistency Checking
Our principals helped pioneer automated consistency checking of Semantic Web ontologies — detecting logical contradictions in a model before it is deployed. Verifying that an ontology is internally consistent is a prerequisite for trusting anything a reasoner derives from it.
Selected Publications
Peer-reviewed foundations of VIStology's ontology and knowledge-representation practice.
Extending the Unified Modeling Language for Ontology Development
Software and Systems Modeling 1(2):142-156
View PDFOur SHACL work extends the standard itself: VIStology proposed TACL, a SHACL-based constraint language for the Test & Evaluation domain.
Introducing TACL – A Proposal for a New Standard T&E Constraint Language
International Telemetering Conference (ITC 2018)
View PublicationRelated
Put a Formal Ontology to Work
Whether you need a foundational model for a new system or a queryable, auditable knowledge layer over existing data, we can help you decide what to build and build it.
Get in Touch