A method for automatically generating an OSDK based on ontology entity metadata

Abstract

The application belongs to the technical field of information technology and software development tool technology, and particularly relates to a method for automatically generating OSDK based on ontology entity metadata, which solves the problems of high coding cost, multiple atlas conflicts and inconsistent protocols caused by entity changes. The method comprises the following steps: collecting and normalizing entity metadata; constructing an object description structure containing class definition and constraints; automatically generating entity classes and access interfaces; editing interfaces and constructing loads according to constraints mapping; converting objectified calls into standardized requests and analyzing results; implementing atlas-level isolated loading; listening to changes and triggering differential hot updates. The application realizes real-time synchronization of the modeling end and the development end, solves the naming conflict, ensures the consistency and standardization of entity access logic, and significantly improves the reliability and maintenance efficiency of the system.

Description

Technical Field

[0001] This invention belongs to the field of information technology and software development tools, and in particular relates to a method for automatically generating OSDK based on ontology entity metadata. Background Technology

[0002] In the current field of cognitive intelligence, which is driven by knowledge, knowledge graph systems have become a fundamental support infrastructure for processing large-scale, unstructured data and achieving semantic associations. As a core component of knowledge graph construction, ontology modeling, through the abstraction of entities in the objective world, defines key metadata such as entity names, unique identifiers, field attributes, data types, primary key constraints, and association descriptions. This metadata not only forms the basis for schema definition in the underlying graph database but also serves as the logical framework for upper-layer business programs to access and process data. To enable business developers to interact efficiently with complex graph entities, a software development kit (SDK) is typically needed to encapsulate the underlying communication protocols and data mapping logic. In traditional technical implementation frameworks, the construction of this entity access capability heavily relies on manual coding. That is, after the modeling activity is completed, developers manually write the corresponding entity object classes, query condition encapsulation structures, parameter objects, and request logic code for interfacing with backend data services, based on the modeling platform's definition manual.

[0003] At certain stages of technological development, this manually driven coding model, to a certain extent, met the customization needs of business logic. Through hard coding, developers could perform fine-grained access control and result parsing for each specific entity, precisely mapping entity attributes to class members in the programming language. However, as knowledge graph applications evolve towards agility, dynamism, and multi-graph parallelism, this technology path based on static code maintenance has gradually revealed its inherent contradictions at the theoretical level. From the perspective of technological evolution, there is a significant difference in pace between the lifecycle of ontology entities and their corresponding coding environment: entity metadata in the modeling platform is often under continuous optimization and adjustment, whether it is adding or deleting fields, correcting type normalization, or redefining primary key rules, all of which are high-frequency modeling activities; while manually written SDK code is essentially a "logical snapshot" of metadata at a specific point in time. This static snapshot mechanism leads to a physical isolation between the modeling results and the object code, so that any slight deviation in metadata must be fed back to the development environment through a long manual refactoring and release cycle, which greatly impairs the consistency and responsiveness of the system.

[0004] A deeper analysis of the underlying technical contradictions reveals that in existing technologies, entity object classes, filtering condition payloads, and call execution logic are typically maintained as independent units. This fragmented maintenance model is particularly vulnerable to complex constraints, such as mandatory field rules, editable permissions, and primary key location strategies, which are often scattered across different validation modules and logic payloads at the code level. Due to the lack of a unified metadata-driven model, the system's identification of these constraints relies entirely on the developers' experience and judgment. This not only results in a large amount of repetitive work but also inevitably introduces hidden faults such as missing field mappings or inconsistent types. Furthermore, in complex industrial scenarios supporting parallel multi-graph operations, different graphs may contain entities with the same name but vastly different structures. Existing class loading mechanisms and interface definition methods often fail to provide adequate namespace isolation and runtime switching capabilities, leading to symbol conflicts and memory logic overwriting between entities with the same name during concurrent operation or hot updates, ultimately causing serious business execution deviations.

[0005] A more critical bottleneck lies in the lack of a fully automated generation mechanism across the entire chain, from metadata to underlying service calls. Consequently, the system's capabilities for retrieving, creating, updating, and deleting entities often exhibit inconsistent styles and scattered validation rules. In the runtime environment, because the server-side execution logic is based on the latest metadata model, while the client-side OSDK logic may still reside in older structural definitions, this "logic mismatch" directly leads to secondary problems such as field parsing failures, constraint violation anomalies, and unreliable execution results. This series of technical defects caused by the fundamental "dynamic-static contradiction" results in exponentially increasing maintenance costs as the system scales. Therefore, completely eliminating reliance on manual coding and building a technical solution capable of deeply deconstructing ontology entity metadata and automatically generating OSDK (Ontology Object Development Tool) capabilities and updating them in a graph-level isolated manner during service operation has become a core challenge and an urgent technical problem in the current field of knowledge graph engineering, aimed at improving modeling and execution consistency and reducing maintenance complexity. Summary of the Invention

