Complex equipment knowledge graph constraint construction method

Abstract

The invention discloses a complex equipment knowledge graph constraint construction method, and relates to the technical field of complex equipment.The method comprises the steps that firstly, data features of complex equipment in the whole life cycle of the complex equipment are analyzed, and a corresponding knowledge graph is constructed; furthermore, two types of constraint models are provided: a universal constraint model which is suitable for all complex equipment knowledge; and the special constraint model is designed for a specific knowledge type. In addition, the invention also develops an automatic construction algorithm of global constraints and a semi-automatic construction algorithm of local constraints, and aims to reduce manual intervention and improve the efficiency and applicability of knowledge graph construction. Experimental verification is carried out on a data set in the field of wind power equipment, and the result shows that the method can provide a constraint model for the equipment-level knowledge graph and can replace a traditional manual constraint construction method, so that the quality and construction efficiency of the knowledge graph are improved, and the purpose of improving the reliability of downstream services such as question and answer recommendation is achieved.

Description

Technical Field

[0001] The present invention relates to the field of complex equipment technology, and more specifically to a method for constructing complex equipment knowledge graph constraints. By researching and developing knowledge graph technology, especially by constructing general and special constraint models, and developing automatic and semi-automatic construction algorithms, data quality is improved, the knowledge graph construction process is optimized, and the knowledge graph data quality is improved to meet the accuracy and efficiency of downstream services. Background Art

[0002] With the rapid development of artificial intelligence technology, knowledge graphs have become core tools in fields such as information retrieval, natural language processing, and recommendation systems. Knowledge graphs provide a new way for machines to understand the real world by representing entities and relationships in a structured manner. However, the construction and maintenance of knowledge graphs face challenges in data quality. Although there are various definitions and evaluation methods for data quality, there is a lack of unified standards. Data quality is not only affected by intrinsic characteristics, but is also closely related to the business environment.

[0003] In horizontal fields, the accuracy of knowledge graphs can tolerate certain errors and is mainly used to provide macro information. In vertical fields, such as healthcare and finance, data accuracy and quality requirements are higher because they support sophisticated decision-making and complex analysis. Inaccurate data can lead to serious consequences, such as misdiagnosis in the medical field and investment errors in the financial field. Therefore, improving data accuracy is crucial to improving application performance, reliability, and fulfilling social responsibility.

[0004] In industrial environments, knowledge graphs are used for decision making and search and answer questions. Their data includes scheduling, manufacturing, production processes, and expert knowledge. Low-quality data may lead to misleading information and affect the accuracy of decision-making and question-answering. In addition, knowledge graphs also play an important role in preventive maintenance in industrial scenarios. For example, in the operation and maintenance stage of complex equipment, inaccurate data may lead to improper equipment maintenance and increase operation and maintenance costs.

[0005] In addition, there are still some shortcomings in the existing knowledge graph integrity constraint construction and automatic construction methods, which are mainly reflected in the fact that the construction of knowledge graph constraints currently relies mainly on manual construction by domain experts, and there are few automated construction algorithms and tools. Some scholars have conducted research on semi-automatic methods for constraint construction, combining algorithms and interactive workflows to construct SHACL or ShEx constraints for existing RDF data sets. This method allows users to use schematic patterns as a parameterization mechanism to guide and adjust automatically generated patterns with expert knowledge, thereby generating complex patterns containing nested constraints and references between shapes. However, this method has a lot of noise or incompleteness in more complex knowledge systems, resulting in a huge workload for review and editing by domain experts. Therefore, in industrial verticals, automated construction faces more complex challenges:

[0006] (1) Industry-specific data patterns and constraint requirements are very complex, making existing automatic construction methods unable to adapt to these complexities.

[0007] (2) Industrial data often contains sensitive content and is subject to strict data management regulations. In this context, the industry has put forward more rigorous standards and expectations for the accuracy and execution efficiency of the data constraint verification process.

[0008] Complex equipment refers to equipment systems with complex structures, diverse functions, and high technical requirements, such as shield machines, high-speed trains, and wind turbines. They have the following three characteristics: (1) Complex structure. For example, a high-speed train is composed of tens of thousands of parts, and there are complex constraints between the parts; (2) The design, manufacturing, and operation and maintenance of complex equipment are all based on parts as task units, so the application of knowledge is also based on the assembly relationship at the part level; (3) The production of complex equipment is characterized by single-piece and small-batch, and its production organization model mostly adopts modular customization to meet the changing market needs.

[0009] The R&D process and data sources of the entire life cycle of complex equipment involve all stages from conceptual design, detailed design, manufacturing, testing, use, maintenance to scrapping. In order to realize the digitalization, intelligence and visualization of equipment management and application, it is essential to establish an information model of complex equipment. However, these data are usually stored in relational databases represented by XBOM (X Bill of Material), which have the characteristics of diverse sources, strong heterogeneity and huge data volume.

[0010] Therefore, a method for constructing complex equipment knowledge graph constraints is urgently needed. Summary of the invention

[0011] In order to overcome the defects in the above-mentioned prior art, the present invention discloses a method for constructing complex equipment knowledge graph constraints. The present invention improves data quality by studying the integrity constraints in the knowledge graph, thereby optimizing the equipment-level knowledge graph. First, general and special constraint models are constructed using the characteristics of equipment knowledge, and then automatic and semi-automatic construction algorithms are designed respectively to verify the equipment knowledge in the knowledge graph, so as to improve the quality of knowledge graph data and improve the accuracy and efficiency of downstream services such as recommendation questions and answers.

[0012] In order to achieve the above objectives, the technical solution adopted by the present invention is:

[0013] A method for constructing complex equipment knowledge graph constraints, comprising the following steps:

[0014] Step S1, collect complex equipment data to construct a knowledge graph ontology, and classify the knowledge graph ontology;

[0015] Step S2: Based on the knowledge graph ontology classification, define a general constraint model and a special constraint model;

[0016] Step S3: construct a general constraint model using a global constraint construction method, and construct a special constraint model using a local constraint construction method;

[0017] Step S4: verify the constructed general constraint model and special constraint model, and modify the complex equipment knowledge graph according to the verification results.

[0018] 1. Knowledge Graph Ontology Classification

[0019] Preferably, the knowledge graph ontology classification includes: general bill of materials GBOM, instance knowledge Instance, event knowledge Event, and abstract knowledge Abstract;

[0020] Among them, the general bill of materials GBOM is a general template of assembly relationship between modules constructed based on product family characteristics, with hierarchical relationship and unique identification. GBOM provides a unified template or specification to generate different instance class knowledge;

[0021] The instance-based knowledge Instance reflects the specific application scenarios and practical experience of knowledge and is the concrete embodiment of theoretical knowledge in practice. Instance-based knowledge has direct application value in knowledge management and provides practical guidance and reference for solving specific problems.

[0022] The event-type knowledge Event is a derivative of instance-type knowledge and is composed of multiple instance-type knowledge. Event-type knowledge describes the process, rules and impact of specific events or phenomena, and is the result of abstraction and summary of instance-type knowledge. Through the study and analysis of event-type knowledge, we can obtain in-depth understanding and insights to guide practice and decision-making.

[0023] The abstract class knowledge Abstract is the subdivision and classification of instance knowledge. It is formed by extracting and summarizing the common features of instances to understand and manage the structure and internal relationships of knowledge. Abstract class knowledge provides a deep understanding of knowledge and discovers the commonalities and laws between knowledge.

[0024] 2. Define the constraint model

[0025] Preferably, step S2 also includes defining a basis, wherein defining a basis includes defining a basic diagram and defining basic constraints, wherein defining a general constraint model includes defining a general bill of materials (GBOM) constraint model, defining a chain constraint model, and defining an abstract class entity constraint model, and wherein defining a special constraint model includes defining an attribute constraint model, defining an event class entity constraint model, and defining a rule class constraint model.

