OntoL's DSL and Inference Engine: From Static Ontology to Executable Knowledge Graphs

OntoL's self-developed DSL and inference engine form an executable ontology system where a property graph carries entities, relationships, and properties, while the DSL describes trigger conditions, actions, graph traversals, and state updates. These expressions are attached to ontology nodes or relationships, and the inference engine evaluates, validates, derives, propagates, and writes back results using instance data. Standard fields provide unified metadata for rule definition, execution order, timeout control, result tracing, provenance, confidence, verification status, and replica state. Together they turn the ontology from a static description into a dynamic execution network that supports business computation, impact analysis, and sandbox simulation.

Why Ontology Products Need DSL and Inference Engine

The basic task of an ontology is to formalize concepts, entities, relationships, properties, and constraints in a domain. For example, in supply chain one can define Supplier, PurchaseOrder, ProductionBatch, WorkOrder, Product and their relations. However, a static ontology only solves data organization and semantic unification; it cannot directly perform business reasoning such as:

Should a supplier with on-time delivery rate below 80% be flagged as high-risk?

Should a batch nearing expiry be blocked from allocation?

Which purchase orders, work orders, and sales orders are affected when a supplier becomes risky?

Which data triggered a rule and which property did it modify?

How would downstream risk status change if a supplier grade is adjusted in a sandbox replica?

These questions require the system to compute over facts according to rules. An executable ontology system therefore needs at least two components: a language for expressing rules (conditions, actions, constraints, graph traversals) and an inference engine that reads the ontology and instance data, interprets expressions, controls execution, and outputs reasoning results. OntoL's custom DSL and inference engine address these two parts, while standard fields manage rule and execution state uniformly, and the graph database handles storage and association of ontology and instance facts.

Basic Positioning: From Static Ontology to Executable Ontology

A traditional property graph expresses three types of information:

Node: business entity or concept
Edge: relationship between entities
Property: key-value data carried by node or edge

For example:

SupplierA --supplies--> PurchaseOrderB
SupplierA.onTimeRate = 0.62

This structure describes who SupplierA is, which orders it relates to, and its on-time rate, but whether 0.62 means high risk still requires extra rules. OntoL adds executable rules on top of the graph model so that nodes and relationships can also carry:

Trigger condition
Action to execute
Target node or property
Execution order
Whether failure blocks
Execution result
Affected objects
Validation status
Execution on original or replica data

This makes OntoL closer to an executable ontology where classes, relationships, constraints, and behaviors are managed in the same graph model; the DSL expresses behavior and the inference engine executes it.

Overall Architecture: Declaration Layer, Fact Layer, Execution Layer

1. Ontology Declaration Layer (TBox)

Defines the basic structure of the business domain:

Node types and their properties

Relationship types and directions

Constraints on nodes and relationships

Rule trigger conditions

Rule execution actions

Rule descriptions, execution order, and validation strategies

This layer resembles the TBox in ontology theory — knowledge about concepts and schemas. For example, "Supplier has onTimeRate" and "High-risk supplier enters watchlist" are domain rule declarations.

2. Instance Fact Layer (ABox)

Stores concrete business objects:

Supplier: SuBei Casting Factory
onTimeRate: 0.62
supplierGrade: C

This layer resembles the ABox — facts about specific individuals and their relations, answering what actually exists in the current business world.

3. Inference Execution Layer

The inference engine reads rules from the declaration layer and applies them to the fact layer. For instance, when a supplier satisfies "onTimeRate < 0.8", the engine executes the rule and derives: riskLevel = 高风险 This property is not manually entered but derived from existing facts and rules. The flow is:

Ontology Declaration + Instance Facts
        ↓
    Inference Engine
        ↓
Validation Results / Derived Facts / Graph Traversal Results / Business Actions

DSL Core: Condition Declaration, Execution Actions, and Graph Traversal

The core rule structure of OntoL DSL is:

ontoL_condition: trigger precondition function
ontoL_execution: execution effect function

condition

decides whether the rule's precondition is satisfied; execution decides what operation to perform when the condition holds. Example:

ontoL_condition:
reasonObj.attr("onTimeRate") < 0.8

ontoL_execution:
reasonObj.set("riskLevel", "高风险")

Here reasonObj represents the current ontology object participating in evaluation; .attr() reads an object property; the comparison forms a boolean condition; .set() writes a derived property; condition and execution together form a complete rule. This structure is declarative — modelers describe what conditions produce what results without writing full procedural control — yet executable because the DSL is parsed, distributed, and evaluated by the inference engine, turning into property reads, logical comparisons, graph queries, or state updates.

Beyond single-object rules, DSL supports graph traversal via chained expressions. Example:

