Ontology-based graph query optimization

CN116775693BActive Publication Date: 2026-10-16MICROSOFT TECHNOLOGY LICENSING LLC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202310688092.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2017-02-28
Filing Date
2018-02-22
Publication Date
2026-10-16
Estimated Expiration
2038-02-22

Smart Images

  • Figure CN116775693B_ABST
    Figure CN116775693B_ABST
Patent Text Reader

Abstract

Examples of the present disclosure describe systems and methods for ontology-based graph query optimization. In examples, ontology data related to a graph or isolated collection can be collected. The ontology data can include uniqueness and topology information, and can be used to reformulate a query in order to produce a higher performing query than the original query when retrieving target information from the graph. In examples, reformulating a query can include reordering one or more parameters of a query related to sources, relationships, and / or attributes based on uniqueness information. In another example, a query can be reformulated by modifying a source type to which the query is anchored based on the topology information. The reformulated query can then be executed to identify target information in the isolated collection, thereby identifying the same target information as the original query, but in a higher performing manner.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of the invention patent application filed on February 22, 2018, with application number 201880014192.8 and title "Ontology-based Graph Query Optimization". Background Technology

[0002] Queries can be used to retrieve target information from a database. A query can include one or more parameters, which the database can use to identify stored information that matches those parameters. However, not all query parameter formulations produce the same performance characteristics, although such queries with similar parameter sets can ultimately return the same target information from the database.

[0003] These and other general considerations constitute the aspects disclosed herein. Similarly, while relatively specific problems may be discussed, it should be understood that these examples are not intended to address specific problems identified in the background art or elsewhere in this disclosure. Summary of the Invention

[0004] This disclosure describes examples of systems and methods for optimizing ontology-based graph queries. In these examples, ontology data associated with a graph or isolated sets may be collected (e.g., periodically, as the contents of the isolated sets change). The ontology data may include information related to the uniqueness of sources and / or attributes within the isolated sets. In another example, the ontology data may include topological information associated with the isolated sets, including but not limited to the average number of relations for a given source type. The ontology data may be stored in a data structure such that values ​​(e.g., those related to uniqueness and topology) can serve as keys for objects associated with them (e.g., sources, relations, or attributes).

[0005] The ontology data can be used to re-formulate queries to produce queries with higher performance than the original query when executed to retrieve target information from isolated sets. In one example, re-formulating a query could include reordering one or more parameters of a query related to sources, relationships, and / or attributes based on uniqueness information from the collected ontology data. In another example, the query can be re-formulated by modifying one or more source types to which it is anchored, based on topological information from the collected ontology data. As an example, the query can be re-formulated such that it is anchored to source types with fewer average relationships compared to the previously anchored source types. The re-formulated query can then be executed to identify target information in isolated sets, thereby identifying the same target information as the original query, but in a more efficient manner.

[0006] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary 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. Additional aspects, features, and / or advantages of the examples will be set forth in part in the description below, and in part will be apparent from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0007] Examples of non-restrictive and non-exhaustive approaches are illustrated with reference to the following figures.

[0008] Figure 1 The illustration provides an overview of an exemplary system for performing and optimizing queries within isolated collections.

[0009] Figure 2 The illustration provides an overview of an exemplary system for managing isolated sets of source identifiers and their correspondences.

[0010] Figure 3A An overview of an exemplary isolated set is illustrated.

[0011] Figure 3B-3E The illustration shows an exemplary query model that can be used to traverse isolated collections.

[0012] Figure 4 The illustration provides an overview of an exemplary system for performing ontology-based query optimization.

[0013] Figure 5 The illustration provides an overview of an exemplary method for generating ontology data for isolated sets.

[0014] Figure 6 The illustration provides an overview of an exemplary method for generating ontology data for isolated sets.

[0015] Figure 7 The illustration provides an overview of an exemplary method for re-formulating queries using ontology data.

[0016] Figure 8 This is a block diagram illustrating exemplary physical components of a computing device that can utilize various aspects of the present disclosure.

[0017] Figure 9A and Figure 9B It is a simplified block diagram of a mobile computing device that can be used to implement various aspects of the present disclosure.

[0018] Figure 10 It is a simplified block diagram of a distributed computing system in which the various aspects of this disclosure can be implemented.

[0019] Figure 11The illustration depicts a tablet computing device for performing one or more aspects of this disclosure. Detailed Implementation

[0020] Various aspects of this disclosure are described more fully below with reference to the accompanying drawings, which form part of this disclosure and illustrate specific exemplary aspects. However, different aspects of this disclosure may be implemented in many different forms and should not be construed as limited to the aspects set forth herein; rather, these aspects are provided so that this disclosure will be thorough and complete and will fully convey the scope of the aspects to those skilled in the art. The aspects may be practiced as methods, systems, or apparatuses. Therefore, the aspects may take the form of hardware implementations, entirely software implementations, or implementations combining software and hardware aspects. Therefore, the following detailed description should not be considered limiting.

[0021] This disclosure provides systems and methods for performing ontology-based graph query optimization. In examples, queries targeting target information within a graph or isolated set can be further formulated to generate queries that identify the same target information as the original query, but in a more efficient manner. Graphs can be used to store information, which can be represented using one or more sources and relations. To retrieve information from a graph, queries including one or more parameters can be executed to identify target information related to the one or more parameters within the graph. Unlike relational databases, queries within a graph rely on identifying relationships between sources and examining the attributes of relations and / or sources within the graph. Consequently, queries within a graph can be executed by traversing the graph using one or more "anchor" sources. However, even though the same or similar target information is ultimately identified in the graph, not all query formulation and / or execution strategies will produce the same performance characteristics. As an example, the type of source used to anchor the query or the order in which query parameters are evaluated may affect query performance. Thus, aspects of this disclosure involve collecting graph-related information and using the collected information to re-formulate queries such that the re-formulated query can have higher performance than the original query.

[0022] In some examples, a graph or isolated set may include sources and relationships. Sources can be identified by source identifiers, which may be persistent uniform source identifiers (URIs) pointing to a specific source. The source identifier can also be a uniform source locator (URL), a uniform source name (URN), or other suitable identifier or pointer to the source itself. In one example, the source may be stored within an isolated set. In another example, the source may be stored in a data set, while the associated source identifier may be stored within the isolated set. For example, the source may reside on a remote server, and the source identifier may be used to retrieve the source (e.g., the source may be stored on a remote web server, where the source identifier includes a URL). Identifying the location of a source may include: parsing the source identifier using, for example, regular expressions; providing one or more portions of the source identifier to a search utility; executing the source identifier; and so on. Relationships within the isolated set can identify the correlation between two or more sources in the isolated set. In some examples, an isolated set may be a uniform dimensional model (UDM), a graph, or other collection of sources and relationships.

[0023] Attributes can be associated with or stored through sources or relationships of isolated sets. In the example, the attribute may include a name and a value, allowing it to be used to store information related to a source or relationship. As an example, an "email" attribute for a "people" source (e.g., having the name "email") could store email addresses for people involved in the "people" source (e.g., as the value for the "email" attribute). In another example, a "relationship" source for a "family member" relationship could indicate that the "family member" relationship specifies a "sibling" relationship for the relationship indicated by the "family member" relationship. It will be appreciated that attributes can contain information beyond names and / or values ​​and can be stored as or associated with any type of information within a graph or isolated set.

[0024] Sources or source identifiers and / or relationships can be provided by the developer or other external sources. Such sources, source identifiers, and relationships are referred to herein as asserted sources, asserted source identifiers, and asserted relationships. Each isolated set can also be enriched to create additional relationships, and in some examples, additional source identifiers, by executing a set of rules relative to the data already in the isolated sets. The additional data generated by executing such a set of rules is referred to herein as inferred data, such as inferred relationships, inferred sources, and inferred source identifiers. Queries can then be executed against isolated sets that include both asserted data and inferred data to provide richer results than could be obtained from asserted data alone. The isolated sets can also be stored as a graph database, and the results of queries against the isolated sets can be displayed in a graph format, where sources are shown as nodes and relationships are shown as edges. As used herein, source identifiers and isolated sets of relationships between those sources or source identifiers can be referred to as “sets”. Furthermore, access to isolated sets can be controlled through various technologies, thereby providing additional security measures for the content in each isolated set, and each isolated set can have a different set of rules to generate unique and different inferred data to meet the specific needs of each application.

