Method, apparatus, and system for ontology-based knowledge graph modeling and non-destructive bidirectional synchronization in heterogeneous database environments

Abstract

One embodiment of the present invention relates to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method, apparatus, and system for a heterogeneous database environment, wherein the method generates a knowledge graph document model including a schema structure of a property graph from ontology design information, converts the knowledge graph document model into a normalized intermediate representation specification independent of the database, and then non-destructively synchronizes it with a heterogeneous property graph database or an RDF (Resource Description Framework) triple store through an adapter corresponding to the target database.

Description

Technology Field

[0001] The following embodiments relate to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method, apparatus, and system for a heterogeneous database environment, wherein the knowledge graph document model is generated from ontology design information and includes a schema structure of a property graph, the knowledge graph document model is converted into a database-independent normalized intermediate representation specification, and then non-destructively synchronized to a heterogeneous property graph database or a Resource Description Framework (RDF) triple store through an adapter corresponding to a target database. Background Technology

[0002] Knowledge graphs are seeing an expanding scope of application in fields such as search, recommendation, data integration, question answering, GraphRAG (Graph-based Retrieval Augmented Generation), and enterprise knowledge management, as they can explicitly represent relationships between data and leverage semantic connection structures between entities. In particular, there is a growing demand to integrate internal business data, operational data stored in relational databases, semantic data accumulated in RDF triple stores, and ontology-based domain knowledge into a single knowledge graph asset.

[0003] However, conventional knowledge graph design and operation methods often involved operating ontology design tools, visual graph modeling tools, property graph databases, RDF triple stores, and relational databases in separate environments. For example, while OWL (Web Ontology Language)-based ontology editing tools can design classes, attributes, and relationships in a sophisticated manner, a separate manual conversion process is required to directly reflect the design results in property graph databases such as Apache AGE or Neo4j. During this process, errors may occur because the resolution of class hierarchies, edge type conversion of object properties, scalar type conversion of data type properties, identification key setting, and instance mapping are not handled consistently.

[0004] Furthermore, while existing visual graph modeling tools support users in intuitively designing nodes and edges, they often lack sufficient functionality to safely reflect the designed model in an actual operational database. Even if users adjust the position, color, size, and style of nodes on the canvas, these visual attributes must be distinguished from the logical graph model that needs to be reflected in the database. However, conventional tools fail to clearly separate the editor state, document state, and graph state for database reflection, posing a risk that UI operation states may become mixed with the storage or synchronization targets.

[0005] Furthermore, property graph databases and RDF triple stores utilize different data models and query languages. Property graph databases execute Cypher-based queries centered on nodes, edges, and properties, whereas RDF triple stores operate based on SPARQL queries using triples composed of subject, predicate, and object. Consequently, even when representing the same domain knowledge, the representation of schemas, instances, identifiers, and relationships differs between LPG (Labelled Property Graph) and RDF environments. While some conventional technologies support RDF import / export or Cypher / SPARQL concurrent queries within a specific vendor or single platform, these are often dependent on specific database products or limited to transformations at the data level.

[0006] In particular, conventional graph database migration or synchronization methods often involve completely replacing existing data in the target database or executing change queries immediately without prior user validation. Such approaches can lead to problems in the production environment, such as the unintended deletion of existing data or the execution of queries based on previous preview results even after the document model has been modified. Therefore, a non-destructive synchronization structure is required that provides users with a list of change queries, insertion targets, update targets, deletion targets, and summary information in advance before reflecting changes to the knowledge graph model in the actual database, and enables verification of document changes at the time of application.

[0007] Furthermore, in heterogeneous database environments, supported features vary by target database. For example, some databases may support multi-labeling, while others may not. Consequently, even when converting the same ontology hierarchy into a property graph schema, superclass information must be flattened into meta-properties or merged property templates for specific databases, whereas a multi-labeling strategy that assigns both superclass and subclass labels must be applied for others. Conventional single-vendor dependent tools have limitations in adaptively applying the same design assets to heterogeneous databases because they reflect these differences in capabilities across adapters.

[0008] Problems also exist in the process of generating a property graph model from an RDF triple store. While entities in RDF are often identified by IRIs, property graphs require an identification key to uniquely identify node instances. Depending on which value is chosen as the identification key from various candidates—such as IRI local parts, explicit identifier properties, schema.org-based attribute values, or hash values—identical entities may be created as duplicate nodes, or different entities may be merged into a single node. Therefore, when converting RDF triples to a property graph document model, criteria are required to automatically infer the identification key based on cascading priority rules and maintain data integrity during resynchronization.

[0009] Furthermore, large-scale RDF triple stores may store multiple Named Graphs, instances of various classes, and triples irrelevant to business purposes. In such cases, loading the entire RDF dataset in bulk and converting it into a document model can lead to excessive increases in memory usage, network bandwidth, and conversion time. Therefore, a scoping method is required that allows users to selectively collect only the necessary subgraphs based on specific Named Graphs, specific classes, or user-defined SPARQL CONSTRUCT queries, and convert them into a Knowledge Graph document model.

[0010] Meanwhile, in enterprise environments, there is also a demand to convert information regarding tables, columns, primary keys, foreign keys, and join tables accumulated in existing relational databases into knowledge graphs. Although relational databases are the most widely used storage structure in business systems, there are cases where semantic relationships between tables are not clearly defined by foreign keys, or where logical relationships exist only in separate mapping documents. In such cases, converting the relational schema into node labels, edge types, and property templates requires a combination of automated schema lookup, external mapping definition files, LLM-based mapping draft generation, and user review procedures.

[0011] Ultimately, conventional technologies failed to integrate ontology design, property graph modeling, RDF triple store integration, relational database import, heterogeneous database adapters, non-destructive synchronization, and source-independent editing environments into a single normalized workflow. Consequently, users had to individually handle tool-to-tool conversion, manual mapping, vendor-specific query writing, synchronization verification, and data loss prevention, which increased the complexity, error tolerance, and maintenance costs associated with building and operating knowledge graphs. Prior art literature

[0012] (Patent Document 0001) KR 10-2400201 B (Patent Document 0002) KR 10-2265304 B (Patent Document 0003) KR 10-1014429 B The problem to be solved

[0013] The problem to be solved by one embodiment of the present invention is to provide an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method, apparatus, and system for a heterogeneous database environment, which, in order to overcome the limitations of conventional knowledge graph design and database synchronization technologies as described above, automatically generate a knowledge graph document model including a schema structure of a property graph from ontology design information, convert the knowledge graph document model into a normalized intermediate representation specification independent of the database, and then non-destructively link to a heterogeneous database through an adapter corresponding to the target database. means of solving the problem

[0014] According to one embodiment, in an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment, wherein a device includes a processor, memory, a communication module, and a non-transient storage medium, and the method is performed by the processor by executing a program stored in the non-transient storage medium, the method comprises: a modeling operation that identifies an adapter type corresponding to a target database based on a connection profile, extracts ontology components from ontology design information, and generates a knowledge graph document model including a schema structure of a property graph according to a pre-set conversion rule; a normalization operation that generates a Normalized Intermediate Specification (NSP) from the knowledge graph document model that excludes visual attributes and is independent of the database, corresponding to the type of the target database; and a query conversion operation that converts the Normalized Intermediate Specification into a specialized query specialized for the target database through the adapter. The present invention provides an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment, comprising: a non-destructive bidirectional linkage operation that uses the specialized query to incrementally reflect changes to the knowledge graph document model while preserving existing data in the target database, or collects and analyzes data stored in the target database and inversely transforms it into the knowledge graph document model to reflect it.

[0015] In addition, the above non-destructive bidirectional linkage operation comprises: a preview provision operation that, without immediately reflecting the above specialized query in the target database, generates synchronization plan data including a list of specialized queries and synchronization summary information in response to a synchronization preview request received from a client terminal, transmits the synchronization plan data to the client terminal so that the synchronization plan data is visually displayed as a preview interface on the screen of the client terminal, and temporarily stores the synchronization plan data for a preset validity period (TTL); And when a user’s apply request for synchronization plan data is received from the client terminal, a first hash value for the knowledge graph document model at the time of the preview provision operation and a second hash value for the knowledge graph document model at the time of receiving the apply request are compared to verify whether the document has been modified in the middle, and a transaction-based specialized query is executed on the target database only if the first hash value and the second hash value match, and an application operation that invalidates the synchronization plan data if the first hash value and the second hash value do not match; thereby, the system can prevent existing data loss in the operating environment and ensure system integrity.

[0016] And, the above modeling operation includes: a hierarchy resolution strategy determination operation that adaptively determines a hierarchy resolution strategy by referring to the supportsMultiLabel parameter within the capability information (AdapterCapabilities) declaratively provided by the adapter when mapping the hierarchy (rdfs:subClassOf) between the superclass and subclass included in the above ontology design information to the schema structure of the property graph; and the hierarchy resolution strategy determination operation includes: for a first type adapter in which the supportsMultiLabel parameter is identified as False, a flattening strategy application operation that generates the knowledge graph document model by applying a flattening strategy that resolves the inheritance relationship into a single hierarchy by physically copying and merging the property template defined in the superclass to the node label definition of the subclass; For a second type adapter in which the multi-label support parameter is identified as True, a multi-label strategy application operation is included to generate the knowledge graph document model by applying a multi-label strategy defined to maintain separate property templates for each of the upper class and lower class, while assigning multiple labels corresponding to the upper class and lower class in parallel when creating a single node instance; thereby ensuring query integrity across a heterogeneous environment by fully preserving the hierarchical logic and polymorphism of the original ontology without being dependent on the physical schema constraints of the target database vendor.

[0017] In addition, the above-mentioned non-destructive bidirectional linkage operation further includes: an automatic identification key inference operation for determining an identity key to uniquely identify a single node in order to map each entity within the data collected from the target database to a single node of the property graph; wherein the automatic identification key inference operation comprises, according to a pre-configured cascading priority rule: a first inference operation as a first priority, extracting a local part from an IRI (Internationalized Resource Identifier) ​​which is the identifier of the entity and designating it as the identification key; a second inference operation as a second priority, if extraction through the first inference operation is impossible, designating the value of an explicit identifier property assigned to the entity as the identification key; and a third priority, if the explicit identifier property is absent, a pre-configured standard vocabulary (schema.A third inference operation is executed by extracting a universal attribute value based on org) and designating it as the identification key; and a fourth inference operation is executed as a fourth priority, wherein if the universal attribute value does not exist in the third inference operation, a hash value is calculated for the entire string of the IRI, and if the IRI does not exist, a hash value is calculated for at least one of a triple set corresponding to the entity, a blank node identifier, and an internal temporary identifier, and finally designated as the identification key; and the knowledge graph document model that has been reverse-transformed based on the automatically inferred identification key is loaded in the form of a Source-Agnostic Canvas having the same schema structure and operation method on a visual editing canvas regardless of whether the source of the initial data is a property graph or an RDF (Resource Description Framework) triple store, thereby reducing the possibility of identifier collisions between heterogeneous data models and providing a criterion for re-identification in the event of a collision, thereby ensuring data integrity during re-synchronization of the reverse-transformed data.

[0018] In addition, the above non-destructive bidirectional linkage operation includes: a selective collection operation that collects data by selecting one of three pre-configured reverse transformation range modes to selectively extract only subgraphs suitable for the purpose from a large-scale knowledge base when the target database is an RDF triple store; and the selective collection operation includes: a first collection mode that independently extracts and reverse transforms only the set of triples existing within the specific named graph context based on the identifier (IRI) of a specified specific named graph among a plurality of named graphs logically partitioned within the target database; a second collection mode that filters and transforms only instances and properties associated with at least one target class specified by the user based on an ontology hierarchy; and a third collection mode that executes a custom SPARQL CONSTRUCT query written directly by the user to extract and transform the set of triples corresponding to the user-defined query result. By performing this through either of the above methods, it is possible to prevent system overhead and wasted network bandwidth resulting from loading the entire large-scale RDF dataset into memory, and to support the dynamic extraction and construction of domain-specific knowledge graphs specialized for specific business logic.

[0019] A device according to one embodiment may be combined with hardware and controlled by a computer program stored on a medium to execute the method of any one of the methods described above. Effects of the invention

[0020] According to one embodiment, ontology components can be extracted from ontology design information and converted into a knowledge graph document model that includes the schema structure of a property graph. Accordingly, the burden of manual conversion between OWL-based ontology design and property graph database implementation can be reduced, and errors that may occur during the conversion process of classes, relationships, and attributes can be reduced.

[0021] Furthermore, the knowledge graph document model can be converted into a normalized intermediate representation specification that excludes visual attributes, rather than being directly dependent on the target database. Accordingly, this prevents editor-specific information, such as coordinates, colors, sizes, styles, or selection states on the canvas, from being unnecessarily reflected in the operational database, and enables the stable synchronization of only the logical graph structure.

[0022] In addition, based on the connection profile, the adapter type corresponding to the target database can be identified, and the normalized intermediate representation specification can be converted into a query specialized for the target database. Accordingly, the same knowledge graph document model can be applied in a manner suitable for property graph databases such as Apache AGE and Neo4j, or RDF triple stores such as GraphDB, and dependency on a specific database vendor can be reduced.

[0023] Furthermore, by utilizing specialized queries, changes to the Knowledge Graph Document Model can be incrementally reflected while preserving existing data, or data stored in the target database can be collected and analyzed to perform reverse conversion into the Knowledge Graph Document Model. Accordingly, it supports both the direction of reflecting Knowledge Graph design assets into the database and the direction of bringing Knowledge Graph assets accumulated in the database back into the Document Model, enabling the integrated management of both LPG and RDF within a single workflow.

[0024] In addition, in response to a synchronization preview request, synchronization plan data including a list of specialized queries and synchronization summary information can be generated and displayed on the preview interface of the client terminal. Accordingly, users can check the contents of schemas, nodes, edges, or triples to be changed before actual application, and review unexpected changes to the operational database in advance.

[0025] Additionally, synchronization plan data is temporarily stored for a pre-set validity period, and upon receiving an application request, the document hash value at the time of providing the preview can be compared with the document hash value at the time of receiving the application request. Accordingly, if the document has changed since the preview, the existing synchronization plan can be invalidated, and the execution of incorrect queries based on outdated or inconsistent plans can be prevented.

[0026] In addition, transaction-based specialized queries can be executed only when the hash values ​​match. Accordingly, this reduces the problem of data consistency being compromised when only partial queries are applied during the synchronization process, and ensures systemic integrity in the production environment.

[0027] Furthermore, when mapping the hierarchical structure between superclasses and subclasses included in the ontology design information to the schema structure of the property graph, the strategy for resolving the hierarchy can be adaptively determined based on whether the adapter supports multiple labels. Accordingly, even if the target database does not support multiple labels, hierarchical information can be reflected through a flattening strategy; conversely, if multiple labels are supported, superclass and subclass labels can be assigned together to maintain the ontology hierarchy logic more naturally.

[0028] Furthermore, for adapters that do not support multiple labels, the property template defined in the superclass can be merged into the node label definition of the subclass to resolve the issue into a single layer. Accordingly, even in databases without multi-label capabilities, subclass nodes can utilize the attribute structure of the superclass, and ontology-based modeling results can be reflected despite the physical schema constraints of the target database.

[0029] In addition, for adapters that support multiple labels, multiple labels corresponding to superclasses and subclasses can be assigned in parallel to a single node instance. Accordingly, both superclass-based and subclass-based queries can be supported, and a polymorphic query environment can be implemented where the same node belongs to multiple semantic hierarchies.

[0030] Furthermore, when mapping entities collected from an RDF triple store to a single node in a property graph, identification keys can be automatically inferred based on cascading priority rules. This can mitigate the difference between the IRI-based identification scheme in an RDF environment and the business key-based identification scheme in a property graph environment, and reduce the possibility of identical entities being generated as duplicate nodes during the reverse transformation process.

[0031] Furthermore, if an IRI local part exists, it is utilized as the identification key; otherwise, explicit identifier properties, schema.org-based universal attribute values, and hash values ​​can be applied sequentially. Accordingly, even if the RDF triple creation methods or data quality differ, criteria for re-identification can be assigned to each entity, and data integrity can be ensured during resynchronization.

[0032] Furthermore, the inversely transformed Knowledge Graph document model can be loaded as a source-independent canvas regardless of the source of the original data. Accordingly, graphs imported from RDF triple stores, property graph databases, relational databases, or user-created graphs can be processed with the same schema structure and editing method.

[0033] Additionally, if the target database is an RDF triple store, the inverse transformation range can be selected based on a specific Named Graph, target class, or Custom SPARQL CONSTRUCT query. This allows for the selective collection of only the sets of triples suitable for the intended purpose, without unnecessarily loading the entire large RDF dataset into memory.

[0034] Furthermore, since only the set of triples within the Named Graph context can be extracted independently, only the necessary graphs can be inversely transformed without interference, even when multiple business domain or document-unit graphs exist within the same RDF triple store. Accordingly, the scope of data collection can be clearly limited, and network bandwidth and transformation processing costs can be reduced.