$n('产品')
.filter("[name=行星减速器]")
.next_n("R_COMPOSED_OF")
.attr("name")

This expression locates a product, filters by name, traverses along a relationship, and extracts an attribute. Repeated .next_n() enables multi-hop traversal. Thus DSL covers both local property computation and graph structural computation. From a language composition perspective, OntoL DSL includes four operation categories:

Object operations : read property, check property existence, modify property

Logical operations : comparison, containment judgment, boolean combination

Graph operations : node selection, edge selection, filtering, forward or reverse traversal

Action operations : write back property, update state, call extension functions, enter complex query channels

Therefore it is not purely a rule condition language nor a pure graph query language, but a combination of both with additional business write capabilities.

Standard Fields: Unifying Rules and Execution Process in a Meta-Model

If DSL is the expression form of rules, OntoL standard fields are the metadata containers for rules. Their role is not to perform reasoning directly but to let the inference engine identify, schedule, and record rules in a uniform way. These fields are grouped into seven functional categories:

1. Identity and Provenance Fields

ontoL_snowflake_id

identifies objects; ontoL_source_id records provenance information. They provide the basis for rule location, data tracking, and audit. Provenance is critical because a derived conclusion must answer "which rule, based on which facts" to be explainable and auditable.

2. Rule Target Fields

ontoL_target_node

and ontoL_target_field point to the target ontology and target property; ontoL_relType indicates the relationship type. These fields allow rules to explicitly describe impact targets beyond the current object, e.g., a rule validating a batch can direct its result to a product property or find affected objects along a specified relationship. However, the presence of target definitions only shows the system's expressive capability; whether automatic cascading execution occurs and how multiple targets are handled depends on the inference engine's scheduling implementation.

3. Rule Declaration Fields

ontoL_condition

, ontoL_execution, ontoL_relationship, and ontoL_rule_description carry condition, action, relationship syntax, and rule description respectively. The first two face machine execution; the description faces human understanding and maintenance. Placing both in the same meta-model reduces separation between "code logic" and "business explanation".

4. Execution Control Fields

ontoL_exec_order

, ontoL_order, ontoL_execution_timeout_ms, and validation type fields provide control parameters for rule ordering, execution timeout, and validation strategy. Rule ordering is essential in multi-rule systems: e.g., supplier risk classification must complete before high-risk supplier impact analysis, otherwise the latter may read stale state. Timeout control ensures DSL execution is not unlimited computation; for external interfaces, dynamic functions, or complex graph traversals, single rules must not occupy execution resources indefinitely.

5. Execution Result Fields

ontoL_condition_val

, ontoL_condition_msg, ontoL_execution_val, ontoL_execution_msg, and ontoL_llm_message form a result receipt system. val stores machine-processable computation results; msg stores business-understandable execution explanations; llm_message can store LLM-generated explanations for interactive scenarios. This design preserves both "whether execution succeeded" and "why this result was produced", making reasoning results consumable by programs and readable by business personnel.

6. Quality and Verification Fields

ontoL_is_consistent

, ontoL_diff_reason, ontoL_match_score, ontoL_confidence, and ontoL_verification_state describe consistency, differences, match degree, confidence, and verification state. These fields show OntoL does not treat all generated content as reliable fact but retains quality markers for pending-verification knowledge. Especially when LLMs auto-generate ontologies or rules, syntactic executability does not guarantee business semantic correctness, so consistency checks and verification processes remain necessary.

7. Impact and State Fields

ontoL_impacted_by

, ontoL_impact_oneself, ontoL_weight_value, ontoL_source_state, and ontoL_copy_state express impact source, self-impact, weight, and original vs. replica state. They link rule execution with impact propagation, version management, and sandbox simulation, enabling the system to distinguish:

What the original fact is
What it became during simulation
Who caused the change
Impact magnitude
Whether the result is verified

Thus standard fields extend DSL from a mere expression into a manageable, schedulable, auditable rule object.

Inference Engine Execution Process: From Rule Loading to Result Write-Back

Combining DSL and standard fields, a typical OntoL inference engine execution can be abstracted into the following steps:

Step 1: Establish Inference Context

The engine first determines the current inference objects, including:

Current node or relationship

Current business scenario

Original data or sandbox replica

Available nodes, edges, and properties

Current rule's execution order and validation strategy

Runtime objects like reasonObj are then bound to concrete instances, allowing the same DSL rule to act on different business objects.

Step 2: Load and Parse Rules

The engine reads ontoL_condition, ontoL_execution, and other fields, parsing and dispatching expressions. Simple property comparisons enter the expression evaluation pipeline; graph traversals enter the graph operation pipeline; complex queries or extension functions enter their respective execution channels. The DSL engine acts as a "translator and dispatcher": it does not perform all business reasoning itself but must convert different syntax elements into deterministic internal operations.

