A knowledge graph construction method and system

Abstract

The present application relates to the field of big data processing, and particularly relates to a knowledge graph construction method and system. The method describes entity instances from two aspects of metadata structure and semantic concept of knowledge, and further comprises: generating metadata structure definition of an entity type based on entity instances containing the same type of characteristic information; the metadata structure definition of the entity type comprises definition of more than one attribute field and definition of a relationship; obtaining concept types corresponding to abstract semantic knowledge and concept instances under each concept type; at least part of the concept types and / or at least part of the concept instances under the concept types are extracted from characteristic information of the entity instances; obtaining more than one entity instance under each entity type and attribute values and relationship data of the entity instances from instance data based on the metadata structure definition of more than one entity type; and connecting the entity instances to corresponding concept instances.

Description

Technical Field

[0001] This invention relates to the field of big data processing, and in particular to a method and system for constructing knowledge graphs. Background Technology

[0002] Building a knowledge graph involves abstracting and modeling domain or industry knowledge, a highly complex, labor-intensive, and time-consuming process. Inappropriate structural definitions of knowledge and flawed cognitive hierarchy decompositions, particularly the coupling between knowledge metadata structure definitions and semantic concept definitions, will increase the complexity of the knowledge graph and the difficulty of subsequent operation, maintenance, and expansion.

[0003] Some embodiments in this specification propose a knowledge modeling method from a more general knowledge cognition perspective, which helps modelers quickly recognize and decompose domain-specific knowledge structures, decouples the structured definition and semantic definition of knowledge, thereby enabling agile startup of knowledge graph projects, while reducing the complexity and risk of knowledge production and subsequent graph operation and maintenance. Summary of the Invention

[0004] One embodiment of this specification provides a knowledge graph construction method that describes entity instances from two levels: the metadata structure of knowledge and the semantic concept system. The method further includes: generating a metadata structure definition for entity types based on entity instances containing the same type of feature information; the metadata structure definition for entity types includes the definition of one or more attribute fields and the definition of relationships; obtaining concept types corresponding to abstract semantic knowledge and concept instances under each concept type; wherein at least some concept types and / or at least some concept instances under concept types are extracted from the feature information of entity instances; obtaining one or more entity instances under each entity type and their attribute values ​​and relationship data from the instance data based on the metadata structure definition of one or more entity types; and connecting the entity instance edges to the corresponding concept instances.

[0005] One embodiment of this specification provides a knowledge graph construction system. The system describes entity instances from two levels: the metadata structure of knowledge and the semantic concept system. It includes: a generation module for generating metadata structure definitions for entity types based on entity instances containing the same type of feature information; the metadata structure definitions for entity types include definitions of one or more attribute fields and definitions of relationships; a first acquisition module for acquiring concept types corresponding to abstract semantic knowledge and concept instances under each concept type; wherein at least some concept types and / or at least some concept instances under concept types are extracted from feature information of entity instances; a second acquisition module for acquiring one or more entity instances under each entity type, along with their attribute values ​​and relationship data, from instance data based on the metadata structure definitions of one or more entity types; and an edge-connecting module for connecting entity instances to corresponding concept instances.

[0006] One embodiment of this specification provides a knowledge graph construction apparatus, including a processor and a storage medium. The storage medium is used to store computer instructions, and the processor is used to execute at least a portion of the computer instructions to implement the knowledge graph construction method described above.

[0007] One embodiment of this specification provides a computer-readable storage medium for storing computer instructions that, when at least a portion of the computer instructions are executed by a processor, enable the implementation of the knowledge graph construction method described above. Attached Figure Description

[0008] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0009] Figure 1 These are exemplary schematic diagrams of knowledge graphs according to some embodiments of this specification;

[0010] Figure 2 This is an exemplary flowchart of a knowledge graph construction method according to some embodiments of this specification;

[0011] Figure 3 This is a schematic diagram of a concept tree illustrating some embodiments of this specification;

[0012] Figure 4 These are exemplary schematic diagrams of edge-connected entity instances and conceptual instances shown according to some embodiments of this specification;

[0013] Figure 5 This is an exemplary schematic diagram illustrating the integration of a general common-sense concept system and a proprietary domain concept system according to some embodiments of this specification;

[0014] Figure 6 This is an exemplary block diagram of a knowledge graph construction system shown in some embodiments of this specification;

[0015] Figure 7 This is an exemplary schematic diagram of a modeling framework shown according to some embodiments of this specification. Detailed Implementation

