Unified management method, device and equipment for ontology resources and storage medium

Abstract

The present disclosure provides an ontology resource-oriented unified management method, device, equipment and storage medium, the method comprising: receiving a resource increase request of a business system, the resource increase request comprising a namespace, a parent resource identifier, a physical type, a business type, basic data corresponding to the resource to be added, and an identifier of the business system; checking the operation authority corresponding to the resource increase request based on the namespace, the parent resource identifier, the physical type, the business type, and the identifier of the business system of the resource to be added, and determining whether the check is passed; in the case where it is determined that the check is passed, generating a globally unique identifier and path index data for the resource to be added, and storing the globally unique identifier, the path index, the namespace, the parent resource identifier, the physical type, the business type, and the basic data of the resource to be added as metadata of the resource to be added in the core resource table. Through the method of the present disclosure, cross-system reference and tracking of ontology resources can be realized.

Description

Technical Field

[0001] This disclosure relates to the field of resource management technology, and in particular to a unified management method, apparatus, device and storage medium for ontology resources. Background Technology

[0002] In ontology engineering and data intelligence systems, various ontology resources, such as ontology entities, relations, actions, functions, datasets, process configurations, knowledge base documents, and application components, are typically managed separately by different business systems. However, the identification, physical storage methods, business semantics, access paths, and permission policies of resources in different business systems are deeply coupled within each system, lacking global overall management. This leads to difficulties in cross-system referencing and tracking of ontology resources. Therefore, how to achieve cross-system referencing and tracking of ontology resources has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0003] In view of this, this disclosure proposes a unified management method, apparatus, device and storage medium for ontology resources, which can realize cross-system reference and tracking of ontology resources.

[0004] According to a first aspect of this disclosure, a unified management method for ontology resources is provided, comprising: Receive a resource addition request from a business system, wherein the resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and identifier of the business system corresponding to the resource to be added; The operation permissions corresponding to the resource addition request are verified based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and it is determined whether the verification passes. If the verification passes, a globally unique identifier and path index data are generated for the resource to be added. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

[0005] In one possible implementation, when verifying the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and determining whether the verification passes, the process includes: Based on the namespace corresponding to the resource to be added, the parent resource identifier, and the identifier of the business system, determine whether the resource addition request has the corresponding role operation permission; If it is determined that the resource addition request has the corresponding role operation permission, then based on the physical type and the business type of the resource to be added, it is determined whether the resource addition request has the corresponding resource type operation permission. If it is determined that the resource addition request has the corresponding resource type operation permission, the verification is deemed to have passed.

[0006] In one possible implementation, when determining whether the request to add the resource has the corresponding resource type operation permission based on the physical type and the business type corresponding to the resource to be added, the process includes: Determine whether the business type has been registered; If the business type is already registered, determine whether the business type is allowed to be bound to the physical type; If it is determined that the business type allows binding to the physical type, then the resource addition request is deemed to have the corresponding resource type operation permission.

[0007] In one possible implementation, generating path index data for the resource to be added includes: Obtain the namespace corresponding to the resource to be added, and use it as the first-level path index; Obtain the parent resource identifier corresponding to the resource to be added, and recursively query the existing path index of the parent resource corresponding to the resource to be added based on the parent resource identifier; Based on the first-level path index and the existing path index of the parent resource, the path index of the resource to be added is generated, and the path index status of the path index of the resource to be added is set to synchronized. The path index of the resource to be added and the path index status are used as the path index data of the resource to be added.

[0008] In one possible implementation, the resource to be added is a file resource, and if the verification passes, the method further includes: An upload session is created for the file resource, wherein the upload session includes a session flag, an expiration time, and object storage space allocated for the file resource; Based on the upload session, a direct upload credential for the file resource is issued to the business system, so that the business system can directly upload the file resource to the object storage space using the direct upload credential; The upload result of the file resource is verified. If the verification is successful, a globally unique identifier and path index data are generated for the resource to be added. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

[0009] In one possible implementation, after storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the method further includes: Receive a resource update request from a business system, wherein the resource update request includes a globally unique identifier, namespace, parent resource identifier, physical type, business type, basic data, and the identifier of the business system corresponding to the resource to be updated; The operation permissions corresponding to the resource update request are verified based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be updated, and it is determined whether the verification passes. If the verification passes, a version snapshot is generated for the previous version of the resource to be updated; After generating the version snapshot, the resource to be updated is then updated.

[0010] In one possible implementation, after storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the method further includes: Generate lineage records for each resource in the core resource table, wherein the lineage records include static lineage relationships for recording long-term derivation relationships between the resources and dynamic lineage relationships for recording the execution process, the input resources and output resources in the execution process.

[0011] According to a second aspect of this disclosure, a unified management apparatus for ontology resources is provided, comprising: The permission verification module is used to receive resource addition requests from the business system. The resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and identifier of the business system corresponding to the resource to be added. The module verifies the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and identifier of the business system corresponding to the resource to be added, and determines whether the verification passes. The core resource table management module is used to generate a globally unique identifier and path index data for the resource to be added when the verification is passed, and to store the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type and basic data corresponding to the resource to be added as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

[0012] According to a third aspect of this disclosure, a unified management device for ontology resources is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the method described in the first aspect of this disclosure.

[0013] According to a fourth aspect of this disclosure, a non-volatile computer-readable storage medium is provided that stores computer program instructions thereon, wherein the computer program instructions, when executed by a processor, implement the method described in the first aspect of this disclosure.

[0014] This disclosure provides a unified management method, apparatus, device, and storage medium for ontology resources. The method includes: receiving a resource addition request from a business system, the request including the namespace, parent resource identifier, physical type, business type, basic data, and business system identifier corresponding to the resource to be added; verifying the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and determining whether the verification passes; if the verification passes, generating a globally unique identifier and path index data for the resource to be added, and storing the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data of the resource to be added as metadata in a core resource table. This method enables cross-system referencing and tracking of ontology resources.