Step 3: Compute Trigger Preconditions

The engine executes condition, obtains the condition result, and writes to corresponding condition_val and condition_msg. If the condition fails, the rule typically does not trigger; if it passes, subsequent validation and execution phases proceed. For missing properties or expression evaluation failures, the public DSL examples adopt a tolerant execution approach that returns a failure result without interrupting the overall flow. This improves batch reasoning stability but creates a semantic issue: missing properties, type errors, and unmet conditions may be compressed into the same failure result. Engineering implementations still need logs or status codes to distinguish "business non-match" from "technical execution failure".

Step 4: Apply Validation Strategy

Standard fields' Strong, Weak, etc. validation types express handling intensity after rule failure. Generally:

Strong validation tends to block execution, write, or state transition

Weak validation tends to alert, record, or lower confidence but allows process to continue

However, the field table itself does not fully define state transitions; specific behavior should follow the inference engine specification. It is especially important to distinguish "condition not hit", "validation not passed", and "execution exception" — three cases that should not share a single boolean value.

Step 5: Execute Action and Control Timeout

After condition satisfaction, the engine executes execution. Actions may include:

Generate derived properties

Modify business state

Query associated nodes

Compute impact results

Call external functions

Return a natural-language explainable business conclusion

Execution is constrained by parameters like execution_timeout_ms. Upon completion, results are written to execution_val and execution_msg, optionally generating llm_message.

Step 6: Record Provenance, Quality, and State

The engine or upper business system further updates provenance, confidence, verification state, difference reason, and replica state. This step determines whether reasoning results can enter the trusted knowledge base. A technically successful execution result may still be in a pending-verification state; an LLM-generated rule, even if syntactically correct, may not be published directly due to unreasonable business meaning.

Step 7: Handle Subsequent Impacts

If a rule modifies a key property, the system can continue impact analysis or schedule subsequent rules based on target node, target field, relationship type, and impact fields. Thus a single rule execution can expand into a graph reasoning process:

Fact change
 → Current rule hit
 → Derived state update
 → Associated objects recalculated
 → Downstream rules hit
 → Propagation chain formed

This is the core capability added by combining DSL with the inference engine compared to a single graph query.

Rule Propagation and Sandbox Simulation: Computing "Impact of Change" on the Graph

Ontology reasoning is not only for producing classification labels but also for analyzing how a change propagates along business relationships. For example, when a supplier is flagged as high-risk, the impact scope can be traced along:

High-risk supplier
 ← supply relation —
PurchaseOrder
 ← batch source —
InboundBatch
 ← work order consumes —
WorkOrder
 — fulfillment relation →
SalesOrder

In this process, DSL describes traversal direction and filter conditions; the inference engine maintains the current object set, executes each hop, and aggregates results; standard fields record impact source, weight, and execution explanation.

If such computation directly modifies production data, it may introduce uncontrolled risks. Therefore OntoL introduces a replica simulation mechanism: hypotheses, rules, and data adjustments are executed on an isolated replica, and based on audit results, a decision is made whether to update the formal ontology. Public product materials describe this as isolating uncontrollable data changes during simulation via replicas.

From a principle perspective, sandbox simulation is not a separate inference engine but a change of data scope for the same engine:

Formal reasoning: Rules × Original Facts → Formal Results
Sandbox simulation: Rules × Replica Facts + Hypothesis Conditions → Candidate Results

source_state

and copy_state fields provide the metadata basis for distinguishing data under these two states.

LLM's Role: Generating Constrained Instructions, Not Replacing the Inference Engine

Another purpose of OntoL's DSL is to constrain the interaction between LLMs and the ontology system. Without DSL, an LLM might directly generate natural language answers, database statements, or unstructured operation instructions, which can suffer from unstable formats, wrong field names, incorrect relationship directions, and non-executability.

With DSL, the interaction chain becomes:

User Question
 ↓
LLM understands intent and selects ontology symbols
 ↓
Generates DSL expression
 ↓
Syntax parsing and execution dispatch
 ↓
Inference engine or graph operation engine executes
 ↓
Returns structured results
 ↓
LLM organizes natural language response

In this architecture, the LLM mainly handles semantic understanding, intent recognition, and expression generation, while the inference engine handles deterministic computation. OntoL's public positioning of its product DSL is precisely to translate a standardized symbolic language into ontology operation instructions, thereby constraining LLM output boundaries.