[0016] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0017] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0018] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0019] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0020] Knowledge graphs, also known as graphs, data graphs, or graph data, are widely used in fields such as physics, chemistry, biology, medicine, transportation, communication, and the internet. Nodes in a graph represent entities. Nodes can be of various types, called node types, used to indicate different types of entities. Entities can refer to objectively existing things in the real world, and can further include users, merchants, accounts, cities, drugs, companies, devices, etc. Edges in a graph represent relationships between entities. Edges can also be of various types, called edge types, used to represent relationships between different types of entities. For example, Zhang San and Li Si are "friends," and social media accounts and mobile terminals have a login relationship. For ease of description, nodes representing "XX" entities can be simply called "XX nodes," and edges representing "XX" relationships can be simply called "XX edges." Entities and nodes, relationships and edges can be used interchangeably without causing ambiguity. Knowledge graphs construct semantic network graphs through nodes and edges, which conforms to the knowledge logic in most scenarios. Therefore, they are often used in big data scenarios for knowledge modeling to intuitively and concisely represent knowledge information.

[0021] A knowledge graph corresponds to a schema (also known as metadata structure definition, or a structured representation specification of knowledge). The schema of a knowledge graph refers to the data that defines the nodes and edges included in the knowledge graph. The schema guides the collection of data instances and the construction of the graph based on these instances, resulting in a knowledge graph (also known as an instance graph).

[0022] Knowledge graphs contain specific knowledge data (such as node instance data, or entity node instances, and edge instance data). Each piece of knowledge can be represented as a triple, which contains two nodes and their relationship. For example, in a social network graph, there can be entities like "people," such as Zhang San and Li Si, or entities like "companies," such as Company A and Company B. The relationship between people can be "friends" or "colleagues," and the relationship between people and companies can be "currently employed" or "formerly employed." Relationships / edges can be directional; for example, the "friend" relationship can be bidirectional, while the "currently employed" or "formerly employed" relationship can be unidirectional.

[0023] Figure 1 These are exemplary schematic diagrams of knowledge graphs according to some embodiments of this specification. For example... Figure 1 As shown, the knowledge graph includes nodes representing entities Zhang San, Li Si, Convenience Store 1, and Convenience Store 2. Zhang San and Li Si are instance data under the user entity, while Convenience Store 1 and Convenience Store 2 are instance data under the merchant entity. The graph clearly shows that Zhang San and Li Si are friends, both Zhang San and Li Si have made purchases at Convenience Store 1, Zhang San made purchases at Convenience Store 2, and the specific amounts spent.

[0024] The above are just examples. In practical applications, knowledge graphs involve hundreds of millions of data points. Highly abstracting and modeling domain or industry knowledge is a very complex and time-consuming process. For example, unreasonable definitions of knowledge representation structures or incorrect cognitive hierarchy decompositions will increase the complexity of knowledge graph construction and the difficulty of subsequent operation, maintenance, and expansion.

[0025] Currently, some related technologies employ ontology modeling representation for knowledge modeling. Ontology modeling representation methods define the characteristic attributes of instances of each entity type, standardize their structural representation, and define the semantic constraints and logical definitions of relationships and attributes. This method is based on "ontology," requiring the definition of a schema for each entity type, which leads to schema type explosion. For example, for mobile phone products and clothing products, the current business scenario only requires the attribute fields of name and price, and the only relationship needed is the association with the brand entity. However, when performing knowledge modeling based on ontology modeling representation, it is still necessary to define schemas for two entity types: mobile phone products and clothing products. When a new product is introduced, the ontology modeling representation needs to add a new schema for it again. This easily leads to schema explosion, increasing the complexity of knowledge graph construction and expansion.

[0026] To address the aforementioned issues, this specification proposes a knowledge graph construction method in some embodiments. This method describes entity instances from two levels: the metadata structure of knowledge and semantic conceptual knowledge. It aims to classify entity types from the perspective of structural data, while simultaneously promoting the accumulation of domain-specific knowledge and domain-independent semantic common sense. This helps modelers quickly understand and deconstruct domain-specific knowledge structures, thereby enabling agile startup of knowledge graph projects, ensuring the scalability of the graph, and reducing the complexity and risks of knowledge production and graph maintenance.

[0027] Figure 2 This is an exemplary flowchart illustrating a knowledge graph construction method according to some embodiments of this specification. In some embodiments, Figure 2The illustrated process can be executed by a processing device, and further implemented by a system 600 deployed on the processing device. In some embodiments, the processing device may belong to a knowledge graph platform, which provides knowledge graph services to users, such as standardizing data (units of measurement or format), fusing data from multiple businesses, constructing knowledge graphs, and providing knowledge graph query services. Users can access the knowledge graph platform through a client and request knowledge graph services. In still other embodiments, the processing device may belong to a proprietary business platform, which is only responsible for knowledge modeling of data generated for its own business domain. Exemplary business platforms may be e-commerce platforms, logistics platforms, online and offline transportation platforms, etc.

