OntologyL_Cypher: First Ontology Language Custom-Built for Product-Driven Reasoning

Abstract

OntoL's self-developed OntologyL_Cypher (OLC) is China's first ontology language customized and optimized for an ontology product. It is generated by the ontology product through dialogue to address the biggest pain point in ontology implementation: incompatibility between different languages, while being compatible with mainstream ontology languages such as OWL2, SWRL, and SHACL. OLC is not a simple graph query extension, nor a new query language to replace SQL, Cypher, or SPARQL. Instead, it is a coordinating ontology language responsible for managing and scheduling underlying query commands like SQL and native Cypher, unifying the orchestration of multi-source data from relational databases (MySQL8, Oracle) and graph databases (Memgraph, Neo4j). After global optimization, it provides a unified reasoning context for the ontology inference engine, serving as the scheduling hub of the entire ontology reasoning pipeline. The "customization" targets the meta-model, inference engine, and implementation process of a specific ontology product (OntoL), not a storage engine, which determines its form and why it appears first in China.

I. Necessity of the First: General Query Languages Cannot Meet Ontology Product Needs

Industrial ontology deployment inherently involves a mix of multiple languages and data sources:

Structured business data such as ledgers, work orders, and version records are stored in MySQL8 and accessed via SQL.

Equipment associations, material hierarchies, and fault propagation topologies are stored in graph databases and traversed via native Cypher.

Semantic modeling and standard ontology exchange use SPARQL and the OWL family of standards.

Each language manages its own storage well, but none understands the global goal of ontology reasoning. A standalone SQL query does not know which axiom its results will participate in; a standalone Cypher query does not know it can join with MySQL fields for filtering. When hard-coded in business logic, scheduling becomes messy, preventing global cost optimization and unified control of reasoning scope, depth, and spatiotemporal constraints. When TBox ontology rules change, scattered SQL, Cypher, and business code must all be modified, making the pipeline nearly ungovernable.

The design goal of general languages is generality; they do not reserve semantic slots for a specific ontology product's inference engine. OWL2 handles modeling, SWRL handles rules, SHACL handles validation, SPARQL handles queries, but no language specifies which axioms to activate for a reasoning run, which direction the reasoning chain grows, where Allen interval constraints and DE-9IM spatial constraints attach, or in what cost order heterogeneous sub-queries execute. These are exactly the decisions ontology products face daily on the implementation front line.

OLC exists to fill this gap: it does not add another general query language on top, but provides the product with its own language , allowing product-level semantics to be written directly, understood by the engine, and executed by the optimizer.

II. Four Layers of Customization: What This Language Changes for the Product

To judge whether a language is "customized for the first ontology product," the key is whether it modifies the product's own semantic structure. OLC's customization spans four layers, deepening progressively:

Layer 1: Syntax built on usage habits. Syntax is compatible with standard Cypher; simple scenarios can be written directly in Cypher-style pattern matching, so engineers need not learn a new syntax from scratch. It also provides a STRICT_CYPHER strict mode: disabling coordination, multi-source, and reasoning capabilities reduces OLC to a regular Cypher executor, allowing existing graph workloads to run smoothly. Customization does not mean starting from scratch; it means letting this language land on the enterprise's existing skill stack.

Layer 2: Scheduling layer commands underlying instructions. OLC statements can embed and reference SQL and native Cypher, and explicitly know which data source each sub-query corresponds to: MySQL8 uses SQL, graph databases use native Cypher. OLC does not handle low-level data retrieval itself; it manages these sub-tasks: when to execute, how filter parameters are passed, how result sets are merged. This distinguishes it from an "enhanced Cypher": its role is command , not query execution .

Layer 3: Optimization layer oriented to ontology semantics. OLC holds TBox ontology metadata and multi-source statistics. The optimizer decomposes the entire coordination description, automatically pushing down filter conditions to the corresponding underlying languages: conditions suitable for relational databases are pushed to SQL, those suitable for graph topology to native Cypher, pulling only necessary data to the upper layer for join fusion, avoiding full data retrieval and in-memory stitching. The optimization basis is ontology rules and data distribution, not merely relational algebra equivalence transformations, which general multi-source query middleware cannot provide.