[0006] The purpose of this invention is to provide a method for automatically generating OSDKs based on ontology entity metadata, aiming to solve technical problems such as high coding costs, poor data consistency, multi-graph operation conflicts, and inconsistent interface protocols caused by frequent changes in entity structure during knowledge graph modeling and application development. This invention achieves end-to-end structural synchronization and automated capability mapping from ontology modeling to application development by constructing a metadata-driven OSDK automatic generation and dynamic execution framework.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0008] A method for automatically generating OSDK based on ontology entity metadata, characterized in that the method includes the following steps:

[0009] S1: Entity Metadata Collection and Standardization: The system connects to knowledge graph modeling services, graph initialization snapshots, or entity configuration data sources through a preset interface protocol to extract the original metadata of the target entity. The original metadata includes at least the entity name, entity identifier, graph identifier, Chinese name, descriptive information, field list, field type, field order, field nullability flag, field primary key flag, and field description information. After collection, the system initiates a standardization process to perform integrity verification, naming conventions, type normalization, and constraint identification on the extracted original metadata. The type normalization process converts the diverse type system defined in the modeling platform into a strongly typed identifier for the target programming language. The normalization conversion logic follows a preset mapping matrix M={( T raw , T target )},in T raw Primitive data type, T target The target language type is specified. For the identified primary key and nullable tags, the system converts them into entity constraint logical vectors, forming normalized entity metadata that can be directly used for object structure generation.

[0010] S2: Object Description Structure Construction: Based on the normalized entity metadata generated in the first step, a multi-dimensional object description structure (ODS) is constructed in memory. This object description structure serves as middleware between the metadata and code generation layer, and its data model is defined as follows: ODS ={ N cls , M mod , ID graph , ID ent , L field , L pk , L req , L edit , I info}.in, N clsFor object class names that follow camelCase naming conventions; M mod Used as a module path identifier; ID graph This serves as a globally unique identifier for the map; ID ent A unique serial number for the entity; L field Define a list of fields that include physical name, logical name, and normalized type; L pk Primary key field index set; L req This is a set of non-empty constraint fields; L edit This is the set of editable fields excluding the primary key. I info This includes metadata information such as the display name and meta-description. The object description structure not only guides the generation of source code for entity object classes but also serves as the core logical basis for subsequent query interface generation, editing interface generation, network request construction, and result deserialization.

[0011] S3: Entity Object Class and Object Access Interface Generation Steps. The system invokes the code generation engine to automatically generate entity object class files in the target language based on the object description structure. In the generated class definition, the system uses metaprogramming techniques to write static field definitions, primary key index mappings, and graph-entity association identifiers. The entity object class inherits from a preset ontology object base class, which encapsulates basic serialization, deserialization, and attribute observer logic. Furthermore, the system embeds an object access interface into the generated entity object class, which defines a unified entity operation entry point. Upper-layer business programs can obtain a query interface object with chainable call capabilities by calling this entry point. The query interface object internally maintains a query state machine, supporting single entity primary key retrieval, conditional expression filtering, pagination parameter configuration, and set sorting retrieval, thereby achieving transparent access to the underlying graph data in the object encoding environment.

[0012] S4: Entity Editing Interface and Edit Request Data Generation Steps. The system relies on the object description structure... L pk , L req and L edit The system automatically generates a set of editing capabilities for this entity, including interfaces for adding, modifying, and deleting entities. When the upper-level business application initiates a add operation, the system activates mandatory field validation logic to ensure... L reqAll fields in the dataset have been assigned values, and a new payload containing complete field mappings has been constructed. When a modification operation is initiated, the system uses the attribute observer to record the changes in the assigned fields and compares them. L edit The set removes illegally modified fields and combines them with those modified by... L pk The extracted primary key values ​​are used to construct the local update payload. When a delete operation is initiated, the system only extracts... L pk The corresponding primary key information is included, along with a deletion action identifier. All generated editing payloads are encapsulated into standard edit request data objects, and support organizing edit requests from multiple different entities into transactional edit sets for unified submission.

[0013] S5: Standardized Request Construction and Result Parsing Steps. The system has a built-in execution unit responsible for converting application-layer object-oriented calls into standardized communication requests conforming to server specifications. For query operations, the execution unit reads the condition status from the query interface object and serializes it into a sequence containing... graphId , entityId , fieldList and conditions The execution unit generates a JSON payload structured by a specific query server endpoint. For write operations, it aggregates the edit request data set generated in step four by graph dimension, constructs a unified batch write payload, and points it to the corresponding write server endpoint. Upon receiving the response data from the server, the execution unit starts the result parsing engine, mapping the original row and column data or key-value pairs to corresponding entity object instances or object collections based on the object description structure. The parsing process includes secondary type validation and exception handling to ensure that the object instances returned to the upper-layer business program meet type safety requirements.