[0026] In the present invention, step S2 defines the basic graph, defines the basic constraints, defines the general bill of materials (GBOM) constraints, defines the chain constraints, defines the abstract class entity constraints, defines the attribute constraints, defines the event class entity constraints, and defines the rule class constraints, a total of 8 definitions, as follows:

[0027] 2.1 Define the basic graph

[0028] Preferably, the defined basic graph includes: an RDF graph G is a set of triples, (a, p, b) represents a triple, a, p, b are the subject, predicate, and object of the triple respectively; an element appearing in the subject or object position is called a node, and an element appearing in the predicate position is called a relationship or attribute; the triple is represented in the form of p(a, b), if N(G) and P(G) represent the node set and attribute name set in G respectively, where the attribute name set includes a set of internal attribute names and external attribute names, then p∈P(G), a∈N(G), and P(a) represents the attribute name set of node a.

[0029] 2.2 Define basic constraints

[0030] Preferably, the defining basic constraint comprises: assuming S=(L,def) is a SHACL pattern, where L is a finite set of shape names, def is associated with each shape name in L, and the definition is a shape constraint; the verification target of the pattern S and the graph G is a pair T=(L,tgt), where tgt associates a set of nodes in G with shape names in L; if for any shape name l in L, all nodes in tgt(l) satisfy the constraint def(l), then the graph G satisfies the pattern S with the target T;

[0031] Where G represents a triple set, N represents a node set, P represents a set of attribute names, L represents a set of shape names, def represents a shape constraint associated with a shape name, and S = (L, def) represents a SHACL pattern, which can be simplified to S = {def(l1), def(l2), ..., def(l n )}, tgt represents a set of nodes associated with the shape name, T = (L, tgt) represents the verification target, which can be simplified to T = {tgt(l1), tgt(l2), ..., tgt(l n )}.

[0032] 2.3 Defining GBOM constraints

[0033] Preferably, the definition of the general bill of materials GBOM constraint model includes: the complex equipment knowledge graph organizes knowledge with GBOM, all knowledge is mounted under GBOM, all knowledge has a reachable path with GBOM, and the constraint is defined as l = 'GBOM_constraint', where l∈L, and the corresponding def(l) expression is: satisfy:

[0034] Φ::=(p(v,a)|^p(v,a))∧(p(a,b)|^p(a,b)) * ∧(p(b,v GBOM )|^p(b,v GBOM ))

[0035] Where Φ represents a shape expression, ::= is the Backus-Naur form, which represents a definition, (p())* represents a path connecting the subject and the object through zero or more matching p(), ^p() represents the reverse path, v,a,b,v GBOM ∈N(G),v GBOM The node representing the ontology concept is a GBOM, that is, it satisfies the shape Node, type represents internal attributes, and ontology concepts use Represents a shape constraint expression for a node.

[0036] 2.4 Defining chain constraints

[0037] Preferably, the definition of the chain constraint model includes: when the shape constraint of an entity contains another entity constraint, a chain constraint is generated; if a shape l' appears in the constraint expression of a certain shape l, then when verifying the shape l and its constrained node v, the verification of the shape l' and its constrained node v' is called; if def(l)←def(l')∧Φ, where l, l'∈L, Φ represents other shape expressions, then what is actually verified is S={def(l'),def(l)}.

[0038] 2.5 Defining abstract class entity constraints

[0039] Preferably, the definition of the abstract class entity constraint model includes: the abstract class entity is a classification item abstracted from the instance class knowledge, which is responsible for improving the subgraph segmentation and reasoning efficiency in the reasoning and application of the knowledge graph, and depends on the corresponding instance knowledge; the abstract class entity is strongly associated with at least one type of instance knowledge, and its shape is expressed as a constraint on any entity that satisfies the shape , subClassOf represents the attribute of node v, Abstract represents abstraction, and the ontology concept type satisfies:

[0040]

[0041] in, Represents non,subClassOf,type∈P(G).

[0042] 2.6 Defining attribute constraints

[0043] Preferably, the definition of the attribute constraint model includes: attribute constraints are divided into attribute value type constraints and attribute value format constraints. Attribute constraints are some widely recognized consensus constraints and attribute specification constraints required by the field. The attribute value type constraint refers to which type or types a certain attribute of an entity must be. The attribute value types of data attributes include: string type, integer type, and time type; the attribute value format constraint stipulates the numeric range or string format of the attribute value, which is used to constrain data attributes.

[0044] 2.7 Define event entity constraints

[0045] Preferably, the event entity constraint model is defined as follows: the event entity is similar to the intermediate table in the relational database, and its entity is composed of other entities and has atomicity; if other entities associated with the event entity are deleted, the corresponding event entity and its associated edges are deleted together; in the data model, there is a strong coupling relationship between the event entity and other entities associated with it; when designing the data model, consider how to implement atomicity constraints; defining the event entity constraint model includes: for any entity that satisfies the shape Nodes that satisfy:

[0046]

[0047] Where: a1, a2, ..., a n Represents the entity node participating in the event, n≥2. The constraint after the last ∧ indicates that the entity participating in the event may be of event type in addition to instance type. Event represents the event.

[0048] The event includes constraints: when there is another event class entity in the entity associated with the event, there is a causal relationship between the two events; when the cause event disappears, the effect event disappears together; it is expressed as when nodes a and b satisfy the shape a←subClassOf.Event, b←subClassOf.Event, satisfy

[0049] 2.8 Define rule class constraints

[0050] Preferably, the rule-based constraint model includes: in the complex equipment knowledge graph, there are specific semantic constraints between component design, process and manufacturing parameter values. This type of rule-based constraint refers to the rules or conditions for specific attribute values ​​defined by experts based on domain knowledge and needs. Sub-level attributes are related to parent-level attributes. Rule-based constraints include conditional constraints and ordinary constraints.

[0051] 3. Building a Constraint Model

[0052] 3.1 Construction method of global constraints Constructing a general constraint model

[0053] Preferably, in the construction method of the universal constraint model using the global constraint, the ontology graph O and the graph G have similar structures, the difference lies in the different storage data, the graph O stores the node relationship information of the ontology, and the graph G stores the node relationship information of the entity, wherein, GBOM , l Abstract ∈SL, all have already constructed and encapsulated constraints def(l GBOM )、def(l Abstract ), this construction method constructs GBOM constraints, chain constraints and abstract class entity constraints for each type of ontology by parsing the ontology graph.

[0054] Preferably, the construction method of using global constraints to build a universal constraint model includes the following steps:

[0055] Step A1: Input the ontology graph O, obtain the ontology nodes from the graph O, and save it as the ontology list O_list;

[0056] Step A2: traverse the ontology list and construct GBOM constraints and abstract class entity constraints;

[0057] Step A21: let i=1;

[0058] Step A22: determine whether i is less than or equal to the length of the entity list, if yes, proceed to the next step, otherwise go to step A3;

[0059] Step A23: Determine whether the i-th element o of O_list satisfies That is, whether the name of the ontology o is GBOM, if so, the ontology calls the packaged GBOM constraint, def(l o )←def(l GBOM ), otherwise proceed directly to the next step;

[0060] Step A24: Determine whether the entity o satisfies That is, whether the ontology type of ontology o is abstract class knowledge, if so, let the ontology call the encapsulated abstract class entity constraint, def(l o )←def(l o)∧def(l Abstract ), otherwise proceed directly to the next step;

[0061] Step A25: Construct the constraint def(l o ) is added to the SHACL pattern S;

[0062] Step A26: Verify the target atom tgt(l o ) is added to the verification target T;

[0063] Step A27: set i+1, and go to step A22;

[0064] Step A3: traverse the shape set and construct chain constraints;

[0065] Step A31: let j=1;

[0066] Step A32: determine whether j is less than or equal to the length of the shape set TL in the verification target, if yes, proceed to the next step, otherwise go to step A4;

