An ontology semantic data network modeling method and system for AI native

Abstract

This application provides a method and system for modeling AI-native ontology semantic data networks. The method includes the following steps: constructing an ontology model layer, including defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein the ontology classes include entity classes and event classes, and the CBC strategies include context dimensions, behavior dimensions, and constraint dimensions; constructing a behavior implementation layer, wherein each behavior is associated with a specific execution implementation; and constructing an instance network layer, wherein ontology instances automatically inherit all the CBC strategies of their respective ontology classes. This technical solution addresses the problem of separating data models, business logic, and execution engines in traditional solutions.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method and system for modeling ontology semantic data networks native to AI. Background Technology

[0002] In the process of enterprise digital transformation and AI application implementation, existing data modeling methods face the following prominent problems:

[0003] 1. Traditional ontology and knowledge graphs (such as OWL / RDF) lack behavioral modeling capabilities. Existing ontology standards (such as OWL and RDFS) excel at describing the classification hierarchy and attribute constraints of concepts, but they are merely pure "data models" and cannot express dynamic business logic such as "what operations can be performed in what context and what rules need to be followed." When faced with such ontology, AI agents can only perform static data queries and cannot understand and securely execute business operations.

[0004] 2. The "black box" nature of business rules in enterprise systems. In traditional enterprise systems (ERP, MES, CRM, etc.), business rules are translated by programmers into if-else logic and deeply embedded in the application codebase. These rules are completely invisible to AI agents—AI cannot know that "job transfer" requires checking rules such as "performance rating," "years of service," and "departmental staffing," because these rules are scattered across different functions in different systems. AI either has no way to proceed or risks performing high-risk operations, compromising data consistency and business compliance.

[0005] 3. The data model and execution engine are tightly coupled. The definition of objects, the expression of relationships, the validation of constraints, and the execution of behaviors are scattered across different technology stacks (databases, middleware, application servers), lacking a unified semantic layer to connect them. When AI agents need to automate business operations across systems, adaptation code must be written separately for each system, making it impossible to achieve universal semantic interaction.

[0006] 4. Lack of AI-native business rule expression methods. While existing system constraint expressions (such as database check constraints, SHACL shape constraints, and OWL axioms) are effective within their respective technology stacks, they all use machine-specific formal languages. Large Language Models (LLMs) cannot directly "read" and "understand" the business meaning of these rules. This prevents AI agents from autonomously assessing compliance before executing business operations, reducing the credibility of AI in enterprise scenarios.

[0007] 5. Lack of standardization in the connection between AI agents and external tools and services. As AI agents need to interact with more and more external systems, how to standardize the discovery, connection, and invocation of these capabilities has become a key challenge. Existing solutions mostly use hard-coded API integration, lacking a unified behavior discovery and secure invocation mechanism for AI. Summary of the Invention

[0008] This application provides a method and system for modeling ontology semantic data networks native to AI, which solves the problem of separation of data model, business logic and execution engine in traditional solutions.

[0009] Firstly, a method for modeling ontology semantic data networks native to AI is provided, including the following steps:

[0010] Constructing the ontology model layer includes defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein, the ontology classes include entity classes and event classes, and the CBC strategies include context dimension, behavior dimension and constraint dimension;

[0011] Construct a behavior implementation layer, where each behavior is associated with a specific execution implementation;

[0012] Construct an instance network layer where ontology instances automatically inherit all the CBC strategies described in their respective ontology classes.

[0013] In the above technical solution, an ontology model layer is constructed, including defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein the ontology classes include entity classes and event classes, and the CBC strategies include context dimensions, behavior dimensions, and constraint dimensions; a behavior implementation layer is constructed, wherein each behavior is associated with a specific execution implementation; an instance network layer is constructed, wherein ontology instances automatically inherit all the CBC strategies of their respective ontology classes; this solves the problem of separation between data model, business logic, and execution engine in traditional solutions.

[0014] In one specific implementation, the scenario description, behavior description, and constraint rules in the CBC strategy are all in natural language form, which is used by the AI ​​agent to directly read and understand the natural language description in order to understand the business rules.

[0015] In one specific implementation scheme, the behavior implementation layer includes traditional IT implementation and AI-native implementation.

[0016] In one specific implementation, the traditional IT implementation includes program code functions and API calls; the AI-native implementation includes Agent workflow, MCP service, A2A collaboration, and Skills package.

[0017] In one specific implementation, the event class is used to describe dynamic business activities and together with the entity class constitutes a process network; wherein, the business activities include process execution, quality inspection, and assembly.

[0018] In one specific implementation scheme, in addition to defining the source ontology class and the target ontology class, the relation class can also independently attach attribute definitions and the CBC strategy, making the relation class an independent semantic entity that can carry information and rules.