[0014] S6: Graph-level object generation, loading, and update steps. The system executes a graph-isolated runtime environment construction scheme. First, the system creates an independent runtime directory in physical storage for each graph to store the source code of the entity object classes generated by the corresponding graph and the compiled bytecode files. Second, the system maintains a graph-level object list, recording the metadata hash values ​​and file path mappings of all entities under the current graph version. At runtime, the system uses a custom class loader to achieve namespace isolation between graphs, ensuring that even entities with conflicting names in different graphs can be correctly loaded in their respective isolated spaces. In addition, the system monitors graph initialization snapshots to achieve full construction of the object runtime directory and runtime initialization mounting.

[0015] S7: Entity Metadata Change Synchronization Update Steps. The system polls the metadata change log of the modeling service in real time or periodically. When it detects that the metadata of a specific entity has undergone attribute additions, deletions, or constraint adjustments, the system automatically triggers a differential update process. The process includes: re-collecting the normalized metadata of the affected entity; comparing the metadata hash value to confirm the scope of the change; re-executing steps two through four to overwrite and generate new object description structures, entity object classes, and access interface files; subsequently, the system calls a hot reload instruction to disable the class loader of the corresponding graph and reload the updated class definition, while simultaneously refreshing the graph-level runtime cache. Through this mechanism, changes at the modeling end can be seamlessly propagated to the object coding environment without affecting the operational stability of other entities that have not undergone changes.

[0016] Preferably, the type normalization process in step S1 also includes logic for identifying complex data structures:

[0017] For fields containing arrays, JSON objects, or geospatial coordinates, they are mapped to the corresponding collection types or custom structures in the target language; when processing date and time types, the ISO 8601 standard format is used as an intermediate conversion protocol, and the corresponding date parser is automatically configured when generating the entity object class to ensure the accuracy of data parsing under different time zones and format environments;

[0018] Step S1 also includes automatic handling logic for field mapping conflicts: when the original field name of an entity contains reserved keywords of the target language, a valid object attribute name is generated according to a preset renaming rule, and the mapping relationship between physical field names and logical attribute names is recorded in the object description structure.

[0019] P map =( FieldName raw , AttributeName obj ), P map Map the field to a tuple. FieldName raw This is the original physical field name. AttributeName obj This refers to the logical property name of the object. This ensures that the physical field names can be accurately restored during the request construction phase.

[0020] Preferably, the object description structure in step S2 is defined as a nine-tuple:

[0021] ODS ={ N cls , M mod , ID graph, ID ent , L field , L pk , L req , L edit , I info};

[0022] in, N cls For object class names that follow camelCase naming conventions; M mod Used as a module path identifier; ID graph This serves as a globally unique identifier for the map; ID ent A unique serial number for the entity; L field Define a list of fields that include physical name, logical name, and normalized type; L pk Primary key field index set; L req This is a set of non-empty constraint fields; L edit This is the set of editable fields excluding the primary key. I info This includes metadata information that displays the name and meta description.

[0023] Preferably, the entity object class generated in step S3 is written into static field definitions using metaprogramming techniques to record the graph ID and entity ID corresponding to the entity; the ontology object base class implements the observer pattern to monitor the change status of object attributes in real time and record it in the internal state bitmap; the object access interface adopts a reactive programming model, and the query interface object implements the streaming construction of query conditions through the defined where(), orderBy(), and select() operators. Each operator call returns a new copy of the interface object to ensure the immutability of the query expression, and at runtime, the chained call stack is parsed into a logical query tree to generate a standardized query domain-specific language (DSL).

[0024] Preferably, the edit request data generation process in step S4 includes a pre-validation engine: before constructing the new payload, the pre-validation engine scans the set of non-empty constraint fields, and if it finds that a required field is missing, it throws a structured exception and prevents the request from entering the network layer; when constructing the modified payload, the execution unit adopts dirty checking technology, and by comparing the original value in the entity object class instance with the current value, only fields that have undergone actual numerical offset and belong to the set of editable fields are included in the update payload, thereby reducing the network transmission bandwidth usage.

[0025] Preferably, the result parsing engine in step S5 is equipped with a multi-level caching mechanism: the system maintains an object pool in memory based on the globally unique identifier of the graph and the unique sequence number of the entity. For duplicate query requests with the same primary key identifier, the parsing engine first retrieves the instantiated objects from the object pool and uses a weak reference mechanism to manage the lifecycle of the objects. The result parsing engine adopts streaming parsing technology, instantiating objects while reading the streaming data from the server, and calling the type converter in real time to normalize each row of data.

[0026] Preferably, the graph-level isolation mechanism in step S6 also involves version isolation of third-party dependency libraries: configuring an independent resource description file for the code space generated for each graph, and maintaining a graph-level object list, which records the structural signature of each entity. When referencing entities across graphs, the validity of the reference is ensured by verifying the structural signature. When loading entity classes, the class loader prioritizes searching the runtime directory of the corresponding graph to resolve conflicts between entities with the same name.

