Embedded Semantic Reasoning
A reasoner that lives in a demo does not change your operations. VIStology demonstrated the full semantic stack running as one system at the field’s flagship conference — then built BaseVISor, a forward-chaining inference engine engineered from the start to run inside the software you already operate.
The Challenge: Reasoning That Has Somewhere to Live
Semantic reasoning earns its keep only as a component — wired into event feeds, databases, services, and the screens people actually watch. Two problems stand in the way, and VIStology hit both early enough to publish what it learned.
The first is generality. The relations that matter in an evolving situation — who supplies whom, what threatens what — are not directly measurable the way object properties are; deriving them takes background knowledge, and the space of potentially relevant relation types is practically unlimited. A system cannot hardcode a detection algorithm per relation. It needs generic reasoning machinery driven by user-defined, formally represented domain knowledge — ontologies and rules the customer can change without changing the engine.
The second is engineering fit. The OWL of the day could not express composite properties — the 2006 paper’s example is “uncle,” composed from “parent” and “brother,” the analogue of a join in a relational database — and the rule-based extensions to OWL proposed at the time were undecidable, with no effective reasoner available. General-purpose Rete engines such as Jess and CLIPS match against arbitrary list structures, not the fixed subject–predicate–object shape of RDF; and asking developers to work at the raw-triple level is, in the paper’s words, “the modern day equivalent of programming in assembly code.”
SAWA: The Whole Stack, Running as One System
At ISWC 2005 — the field’s flagship conference — VIStology, then operating as Versatile Information Systems, demonstrated SAWA, a situation-awareness assistant that wired every layer of the semantic stack into a single running application: OWL ontologies, user-defined rules with formal, ontology-grounded semantics, a forward-chaining Rete reasoner extended with procedural attachments, a persistent triple store answering historical and what-if queries, streaming event ingestion, and a live monitoring GUI — fed by an authoring toolchain of a visual ontology editor, VIStology’s ConsVISor consistency checker, and a graphical rule editor with drag-and-drop authoring against the ontology.
A reusable core, a swappable domain
The design center is a domain-independent core ontology that every domain plugs into: a Situation consists of Objects, Relations, and a Goal — the standing relation the user cares about — and any domain ontology whose classes subclass the core’s Object works with the unchanged engine. The demonstration domain was military supply logistics: a small domain ontology, every class subclassing the core, plus a compact rule set defining when a unit has a supply line. The engine did not know, and did not need to know, anything about logistics.
Integration by ontology, not by adapter
Two wiring decisions carry the integration lesson. Only the event-ingestion component knows the event ontology — a deliberate isolation, so data sources annotated against different ontologies can be swapped in without touching the reasoner, the store, or the user interface; each consumer receives events in exactly the form it needs. And the user’s goal does systems-engineering work: starting from the standing relation, the system reasons its way to the subset of rules worth loading and the objects and attributes worth monitoring, paring an intractable event stream down to what matters before the reasoner ever sees it.
What the demonstration showed — and what it did not
The supply-line scenario was simulated as OWL-annotated snapshots of the world at sequential time slices, a unit moved each slice to change which relations hold; fed to the running system, “the system correctly detected the standing relations that held true at each time slice and reported these back to the GUI.” The triple store retained the full event history, and supported what-if queries: assert a hypothetical fact, query, then retract it along with everything deduced from it. This is a systems demonstration, not a benchmark — there are no timing or accuracy tables, every derived relation carried certainty 1.0, and no live sensor feed was involved. We state that because the papers do.
The pain points that became a product
The paper is frank about where the era’s stack fought back. The rule layer of the day was verbose to the point of pain — nine rules in the second scenario took more than 1,000 lines of rule code, and a four-variable predicate had to be reified as a class nine times over — it allowed only binary predicates, it had no negation as failure, and it had no user-defined procedural attachments. The triple store, built on a general-purpose rule engine, was too inefficient for near-real-time use; the reasoner itself was an enhanced Jess engine, and we are precise about that: BaseVISor did not run SAWA. What the team wrote instead is the bridge: they were developing “our own inferencing and query engine optimized for the processing of triples.” The integration lessons from SAWA became the requirements for BaseVISor and BVR.
BaseVISor: An Engine Built to Embed
“BaseVISor is a forward-chaining inference engine based on a Rete network optimized for the processing of RDF triples.” That sentence, from the 2006 work that introduced it, contains the design decision: instead of wrapping a general-purpose rule engine, VIStology re-engineered the Rete match network around the fixed shape of the RDF triple.
Specialized for the workload
Where engines like Jess and CLIPS match facts as arbitrary list structures, BaseVISor’s facts are triples and nothing but — a simple, fixed data structure that, in the paper’s words, “permits greatly enhanced efficiency in pattern matching which is at the core of a Rete network.” That is an architecture claim, and we keep it one: the 2006 papers report no performance benchmarks, and we attribute none to them.
Two ways into your system
BaseVISor is written in Java and deploys both ways an integrator needs: embedded within an application through its API, which permits “finer control of the loading and operation of the inference engine,” or standalone, driven by a batch file of facts, rules, and queries. Facts, rules, and queries are written in BVR, BaseVISor’s XML-based rule language — a name the site uses in its own voice; the 2006 papers say “BaseVISor’s native rule language.” Rule bodies and heads can invoke procedural attachments, built-in or user-defined — math, comparisons, string and date functions, symbol generation, matching on the absence of triples — and, in the line that matters most for integration, “procedural attachments may be used to interface to other applications (e.g., a database or web service).” The rules do not just conclude; they reach into the systems around them.
Standards-grounded, with guarantees you can predict
BaseVISor imports RDF/OWL documents and derives their entailed triples under R-Entailment semantics — covering RDF, RDFS, and a substantial subset of OWL, implemented in full in the distribution — a semantics chosen for its formal properties: decidable for rules that do not introduce blank nodes, NP in general, and polynomial when the target graph is ground. Complexity guarantees rather than timings — reasoning behavior you can predict before you put it in a product. N-ary predicates are decomposed automatically into standard binary triples following the W3C best-practice pattern for n-ary relations, so developers write the predicate they mean and the engine handles the plumbing. In the 2006 conclusion’s words, with this capability BaseVISor “moves beyond the realm of rule based inference engines into the space of description logic reasoners.” The engine was developed under U.S. ONR STTR and U.S. Army SBIR contracts — and it is the reasoning core VIStology’s integration practice still builds on.
Proof Points
SAWA: The Full Stack, Running
At ISWC 2005, VIStology — then operating as Versatile Information Systems, Inc. — demonstrated SAWA, a situation-awareness system wiring the whole stack together: OWL ontologies, user-defined rules, a forward-chaining reasoner with procedural attachments, a queryable triple store, and a live monitoring GUI. In its supply-logistics demonstration, the system correctly tracked which units held supply-line relations at every time slice. The integration lessons from SAWA became the requirements for BaseVISor and BVR.
BaseVISor: Built to Embed
BaseVISor is a Java inference engine designed from the start for deployment: embedded inside an application through its API — with procedural attachments that interface to databases and web services — or run standalone, with a Rete match network engineered around the fixed shape of RDF triples. Developed under U.S. ONR STTR and Army SBIR contracts, it is available as a free download from vistology.com.
Selected Publications
BaseVISor: A Triples-Based Inference Engine Outfitted to Process RuleML and R-Entailment Rules
2nd International Conference on Rules and Rule Markup Languages for the Semantic Web (RuleML'06)
View PublicationRelated
Put a Reasoner Inside Your Product
If your systems need conclusions, not just data — derived in-process, against your ontology, with rules your engineers can read — we can help you embed the reasoning where your software already runs.
Get in Touch