Industrial data organization and verification method and device fusing closed world assumption

CN123011869APending Publication Date: 2026-10-30德中(天津)技术发展股份有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611105009.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-23
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

然而,OWL原生遵循开世界假设(Open World Assumption,OWA),其语义将未显式声明的事实视为未知而非缺失或无效,这一逻辑与工业领域天然要求的闭世界判定(即未记录即视为不存在)之间存在着根本性的语义鸿沟

Benefits of technology

[0018]本公开实施例的第五方面,提供了一种工业数据治理系统,包括处理器、存储器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行程序时实现如第一方面任一实现方式提供的方法;系统还包括数据仓储模块,用于存储按照命名图组织的RDF数据,并内置SHACL验证引擎,以根据多层级SHACL约束规则集对数据进行完整性与合规性检查。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123011869A_ABST
    Figure CN123011869A_ABST
Patent Text Reader

Abstract

The disclosure discloses a closed world assumption industrial data organization and verification method, device, medium and system. The method comprises the following steps: constructing a named graph hierarchical structure with an import relationship; setting that each IRI node is uniquely attributed to one named graph and only the attribution graph defines the triples with the IRI node as the subject, and the rest of the named graphs can only be referenced; predefining a multilevel SHACL constraint rule set containing data integrity constraints and semantic consistency constraints; and performing integrity and compliance verification on the data organized according to the rules. Through the combination of the closed world named graph boundary and the IRI attribution mandatory rule and the multilevel SHACL constraint verification, the scheme can check the integrity and compliance in the data writing transaction, automatically identify the violations such as missing and unauthorized definition, and prevent the violations, overcome the defect that the OWA cannot judge the data missing, and realize the clear definition of the industrial data boundary and the high-credibility integrity guarantee.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of industrial data processing, and in particular to a method, apparatus, medium, and system for organizing and verifying industrial data that incorporates the closed-world hypothesis. Background Technology

[0002] In the technologies related to building industrial data governance environments based on Resource Description Framework (RDF) and Web Ontology Language (OWL), in order to ensure the credibility and exchangeability of data in product design, process collaboration and full life cycle management, it is necessary to provide deterministic boundary definition and automated integrity verification mechanisms for industrial data to ensure that the data written to the warehouse always meets the preset industrial standards and business rules.

[0003] To achieve the above goals, related technologies often employ OWL-based ontology models to semantically represent industrial data, and combine this with the W3C Shapes Constraint Language (SHACL) to perform basic structure and format validation on the data. However, OWL natively follows the Open World Assumption (OWA), which treats undeclared facts as unknown rather than missing or invalid. This logic has a fundamental semantic gap with the closed-world judgment (i.e., if not recorded, it is considered non-existent) inherently required in the industrial field. As a result, when data is written to a distributed semantic warehouse, the relevant validation mechanisms cannot effectively determine fatal data defects in industry, such as missing parameters, omitted assembly relationships, or missing key attribute values, resulting in blurred data boundaries. At the same time, conventional SHACL applications mostly focus on single-dimensional constraints on RDF triple formats, data types, and simple cardinality, lacking the ability to integrate and validate the legality of cross-named graph relationships, deep business semantic consistency, and multi-level industry-specific rules. Furthermore, if the traditional process prioritizes reasoning in data processing, unverified invalid data may participate in the OWL reasoning process, making it difficult to guarantee the credibility of derived knowledge.

[0004] The aforementioned situation has ultimately led to technical problems in industrial data environments, such as incomplete integrity verification coverage, heavy reliance on manual review during data governance, and frequent cross-system semantic conflicts. Especially in industrial scenarios involving multi-departmental collaboration and the integration of heterogeneous data from multiple sources, establishing a deterministic data processing mechanism that can both rigorously determine data missingness and unauthorized access definitions, and achieve automated verification across all dimensions from the underlying structure to the upper-level business logic, has become a critical issue that urgently needs to be addressed. Summary of the Invention

[0005] To address the aforementioned technical issues, this paper provides an RDF / OWL industrial data organization and verification method incorporating the closed-world hypothesis, an industrial data organization and verification device incorporating the closed-world hypothesis, an RDF / OWL industrial data organization and verification device incorporating the closed-world hypothesis, a computer-readable storage medium, and an industrial data governance system.

[0006] A first aspect of this disclosure provides an RDF / OWL industrial data organization and verification method that incorporates the closed-world assumption, comprising: constructing a named layer-level structure with import relationships; setting rules such that each IRI node uniquely belongs to a named graph, and only the belonging graph defines triples with the IRI node as the subject, while other named graphs can only reference the IRI node; predefining a multi-level SHACL constraint rule set, the rule set including at least data integrity constraints and semantic consistency constraints; performing verification operations on the data constructed based on the named layer-level structure and the belonging rules, and performing integrity and compliance checks according to the rule set.

[0007] In one embodiment, constructing a named layer hierarchical structure with import relationships includes: defining direct import and indirect inheritance relationships between named graphs, such that a named graph inherits the definition rights and semantics of all IRI nodes in the imported named graph by importing another named graph; the importing named graph has only read-only permissions for the IRI nodes of the imported named graph and does not have the permission to modify the definition of the imported named graph, wherein the import relationship supports multi-level inheritance.

[0008] In one embodiment, the rule setting further includes: for cross-name graph associations, explicitly declaring the legal boundaries of the associations by defining attribute chains or using SHACL attribute paths; the verification engine automatically checks whether the target IRI referenced across graphs actually exists within the domain of the target named graph.

[0009] In one embodiment, the multi-level SHACL constraint rule set includes integrity constraints for data structures, consistency constraints for business semantics, and validity constraints for cross-graph associations; integrity constraints include at least restrictions on the number of class instances, cardinality constraints on attribute values, and data type constraints; semantic consistency constraints include at least functional dependencies and mutual exclusion relationships between attributes; and cross-graph association validity constraints are used to verify whether IRI references across named graphs actually exist within the domain of the target named graph.

[0010] In one embodiment, the verification operation is performed synchronously during the transaction execution phase of the BBolt database in the SST Repository; when a newly added or modified triple violates any constraint rule, the transaction is rolled back and specific violation information is returned; the violation information includes the violating triple and the identifier of the violated constraint rule, so as to support the resubmission of the transaction for verification after the violation data is corrected.

[0011] In one embodiment, after performing a verification operation on the data constructed according to the named layer hierarchical structure and attribution rules and the verification is successful, the method further includes: enabling the OWL inference engine on the verified subset of data according to the configuration or calling instructions, and performing knowledge inference based on the explicitly declared ontology axioms; storing the derived triples generated by the OWL inference engine in a named graph different from the explicitly asserted triples or in a graph region with different labels to achieve physical separation; and automatically triggering a round of SHACL lightweight verification after the inference is completed.

[0012] In one embodiment, the SHACL constraint rule set adopts a modular design. The SHACL verification engine that performs the verification operation supports hot updates of the rule set. Hot updates can add or modify industry-customized constraints without restarting the system. Hot updates take effect in real time after the update and do not affect ongoing transactions.

