OntoL 8.0 Unifies Temporal, Spatial, Derivation & Fission Ontologies in Single Graph Reasoning Engine

Version Positioning

OntoL 8.0 integrates four ontology types — temporal (M_TIME), spatial (M_SPACE), derivation, and fission — into a single graph reasoning engine. Reasoning no longer only answers "which relationship to follow" but also "at what time and place does it hold", "which branches should grow", and "what are all the real instances". This document targets product introduction, solution reporting, and customer demos, covering capabilities, deployment path, and current boundaries.

One-Sentence Summary

The reasoning engine can now operate in a "real spatiotemporal context", propagating results along ontology chains to every real instance.

Previous Limitation

Earlier ontology reasoning was a static traversal on a relationship graph: start point, path, rules, result. It knew how entities connected but not the time window or spatial scope of the inference, and it often saw only the first row when multiple instances existed.

Four Ontology Types and Their Roles

The four ontologies form a continuous capability from semantic constraints to instance expansion. The first two let reasoning understand real-world coordinates; the last two let reasoning push conclusions onto actual business objects.

Temporal Ontology (M_TIME): "When Does It Hold?"

M_TIME turns instants and intervals into comparable graph nodes. It supports Allen's interval algebra with 13 relations (before, meets, overlaps, starts, during, finishes, equals, and their inverses). The same comparison logic accepts ISO instants, start-end intervals, and external time perspectives.

Instants are treated as zero-length closed intervals; interval start/end points are comparable; cross-timezone inputs are unified before judgment.

Time perspective is passed via the reasoning API's time_context, supporting ISO instants or {"start":"...","end":"..."} intervals.

Temporal node configuration undergoes TBox validation at load time; illegal relation names, unparsable time values, and missing time sources block loading.

Spatial Ontology (M_SPACE): "Where Does It Hold?"

M_SPACE turns geometric objects into comparable graph nodes, supporting POINT, LINESTRING, POLYGON, MULTIPOLYGON, and bbox, expressible in WKT, bbox, or GeoJSON. Topological judgments cover within, contains, intersects, disjoint, touches, equals, covers, covered_by, etc.

Points, lines, polygons, and bounding boxes are parsed uniformly; geometry values support WKT strings, [minx,miny,maxx,maxy], and GeoJSON coordinates.

Spatial perspective is passed via the API's space_context; if the constraint node declares a CRS and the external perspective also declares one, inconsistency is treated as "no match" with an explicit warning, not a silent error.

Spatial nodes must be linked via the business node's R_HAS_SITE mounting edge; wrong direction or target type blocks loading.

Significance of Spatiotemporal Ontologies: From "Describing the World" to "Judging the World"

For business: time windows and spatial ranges become hard constraints on the reasoning chain, not just report filters; rule hits are traceable to specific periods and spatial objects.

For decisions: conclusions upgrade from "holds/does not hold" to "holds in what time, in what range, for which objects", matching real business questions.

For platform: description, constraint, and inference share one ontology; no need to stitch together a separate GIS, rule engine, or BI layer outside the knowledge graph.

Two Examples: From Scenario-Level to Instance-Level Validity

Example 1 — Time: Scenario has a global validity period, but work orders and reports inside have their own periods.

Approach A (pre-8.0): Twin subject → Scenario → Scenario binds a single global temporal interval (e.g., 2025-01-01 to 2027-12-31). All queries first pass this fence.

Effect: Queries outside the interval immediately deem the whole scenario inaccessible; permissions and scenario lifecycle can be bound together.

Limitation: It only represents the scenario's start/end, cannot constrain each business instance's independent validity. E.g., project cycle 2025–2027, but a test report valid only in H1 2026; the global interval cannot distinguish that the report has expired.

8.0 Approach: Scenario-level interval remains the first fence; simultaneously, reports, licenses, work orders carry their own M_TIME constraints set as instance-level ( derivation_scope=instance). Querying 2026-11-03 passes the scenario fence, but the H1 2026 report fails and its branch is excluded; a license expiring in 2027 continues inference.

Example 2 — Space: Scenario binds a large region, but outlets and devices each have their own service ranges.

Approach A: Twin subject → Scenario → Scenario binds a single global spatial range (e.g., East China region). First judge whether query point lies in East China.