[0019] In one feasible implementation, the instance inheritance mechanism enables changes to the CBC strategy of the ontology model layer to be automatically propagated to all corresponding ontology instances without requiring individual instance modifications.

[0020] In one specific implementation, the AI-native implementation of A2A collaboration supports AI agents in publishing capability descriptions through the AgentCard mechanism and in discovering, delegating, and coordinating the execution of tasks with external AI agents through standardized communication protocols.

[0021] Secondly, a native AI-based ontology semantic data network modeling system is provided, including:

[0022] The model layer management module is used for defining and managing ontology classes, relation classes, and CBC strategies.

[0023] The instance network layer management module is used for instance creation and inheritance linkage;

[0024] The behavior implementation layer management module is used for registration and routing of traditional IT implementations and AI-native implementations.

[0025] In the above technical solution, an ontology model layer is constructed, including defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein the ontology classes include entity classes and event classes, and the CBC strategies include context dimensions, behavior dimensions, and constraint dimensions; a behavior implementation layer is constructed, wherein each behavior is associated with a specific execution implementation; an instance network layer is constructed, wherein ontology instances automatically inherit all the CBC strategies of their respective ontology classes; this solves the problem of separation between data model, business logic, and execution engine in traditional solutions.

[0026] In one specific implementation scheme, it also includes:

[0027] The CBC engine module is used to automatically perform scenario and constraint verification before the behavior is executed;

[0028] The AI ​​interaction module is used to realize the read-understand-write closed loop of the AI ​​agent. Attached Figure Description

[0029] Figure 1 A flowchart illustrating the AI-native ontology semantic data network modeling method provided in this application embodiment;

[0030] Figure 2 This is a structural block diagram of an AI-native ontology semantic data network modeling system provided in an embodiment of this application. Detailed Implementation

[0031] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. Through these descriptions, the features and advantages of the present application will become clearer and more apparent.

[0032] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0033] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other. The following detailed description, in conjunction with specific accompanying drawings, illustrates the embodiments.

[0034] In order to accurately define the technical scope of this application, the core terms are defined and explained as follows:

[0035] 1. Ontology Semantic Data Network (ONN): A computable semantic network data structure with ontology classes as nodes, semantic relation classes as edges, and a CBC (Contextualized Business Layout) pattern as the unified logical kernel. ONN consists of three layers: the ontology model layer (defining object classes, relation classes, and their CBC strategies), the instance network layer (storing specific instance data and automatically inheriting the CBC strategies from the model layer), and the behavior implementation layer (associating semantic behaviors with specific execution implementations). The term "network" specifically refers to the semantic graph topology structure composed of ontology classes, relation classes, instance nodes, and their attributes and strategies, rather than a deep learning parameterized model based on artificial neuron weights and backpropagation algorithms.

[0036] 2. Ontology Class (OC): An abstract type definition for business objects in the ONN model layer; it serves as a "template" or "blueprint" for things. Each ontology class contains: a class identifier, a classpath, a set of attribute definitions, a semantic boundary description, and a set of associated CBC strategies. Ontology classes are divided into entity classes (Nouns, describing static objects such as equipment and personnel) and event classes (Verbs, describing dynamic activities such as process execution and quality inspection).

[0037] 3. Link Class (LC): An abstract type definition of business relationships in the ONN model layer. Each link class contains: a source ontology class, a target ontology class, a relationship cardinality (one-to-one / one-to-many / many-to-many), relationship constraints, and optional attribute definitions. Link classes are not merely simple "connections"; they can also be equipped with independent attributes and CBC strategies, becoming computable semantic entities.

[0038] 4. CBC Pattern (Context-Behavior-Constraint): The unified logical core of ONN, endowing each ontology class and relation class with context awareness, behavior execution, and constraint governance capabilities. Its three dimensions are: Context defines the environmental boundaries and preconditions for behavior and constraint to take effect; Behavior defines the callable operations that encapsulate business logic, described in natural language for easy understanding by AI agents; and Constraint defines the business rule checks that must be passed before executing a behavior.

[0039] 5. Policy (Pol): The carrier unit of CBC patterns. A policy contains a complete set of three-dimensional CBC definitions (contextual conditions, behavioral descriptions, and constraint rules), which can be associated with one or more ontology classes or relation classes. The contextual, behavioral, and constraint descriptions in the policy are in natural language, which AI agents can directly read and understand without reverse engineering the program code.

[0040] 6. Behavior Implementation Layer: This layer acts as an "execution bridge" connecting the ONN semantic world with the enterprise's existing IT and AI capabilities. Each behavior in the strategy is described in natural language at the semantic layer (for easy AI understanding) and can be associated with one or more specific implementations. Implementations are divided into two categories: traditional IT implementations (program code functions: executed directly within the platform; API calls: driving external microservices or enterprise applications such as ERP and MES) and AI-native implementations (Agent workflows: triggering AI agents to complete complex tasks; MCP services: connecting external tools and data sources via model context protocols; A2A collaboration: coordinating execution with other AI agents via inter-agent communication protocols; Skills packages: predefined, reusable AI capability modules).