[0013] In one embodiment, the method further includes: serializing the verified and / or inferred industrial data model using RDF / Turtle format, or outputting it via an API interface provided by the SST core library.

[0014] In one embodiment, rules are set such that data not explicitly declared in any named graph is judged as missing or invalid.

[0015] A second aspect of this disclosure provides an industrial data organization and verification apparatus that incorporates the closed-world assumption, comprising: a naming graph construction module for constructing a naming layer hierarchical structure with import relationships; a rule setting module for setting rules, including ensuring that each IRI node uniquely belongs to a naming graph, and that only the naming graph to which it belongs defines triples with the IRI node as the subject, while other naming graphs can only reference the IRI node; a constraint rule set predefinition module for predefining a multi-level SHACL constraint rule set, wherein the rule set includes at least data integrity constraints and semantic consistency constraints; and a verification module for performing verification operations on the data constructed according to the naming layer hierarchical structure and attribution rules, and performing integrity and compliance checks according to the rule set.

[0016] A third aspect of this disclosure provides an RDF / OWL industrial data organization and verification apparatus that incorporates the closed-world assumption, comprising: a naming graph construction module for constructing a naming layer-level structure with import relationships; a rule setting module for setting rules so that each IRI node uniquely belongs to a naming graph, and only the belonging graph defines triples with the IRI node as the subject, while other naming graphs can only reference them; a constraint rule set predefinition module for predefining a multi-level SHACL constraint rule set, wherein the rule set includes at least data integrity constraints and semantic consistency constraints; and a verification module for performing verification operations on the data organized according to the rules, and performing integrity and compliance checks according to the rule set.

[0017] A fourth aspect of this disclosure provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method provided in any implementation of the first aspect.

[0018] A fifth aspect of this disclosure provides an industrial data governance system, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method provided in any implementation of the first aspect. The system also includes a data warehouse module for storing RDF data organized according to a named graph, and has a built-in SHACL verification engine to perform integrity and compliance checks on the data according to a multi-level SHACL constraint rule set.

[0019] According to the RDF / OWL industrial data organization and verification method based on the closed-world assumption of this disclosure, the problem in RDF / OWL-based industrial data management is that the native open-world assumption of OWL treats undeclared facts as unknown, leading to the inability to strictly verify data integrity and the ambiguity of data boundaries. This method constructs a named layer-level structure with import relationships and sets rules so that each IRI node uniquely belongs to a named graph and is defined only by the belonging graph with the IRI node as the subject of the triplet; other named graphs can only reference it. Simultaneously, data not explicitly declared in any named graph is judged as missing or invalid. This forces the closed-world assumption into data organization, giving industrial data clear boundaries and ownership definitions. Data not explicitly declared is considered missing or invalid, making previously impossible integrity verification possible. Combined with a predefined multi-level SHACL constraint rule set, integrity and compliance verification operations are performed on data constructed according to the above structure and rules. This automatically identifies problems such as missing data, structural violations, and semantic inconsistencies, effectively ensuring the integrity and consistency of industrial data. Attached Figure Description

[0020] Figure 1This is a schematic diagram of a typical implementation environment for industrial data organization and verification methods that incorporate the closed-world hypothesis.

[0021] Figure 2 It is a flowchart of an industrial data organization and verification method that incorporates the closed-world hypothesis. Detailed Implementation

[0022] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0023] In the field of industrial data processing combined with the Semantic Web, to achieve unified organization and computer-processable expression of product structure, process parameters, assembly relationships, and business semantics, a common approach is to describe instance data based on RDF, define ontology semantics based on OWL, and validate the data using constraint rules. Specifically, this approach typically organizes industrial objects, attributes, and relationships using RDF triples, models class hierarchies, attribute semantics, and relationships between objects using OWL, and stores data from different business processes in a repository. Its basic working principle is to first represent equipment, parts, processes, and testing information as IRI nodes and their corresponding triples, then perform association and reasoning based on ontology semantics, and, when necessary, check data format, attribute values, and local relationships using SHACL or custom rules. This approach is widely adopted primarily because it effectively supports the semantic representation of heterogeneous industrial data, cross-system sharing, and knowledge reuse.

[0024] However, this solution performs poorly when applied to scenarios requiring strict integrity checks, boundary controls, and pre-inbound compliance verification of industrial data. A fundamental contradiction lies in the fact that, to maintain the OWL semantic system's ability to openly express unknown facts, its inherent design treats undeclared facts as unknown rather than invalid. This compromises the ability to verify certainty, completeness, and responsibility boundaries in industrial data scenarios, leading to problems such as the inability to directly identify missing data, difficulty in determining cross-graph definition conflicts, and difficulty in verifying the authenticity of referenced targets. Specifically, in product assembly modeling or process parameter management scenarios, when a component lacks necessary attributes, a process object references an IRI not actually defined in the target graph, or the same IRI is repeatedly defined in different graphs, the system may still retain this data and continue to participate in association or inference. This results in verification results that cannot accurately reflect missing items, out-of-bounds definitions, or invalid references, manifesting as distorted integrity checks, blurred semantic boundaries, and the mixing of non-compliant data into subsequent inference results.

[0025] Through in-depth analysis, the inventors discovered that the root cause of the aforementioned contradictions lies in the fact that the RDF / OWL data organization methods in related technologies primarily revolve around open semantic modeling, lacking data boundary mechanisms and definition right constraint mechanisms corresponding to the closed-world constraints of industrial data. Firstly, IRI nodes lack unique attribution rules in multi-graph environments, allowing the same node to be supplemented, rewritten, or repeatedly defined in different data graphs, resulting in unclear definition sources for subject triples. Secondly, cross-graph associations typically only focus on semantic connectability, failing to establish a unified explicit verification path for reference boundaries and target existence, making it uncertain whether reference relationships fall within a valid domain, even if they can be expressed. Thirdly, conventional constraint rules primarily check local structures or formats, failing to form a hierarchical rule system covering structural integrity, semantic consistency, and the validity of cross-graph relationships, thus making it difficult to make linked judgments on missing, conflicting, and out-of-bounds references in industrial data. Fourth, in the process of data writing, modification and reasoning, if there is a lack of verification and isolation mechanisms synchronized with transactions, non-compliant triples may enter the warehouse first and then participate in subsequent processing, further blurring the boundary between the original business data and the derived results.

[0026] To overcome the aforementioned contradictions, this disclosure proposes a different technical approach. The core concept of this disclosure lies in improving the organization and verification process of industrial data by introducing a named layer-level structure with import relationships, unique attribution and definition rights isolation rules for IRI nodes, combined with a closed-world determination method that classifies undeclared data as missing or invalid, and a multi-level SHACL constraint rule set. This improves upon these features while preserving the semantic expression and graph reuse capabilities of RDF / OWL, allowing for explicit constraints on data boundaries, definition sources, and cross-graph reference relationships, and ensuring that integrity and compliance checks are applied to actual data objects. In other words, it provides an RDF / OWL industrial data organization and verification technique that integrates the closed-world assumption, addressing the challenges of rigorous integrity verification, difficulty in confirming the legality of cross-graph references, and unclear data definition boundaries within an open semantic framework. This achieves the technical effect of improved industrial data integrity, consistency, and verifiability.