[0067] Step A33: Determine whether the constraint def(l) of the j-th element l in TL contains another shape constraint l', and At the same time, l'∈SL, where SL represents the shape set in SHACL; if yes, add the verification target atom tgt(l') to the verification target T; otherwise go to step A34;

[0068] Step A34: let j+1, go to step A32;

[0069] Step A4: Output SHACL pattern S and verification target T.

[0070] 3.2. Construction method of local constraints to build a special constraint model

[0071] Preferably, in the construction of a special constraint model using the construction method of local constraints, for attribute constraints, an ontology attribute dictionary is created when constructing the ontology, the dictionary includes name, type and value range, and the attribute dictionary is added to the constraint construction as a reference template; when constructing event-type entities, ontology concepts that are strongly associated with the event are obtained to provide a template for the shape constraints of the event-type entities; rule-type constraints are designed with templates based on two types: conditional constraints and ordinary constraints, and the constraint construction is assisted by constructing a rule dictionary.

[0072] Preferably, the construction method using local constraints to build a dedicated constraint model includes the following steps:

[0073] Step B1: Input the ontology graph O, obtain the ontology nodes from the graph O, and save it as the ontology list O_list;

[0074] Step B2: traverse the ontology list and construct three local constraints, setting i = 1;

[0075] Step B3: Determine whether i is less than or equal to the length of the entity list, if yes, proceed to the next step, otherwise go to step B10;

[0076] Step B4: traverse each attribute of the ith ontology o in O_list and construct attribute constraints;

[0077] Step B41: let j=1;

[0078] Step B42: Determine whether j is less than or equal to the length of the attribute set P(o) of the ontology node; if yes, proceed to the next step, otherwise go to step B5;

[0079] Step B43: Determine whether the jth attribute of P(o) is in the attribute dictionary set PD; if so, set the ontology constraint def(l o ) calls the attribute type constraint, that is, def(l o )←def(l datatype ), otherwise go to step B45;

[0080] Step B44: Determine whether the value range corresponding to the jth attribute of P(o) in PD is empty; if so, go to step B45, otherwise call the attribute value format constraint, i.e., def(l o )←def(l o )∧def(l range );

[0081] Step B45: let j+1, go to step B42;

[0082] Step B5: construct event class constraints;

[0083] Step B51: Determine whether the entity is an event class, if yes, go to the next step, otherwise go to step B6;

[0084] Step B52: Obtain the instance class and event class ontology concepts associated with the event and save them as E_list;

[0085] Step B53: Use E_list to construct event class entity constraint def(l Event ), the ontology constraint def(l o ) calls the event class entity constraint, that is, def(l o )←def(l o )∧def(l Event );

[0086] Step B54: construct causal association constraints;

[0087] Step B541: traverse the ontology concept list E_list associated with the event, and set k=1;

[0088] Step B542: Determine whether k is less than or equal to the length of E_list, if yes, go to the next step, otherwise go to step B6;

[0089] Step B543: Determine whether the kth ontology concept type of E_list is an event class; if so, call the event class entity causal association constraint, i.e., def(l o )←def(l o )∧def(l causal ), otherwise the next step;

[0090] Step B544: let k+1, go to step B542;

[0091] Step B6: construct rule class constraints;

[0092] Step B61: Filter out the rule constraint list Ru whose ontology concepts are the same as ontology o from the rule constraint set RC, traverse the list, and set h=1;

[0093] Step B62: Determine whether h is less than or equal to the length of Ru; if yes, proceed to the next step, otherwise go to step B7;

[0094] Step B63: Determine whether the rule type corresponding to the hth element of Ru is a conditional constraint, if yes, go to step B64, otherwise go to step B65;

[0095] Step B64: Construct a conditional rule constraint based on the expression corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l condition[h] ), then go to step B66;

[0096] Step B65: Construct a general class rule constraint based on the expression corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l rule[h] ), then go to step B66;

[0097] Step B66: set h+1, and go to step B62;

[0098] Step B7: Construct the constraint def(l o ) is added to the SHACL pattern S;

[0099] Step B8: Verify the target atom tgt(l o) is added to the verification target T;

[0100] Step B9: Set i+1 and go to step B3;

[0101] Step B10: Output SHACL mode S and verification target T.

[0102] Preferably, in the construction method of using local constraints to construct a special constraint model, the attribute dictionary provides a template for attribute constraints, and the rule constraint set provides a template for rule class constraints; wherein the rule constraint set is composed of ontology concepts, rule types and rule expressions, datatype , l range , l Event , l causal , l condition , l rule ∈SL, all have already constructed and encapsulated constraints def(l datatype )、def(l range )、def(l Event )、def(l causal )、def(l condition )、def(l rule ), def(l datatype )、def(l range )、def(l Event )、def(l causal )、def(l condition )、def(l rule ) are attribute type constraints, attribute value format constraints, event entity constraints, event causal association constraints, conditional rule constraints, and general rule constraints.

[0103] IV. Model Validation

[0104] In the present invention, based on all the above constraint definitions and constructions, the final constraint file is generated and enters the verification phase together with the entity graph. All constraints are integrated into a SHACL file, and a verification report is generated using a verification model combined with the SHACL engine. Finally, the verification report is parsed and the knowledge graph is corrected.

[0105] Beneficial effects of the present invention:

[0106] 1. The present invention provides a method for improving data quality in the field of complex equipment by studying integrity constraints in knowledge graphs, thereby optimizing equipment-level knowledge graphs. First, general and special constraint models are constructed using the characteristics of equipment knowledge, and then automatic and semi-automatic construction algorithms are designed to verify the equipment knowledge in the knowledge graph, thereby improving the quality of knowledge graph data and improving the accuracy and efficiency of downstream services such as recommendation questions and answers.

[0107] 2. In the field of equipment, knowledge graph technology has been widely used in design, manufacturing, operation and maintenance, but its performance is often limited by data quality. The present invention first analyzes the data characteristics of complex equipment throughout its life cycle and constructs the corresponding knowledge graph. Furthermore, two types of constraint models are proposed: a general constraint model, which is applicable to all complex equipment knowledge; and a special constraint model, which is designed for specific knowledge types. In addition, the present invention has also developed an automatic construction algorithm for global constraints and a semi-automatic construction algorithm for local constraints, aiming to reduce manual intervention and improve the efficiency and applicability of knowledge graph construction. Through experimental verification on a data set in the field of wind power equipment, the results show that the present invention can not only provide a constraint model for equipment-level knowledge graphs, but also replace the traditional manual constraint construction method, thereby improving the quality and construction efficiency of the knowledge graph, and achieving the purpose of improving the reliability of downstream services such as recommendation questions and answers. BRIEF DESCRIPTION OF THE DRAWINGS

[0108] Figure 1 Build a process for the ontology.

[0109] Figure 2 Schematic diagram of GBOM constraints.

[0110] Figure 3 This is a schematic diagram of abstract class entity constraints.

[0111] Figure 4 This is a schematic diagram of event-type entity constraints.

[0112] Figure 5 Verify the technical route for knowledge data.

[0113] Figure 6 It is the main body of wind power equipment.

[0114] Figure 7 This is a partial screenshot of the wind power equipment constraint file.

[0115] Figure 8 To verify the report.

[0116] Fig. 9 Store partial views in Neo4j for knowledge storage.

[0117] Fig.10 This is the verification when test set 1 meets the constraints. Sub-graph a is the visualization graph of test set 1, and sub-graph b is the verification result of test set 1.

[0118] Fig.11 This is the verification when test set 1 does not meet the constraints. Sub-figure a is the visualization diagram after test set 1 is destroyed, and sub-figure b is the verification result after test set 1 is destroyed.

[0119] Fig.12This is the verification when test set 2 meets the constraints. Sub-figure a is the visualization diagram of test set 2, and sub-figure b is the verification result of test set 2.

[0120] Fig.13 This is the verification when test set 2 does not meet the constraints. Sub-figure a is the visualization diagram after test set 2 is destroyed, and sub-figure b is the verification result after test set 2 is destroyed. DETAILED DESCRIPTION