[0035] In addition, only instances and properties associated with the target class can be filtered based on the ontology hierarchy. Accordingly, only the partial knowledge graphs necessary for specific business purposes or domain analysis can be quickly constructed, and the inclusion of unnecessary classes and relationships in the document model can be reduced.

[0036] In addition, it is possible to collect sets of triples corresponding to the results of user-defined Custom SPARQL CONSTRUCT queries. Accordingly, business conditions, relationship patterns, or subgraph extraction conditions that are difficult to express using basic Named Graph or class filter methods can be reflected in a user-defined manner.

[0037] Furthermore, semantic data assets stored in the RDF Triple Store can be reused within the Property Graph ecosystem, and conversely, Knowledge Graph document models edited on Canvas can be synchronized back to the RDF Triple Store. As a result, even in organizational environments where LPG and RDF coexist, Knowledge Graphs can be built, edited, verified, and operated around a single design asset.

[0038] Furthermore, it can be combined in the future with relational database schema import, automatic LLM-based mapping suggestions, natural language-based ontology generation, and schema metadata export for GraphRAG. Accordingly, ontologies, relational databases, RDF triple stores, and natural language domain descriptions can be processed within a single integrated knowledge graph platform, thereby improving the accuracy of knowledge graph-based query answering and data utilization. Brief explanation of the drawing

[0039] FIG. 1 is a schematic diagram showing an ontology-based knowledge graph modeling and non-destructive bidirectional linkage system for a heterogeneous database environment according to an embodiment of the present invention. FIG. 2 is a diagram showing the flowchart of the conversion process from an ontology to a document schema according to the ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 3 is a diagram showing the overall transformation pipeline flowchart according to the ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 4 is a sequence diagram of a non-destructive synchronization process according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 5 is an adapter architecture class diagram according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 6 is a comparative diagram of class hierarchy resolution strategies according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 7 is a diagram showing an integrated studio interface layout wireframe according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 8 is a diagram showing the separation relationship of three boundary models according to the ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 9 is an extended overall data flow diagram according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 10 is a flowchart of the conversion from a relational database schema to a property graph model according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 11 is a flowchart of GraphRAG utilization according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 12 is a flowchart of an LLM-based relational schema mapping automatic proposal method according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 13 is a flowchart of the automatic generation of an LLM-based natural language ontology according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 14 is a flowchart of non-destructive synchronization of an RDF triple store according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 15 is a flowchart of an RDF triple store import according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. FIG. 16 is an adapter layer extension diagram according to an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment according to an embodiment of the present invention. Specific details for implementing the invention

[0040] Hereinafter, embodiments are described in detail with reference to the attached drawings. However, various modifications may be made to the embodiments, and thus the scope of the patent application is not limited or restricted by these embodiments. It should be understood that all modifications, equivalents, and substitutions to the embodiments are included within the scope of the rights.

[0041] Specific structural or functional descriptions of the embodiments are disclosed for illustrative purposes only and may be modified and implemented in various forms. Accordingly, the embodiments are not limited to the specific disclosed forms, and the scope of this specification includes modifications, equivalents, or substitutions that fall within the technical concept.

[0042] Terms such as "first" or "second" may be used to describe various components, but these terms should be interpreted solely for the purpose of distinguishing one component from another. For example, the first component may be named the second component, and similarly, the second component may be named the first component.

[0043] When it is stated that a component is "connected" to another component, it should be understood that it may be directly connected to or coupled with that other component, or that there may be other components in between.

[0044] The terms used in the embodiments are for illustrative purposes only and should not be interpreted as intended to be limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprising" or "having" are intended to indicate the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0045] In particular, where a 'step' in this specification is described as 'comprising' one or more detailed steps or sub-steps, said 'step' may be interpreted as including its own basic processing step while simultaneously performing the described detailed steps as well.

[0046] For example, if it is stated that 'a step of doing B to A' includes 'a step of doing D to C; a step of doing F to E; and a step of doing H to G,' the 'step of doing B to A' may be interpreted not merely as the basic operation of doing B to A, but as a configuration that performs detailed procedures together, such as a step of doing D to C, a step of doing F to E, and a step of doing H to G.

[0047] Accordingly, the above configuration does not exclude various sub-procedures included within the scope of execution of the corresponding step, and may be included within the scope of the present invention even if other procedures or means performing substantially the same or equivalent functions are substituted.

[0048] Expressions such as 'end part', 'both ends', 'one end', 'other end', and 'side end' of a component can be interpreted as referring to at least / any one of the end parts of that component.

[0049] In the description of the present invention, 'a method in which a device comprises a processor, a memory, a communication module, and a non-transient storage medium, and a program stored in the non-transient storage medium is executed by the processor,' the term 'method' may be interpreted as referring to the program stored in the non-transient storage medium itself or a part of the program.

[0050] The term 'Return' as used in the description of the present invention may refer to a result value being output, returned, or returned from a method, procedure, function, etc. used in a given program language / structure.

[0051] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the embodiments pertain. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application. For example, the term 'artificial intelligence model' may be selected from one or more of known general artificial intelligence models.

[0052] In addition, when describing with reference to the attached drawings, identical components are assigned the same reference numeral regardless of drawing symbols, and redundant descriptions thereof are omitted. In describing the embodiments, if it is determined that a detailed description of related prior art could unnecessarily obscure the essence of the embodiments, such detailed description is omitted.

[0053] According to one embodiment, in an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment, wherein a device includes a processor, memory, a communication module, and a non-transient storage medium, and the method is performed by the processor by executing a program stored in the non-transient storage medium, the method comprises: a modeling operation that identifies an adapter type corresponding to a target database based on a connection profile, extracts ontology components from ontology design information, and generates a knowledge graph document model including a schema structure of a property graph according to a pre-set conversion rule; a normalization operation that generates a Normalized Intermediate Specification (NSP) from the knowledge graph document model that excludes visual attributes and is independent of the database, corresponding to the type of the target database; and a query conversion operation that converts the Normalized Intermediate Specification into a specialized query specialized for the target database through the adapter. The present invention provides an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment, comprising: a non-destructive bidirectional linkage operation that uses the specialized query to incrementally reflect changes to the knowledge graph document model while preserving existing data in the target database, or collects and analyzes data stored in the target database and inversely transforms it into the knowledge graph document model to reflect it.

[0054] The above device may be implemented as a server, cloud server, on-premises server, workstation, or a combination thereof that performs knowledge graph modeling and database linkage functions in a heterogeneous database environment. A processor included in the above device may execute program instructions stored in the above non-transient storage medium to perform ontology analysis, adapter type identification, knowledge graph document model generation, normalization intermediate representation specification generation, target database-specific query transformation, and non-destructive bidirectional linkage processing.

[0055] The memory may be configured to temporarily store ontology design information, connection profiles, knowledge graph document models, normalization intermediate representation specifications, specialized queries, synchronization plan data, and inverse transformation intermediate data processed by the processor. The communication module may be a wired or wireless communication interface for communicating with a client terminal, a property graph database, an RDF triple store, a relational database, or an external authentication server. The non-temporary storage medium may be a storage means for storing program code, adapter registry, transformation rules, database connection settings, document model storage, and synchronization history information.

[0056] The modeling operation is an operation that identifies the adapter type of the target database to be integrated by referencing the connection profile, extracts ontology components from the input ontology design information, and generates a knowledge graph document model containing the schema structure of the property graph by converting them according to pre-configured transformation rules. Here, the modeling operation does not simply refer to the operation of saving an ontology file, but rather to the operation of reconstructing the domain concepts, attributes, and relationships defined in the ontology into document objects that are editable in an actual graph modeling environment and capable of database integration.

[0057] A connection profile may refer to a set of configuration information necessary for connection and integration with a target database. For example, a connection profile may include at least one of the target database type, connection address, port, authentication account information, authentication token, database name, graph name, named graph identifier, query language, driver information, and adapter identifier. Accordingly, the device can automatically determine a suitable integration method by analyzing the database type and connection information included in the connection profile, even if the user does not explicitly select a database-specific query generation method.

[0058] The target database refers to a database in which data is stored to be synchronized with or inversely transformed into the knowledge graph document model. For example, the target database may be a property graph database such as Neo4j or Apache AGE that stores data based on nodes, edges, and properties, a Resource Description Framework (RDF) triple store that stores data based on triples consisting of subject, predicate, and object, or a relational database that stores entities and relationships through a relational schema.

[0059] An adapter type refers to a type of interface module classified to standardize and handle the physical schema constraints, connection methods, and query language characteristics of various heterogeneous database systems within a common system architecture. For example, adapter types can be classified into adapter types for property graph databases, adapter types for RDF triple stores, or adapter types for relational database imports. The device analyzes a connection profile to determine whether the target database uses Cypher-based queries, SPARQL-based queries, or requires SQL-based schema lookups, and can identify the corresponding adapter type.

[0060] The adapter described above refers to a bridge-type software module that converts a common normalized intermediate representation within the system into the unique language and protocol of an individual database. The adapter can convert database-independent normalized intermediate representation specifications into commands or queries that the target database can understand, and can provide capability information to absorb functional differences of the target database. The capability information may include at least one of multi-label support, transaction support, named graph support, RDF-star support, label inheritance support, and the requirement for query wrapping.

[0061] The above device may include an adapter registry for registering, querying, and creating adapters corresponding to a plurality of target databases. The adapter registry stores a mapping between an adapter type identifier and an adapter factory function, and can create a suitable adapter instance based on the type of target database, query language, connection protocol, or adapter identifier included in the connection profile.

[0062] The adapter registry described above can be configured to allow the addition of new adapter types and adapter creation logic without directly modifying the code of existing modeling operations, normalization operations, or query transformation operations to support new databases. For example, the adapter registry may manage Apache AGE adapters, Neo4j adapters, RDF triple store adapters, or adapters for relational database imports as separate adapter types.

[0063] The adapter registry described above may perform at least one of an adapter registration operation, an adapter creation operation, an adapter list return operation, and an adapter capability information return operation. The adapter registration operation is an operation of storing an adapter type identifier and an adapter factory function, the adapter creation operation is an operation of creating an adapter instance corresponding to a connection profile, and the adapter list return operation may be an operation of returning a list of adapter types available on the current device.

[0064] The above adapter may be implemented as a hierarchical structure including a common base adapter (BaseAdapter), a property graph adapter (LpgAdapter), and an RDF adapter (RdfAdapter). The common base adapter may be a higher-level interface that defines connection operations, disconnection operations, connection test operations, capability information return operations, and adapter family identification operations that are commonly required regardless of the type of target database.

[0065] The above property graph adapter may be a lower adapter layer for interacting with Neo4j, Apache AGE, or a similar property graph database. The above property graph adapter may perform at least one of checking for graph existence, node upsert, edge upsert, index creation, generating queries based on normalized graph specifications, and executing queries. For example, a Neo4j adapter may generate pure Cypher queries, and an Apache AGE adapter may generate Cypher queries wrapped in SQL.

[0066] The above RDF adapter may be a lower adapter layer for interoperating with an RDF triple store. The above RDF adapter can perform at least one of the following operations: querying a list of named graphs, querying triples of a specified named graph, calculating the difference between an existing triple and a new triple, generating a SPARQL UPDATE query, and executing a synchronization plan. Accordingly, the device can integrately interoperate through a common adapter layer even if the property graph database and the RDF triple store use different data models and query languages.

[0067] According to the hierarchical structure of the aforementioned common base adapter, property graph adapter, and RDF adapter, database-specific functions can be handled by lower-level adapters, while common functions such as connection management, capability information provision, and adapter identification can be consistently handled by higher-level adapters. Consequently, even when adding a new database vendor in a heterogeneous database environment, the system can be scaled at the adapter level without altering the overall system structure.

[0068] Ontology design information refers to structured design data that formally defines concepts, attributes, and relationships for a specific domain. The ontology design information may be provided in the form of OWL (Web Ontology Language), RDF, RDFS, Turtle, RDF / XML, JSON-LD, or an ontology document format defined internally within the device. The ontology design information may include at least one of a class, a hierarchy between a superclass and a subclass, an object property, a data type property, a domain, a range, a constraint, a label, annotations, and instance example information.

[0069] The above ontology design information may include ontology design information at the OWL 2 EL profile level. Here, the OWL 2 EL profile may refer to an ontology representation range capable of relatively efficiently handling large-scale class hierarchies, existence restrictions, class inclusion relationships, and property-based inference, and may be an ontology representation format suitable for domains where multiple conceptual layers and relationships appear repeatedly, such as medical, manufacturing, organizational management, product classification, and business knowledge structures.

[0070] The device can extract at least one of owl:Class, rdfs:subClassOf, owl:ObjectProperty, owl:DatatypeProperty, rdfs:domain, rdfs:range, rdfs:label, and rdfs:comment defined at the OWL 2 EL profile level, and convert it into node label definitions, edge type definitions, property templates, hierarchical information, and descriptive metadata of the knowledge graph document model. Accordingly, the device can reconstruct domain concepts and relationship definitions included in the ontology design information into schema components that can be directly edited in the property graph model.

[0071] The above device prioritizes interpreting class hierarchies and property definitions supported by the OWL 2 EL profile, but if complex restrictive expressions, anonymous class expressions, or logical expressions that are difficult to express directly in the target database are included that fall outside the scope of the OWL 2 EL profile, it may classify the corresponding elements as warning information, comment metadata, or a list of unsupported elements. In this case, the device may generate a knowledge graph document model based on the supported ontology components and provide guidance information so that the user can manually supplement or override the unsupported elements.

[0072] As described above, by prioritizing support for ontology design information at the OWL 2 EL profile level, the device can reliably extract classes, hierarchies, object properties, and data type properties created in an ontology editing tool, and efficiently convert actual schema information required for knowledge graph modeling without forcibly reflecting the entire complex logical reasoning into the target database.

[0073] An ontology component refers to a basic unit for creating a knowledge graph model extracted from the ontology design information. For example, an ontology component may include a class defined by owl:Class, a class hierarchy defined by rdfs:subClassOf, relationships between classes defined by owl:ObjectProperty, attributes defined by owl:DatatypeProperty, scopes defined by rdfs:domain and rdfs:range, and label or descriptive information for each component.

[0074] The configured transformation rules are a set of predefined rules for converting ontology components into schema components of a property graph. For example, classes can be converted into node label definitions, object properties into edge type definitions, and data type properties into property templates assigned to nodes or edges. Additionally, class hierarchies can be converted using either a flattening method or a multi-label method, depending on whether the target database supports multi-labels.

[0075] The above device can manage the relationship between the ontology design information and the document schema of the knowledge graph document model in either a Derive mode or an Override mode. The Derive mode may be a mode that automatically generates a document schema based on the ontology design information and maintains the generated document schema as dependent on the original ontology design information. In the Derive mode, rather than the user arbitrarily changing the document schema, the node label definitions, edge type definitions, and property templates can be updated by re-analyzing changes in the original ontology design information.

[0076] In the above-described derivation mode, when owl:Class is added to the original ontology design information, a corresponding node label definition is automatically generated, when owl:ObjectProperty is added, a corresponding edge type definition is automatically generated, and when owl:DatatypeProperty is added, a corresponding property template can be automatically generated. Additionally, when the rdfs:subClassOf relationship changes, the device can update the reflection method of the class hierarchy by reapplying a flattening strategy or a multi-label strategy according to the adapter capability information of the target database.

[0077] The above override mode may be a mode that allows a user to add, modify, or supplement node label definitions, edge type definitions, property templates, display names, relationship directions, or synchronization settings at the document level of the knowledge graph document model after automatically generating an initial document schema from the ontology design information. For example, a property template for business convenience that does not exist in the ontology design information can be added to the document model, or the display name of a specific edge type can be changed to match actual business terminology.

[0078] In the above override mode, components derived from the original ontology design information and components added or modified by the user at the document level can be managed separately. To this end, the device may store schema source metadata for each node label definition, edge type definition, and property template, including at least one of the original ontology IRI, whether it is derived, whether it is modified by the user, the time of modification, and the conflict status.

[0079] When the original ontology design information is updated, the device can automatically regenerate the document schema based on the updated ontology design information in derived mode, and in override mode, classify merge candidates, conflict candidates, and retention candidates by comparing changes in the original ontology with user modifications. For example, if the type of a specific data type property in the original ontology is changed but the user separately modifies the type of the same property in the document model, the device can mark this as a conflict candidate and request user confirmation.

[0080] According to the above-mentioned derivation and override modes, it is possible to support both an automatic conversion workflow that strictly follows ontology design information and a flexible workflow that allows for document-level corrections considering the actual database operating environment or business convenience. Accordingly, users can practically adjust the knowledge graph document model to align with physical constraints specific to target databases or internal business terminology while maintaining the design consistency of the original ontology.

[0081] The schema structure of a property graph refers to a logical graph structure including node labels, edge types, property templates, identification keys, index candidates, relationship directions, acceptable source node labels, and destination node labels. The schema structure of the property graph may not be a physical schema immediately reflected in the actual database, but rather a logical design structure managed within the knowledge graph document model.