Effect: Out-of-range requests are blocked at scenario level, controlling permissions, data boundaries, and query cost.

Limitation: Regional coverage ≠ every outlet covers the whole region. An outlet may serve only Shanghai Pudong; a device may be installed only in Suzhou Industrial Park. The global "East China" range cannot distinguish these instance-specific spatial conditions.

8.0 Approach: Scenario-level range remains the outer fence; outlets and devices carry their own M_SPACE constraints as instance-level. Query point in Pudong → only that outlet's branch continues; query point in East China but outside any outlet's range → scenario fence passes, instance constraint fails, inference explicitly blocks and gives spatial reason.

Common pattern: Approach A solves "can the whole scenario be queried"; 8.0 further solves "which instances in the scenario, at what time or range, can continue inference". The former is a master switch; the latter is business-level validity and range judgment.

Without spatiotemporal ontologies, the ontology is a relationship network; with them, it becomes a reasoning engine that can judge real business.

Derivation Ontology: Letting Reasoning Grow Branches

Derivation ontology addresses "what happens after a constraint is hit". When a business entity's associated temporal or spatial constraint matches the current perspective, the engine does not merely filter the entity; it pulls the associated formal entity branch into the replica and continues downstream reasoning.

This is the "derivation" in "derivation-fission": constraints become growth points, not just gates. Time and space constraints on the same target are AND-aggregated; any unsatisfied constraint discards the branch; when satisfied, the constraint node, mounting edge, and downstream branches enter the replica together, forming traceable derivation evidence.

Derivation modes: copy_targets (copy target branches), filter_existing (filter existing paths), both (both), controlled by derivation_mode on the constraint node.

Derivation nodes write provenance fields: ontoL_derived_from, ontoL_derivation_mode, ontoL_time_window_id, ontoL_space_region_id, enabling later traceback to which constraint, time window, or spatial region triggered it.

Scenario-level constraints act as "spatiotemporal fences"; instance-level constraints derive business entity branches; cross-scenario associations are blocked to avoid pulling other scenario assets into the current inference.

Fission Ontology: Letting Reasoning See Every Instance

Fission ontology solves the old "list problem only sees the first row". When a node binds a dynamic source and enables multi_instance.multi, a multi-row query result causes the first row to reuse the current replica, while each additional row generates an independent replica with a new snowflake ID and corresponding row data.

If follow is also enabled, downstream nodes replicate in the same quantity, giving each upstream instance a corresponding downstream instance; shared nodes without follow are deduplicated to avoid repeated inference. Single-node fission caps at 50 rows to keep inference scale controllable. multi decides "whether to expand by row"; follow decides "whether downstream follows proportionally"; both configured in ontoL_db_dynamic_source 's top-level multi_instance.

Database, dynamic API, and raw SQL sources unify under the same fission semantics; each row returned by the executor maps to an independent replica.

Fission failures use a tolerant strategy: SQL errors, API failures, or empty data retain the single node and record "not fissioned" reason in ontoL_impact_oneself, preventing silent pipeline interruption.

Single Pipeline: Four Ontologies Naturally Collaborate

8.0 does not spin up a separate spatiotemporal engine nor treat fission as an independent side task. All four ontology types complete within the existing four-step pipeline: pathfinding, axiom validation, cloning, chained inference. Customers need not learn a second operation mode; existing ontologies and rules require no migration.

Step 0 — Pathfinding: Find the Right Path First

Supports five modes: shortest path, weight-optimal, full-chain, minimum cost, maximum value. Full-chain mode restricts first-hop edge type then expands by level, suitable for "view all impacts from an entity" demos and troubleshooting.

Step 1 — Validation: Confirm Ontology Stands

Validates inheritance chain conflicts, spatiotemporal node TBox contracts, mounting edge directions, and ABox field quality. TBox non-compliance blocks loading; ABox field issues only diagnose, not block historical data en masse. Spatiotemporal perspective parsing failures and CRS mismatches surface here with explicit reasons.

Step 2 — Cloning: Bring Required Branches and Instances

Collects endpoints edge-by-edge, clones node-by-node and edge-by-edge. Spatiotemporal derivation branches are planned before cloning and merged during cloning; fission pre-expands at cloning stage, though Step 3 can still supplement fission with runtime data. Original graph remains read-only; replica nodes and edges use new snowflake IDs and trace back via ontoL_source_id.