[0015] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0016] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0017] Figure 1 A flowchart illustrating a unified management method for ontology resources according to an embodiment of the present disclosure is shown; Figure 2 A schematic diagram illustrating the process of asynchronous reconstruction of resource movement and virtual path index according to an embodiment of the present disclosure is shown. Figure 3 This diagram illustrates a process for querying resources during resource movement according to an embodiment of the present disclosure. Figure 4 This diagram illustrates a resource version and lineage tracing relationship according to an embodiment of the present disclosure; Figure 5 A schematic block diagram of a unified management apparatus for ontology resources according to an embodiment of the present disclosure is shown; Figure 6 A schematic block diagram illustrating an example of a unified management apparatus for ontology resources according to an embodiment of the present disclosure; Figure 7 A schematic block diagram of a unified management device for ontology resources according to an embodiment of the present disclosure is shown. Detailed Implementation

[0018] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0019] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0020] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0021] <Method Implementation> Figure 1 A flowchart illustrating a unified management method for ontology-oriented resources according to an embodiment of this disclosure is shown. Figure 1 As shown, the method includes steps S1100-S1300.

[0022] S1100 receives resource increase requests from the business system.

[0023] First, it should be noted that the unified management method for ontology resources provided in this disclosure is executed by a metafile system independent of each business system. This metafile system is essentially a lightweight resource index construction and control hub, rather than the actual data carrier. That is, the physical data of various ontology resources are stored in the databases or object storage of each business system, while the metafile system is only responsible for constructing and managing the index data of these ontology resources, thus achieving a decoupled architecture of "centralized index control and distributed data storage." Through the unified index service provided by the metafile system, an agent, regardless of its business context, can quickly locate and reference any required ontology resource through a globally unique identifier and standardized path index, thereby enabling the agent to perform corresponding functions based on the retrieved ontology resources. As the core of ontology resource construction and management, the metafile system is completely decoupled from each business system, uniformly responsible for the core capabilities of ontology resource identification allocation, hierarchical organization, permission verification, version management, and lineage tracing in each business system. Each business system only needs to focus on the semantic definition and interaction logic of ontology resources within its own business scenario.

[0024] To decouple physical storage from business semantics, the metafile system explicitly categorizes resource types into two main types: physical types and business types. Physical types are relatively fixed enumeration types built into the system, used to describe the physical storage method of resources. These include sub-types such as namespaces, folders, files, data, lists, and links, covering the physical storage needs of various ontology resources. Business types, on the other hand, are pre-registered by business systems according to their own needs, used to describe the semantics and interaction methods of resources in business operations. These include sub-types such as ontology entities, ontology relationships, ontology actions, ontology functions, datasets, process configurations, knowledge base documents, and application components, supporting unlimited expansion and adapting to iterative upgrades of the ontology model. By decoupling physical types from business types, physical types act as a stable layer providing unified storage and access capabilities, while business types act as a change layer supporting on-demand expansion and flexible configuration. The two are bound together by a "set of allowed associated physical types," enabling flexible expansion of resource types.

[0025] In one possible implementation, the business system may include the following steps when registering business types: First, the business system calls the business type registration interface provided by the metafile system to submit business type registration information. This registration information includes at least the business type code, business type name, set of allowed associated physical types, and resource attribute validation mode. Specifically, the business type code uniquely identifies the business type; the business type name demonstrates the semantic understanding of the business type; the set of allowed associated physical types declares which physical types the business type can be bound to, for example, an ontology entity business type can declare that it can be associated with physical types such as lists, data, or files; and the resource attribute validation mode defines the validation rules that resource attributes under this business type must meet, which can be described using JSON Schema format.

[0026] Secondly, after receiving the business type registration information submitted by the business system, the metafile system verifies whether the business type code has been registered to ensure the uniqueness of the business type code.

[0027] Secondly, the metafile system verifies whether each physical type in the allowed associated physical type set belongs to the system's pre-defined physical type set, namely namespaces, folders, files, data, manifests, and links. If a physical type that does not belong to the pre-defined set is declared, the verification fails, and the business type registration fails.

[0028] Finally, if all the above verifications pass, the metafile system writes the business type registration information into the business type table, completing the registration of the business type.

[0029] Once the business type is registered, the business system can reference the business type when creating resources in the future. The metafile system will verify the legality of the resource creation request based on the set of allowed associated physical types and the resource attribute verification mode in the registration information.

[0030] When any business system needs to add an ontology resource, that business system, as the request initiator, sends a resource addition request to the metafile system executing the methods disclosed herein. In this way, the metafile system can receive resource addition requests from various business systems. The resource addition request includes at least the following parameters: the namespace corresponding to the resource to be added, the parent resource identifier, the physical type, the business type, the underlying data, and the identifier of the business system.

[0031] Namespaces are used to indicate the isolation domain to which a resource to be added belongs. As the first-level node in the resource hierarchy path, resources in different namespaces are isolated from each other, which facilitates the classification and management of resources in multi-tenant or multi-business line environments.

[0032] The parent resource identifier is used to indicate the mount location of the resource to be added in the hierarchical directory structure. The metafile system constructs the parent-child relationship between resources through the parent resource identifier, thereby forming a tree-like metafile system directory structure.

[0033] The physical type describes the physical hosting method of the resource to be added. It is pre-defined and stabilized by the metafile system and includes, but is not limited to, namespaces, folders, files, data, manifests, and links. The physical type determines the storage method of the resource and the data structure of the resource attributes.

[0034] Business types describe the semantics and interaction methods of the resources to be added at the business level, and are pre-registered with the meta-file system by the business system before resource creation. Business types are decoupled from physical types; the same business type can be bound to multiple physical types, and the same physical type can also be associated with multiple business types, thereby achieving scalability of business semantics and stability of physical storage.