[0027] To concretize the inventive concept, first combine Figure 1 Describe a typical implementation environment. Figure 1 This is a schematic diagram of a typical implementation environment for industrial data organization and verification methods that incorporate the closed-world hypothesis.

[0028] The system comprises a data access layer, a data organization layer, a data storage layer, a verification and inference layer, and a data output layer. These layers are sequentially connected through internal interfaces, collectively carrying out the complete process of industrial data from acquisition, organization, verification, inference to external output.

[0029] The data access layer connects to external industrial information systems. Its input end interfaces with industrial software such as CAD, PDM, ERP, and MES, as well as data sources such as field sensors and engineering documents. It is used to receive multi-source heterogeneous raw industrial data and standardize it into triples that conform to RDF / OWL syntax for subsequent processing.

[0030] The data organization layer, located after the data access layer, includes a named graph construction unit and a rule setting unit. The named graph construction unit organizes several named graphs according to a preset hierarchical relationship, forming a named graph hierarchical structure with import and inheritance relationships. The rule setting unit maintains the attribution information of IRI nodes in each named graph and describes cross-named graph reference relationships. The output of the data organization layer is an RDF dataset organized according to the named graph, which is then passed down to the data warehouse layer.

[0031] The data repository layer is handled by SST Repository, which uses a BBOlt key-value database for persistent storage and employs the Bleve search engine to build indexes. The data repository layer stores RDF data in named graph units, exposing transaction write interfaces to the upper data organization layer and data read and event listening interfaces to the lower validation and inference layer. When an add, modify, or delete operation occurs, it sends corresponding event notifications to the validation and inference layer.

[0032] The validation and inference layer includes a constraint rule set storage unit, a SHACL validation engine, and an OWL inference engine. The constraint rule set storage unit stores predefined multi-level SHACL constraint rule sets and provides rule loading and updating interfaces to the SHACL validation engine. The SHACL validation engine listens for transaction events in the data warehouse layer, performs integrity and compliance checks on the written or modified data, and feeds back the check results to the data warehouse layer to determine whether the transaction should be committed. The OWL inference engine is invoked after the SHACL validation engine passes validation, reads the validated subset of data for inference, and writes the inference results back to the designated named graph area of ​​the data warehouse layer via an internal channel.

[0033] The data output layer is connected to the data storage layer. Through the RDF / Turtle serialization module and the API interface provided by the SST core library, the processed industrial data model is output to external industrial software for consumption.

[0034] In the data and signal flow direction, raw industrial data enters through the data access layer, is organized at the naming graph and IRI levels by the data organization layer, and then written to the data warehouse layer. During the transaction commit process, the data warehouse layer triggers the processing flow of the verification and inference layers. The results of verification and inference, in turn, affect the commit or rollback of the transaction, ultimately forming a high-quality data view that can be read by the data output layer. The interfaces between the above layers are all implemented within the same operating environment, which can be deployed on a single server or in a distributed cluster, providing a unified operating platform for the specific processing flow described in the subsequent embodiments.

[0035] In this disclosure, "named graph" refers to any data container or data structure capable of logically partitioning and assigning unique identifiers to an RDF dataset. Examples include, but are not limited to: graph objects implemented based on the W3C Named Graph standard, storage partitions in a database divided by graph namespaces, or combinations thereof.

[0036] The "closed-world hypothesis" broadly refers to the semantic convention in data management that treats information not explicitly declared as false or invalid. Examples include, but are not limited to: setting rules to determine that any triple not explicitly declared in any named graph is missing or invalid, or enabling closed-world completeness checks for specified partitions.

[0037] "IRI attribution rules" broadly refer to a set of rules used to determine the attribution of the definition rights of each IRI node in industrial data. For example, these rules may include, but are not limited to: stipulating that each IRI node uniquely belongs to a designated named graph and that only that attribution graph defines triples with the IRI node as the subject; that other named graphs can only reference the IRI node as an object or subject and cannot modify its core definition; or declaring cross-graph reference boundaries through ontology association attributes.

[0038] "SHACL constraint rule set" refers to a set of constraints defined by the W3C Shape Constraint Language used to verify whether an RDF data graph conforms to a preset shape. For example, it may include, but is not limited to: integrity constraints, semantic consistency constraints, and cross-graph association validity constraints containing sh:NodeShape and sh:PropertyShape, or custom constraint rules that incorporate extensions of industry standards such as IEC 81346 and ISO 15926.

[0039] "Integrity constraints" broadly refer to constraints that restrict the format, structure, and cardinality characteristics of data. For example, they may include, but are not limited to: restrictions on the number of class instances, cardinality constraints on attribute values ​​(such as sh:minCount and sh:maxCount), or data type constraints (such as xsd:string and xsd:integer). In a preferred implementation of this disclosure, the cardinality constraint can be so strict that a violation is determined when the number of occurrences is zero.

[0040] "Semantic consistency constraints" broadly refer to constraints that validate the logical relationships between attributes based on business semantics. For example, they may include, but are not limited to: functional dependencies between attributes (the value of one attribute uniquely determines the value of another attribute), mutual exclusion relationships (two attributes cannot exist simultaneously), or complex conditional constraints based on business rules.

[0041] "Cross-graph association validity constraints" broadly refer to constraints used to verify whether a target referenced across a named graph actually exists. Examples include, but are not limited to: explicitly declaring the legal boundaries of associations through SHACL attribute paths, and having the validation engine automatically check whether the target IRI referenced across the graph exists within the domain of the target named graph.

[0042] "Import relationship" refers to a unidirectional association between named graphs used to achieve data reuse and hierarchy. For example, it may include, but is not limited to: direct import relationship, indirect inheritance relationship, or a combination of both; one named graph inherits the definition rights and semantics of all IRI nodes in the imported named graph by importing another named graph, and the importing named graph has only read-only permissions for the IRI nodes of the imported named graph.

[0043] "SST Repository" broadly refers to a repository system that supports distributed storage and retrieval of industrial semantic data. Examples include, but are not limited to: data repositories using BBolt as the key-value persistence engine and Bleve as the full-text search indexing engine, or semantic repositories with built-in SHACL validation and OWL inference engines.

[0044] "Hot update" broadly refers to the ability to dynamically load or change configurations or rules without halting system operation. Examples include, but are not limited to: the SHACL validation engine supporting the addition or modification of modular rule sets, with updates taking effect in real time and not impacting ongoing transactions. In a typical application disclosed herein, rule changes can take effect within seconds.