[0041] 7. Instance Inheritance: The core mechanism in the ONN instance network layer. Each ontology instance (OI) automatically inherits all CBC strategies defined in the model layer of its parent ontology class, eliminating the need for redefinition. When the CBC strategy in the model layer changes, the change is automatically propagated to all corresponding instances.

[0042] 8. AI-Native Read-Write Loop: ONN's unique AI interaction mode. The AI ​​agent can achieve a complete "read-understand-write" closed loop in ONN: read CBC natural language descriptions to understand business rules, make inferences and decisions based on understanding, and securely invoke rules-protected behaviors to execute business operations.

[0043] exist Figure 1 In this application, an embodiment provides a method for modeling ontology semantic data networks native to AI, including the following steps:

[0044] Constructing the ontology model layer includes defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein, the ontology classes include entity classes and event classes, and the CBC strategies include context dimension, behavior dimension and constraint dimension;

[0045] Construct a behavior implementation layer, where each behavior is associated with a specific execution implementation;

[0046] Construct an instance network layer where ontology instances automatically inherit all the CBC strategies described in their respective ontology classes.

[0047] In the above technical solution, an ontology model layer is constructed, including defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein the ontology classes include entity classes and event classes, and the CBC strategies include context dimensions, behavior dimensions, and constraint dimensions; a behavior implementation layer is constructed, wherein each behavior is associated with a specific execution implementation; an instance network layer is constructed, wherein ontology instances automatically inherit all the CBC strategies of their respective ontology classes; this solves the problem of separation between data model, business logic, and execution engine in traditional solutions.

[0048] Specifically, the beneficial effects include:

[0049] Unified modeling capabilities. It simultaneously expresses object definitions, relational topologies, dynamic behaviors, and constraint rules within the same semantic network, eliminating the separation between data models, business logic, and execution engines found in traditional solutions. By dividing ontology classes into entity classes and event classes, ONN becomes a "process network" rather than merely an "entity graph," making it naturally suitable for process-driven business scenarios such as quality traceability and workflow management.

[0050] AI-enabled accessibility of business rules. Behaviors and constraints in the CBC model are described in natural language, which large language models and AI agents can directly "read" and "understand" without reverse engineering the program code. This is the fundamental difference between this invention and traditional ontologies (OWL / RDF), enterprise data platforms (Palantir Ontology, etc.).

[0051] Complete decoupling of semantics and execution. The behavior implementation layer separates the semantic description of behavior from the specific execution implementation. The same behavior can be flexibly associated with traditional IT implementations and AI-native implementations, supporting a progressive upgrade from traditional IT to AI-native.

[0052] Model-instance inheritance linkage. Instances automatically inherit all CBC strategies from the ontology class, and model changes are automatically propagated to instances, reducing the complexity of rule maintenance in large-scale business networks.

[0053] Intrinsic AI security governance. Before an AI agent executes business operations, the ONN engine automatically performs compliance checks according to the CBC policy, achieving "trustworthy AI execution"—AI does not bypass rules to execute operations, but executes securely under the protection of rules.

[0054] Dual-channel behavior implementation. Supports the coexistence of traditional IT implementations (code / API) and AI-native implementations (Agent / MCP / A2A / Skills), enabling enterprises to progressively introduce AI capabilities based on existing IT infrastructure, rather than "starting from scratch".

[0055] Binary modeling of relationships. Relationships are not just simple "connections"; they can also be attached with independent attributes and CBC strategies, making the relationship itself a computable semantic entity. This is suitable for complex business scenarios where state, rules, or behaviors need to be attached to relationships.

[0056] In one specific implementation, the scenario description, behavior description, and constraint rules in the CBC strategy are all in natural language form, which is used by the AI ​​agent to directly read and understand the natural language description in order to understand the business rules.

[0057] In one specific implementation scheme, the behavior implementation layer includes traditional IT implementation and AI-native implementation.

[0058] In one specific implementation, the traditional IT implementation includes program code functions and API calls; the AI-native implementation includes Agent workflow, MCP service, A2A collaboration, and Skills package.

[0059] In one specific implementation, the event class is used to describe dynamic business activities and together with the entity class constitutes a process network; wherein, the business activities include process execution, quality inspection, and assembly.

[0060] In one specific implementation scheme, in addition to defining the source ontology class and the target ontology class, the relation class can also independently attach attribute definitions and the CBC strategy, making the relation class an independent semantic entity that can carry information and rules.