[0035] The basic data includes the resource name, resource attributes, business extension information, and tags for the resources to be added in various business systems. The resource name is used for resource display and path construction. Resource attributes use different data structures depending on the physical type to adapt to the management needs of different physical hosting methods. For example, when the physical type is a file, resource attributes may include information such as the object storage provider, bucket name, object key, file size, and media type; when the physical type is data, resource attributes may include information such as the data engine, database name, and table name; when the physical type is a manifest, resource attributes may include the content format and manifest content; when the physical type is a link, resource attributes may include the target resource identifier and access control inheritance mode. Business extension information is used to reserve fields for business systems / modules that need to be stored in the resource management system; tags are used for custom labeling and annotation of resources by business systems / modules for retrieval and agent identification.

[0036] The business system identifier is used to uniquely identify the business system that initiates the resource addition request. It is used by the metafile system for source verification and permission judgment to ensure that only registered business systems with the corresponding permissions can perform resource addition operations.

[0037] In this way, each business system only needs to submit a standardized resource addition request to an independent metafile system. The metafile system will then uniformly complete the generation of global identifiers for resources, storage of metadata, and overall management, thereby enabling unified addressing, cross-system referencing, and global tracking of ontology resources across different business systems.

[0038] S1200 verifies the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and determines whether the verification passes. Specifically, this may include the following steps: First, based on the namespace, parent resource identifier, and business system identifier of the resource to be added, determine whether the resource addition request has the corresponding role's operation permissions. This includes the following steps: First, based on the identifier of the business system corresponding to the resource to be added, the system verifies whether the business system initiating the resource addition request has been registered in the metafile system. If the business system is not registered, the verification fails, and the metafile system rejects the resource addition request. This step ensures that only legitimately registered business systems can initiate resource operations to the metafile system, preventing unauthorized external systems from accessing the system illegally.

[0039] If the business system is already registered, the system checks whether it has access permissions to the namespace. If the business system does not have access permissions, the check fails, and the metafile system rejects the resource addition request. This step achieves resource isolation and access control between different namespaces.

[0040] Assuming the business system has access permissions to the specified namespace, the system checks if the parent resource identifier exists and if the namespace containing the parent resource matches the namespace in the resource addition request. If the parent resource identifier does not exist, the mount location specified in the request is invalid, and the check fails. If the namespace containing the parent resource does not match the namespace in the request, the request attempts to mount the resource to a parent resource across namespaces, violating the namespace isolation principle, and the check fails. These checks ensure the legality and consistency of the resource hierarchy.

[0041] If all the above checks pass, it is determined that the resource addition request has the corresponding role operation permissions, that is, the business system identity is legitimate, it has access permissions to the target namespace, and the parent resource is valid.

[0042] Second, assuming the resource addition request has the corresponding role's operation permissions, based on the physical type and business type of the resource to be added, determine whether the resource addition request has the corresponding resource type's operation permissions. This specifically includes the following steps: First, it checks if the business type has been registered. Specifically, it searches the business type table to see if a registration record for that business type exists. If not, it means the business system has not pre-registered the business type and cannot create resources based on its semantic rules. The verification fails, and the metafile system rejects the resource addition request. This step ensures that only registered, legitimate business types can be used for resource creation, preventing business systems from arbitrarily referencing undefined business types, which could lead to unrecognized and unmanageable resource semantics.

[0043] Secondly, assuming the business type is already registered, the system checks whether the business type is allowed to bind the physical type specified in the resource add request. Specifically, it retrieves the pre-declared set of allowed associated physical types for the business type from the business type table and verifies whether the business type is allowed to bind the physical type specified in the resource add request. If the physical type specified in the resource add request is not in the set of allowed associated physical types declared by the business type, it means that the binding relationship between the physical type and the business type does not comply with the constraints pre-set by the business system, the verification fails, and the metafile system rejects the resource add request. This step ensures that the binding relationship between the physical type and the business type complies with the constraints pre-set by the business system, preventing unreasonable combinations between business semantics and physical bearer methods, while ensuring that the physical layer, as a stable layer, is not affected by unreasonable bindings.

[0044] Finally, if the business type allows the binding of the physical type specified in the resource addition request, then the resource addition request is determined to have the corresponding resource type operation permissions.

[0045] Third, if it is determined that the resource addition request has the corresponding resource type operation permissions, the verification is deemed successful.

[0046] Only after both the role-based operation permission verification and the resource-type operation permission verification pass will the operation permission verification corresponding to the resource addition request be deemed successful, allowing the subsequent resource addition operation to continue. This dual-verification mechanism enables comprehensive legality verification of requests before resource creation. The first verification (role-based operation permission) ensures that the business system is registered, has namespace access permissions, and that the parent resource is valid, focusing on "who can operate and within what scope"; the second verification (resource-type operation permission) ensures that the business type is registered and that the physical type is legally bound to the business type, focusing on "what type of resource to create." These two verifications complement each other, forming a front-end security barrier that effectively prevents unauthorized requests from entering the core creation process, ensuring the compliance, consistency, and security of resource data in the metafile system, and laying a reliable foundation for subsequent global unique identifier generation and metadata storage.

[0047] S1300, if the verification passes, generate a globally unique identifier and path index data for the resource to be added. In one possible implementation, generating the globally unique identifier for the resource to be added may include the following steps: First, obtain a fixed prefix `ri` as the header component of the globally unique identifier. Second, obtain the business system identifier `service` that created the resource to be added as the middle component of the globally unique identifier. Next, generate a random identifier code `xxxxx` as the tail component of the globally unique identifier. Finally, combine the fixed prefix `ri`, the business system identifier `service`, and the random identifier code `xxxxx` in sequence to generate the globally unique identifier for the resource to be added, represented as `ri.service_xxxxx`. Through this combination method, the globally unique identifier can reflect the source information of the resource through the business system identifier `service`, and ensure uniqueness globally through the random identifier code `xxxxx`. Furthermore, this globally unique identifier remains unchanged during resource movement, renaming, version updates, and object storage key updates, thereby ensuring the stability of cross-system resource references.