[0045] Figure 2 This is a flowchart of an industrial data organization and verification method that incorporates the closed-world assumption. This method can be executed by the industrial data governance system described in the aforementioned implementation environment, specifically by processing units deployed at various layers of the system in collaboration. The method generally includes steps S101 to S104.

[0046] Step S101 includes: constructing a named layer-level structure with import relationships.

[0047] Step S102 includes: setting each IRI node to be uniquely assigned to a naming graph, and defining triples with the IRI node as the subject only by that naming graph, while other naming graphs can only reference the rules of the IRI node.

[0048] Step S103 includes: predefining a multi-level SHACL constraint rule set, wherein the rule set includes at least data integrity constraints and semantic consistency constraints.

[0049] Step S104 includes: performing a verification operation on the data constructed based on the naming layer-level structure and the attribution rules, and performing integrity and compliance checks according to the rule set.

[0050] The following section will describe each of the technical features mentioned above in detail.

[0051] Step S101: Construct a named graph hierarchical structure with import relationships. The named graph can be understood as a semantic partitioning unit in an RDF dataset used to identify and manage a set of triples as a whole. It can be named using globally unique identifiers, such as assigning a unique graph identifier to each named graph using a UUID-URN string. The hierarchical structure can be a tree-like or directed acyclic graph-like organization formed by establishing parent-child relationships between named graphs. The named graph at the upper level is called the imported named graph, and the named graph at the lower level is called the importing named graph. The importing named graph and the imported named graph are associated through a pre-declared import relationship. The import relationship can be implemented by registering a reference record from the importing named graph to the imported named graph in the named graph construction unit of the data organization layer, or by explicitly declaring it in the graph metadata using ontology import statements such as owl:imports.

[0052] As a specific implementation, the named layer-level structure can be divided into several basic graphs according to the purpose of industrial data. For example, it may include: a basic ontology graph (G0) for storing core ontology, industrial standard vocabulary, measurement units, and basic component ontology; a domain modeling graph (G1) for storing product topology, assembly structure, and component instances; a process parameter graph (G2) for storing process specifications, testing indicators, and sensor dynamic parameters; and a reasoning result graph (G3) for isolating and storing derived triples generated by OWL reasoning. In a typical organization, G1 imports from G0 to reuse the classes and attributes defined therein, G2 references instance nodes in G1 across graphs to supplement process-related data, and G3 independently carries reasoning-derived knowledge, separate from G0 to G2. This organization method enables clear semantic partitioning of industrial data in physical storage, facilitating hierarchical governance.

[0053] The construction methods for the named layer hierarchical structure can include, but are not limited to: division by data source (e.g., forming independent import named diagrams for different industrial software systems), division by business domain (e.g., forming independent import named diagrams for electrical wiring harnesses, mechanical assembly, chemical processes, etc.), division by data maturity (e.g., forming independent import named diagrams for design, review, and release), or division by time dimension (e.g., forming independent import named diagrams by shift or version). These solutions can all achieve the function of segmenting continuous industrial data into semantic units with clear boundaries. In this disclosure, the term "hierarchical structure" refers to an organizational form where there is a clear order of reference or inheritance among the named diagrams. It can be a strict tree hierarchy or a multiple inheritance structure that allows one import named diagram to import multiple imported named diagrams simultaneously.

[0054] Step S102: Each IRI node is uniquely assigned to a named graph, and only that graph defines triples with that IRI node as the subject. Other named graphs can only reference rules for that IRI node. An IRI node is an entity node in RDF data marked with an Internationalized Resource Identifier (IRI). It can represent a class, an attribute, a specific part instance, an assembly, or a process parameter in an industrial scenario. The attribution relationship can be maintained by the rule setting unit of the data organization layer. Specifically, it can be recorded by establishing an attribution registration table within the named graph, where each row registers an IRI node and the identifier of its associated named graph; alternatively, it can be implemented by declaring through SHACL shapes that the IRI node must appear within a specified sh:graph range.

[0055] In this disclosure, the term "attribution" refers to the idea that a core defining triple of an IRI node can only exist in a single named graph. Specifically, it can mean that for an IRI node X, triples with X as the subject are only allowed in its own named graph G_X (e.g., X rdf:type Y, X hasProperty Z, etc.). It can also encompass the fact that for an IRI node X, when it appears in any other named graph, it can only be used as the object of other triples or as a reference object for cross-graph association attributes. Implementations of definition right isolation can include: configuring a shape in the SHACL verification engine such that when a triple in a named graph G_i has an IRI node X belonging to G_j (where i≠j) as the subject, it is directly determined to violate the attribution rule; or installing an interceptor on the BBolt transaction write interface of the data warehouse layer, querying the attribution registry table for each newly written triple based on its subject IRI, and rejecting the write of the triple if the subject's attribution graph is inconsistent with the target named graph being written to.

[0056] Specific means to achieve the aforementioned closed-world determination function can include: at the hardware or storage level, the BBOlt key-value database, with its named graph as the key and triple sets as the value, can be used to enable the system to determine whether a fact is explicitly stored within milliseconds; at the software or logic level, attributes not explicitly declared can be considered violations by executing the sh:closed constraint or the equivalent sh:minCount 1 constraint in the SHACL verification engine. In some embodiments, data not explicitly declared in any named graph is judged as missing or invalid, which can be specifically stated as follows: for any triple pattern expected to appear in the data model, if no matching triple is found after traversing all named graphs in the data warehouse layer, the data corresponding to that pattern is judged as missing and marked as a violation in the verification result. Such determination enables industrial data to achieve the same determinism as traditional relational databases at the semantic level; any omitted parameters, assembly relationships, or attributes will not be interpreted as unknown, but will be explicitly identified as missing.

[0057] It should be noted that the implementation of the aforementioned attribution rules provides the necessary semantic premise for the validity of subsequent SHACL constraints. The synergy between the two ensures that any IRI subject triplet not explicitly declared in the correct naming graph, or expected data not appearing in any naming graph, can be automatically identified as non-compliant or missing during the verification phase. This jointly solves the technical problems of the inability to rigorously verify the integrity of industrial data and the ambiguity of data boundaries under the OWL native open-world assumption.

[0058] Step S103: Predefine a multi-level SHACL constraint rule set, which includes at least data integrity constraints and semantic consistency constraints. The SHACL constraint rule set can be understood as a set of shapes described by the W3C SHACL standard, where each shape corresponds to a specific verification specification. The multi-level structure can refer to the rule set being divided vertically into several progressive levels according to the verification dimension. For example, it may include: a bottom-level integrity constraint layer for structural aspects such as RDF triple format compliance, IRI naming conventions, XSD data types, and attribute cardinality (sh:minCount / sh:maxCount); a middle-level consistency constraint layer for business semantic aspects such as attribute domain and value domain matching, class inheritance consistency, attribute mutual exclusion, or functional dependency; and a top-level association validity constraint layer for business association aspects such as cross-name graph relationships, assembly relationships, electrical connection relationships, and process sequence relationships.