[0027] Preferably, the synchronous update process in step S7 adopts a double-buffered switching strategy: during the process of regenerating the class file and compiling, the old version of the object class still provides services to the outside world; only when the new version class has completely passed the compilation verification and successfully loaded into the shadow space, the system achieves instantaneous reloading at runtime by switching the reference pointer of the class loader, so as to ensure that the metadata update process is unaware of the business layer in high-concurrency access scenarios.

[0028] The beneficial effects of this invention include:

[0029] 1. Real-time synchronization between ontology modeling results and object coding environment is achieved. Through automated metadata collection and code generation processes, this invention eliminates redundant work of manually writing entity classes and interface code, ensuring that any adjustments to the entity structure can be immediately fed back to the development end, greatly shortening the delivery cycle from modeling to application.

[0030] 2. Ensures a high degree of consistency and standardization in entity access logic. The system generates query and edit interfaces based on a unified object description structure, enforces primary key constraints, mandatory field validation, and editability rules, thereby eliminating field type errors or invalid operations caused by human mapping oversights and improving the system's operational reliability.

[0031] 3. Provides comprehensive multi-graph operation isolation and dynamic expansion capabilities. By constructing independent operation directories and class loading spaces according to the graph dimension, this invention effectively solves the loading conflict problem of entities with the same name in multi-graph scenarios, and supports dynamic updating and hot reloading of the capabilities of a single graph entity without restarting the system.

[0032] 4. Significantly reduces system maintenance complexity and cost. Encapsulating entity structure, operational logic, and request protocols within an automatically generated OSDK allows upper-layer business logic to focus on the business itself rather than the details of underlying data interaction, while also providing a unified technical support foundation for horizontal system expansion and protocol upgrades.

[0033] 5. Enhanced security and accuracy of data interaction. The built-in verification engine can intercept calls that violate metadata constraints before the request is sent, reducing unnecessary network overhead and server pressure. At the same time, the standardized result parsing mechanism ensures the integrity and type safety of complex entity data during the deserialization process. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating the method for automatically generating OSDK based on ontology entity metadata according to the present invention.

[0035] Figure 2 This is a schematic diagram illustrating the mapping from entity metadata to object description structure and entity object class according to the present invention.

[0036] Figure 3 This is a schematic diagram illustrating the generation of the entity query interface and the construction of the query request according to the present invention.

[0037] Figure 4 This is a schematic diagram illustrating the generation and editing of the entity addition, modification, and deletion interface and the load structure of the present invention.

[0038] Figure 5 This is a schematic diagram illustrating the loading, updating, and entity result return of graph-level objects according to the present invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. This invention provides a method and system for automatically generating OSDK based on ontology entity metadata. In practical engineering applications, through a metadata-driven automated architecture, it achieves end-to-end structural synchronization from the knowledge graph modeling end to the application development end.

[0040] See appendix Figure 1 As shown, in this invention, the ontology object development tool, which dynamically generates ontology metadata and provides object development capabilities as a service, is referred to as OSDK. The method of automatically generating OSDK based on ontology entity metadata in this invention...

[0041] During the entity metadata collection and normalization process in step S1, the system connects to the knowledge graph modeling service via a pre-defined RESTful interface protocol or message queue (such as Kafka). In the initialization phase, the system obtains a snapshot of the graph initialization and extracts the raw metadata of the target entities. This raw metadata includes basic attributes such as entity name, entity identifier, graph identifier, Chinese name, and descriptive information, as well as detailed field-level definitions. Specifically, field definitions include a field list, physical field name, logical field name, field type (VARCHAR, INT8, FLOAT, TIMESTAMP, etc.), the physical order of the field in the database, a flag indicating whether the field can be nullable, a flag indicating whether it is a primary key, and a business description of the field.

[0042] After data collection is complete, normalization processing is initiated. First, integrity checks are performed on the raw metadata to ensure that each entity has a valid unique identifier and at least one primary key field. Then, the system performs naming normalization, converting underscore names (snake_case) or non-standard names from the physical storage layer into identifiers conforming to the target programming language's specifications. The core type normalization process utilizes a pre-defined mapping matrix. Mapping matrix M = {( T raw , T target The `}` defines the mapping relationship between the underlying storage type and the strongly typed application layer. For example, when... T raw When it is "INT8", T target It is mapped to "Long" in Java or "long" in C#; when T raw When it is "DECIMAL(18,4)", T target It is mapped to "BigDecimal". For Boolean types, the system recognizes commonly used physical layer representations such as "T / F", "1 / 0", or "Y / N" and normalizes them into standard Boolean identifiers. In addition, the system converts the identified primary key tags and nullable tags into entity constraint logic vectors. These vectors consist of a set of bitmaps or Boolean arrays, used to quickly retrieve the constraint attributes of fields in subsequent steps, thereby forming normalized entity metadata.