[0048] In one possible implementation, generating path index data for the resource to be added may include the following steps: obtaining the namespace corresponding to the resource to be added, as the first-level path index; obtaining the parent resource identifier corresponding to the resource to be added, and recursively querying the existing path index of the parent resource corresponding to the resource to be added based on the parent resource identifier; generating the path index of the resource to be added based on the first-level path index and the existing path index of the parent resource, and setting the path index status of the path index of the resource to be added to synchronized; and using the path index of the resource to be added and the path index status as the path index data of the resource to be added. For example, assuming the namespace is ns1, the existing path index of the parent resource is / ns1 / folderA, and the resource name of the resource to be added is resourceB, then the generated path index is / ns1 / folderA / resourceB, and the path status is marked as synchronized.

[0049] The path index generation method of the aforementioned metafile system ensures the uniqueness of the path index and the accuracy of the hierarchical relationship by recursively constructing hierarchical paths with namespaces as the first-level path nodes and parent resource identifiers. This provides a unified basic data structure for hierarchical organization of resources, directory browsing, and path addressing. At the same time, the introduction of the path index status field enables the system to distinguish between synchronized paths and paths to be synchronized. This provides a status marking basis for the mechanism of only updating the parent resource identifier and asynchronously rebuilding the subtree path cache in subsequent resource movement scenarios. This avoids the large transaction and lock contention problems caused by the need to synchronously rewrite the entire subtree path when moving directories in traditional solutions, significantly reducing the performance loss of directory movement operations and balancing resource movement efficiency and hierarchical query performance.

[0050] After generating globally unique identifiers and path index data for the resources to be added, the globally unique identifiers, path indexes, namespaces, parent resource identifiers, physical types, business types, and basic data corresponding to the resources to be added will be stored as metadata in a pre-created unified core resource table for global management.

[0051] In one possible implementation, when the physical type of the resource to be added is a file, it is indicated that the resource to be added is a file resource. In this case, after passing the above-mentioned operation permission verification, the following steps will also be included: First, an upload session is created for the file resource. This upload session includes a session identifier, an expiration time, and object storage space allocated to the file resource. This object storage space is characterized by the object storage provider, the object bucket, and the object key. The object key can be generated by a combination of namespace, date, resource category, or random identifier to prevent multiple versions from overwriting the same object.

[0052] Second, based on the upload session, direct upload credentials for file resources are issued to the business system, enabling the business system to directly upload file resources to the dedicated object storage space allocated to it through the direct upload credentials, without going through the meta file system backend.

[0053] Third, the upload results of file resources are verified. If the verification is successful, a globally unique identifier and path index data are generated for the resource to be added. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

[0054] In one possible implementation, the verification of file resource upload results includes: First, receiving an upload completion request submitted by the business system, which carries an upload session identifier; second, querying the upload session record based on the upload session identifier to verify the session status, including: verifying whether the session is online, expired (i.e., whether the current time has not exceeded the expiration time of the upload session), or lost; then, after the session verification passes, calling the object storage adapter to verify whether the corresponding file object exists in the object storage based on the object storage provider, object storage bucket, and object key in the upload session record; if the file object exists, further verifying whether the actual size and media type of the file object are consistent with the expected size and media type of the file resource recorded in the resource addition request submitted by the business system. Only after all the above verifications pass will a globally unique identifier and path index data be generated for the resource to be added, and the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added will be stored as metadata of the resource to be added in a pre-created unified core resource table for global overall management, thus realizing the mounting of the file resource. If any verification step fails, the request to complete the file resource upload will be rejected, and the corresponding error message will be returned to the business system to ensure that there will be no abnormal situation where the file content is inconsistent with the metadata status.

[0055] It should also be noted that when the resource to be added is a file resource, the resource attributes in the basic data of the above resource addition request are actually empty. Only when the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in the pre-created unified core resource table, will the object storage provider, object storage bucket, object key recorded in the file resource upload session, as well as the file size and media type recorded in the above resource addition request be filled into the core resource table as resource attributes of the file resource.

[0056] It should be further noted that after the resource file is uploaded and mounted, the status of the upload session for that resource will be updated to "Completed" to indicate that the file resource corresponding to that upload session has been fully uploaded and successfully mounted. The upload session connection will be automatically closed once the status is updated to "Completed".

[0057] In one possible implementation, in addition to uploading single file resources, resource trees can also be uploaded in batches. The resource tree nodes include relative paths, node types (including at least one of directory nodes and file nodes), filenames, business types, and resource attributes. Batch uploading of the resource tree can include the following steps: After the metafile system parses the resource tree, it traverses the resource nodes sequentially. For each traversed resource node, its node type is determined. If it is a directory node, a corresponding folder resource is created. Simultaneously, for all file nodes under the current resource node, an upload session is created, and the upload session identifier and object storage direct transfer credential corresponding to each file node are returned. The business system performs batch uploads of the files corresponding to each file node based on the upload session and object storage direct transfer credential. After the batch upload is complete, the business system calls the batch completion interface to inform the metafile system that the file transfer is complete. At this point, the metafile system checks the existence of each uploaded file object and, if the object exists, mounts the uploaded file node to the directory of the folder resource created for the current resource node. If there are still directory nodes under the current resource node, the batch upload processing for those directory nodes is performed in accordance with the processing method for the current resource node. Once the traversal is complete, the batch upload of the resource tree is finished.

[0058] In this way, resource trees such as ontology resource packages, knowledge base directories, process directories, and application component directories can be imported in batches while maintaining the consistency of resource hierarchy and object storage content.

[0059] In one possible implementation, when a business system requests to download a file resource, the metafile system queries the resource metadata and attributes based on the resource identifier, and performs the Role-Based Access Control (RBAC) and Resource-Based Access Control (ACL) checks mentioned above. After successful verification, the metafile system generates a temporary download link based on the object storage provider, bucket name, and object key in the resource attributes, and returns it to the business system. The business system then downloads directly from object storage.

[0060] When a download occurs during automated execution or agent operation, the metafile system can generate a resource usage record and associate the execution process with the version of the read resource, thereby supporting subsequent lineage tracing.