[0059] As a specific implementation, the SHACL constraint rule set can be stored in the constraint rule set storage unit of the verification and inference layer in Turtle format, which provides a loading and updating interface to the SHACL verification engine. For example, a shape for a part class can be defined, requiring its sso:id attribute to have sh:datatype as xsd:string, sh:minCount as 1, and sh:maxCount as 1, to force each part instance to have a unique string identifier; alternatively, a shape for an assembly instance can be defined, requiring it to be associated with an sso:Part type object through lci:isDefinedBy, to force the assembly instance to be traceable to the corresponding part body.

[0060] Step S104: Perform a verification operation on the data constructed based on the naming layer hierarchical structure and the attribution rules, and perform integrity and compliance checks according to the rule set. The verification operation can be executed by the SHACL verification engine in the verification and inference layer, which can be triggered by listening to transaction events in the data warehouse layer or initiated proactively through external calls. After being triggered, the SHACL verification engine loads the currently effective rule set from the constraint rule set storage unit, performs matching and judgment on the target data set sequentially according to the three levels of structure, semantics, and association, and summarizes and outputs the specific information of each rule violation (e.g., the position of the violating triplet, the violated shape identifier, and optional correction suggestions) as a verification report. The verification report can be fed back to the data warehouse layer through an internal channel to determine whether the current transaction should be committed or rolled back.

[0061] In some embodiments, the integrity and compliance checks can be performed in a progressive manner, i.e., first the structural integrity constraint layer is checked, and only after all layers pass is the semantic consistency constraint layer checked, and finally the cross-graph association validity constraint layer is checked. This execution order can avoid generating a large number of false positives for semantic violations when the structure is non-compliant. Optionally, a parallel execution approach can also be used, applying all three layers of checks to the target data simultaneously, and finally summarizing the violation information. Both execution methods can achieve a full-dimensional check of data integrity and compliance.

[0062] To further optimize the reusability of the named layer hierarchical structure and the organizational efficiency of the data model in the above embodiments, this disclosure also provides the following preferred solutions. As mentioned above, the import relationship between named graphs can be implemented in various ways. In a preferred embodiment, the import relationship in the named layer hierarchical structure is specifically limited to two types: direct import and indirect inheritance. Direct import means that the importing named graph directly obtains the definition rights and semantics of all IRI nodes from its imported named graph through explicit declaration. Indirect inheritance means that the importing named graph at a deeper level indirectly inherits the definition from the higher-level imported named graph through its directly imported graph. This limitation aims to enable the data model to be organized in a hierarchical and reusable manner, so that the same basic definition does not need to be described repeatedly in multiple importing named graphs.

[0063] In this preferred embodiment, the importing named graph has only read-only access to IRI nodes imported from the imported named graph. That is, the importing named graph can reference IRI nodes already defined in the imported named graph as the subject or object of its newly added triples in read-only mode, but it is not allowed to add or modify type declarations, basic attributes, or standard parameters already made by the imported named graph for that IRI node. This design ensures that the definition rights of IRI nodes are strictly concentrated in the original named graph to which they belong, avoiding conflicting definitions of the same node by multiple importing named graphs. Its advantage is that any modification to the basic definition must be executed back to the imported named graph, thus forming a clear boundary of responsibility. Those skilled in the art will understand that alternative structures achieving the same purpose may also include: binding an explicit definition right tag to each IRI node, and having the data warehouse layer verify the consistency of this tag with the current target named graph during the write phase; or using a SHACL sh:closed constraint to limit the set of attributes allowed in the importing named graph, thereby indirectly protecting the definition of the imported named graph.

[0064] Specifically, the import relationship supports multi-level inheritance, meaning it can form a multi-level inheritance chain of main naming graph — first-level import naming graph — second-level import naming graph — … — n-level import naming graph, where n can be any integer between 2 and 10. In actual deployment, the appropriate number of layers can be selected based on the complexity of the industrial data. By adopting the above specific constraints, this preferred solution can maintain the uniqueness of definitions while allowing the automatic reuse of upper-level general definitions in multiple lower-level business scenarios. This further helps to solve the problem that basic definitions are easily contaminated or repeatedly defined when collaborating on modeling across multiple domains and departments, thereby synergistically strengthening the overall solution's technical effectiveness in managing the boundaries of industrial data.

[0065] To address the specific sub-problem of ensuring the legality and traceability of cross-named graph references after setting IRI attribution rules, this disclosure also provides the following preferred solution. In this preferred solution, in addition to the attribution rules described in step S202, the rule setting further includes: for cross-named graph associations (e.g., associations from process parameter nodes in importing named graph G2 to part instance nodes in G1), explicitly declaring the legal boundaries of the association by defining a property chain or using SHACL attribute paths (sh:path); and having the SHACL verification engine automatically check whether the target IRI of the cross-graph reference actually exists within the domain of the target named graph. This constraint aims to prevent dangling references pointing to non-existent IRIs.

[0066] This design ensures that all cross-graph references are semantically controlled. The principle is that attribute chains or sh:paths can precisely describe the starting type, intermediate path predicates, and ending type of a reference path within a SHACL shape. The validation engine can then traverse the domain of the target named graph along the path during the validation phase, reporting a violation if the target IRI does not exist or the type does not match. Its advantage lies in the fact that the boundaries of cross-graph associations no longer rely on developers' voluntary compliance but are enforced by rules. Those skilled in the art will understand that alternative structures achieving the same purpose could include: introducing dedicated encapsulation predicates (e.g., lci:referTo, lci:isDefinedBy) for cross-graph reference attributes and defining strict sh:class constraints on these predicates; or maintaining an IRI existence index for each named graph at the data warehouse layer, with cross-graph references querying the target index on the fly during write operations to determine validity.

[0067] By adopting the above specific constraints, this preferred solution can immediately detect dangling references pointing to invalid IRIs, avoiding semantic errors of null pointer type in subsequent queries or inferences, and further helping to solve the problems of poor traceability of cross-graph associations and difficulty in ensuring reference consistency.

[0068] To further refine the division method of the multi-level SHACL constraint rule set, this disclosure also provides the following preferred scheme. In a preferred embodiment, see... Figure 2The multi-level SHACL constraint rule set is specifically defined as including three layers: integrity constraints for data structures, consistency constraints for business semantics, and validity constraints for cross-graph relationships. The integrity constraints include at least restrictions on the number of class instances, cardinality constraints on attribute values, and data type constraints. For example, the restriction on the number of class instances can be implemented by declaring `sh:targetClass` on the shape and combining it with the global `sh:minCount` / `sh:maxCount`; the cardinality constraint on attribute values ​​can be specified on the attribute shape (`sh:PropertyShape`) using `sh:minCount` and `sh:maxCount`, for example, constraining the unique identifier attribute `sso:id` of a part to appear only once; and the data type constraint can be specified using `sh:datatype` as a standard XSD type such as `xsd:string`, `xsd:double`, or `xsd:dateTime`.