[0043] In step S2, the object description structure building module receives normalized entity metadata and constructs a multi-dimensional object description structure in memory. This structure, serving as an intermediate medium for the conversion of metadata to code, is defined as a nine-tuple. ODS ={ N cls , M mod, ID graph , ID ent , L field , L pk , L req , L edit , I info}

[0044] in, N cls The class name, which follows the upper camelCase naming convention, is obtained by normalizing the entity identifier. M mod This identifies the package path or namespace to which the entity belongs, typically related to... ID graph Related. ID graph and ID ent Store the globally unique codes for the graph and the entity respectively. L field It is a composite structure that includes the physical name, logical name, and normalized data type of the field. L pk Stores an index set of primary key fields, supporting composite primary keys. L req Record all non-null constraint fields. L edit That is in L field The subset after removing primary key fields and system-reserved fields (such as read-only fields like creation time and update time) from the base. I info This encapsulates metadata used for UI display, such as Chinese names and descriptive text. The construction process of the object description structure is managed using a singleton pattern or a cache pool to ensure that only one copy of the description structure for the same entity exists in memory, and its version consistency is verified through hash signatures.

[0045] In a preferred embodiment of the present invention, when constructing the object description structure, if the system detects that the original field name contains reserved keywords of the target language, such as "class", "public", "void", etc., the system will automatically apply renaming rules to add "attr_" before the physical field name or "_field" after it, generating a valid object attribute name. Simultaneously, the system records the mapping relationship between physical field names and logical attribute names in the object description structure. P map =( FieldNameraw , AttributeName obj ), P map Map the field to a tuple. FieldName raw This is the original physical field name. AttributeName obj This is the logical attribute name of the object. This mapping relationship is used to establish a one-to-one correspondence between the underlying physical metadata fields and the upper-layer OSDK object attributes, solving problems such as non-standard original field naming, keyword conflicts, and syntax incompatibility. It also plays a crucial role in the subsequent request construction phase, ensuring that the application layer object attributes can be accurately restored to the physical field names that the server can recognize.

[0046] Step S3 is executed by the object class and object access interface generation module. The system calls the built-in code generation engine, which parses the object description structure based on a preset code template (Velocity or FreeMarker template) and generates the source code of the entity object class in the target language. The generated entity object class contains private member variables, public getter and setter methods, and annotations for identifying field constraints. Furthermore, the system uses metaprogramming techniques to write static constants in the class definition to record the graph ID and entity ID corresponding to the entity. The entity object classes uniformly inherit from the preset ontology object base class, which has built-in serialization logic based on Jackson or Fastjson and implements the observer pattern to monitor changes in object attributes.

[0047] While generating entity object classes, the system embeds an object access interface. This interface serves as the sole entry point for upper-layer business calls to the entity, encapsulating the lifecycle management logic of the entity. Business programs obtain a query interface object with chainable call capabilities by calling this interface. The query interface object internally maintains a query state machine, which includes a condition container, a sorting container, and a pagination container. By defining operators such as where(), orderBy(), and limit(), developers can construct query conditions in a streaming manner. For example, calling where(User.AGE.gt(18)) will add a greater than constraint to the state machine. As a preferred embodiment of the present invention, the query interface object adopts a reactive programming model, and each operator call returns a new copy of the interface. This immutability design ensures call safety in a multi-threaded environment.

[0048] Step S4 involves generating the editing interface and editing request data. This is based on the object description structure... L pk , L req andL edit The collection automatically maps to generate a set of editing capabilities, including interfaces for adding, modifying, and deleting entities—specifically, the insert(), update(), and delete() interfaces for that entity. See [link to documentation]. Figure 4 As shown. When the business layer initiates an insert operation, the pre-validation engine is started, and iterates through... L req The list checks if required fields have been assigned values; if any are missing, an exception is immediately thrown and the process terminates. When constructing the update request, the system uses the property observer in the entity object's base class to obtain the set of fields to be modified. The system then compares this set with... L edit The system performs an intersection operation to remove illegally modified primary key fields or read-only fields. Then, it employs dirty checking to include only fields whose values ​​have actually shifted in the update payload. All edit operations are ultimately encapsulated into edit request data, supporting the organization of edit requests for multiple entities in a transactional manner.

[0049] Step S5, request construction and result parsing: The application layer's calling logic is transformed into a standardized communication request. For query operations, the state machine data in the query interface object is read and serialized into a format containing... graphId, entityId, fieldList and conditions The JSON structure of the nodes is as follows. For edit operations, the edit request data generated in step four is aggregated to construct a batch write payload. The request is sent to the specified endpoint on the server via the built-in HTTP client. After receiving the response data, the result parsing engine intervenes. This engine maps the row and column format data returned by the server to instances of entity object classes based on the type definitions in the object description structure. See [link to documentation]. Figure 2 As shown. During the parsing process, the system performs secondary type validation and handles conversions of complex data structures such as JSON objects or geospatial coordinates. To optimize performance, the result parsing engine supports a multi-level caching mechanism, utilizing a pool of entity objects managed by weak references to avoid duplicate instantiation and ensure that each primary key corresponds to a unique object instance.

