Local knowledge graph and use thereof

Abstract

The present disclosure provides techniques and solutions for linking elements of different knowledge graphs and for using such links during knowledge graph processing. When creating an element of a knowledge graph, such as a class, an attribute, or a class instance, it may be determined whether a corresponding element exists in another knowledge graph. If so, the elements may be operably linked. When executing a query for a knowledge graph, if an element is linked to an element of another knowledge graph, the other knowledge graph may be accessed for query processing. When a statement is made with respect to a knowledge graph element defined in a first knowledge graph element and the element is defined with respect to an element of a second knowledge graph, a range of the statement may be limited to the second knowledge graph.

Description

Technical Field

[0001] This disclosure generally relates to establishing relationships between elements of a knowledge graph. Specific implementations involve mapping elements of a local knowledge graph to elements of a source knowledge graph, which can be a core knowledge graph or another local knowledge graph. Background Technology

[0002] In contemporary data management and analytics, knowledge graphs provide a fundamental framework for organizing, representing, and utilizing structured knowledge from diverse data sources. Knowledge graphs encode information in a graph-based format, featuring nodes representing entities and edges representing relationships between these entities. This structure facilitates the synthesis and exploration of interconnected data, thereby enabling advanced data analytics, natural language processing (NLP), and artificial intelligence (AI) applications.

[0003] Ontologies can be used as schemas to define domain-specific concepts and relationships in a knowledge graph. Essentially, an ontology provides a formal representation of domain knowledge, capturing hierarchical classifications (classes) and semantic relationships (attributes) between entities. Through ontology, knowledge graphs gain semantic richness and consistency, enabling more precise querying and reasoning about interconnected data. Statements about concepts, whether they are classes or instances, can be expressed, for example, using RDF triples. RDF triples are formed as subject-predicate-object triples, where the subject represents an entity or instance, the predicate represents a relation or attribute, and the object represents another entity or literal value.

[0004] The integration of ontology and knowledge graph enhances their expressiveness and interoperability across technological fields. For example, in the context of semantic web applications, an ontology defining concepts related to e-commerce can be used as a schema for structuring product information within a knowledge graph. By representing products as instances of classes defined in the ontology and specifying relationships such as "is..." or "part of...", the knowledge graph becomes rich in semantic meaning, facilitating more precise searching and retrieval of product data. Furthermore, ontology enables the harmonization of data representations across different systems by providing a common vocabulary and semantic framework for interconnecting different datasets.

[0005] Knowledge graphs and ontology are becoming increasingly important, especially with the rapid adoption of natural language generators such as large language models. The size of knowledge graphs and ontology is growing, and more users are interacting with them. However, problems can arise when knowledge graphs or ontology become too large, or when they are accessed by a large number of users. Therefore, there is room for improvement. Summary of the Invention

[0006] The Summary Section is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This Summary Section is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0007] This disclosure provides techniques and solutions for linking elements of different knowledge graphs and for using such links during knowledge graph processing. When an element (such as a class, attribute, or class instance) of a knowledge graph is created, it can be determined whether a corresponding element exists in another knowledge graph. If so, the elements can be operatively linked. When a query is run against a knowledge graph, if an element is linked to an element in another knowledge graph, that other knowledge graph can be accessed for query processing. When a statement is made about a knowledge graph element defined in a first knowledge graph and that element is defined relative to an element in a second knowledge graph, the scope of the statement can be limited to the second knowledge graph.

[0008] In one aspect, this disclosure provides a process for retrieving data from a second knowledge graph in response to a query from a first knowledge graph. A query specifying the first knowledge graph is received. Elements of the first knowledge graph specified in the query or determined based on query processing are determined to be linked to elements of the second knowledge graph. When the query is executed, elements of the second knowledge graph are used to retrieve information from the second knowledge graph. Query results are returned in response to the query.

[0009] On the other hand, this disclosure provides a process for creating a derived element in a local knowledge graph that corresponds to an element in another knowledge graph. A request to create an element in the local knowledge graph is received. One or more other knowledge graphs are searched to determine whether a semantically equivalent element exists in the knowledge graphs of the one or more other knowledge graphs. It is determined that a presumed semantically equivalent element exists in the knowledge graphs. A derived element is created in the local knowledge graph that is operatively linked to the presumed semantically equivalent element and is semantically identical to the presumed semantically equivalent element.

[0010] This disclosure also includes a computing system configured to perform the methods described above or including instructions for performing the methods described above, and a tangible, non-transitory computer-readable storage medium. As described herein, various other features and advantages may be incorporated into this technology as needed. Attached Figure Description

[0011] Figure 1 An exemplary directed graph is shown.

[0012] Figure 2 The domain and extent of attributes in the pattern of a directed graph are shown.

[0013] Figure 3 An example SPARQL query and its results are shown.

[0014] Figure 4 The diagram illustrates a computing environment that describes how interactions between the local graph and the core graph can be managed, as well as how access permissions to various graphs can be managed.

[0015] Figure 5 It is a graph that shows the relationship between the core knowledge graph and the local knowledge graph.

[0016] Figure 6 A graph is provided that shows the example core knowledge graph and its relationship to the elements of the two local knowledge graphs.

[0017] Figure 7 It is a diagram of the process of creating classes in the local knowledge graph.

[0018] Figure 8 It is a graph of the process of creating attributes in a local knowledge graph.

[0019] Figure 9 It is a graph depicting the process of creating instances in the local knowledge graph.

[0020] Figure 10A , Figure 10B and Figure 10C Example user interfaces are shown for creating new graph statements, creating new graph predicates, and creating new graph class instances, respectively.

[0021] Figure 11 This is a flowchart of the process of retrieving information from a local knowledge graph.

[0022] Figure 12A Provides class definition triples that can be used by the example graph database class.

[0023] Figure 12B It provides examples of how semantic web applications (such as those using Python with RDFLib) can create and use knowledge graphs.

[0024] Figure 12C It provides examples of how to create and use knowledge graphs using a content management system.

[0025] Figure 12D Various examples of how graph information can be stored / serialized are shown, particularly in Turtle, RDF / XML, and JSON formats.

[0026] Figure 13A This is a flowchart of an example process for retrieving data from a second knowledge graph in response to a query from a first knowledge graph.

[0027] Figure 13B This is a flowchart illustrating an example process of creating derived elements in a local knowledge graph that correspond to elements in another knowledge graph.

[0028] Figure 14 This is a diagram of an example computing system in which some of the described embodiments can be implemented.

[0029] Figure 15 This is an example cloud computing environment that can be used in conjunction with the technologies described in this article. Detailed Implementation

[0030] Example 1 - Overview

[0031] In contemporary data management and analytics, knowledge graphs provide a fundamental framework for organizing, representing, and utilizing structured knowledge from diverse data sources. Knowledge graphs encode information in a graph-based format, featuring nodes representing entities and edges representing relationships between these entities. This structure facilitates the synthesis and exploration of interconnected data, thereby enabling advanced data analytics, natural language processing (NLP), and artificial intelligence (AI) applications.

[0032] Ontologies can be used as schemas to define domain-specific concepts and relationships in knowledge graphs. Essentially, ontology provides a formal representation of domain knowledge, capturing hierarchical classifications (classes) and semantic relationships (attributes) between entities. Through ontology, knowledge graphs gain semantic richness and consistency, enabling more precise querying and reasoning about interconnected data. Statements about concepts, whether they are classes or instances, can be expressed, for example, using RDF triples. RDF triples are formed as subject-verb-object triples, where the subject represents an entity or instance, the verb represents a relation or attribute, and the object represents another entity or literal value.