[0028] Step 202: Generate a metadata structure definition (or schema) for the entity type based on entity instances containing the same type of characteristic information. In some embodiments, step 202 may be performed by the generation module 610.

[0029] Some embodiments in this specification classify entity types from the perspective of entity data structure, grouping instances with the same data structure into one entity type. Having the same data structure means having the same type of feature information. In some embodiments, feature information may include the entity's own attribute information, as well as the entity's behavioral information and its associations with other entities. For example, Zhang San and Li Si both have attribute information such as age and gender, and relationship information such as kinship, friendship, and employment. Therefore, Zhang San and Li Si can be classified as the same entity type, such as the user entity type. Similarly, for the two product categories of mobile phones and clothing, the current modeling scenario only requires the attribute fields of name and price, and the only relationship needed is the association with the brand entity. Therefore, some embodiments in this specification consider these two types of entities to have the same type of feature information / the same data structure, and thus belong to the same entity type.

[0030] The metadata structure definition of an entity type is used to define a class of instance data with the same data structure, which can be part of a knowledge graph schema. In some embodiments, the metadata structure definition of an entity type may include definition data for more than one attribute field and definition data for relationships. The definition data for attribute fields is used to describe the attributes of the entity type, and may further include attribute field names and value types. Taking the "User" entity type as an example, its attribute field definition data defines that it may include attribute field names such as name, age, and gender, and the value types can be string, int, and char, respectively. As another example, the attribute fields of the "Product" entity type may include name and price, and the value types can be string and float, respectively. The definition data for relationships is used to describe the relationships between entities. For example, the relationship definition data for the "User" entity type may define that this entity type can have friend relationships (edges), colleague relationships, and employment relationships. The relationship definition data may further constrain that the tail node of friend relationships and colleague relationships should be an entity instance of the "User" entity type, and the tail node of employment relationships should be an entity instance under the "Merchant" or "Enterprise" entity type. The metadata structure definition for the "Product" entity type allows you to define whether this entity type can have an association with a brand entity.

[0031] In some embodiments, the step of generating the metadata structure definition for entity types can be implemented based on meta-meta-concept data.

[0032] Meta-meta-conceptual data can serve as a specification for the syntax structure and schema definition of a knowledge graph modeling platform or modeling representation framework language, guiding schema generation during knowledge graph construction. Specifically, meta-meta-conceptual data can be embodied in the knowledge modeling syntax rules that must be followed when defining the metadata structure of entity types; that is, according to the specification, field constraints are added to each entity type and its attributes and relationships. For example, meta-meta-conceptual data can require that, when generating metadata structure definitions, the described knowledge be abstracted into "entity types," which can have an inheritance structure of isA; each entity type needs descriptions and constraints regarding attribute characteristics and relational characteristics; and entity types can be instantiated into "entity instances."

[0033] In some embodiments, the meta-meta-conceptual data can be represented as meta-classes (types) in computer programming languages, and the metadata structure definition of entity types can be regarded as meta-conceptual data, which can be represented as classes (classes) in computer programming languages. A meta-class is a class whose instances are classes; essentially, a meta-class is also a class, which can be used to create classes. Classes can be used to support the production and management of instance data. Instances of classes are objects; correspondingly, entity instances under an entity type are represented as objects (objects) in computer programming languages. By mapping information at different levels in knowledge modeling to object-oriented computer programming languages, knowledge modeling can be efficiently achieved with the help of computer programming languages.

[0034] In some embodiments, the meta-meta-concept data specifies that entity types can have an inheritance structure. Therefore, during the construction of the knowledge graph, the metadata structure definition of the entity type can also be inherited (such as class inheritance) to obtain the metadata structure definition of its sub-entity types.

[0035] Inheritance can add new attribute field definitions and / or edge definitions to the metadata structure definition of the parent entity type to obtain the metadata structure definition of the child entity type. For example, as the instance data under the "User" entity type increases, a special type of user appears. This user is a user of a certain payment platform. In addition to the attribute data and relation data defined by the "User" entity type, this type of user also has a payment account unique to the payment platform. This type of user needs to be given extra attention. Therefore, a new entity type can be created for this type of user. It can inherit the metadata structure definition of the "User" entity type. In addition, its metadata structure definition also includes a new attribute field: the payment account in the payment platform.

