OntologyL_Cypher 2.0: Temporal, Spatial & Path Reasoning for Ontologies

Introduction

OntologyL_Cypher 2.0 is the next-generation ontology rule language for OntoL-Manage. It unifies time, space, relations, and context passing into a single chain expression that is readable, executable, and auditable, so business rules no longer scatter across scripts, SQL, and verbal conventions.

In one sentence: version 1.0 made ontologies queryable; version 2.0 makes them reasonable.

Business Problems Addressed

Does this work order fall within its validity window?

Is this measurement point located inside the current work area?

Can the chain from floor to room to point be traversed completely?

How are codes collected along the chain passed to the next business data fetch?

How do intermediate values produced during reasoning stay intact, not get mixed up, and not rely on implicit conventions?

Core Capabilities as First-Class Citizens

Temporal ontology: 13 Allen relations + timeSpan(...) interval construction.

Spatial ontology: geometry(...) + intersects(...) based on DE-9IM.

Time ontology: Business time fields directly participate in instant, interval, validity, and closed-interval judgments.

Path reasoning: path(...) supports shortest path, relation priority, and explicit relation chains.

Parameter passing: $field, pass_value(...), pass_values(...), path_value(...) form a complete data relay.

Deterministic execution: Conditions only judge; execution fetches and writes; fail-fast with Chinese reasons.

Important Boundary

The temporal/spatial/time ontology upgrades are semantic-layer capabilities, not new mounted ontologies like M_TIME or M_SPACE. Time, validity, WKT, bbox, and coordinates remain ordinary business fields; spatiotemporal judgments are performed by DSL methods. This preserves model simplicity while keeping rules directly executable.

Why 2.0: From Point Judgments to Spatiotemporal Chains

Traditional graph queries answer "who connects to whom", but real business asks:

Business Problem              Traditional Approach                    2.0 Approach
Validity covers query window  Code date comparisons                 timeSpan(...).timeContains(...)
Work area intersects device   GIS scripts or DB extensions          geometry(...).intersects(...)
Multi-level chain complete    Multiple queries, app-layer stitching path(...) single expression
Chain fields to next step     Temp variables, context objects, implicit conventions  path_value(..., targetParam)
Why rule holds                Read logs, guess code                 Chinese semantic messages + reasoning cards

2.0 does not merely stuff more functions into the language; it puts business semantics into the language:

Time is no longer just a string.

Space is no longer just latitude/longitude fields.

Relations are no longer two separate queries.

Intermediate values no longer depend on external variables.

The reasoning process can be explained, reviewed, and audited.

Three Leaps

Leap 1: Temporal Ontology — Native "Before, Overlap, Contain" Expressions

OntologyL_Cypher 2.0 embeds 13 Allen relations covering the most common interval judgments:

DSL Method        Allen Relation   Business Meaning
timeBefore        before           Before
timeMeets         meets            Meets
timeOverlap       overlaps         Overlaps
timeStarts        starts           Same start
timeBetween       during           During
timeFinishes      finishes         Same end
timeEquals        equals           Equals
timeFinishedBy    finished_by      Finished by
timeContains      contains         Contains
timeStartedBy     started_by       Started by
timeOverlappedBy  overlapped_by    Overlapped by
timeMetBy         met_by           Met by
timeAfter         after            After

Combined with timeSpan(start, end), two ordinary business fields instantly form a decidable interval.

Example: Work Order Validity Covers Query Window

timeSpan(valid_to).timeContains(query_end)

Product Semantic Details

Date-only precision: interval end covers to 23:59:59 of that day. timeBetween / timeContains use closed-interval semantics.

Missing fields, invalid dates, or invalid intervals do not silently become "no match"; they fail-fast with Chinese reasons.

Value: Validity, scheduling windows, maintenance cycles, contract periods, event overlaps — no external date libraries or scattered if/else.

Leap 2: Spatial Ontology — "Where, Intersect" Directly in Rules

2.0 provides geometry construction and DE-9IM intersection judgment: geometry(dispatch_area).intersects(...) Supported operands:

WKT: POINT (...), POLYGON ((...)), etc.

BBox: [minx, miny, maxx, maxy] GeoJSON

Business geometry text fields $ dynamic parameters

Value: Park, factory, work face, delivery range, equipment location, patrol area — spatial rules share the same expression with business rules, no GIS service or frontend script split.

Leap 3: Time Ontology — Business Time Fields as First-Class Operands

2.0 does not require a dedicated "time ontology" for temporal judgments. Work order creation time, equipment commissioning time, contract validity, batch inspection time — all participate directly:

timeBefore(work_order.create_time, $cutoff)

timeSpan(valid_to).timeOverlap(query_end)

Time expression operands can come from:

Current chain value

get(business_time_field)

$field

dynamic parameters

Date/time literals

Interval objects in start/end or from/to form

Value: Time semantics no longer rely on field naming conventions or virtual nodes. Business fields are consumed directly.