[0061] In one possible implementation, for resources that have already been uploaded and mounted, when moving resources, it can be done as follows: Figure 2As shown, the process includes the following steps: The metafile system receives a resource move request submitted by the business system. First, the metafile system performs the operation permission verification described above on the resource move request. After the permission verification passes, the metafile system only updates the parent resource identifier of the moved resource in the unified core resource table, pointing it to the new parent resource. Simultaneously, the path index status of the moved resource and all its descendant resources is set to pending synchronization. All descendant resources of the moved resource are determined through recursive querying of parent-child relationships. When updating the parent resource identifier, the metafile system only modifies the parent resource identifier field in the record of the moved resource itself, without modifying any records of its descendant resources. After completing the above parent resource identifier update, the metafile system returns a move success response to the business system, enabling the foreground operation to end quickly and avoiding long lock waits due to the move operation involving a large number of descendant resources. Meanwhile, after scanning resources with a path index status of pending synchronization (DIRTY) through a background asynchronous task, the metafile system calculates the path index (vfs_path) of the new metafile system for each resource level by level according to the latest parent resource identifier. After the calculation is completed, the path index of the metafile system of the moved resources and all their descendant resources is updated in batches, and the path status is updated to synchronized, thereby improving the overall efficiency of large-scale subtree path reconstruction.

[0062] Before the background path index reconstruction is complete, if a hierarchical query request for the moved resource or its subtree is received, the metafile system will process it as follows: Figure 3 As shown, the unified core resource table is first queried based on the globally unique identifier of the queried resource to obtain the current path index status (path_state) of the resource. If the path index status is SYNCED, the metafile system directly uses the metafile system path index (vfs_path) for querying, which provides the best query performance. If the path index status is DIRTY, it means that the resource or its ancestor resources are in the process of rebuilding the path after the move. The metafile system path index may not yet reflect the latest hierarchical relationship. The metafile system chooses to restrict path queries according to business strategies to avoid returning inaccurate results, or performs a fallback query using the parent resource identifier (parent_rid) to ensure that the query function is available.

[0063] The resource movement method described above updates only the parent resource identifier in the foreground operation without synchronously rewriting the entire subtree path index. This shifts the path index reconstruction work to an asynchronous background task, avoiding the large transaction and lock contention issues caused by the need to synchronously update all descendant resource paths during directory movement in traditional solutions. This significantly reduces the impact of resource movement operations on foreground business and reduces response latency. At the same time, by introducing path index status, multiple fault-tolerant solutions are provided for read requests during asynchronous reconstruction, such as reading the old path, restricting queries, and using the parent resource identifier as a fallback query. This ensures the basic availability of the query function during path reconstruction while balancing data consistency and query accuracy, effectively improving the stability and maintainability of the system in scenarios with large-scale resource level changes.

[0064] In one possible implementation, after storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the following operations may also be included: First, receive resource update requests from business systems. These requests include the global identifier, namespace, parent resource identifier, physical type, business type, basic data, and business system identifier of the resource to be updated.

[0065] Second, the operation permissions corresponding to the resource update request are verified based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be updated, and the verification is determined to be successful. The specific verification process is described above and will not be repeated here.

[0066] Third, if the verification passes, a version snapshot is generated for the previous version of the resource to be updated. Specifically, first, the metadata of the resource to be updated is queried from the unified core resource table based on the globally unique identifier of the resource. A version snapshot is generated for the previous state of all metadata or specified fields in the metadata, and a corresponding version number is added to the snapshot. This version number is automatically incremented by the metafile system according to the number of existing versions of the resource to be updated, ensuring that the version numbers of the snapshots of the same resource are continuous and ordered. After generating the version snapshot, the metafile system persistently stores the snapshot record in a pre-created resource version table, ensuring that the snapshot data is not lost in subsequent resource updates, system restarts, and other scenarios.

[0067] Fourth, update the resources to be updated only after generating the version snapshot.

[0068] It should be noted that if the file to be updated was stored under a specified object storage provider, object bucket, and object key before the update, after the update, a new object key will be assigned to the updated file in the original specified object storage provider and object bucket for storage. That is, the new version of the file is stored in the object storage using the new object storage key, and the old version of the file is stored in the object storage using the old object key. The old object storage information is retained in the version snapshot, thereby avoiding the inability to recover historical versions due to object overwriting during the update process.

[0069] In one possible implementation, after storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the method also includes generating lineage records for each resource in the core resource table.

[0070] Static lineage relationships are used to record long-term derivation relationships between resources. For example, an ontology relationship resource depends on two ontology entity resources, a dataset resource is derived from another dataset resource, and a process configuration resource consumes several ontology function resources. When recording static lineage relationships, the metafile system generates a static lineage edge record for each static lineage relationship. This static lineage edge includes at least a namespace, a source resource identifier, a target resource identifier, and an edge type. The namespace identifier is the identifier corresponding to the virtual directory of the ontology module in the metafile system, automatically mapped by the metafile system based on business identifiers and conventions. The source resource identifier is a globally unique identifier for the dependent or consumed party, and the target resource identifier is a globally unique identifier for the dependent or producer party. The edge type identifies the specific relationship type between the source and target resources, such as "dependency," "derivation," or "consumption."

[0071] Dynamic lineage relationships are used to record a specific execution process and the input and output resources within that process. When recording dynamic lineage relationships, the metafile system first generates an execution record, which includes at least the namespace, run identifier, job name, event type, execution status, start time, and end time. The run identifier uniquely identifies an execution process, the job name identifies the job definition corresponding to this execution, the event type identifies the type of execution event (e.g., started, running, completed), and the execution status identifies the final state of this execution (e.g., success, failure). Simultaneously, the metafile system records an execution input table and an execution output table: the execution input table records the globally unique identifiers and version numbers of the input resources read during this execution, and the execution output table records the globally unique identifiers and version numbers of the output resources generated during this execution. Through this method, dynamic lineage relationships link the execution process with resource consumption and output, enabling complete tracking of resource usage history.

