OntologyL_Cypher 1.0: Executable Ontology Functions for AI and Complex Business

One Chain Completes a Business Judgment

Traditional approaches break a seemingly simple business question into multiple steps: query the graph, filter, aggregate, compare, and write back. In OntologyL_Cypher, the same logic can be expressed as a single chainable expression: path(楼层->房间->测点).sum(能耗读数) Starting from the current node, the expression follows ontology relationships to target objects, then aggregates over terminal instances. Path traversal, relationship binding, and failure handling all have defined semantics. The language feels like jq but understands ontology natively.

The language provides 49 methods covering query, filter, traversal, aggregation, collection, date, spatio-temporal, data retrieval, external calls, and write operations. Key method groups include: n(...) / r(...) – enter from graph objects get(...) / has(...) – read and judge filter(...) / order_by(...) / limit(...) – narrow results next_n(...) / prev_n(...) – traverse along relationships path(...) – find paths by ontology type chains count/sum/avg/max/min/group_by – perform aggregations set/remove/detach/empty – execute write actions

These methods are not a piled toolbox but a convergent, readable, auditable, and generatable expression style for common ontology functions.

Built for AI, Not Guessing

Large language models excel at generating language, but enterprises fear "generates plausibly, fails at execution." OntologyL_Cypher assumes the author may be an AI from day one. The method table serves as a single source of truth: parameters, terminal states, condition availability, and return shapes are uniformly registered. Prompts, documentation, validators, and executors share the same contract. The model does not need to remember multiple whitelists, nor can it hallucinate in gaps between documentation and executor.

Crucially, it adopts fail-fast semantics. Missing fields, null values, empty collections, parsing errors, and execution errors never silently return a "plausible" result; they return explicit failure semantics. Every expression uniformly returns:

DSLResult(val, msg, current)

val

provides a decidable result, msg gives a Chinese explanation, and current retains the current object for downstream chaining. This means reasoning cards know why a conclusion holds, block logs know why it failed, and business users know what the system actually did. AI can write, the system can catch, and humans can understand. This is closer to the intelligence enterprises truly need than "let the model write code and see."

Native Ontology Semantics in Functions

General-purpose languages can express anything but may not understand your ontology. OntologyL_Cypher natively understands OntoL-Manage's four groups of ten ontology types, 13 basic relationships, and system field specifications. It treats types, relationships, primary keys, and replica versions as language primitives, not mere strings. It knows:

Nodes and relationships each carry system semantics ontoL_snowflake_id is the graph primary key, not a database internal ID

Replica deduction must be confined to the same ontoL_copy_version Condition fields only judge; execution fields allow writes path(...) in conditions is read-only query; in execution it can trigger same-replica supplementary deduction

Aggregation can hit all instances along a path, not just the first

Therefore, it is not merely a "query language" but an ontology function language that turns ontology from a modeling artifact into callable business capabilities.

Spatiotemporal, Data Access, and Actions in One Chain

Real business never occurs only on static graphs. A judgment may need a time window, an action may need a spatial range, a conclusion may need a database, dynamic API, or MCP tool. OntologyL_Cypher places these capabilities within the same language boundary:

13 Allen temporal relations – covering precedes, meets, overlaps, contains, equals, follows, and full interval semantics

DE-9IM spatial predicates – supporting intersects, contains, covers, equals, and other topological relations

db_sim / db_query – direct data access; SQL is read-only with parameter binding, not string concatenation

func / mcp – call external interfaces and MCP tools, with explicit distinction of whether they fork

Condition–execution separation – capabilities with side effects cannot mix into judgment fields

This means an ontology function can perform an entire business action chain:

Data retrieval → Validation → Judgment → Aggregation → Write → Deduction

Every step runs under the same semantics, same logs, and same failure rules.

The Missing Piece for the Reasoning Engine

The reasoning engine decides "who to deduce first, along which path"; OntologyL_Cypher decides "does this node, this relationship hold, what does it compute, what does it write." The two are not competitors but collaborators. When path(...) appears in an execution field, the reasoning engine can launch additional chained deduction within the same replica, waiting for events and cards on the path to return before continuing the main deduction. The path is not an arbitrary query but part of the deduction chain. In condition fields, path(...) remains read-only, only querying or boolean judging, without altering deduction order. This is OntologyL_Cypher's sense of proportion: compute what should be computed, query what should be queried, wait what should be waited, block what should be blocked. It avoids stuffing all logic into a single large model or writing all rules as scripts, letting the language, reasoning engine, and replica space each do their job.

From "People Finding Data" to "Ontology Giving Answers"

OntologyL_Cypher already serves as the function layer in OntoL-Manage's core pipelines:

Data quality analysis – turns field rules into decidable conditions

Sandbox deduction – aggregates, validates, blocks, and writes back along paths

Automatic workshop – lets AI-generated drafts be deterministically executed

Scenario dialogue – grounds natural language business judgments onto graph objects

Upload import and ontology exchange – brings external semantics into the same execution contract

It does not require business users to learn a general-purpose programming language, nor does it require AI to reinvent query logic on every response. It provides a stable middle layer: above, it connects natural language and agents; below, it connects graph databases, business databases, and external systems; in the middle, ontology semantics align both sides.

Not Another General-Purpose Language, but an Ontology Function Layer

General-purpose programming languages have their battlefield: complex algorithms, large-scale engineering, ecosystem integration. Ontology function languages have their own mission: make business semantics executable, make AI generation controllable, make reasoning processes explainable. OntologyL_Cypher 1.0 chooses the latter. It uses one chain to connect objects and actions; one contract to connect models and systems; one explainable result to connect computation outcomes and business judgments. Let ontology be not just a knowledge graph, but an executable business brain.

OntologyL_Cypher 1.0 Capability Overview

Ontology-native – nodes, relationships, types, primary keys, replica versions enter language semantics

Chainable expressions – one expression completes filtering, traversal, aggregation, judgment, and writing

AI-friendly – method contract as single source of truth; prompts and executors synchronized

Fail-fast – nulls, exceptions, illegal inputs return explicit Chinese reasons

Spatiotemporal unified – 13 Allen temporal relations + DE-9IM spatial topology

Data and action integration – db_sim, db_query, func, mcp unified access

Reasoning collaboration – path(...) supports same-replica supplementary deduction and read-only condition judgment

Explainable – DSLResult(val, msg, current) simultaneously yields result, semantics, and context