[0025] An isolated set can be queried to identify or retrieve target information (e.g., attributes, sources, and / or relationships) relevant to the query. The query may include one or more parameters or constraints related to the relationship type, the type or content of the source, or any other attribute of the relationship or source. In some examples, the parameters may relate to multiple sources (e.g., a friend relationship between friends, or a source common to multiple other unrelated sources, etc.). The parameters of the query may relate to one or more “anchor” sources or source types, which can be used when executing the query to identify context or initiate sources for query evaluation. As an example, an anchor source may be a source type or multiple source types associated with a relationship, such that sources within the isolated set matching one or more source types are identified and further evaluated based on the query parameters. Given a variety of possible sources and relationships that can be stored by or represented within an isolated set, executing such a query can be source-intensive. In the examples, some queries may perform poorly depending on the structure of the query (e.g., the order of parameters, the direction of the relationship, etc.) or the sources used to anchor the query. As a result, based on the aspects disclosed herein, queries can be further formulated to generate queries with higher performance than the original query while still identifying the same target information.

[0026] In the examples, query performance can be evaluated based on one or more of a variety of factors, including but not limited to: the amount of read operations performed, memory consumption, the number of intermediate results returned, or execution time. In some examples, performance metrics can be determined based on the actual query executed in the isolated set. In other examples, performance metrics can be estimated based on information related to the isolated set, information from previously executed queries, or other information. It will be appreciated that query performance can be determined based on any factors such that a query is considered "higher performing," "more efficient," or "optimal" relative to another query based on one or more such factors. Furthermore, query performance does not actually need to be optimal, but can instead be optimal in a probabilistic sense, such that a query can be expected or estimated to have higher performance than other queries. Therefore, while a particular query may actually execute suboptimally in one case, it may be considered to have higher performance on average or overall in some or most cases.

[0027] To generate higher-performance queries for target information within isolated sets, queries can be re-formulated based on ontology data associated with the isolated sets. This ontology data includes, but is not limited to, its topology (e.g., its structure, number of relationships between sources, number of sources of a given type, etc.) or the uniqueness or frequency of information within the graph (e.g., the frequency of attributes, sources, and / or relationships). In some examples, other information can be evaluated, such as indexes of information (e.g., indexes associated with the target information, indexes associated with one or more query parameters, or indexes associated with specific types of sources, relationships, or attributes within the isolated set), provided or query-related information, or data from previous queries (e.g., previously executed queries and / or related results, performance metrics, etc.). In examples, query re-formulation may include: changing the query order of parameters, removing or adding parameters, modifying query anchors, and other re-formulation techniques.

[0028] As an example, uniqueness information may include unique indexes for attributes within an isolated set and / or unique indexes for source types. Uniqueness indexes may be determined algorithmically (e.g., based on statistical models, calculated relative to the uniqueness of other observed attributes and / or sources), or they may be frequency measurements related to attributes or source types within the isolated set, as well as other metrics. In some examples, uniqueness indexes for various objects (e.g., sources, attributes, etc.) may be relative to each other and therefore comparable, allowing different objects to be compared based on their respective uniqueness indexes. In other examples, uniqueness indexes may be comparable only between similar objects (e.g., attribute uniqueness indexes may be comparable to other attribute uniqueness indexes, and source type uniqueness indexes may be comparable only between other source type uniqueness indexes). As a result, uniqueness indexes can be used to compare one or more parameters of a query to determine the query order in which attributes and source types can be evaluated.

[0029] In another example, topology information can include frequency information related to the average number of relations for the source types it involves. As an example, the average number of relations for each source type can be determined to compare source types and determine which source type is better for anchoring sources when executing a query. For instance, an isolated set might contain people sources and project sources, and there can be relations between each people source and each project source that a person works on. If people work on an average of ten projects, but each project has an average of 20 people working on it, then the average number of relations for the people source type will be 10, while the average number of relations for the project sources will be 20. Thus, the average number of relations for the sources can be used to determine which "direction" the query should be executed in, in order to evaluate sources with lower average number of relations. Therefore, anchoring queries based on people sources (with an average of ten relations) rather than project sources (with an average of 20 relations) may result in higher performance. This allows queries to be formulated such that the query direction is from people sources to project sources, rather than from project sources to people sources.

[0030] As will be appreciated, additional unique or topological information can be gathered to further formulate queries. In some examples, the type of information may depend on how the query is constructed or executed. For instance, the average number of relations for a particular source type may be relevant when a query is anchored to that source type. If a relation can be used as an anchor rather than a source to construct a query, it may be useful to quantify and evaluate the number of different source types that can be used with a given relation type when re-formulating the query. Furthermore, while the examples above involve people and project sources, it will be appreciated that the aspects disclosed herein can involve any domain, source type, and relation type.

[0031] At least some information for query re-formulation can be stored or collected before the query is re-formulated. As an example, ontology data (e.g., uniqueness information, topological information, etc.) related to isolated sets can be pre-generated and stored. In some examples, the ontology data can be updated when the contents of the isolated set change (e.g., when sources, relationships, or attributes are added, removed, or modified), periodically (e.g., at specific time intervals, in response to the occurrence of an event, etc.), or a combination thereof. As will be appreciated, other information related to isolated sets (e.g., the number of sources within the isolated set, interconnection metrics, etc.) can be collected, and ontology data can be updated or generated at other intervals or in response to any event.

[0032] In the examples, ontology data (or other information, such as index information or previous query data) may be stored in one or more data structures, such as a PATRICIA tree (the actual algorithm used to retrieve information encoded in an alphanumeric tree), a hash table, or any other data structure. In some examples, to facilitate efficient data storage and retrieval, each value stored in a data structure (e.g., a unique index, topology information, etc.) may be associated with a key (e.g., a hash value associated with the stored information, such as an attribute name, source type, or relation type) used when creating, updating, and retrieving values ​​based on the data structure. As will be appreciated, ontology data and other information used for re-formulating queries may be stored and retrieved in any manner without departing from the spirit of this disclosure.

[0033] Figure 1 The illustration provides an overview of an exemplary system for executing and optimizing queries within isolated sets. Exemplary system 100 may be a combination of interdependent components that interact to form an integrated whole for optimizing queries within isolated sets. In various aspects, system 100 may include hardware components (e.g., for executing / running an operating system (OS)) and / or software components (e.g., applications, application programming interfaces (APIs), modules, virtual machines, runtime libraries, etc.) running on the hardware. In certain aspects, system 100 may provide an environment for software components to execute, evaluate sets of operational constraints, and utilize the resources or facilities of system 100. In such aspects, the environment may include or be installed on one or more processing devices. For example, software (e.g., applications, operational instructions, modules, etc.) may run on processing devices such as computers, mobile devices (e.g., smartphones / phones, tablets, laptops, personal digital assistants (PDAs), etc.) and / or any other electronic devices. As an example of a processing device operating environment, references are made to... Figure 8-11The exemplary operating environment described herein. In other cases, components of the systems disclosed herein can be distributed across multiple devices and can be executed by multiple devices. For example, input can be made on a client device and information can be processed or accessed from other devices on the network (e.g., server devices, networked appliances, other client devices, etc.).

[0034] As presented, system 100 includes client devices 102A-C, a distributed network 104, and a distributed server environment including one or more servers, such as server devices 106A-C. Those skilled in the art will recognize that the size of systems such as system 100 can vary and can include more than [previous system description needed]. Figure 1 The components described herein may include more or fewer components. In some respects, the interfaces between the components of system 100 may occur remotely, for example, where the components of system 100 may be distributed across one or more devices in a distributed network.

[0035] In various aspects, client device 102A-C can be configured to receive input via user interface components or other input units. Examples of input may include voice, visual, touch, and text input. The interface components can enable the creation, modification, and navigation of various datasets and graph representations. In examples, various datasets may include (or be otherwise associated with), for example, source identifiers, source metadata, relational information, assertion relations, graph mapping information, query data, rule sets (such as, for example, inference rules), authorization information, authentication information, etc., as discussed in further detail below. Typically, datasets are stored on one or more server devices 106A-C and are accessible by client device 102A-C. However, in some examples, the datasets may be stored at least partially on one or more client devices within client device 102A-C. The underlying sources represented in the various datasets may be stored locally or in a data store accessible to client device 102A-C, such as a cloud storage application. In at least one example, the underlying sources represented in various datasets (or portions thereof) may be distributed across client devices 102A-C. For example, client device 102A (e.g., a mobile phone) may locally store a first portion of the sources represented in the dataset, client device 102B (e.g., a tablet computer) may locally store a second portion of the sources, and client device 102C (e.g., a laptop computer) may locally store the remaining portion of the sources represented in the dataset. In this example, client devices 102A-C may access all sources contained in the dataset, may access a subset of sources contained in the dataset, or alternatively may access any source contained in the dataset.