[0069] The semantic consistency constraints include at least functional dependencies and mutual exclusion relationships between attributes. A functional dependency can be understood as a constraint that if the value of attribute A is determined, the value of attribute B should also be uniquely determined. This can be checked by writing a custom SPARQL query using the SHACL sh:sparql extension. A mutual exclusion relationship can be understood as meaning that attributes A and B are not allowed to have the same value on the same instance. This can be expressed using sh:not combined with sh:or. For example, one could constrain that once the rated current value of a conductor is determined, its allowable cross-sectional area must fall within a predetermined range; or one could constrain that an assembly hole cannot be filled with both welded and bolted connections simultaneously.

[0070] The cross-graph association validity constraint is used to verify whether the IRI reference across the named graph actually exists within the domain of the target named graph. As a specific example, a shape can be defined for the `lci:referTo` attribute, requiring that the target node pointed to by its `sh:path` must be explicitly defined as an instance of a given class within the pre-declared target named graph. When performing this shape check, the verification engine will automatically search the target named graph and perform an existence determination. By adopting the above specific constraints, this preferred solution can perform progressive, full-dimensional automatic verification from the lowest level of format and type, to the middle level of business logic, and then to the upper level of cross-graph associations, avoiding missed detections caused by a single verification dimension.

[0071] To address the issue of ensuring that only validated data is persisted during data storage, this disclosure provides the following preferred solution. In a preferred embodiment, the validation operation is performed synchronously during the transaction execution phase of the SSTRepository's BBOlt database. That is, the SHACL validation engine and the BBOlt database's transaction commit process are sequentially connected. When a transaction attempts to write to or modify a set of triples, the transaction processor calls the SHACL validation engine to perform a check of all effective rules on the target data of this transaction before the transaction is committed.

[0072] When a newly added or modified triple violates any constraint rule, the transaction is rolled back, and specific violation information is returned. This violation information may include the violating triple itself (e.g., returned as a subject-verb-object triple) and an identifier of the violated constraint rule (e.g., an IRI of the violated SHACL shape), allowing the transaction to be resubmitted for verification after the violation data is corrected. As a specific implementation, the violation information may further include a correction suggestion field, providing a possible range of correct values ​​or a reference instance. This design ensures atomicity and reliability in data persistence operations. The principle behind this is that the atomicity of transactions guarantees that if verification fails, all changes made by the entire transaction will not be implemented in the BBOlt database.

[0073] Those skilled in the art will understand that alternative structures achieving the same purpose may include: registering the SHACL verification engine as a pre-commit hook for the BBolt database; or employing a two-phase commit protocol, first writing changes to a staging area, and then migrating the changes from the staging area to the official data area after verification. These solutions all enable compliance checks to be completed before data enters the official repository. By adopting the above specific limitations, this preferred solution can form an immediate verification loop for data writing, further helping to solve the problem of difficulty in cleaning up non-compliant data after it has entered the repository.

[0074] To further expand the knowledge content while ensuring data integrity, this disclosure also provides the following preferred solutions. In a preferred embodiment, after performing a verification operation on the data constructed according to the naming layer hierarchical structure and attribution rules, and the verification passes, the method further includes: enabling the OWL inference engine on the verified subset of data according to configuration or invocation instructions, and performing knowledge inference based on explicitly declared ontology axioms. The configuration may be specified through a configuration file at system startup for which named graphs or classes to enable inference, and the invocation instructions may be dynamically triggered at runtime through an API interface.

[0075] The derived triples generated by the OWL inference engine are stored in a named graph or an in-graph region with different labels than the triples of the explicit assertion, to achieve physical separation. See also Figure 2 One specific storage location is the aforementioned inference result graph G3, which is physically independent of G0, G1, and G2, thus preventing the derived triples from being confused with the original business data. Alternatively, each triple can be labeled within the same named graph (e.g., using RDF-Star references or adding the `rdf:type:DerivedTriple` tag) to distinguish it from explicitly asserted triples. This design protects the integrity of the original business data, allowing the derived knowledge from the inference output to be managed, queried, and retrieved separately.

[0076] After inference is completed, a round of SHACL lightweight verification is automatically triggered. Compared to the full verification during the transaction write phase, the lightweight verification can omit irrelevant rules or select a subset of rules with shorter execution time. Its purpose is to confirm that the derived triples still satisfy industrial constraints with lower computational overhead. For example, it can specifically check whether the derived assembly hierarchy is consistent with the existing instance assembly topology. By adopting the above specific limitations, this preferred solution can effectively expand knowledge while avoiding inference pollution, further helping to solve the problem of low reliability of inference results. Those skilled in the art can easily combine the inference data isolation feature in this embodiment with the transaction synchronization verification feature in the aforementioned embodiments. This combination can simultaneously obtain highly complete original data and highly reliable derived data.

[0077] To enable the SHACL constraint rule set to flexibly adapt to the customized needs of different industrial sectors, this disclosure also provides the following preferred solutions. In one preferred embodiment, the SHACL constraint rule set adopts a modular design, that is, rules at different levels and in different fields are encapsulated into independent rule modules (e.g., structural constraint modules, semantic constraint modules, association validity constraint modules, and constraint modules for the electrical, mechanical, and chemical fields, etc.), and the modules are combined with each other through predefined reference interfaces. The SHACL verification engine that performs the verification operation supports hot updates to the rule set, which can add or modify industry-customized constraints without restarting the system.

[0078] This design eliminates the reliance on system startup for rule loading. The SHACL validation engine can monitor changes to the constraint rule set storage unit. When a new rule module is added or an existing module is modified, it dynamically updates the internal rule index and shape cache. Hot updates take effect immediately after the update and do not affect ongoing transactions. This is achieved through a versioned rule snapshot mechanism, where ongoing transactions continue to use their initial rule version for validation, while new transactions use the latest version, thus avoiding consistency issues caused by switching rules mid-transaction.

[0079] As a specific example, based on the SST ontology extension interface, industry-specific parameter constraints from the electrical wiring harness field (e.g., the connection number constraint sh:maxCount1 for ferrules and connectors), assembly constraints from the mechanical manufacturing field (e.g., the number of bolts in the same assembly hole position), or process verification logic from the chemical industry (e.g., the upper limit constraint of reactor pressure) can be superimposed on top of the basic three-layer rules of structure, semantics, and association. This superposition process requires no system downtime. By adopting the above specific constraints, this preferred solution can significantly improve the system's domain adaptability and maintenance flexibility.

[0080] To output the processed, high-quality industrial data in a standardized, interchangeable manner for consumption by external industrial software, this disclosure also provides the following preferred solutions. In a preferred solution that follows the foregoing inference implementation, see... Figure 1 The data output layer in the implementation environment shown also includes: serializing the verified and / or inferred industrial data model using RDF / Turtle format, or outputting it through the API interface provided by the SST core library. The RDF / Turtle format is a compact RDF text serialization format specified by the W3C, which can export named diagrams, IRIs, and triples into .ttl files in a human-readable format for direct parsing by third-party W3C-compliant tools. The API interface can be a set of read and query interfaces exposed by the SST core library, providing programmatic access to industrial software such as CAD, PDM, ERP, and MES in various ways, including by named diagram, by IRI, and by SPARQL query.