[0050] Step S6 achieves graph-level isolation through runtime graph loading and updating, see [link to relevant documentation]. Figure 5 As shown, a separate runtime directory is allocated for each graph in physical storage to store the generated source code and compiled bytecode. To resolve potential conflicts between entities with the same name across different graphs, a separate custom class loader is instantiated for each graph. When loading entity classes, the class loader prioritizes searching the runtime directory of the corresponding graph. Furthermore, a graph-level object list is maintained, recording the metadata hash value, version number, and physical path of each entity.

[0051] Step S7 Synchronous Update: Continuously poll the metadata change log of the modeling service. When a change in the metadata of a specific entity is detected (addition of fields or modification of constraints, etc.), the system restarts the data collection and generation process. To ensure uninterrupted business operations during the update process, the system employs a double-buffering switching strategy. New class definitions are compiled and preloaded in the shadow space, while existing class definitions continue to serve current calls. Only after all classes in the shadow space have passed full verification does the system update the class loader's reference pointer to achieve runtime hot replacement.

[0052] In S1's type normalization, the system possesses deep recognition logic for complex data structures. For example, when a field type of geospatial coordinates (GeoPoint) is detected, the system not only maps it to a structure containing latitude and longitude in the generated entity object class, but also automatically injects spatial search operators, such as withinCircle() or withinBox(), into the query interface object. These operators are parsed into a server-recognized spatial query DSL during the request construction phase, thereby enabling the pass-through of advanced business capabilities from metadata to code.

[0053] During the construction of the object description structure in S2, for L field The processing employs ordered mapping storage to ensure that the order of member variables in the generated entity class is completely consistent with the field order defined by the modeling platform. This consistency is crucial for certain serialization protocols (such as Protocol Buffers) that are sensitive to field order. Additionally, the object description structure includes an extended attribute dictionary to store optimization tips for specific storage engines, such as index suggestions or shard key information. This information is appended to the request header when constructing the query request. See [link to relevant documentation]. Figure 3 As shown.

[0054] In the S3 code generation process, the generated entity classes not only contain attributes but also a set of static metadata constants. For example, for an entity named "User", the generated code will contain static attribute objects such as User.NAME and User.AGE. These attribute objects encapsulate the physical field names, type information, and corresponding comparison operators. When the developer calls where(User.AGE.gt(18)), they are actually using these pre-generated metadata constants to construct type-safe query expressions. This approach completely avoids the risk of spelling errors caused by hard-coded strings.

[0055] In S4's edit request generation, the implementation of dirty checking logic relies on two state bitmaps maintained by the entity object base class: `initialized_mask` and `modified_mask`. When an attribute is assigned a value via a setter method, the system first marks `initialized_mask`, indicating that the field has entered the "set value" state. Subsequently, the system compares the old and new values; if a change has occurred, it marks `modified_mask`. When constructing the update payload, the execution unit only extracts fields where `modified_mask` is true. If a field is explicitly set to null in the business logic, the system will also check for changes based on the data. L req Constraints determine whether this operation is allowed, thus completing the first line of security on the client side.

[0056] In the S5 parsing process, streaming parsing technology is employed. When the server returns a large-scale dataset, the parsing engine does not need to load the entire JSON payload into memory at once. Instead, it instantiates objects while reading the streaming data. During this process, the parsing engine calls the type converter in real time to normalize each line of data. For example, it converts the millisecond-level timestamp returned by the server into a LocalDateTime object specified by the application layer. In addition, to prevent type mismatch issues caused by lag in server-side metadata, the parsing engine has a built-in fault tolerance mechanism. It provides weak warnings for non-critical fields that cannot be parsed, rather than directly interrupting program execution.

[0057] In S6's isolation mechanism, a custom class loader overrides the `loadClass` method. When a request is made to load an entity class, the class loader first calculates the graph context to which the request belongs. If the request originates from graph A, the class loader only searches for bytecode in the runtime directory ` / runtime / graph_A / `. This design allows both a version of the `User` class for graph A and a version for graph B to run concurrently within the same JVM process, even if the attributes of these two versions are completely different. Simultaneously, the system ensures that resource files (such as configuration files and internationalization resources) generated by each graph do not interfere with each other through physical path isolation.

[0058] In S7's synchronous updates, the atomicity of hot reloading is maintained by a global version manager. Once the synchronous update completes the compilation of the new version class, it generates a new class loader instance with an incrementing version number. At this point, the system enters a brief "preparatory switchover" state. In this state, new requests are routed to the new loader, while incomplete old requests continue to be handled by the old loader. The system monitors the reference status of active threads, triggering garbage collection when all requests associated with the old loader have been processed and are no longer referenced. This smooth transition mechanism demonstrated extremely high stability in system tests with tens of thousands of concurrent requests per second (TPS), without any ClassNotFoundException or MethodNotFoundExceptions caused by class definition changes.