[0121] The concept, specific structure and technical effects of the present invention will be clearly and completely described below in conjunction with the embodiments and drawings to fully understand the purpose, characteristics and effects of the present invention.

[0122] Example 1

[0123] GBOM (Generic Bill of Materials), as a general bill of materials structure, can effectively sort out and organize data and information throughout the life cycle of complex equipment. Through GBOM, data from various stages can be systematically integrated to achieve digital, intelligent and visual management of the entire life cycle of complex equipment. The knowledge architecture of the knowledge graph follows the above rules to create a comprehensive information model to achieve effective integration and management of data throughout the life cycle of complex equipment.

[0124] The complex equipment knowledge graph of the present invention will start from GBOM to build an ontology model. In order to organize and manage knowledge resources more systematically to meet the needs of different levels and scenarios and improve the efficiency of retrieval and reasoning, the ontology concepts are divided into four types, as shown in Table 1.

[0125] Table 1 Classification of complex equipment knowledge graph ontology concepts

[0126]

[0127]

[0128] According to the definition, GBOM is also an abstract knowledge, but it is in a central hub position in the equipment knowledge graph, so it is described separately. Based on this setting, this description adds ontology concept classification to the ontology construction, and uses the improved top-down seven-step method to construct the ontology. The construction process is as follows: Figure 1 shown.

[0129] When constructing a complex equipment knowledge graph, the quality of the knowledge graph can be improved by using domain knowledge to correct and enhance relationship descriptions. The design of knowledge graph constraint rules aims to analyze the knowledge characteristics of domain knowledge and improve the data quality and consistency in the knowledge graph. Before the constraint construction, a constraint rule definition applicable to the complex equipment knowledge graph is proposed to constrain the attributes of entities and relationships. The present invention divides constraints into two categories: global constraints that can be constructed automatically and local constraints that are semi-automatically constructed based on templates. Global constraints refer to constraints that are applied to the vast majority of entity and relationship attributes and are based on fixed rules or conditions; local constraints define templates or specifications based on knowledge characteristics, thereby performing targeted restrictions, and have more flexible applicability and extensibility. First, the basic representation of RDF graphs and the abstract syntax of constraints are defined.

[0130] Definition 1 (Basic graph definition). An RDF graph G is a set of triples. (a, p, b) represents a triple, then a, p, b are the subject, predicate, and object of the triple respectively. Elements that usually appear in the subject or object position are called nodes, and elements that appear in the predicate position are called relations or attributes. In the present invention, we represent triples in the form of p(a, b). If N(G) and P(G) represent the node set and attribute name set in G respectively, where the attribute name set includes the set of internal attribute names and external attribute names (relationship names), then p∈P(G), a∈N(G), and P(a) represents the attribute name set of node a.

[0131] Definition 2 (Basic constraint definition). Let S = (L, def) be a SHACL pattern, where L is a finite set of shape names, def is associated with each shape name in L, and the definition is a shape constraint. The verification target of the pattern S and the graph G is a pair T = (L, tgt), where tgt associates a set of nodes in G with shape names in L. If for any shape name l in L, all nodes in tgt(l) satisfy the constraint def(l), then the graph G satisfies the pattern S with the target T. The main definitions are shown in Table 2.

[0132] Table 2 Symbol Definition

[0133]

[0134]

[0135] Based on the above basic definitions, the following six constraint model definitions will be introduced. First, in a fixed RDF graph G, this section studies the problem of global constraints to satisfy a given node sample set of G. Global constraints For any sample node set N(G), there are universal constraints that apply to the vast majority of nodes in N(G). Such constraints allow the consideration of noise in sample data, that is, constraints under a priori conditions.

[0136] Definition 3 (GBOM constraint). The complex equipment knowledge graph organizes knowledge using GBOM. In other words, all knowledge will be mounted under GBOM, that is, all knowledge should have a reachable path with GBOM. Figure 2 As shown in the figure, if the "Instance3" node is disconnected from the "Event" node, then there is no path for the "Instance3" node to be associated with GBOM, and it cannot produce practical meaning in the graph. To avoid a large amount of similar junk data in the graph, which will cause graph burden, it should be cleared. If the constraint is called l = 'GBOM_constraint', where l∈L, the corresponding def(l) expression is: satisfy:

[0137] Φ::=(p(v,a)|^p(v,a))∧(p(a,b)|^p(a,b)) * ∧(p(b,v GBOM )|^p(b,v GBOM ))

[0138] Among them, Φ is used to represent the shape expression, ::= is the Backus-Naur form, which means "definition", (p())* represents the path connecting the subject and the object through zero or more matching p(), ^p() represents the reverse path, v,a,b,v GBOM ∈N(G),v GBOM The node representing the ontology concept is a GBOM, that is, it satisfies the shape Node, type represents internal attributes: ontology concept, use Represents a shape constraint expression for a node.

[0139] Definition 4 (Chained Constraint). When the shape constraint of an entity contains another entity constraint, a chained constraint is generated. That is, if a shape l' appears in the constraint expression of a certain shape l, then to verify the shape l and its constrained node v, it is necessary to call the verification of the shape l' and its constrained node v'. That is, if def(l)←def(l')∧Φ, where l,l'∈L, Φ represents other shape expressions, then what is actually verified is S={def(l'),def(l)}.

[0140] Definition 5 (Abstract Class Entity Constraint). Abstract class entities are classification items abstracted from instance class knowledge. In the reasoning and application of knowledge graphs, they are mainly responsible for improving the efficiency of subgraph segmentation and reasoning. Therefore, they rely on the corresponding instance knowledge. That is, abstract class entities have a strong association with at least one type of instance knowledge, such as Figure 3 Its shape is shown as subClassOf represents the attribute of node v: ontology concept type, which should satisfy:

[0141]

[0142] in, Represents non,subClassOf,type∈P(G).

[0143] In complex equipment knowledge, some specific rules are not common to all nodes, and different constraints will be generated according to their own characteristics and attributes. Therefore, it is also necessary to define models for special constraints.

[0144] Definition 6 (Attribute Constraints). Attribute constraints are divided into attribute value type constraints and attribute value format constraints. Attribute constraints are generally some widely recognized consensus constraints and attribute specification constraints required by the domain. Attribute value type constraints refer to which type or types a certain attribute of an entity must be. Common attribute value types of data attributes are: string type, integer type, and time type. For example, the age of a salesperson must be an integer, so the attribute value type of the "age" attribute is integer. Attribute value format constraints specify the numeric range or string format of the attribute value, etc., and are generally used to constrain data attributes. For example, a person's age must be greater than 0 years old, so the attribute value of the salesperson's "age" attribute is greater than 0. Table 3 shows the abstract expression of simple attribute constraints using SHACL syntax.

[0145] Table 3 SHACL attribute constraint expressions

[0146]

[0147] Definition 7 (Event Entity Constraint). An event entity is similar to an intermediate table in a relational database. This entity is meaningful only when it is composed of other entities, so it has a certain atomicity. Specifically, if other entities associated with the event entity are deleted, then the corresponding event entity and its associated edges should also be deleted to maintain the integrity of the event entity. In the data model, the existence of this constraint means that there is a strong coupling relationship between the event entity and its associated entities, such as Figure 4 Therefore, when designing a data model, we must consider how to implement this atomic constraint to ensure data consistency and integrity. The event class entity constraint model is defined as follows: The nodes should satisfy:

[0148]

[0149] Where: a1, a2, ..., a nRepresents the entity nodes participating in the event, n≥2. The constraint after the last ∧ indicates that the entities participating in the event may be of Event type in addition to Instance type. Therefore, the event also contains a special constraint. When there is another event-type entity in the entity associated with the event, there is a causal relationship between the two events. That is, when the cause event disappears, the effect event should disappear together. It is represented as when nodes a and b satisfy the shape a←subClassOf.Event, b←subClassOf.Event, satisfy