[0082] For example, if the ontology design information defines a superclass named "Person," a subclass named "Employee," a data type property named "Name," and an object property named "Belongs to a Company," the modeling operation can analyze this to generate node label definitions corresponding to "Person" and "Employee," generate a property template corresponding to "Name," and generate an edge type definition corresponding to the relationship "Belongs to a Company." Accordingly, the ontology design information can be automatically converted into a draft of a knowledge graph document model that the user can visually edit.

[0083] A knowledge graph document model is a data model that represents knowledge graph design and instance information generated from ontology design information or an external database as a single document unit. The knowledge graph document model may include at least one of node label definitions, edge type definitions, property templates, node instances, edge instances, layout information, style information, synchronization setting information, and ontology reference information.

[0084] The above knowledge graph document model can represent the document state used in a visual editing environment. That is, the knowledge graph document model may include logical schema and instance information to be reflected in the database, along with visual information such as node location, edge placement, color, display name, size, collapse status, and selection status required for the user to edit on the canvas. However, such visual information may be excluded from being reflected in the database during the normalization operation described later.

[0085] The normalization operation is an operation that extracts only the logical graph structure that can be reflected in the target database from the knowledge graph document model and generates a normalized intermediate representation specification independent of the database. In the normalization operation, visual attributes such as coordinates, color, size, border thickness, zoom level, selection state, hover state, temporary highlight, UI panel state, and editing state that are required only in the visual editing canvas may be removed.

[0086] The exclusion of visual attributes means that frontend-dependent data unrelated to the database's logical schema updates or instance data—such as the X and Y coordinates where a user places a node by dragging a mouse in a studio interface, node color, edge style, and canvas zoom scale—is not included in the Normalized Intermediate Representation specification. For example, even if a node is placed at X-coordinate 300 and Y-coordinate 150 on the canvas and displayed in blue, this coordinate and color information may not be included in the Normalized Intermediate Representation specification. Consequently, only logical schema, instance, and relationship information can be reflected in the target database.

[0087] A normalized intermediate expression specification refers to a standardized internal representation that is not dependent on a specific database vendor or query language. The aforementioned normalized intermediate expression specification may be a logical structure at the stage immediately preceding alignment with the individual query language structure required by a specific database engine, and may refer to a specification in a form that can be universally interpreted regardless of the type of database.

[0088] The above normalized intermediate representation specification can be derived in the form of a normalized graph specification or a normalized triple specification, respectively, depending on whether the target database is a property graph database or an RDF triple store. Here, the normalized graph specification may include at least one of a list of node labels, a list of edge types, a list of properties, an identification key, index creation candidates, a node upsert plan, and an edge upsert plan. The normalized triple specification may include at least one of a subject, a predicate, an object, a graph identifier, and synchronization metadata.

[0089] In the normalization operation, each node label definition included in the knowledge graph document model can be converted into normalized node type information, and each edge type definition can be converted into normalized relationship type information. Additionally, for each property template, the name, data type, required status, default value, multi-value allowance, and index candidate status can be converted into normalized field information. Accordingly, the aforementioned normalization intermediate representation specification may include only data update information that needs to be purely reflected in the database.

[0090] The query transformation operation is the operation of converting vendor-neutral normalized intermediate representation specifications through the previously identified adapter into specialized queries that the target database can actually read and execute. The aforementioned specialized query refers to final statements or request data that the target database engine can directly interpret and execute without syntactic errors.

[0091] If the target database is a property graph database, the specialized query may be a Cypher-based query for node creation, edge creation, node upsert, edge upsert, or index creation. If the target database is an RDF triple store, the specialized query may be a SPARQL UPDATE query. If the target database is a relational database, the specialized query may be an SQL query for schema lookup, metadata extraction, or row data collection.

[0092] Query transformation through the above adapter may be a structural transformation that reflects the capabilities and constraints of the target database, rather than a simple string substitution. For example, if the target database is Neo4j, the adapter can convert the normalized intermediate expression specification into pure Cypher query syntax and return it. On the other hand, if the target database is Apache AGE, which operates based on a relational database, the adapter can convert Cypher syntax into a query in the form of an SQL function call or wrapped inside an SQL statement. Additionally, if the target database is an RDF triple store, the adapter can generate SPARQL UPDATE syntax based on the normalized triple specification.

[0093] The adapter described above can function as a transformation layer that absorbs differences in execution environments depending on the target database. For example, if a target database does not support multiple labels, the adapter can transform multiple class labels into a single node label and a parent class meta-property. Conversely, if the target database supports multiple labels, the adapter can generate a query that assigns both a parent class label and a child class label to a single node.

[0094] Non-destructive bidirectional integration is an operation that controls the reflection of changes in the Knowledge Graph Document Model to the target database or the inverse transformation of data stored in the target database into the Knowledge Graph Document Model, while ensuring that existing data is not arbitrarily deleted or entirely replaced. Here, non-destructive integration is a concept contrasted with destructive methods, which completely initialize and overwrite existing tables, graphs, nodes, edges, triples, or properties when synchronizing a database; it refers to a processing method that protects existing instance data and guarantees integrity by preventing the arbitrary deletion of data without explicit user approval or verification.

[0095] Incrementally reflecting changes to the above knowledge graph document model means that instead of creating the entire knowledge graph anew or initializing the target database every time, only insert, update, or limited delete commands corresponding to the difference between the previous state and the current state are generated and applied. For example, if a user requests synchronization by adding a new node label called “Project” and a new edge type called “Participate” to a target database containing 100,000 existing data records, the device may not delete the entire database and re-enter the 100,000 data records from scratch, but may generate and execute only specialized queries corresponding to the newly added node label and edge type.

[0096] Preserving existing data in the target database means ensuring that operational data already existing within the target database, data separately created by users, data generated by external systems, or previous synchronization results are not deleted by default during the synchronization process. Accordingly, the device may use upcert, merging, conditional generation, and difference-based update methods to apply a new model, rather than deleting the entire existing graph.

[0097] Bidirectional integration refers to supporting both forward integration, which reflects modifications to a Knowledge Graph Document Model edited in the integrated canvas environment into the target database, and reverse integration, which reads schema and instance data stored in the target database to create or update the Knowledge Graph Document Model. For example, in forward integration, node labels, edge types, and property templates designed by the user in the canvas can be reflected in the target database in the form of specialized queries, while in reverse integration, semantic data newly added to the target database by an external system can be collected and transformed back into nodes and edges of the Knowledge Graph Document Model.

[0098] Collecting and analyzing data stored in the aforementioned target database to inversely transform it into a Knowledge Graph Document Model means reading nodes, edges, properties, triples, or schema information existing in the target database and reconstructing them into the Knowledge Graph Document Model structure within the device. For example, class, object properties, data type properties, and instance triples collected from an RDF triple store can be transformed into node label definitions, edge type definitions, property templates, node instances, and edge instances.

[0099] According to the aforementioned non-destructive bidirectional integration operation, users can reflect the knowledge graph designed on the canvas into the actual database, and conversely, bring knowledge graph assets accumulated in an existing database back to the canvas for visual editing or resynchronize with another database. Accordingly, ontology design, the knowledge graph document model, normalized intermediate representation specifications, database-specific queries, and non-destructive bidirectional integration can be connected into a single processing flow.

[0100] According to the above method, users can integrally design, transform, synchronize, and reverse transform knowledge graphs in heterogeneous database environments through a single device or platform without having to individually switch between ontology design tools, graph modeling tools, property graph database management tools, and RDF triple store management tools. Furthermore, since database-specific query languages ​​and physical constraints are absorbed by the adapter, the same knowledge graph document model can be reused in multiple target database environments.

[0101] In addition, the above non-destructive bidirectional linkage operation comprises: a preview provision operation that, without immediately reflecting the above specialized query in the target database, generates synchronization plan data including a list of specialized queries and synchronization summary information in response to a synchronization preview request received from a client terminal, transmits the synchronization plan data to the client terminal so that the synchronization plan data is visually displayed as a preview interface on the screen of the client terminal, and temporarily stores the synchronization plan data for a preset validity period (TTL); And when a user’s apply request for synchronization plan data is received from the client terminal, a first hash value for the knowledge graph document model at the time of the preview provision operation and a second hash value for the knowledge graph document model at the time of receiving the apply request are compared to verify whether the document has been modified in the middle, and a transaction-based specialized query is executed on the target database only if the first hash value and the second hash value match, and an application operation that invalidates the synchronization plan data if the first hash value and the second hash value do not match; thereby, the system can prevent existing data loss in the operating environment and ensure system integrity.

[0102] The above non-destructive bidirectional synchronization operation is an operation that allows the user to verify the changes to be reflected in advance before reflecting the changes to the knowledge graph document model in the target database, and performs the actual update to the target database only when there is an explicit request for application from the user. Here, the non-destructive bidirectional synchronization includes both forward synchronization, which reflects changes from the knowledge graph document model to the target database, and reverse synchronization, which collects data stored in the target database and transforms it back into the knowledge graph document model; however, it can be performed in a manner that does not arbitrarily delete or completely replace existing nodes, edges, triples, properties, or schema elements of the target database without the user's approval.

[0103] The above preview provision operation is an operation that generates synchronization plan data that allows checking in advance what data will be changed and how, in response to a synchronization preview request received from a client terminal, without immediately executing the above specialized query on the target database currently in operation. In the above preview provision operation, when a synchronization preview request including at least one of a specific document identifier, a target database identifier, or a connection profile is received from a client terminal, the device reads the knowledge graph document model at the current time, converts the knowledge graph document model into a normalized intermediate representation specification, and then generates a list of specialized queries for each target database through the adapter.

[0104] The above client terminal may refer to a PC, web browser, tablet, workstation, or studio interface operating device connected by a user performing knowledge graph modeling. For example, if a user adds a new node label on a canvas, adds a property template to an existing edge type, or modifies a specific node instance through a web-based studio interface, the above client terminal may send a synchronization preview request to the device that includes the corresponding document identifier and the target database connection profile.

[0105] The above synchronization preview request may be a request sent by a user to verify changes after editing a knowledge graph document model on a visual editing canvas and before reflecting them in a target database. Accordingly, at the time of receiving the synchronization preview request, the device may generate a normalized intermediate representation specification based on the current state of the knowledge graph document model, and produce specialized queries and change summary information that serve as actual execution candidates based on the normalized intermediate representation specification.

[0106] The above synchronization plan data is a data package containing a list of specific specialized queries to be reflected in the target database and synchronization summary information aggregated from the number of data items classified as candidates for insertion, update, or deletion. The list of specialized queries may refer to an array of queries or commands executable in the target database; if the target database is a property graph database, it may include Cypher-family queries or Cypher queries wrapped in SQL, and if the target database is an RDF triple store, it may include SPARQL UPDATE queries.

[0107] The above synchronization summary information may include at least one of the following: the number of node labels to be created, the number of edge types to be created, the number of nodes to be upserted, the number of edges to be upserted, the number of triples to be inserted, the number of triples to be updated, the number of deletion candidates, the number of elements determined to be unchanged, warning messages, and adapter-specific execution method information. For example, the above synchronization summary information may include summary phrases in the form of “2 node labels created,” “1 edge type created,” “15 nodes upserted,” “7 edges upserted,” and “no deletion targets.”

[0108] In the above preview provision operation, the device may query the current state of the target database and compare it with the knowledge graph document model or the normalized intermediate representation specification. For example, if the target database is a property graph database, the device may query the node labels, edge types, indexes, and instance identification keys already existing in the target database and compare them with the normalized graph specification generated from the current knowledge graph document model to classify newly created targets, updated targets, and unchanged targets.

[0109] If the target database is an RDF triple store, the device can query existing triples stored in a designated Named Graph and classify them as insertion targets, update targets, deletion candidates, and no-change targets by comparing them based on hashing with triples included in the new normalized triple specification. In this case, the hash-based comparison can be performed using a combination of the subject, predicate, and object of the triple or a comparison key based on the subject and predicate; identical triples are classified as no-change, newly introduced triples are classified as insertion targets, and triples with different objects are classified as update targets.

[0110] The above synchronization plan data may be temporary plan data representing a candidate state for execution before being reflected in the actual target database. That is, the above synchronization plan data does not cause any changes to the target database until a user requests application, and can be used as preview data to check scheduled changes on the screen of a client terminal. Accordingly, the user can decide whether to apply the changes after checking the details of the specialized query to be executed on the target database and the change summary.

[0111] The above preview interface is a user interface that visually displays the synchronization plan data on the screen of a client terminal. The above preview interface may display a list of queries to be generated, a change summary, information on the database to which it applies, an adapter type, a query language, a deletion policy, a list of warnings, and an apply button. For example, the above preview interface may include a change summary area, a query details view area, a warning message area, and an application confirmation area, and when the user expands the details view area, it may display the Cypher query or SPARQL UPDATE query to be actually executed.

[0112] The operation of transmitting the above synchronization plan data to a client terminal is an operation in which the device transmits the entire content or a partial summary of the synchronization plan data to the client terminal. At this time, for reasons of security or performance, the device may not immediately transmit the entire body of the specialized query, but instead first transmit the query identifier, query type, execution order, target element, and summary message, and then additionally transmit the body of the corresponding specialized query if the user requests a detailed view of a specific query.

[0113] The operation of temporarily storing the above synchronization plan data for a preset validity period is an operation of assigning a plan identifier to the synchronization plan data generated in the above preview provision operation and storing it for a certain period of time in the server's memory, cache storage, or temporary data storage along with the plan identifier. The above preset validity period may refer to an expiration time during which the synchronization plan data is validly preserved in order to prevent waste of system resources and maintain session consistency.

[0114] For example, if the validity period is set to 30 minutes, synchronization plan data that has exceeded 30 minutes after a preview request may be automatically discarded or switched to an invalid state. In this case, even if an application request for the synchronization plan data is received from a client terminal, the device may reject the application request and guide the user to perform a new synchronization preview request. However, the validity period is not limited to 30 minutes and may be changed depending on the system environment, the throughput of the target database, security policies, or user settings.

[0115] The temporary storage of the above synchronization plan data is intended to prevent the query list generated at the time of preview from differing from the execution target at the time of application. For example, if a user presses the apply button after a long period has elapsed since displaying the preview screen, the knowledge graph document model may have been modified or the state of the target database may have changed in the meantime. In this case, the device may not apply the synchronization plan data whose validity period has expired and may allow the user to perform a new preview request.

[0116] The above application operation is an operation that, upon receiving a user's application request from a client terminal, verifies whether the document state at the time of the preview provision operation is identical to the document state at the time of receiving the application request, and then executes a specialized query or invalidates the synchronization plan data based on the verification result. The above application request may include at least one of a plan identifier, a document identifier, a target database identifier, a user identifier, and application approval information corresponding to the above synchronization plan data.

[0117] The first hash value is a unique string value calculated by inputting the original data of the knowledge graph document model or document state data affecting the synchronization result at the time the preview provision operation is performed into a hash function. When the device performs the preview provision operation, it may serialize items affecting the synchronization result among the schema, instance, synchronization settings, and ontology reference information included in the knowledge graph document model in a normalized order, and apply a cryptographic hash algorithm such as SHA-256 to the serialized data to calculate the first hash value.

[0118] The second hash value is a unique string value calculated by inputting the original data of the knowledge graph document model at the time the user's application request is received, or the current document state data affecting the synchronization result, into a hash function identical to the first hash value calculation method. When the application request is received, the device can read the currently stored knowledge graph document model again, serialize the current document state in the same manner as the first hash value calculation method, and then calculate the second hash value.

[0119] The targets for calculating the hash value may include node label definitions, edge type definitions, property templates, node instances, edge instances, synchronization settings, deletion policies, and ontology reference information that affect database reflection. On the other hand, editor view states, mouse hover states, temporary selection states, canvas zoom levels, or panel open states that do not affect database reflection may be excluded from the hash value calculation targets. Accordingly, it is possible to prevent synchronization plan data from being unnecessarily invalidated due to simple screen operations by the user.

[0120] The operation of verifying whether the above document has been modified in the interim is an operation of comparing the first hash value and the second hash value to determine whether the knowledge graph document model has been modified or corrupted in the interim by another user or process during the time between the creation of the preview and the application. If the first hash value and the second hash value match, the device may determine that the synchronization plan data generated at the time of the preview is valid in the current document state. Conversely, if the first hash value and the second hash value do not match, the device may determine that the document's schema, instance, or synchronization settings have been changed since the preview.

[0121] The operation of executing a specialized query on the target database only when the above-mentioned first hash value and second hash value match is an operation that performs actual database changes only when the state of the knowledge graph document model to be applied currently matches the preview content viewed by the user. Accordingly, if another user modifies the same document or the user directly performs additional editing on the canvas after the user has viewed the preview screen, the execution of a query based on the existing preview result may be blocked.