[0061] In one feasible implementation, the instance inheritance mechanism enables changes to the CBC strategy of the ontology model layer to be automatically propagated to all corresponding ontology instances without requiring individual instance modifications.

[0062] In one specific implementation, the AI-native implementation of A2A collaboration supports AI agents in publishing capability descriptions through the AgentCard mechanism and in discovering, delegating, and coordinating the execution of tasks with external AI agents through standardized communication protocols.

[0063] In one specific implementation scheme, the AI-native ontology semantic data network modeling method includes the following steps:

[0064] Step 1: Construct the ontology model layer – Define ontology classes (Objective-C)

[0065] Objects in the business domain are abstracted and typed to form a collection of ontology classes. Each ontology class definition includes:

[0066] (a) Class identifier and classpath. The class is uniquely identified in the ontology hierarchy in the form of a hierarchical path, such as " / manufacturing / equipment".

[0067] (b) Attribute definition set. Define the attributes contained in this class. Each attribute includes meta-information such as attribute name, data type, value range, whether it is required, and whether it is aggregable.

[0068] (c) Semantic boundary description. Describe the domain and scope of application of this class in natural language so that the AI ​​agent can understand the business meaning of this class and its effective boundaries.

[0069] (d) Binary classification of ontology classes. Ontology classes are divided into entity classes (Nouns, describing static business objects such as products, equipment, and personnel) and event classes (Verbs, describing dynamic business activities such as process execution, quality inspection, and assembly), enabling the model to simultaneously express "what happened" and "what happened." The introduction of event classes makes ONN a process network rather than just an entity graph.

[0070] Step 2: Construct the ontology model layer – Define relation classes (LC)

[0071] The semantic relationships between business objects are abstracted and typed to form a collection of relationship classes. Each relationship class definition includes:

[0072] (a) Source ontology class and target ontology class. Specifies which two types of ontology instances this relationship can connect.

[0073] (b) Relationship cardinality. Defines one-to-one, one-to-many, or many-to-many constraints, affecting the topology of the instance network.

[0074] (c) Relationship constraints. These specify the business prerequisites that must be met to establish the relationship.

[0075] (d) Optional attribute definition. Relationship classes can independently attach attributes (such as the time when the relationship was established, weight, and status), making the relationship not just a "connection" but an independent semantic entity that can carry information.

[0076] (e) Optional CBC policy association. Relationship classes can be associated with independent CBC policies, expressing "under what circumstances the relationship can be established / dissolved, and what rules need to be followed".

[0077] Step 3: Define CBC strategies for ontology and relation classes

[0078] Associate the ontology and relationship classes defined in steps one and two with CBC policies, endowing them with context awareness, behavior enforcement, and constraint governance capabilities:

[0079] (a) Context-based modeling. Describes the environmental boundaries and preconditions for the effectiveness of behaviors and constraints in natural language. Context definition enables ONN to have "environmental awareness"—the same behavior may or may not be effective in different contexts.

[0080] Example: The "emergency shutdown" behavior of the device object class is used when "the device temperature exceeds the threshold or a safety alarm signal is received"; the "request transfer" behavior of the personnel object class is used when "it is only available during the transfer window at the end of each fiscal year".

[0081] (b) Behavior-based modeling. Business logic is encapsulated in natural language for callable operations. Behavior descriptions upgrade ONN from a "static data model" to a "dynamic business service." Each behavior includes: behavior name, natural language description (for easy understanding by the AI ​​agent), input parameter definition, expected output, and associated execution implementation.

[0082] Example: The behaviors of the equipment object class include "starting the equipment", "emergency shutdown", and "submitting a maintenance request"; the behaviors of the quality inspection event class include "recording inspection results" and "triggering non-conforming product processing".

[0083] (c) Constraint-based modeling. This describes the business rule checks that must be passed before any action can be performed, using natural language. Constraints act as "safety and compliance" safeguards embedded within the model.

[0084] Example: The constraints for personnel "applying for a job transfer" are: "The applicant's last job transfer must have occurred at least 365 days ago," "The applicant's performance rating for the past year must be excellent," and "The target department must have available staffing." The constraints for equipment "starting up equipment" are: "The equipment's most recent maintenance must be within its validity period," and "The operator must hold an operating qualification certificate for that type of equipment." CBC's revolutionary feature—AI-native natural language description:

[0085] Traditional approach: Business rules (such as "can only be transferred once a year") are translated by programmers into if-else logic, buried deep in the codebase, and are invisible to AI.

[0086] ONN approach: The same rule, described in natural language, is directly attached as a constraint to the "request transfer" behavior. The AI ​​agent only needs to read the natural language description of the CBC to instantly understand the rules of the action.

[0087] Step 4: Construct the behavior implementation layer – bridging semantics and execution

[0088] Establish a semantic association between the behavior defined in step three and its execution:

[0089] (a) Traditional IT implementation channels:

[0090] Program code functions—perform calculations or logical judgments directly within the ONN platform, suitable for deterministic data processing operations.

[0091] API calls – driving external microservices or enterprise applications (such as inventory deduction interfaces in ERP systems and work order status update interfaces in MES systems) via HTTP / RESTful interfaces, suitable for cross-system business operations.

[0092] (b) AI native implementation channel:

[0093] Agent Workflow – Triggers AI Agents to complete complex tasks that require multi-step reasoning (such as "analyzing the cause of equipment failure and generating a repair plan"), suitable for nondeterministic intelligent decision-making.

[0094] MCP (Model Context Protocol) service – connects external tools and data sources in a standardized way through the Model Context Protocol. AI agents discover and use external capabilities (such as connecting to enterprise document libraries to retrieve technical manuals and calling professional computing tools) through the MCP Server, which is suitable for AI agents to obtain context information.

[0095] A2A Collaboration (Agent-to-Agent Protocol) – Enables secure communication and coordinated execution between AI agents in an ONN and external AI agents through an inter-agent communication protocol. Each AI agent publishes an Agent Card describing its capabilities, and task discovery, delegation, and status tracking are performed via JSON-RPC. This approach is suitable for multi-agent collaboration scenarios across systems.

[0096] Skills packages—predefined, reusable AI capability modules—encapsulate domain-specific knowledge and reasoning logic (such as "root cause analysis of quality anomalies" and "supplier risk assessment" skills). AI agents can load and invoke these skill packages on demand, suitable for domain-specific AI enhancement. Core design principle: complete decoupling of semantics and execution. The AI ​​agent interacts with semantic "behaviors" (reading natural language descriptions), and the ONN is responsible for translating these "behaviors" into the underlying actual execution implementation. When the execution implementation changes (such as upgrading from API calls to Agent workflows), the semantic layer remains unaffected.

[0097] Step 5: Constructing the Instance Network Layer – Instantiation and Inheritance

[0098] Based on the definition of the ontology model layer, specific business instances are created in the instance network layer:

[0099] (a) Ontology Instance (OI). Each specific business object or event is treated as an ontology instance, automatically inheriting all property definitions and CBC strategies of its respective ontology class, without the need for redefinition.

[0100] (b) Relationship Instance (LI). The specific relationship established between two ontology instances, which follows the cardinality and constraint rules defined in the relation class.

[0101] (c) Attribute Value (VAL). The specific data value of the attribute of an ontology instance or relation instance.

[0102] Inheritance and linkage mechanism: When the CBC policy in the model layer changes (such as adding a new constraint rule), the change is automatically propagated to all corresponding instances without the need for individual modification. This ensures rule consistency throughout the entire network.

[0103] Step Six: Support AI-native read / write closed loop

[0104] When an AI agent needs to perform business operations in an ONN, the following process should be followed:

[0105] (a) Understanding and Discovery. The AI ​​agent locates the target object and its available behaviors in the ONN through natural language queries, and reads the natural language description of the behaviors to understand their functions.

[0106] (b) Reading the rules. Before invoking an action, the AI ​​agent reads the CBC policy associated with that action to understand the contextual conditions and constraint rules. Based on this understanding, the AI ​​autonomously determines whether the execution conditions are met.

[0107] (c) Secure Invocation. The AI ​​agent sends a request to the ONN to execute an action. The ONN engine automatically takes over and performs a final, precise verification in strict accordance with the CBC definition.

[0108] (d) Endogenous governance. Once all constraint checks pass, the action is executed (routed to the specific execution implementation via the action implementation layer), and the data is updated securely. If any constraint check fails, the operation is rejected, and a clear rejection reason and specific unmet condition based on natural language are returned to the AI ​​agent.

[0109] In a specific feasible implementation, ONN modeling for a manufacturing quality traceability scenario includes:

[0110] Scenario: Engine manufacturing plant. A quality traceability semantic network needs to be built to answer the questions: "Who produced and inspected this part, when, where, using what equipment, and according to what standards?" Data sources include ERP (Materials and Planning Data), MES (Manufacturing Execution System), QMS (Quality Management System), and an IoT platform (Environmental Monitoring Data).

[0111] Implementation of Step One (Modeling the Ontology Class):

[0112] Business objects are divided into two main categories: entity classes (Nouns) and event classes (Verbs).

[0113] Entity Class (The Nouns) – Static Business Objects:

[0114] Product (product / engine), primary key sn (serial number), attributes include model, order number, status, and warranty period;

[0115] SubAssembly (component), primary key part_code (component code), attributes include name, specification, and level;

[0116] Part (component), primary key part_code (component code), attributes include name, material, specifications, and key component identifier;