[0150] Definition 8 (Rule-based constraints). In the equipment knowledge graph, in addition to the shape constraints of different entity types, there are also specific semantic (value) constraints between component design, process, and manufacturing parameter values. This type of rule-based constraint refers to the rules or conditions for specific attribute values ​​defined by experts based on domain knowledge and needs. For example, the GBOM entity is a kind of knowledge that contains hierarchical relationships. Sub-level attributes are related to parent-level attributes. For example, the bearing is related to the bearing seat: bearing clearance = bearing outer diameter - bearing seat hole diameter. For another example, there is a correlation between the force F of the fan blade and the wind speed V (unit: m / s), (specific parameter values ​​and models need to be set according to actual data and engineering requirements):

[0151]

[0152] The present invention divides rule-based constraints into two types as shown in Table 4. Different types will be distinguished in specific constraint descriptions.

[0153] Table 4 Classification of rule class constraints

[0154]

[0155] The three constraints of Definition 3, Definition 4, and Definition 5 are all constraints for all knowledge or partial knowledge in the knowledge graph. They are characterized by being constructed as universal constraints, and all knowledge in the graph can be called as self-constraints without customization. When using constraint language to describe constraints, manual construction is obviously inefficient. Therefore, the present invention provides an automatic construction algorithm for the construction of these three types of constraints, including the following steps:

[0156] Step S1: Input the ontology graph O, and obtain the ontology nodes from the graph O. Save it as the ontology list O_list.

[0157] Step S2: Traverse the ontology list and construct GBOM constraints and abstract class entity constraints.

[0158] Step S21: let i=1.

[0159] Step S22: Determine whether i is less than or equal to the length of the entity list: if yes, go to the next step, otherwise go to step 3.

[0160] Step S23: Determine whether the i-th element o of O_list satisfies That is, whether the name of the ontology o is 'GBOM', if so, the ontology calls the packaged GBOM constraint, def(l o )←def(l GBOM ), otherwise proceed directly to the next step.

[0161] Step S24: Determine whether the entity o satisfies That is, whether the ontology type of ontology o is abstract class knowledge, if so, let the ontology call the encapsulated abstract class entity constraint def(l o )←def(l o )∧def(l Abstract ), otherwise proceed directly to the next step.

[0162] Step S25: Construct the constraint def(l o ) is added to the SHACL mode S.

[0163] Step S26: Verify the target atom tgt(l o ) is added to the verification target T.

[0164] Step S27: Set i++ and go to step S22.

[0165] Step S3: traverse the shape set and construct chain constraints.

[0166] Step S31: let j=1.

[0167] Step S32: Determine whether j is less than or equal to the length of the shape set TL in the verification target: if yes, go to the next step, otherwise go to step 4.

[0168] Step S33: Determine whether the constraint def(l) of the j-th element l in TL contains another shape constraint l', and At the same time, l'∈SL, where SL represents the shape set in SHACL. If yes, then add the verification target atom tgt(l') to the verification target T. Otherwise, go to step S34.

[0169] Step S34: Let j++, go to step S32.

[0170] Step S4: Output SHACL mode S and verification target T.

[0171] In the above algorithm, the ontology graph O and graph G have similar structures, the difference lies in the different data storage. Graph O stores the node relationship information of the ontology, and graph G stores the node relationship information of the entity. GBOM , l Abstract ∈SL, all have already constructed and encapsulated constraints def(l GBOM )、def(l Abstract ). The algorithm constructs GBOM constraints, chain constraints and abstract class entity constraints for each type of ontology by parsing the ontology graph, without the need for manual construction of constraints.

[0172] The three constraints proposed in Definition 6, Definition 7, and Definition 8 can be summarized as widely recognized consensus constraints, constraints based on entity shapes, and constraints based on rule conventions. These constraints require in-depth entity information during the construction process to ensure the effectiveness and applicability of the constraints. In view of the importance and complexity of constraints, in order to improve construction efficiency, the present invention proposes a template-based semi-automatic construction method. This method aims to provide templated processes and tool support for the construction of constraints by combining professional domain knowledge and computer-aided technology, thereby reducing manual intervention to a certain extent and improving the efficiency and quality of constraint construction.

[0173] For attribute constraints, an ontology attribute dictionary is created when constructing the ontology. The dictionary includes name, type and value domain. An example is shown in Table 5. The attribute dictionary is added to the constraint construction as a reference template to achieve rapid construction of attribute constraints.

[0174] Table 5 Ontology attribute dictionary

[0175]

[0176] Event entity constraints are closely related to the shape of events in the ontology. Therefore, when constructing event entities, it is necessary to obtain ontology concepts that are strongly associated with events to provide templates for the shape constraints of event entities. Rule constraints are divided into two types according to Table 4, and templates are designed for each type. However, most rule constraints require expert customization, so rule dictionaries are constructed to assist constraint construction. In summary, the steps of the template-based semi-automatic construction algorithm are as follows:

[0177] Step S1: Input the ontology graph O, and obtain the ontology nodes from the graph O. Save it as the ontology list O_list.

[0178] Step S2: Traverse the ontology list and construct three local constraints. Let i=1.

[0179] Step S3: Determine whether i is less than or equal to the length of the entity list. If yes, go to the next step, otherwise go to step 10.

[0180] Step S4: traverse each attribute of the ith ontology o in O_list and construct attribute constraints.

[0181] Step S41: let j=1.

[0182] Step S42: Determine whether j is less than or equal to the length of the attribute set P(o) of the ontology node. If yes, go to the next step, otherwise go to step 5.

[0183] Step S43: Determine whether the jth attribute of P(o) is in the attribute dictionary set PD. If yes, let the ontology constraint def(l o ) calls the attribute type constraint, that is, def(l o )←def(l datatype ), otherwise go to step 45.

[0184] Step S44: Determine whether the "value range" corresponding to the jth attribute of P(o) in PD is empty. If yes, go to step 45, otherwise call the attribute value format constraint, i.e., def(l o )←def(l o )∧def(l range ).

[0185] Step S45: Let j++, go to step 42.

[0186] Step S5: Construct event class constraints.

[0187] Step S51: Determine whether the entity is an event type. If yes, go to the next step; otherwise, go to step 6.

[0188] Step S52: Obtain the instance class and event class ontology concepts associated with the event, and save them as E_list.

[0189] Step S53: Use E_list to construct event class entity constraint def(l Event ), the ontology constraint def(l o ) calls the event class entity constraint, that is, def(l o )←def(l o )∧def(l Event ).

[0190] Step S54: construct causal association constraints.

[0191] Step S541: traverse the ontology concept list E_list associated with the event, and set k=1.

[0192] Step S542: Determine whether k is less than or equal to the length of E_list, if yes, go to the next step, otherwise go to step 6.

[0193] Step S543: Determine whether the kth ontology concept type of E_list is an event class. If so, call the event class entity causal association constraint, i.e., def(l o )←def(l o )∧def(l causal ), otherwise go to next step.

[0194] Step S544: Let k++, go to step 542.

[0195] Step S6: Construct rule class constraints.

[0196] Step S61: Filter out the rule constraint list Ru whose “ontology concept” is the same as ontology o from the rule constraint set RC, traverse the list, and set h=1.

[0197] Step S62: Determine whether h is less than or equal to the length of Ru. If yes, go to the next step, otherwise go to step 7.

[0198] Step S63: Determine whether the “rule type” corresponding to the hth element of Ru is “condition”. If yes, go to step 64; otherwise, go to step 65.

[0199] Step S64: construct a conditional rule constraint based on the "expression" corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l condition[h] ), then go to step 66.

[0200] Step S65: construct a general class rule constraint according to the "expression" corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l rule[h] ), then go to step 66.

[0201] Step S66: Set h++ and go to step 62.

[0202] Step S7: Construct the constraint def(l o ) is added to the SHACL mode S.

[0203] Step S8: Verify the target atom tgt(l o ) is added to the verification target T.

[0204] Step S9: Let i++, go to step S3.

[0205] Step S10: Output SHACL mode S and verification target T.