[0033] The integration of ontology and knowledge graph enhances their expressiveness and interoperability across technological fields. For example, in the context of semantic web applications, an ontology defining concepts related to e-commerce can be used as a schema for structuring product information within a knowledge graph. By representing products as instances of classes defined in the ontology and specifying relationships such as "is..." or "part of...", the knowledge graph becomes rich in semantic meaning, facilitating more precise searching and retrieval of product data. Furthermore, ontology enables the harmonization of data representations across different systems by providing a common vocabulary and semantic framework for interconnecting different datasets.

[0034] Knowledge graphs and ontology are becoming increasingly important, especially with the rapid adoption of natural language generators such as large language models. The size of knowledge graphs and ontology is growing, and more users are interacting with them. However, problems can arise when knowledge graphs or ontology become too large, or when they are accessed by a large number of users. Therefore, there is room for improvement.

[0035] While Unified Modeling Language (UML) models and knowledge graphs share common goals in representing and organizing information, they differ significantly in their fundamental principles, representations, and intended use cases. UML models are primarily used in software engineering to design and visualize software systems, while knowledge graphs are used to organize and semantically enrich diverse data sources for knowledge representation and reasoning.

[0036] A key similarity between UML models and knowledge graphs is that they both use graphical representations to depict complex systems or domains. Both UML graphs and knowledge graphs employ nodes and edges to represent entities and relationships, thereby facilitating visual understanding and communication of modeled concepts.

[0037] However, significant differences exist between UML models and knowledge graphs. UML models are typically static and focus on capturing structural and behavioral aspects of software systems using predefined graphs such as class diagrams, sequence diagrams, and activity diagrams. In contrast, knowledge graphs are dynamic and can represent broad domains of knowledge, including but not limited to software engineering. Knowledge graphs emphasize semantic richness and interoperability, enabling high-level querying, inference, and discovery of relationships and patterns across diverse datasets. This is facilitated by having more structured / formal relationships between knowledge graph elements than are present in UML models.

[0038] A significant technical hurdle in applying UML-related techniques to knowledge graphs stems from the more structured nature of relations in knowledge graphs compared to UML. UML relations are typically represented using a predefined set of constructs and may not enforce strict semantics or constraints. In contrast, knowledge graphs often utilize structured relations defined by ontology or schema, which impose semantic constraints and enable complex reasoning and inference capabilities. Therefore, techniques developed for UML may not be applicable to knowledge graphs, and their implementation may involve significant technical barriers arising from overcoming the differences in the structured nature of representation, semantics, and relations.

[0039] This disclosure provides methods for facilitating the customization of knowledge graphs while maintaining knowledge. Figure 1 Techniques to improve consistency and reduce computational resource usage. Certain techniques can be used to help manage knowledge graphs, such as determining which users have permission to modify them.

[0040] In one aspect, this disclosure provides "local" knowledge graphs that can use elements from either a "core" or "global" knowledge graph. Therefore, users can create their own knowledge graphs that can contain elements not in the core knowledge graph, but also elements from it. Access to the core knowledge graph can be "read-only," preventing the local graph from modifying elements in the core knowledge graph. Additionally, in certain implementations, the local knowledge graph links to / references the core knowledge graph, but does not directly incorporate elements (such as attributes or attribute values) from the core knowledge graph. Maintaining this link reduces computational resource usage, as a single dataset can be used for both the local and core knowledge graphs. Furthermore, if the core knowledge graph changes, these changes are also "visible" to the local graph, so core knowledge graph elements in the local graph do not become obsolete or deviate from the core knowledge graph. Similar relationships can be established between different local knowledge graphs. Elements in the target knowledge graph corresponding to elements in the source knowledge graph can be referred to as semantically identical or semantically equivalent elements.

[0041] Relationships between knowledge graphs can be used to manage them, such as for operations that might modify them, rather than simply reading information from them. That is, each knowledge graph can have a group of one or more users with the authority to modify it. In this way, for example, a user might have permission to manage elements directly within their local knowledge graph, but might not have permission to modify elements from other knowledge graphs, whether those local or core knowledge graphs.

[0042] Example 2 - Example Knowledge Graph

[0043] Businesses can possess a wide variety of products, services, and teams. They can also maintain comprehensive knowledge graphs, storing knowledge about the skills, processes, experiences, capabilities, and insights relied upon in their day-to-day operations. The content of the knowledge graph can also include business-specific acronyms, departments, and product specifications. This knowledge enables businesses to respond to business situations quickly, professionally, and flexibly. Building and maintaining knowledge graphs can be expensive and labor-intensive. A Resource Description Framework (RDF) can be used to specify knowledge graphs (i.e., a semantic web and / or a web of linked data).

[0044] Typically, a knowledge graph or its subgraph / subset comprises multiple nodes connected by edges. Nodes can represent real-world entities, and edges can represent relationships between entities or relationships between entities and their types (i.e., classes). Therefore, a predicate can be distinguished based on whether it connects two entities or an entity and its type. Entities can also be referred to as resources. For each statement, the subject can correspond to a node, the object can correspond to a (different) node, and an edge corresponding to the predicate can connect the subject node to the object node. Depending on the specific application, edges can be directed or undirected. For the purposes of this disclosure, examples are generally described using directed graphs, such as those described using RDF. However, the disclosed techniques can be adapted to other types or implementations. Figure 1 Used, including with undirected Figure 1 Start using it.

[0045] Nodes can have corresponding classes, such that each node has a corresponding class. The (corresponding) class can be part of (or organized within) a schema (i.e., a data schema or ontology). This schema can be defined using RDF or a Web Ontology language.

[0046] Here is an example of a class:

[0047] :State a rdfs:Class.

[0048] :EuropeanState a rdfs:Class.

[0049] :City a rdfs:Class.

[0050] Therefore, ":State" serves as a resource for the class, more specifically, as an RDF class. The class ":EuropeanState" serves as another resource for the class, more specifically, as a subclass of ":State," thus enabling class hierarchies. Furthermore, multiple inheritance is also possible.

[0051] Alternatively, directed graphs can be labeled and are multi-relational. Therefore, nodes and edges can both have labels, and edges can have directions. The object of a statement can be a label of the directed graph. A directed graph can be multi-relational in the sense that edges have different labels. Nodes in a directed graph can be subjects or objects, and edges can be predicates.

[0052] Alternatively or concurrently, a schema may include attributes. Each of the attributes may be applied to at least one class of the schema. At least one attribute may have a domain and / or a range. Each attribute may be used by (or applied to) at least one statement. A domain (e.g., rdfs:domain) may specify the class to which the subject belongs, and a range (e.g., rdfs:range) may specify the class to which the object belongs. More specifically, a domain may specify the class to which the subject of a statement belongs, and a range may specify the class to which the object of a statement belongs. For more information on RDF schemas, please refer to the W3C RDF schema specification: https: / / www.w3.org / TR / rdf-schema / .

[0053] Here are examples of attributes:

[0054] rdf:type a rdf:Property

[0055] dbo:foundationPlace a rdf:Property.

[0056] :EuropeanState rdfs:subClassOf:State.

[0057] :locatedIn a rdf:Property.

[0058] :capitalOf a rdf:Property.

[0059] :capitalOf rdfs:subPropertyOf:locatedIn.

[0060] Therefore, ":locatedIn" and ":capitalOf" are attributes. Furthermore, ":capitalOf" is a sub-attribute of ":locatedIn". Thus, attributes can also form a hierarchy. The attribute ":EuropeanState rdfs:subClassOf:State" indicates that ":EuropeanState" is a subclass in a class hierarchy that includes the class ":State" and its subclass ":EuropeanState".