[0036] Client devices 102A-C can also be configured to query data storage for sources, including those corresponding to source identifiers in various datasets. In the example, client devices 102A-C can query content providers, such as server devices 106A-C, via distributed network 104. The query may include identifying the remote device where the source resides and / or determining whether the remote device (or a service / individual remote device) has authenticated access to the source. If access to the source has been authenticated, client devices 102A-C can retrieve an authentication indication from the remote device. Client devices 102A-C can use the authentication indication to provide access to one or more datasets among various datasets including corresponding source identifiers.

[0037] Server devices 106A-C can be configured to store and / or provide access to one or more sources. For example, server device 106A may be a web server, server device 106B may be a device including collaborative messaging tools and calendar applications, and server device 106C may be an email server. Each of these devices may include a repository of sources accessible via one or more authentication mechanisms. In the example, server device 106A-C may perform or monitor the authentication process upon receiving a request for a source. If authentication is successful, the authentication device may store or maintain an authentication indication for a specified time period. When the time period expires, server device 106A-C may remove or attempt to update the authentication indication. In the example, server device 106A-C may provide the authentication indication to a querying client device. In some aspects, server device 106A-C may also be configured to store at least a portion of various datasets and graphical representations, as discussed above.

[0038] Figure 2 The illustration shows an overview of an exemplary system 200 for managing isolated sets of source identifiers and their correspondences. The isolated set technology implemented in system 200 may include or be associated with... Figure 1 One or more of the delegated authentication technologies described herein. In an alternative example, a single device (including one or more components such as a processor and / or memory) may perform the processes described in systems 100 and 200, respectively.

[0039] about Figure 2System 200 may include: collection creation applications 202 and 204, collection environment 206, collections 208 and 210, entities 212 and 214, source identifiers 216, 218, 220, 222, 224, and 226, and sources 228, 230, 232, 234, 236, and 238. In various respects, collection creation applications 202 and 204 may be applications or services configured to create, infer, manipulate, navigate, and visualize various sources, relationships, and graphical representations. Collection creation applications 202 and 204 may define sets of relationships between sources (e.g., people, files, tasks, emails, documents, calendar events, etc.) and queries performed on these collections. Collection creation applications 202 and 204 may also provide rule sets for defining and storing rules for inferring one or more relationships in a collection, as well as graphical representations of the collection data. The defined rule sets may be stored within the collection itself, and in some examples, stored as metadata within the collection. In the example, collection creation applications 202 and 204 can be installed and executed on client devices or on one or more devices in a distributed environment. For example, collection creation application 202 can be installed on client device 102A, collection creation application 204 can be installed on client device 102B, and the collection creation service associated with server device 106A can be accessible to client device 102C.

[0040] In various ways, collection creation applications 202 and 204 can access file directories or execution environments, such as environment 206. Environment 206 can be co-located with the collection creation applications, or it can be located remotely from them. Environment 206 can provide access to one or more data collections, such as access to collections 208 and 210. In the example, access to a data collection can be determined using one or more license sets generated and / or maintained by collection creation applications 202 and 204. These license sets can differ across one or more data collections. As a result, it may be impossible to access one or more data collections (or their associated functionality) from one or more collection creation applications 202 and 204.

[0041] Sets 208 and 210 may respectively include source identifiers of assertions and isolated sets of corresponding relations. Relations in isolated sets can be defined manually or automatically derived using one or more rule sets. Isolated sets can be represented using a graphical structure that directly relates to the sources in the dataset and provides a way to retrieve relational data using a single operation. Each isolated set may include source identifiers unique to that isolated set. Alternatively, the isolated sets may include source identifiers contained in one or more alternative isolated sets. For example, as in... Figure 2As depicted herein, set 208 may include source identifiers 216, 218, 220, and 222, and set 210 may include source identifiers 220, 222, 224, and 226. Source identifiers 216, 218, 220, 222, 224, and 226 may correspond to and / or identify the location of one or more sources. As used herein, a source identifier references an existing source but is not itself a source. Exemplary types of source identifiers include, but are not limited to, uniform source identifiers (e.g., uniform source locator (URL), uniform source name (URN), etc.), IP addresses, memory or storage addresses, etc. Those skilled in the art will recognize that any type of identifier may be employed in the various aspects disclosed herein without departing from the scope of this disclosure. Identifying the location of a source may include parsing the source identifier using, for example, regular expressions, providing one or more portions of the source identifier to a search utility, executing the source identifier, etc. In all respects, accessing a data set does not guarantee access to a source identified by the source identifiers contained in each data set. For example, although a user can access and manipulate set 208, the user may not be authorized to access one or more underlying sources corresponding to the source identifiers in set 208.

[0042] Source providers 212 and 214 can be configured to store one or more sources and / or provide access to one or more sources. Thus, the source providers used herein can be data storage, cloud service providers, client computing devices, server computing devices, distributed device systems, such as, for example, enterprise networks, applications, software platforms (e.g., operating systems, databases, etc.), and so on. In various respects, source providers 212 and 214 can be (or access) various different data sources, such as content providers, data storage, various application datasets, etc. The data storage may include one or more sources corresponding to one or more source identifiers. For example, as in... Figure 2As depicted, source provider 212 can be a data store comprising various different types of sources, such as source 228 (e.g., document 1 (D1)) and source 230 (e.g., presentation 2 (P1)), and source provider 214 can be a contact management application that includes contact sources 232 (e.g., contact 1 (C1)), 234 (e.g., contact 2 (C2)), 236 (e.g., contact 3 (C3)), and 238 (e.g., contact 4 (C4)). In this example, source identifier 216 can correspond to source 228; source identifier 218 can correspond to source 230; source identifier 220 can correspond to source 232; source identifier 222 can correspond to source 234; source identifier 224 can correspond to source 236; and source identifier 226 can correspond to source 238. In some aspects, source providers 212 and 214 can be accessed by collection creation applications 202 and 204. Collection creation applications 202 and 204 can access source providers 212 and 214 to determine the existence of a source and / or retrieve information associated with the source (e.g., source metadata, source location, source identifier, license set, authentication data, etc.). The information retrieved from source providers 212 and 214 can be used to determine a set of source identifiers corresponding to one or more available sources. This set of source identifiers can be used to create asserted source identifiers and one or more isolated sets of corresponding relationships. As mentioned above, the source identifier can be or include a persistent URI for its corresponding source. For example, source identifier 216 can include a URI for the actual document (D1) 228. Thus, in such an example, a user can determine the location of document (D1) 228 from the set and, depending on authentication and access constraints, retrieve document (D1) 228. As another example, as in... Figure 2 As depicted, source provider 212 can be accessed by collection creation application 202. Collection creation application 202 can determine that source provider 212 includes at least sources 228 and 230, and can determine source identification information for each source. Based on the determined source identification information, source identifiers 216 and 218 can be applied / associated to sources 228 and 230 respectively, and are provided to environment 206. Environment 206 can then qualify source identifiers 216 and 218 for inclusion analysis of one or more isolated collections.

[0043] Figure 3A An exemplary isolated set 300 is illustrated, showing the source identifiers and corresponding relations of an assertion. The exemplary isolated set 300 includes source identifiers 302, 304, 306, 308, 310, 312, and 314, and relations 316, 318, 320, 322, 324, and 326. In various aspects, isolated set 300 can be generated and / or manipulated using set creation utilities included as part of a set creation application as discussed above. Figure 3A When presented in the graphical form depicted, each source identifier can be referred to as a "node," and each relationship can be referred to as an "edge." The collection creation utility can also use one or more rule sets to identify sources and / or determine the source type for the collection. These rule sets can include rules defined according to semantic web technologies such as Source Description Framework (RDF), RDF Schema (RDFS), the SPARQL protocol and RDF Query Language (SPARQL), Web Ontology Language (OWL), etc. For example, collection 300 includes source identifier 312 representing the underlying source, which is "email789" in the depicted example. Similarly, source identifier 304 represents the source document "Doc 123," and source identifier 302 represents the source task "Task123." Each source and relationship contained in the isolated collection 300 can be asserted by the developer through the collection creation application. For example, the developer can manually add each source identifier and the relationships between source identifiers. As an example, a developer can manually indicate that "taskl23" is a task on "Doc123," as represented in set 300 by the "taskOn" relation 316. Source identifiers and relations can also be asserted by external bots or applications created by the developer. For example, a plugin can be programmed to monitor activity in a browser or other applications to track application usage. Based on application usage, the plugin sends additional sources and relations to be included in set 300.

[0044] In contrast to asserted source identifiers and relations, the set creation utility can execute rule sets to determine additional relations and source types, referred to herein as “inferred relations” and “inferred source identifiers” or “inferred source types.” For example, when executing a rule set, the set creation utility can determine that source identifier 312 represents an email message and source identifier 304 represents a document. The generation of inferred relations and sources is discussed in further detail below.