[0122] The above transaction-based execution may refer to an atomic execution method that prevents partial data loss or inconsistency in an operational environment by performing a rollback to restore the target database to a safe state prior to query execution if any of the multiple specialized queries fail to execute. For example, if the target database supports transactions, the device may start a transaction before executing the specialized queries, perform a commit if all queries are executed successfully, and perform a rollback if an error occurs in some queries.

[0123] If the target database does not support explicit transactions, the device may perform integrity assurance processing similar to transactions using an atomic batch execution unit, a batch execution unit, or a compensation processing procedure. For example, if a failure in some query execution is detected, a compensation query corresponding to the already executed query may be generated, or the target database may be restored by referring to a recovery log to revert to the state prior to the failure.

[0124] The execution order of the above specialized queries can be determined based on the dependency relationships of the above normalized intermediate representation specifications. For example, for a property graph database, execution may proceed in the order of node label generation, edge type generation, index creation, node upsert, and edge upsert; for an RDF triple store, execution may proceed in the order of Named Graph verification, schema triple insertion, instance triple insertion or update, and synchronization metadata triple update. Accordingly, execution errors caused by the node or class referenced by an edge or object property not being prepared first can be reduced.

[0125] The operation of invalidating the synchronization plan data when the first hash value and the second hash value are inconsistent is intended to prevent the application of outdated synchronization plan data that does not match the current document state when the preview content viewed by the user and the state of the knowledge graph document model to be applied are logically inconsistent. When the device detects a hash value mismatch, it may immediately change the synchronization plan data corresponding to the plan identifier to an invalid state and send a message to the client terminal notifying that preview regeneration is required.

[0126] Invalidation of the above synchronization plan data may be performed under at least one of the following conditions, in addition to hash value mismatch: expiration of validity period, disconnection of the target database, change in user permissions, change in the target database schema state, change in adapter type, or change in deletion policy. For example, if a user changes the target database from Neo4j to an RDF triple store after a preview provision operation, the existing Cypher-based synchronization plan data may be invalidated as it is no longer valid.

[0127] In the above non-destructive bidirectional linkage operation, the default deletion policy may be set to a state where automatic deletion is prohibited. That is, even if a specific node label, edge type, node instance, edge instance, or triple is removed from the knowledge graph document model, the device may not immediately delete it from the target database. If deletion is required, a deletion query may be included in the synchronization plan data only when the user explicitly specifies the deletion target or when an explicit deletion policy is enabled.

[0128] The default deletion policy mentioned above can be set to “none,” in which case elements removed from the document are not automatically deleted from the target database. Additionally, the explicit deletion policy can be set to “explicit_only,” in which case deletion queries can be generated only for elements specified by the user as targets for deletion. When integrated with an RDF triple store, a Named Graph full replacement method may be provided as a separate policy; however, since this method can delete triples added externally, it is advisable to perform it only after explicit selection and warning confirmation by the user.

[0129] When the above application operation is completed, the device may generate execution results and an audit log. The execution results may include success status, the number of executed queries, the number of insertions, the number of updates, the number of deletions, information on failed queries, error messages, and execution time. The audit log may include at least one of the application request user, the time of application, the target database, the document identifier, the plan identifier, the first hash value, the second hash value, a summary of the executed queries, the deletion policy, and the adapter type. Accordingly, it is possible to track who, when, and what changes were reflected in the target database in an operational environment.

[0130] The above device can transmit the execution result of the application operation to a client terminal, and the client terminal can output it as a synchronization completion message, a failure message, or a retry guidance message. For example, if all specialized queries are executed successfully, the client terminal can display a summary of the application results along with a message stating “Synchronization is complete,” and if some queries fail, it can display the failed queries and the cause to the user.

[0131] According to the preview provision and application operations described above, users can review changes to the knowledge graph document model in advance before they are reflected in the target database, verify whether documents have been modified using hash values ​​after the preview, and ensure that only verified specialized queries are executed on a transactional basis in the target database. Accordingly, this reduces the risk of data loss in the production environment, prevents missynchronization caused by the application of outdated synchronization plans, and ensures systemic integrity and synchronization safety across heterogeneous database environments.

[0132] And, the above modeling operation includes: a hierarchy resolution strategy determination operation that adaptively determines a hierarchy resolution strategy by referring to the supportsMultiLabel parameter within the capability information (AdapterCapabilities) declaratively provided by the adapter when mapping the hierarchy (rdfs:subClassOf) between the superclass and subclass included in the above ontology design information to the schema structure of the property graph; and the hierarchy resolution strategy determination operation includes: for a first type adapter in which the supportsMultiLabel parameter is identified as False, a flattening strategy application operation that generates the knowledge graph document model by applying a flattening strategy that resolves the inheritance relationship into a single hierarchy by physically copying and merging the property template defined in the superclass to the node label definition of the subclass; For a second type adapter in which the multi-label support parameter is identified as True, a multi-label strategy application operation is included to generate the knowledge graph document model by applying a multi-label strategy defined to maintain separate property templates for each of the upper class and lower class, while assigning multiple labels corresponding to the upper class and lower class in parallel when creating a single node instance; thereby ensuring query integrity across a heterogeneous environment by fully preserving the hierarchical logic and polymorphism of the original ontology without being dependent on the physical schema constraints of the target database vendor.

[0133] The above modeling operation is an operation that resolves the class hierarchy included in the ontology design information to fit the physical schema constraints of the target database, while maintaining the semantic relationship between the superclass and subclass of the ontology design information within the knowledge graph document model. Here, the class hierarchy may refer to an inheritance or inclusion relationship expressed by the rdfs:subClassOf relationship, and for example, if the “Employee” class is defined as a subclass of the “Person” class, it may represent a semantic inclusion relationship in which an instance of the “Employee” class is simultaneously an instance of the “Person” class.

[0134] The above-mentioned hierarchy resolution strategy determination operation is an operation that determines the method of converting the class hierarchy into a node label structure based on the label structure, query language, schema processing method, and physical constraints actually supported by the target database when mapping the rdfs:subClassOf relationship included in the above-mentioned ontology design information to the schema structure of the property graph. In other words, the above-mentioned hierarchy resolution strategy determination operation may be an operation that selects a transformation strategy to reflect the relationship between a superclass and a subclass as a node label structure that can be queried in the actual database, rather than converting it merely into a simple edge.

[0135] The capability information declaratively provided by the adapter is metadata that informs the device of the capabilities supported by the target database to which the adapter is connected. The capability information may include at least one of whether multiple labels are supported, whether label inheritance is supported, whether transactions are supported, a query language, a connection protocol, whether SQL wrapping is required, whether named graphs are supported, and whether RDF-star is supported.

[0136] The above multi-label support parameter may be a Boolean value indicating whether multiple node labels can be assigned simultaneously to a single node instance. For example, the multi-label support parameter may be managed by the supportsMultiLabel value, and if the supportsMultiLabel value is identified as false, the target database may be determined not to directly support a structure that assigns an upper class label and a lower class label simultaneously to a single node instance. Conversely, if the supportsMultiLabel value is identified as true, the target database may be determined to be able to assign an upper class label and a lower class label in parallel to a single node instance.

[0137] The above-mentioned hierarchy resolution strategy may be determined as either a flattening strategy or a multi-label strategy depending on the parameter regarding multi-label support. The flattening strategy may be applied to a target database that does not support multi-labels, and the multi-label strategy may be applied to a target database that supports multi-labels. Accordingly, the device can adaptively convert the same ontology hierarchy into an executable structure specific to the target database, without using a single conversion method fixed to a specific database.

[0138] The operation of applying the flattening strategy described above is an operation that generates the knowledge graph document model by compressing the inheritance relationship between the superclass and the subclass into a single-node label-centric structure for the first type adapter in which the multi-label support parameter is identified as false. Here, the first type adapter may refer to an adapter that communicates with a property graph database that cannot directly assign multiple labels to a single node or has single-label-centric schema constraints. For example, the first type adapter may correspond to a database environment such as Apache AGE that does not support multiple labels.

[0139] The above flattening strategy may refer to a data structure optimization technique that physically copies and merges property templates defined in a superclass into the node label definitions of a subclass in order to ensure that the semantics and attribute structure of a superclass are not omitted in a subclass in an environment where multiple labels cannot be assigned to a node simultaneously. Accordingly, even if the subclass is represented by a single node label, it can include attribute information derived from the superclass.

[0140] In the operation of applying the flattening strategy described above, the property template defined in the superclass can be copied to the node label definition of the subclass and merged with the property template previously defined in the subclass. For example, if the superclass “Person” class has “Name” and “Age” property templates defined and the subclass “Employee” class has “Employee ID” and “Department Name” property templates defined, the operation of applying the flattening strategy may merge the “Employee” node label definition to include all of the “Name”, “Age”, “Employee ID”, and “Department Name” property templates.

[0141] The physical copying and merging of the above property templates may be performed not merely by adding duplicate attribute names from the superclass to the subclass, but by determining whether a conflict exists by comparing at least one of the property name, data type, required status, default value, allowance of multiple values, index candidate status, and descriptive information. For example, if property templates with the same name exist in both the superclass and the subclass and have the same data type, the duplicate entries may be merged into one; if the data types differ, the definition of the subclass may be applied first, or a warning message requiring user confirmation may be generated.

[0142] In the operation of applying the flattening strategy described above, the parent class identifier or parent class reference metadata may be stored together with the node label definition of the subclass to prevent the loss of the original hierarchical logic between the parent class and the subclass. For example, the identifier of the “Person” class, the parent class path, the parent label list, or the hierarchical reference key may be recorded as metadata in the “Employee” node label definition. Accordingly, even if it is reflected as a single node label structure of “Employee” in the target database, the inheritance relationship of the original ontology, which is that “Employee” is a subclass of “Person,” can be tracked within the knowledge graph document model.

[0143] The above-mentioned superclass reference metadata may include at least one of a parent label list, a hierarchical path, an original ontology IRI, a superclass local name, or a superclass key. The above-mentioned superclass reference metadata may be reflected in the target database in the form of meta-properties, or may be maintained solely as schema metadata within the knowledge graph document model. Accordingly, even when a superclass-based query is required, the device can perform query transformation or filtering using the subclass node labels and the superclass reference metadata.

[0144] In the operation of applying the flattening strategy described above, property templates of each superclass can be merged sequentially even when the subclass has multiple superclasses. In this case, the device checks for conflicts between property templates of superclasses, and if identical property names are defined with different data types, it can determine the merging result according to a pre-configured priority rule or a user verification procedure. Accordingly, ontology design information with multiple inheritance or complex hierarchical structures can also be converted into a single-node label-based property graph schema.

[0145] In the knowledge graph document model generated according to the flattening strategy application operation described above, since the node label definitions corresponding to the subclasses include the property structure of the superclasses, it is possible to create subclass nodes with superclass attributes even in target databases that do not support multiple labels. For example, the “Employee” node may have only a single node label of “Employee” in the target database, but it may also have “Name” and “Age” properties derived from the “Person” class.

[0146] The above-described multi-label strategy application operation is an operation that generates the knowledge graph document model to assign multiple labels in parallel to a single node instance, while maintaining the node label definitions of the upper class and lower class separately, for a second-type adapter in which the multi-label support parameter is identified as true. Here, the second-type adapter may refer to an adapter that communicates with a property graph database capable of assigning multiple labels to a single node without restriction or within a pre-configured range. For example, the second-type adapter may correspond to a database environment such as Neo4j that supports multiple labels.

[0147] The above multi-label strategy may refer to a modeling technique in which the property templates of the superclass and the subclass are maintained as separate, independent templates, while simultaneously assigning both the superclass label and the subclass label to the node when a single node instance is actually created. Accordingly, the above multi-label strategy can implement a polymorphic structure that maintains the attribute definitions of the superclass and subclass independently, while allowing instances of the subtype to be retrieved when a query is made for the supertype.

[0148] In the operation of applying the multi-label strategy described above, the property templates of the superclass and the subclass can be maintained independently within their respective node label definitions without physically merging them into a single node label definition. For example, the “Name” and “Age” property templates may be maintained in the “Person” node label definition, and the “Employee ID” and “Department Name” property templates may be maintained in the “Employee” node label definition. In this case, when an “Employee” instance is created, both the “Person” label and the “Employee” label may be assigned to a single node.

[0149] Assigning the aforementioned multiple labels in parallel means configuring the label set so that a single node instance simultaneously holds the meanings of both a superclass and a subclass. For example, if the “Employee” class is defined as a subclass of the “Person” class, a specific Employee node may possess both the “Person” label and the “Employee” label in the target database. Accordingly, the corresponding Employee node can be retrieved in queries executed based on the “Person” label, and it can also be retrieved in queries executed based on the “Employee” label.

[0150] In the operation of applying the multi-label strategy described above, if a subclass has multiple levels of superclasses, the subclass instance may be assigned a label corresponding not only to the superclass but also to the ancestor class above it. For example, if the “Manager” class is a subclass of the “Employee” class and the “Employee” class is a subclass of the “Person” class, the “Manager” instance may be assigned the labels “Person,” “Employee,” and “Manager.” Accordingly, it is possible to ensure that subclass instances are not omitted regardless of where a query is performed in the hierarchy.

[0151] In the operation of applying the multi-label strategy described above, the property templates of the superclass and subclass are maintained separately, but when validating a single node instance, the property templates of all assigned labels can be referenced together. For example, if a specific node instance has both “Person” and “Employee” labels, the device can check both the required properties for the “Person” label and the required properties for the “Employee” label. Accordingly, ontology-based attribute constraints can be maintained even in a multi-label structure.

[0152] The above-described operation for determining the hierarchy resolution strategy refers to the capability information of the adapter before transforming the hierarchy of the ontology design information, thereby preventing the generation of document models or specialized queries that do not match the supported functions of the target database. For example, applying a multi-label strategy to a target database that does not support multi-labels may result in query execution errors; however, the device can prevent such errors in advance by selecting a flattening strategy when the supportsMultiLabel parameter is false.

[0153] In the operation to determine the hierarchy resolution strategy above, at least one of user settings, ontology complexity, class depth, number of inheritance relationships, property conflicts, and query performance characteristics of the target database may be additionally considered, in addition to the capability information of the adapter. For example, even if the target database supports multiple labels, a flattening strategy may be applied if the user selects a single-label-centric operation policy, and conversely, in an environment that supports multiple labels, a multi-label strategy may be applied first to increase the accuracy of queries based on the parent class.

[0154] In the operation for determining the hierarchy resolution strategy described above, guidance or warning information regarding the determined strategy may be provided to the user interface. For example, if the target database does not support multiple labels, the device may output guidance information such as “The class hierarchy is flattened based on property inheritance.” Conversely, if the target database supports multiple labels, the device may output guidance information such as “The class hierarchy is mapped to multiple labels.” Accordingly, the user can check in advance how the same ontology design information is reflected for each target database.

[0155] The above knowledge graph document model may reflect the result of the above-described hierarchy resolution strategy determination operation in at least one of schema definitions, instance creation rules, and synchronization setting information. For example, when a flattening strategy is applied, the node label definition of a subclass may include a superclass-derived property template and superclass reference metadata, and when a multi-label strategy is applied, a set of labels to be assigned when creating a node instance may be automatically calculated according to the hierarchical path.

[0156] According to the above-described hierarchy resolution strategy determination operation, it is possible to maintain a structure that enables superclass-based queries, subclass-based queries, and polymorphism-based queries while transforming the hierarchical logic of the ontology design information to fit the physical constraints of the target database. Accordingly, the user can generate a knowledge graph document model suitable for heterogeneous databases from the same ontology design information without directly considering whether the target database supports multiple labels.

[0157] According to the above-mentioned hierarchy resolution strategy determination operation, a single ontology design asset can be reused even in database environments where multi-label support varies. For example, the same “Person-Employee” ontology hierarchy can be transformed into a flattened structure with a single “Employee” label and superclass metadata for the first type adapter, and into a multi-label structure with both “Person” and “Employee” labels for the second type adapter. Accordingly, it is possible to absorb differences in physical schema constraints specific to target database vendors while preserving the hierarchical logic and polymorphism of the original ontology and ensuring query integrity across heterogeneous environments.

[0158] The above modeling operation or the above non-destructive bidirectional linkage operation may further include an ontology consistency verification operation that verifies whether the knowledge graph document model logically matches the class definitions, property definitions, and hierarchical structure of the original ontology design information. The above ontology consistency verification operation may be an operation that determines whether the node label definitions, edge type definitions, property templates, node instances, and edge instances included in the document model satisfy constraints derived from the ontology design information.

[0159] In the above-described ontology consistency verification operation, it is possible to verify whether a node label assigned to a node instance corresponds to a class definition in the ontology design information. For example, if a specific node instance has the label “Employee,” the device can determine whether the “Employee” class exists in the ontology design information, what hierarchical relationship the “Employee” class has with the superclass “Person” class, and whether the relationship is correctly reflected according to the hierarchy resolution strategy of the target database.