[0061] Therefore, schemas can provide a vocabulary for directed graphs (e.g., knowledge graphs). Directed graphs can have predefined attribute prefixes that indicate whether a node (i.e., subject or object) is an instance of a class or a class (e.g., if a node has the prefix "dbo" representing a DBpedia ontology, the node can be a class, and if a node has the prefix "dbr" representing a DBpedia resource, the node can be an instance). In some cases, directed graphs can use URI design to distinguish between instances and classes. Directed graphs can include statements that explicitly indicate a particular node is a class. In some cases, whether a particular node represents an instance or a class can depend on the underlying model. For example, it can be determined whether a node is a class (and included in the schema of the directed graph) or an instance (and therefore not included in the schema of the directed graph) by examining the rdf:type attribute: if the type is owl:class, the node is a class and included in the schema; otherwise, the node is an instance (i.e., an instance of a class) and not included in the schema.

[0062] Compared to relational databases, knowledge graphs offer a more flexible data structure because the type of data provided by a knowledge graph can vary. For example, attributes associated with different instances can differ, even if these instances share the same class (e.g., "SAP_SE" and "BASF_SE" can have different available attribute data, despite sharing the same class "Company"). On the other hand, relational databases can be represented in a knowledge graph format; that is, a knowledge graph can be a higher-level abstraction of a relational database.

[0063] In some examples, nodes in a directed graph (e.g., a knowledge graph) can be organized in a hierarchical structure, where lower-level nodes (representing more specific objects) can be connected to higher-level nodes (representing more general objects) via one or more edges. A lower-level node (or the lower-level object it represents) can be called a descendant of a higher-level node (or the higher-level object it represents), and a higher-level node (or the higher-level object it represents) can be called an ancestor of a lower-level node (or the lower-level object it represents).

[0064] Figure 1 A subset 100 of the directed graph is shown. More specifically, Figure 1 A subset 100 of the knowledge graph is shown. Nodes of the directed graph are shown as circles, and edges of the directed graph are shown as arrows. Subset 100 of the directed graph includes labels 102, 104, 106, 108, and 110, where labels are URIs and defined in a Resource Description Frame (RDF). Node labels 102 and 104 are objects, and edge labels 106, 108, and 110 are predicates. The string "1972-01-01" can also be a node label (i.e., an object) with the type xsd:date.

[0065] A subset 100 of the directed graph comprises statements 112 (i.e., triple statements) with a subject “dbr:SAP_SE”, a predicate “dbo:foundationPlace”, and an object “dbr:Germany”, each of which is a URI defined in RDF. An exemplary serialization of statement 112 is dbr:SAP_SE dbo:foundationPlace dbr:Germany. The schema of the directed graph can be defined via the RDF schema (RDFS) from the World Wide Web Consortium (W3C) or the Web Ontology Language (OWL).

[0066] Figure 2 The field 201 and range 203 of the attribute ":capitalOf" are shown. Field 201 and range 203 can be defined as follows:

[0067] :capitalOf rdfs:domain:City.

[0068] :capitalOf rdfs:range:Country.

[0069] Figure 3 An exemplary SPARQL query 301 for a knowledge graph is shown. Query 301 is configured to determine the answer to the question: What is the population of Chinese cities with more than 100,000 residents? The results of running query 301 are also shown.

[0070] Example 3 - Example computing environment supporting relationships between knowledge graphs

[0071] Figure 4 A computing environment 400 is illustrated, depicting how the interaction between the local knowledge graph and the core knowledge graph can be managed, as well as how access permissions to various knowledge graphs can be managed. Computing environment 400 assumes that the core knowledge graph 414 is available, such as in graph storage 410. In a particular implementation, the knowledge graph may be maintained in RDF format, such as using RDF triples, but other types of knowledge graph representations may be used without departing from the scope of this disclosure.

[0072] The computing environment 400 includes a local knowledge graph editor 418 for creating local knowledge graphs 422 of the graph storage 410. As will be explained further, local knowledge graph 422 may have some elements that are “unique” to a given local knowledge graph, or at least that local knowledge graph serves as the primary “source” of graph elements. That is, a first local knowledge graph 422 may reference elements of a core knowledge graph 414, but a second local knowledge graph may reference elements defined in the first local knowledge graph. From the perspective of the second local knowledge graph, the first local knowledge graph can act as the core knowledge graph for elements first defined in the first local knowledge graph, even if the first local knowledge graph also references the core knowledge graph 414.

[0073] The computing environment 400 also includes a matching system 430. The matching system 430 compares knowledge graph elements, such as between a core knowledge graph 414 and a local knowledge graph 422, or between two local knowledge graphs, to determine if they are identical. For example, if a user attempts to define a new class or instance for local knowledge graph 422, the matching system 430 can determine whether the class or instance already exists in core knowledge graph 414 or another local knowledge graph. Any suitable matching technique can be used, including those described in U.S. Patent Nos. 11,487,721 and 11,263,187, which are incorporated herein by reference.

[0074] Typically, users have at least read access to the core knowledge graph 414, and may also be allowed to modify the core knowledge graph, including adding, removing, or modifying elements. "Write" access to the local knowledge graph 422 can be restricted, as can read access. That is, a given user may have read access to the core knowledge graph 414, but less than all of the local knowledge graphs 422 in the graph storage 410.

[0075] The access control component 438 can be used to track access permissions and perform authorization checks. For example, when a user wants to use the local knowledge graph editor 418 to create or modify a local knowledge graph 422, the local knowledge graph editor can use the access control component 438 to determine which local knowledge graphs are available to the user. The matching system 430 can then perform matching operations on these knowledge graphs.

[0076] Knowledge graphs can be extremely useful, but they can require significant effort to create and maintain. In some implementations, computing environment 400 may include a directory 450, which users can access to view knowledge graphs available in graph storage 410. Although graph storage 410 displays a single core knowledge graph 414, it may include multiple core knowledge graphs, as well as multiple local knowledge graphs 422. Directory 450 can provide descriptive information about the core knowledge graph 414 and local knowledge graphs 422, and users can request access to such knowledge graphs, such as through purchase. In response to such a transaction, permission management component 438 may update the stored permission information to indicate that the user now has permission to access the selected core knowledge graph 414 or local knowledge graph 422.

[0077] Client 460 can access one or more of the following through user interface 464: local knowledge graph editor 418, matching system 430, access control component 438, or directory 450. For example, user interface 464 can allow a user to create or edit a local knowledge graph 422 using local knowledge graph editor 418. Matching results from matching system 430 can be displayed on user interface 464 (or matching results can be processed by local knowledge graph editor 418 and displayed on user interface). User interface 464 can allow a user to edit access permissions using access control component 438. A user can view available knowledge graphs in directory 450 through user interface and can optionally request access to one or more such knowledge graphs, which can then be granted using access control component 438.

[0078] Example 4 - Instance relationships between elements of the source knowledge graph and the target knowledge graph

[0079] As discussed, the core knowledge graph can encompass a wide variety of topics and can serve as the central source of truth for an organization. Therefore, write access to the core knowledge graph is typically strictly controlled. However, a local knowledge graph can be read from the core knowledge graph and can be defined as a proper subset of the core graph. That is, typically, for a specific use case, all elements of the core knowledge graph may not be needed / relevant. Therefore, a local knowledge graph can be created that includes a proper subset of the elements (nodes and edges) of the core knowledge graph and may optionally include elements other than those in the core knowledge graph.

[0080] When creating a local knowledge graph, you can specify access permissions for user / software processes that can read from or modify the local knowledge graph. Typically, access permissions are specified for the local knowledge graph as a whole, rather than for specific elements, which simplifies access control. That is, even though a local knowledge graph may contain many nodes and edges, specifying access permissions node-by-node may be impractical.

[0081] Different local knowledge graphs and the core knowledge graph can be associated with their own namespace / URI patterns, which distinguishes the knowledge graphs and provides a way to track / enforce access permissions. Consider a core knowledge graph named "core" and a local knowledge graph named "odm". Their respective prefixes could be:

[0082] @PREFIX core:<http: / / www.sap.com / core>