[0045] Isolated set 300 also depicts source identifier 302 associated with source identifiers 304, 306, and 308, as well as source identifier 310. The set creation utility can determine that source identifier 302 represents a task to be performed on identifiers 304, 306, and 308. Based on this determination, the set creation utility can assign relations 316, 318, and 320 (e.g., “taskOn”) to define the association between source identifier 302 and source identifiers 304, 306, and 308. In other examples, as discussed above, relations 316, 318, and 320 can be asserted. Additional relations such as the “hasDiscussion” relation 322 may have been asserted manually by the developer or asserted based on a plugin of an email application that analyzes the content of email 101. Although specific types of sources and relations are as described in... Figure 3A As described herein, however, those skilled in the art will recognize that other types of sources and / or relationships may be included in isolated sets without departing from the spirit of this disclosure.

[0046] Figure 3B-3E The diagram illustrates an exemplary query model that can be used to traverse collection 300. In various aspects, queries can be executed via interfaces provided by collection creation utilities. Queries can be executed against one or more files and / or directories that include information such as source identifiers, source types, source metadata, license data, etc. Query results can be visualized graphically as one or more collections, such as collection 300. For example, the entire collection 300 dataset may include only those elements illustrated in collection 300 (e.g., source identifiers 302, 304, 306, 308, 310, 312, and 314, and relations 316, 318, 320, 322, 324, and 326). In this particular example, source identifier 312 may represent an email containing the subject "API Design," and source identifier 314 may represent an email containing the subject "Collection." The query "http: / / ... / collection300 / task123" can be executed against collection 300. The query results may include source identifier 302 and, as shown... Figure 3B The illustration is visualized. In Figure 3C In the original text, the query has been modified to "http: / / ... / collection300 / task123?$expand=taskOn" and executed against collection 300. The query results may include source identifiers 302, 304, 306, and 308, and relations 316, 318, and 320, and as shown in... Figure 3C The figures shown are visualized. Figure 3D In the original code, the query has been modified to "http: / / ... / collection300 / task123?$expand=taskOn($expand=attachmentOn)" and executed against collection 300. The query results can include source identifiers 302, 304, 306, 308, 312, and 314, as well as relations 316, 318, 320, 324, and 326, and as shown in... Figure 3D The figures shown are visualized. Figure 3EIn the original text, the query has been modified to "http: / / ... / collection300 / taskl23? ($expand=taskOn ($expand=attachmentOn)($filter=Subject eq'Sets'))" and executed against collection 300. Since only the source identifier includes the subject "Sets" 314, the query results can include source identifiers 302, 306, and 314, as well as relations 318 and 326, and as shown in... Figure 3E The image shown is visualized.

[0047] Figure 4 The diagram illustrates an exemplary system for performing ontology-based query optimization. 400 Overview. system 400 may include client device 402 and server device 404. In some examples, client device 402 may be one of client devices 102A-C, and server device 404 may be... Figure 1 One of the server devices 106A-C in the series. Although in Figure 4 A client device and a server device are shown, but it will be appreciated that multiple client devices, multiple server devices, or any combination thereof can be used to practice various aspects of this disclosure.

[0048] Server device 404 may include an isolated set 406, ontology data 408, an ontology data generation process 410, and a query re-formulation process 412. According to the aspects disclosed herein, isolated set 406 may store one or more sources and relations. Client device 402 may access the information stored by server device 404. In some examples, client device 402 may provide server device 404 with queries formulated using a query language (e.g., Cypher query language, SPARQL, etc.) to access the information stored by isolated set 406. It will be appreciated that although components 406-412 are depicted as part of server device 404, components 406-412 may be distributed across multiple computing devices, may be part of client device 402, or may be combined such that the functionality described herein associated with the multiple components 406-412 can be performed by a single component.

[0049] In the example, ontology data 408 may store data related to the isolated set 406, including but not limited to uniqueness information or topological information. Ontology data 408 may include one or more data structures. Ontology data 408 may be generated and maintained by ontology data generation process 410. In the example, ontology data generation process 410 may be performed by executing the following description regarding... Figure 5 and Figure 6The methods 500 and 600 illustrated in the figures discuss one or more operations for generating and storing information in ontology data 408. As described above, ontology data generation process 410 may update ontology data 408 when the contents of orphanage 406 change (e.g., by adding, removing, or updating sources, relations, or attributes), after a certain amount of time, or in response to events such as adding a user to an orphanage, importing data from another orphanage, identifying an orphanage 406 that can be queried for information, and other events.

[0050] The query re-formulation process 412 can receive queries for data stored in the isolated set 406. In the example, the query re-formulation process 412 can perform the following: Figure 7 The method 700 illustrated herein discusses one or more operations. According to the aspects disclosed herein, the query re-formulation process 412 can re-formulate a received query to generate a query that performs better than the original query when executed to identify target data in the isolated set 406. In the example, the query re-formulation process 412 can access ontology data 408 and use information from ontology data 408 when re-formulating the query. In some examples, the query re-formulation process 412 can access other data besides or as a substitute for ontology data 408. As an example, the query re-formulation process can access data stored by or associated with the isolated set 406. The query re-formulation process 412 can evaluate query parameters associated with the accessed data to generate an optimal query.

[0051] In the example, query re-formulation process 412 may evaluate uniqueness information (e.g., it may be stored in ontology data 408) for each attribute and source type of the query. Query re-formulation process 412 may compare the uniqueness information for each attribute and / or source type to determine whether there may be parameters for the query to be executed when a search is performed within the isolated set 406 (e.g., by executing...). Figure 7 The method 700 prioritizes operations 704-710 for higher performance. In some examples, uniqueness information for an attribute can be compared with uniqueness information for other attributes, and uniqueness information for a source type can be compared with uniqueness information for other source types. In other examples, uniqueness information for an attribute or source type can be compared with uniqueness information for other attributes or source types. As will be appreciated, query refactoring process 412 can evaluate the uniqueness information of other entities or information stored by or associated with isolated set 406.

[0052] In another example, query re-formulation process 412 can evaluate topological information (e.g., it can be stored in ontology data 408). Query re-formulation process 412 can use the topological information to determine the use of different source types (e.g., by executing...). Figure 7 Method 700 (operations 704-714, or one or more) re-formulates the query to determine if it performs better when anchored. In the example, the query may specify a relationship between a first source type and a second source type, such that the query is anchored using the first source type. Query re-formulation process 412 may determine that the second source type has fewer relationships on average than the first source type, and accordingly re-formulate the query such that it is anchored using the second source type instead, specifying the relationship between the second source type and the first type. It will be appreciated that topological information may contain other information and may be used to perform additional evaluations on one or more parameters of the query.

[0053] In some examples, the query re-formulation process 412 may use a variety of techniques to re-formulate the query. For example, the query re-formulation process 412 may use uniqueness information in conjunction with topological information when re-formulating the query. In another example, query re-formulation may evaluate uniqueness information to determine whether the query should be further processed, and if it is determined that the query should be further re-formulated, also evaluate topological information. The determination may include evaluating the expected performance of the query or the expected amount of time required to participate in additional processing, as well as other factors. In another example, the query re-formulation process 412 may evaluate other information as a substitute for or supplement to uniqueness information or topological information. The query re-formulation process 412 may also combine each other to evaluate any number of factors, or evaluate one or more factors first, and then evaluate one or more subsequent factors. In some examples, the query re-formulation process 412 may be performed multiple times, such that iterative re-formulation is based on similar or different factors considered in previous re-formulation iterations.