[0160] In the above-described ontology consistency verification operation, it is possible to verify whether an edge type definition or an edge instance conforms to the domain and range constraints of an object property. For example, if a specific object property is defined to have the “Employee” class as its domain and the “Department” class as its range, the device can determine whether the source node of the edge instance corresponding to the object property belongs to “Employee” or its subclass, and whether the destination node belongs to “Department” or its subclass.

[0161] In the above ontology consistency verification operation, it can be verified whether the value of a data type property matches a data type defined in the ontology design information or a scalar type defined in the property template of the knowledge graph document model. For example, if a specific property template is defined as a datetime type but the corresponding property value of a node instance is a string that cannot be parsed into a datetime format, the device may classify this as a type mismatch error or warning.

[0162] In the above-described ontology consistency verification operation, at least one of the following can be verified: whether required properties are missing, whether multi-values ​​are allowed, whether identification keys are duplicated, whether the hierarchy is circular, whether undefined classes are referenced, whether undefined properties are referenced, and whether domain-range conflicts occur. The device can classify the verification results into error, warning, or guidance grades and display the verification results in the integrated studio interface or the synchronization preview interface.

[0163] The above-mentioned ontology consistency verification operation may be performed before executing a specialized query on the target database. In this case, if there is a consistency violation classified as a fatal error, the device may stop the generation of synchronization plan data or block the application of the specialized query. On the other hand, for violations classified as warning levels, the device may require confirmation from the user or continue synchronization only if the user explicitly approves in override mode.

[0164] According to the above ontology consistency verification operation, it is possible to prevent nodes, edges, or properties that differ from the intent of the ontology design information from being reflected in the target database. Accordingly, users can freely edit the knowledge graph document model on the visual canvas while ensuring that the data ultimately reflected in the target database satisfies ontology-based class hierarchy, property types, and relationship constraints.

[0165] In addition, the above-mentioned non-destructive bidirectional linkage operation further includes: an automatic identification key inference operation for determining an identity key to uniquely identify a single node in order to map each entity within the data collected from the target database to a single node of the property graph; wherein the automatic identification key inference operation comprises, according to a pre-configured cascading priority rule: a first inference operation as a first priority, extracting a local part from an IRI (Internationalized Resource Identifier) ​​which is the identifier of the entity and designating it as the identification key; a second inference operation as a second priority, if extraction through the first inference operation is impossible, designating the value of an explicit identifier property assigned to the entity as the identification key; and a third priority, if the explicit identifier property is absent, a pre-configured standard vocabulary (schema.A third inference operation is executed by extracting a universal attribute value based on org) and designating it as the identification key; and a fourth inference operation is executed as a fourth priority, wherein if the universal attribute value does not exist in the third inference operation, a hash value is calculated for the entire string of the IRI, and if the IRI does not exist, a hash value is calculated for at least one of a triple set corresponding to the entity, a blank node identifier, and an internal temporary identifier, and finally designated as the identification key; and the knowledge graph document model that has been reverse-transformed based on the automatically inferred identification key is loaded in the form of a Source-Agnostic Canvas having the same schema structure and operation method on a visual editing canvas regardless of whether the source of the initial data is a property graph or an RDF (Resource Description Framework) triple store, thereby reducing the possibility of identifier collisions between heterogeneous data models and providing a criterion for re-identification in the event of a collision, thereby ensuring data integrity during re-synchronization of the reverse-transformed data.

[0166] The above non-destructive bidirectional linkage operation may further include an operation to automatically determine identification criteria to prevent the same entity from being created as a duplicate node or different entities from being merged into a single node when each entity included in the data collected from the target database is inversely transformed into a node instance of the knowledge graph document model. Here, the data collected from the target database may include a set of triples collected from an RDF triple store, a set of nodes and edges collected from a property graph database, row data extracted from a relational database, or a combination thereof.

[0167] The above entity refers to an independent unit of information stored within the target database, which may mean a data unit treated as a single conceptual object, such as a specific person, department, project, product, document, or event. For example, in an RDF triple store, a set of triples with a specific IRI as the subject may correspond to a single entity; in a property graph database, a node with a specific node identifier or label and a set of properties may correspond to a single entity; and in a relational database, a single row of a specific table or a record identified by a composite key may correspond to a single entity.

[0168] A single node of the above property graph refers to a single node instance created when the entity is inversely transformed into the knowledge graph document model. The single node may include at least one of a node label, a property value, an identification key, source information, and synchronization metadata. For example, if an entity with an IRI named `http: / / example.org / person / kim001` is collected from an RDF triple store, the entity may be transformed into a single node instance with the node label `Person`.

[0169] The above-described automatic identification key inference operation is an operation that automatically determines and assigns an identification key, which is a unique value capable of clearly distinguishing a single node from other nodes, in order to map each entity collected from the target database to a single node of the property graph. Here, the identification key may refer to a reference value for determining whether node instances are duplicated within the knowledge graph document model and for finding the same entity again during synchronization or re-synchronization.

[0170] The aforementioned identification key is not merely a name for screen display, but can be used as a criterion to determine whether the entity is the same node instance when it is collected again from a different data source or resynchronized with a target database. For example, the same person entity may be represented as an IRI in an RDF triple store, as an `identityKey` property in a property graph database, and as a primary key in a relational database. The automatic identification key inference operation can convert these different identification schemes into a consistent node identification standard within a single knowledge graph document model.

[0171] The above-described cascading priority rule is a pre-configured sequential judgment rule for determining which value among multiple identification key candidates to use preferentially. The device first checks whether the first priority condition is satisfied, and performs fallback processing by sequentially moving to the second, third, and fourth priorities only if a valid identification key cannot be derived from the first priority condition. Accordingly, the device can determine an identification key that is as stable and reproducible as possible for each entity.

[0172] The above first inference operation is an operation that, as the first priority of a pre-configured cascading priority rule, analyzes the string form of the IRI, which is the identifier of the entity, extracts the local part located at the very end of the IRI, and designates it as the identification key. Here, IRI may refer to an Internationalization Resource Identifier used to globally represent the location and identifier of a specific resource or entity in a Semantic Web and RDF environment.

[0173] The above-mentioned local part refers to the final string portion assigned to individually identify only the relevant resource, excluding common domain and namespace paths from the above-mentioned IRI. For example, if the IRI is structured in the format `http: / / example.com / ontology / Employee_1020`, `Employee_1020`, excluding the common namespace portion, can be extracted as the local part. Additionally, if the IRI includes a hash symbol, such as `http: / / example.org#Employee`, the string `Employee` following the hash symbol can be extracted as the local part.

[0174] In the first inference operation above, a local part can be produced by searching for a string following the last slash, hash symbol, or pre-set delimiter included in the IRI. Then, the device can generate a normalized string that can be used as an identification key by removing or replacing spaces, control characters, special characters not allowed in the database, or unnecessary prefix / suffix delimiters from the produced local part.

[0175] In the first inference operation described above, the local part may not be used as a valid identification key if it is empty, an excessively long string, corresponds to a system reserved word, or duplicates another entity within the same Import scope. For example, if the entity's IRI is an anonymous blank node that does not exist, or if the end of the IRI consists of a meaningless random string or a temporary hash value, making it difficult to reliably identify the entity solely by the local part, it may be determined that extraction through the first inference operation is impossible.

[0176] The second inference operation described above is an operation that, when extraction of the identification key through the first inference operation is impossible or inappropriate, reads the value of an explicit identifier property assigned to the entity as a second priority and designates it as the identification key. Here, the explicit identifier property may refer to a unique ID, employee number, product number, code value, or similar identification attribute explicitly assigned by a user or external system for the purpose of identifying the entity at the time data is built into the database.

[0177] In the second inference operation described above, the existence of an explicit identifier property can be determined by searching through a list of data type property triples or node properties connected to the entity. For example, if a specific entity possesses an explicit identifier property named `ex:employeeId` and its value is `EMP-9999`, the device can extract the value `EMP-9999` and designate it as the identification key of the entity.

[0178] The explicit identifier property may include at least one of `schema:identifier`, `dcterms:identifier`, `id`, `code`, `employeeId`, `serialNumber`, `productNo`, or a domain-specific identification attribute. The device may search for an attribute value of the entity based on a pre-configured list of identifier property candidates, and if a property corresponding to the candidate list exists, extract the corresponding value as an identification key candidate.

[0179] In the second inference operation described above, if multiple explicit identifier properties exist simultaneously, one value may be selected according to a pre-configured identifier property priority list. For example, if `schema:identifier` and `dcterms:identifier` exist together, `schema:identifier` may be prioritized or the identifier property selected by the user may be prioritized according to the system settings. Additionally, if multiple values ​​exist, the first value, the shortest value, a value satisfying a regular expression condition, or a value verified by the user may be used as the identification key.

[0180] In the second inference operation described above, even if a value of an explicit identifier property exists, if the value is determined to be blank, duplicated within the same import range, or difficult to guarantee uniqueness, the value of the explicit identifier property may not be used as an identification key, and the next-ranked inference operation may be performed. Accordingly, the problem of different entities being merged into a single node due to an incorrect identifier property value can be reduced.

[0181] The above third inference operation is an operation that, when the above explicit identifier property is absent or unavailable, searches for and extracts a universal attribute value based on a pre-configured standard vocabulary as a third priority and designates it as the identification key. Here, the standard vocabulary may include schema.org, and the universal attribute value may include `schema:identifier`, `schema:name`, `schema:email`, `schema:url`, `schema:telephone`, `dc:identifier`, or an attribute value configured to have relatively high uniqueness in a specific domain.

[0182] The above standard vocabulary may refer to a dictionary of standardized concepts and attributes commonly used when structuring data on the web to ensure interoperability in search engines or various heterogeneous database environments. The above third inference operation may be an operation to designate a universal attribute value as a candidate for an identification key, since even an entity that does not have its own identifier property defined may possess one of the universal attribute values ​​widely defined in the standard vocabulary.

[0183] In the third inference operation described above, a universal attribute value among the attributes of the entity that can be used for unique identification can be searched. For example, in the case of a person entity, if the `schema:email` value exists, it can be used as an identification key, and in the case of an organization entity, the `schema:url` or `schema:name` values ​​can be used as identification key candidates. However, attribute values ​​that may be duplicated, such as `schema:name`, can be used as identification keys in combination with class type, source graph, parent context, or additional attribute values.

[0184] In the third inference operation described above, if multiple general-purpose attribute values ​​exist, one or more attribute values ​​may be selected according to pre-set attribute priority and uniqueness judgment rules. For example, if an email address exists, the email address is prioritized; if there is no email address, a combined value of name and date of birth is used; and if these values ​​are also unavailable, a combined value of name and organization affiliation may be used. Accordingly, a composite identification key can be generated even in cases where it is difficult to ensure uniqueness using only a single attribute.

[0185] In the third inference operation described above, the selected universal attribute value may be used as an identification key as is, or it may be used as an identification key after performing processes such as removing spaces, standardizing case, replacing special characters, removing language tags, removing data type suffixes, and limiting length. For example, the name attribute `Kim Jinseo` can be normalized to `kim_jinseo`, and the email attribute `jinseo@example.com` can be designated as an identification key after standardizing to lowercase.

[0186] The above-mentioned fourth inference operation is an operation that finally designates the identification key using a hash value as the fourth priority when no text or attribute value that can be used as an identification key exists despite the search process from the first to the third priority. In the above-mentioned fourth inference operation, if the above-mentioned IRI exists, the entire string of the above-mentioned IRI is input into a hash function, and part or all of the calculated hash value can be used as an identification key.

[0187] The above hash function is a function that produces a fixed-length string from input data and may be a cryptographic hash algorithm such as SHA-256. For example, the device may input the entire IRI string into a SHA-256 hash function and designate the first 12 digits, the first 16 digits, or a part of the string of a pre-set length of the produced hash value as an identification key. Even when using only a part of the hash value in this way, the device can reduce the possibility of identification key collisions by additionally checking for duplicates within the same Import range.

[0188] In the fourth inference operation above, if the IRI does not exist, a hash value for at least one of a set of triples corresponding to the entity, a blank node identifier, or an internal temporary identifier may be calculated and finally designated as the identification key. Here, a blank node is a node used to represent an anonymous resource without a global IRI in RDF data, and a blank node identifier may be an internal identifier assigned to distinguish such anonymous resources during processing. Additionally, an internal temporary identifier may refer to an identifier generated by the device to temporarily distinguish an entity during import processing.

[0189] In the above-described fourth inference operation, when calculating a hash value for a set of triples, triples having entities as subjects are sorted in the order of predicate and object, serialized, and a hash function can be applied to the serialized string. Accordingly, the same identification key can be generated even if sets of triples with the same meaning are collected in different orders. Additionally, by inputting the entire set of triples data representing all attributes and connection relationships possessed by the entity, or an internal temporary identifier value, into the hash function, the device can confer systemic uniqueness and traceability even on entities that lack explicit identification information.

[0190] In the above fourth inference operation, if a hash-based identification key is used, warning information or identification confidence information can be generated for the corresponding entity. For example, the device may record warning information such as “Hash-based identification key used because no explicit identifier exists” in the metadata of the knowledge graph document model or in the Import result summary information. Accordingly, the user can subsequently specify an explicit identifier property for the corresponding entity or manually correct the identification key.

[0191] In the above-described automatic identification key inference operation, after the identification key is determined through any one of the first to fourth inference operations, the device can check for duplicate identification keys. For example, if the same identification key already exists within the same node label or the same entity class, the device can generate a corrected identification key by combining a source identifier, a class name, a named graph identifier, or a hash suffix. Accordingly, identifier duplication or overwrite errors that may occur when databases with different identification systems are loaded into a single integrated canvas can be reduced.

[0192] In the above-described automatic identification key inference operation, identification key source information may be stored together to track the reason why the identification key was determined. The identification key source information may indicate whether the identification key was extracted from an IRI local part, from an explicit identifier property, from a schema.org-based universal property value, or generated as a hash value. Additionally, the identification key source information may include at least one of the property name used, the original IRI, the applied hash algorithm, the data to be hashed, and the identification confidence level.

[0193] In the above identification key automatic inference operation, if the data collected from the target database originates from an RDF triple store, the TBox and ABox can be separated and extracted, and then the identification key can be determined on an individual instance basis contained in the ABox. For example, an individual instance identified as belonging to a specific class by the `rdf:type` triple is converted into a node instance, and the first to fourth inference operations can be sequentially applied to the node instance.

[0194] In the above-described automatic identification key inference operation, even when converting object property triples collected from an RDF triple store into edge instances, the identification keys inferred for the source entity and the destination entity, respectively, can be referenced. For example, if a relationship triple named `person001 worksFor company001` is collected, the device can determine the identification key of the node corresponding to `person001` and the identification key of the node corresponding to `company001`, respectively, and then use these identification keys to create an edge instance connecting the source node and the destination node.

[0195] The above-described automatic identification key inference operation can also be used when extracting edge properties expressed as Reification patterns or RDF-star patterns. For example, if edge properties such as start date, role, trust level, or source are attached to a specific relationship triple, the device may first determine the identification keys of the subject and object entities, then identify edge instances based on the corresponding identification key pairs and predicate information, and store the attached attributes extracted from Reification or RDF-star as properties of the edge instances.

[0196] The knowledge graph document model, inversely transformed based on the automatically inferred identification key, can be generated with the same document model structure regardless of the source of the initial data. For example, even if the source of the initial data is a property graph database, it can be transformed into a structure of node label definitions, edge type definitions, node instances, and edge instances; and even if the source of the initial data is an RDF triple store, the TBox and ABox analysis results can be transformed into the same document model structure.

[0197] The source-independent canvas mentioned above refers to an integrated canvas environment that provides the same visual editing experience regardless of whether the initial creation path of the knowledge graph document model is direct creation, ontology import, relational database import, RDF triple store import, or property graph database import. In the source-independent canvas, functions such as node placement, edge connection, property editing, layout adjustment, style setting, preview, and synchronization application can be provided in the same manner.

[0198] The fact that it is loaded in the aforementioned source-independent canvas form means that the inversely transformed Knowledge Graph document model is displayed on the canvas as an editable object identical to a standard Knowledge Graph document model, rather than as a screen dedicated to a specific source database or a read-only view. For example, documents imported from an RDF triple store can have node positions moved, edge types modified, or property templates added, just like graph documents drawn directly by the user.

[0199] The above knowledge graph document model may preserve source information as metadata when loaded onto the source-independent canvas. The source information may include at least one of a source type, access endpoint, named graph identifier, import time, import scope mode used, source class identifier, and source IRI. The source information may not act as a direct editing constraint when a user edits on the canvas, but may be referenced during re-import, re-synchronization, audit log generation, or conflict resolution.

[0200] According to the source-independent canvas described above, a document model inversely transformed from an RDF triple store can be synchronized to a property graph database, and a document model inversely transformed from a property graph database can also be synchronized to an RDF triple store. For example, semantic data accumulated in an RDF triple store can be imported, edited on the canvas, and then reflected in a property graph database such as Neo4j or Apache AGE. Conversely, node and edge structures collected from a property graph database can also be synchronized to an RDF triple store.