[0206] In the above algorithm input, the attribute dictionary provides a template for attribute constraints, and the rule constraint set provides a template for rule class constraints. The rule constraint set consists of ontology concepts, rule types, and rule expressions. datatype , l range , l Event , l causal , l condition , l rule ∈SL, all have already constructed and encapsulated constraints def(l datatype )、def(l range )、def(l Event )、def(l causal )、def(l condition )、def(l rule ). The difference between these encapsulated constraints and the previous unified constraints is that the corresponding parameters need to be passed in to realize the constraint construction based on the template. The constraints and related parameters are shown in Table 6. The rule constraint template only supports standardized parameters. If it is a more complex expression, it can only be constructed manually. Based on all the above constraint definitions and constructions, the final constraint file is generated and enters the verification stage together with the entity graph.

[0207] Table 6 Constraint template construction parameter settings

[0208]

[0209]

[0210] The present invention defines different constraints according to knowledge characteristics. Simple constraints such as attribute constraints can be directly defined using SHACL syntax, but path constraints and complex semantic constraints such as GBOM constraints, abstract class entity constraints, event class entity constraints, and rule class constraints require the extension of SHACL syntax. Therefore, SPARQL query statements are used to fully describe the constraints. All constraints are integrated into a SHACL file, and a verification report is generated using a verification model combined with the SHACL engine. Finally, the verification report is parsed and the knowledge graph is corrected. The knowledge data verification technical route of the present invention is as follows: Figure 5 shown.

[0211] Example 2

[0212] This embodiment further elaborates on the basis of embodiment 1. The present invention discloses a method for optimizing equipment-level knowledge graphs by studying integrity constraints in knowledge graphs to improve data quality in the field of complex equipment. First, general and special constraint models are constructed using the characteristics of equipment knowledge, and then automatic and semi-automatic construction algorithms are designed respectively to verify the equipment knowledge in the knowledge graph, so as to improve the quality of knowledge graph data and improve the accuracy and efficiency of downstream services such as recommendation questions and answers.

[0213] The specific steps include:

[0214] 1. Collected and analyzed wind power equipment data from enterprise project databases, covering the design, manufacturing and operation and maintenance of wind power equipment.

[0215] 2. According to the ontology construction process, the Protégé open source tool was used to build the wind power equipment knowledge graph ontology model. 22 ontology concepts were extracted, such as EBOM, product model, parameter setting, inspection plan, faulty parts, fault events, suppliers, projects, salesmen, wind turbines, wind farms, etc. The relationship between the ontologies was analyzed and the ontology results were constructed as follows: Figure 6 shown.

[0216] 3. Use the ontology to generate data templates, clean and organize the data, and integrate them to generate RDF graph files as data sets. The data content statistics are shown in Table 7.

[0217] Table 7 Statistics of wind power equipment dataset

[0218]

[0219] 4. After the data is ready, start to construct constraints, implement the automatic construction algorithm of global constraints and the semi-automatic construction algorithm based on templates, and finally integrate them to generate a complete SHACL file. The specific steps are as follows:

[0220] Step S41: construct the GBOM constraint GBOMPathConstraint and the abstract class entity constraint AbstractConstraint.

[0221] Step S42: Obtain the ontology concept list owl_concept and the ontology attribute list owl_attribute.

[0222] Step S43: construct global constraints.

[0223] Step S431: traverse owl_concept, if the ontology concept is not "GBOM", call GBOMPathConstraint for the ontology constraint.

[0224] Step S432: If the ontology concept belongs to an abstract class, AbstractConstraint is called for the ontology constraint.

[0225] Step S433: The traversal of owl_concept ends.

[0226] Step S44: Save as a SHACL file.

[0227] Step S45: construct local constraints.

[0228] Step S451: Get the existing SHACL file.

[0229] Step S452: Get the ontology attribute dictionary owl_attribute_list. Traverse the ontology attribute list owl_attribute, locate the ontology constraints created in the SHACL file, construct and call the attribute type constraint, and if the corresponding "value range" in owl_attribute_list is not empty, construct and call the attribute value format constraint.

[0230] Step S453: The traversal of owl_attribute ends.

[0231] Step S454: Get the event ontology related ontology concept list event_rela_list, traverse the list, locate the ontology constraints created in the SHACL file, and construct and call the event class entity constraints.

[0232] Step S455: End of traversal of event_rela_list.

[0233] Step S456: Get the rule constraint set rule_list, traverse the list, locate the ontology constraint created in the SHACL file, if the corresponding "rule type" is "condition", construct and call the conditional rule constraint, otherwise construct and call the general rule constraint.

[0234] Step S457: The traversal of rule_list ends.

[0235] Step S46: Save as a SHACL file.

[0236] After the construction is completed, the generated six types of constraint statistics are shown in Table 8. Automatic construction can replace most of the manually constructed constraints, but some constraints with complex expressions cannot be accurately constructed and therefore require manual assistance. Figure 7The data of the same ontology have the same data characteristics, so a constraint is constructed for each ontology in the experiment. Some constraints are customized for a certain ontology, and some constraints are reused by different ontologies.

[0237] Table 8 Statistics of six types of constraints

[0238]

[0239] 5. Generate a report using the RDF file and SHACL constraint file generated by the wind power equipment through the verification engine. Some of the results are as follows: Figure 8 The error report information is parsed and the data violating the constraint is processed, as shown in Table 9.

[0240] Table 9 Partial processing methods for constraint verification

[0241]

[0242] GBOM is an abstract class entity and has 47 uninstantiated instance nodes. However, through previous analysis, GBOM plays an important role in the complex equipment knowledge graph. Therefore, we need complete GBOM information, which requires it to exist and allows it to temporarily exist without being instantiated. Based on this, we choose to rewrite the constraints to exclude GBOM-class knowledge from the scope of the constraint restriction. There are also 195 data types in this dataset that do not comply with the regulations, so the data needs to be modified. For violations of the constraints on the path, it is usually chosen to delete the instance node or complete the relationship. After all the erroneous data is processed, re-enter the verification engine. When the error entry is 0, the success information is obtained, and the data is imported into the graph database for storage. Some of the results are shown below. Fig. 9 As shown in the figure, all subsequent downstream services of the knowledge graph can be realized through interaction with the Neo4j graph database.

[0243] 6. In order to intuitively verify whether the constructed constraints can play the role of knowledge constraints, this paper sets up a test data set to verify the constraint effect.

[0244] Step S61: Fig.10 As shown in sub-figure a, test set 1 contains an Event type Fault entity "pitch bearing seal ring fracture", and its four associated entities are Instance type, namely FaultComponent entity "pitch bearing seal ring", FaultSource entity "daily inspection", WindFarm entity "Tianci Bay", OperationPerson entity "Hou Junheng", Instance type SBOM entity "audio and video monitoring system" associated with FaultComponent entity, and GBOM entity "unit main control system" associated with SBOM entity. This data set is a data set that meets the constraints, and the verification result is passed, such as Fig.10 As shown in sub-figure b.

[0245] Step S62: Fig.11 As shown in sub-figure a, when the association between the entity "pitch bearing seal ring fracture" and the entity "pitch bearing seal ring" is disconnected and the attribute value of its attribute fanStatus is modified to "not running", as shown in Fig.11 As shown in sub-figure b, after verification, six constraints were violated, including four GBOM constraints, one attribute constraint, and one event constraint. In the test constraints, the Fault entity attribute fanStatus is required to belong to the enumeration range: "running", "shutdown", "power limit", and "not running" exceeds this range and should be modified to "shutdown". The association between the entity "pitch bearing seal ring fracture" and the entity "pitch bearing seal ring" was deleted, which destroyed the atomicity of the event entity, so an error was reported. Test set 1 tested the GBOM constraints, attribute constraints, and event entity constraints, and achieved the expected results.