[0117] Batch, with primary key batch_no (batch number), and attributes including material code, supplier, production date, and status—the batch is the core identifier for traceability;

[0118] Equipment, primary key equipment_id, attributes include name, model, work center, and status;

[0119] Gage (measuring tool), primary key gage_id, attributes include type, accuracy, and calibration cycle;

[0120] Person (personnel), primary key employee_id, attributes include name, work group, position, and qualifications;

[0121] Supplier (Supplier), primary key supplier_code, attributes include name, rating, and qualification status;

[0122] WorkOrder (work order), primary key work_order_id, attributes include order number, material code, target quantity;

[0123] Operation (process definition), primary key op_code, attributes include name and process specification version. Event class (TheVerbs) – dynamic business activities:

[0124] ProcessExecution (process execution), with the primary key execution_id and attributes including start time, end time, status, and actual parameters—records a specific production and processing activity and is the core event of the traceability chain;

[0125] AssemblyEvent (assembly event), with primary key assembly_id and attributes including timestamp and torque value—records the activity of assembling parts into a product;

[0126] InspectionEvent (quality inspection event), with primary key inspection_id and attributes including timestamp and total result—records a quality inspection activity;

[0127] The CalibrationEvent (maintenance event) has the primary key calibration_id and attributes including maintenance time, maintenance content, and result—proving the validity of the measuring instrument within a certain period of time.

[0128] Step Two (Modeling Relationships):

[0129] Production process relationships:

[0130] ProcessExecution — [consumed_batch] → Batch (which batch of raw materials / parts was consumed)

[0131] ProcessExecution — [produced_batch] → Batch (which batch of parts / components was produced)

[0132] ProcessExecution — [ran_on] → Equipment (on which device to execute on)

[0133] ProcessExecution — [operated_by] → Person (Who performed the operation)

[0134] ProcessExecution — [based_on] → Operation (Based on which process definition)

[0135] WorkOrder —[includes]→ ProcessExecution (A work order contains multiple process executions) Quality traceability relationship:

[0136] InspectionEvent —[used_gage]→ Gage (Which gauge was used)

[0137] Gage —[was_calibrated_in]→ CalibrationEvent (Key link: Proving the validity of the gauge during testing)

[0138] InspectionEvent — [found] → Nonconformance (If inspection fails and nonconforming products are found) Assembly and supply chain relationship:

[0139] AssemblyEvent — [creates] → Product (Assembles and generates a product)

[0140] AssemblyEvent —[uses_batch]→ Batch (which batches of components were used)

[0141] Batch —[supplied_by]→ Supplier (which supplier supplied the batch).

[0142] Step 3 (Implementation of CBC Strategy Modeling):

[0143] Taking the Equipment class as an example:

[0144] Strategy 1: Device Startup Strategy

[0145] Context: The device is in "standby" mode and the current time is within the production window of the production schedule.

[0146] Behavior: Start-up device – Switch the device status from “standby” to “running” and record the start-up time and operator.

[0147] Constraints: ① Operators must hold an operating qualification certificate for this type of equipment; ② The equipment's most recent maintenance record must be valid; ③ The environmental readings (temperature, humidity) of the work center where the equipment is located must be within the allowable range.

[0148] Strategy 2: Emergency Equipment Shutdown Strategy

[0149] Context: When the device sensor reports that the temperature exceeds the safety threshold, or when an alarm signal is received from the safety system.

[0150] Behavior: Emergency Stop – Immediately switches the equipment status to "Stop-Safe" and automatically creates a maintenance work order.

[0151] Constraints: ① Only operators or safety administrators of the current shift are allowed to execute this command; ② A downtime reason report must be submitted within 30 minutes after execution.

[0152] Taking the InspectionEvent class as an example:

[0153] Strategy: Quality Inspection Implementation Strategy

[0154] Context: When the corresponding process execution status is completed, and the inspection plan for this process requires quality inspection.

[0155] Behavior: Record test results - Record the measured values ​​and judgment results for each test item of the batch.

[0156] Constraints: ① The gauges used must be within their calibration validity period (verified through CalibrationEvent); ② Inspection personnel must hold inspection qualifications; ③ Inspection of critical components must be performed by quality control personnel independent of production operators (personnel separation principle).

[0157] Implementation of Step Four (Modeling Behavior Implementation Layer):

[0158] Dual-channel implementation, taking the device "start device" behavior as an example:

[0159] Traditional IT implementation:

[0160] The program code function calls the platform's internal device status management module to update the status field (status: "standby" → "running") and record the operation log.

[0161] API call – Sends a RESTful request to the MES system (POST / api / equipment / {id} / start), passing in the operator ID and work order number. The MES system then completes the equipment linkage control. AI native implementation:

[0162] Agent Workflow – Trigger the “Device Startup Pre-Check Agent”, which automatically completes the following: query operator qualifications → check maintenance validity period → obtain environmental readings → execute startup after comprehensive judgment.

[0163] MCP Service – Connects to the IoT platform via MCP Server to obtain real-time device sensor data (temperature, vibration, current) as context for initiation decisions.

[0164] A2A Collaboration – Communicates with the security management agent via the A2A protocol, exchanges capability information by sending Agent Cards, and entrusts the security agent to verify whether there are any unresolved security risk events.

[0165] In a specific feasible implementation, the process of using ONN for quality traceability query includes:

[0166] Scenario: A delivered engine (SN: E-20240917-001) malfunctioned at the customer's site, and the initial assessment is that it is a "crankshaft" problem. Reverse tracing is required.

[0167] Traceability path:

[0168] Step 1: Locate the Product instance (sn = “E-20240917-001”) in the instance network layer.

[0169] Step 2: Find all Batch instances contained in this product through the Product ←[creates]—AssemblyEvent —[uses_batch]→ Batch relationship chain, and filter out the batch with material code "crankshaft" (such as BATCH-CRANK-20240810).

[0170] Step 3: Starting from the crankshaft batch, find the process execution event for producing this batch through the reverse relationship of Batch ← [produced_batch] — ProcessExecution.

[0171] Step 4: Starting from the ProcessExecution event, obtain the complete production context: [ran_on]→Equipment (CNC machine tool No. 5), [operated_by]→Person (employee Zhang San), [based_on]→Operation (crankshaft finishing v2.1 process specification).

[0172] Step 5: Starting from the crankshaft batch, find all quality inspection events through Batch ← [inspects] — InspectionEvent, and obtain the inspection context: [used_gage] → Gage (coordinate measuring machine No. 2) and the measured values ​​of all inspection items.

[0173] Step 6: Verify the validity of the inspection – Starting with Gage, confirm via [was_calibrated_in] → CalibrationEvent that the measuring instrument was within its calibration validity period during the inspection. Traceability conclusion: Through graph traversal of ONN, a complete chain of evidence is constructed within seconds – this crankshaft was produced by Zhang San on August 10th using CNC machine tool No. 5, and inspected by Li Si using coordinate measuring machine No. 2. The measuring instrument was within its calibration validity period, and the inspection data were all within tolerance. Traceability can be further extended to raw material batches, supplier ratings, etc.

[0174] In a specific feasible implementation, the process by which an AI Agent securely executes a job reassignment operation includes:

[0175] Scenario: HR management system. The AI ​​Agent receives the instruction "Help me transfer Xiao Zhang to the R&D department".

[0176] The dilemma of traditional systems: AI faces the employees and departments tables, but does not know what rules need to be checked for "job transfer", and the rules are scattered in the code of multiple applications.

[0177] Safe execution process in ONN:

[0178] Step 1 (Understanding and Discovery): The AI ​​uses natural language queries to locate the "belongs to" relationship between "employees" and "departments" in the ONN, and discovers that a behavior called "apply for transfer" is defined on the employee class.

[0179] Step 2 (Reading Rules): The AI ​​reads the CBC strategy for the "reassignment application" behavior: Context: "Available only during the reassignment window at the end of each fiscal year"; Constraints: "The applicant's last reassignment must have been more than 365 days ago," "The applicant's performance rating for the past year must be excellent," and "The target department must have available staffing." The AI ​​understands all the constraints.

[0180] Step 3 (Secure Invocation): The AI ​​determines that the current situation conditions are met (within the job transfer window) and sends an execution request to the ONN: "Execution action 'Request for Job Transfer', Subject: Xiao Zhang, Target: R&D Department".

[0181] Step 4 (Endogenous Governance): The ONN engine automatically verifies all constraints—queries Xiao Zhang's last job transfer date (meets 365 days), performance rating (excellent, passed), and R&D department staffing (vacancy, passed). Once all checks pass, the action is executed securely, and the employee-department relationship instance is updated.

[0182] The beneficial effects of the above technical solution include:

[0183] A unified business semantic network. Taking engine manufacturing as an example, 15 core ontology classes (10 entity classes + 5 event classes) and 15 relationship classes fully express all the business semantics required for quality traceability in the same ONN, eliminating semantic silos between the four systems: ERP / MES / QMS / IoT.

[0184] AI can directly read business rules. The scenarios, behaviors, and constraints in the CBC strategy are all described in natural language. The AI ​​agent can understand business rules such as "what qualifications are needed to start the equipment", "quality inspection requires calibrating valid measuring instruments", and "job transfer requires checking performance and staffing" without reverse engineering any program code.

[0185] Process-driven traceability capabilities. By using event classes (ProcessExecution, InspectionEvent, etc.) as the glue for the traceability chain, full-chain forward / reverse traceability from product to raw materials is realized in the ONN graph structure, reducing traceability response time from minutes to seconds in traditional cross-system queries.