[0201] According to the above-described automatic identification key inference operation, node duplication, node merging errors, and edge connection errors that may occur due to differences in identifier representation methods between heterogeneous data models can be reduced. For example, even if the same entity is represented as a global IRI in an RDF triple store and as an internal sequential numeric ID or business key in a property graph database, the device can map it to the same node instance by generating a consistent identification key based on cascading priority rules.

[0202] According to the above identification key automatic inference operation, criteria for re-identification can be provided in the event of a collision. For example, if two entities have the same `schema:name` value and generate the same identification key candidate, the device can distinguish the collision by referring to the original IRI, source named graph, class type, or hash suffix, and can display the collision history to the user to allow them to select whether to perform manual or automatic correction.

[0203] According to the above-mentioned automatic identification key inference operation, data integrity can be ensured during re-synchronization of reverse-transformed data. For example, if a node created with the identification key `kim001` during the initial import is subsequently edited by a user and synchronized back to the target database, the device can locate and update the existing entity based on the identification key. Accordingly, existing entities can be accurately matched with the newly edited node, and problems such as duplicate creation of the same entity or existing relationships being connected to incorrect nodes can be reduced.

[0204] According to the above-described automatic identification key inference operation and source-independent canvas loading structure, entities collected from a target database can be reliably mapped to a single node of the property graph, and can be integrated into a knowledge graph document model having the same schema structure and behavior even when the sources of the initial data differ. Accordingly, knowledge graph assets distributed across an RDF triple store, a property graph database, and a relational database can be reused in a single editing and synchronization environment, and resynchronization integrity and data identification consistency can be improved in heterogeneous database environments.

[0205] In addition, the above non-destructive bidirectional linkage operation includes: a selective collection operation that collects data by selecting one of three pre-configured reverse transformation range modes to selectively extract only subgraphs suitable for the purpose from a large-scale knowledge base when the target database is an RDF triple store; and the selective collection operation includes: a first collection mode that independently extracts and reverse transforms only the set of triples existing within the specific named graph context based on the identifier (IRI) of a specified specific named graph among a plurality of named graphs logically partitioned within the target database; a second collection mode that filters and transforms only instances and properties associated with at least one target class specified by the user based on an ontology hierarchy; and a third collection mode that executes a custom SPARQL CONSTRUCT query written directly by the user to extract and transform the set of triples corresponding to the user-defined query result. By performing this through either of the above methods, it is possible to prevent system overhead and wasted network bandwidth resulting from loading the entire large-scale RDF dataset into memory, and to support the dynamic extraction and construction of domain-specific knowledge graphs specialized for specific business logic.

[0206] The above selective collection operation is an operation in which, when the target database is an RDF triple store, instead of reading the entire set of triples stored in the target database in bulk, only a set of triples within a range suitable for the intended use is selectively collected and inversely transformed into the knowledge graph document model. Here, an RDF triple store may refer to a semantic web-specific database that stores triples composed of subject, predicate, and object and allows data to be queried or updated through SPARQL queries. For example, the RDF triple store may include systems such as GraphDB, Apache Jena Fuseki, or an RDF4J-based repository.

[0207] The above knowledge base may refer to a knowledge storage set containing ontology schema information, instance information, relationship information, annotation information, source information, and metadata accumulated within an RDF triple store. The knowledge base may contain only data regarding a single domain, or it may be a large-scale dataset containing a mixture of data collected from multiple business domains, multiple services, multiple documents, or multiple external sources.

[0208] The above subgraph may refer to a partial set of triples within the above-described large-scale knowledge base that aligns with a user-specified business purpose, analysis purpose, synchronization purpose, or modeling purpose. For example, even if the entire knowledge base includes all triples regarding people, organizations, projects, contracts, equipment, and documents, if the user intends to model only the “affiliation relationship between employees and departments,” the above-described selective collection operation may extract only the employee class, department class, affiliation relationship, and attribute triples directly related to them as a subgraph.

[0209] The above-mentioned inverse transformation range mode refers to a collection criterion that determines which range of triples from the RDF triple store to collect and transform into the knowledge graph document model. The device may select one of a first collection mode, a second collection mode, and a third collection mode based on user selection, connection profile settings, previous import history, or automatic recommendation results. Additionally, the device may apply different SPARQL query statements, target triple ranges, and inverse transformation rules generated according to each collection mode.

[0210] In the above-described optional collection operation, the target database is first accessed, and a list of available named graphs, a list of classes, the number of triples, a list of major properties, or endpoint status information can be queried through the RDF adapter. For example, the RDF adapter can perform a named graph list lookup operation to return multiple named graph identifiers existing in the RDF triple store and the number of triples included in each named graph, and the device can display this on the selection screen of the client terminal.

[0211] The first collection mode described above is a mode that independently extracts and inversely transforms only the set of triples existing within the context of a specific named graph, based on the identifier of a specific named graph designated by the user among a plurality of named graphs logically partitioned within the target database. Here, a named graph may refer to a graph unit assigned an identifier (IRI) to group specific data sets into logical groups for management within an RDF triple store.

[0212] The identifier of the above-mentioned named graph may be an IRI used to uniquely designate a specific named graph globally or within a repository. For example, `http: / / example.org / graph / hr` may designate a named graph for the HR domain, and `http: / / example.org / graph / project` may designate a named graph for the Project domain. Since the collection scope in the above-mentioned first collection mode is limited based on such named graph identifiers, triples stored in other named graphs may be excluded from the collection target.

[0213] The above-mentioned named graph context may refer to a triple storage space defined by the specific named graph identifier or a membership range indicating which named graph area specific data belongs to. The device may retrieve only triples existing within the specific named graph context by using the GRAPH clause or FROM NAMED clause of a SPARQL query. For example, if a user selects a named graph corresponding to the HR domain, the device may collect employees, departments, job functions, membership relationships, and related triples within that named graph.

[0214] In the first collection mode above, after collecting a set of triples within the specific named graph, TBox triples corresponding to schema information and ABox triples corresponding to instance information can be separated. For example, the `owl:Class` declaration triple is used to generate node label definitions, the `owl:ObjectProperty` declaration and its domain / range triples are used to generate edge type definitions, and the `rdf:type` triple of an individual instance can be used to determine the label of the node instance.

[0215] The above-mentioned first collection mode is advantageous when multiple business domains or multiple document-unit graphs are stored together in the same RDF triple store. For example, if a personnel information named graph, a financial information named graph, and a research and development information named graph are stored separately in a single RDF triple store, the user can specify only the IRI of the personnel information named graph to extract only employee and department-related triple data and inversely transform it into a knowledge graph document model regarding the personnel domain.

[0216] The second collection mode described above is a mode that filters and transforms only instances and properties associated with at least one target class specified by the user based on an ontology hierarchy. Here, the target class may refer to an RDF class or OWL class selected by the user to use as a standard for data collection, and may be, for example, a `Person`, `Employee`, `Organization`, `Project`, `Vehicle`, or an IRI class defined in a specific domain.

[0217] In the second collection mode described above, a list of available classes can be generated by first querying the TBox triples of the target database. The device can search for classes declared as `owl:Class` or `rdfs:Class`, analyze the `rdfs:subClassOf` relationship to construct a class hierarchy, and then display it on a client terminal in a tree form or a list form. The user can select one or more target classes from the displayed classes.

[0218] Filtering based on the above-mentioned ontology hierarchy may mean determining the scope of collection by considering not only the target class specified by the user itself, but also its relationship with subclasses or superclasses. For example, if the user specifies the “Automobile” class as the target class, the device may collect not only instances belonging to the “Automobile” class, but also instances belonging to the subclasses of the Automobile class, such as “Electric Vehicle” or “Hydrogen Vehicle,” along with their attribute data.

[0219] In the second collection mode described above, the entity to be collected can be identified based on the `rdf:type` triple to search for instances associated with the target class. For example, if a specific entity has the `rdf:type ex:Employee` triple and `ex:Employee` corresponds to a target class specified by the user or a subclass thereof, the device can classify the entity as a node instance to be collected.

[0220] In the second collection mode described above, data type properties connected to the target entity can be collected together. For example, if data type properties such as `schema:name`, `schema:email`, `ex:employeeId`, and `ex:hireDate` are connected to an employee entity, the device can convert the corresponding attribute values ​​into property values ​​of a node instance. Additionally, if the data type properties are declared as `owl:DatatypeProperty` in the TBox, they can be converted into property templates.

[0221] In the second collection mode described above, object properties connected to the target entity can also be collected. For example, if an employee entity is connected to an organization entity through the `ex:worksFor` property, the device can convert the `ex:worksFor` relationship into an edge instance. In this case, if the domain and range of the object property are defined in a TBox, the device can map them to the source node label and destination node label of the edge type definition.

[0222] In the second collection mode described above, the depth of relationship extension can be limited to prevent the collection scope from being excessively expanded. For example, the device may collect only one-level relationships directly connected to target class instances, or extend to two-level relationships if specified by the user. Additionally, specific properties may be excluded from collection by including them in an exclusion list, or specific important properties may be included in an inclusion list for priority collection. Accordingly, the user can control the size and content of the subgraphs that match the domain of interest.

[0223] In the second collection mode described above, by collecting schema triples and instance triples associated with the target class together, the knowledge graph document model can be generated not as a simple list of instances, but as a document model including node label definitions, edge type definitions, and property templates. For example, the device can construct the schema information of the knowledge graph document model by collecting the target class's `rdfs:label`, `rdfs:comment`, superclass reference, related object property, and data type property definitions together.

[0224] The above third collection mode is a mode that executes a Custom SPARQL CONSTRUCT query written directly by the user to extract and transform a set of triples corresponding to the user-defined query results. Here, SPARQL may refer to a standard query language used to search for and manipulate data stored in an RDF triple store, and a SPARQL CONSTRUCT query may refer to a query format that returns results retrieved from an RDF triple store by constructing them into a new triple pattern specified by the user.

[0225] The above Custom SPARQL CONSTRUCT query may be a SPARQL syntax that, rather than simply returning data in a table format, assembles and returns a triple structure directly defined by the user based on the search results. The above third collection mode may be used to reflect complex business conditions that are difficult to express solely through named graph selection or class filtering, or to reflect a new graph connection structure desired by the user.

[0226] The above Custom SPARQL CONSTRUCT query can be created by the user writing it directly, or by the device providing a default template and the user modifying it. For example, the user can write a CONSTRUCT query that extracts only projects created after a specific period and the employees who participated in those projects, and the device can collect the set of triples returned as a result of executing the query into a subgraph.

[0227] In the above third collection mode, a user-defined graph topology different from the connection structure of the original RDF data can be configured by a SPARQL CONSTRUCT query written by the user. Here, topology may refer to the form or structural arrangement of a network in which nodes and edges are connected to each other. For example, even if the original database stores data connected in three stages in the form of “Employee-Department-Headquarters,” the user can define a triple structure that is directly connected to “Employee-Headquarters” by omitting the intermediate department stage through a SPARQL CONSTRUCT query.

[0228] In the third collection mode described above, the device may verify the query type, whether prohibited commands are included, the expected result size, time limits, and access permissions before executing the user's Custom SPARQL CONSTRUCT query. For example, the device may allow only CONSTRUCT queries for import queries and may not allow SPARQL UPDATE statements that perform data updates or deletions. Additionally, it may provide a warning to the user if the query execution time exceeds a preset time limit or if the expected number of triples is excessive.

[0229] In the third collection mode described above, after collecting a set of triples corresponding to the user-defined query results, the TBox and ABox information included in the set of triples can be analyzed and converted into the knowledge graph document model. However, since the CONSTRUCT query results written by the user may be configured differently from the original RDF schema structure, the device checks for the existence of `rdf:type`, `owl:Class`, `owl:ObjectProperty`, `owl:DatatypeProperty`, `rdfs:domain`, and `rdfs:range` triples within the query results, and can infer missing schema information or supplement it through user verification.

[0230] In the third collection mode described above, user-defined query results can provide a subgraph reconfigured to suit specific business logic. For example, even if the original RDF triple store stores complex data regarding employees, departments, projects, and work history, the user can create a CONSTRUCT query that represents only “employees who participated in projects within the last year and their departments.” Based on the query results, the device can generate a knowledge graph document model specialized for the corresponding business purpose.

[0231] In the above-described selective collection operation, TBoxes and ABoxes can be separated and extracted from the set of triples collected by the first collection mode, the second collection mode, or the third collection mode. The TBoxes represent schema information such as classes, properties, and hierarchical relationships, and the ABoxes represent data information such as individual instances and relationships between instances. By separating the TBoxes and ABoxes, the device can convert schema definitions and instance data into appropriate document model components, respectively.

[0232] In the above TBox extraction, resources declared as `owl:Class` or `rdfs:Class` can be converted into node label definitions. At this time, the device extracts the local names of class IRIs and normalizes them into PascalCase form to be used as node label keys or display names. Additionally, the `rdfs:subClassOf` triple can be converted into parent class references or hierarchical information, and can be utilized as base data for flattening strategies or multi-label strategies depending on whether the target database supports multi-labels.

[0233] In the above TBox extraction, the resource declared as `owl:ObjectProperty` can be converted into an edge type definition. At this time, the device can extract the local name of the object property IRI and normalize it into an edge type name based on uppercase letters and underscores. Additionally, the `rdfs:domain` triple can be mapped as a source node label candidate for the edge type definition, and the `rdfs:range` triple can be mapped as a destination node label candidate.

[0234] In the above TBox extraction, the resource declared as `owl:DatatypeProperty` can be converted into a property template. At this time, the device can normalize the IRI local name of the data type property into a property name in lowerCamelCase form, and if an XSD type is defined, it can map it to a scalar type such as a string, integer, real number, boolean, datetime, or JSON serialized string. For example, `xsd:string` can be converted to a string type, `xsd:integer` to an integer type, and `xsd:dateTime` to a datetime type.

[0235] In the above ABox extraction, node instances can be created by analyzing the `rdf:type` triple of individual instances. For example, if a specific IRI has the `rdf:type ex:Employee` triple, the device can convert the entity corresponding to that IRI into a node instance having the `Employee` node label. Additionally, the data type property triple associated with the individual instances can be converted into property values ​​of the node instances.

[0236] In the above ABox extraction, an edge instance can be generated by analyzing object property triples. For example, if a triple named `ex:employee001 ex:worksFor ex:company001` is collected, the device can generate an edge instance having the node corresponding to `ex:employee001` as the source node, the node corresponding to `ex:company001` as the destination node, and the edge type corresponding to `ex:worksFor`. At this time, the source node and the destination node can be mapped based on a previously determined identification key.

[0237] In the above-described optional collection operation, edge properties can be extracted by detecting a Reification pattern or an RDF-star pattern. For example, if a node of type `rdf:Statement` exists in an RDF standard Reification structure and includes values ​​of `rdf:subject`, `rdf:predicate`, and `rdf:object`, the device can convert this into a single edge and store the remaining additional properties as the property values ​​of that edge. Additionally, if a triple with a quoted triple as the subject exists in an RDF-star structure, the device can convert the attributes attached to that quoted triple into edge properties.

[0238] In the above selective collection operation, the collected set of triples can be processed in page, streaming, or chunk units rather than being loaded into memory all at once. For example, the device can sequentially retrieve only a certain number of triples by applying LIMIT and OFFSET to SPARQL queries or by using a cursor-based collection method. Accordingly, system overhead associated with loading the entire large-scale RDF dataset into memory can be reduced, and network bandwidth usage can be decreased.

[0239] In the above-described selective collection operation, for each collection mode, the estimated collection amount, the number of collected triples, the number of nodes to be generated, the number of edges to be generated, the number of node labels to be generated, and warning information can be provided to the user. For example, if the user selects a specific named graph, the device can display in advance the total number of triples included in that named graph and the expected transformation results. If the user selects a target class, the number of instances of the selected class and subclasses can be displayed.

[0240] The above-mentioned optional collection operation can record the difference between the selected collection range and the actual transformation result. For example, if instances related to a specific target class were collected but a hash-based identification key was used because some instances lacked an explicit identifier property, the device can record this fact in the Import result summary information. Additionally, if the domain or range of some object properties cannot be verified, the device can create the corresponding edge type definition in a temporary state and request user confirmation.

[0241] The knowledge graph document model generated by the above-described selective collection operation can be loaded in the form of a source-independent canvas. That is, the document model generated through any one of the first collection mode, the second collection mode, or the third collection mode can be provided with functions for node placement, edge connection, property editing, layout adjustment, and synchronization application, just like a document model created directly by the user or a document model generated by relational database import.

[0242] According to the above selective collection operation, only subgraphs corresponding to specific named graphs, specific classes, or user-defined query results among the semantic data assets accumulated in the RDF triple store can be selected and converted into a knowledge graph document model. Accordingly, a domain-specific knowledge graph suitable for the purpose can be constructed without unnecessarily collecting the entire large-scale RDF dataset, and subsequently, the knowledge graph document model can be resynchronized with a property graph database or an RDF triple store.