[0054] Figure 5 The illustration provides an overview of an exemplary method 500 for generating ontology data for isolated sets. Method 500 can be provided by a computing device (e.g., Figure 4This can be performed by a client device 402 or server device 404, or by a computing component (e.g., ontology data generation process 410). In the example, method 500 can be performed periodically (e.g., at specific time intervals in response to the occurrence of an event), when the contents of an isolated set are updated, when a query is received or evaluated, or at other periods, intervals, or events. In some examples, method 500 can be performed to analyze a larger isolated set in order to generate ontology data for a smaller but related isolated set. This ontology data can then be used when queries are formulated for the smaller and / or larger isolated sets. The smaller isolated set can be related because it contains similar sources, relations, and / or attributes. In the example, the smaller isolated set may have similar ontology characteristics to the larger isolated set (e.g., source types, relations, or attributes, or the similarity frequency of the smaller isolated set may include similar source types, etc.).

[0055] Method 500 begins with operation 502, where an isolated set can be received or accessed. In the example, the isolated set could be... Figure 4 The isolated set 406. The isolated set can be stored by the same or different computing devices performing method 500. In some examples, the isolated set can be stored by a storage system or data store, which can be provided by a single computing device or distributed across multiple computing devices.

[0056] At operation 504, the isolated set can be analyzed based on the aspects disclosed herein. As an example, the sources, relationships, and / or attributes of the isolated set can be analyzed. Analyzing the isolated set may include evaluating some or all of the isolated sets. In some examples, only a portion of the isolated set may be analyzed. In one example, determining which parts of the isolated set to analyze may be based on: which sources, attributes, or relationships might be queried, or whether analyzing a given portion of the isolated set would provide benefit when formulating a query. For example, analyzing attributes with less value (e.g., where each attribute is fairly general, such as a person's gender, associated with sources including US phone numbers). Country (Code, etc.) can provide less benefit than analyzing attributes that contain more unique information.

[0057] Moving to operation 506, ontology data can be generated based on the analysis of the isolated set. As discussed herein, the ontology data may include uniqueness information and / or topological information associated with the isolated set. The uniqueness information may include uniqueness indexes for source types and / or attributes within the isolated set, determined based on the analysis of other sources and attributes within the isolated set. As discussed above, the uniqueness indexes can be used to compare source types and / or attributes to determine how unique a source type or attribute is relative to other source types and / or attributes. The topological information can be determined by analyzing the sources and relations of the isolated set to determine the average number of relations for a given source type. As will be appreciated, although examples of ontology data, uniqueness information, and topological information are given, other information associated with isolated sets can be generated as ontology data without departing from the spirit of this disclosure.

[0058] In some examples, generating ontology data may also include generating one or more indexes associated with the information stored by the isolated collection. In one example, specific attributes or other information may be indexed (e.g., as a result of instructions received from a user or from an application or service). In another example, indexes may be generated based on heuristics (e.g., determining that certain attributes are frequently queried, determining that indexed attributes can provide performance benefits, etc.). As an example, indexes may be generated for values ​​associated with attributes, thereby allowing queries to be further formulated to evaluate which values ​​are typically associated with a given attribute, and to further evaluate the uniqueness of various parameters within the query based on such data. In one example, attribute indexes may be stored separately from the ontology data associated with the isolated collection discussed above, or stored as part of the aforementioned ontology data, as well as other storage techniques.

[0059] At operation 508, the ontology data can be stored for subsequent evaluation. In the example, the ontology data may be... Figure 4 The ontology data 408. The ontology data can be stored in one or more data structures, data stores, or storage systems. As discussed above, a PATRICIA tree can be used to store at least a portion of the ontology data, such that values ​​(e.g., uniqueness and / or topological information) can be associated with keys (e.g., hashes of relations, source types, or attributes) and stored in the PATRICIA tree. Although specific data structures have been described herein, those skilled in the art will recognize that other types of data structures can be used to store ontology data without departing from the scope of this disclosure. In the example, the stored data can be associated with the isolated sets, allowing for the re-formulation of queries (e.g., via...). Figure 4 The query is accessed via process 412. The process terminates at operation 508.

[0060] Figure 6 An exemplary method 600 for generating ontology data for isolated sets is illustrated. Method 600 can be derived from... Figure 4 The ontology data generation process 410 is executed. In some examples, method 600 can be executed when the contents of an isolated collection are changed (e.g., when a source, relation, or attribute is added, modified, or deleted), or method 600 can be executed occasionally.

[0061] Method 600 begins with operation 602, where information to be added to the orphaned collection can be received. This information can be received from a client device (e.g., ...). Figure 4 The client device (402) in the process receives the information, as does the service, application, or another source. It will be appreciated that while this example involves adding information to an orphaned collection, when modifying, accessing, or deleting information within an orphaned collection, one or more of the following operations can be performed.

[0062] At operation 604, the type of information can be determined. If the information is determined to be an attribute, the flow branches to operation 606, where a key can be generated based on the name of the attribute. In the example, the key can be a hash of the attribute value or other information associated with the attribute. Hash algorithms can be used to generate the hash, including but not limited to secure hash algorithms (e.g., SHA-1, SHA-128, SHA-256, etc.), MD5, or Whirlpool. It will be appreciated that any of a variety of techniques can be used to generate keys that can be used to store and retrieve information associated with the attribute.

[0063] Moving to operation 608, uniqueness information for the information can be generated. In the example, generating uniqueness information may include determining whether any pre-existing uniqueness information is available (e.g., in a data store storing ontology data or other storage system, such as...). Figure 4 (In the ontology data 408). If it is determined that pre-existing uniqueness information is available, the pre-existing uniqueness information can be accessed and used to generate a new or updated uniqueness index for the attribute. In another example, if no pre-existing uniqueness information exists, a new uniqueness index can be generated.

[0064] As discussed above, the uniqueness index can be generated algorithmically (e.g., based on a statistical model, calculated relative to the uniqueness of other observed attributes, etc.), or it can be a frequency measurement related to the frequency with which the attribute occurs within an isolated set, as well as other techniques. In some examples, uniqueness indexes for various objects (e.g., sources, attributes, etc.) can be relative to each other and therefore comparable, allowing comparisons to be made based on the respective uniqueness indexes of different objects. In other examples, uniqueness indexes can be comparable only between similar objects (e.g., an attribute uniqueness index can be comparable to other attribute uniqueness indexes, and a source type uniqueness index can be comparable only between other source type uniqueness indexes).

[0065] At operation 610, the uniqueness information associated with the key can be updated. In an example, updating the uniqueness information may include storing the uniqueness index generated at operation 608 in a data structure or other storage system. In some examples, the uniqueness index may be associated with or stored based on the key generated at operation 606 to facilitate the retrieval of the uniqueness information (e.g., via query re-creation process 412 when a query is re-formulated). The process terminates at operation 610.

[0066] Returning to operation 604, if the information is determined to be a source, the flow branches to operation 612, where a key can be generated based on the source type. In this example, the key could be the name of the source type or a hash of other information associated with the source. As discussed above, hash algorithms can be used to generate the hash. As will be appreciated, any of a variety of techniques can be used to generate keys that can be used to store and retrieve information associated with or related to the source type.

[0067] The process then moves to operation 608, where, as discussed above, unique information specific to the information can be generated. In the example, generating unique information specific to the source type may include determining whether any pre-existing unique information is available (e.g., in a data store or other storage system storing ontology data, such as...). Figure 4 (In the ontology data 408). If it is determined that pre-existing uniqueness information is available, the pre-existing uniqueness information can be accessed and used to generate a new or updated uniqueness index for the source type. In another example, if no pre-existing uniqueness information exists, a new uniqueness index can be generated.

[0068] As discussed above, the uniqueness index can be generated algorithmically, or it can be a frequency measurement related to the frequency with which the source type occurs in an isolated set, as well as other techniques. In some examples, uniqueness indexes for various objects (e.g., sources, attributes, etc.) can be relative to each other and therefore comparable, allowing comparisons to be made based on the respective uniqueness indexes of different objects. In other examples, uniqueness indexes can be comparable only between similar objects (e.g., an attribute uniqueness index can be comparable to other attribute uniqueness indexes, and a source type uniqueness index can be comparable only between other source type uniqueness indexes).

[0069] At operation 610, the uniqueness information associated with the key can be updated. In examples, updating the uniqueness information may include storing the uniqueness index generated in operation 608 in a data structure or other storage system. In some examples, the uniqueness index may be associated with or stored based on the key generated in operation 606 to facilitate the retrieval of the uniqueness information (e.g., via query re-formulation process 412 when a query is re-formulated). The process terminates at operation 610.

[0070] Returning to operation 604, if the information is determined to be a relationship, the flow branches to operation 614, where multiple sources associated with the relationship can be identified. In one example, identifying sources associated with the relationship may include accessing the isolated set to identify the associated sources. In another example, information related to the associated sources, as well as the information received at operation 602, may be provided.

[0071] Moving to operation 616, a key can be generated for each source based on its type. In the example, the key could be the name of the source type or a hash of other information associated with each source. As discussed above, hash algorithms can be used to generate the hash. As will be appreciated, any of a variety of techniques can be used to generate the keys, making them usable for storing and retrieving information associated with or related to each source.

[0072] The process then moves to operation 618, where topology information can be updated for each key. In this example, updating the topology information for each key may include determining whether any pre-existing topology information associated with each source type is available (e.g., in a data store or other storage system storing ontology data, such as...). Figure 4(In the ontology data 408). If it is determined that pre-existing topology information can be used for the source type, the pre-existing topology information can be accessed and used to generate updated topology information for the source type. In another example, if no pre-existing topology information exists, new topology information can be generated. As discussed above, the topology information may include information related to how many relations the source type has in the isolated set. The topology information may be: the average number of relations associated with a given source type, or other measures indicating how the source types are connected. The determined topology information for each source type may be stored in a data structure or other storage system. In some examples, the topology information may be associated with or based on the key for the source type generated at operation 616 to facilitate the retrieval of uniqueness information (e.g., through query re-formulation process 412 when re-formulating a query). The process terminates at operation 618.

[0073] Figure 7 The illustration provides an overview of an exemplary method 700 for re-formulating queries using ontology data. In this example, method 700 can be... Figure 4 The query re-formulation process 412 is executed in the middle. In some examples, method 700 can be performed by a computing device (e.g., Figure 4 This can be executed via client device 402 or server device 404. Method 700 can begin at operation 702, where a query for data in an isolated set can be received. The query can be formulated in a query language such as Cypher or SPARQL. The query can include one or more parameters or constraints related to the relation type, the type or content of the source, or any other attribute of the relation or source. In some examples, the parameters can relate to multiple sources (e.g., a friend relationship between friends or a common source for multiple other unrelated sources, etc.).

[0074] At operation 704, uniqueness information can be accessed for each parameter of the query. This is based on the aspects disclosed herein (e.g., using methods such as...). Figure 5 and Figure 6 The uniqueness information (as illustrated in methods 500 and / or 600) can be generated based on the content of the isolated set. In the example, the uniqueness information can be generated based on related isolated sets within the isolated set (e.g., where the isolated set includes a subset of data from the related isolated sets, or where the related isolated sets have similar source types, similar relationships, or other similarities). According to the aspects disclosed herein, the uniqueness information can be accessed from data structures or other data stores associated with or related to the isolated set.

[0075] Moving to operation 706, each parameter of the query can be evaluated based on the accessed uniqueness information. The evaluation may include generating a query order indicating the arrangement of one or more parameters for the query by ranking or sorting each parameter based on uniqueness. In one example, parameters related to similar objects (e.g., related to sources, relationships, or attributes) can be evaluated with respect to similarity parameters. In another example, each parameter can be evaluated with respect to other parameters (e.g., regardless of the objects the parameter relates to).

[0076] At operation 708, it can be determined whether re-formulating the query based on the uniqueness information is sufficient to produce a higher-performance query. In one example, this determination may include further analysis of the uniqueness information to determine whether the uniqueness information for each parameter indicates that one or more parameters are relatively unique (e.g., compared to a uniqueness threshold, compared to other parameters of the query, etc.). In another example, the determination may include evaluating how the query would likely be executed when executed against the isolated set (e.g., based on historical or statistical measures, comparisons of previous similar queries and results, etc.). It will be appreciated that any factors can be evaluated to determine whether the uniqueness information is sufficient to produce a higher-performance query.

[0077] If the uniqueness information is determined to be sufficient, the process branches to operation 710, where the query can be re-formulated based on an evaluation of the uniqueness information. In the example, re-formulating the query, according to various aspects disclosed herein, may include rearranging the parameters of the query, removing parameters of the query, or modifying the parameters of the query. Once the query has been re-formulated, it can be offered to another computing device, application, or service, etc. In the example, the query may be offered to execute within an isolated set, enabling the identification of target information. The process terminates at operation 710.

[0078] However, if it is determined that the uniqueness information is insufficient, the process will branch "No" to operation 712, where topology information can be evaluated. Evaluating the topology information may include identifying multiple source types to which the query is anchored and accessing the topology information associated with those multiple source types. As discussed above, the topology information can describe the average number of relations for a given source type, making it possible to determine which source types typically have fewer relations.

[0079] Moving to operation 714, the query can be re-formulated based on the evaluated topology information. Re-formulating the query may include modifying the source type to which the query is anchored, such that the new anchor is a source type with a lower average number of relations. In some examples, this may include reversing one or more relations specified within the query, or identifying one or more inverted relations (e.g., there may be an inferred relation representing the inverse relation of a relation specified in the query). In other examples, re-formulation may also include re-formulating the query based on the unique information discussed with respect to operation 710. As will be appreciated, although the above examples involve re-formulating the query by changing the source type to which the query is anchored, the query can be re-formulated by using topology information in other ways, including but not limited to: modifying one or more relations within the query, reversing the direction of relations within the query, etc. Once the query has been re-formulated, it can be offered to another computing device, application, or service, etc. In the example, the query can be offered to execute within an isolated set, allowing the target information to be identified. The process terminates at operation 714.

[0080] Figure 8-11 The associated description provides a discussion of various operating environments in which the aspects of this disclosure can be practiced. However, regarding Figure 8-11 The devices and systems illustrated and discussed are for illustrative purposes and are not intended to limit the wide range of computing device configurations that may be used to practice the aspects of this disclosure described herein.

[0081] Figure 8 This is a block diagram illustrating the physical components (e.g., hardware) of a computing device 800 that can implement the aspects of this disclosure. The computing device components described below are applicable to the computing devices described above, including client computing devices 102A-C and server computing devices 106A-C. In a basic configuration, computing device 800 may include at least one processing unit 802 and system memory 804. Depending on the configuration and type of the computing device, system memory 804 may include, but is not limited to: volatile storage devices (e.g., random access memory), non-volatile storage devices (e.g., read-only memory), flash memory, or any combination of such memories. System memory 804 may include an operating system 805 and one or more program modules 806 suitable for executing the aspects disclosed herein, such as ontology data generation component 824 and query re-formulation component 826. Operating system 805 may, for example, be adapted to control the operation of computing device 800. Furthermore, embodiments of this disclosure can be practiced in conjunction with graphics libraries, other operating systems, or any other applications, and are not limited to any particular application or system. This basic configuration in Figure 8The components within the dashed line 808 are illustrated. The computing device 800 may have additional features or functions. For example, the computing device 800 may also include additional data storage devices (removable and / or non-removable), such as, for example, a disk, optical disc, or magnetic tape. Figure 8 The diagram illustrates such an additional storage device, consisting of removable storage device 809 and non-removable storage device 810.

[0082] As described above, multiple program modules and data files can be stored in system memory 804. When executed on processing unit 802, program module 806 (e.g., application 820) can perform processes including but not limited to the aspects disclosed herein. Other program modules that can be used according to aspects of this disclosure may include: email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, etc.

[0083] Furthermore, embodiments of this disclosure can be practiced in electronic circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, embodiments of this disclosure can be practiced via a system-on-a-chip (SOC), wherein... Figure 8 Each or many of the components illustrated in the diagram can be integrated onto a single integrated circuit. Such a SoC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or “burned in”) onto a chip substrate as a single integrated circuit. When operated via the SoC, the functionality described herein regarding the ability to switch client protocols can be operated via dedicated logic integrated on a single integrated circuit (chip) along with other components of the computing device 800. Embodiments of this disclosure can also be practiced using other techniques capable of performing logical operations, such as AND, OR, and NOT, including but not limited to mechanical, optical, fluid, and quantum technologies. Furthermore, embodiments of this disclosure can be practiced within a general-purpose computer or in any other circuit or system.

[0084] The computing device 800 may also have one or more input devices 812, such as a keyboard, mouse, pen, voice or speech input device, touch or swipe input device, etc. It may also include one or more output devices 814, such as a display, speaker, printer, etc. The above devices are examples, and other devices may be used. The computing device 800 may include one or more communication connections 816 that allow communication with other computing devices 850. Examples of suitable communication connections 816 include, but are not limited to: radio frequency (RF) transmitters, receivers, and / or transceiver circuitry; universal serial bus (USB); parallel and / or serial ports.

[0085] As used herein, the term "computer-readable medium" can include computer storage media. Computer storage media can include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information, such as computer-readable instructions, data structures, or program modules. System memory 804, removable storage device 809, and non-removable storage device 810 are examples of computer storage media (e.g., memory storage devices). Computer storage media can include: RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other article of manufacture that can be used to store information and can be accessed by computing device 800. Any such computer storage medium may be part of computing device 800. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0086] Communication media can be embodied in computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves or other transmission mechanisms), and include any information transmission medium. The term "modulated data signal" can describe a signal having one or more characteristics that are set or altered in a manner that encodes information in the signal. By way of example, and not limitation, communication media can include wired media such as wired networks or direct-connected wired networks, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0087] Figure 9A and Figure 9B The illustration depicts a mobile computing device 900, such as a mobile phone, smartphone, wearable computer (e.g., a smartwatch), tablet computer, laptop computer, etc., which can be used to practice embodiments of the present disclosure. In some aspects, the client may be a mobile computing device. Reference Figure 9AThe illustration shows one aspect of a mobile computing device 900 for implementing various aspects. In a basic configuration, the mobile computing device 900 is a handheld computer with both input and output elements. The mobile computing device 900 typically includes a display 905 and one or more input buttons 910 that allow users to input information into the mobile computing device 900. The display 905 of the mobile computing device 900 can also be used as an input device (e.g., a touchscreen display). If included, an optional side input element 915 allows additional user input. The side input element 915 can be a rotary switch, a button, or any other type of manual input element. Alternatively, the mobile computing device 900 can incorporate more or fewer input elements. For example, in some embodiments, the display 905 may not be a touchscreen. In yet another alternative embodiment, the mobile computing device 900 is a portable telephone system, such as a cellular phone. The mobile computing device 900 may also include an optional keypad 935. The optional keypad 935 can be a physical keypad or a “soft” keypad generated on a touchscreen display. In various embodiments, the output elements include a display 905 for displaying a graphical user interface (GUI), a visual indicator 920 (e.g., a light-emitting diode), and / or an audio transducer 925 (e.g., a speaker) for displaying a graphical user interface (GUI). In some aspects, the mobile computing device 900 includes a vibration transducer for providing tactile feedback to a user. In another aspect, the mobile computing device 900 includes input and / or output ports, such as audio input (e.g., a microphone jack), audio output (e.g., a headphone jack), and video output (e.g., an HDMI port), for sending signals to or receiving signals from external devices.