[0246] Step S63: Construct test set 2, such as Fig.12 As shown in sub-figure a, it contains two Abstract type ParaDict entities "maximum turbulence intensity Iref" and "maximum annual average wind speed", two Event type ParaSet entities "maximum turbulence intensity Iref" and "maximum annual average wind speed", one GBOM entity "unit" and two Instance type entities, namely ProductModel entity "DEW-D3200-155" and EBOM entity "unit general diagram". Test set 2 meets the constraints and the verification result is passed, as shown in Fig.12 As shown in sub-figure b.

[0247] Step S64: Fig.13 As shown in sub-figure a, when the association between the Abstract type ParaDict entity "maximum turbulence intensity Iref" and the Event type ParaSet entity "maximum turbulence intensity Iref" is disconnected and the attribute paraValue value of the ParaSet entity "maximum turbulence intensity Iref" is modified to "0.12", two constraint violation records are generated after verification, such as Fig.13As shown in sub-figure b. First, in the test constraints, it is required that when the value of "maximum annual average wind speed" is "8.5", the value of "maximum turbulence intensity Iref" should be "0.14", so "0.12" violates the rule-based constraints. Secondly, when the Abstract type ParaDict entity loses its association, the abstract class constraint is violated. In addition, in the test constraints, the GBOM constraint is included in the abstract class constraint. Therefore, the violation of the GBOM constraint is actually the effect of the chain constraint, and the two violation records will be integrated into one. In summary, through the verification of test set 2, the expected effects can be achieved in rule-based constraints, abstract class entity constraints, and chain constraints.

[0248] The above is a specific description of the implementation mode of the present invention, but the present invention is not limited to the described embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention, and these equivalents or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A method for constructing complex equipment knowledge graph constraints, characterized in that: The following steps are involved: Step S1, collect complex equipment data to construct a knowledge graph ontology, and classify the knowledge graph ontology; Step S2: Based on the knowledge graph ontology classification, define a general constraint model and a special constraint model; Step S3: construct a general constraint model using a global constraint construction method, and construct a special constraint model using a local constraint construction method; Step S4: verify the constructed general constraint model and special constraint model, and modify the complex equipment knowledge graph according to the verification results.

2. A complex equipment knowledge graph constraint construction method as claimed in claim 1, characterized in that: The knowledge graph ontology classification includes: general bill of materials GBOM, instance knowledge Instance, event knowledge Event, and abstract knowledge Abstract; Among them, the general bill of materials GBOM is a general template of assembly relationship between modules constructed based on product family characteristics, with hierarchical relationship and unique identification. GBOM provides a unified template or specification to generate different instance class knowledge; The instance-based knowledge Instance reflects the specific application scenarios and practical experience of knowledge and is the concrete embodiment of theoretical knowledge in practice. Instance-based knowledge has direct application value in knowledge management and provides practical guidance and reference for solving specific problems. The event-type knowledge Event is a derivative of instance-type knowledge and is composed of multiple instance-type knowledge. Event-type knowledge describes the process, rules and impact of specific events or phenomena, and is the result of abstraction and summary of instance-type knowledge. Through the study and analysis of event-type knowledge, we can obtain in-depth understanding and insights to guide practice and decision-making. The abstract class knowledge Abstract is the subdivision and classification of instance knowledge. It is formed by extracting and summarizing the common features of instances to understand and manage the structure and internal relationships of knowledge. Abstract class knowledge provides a deep understanding of knowledge and discovers the commonalities and laws between knowledge.

3. A complex equipment knowledge graph constraint construction method as claimed in claim 1, characterized in that: Step S2 also includes defining a basis, which includes defining a basic diagram and defining basic constraints. The definition of a general constraint model includes defining a general bill of materials (GBOM) constraint model, defining a chain constraint model, and defining an abstract class entity constraint model. The definition of a special constraint model includes defining an attribute constraint model, defining an event class entity constraint model, and defining a rule class constraint model.

4. A complex equipment knowledge graph constraint construction method as claimed in claim 3, characterized in that: The definition of the basic graph includes: an RDF graph G is a set of triples, (a, p, b) represents a triple, a, p, b are the subject, predicate, and object of the triple respectively; an element appearing in the subject or object position is called a node, and an element appearing in the predicate position is called a relationship or attribute; a triple is represented in the form of p(a, b), if N(G) and P(G) represent the node set and attribute name set in G respectively, wherein the attribute name set includes the set of internal attribute names and external attribute names, then p∈P(G), a∈N(G), and P(a) represents the attribute name set of node a; The definition of the basic constraint includes: let S = (L, def) be a SHACL pattern, where L is a finite set of shape names, def is associated with each shape name in L, and the definition is a shape constraint; the verification target of the pattern S and the graph G is a pair T = (L, tgt), where tgt associates a set of nodes in G with shape names in L; if for any shape name l in L, all nodes in tgt(l) satisfy the constraint def(l), then the graph G satisfies the pattern S with the target T; Where G represents a triple set, N represents a node set, P represents a set of attribute names, L represents a set of shape names, def represents a shape constraint associated with a shape name, and S = (L, def) represents a SHACL pattern, which can be simplified to S = {def(l1), def(l2), ..., def(l n )}, tgt represents a set of nodes associated with the shape name, T = (L, tgt) represents the verification target, which can be simplified to T = {tgt(l1), tgt(l2), ..., tgt(l n )}.

5. A complex equipment knowledge graph constraint construction method as claimed in claim 4, characterized in that: The definition of the general bill of materials GBOM constraint model includes: the complex equipment knowledge graph organizes knowledge with GBOM, all knowledge is mounted under GBOM, all knowledge has a reachable path with GBOM, and the constraint is defined as l = 'GBOM_constraint', where l∈L, and the corresponding def(l) expression is: satisfy: Φ::=(p(v,a)|^p(v,a))∧(p(a,b)|^p(a,b)) * ∧(p(b,v GBOM )|^p(b,v GBOM )) Where Φ represents a shape expression, ::= is the Backus-Naur form, which represents a definition, (p())* represents a path connecting the subject and the object through zero or more matching p(), ^p() represents the reverse path, v,a,b,v GBOM ∈N(G),v GBOM The node representing the ontology concept is a GBOM, that is, it satisfies the shape Node, type represents internal attributes, and ontology concepts use Represents the shape constraint expression of the node; The definition of the chain constraint model includes: when the shape constraint of an entity contains another entity constraint, a chain constraint is generated; if a shape l' appears in a constraint expression of a certain shape l, when verifying the shape l and its constrained node v, the verification of the shape l' and its constrained node v' is called; if def(l)←def(l')∧Φ, where l,l'∈L, Φ represents other shape expressions, then the actual thing to be verified is S={def(l'),def(l)}; The definition of the abstract class entity constraint model includes: the abstract class entity is a classification item abstracted from the instance class knowledge, which is responsible for improving the subgraph segmentation and reasoning efficiency in the reasoning and application of the knowledge graph, and depends on the corresponding instance knowledge; the abstract class entity is strongly associated with at least one type of instance knowledge, and its shape is expressed as a , subClassOf represents the attribute of node v, Abstract represents abstraction, and the ontology concept type satisfies: in, Represents non,subClassOf,type∈P(G).

6. A complex equipment knowledge graph constraint construction method as claimed in claim 5, characterized in that: The definition of the attribute constraint model includes: attribute constraints are divided into attribute value type constraints and attribute value format constraints. Attribute constraints are some widely recognized consensus constraints and attribute specification constraints required by the field. The attribute value type constraint refers to which type or types a certain attribute of an entity must be. The attribute value types of data attributes include: string type, integer type, and time type. The attribute value format constraint specifies the numeric range or string format of the attribute value, which is used to constrain data attributes. The event entity constraint model is defined as follows: the event entity is similar to the intermediate table in the relational database, and its entity is composed of other entities and has atomicity; if other entities associated with the event entity are deleted, the corresponding event entity and its associated edges are deleted together; in the data model, there is a strong coupling relationship between the event entity and other entities associated with it; when designing the data model, consider how to implement atomicity constraints; defining the event entity constraint model includes: for any entity that satisfies the shape Nodes that satisfy: Where: a1, a2, ..., a n Represents the entity node participating in the event, n≥2. The constraint after the last ∧ indicates that the entity participating in the event may be of event type in addition to instance type. Event represents the event. The event includes constraints: when there is another event class entity in the entity associated with the event, there is a causal relationship between the two events; when the cause event disappears, the effect event disappears together; it is expressed as when nodes a and b satisfy the shape a←subClassOf.Event, b←subClassOf.Event, satisfy The rule-based constraint model includes: in the complex equipment knowledge graph, there are specific semantic constraints between component design, process, and manufacturing parameter values. This type of rule-based constraint refers to the rules or conditions for specific attribute values ​​defined by experts based on domain knowledge and needs. Sub-level attributes are related to parent-level attributes. Rule-based constraints include conditional constraints and common constraints.