[0083] @PREFIX odm: <http: / / www.sap.com / odm?

[0084] These prefixes can then be used in RDF triples, such as for triples in a local ODM knowledge graph:

[0085] odm:BusinessPartner rdf:type odm:Entity

[0086] As explained in Example 1, a knowledge graph is typically associated with an ontology that provides a “pattern” for the knowledge graph. Having an ontology for the core knowledge graph (and preferably, the local knowledge graph) can be useful because it helps ensure that the same semantic concepts are described using the same terminology.

[0087] Using a local knowledge graph, users may want to introduce ontology elements such as attributes that are not presented in the core knowledge. Figure 1 In the global ontology used by the system, these situations can be handled in various ways. Taking ontology attributes as an example, if a new attribute is expected, one approach is to create the attribute in the global ontology or request its creation. However, this may be undesirable in some cases, such as when other users (using different local knowledge graphs) might want to use the same semantic concepts, and the original attribute name might not be the "best" choice, or when there might be an expectation to incorporate the attribute into the core knowledge graph at some point but with a different name.

[0088] Therefore, in another approach, when a new attribute (or other ontology element) is expected, the attribute can be created locally (such as a local extension of the global ontology). This method can also be used while a request to add an attribute to the global ontology is pending, or it can continue to be used if the request to add an attribute to the global ontology is rejected.

[0089] While a local knowledge graph may include elements outside of the core knowledge graph or its ontology, including elements related to the ontology, it is desirable to enforce the use of the core knowledge graph and its ontology for concepts expressed in the core knowledge graph / ontology. As will be further described, if a user wishes to add a new knowledge graph element to the local knowledge graph, it can first be determined whether the element exists in the core knowledge graph / its associated ontology. If so, the user can be prompted to use a node from the core knowledge graph. In some cases, it is possible to restrict the creation of knowledge graph elements that are determined to correspond to elements in the core knowledge graph.

[0090] This disclosure allows knowledge graph elements, such as instances, classes, or properties of a knowledge graph, to be "reused" in other knowledge graphs, where the reused elements can be considered derivatives of elements in the source knowledge graph. As a concrete example, consider a company that may have a large number of products, each potentially with multiple components. A core knowledge graph can be created for these products. Due to its importance, a very limited number of users may have permission to modify this core knowledge graph.

[0091] Companies may desire more product-specific information, such as in a knowledge graph that reflects entities (which may correspond to relational database tables), entity attributes, and the relationships between entities and attributes. Local knowledge graphs can be created for specific operational areas (also known as "domains"). Local knowledge graphs can incorporate elements that differ from those in the core knowledge graph, including more domain-specific ones. That is, in some cases, it may be desirable to maintain higher-level / more general (or basic) information in the core knowledge graph and include more specific information in the local knowledge graph, which can help keep the core knowledge graph at a more manageable scale.

[0092] However, for reasons previously described (such as reduced storage requirements and improved consistency), using elements from the core knowledge graph within a local knowledge graph can be beneficial. If a "statement" is made about these core knowledge graph elements, it is expected that the statement was made by the local knowledge graph, not the core knowledge graph. Besides enforcing a "read-only" state to reuse core knowledge graph elements, this "attribution" aspect helps clarify the authenticity / scope of knowledge graph elements. For example, a statement in the local knowledge graph for an element reused from the core knowledge graph can be understood as having a scope limited to that local knowledge graph. Users of the core knowledge graph or other local knowledge graphs will not see the statement unless, for example, another local knowledge graph links to it.

[0093] For attributes of the core knowledge graph that are reused (or more generally, the "source" knowledge graph—because in some cases, a local knowledge graph can act as the source of other local knowledge graphs), the reused element of the local (or target) knowledge graph can be referred to as a sub-attribute of the attribute of the source knowledge graph. For example, suppose a local private knowledge graph needs an object attribute with the semantic "hasMetric". If another knowledge graph (either the core knowledge graph or one of the different local knowledge graphs) contains an attribute with that semantic, it may be advantageous to reuse that attribute rather than creating a duplicate attribute with the same semantic.

[0094] To help maintain the authenticity of the source knowledge graph, users of the target knowledge graph are not allowed to make statements about attributes in the source knowledge graph. However, users of the local knowledge graph can make statements about sub-attributes derived from the source knowledge graph. The namespace information discussed earlier can enable this functionality.

[0095] Consider an example with a core knowledge graph, where the first local knowledge graph is named "odm" and the second local knowledge graph is named "signavio". These knowledge graphs can have the following corresponding namespaces:

[0096] @PREFIX core:<http: / / www.sap.com / core>

[0097] @PREFIX odm:<http: / / www.sap.com / odm>

[0098] @PREFIX sig:<http: / / www.signavio.com / >

[0099] The following RDF triple expresses the relationship between the "hasMetric" attribute of the source local knowledge graph (odm) and the "hasMetric" sub-attribute of the target local knowledge graph (sig) and the "hasMetric" attribute of the source local knowledge graph:

[0100] odm:hasMetric rdf:type owl:ObjectProperty

[0101] sig:hasMetric rdfs:subPropertyOf odm:hasMetric

[0102] Consider knowledge graph elements of classes. Derived classes of the target knowledge graph can be associated with source classes via the "isDerivativeOf" relationship. Of course, the names of this technique and others disclosed herein are for illustrative purposes, and other names can be used for the same functionality. Instances of derived classes include properties that establish and detail links to specific instances of the source class. The hasDerivative object property establishes the link to the source instance. A DataTypeProperty is used to store the identifier of the source instance.

[0103] Typically, reusing instances from the source knowledge graph assumes that the local knowledge graph has the appropriate class for that instance. To reuse instances from the source knowledge graph, you can first determine if the target knowledge graph includes a derived class of the source instance's source class. If the derived class does not exist, create it, and then create a local instance of the class in the target knowledge graph and link it to the corresponding instance in the source knowledge graph.

[0104] In summary, when an instance and its derived class from the source knowledge graph do not exist in the target knowledge graph, the derived class is created in the target knowledge graph. A new instance of this derived class is created in the target knowledge graph and linked to the original instance using the `hasDerivative` relationship. The name of the original instance is passed to the new instance, and the identifier of the original instance is passed to the `DerivedFromIdentifier` property of the new instance's data type. This process can be represented in pseudocode as follows:

[0105] METHOD reuseInstance(Instance i,Graph thisgraph):

[0106] IF NOT derivativeExistsInGraph(i.getClass(),thisGraph)THEN

[0107] derivative=thisGraph.createDerivative(i.getClass)

[0108] newInstance=thisGraph.createDerivedInstance(i)

[0109] As a more concrete example, suppose the core knowledge graph has instances of the HANA database representing SAP, SE. These instances can be represented as ppms:HANA in the source knowledge graph. The local knowledge graph creates (or contains) the class odm:Product, which is a derivative of the source class (where ppms:HANA is an instance) ppms:Product. The local knowledge graph creates its own node odm:HANA, and the local knowledge graph notices (through the properties discussed above) that odm:HANA is derived from ppms:HANA. When the local knowledge graph makes statements about HANA, it uses only odm:HANA, not ppms:HANA.