[0088] Figure 9B This is a block diagram illustrating one aspect of the architecture of a mobile computing device. Specifically, the mobile computing device 900 can include a system (e.g., architecture) 902 to implement certain aspects. In one embodiment, the system 902 is implemented as a "smartphone" capable of running one or more applications (e.g., browser, email, calendar, contact manager, messaging client, game, and media client / player). In some aspects, the system 902 is integrated as a computing device, such as an integrated personal digital assistant (PDA) and cordless phone.

[0089] One or more applications 966 can be loaded into memory 962 and run on or associated with operating system 964. Examples of applications include: telephone dialer, email program, personal information management (PIM) program, word processing program, spreadsheet program, internet browser program, messaging program, etc. System 902 also includes a non-volatile storage area 968 within memory 962. Non-volatile storage area 968 can be used to store persistent information that should not be lost when system 902 is powered off. Applications 966 can use and store information in non-volatile storage area 968, such as emails or other messages used by email applications. A synchronization application (not shown) also resides on system 902 and is programmed to interact with a corresponding synchronization application residing on a host computer to keep the information stored in non-volatile storage area 968 synchronized with the corresponding information stored on the host computer. It should be appreciated that other applications can be loaded into memory 962 and run on the mobile computing device 900 described herein (e.g., search engine, extractor module, relevance ranking module, answer scoring module, etc.).