Step 3 — Inference: Rules, Data Fetch, Fission, Cascading Block

Each replica node executes preconditions, dynamic data fetch, actions, then recurses downstream. Precondition failure or DSL error cascades block downstream, but traversal continues, still producing "blocked" edge cards to pinpoint which node, edge, or instance caused the issue.

Result is edge_card: source node, relation, target node, status, block reason. Spatiotemporal hit info, derivation branches, and fission instances appear in cards and replica statistics; inference yields not just pass/fail but "why, where, for which instances".

Why This Is Not "Just Adding a Few Fields"

Spatiotemporal and fission are 8.0 upgrade points because they change the engine's explanatory power and result shape. Four comparisons for direct customer use:

Time Semantics: Previously time conditions lived in SQL or rule strings; engine saw only boolean result. Now M_TIME participates as ontology node in validation and dispatch; time windows, interval relations, and hit reasons are traceable.

Space Semantics: Previously spatial judgment scattered in GIS scripts or report filters, disconnected from ontology chain. Now M_SPACE mounts to business entities via R_HAS_SITE; geometric topology judgment enters the same inference chain.

Branch Growth: Previously constraint hit only filtered; associated entities and downstream evidence did not auto-enter inference. Now derivation ontology pulls formal entity branches per instance constraint; constraint nodes and mounting edges enter replica as evidence.

Multi-Instance: Previously list sources took only first row or required external expansion. Now multi_instance expands by row; follow replicates downstream proportionally; single node max 50 rows.

Three Customer-Facing Soundbites

"Time is no longer a SQL condition; it's an ontology constraint that enters the replica."

"Space no longer requires a separate GIS; geometric judgment and business rules complete on the same chain."

"Lists no longer take only the first row; as many rows as exist, that many independently inferable instances exist."

Together, these give the engine true "business-level inference" shape: not answering whether a single rule holds, but answering for which instances, along which branches, in what time, in what region, it holds or blocks.

How to Explain to Customers

Three illustrative scenarios (not industry-bound); replace with customer's own entities, times, regions during demo.

Scenario 1: Validity Rules & Effective Windows

Customer asks "Is this rule still effective now?" Build policies, contracts, qualifications as M_TIME nodes; business entities mount via R_VALID_INTERVAL. At inference, pass current instant or query interval; temporal constraints that match let entity branches continue; non-matching branches filtered or blocked. Result cards explain which time window and relation drove the judgment.

Scenario 2: Regional Coverage & Spatial Affiliation

Customer asks "Is this object inside the target area?" Build plant zones, jurisdictions, service ranges as M_SPACE nodes; mount via R_HAS_SITE. At inference, pass WKT or bbox; spatial topology decides which entities enter branches. CRS mismatches surface explicit warnings, not seemingly correct results.

Scenario 3: One-to-Many Business Lists

Customer asks "How many total, and what are they?" Configure source node with multi_instance.multi; enable follow if downstream should expand together. Query returns N rows → replica contains N instances; each independently executes rules and data fetch; cards and replica stats directly answer count and list, not just first row.

Scenarios stack: e.g., "All qualified devices and their downstream work orders in a certain region and time window" combines spatial derivation, temporal derivation, and list fission. 8.0's value lies not in any single scenario's complexity but in these capabilities stacking on the same ontology chain.

Deployment Path (Six Steps)

Steps organized by actual pages and interfaces. Demo can start with "six-step launch", then expand on the two or three ontology types the customer cares most about; implementation follows sequentially.

01 Prepare Ontology Structure

In /ontology create M_TIME/M_SPACE nodes, fill time or geometry fields; business entities point to constraint nodes via R_VALID_INTERVAL (temporal) or R_HAS_SITE (spatial). Mounting edge direction must be business node → spatiotemporal node.

02 Configure Dynamic Sources

In /datamanage prepare database or dynamic API. Node's ontoL_db_dynamic_source selects one of db_sim, db_source, api_source; for list fission add top-level multi_instance: {"multi":"true","follow":"true"}.

03 Enable Scenario & Rules