[0036] Some embodiments in this specification classify entity types based on instance data structures. Entity types of the same type have the same schema, which effectively reduces the number of schema types in the knowledge graph construction. When it is necessary to establish more granular entity types, new entity type schemas can be derived from existing instance type schemas based on inheritance, effectively reducing the complexity of knowledge graph construction and expansion.

[0037] Step 204: Obtain the concept types corresponding to abstract semantic knowledge and the concept instances under each concept type. In some embodiments, step 204 may be performed by the first acquisition module 620.

[0038] A concept is knowledge obtained by abstracting and generalizing the common essential characteristics of perceived things during the cognitive process. It reflects the general and essential features of objective things. Examples include gender, administrative divisions (such as provinces, cities, districts, etc.), and cuisines (such as Sichuan cuisine, Western cuisine, etc.) obtained by summarizing and generalizing dishes.

[0039] In knowledge modeling, a concept can be understood as a set of instances with the same characteristics or a set of instances sharing common characteristics; it is a semantic generalization and extension of a specific "entity type." The difference between a concept and an entity type lies in the fact that an entity type defines the attributes and / or relationships of an entity. It can be considered that the same metadata structure in the data structure of knowledge representation corresponds to an entity type, such as the schemas for "user" and "product" in the example above. A concept, on the other hand, embodies a cognitive abstraction of "the same class," describing shared semantics. For example, under the category of "product," there are mobile phone products and clothing products.

[0040] Abstract semantic knowledge, also known as conceptual knowledge, can be generalized from existing entity knowledge. For example, abstract knowledge can originate from generally accepted knowledge of the common essential characteristics of certain things, or it can be obtained by those constructing knowledge graphs through induction from business data, such as the induction of disease classifications in the medical field. In some embodiments, at least some concept types and / or at least some concept instances under a concept type are extracted from the feature information of entity instances.

[0041] The abstract knowledge obtained through generalization can include concept types and their concept instances. In some embodiments, a concept type can be a further abstraction of a concept, such as "brand," "category," or "administrative division." The specific knowledge corresponding to the concept type is the concept instance. For example, concept instances of the concept type "brand" can include "KFC" or "Pepsi." Similarly, concept instances of the concept type "mobile phone product" can include "Apple phone" or "smartphone," and concept instances of the concept type "clothing product" can include "suit" or "shirt." In some embodiments, a concept type can also include attributes, such as the concept creation time and the standard library it belongs to. Taking "brand" as an example, its concept instance "KFC" can further have a concept creation time of April 5, 2022, and a standard library belonging to the brand library.

[0042] In some embodiments, multiple concept instances under the same concept type can have a hierarchical relationship. For example, the two concept instances "Sichuan" and "Chengdu" under the concept type "administrative division" have a province-city hierarchical relationship, and the three concept instances "Chinese cuisine," "Sichuan cuisine," and "hot pot" under the concept type "cuisine" have a first-level, second-level, and third-level hierarchical relationship. Therefore, in some embodiments, the attributes of a concept type can also include hierarchical relationships or a parent category (SubCategoryOf). For example, the concept instance "Sichuan cuisine" has a parent category "Chinese cuisine," and the concept instance "hot pot" has a parent category "Sichuan cuisine." The hierarchical relationship is similar to a tree structure; therefore, a "concept tree" can be built based on concept instances under the same concept type.

[0043] Figure 3 This is a schematic diagram of a concept tree illustrating some embodiments of this specification. For example... Figure 3 As shown, the concept tree, represented in a top-down manner, includes the concept type "cuisine." This concept type can further include attribute types such as concept creation time, belonging to the standard library, and belonging to a parent category (not shown in the figure). Based on the concept tree, we can see that this concept type includes concept instances such as "hot pot," "Hunan cuisine," "Sichuan cuisine," "Western cuisine," and "Chinese cuisine." The hierarchical relationship between concept instances is represented by the "subcategory" edges (solid lines) in the figure. Other attribute values ​​of concept instances are not shown in the figure. It can be seen that concept types and concept instances themselves contain a large amount of knowledge content, such as the hierarchy of the aforementioned cuisines and the inherent lower-level concept instances of each level (e.g., hot pot belongs to Sichuan cuisine). Concept instances can exist as nodes in a knowledge graph, or concept node instances. When constructing different knowledge graphs, entity node instances in the graph can all be connected to these concept node instances. Through the hierarchical relationship between concept node instances, knowledge reuse and semantic expansion can be easily achieved, improving the efficiency of knowledge construction.