7. A complex equipment knowledge graph constraint construction method as claimed in claim 5, characterized in that: In the construction of the universal constraint model using the global constraint construction method, the ontology graph O and the graph G have similar structures, the difference lies in the different storage data. Graph O stores the node relationship information of the ontology, and graph G stores the node relationship information of the entity. GBOM , l Abstract ∈SL, all have already constructed and encapsulated constraints def(l GBOM )、def(l Abstract ), this construction method constructs GBOM constraints, chain constraints and abstract class entity constraints for each type of ontology by parsing the ontology graph.

8. A complex equipment knowledge graph constraint construction method as claimed in claim 7, characterized in that: The method for constructing a universal constraint model using a global constraint construction method comprises the following steps: Step A1: Input the ontology graph O, obtain the ontology nodes from the graph O, and save it as the ontology list O_list; Step A2: traverse the ontology list and construct GBOM constraints and abstract class entity constraints; Step A3: traverse the shape set and construct chain constraints; Step A4: Output SHACL pattern S and verification target T.

9. A complex equipment knowledge graph constraint construction method as claimed in claim 8, characterized in that: Step A2 includes the following steps: Step A21: let i=1; Step A22: determine whether i is less than or equal to the length of the entity list, if yes, proceed to the next step, otherwise go to step A3; Step A23: Determine whether the i-th element o of O_list satisfies That is, whether the name of the ontology o is GBOM, if so, the ontology calls the encapsulated GBOM constraint, def(l o )←def(l GBOM ), otherwise proceed directly to the next step; Step A24: Determine whether the entity o satisfies That is, whether the ontology type of ontology o is abstract class knowledge, if so, let the ontology call the encapsulated abstract class entity constraint, def(l o )←def(l o )∧def(l Abstract ), otherwise proceed directly to the next step; Step A25: Construct the constraint def(l o ) is added to the SHACL pattern S; Step A26: Verify the target atom tgt(l o ) is added to the verification target T; Step A27: Set i+1 and go to step A22.

10. A complex equipment knowledge graph constraint construction method as claimed in claim 8, characterized in that: Step A3 includes the following steps: Step A31: let j=1; Step A32: determine whether j is less than or equal to the length of the shape set TL in the verification target, if yes, proceed to the next step, otherwise go to step A4; Step A33: Determine whether the constraint def(l) of the j-th element l in TL contains another shape constraint l', and At the same time, l'∈SL, where SL represents the shape set in SHACL; if yes, add the verification target atom tgt(l') to the verification target T; otherwise, go to step A34; Step A34: Let j+1, and go to step A32.

11. A complex equipment knowledge graph constraint construction method according to claim 6, characterized in that: In the construction of a special constraint model using the construction method of local constraints, for attribute constraints, an ontology attribute dictionary is created when constructing the ontology, and the dictionary includes name, type and value range. The attribute dictionary is added to the constraint construction as a reference template; when constructing event-type entities, ontology concepts that are strongly associated with events are obtained to provide templates for shape constraints of event-type entities; rule-type constraints are designed according to two types: conditional constraints and common constraints, and the constraint construction is assisted by constructing rule dictionaries; In the construction method of the local constraint to construct the special constraint model, the attribute dictionary provides a template for the attribute constraint, and the rule constraint set provides a template for the rule class constraint; wherein the rule constraint set is composed of ontology concepts, rule types and rule expressions. datatype , l range , l Event , l causal , l condition , l rule ∈SL, all have already constructed and encapsulated constraints def(l datatype )、def(l range )、def(l Event )、def(l causal )、def(l condition )、def(l rule ), def(l datatype )、def(l range )、def(l Event )、def(l causal )、def(l condition )、def(l rule ) are attribute type constraints, attribute value format constraints, event entity constraints, event causal association constraints, conditional rule constraints, and general rule constraints.

12. A complex equipment knowledge graph constraint construction method according to claim 11, characterized in that: The method of constructing a special constraint model using a local constraint construction method comprises the following steps: Step B1: Input the ontology graph O, obtain the ontology nodes from the graph O, and save it as the ontology list O_list; Step B2: traverse the ontology list and construct three local constraints, setting i = 1; Step B3: Determine whether i is less than or equal to the length of the entity list, if yes, proceed to the next step, otherwise go to step B10; Step B4: traverse each attribute of the ith ontology o in O_list and construct attribute constraints; Step B5: construct event class constraints; Step B6: construct rule class constraints; Step B7: Construct the constraint def(l o ) is added to the SHACL pattern S; Step B8: Verify the target atom tgt(l o ) is added to the verification target T; Step B9: Set i+1 and go to step B3; Step B10: Output SHACL mode S and verification target T.

13. A complex equipment knowledge graph constraint construction method as claimed in claim 12, characterized in that: Step B4 includes the following steps: Step B41: let j=1; Step B42: Determine whether j is less than or equal to the length of the attribute set P(o) of the ontology node; if yes, proceed to the next step, otherwise go to step B5; Step B43: Determine whether the jth attribute of P(o) is in the attribute dictionary set PD; if so, set the ontology constraint def(l o ) calls the attribute type constraint, that is, def(l o )←def(l datatype ), otherwise go to step B45; Step B44: Determine whether the value range corresponding to the jth attribute of P(o) in PD is empty; if so, go to step B45, otherwise call the attribute value format constraint, i.e., def(l o )←def(l o )∧def(l range ); Step B45: Let j+1, go to step B42.

14. A complex equipment knowledge graph constraint construction method as claimed in claim 12, characterized in that: Step B5 includes the following steps: Step B51: Determine whether the entity is an event class, if yes, go to the next step, otherwise go to step B6; Step B52: Obtain the instance class and event class ontology concepts associated with the event and save them as E_list; Step B53: Use E_list to construct event class entity constraint def(l Event ), the ontology constraint def(l o ) calls the event class entity constraint, that is, def(l o )←def(l o )∧def(l Event ); Step B54: construct causal association constraints; Step B541: traverse the ontology concept list E_list associated with the event, and set k=1; Step B542: Determine whether k is less than or equal to the length of E_list, if yes, go to the next step, otherwise go to step B6; Step B543: Determine whether the kth ontology concept type of E_list is an event class; if so, call the event class entity causal association constraint, i.e., def(l o )←def(l o )∧def(l causal ), otherwise the next step; Step B544: Let k+1, go to step B542.

15. A complex equipment knowledge graph constraint construction method according to claim 12, characterized in that: Step B6 includes the following steps: Step B61: Filter out the rule constraint list Ru whose ontology concepts are the same as ontology o from the rule constraint set RC, traverse the list, and set h=1; Step B62: Determine whether h is less than or equal to the length of Ru; if yes, proceed to the next step, otherwise go to step B7; Step B63: Determine whether the rule type corresponding to the hth element of Ru is a conditional constraint, if yes, go to step B64, otherwise go to step B65; Step B64: Construct a conditional rule constraint based on the expression corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l condition[h] ), then go to step B66; Step B65: Construct a general class rule constraint based on the expression corresponding to the hth element of Ru, and let the ontology constraint call the constraint, that is, def(l o )←def(l o )∧def(l rule[h] ), then go to step B66; Step B66: Set h+1 and go to step B62.

Images