Path Reasoning: From "Query an Edge" to "Explain a Chain"

Three Path Syntaxes

Syntax                                    Semantics                                      Applicable Scenario
path(floor->room->point)                  Each hop unconstrained, unique shortest path     Exploratory chains, clean topology
path(floor->room->point, R_CONTAINS)      Each hop prefers specified relation, fallback    Business relation priority, allow fallback
path(floor-[R_CONTAINS]->room-[R_CONTAINS]->point)  Each hop strongly bound, missing fails   Strong constraint chains, high audit

Execution Semantics

In ontoL_execution, hitting path(...) launches additional chained reasoning in the same replica space, waiting for events and cards before continuing the original expression and main reasoning. path(...) in condition fields only does read-only query or boolean judgment, not triggering additional reasoning. This means:

Chain reasoning never silently switches replica versions.

Intermediate results share the same business context as main reasoning.

Every edge's condition, execution result, and block reason are traceable.

"Chain exists" and "chain produced what" can be expressed separately.

Condition: Chain Exists and Count Satisfies

path(floor->room->point).count() >= 1

Execution: Aggregate Readings Along Chain

path(floor->room->point).sum(energy_reading)

Value: Chains not only answer "which endpoints reached", but bring edges, nodes, cards, and semantic explanations into business conclusions.

Parameter Passing: Safe Context Relay in Chains

This is 2.0's most underestimated yet modeling-experience-changing capability.

Layer 1: $field — Unified Dynamic Parameters

$field

is the sole dynamic parameter syntax: db_sim(ERP, energy, {"point_code": $point_code}, F) Rules:

Bare $field is a dynamic value.

Quoted "$field" or '$field' is a string literal, not a parameter.

JSON params written directly as {...}, empty object as {}.

Chain-head functions read from current node's graph object.

Non-chain-head functions read only previous result, never fall back to graph object, avoiding implicit value mixing.

Missing value fails-fast; null not treated as business conclusion.

Layer 2: pass_value / pass_values — Explicit Transfer

When a value must relay across multiple functions:

pass_value($source_field, target_field)

pass_values(($source_field1, target_field1), ($source_field2, target_field2))

Conventions:

Source field prefixed with $.

Target field bare, no $.

Subsequent functions read via $target_field. pass_values for multiple values, reducing intermediate field pollution.

Example: Store Then Use in Subsequent Fetch

pass_values((meter_no, meter_no)).db_sim(ERP, reading, {"point_code": $meter_no}, F)

Layer 3: path_value(...) — Collect and Pass Per Hop

path_value

does not just take the path endpoint; it collects field values hop-by-hop along the entire chain, solving "path connected but how to pass intermediate node values to next action".

Syntax                                                    Semantics                                      Returns
path(floor->room->point).path_value(energy_reading)       Read previous path(...), collect per hop           Array
path_value(floor->room->point, energy_reading)            Find path from current node, collect per hop       Array
path_value(floor->room->point, energy_reading, readings)  Collect and bind array to target param             {readings: [...]}

Example: Chain Value Collection

path_value(floor->room->point, energy_reading)

— returns readings in floor→room→point order.

Example: Chain Parameter Passing

path_value(floor-[R_CONTAINS]->room-[R_CONTAINS]->point, point_code, point_codes).db_sim(ERP, energy, {"point_code": $point_codes}, F)

— collect point codes along chain, pass array to business fetch.

Fail-Fast Rules

Path not found, ambiguous, missing explicit relation: fail-fast.

Chain node missing target field: skip node, note skip count in message.

All nodes missing target field: return False with Chinese reason, no fabricated empty result.

Target parameter must be bare field name; $readings explicitly rejected.

Condition fields may use path_value(...).count() > 0, but data actions only allowed in ontoL_execution.

Why It Matters

Previously, chain intermediate values relied on:

Application-layer temporary variables.

Manual stitching after multiple queries.

Conventions that a node must carry a field.

Stuffing context into global state.

Now the chain itself produces consumable parameters:

Chain -> per-hop collect -> bind target param -> subsequent fetch/judge continues

This closes the loop on "chain reasoning": not only judge existence, but bring chain business data into next calculation.

Complete Expression Examples (Grouped for Display)

DSL expressions stay one line in system fields; grouping below illustrates distinct capabilities.

Time ontology — validity covers window: timeSpan(valid_to).timeContains(query_end) Temporal ontology — two intervals overlap: timeOverlap(maintenance_end, query_end) Spatial ontology — geometry intersects work area: geometry(dispatch_area).intersects(...) Path reasoning — strong constraint path complete:

path(floor-[R_CONTAINS]->room-[R_CONTAINS]->point).count() > 0

Chain parameter — collect point codes, pass to business fetch:

path_value(floor-[R_CONTAINS]->room-[R_CONTAINS]->point, point_code, point_codes).db_sim(ERP, energy, {"point_code": $point_codes}, F)