[0072] In one possible implementation, dynamic lineage relationships are established by creating unique constraints and indexes based on namespaces, runtime identifiers, globally unique identifiers of resources, and version numbers to prevent redundancy in lineage data caused by duplicate reporting. At the same time, the index established by runtime identifiers allows for quick querying of the complete list of input and output resources for a specific execution process. The index established by globally unique identifiers and version numbers of resources allows for quick reverse lookup of which execution processes read or generated a particular resource version, thereby achieving bidirectional traceability from resources to execution processes.

[0073] In one possible implementation, the dynamic lineage reporting interface is compatible with the OpenLineage protocol. Specifically, the metafile system maps the run, job, input dataset, output dataset, and facet entities in the OpenLineage protocol to execution records, execution inputs, execution outputs, and lineage facet information in the metafile system, respectively. Through this mapping mechanism, the metafile system can receive lineage reporting requests conforming to the OpenLineage standard format without requiring additional protocol adaptation from business systems. This reduces the integration cost with the existing data ecosystem and improves system compatibility and scalability.

[0074] The above-mentioned method of generating lineage records clearly distinguishes between static and dynamic lineages and manages them separately. This ensures that the long-term derivation relationships between resources and the input and output relationships of the execution process each perform their respective functions without interfering with each other. It supports stable queries at the resource relationship level and also adapts to the high-concurrency write requirements at the execution process level.

[0075] To clearly explain the version and lineage tracking of resources, the following will combine... Figure 4 The process will be explained again. The process specifically includes the following steps: S401, Receive resource change request / lineage reporting request. This means receiving resource update requests or lineage reporting requests submitted by the business system.

[0076] S402, parse resource identity information and collect current resource status. That is, query the current resource metadata from the unified core resource table based on the resource's globally unique identifier to obtain the resource's identity information and current status.

[0077] S403, determine if the resource status has changed. If no change has occurred, maintain the existing resource status and proceed to the next relevant steps; if a resource addition, upload completion, or update operation is detected, proceed to the version snapshot generation process.

[0078] S404 generates a resource version snapshot. This involves creating a snapshot of the changed resource; the specific snapshot generation method is described above and will not be repeated here. Simultaneously, the latest metadata after the resource change is written to or updated in the unified core resource table, while maintaining the resource's globally unique identifier. For file-type resources, when the file content changes, the updated resource version corresponds to a new object storage key, and historical version snapshots retain the original object storage key, thus supporting backtracking of file content by version.

[0079] S405, Bind to Latest Status. This involves associating the latest status of a resource after changes with its corresponding historical version snapshot, thus establishing a version tracking relationship.

[0080] S406, determine whether a long-term resource relationship exists. If a long-term dependency, derivation, or consumption relationship exists between resources, proceed to the static lineage construction process; otherwise, skip the static lineage construction.

[0081] S407, Construct static lineage relationships. This involves generating static lineage records. Specifically, the metafile system verifies whether the source resource identifier and target resource identifier exist in the unified core resource table, and generates static lineage edge records based on the namespace, source resource identifier, target resource identifier, and edge type. When the static lineage relationship contains large amounts of metadata such as field mappings, quality indicators, ontology mapping rules, or prompt word snapshots, this type of metadata is written to the lineage surface information table and associated with the corresponding static lineage edge records.

[0082] S408, determine if an actual business execution process exists. That is, determine if there is a job, process, model reasoning, or data processing execution process. If it exists, proceed to the dynamic execution pipeline generation process; if it does not exist, skip the dynamic execution pipeline generation.

[0083] S409, Generate dynamic execution log records. Specifically, the metafile system generates or updates execution records based on the namespace and run identifier. These execution records include the run identifier, job name, job namespace, event type, execution status, start time, and end time.

[0084] S410, Bind the version of the input resource for this execution. That is, record the input resources of the execution process. Specifically, the metafile system writes the globally unique identifier and version number of the resource read in this execution into the execution input table, and establishes an association between this execution and the version of the resource consumed.

[0085] S411, Bind the output resource version of this execution. This records the output resources of the execution process. Specifically, the metafile system writes the globally unique identifier and version number of the resources generated in this execution into the execution output table, establishing a relationship between this execution and the resource version it produces. Thus, an execution process is fully associated with the resource versions it consumes and produces, thereby obtaining a dynamic lineage relationship.

[0086] S412, Deduplication processing is performed to build a basic query mapping. This involves establishing deduplication constraints and query indexes for dynamic lineage records. Specifically, the metafile system establishes unique constraints based on namespaces, runtime identifiers, globally unique resource identifiers, and version numbers to avoid redundant records caused by repeated reporting; it builds an index based on runtime identifiers to query the complete input / output resource list for a given execution process; and it builds an index based on the globally unique resource identifiers and version numbers to reverse-check which execution processes read or generated a specific resource version.

[0087] S413, directly solidify searchable resource tracking relationships. This involves persistently storing the resource version information, static lineage relationships, dynamic lineage relationships, and their mapping relationships generated in the above steps, forming a directly searchable resource tracking relationship system.

[0088] S414, adapts to standard lineage protocol for external reporting. That is, when a dynamic lineage reporting request conforms to the OpenLineage protocol, the metafile system maps `run` to execution records, `job` to job information, `input dataset` to execution input records, `output dataset` to execution output records, and `facet` to lineage facet information, thereby achieving compatible access to the standard lineage protocol and reporting standardized lineage data externally.

[0089] S415, construct a two-way traceability system for the [Resource Version ← Lineage Link]. This involves creating a two-way tracking link between resource versions and lineage relationships based on the resource version table, static lineage edge table, lineage surface information table, execution record table, execution input table, and execution output table. Through this link, one can query the historical snapshots, dependency sources, derived products, and related execution processes of a specific resource version, and also reverse-engineer the input and output resource versions of a specific execution process, thus achieving two-way traceability.