[0059] In another preferred embodiment of the present invention, the system also incorporates a performance monitoring unit that works in conjunction with the execution unit. The monitoring unit collects real-time data on the query frequency, average parsing time, and editing load for each entity. This data is fed back to the synchronization update module as a basis for dynamic optimization. For example, for frequently accessed entities, the system may implement a more efficient caching strategy through metaprogramming when automatically generating code, or adopt a more direct field offset access method instead of reflection calls when generating the result parsing engine logic.

[0060] Furthermore, this invention supports automatic association of entity references across graphs. During the construction of the object description structure, if a field of entity A is found to be a reference key pointing to entity B, the system automatically generates a lazy-loading attribute in the code definition of entity A. When the business layer accesses this attribute, the system automatically triggers a query flow for entity B and utilizes the aforementioned object pool and caching mechanism to ensure the uniqueness of associated objects and loading efficiency. This automated association processing capability greatly simplifies the traversal and display logic of complex graph data.

[0061] In terms of security, the OSDK generated by this invention automatically injects tenant identifiers and permission verification tokens during the request construction phase. These security contexts are obtained from the global runtime environment of the application layer and encapsulated in a standardized JSON payload by the execution unit. In this way, this invention not only achieves structural synchronization but also ensures that the security of data access conforms to the permission policy defined at the modeling end.

[0062] The method for automatically generating OSDK based on ontology entity metadata of the present invention is implemented through a system for automatically generating OSDK based on ontology entity metadata, including: a metadata collection and normalization module, configured to interface with an external metadata source, extract raw metadata and perform integrity auditing, field name normalization, and data type normalization based on a mapping matrix, outputting normalized entity metadata; an object description structure construction module, configured to map the normalized entity metadata into a multi-dimensional object description structure, and maintain the structured projection of entity metadata in memory and the mapping relationship between physical and logical names in the object description structure; an object class and object access interface generation module, configured to output entity object classes and query interface objects with chained query capabilities based on the object description structure through a code generation engine; and an editing interface and editing request data generation module, configured to automatically map the editing capability set according to the entity's constraint rules, and incorporate a pre-validation engine and dirty checking logic, responsible for converting application-layer assignment behavior into valid editing request data.

[0063] The request construction and result parsing module is configured to implement bidirectional conversion between object operations and network protocols. It includes an execution unit for sending standardized communication requests and a result parsing engine for restoring execution results into entity object instances. The graph runtime loading and updating module is configured to manage the runtime directory in physical memory by graph dimension, maintain a graph-level object list, and implement isolated loading using a custom class loader. The synchronous update module is configured to listen for metadata change events, drive differential reconstruction of affected entities, and implement runtime hot replacement through a shadow space double-buffering switching strategy.

[0064] In summary, this invention provides a method and system for automatically generating OSDK based on ontology entity metadata. Through rigorous metadata-driven logic and an engineered automatic generation framework, it addresses core pain points in knowledge graph application development. From accurate metadata collection to scientific modeling of object description structures, and then to the automatic generation and dynamic hot-loading of multi-language code, every step demonstrates a high degree of engineering rigor. By comprehensively applying technologies such as graph isolation, dirty checking, hot reloading, and reactive programming, this invention ensures development efficiency while also considering system performance and reliability. This invention significantly reduces the development threshold and maintenance costs of knowledge graph applications, providing a solid technical foundation for building a large-scale, dynamically scalable knowledge graph application system.

Claims

1. A method for automatically generating OSDK based on ontology entity metadata, characterized in that, Includes the following steps: S1: Connect to the knowledge graph modeling service through the preset interface protocol, extract the original metadata, perform integrity verification and naming regularization on the original metadata, and complete the type normalization process according to the preset mapping matrix, convert the modeling platform type into the target programming language strong type identifier, and combine the primary key and nullable tag to form standardized entity metadata; S2: Based on standardized entity metadata, a multi-dimensional object description structure is constructed in memory as a middleware for metadata and code generation layer, including object class name, module path identifier, graph globally unique identifier, entity unique sequence number, field definition list, primary key field index set, non-null constraint field set, editable field set, and metadata display information; S3: Based on the object description structure, automatically generate target language entity object classes that inherit from the preset ontology object base class and encapsulate serialization and attribute observer logic. Implant an object access interface in the entity object class. Through this interface, obtain a query interface object with chainable call capability. The query interface object maintains a query state machine internally to achieve transparent access to the underlying graph data. S4: Based on the primary key field index set, non-null constraint field set, and editable field set in the object description structure, automatically generate the entity editing capability set. When an add or modify operation is initiated, capture field changes through the attribute observer and compare them with the constraint rules to construct editing request data containing physical field mappings. S5: Transforms application-layer object-oriented calls into standardized communication requests according to server specifications. After receiving the server response, the result parsing engine maps the original data into entity object class instances or collections based on the object description structure and performs secondary type validation. S6: Build runtime environments in isolation according to graphs, create an independent runtime directory in physical memory for each graph to store source code and bytecode files, and achieve namespace isolation between graphs through a custom class loader; S7: Poll the modeling service change log. When a metadata change is detected, trigger the differential update process. Re-execute steps S2 to S4 to generate a new object description structure and entity object class. Use the hot reload instruction to make the corresponding class loader reload the updated class definition.