[0110] In some implementations, information related to target knowledge graph elements derived from source knowledge graph elements is obtained directly from the source knowledge graph. For example, in the case of instances, if information about derived instances in the target knowledge graph, such as attribute values, is needed, these values ​​can be obtained from the source knowledge graph instead of being copied to the target knowledge graph. This value can be obtained using attributes of the target knowledge graph instance, such as the "core:hasDerivative" link (which, from the target knowledge graph's perspective, can be the reverse of "isDerivativeOf").

[0111] Figure 5 The scenario described above involves a product node 510 in the target knowledge graph (“odm”) referencing a product node 514 in the source knowledge graph (“ppms”). An edge 518 establishes a derivation relationship between nodes 510 and 514. Furthermore, an instance 522 of the product node 514 in the source knowledge graph links to the corresponding node 526 of a derived instance of instance 522. An edge 530 establishes that node 526 is a derivative of node 522.

[0112] Figure 5 The diagram also illustrates how instance nodes 522 and 526 can be associated with additional facts. Source instance node 522 can have facts that can be read by the target knowledge graph but not modified. Conversely, instance node 526 can add facts specific to the target knowledge graph.

[0113] Figure 6 It provides a more comprehensive description of how local knowledge graphs 614 and 616 can be related to the core knowledge graph 610. Figure 6The diagram also illustrates how the core knowledge graph 610 can contain more advanced / more basic information, where additional details can be added using local knowledge graphs 614 and 616. For example, node 620 of the core knowledge graph 610 represents a "one domain model" in the SE, SAP system. The core knowledge graph 610 indicates that the master data integration product, represented by node 622, uses a one domain model, and indicates that the one domain model is a semantic data model connected to node 624 via an edge.

[0114] The ODM node 630 of the local knowledge graph 614 has an isDerivative relationship with the ODM node 620 of the core knowledge graph 610, indicated by edge 632. The local knowledge graph 614 then provides more specific facts about the single-domain model. For example, node 634 can represent a person, and the edge linking nodes 630 and 634 can indicate a "hasOwner" relationship. Node 636 can indicate a publication date, which is linked to node 638, which provides a literal value of the publication date. The edge between nodes 630 and 636 can be used to establish an association between the ODM of node 630 and the specific publication date of node 638.

[0115] Node 640 of the core knowledge graph 610 can be linked to node 642 of the local knowledge graph 616 using a hasDerivative edge 644, in a similar way to how edge 632 links nodes 620 and 630. Note that in Figure 6 In the knowledge graph, the unique relationship between knowledge graphs 610, 614, and 616 uses hasDerivative edges.

[0116] Example 5 - Example process for creating local knowledge graph elements

[0117] Figure 7-9 A swimlane diagram is provided for the process of creating various types of derived elements in the target knowledge graph. Figure 7-9 This is described using specific examples of core and local knowledge graphs, but it can be applied more generally to source and target knowledge graphs. These processes can be used... Figure 4 The computing environment 400 is implemented using components, particularly the client 460, the local knowledge graph editor 418, the matching system 430, and the permission management component 438.

[0118] Figure 7 A swimlane diagram is provided for process 700 for creating classes in the local knowledge graph, which can be new classes in the local knowledge graph or derivatives of classes in the core knowledge graph. At 710, the client 460 provides this information through a user interface (such as...). Figure 4The user interface 464 requests the creation of a new class. This request is received by the local knowledge graph editor 418, which initiates a class creation process (such as a computation method or function) at 714. The local knowledge graph editor 418 invokes the matching system 430, which runs a matching process at 718. For example, a request provided at 710 could provide a class name. The matching process 718 can determine whether the name exists in the core knowledge graph, or whether semantic equivalence exists in the core knowledge graph.

[0119] If a match is found, it can be displayed to the client 460 via user interface 464. At 722, the client evaluates the match and determines whether the proposed match reflects their intent. If so, the client can approve the match, and at 726, a derived class is created in the local knowledge graph by the local knowledge graph editor 418.

[0120] If no match is identified at 718, or if the user rejects the match after evaluation at 722, then at 730, the matching component 430 requests the local knowledge graph that the user has access to from the permission management component 438. The permission management component 438 obtains the relevant local knowledge graphs at 734 and provides them to the matching component 430. Then, at 738, the matching component 430 performs the matching process on the local knowledge graphs.

[0121] If a match is found, it can be presented to client 460, who can evaluate the match at 742. If client 460 accepts the match, process 700 proceeds to 726. If no match is found at 738, or if the user rejects the match after evaluation at 742, a new local class (a class not linked to the core knowledge graph) is created at 746.

[0122] Figure 8 A swimlane graph is provided for the process 800 of creating attributes, which can be either new attributes in the local knowledge graph or sub-attributes of attributes in the core knowledge graph. At 810, the client 460 provides this information through a user interface (such as...). Figure 4 The user interface 464 requests the creation of a new attribute. The request is received by the local knowledge graph editor 418, which begins the attribute creation process (such as a calculation method or function) at 814. The local knowledge graph editor 418 invokes the matching system 430, which runs the matching process at 818. For example, a request provided at 810 could provide an attribute name. The matching process 818 can determine whether the name exists in the core knowledge graph, or whether a semantically equivalent attribute exists in the core knowledge graph.

[0123] If a match is found, it can be displayed to the client 460, for example, via user interface 464. At 822, the client evaluates the match and determines whether the proposed match reflects their intent. If so, the client can approve the match, and at 826, the local knowledge graph editor 418 creates a sub-attribute in the local knowledge graph that links to the corresponding attribute in the core knowledge graph.

[0124] If no match is identified at 818, or if the user rejects the match after evaluation at 822, then at 830, the matching component 430 requests the local knowledge graph that the user has access to from the permission management component 438. The permission management component 438 obtains the relevant local graphs at 834 and provides them to the matching component 430. Then, at 838, the matching component 430 performs the matching process on the local knowledge graph.

[0125] If a match is found, it can be presented to client 460, who can evaluate the match at 842. If client 460 accepts the match, process 800 proceeds to 826. If no match is found at 838, or if the user rejects the match after evaluation at 842, a new local attribute (an attribute not linked to the core knowledge graph) is created at 846.

[0126] Figure 9 A swimlane graph is provided for the process of creating instances (900), which can be either new instances in the local knowledge graph or derived instances from instances in the core knowledge graph. At 910, the client (460) provides this information through a user interface (such as...). Figure 4 The user interface 464 requests the creation of a new instance. The request is received by the local knowledge graph editor 418, which initiates the instance creation process (such as a computation method or function) at 914. The local knowledge graph editor 418 invokes the matching system 430, which runs the matching process at 918. For example, a request provided at 910 could provide an instance name or identifier. The matching process 918 can determine whether the name or identifier exists in the core knowledge graph.

[0127] If a match is found, it can be displayed to the client 460, for example, via user interface 464. At 922, the client evaluates the match and determines whether the proposed match reflects their intent. If so, the local graph editor 418 determines at 926 whether a derived class corresponding to the class of the instance in the core knowledge graph exists in the local knowledge graph. If not, the derived class is created at 930, and an instance of the derived class corresponding to the instance in the core knowledge graph is created in the local knowledge graph at 934. If, in response to the determination at 926 that the derived class already exists, the existing derived class is reused at 938, and process 900 proceeds to 934.

[0128] If no match is identified at 918, or if the user rejects the match in response to the evaluation at 922, the matching component 430 may request a local knowledge graph accessible to the client 460 from the permission management component 438 at 942. The permission management component 438 obtains such a local knowledge graph at 946 and sends it to the matching component 430. At 950, the matching component 430 uses the local knowledge graph to perform the instance matching process.

[0129] If a match is identified, it is presented to client 460, which evaluates the match at 954. If the match is approved, the process proceeds from 900 to 926. If no match is found at 950, or if the user rejects the match after evaluation at 954, the process creates a new local instance of the local class at 958.

[0130] Example 6 - Sample user interface for creating knowledge graph elements

[0131] Figures 10A to 10C A sample user interface is provided for creating new local knowledge graph elements, where, in some cases, the user is given feedback on whether the corresponding element can correspond to an element in the core knowledge graph or another local knowledge graph. Figure 10A The user interface 1000 shows how users can define new statements.

[0132] User interface element 1010 allows the user to select a knowledge graph from which statements will be assigned. In some implementations, user interface control 1012 allows the user to select from a pre-existing knowledge graph, such as by providing a drop-down menu. The user can then define statements, such as in the form of RDF triples with a subject, object, and predicate. User interface elements 1018 and 1022 allow the user to input the subject and object. User interface elements 1018 and 1022 allow free-form text input, while in at least some implementations, user interface element 1020 is used to select predicates from a defined set. For example, selecting user interface element 1020 can cause a list of available predicates to appear in a drop-down menu.

[0133] User interface elements 1018, 1020, and 1022 can be implemented in different ways. For example, user interface element 1020 can also allow free-form text input, where the input text is compared against a set of available predicates, and an alert can be provided if the input text does not match an existing predicate (either precisely or semantically). In some cases, the user is constrained to a defined set of predicates, while in others, input of predicates not in the defined set is allowed. Typically, if a predicate does not currently exist, a predicate is defined for a local graph created / modified using user interface 1000.

[0134] Figure 10A The diagram illustrates informational text that can be displayed to the user. For example, subject user interface element 1018 and object user interface element 1022 are associated with text indicating that attempting to use a subject or object existing in another namespace (or at least in the namespace of the core knowledge graph) will result in the creation of a derived subject or object. Therefore, user interface 1000 can be associated with functionality that prevents the user from creating subjects or objects corresponding to those in other namespaces. This functionality can be extended to prevent the creation of subjects or objects that are semantically equivalent to those in other knowledge graphs.

[0135] Figure 10B A user interface 1030 is shown that allows users to define predicates. Similar to user interface 1000, user interface 1030 includes user interface element 1032, which allows users to select a knowledge graph to which predicates will be assigned. User interface 1030 allows users to input values ​​for specific attributes of the predicates. In the corresponding fields 1034, 1036, and 1038, users can input the URI, name, and description of the predicate.

[0136] Figure 10B The diagram illustrates message 1042, which can be displayed if a user inputs information about a predicate that exists in another knowledge graph (such as the core knowledge graph). In a particular implementation, the computation process compares the name entered in field 1036, along with optional semantic equivalents, with existing predicates. In this scenario, message 1042 provides user interface elements 1044 and 1046, where user interface element 1044 allows the user to select predicates from the core data model, and user interface element 1046 allows the user to continue creating predicates unrelated to those in the core knowledge graph.

[0137] Figure 10C A user interface 1060 is shown that allows a user to create new instances of a class. User interface 1060 includes user interface element 1062, which allows the user to select a knowledge graph to which instances will be added. User interface 1060 also includes user interface element 1064, which allows the user to input the class to which instances will be assigned; user interface element 1066, which allows the user to specify the URI of the instance (which may include the namespace of the knowledge graph to which instances will be assigned); and user interface element 1068, which allows the user to input the name of the instance.

[0138] When an instance name is provided using user interface element 1068, computational logic associated with user interface 1060 can determine whether the name corresponds to an instance name in another knowledge graph (e.g., a core knowledge graph or another local knowledge graph). If so, user interface 1060 can display a message 1070 indicating that an instance with that name already exists.

[0139] Message 1070 can display the class 1072, URI 1074, and name 1076 of the identified instance. Then, if the identified instance is the same as the instance the user intends to add, the user can select user interface element 1080; otherwise, the user can select user interface element 1082. If user interface element 1080 is selected to indicate that the instances are the same, a derivative of the instance can be created in the local knowledge graph, as previously described.

[0140] It should be noted that in the specific example shown in user interface 1060, the class specified in user interface element 1064 is the same as the class 1072 identified in message 1070. This information can be used to help determine whether the instance to be added can correspond to an existing instance. Conversely, the URI of user interface element 1066 is different from the URI 1074 of message 1070, has a different namespace, and a different instance identifier, indicating that the instance is in a different knowledge graph.

[0141] The instance in message 1070 has been identified as potentially corresponding to an instance the user wishes to add, even if the instance name 1076 in the message differs from the name entered using user interface element 1068. This indicates that the matching logic does not require strict consistency between instance names for possible matches. For example, the matching logic could look for overlaps between information / text between two URIs (e.g., both containing the text "ODM"), or between URIs and names (e.g., where user interface element 1068 includes the text "One Domain Model," which also exists in URI 1074 of message 1070). The degree of overlap can be used to help prioritize or rank possible matches, such as where overlap occurs (e.g., between URIs, between names, or between a name and a URI). In the case of finding multiple possible matches, the possible matches can be displayed to the user, who can then select the appropriate element or indicate the desired new element. This display / selection process can be incorporated into... Figures 7 to 9 The process is in steps 700, 800, and 900.

[0142] Example 7 - Example operation for retrieving information from a local knowledge graph

[0143] Figure 11 A flowchart of process 1100 for retrieving information from a local knowledge graph using the techniques of this disclosure is provided. At 1105, a request for information about the local knowledge graph is received. For example, the request may be a query using a computer-implemented query language (such as SPARQL) that operates on knowledge graph information (such as RDF triples) stored in a graph database. At 1110, relevant information is retrieved from the local knowledge graph.

[0144] At 1115, it is determined whether an element of the local knowledge graph specified in the query or identified as part of the query run is linked to an element of the source knowledge graph, which can be the core knowledge graph or another local knowledge graph. If not, the query results are returned in response to the request at 1120. If a link is identified at 1115, the relevant information is retrieved from the source knowledge graph at 1125, and then process 1100 proceeds to 1120.

[0145] Example 8 - Example Knowledge Graph Implementation Method

[0146] As mentioned earlier, knowledge graphs are essentially computer-implemented structures and can be processed using computer execution processes, such as graph definition operations or graph query operations.

[0147] Figure 12A A simple example of class-defined triples that can be used by the example graph database class is provided. Figure 12B It provides examples of how semantic web applications (such as those using Python with RDFLib) can create and use knowledge graphs. Figure 12C Examples of how to create and use knowledge graphs using a content management system (specifically using PHP with EasyRdf) are provided. Figure 12D Various examples of how graph information can be stored / serialized are shown, particularly in Turtle, RDF / XML, and JSON formats.

[0148] Example 9 - Example Operation

[0149] Figure 13A This is a flowchart of an example process 1300 for retrieving data from a second knowledge graph in response to a query from a first knowledge graph. At 1304, a query specifying the first knowledge graph is received. At 1308, it is determined that elements of the first knowledge graph specified in the query or determined based on query processing are linked to elements of the second knowledge graph. While the query is executed, at 1312, elements of the second knowledge graph are used to retrieve information from the second knowledge graph. At 1316, query results are returned in response to the query.

[0150] Figure 13BThis is a flowchart of example process 1320, which involves creating a derived element in a local knowledge graph that corresponds to an element in another knowledge graph. At 1324, a request to create an element in the local knowledge graph is received. At 1328, one or more other knowledge graphs are searched to determine if a semantically equivalent element exists in the knowledge graphs of the one or more other knowledge graphs. At 1332, it is determined that a presumed semantically equivalent element exists in the knowledge graph. At 1336, a derived element is created in the local knowledge graph that is operatively linked to the presumed semantically equivalent element and is semantically identical to the presumed semantically equivalent element.

[0151] Example 10 - Additional Examples

[0152] Example 1 includes a computing system comprising at least one memory, one or more hardware processing units coupled to the at least one memory, and one or more computer-readable storage media storing computer-executable instructions that, when executed, cause the computing system to perform operations. These operations include receiving a query specifying a first knowledge graph, determining elements in the first knowledge graph specified in the query or determined based on processing the query that are linked to elements in a second knowledge graph, retrieving information from the second knowledge graph using elements of the second knowledge graph while running the query, and returning query results in response to the query.

[0153] Example 2 includes the topic of Example 1, with the addition that the elements of the first knowledge graph are derived from the elements of the second knowledge graph.

[0154] Example 3 includes the topic of Example 2, and further specifies that the elements of the first knowledge graph and the elements of the second knowledge graph are semantically identical.

[0155] Example 4 includes the topic of Example 3, and describes in detail the elements of the first knowledge graph and the elements of the second knowledge graph that share a common identifier.

[0156] Example 5 includes the topic of Example 4, specifying that the public identifier is defined in the first namespace of the first knowledge graph and the second namespace of the second knowledge graph.

[0157] Example 6 includes the subject of any one of Examples 1-5, wherein the operation further includes receiving the access credentials of the user who submitted the query, and determining that the user is authorized to access the second knowledge graph.

[0158] Example 7 includes a topic from any of Examples 1-6, specifying the use of tuples with subject, object, and predicate to link elements of the first knowledge graph to elements of the second knowledge graph.

[0159] Example 8 is a method implemented in a computing system including at least one hardware processor and at least one memory. The method includes receiving a request to create elements of a local knowledge graph, searching one or more other knowledge graphs to determine whether semantically equivalent elements exist in the knowledge graphs of the one or more other knowledge graphs, determining that a presumed semantically equivalent element exists in the knowledge graphs, and creating a derived element in the local knowledge graph that is operatively linked to and semantically identical with the presumed semantically equivalent element.

[0160] Example 9 includes the topic of Example 8, specifying that the elements of the local knowledge graph are attributes.

[0161] Example 10 includes the topic of Example 8, specifying that the elements of the local knowledge graph are classes.

[0162] Example 11 includes the topic of Example 8, specifying that the elements of the local knowledge graph are class instances.

[0163] Example 12 includes the topic of Example 11, adding operations involving assigning the name of a class instance of a knowledge graph corresponding to a class instance to a class instance of a local knowledge graph, and assigning the identifier of a class instance of a knowledge graph to a class instance of a local knowledge graph.

[0164] Example 13 includes the topic of any of Examples 8-12 and describes in detail how derived elements of a local knowledge graph can be operationally linked to semantically equivalent elements by assigning the URI of a semantically equivalent element to the derived element.

[0165] Example 14 includes a topic from any of Examples 8-13, wherein the operation further includes receiving access credentials of a user who submits a request to create an element of a local knowledge graph, and using the access credentials to determine one or more other knowledge graphs, wherein the one or more other knowledge graphs are a proper subset of a plurality of available knowledge graphs.

[0166] Example 15 includes the topic of any of Examples 8-14, and adds an indication to the user via a user interface that a presumed semantic equivalent exists in response to determining that a presumed semantic equivalent exists in the knowledge graph.

[0167] Example 16 includes the subject of Example 15, and describes in further detail its involvement in receiving user input that approves presumed semantically equivalent elements as semantically equivalent, and in response to the user input, performing the creation of derived elements.

[0168] Example 17 includes the topic of any of Examples 8-16, specifying that elements of the local knowledge graph are operationally linked to presumed semantic equivalent elements using tuples of Es with subject, object, and predicate.

[0169] Example 18 includes one or more computer-readable storage media, including computer-executable instructions that, when executed by a computing system including at least one hardware processor and at least one memory, cause the computing system to receive a request to create elements of a local knowledge graph, search one or more other knowledge graphs to determine whether semantically equivalent elements exist in the knowledge graphs of the one or more other knowledge graphs, determine that a presumed semantically equivalent element exists in the knowledge graphs, and create derived elements in the local knowledge graph that are operatively linked to the presumed semantically equivalent element and are semantically identical to the presumed semantically equivalent element.

[0170] Example 19 includes the topic of Example 18, specifying that elements of the local knowledge graph can be attributes, classes, or class instances.

[0171] Example 20 includes the topics of Example 18 or Example 19, and describes in detail how derived elements of a local knowledge graph can be operationally linked to semantically equivalent elements by assigning the URI of a semantically equivalent element to the derived element.

[0172] Example 11 - Computing System

[0173] Figure 14 A generalized example of a suitable computing system 1400 in which the described innovations can be implemented is depicted. The computing system 1400 is not intended to impose any limitation on the scope or functionality of this disclosure, and the innovations can be implemented in various general-purpose or special-purpose computing systems.

[0174] refer to Figure 14 The computing system 1400 includes one or more processing units 1410, 1415 and memories 1420, 1425. Figure 14 In this diagram, the basic configuration 1430 is included within the dashed lines. Processing units 1410 and 1415 execute computer-executable instructions, such as those used to implement the techniques described in Examples 1-10. The processing units can be general-purpose central processing units (CPUs), processors in application-specific integrated circuits (ASICs), or any other type of processor. In a multiprocessor system, multiple processing units execute computer-executable instructions to increase processing power. For example, Figure 14 A central processing unit 1410 and a graphics processing unit or coprocessor 1415 are shown. Physical memories 1420 and 1425 may be volatile memories (e.g., registers, caches, RAM), non-volatile memories (e.g., ROM, EEPROM, flash memory, etc.), or some combination thereof, accessible by the processing units 1410 and 1415. Memories 1420 and 1425 store software 1480, which stores implementations of one or more of the innovations described herein in the form of computer-executable instructions suitable for execution by the processing units 1410 and 1415.

[0175] The computing system 1400 may have additional features. For example, the computing system 1400 includes storage 1440, one or more input devices 1450, one or more output devices 1460, and one or more communication connections 1470. Interconnection mechanisms (not shown), such as buses, controllers, or networks, interconnect the components of the computing system 1400. Typically, operating system software (not shown) provides an operating environment for other software running in the computing system 1400 and coordinates the activities of the components of the computing system 1400.

[0176] Tangible storage 1440 may be removable or non-removable and includes disks, magnetic tapes or cartridges, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner and can be accessed within computing system 1400. Storage 1440 stores instructions for implementing one or more innovative software 1480 described herein.

[0177] Input device 1450 may be a touch input device (such as a keyboard, mouse, pen, or trackball), voice input device, scanning device, or another device that provides input to computing system 1400. Output device 1460 may be a monitor, printer, speaker, CD burner, or another device that provides output from computing system 1400.

[0178] Communication connection 1470 enables communication with another computing entity via a communication medium. The communication medium transmits information such as computer-executable instructions, audio or video input or output, or other data in modulated data signals. Modulated data signals are signals whose characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may be electrical, optical, RF, or other carriers.

[0179] Innovations can be described in the general context of computer-executable instructions, such as those included in program modules and running on a computing system targeting a real or virtual processor. Typically, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The computer-executable instructions for a program module can run within a local or distributed computing system.

[0180] The terms “system” and “device” are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on the type of computing system or computing device. Generally, a computing system or computing device can be local or distributed and can include any combination of dedicated hardware and / or general-purpose hardware with software that implements the functions described herein.

[0181] In the various examples described herein, modules (e.g., components or engines) may be "coded" to perform certain operations or provide certain functions, indicating that computer-executable instructions for the module can be run to perform such operations, cause such operations to be performed, or otherwise provide such functions. While the functionality described with respect to a software component, module, or engine may be executed as a separate software unit (e.g., a program, function, class method), it does not need to be implemented as a separate unit. That is, the functionality can be incorporated into a larger or more general program, such as one or more lines of code within a larger or more general program.

[0182] For the sake of presentation, detailed descriptions use terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions of operations performed by a computer and should not be confused with actions performed by humans. The actual computer operations corresponding to these terms vary depending on the implementation.

[0183] Example 12 - Cloud Computing Environment

[0184] Figure 15 An example cloud computing environment 1500 is depicted in which the described technologies can be implemented. The cloud computing environment 1500 includes a cloud computing service 1510. The cloud computing service 1510 may include various types of cloud computing resources, such as computer servers, data storage repositories, networking resources, etc. The cloud computing service 1510 may be centralized (e.g., provided by a data center of an enterprise or organization) or distributed (e.g., provided by various computing resources located in different locations, such as different data centers and / or located in different cities or countries).

[0185] Cloud computing service 1510 is used by various types of computing devices (e.g., client computing devices), such as computing devices 1520, 1522, and 1524. For example, computing devices (e.g., 1520, 1522, and 1524) can be computers (e.g., desktop computers or laptop computers), mobile devices (e.g., tablet computers or smartphones), or other types of computing devices. For example, computing devices (e.g., 1520, 1522, and 1524) can utilize cloud computing service 1510 to perform computational operations (e.g., data processing, data storage, etc.).

[0186] Example 13 - Implementation

[0187] Although some operations of the disclosed methods have been described in a specific order for ease of presentation, it should be understood that this description includes rearrangement unless the specific language described below requires a particular order. For example, operations described sequentially may be rearranged or performed simultaneously in some cases. Furthermore, for simplicity, the accompanying drawings may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

[0188] Any of the methods disclosed can be implemented as a computer-executable instruction or computer program product stored on one or more computer-readable storage media (such as tangible, non-transitory computer-readable storage media) and running on a computing device (e.g., any available computing device, including smartphones or other mobile devices including smart hardware). A tangible computer-readable storage medium is any available tangible medium that can be accessed within a computing environment (e.g., one or more optical media discs (such as DVDs or CDs), volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as flash memory or hard disk drives)). As an example, and with reference to... Figure 14 Computer-readable storage media include memories 1420 and 1425 and memory 1440. The term "computer-readable storage medium" excludes signals and carrier waves. Furthermore, the term "computer-readable storage medium" excludes communication connections (e.g., 1470).