[0044] In some embodiments, a concept type can also be viewed as a concept instance that serves as the root node in a concept tree.

[0045] In some embodiments, meta-meta-concept data can guide the construction of a semantic concept system. Specifically, it can specify that the knowledge graph contains conceptual knowledge, which can further include concept types and concept instances. Concept instances can have hierarchical relationships, and concept instances under different types can also be semantically attached. Therefore, the steps of generating concept types and concept instances under each concept type can also be implemented based on meta-meta-concept data. In some embodiments, concept types and concept instances can be represented as objects in computer programming languages ​​that define the values ​​of individual fields.

[0046] Figure 7These are exemplary schematic diagrams illustrating a modeling framework according to some embodiments of this specification. Figure 7 As shown, in some embodiments of this specification, the cognitive levels of knowledge are divided into a four-layer hierarchical system of concept-concept-instance. This system enables top-down knowledge cognitive modeling, as well as knowledge construction combining top-down and bottom-up approaches. Furthermore, based on this hierarchical division of knowledge cognition, some embodiments of this specification also provide middleware and data storage solutions for convenient knowledge modeling and management. The middleware can be object-oriented language middleware, where meta-meta-concepts are represented by `type`, meta-concepts by `class`, concepts by `object`, and instances by `object`. In the data storage solution, i.e., the data layer, meta-meta-concepts are represented by `Meta-schema`, reflecting modeling specifications and cross-domain standards; meta-concepts are represented by `schema`, reflecting knowledge production paradigms and knowledge storage structures; concepts are represented by a `record`, reflecting the cognitive concept system and common-sense semantic connections; and instances are represented by a `record`, reflecting instance representation and factual connections.

[0047] Step 206: Based on the metadata structure definition of more than one entity type, obtain more than one entity instance, its attribute values, and relationship data under each entity type from the instance data. In some embodiments, step 206 can be performed by the second acquisition module 630.

[0048] Instance data is defined relative to the metadata structure. For example, for a node of the natural person type, its instance data could be "Zhang San" or "Li Si". Instance data can be business data from the business domain, and its content is rich and its organization format is flexible. For example, instance data could be several purchase records, transfer records, or browsing history of different users, etc.

[0049] As mentioned earlier, the metadata structure definition can guide the construction of a knowledge graph. Specifically, the processing device can retrieve one or more entity instances, their attribute values, and relationship data for each entity type from the instance data based on the entity type's metadata structure definition. The attribute fields in the metadata structure definition determine which instance data to retrieve as entity node instances in the knowledge graph, and the relationship definition data determines whether there is an edge between two entity node instances.

[0050] In some embodiments, a graph operator can also be determined. The graph operator is configured to find entity instances and determine the relationships between entity instances from a large amount of instance data based on the definition data of attribute fields or the definition data of relationships. The graph operator can also be understood as a graph computing algorithm or method, which is used for data processing operations or calculations for graph construction. It can be implemented in various ways such as data processing / computing units, program codes, and machine learning models. In some embodiments, for operator input data, the operator can perform corresponding data processing / computation, complete data conversion, and output the converted data. In some embodiments, the graph operator can be regarded as an algorithm or method based on the metadata structure definition of the knowledge graph (including entity definition and relationship description), and can also be regarded as a part of the metadata structure definition of the knowledge graph. According to different data processing functions, graph operators can be further divided into normalization operators, linking operators, etc.

[0051] A normalization operator is used to perform data normalization on the attribute data of node instances and / or edge instances. For example, different currencies (such as US dollars and RMB) can be normalized into the same currency (such as RMB) after conversion. For another example, expression normalization processing is performed on the attribute values of attribute fields obtained from business data. For example, the normalization operator can unify the data format of the attribute value of the phone number attribute into a 13-digit digital format, or can standardize non-standard expressions such as "KFC", "Ken De Ji" and uniformly express them as "Kentucky Fried Chicken". In some embodiments, the normalization operator can input attribute values of entities or edges, and output normalized attribute expressions.

[0052] A linking operator can establish a relationship description for two corresponding node instances based on the attribute data of the two node instances. For example, the node "Zhang San" has a preference attribute "hot pot", and the store node "Wang Wu Old Hot Pot" has a business scope attribute "hot pot", the linking operator can establish an edge for two instance nodes with similar or identical attribute data, and the edge can be a "recommendation relationship".

[0053] In some other embodiments, according to specific usage scenarios, other graph operators can also be used to process the attributes of entity node instances, such as fusion operators, extraction operators, etc.