Layer 4: Reasoning layer defines inference boundaries. This is the deepest customization layer and the dividing line between OLC and all general query languages. In a single statement, it can specify which axioms to activate for this reasoning run, the direction of the reasoning chain, maximum reasoning depth, Allen temporal constraints, and DE-9IM spatial constraints. In other words, it governs the complete fact and rule scope of an ontology reasoning run; all underlying SQL and Cypher serve this reasoning goal. OLC decides which data layer fetches data, what is fetched, and how it is organized into the reasoning context.

Beyond these four layers, OLC does one more thing for the "ontology product" use case that does not exist in general languages: dialogue generation . OLC statements can be produced directly by the ontology product through natural language dialogue. Business users describe what they want to query or reason; the product turns that description into an executable, optimizable coordination statement. The most intuitive test of whether a language truly fits the product is whether the product can generate it itself.

III. Compatibility and Translation: Custom Languages Must Interoperate with External Ecosystems

First, connect the ecosystem. OLC is compatible with mainstream ontology languages including OWL2, SWRL, and SHACL. It does not require enterprises to discard existing ontology assets; existing semantic modeling results can continue to be used.

Second, draw clear translation boundaries. Simple query subsets that do not involve scheduling or reasoning can be translated to standard Cypher or SPARQL for integration with tools like Protégé and Stardog. However, OLC-exclusive directives responsible for scheduling sub-queries and controlling reasoning chains (e.g., INFER, FEDERATE) belong to coordination-layer control semantics; standard Cypher and SPARQL lack corresponding scheduling models and cannot be losslessly translated.

This is often misread as a defect, but it is an inevitable boundary of a customized language: if these directives could be losslessly expressed in standard languages, it would mean the language added nothing to ontology reasoning. The non-translatable part is precisely its value as an ontology product's dedicated language.

IV. Two Performance Tracks: Aligning with Native, and Global Optimization in Coordination Scenarios

OLC does not modify the execution kernels of MySQL or graph databases; it optimizes the global plan of multi-language coordinated scheduling, thus two tracks:

Strict mode. Pure graph queries only, without coordination scheduling, aiming to minimize overhead and align with native Cypher performance, ensuring smooth migration of existing workloads.

Ontology coordination reasoning mode. Its benchmark is the traditional approach, not a single SQL or Cypher: serially writing and manually scheduling SQL+Cypher in business code, stitching results, then feeding them to the inference engine. OLC perceives all data sources and ontology rules at compile time, performing predicate pushdown, task reordering, branch pruning, and reasoning result materialization. After long-term iteration, overall performance in ontology reasoning scenarios significantly outperforms fragmented script stitching.

The costs must be clear: cross-source scheduling incurs overhead; materialization accelerates reasoning queries but increases write-side maintenance costs; the optimizer relies on data source statistics, and statistical deviations degrade execution plan quality. A customized language's gains come from deep understanding of its own scenario, not from "being able to do everything."

V. Position in the OntoL Product System

In the entire OntoL pipeline, OLC sits at the coordinating hub:

Upstream: Receives document extraction results from OntoL-Manage, business messages, and external ontology inputs.

OLC coordination layer: Orchestrates SQL, Cypher, and other sub-queries, assigns them to MySQL8 and graph databases for execution, aggregates and fuses facts.

Output: Structured ABox fact sets fed into the OntoL inference engine for chained reasoning and axiom adjudication.

Downstream: Reasoning results handed to OntoL-Manage orchestration engine to drive business processes and automated adjudication.

Typical scenarios include ECN change impact reasoning, BOM compliance verification, and equipment fault root cause analysis. Business code no longer scatters large amounts of SQL and Cypher; instead, a single OLC coordination statement clarifies multiple concerns at once: which business tables to query, which graph relationships to fetch, which ontology rule set to activate, and what the spatiotemporal constraints are. All underlying queries are managed uniformly by OLC; when ontology rules change, modifications are concentrated in the OLC coordination description and TBox.

Conclusion

OntologyL_Cypher is China's first ontology language customized and optimized for an ontology product. It does not replace SQL or Cypher, nor does it need to: it stands one layer higher, managing and scheduling these languages, unifying coordination of multi-source data from MySQL8, graph databases, etc., performing global optimization based on ontology semantics, and serving as the unified orchestration entry point for the inference engine.

It appears first in China because Chinese ontology products first achieved industrial-grade usability of the full reasoning pipeline, which in turn demanded a language fully matched to the product's form. The key to being "first" is that it is the first language designed for a specific ontology product, generated by that product itself, and only fully valid within that product's reasoning pipeline ; merely being earliest in time is not enough.