[0243] According to the above selective collection operation, it is possible to support the dynamic extraction and construction of partial knowledge graphs specialized for specific business logic. For example, users can separate and retrieve business domains by named graph unit, retrieve only specific object types by target class unit, or retrieve only partial graphs satisfying complex business conditions through Custom SPARQL CONSTRUCT queries. Accordingly, the device can efficiently generate knowledge graph document models suitable for the user's analysis and synchronization purposes regardless of the total data size of the RDF triple store, and can improve the effectiveness of heterogeneous database integration while optimizing system resources.

[0244] The above device may be configured to perform ontology design, knowledge graph modeling, database synchronization, and inverse transformation processing in a single integrated studio interface. The integrated studio interface may operate based on a three-boundary separation structure including an Editor View Model, a Document Model, and a Graph Model so that the screen state being edited, the actual document state to be saved, and the state to be reflected in the target database are not confused with each other while the user visually edits the knowledge graph document model.

[0245] The above three-boundary separation structure is a structure that manages the operation state that occurs temporarily in the user interface of a client terminal, the document state stored in a server or document repository, and the normalization state reflected in the target database by separating them into different layers. Accordingly, it is possible to prevent the user's screen operation from unnecessarily changing or contaminating the document storage state or the database synchronization results.

[0246] The editor view model above may be a state model of a first boundary that is temporarily maintained only on the user interface. For example, the editor view model may include at least one of a list of selected node identifiers, a list of selected edge identifiers, a mouse hover target node identifier, the X-coordinate, Y-coordinate and zoom scale of the canvas viewport, a panel open or closed state, a temporary property value being edited in the inspector, and a temporary connector state being dragged.

[0247] The above editor view model is not a target for server storage and is not included in the data synchronized to the target database. For example, even if a user selects a specific node, hovers the mouse over a specific edge, or zooms in or out of the canvas, these selection states, hover states, and viewport states are not stored as logical schema or instance data of the above knowledge graph document model, nor are they included in the normalized intermediate representation specifications.

[0248] The document model above may be a state model of a second boundary that stores knowledge graph design content created by a user or generated by inverse transformation from an external database in document units. The document model above may include at least one of node label definitions, edge type definitions, property templates, node instances, edge instances, layout information on a canvas, style information per object, synchronization setting information, and ontology reference information.

[0249] The above document model may be recorded on a server or document repository by a user's explicit save request or an automatic save action, and may serve as the basis for undo and redo functions. For example, if a user adds a new node label, changes the domain and range of an edge type, or modifies the property value of a node instance, these changes may be recorded as change history in the above document model. On the other hand, actions such as a user moving the screen or temporarily selecting a specific node may be managed only as the state of the above editor view model.

[0250] The above graph model may be a state model of a third boundary derived from the above document model and intended to be reflected in the actual target database. The above graph model may correspond to a normalized intermediate representation specification, and may be generated in the form of a NormalizedGraphSpec if the target database is a property graph database, and in the form of a NormalizedTripleSpec if the target database is an RDF triple store.

[0251] The above graph model includes only logical data reflected in the target database and does not include visual attributes such as canvas coordinates, node colors, edge styles, selection state, hover state, panel state, and temporary edit state. Accordingly, even if the same knowledge graph document model is displayed with different screen layouts or zoom ratios on different user terminals, the logical schema and instance data reflected in the target database can be consistently maintained.

[0252] According to the above three-boundary separation structure, visual manipulation actions by a user, such as simply selecting a node on the canvas or moving the screen, can be blocked from unnecessarily changing the saved state of the document model. In addition, even if the visual arrangement of a node on the canvas is arbitrarily changed, the corresponding visual attributes are not transmitted to the graph model, thereby preventing database synchronization operations from being unnecessarily triggered or existing data in the target database from being corrupted.

[0253] The integrated studio interface described above may include a left panel, a central canvas, a right inspector, and a bottom drawer. The left panel may display a list of node labels, edge types, and property templates included in the document schema, and may display a class hierarchy in a tree form if ontology design information is connected. When a user selects a specific class in the class hierarchy, a node label or node instance associated with that class may be highlighted on the central canvas.

[0254] The central canvas described above may serve as the primary workspace for visually arranging and editing nodes and edges. Users can place nodes on the central canvas using a drag-and-drop method, create edges by connecting nodes, and view the visual layout of the entire knowledge graph through pan and zoom operations. The placement and style adjustments performed on the central canvas may be saved as layout or style information for the document model, but may be excluded from the graph model reflected in the target database.

[0255] The above-mentioned right inspector may be an area for editing detailed attributes of a node, edge, node label definition, edge type definition, or property template selected on the above-mentioned central canvas. For example, when a user selects a specific node, the above-mentioned right inspector may display the node's label, identification key, property value, style override, and synchronization target status, and the user may modify the corresponding values ​​using an inline editing method.

[0256] The bottom drawer above may be an area displaying at least one of a query console, synchronization status, execution log, and revision history. The query console may be an input area for executing a lookup or validation query for a target database, the synchronization status area may display preview results, synchronization plan data, application results, and warning messages, the execution log area may display query execution results and error information, and the revision history area may display the change history of the document model.

[0257] The integrated studio interface described above can operate adaptively based on capability information of the connected adapter. For example, if the multi-label support status of the adapter corresponding to the target database is identified as false, guidance information indicating that the class hierarchy is flattened based on property inheritance may be displayed on the left panel or the synchronization preview screen. Conversely, if the multi-label support status is identified as true, guidance information indicating that the class hierarchy is mapped to multiple labels may be displayed.

[0258] The above integrated studio interface can provide different formats for specialized queries displayed on the synchronization preview screen depending on the query language and connection method of the target database. For example, if the target database is Neo4j, the preview interface can display pure Cypher queries; if the target database is Apache AGE, it can display Cypher queries wrapped in SQL; and if the target database is an RDF triple store, it can display SPARQL UPDATE queries. Accordingly, users can check in advance how the same knowledge graph document model is converted for each target database.

[0259] The above device may include a relational database schema analyzer that queries schema information of a relational database or receives external mapping definition data and converts a relational table structure into a property graph model. The relational database schema analyzer may generate an initial schema draft of the knowledge graph document model by analyzing information on tables, columns, primary keys, foreign keys, indexes, and constraints accumulated in the relational database.

[0260] The above relational database schema analyzer may provide an automatic schema lookup mode and a mapping definition data input mode. The automatic schema lookup mode may be a mode that automatically collects table names, column names, data types, primary keys, foreign keys, and index information using the relational database's metadata catalog, information_schema, system tables, or database-specific schema lookup APIs. The mapping definition data input mode may be a mode that receives mapping definition data in CSV, Excel, or JSON format and performs graph transformation by supplementing logical relationships even in relational databases where actual foreign key constraints are not set.

[0261] The above relational database schema information may refer to metadata catalog information including table names, column names, data types, primary keys (PK), foreign keys (FK), indexes, constraints, and relationship information between tables within a legacy database. Based on the above relational database schema information, the device can determine whether a table is a node table representing a single entity, an edge table representing a relationship, a bridge table for a many-to-many join, or a reference table providing a code value.

[0262] The above relational database schema analyzer can convert a table in a relational database into a node label definition. In this case, the device can normalize the table name into PascalCase form to use as a node label key or display name. For example, the `employee_master` table can be converted into the `EmployeeMaster` node label definition, and the `project_assignment` table can be converted into a node label definition or an edge type definition depending on its structure.

[0263] The above relational database schema analyzer can convert the columns of a table into property templates. In this case, the device can normalize the column names into lowerCamelCase form and map SQL data types to scalar types used in the knowledge graph document model. For example, VARCHAR, CHAR, and TEXT can be converted to string types; INTEGER, BIGINT, and SMALLINT to integer types; FLOAT, DOUBLE, NUMERIC, and DECIMAL to real number types; BOOLEAN to boolean types; DATE, TIMESTAMP, and TIMESTAMPTZ to date / time types; and JSON and JSONB to JSON serialized string types.

[0264] The above relational database schema analyzer can map the primary key of a table to the identification key of the above node label definition. If a single primary key exists, the corresponding primary key column can be directly designated as the identification key; if a composite primary key exists, multiple primary key column values ​​can be combined according to a pre-configured separator or hash-based combination rule to generate a composite identification key. Accordingly, when row data of the relational database is converted into node instances, each node instance can be uniquely identified.

[0265] The above relational database schema analyzer can convert foreign keys into edge type definitions. For example, if the `department_id` column of the `employee` table references the primary key of the `department` table, the device can generate an edge type definition in which the node label corresponding to the `employee` table is the source node label and the node label corresponding to the `department` table is the destination node label. In this case, the edge type name can be determined based on the foreign key name, column name, reference table name, or the result of a proposal based on a large-scale language model.

[0266] The above relational database schema analyzer can convert M:N join tables, which are difficult to view as independent entities and include two or more foreign keys referencing the primary keys of both tables, into edge type definitions and edge properties. For example, if the `employee_project` table includes columns `employee_id`, `project_id`, `role`, and `start_date`, `employee_id` and `project_id` can be used as relationship keys to determine the origin and destination nodes, and `role` and `start_date` can be converted into property values ​​of the corresponding edge instances.

[0267] In the above mapping definition data input mode, edge types can be generated based on user-defined logical relationship information even for relational databases where foreign key constraints do not physically exist. For example, the mapping definition data may include source table name, source column name, reference table name, reference column name, relationship direction, edge type name, join condition, and edge property mapping information. The device can restore logical relationships that do not exist in the actual database schema into a property graph structure by referencing the mapping definition data.

[0268] The above device may include a large-scale language model-based relational schema mapping proposal module that automatically proposes a draft property graph mapping from the table and column structures of a relational database. The mapping proposal module can infer the role of each table within the graph by analyzing at least one of the table name, column name, data type, primary key, foreign key, index, number of rows, column value samples, and naming rules between tables of the relational database.

[0269] The above mapping proposal module can classify each table into any one of an entity table, a join table, a reference table, a code table, or an attribute auxiliary table. For example, a table with an independent primary key and multiple attribute columns can be classified as an entity table for node creation, a table with two or more foreign keys and relational attribute columns can be classified as a join table for edge creation, and a table with a small number of code values ​​and description values ​​can be classified as a reference table or a property mapping target.

[0270] The mapping proposal module described above can generate a mapping draft that includes a node label name corresponding to an entity table, an edge type name corresponding to a join table or foreign key relationship, an edge direction, a property mapping, identification key candidates, and columns to be excluded. For example, if a `department_id` column exists between the `employee` table and the `department` table, the mapping proposal module may propose edge type name candidates such as `WORKS_IN`, `BELONGS_TO`, or `ASSIGNED_TO_DEPARTMENT`.

[0271] The above mapping proposal module can infer hidden relationships between tables by analyzing column names, data types, table names, column value samples, and domain context, even when explicit foreign key constraints are not physically set on an actual operational relational database. For example, if `user_id`, `product_id`, and `order_date` columns exist in a specific table, the mapping proposal module can generate edge type candidates representing the purchase relationship between a user and a product.

[0272] The mapping draft generated by the mapping proposal module described above may be displayed in a user review interface. The user may modify or approve the proposed node label name, edge type name, relationship direction, identification key, inclusion of properties, and join table processing method. The device transmits the mapping definition confirmed by the user to the data extraction pipeline of a relational database schema analyzer and can create node instances and edge instances according to the confirmed mapping definition.

[0273] The above relational database schema analyzer can execute a SELECT query on the target relational database after the mapping rules are finalized to convert rows of each table into node instances and rows corresponding to foreign key relationships or join tables into edge instances. The results of the conversion can be placed on the central canvas as a draft document model, and the user can finalize it as the final document model after reviewing or modifying node labels, edge types, property templates, identification keys, and relationship directions.

[0274] The above device may include a natural language ontology generation module in which a large-scale language model analyzes a description of a domain by a user and generates a draft ontology. The natural language ontology generation module can receive the user's domain description, business rules, example sentences, glossaries, or existing document content as input and extract core concepts, class hierarchies, object properties, and data type properties.

[0275] The above domain description may refer to a natural language sentence describing the industry sector, key objects, relationships between objects, and attributes of each object of the knowledge graph that the user intends to build. The above natural language ontology generation module can semantically analyze the input natural language sentence to convert core concepts into class candidates and construct the relationships between super-concepts and sub-concepts into class hierarchy candidates based on rdfs:subClassOf.

[0276] The above natural language ontology generation module can extract behavior, membership, participation, possession, management, creation, reference, or connection relationships between concepts as object property candidates, and extract attributes such as name, code, date, amount, state, description, and quantity as data type property candidates. Additionally, the above natural language ontology generation module can generate at least one of a label, description, domain, range, data type, and example instance together with the class candidate, object property candidate, and data type property candidate.

[0277] For example, if a user inputs, “There are doctors and patients in the hospital, doctors treat patients, and patients have symptom and age information,” the device can generate class candidates corresponding to doctors and patients, generate candidate treatment relationship object properties that connect the two classes, and automatically assign symptom and age data type property candidates to the patient class. Accordingly, even domain experts who are not familiar with the use of professional ontology editing tools can perform the initial design of a knowledge graph schema using only natural language instructions.

[0278] The above natural language ontology generation module can display the generated ontology draft in a user review interface. The user can modify or approve class names, parent-child relationships, object property names, domains, ranges, data type property names, and data types. When the user finalizes the ontology draft, the device can generate a knowledge graph document model including node label definitions, edge type definitions, and property templates by using the finalized ontology design information as input for a modeling operation.

[0279] The above natural language ontology generation module can also support incremental expansion of existing ontology design information. For example, when a user inputs a natural language instruction such as “add concepts related to insurance claims,” the device can generate new class candidates and new property candidates by referencing the class names, property names, and hierarchical structure of the existing ontology, and after reviewing for duplication with existing elements, name conflicts, and domain / range conflicts, present merge candidates.

[0280] The above device may include a schema metadata export module that exports schema information of a document model as structured metadata that can be interpreted by a large-scale language model. The schema metadata export module may generate schema metadata including at least one of a list of node labels, a list of edge types, property names and data types of each node label, source node labels and destination node labels of each edge type, relationship summary information, identification key information, index candidates, and sample Cypher queries.

[0281] The schema metadata may be a summary document containing a complete list of node labels existing within the graph, the names and data types of properties held by each label, a list of edge types specifying source and destination nodes, summary information on relationships regarding the overall graph structure, and a sample Cypher query that can be queried to the target database. The schema metadata may be generated in at least one of JSON Schema, YAML, or Markdown format.

[0282] The schema metadata export module described above can generate a schema prompt to convert a natural language question into a graph query in a GraphRAG pipeline. For example, if a user inputs a natural language question such as “Who are the employees who participated in the project in the last year?”, the device can provide schema metadata including node labels, edge types, property names, and a sample Cypher query as an input context for a large-scale language model. Accordingly, the large-scale language model can generate a Cypher query or a graph lookup query based on schema elements existing in the actual document model.

[0283] The above GraphRAG pipeline may be a processing flow that executes a graph query generated based on the schema metadata on a target database and provides the execution results back to a large-scale language model to generate a final natural language response. Before executing the query generated by the large-scale language model, the device may verify whether the node labels, edge types, and property names included in the query exist in the schema metadata. Accordingly, this prevents the execution of phantom queries that reference non-existent schema elements and can improve the syntactic accuracy and schema consistency of the query during the text-to-cypher process.

[0284] The above device may include an RDF export module that inversely converts the schema and instance data of the knowledge graph document model into RDF format and exports them externally. The RDF export module can convert node label definitions, edge type definitions, property templates, node instances, and edge instances included in the knowledge graph document model into a set of RDF triples.

[0285] The above RDF export module can convert a node label definition into an owl:Class declaration triple. For example, if a node label definition of `Employee` exists, the device can generate an IRI corresponding to `Employee` and generate a triple indicating that the IRI is `owl:Class`. Additionally, if a superclass reference exists in a node label definition, the device can convert it into an rdfs:subClassOf triple.

[0286] The above RDF export module can convert edge type definitions into owl:ObjectProperty declaration triples. At this time, the device can convert the source node label of the edge type definition into an rdfs:domain triple and the destination node label into an rdfs:range triple. For example, if the `WORKS_FOR` edge type is defined to connect from the `Employee` node label to the `Organization` node label, the device can generate domain and range triples along with the object property IRI corresponding to `WORKS_FOR`.

[0287] The above RDF export module can convert a property template into an owl:DatatypeProperty declaration triple. At this time, the device can reverse map the data type of the property template to an XSD type. For example, a string type can be converted to xsd:string, an integer type to xsd:integer, a floating-point type to xsd:decimal or xsd:double, a boolean type to xsd:boolean, and a datetime type to xsd:dateTime.

[0288] The above RDF export module can convert a node instance into an RDF Individual. For example, if a node instance with the node label `Employee` exists, the device can generate an instance IRI based on the identification key or original IRI of the node instance and generate an rdf:type triple indicating that the instance belongs to the `Employee` class. Additionally, the property values ​​of the node instance can be converted into data type property triples.