[0054] Through the metadata structure definition of entity types and the graph operators, corresponding entity instances as well as their attribute values and relationship data can be automatically determined from a large amount of instance data.

[0055] Step 208: Connecting edges of entity instances to corresponding concept instances. In some embodiments, step 208 can be executed by edge connecting module 640.

[0056] In some embodiments, edge connections can be established based on graph operators. Specifically, the chain pointer operator (or mounting operator) can still be used to process the attribute values ​​of entity instance nodes and concept instance nodes to predict whether an entity node instance can be connected to a concept node instance. In some embodiments, the semantic similarity between the attribute values ​​of entity instance nodes and concept instance nodes can be calculated using the chain pointer operator. When the semantic similarity is greater than a set threshold, an edge connection can be established between the two.

[0057] See Figure 4 , Figure 4 This is an exemplary schematic diagram illustrating the connection between entity instances and concept instances according to some embodiments of this specification. Above the horizontal line in the diagram are entity nodes in the knowledge graph, and below the horizontal line are concept nodes, including the concept type "catering," and concept instances including "Western food" and "hamburger." The attributes of the entity instance node "KFC" can include "business hours," "catering type," and "products sold." Its attribute values ​​include "9:00-22:00," "Western food," and "hamburger, cola, fried chicken." Based on the attribute values, it can be determined that the entity instance "KFC" is related to the concept instance "hamburger," and thus the "KFC" entity instance is connected to the "hamburger" concept instance. Furthermore, through the "concept tree," it can be further determined that "KFC" belongs to the Western food category under catering, thereby achieving knowledge reuse and semantic expansion.

[0058] In some embodiments of this specification, entity types and conceptual knowledge are decoupled during the construction of the knowledge graph. The metadata structure definition of entity types focuses on defining the data structure that characterizes knowledge attributes and relational features, while the "concept system" is used to model the semantic concepts of cross-domain common sense or domain-specific knowledge. Entity instances under an entity type can be attached to corresponding concept instances to represent a specific semantic information, while simultaneously simplifying the attribute definitions in the entity type metadata structure definition. For example, an entity instance under the "merchant" entity type can be attached to the "Xihu District" concept instance based on the address attribute, and then, through the hierarchical relationship of concept instances, such as "Xihu District" – "Hangzhou City" – "Zhejiang Province," its further refined administrative division semantics can be represented.

[0059] In some embodiments, the processing device may obtain the concept types and concept instances of the corresponding general common sense and the concept types and concept instances of the corresponding domain-specific knowledge by summarizing the cross-domain general common sense and domain-specific knowledge respectively.

[0060] The generalization of cross-domain common sense can be based on sources such as encyclopedias and knowledge bases, collecting general knowledge data and refining it into a common sense concept system, which can cover the cognitive concept definitions involved in general knowledge. The generalization of domain-specific knowledge can be carried out by staff in each business area regarding their domain-specific knowledge.

[0061] In some embodiments, the processing device may also establish edges between concept instances of a concept type corresponding to general common sense and concept instances of a concept type corresponding to a domain-specific concept type, wherein the edges may reflect semantic relationships including hierarchical relationships or equivalence relationships.

[0062] Compared to cross-domain general knowledge, domain-specific knowledge possesses domain-specific semantics and is often a hierarchical category with consensus or established within a specific domain. To break down semantic barriers between domain concepts, after generalizing domain concepts based on domain-specific knowledge, these domain concepts can be linked to existing common-sense concepts. Linking involves establishing edges, or associations, between concept instances under common-sense concept types and concept instances under corresponding domain-specific concept types.

[0063] The methods of association can include concept alignment and hypernym prediction. Concept alignment refers to using a recall and similarity matching method for each domain concept to find the most similar common-sense concept on the common-sense concept tree, and then using a binary classification discriminant model to decide whether a same-as alignment relationship (or equivalence relationship) can be established between them. As an example, the concept "potato" in cross-domain general knowledge and the concept "potato" in domain-specific knowledge actually refer to the same concept, so a same-as alignment relationship can be established between them. Hypernym prediction refers to using a cue-based concept prediction method for domain concepts that cannot be directly aligned, to find the hypernym of the domain concept on the common-sense concept tree, and establish an association between the two, which is an "isA" relationship (or hypernym / hypernym relationship). For example, when the domain-specific knowledge "swine fever" cannot find a directly aligned common-sense concept in cross-domain general knowledge, the cue-based concept prediction method discovers that "swine fever" belongs to infectious diseases, and the common-sense concept of "infectious disease" exists, so an isA type association can be established between "swine fever" and "infectious disease". By establishing conceptual connections between domain-specific knowledge and cross-domain common sense, semantic barriers between concepts across different domains can be broken down, allowing any domain concept to find its superordinate concept on a "common sense concept tree." A top-down conceptual system based on common sense cognition unifies the semantic description of cross-domain knowledge, overcoming the difficulties in aligning attributes and category features caused by semantic differences in instance classification across different domains, thus aiding in the knowledge fusion of cross-domain graphs. In some embodiments, the mounting method can also be the prediction of other predicate relations, not limited to the alignment and superordinate word prediction mentioned above.