2. The method for automatically generating OSDK based on ontology entity metadata according to claim 1, characterized in that, The type normalization process in step S1 also includes logic for identifying complex data structures: For fields containing arrays, JSON objects, or geospatial coordinates, they are mapped to the corresponding collection type or custom structure in the target language; when processing date and time types, a specified standard format is used as an intermediate conversion protocol, and the corresponding date parser is automatically configured when generating the entity object class; Step S1 also includes automatic handling logic for field mapping conflicts: when the original field name of an entity contains reserved keywords of the target language, a valid object attribute name is generated according to a preset renaming rule, and the mapping relationship between physical field names and logical attribute names is recorded in the object description structure. P map =( FieldName raw , AttributeName obj ), P map Map the field to a tuple. FieldName raw This is the original physical field name. AttributeName obj For object logical property names.

3. The method for automatically generating OSDK based on ontology entity metadata according to claim 1, characterized in that, The object description structure in step S2 is defined as a nine-tuple: ODS ={ N cls , M mod ID graph ID ent , L field , L pk , L req , L edit , I info}； in, N cls For object class names that follow camelCase naming conventions; M mod Used as a module path identifier; ID graph This serves as a globally unique identifier for the map; ID ent A unique serial number for the entity; L field Define a list of fields that include physical name, logical name, and normalized type; L pk Primary key field index set; L req This is a set of non-empty constraint fields; L edit This is the set of editable fields excluding the primary key. I info This includes metadata information that displays the name and meta description.

4. The method for automatically generating OSDK based on ontology entity metadata according to claim 3, characterized in that, The entity object class generated in step S3 is written into the static field definition through metaprogramming technology to record the graph ID and entity ID corresponding to the entity; the ontology object base class implements the observer pattern to monitor the change status of object attributes in real time and record it in the internal state bitmap. The object access interface adopts a reactive programming model. The query interface object realizes the streaming construction of query conditions through defined operators. Each operator call returns a new copy of the interface object to ensure the immutability of the query expression. At runtime, the chained call stack is parsed into a logical query tree to generate a standardized query domain-specific language (DSL).

5. The method for automatically generating OSDK based on ontology entity metadata according to claim 1, characterized in that, The edit request data generation process in step S4 includes a pre-validation engine: before constructing the new payload, the pre-validation engine scans the set of non-empty constraint fields. If it finds that a required field is missing, it throws a structured exception and prevents the request from entering the network layer. When constructing the modified payload, a dirty checking technique is used. By comparing the original value in the entity object class instance with the current value, only fields that have undergone actual numerical offset and belong to the set of editable fields are included in the updated payload.

6. The method for automatically generating OSDK based on ontology entity metadata according to claim 1, characterized in that, In step S5, the result parsing engine sets up a multi-level caching mechanism: it maintains an object pool in memory based on the globally unique identifier of the graph and the unique sequence number of the entity. For duplicate query requests with the same primary key identifier, the parsing engine first retrieves the instantiated objects from the object pool and uses a weak reference mechanism to manage the lifecycle of the objects. The result parsing engine adopts streaming parsing technology, instantiating objects while reading the streaming data from the server, and calling the type converter in real time to normalize each row of data.

7. The method for automatically generating OSDK based on ontology entity metadata according to claim 1, characterized in that, The graph-level isolation mechanism in step S6 also involves version isolation of third-party dependency libraries: configuring an independent resource description file for the code space generated for each graph, and maintaining a graph-level object list, which records the structural signature of each entity. When referencing entities across graphs, the validity of the reference is ensured by verifying the structural signature. When loading entity classes, the class loader prioritizes searching the runtime directory of the corresponding graph to resolve conflicts between entities with the same name.

8. The method for automatically generating OSDK based on ontology entity metadata according to claim 7, characterized in that, The synchronous update process in step S7 adopts a double-buffered switching strategy: during the process of regenerating and compiling the class file, the old version of the object class still provides services to the outside world; only when the new version class has completely passed the compilation verification and successfully loaded into the shadow space, the instantaneous reloading at runtime is achieved by switching the reference pointer of the class loader, so as to ensure that the metadata update process is unaware of the business layer in high-concurrency access scenarios.

Images