[0289] The above RDF export module can convert edge instances into object property triples. For example, if a specific employee node is connected to a specific organization node via the `WORKS_FOR` edge, the device can generate an RDF triple with the employee instance IRI as the subject, the object property IRI corresponding to `WORKS_FOR` as the predicate, and the organization instance IRI as the object.

[0290] The above RDF export module may optionally use the RDF-star method or the Reification method to represent edge properties of a property graph in RDF. In a property graph model, properties such as contract date, role, weight, trust, or source can be stored directly in the edges themselves; however, since it is difficult to directly assign attributes to the relationships themselves in a traditional RDF triple structure, the device may select an edge property serialization method based on the target system's support and user settings.

[0291] The above RDF-star method may be a method that uses quoted triples to treat the edge itself as a subject and represents the properties assigned to the edge as additional triples. The above Reification method may be a method that uses the rdf:Statement, rdf:subject, rdf:predicate, and rdf:object vocabularies to represent relational triples as separate statement nodes and assign edge properties to the statement nodes. Accordingly, edge properties of a property graph can be represented without loss in the RDF ecosystem.

[0292] The above RDF export module can provide the generated set of RDF triples by serializing them into at least one of Turtle, OWL / XML, or JSON-LD formats. For example, the user can export the knowledge graph document model to an external system by selecting any one of the human-readable Turtle format, the OWL / XML format which is highly compatible with OWL tools, or the JSON-LD format which is easy to integrate with web applications.

[0293] The device may generate a normalized triple specification to non-destructively synchronize the knowledge graph document model to an RDF triple store. The normalized triple specification may be a normalized intermediate representation of an RDF target corresponding to a normalized graph specification of a property graph target, and may include at least one of a document identifier, a base IRI, a named graph IRI, a schema triple, an instance triple, and synchronization metadata.

[0294] The above RDF adapter may sequentially perform a named graph list lookup operation, a triple lookup operation, a triple difference calculation operation, a SPARQL UPDATE generation operation, and a synchronization plan execution operation to perform non-destructive synchronization with the RDF triple store. The named graph list lookup operation may be an operation that retrieves and returns at least one of the identifier of a named graph existing in the RDF triple store, the number of triples included in each named graph, the number of classes, or the last update time.

[0295] The above triple lookup operation may be an operation that queries an existing set of triples existing within the corresponding named graph context based on a named graph IRI specified by the user or by the synchronization settings of the knowledge graph document model. For example, the RDF adapter may collect subject, predicate, object, and graph identifier information within a specific named graph using a SPARQL SELECT or CONSTRUCT query.

[0296] The above triple difference calculation operation may be an operation that classifies insertion targets, update targets, deletion candidates, and unchanged targets by comparing the existing set of triples collected through the above triple lookup operation with the new normalized triple specifications generated from the knowledge graph document model. In this case, the RDF adapter can reduce the computational cost associated with large-scale triple comparison by serializing the subject, predicate, and object of each triple into a normalized string and hashing the serialized value.

[0297] The above SPARQL UPDATE generation operation may be an operation that generates an executable SPARQL UPDATE query in an RDF triple store based on the insertion target, update target, and deletion candidate calculated in the above triple difference calculation operation. For example, an INSERT DATA statement may be generated for the insertion target triple, a DELETE / INSERT / WHERE statement may be generated for the update target triple, and a DELETE DATA statement or deletion exclusion warning information may be generated for the deletion candidate triple according to the deletion policy.

[0298] The above synchronization plan execution operation may be an operation that executes the list of queries generated through the above SPARQL UPDATE generation operation into the RDF triple store according to the user's application request. If the target RDF triple store supports transactions, the RDF adapter may execute multiple SPARQL UPDATE queries within a single transaction; if it does not support transactions, it may maintain synchronization integrity using batch execution units, failure abort rules, or compensation processing logs.

[0299] The RDF adapter described above may include the results of each operation in synchronization plan data or audit records. For example, the audit records may include at least one of the queried named graph IRIs, the number of existing triples, the number of new triples, the number of insertions, the number of updates, the number of deletion candidates, the number of generated SPARQL UPDATE queries, whether execution was successful, and error messages. Accordingly, the synchronization process for the RDF triple store is transparently recorded, and traceable criteria can be provided for resynchronization or error analysis.

[0300] The above document identifier may be a value that uniquely identifies the document to be synchronized. The above base IRI may be used as a namespace for generating node labels, edge types, property templates, and instance IRIs. The above named graph IRI may be an identifier for an RDF triple storage space generated by combining the above base IRI and the document identifier, for example, ` <baseiri> / graph / <documentid>It can be generated in the form of `

[0301] The schema triple may include at least one of the owl:Class, owl:ObjectProperty, owl:DatatypeProperty, rdfs:domain, rdfs:range, and rdfs:subClassOf declaration triples as a triple corresponding to a TBox. The instance triple may include at least one of the rdf:type triple, data type property triple, and object property triple of an individual node instance as a triple corresponding to an ABox. The synchronization metadata may include at least one of a synchronization mode, a deletion policy, an edge property processing mode, triple count statistics, the last synchronization time, and an administrator mark.

[0302] The above normalized triple specification does not include visual attributes such as coordinates, colors, styles, selection state, hover state, or viewport state on the canvas. Accordingly, regardless of where the user places a node on the visual canvas, the RDF triple store can reflect only logical triples representing classes, properties, instances, and relationships.

[0303] The above device may apply a named graph-based isolation strategy to ensure non-destructive synchronization in an RDF triple store. In the named graph-based isolation strategy, each knowledge graph document model has a triple storage space corresponding to a unique named graph IRI, and triples managed by the device and triples directly added by an external system or user can be distinguished.

[0304] The device may store synchronization metadata triples together within the named graph. For example, the synchronization metadata triple may include at least one of an administrator mark, a document identifier, a last synchronization time, a synchronization mode, a deletion policy, and an edge property processing mode. Accordingly, even if multiple document models are synchronized to the same RDF triple store, the sets of triples for each document do not interfere with each other, and upon resynchronization, it is possible to determine which triple is under the management of the device.

[0305] The above device may apply a triple difference algorithm to compare triples of an existing named graph with triples of a new normalized triple specification. The triple difference algorithm uses the subject and predicate of each triple as comparison keys and determines whether the object has been modified, classifying them as insertion targets, update targets, deletion candidates, or no modifications. Additionally, in the case of properties with multiple objects, the combination of the subject, predicate, and object can be hashed to determine whether they are identical triples.

[0306] In the above triple difference algorithm, triples that do not exist in the existing named graph but exist only in the new normalized triple specification can be classified as insertion targets; triples where the same subject and predicate exist in both the existing named graph and the new normalized triple specification but the object has changed can be classified as update targets; and triples that exist in the existing named graph but not in the new normalized triple specification can be classified as deletion candidates. However, the actual deletion of deletion candidates may be determined according to the deletion policy.

[0307] The above device may provide at least one of a schema-only mode, a schema and data mode, and a data overlay mode as an RDF triple store synchronization mode. The schema-only mode may be a mode that synchronizes only TBox triples, such as class, object property, and data type property definitions. The schema and data mode may be a mode that synchronizes both TBox triples and ABox triples. The data overlay mode may be a mode that adds or updates only ABox triples corresponding to instance data without modifying the existing schema.

[0308] The above device may provide at least one of an automatic deletion prohibition policy, an explicit deletion policy, and a management graph-wide replacement policy as an RDF triple store synchronization deletion policy. The automatic deletion prohibition policy may be a default policy that prevents elements removed from the document model from being automatically deleted from the RDF triple store. The explicit deletion policy may be a policy that generates deletion queries only for triples designated by the user as deletion targets. The management graph-wide replacement policy may be a policy that deletes the entire specific named graph and then re-inserts triples according to the new normalized triple specification.

[0309] Although the above-mentioned policy for replacing the entire management graph has the advantage of being simple to implement, since it may delete triples added externally within the same named graph, the device may provide warning information to the user and request explicit confirmation when such a policy is selected. Accordingly, the user may perform synchronization using the full replacement method only when aware of the possibility of data loss in the operating environment.

[0310] The above device can generate a SPARQL UPDATE query based on the result of the triple difference algorithm. For example, for triples classified as insertion targets, it can generate an INSERT DATA statement targeting a specific named graph IRI, and for triples classified as update targets, it can generate a DELETE / INSERT / WHERE statement that deletes the existing object and inserts a new object, and if the entire managed graph replacement policy is selected, it can generate a combination of a DROP GRAPH statement and an INSERT DATA statement.

[0311] The above SPARQL UPDATE query may be included in the synchronization plan data in the preview provision operation and displayed to the user, and may be executed in the RDF triple store only when a user's application request is received. The device may record the number of triples, insertions, updates, deletions, and error information before and after the execution of the SPARQL UPDATE query, and may maintain data consistency through transactions, batch aborting, or compensation processing procedures in the event of an error during execution.

[0312] Based on the integrated studio interface, relational database schema analyzer, large-scale language model-based mapping proposal module, natural language ontology generation module, schema metadata export module, RDF export module, and RDF triple store synchronization structure described above, users can perform ontology design, relational database-based knowledge graph generation, visual editing, GraphRAG utilization, RDF file export, and heterogeneous database synchronization as a single continuous workflow. Consequently, the reusability of design assets is enhanced, physical constraints specific to database vendors are alleviated, and substantial bidirectional interoperability between the RDF ecosystem and the property graph ecosystem becomes possible.

[0313] According to the above configuration, ontology design information, relational database schema information, the node and edge structure of a property graph database, and the triple structure of an RDF triple store can be integrated into a single knowledge graph document model. Accordingly, users can design, edit, validate, export, and synchronize knowledge graphs based on the same visual canvas and the same document model, even in heterogeneous database environments using different data models and query languages.

[0314] In addition, according to the above configuration, database-specific specialized queries are generated based on database-independent normalized intermediate representation specifications, allowing for the construction of knowledge graph design assets that are not dependent on a specific database vendor. Accordingly, users can reuse the same knowledge graph document model not only in property graph databases such as Neo4j and Apache AGE but also in RDF triple stores, and reduce the cost of rewriting design assets during database replacement or concurrent operation.

[0315] Furthermore, according to the above configuration, existing data in the target database can be protected through a non-destructive synchronization procedure based on preview and application. Users can preview change summaries, query lists, deletion candidates, and warning information before specialized queries are actually executed on the target database, and at the time of application, document hash value verification and transaction-based execution can prevent outdated synchronization plans or intermediate changes to document states from being incorrectly reflected in the target database.

[0316] Furthermore, according to the above configuration, the class hierarchy of ontology design information, the domain and range of object properties, and the type constraints of data type properties can be applied together to the knowledge graph document model and the target database reflection process. Accordingly, unlike simple visual graph editing tools, synchronization to the property graph database and RDF triple store can be performed while maintaining ontology-based semantic consistency.

[0317] Furthermore, according to the above configuration, legacy data assets accumulated in a relational database can be automatically converted into a property graph model including node labels, edge types, property templates, and identification keys. In particular, since hidden logical relationships can be restored through mapping definition data or mapping proposals based on large-scale language models even in database environments where physical foreign keys do not exist, existing relational database assets can be reused in knowledge graph-based analytics and GraphRAG environments.

[0318] Furthermore, according to the above configuration, domain experts and large-scale language models can share the same knowledge graph schema through natural language-based ontology generation and schema metadata export. Domain experts can generate ontology drafts by describing domain concepts and relationships in natural language, and large-scale language models can generate graph queries based on actual node labels, edge types, and property names by referencing the exported schema metadata. Accordingly, this can reduce illusory queries that may occur during the text-to-cypher process and improve the reliability of graph-based search augmentation generation.

[0319] Furthermore, according to the above configuration, edge properties of a property graph model can be converted using the RDF-star or Reification method, allowing relational attributes expressed in the property graph ecosystem to be represented in the RDF triple store ecosystem without loss. Consequently, data portability and interoperability between property graph-based business models and semantic web-based knowledge representation models can be enhanced.

[0320] Furthermore, according to the above configuration, non-destructive synchronization of RDF data can be performed through a named graph-based isolation strategy and a triple difference algorithm for the RDF triple store. Since each document model is managed based on a unique named graph IRI and the difference between existing and new triples is classified into insertion, update, deletion candidate, and no change, secure incremental synchronization at the document level is possible even in large-scale RDF triple stores.

[0321] Consequently, according to the above device and method, functions that were previously separated into an ontology design tool, a visual graph modeling tool, a relational database migration tool, a property graph database management tool, and an RDF triple store management tool can be provided on a single integrated platform. Accordingly, the entire lifecycle of a knowledge graph—including design, creation, verification, transformation, querying, exporting, and synchronization—can be unified into a single workflow, and the safety, scalability, and reusability of knowledge graph operations in heterogeneous database environments can be improved.

[0322] An apparatus according to one embodiment includes a processor and memory. The processor may include at least one apparatus described above through the drawings or perform at least one method described above through the drawings. The memory may store information related to the method described above or store a program in which the method described above is implemented. The memory may be volatile memory or non-volatile memory.

[0323] The processor can execute a program and control the device. The code of the program executed by the processor can be stored in memory. The device can be connected to an external device (e.g., a personal computer or a network) through an input / output device (not shown in the drawing) and exchange data.

[0324] The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose or special-purpose computers, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing unit may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing unit may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing unit may be described as being used as a single unit, but those skilled in the art will understand that the processing unit may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

[0325] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0326] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and may be stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0327] Although the embodiments have been described above with reference to the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, suitable results may be achieved even if the described techniques are performed in a different order than described, and / or if the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

[0328] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims set forth below.< / documentid> < / baseiri>

Claims

Claim 1 A method for ontology-based knowledge graph modeling and non-destructive bidirectional linkage for a heterogeneous database environment, wherein the device includes a processor, memory, a communication module, and a non-transient storage medium, and the method is performed by the processor by executing a program stored in the non-transient storage medium, comprising: a modeling operation that identifies an adapter type corresponding to a target database based on a connection profile, extracts ontology components from ontology design information, and generates a knowledge graph document model including a schema structure of a property graph according to a pre-set transformation rule; a normalization operation that generates a normalized intermediate specification from the knowledge graph document model that excludes visual attributes and is independent of the database, corresponding to the type of the target database; and a query transformation operation that transforms the normalized intermediate specification into a specialized query specialized for the target database through the adapter. and a non-destructive bidirectional linkage operation comprising: incrementally reflecting changes to the knowledge graph document model while preserving existing data in the target database using the specialized query, or collecting and analyzing data stored in the target database and inversely transforming it into a knowledge graph document model to reflect it; an ontology-based knowledge graph modeling and non-destructive bidirectional linkage method for a heterogeneous database environment. Claim 2 In claim 1, the non-destructive bidirectional linkage operation comprises: generating synchronization plan data including a list of specialized queries and synchronization summary information in response to a synchronization preview request received from a client terminal without immediately reflecting the specialized query in the target database, transmitting the synchronization plan data to the client terminal so that the synchronization plan data is visually displayed as a preview interface on the screen of the client terminal, and temporarily storing the synchronization plan data for a preset valid time (TTL); The method comprises: an application operation that, when a user’s apply request for synchronization plan data is received from the client terminal, verifies whether an intermediate change has occurred in the document by comparing a first hash value for the knowledge graph document model at the time of the preview provision operation with a second hash value for the knowledge graph document model at the time of receiving the apply request, executes a transaction-based specialized query on the target database only if the first hash value and the second hash value match, and invalidates the synchronization plan data if the first hash value and the second hash value do not match; thereby preventing existing data loss in an operating environment and ensuring systemic integrity, an ontology-based knowledge graph modeling and non-destructive bidirectional interoperability method for a heterogeneous database environment. Claim 3 In claim 1, the modeling operation comprises: a hierarchy resolution strategy determination operation that adaptively determines a hierarchy resolution strategy by referring to a supportsMultiLabel parameter within the capability information (AdapterCapabilities) declaratively provided by the adapter when mapping the hierarchy (rdfs:subClassOf) between the superclass and subclass included in the ontology design information to the schema structure of the property graph; and the hierarchy resolution strategy determination operation comprises: for a first type adapter in which the supportsMultiLabel parameter is identified as False, a flattening strategy application operation that generates the knowledge graph document model by applying a flattening strategy that resolves the inheritance relationship into a single hierarchy by physically copying and merging the property template defined in the superclass to the node label definition of the subclass. and for a second type adapter in which the multi-label support parameter is identified as True, a multi-label strategy application operation is applied to generate the knowledge graph document model by defining to separate and maintain property templates for each of the upper class and lower class, and to assign multiple labels corresponding to the upper class and lower class in parallel when creating a single node instance; comprising: an ontology-based knowledge graph modeling and non-destructive bidirectional interoperability method for a heterogeneous database environment that ensures query integrity across the heterogeneous environment by fully preserving the hierarchical logic and polymorphism of the original ontology without being dependent on the physical schema constraints of the target database vendor.

Images