[0090] System 902 has a power supply 950, which can be implemented as one or more batteries. The power supply 950 may also include an external power source, such as an AC adapter or a power docking station, which replenishes or recharges the batteries.

[0091] System 902 may also include a radio interface layer 952 that performs the functions of transmitting and receiving radio frequency communications. Radio interface layer 952 facilitates wireless connectivity between system 902 and the "external world" via a communications operator or service provider. Transmissions to and from radio interface layer 952 are controlled by operating system 964. In other words, communications received by radio interface layer 952 can be propagated to application program 966 via operating system 964, and vice versa.

[0092] A visual indicator 920 can be used to provide visual notifications, and / or an audio interface 954 can be used to generate audible notifications via an audio transducer 925. In the illustrated embodiment, the visual indicator 920 is a light-emitting diode (LED), and the audio transducer 925 is a speaker. These devices can be directly coupled to a power supply 950 such that when activated, they remain on for the duration indicated by the notification mechanism, even if the processor 960 and other components may be turned off to conserve battery power. The LED can be programmed to remain on indefinitely until the user takes action to indicate the device's power-on status. The audio interface 954 is used to provide and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 925, the audio interface 954 can also be coupled to a microphone to receive audible input, such as for telephone conversations. According to embodiments of this disclosure, the microphone can also be used as an audio sensor to control notifications, as will be discussed below. System 902 may also include a video interface 956, which enables the operation of the vehicle camera 930 to record still images, video streams, etc.

[0093] The mobile computing device 900 implementing system 902 may have additional features or functions. For example, the mobile computing device 900 may also include additional data storage devices (removable and / or non-removable), such as disks, optical discs, or magnetic tapes. Figure 9B The diagram shows a non-volatile storage region 967.

[0094] As discussed above, data / information generated or captured by mobile computing device 900 and stored via system 902 can be stored locally on mobile computing device 900, or the data can be stored on any number of storage media, which can be accessed via radio interface layer 952 or via a wired connection between mobile computing device 900 and a separate computing device associated with mobile computing device 900 (e.g., a server computer in a distributed computing network such as the Internet). It should be appreciated that such data / information can be accessed by mobile computing device 900 via radio interface layer 952 or via a distributed computing network. Similarly, according to well-known data / information transmission and storage units, including email and collaborative data / information sharing systems, such data / information can be easily transferred between computing devices for storage and use.

[0095] Figure 10The illustration depicts one aspect of the architecture of a system for processing data received at a computing system from remote sources (such as personal computer 1004, tablet computing device 1006, or mobile computing device 1008, as described above). Content displayed at server device 1002 can be stored in different communication channels or other storage types. For example, various documents can be stored using directory service 1022, web portal 1024, email service 1026, instant messaging storage 1028, or social networking site 1030. Query re-selection component 1021 can be used by a client communicating with server device 1002, and / or ontology data generation component 1020 can be used by server device 1002. Server device 1002 can provide data to and from client computing devices such as personal computer 1004, tablet computing device 1006, and / or mobile computing device 1008 (e.g., smartphone) via network 1015. By way of example, the computer system described above can be embodied in a personal computer 1004, a tablet computing device 1006, and / or a mobile computing device 1008 (e.g., a smartphone). In addition to receiving graphics data that can be preprocessed at the graphics originating system or post-processed at the receiving computing system, any embodiment of these computing devices can obtain content from storage 1016.

[0096] Figure 11 An exemplary tablet computing device 1100 is illustrated, capable of performing one or more aspects disclosed herein. Furthermore, the aspects and functions described herein can operate on a distributed system (e.g., a cloud-based computing system), wherein application functions, memory, data storage and retrieval, and various processing functions can operate remotely to each other via a distributed computing network (such as the Internet or an intranet). User interfaces and various types of information can be displayed via an onboard computing device display or via a remote display unit associated with one or more computing devices. For example, user interfaces and various types of information can be displayed and interacted with on a wall on which user interfaces and various types of information are projected. Interaction with multiple computing systems on which embodiments of the invention can be practiced includes keystroke input, touchscreen input, voice or other audio input, gesture input, etc., wherein the associated computing device is equipped with detection (e.g., camera) functions for capturing and interpreting user gestures, etc., for controlling functions of the computing device.

[0097] As will be understood from the foregoing disclosure, one aspect of this technology relates to a system comprising: at least one processor; and a memory storing instructions, the instructions being a set of operations to be performed when executed by the at least one processor. The operations include: receiving a query for information stored in an isolated set, wherein the query includes one or more parameters; accessing ontology data associated with the isolated set, wherein the ontology data includes uniqueness information; using at least the uniqueness information to identify a uniqueness level for each of the one or more parameters; determining a query order for each of the one or more parameters based on the uniqueness information identified for the parameter; generating a higher-performance query for the query, wherein the higher-performance query includes one or more parameters in the determined query order; and executing the higher-performance query to identify the information in the isolated set. In the example, the ontology data also includes topological information, and the set of operations further includes: identifying anchors and one or more source types for the query, wherein the anchors are associated with at least one of the one or more source types; using the topological information to identify the average number of relations for each of the one or more source types; and using the average number of relations for each of the one or more source types to determine whether the anchor for the query should be associated with one or more source types from different groups of the one or more source types. In another example, generating the higher-performance query further includes: when it is determined that the anchor query should be associated with one or more source types from different groups of the one or more source types, generating the higher-performance query such that one or more source types from different groups of the one or more source types are associated with the anchor of the higher-performance query. In yet another example, the isolated set is associated with related isolated sets, and the related isolated sets are used to generate ontology data associated with the isolated sets. In yet another example, the ontology data associated with the isolated set is updated when information in the isolated set is added, modified, or deleted. In yet another example, the ontology data associated with the isolated set is updated periodically. In another example, the higher-performance query is more efficient than the received query when it is executed to identify information in the isolated set.