[0186] Flexible dual-channel execution. The same "start device" action can be executed either by calling the MES system via API (traditional IT channel) or by automatically completing pre-checks and executing via Agent workflow (AI native channel), supporting enterprises' gradual upgrade from traditional IT to AI native.

[0187] exist Figure 2 In this application, an embodiment provides an AI-native ontology semantic data network modeling system, including:

[0188] The model layer management module is used for defining and managing ontology classes, relation classes, and CBC strategies.

[0189] The instance network layer management module is used for instance creation and inheritance linkage;

[0190] The behavior implementation layer management module is used for registration and routing of traditional IT implementations and AI-native implementations.

[0191] In the above technical solution, an ontology model layer is constructed, including defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein the ontology classes include entity classes and event classes, and the CBC strategies include context dimensions, behavior dimensions, and constraint dimensions; a behavior implementation layer is constructed, wherein each behavior is associated with a specific execution implementation; an instance network layer is constructed, wherein ontology instances automatically inherit all the CBC strategies of their respective ontology classes; this solves the problem of separation between data model, business logic, and execution engine in traditional solutions.

[0192] In one specific implementation scheme, it also includes:

[0193] The CBC engine module is used to automatically perform scenario and constraint verification before the behavior is executed;

[0194] The AI ​​interaction module is used to realize the read-understand-write closed loop of the AI ​​agent.

[0195] Those skilled in the art will know that this application can be implemented as a system, method, or computer program product.

[0196] Therefore, this disclosure can be implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this application can also be implemented as a computer program product in one or more computer-readable media, the computer-readable media containing computer-readable program code.

[0197] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0198] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application. Based on this, various substitutions and improvements can be made to this application, all of which fall within the protection scope of this application.

Claims

1. A method for modeling ontology semantic data networks native to AI, characterized in that, Includes the following steps: Constructing the ontology model layer includes defining ontology classes and their attributes and semantic boundaries, defining relation classes and their cardinality and constraints, and associating CBC strategies with ontology classes and relation classes; wherein, the ontology classes include entity classes and event classes, and the CBC strategies include context dimension, behavior dimension and constraint dimension; Construct a behavior implementation layer, where each behavior is associated with a specific execution implementation; Construct an instance network layer where ontology instances automatically inherit all the CBC strategies described in their respective ontology classes.

2. The AI-native ontology semantic data network modeling method according to claim 1, characterized in that, The scenario descriptions, behavior descriptions, and constraint rules in the CBC strategy are all based on natural language, allowing the AI ​​agent to directly read and understand the natural language descriptions in order to comprehend the business rules.

3. The AI-native ontology semantic data network modeling method according to claim 2, characterized in that, The behavior implementation layer includes traditional IT implementation and AI native implementation; the traditional IT implementation includes program code functions and API calls.

4. The AI-native ontology semantic data network modeling method according to claim 3, characterized in that, The AI ​​native implementation includes Agent workflow, MCP service, A2A collaboration, and Skills package.

5. The AI-native ontology semantic data network modeling method according to claim 4, characterized in that, The event class is used to describe dynamic business activities and together with the entity class constitutes a process network; wherein, the business activities include process execution, quality inspection and assembly.

6. The AI-native ontology semantic data network modeling method according to claim 5, characterized in that, In addition to defining the source ontology class and the target ontology class, the relation class can also independently attach attribute definitions and the CBC strategy, making the relation class an independent semantic entity that can carry information and rules.

7. The AI-native ontology semantic data network modeling method according to claim 6, characterized in that, The instance inheritance mechanism enables changes to the CBC strategy in the ontology model layer to be automatically propagated to all corresponding ontology instances without requiring individual instance modifications.

8. The AI-native ontology semantic data network modeling method according to claim 7, characterized in that, The AI-native implementation of A2A collaboration enables AI agents to publish capability descriptions through the Agent Card mechanism and to discover, delegate, and coordinate the execution of tasks with external AI agents through standardized communication protocols.

9. A system for modeling AI-native ontology semantic data networks based on the AI-native ontology semantic data network modeling method according to any one of claims 1-8, characterized in that, include: The model layer management module is used for defining and managing ontology classes, relation classes, and CBC strategies. The instance network layer management module is used for instance creation and inheritance linkage; The behavior implementation layer management module is used for registration and routing of traditional IT implementations and AI native implementations; the traditional IT implementations include program code functions and API calls.

10. The AI-native ontology semantic data network modeling system according to claim 9, characterized in that, Also includes: The CBC engine module is used to automatically perform scenario and constraint verification before the behavior is executed; The AI ​​interaction module is used to realize the read-understand-write closed loop of the AI ​​agent.

Images