[0081] This design allows for the delivery of governed data in two complementary ways: a serialization format suitable for offline exchange and archiving, and an API interface suitable for online consumption and real-time integration. Those skilled in the art will understand that alternative structures achieving the same purpose may include other RDF serialization formats such as JSON-LD, N-Quads, and RDF / XML, or other API styles such as GraphQL and REST. By adopting the specific constraints described above, this preferred solution enables seamless integration of data governance results with the industrial ecosystem.

[0082] To further thoroughly implement the integrity semantics of the closed-world assumption, this disclosure also provides the following preferred solutions. In a preferred embodiment, the setting rules are explicitly stipulated such that data not explicitly declared in any named graph is judged as missing or invalid. This constraint aims to eliminate any data ambiguity at the rule level. This design makes integrity determination no longer dependent on implicit assumptions. The principle is that the global closed-world rule is written in plaintext into the constraint rule set. Any missing parameters, assembly relationships, or attributes will be identified as empty matches during the matching phase of the SHACL verification engine, and thus reported as missing or invalid. As a specific implementation, sh:minCount 1, sh:closed true, and custom sh:message text can be widely used on the SHACL shape to combine closed-world determination with human-readable error feedback. By adopting the above specific constraints, this preferred solution can comprehensively guarantee the determinism of industrial data.

[0083] Corresponding to the above methods, this disclosure also provides an industrial data organization and verification apparatus that incorporates the closed-world assumption. The apparatus includes: a named graph construction module for constructing a named layer hierarchical structure with import relationships; a rule setting module for setting rules, including ensuring that each IRI node uniquely belongs to a named graph, and that only the belonging named graph defines triples with the IRI node as the subject, while other named graphs can only reference the IRI node; a constraint rule set predefinition module for predefining a multi-level SHACL constraint rule set, the rule set including at least data integrity constraints and semantic consistency constraints; and a verification module for performing verification operations on the data constructed according to the named layer hierarchical structure and belonging rules, and performing integrity and compliance checks according to the rule set.

[0084] The named graph construction module can be deployed in software within the named graph construction unit of the aforementioned data organization layer, or it can be implemented in hardware as a dedicated module with independent processing capabilities. The rule setting module can maintain the IRI node ownership registration table and descriptive data of cross-graph reference relationships. The constraint rule set predefinition module can load pre-written SHACL rule files during system initialization and supports adding new rule modules subsequently via hot updates. The verification module can integrate or call the SHACL verification engine, triggering its execution by listening for transaction events in the data warehouse layer. The above modules are sequentially connected through internal interfaces, and their collaborative working method corresponds to steps S101 to S104 described in the aforementioned method embodiments, and will not be repeated here.

[0085] In an optional implementation, this disclosure also provides another RDF / OWL industrial data organization and verification apparatus that incorporates the closed-world assumption. This apparatus also includes a named graph construction module, a rule setting module, a constraint rule set predefinition module, and a verification module. The rule setting module is used to set rules so that each IRI node uniquely belongs to a named graph, and only that graph defines triples with the IRI node as the subject; other named graphs can only reference them. The verification module is used to perform verification operations on the data organized according to the rules. The implementation of each module of this apparatus can refer to the corresponding modules of the aforementioned apparatus, and can be functionally subdivided or merged according to actual deployment needs.

[0086] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements any of the methods described in the foregoing method embodiments. The computer-readable storage medium may include, but is not limited to, various media capable of storing program code such as ROM, RAM, disk, optical disk, and solid-state drive.

[0087] This disclosure also provides an industrial data governance system, see [link to relevant documentation] Figure 1 The system includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements any of the methods described in the foregoing method embodiments. The system also includes a data warehouse module (i.e., the SSTRepository in the foregoing data warehouse layer), used to store RDF data organized according to a named graph, and has a built-in SHACL verification engine to perform integrity and compliance checks on the data based on a multi-level SHACL constraint rule set. The system can be deployed on a single server or in a distributed cluster. The interfaces between its layers are implemented within the same operating environment, providing a unified operating platform for the specific processing flows described in the foregoing method embodiments.

[0088] The technical solution of this disclosure will be described below with reference to a specific embodiment. It should be noted that this specific embodiment is only for the purpose of enabling those skilled in the art to better understand the solution of this disclosure, and should not be regarded as an unreasonable limitation on the scope of protection of this disclosure.

[0089] An aerospace manufacturing company is designing the Electrical Wiring System (EWIS) for a new generation of wide-body passenger aircraft. The project involves tens of thousands of connectors and ferrules, requiring collaboration from multiple engineering teams located in different regions. The design data is stored in an industrial data governance system in RDF format. During the initial system deployment phase, maintenance personnel first construct a named layer-level structure: a basic ontology graph G0 is created, storing the SST core ontology, industry standard vocabulary, and connector basic part type definitions; a new domain modeling graph G1 is created, declaring direct import relationships with G0 via owl:imports to inherit all basic part classes and attribute definitions; a process parameter graph G2 is then created, which will later separately store parameters such as harness diameter and bending radius; simultaneously, a separate inference result graph G3 is reserved to isolate and store derived triples generated by subsequent inference. The system assigns a unique UUID-URN identifier to each named graph, completing the construction of a data repository structure with clear data boundaries.

[0090] Subsequently, the rule setting module configures the IRI attribution and definition rules under the closed-world assumption for the entire system. Any IRI node representing a connector part, ferrule instance, or process parameter must uniquely belong to one of the aforementioned G0, G1, or G2. Taking the connector part body sso:Connector as an example, its core triples, such as type declaration and standard parameters, can only be defined in its attribution graph G0. In design collaboration, if assembly engineers in G1 want to reference this connector, they can only add reference triples through cross-graph association attributes such as lci:isDefinedBy; they have no right to modify its ontology definition. The rules also explicitly stipulate that any data fact not explicitly declared in any named graph is directly judged as missing or invalid. Attribution relationships are registered in the attribution registration table of the named graphs and verified in real time by the repository write interface.

[0091] Based on this architecture, the validation rule manager predefines a three-layer SHACL constraint rule set. Structural integrity constraints require each part instance to contain a unique identifier attribute `sso:id`, and that it appears exactly once. Semantic consistency constraints stipulate that assembly instances must point to a valid `sso:Part` class instance via `lci:isDefinedBy`. Cross-graph association validity constraints design shapes for cross-graph reference attributes, and the validation engine automatically checks that the target IRI actually exists within the domain of the target named graph during execution. The entire set of rules is stored in modular Turtle files and supports hot updates.