[0090] This disclosure provides a unified management method for ontology resources, including: receiving resource addition requests from business systems, wherein the resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and business system identifier corresponding to the resource to be added; verifying the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and determining whether the verification passes; if the verification passes, generating a globally unique identifier and path index data for the resource to be added, and storing the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added as metadata in a pre-created unified core resource table for global overall management. In this disclosure, a globally unique identifier is generated for each resource to be added. This identifier does not depend on any specific business system and can serve as a unified identity identifier for referencing the resource across systems. Different business systems can use this identifier to point to the same resource. Simultaneously, all metadata, including the resource's globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data, is centrally stored in a pre-created unified core resource table. This unified core resource table enables global aggregation and unified management of all resource information, allowing any business system to query, locate, and associate resources based on the data in this table, thus supporting cross-system resource tracking. In summary, a globally unique identifier provides a unified reference handle, and the unified core resource table provides centralized metadata query and association capabilities; together, these two aspects enable cross-system referencing and tracking of ontology resources. Furthermore, this disclosure also establishes a connection and tracking mechanism for the lineage of upstream and downstream resources through unified management of ontology resources. For example, the upstream of the ontology is the dataset of the data platform, and the downstream is the intelligent agent and application system.

[0091] <Device Embodiment> Figure 5 A schematic block diagram of a unified management apparatus for ontology resources according to an embodiment of the present disclosure is shown. Figure 5 As shown, the device 100 includes: The permission verification module 110 is used to receive a resource addition request from a business system, wherein the resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and identifier of the business system corresponding to the resource to be added; and verifies the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and identifier of the business system corresponding to the resource to be added, and determines whether the verification passes. The core resource table management module 120 is used to generate a globally unique identifier and path index data for the resource to be added when the verification is passed, and store the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type and basic data corresponding to the resource to be added as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

[0092] Figure 6 A schematic block diagram of a unified management apparatus for ontology resources according to an embodiment of the present disclosure is shown. Figure 6 As shown, the unified management device 100 for ontology resources includes a business type registration module, a resource metadata module, a path index module, a storage credential module, a version snapshot module, a lineage management module, and a permission verification module.

[0093] The business type registration module maintains a business type table, receives business type registration information submitted by business systems, verifies the uniqueness of the business type code and whether the allowed set of associated physical types belongs to the system's preset physical type set, and writes the business type registration information into the business type table after successful verification, thus completing the business type registration and supporting the expansion and management of business types. The business type registration information includes at least the business type code, business type name, allowed set of associated physical types, and resource attribute verification mode.

[0094] The resource metadata module is used to manage the unified core resource table. It generates globally unique identifiers and path index data for resources that pass the verification. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, resource attributes, business extension information and tags of the resource are stored as resource metadata in the unified core resource table for global overall management, and provide query and update interfaces for resource metadata.

[0095] The path index module is used to construct a meta-file system path index based on the parent resource identifier. It uses namespaces as the first-level path nodes and parent-child resource relationships as the basis for hierarchical construction, maintaining the path index status and supporting hierarchical resource queries. When resources are moved, the path index module only updates the parent resource identifier of the moved resource and sets the path index status of the moved resource and all its descendant resources to "pending synchronization." A background asynchronous task scans the resources to be synchronized and rebuilds the meta-file system path index level by level based on the latest parent resource identifier, achieving asynchronous reconstruction and batch updates of the path index.

[0096] The storage credential module is used to create upload sessions for file resources and issue object storage direct transfer credentials to business systems. It manages the creation, status maintenance, and expiration verification of upload sessions. After the business system completes the direct transfer, it verifies whether the existence, size, and media type of the file object in object storage match expectations. Upon successful verification, it completes the creation and mounting of the file resource's metadata. An upload session includes at least a session identifier, expiration time, and the object storage provider, object storage bucket, and object key allocated to the file resource.

[0097] The version snapshot module is used to query the current metadata recorded in the unified core resource table based on the globally unique identifier of the resource to be updated when a resource is updated. It generates an immutable version snapshot of the state before the update and persists it to the resource version table, maintaining the resource version table and supporting version querying and rollback. The version snapshot includes at least the version number, resource attributes at the time of the snapshot, business extension information at the time of the snapshot, resource name at the time of the snapshot, and version description. The version number is automatically incremented by the metafile system according to the number of existing versions of the resource.

[0098] The lineage management module records the lineage relationships between resources and between execution processes and resources, distinguishing between static and dynamic lineages, and providing lineage query and tracing functions. Static lineages record long-term derivation relationships between resources, including static lineage edges and lineage surface information. Lineage surface information stores field mappings, data quality indicators, ontology mapping rules, and runtime prompt snapshots. Dynamic lineages record execution processes, input resources during execution, and output resources during execution. Unique constraints and indexes are established by namespace, runtime identifier, resource identifier, and version number, supporting querying resource lists by execution process and reverse lookup of execution processes by resource version.

[0099] The permission verification module performs role-based access control (RBAC) and resource-based access control (ACL) permission verification before resource operations, blocking unauthorized operations and ensuring resource security. Permission verification covers the entire process of resource creation, upload initialization, upload completion, download credential issuance, resource movement, version creation, lineage reporting, and resource deletion. Subsequent operations can only be performed after verification is successful.

[0100] The aforementioned unified management device for ontology resources decouples physical and business types through a business type registration module. This allows physical types to act as a stable layer providing unified storage and access capabilities, while business types act as a change layer supporting on-demand expansion and flexible configuration. The resource metadata module generates a globally unique identifier for each resource and centrally stores all metadata in a unified core resource table, achieving global unified management and cross-system unified addressing of ontology resources. The path index module maintains the metafile system path index based on namespaces as root nodes and parent-child relationships, and combines parent resource identifier updates with an asynchronous backend path reconstruction mechanism during resource movement, balancing directory movement efficiency and hierarchical query performance. The storage credential module issues direct transfer credentials, enabling business systems to bypass backend direct transfer object storage and integrating with upload... The consistency verification mechanism at completion overcomes backend bandwidth and connection bottlenecks and ensures the consistency of file content and metadata state. The version snapshot module automatically generates immutable version snapshots and persists them before resource updates, completely preserving the state information of resources before each change, providing reliable historical state data for model training replay, workflow execution reproduction, and ontology change auditing. The lineage management module separates static and dynamic lineages, supporting stable queries of long-term derivation relationships between resources and adapting to high-concurrency write requirements at the execution level, while also supporting compatible mapping with standard lineage protocols such as OpenLineage. The permission verification module performs unified RBAC and ACL permission control on all system calls, covering the entire operation process and ensuring the security of resource access and operations. These modules work together to solve pain points in existing ontology resource management such as type coupling, complex addressing, performance bottlenecks, version gaps, and chaotic lineages, effectively improving the efficiency, stability, and scalability of ontology resource management.