[0064] In some embodiments, since common sense concepts and domain concepts are fewer in number than instance data and their scale is relatively limited, and the construction of the concept layer has high requirements for the accuracy of its semantic hierarchy division, the alignment and mounting results predicted by the algorithm can be confirmed by a manual quality inspection process or corresponding quality inspection process standards can be formulated.

[0065] Linking general common-sense concepts with domain-specific concepts makes it easier for users to build or expand knowledge graphs later. For example, suppose a company defines a set of concepts based on its internal business system. Later, it wants to introduce knowledge from other domains, but because the definitions of concepts in other domains differ from those in its internal business system, it becomes difficult to introduce knowledge from other domains due to misunderstanding. The method disclosed in the embodiments of this specification, by linking general common-sense knowledge with domain-specific knowledge, can quickly find the parent concepts of the concepts in the internal concept system within the general common-sense concepts through the relationship between the two. This helps external personnel quickly understand the internal business system and facilitates knowledge integration.

[0066] Figure 5 This is an exemplary schematic diagram illustrating the mounting of a general common-sense concept system and a domain-specific knowledge concept system according to some embodiments of this specification. For example... Figure 5 As shown, the general common sense concept system can include concept types such as "items," "vocabulary terms," ​​and "administrative divisions." These concept types have corresponding concept instances such as "3C digital products," "mobile phone," "verb," ​​and "Shanghai," which will not be listed here. The domain knowledge concept system can include concept types such as "intent concepts" and "financial concepts." These concept types have corresponding concept instances such as "purchase intent," "buying a mobile phone," and "sector concept." By mounting these concepts, associations can be established between concept instances in the domain knowledge concept system and those in the general common sense concept system. For example, "renting a mobile phone" in the domain knowledge concept system has a predicate relationship of "behavioral object" with "mobile phone" in the general common sense concept system, and a predicate relationship of "functional verb" with the verb "rent" in the general common sense concept system. As can be seen from the diagram, by mounting and integrating the domain knowledge concept system and the general common sense concept system, the interpretation and transfer of domain-specific knowledge concept systems can be achieved quickly and conveniently, thereby reducing the cost of understanding. For example, the concept of "renting a mobile phone" can be quickly interpreted as belonging to the functional verb "rent," and the behavioral object is "mobile phone."

[0067] Some embodiments of this specification also provide a knowledge graph construction apparatus, including a processor and a storage medium, wherein the storage medium stores computer instructions, and the processor processes the computer instructions to implement the method described in process 200.

[0068] Some embodiments of this specification also provide a storage medium for storing computer instructions that, when executed by a processor, can implement the method described in process 200.

[0069] Figure 6 This is an exemplary module diagram of a knowledge graph construction system according to some embodiments of this specification. The knowledge graph construction system 600 can be used to describe entity instances from two levels: the metadata structure of knowledge and the semantic concept system. For example... Figure 6 As shown, the knowledge graph construction system 600 may include a generation module 610, a first acquisition module 620, a second acquisition module 630, and an edge connection module 640.

[0070] The generation module 610 can generate a metadata structure definition for an entity type based on entity instances containing the same type of feature information; the metadata structure definition for the entity type includes the definition of one or more attribute fields and the definition of relationships. In some embodiments, the generation module 610 is also used to inherit the metadata structure definition of an entity type to obtain the metadata structure definition of its sub-entity types.

[0071] The first acquisition module 620 can be used to acquire concept types corresponding to abstract semantic knowledge and concept instances under each concept type; wherein at least some concept types and / or at least some concept instances under concept types are extracted from feature information of entity instances.

[0072] The second acquisition module 630 can be used to obtain one or more entity instances, their attribute values, and relationship data under each entity type from the instance data based on the metadata structure definition of one or more entity types.

[0073] The edge-connect module 640 can be used to connect entity instances to corresponding concept instances.

[0074] For more detailed explanations of the modules involved in the above system, please refer to the relevant processes, such as the detailed description in process 200, which will not be repeated here.