Parameter transfer — pass upstream result explicitly:

pass_values((meter_no, meter_no))

Capability Matrix

Domain                2.0 Provides                                    Business Benefit
Chain query           n(...)/r(...)/get/filter/agg/sort/group         Single expression for graph object filter & compute
Temporal ontology     13 Allen relations, timeSpan(...)               Validity, windows, overlap, contain directly decidable
Time ontology         Business time fields, instant/interval literals, closed intervals  Time rules without virtual nodes
Spatial ontology      geometry(...), intersects(...), DE-9IM          Region, range, location relations in business rules
Path reasoning        path(...) three modes, replica-internal reasoning  From "reach endpoint" to "explain whole chain"
Parameter passing     $field, pass_value, pass_values, path_value     Intermediate values relayable, reusable, auditable
Dynamic fetch         db_sim / db_query / func / mcp                  Direct data source, API, tool integration in rules
Execution governance  Condition/execution separation, fail-fast, Chinese messages, reasoning cards  Rules explainable, reviewable, traceable
AI generation         Unified prompt & method registry; model emits default OntologyL_Cypher 2.0  Reduce syntax drift from model hallucination
Compatibility         1.0 expressions valid, method table incremental  No forced rewrite of existing ontology assets

Current method registry: 52 methods, maintained with "method table -> dispatch table -> prompt -> user doc -> contract test" single-source.

Differences from Generic Graph Query

Dimension               Generic Cypher / Scripts          OntologyL_Cypher 2.0
Time judgment           DB functions or app code          13 Allen relations built-in
Spatial judgment        GIS extensions or external svc    geometry / intersects direct
Chain value fetch       Multiple queries, app stitching   path_value per-hop collect & pass
Parameter scope         External vars, call conventions   $field explicit chain-head/chain-mid rules
Business semantics      Scattered in code comments        Expression + Chinese msg + reasoning cards
Failure semantics       Null, empty array, exception mixed  Fail-fast; empty result explicitly []
AI generation           Dialects, SQL concatenation       Method registry constrains generation boundaries

Applicable Scenarios

Manufacturing quality & process: Process parameters in valid window? Batch inspection overlaps production interval? Production line → station → detection point chain complete? Collect detection codes along chain for quality data fetch.

Energy & equipment maintenance: Maintenance validity covers current window? Work area intersects equipment geometry? Floor → room → point reachable? Collect point codes along chain, batch fetch energy readings.

Supply chain & batch traceability: Batch validity, inspection time, in/out warehouse temporal relations; multi-level supply strong constraint paths; intermediate batch numbers, material numbers passed downstream; deterministic break on broken chain, ambiguous path, missing field.

Asset & park management: Asset location intersects responsibility region; contract, lease, patrol interval judgments; asset hierarchy chain integrity & aggregation; pass asset codes from chain to ledger or work order system.

Upgrading from 1.0 — No Rewrite Required

2.0 upgrade strategy: incremental extension, backward compatible.

1.0 chain expressions remain valid.

Existing ontology assets and reasoning configs need no rewrite due to version change.

New capabilities extend method table, dispatch table, prompts, docs in sync.

Spatiotemporal semantics converge to default DSL methods; no independent prefix language for model generation.

Old prefixes kept only for runtime compatibility, not as new rule generation targets.

Teams can adopt 2.0 scenario by scenario:

First use timeSpan / timeXxx in time window and validity rules.

Then use geometry / intersects in region and range rules.

Then use path / path_value in multi-level business chains.

Finally migrate rules with many intermediate values to pass_value / pass_values, reducing implicit context.

Design Principles: Writable, Readable, Executable, Auditable, Reasonable

Writable: Chain syntax keeps one expression per task; business people can read, models generate stably.

Readable: Method names map directly to business semantics: timeBetween, timeOverlap, intersects, path_value — no need to understand underlying graph query dialect.

Executable: Push down to Cypher where possible; deterministic Python evaluation for the rest; conditions only judge, execution fetches and writes.

Auditable: Every execution returns (val, msg): value, why it holds, why blocked, how many nodes skipped — all in Chinese semantic records. Reasoning engine organizes them into cards and chain conclusions.

Reasonable: path(...) with path_value(...) lets chains produce consumable context; replica isolation guarantees reasoning does not pollute original graph.

Conclusion

OntologyL_Cypher 2.0 is more than a version number. It represents a capability shift for the ontology platform:

From "field queryable" to "business reasonable".

From "relation connected" to "chain explainable".

From "rules in code" to "rules in ontology".

From "model generates a query" to "model generates verifiable, executable, auditable business semantics".

When temporal, spatial, time, and chain enter one language, ontology truly becomes business reasoning infrastructure.

Version: OntologyL_Cypher 2.0<br/> Document Date: 2026-11<br/> Note: Specific methods, parameters, and runtime behavior subject to deployed method_registry, executor, and product specification.