[0098] In another aspect, the technology relates to a computer-implemented method for generating ontology data for isolated sets. The method includes: receiving from a computing device a request including changes to the isolated sets; determining whether the changes are related to one of a source and an attribute; when the changes are determined to be related to a source, generating a key for the source; when the changes are determined to be related to an attribute, generating a key for the attribute; generating uniqueness information based on the changes, wherein the uniqueness information includes a uniqueness index; associating the generated uniqueness information with the key; and using the key to store the generated uniqueness information. In an example, the method further includes: determining whether the changes are related to a relation; when the changes are determined to be related to a relation, identifying a plurality of sources associated with the relation; for each of the plurality of sources: generating a key for the source based on a source type for the source; generating topology information, wherein the topology information indicates the average number of relations for the source type; associating the generated topology information with the key; and using the key to store the generated topology information. In another example, storing the generated uniqueness information includes using a PATRICIA tree to store the generated uniqueness information. In another example, storing the generated topology information includes using a PATRICIA tree. In yet another example, the uniqueness index indicates the relative level of uniqueness for one of the sources and attributes compared to at least one of the second source and the second attribute. In yet another example, the topology information indicates the relative level of connectivity for the source type compared to a second source type.

[0099] In another aspect, the technology relates to a computer-implemented method for generating higher-performance queries for information stored in isolated sets. The method includes: receiving a query for information stored in isolated sets; identifying an anchor and one or more source types for the query, wherein the anchor is at least one of the one or more source types; accessing ontology data associated with the isolated set, wherein the ontology data includes topological information; using the topological information to identify the average number of relations for each of the one or more source types; using the average number of relations for each of the one or more source types to determine whether the anchor for the query should be one or more source types from a different group among the one or more source types; when it is determined that the anchor query should be one or more source types from a different group among the one or more source types, generating a higher-performance query such that one or more source types from a different group among the one or more source types are the anchors for the higher-performance query; and executing the higher-performance query to identify the information in the isolated set. In one example, the ontology data also includes uniqueness information, and the method further includes: identifying one or more parameters of the query; using the uniqueness information to identify a uniqueness level for each of the one or more parameters; and determining a query order for each of the one or more parameters based on the uniqueness information identified for that parameter. In another example, generating the higher-performance query further includes re-formulating the query such that one or more parameters of the higher-performance query are in the determined query order. In yet another example, the isolated set is associated with related isolated sets, and ontology data associated with the isolated sets is generated based on the related isolated sets. In yet another example, the ontology data associated with the isolated set is updated when information in the isolated set is added, modified, or deleted. In yet another example, the ontology data associated with the isolated set is updated periodically. In this example, the ontology data is stored in a PATRICIA tree.

[0100] For example, the foregoing references to block diagrams and / or operational illustrations of methods, systems, and computer program products according to various aspects of this disclosure have described aspects of this disclosure. The functions / actions recorded in the blocks may not occur in the order shown in any flowchart. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions / actions involved.

[0101] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of this disclosure in any way. The aspects, examples, and details provided in this application are considered sufficient to convey the property and enable others to make and use the best mode of the claimed disclosure. The claimed disclosure should not be construed as limited to any aspect, example, or detail provided in this application. Whether shown and described in combination or separately, various features (structures and methods) are intended to be selectively included or omitted to produce embodiments with a particular set of features. Having been provided with the description and illustration of this application, those skilled in the art will envision variations, modifications, and substitutions falling within the broader scope of the overall inventive concept embodied in this application, without departing from the broader scope of the claimed disclosure.

Claims

1. A computer-implemented method for generating ontology data for isolated sets, the method comprising: Receive a request from a computing device to modify an isolated set, wherein the isolated set is a graph database including sources, attributes, and relations, and wherein the ontology data includes uniqueness information and / or topological information related to the isolated set; The contents of the isolated set are changed in response to the request; Determine whether the change is related to a source, attribute, or relationship; When it is determined that the change is related to the source, a key for the source is generated; When it is determined that the change is related to the attribute, a key for the attribute is generated; Based on the changes, updated uniqueness information is generated, wherein the generated updated uniqueness information includes a uniqueness index for the type of the source and / or a uniqueness index for the attribute. Associate the generated, updated unique information with the key; The key is used to store the generated, updated unique information; The parameter order of a query comprising multiple parameters is determined based on the uniqueness information, wherein the parameter identified by the uniqueness information as the most unique among the multiple parameters is used as the anchor resource for the query; and The queries are provided in the order of the parameters, wherein the queries identify target information in the isolated set.

2. The computer-implemented method according to claim 1 further includes: When it is determined that the change is related to a relationship, multiple sources associated with the relationship are identified; For each of the plurality of sources: Generate a key for the source based on the source type of the source; Generate topology information, wherein the topology information indicates the average number of relations for the source type; Associate the generated topology information with the key; and The key is used to store the generated topology information.

3. The computer-implemented method according to claim 1, wherein, Storing the generated updated uniqueness information includes using a PATRICIA tree to store the generated updated uniqueness information.

4. The computer-implemented method according to claim 2, wherein, Storing the generated topology information includes using a PATRICIA tree to store the generated topology information.

5. The computer-implemented method according to claim 1, wherein, The uniqueness index indicates the relative level of uniqueness for one of the source and the attribute compared to at least one of the second source and the second attribute.

6. The computer-implemented method according to claim 1, wherein, The key for the source is a hash of the name of the source.

7. The computer-implemented method according to claim 1, wherein, The key for the attribute is a hash of the attribute's value.

8. The computer-implemented method according to claim 7, wherein, The key for the attribute is used to store and retrieve information associated with the attribute.

9. The computer-implemented method according to claim 1, wherein, Generating the updated uniqueness information includes: Determine whether pre-existing uniqueness information is available; If it is determined that the pre-existing uniqueness information is available, then the pre-existing uniqueness information is used to generate the uniqueness index.

10. The computer-implemented method according to claim 9, wherein, Generating the updated uniqueness information further includes: If it is determined that the pre-existing uniqueness information is not available, a new uniqueness index is generated as the uniqueness index.

11. The computer-implemented method according to claim 9, wherein, The uniqueness index is generated by an algorithm based on at least one of the following: The observed uniqueness of a set of attributes, wherein the set of attributes includes at least the attribute; or Frequency measurements related to the frequency with which the attribute occurs within the isolated set.

12. The computer-implemented method according to claim 1, wherein, The updated unique information generated by the storage includes: The generated, updated uniqueness information is stored in a data store that includes ontology data for the isolated set.

13. A system for generating ontology data for isolated sets, comprising: processor; as well as A memory coupled to the processor, the memory including computer-executable instructions that, when executed by the processor, perform operations including: Receive a request from a computing device that includes operations related to an isolated set, wherein the isolated set is a graph database including sources, attributes, and relationships, and wherein the ontology data includes uniqueness information and / or topological information related to the isolated set; The operation is performed on the contents of the isolated set in response to the request; Determine whether the operation is related to a source, attribute, or relationship; When it is determined that the operation is related to the source, a key for the source is generated; When it is determined that the operation is related to the attribute, a key for the attribute is generated; Based on the operation, updated uniqueness information is generated, wherein the generated updated uniqueness information includes a uniqueness index for the type of the source and / or a uniqueness index for the attribute. Associate the generated, updated unique information with the key; The key is used to store the generated, updated unique information; The parameter order of a query comprising multiple parameters is determined based on the uniqueness information, wherein the parameter identified by the uniqueness information as the most unique among the multiple parameters is used as the anchor resource for the query; and The queries are provided in the order of the parameters, wherein the queries identify target information in the isolated set.

14. The system according to claim 13, wherein, The operation corresponds to at least one of the following: modifying, accessing, or deleting information within the isolated set.

15. The system according to claim 13, wherein: If the information type is determined to be the attribute, then the key is generated based on the name of the attribute.

16. The system according to claim 15, wherein, The key is further generated based on the value corresponding to the name of the attribute, and the key is a hash of the name and the value.

17. The system according to claim 13, wherein, The operation also includes: When it is determined that the operation is related to a relationship, multiple sources associated with the relationship are identified; For each of the plurality of sources: Generate a key for the source based on the source type of the source; Generate topology information, wherein the topology information indicates the average number of relations for the source type; Associate the generated topology information with the key; and The key is used to store the generated topology information.

18. The system according to claim 17, wherein, The key is a hash of the name of the source type.

19. The system according to claim 13, wherein, The isolated set identifies a set of sources and a set of relations, where each source in the set of sources is identified by a source identifier.

20. A computer-readable medium having instructions stored thereon, the instructions, when executed by a processor, causing the processor to perform the method according to any one of claims 1-12.

Citation Information

Patent Citations

  • Storage method and management system for high-association big data

    CN106227800A

  • System and method for network access without reconfiguration

    US6857009B1

  • Method and apparatus for identifying and processing changes to management information

    US7233957B1