[0075] It should be understood that Figure 6The systems and modules shown can be implemented in various ways. For example, in some embodiments, the systems and modules can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods and systems described above can be implemented using computer-executable instructions and / or included in processor control code, for example, on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The systems and modules of this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., but also by software, for example, executed by various types of processors, or by a combination of the aforementioned hardware circuits and software (e.g., firmware).

[0076] It should be noted that the above description of the system and its modules is for convenience only and should not be construed as limiting this specification to the scope of the illustrated embodiments. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the modules or construct subsystems connected to other modules without departing from these principles.

[0077] The beneficial effects that the embodiments of this specification may bring include, but are not limited to: (1) decoupling "entity type" and "concept" in terms of definition simplifies the complexity of knowledge sorting in the knowledge graph construction process and promotes knowledge reuse; (2) proposing the concept system of "common sense concept tree" unifies the semantic description of cross-domain knowledge; (3) solidifying the norms that need to be followed in the construction of knowledge graphs through meta-meta-concept data can efficiently help modelers quickly recognize and decompose relevant knowledge structures, thereby realizing the agile start of knowledge graph projects.

[0078] It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects may be any one or a combination of the above, or any other possible beneficial effects.

[0079] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0080] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0081] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0082] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0083] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0084] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A knowledge graph construction method that describes entity instances from two levels: the metadata structure of knowledge and the semantic concept system, further comprising: Metadata structure definitions for entity types are generated based on entity instances containing the same type of characteristic information; the metadata structure definition for an entity type includes the definition of one or more attribute fields and the definition of relationships; wherein, the entity types include users, merchants, accounts, cities, drugs, companies, brands, categories, administrative regions, and devices; the relationships are used to represent the relationships between various types of entities; Obtain the concept types corresponding to abstract semantic knowledge and the concept instances under each concept type; wherein at least some concept types and / or at least some concept instances under concept types are extracted from the feature information of entity instances; Based on the metadata structure definition of more than one entity type, retrieve more than one entity instance, its attribute values, and relationship data under each entity type from the instance data; Connect entity instances to their corresponding concept instances.

2. The method of claim 1, further comprising: Inherit the metadata structure definition of an entity type to obtain the metadata structure definition of its child entity types.

3. As described in claim 1, multiple concept instances under the same concept type have a hierarchical relationship.

4. The method of claim 3, further comprising: An edge is established between a concept instance of a general common sense concept type and a concept instance of a domain-specific concept type, and the edge reflects semantic relationships including hierarchical relationships or equivalence relationships.

5. The method as described in claim 1, wherein the steps of generating the metadata structure definition of entity types and concept types and concept instances under each concept type are implemented based on meta-meta-concept data; the meta-meta-concept data is used to guide the generation of metadata structure definitions and the construction of semantic concept systems during knowledge graph construction.

6. The method as described in claim 5, wherein the meta-meta-concept data is represented as a metaclass in a computer programming language, the metadata structure definition of the entity type is represented as a class in a computer programming language, the concept type and its concept instance are respectively represented as objects in a computer programming language, and the entity instance under the entity type is represented as an object in a computer programming language.

7. A knowledge graph construction system, the system being used to describe entity instances from two levels: the metadata structure of knowledge and the semantic concept system, comprising: The generation module is used to generate metadata structure definitions for entity types based on entity instances containing the same type of feature information. The metadata structure definition of the entity type includes the definition of one or more attribute fields and the definition of relationships. The entity types include users, merchants, accounts, cities, drugs, companies, brands, categories, administrative regions, and devices. The relationships are used to represent the relationships between various entities. The first acquisition module is used to acquire concept types corresponding to abstract semantic knowledge and concept instances under each concept type; wherein, at least some concept types and / or at least some concept instances under concept types are extracted from feature information of entity instances; The second acquisition module is used to obtain one or more entity instances, their attribute values, and relationship data under each entity type from the instance data based on the metadata structure definition of one or more entity types. The edge-connect module is used to connect entity instances to their corresponding concept instances.

8. The system of claim 7, wherein the generation module is further configured to: Inherit the metadata structure definition of an entity type to obtain the metadata structure definition of its child entity types.

9. A knowledge graph construction apparatus, comprising a processor and a storage medium, the storage medium being used to store computer instructions, the processor being used to execute at least a portion of the computer instructions to implement the knowledge graph construction method as described in any one of claims 1 to 6.

10. A computer-readable storage medium for storing computer instructions that, when at least a portion of the computer instructions are executed by a processor, enable the knowledge graph construction method as described in any one of claims 1 to 6.

Images