[0092] After a design engineer completes the modeling of a wire harness assembly station locally, they commit a batch of newly added triples via a BBolt transaction in the SST Repository. During the transaction execution phase, the system synchronously triggers the SHACL verification engine to perform three-level checks on the data being written. When a ferrule instance is found to be missing the sso:id attribute, indicating a violation of structural integrity constraints, the transaction is immediately rolled back, and a detailed error report containing the violating triples and the violated shape identifier is returned to the engineer's interface. After the engineer supplements the missing attributes based on the report and resubmits, the transaction successfully passes all checks and is persisted. For cases where an assembly instance references a temporary part IRI that is not yet defined in G1 across diagrams, the cross-diagram association validity constraint will also immediately identify the dangling reference, preventing the transaction from committing and thus preventing invalid association data from entering the repository.

[0093] After all data validations pass, the system, according to preset configurations, enables the OWL inference engine on a clean subset of data containing only compliant triples. Based on ontology axioms such as class inheritance and attribute association, the inference engine automatically derives assembly hierarchy relationships and implicit component connections. The generated derived triples are uniformly stored in the G3 inference result graph, physically isolated from the original assertion data in G0 to G2. Subsequently, the system automatically performs a lightweight SHACL secondary validation to ensure that the derivation relationships still conform to industry constraints. Throughout this process, the original business data remains uncontaminated, and the derived knowledge is reliable and traceable.

[0094] In the output phase, the complete industrial data model, after verification and inference, is serialized and exported as a .ttl file in RDF / Turtle format for direct parsing and consumption by downstream MES and PDM systems. Simultaneously, the open SST API allows CAD tools to query assembly trees in specified named drawings online, enabling seamless integration of heterogeneous industrial software.

[0095] In this scenario, this disclosure significantly improves the efficiency of electrical harness data management in cross-regional team collaborative design. For example, the accuracy of data integrity verification reaches 100%, completely avoiding errors such as missing parameters or omissions in assembly relationships caused by the OWL open world assumption. The workload of manual review is reduced by approximately 75%, cross-graph reference conflicts are reduced to zero, and the knowledge extension results stored in the independent reasoning graph are accurate and not confused with the original design data. The overall data governance forms a closed loop from writing, verification, reasoning to output, providing a highly deterministic and life-cycle traceable industrial data foundation for passenger aircraft EWIS design.

[0096] In addition to the methods, apparatus, and devices described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the cross-modal retrieval methods for a specific domain provided in the various embodiments of this disclosure.

[0097] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0098] Furthermore, embodiments of this disclosure may also be storage media (e.g., computer-readable storage media) storing a computer program (or instructions) thereon, which, when run by a processor, causes the processor to perform the various steps of the cross-modal retrieval methods for a specific domain provided in the various embodiments of this disclosure.

[0099] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0100] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0101] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0102] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] In addition, the functional units in the various embodiments of this disclosure can be integrated into a similar region segmentation unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0106] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for organizing and validating industrial data that incorporates the closed-world hypothesis, characterized in that, include: Construct a named layer-level structure with import relationships; The rules include ensuring that each IRI node uniquely belongs to a single named graph, and that only the named graph to which it belongs defines triples with that IRI node as the subject; other named graphs can only reference that IRI node. A predefined multi-level SHACL constraint rule set is provided, which includes at least data integrity constraints and semantic consistency constraints. Validation operations are performed on the data constructed according to the naming layer-level structure and attribution rules, and integrity and compliance checks are performed according to the rule set.

2. The method according to claim 1, characterized in that, The construction of the named layer hierarchical structure with import relationships includes: defining direct import and indirect inheritance relationships between named graphs, so that a named graph inherits the definition rights and semantics of all IRI nodes in the imported named graph by importing another named graph; Preferably, the imported named graph has only read-only permissions for the IRI nodes of the imported named graph and does not have permissions to modify the definition of the imported named graph. The import relationship supports multi-level inheritance.

3. The method according to claim 1, characterized in that, The setting rules also include: for cross-name graph associations, explicitly declaring the legal boundaries of the association by defining attribute chains or using SHACL attribute paths; Preferably, the verification operation includes: the verification engine automatically checking whether the target IRI referenced across the graph actually exists within the domain of the target named graph.

4. The method according to claim 1, characterized in that, The multi-level SHACL constraint rule set includes integrity constraints for data structures, consistency constraints for business semantics, and validity constraints for cross-graph relationships; the integrity constraints include at least the limit on the number of class instances, the cardinality constraint on attribute values, and the data type constraint; the semantic consistency constraints include at least the functional dependencies and mutual exclusion relationships between attributes. Preferably, the cross-graph association validity constraint is used to verify whether the IRI reference across the named graph actually exists within the domain of the target named graph.

5. The method according to claim 1, characterized in that, The verification operation is performed synchronously during the transaction execution phase of the BBolt database in the SST Repository; when a newly added or modified triple violates any constraint rule, the transaction is rolled back and the specific violation information is returned. Preferably, the violation information includes a violation triple and an identifier of the violated constraint rule, to support resubmitting the transaction for re-verification after the violation data is corrected.

6. The method according to claim 1, characterized in that, The verification operation performed on the data constructed according to the naming layer hierarchy structure and attribution rules, after the verification set results are passed, further includes: enabling the OWL inference engine on the verified data subset according to the configuration or calling instructions, and performing knowledge inference based on the explicitly declared ontology axioms; Preferably, the derived triples generated by the OWL inference engine are stored in a named graph different from the triples of the explicit assertion or in a graph region with different labels, thus achieving physical separation. Preferably, a round of SHACL lightweight verification is automatically triggered after inference is completed.

7. The method according to claim 1, characterized in that, The SHACL constraint rule set adopts a modular design. The SHACL verification engine that performs verification operations supports hot updates of the rule set. The hot updates can add or modify industry-customized constraints without restarting the system. Preferably, the hot update takes effect immediately after the update and does not affect ongoing transactions.

8. The method according to claim 6, characterized in that, Also includes: The validated and / or inferred industrial data model is serialized in RDF / Turtle format or output via the API interface provided by the SST core library.

9. The method according to claim 1, characterized in that, The rules set up so that data not explicitly declared in any named graph is judged as missing or invalid.

10. An industrial data organization and verification device incorporating the closed-world hypothesis, characterized in that, include: The named graph building module is used to build a named layer-level structure with import relationships; The rule setting module is used to set rules, including ensuring that each IRI node uniquely belongs to a named graph, and that only the named graph to which it belongs defines triples with the IRI node as the subject, while other named graphs can only reference the IRI node; A constraint rule set predefined module is used to predefine multi-level SHACL constraint rule sets, which include at least data integrity constraints and semantic consistency constraints. The verification module is used to perform verification operations on the data constructed according to the naming layer-level structure and attribution rules, and to perform integrity and compliance checks according to the rule set.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 9.

12. An industrial data governance system, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 9; The system also includes a data warehouse module for storing RDF data organized according to a named graph, and has a built-in SHACL verification engine to perform integrity and compliance checks on the data based on the multi-level SHACL constraint rule set.