However, DSL can only constrain output form, not automatically guarantee semantic correctness. The LLM may still choose wrong node types, relationship types, or comparison thresholds. Therefore governance fields like is_consistent, diff_reason, match_score, and verification_state have practical significance: they provide audit basis for "whether generated results can become trusted ontology knowledge". A reasonable division of responsibilities is:

LLM converts vague requirements into candidate rules; the inference engine executes rules deterministically; verification and audit mechanisms decide whether rules and results can enter the formal knowledge system.

Relationship with OWL, SWRL, and SPARQL

OntoL DSL has certain correspondences with standard ontology technologies:

OntoL Mechanism          | Comparable Standard Technology
-------------------------|------------------------------
Node/Relationship Types  | OWL Classes & Object Properties
Condition Constraints    | OWL Restrictions or Business Validation Conditions
Condition + Execution    | SWRL Rules or Production Rules
$n/$e Chained Traversal  | SPARQL Graph Pattern Queries
Inference Engine         | OWL Reasoner or Rule Engine
val/msg Receipts         | Engineering Execution Explanation & Audit Mechanism

This correspondence is mainly functional and architectural, not formal semantic equivalence. OWL reasoning emphasizes logical entailment, usually under open-world assumption; OntoL DSL includes property writes, execution order, timeout, failure returns, external functions, and replica states — engineering mechanisms. In particular, the .set() operation changes graph state, while pure logical reasoning typically only cares about which conclusions can be entailed, not treating side effects as core semantics. Therefore, a more accurate judgment is:

OntoL DSL is a business rule and action language for graph ontologies, absorbing ideas from ontology declaration, graph query, and production rules; the inference engine is an engineering executor of these declarations, not a formal logic system proven equivalent to an OWL reasoner.

Engineering Problems That Must Be Solved

Combining DSL with the inference engine significantly enhances system capabilities but also introduces a series of engineering problems that must be explicitly addressed:

1. Rule Cycles and Termination

If node A's update triggers node B, and node B reversely triggers node A, a cycle may form. The system must define maximum propagation depth, revisit strategies, rule trigger deduplication, and termination conditions, not relying solely on natural termination of relationship traversal.

2. Execution Idempotency and Transactions

Does repeated execution of the same rule produce the same result? Can inventory deduction, state transitions, and similar operations be safely retried? How to maintain consistency when multiple rules modify the same property simultaneously? These require transaction, locking, versioning, or idempotency designs — not solvable by DSL syntax alone.

3. Separation of Definition and Runtime History

condition

and execution are relatively stable rule definitions; val/msg are often results of a specific execution. If everything is overwritten on the same node, history may be lost and concurrent overwrites may occur. A safer approach is to keep current summaries in standard fields while writing each execution to an independent log.

4. Type and Temporal Semantics

If graph properties are stored as strings, numeric conversion, null values, dates, time zones, and comparison rules must be explicit. Otherwise the same DSL expression may yield different results due to data format differences.

5. Confidence Cannot Replace Truth Value

confidence

and match_score can describe result credibility but cannot directly substitute logical truth values. The system must distinguish "conclusions necessarily entailed by rules", "conclusions LLMs consider possibly correct", and "facts confirmed by human review".

6. Execution Permissions and Side-Effect Control

When DSL supports write operations, dynamic functions, or external interfaces, it effectively gains business automation capability. Therefore permissions, parameter validation, timeouts, auditing, and replica isolation must be configured to prevent high-risk operations generated by LLMs from directly affecting production data.

These problems determine whether OntoL DSL and inference engine can evolve from demo-level capabilities into a stable production-grade rule platform.

Conclusion

The collaboration principle of OntoL's custom DSL and inference engine can be summarized in one sentence:

Use a property graph to carry the ontology, use standard fields to describe rules and their execution metadata, use DSL to declare conditions, actions, and graph traversals, and let the inference engine perform evaluation, derivation, propagation, write-back, and tracing on original data or sandbox replicas.

Here, DSL solves unified rule expression, the inference engine solves deterministic rule execution, standard fields solve full lifecycle rule management, graph relationships solve structural impact propagation, and replica and verification mechanisms solve simulation safety and knowledge credibility.

Thus OntoL's core is not merely "using a custom syntax to operate a knowledge graph" but an attempt to organize business knowledge, business rules, and business behaviors into the same executable ontology. Its ultimate value lies not in how many derived properties are generated, but in whether it can form an explainable, auditable, controllable chain:

Where facts come from
 → Why rules trigger
 → What the inference engine executed
 → What state changes occurred
 → Which objects were affected
 → Whether results are verified
 → Whether traceability and rollback are possible

Only when this chain is complete do DSL and inference engine truly transform from a combination of language and component into an ontology computing infrastructure that can support business decisions.