[0101] <Equipment Example> Figure 7 A schematic block diagram of a unified management device for ontology resources according to an embodiment of the present disclosure is shown. Figure 7 As shown, the unified management device 200 for ontology resources includes a processor 210 and a memory 220 for storing executable instructions of the processor 210. The processor 210 is configured to implement any of the aforementioned unified management methods for ontology resources when executing the executable instructions.

[0102] It should be noted here that the number of processors 210 can be one or more. Furthermore, the unified management device 200 for ontology resources in this embodiment may also include an input device 230 and an output device 240. The processors 210, memory 220, input device 230, and output device 240 can be connected via a bus or other means, without specific limitations here.

[0103] The memory 220, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the unified management method for ontology resources in this embodiment of the present disclosure. The processor 210 executes various functional applications and data processing of the unified management device 200 for ontology resources by running the software program or module stored in the memory 220.

[0104] Input device 230 can be used to receive input digital numbers or signals. These signals may include key signals related to user settings and function control of the device / terminal / server. Output device 240 may include a display device such as a screen.

[0105] <Storage Medium Examples> According to a fourth aspect of this disclosure, a non-volatile computer-readable storage medium is also provided, on which computer program instructions are stored, which, when executed by processor 210, implement any of the preceding ontology-oriented unified management methods.

[0106] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for unified management of ontology resources, characterized by, include: Receive a resource addition request from a business system, wherein the resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and identifier of the business system corresponding to the resource to be added; The operation permissions corresponding to the resource addition request are verified based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and it is determined whether the verification passes. If the verification passes, a globally unique identifier and path index data are generated for the resource to be added. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in a pre-created unified core resource table for global management.

2. The method of claim 1, wherein, When verifying the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be added, and determining whether the verification passes, the process includes: Based on the namespace corresponding to the resource to be added, the parent resource identifier, and the identifier of the business system, determine whether the resource addition request has the corresponding role operation permissions. If it is determined that the resource addition request has the corresponding role operation permission, then based on the physical type and the business type of the resource to be added, it is determined whether the resource addition request has the corresponding resource type operation permission. If it is determined that the resource addition request has the corresponding resource type operation permission, the verification is deemed to have passed.

3. The method of claim 2, wherein, When determining whether a request to add a resource has the corresponding resource type operation permission based on the physical type and the business type corresponding to the resource to be added, the following steps are included: Determine whether the business type has been registered; If the business type is already registered, determine whether the business type is allowed to be bound to the physical type; If it is determined that the business type allows binding to the physical type, then the resource addition request is deemed to have the corresponding resource type operation permission.

4. The method according to claim 1, characterized in that, When generating path index data for the resource to be added, the following is included: Obtain the namespace corresponding to the resource to be added, and use it as the first-level path index; Obtain the parent resource identifier corresponding to the resource to be added, and recursively query the existing path index of the parent resource corresponding to the resource to be added based on the parent resource identifier; Based on the first-level path index and the existing path index of the parent resource, the path index of the resource to be added is generated, and the path index status of the path index of the resource to be added is set to synchronized. The path index of the resource to be added and the path index status are used as the path index data of the resource to be added.

5. The method according to claim 1, characterized in that, The resource to be added is a file resource. If the verification passes, the method further includes: An upload session is created for the file resource, wherein the upload session includes a session flag, an expiration time, and object storage space allocated for the file resource; Based on the upload session, a direct upload credential for the file resource is issued to the business system, so that the business system can directly upload the file resource to the object storage space using the direct upload credential; The upload result of the file resource is verified. If the verification is successful, a globally unique identifier and path index data are generated for the resource to be added. The globally unique identifier, path index, namespace, parent resource identifier, physical type, business type, and basic data corresponding to the resource to be added are stored as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

6. The method according to claim 1, characterized in that, After storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the process also includes: Receive a resource update request from a business system, wherein the resource update request includes a globally unique identifier, namespace, parent resource identifier, physical type, business type, basic data, and the identifier of the business system corresponding to the resource to be updated; The operation permissions corresponding to the resource update request are verified based on the namespace, parent resource identifier, physical type, business type, and business system identifier of the resource to be updated, and it is determined whether the verification passes. If the verification passes, a version snapshot is generated for the previous version of the resource to be updated; After generating the version snapshot, the resource to be updated is then updated.

7. The method according to claim 1, characterized in that, After storing the metadata of the resources to be added in a pre-created unified core resource table for global management, the process also includes: Generate lineage records for each resource in the core resource table, wherein the lineage records include static lineage relationships for recording long-term derivation relationships between the resources and dynamic lineage relationships for recording the execution process, the input resources and output resources in the execution process.

8. A unified management device for ontology resources, characterized in that, include: The permission verification module is used to receive resource addition requests from the business system. The resource addition request includes the namespace, parent resource identifier, physical type, business type, basic data, and identifier of the business system corresponding to the resource to be added. The module verifies the operation permissions corresponding to the resource addition request based on the namespace, parent resource identifier, physical type, business type, and identifier of the business system corresponding to the resource to be added, and determines whether the verification passes. The core resource table management module is used to generate a globally unique identifier and path index data for the resource to be added when the verification is passed, and to store the globally unique identifier, path index, namespace, parent resource identifier, physical type, business type and basic data corresponding to the resource to be added as metadata of the resource to be added in a pre-created unified core resource table for global overall management.

9. A unified management device for ontology resources, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1 to 7 when executing the executable instructions.

10. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images