In /prompt-manager open "Inference Config", enable scenario, check participating nodes and rules. Scenario-level spatiotemporal nodes act as fences; instance-level nodes derive business branches.

04 Create Inference & Choose Path

Enter /sandbox-wargame, click a node as start, another as target; click "▶ New Replica" to enter replica edit, choose shortest/weight-optimal/full-chain/min-cost/max-value mode, name replica and save.

05 Run Inference

On replica page click "▶ Re-infer" to execute pathfinding→validation→cloning→inference. For rule-only rerun on existing replica click "🔄 Re-infer"; to clear and re-clone click "🔄 Re-clone".

06 Interpret & Reuse

In right panel "Modify Steps" view edge cards and block reasons; toolbar "Entity Ontology / Derivation Ontology / Fission Ontology" stats expand temporal/spatial details; "🔍 Compare Diff" contrasts replica changes with original graph; confirm before deciding to apply.

Passing Spatiotemporal Perspectives

Sandbox page handles path selection, inference execution, and derivation/fission result viewing; time and space perspectives are passed via inference API. During demo or integration, include time_context and space_context directly in request body; no page changes needed. time_context examples: 2026-11-03T10:00:00+08:00 (single ISO instant, treated as zero-length interval) or {"start":"2026-11-01","end":"2026-11-30"} (interval; also accepts start/end object). space_context examples: POINT(120.15 30.28) (WKT point/line/polygon), {"bbox":[120.0,30.0,120.5,30.5]} (bbox; also accepts [minx,miny,maxx,maxy]), {"wkt":"POLYGON((...))","crs":"EPSG:4326"} (with CRS; checked against constraint node's space_crs for consistency).

Corresponding APIs: POST /api/v1/reasoning/run, /api/v1/cope-versions/{cope_id}/infer-by-mode, /reclone. For read-only fact queries use /api/v1/reasoning/fact-query (no replica created).

Fission Configuration Example

Recommended to place multi_instance at top level of ontoL_db_dynamic_source, alongside source config. Minimal example (adjust fields per data source catalog); props direction is "ontology field → result column".

{
  "db_sim": {
    "db_code": "your_db",
    "table": "your_table",
    "filters": [
      {"field": "region_code", "op": "eq", "value": ":region_code"}
    ],
    "props": {"device_code": "device_code", "device_name": "device_name"},
    "multi_instance": {"multi": "true", "follow": "true"}
  }
}

Note: :region_code takes value from current node properties first, then upstream node; multi-row results fission by row, single node max 50 rows. Database, dynamic API, and raw SQL cannot be mixed; each node picks one source.

Capability Boundaries & Demo Notes

Promotional version does not hide boundaries. Proactively clarify these in pre-sales Q&A to reduce later "why not like demo" rework.

Spatiotemporal perspectives currently enter via inference API; sandbox page handles execution and interpretation, no independent spatiotemporal perspective input panel; demo via API integration or pre-set requests.

Scenario-level spatiotemporal constraints are fences; instance-level constraints derive business entity branches; cross-scenario associations are intentionally blocked, not a capability gap.

Spatial geometry uses lightweight algebra for topology judgment, suitable for pre-inference filtering; no projection transformation, buffer analysis, or large-scale GIS computation; complex spatial analysis still delegated to professional GIS.

Fission single-node max 50 rows; external dynamic data source multi-row fission has known limitations in draft inference; report "not included" honestly, do not claim pass.

Temporal nodes require parsable time values and legal relation names; spatial nodes require parsable geometry and correct mounting edge direction. These are hard load-time constraints; incomplete config causes explicit block, not sick inference.

Inference writes only to replica space; original graph is read-only; replica diffs require explicit "Apply to Original Data" to persist. Do not say "replica fixed" equals "production assets updated".

Suggested Demo Flow

Start with the four-ontology capability diagram to show "what's added"; then use derivation/fission diagram to show "how they grow"; finally run a full inference in sandbox: choose path, run inference, view cards, expand derivation/fission stats. Keep within 15 minutes; more memorable than walking through configs.

If customer asks "Can we do only temporal without spatial?" Answer: yes — both constraints configure independently, validate independently; only when both configured on same target do they AND-aggregate. Derivation and fission can also be enabled separately; no prerequisite that all four must be used together.