[0189] Any computer-executable instructions used to implement the disclosed technology, and any data created and used during the implementation of the disclosed embodiments, may be stored on one or more computer-readable storage media. The computer-executable instructions may be, for example, a dedicated software application or a software application accessed or downloaded via a web browser, or part of another software application (such as a remote computing application). Such software may run, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment using one or more networked computers (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such networks).

[0190] For clarity, only certain selected aspects of the software-based implementation are described. Other details well-known in the art have been omitted. For example, it should be understood that the disclosed techniques are not limited to any particular computer language or program. For instance, the disclosed techniques can be implemented by software written in C, C++, C#, Java, Perl, JavaScript, Python, R, Ruby, ABAP, SQL, Xcode, Go, Adobe Flash, or any other suitable programming language, or, in some examples, markup languages ​​such as HTML or XML, or a combination of suitable programming languages ​​and markup languages. Similarly, the disclosed techniques are not limited to any particular computer or hardware type. Certain details of suitable computers and hardware are well-known and do not need to be elaborated in this disclosure.

[0191] Furthermore, any software-based implementation (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, intranets, software applications, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

[0192] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. Rather, this disclosure relates to all novel and non-obvious features and aspects of the various disclosed embodiments, individually and in various combinations and sub-combinations with each other. The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor are the disclosed embodiments required to have any one or more particular advantages or problems solved.

[0193] The techniques from any example can be combined with the techniques described in any one or more other examples. Given that the principles of the disclosed techniques can be applied to many possible embodiments, it should be understood that the illustrated embodiments are examples of the disclosed techniques and should not be considered as limiting the scope of the disclosed techniques. Rather, the scope of the disclosed techniques includes everything covered by the scope and spirit of the appended claims.

Claims

1. A computing system, comprising: At least one memory; One or more hardware processing units coupled to the at least one memory; as well as One or more computer-readable storage media storing computer-executable instructions, which, when executed, cause the computing system to perform operations, including: Receive queries for the specified first knowledge graph; Elements in the first knowledge graph specified in the query or determined based on processing the query are linked to elements in the second knowledge graph. When running the query, information is retrieved from the second knowledge graph using elements of the second knowledge graph; and The query results are returned in response to the query.

2. The computing system according to claim 1, wherein, The elements of the first knowledge graph are derived from the elements of the second knowledge graph.

3. The computing system according to claim 2, wherein, The elements of the first knowledge graph and the elements of the second knowledge graph have the same semantics.

4. The computing system according to claim 3, wherein, The elements of the first knowledge graph and the elements of the second knowledge graph share a common identifier.

5. The computing system according to claim 4, wherein, The public identifier is specified in a first namespace of the first knowledge graph and in a second namespace of the second knowledge graph.

6. The computing system according to claim 1, further comprising: Receive the access credentials of the user who submitted the query; as well as It is determined that the user is authorized to access the second knowledge graph.

7. The computing system according to claim 1, wherein, Elements of the first knowledge graph are linked to elements of the second knowledge graph using tuples containing a subject, object, and predicate.

8. A method implemented in a computing system, the computing system including at least one hardware processor and at least one memory coupled to the at least one hardware processor, the method comprising: Receive requests to create elements for a local knowledge graph; Search one or more other knowledge graphs to determine whether semantically equivalent elements exist in the knowledge graphs of the one or more other knowledge graphs; It is determined that there are presumed semantically equivalent elements in the knowledge graph; as well as Create derived elements in the local knowledge graph that are operatively linked to the presumed semantically equivalent element and are semantically identical to the presumed semantically equivalent element.

9. The method according to claim 8, wherein, The elements of the local knowledge graph are attributes.

10. The method according to claim 8, wherein, The elements of the local knowledge graph are classes.

11. The method according to claim 8, wherein, The elements of the local knowledge graph are class instances.

12. The method of claim 11, further comprising: Assign the name of the class instance of the knowledge graph corresponding to the class instance to the class instance of the local knowledge graph; as well as Assign the identifier of the class instance of the knowledge graph to the class instance of the local knowledge graph.

13. The method according to claim 8, wherein, By assigning the URI of the presumed semantically equivalent element to the derived element, the derived element of the local knowledge graph is operatively linked to the presumed semantically equivalent element.

14. The method of claim 8, further comprising: The access credentials of the user who submitted the request to create the elements of the local knowledge graph; as well as The access credentials are used to determine the one or more other knowledge graphs, wherein the one or more other knowledge graphs are proper subsets of a plurality of available knowledge graphs.

15. The method of claim 8, further comprising: In response to determining that a presumed semantically equivalent element exists in the knowledge graph, an indication of the existence of the presumed semantically equivalent element is displayed to the user via a user interface.

16. The method of claim 15, further comprising: Receive user input that approves the presumed semantically equivalent element as semantically equivalent, wherein the creation of the derived element is performed in response to the user input.

17. The method according to claim 8, wherein, The elements of the local knowledge graph are operationally linked to the presumed semantic equivalent elements using tuples with elements having a subject, object, and predicate.

18. One or more computer-readable storage media, comprising: Computer-executable instructions, when executed by a computing system comprising at least one hardware processor and at least one memory coupled to said at least one hardware processor, cause said computing system to: receive a request to create elements of a local knowledge graph; Computer-executable instructions, when executed by the computing system, cause the computing system to search one or more other knowledge graphs to determine whether semantically equivalent elements exist in the knowledge graphs of the one or more other knowledge graphs; Computer-executable instructions, when executed by the computing system, cause the computing system to determine that a presumed semantically equivalent element exists in the knowledge graph; as well as Computer-executable instructions, when executed by the computing system, cause the computing system to create derived elements in a local knowledge graph, the derived elements being operatively linked to the presumed semantically equivalent elements and being semantically identical to the presumed semantically equivalent elements.

19. One or more computer-readable storage media according to claim 18, wherein, The elements of the local knowledge graph are attributes, classes, or class instances.

20. One or more computer-readable storage media according to claim 18, wherein, The derived elements of the local knowledge graph are operatively linked to the semantically equivalent element by assigning the URI of the semantically equivalent element to the derived element.

Images