Graph linked infrastructure

Abstract

The present disclosure relates generally to computing and / or communication infrastructure, and more particularly to infrastructure for graph linking.

Description

Background Art

[0001] Field:

[0002] The present disclosure generally relates to computing and / or communication infrastructure, and more particularly, to infrastructure for graph linking.

[0003] Information:

[0004] The Internet is ubiquitous. The World Wide Web or simply the Web provided by the Internet is growing rapidly, at least in part because a large amount of content seems to be added every day. A wide variety of content in the form of stored signals can be continuously acquired, identified, located, retrieved, collected, stored, transmitted, etc., such as, for example, text files, images, audio files, video files, web pages, and / or measurements of physical phenomena. More and more, content is acquired, collected, transmitted, etc. through multiple electronic devices, such as embedded computing devices that utilize the existing Internet and / or similar infrastructure as part of the so-called "Internet of Things" (IoT) via various protocols, domains, and / or applications. The IoT can generally include a system of interconnected and / or Internet physical computing devices that can be uniquely identified, for example, via an assigned Internet Protocol (IP) address. For example, a device (such as an IoT type device) can include computing resources embedded in the hardware to facilitate and / or support the device's ability to acquire, collect, process, and / or transmit content through one or more communication networks. For example, IoT type devices can include a variety of embedded devices, such as automotive sensors, bi-chip transponders, cardiac monitoring implants, thermostats, kitchen appliances, locks or similar fastening devices, solar panel arrays, home gateways, and / or controllers.

[0005] In some instances, for example, challenges may be faced in improving communication performance between and / or among IoT type devices and / or other types of electronic devices. For example, aspects of communication related to IoT type devices and / or other types of electronic devices may involve processing one or more queries that may be generated on IoT type devices and / or other types of electronic devices. Brief Description of the Drawings

[0006] The claimed subject matter is specifically pointed out and distinctly claimed in the concluding portion of the specification. However, the organization and / or method of operation and its objectives, features, and / or advantages are best understood by reference to the following detailed description when read in conjunction with the drawings, in which:

[0007] Figure 1is a schematic block diagram depicting an embodiment of an example system including one or more server computing devices and / or one or more IoT type devices according to an embodiment.

[0008] Figure 2 is a schematic block diagram depicting an embodiment of an example Internet of Things (IoT) type device according to an embodiment.

[0009] Figure 3 depicts an example diagram implemented across multiple API services according to an embodiment.

[0010] Figure 4 is a schematic diagram depicting an example federated graph according to an embodiment.

[0011] Figure 5 is a schematic block diagram depicting another federated method according to an embodiment.

[0012] Figure 6 is an illustration depicting an example query incorporating a graph linking method according to an embodiment;

[0013] Figure 7 is a schematic block diagram of an example device, system, and / or process for graph linking of a query for linking multiple graph patterns according to an embodiment;

[0014] Figure 8 is a schematic block diagram of an example device, system, and / or process for graph linking according to an embodiment, where a graph pattern is linked to multiple graphs;

[0015] Figure 9 is a flowchart showing an example process for graph linking according to an embodiment; and Figure 10 depicts a schematic of an implementation of an example computing and / or communication environment according to an embodiment.

[0016] In the following detailed description, reference is made to the accompanying drawings, which form a part of the present invention, and in which like reference numerals may refer to corresponding and / or similar parts throughout. It should be understood that the drawings are not necessarily drawn to scale, such as for simplicity and / or clarity of illustration. For example, the dimensions of some aspects may be exaggerated relative to other aspects. Further, it should be understood that other embodiments may be utilized. In addition, structural and / or other changes may be made without departing from the claimed subject matter. References throughout this specification to "the claimed subject matter" refer to the subject matter intended to be covered by one or more claims or any part thereof, and do not necessarily refer to a complete set of claims, a specific combination of sets of claims (e.g., method claims, apparatus claims, etc.), or a specific claim. It should also be noted that directions and / or references (e.g., such as up, down, top, bottom, etc.) may be used to facilitate discussion of the drawings and are not intended to limit the application of the claimed subject matter. Accordingly, the following detailed description should not be considered limiting of the claimed subject matter and / or equivalents.

[0017] Specific Implementations

[0018] References throughout this specification to an implementation, implementations, an embodiment, embodiments, etc. mean that the specific features, structures, and / or characteristics, etc. described with respect to the specific implementation and / or embodiment are included in at least one implementation and / or embodiment of the claimed subject matter. Thus, the appearance of such phrases (e.g., throughout this specification in various places) does not necessarily refer to the same implementation and / or embodiment or to any one specific implementation and / or embodiment. In addition, it should be understood that the specific features, structures, and / or characteristics, etc. described can be combined in various ways in one or more implementations and / or embodiments and are thus within the scope of the expected claims. Of course, generally speaking, as is always the case with the specification of a patent application, these and other issues are subject to change in the specific context of use. In other words, throughout the patent application, the specific context in which the description and / or use occur provides helpful guidance for making reasonable inferences; however, likewise, without further qualification, "in this context" generally refers to the context of this patent application.

[0019] As described above, the World Wide Web or simply the Web provided by the Internet is growing rapidly, at least in part because a large amount of content seems to be added every day. A wide variety of content in the form of stored signals can be continuously acquired, identified, located, retrieved, collected, stored, transmitted, etc., such as, for example, text files, images, audio files, video files, web pages, and / or measurements of physical phenomena. Increasingly, content is acquired, collected, transmitted, etc. by multiple electronic devices, such as embedded computing devices that utilize the existing Internet and / or similar infrastructure as part of the so-called "Internet of Things" (IoT) via various protocols, domains, and / or applications. The IoT can generally include a system of interconnected and / or Internet physical computing devices that can be uniquely identified, for example, via an assigned Internet Protocol (IP) address. For example, a device (such as an IoT type device, etc.) can include computing resources embedded in the hardware to facilitate and / or support the device's ability to acquire, collect, process, and / or transmit content through one or more communication networks. In this context, "IoT type device" and / or the like refers to one or more electronic and / or computing devices that can utilize the existing Internet and / or similar infrastructure as part of the IoT via various applicable protocols, domains, applications, etc. In a specific implementation, IoT type devices can, for example, include various embedded devices, such as automotive sensors, biochip transponders, heart monitoring implants, thermostats, kitchen appliances, locks or similar fastening devices, solar panel arrays, home gateways, and / or controllers, etc. Although the embodiments described herein may relate to IoT type devices, the claimed subject matter is not limited to the scope of these aspects. For example, although IoT type devices may be described, the claimed subject matter is intended to include the use of any of a wide variety of electronic device types, including a wide variety of computing device types.

[0020] In some instances, for example, in improving communication performance between and / or among IoT type devices and / or other electronic device types, challenges may be faced. For example, aspects of communication related to IoT type devices and / or other electronic device types may involve processing one or more queries that may be generated on IoT type devices and / or other electronic device types.

[0021] The terms "electronic content", "content", etc. used in this document should be construed broadly and refer to signals (e.g., such signal packets) and / or states (such as physical states on a memory device, etc.), but are otherwise adopted in a manner independent of formats (such as any expression, representation, implementation, and / or communication, etc.). For example, content can include any information, knowledge, and / or experience again in the form of signals and / or states, physical or other forms. In this context, "electronic" or "online" content refers to content in the following form: Although not necessarily perceivable by humans (e.g., via human senses, etc.), it can still be converted into a form that can be so perceived (such as visually, tactilely, and / or auditorily, etc.). Non-limiting examples can include text, audio, images, video, security parameters, combinations, etc. Thus, content can be electronically stored and / or transmitted, such as before or after being perceived by human senses, etc. Generally, it can be understood that electronic content can be referred to in a specific discussion, although in a specific context, the term "content" can be adopted for the convenience of discussion. Specific examples of content can include, for example, computer code, data, metadata, messages, text, audio files, video files, data files, or web pages, etc. Of course, the claimed subject matter is not intended to be limited to these specific examples.

[0022] Figure 1 is a schematic diagram showing features associated with an implementation of an example operating environment 100 that can facilitate and / or support one or more operations and / or techniques for updating and / or managing an infrastructure for IoT-type devices (generally shown at 102 herein). As indicated, IoT is generally a system of interconnected and / or internet-connected physical devices, where computing can be embedded in the hardware to facilitate and / or support the ability of the devices to acquire, collect, and / or transmit content through one or more communication networks, for example, sometimes without human participation and / or interaction. As mentioned, IoT-type devices can include a variety of fixed and / or mobile devices, such as automotive sensors, biometric chip transponders, heart monitoring implants, kitchen appliances, locks or similar fastening devices, solar panel arrays, home gateways, smart meters, smartphones, cellular phones, security cameras, wearable devices, thermostats, Global Positioning System (GPS) transceivers, personal digital assistants (PDAs), virtual assistants, laptop computers, personal entertainment systems, tablet personal computers (PCs), PCs, personal audio and / or video devices, personal navigation devices, and / or the like.

[0023] It should be appreciated that the operating environment 100 is described herein as a non-limiting example that may be implemented, in whole or in part, in the context of various wired and / or wireless communication networks and / or any suitable portion and / or combination of such networks. For example, these or similar networks may include one or more public networks (e.g., the Internet, the World Wide Web), private networks (e.g., an intranet), wireless wide area networks (WWANs), wireless local area networks (WLANs, etc.), wireless personal area networks (WPANs), telephone networks, cable television networks, Internet access networks, fiber optic communication networks, waveguide communication networks, and / or the like. It should also be noted that the claimed subject matter is not limited to a specific network and / or operating environment. Thus, for a particular implementation, one or more operations and / or techniques for updating and / or managing IoT-type devices may be performed, at least in part, in an indoor environment and / or an outdoor environment or any combination thereof.

[0024] Thus, as shown, in a particular implementation, one or more IoT-type devices 102 may receive and / or obtain an SPS signal 104, for example, from satellite positioning system (SPS) satellites 106. In some instances, the SPS satellites 106 may be from a single global navigation satellite system (GNSS), such as the GPS or Galileo satellite system. In other instances, the SPS satellites 106 may be from multiple GNSSs, such as (but not limited to) GPS, Galileo, Glonass, or the Compass satellite system. In certain implementations, the SPS satellites 106 may be from any one of several regional navigation satellite systems (RNSSs), just a few examples being, for instance, WAAS (Wide Area Augmentation System), EGNOS (European Geostationary Navigation Overlay Service), QZSS (Quasi-Zenith Satellite System), etc.

[0025] Sometimes, one or more IoT type devices 102 may, for example, transmit wireless signals to and / or receive wireless signals from a suitable wireless communication network. In one example, one or more IoT type devices 102 may communicate with a cellular communication network by transmitting wireless signals to and / or receiving wireless signals from one or more wireless transmitters (such as, for example, base transceiver 108) capable of transmitting and / or receiving wireless signals via a wireless communication link 110. Similarly, one or more IoT type devices 102 may transmit wireless signals to and / or receive wireless signals from local transceiver 112 via, for example, wireless communication link 114. Depending on the implementation, base transceiver 108, local transceiver 112, etc. may be of the same or similar type, for example, and / or may represent different types of devices, such as access points, wireless beacons, cellular base stations, femtocells or access transceiver devices, etc. Similarly, local transceiver 112 may include (for example) a wireless transmitter and / or receiver capable of transmitting and / or receiving wireless signals. For example, sometimes, wireless transceiver 112 is capable of transmitting and / or receiving wireless signals from one or more other terrestrial transmitters and / or receivers.

[0026] In a particular implementation, local transceiver 112 may, for example, be able to communicate with one or more IoT type devices 102 via wireless communication link 114 over a shorter distance than the distance established via base transceiver 108 over wireless communication link 110. For example, local transceiver 112 may be located indoors or in a similar environment and / or may provide access to a wireless local area network (WLAN, for example, IEEE Std. 802.11 network, etc.) and / or a wireless personal area network (WPAN, for example, network, etc.). In another example implementation, local transceiver 112 may include a femtocell and / or picocell capable of facilitating communication via link 114 according to an applicable cellular or similar wireless communication protocol. Again, it should be understood that these are only examples of networks that may communicate with one or more IoT type devices 102 via a wireless link, and the claimed subject matter is not limited in this regard. For example, in some instances, the operating environment 100 may include a larger number of base transceivers 108, local transceivers 112, networks, terrestrial transmitters and / or receivers, etc.

[0027] In an implementation, one or more IoT type devices 102, base station transceivers 108, local transceivers 112, etc. may communicate with one or more servers referenced herein at 116, 118, and 120 via a network 122 (such as, via one or more communication links 124, etc.). The network 122 may include any combination of, for example, wired and / or wireless communication links. In a specific implementation, the network 122 may include, for example, an Internet Protocol (IP)-type infrastructure that can directly facilitate or support communication between one or more IoT type devices 102 and one or more servers 116, 118, 120, etc. via the local transceiver 112, base station transceiver 108, etc. In another implementation, the network 122 may include, for example, a cellular communication network infrastructure, such as a base station controller and / or a main switching center, to facilitate and / or support mobile cellular communication with one or more IoT type devices 102. The servers 116, 118, and / or 120 may include any suitable server or combination thereof capable of facilitating or supporting one or more operations and / or techniques discussed herein. For example, the servers 116, 118, and / or 120 may include one or more update servers, backend servers, management servers, archive servers, location servers, positioning assistance servers, navigation servers, map servers, crowdsourcing servers, network-related servers, or the like.

[0028] Even though a certain number of computing platforms and / or devices are shown herein, any number of suitable computing platforms and / or devices may be implemented to facilitate and / or support one or more technologies and / or processes associated with the operating environment 100. For example, sometimes, the network 122 may be coupled to one or more wired and / or wireless communication networks (such as, WLAN, etc.) to enhance the coverage area for communication with one or more IoT type devices 102, one or more base station transceivers 108, local transceivers 112, servers 116, 118, 120, etc. In some cases, for example, the network 122 may facilitate and / or support a femtocell-based operating coverage area. Again, these are only example embodiments, and the claimed subject matter is not limited in this regard.

[0029] In context, an "IoT type device" refers to one or more electronic and / or computing devices that can utilize an existing Internet or similar infrastructure as part of a so-called "Internet of Things" or IoT, such as via various applicable protocols, domains, applications, etc. As indicated, the IoT is generally a system of interconnected and / or Internet-connected physical devices, where computing can be embedded in the hardware to facilitate and / or support the device's ability to acquire, collect, and / or transmit content via one or more communication networks, for example, sometimes without human participation and / or interaction. The IoT type device 102 can include, for example, a variety of fixed and / or mobile devices, such as automotive sensors, biometric chip transponders, heart monitoring implants, kitchen appliances, locks or similar fastening devices, solar panel arrays, home gateways, smart meters, smart phones, cellular phones, security cameras, wearable devices, thermostats, global positioning system (GPS) transceivers, personal digital assistants (PDAs), virtual assistants, laptop computers, personal entertainment systems, tablet personal computers (PCs), PCs, personal audio or video devices, personal navigation devices, and / or the like, to name just a few non-limiting examples. Typically, in this context, a "mobile device" refers to an electronic and / or computing device that can have a changing location or place over time, and / or a fixed device refers to a device that can have a location or place that generally does not change. In some instances, an IoT type device (such as the IoT type device 102, etc.) may be capable of being uniquely identified, for example, via an assigned Internet protocol (IP) address (as one specific example), and / or having the ability to communicate (e.g., receive and / or transmit electronic content via one or more wired and / or wireless communication networks).

[0030] Figure 2 FIG. 200 is an illustration of an embodiment of an example specific IoT device. Of course, the scope of the claimed subject matter is not limited to the specific configurations and / or arrangements of the components depicted and / or described for the example devices herein. In an embodiment, an IoT type device (such as 200) can include one or more processors (such as processor 210), and / or can include one or more communication interfaces (such as communication interface 220). In an embodiment, one or more communication interfaces (such as communication interface 220) can enable wireless communication between an electronic device (such as IoT type device 200) and one or more other computing devices. In an embodiment, the wireless communication can occur substantially according to any of a wide variety of communication protocols, such as those mentioned herein.

[0031] In a specific implementation, an IoT type device (such as, IoT type device 200) may include a memory (such as, memory 230). In a specific implementation, memory 230 may include, for example, non-volatile memory. Further, in a specific implementation, the memory (such as, memory 230) may have executable instructions stored therein, such as executable instructions for, for example, one or more operating systems, communication protocols, and / or applications. The memory (such as, 230) may further store specific instructions (such as, software (SW) and / or firmware (FW) code 232) that may be updated via one or more of the example implementations and / or embodiments described herein. Further, in a specific implementation, an IoT type device (such as, IoT type device 200) may include a display (such as, display 240) and / or one or more sensors (such as, one or more sensors 250). As used herein, "sensor" and / or the like refers to a device and / or component that can respond to a physical stimulus (such as, for example, heat, light, sound pressure, magnetic force, specific movement, etc.) and / or can generate one or more signals and / or states in response to a physical stimulus. Example sensors may include (but are not limited to) one or more accelerometers, gyroscopes, thermometers, magnetometers, barometers, light sensors, proximity sensors, heart rate monitors, perspiration sensors, hydration sensors, respiration sensors, cameras, microphones, etc., and / or any combination thereof.

[0032] In a specific implementation, IoT type device 200 may include one or more timers and / or counters and / or similar circuits such as circuit 260. In an embodiment, one or more timers and / or counters and / or the like may track one or more aspects of device performance and / or operation. For example, in a specific implementation, the timer, counter, and / or other similar circuits may be used by IoT type device 200 at least in part to determine, for example, a measurement of fitness, and / or otherwise generate feedback content related to test results.

[0033] Although Figure 2Depicts a specific example implementation of an IoT type device (such as, IoT type device 200), but other embodiments may include other types of electronic and / or computing devices. Example types of electronic and / or computing devices may include, for example, any digital electronic device among a variety of digital electronic devices, including but not limited to desktop and / or laptop computers, high-definition televisions, digital video players and / or recorders, game consoles, satellite TV receivers, cellular phones, tablet devices, wearable devices, personal digital assistants, mobile audio and / or video playback and / or recording devices, or any combination of the foregoing.

[0034] In an embodiment, a client computing device (e.g., via the execution of an application) (such as, IoT type device 200) may generate one or more queries, such as queries that may include content requests. There may be various query languages to formulate queries for the specific content being sought. Examples of query languages may include Structured Query Language (SQL), XML Path Language (XPATH), and / or GraphQL (Graph Query Language), but these are merely illustrative examples. The terms Structured Query Language, SQL, and / or similar terms are intended to refer to any currently known and / or later developed version of the Structured Query Language. Similarly, the terms XML Path Language, XPATH, and / or similar terms are intended to refer to any currently known and / or later developed version of the XML Path Language. Likewise, the terms GraphQL and / or similar terms are intended to refer to any currently known and / or later developed version of the GraphQL query language. Additionally, as used herein, the terms query, query request, query, etc. are intended to refer to one or more queries formulated in a specific query language (such as, for example, one of the foregoing languages). Moreover, although the embodiments and / or implementations described herein may refer to queries, other embodiments and / or implementations may include other types of operations, such as, for example, mutations.

[0035] In an embodiment, GraphQL may include a query language for an application programming interface (API) and / or a server-side runtime service that is used to execute queries using a type system and / or the like that can be defined for the content being sought. In a specific implementation, GraphQL may not be bound to any specific database and / or storage engine, and / or may alternatively be supported by existing code and / or content.

[0036] A GraphQL schema can, for example, include specifications such as content types and / or sets of structures, nesting levels, and / or fields, which can indicate available content such as to be queried. Similarly, a GraphQL query path can specify that for certain content fields, a path can be followed and / or traversed to locate such content, for example, in a repository. A GraphQL query shape can likewise specify relationships within a GraphQL schema, such as for content types, etc., including, for example, mutual relationships, nesting, and / or other forms of association.

[0037] As used herein, "graph" and / or the like represents a structure that can include points connected by, for example, edges. Additionally, "data graph" and / or the like represents a model of content (e.g., data) obtainable from a service structured as a graph. In an implementation, a graph can have multiple attributes. For example, in an implementation, a graph can include "points" and / or the like that can represent objects and / or attributes. For example, a point can optionally contain binary or text data. For example, a graph can also include "edges" and / or the like that can represent relationships. Moreover, in an implementation, for example, a graph can include queries that can terminate at certain points and / or change the graph according to the following: a) a query can add or remove points; b) a query can add or remove edges connecting points; and / or c) a query can add, remove, or modify data attached to points. In an implementation, one or more points can be marked as roots for different query categories. For example, a query root can be provided such that a query starting at the query root provides but does not modify graph content. In an implementation, for example, a separate mutation root can be identified such that a query starting at the mutation root can modify and read graph data.

[0038] As used herein, "graph schema" and / or the like represents a description of the expected structure of a data graph. In an implementation, rather than enumerating points and edges (e.g., representations that may be as large or even often much larger than the content being sought itself), a graph schema can provide a type system for data graphs with different example properties. For example, a graph schema can assign a "type" to points within a data graph (e.g., each point in a particular implementation). In an implementation, for example, the schema can specify constraints that some point p must satisfy to be included within a type, including but not limited to: a) the existence of one or more edges that satisfy any criteria starting from p; and b) the existence and / or shape of the content contained within the point. Additionally, for example, a graph schema can assign a "field" to an edge within a data graph (e.g., in a particular implementation, each edge). For example, a field can include a generalization of the edge. In an implementation, while an edge can describe a connection between specific objects in a data graph, a field can describe a connection between types. That is, a field can represent, for example, a category of relationships that can be represented between objects. Moreover, in an implementation, a field can be parameterized to represent a wider range of relationships. For example, the schema can define a User.friends(first:Int)->[User] field, which can connect a user to a list of their friends, the size of which is limited to a specified number of friends. This example field can represent an infinite number of edges, including "the first friend of User A on the service", "the first two friends of User A", "the first three friends of User A", etc.

[0039] In an implementation, a graph schema can define a "type graph", which can represent relationships between types. For example, within a type graph, points can include types and / or edges, and types and / or edges can include "casts" that represent relationships that types can have with each other. In a particular implementation, given two types A and B, the following relationships are possible: a) If all points within B also fall within A, then A can include a proper superset of B. In this case, B can have an unconditional edge to A, and A can have a conditional edge to B; b) If some but not all points within B are in A and some but not all points within A are in B, then A can overlap with B. In this case, A and B can have conditional edges to each other; and / or c) If there are no shared points between A and B, then A and B can be non-overlapping. In this case, there are no edges between A and B. In an implementation, for example, there can be multiple possible textual representations (e.g., encodings) of a graph schema.

[0040] In an implementation, a GraphQL service can be generated at least in part by defining types and / or fields on those types. For example, a GraphQL service that indicates the identity of a logged-in user (e.g., "me") and what the name of that logged-in user might look like could be as follows:

[0041] type Query{

[0042] me:User

[0043] }

[0044] type User{

[0045] id:ID

[0046] name:String

[0047] }

[0048] In an implementation, once run (e.g., at a URL on a web service), a GraphQL service (e.g., an endpoint) can receive GraphQL queries for validation and / or execution. The GraphQL service can first check the query to ensure it involves defined types and / or fields and then can run the specified function to produce a result. For example, a query:

[0049]

[0050] For example, the following JSON result can be generated:

[0051]

[0052] In an implementation, an example GraphQL query language can involve at least in part selecting fields on an object.

[0053]

[0054]

[0055] For the example query shown above, processing can start with a special "root" object. Subsequently, for example, the "hero" field can be selected. For the object returned for "hero", the "name" and "appearsIn" fields can be selected.

[0056] In at least some cases, it can be advantageous and / or beneficial to have a more accurate description of content (e.g., data). One can ask what fields can be selected? What kind of objects can the fields return? What fields are available on those sub-objects? In an implementation, a schema such as a GraphQL schema can help provide the aforementioned advantages and / or benefits, as more fully explained below.

[0057] In an implementation, a schema such as a GraphQL schema can define a set of types that can describe (e.g., can be fully described in a specific implementation) a set of possible content that can be accessed on a specific service. In an implementation, at least in part in response to receiving one or more queries, one or more queries can be verified and / or executed against a specific schema, for example.

[0058] In an implementation, a GraphQL service can be written in any language. Since one can discuss a GraphQL schema without relying on the syntax of a specific programming language such as JavaScript, an example GraphQL schema language that is at least in some respects similar to the GraphQL query language can be used herein for different examples to allow a language-independent discussion of a schema such as a GraphQL schema. Although examples of embodiments and / or implementations can be described herein at least in part in conjunction with GraphQL, the subject matter is not limited to the scope in this regard. That is, GraphQL is used herein as a non-limiting example.

[0059] In an implementation, the basic components of a GraphQL schema can include object types, where an object type can represent a type of object that can be retrieved from a service and what fields the object type can have. In an example GraphQL schema language, an example object type can be represented as follows:

[0060] type Character{

[0061] name:String!

[0062] appearsIn:[Episode!]!

[0063] }

[0064] For the above example, "Character" can include a GraphQL object type, meaning it is a type with some fields. Many or most types in a schema can include, for example, object types. Also, for example, "name" and "appearsIn" can include fields on the Character type. For example, name and appearsIn can include fields that can appear as part of a GraphQL query operating on the Character type. For example, "String" can include one of the built-in scalar types. A scalar type can resolve to a single scalar object and, for example, may not have sub-selections in a query. Further, "String!" can specify that the field is non-nullable, meaning that when the field is queried, the GraphQL service can always provide a value. In the example type language, non-null fields can be represented as those with an exclamation mark. Additionally, [Episode!]! can represent an array of Episode objects. Since it can also be non-null, in response to the appearsIn field being queried, one can expect an array (e.g., having zero or more items). Also, since Episode! can also be non-null, for example, each item in the array can be expected to be an Episode object.

[0065] The above discussion can provide some understanding of what an example GraphQL object type can look like and / or can also provide some understanding of some of the basic language for how to read an example GraphQL type language. In an implementation, an organization can advantageously expose a Single figure (single graph) that can provide a unified interface for various combinations for querying a content source. However, representing an enterprise-scale graph with, for example, a single monolithic GraphQL service can be challenging.

[0066] To address this challenge, at least in part, a federated approach can be used to partition the graph implementation into multiple services that can be more easily maintained by different teams. An example architecture that leverages the federated approach can include, for example, a collection of subgraphs (e.g., typically represented as different API services) that can each define a specific GraphQL schema. For example, multiple GraphQL subgraphs can be declaratively combined to create a unified set of types in a unified supergraph schema. Further, for example, a graph router can utilize the declaratively combined unified supergraph schema (e.g., composed of multiple GraphQL subgraph schemas) to perform operations (e.g., queries across multiple GraphQL subgraphs) to provide clients access to all types and fields in the composed supergraph.

[0067] For example, as Figure 3 depicted in, a graph (e.g., a supergraph), such as supergraph 300, can have its implementation extended across multiple API services, including, for example, a first subgraph (such as, the "User" subgraph 310), a second subgraph (such as, the "Product" subgraph 320), and / or a third subgraph (such as, the "Review" subgraph 330). For example, subgraphs 310, 320, and / or 330 can be grouped to form subgraph 300. For example, by querying subgraph 300, one or more client computing devices or clients 350 can query any one or all of subgraphs 310, 320, and / or 330 simultaneously. In an implementation, a graph router (such as, graph router 340) can serve as an access point to a supergraph (such as, supergraph 300). In an implementation, a graph router (such as, graph router 340) can receive incoming GraphQL operations (e.g., queries) and / or can intelligently distribute incoming GraphQL operations across subgraphs (such as, subgraphs 310, 320, and / or 330). For example, from the perspective of client 350, querying subgraphs via graph router 340 can appear the same as querying any other GraphQL server (e.g., no special configuration is required).

[0068] Unlike other distributed GraphQL architectures (such as, for example, schema stitching), the federation approach can utilize a declarative composition model that can enable individual subgraphs to implement a specified portion of the composed subgraph for which those individual subgraphs are responsible. Different from schema stitching (which may require imperative code manually created in Javascript (a specific programming language) to stitch schemas together at runtime), for example, the federation approach can declaratively compose subgraph schemas into a single unified supergraph schema, verify the single supergraph schema for correctness at build time, for example, and / or can load the supergraph schema into a federated GraphQL runtime (such as a graph router) to serve client queries and perform other GraphQL operations at runtime. Different from schema stitching, the federation approach can use GraphQL schemas to describe the modular subgraph schemas to be composed, which are independent of the programming language used to build the subgraph servers. Thus, the illustrative federation approach for composing subgraph schemas into a unified supergraph schema can be agnostic to the programming language used to author GraphQL servers, which is different from schema stitching that can be tied to the specific programming language Javascript. The federation approach can also enable people to add, remove, and / or refactor subgraphs without causing, for example, downtime of the production graph.

[0069] Unlike other data access methods, such as databases that also use schemas and / or can have query planners to execute queries, a federated GraphQL schema can use GraphQL instead of SQL to define data structures and queries and / or can access GraphQL subgraphs on a network instead of database tables on disk. Additionally, the federated GraphQL approach can, in at least some cases, not provide persistent and / or durable storage of the data itself, but instead can layer on top of underlying network services (such as GraphQL APIs, REST (Representational State Transfer) APIs, and / or microservices) that can in turn use databases or other data stores. Relational databases can be constructed with multiple tables that can reference each other. For example, rows from one table can refer to specific rows in another table that can be joined by some ID column. Fields can be selected from multiple database tables and joined together using keys or IDs that match a WHERE clause. In this way, data for an entity can be scattered across multiple database tables using an SQL query and / or they can be joined together, and then the SQL query can be processed by a database query planning engine to create a query plan to execute by fetching data from the underlying database tables on disk and / or collating and returning the results to a client. In a similar way, the federated approach can allow people to scatter the implementation of entity types in a graph across multiple subgraphs, where a graph router can process queries and / or join entity fields together by dynamically creating a query plan at runtime to fetch entity fields from the corresponding subgraph API servers using entity keys. The federated GraphQL approach can be agnostic to the underlying database or microservices technology used and can be used to create a unified layer on top of multiple underlying microservices (e.g., REST APIs, gRPC (Google Remote Procedure Call), etc.), which can each in turn use different database technologies. The federated approach can provide a single GraphQL schema that application developers can use to access data and services in an organization or across organizations, such as on the public Internet.

[0070] As used herein, an "entity" refers to an object type whose fields can be resolved across multiple subgraphs. Each subgraph can contribute different fields to an entity and can be responsible for resolving only its contributed fields. In an implementation, an entity can be defined within a specific subgraph by assigning an @key GraphQL schema directive for a specific entity and / or by defining a reference resolver for the specific entity. Entity references are discussed below.

[0071] In a federated GraphQL implementation, libraries can be provided to allow a server to act as, for example, a GraphQL subgraph and / or a graph router. Such components can be implemented in any language and / or framework.

[0072] In an implementation, the federated approach can be adopted incrementally. For example, in an implementation using a monolithic GraphQL server, functionality can be converted to the federated approach one service at a time. Further, for example, in an implementation using other architectures (such as schema stitching), support for the federated approach can be added to existing services one by one. In such cases, the client can continue to work and / or may not be able to distinguish between different graph implementations. Thus, the federated approach can be adopted and / or implemented without adversely affecting the client.

[0073] In an implementation, the federated approach can encourage a design principle that can be referred to as "separation of concerns". Such a principle can enable different teams within an enterprise to work on different products and / or features within a single graph without interfering with each other.

[0074] When considering how to partition a single GraphQL schema across multiple subgraphs, it may seem straightforward to partition the schema by type upwards. For example, a "User" subgraph can define the User type, a "Product" subgraph can define the Product type, and so on:

[0075] User subgraph:

[0076] type User{

[0077] id:ID!

[0078] name:String

[0079] reviews:[Review]

[0080] purchases:[Product]

[0081] }

[0082] Product subgraph:

[0083]

[0084] Review subgraph:

[0085]

[0086] Although this separation may seem relatively straightforward, it can cause problems. For example, specific features and / or concerns may sometimes span multiple types. For instance, consider the User.purchases field of the user type in the above schema. Even though this field is a member of the user type, the product list may be populated by a product subgraph rather than the user subgraph. In the implementation, by instead defining the User.purchases field in the product subgraph, the subgraph that defines the field can also be the subgraph that specifies how the field is populated. In some cases, for example, the user subgraph may not even have access to the content store containing product content. Moreover, by defining the User.purchases field in the product subgraph, the team managing the product content, for example, can include product-related logic in a single subgraph that they are responsible for.

[0087] The following example schema uses a federation approach to partition the same set of types and fields across the same three subgraphs (note: certain federation-specific syntax is omitted here for clarity and / or ease of explanation):

[0088] User sub - figure

[0089]

[0090] Product sub - figure

[0091] type Product{

[0092] id: ID!

[0093] name: String

[0094] price: String

[0095] }

[0096] type User{

[0097] id: ID!

[0098] purchases: [Product]

[0099] }

[0100] Comment sub - figure

[0101] type Review{

[0102] id: ID!

[0103] body: String

[0104] author: User

[0105] product: Product

[0106] }

[0107] type User {

[0108] id: ID!

[0109] reviews: [Review][]

[0110] }

[0111] type Product {

[0112] id: ID!

[0113] reviews: [Review][]

[0114] }

[0115] For example, the difference is that now a single subgraph can define (e.g., can at least partially define) the types and / or fields that it can and / or is responsible for populating from its corresponding content store. For example, the result might be the best of both worlds: an implementation that keeps the code for a given feature in a single subgraph and separated from unrelated concerns, and a product - centric schema with rich types that can reflect the way an application developer might want to consume the graph.

[0116] Figure 4 is a diagram depicting an example federated graph 400. In an implementation, a federated graph (such as, graph 400) can utilize multiple types of GraphQL schemas. For example, subgraph schemas (such as, subgraph schemas A, B, and / or C) can each include different schemas, and the different schemas can indicate which types and / or fields the combined supergraph schema (such as supergraph schema 420) is responsible for resolving. The supergraph schema (such as supergraph schema 420) can include the result of performing a combination (such as, combination operation 410) on a set of subgraph schemas (such as, subgraph schemas A, B, and / or C). In an implementation, the supergraph schema can combine all types and / or fields from the subgraph schemas plus some federation - specific directives that can indicate to the graph router which subgraphs can be responsible for resolving specific fields.

[0117] In addition, an API schema (such as, API schema 430) may be similar to a supergraph schema (such as, supergraph schema 420) in some respects, but it may omit types, fields, and / or directives that can be considered "machines" and may not be part of a public API directly used by a GraphQL client. This can include, for example, federation-specific and / or user-defined directives. An API schema (such as, API schema 430) may be exposed in a graph router to consumers of the GraphQL API, who may not need to know any internal implementation details about the specific graph, for example.

[0118] Consider an example. Below, schemas can be defined for three subgraphs in a basic example e-commerce application. Each subgraph can be implemented as a separate GraphQL API, for example:

[0119] User sub - figure

[0120] type Query{

[0121] me:User

[0122] }

[0123] type User@key(fields:"id"){

[0124] id:ID!

[0125] username:String!@shareable

[0126] }

[0127] #(Subgraph schemas include

[0128] #this to opt in to

[0129] #Federation 2 features.)

[0130] extend schema

[0131] @link(url:"https: / / specs.apollo.dev / federation / v2.0",

[0132] import:["@key","@shareable"])

[0133] Product sub - figure

[0134] type Query{

[0135] topProducts(first: Int = 5): [Product]

[0136] }

[0137] type Product @key(fields: "upc") {

[0138] upc: String!

[0139] name: String!

[0140] price: Int

[0141] }

[0142] extend schema

[0143] @link(url: "https: / / specs.apollo.dev / federation / v2.0",

[0144] import: ["@key", "@shareable"])

[0145] Comment sub - figure

[0146] type Review {

[0147] body: String author: User @provides(fields: "username")

[0148] product: Product

[0149] }

[0150] type User @key(fields: "id") {

[0151] id: ID!

[0152] username: String! @external reviews: [Review]

[0153] }

[0154] type Product @key(fields: "upc") {

[0155] upc: String!

[0156] reviews: [Review]

[0157] }

[0158] #(This subgraph uses additional

[0159] #federated directives)

[0160] extend schema

[0161] @link(url:"https: / / specs.apollo.dev / federation / v2.0",

[0162] import:["@key","@shareable","@provides","@external"])

[0163] As shown in the above example scenario, multiple subgraphs can contribute unique fields to a single type. For example, both the product subgraph and the review subgraph contribute fields to the Product type.

[0164] In an implementation, a supergraph schema (such as, supergraph schema 800) can include the output of a schema combination (such as, the schema combination operation 410 depicted in Figure 4 ). In an implementation, the supergraph schema can provide the names and endpoint URLs of the individual subgraphs to a graph router (such as, graph router 340). For example, a supergraph schema (such as, supergraph schema 420) can include types, fields, and / or directives (such as, all, most, etc. types, fields, and / or directives) defined by the subgraph schemas. Also, in an implementation, for example, the supergraph schema can tell the graph router which subgraph schemas can resolve which GraphQL fields. The supergraph schema examples provided below represent the example results of combination operations performed using the example subgraph schemas provided above.

[0165] Hyper - graph mode

[0166] @link(url:"https: / / specs.apollo.dev / link / v1.0")

[0167] @link(url:"https: / / specs.apollo.dev / join / v0.2",for:EXECUTION)

[0168] {

[0169] query:Query

[0170] }

[0171] directive @join__field(graph: join__Graph!, requires: join__FieldSet, provides:

[0172] join__FieldSet, type:

[0173] String, external: Boolean, override: String, usedOverridden: Boolean) repeatable on

[0174] FIELD_DEFINITION | INPUT_FIELD_DEFINITION

[0175] directive @join__graph(name: String!, url: String!) on ENUM_VALUE

[0176] directive @join__implements(graph: join__Graph!, interface: String!) repeatable on OBJECT|

[0177] INTERFACE

[0178] directive @join__type(graph: join__Graph!, key: join__FieldSet, extension:

[0179] Boolean!= false,

[0180] resolvable: Boolean!= true) repeatable on OBJECT|INTERFACE|UNION|

[0181] ENUM|

[0182] INPUT_OBJECT|SCALAR

[0183] directive @link(url: String, as: String, for: link__Purpose, import:

[0184] [link__Import]) repeatable on

[0185] SCHEMA

[0186] scalar join__FieldSet

[0187] enum join__Graph{

[0188] PRODUCTS@join__graph(name:"products",url:"http: / / localhost:4003 / graphql")

[0189] REVIEWS@join__graph(name:"reviews",url:"http: / / localhost:4002 / graphql")USERS@join__graph(name:"users",url:"http: / / localhost:4001 / graphql")

[0190] }

[0191] scalar link__Importenum link__Purpose{

[0192] """

[0193] `SECURITY` features provide metadata necessary to securely resolve fields.

[0194] """

[0195] SECURITY

[0196] """

[0197] `EXECUTION` features provide metadata necessary for operation execution.

[0198] """

[0199] EXECUTION

[0200] }

[0201] type Product

[0202] @join__type(graph:PRODUCTS,key:"upc")

[0203] @join__type(graph:REVIEWS,key:"upc")

[0204] {

[0205] upc: String!

[0206] name: String! @join__field(graph: PRODUCTS)

[0207] price: Int @join__field(graph: PRODUCTS)

[0208] reviews: [Review] @join__field(graph: REVIEWS)

[0209] }

[0210] type Query

[0211] @join__type(graph: PRODUCTS)

[0212] @join__type(graph: REVIEWS)

[0213] @join__type(graph: USERS)

[0214] {

[0215] topProducts(first: Int = 5): [Product] @join__field(graph: PRODUCTS)

[0216] me: User @join__field(graph: USERS)

[0217] }

[0218] type Review

[0219] @join__type(graph: REVIEWS)

[0220] {

[0221] body: String

[0222] author: User @join__field(graph: REVIEWS, provides: "username")

[0223] product: Product

[0224] }

[0225] type User

[0226] @join__type(graph:REVIEWS, key: "id")

[0227] @join__type(graph:USERS, key: "id")

[0228] {

[0229] id: ID!

[0230] username: String! @join__field(graph:REVIEWS, external: true)

[0231] @join__field(graph:USERS)

[0232] reviews: [Review] @join__field(graph:REVIEWS)

[0233] }

[0234] In the implementation, a graph router (such as, graph router 340) can utilize a hypergraph schema (such as, hypergraph schema 420) to generate a GraphQL API schema (e.g., API schema 430), and a client of the graph router can use this hypergraph schema to introspect the API schema (e.g., browse available types and / or root query fields), issue GraphQL queries, and / or perform other GraphQL operations on the graph router. The API schema (such as, the example API schema provided below) can represent a combination of various subgraph schemas:

[0235] type Product{

[0236] name: String!

[0237] price: Int

[0238] reviews: [Review]

[0239] upc: String!

[0240] }

[0241] type Query{

[0242] me: User

[0243] topProducts(first: Int = 5): [Product]

[0244] }

[0245] type Review{

[0246] author: User

[0247] body: String

[0248] product: Product

[0249] }

[0250] type User{

[0251] id: ID!

[0252] reviews: [Review]

[0253] username: String!

[0254] }

[0255] As explained, an enterprise can have, for example, a single unified graph (e.g., a hypergraph) as opposed to multiple graphs created by different teams (of course, an enterprise can leverage multiple unified hypergraphs if they prefer and / or if it is beneficial). By having a unified graph, the value of GraphQL can be enhanced. More content and / or services can be accessed from a single query. For example, the API side can connect all fields of a composable concrete entity, even if distributed across multiple subgraphs, such that a single consolidated result can be returned to the client. In this way, the client does not need to stitch the results together, unlike other methods where individual requests to different subgraphs can be batched in a single query and then the client has to manually stitch these results together. The API side connection can be similar in at least some respects to a database join across tables, although for example the GraphQL federation approach can perform joins across multiple subgraphs rather than tables. For example, having the ability to perform API side connections instead of client side connections can provide advantages in terms of runtime performance and / or in terms of simplifying and / or reducing the work of application developers. Using the GraphQL federation approach, the unified graph can provide a single source of truth for multiple (e.g., all, most, etc.) services and / or can provide faster applications, faster software delivery, reduced maintenance overhead, etc. Additionally, for example, code, queries, skills, and / or experiences can be more portable across teams. The unified graph can also produce, for example, a central directory of available content (e.g., a schema registry) viewable by graph users. Further, at least in part because at least a large amount of graph implementation work is not duplicated between teams, implementation costs can be reduced. Additionally, for example, central management of the graph can be unified across control policies. In this context, "unified graph" and / or the like refers to a graph composed of one or more graphs (such as subgraphs). "Hypergraph" and / or the like refers to an example unified graph composed of one or more subgraphs. "Unified graph" and / or the like and "hypergraph" and / or the like can be used interchangeably herein.

[0256] In an implementation, although there may be only a single graph, the implementation of the graph can be federated across multiple teams within an enterprise. For example, in the absence of specialized infrastructure and / or without a significant negative impact on productivity (e.g., due to different teams having to coordinate with each other), a monolithic architecture may be difficult to scale, and the graph may be no exception. Instead of implementing the entire layer of an organization in a single codebase, for example, the responsibility for defining and / or implementing the graph can be divided across multiple teams. In an implementation, each team can be responsible for maintaining a portion of the schema that exposes its content and / or services, while having the flexibility to develop independently and / or operate on its own release cycle. This can maintain the advantages of a single unified graph while decoupling development efforts across entities, for example. These example features of the GraphQL federation approach can be key to scaling the graph effectively across multiple teams, such that each team can work on specific modules or slices of the graph in an autonomous manner using the independent delivery of its slice, thereby reducing the exponential communication overhead that could be experienced using other (e.g., monolithic) approaches.

[0257] In an implementation, the fundamental property of federation (FPF) specifies that the theoretically possible queries of interest (e.g., one or more queries of interest, all queries of interest, etc.) for a specific supergraph API schema can be served by multiple subqueries on subgraphs. For a specific federation method, such as the methods discussed previously, the FPF can be implemented at least in part by specifying specific rules. For example, for a specific federation method, three object types can be specified, where each object type is allowed a single type of subgraph layout. For example, for a specific federation method, if an entity type has an @key, that key can be used to index the required fields in each subgraph and / or select the required fields from each subgraph to connect the fields of the entity across subgraphs (and API-side connections). Embodiments can use the @key to scatter the entity type across multiple subgraphs (in an implementation, excluding @provides). Otherwise, for types without an @key, if the type is a root type (e.g., query or mutation), then each field can also be in only a single subgraph (e.g., the same rule as for @key, but a different way of identifying the object type). Otherwise, for types without an @key and that are not root types (e.g., value types), each field must be part of all subgraphs in which the type is defined. In other words, all definitions of the type in each subgraph must be the same. Being the same across subgraphs means that the subgraphs must be relatively highly consistent with each other (e.g., identical). These specific rules and / or the permitted layouts can be relatively easy to understand, and they do support and / or enforce the FPF. However, such rules and / or approved layouts for a specific federation method can be somewhat restrictive, constraining, and / or inflexible, for example.

[0258] The specific federation methods discussed above require a relatively high degree of consistency for shared value types (e.g., all types must be exactly the same across subgraphs). As discussed more fully below, another federation method introduces a eventually consistent model, so that value type changes (e.g., adding fields) can be made in a subgraph at once (e.g., using "@inaccessible" to hide newly added fields until the newly added fields are added to each subgraph one by one according to their own release schedules), rather than forcing all subgraphs to perform connection releases that may be difficult to schedule and coordinate. Using further federation methods and their eventually consistent model for shared value types, the further federation method introduces new machine-readable composition hints generated during composition to show subgraph divergence (inconsistency) across graph types and / or field definitions, so that they can be observed and / or verified with user-defined policies in the hypergraph construction pipeline, and / or the construction pipeline can be automated to verify and / or notify the team of potential problems. Therefore, the further federation method can provide more flexibility (e.g., support flexible type merging for eventually consistent types and / or field definitions across subgraphs, and provide more visibility and / or control via composition hints to effectively manage this additional flexibility).

[0259] As mentioned, the specific federation method can allow a single subgraph to provide query root fields that will be composed into a unified graph. Therefore, the query planner can always send a query for a given query root field to a single and unique subgraph (assuming the query root field in the unified graph), and then can use "_entities" and / or "@key" to obtain additional fields from additional subgraphs to join additional subgraph data. As discussed more fully below, another federation method can allow multiple subgraphs to provide the same query root field, and the query planner of the other federation method can now pick the most favorable subgraph as the entry point for the query to, for example, minimize the number of subgraph retrievals.

[0260] For the further federation method, as in the example method discussed below, multiple object types and / or multiple layouts can be acceptable as long as they do not violate the FPF. This means that in an implementation, for one or more specific subgraphs that make up a specific hypergraph schema, any layout for one or more specific subgraphs can be designated as acceptable as long as queries of interest (e.g., queries based on the specific hypergraph schema API) can be provided from the specific subgraph. For example, given an object type T, and any query path to T (e.g., where a "query path" refers to a field chain on the hypergraph schema API that starts from a root field and ends on a field of type T or a supertype of T), and additionally given a field f of T on the hypergraph API, there is a "subgraph query path" for obtaining f (e.g., query planning).

[0261] Because for any specific hypergraph pattern, there is a finite number of types (with a finite number of fields), and further because there is a finite number of query paths (e.g., assuming loops are broken), validating a specific hypergraph pattern under the further methods discussed below to ensure compliance with the FPF can be computationally feasible.

[0262] For another method for federated graph utilization such as Figure 5 depicted in, for example, the combination rules, guidelines, etc. can be relatively simple and / or relaxed (e.g., more flexible type merging, more flexible combination rules, etc.), such that the combination can be successful in more scenarios and / or allow for improved schema evolution, for example, in a multi-team environment. In an implementation, another method for federated graph utilization can include a generalized combination model that is at least partially based on the FPF, which can support smaller incremental changes, more flexible value type merging, and / or an improved shared ownership model, such as more fully explained below. As also more fully explained herein, the generalized combination model that supports the FPF, with its more flexible value type merging, improved shared ownership model, and / or deeper static analysis / validation, when combined with declarative graph combination into a static structure (e.g., subgraph patterns are combined into hypergraph patterns), can provide many benefits and / or advantages over other methods, such as schema stitching and / or other methods that can be written in a specific programming language such as Javascript, which can be dynamically evaluated at runtime and thus may be more error-prone. Further benefits and / or advantages of the federated approach can include, for example, the ability to statically analyze hypergraph patterns at build time to more quickly catch errors, thereby enabling an ecosystem of hypergraph tools that can intercept, validate, transform, and / or otherwise process hypergraph patterns in a CI (Continuous Integration) / CD (Continuous Deployment) pipeline, and / or can send notifications and / or generate reports through which the correctness of hypergraph patterns can be verified and / or ensured before they are delivered to, for example, a graph router farm that processes client queries at scale.

[0263] As mentioned, implementations (e.g., at least in part based on further federated approaches to schema utilization) can include declarative composition into static artifacts (e.g., composing sub-schema patterns into super-schema patterns), which can be statically analyzed at build time or near build time rather than only at runtime. Such implementations can allow groups of development teams and / or evolution teams in a company to further ensure, for example, in an achievable and bounded manner, the correctness and / or security of the super-schema written at build time. In contrast, with schema stitching approaches, validating schema stitching code can be difficult and / or nearly impossible because it is based on a general programming model rather than a more bounded declarative model, for example, that results in a single statically analyzable federated GraphQL schema.

[0264] Figure 5 FIG. is an illustration of an embodiment 500 of a process depicting another method of demonstrating federated schema utilization. The embodiment can include, for example, all of the operations, processes, techniques, methods, etc. described by process 500, less than, for example, the operations, processes, techniques, methods, etc. described by process 500, and / or more than, for example, the operations, processes, techniques, methods, etc. described by process 500. Also, it should be noted that the content obtained or generated in connection with the provided examples (e.g., input signals, output signals, operations, results, etc.) can be represented via one or more analog signals and / or digital signals and / or signal packets. It should also be understood that even though one or more operations, processes, techniques, methods, etc. are shown or described simultaneously or relative to a certain sequence, other sequences or concurrent operations, processes, techniques, methods, etc. can be employed. Further, it should be noted that operations, processes, techniques, methods, etc. can be implemented, executed, etc. by any combination of hardware, firmware, and / or software. Additionally, although the following description refers to specific aspects and / or features shown in certain other figures, other aspects and / or features can be utilized to perform one or more operations, processes, techniques, methods, etc.

[0265] In an implementation, an orchestrator process (such as composer 520) can obtain graph patterns (such as subgraph pattern 510) for one or more services and / or can generate a new unified graph pattern (such as hypergraph pattern 525), which can incorporate content from individual subgraph patterns. Also, in an implementation, a validator process (such as validator process 530) can operate on hypergraph pattern 525 and / or can ensure that there is a graph routing for the theoretically possible queries of interest (e.g., one or more theoretically possible queries, all theoretically possible queries, etc.) with respect to hypergraph pattern 525. In other words, in an implementation, validator 530 can ensure that, for example, a hypergraph query of interest can be satisfied by routing content (e.g., data) between queries by comparing against one or more subgraphs. As depicted at block 540 of example process 500, if hypergraph pattern 525 fails the validator process 530, then hypergraph pattern 525 can be rejected. Also as shown at block 540, if hypergraph pattern 525 passes the validator process 530, then hypergraph pattern 525 can be provided to a graph router process (such as graph router 545).

[0266] In an implementation, the validator process (such as validator 530) can be optional. However, for example, if an implementation lacks a validator process that operates at build time or near build time, then the graph router process (such as graph router 545) can discover that a query cannot be successfully routed before runtime in response to, for example, obtaining the query from a front-end application. This situation can result in user-facing errors. For an implementation that performs the validator process at build time or near build time, for example, such errors can be discovered before deployment, thus improving service reliability and / or improving the user experience. For example, changes to subgraphs can originate from an individual developer's computing device (e.g., a laptop computer). In an implementation, the validator process can be executed on an individual developer's computing device, and this allows subgraph changes to be verified relatively early in the development process.

[0267] Again, referring to example process 500, a graph router process (such as graph router process 545) can obtain a hypergraph schema (such as hypergraph schema 525). For example, graph router process 545 can receive a query from a client computing device (such as client computing device 550), and / or can return results to the client computing device. In an implementation, graph router process 545 can include a query planner process (such as query planner process 546) and / or can include an executor process (such as executor process 548). In an implementation, query planner process 546 can obtain an incoming query from client computing device 550, and / or can utilize knowledge of a hypergraph schema (such as hypergraph schema 525) to construct a graph route (such as graph route 547), which can include a data structure specifying a set of subgraph queries and / or describing the content flow between subgraph queries such that the content requested by the query can be correctly located. Also, in an implementation, executor process 548 can obtain a route (such as graph route 547), and / or can execute the graph route to execute subgraph queries and / or route content between queries.

[0268] Referring again to Figure 5 , the orchestrator process 520 can, for example, obtain subgraph schema 510 and / or can generate hypergraph schema 525 at least in part based on subgraph schema 510. In an implementation, a hypergraph schema (such as hypergraph schema 525) can have specific example characteristics and / or properties. For example, in an implementation, types within a hypergraph schema (such as hypergraph schema 525) can connect one or more subgraph types. Further, for example, individual fields within a hypergraph schema (such as hypergraph schema 525) can refer to fields within one or more subgraphs (such as subgraph 510). Also, in an implementation, a hypergraph schema (such as hypergraph schema 525) can define a "connection graph" that can associate individual hypergraph fields with one or more subgraph fields that can resolve data. In an implementation, subgraph fields can return different types and / or can contain scalar content different from the hypergraph type to which they are connected. Further, in an implementation, a validator process (such as validator process 530 described below) can be responsible for ensuring that this type conversion is valid.

[0269] In an implementation, an orchestrator process (such as orchestrator 520) can apply a connection strategy to build a hypergraph schema (such as hypergraph schema 525). For example, the connection strategy can determine the shape of the joined graph. The format of the connection strategy can depend on the implementation and / or can generally depend on the specific encoding of the graph. For example, in an implementation, if the encoding gives names to types and / or fields, then the connection strategy can attempt to connect subgraph types that can have the same name.

[0270] In addition to the different federation methods discussed above, it may be advantageous to discuss additional embodiments and / or implementations that can provide a range of benefits and / or advantages in a wide range of environments. For example, GraphQL can support a so-called more closed-world model, where, for example, the GraphQL schema and / or types can be local to a given GraphQL processor. In such circumstances, the GraphQL schema may not support, for example, transitive links to remote graphs, and / or may not support the ability to dynamically import parts of a client query and / or delegate parts of a client query to an external processor for operations such as GraphQL query validation and / or GraphQL query execution.

[0271] Further, the federation methods described above can be substantially targeted at teams collaborating on a shared API. Each subgraph can contribute to the overall schema, and / or the composition rules can help ensure that potential conflicts are resolved in a consistent manner. These methods work well when an organizational structure is in place to coordinate schema design between teams, and the system and / or platform provides appropriate workflows to support that coordination.

[0272] In an embodiment, the new graph link type method can support a more open-world model, where existing graphs can be transitively linked to specific types in remote graphs, so that clients can browse and / or query the existing graphs plus the linked remote types, fields, subfields, and / or subtypes (e.g., all remote types, fields, subfields, and / or subtypes) and any additional transitive links to additional remote graphs, for example.

[0273] In an implementation, the federation type method and the graph link type method can be complementary. For example, graph links may not mean replacing the hierarchical subgraph composition in a single supergraph. Instead, in an implementation, the graph link type method can increase the ability to define peer links between supergraphs on top of the federation type mechanism. Further, for example, in an implementation, the links between graphs can allow clients to access content (e.g., data) from multiple graphs by sending a single GraphQL query to a single API endpoint, such as a graph router. As used herein, "graph link" and the like refer to a mechanism, process, apparatus, etc. that transitively links to a specified type in one or more remote graphs (e.g., supergraphs) within a specific graph (such as, for example, a supergraph).

[0274] In an implementation, a graph router computing device (such as graph routers 340 and / or 545) for a single hypergraph other than the type of remote graph from a link can, for example, create a query plan (e.g., favorable, optimized, etc.) to reduce (e.g., minimize) response latency and / or satisfy a client query through an API side connection having some of the following: 1) Subgraph fetching as can be implemented using a federation approach that can support an API side connection via @key; 2) Remote fetching to a linked graph; 3) Remote hypergraphs that can support an API side connection via @key, or any remote GraphQL API that supports an API side connection via @key; 4) And / or one or more entity references (e.g., any entity reference) that can include entity type, namespace, and / or key (or id) fields suitable for retrieving a previously registered GraphQL API endpoint from a schema registry, which can then be used to introspect and / or query a remote GraphQL API.

[0275] In an implementation, a coordination point (e.g., a primary coordination point) for a graph link type method can include an entity that can include, for example, a GraphQL type having an '@key' indication for an API side connection. As mentioned, an "entity", etc. refers to an object type that can resolve its fields across multiple subgraphs. Individual subgraphs can contribute different fields to the entity and / or be responsible for resolving the fields they contribute (e.g., only the fields they contribute). In an implementation, an entity can be defined within a specific subgraph by assigning a specific @key and / or by defining a reference resolver for the specific entity. An "entity reference", etc. ("eref") can include a general reference to an entity. For example, an entity reference can describe an entity by its namespace, entity type, and / or key field. At least in part via the entity reference, the system can look up the API in the API and / or schema registry responsible for serving the specific entity. Additionally, for example, an entity reference can include an additional entry point to the graph. In an implementation, for example, an entity can be fetched as part of a subquery. In other implementations, for example, the graph (e.g., the global graph) can be at least partially explored by entering an entity reference into a graph browser or web browser that supports resolving entity references. Of course, the subject matter is not limited to the scope of these aspects.

[0276] For example, in an implementation, an entity reference can be formed by adding a set of keys and / or values to a type reference. For example, an entity reference can include the following forms: "@github:User#id=gschmidt" or "@mycorp.billing:Invoice#year=2018,week=12,day=3,serial=1234". Of course, the subject is not limited to the scope of these aspects. For example, the order of the keys may not be important. In an implementation, for an entity reference to be legal and / or valid, the keys can correspond to unique key constraints on the type. In some cases (e.g., relatively simpler cases), the keys in an eref can be directly mapped to fields on an object. In other cases (e.g., relatively more complex cases), query fragments that define unique key constraints can use GraphQL's aliasing feature to map components of the query fragment to arbitrary key names. Thus, for example, unique key constraint declarations that can be part of a schema can be used to validate and / or correctly interpret an eref. In an implementation, the type of each key in an eref can be determined by looking at the schema. Further, this type can determine how the values in the eref are resolved into, for example, actual GraphQL values.

[0277] In an implementation, the graph-linking method can support transitive links to another @graph and / or use the namespace and / or schema of the graph in the schema registry. In an implementation, the graph-linking type method can also support adding fields that can return remote entities, e.g., author:github__User, and / or can support extending remote entities, e.g., adding posts to github__User: [Post].

[0278] Consider the following example:

[0279] extend schema@graph(name:“@github”)

[0280] type Post@key(fields:“id”){

[0281] id:ID!

[0282] title:String!

[0283] author:github__User

[0284] }

[0285] type github__User@key(fields:“id”){

[0286] id:ID!@shared

[0287] posts: [Post]

[0288] }

[0289] Except for the namespace, the above example can remind one of the subgraphs in the federated type method, as discussed above. The difference can be that the graph link type method cannot merge in the linked schema. For example, for a global type graph, given the ability to link to anyone and / or anywhere else and be linked from anyone and / or anywhere else, avoiding merges in the link schema can mean avoiding merges worldwide as in the case of the federated type method.

[0290] In the case where such a link is in place, the client may be able to issue a query to a single GraphQL API for data available for a specific type, including for example any relationships it would be able to follow when directly executing against the native API of that remote type. As such, a single API (e.g., any single GraphQL API) can act as an entry point into the global graph, and, in an implementation, once the client is at the entry point, the client can freely explore beyond the local schema by following links. Traversing those fields provides implicit access to other namespaces, which is a possible way to delve into the GitHub API in the example of Figure 6 the in-depth exploration of the GitHub API in the example of

[0291] As Figure 6 depicted in Figure 6 the query 600 can include a reference to an entity of the first (e.g., primary) graph API 610. The query 600 can further include a link 620 to a remote graph (e.g., such as the "author" described in

[0292] In an implementation, contrary to the federated method that can compose all subgraphs into a single large hypergraph schema, for example, the graph link type method can establish links between graphs that can be traversed at design time and / or runtime. Further, for example, in addition to the types of transitive links in an additional remote graph, the graph link type method can also increase support for browsing and / or accessing fields and / or associated types in the remote graph. Additionally, in an implementation, the graph link can be facilitated at least in part by a schema registry (e.g., a GraphQL schema registry), where graphs (e.g., all graphs) can publish their schema under a namespace that can be referenced in other graphs.

[0293] In an implementation, support for graph link type methods can prompt changes to multiple aspects of a graph routing platform. As a non-limiting example, in an implementation, such changes can include, but are not limited to: design-time browsing mode for link schemas plus query construction, run-time validation of client queries (where some parts of the query can be locally validated, but the linked types can be validated by a separate GraphQL schema) and / or run-time query execution, which can query plan and / or resolve fields present in a local schema, but can delegate query planning and / or execution of parts of the query that are linked to a remote graph. Such changes can further include (for example) interrupting change detection for schema changes in a remote graph, which can (for example, in the remote graph and / or graphs linked to it) evaluate observed client operations to prevent valid interrupting changes in the remote graph and / or notify interested parties when the remote graph has interrupted its observed usage.

[0294] In various example embodiments and / or implementations, "graph link" and / or the like can refer to a mechanism that allows a graph (e.g., any graph) to reference other graphs and / or extend types from other graphs, even if those graphs do not have prior knowledge of each other, thereby giving clients a way (e.g., a unified way) to formulate and / or execute queries that traverse fields across multiple APIs. In fact, for example, graph link type methods allow the set of all participating graphs to be treated as a virtual global graph.

[0295] Contrary to schema composition methods that include schema stitching and / or federated type methods, graph link type methods may not require defining queries for a single API, such as might be described by a pre-composed schema. Instead, for example, in an implementation, queries can select fields from multiple namespaces without regard for API boundaries, and cross-API federated execution may be the responsibility of a graph link-aware graph router.

[0296] From the perspective of graph links, schema elements (e.g., all schema elements) can exist within a "namespace". A graph can be defined relative to a root namespace, which means that unqualified schema elements implicitly belong to that specific namespace. However, in addition, in an implementation, a graph can contain explicit namespace declarations and / or can define schema elements that exist within those namespaces.

[0297] For the purposes of at least some of the examples described herein, diagrams and / or namespaces may be considered orthogonal. In an implementation, a centralized schema registry may track mappings between namespaces and / or schema elements. For example, ownership and / or governance rules, and accompanying workflows, may be defined to determine and / or enforce which parties can contribute schema elements to a particular namespace. In a particular implementation, for simplicity, the implementation may rely on a 1:1 mapping between namespaces and hypergraphs, although the subject matter is not limited to the scope of these aspects.

[0298] In an implementation, a namespace may apply to schema elements (e.g., all schema elements), not just top-level definitions. For example, the namespace of a field may not need to match the namespace of the type in which it is defined. Thus, a type may be extended with fields by anyone, not just the party that defined the type (e.g., and / or other parties with permission to contribute to the namespace of that type).

[0299] While standard GraphQL queries may be validated and / or executed against a single API schema, graph links allow queries to specify a selection set that can reach multiple namespaces, where the schema elements may not all be served by the same API. In an implementation, to facilitate graph links at runtime during query execution, for example, an entity reference that describes an entity by its namespace, entity type, and / or key (or id) field may enable the system to look up the API in the API and / or schema registry responsible for serving that entity, and / or may enable the system to use the API endpoints of the linked graph as an entry point to fetch the entity as part of, for example, a subquery. Further, by using the entity reference in a graph browser, the entity reference may be used as an arbitrary entry point into the graph, and the entity reference may allow, for example, exploration of the graph it can connect to and / or transitively linked graphs. The implementation may provide a single integrated graph browsing experience that can provide an improved (e.g., optimized) developer experience for, for example, traversing transitively linked graph schemas, constructing queries that utilize fields from schemas in multiple namespaces, executing those queries, and / or analyzing query plans and the execution of such queries across transitively linked graphs.

[0300] In an implementation, for example, the query may still be statically analyzable, but the interpretation may rely on a centralized schema registry to retrieve the applicable API schema. The result of the analysis phase may include, for example, an annotated query that may map individual field selections to one or more API schemas, effectively, for example, writing query-specific schemas on the fly.

[0301] Further, for example, as a convenience to client developers, queries can use implicit namespaces, thereby avoiding the need to qualify each or individual field selection and / or type reference. To achieve this, queries can be defined relative to a root namespace (e.g., each query, individual queries, etc.), where, in an implementation, the root namespace can include a primary namespace associated with the hypergraph initially being queried against. In an implementation, selecting a field can change the implicit namespace to the namespace of the field's return type. Input GraphQL queries can thus be normalized by, for example, assigning an explicit namespace to each field selection and / or type reference. In an implementation, this can occur in parallel with retrieving the API schema, as the schema is needed to look up fields by name and / or determine their return types. In an implementation, for example, once the query has been annotated, validation can occur. In an implementation, the graph router can cache the retrieved API schema to improve (e.g., optimize) the performance of query validation, query planning, and / or query execution across transitively linked graphs.

[0302] During execution, in an implementation, the graph router (such as, graph routers 340 and / or 545) can choose to skip validation of parts of the query that are not part of the current hypergraph schema and defer validation to the corresponding GraphQL service responsible for the individual parts. Execution can include a query planning phase that, in at least some respects, is similar to federated type execution on a single hypergraph, such as depicted in Figure 5 However, in an implementation, for graph link type methods, query planning can include fetching parts of the query that are not part of the current hypergraph to other APIs.

[0303] Figure 7is a schematic block diagram depicting an example process 700 for graph linking according to an embodiment. For example, in process 700, a query can link multiple schemas, where, for example, each schema may be unaware of the others. An embodiment can include, for example, all of the operations, processes, techniques, methods, etc. described by process 700, fewer than, for example, the operations, processes, techniques, methods, etc. described by process 700, and / or more than, for example, the operations, processes, techniques, methods, etc. described by process 700. Also, it should be noted that the content obtained or generated in connection with the provided examples (e.g., input signals, output signals, operations, results, etc.) can be represented via one or more analog signals and / or digital signals and / or signal packets. It should also be understood that even if one or more operations, processes, techniques, methods, etc. are shown or described simultaneously or with respect to a certain sequence, other sequences or concurrent operation processes, techniques, methods, etc. can be employed. Further, it should be noted that operations, processes, techniques, methods, etc. can be implemented, executed, etc. by any combination of hardware, firmware, and / or software. Additionally, although the following description refers to specific aspects and / or features shown in certain other figures, other aspects and / or features can be utilized to perform one or more operations, processes, techniques, methods, etc.

[0304] In an implementation, as indicated at block 701, an incoming GraphQL request can be received. In an implementation, the incoming GraphQL request can include a query that includes links (e.g., graph links) to multiple graphs (e.g., Graph A, Graph B, …, Graph N). A query planner (see block 702) (such as graph router 340 and / or 545) can obtain content, as indicated at blocks 703, 704, and / or 705, from, for example, one or more schema registries (e.g., data structures) (such as one or more schema registries related to Graph A, Graph B, …, Graph N). In an implementation, the graph router (such as graph router 340 and / or 545) can generate a query plan, as shown at block 706, at least in part based on the content obtained from one or more schema registries (e.g., schema registries for Graph A, Graph B, …, Graph N). As indicated at blocks 707, 708, and / or 709, query plan generation can include, for example, generating a plan to traverse each graph. At least in part based on the generated query plan, the graph router (e.g., graph router 340 and / or 545) can execute the query plan by obtaining content, as indicated at blocks 710, 711, and / or 712, at least in part from one or more data stores (including data stores associated with Graph A, Graph B, …, Graph N) specified at least in part by the query plan.

[0305] Of course, this document discusses further details regarding the example operations depicted in example process 700. For example, in an implementation, the discussions in this document may provide further details related to query planning and / or query planning execution for the graph link type method.

[0306] Figure 8 is a schematic block diagram depicting an example device, system, and / or process 800 for graph linking. For example, for the device, system, and / or process 800, the schema itself can be linked to other graphs. Embodiments can include, for example, all of the operations, processes, techniques, methods, etc. described by process 800, less than the operations, processes, techniques, methods, etc. described by process 800, and / or more than the operations, processes, techniques, methods, etc. described by process 800. Similarly, it should be noted that the content obtained or generated in connection with the provided examples (e.g., input signals, output signals, operations, results, etc.) can be represented via one or more analog signals and / or digital signals and / or signal packets. It should also be understood that even if one or more operations, processes, techniques, methods, etc. are shown or described simultaneously or with respect to a certain sequence, other sequences or concurrent operation processes, techniques, methods, etc. can be employed. Further, it should be noted that the operations, processes, techniques, methods, etc. can be implemented, executed, etc. by any combination of hardware, firmware, and / or software. In addition, although the following description refers to specific aspects and / or features shown in certain other figures, other aspects and / or features can be utilized to perform one or more operations, processes, techniques, methods, etc.

[0307] In an implementation, for example, an incoming GraphQL request can be received, as indicated at block 801. As further indicated at block 802, in an implementation, for example, the incoming GraphQL request can be defined at least in part with respect to a primary, default, and / or implicit namespace. As mentioned, graph linking can be facilitated at least in part by a schema registry (e.g., a GraphQL schema registry), where graphs (e.g., all graphs) can publish their schemas under a namespace that can be referenced, for example, in other graphs.

[0308] As also mentioned, in an implementation, a selection field may change an implicit namespace to the namespace of the return type of the field. Thus, as part of the query planning process indicated at block 803, for example, an incoming GraphQL query (such as incoming GraphQL request 801) may be normalized by, for example, assigning an explicit namespace to each field selection and / or type reference. In an implementation, this may occur in parallel with retrieving the API schema, as the schema needs to look up fields by name and / or determine their return types. As shown at blocks 804, 805, and / or 806, query planning may include traversing multiple links to multiple graph schema registries, where each graph may specify, for example, a corresponding namespace. Although blocks 805 and 806 refer to Graph B, similar operations may be performed, for example, for any number of other linked graphs (such as Graph C, …, Graph N).

[0309] As shown at block 805, in an implementation, a query planner (such as of graph router 340 and / or 545) may obtain, for example, the type and / or schema content of the corresponding namespaces specified by Graph B, …, Graph N. Further, for example, as shown at block 806, a routing URL associated with Graph B, …, Graph N may also be obtained by graph router 340 and / or 545. Additionally, as shown at block 807, a query plan may be generated at least in part based on content obtained from the example operations depicted at blocks 804, 805, and / or 806 (including, for example, routing URL content).

[0310] At least in part based on the query plan generated at block 807, for example, a graph router (such as graph router 340 and / or 545) may execute the query plan by obtaining content from at least one or more data stores at least in part specified by the query plan (including data stores associated with Graph A, Graph B, …, Graph N), as indicated at blocks 808, 809, and / or 810.

[0311] As discussed, for example, the graph links described in connection with example processes 700 and / or 800 may enable a query to specify a selection set that reaches multiple namespaces, where schema elements may not all be served by the same API. Implementations may provide a single integrated graph browsing experience that can provide an improved (e.g., optimized) developer experience for, for example, mobile transitive-linked graph schemas, constructing queries with fields from schemas in multiple namespaces, executing such queries, and / or analyzing query plans and execution of such queries across transitive-linked graphs.

[0312] Although example devices, systems, and / or processes 700 and / or 800 may refer to specific figure (e.g., Figure A, Figure B, …, Figure N) implementations, they are not limited to any specific number of figures. For example, an implementation may include the participation and / or utilization of any number of figures (e.g., hypergraphs, subgraphs, etc.). For example, Figure 7 Figure A, Figure B, …, Figure N are depicted to illustrate that an implementation may include any number of figures. Moreover, Figure 8 Figure A, Figure B, …, Figure N are mentioned again to illustrate that an implementation may include any number of figures.

[0313] In some implementations, when one hypergraph is linked to another hypergraph, each hypergraph may have its own query planning and / or execution (such as depicted at block 706 and / or 710) and its own hypergraph process (such as the example process 700 depicted as Figure 7 ), where, for example, the link from the query planning execution 710 to the incoming GraphQL request 701 (e.g., a recursive link). It may also be noted that for graph link security (e.g., to avoid man-in-the-middle attacks, etc.), it may be advantageous to pass sensitive query context data (e.g., key field values, security headers, etc.) to a given linked graph only what is required to isolate the resolution of its subqueries (e.g., without passing to other linked graphs). In this way, the work of the main hypergraph router (e.g., the graph router that receives client queries) can be used to coordinate all linked graphs, and / or act as the only trusted intermediary between all linked graphs to ensure that the communication across linked graphs is not tampered with, and / or not pass sensitive query context data transitively across linked graphs, e.g., which could be used by malicious linked graphs to gain access to other graphs using the user's credentials.

[0314] Figure 9is a flowchart showing an example process (such as process 900) for graph linking according to example embodiments and / or implementations described herein. Embodiments may include, for example, all operations, processes, techniques, methods, etc. described by process 900, less than, for example, the operations, processes, techniques, methods, etc. described by process 900, and / or more than, for example, the operations, processes, techniques, methods, etc. described by process 900. Also, it should be noted that the content obtained or generated in connection with the provided examples (e.g., input signals, output signals, operations, results, etc.) may be represented via one or more analog signals and / or digital signals and / or signal packets. It should also be understood that even if one or more operations, processes, techniques, methods, etc. are shown or described simultaneously or with respect to a certain sequence, other sequences or concurrent operation processes, techniques, methods, etc. may be employed. Further, it should be noted that operations, processes, techniques, methods, etc. may be implemented, executed, etc. by any combination of hardware, firmware, and / or software. Additionally, although the following description refers to specific aspects and / or features shown in certain other figures, other aspects and / or features may be utilized to perform one or more operations, processes, techniques, methods, etc.

[0315] As depicted in example 900, for example, a graph router (such as graph routers 340 and / or 545) may obtain a query from a client computing device. See, for example Figure 9 box 901. In an implementation, the query may include one or more implicit or otherwise links to one or more remote graphs. Also, in an implementation, the link may include one or more specified entities or entity references. Further, for example, a graph router (such as graph routers 340 and / or 545) may support transitive links.

[0316] As also depicted in example 900, in an implementation, a query plan may be generated at least in part by accessing one or more schema registries associated with one or more remote graphs, as depicted at box 902. In an implementation, the query plan may be executed at least in part by obtaining content from one or more network services at least partially specified by the query plan, and query results may be returned to the client computing device. See, for example Figure 9 box 903 and / or box 904.

[0317] As discussed above, the federated approach can be built on the merits of GraphQL by working, at least in part, towards the powerful concept of being able to accurately fetch desired content (e.g., data) without developing special code to do so. For example, the federated type approach discussed herein offers specific advantages in cases where the desired data is spread across multiple systems and / or managed by different teams. Such a federated type approach has given rise to an architecture known as a hypergraph, as described above. The hypergraph provides layers of a software / hardware stack that enable, at least in part, the unification of all of one's content (e.g., data), services, and / or capabilities.

[0318] However, the federated type approach is not just about unifying one's specific data. Instead, the federated type approach can involve providing access to specified content (e.g., all desired data), regardless of where the content resides or who is responsible for the content. In many cases, more modern applications may not be built on top of silos. Application data may increasingly need to go beyond, for example, a single API and / or beyond the boundaries of a single organization.

[0319] There may be many APIs that could help improve a specific application, and developers may want to leverage these APIs. However, the effort involved in connecting such APIs into a specific application often becomes impractical. As a result, it can be said that a great deal of value may be left on the table. For example, due to these challenges, what features, applications, and / or companies are not being developed?

[0320] For example, consider a specific use case. For this example, it can be assumed that one wishes to develop a travel management application. What would be the ideal developer experience for this application? In the spirit of GraphQL, it may be desirable to enable developers to write queries that specify only the data they need without specifying where or how to obtain the required data. For this specific travel management application example, one may want to show the flight status associated with a specific trip. A developer may write, for example:

[0321]

[0322] For the example above, what would be needed to make the query a reality? For example, one could add a subgraph that wraps access to a third-party API. To do so, a developer may write some resolver proxies, may fetch data from an endpoint, and / or may expose the data as part of a specific schema. Such a solution may work, but it may far from seamless. For example, wrapper code may have to be written and maintained. This can consume a great deal of resources, human and / or otherwise. For example, one may have to coordinate with another team and / or find room on the roadmap to develop such code. It may even be considered not worth the effort.

[0323] The development process can be made slightly easier by developing tools that can automatically generate wrapper code and / or by developing runtime software components that can operate based on a more declarative model. However, this may not completely eliminate the implementation and / or maintenance burden. For example, such an approach may not address the more fundamental issues of wrapping.

[0324] When an external API is wrapped, it can become part of a concrete schema. In fact, a portion of another schema can be projected into the initial schema. One possible challenge with this approach is that it can lead to a tight coupling between the concrete schema and the API's data model, which may be outside of human control. By introducing external data, one may already be responsible for another API's data model. For example, any changes to the underlying API may require corresponding changes not only to the wrapper code for humans but also to the schema for humans.

[0325] A related issue is that projection can significantly limit composability. The wrapped API can be, for example, an ad-hoc solution that can prevent query planning improvements and / or optimizations. What may be needed is a more decoupled approach - an approach that can allow individual APIs to evolve independently and / or enable clients to fully utilize each API without waiting for the wrapper code to be written and / or updated.

[0326] To address such challenges, one can turn to approaches such as the federated type approach discussed in this article. One aspect of this federated type approach is the idea that individual sub-schemas can be responsible only for their respective parts of the super-schema. With such an approach, there can be a clear division of responsibility. For example, any sub-schema can refer to types and / or extend types with fields, but the sub-schema is not responsible for anything contributed by other sub-schemas. For this travel management application example, consider the following:

[0327] type Query{

[0328] upcomingTrips:[Trip]

[0329] }

[0330] type Trip@key(fields:"id"){

[0331] id:ID!

[0332] name:String

[0333] flights:[Flight]

[0334] }

[0335] type Flight@key(fields:"flightNumber"){

[0336] flightNumber: String!

[0337] }

[0338] For at least some federated type approaches, individual subgraphs can contribute types and / or fields to the same schema. Composition rules can help ensure that potential conflicts are detected, and / or that such conflicts can be resolved before deployment. This can work well in cases where an organizational structure is in place to coordinate schema design between teams. However, a truly global graph, etc., may require a more loosely coupled architecture that may not rely on prior coordination.

[0339] To at least partially achieve a relatively more loosely coupled architecture that does not rely on prior coordination, a graph linking type approach can be used. Of course, graph linking type approaches, embodiments, and / or implementations were discussed above. Applying the graph linking approach to this travel management application example considers the following:

[0340] @self(name: "tripplanner")

[0341] @link(to: "airline")

[0342] type Query {

[0343] upcomingTrips: [Trip]

[0344] }

[0345] type Trip @key(fields: "id") {

[0346] id: ID!

[0347] name: String

[0348] flights: [airline__Flight]

[0349] }

[0350] type airline__Flight @key(fields: "flightNumber") {

[0351] flightNumber: String!

[0352] }

[0353] One aspect that may be noted with the graph linking examples provided above is some additional indication. From a global graph perspective, types and / or fields may exist within namespaces. For example, namespaces are discussed above. It may also be noted that the examples shown above may be similar to federated approaches that are gaining wider acceptance and / or practicality. Also, for example, the query plan should look familiar.

[0354] As previously discussed, entities may comprise building blocks of federated methods. Among other things, entities may allow queries to jump from one graph to another. Also, for example, a namespace may allow for the definition of global entity references or "Erefs." The entity references discussed previously may include at least some aspects similar to those of URLs, but rather than referencing a web page, an entity reference may, for example, identify a shared object in a global graph.

[0355] Namespaces can have another powerful feature and / or can have surprising ideas. Not only can types exist in a namespace, but fields can also exist. And, for example, in an implementation, the namespace of a field may not have to match the namespace of the type it defines. For example, when someone extends the airline flight type with carbon emissions, the field exists in the carbon namespace, not the airline namespace. It is this separation that can provide a relatively decoupled (e.g., completely decoupled) graph. For example, a namespace can allow anyone to extend a type without worrying about conflicts and / or without prior coordination.

[0356] In an implementation, for example, a graph link type approach can allow hypergraphs to be processed as modules, just as subgraphs can be processed in a federation type approach. In an implementation, hypergraphs can exist independently but can also be connected in a principled manner. However, the links between hypergraphs may not result in pre-composed patterns. Instead, for example, queries can traverse API boundaries and / or graph routers can compose dynamic patterns on the fly. Again, topics related to these features are discussed at least in part above.

[0357] In an implementation, dynamic schemas can help provide truly global (e.g., wide-ranging) graphs. For situations where everything is potentially connected, static composition may not be practical. With static composition, one may end up with a single schema for the entire world (which, of course, may not be practical and / or possible). In contrast, with a graph link type approach, the connections specified in the query may determine which graphs to pull in.

[0358] In implementations, this may be taken a step further, as the traversal may not be limited to links that may be predefined in the API, queries may be performed against the API. Consider this further travel management application example:

[0359]

[0360]

[0361] In an implementation, anyone can add fields to any entity. Further, in an implementation, queries can be linked to additional diagrams to introduce these fields. This openness lies at the core of at least some of the diagram-linking type methods discussed herein. Using such a method, for example, when referencing and / or extending an entity, it may not be necessary to coordinate with anyone.

[0362] Diagram-linking type methods can provide the next steps regarding federated type methods. For example, diagram-linking type methods such as those discussed herein can be built on proven architectures, but can also enable hypergraphs to scale beyond a single organization. It can even be said that diagram-linking methods can provide a path to building a global (e.g., wide-ranging) hypergraph.

[0363] In the context of this patent application, the terms "connection", the term "component", and / or similar terms are intended to be physical, but not necessarily always tangible. Thus, whether these terms refer to a tangible subject matter can change in the specific context of use. As an example, a tangible connection and / or a tangible connection path can be formed, such as a tangible electrical connection (such as a conductive path including metal or other conductors) that can conduct electric current between two tangible components. Similarly, the tangible connection path can be at least partially affected and / or controlled such that, as is typical, the tangible connection path can be opened or closed, sometimes resulting from the influence of one or more externally derived signals (such as an external current and / or voltage), such as for an electrical switch. Non-limiting illustrations of electrical switches include transistors, diodes, etc. However, in the specific context of use, "connection" and / or "component", although physical, can also be non-tangible, such as a connection between a client and a server over a network (especially a wireless network), which generally refers to the ability of the client and the server to send, receive, and / or exchange communications, as discussed in more detail later.

[0364] Thus, in the specific context of use, such as in the context of discussing tangible components, the terms "coupled" and "connected" are used in a manner such that the terms are not synonymous. Similar terms may also be used in a manner that demonstrates a similar intent. Thus, "connected" is used to indicate that two or more tangible components, etc., are physically connected, for example, tangibly and directly in physical contact. Thus, using the previous example, two tangible components that are electrically connected are physically connected via a tangible electrical connection, as previously discussed. However, "coupled" is used to indicate that potentially two or more tangible components are tangibly and directly in physical contact. Nevertheless, "coupled" is also used to indicate that two or more tangible components, etc., are not necessarily tangibly and directly in physical contact, but are capable of cooperating, communicating, and / or interacting, such as, for example, via "optical coupling". Similarly, the term "coupled" is also understood to indicate an indirect connection. It should also be noted that in the context of this patent application, since the memory (such as memory components and / or memory states) is intended to be non-transitory, the term "physical", at least when used in relation to the memory, necessarily means that such memory components and / or memory states (continuing with this example) are tangible.

[0365] In addition, in this patent application, in the specific context of use, such as in the case of discussing tangible components (and / or similarly, tangible materials), there is a difference between "on" and "over". As an example, depositing a substance "on" a substrate refers to a deposition that involves direct physical and tangible contact, and in this latter example, there is no intermediate (such as an intermediate substance) between the deposited substance and the substrate; nevertheless, depositing "over" the substrate, while understood to potentially include depositing "on" the substrate (since "on" can also accurately be described as "over"), should be understood to include the case where there is one or more intermediates (such as one or more intermediate substances) between the deposited substance and the substrate, such that the deposited substance is not necessarily in direct physical and tangible contact with the substrate.

[0366] Similar distinctions are made in the appropriate specific context of use, such as where tangible materials and / or tangible components are discussed in terms of "beneath" and "under". While in such a specific context of use, "beneath" is intended to necessarily imply physical and tangible contact (similar to "on", as just described), "under" potentially includes cases where there is direct physical and tangible contact, but does not necessarily imply direct physical and tangible contact, for example, if there is one or more intermediates, such as one or more intermediate substances. Thus, "on" should be understood to mean "directly on top of", and "beneath" should be understood to mean "directly under".

[0367] It should also be understood that terms such as "above" and "below" are understood in a manner similar to the previously mentioned terms "upward", "downward", "top", "bottom", etc. These terms can be used to facilitate discussion, but are not necessarily intended to limit the scope of the claimed subject matter. For example, by way of illustration, the term "above" does not mean to imply that the scope of the claim is limited to the case where the front side of the embodiment is upward, such as compared to an inverted embodiment. As an illustration, examples include flip chips, where, for example, the orientation at different times (such as during manufacturing) may not necessarily correspond to the orientation of the final product. Thus, if an object (by way of example) is within the scope of an applicable claim in a particular orientation (such as inverted, as an example), it is likewise intended that the latter be interpreted as being included within the scope of the applicable claim in another orientation (such as front side upward, again as an example, and vice versa), even if the literal claim language of the applicable claim has the possibility of another interpretation. Of course, similarly, as is always the case in the specification of a patent application, the specific context in which it is described and / or used provides helpful guidance as to the reasonable inferences to be drawn.

[0368] Unless otherwise specified, in the context of this patent application, the term "or", if used in connection with a list, such as A, B, or C, is intended to mean A, B, and C as used herein in an inclusive sense, as well as A, B, or C as used herein in an exclusive sense. Under this understanding, "and" is used in an inclusive sense and is intended to mean A, B, and C; while "and / or" can be used very cautiously in order to clearly convey the intention of all the above meanings, although such use is not required. In addition, the term "one or more" and / or similar terms are used to describe any feature, structure, property, etc. in the singular form, and "and / or" is also used to describe multiple and / or some other combinations of features, structures, properties, etc. Similarly, the term "based on" and / or similar terms are understood to not necessarily be intended to convey an exhaustive list of factors, but to allow for the existence of additional factors that are not necessarily explicitly described.

[0369] In addition, for situations involving implementations of the claimed subject matter and subject to tests, measurements, and / or regulations regarding degrees, the specific situations are intended to be understood in the following manner. By way of example, in a given scenario, it is assumed that the value of a physical property is to be measured. Continuing with this example, at least for the purposes of implementation, if a person of ordinary skill in the art could reasonably conceive of at least one reasonable alternative method of testing, measuring, and / or regulating degrees with respect to that property, the claimed subject matter is intended to cover those reasonable alternative methods, unless otherwise expressly indicated. By way of example, if a curve of measured values on a plot area is drawn and the implementation of the claimed subject matter refers to taking a measurement of the slope on said area, but there are various reasonable and alternative techniques for estimating the slope on said area, the claimed subject matter is intended to cover those reasonable alternative techniques, unless otherwise expressly indicated.

[0370] The claimed subject matter is related to one or more specific measured values, such as with respect to physical manifestations that can be physically measured, such as but not limited to temperature, pressure, voltage, current, electromagnetic radiation, etc., and it is argued that the claimed subject matter does not fall within the judicial exception of abstract ideas for statutory subject matter. On the contrary, it is asserted that physical measured values are not mental steps and are likewise not abstract ideas.

[0371] Nonetheless, it should be noted that the typical measurement model employed is one in which one or more measured values can each include the sum of at least two components. Thus, for a given measurement, for example, one component can include a deterministic component, which in an ideal sense can include a physical value (e.g., sought via one or more measured values), typically in the form of one or more signals, signal samples, and / or states, and one component can include a random component, which can have various sources that may be challenging to quantify. Sometimes, for example, a lack of measurement precision can affect a given measurement. Thus, for the claimed subject matter, in addition to deterministic models, statistical or stochastic models can also be used as methods for identifying and / or predicting one or more measured values that may be related to the claimed subject matter.

[0372] For example, a relatively large number of measured values can be collected to better estimate the deterministic component. Similarly, if the measured values change (which typically can occur), then a certain portion of the variance may be interpreted as the deterministic component, while a certain portion of the variance may be interpreted as the random component. Generally, if feasible, it is desirable for the random variance associated with the measured values to be relatively small. That is, generally, it may be preferred to be able to interpret a reasonable portion of the measurement change in a deterministic manner rather than as a random matter for purposes of identification and / or predictability.

[0373] Accordingly, a variety of techniques have been employed such that one or more measurements can be processed to better estimate an underlying deterministic component, as well as to estimate a potential stochastic component. Of course, these techniques can vary with the details surrounding a given scenario. However, generally, more complex problems may involve the use of more complex techniques. To this end, as alluded to above, one or more measurements of a physical manifestation can be modeled deterministically and / or stochastically. Employing a model potentially allows for the identification and / or processing of the measurements collected, and / or potentially allows for the estimation and / or prediction of the underlying deterministic component, for example, with respect to later measurements to be made. A given estimate may not be a perfect estimate; however, generally, it is expected that, on average, one or more estimates will better reflect the underlying deterministic component, for example, if stochastic components that may be included in one or more of the measurements obtained are considered. In fact, of course, it is desirable to be able to generate, for example through an estimation method, a physically meaningful model that affects the process of measurements to be made.

[0374] However, in some cases, as indicated, the potential impacts can be complex. Therefore, it can be particularly challenging to seek an understanding of the appropriate factors to consider. Thus, in such cases, it is not unusual to employ heuristics with respect to generating one or more estimates. A heuristic refers to the use of experience-related methods, which can reflect the processes implemented and / or the results achieved, for example, with respect to the use of historical measurements. For example, heuristics can be employed in situations where more analytical methods may be too complex and / or nearly intractable. Thus, with respect to the claimed subject matter, innovative features in example embodiments can include heuristics that can be used, for example, to estimate and / or predict one or more measurements.

[0375] It should be further noted that if terms such as "type" and / or "similar" are used (such as features, structures, characteristics, etc. using "optical" or "electrical" as simple examples), it indicates at least part of the features, structures, characteristics, etc. and / or is related to the features, structures, characteristics, etc., such that there are minor changes, and even changes that may otherwise be considered not completely consistent with the features, structures, characteristics, etc. Usually, it does not prevent the structures, characteristics, etc. from being of the "type" and / or "similar" (such as "optical type" or "optically similar"), if the minor changes are small enough that the features, structures, characteristics, etc. are still considered to basically exist, and these changes also exist. Thus, continuing with this example, the terms optical type and / or optically similar properties must necessarily be intended to include optical properties. Similarly, as another example, the terms electrical type and / or electrically similar properties must be intended to include electrical properties. It should be noted that the specification of this patent application only provides one or more illustrative examples, and the claimed subject matter is not intended to be limited to one or more illustrative examples; however, again, as has always been the case with respect to the specification of a patent application, the specific context in which it is described and / or used provides helpful guidance for making reasonable inferences to be drawn.

[0376] With the advancement of technology, it has become more typical to adopt distributed computing and / or communication methods, where parts of a process (e.g., signal processing of signal samples) can be distributed among different devices via, for example, a computing and / or communication network, including one or more client devices and / or one or more server devices. The network can include two or more devices (e.g., network devices and / or computing devices), and / or can couple devices (e.g., network devices and / or computing devices), such that signal communication in the form of, for example, signal packets and / or signal frames (e.g., including one or more signal samples) can be exchanged, for example, between server devices and / or client devices and other types of devices, including between wired and / or wireless devices coupled via, for example, wired and / or wireless networks.

[0377] Examples of distributed computing systems include the so-called Hadoop distributed computing system, which employs a map-reduce architecture. In the context of this patent application, the terms map-reduce architecture and / or similar terms are intended to refer to a distributed computing system implementation and / or embodiment that is used to perform map processing and / or to generate a larger set of signal samples and / or to perform reduction operations for parallel, distributed processes executed across a network of devices. The map operation and / or similar terms refer to the processing of signals (e.g., signal samples) to generate one or more key-value pairs and to assign the one or more key-value pairs to one or more devices of a system (e.g., a network). The reduction operation and / or similar terms refer to the processing of signals (e.g., signal samples) via aggregation operations (e.g., counting the number of students in a queue, generating name frequencies, etc.). In an embodiment, a system may adopt such an architecture by, for example, marshaling distributed server devices, executing different tasks in parallel, and / or managing communication (such as signal transmission) between various parts of the system (e.g., a network). As mentioned above, one non-limiting but well-known example includes the Hadoop distributed computing system. It refers to an open-source implementation and / or embodiment of the map-reduce type architecture (available from the Apache Software Foundation, 1901 Munsey Drive, Forrest Hill, MD, 21050-2747), but may include other aspects, such as the Hadoop distributed filesystem (HDFS) (available from the Apache Software Foundation, 1901 Munsey Drive, Forrest Hill, MD, 21050-2747). Thus, generally, "Hadoop" and / or similar terms (e.g., "Hadoop type", etc.) refer to an implementation and / or embodiment of a scheduler for performing larger processing jobs using a map-reduce architecture on a distributed system. Additionally, in the context of this patent application, the use of the term "Hadoop" is intended to include currently known and / or later-developed versions.

[0378] In the context of this patent application, the term network device refers to any device capable of communicating via a network and / or being part of a network, and may include computing devices. While network devices may be capable of transmitting signals (e.g., signal packets and / or frames) via, for example, wired and / or wireless networks, they may also be capable of performing operations associated with computing devices, such as arithmetic and / or logical operations, processing and / or storage operations (e.g., storing signal samples), such as in memory as a tangible, physical memory state, and / or may operate as, for example, a server device and / or a client device in different embodiments. Network devices capable of operating as server devices, client devices, and / or otherwise may include, for example, dedicated rack-mounted servers, desktop computers, laptop computers, set-top boxes, tablets, netbooks, smart phones, wearable devices, integrated devices combining two or more features of the foregoing devices, etc., or any combination thereof. As described above, for example, signal packets and / or frames may be exchanged between, for example, server devices and / or client devices and other types of devices, including between wired and / or wireless devices coupled via, for example, wired and / or wireless networks or any combination thereof. Note that the terms, server, server device, server computing device, server computing platform, and / or similar terms may be used interchangeably. Similarly, the terms client, client device, client computing device, client computing platform, and / or similar terms may also be used interchangeably. While in some cases, for ease of description, these terms may be used in the singular, such as by referring to a "client device" or a "server device," the description is intended to cover, as appropriate, one or more client devices and / or one or more server devices. In a similar manner, a reference to a "database" should be understood to refer to one or more databases and / or portions thereof, as the case may be.

[0379] It should be understood that, for ease of description, network devices (also referred to as networked devices) may be embodied and / or described in terms of computing devices and vice versa. However, it should be further understood that this description should in no way be construed as limiting the claimed subject matter to one embodiment, e.g., only computing devices and / or only network devices, but instead may be implemented as a variety of devices or combinations thereof, including (e.g.) one or more of the illustrative examples.

[0380] The network may also include arrangements, derivations, and / or improvements that are now known and / or developed in the future, including, for example, past, present, and / or future mass storage, such as network attached storage (NAS), storage area network (SAN), and / or other forms of device-readable media. The network may include a portion of the Internet, one or more local area networks (LANs), one or more wide area networks (WANs), wired type connections, wireless type connections, other connections, or any combination thereof. Thus, the network may be worldwide in scope and / or extent. Similarly, sub-networks such as those that may employ different architectures and / or may be substantially compatible and / or substantially compatible with different protocols (such as, network computing and / or communication protocols (e.g., network protocols)) may interoperate within a larger network.

[0381] In the context of this patent application, the term sub-network and / or similar terms (e.g., if used in relation to a network) refer to a network and / or a portion thereof. A sub-network may also include links, such as physical links, connections, and / or coupled nodes, in order to be able to transfer signal packets and / or frames between devices of specific nodes, including via wired links, wireless links, or a combination thereof. Different types of devices (such as, network devices and / or computing devices) may be made available, such that device interoperability is enabled and / or may be transparent in at least some instances. In the context of this patent application, the term "transparent", if used in relation to a device of a network, refers to a device that communicates via the network, where the device is able to communicate via one or more intermediate devices, such as one or more intermediate nodes, but the communicating device does not necessarily have to specify one or more intermediate nodes and / or one or more intermediate devices among the one or more intermediate nodes, and / or, thus, devices that communicate via one or more intermediate nodes and / or one or more intermediate devices among the one or more intermediate nodes may be included within the network, but may participate in signal communication as if such intermediate nodes and / or intermediate devices were not involved. For example, a router may provide links and / or connections between otherwise separate and / or independent LANs.

[0382] In the context of this patent application, a "private network" refers to a specific, limited group of devices, such as network devices and / or computing devices, that are capable of communicating with other devices (such as network devices and / or computing devices) within that specific, limited group (such as via packet and / or frame communication), for example without the need for rerouting and / or redirecting signal communication. A private network can include a stand-alone network; however, a private network can also include a subset of a larger network, such as, but not limited to, all or part of the Internet. Thus, for example, a private network "in the cloud" can refer to a private network that includes a subset of the Internet. Although packet and / or frame communication (e.g., signal communication) may employ intermediate devices at intermediate nodes to exchange packets and / or frames, these intermediate devices may not necessarily be included in the private network, such as not being the source or designated destination of one or more packets and / or frames. It should be understood that in the context of this patent application, a private network can direct output signal communication to devices that are not within the private network, but devices outside the private network may not necessarily be able to direct inbound signal communication to devices included in the private network.

[0383] The Internet refers to a decentralized global network of interoperable networks that conform to the Internet Protocol (IP). Note that there are several versions of the Internet Protocol. The terms Internet Protocol, IP, and / or similar terms are intended to refer to any version that is currently known and / or developed in the future. The Internet includes, for example, local area networks (LANs), wide area networks (WANs), wireless networks, and / or long-distance public networks that permit the transfer of packets and / or frames between LANs. The terms World Wide Web (WWW or Web) and / or similar terms may also be used, although it refers to a part of the Internet that conforms to the Hypertext Transfer Protocol (HTTP). For example, network devices can participate in an HTTP session by exchanging appropriately substantially compatible and / or substantially compatible packets and / or frames. Note that there are several versions of the Hypertext Transfer Protocol. The terms Hypertext Transfer Protocol, HTTP, and / or similar terms are intended to refer to any version that is currently known and / or developed in the future. Also note that in different places in this document, substituting the term World Wide Web ("Web") for the term Internet can be done without a significant deviation in meaning, and thus can also be understood in this way if the statement remains correct with such a substitution.

[0384] Although the claimed subject matter is not particularly limited, in scope, to the Internet and / or the Web; nonetheless, the Internet and / or the Web can, without limitation, provide useful examples of embodiments for illustrative purposes at least. As indicated, the Internet and / or the Web can include a global system of interoperable networks, including interoperable devices within those networks. The Internet and / or the Web has evolved into a public, self-sustaining facility that is potentially accessible to billions or more people globally. Also, in embodiments, as noted above, the terms "WWW" and / or "Web" refer to a portion of the Internet that conforms to the Hypertext Transfer Protocol. Thus, in the context of this patent application, the Internet and / or the Web can include, for example, services that organize stored digital content (such as, for example, text, images, video, etc.) by using hypermedia. Note that networks such as the Internet and / or the Web can be used to store electronic files and / or electronic documents.

[0385] Throughout this document, the term electronic file and / or the term electronic document are used to refer to a set of stored memory states and / or a set of physical signals associated in such a way as to form, at least logically, a file (e.g., electronic) and / or an electronic document. That is, it does not imply an implicit reference to, for example, the specific syntax, format, and / or method used with respect to the associated set of memory states and / or the associated set of physical signals. For example, if a specific type of file storage format and / or syntax is intended to be used, that file storage format and / or syntax is explicitly referenced. It should also be noted that the association of memory states can be, for example, in a logical sense and not necessarily in a tangible physical sense. Thus, although, for example, the signal and / or state components of a file and / or an electronic document will be logically associated, in embodiments, their storage can, for example, reside in one or more different locations in tangible physical memory.

[0386] For example, Hyper Text Markup Language ("HTML") can be used to specify digital content and / or to specify its format, such as in the form of an electronic file and / or an electronic document, such as, for example, a web page, a website, etc. In embodiments, Extensible Markup Language ("XML") can also be used to specify digital content and / or to specify its format, such as in the form of an electronic file and / or an electronic document, such as, for example, a web page, a website, etc. Of course, HTML and / or XML are merely examples of "markup" languages provided for illustrative purposes without limitation. Additionally, HTML and / or XML are intended to refer to any currently known and / or later developed versions of these languages. Similarly, the claimed subject matter is, of course, not intended to be limited to the examples provided for explanation.

[0387] In the context of this patent application, the terms "website" and / or similar terms refer to web pages that are electronically associated to form a specific collection thereof. Moreover, in the context of this patent application, "web page" and / or similar terms refer to electronic files and / or electronic documents that are accessible via a network, and in an example embodiment, include a uniform resource locator (URL) designated for access via the Web. As implied above, in one or more embodiments, a web page may include digital content (e.g., via computer instructions) encoded using one or more languages, such as, for example, markup languages including HTML and / or XML, although the claimed subject matter is not limited in scope in this regard. Moreover, in one or more embodiments, an application developer may write code (e.g., computer instructions) in the form of JavaScript (or other programming language), which, for example, may be executed by a computing device to provide digital content so as to populate an electronic document and / or electronic file in an appropriate format, e.g., for use in a specific application. The use of the term "JavaScript" and / or similar terms intended to refer to one or more specific programming languages is intended to refer to any version of one or more programming languages that are identified, now known, and / or later developed. Thus, JavaScript is merely an example programming language. As described above, the claimed subject matter is not intended to be limited to examples and / or illustrations.

[0388] In the context of this patent application, the terms "entry", "electronic entry", "document", "electronic document", "content", "digital content", "item", and / or similar terms are intended to refer to signals and / or states in a physical format, such as digital signal and / or digital state format, e.g., if displayed, played, haptically generated, etc., a user can perceive and / or otherwise be executed by a device (such as, a digital device, including, for example, a computing device), but otherwise may not necessarily be easily perceivable by a human (e.g., if in a digital format). Similarly, in the context of this patent application, digital content provided to a user in a form such that the user can easily perceive the underlying content itself (e.g., content presented in a human-consumable form, such as, hearing audio, feeling a tactile sensation, and / or seeing an image, as examples) is referred to as "consuming" digital content, "consuming" digital content, "consumable" digital content, and / or similar terms with respect to the user. For one or more embodiments, an electronic document and / or electronic file may include, for example, a web page with code (e.g., computer instructions) of a markup language that is executed or to be executed by a computing and / or networking device. In another embodiment, an electronic document and / or electronic file may include a portion and / or region of a web page. However, the claimed subject matter is not intended to be limited to these aspects.

[0389] In addition, for one or more embodiments, an electronic document and / or an electronic file may include multiple components. As previously mentioned, in the context of this patent application, a component is physical but not necessarily tangible. As an example, in one or more embodiments, components referring to an electronic document and / or an electronic file may include, for example, text in the form of physical signals and / or physical states (e.g., capable of being physically displayed). Generally, for example, a memory state includes tangible components, while physical signals are not necessarily tangible, although a signal may become (e.g., be made) tangible, such as if it appears on a tangible display, which is not uncommon. In addition, for one or more embodiments, components referring to an electronic document and / or an electronic file may include graphical objects (such as, for example, images, such as digital images) and / or sub-objects (including their attributes), which also include physical signals and / or physical states (e.g., capable of being tangibly displayed). In an embodiment, digital content may include, for example, text, images, audio, video, and / or other types of electronic documents and / or electronic files, including, for example, portions thereof.

[0390] Moreover, in the context of this patent application, the term parameter (e.g., one or more parameters) refers to material that describes a set of signal samples (such as, one or more electronic documents and / or electronic files) and exists in the form of physical signals and / or physical states (such as, a memory state). For example, one or more parameters (such as, a reference electronic document and / or electronic file, including an image) may include, for example, the date and time of day the image was captured, the latitude and longitude of the image capture device (e.g., a camera), etc. In another example, one or more parameters related to digital content (such as, digital content including, as an example, a technical article) may include, for example, one or more authors. The claimed subject matter is intended to encompass any format of meaningful descriptive parameters, provided that one or more parameters include physical signals and / or states, which may include: as examples of parameters, a set name (e.g., an electronic file and / or electronic document identifier name), a creation technique, a creation purpose, a creation time and date, a logical path (if stored), the encoding format used (e.g., the type of computer instructions, such as a markup language), and / or standards and / or specifications so as to be protocol-compatible for one or more uses (e.g., meaning substantially consistent and / or substantially compatible), and so on.

[0391] Packet communication and / or frame communication, also referred to as packet transfer and / or frame transfer (or simply “packet” or “frame”), can communicate between nodes of a network, where the nodes can include, for example, one or more network devices and / or one or more computing devices. As an illustrative example, but not limited to, the nodes can include one or more stations having a local network address (such as in a local network address space). Similarly, devices such as network devices and / or computing devices can be associated with the node. It should also be noted that, in the context of this patent application, the term “transfer” is intended as another term for a type of signal communication that can occur in any of a variety of situations. Thus, it is not intended to imply a specific directionality of the communication and / or a specific originator of the communication path for the “transfer” communication. For example, in the context of this patent application, the mere use of the term “in” and by itself is not intended to have a specific meaning with respect to one or more signals being communicated, e.g., whether a signal is being transmitted “to” a specific device, whether a signal is being transmitted “from” a specific device, and / or with respect to which end of the communication path can initiate the communication, e.g., in a “push-type” signal transfer or in a “pull-type” signal transfer. In the context of this patent application, push and / or pull-type signal transfers are distinguished by which end of the communication path initiates the signal transfer.

[0392] Thus, as an example, packets and / or frames can be transferred from a station via a communication channel and / or communication path (e.g., including a portion of the Internet and / or the Web) through an access node coupled to the Internet, and vice versa. Similarly, packets and / or frames can be forwarded via network nodes to a target station coupled to a local network. For example, packets and / or frames communicated via the Internet and / or the Web can be routed via a path (such as a “push” or “pull”) that includes one or more routers, servers, etc., which can route the packets and / or frames, for example, generally based on the target and / or destination address and the availability of the network path of the network nodes to the target and / or destination address. Although the Internet and / or the Web include networks of interoperable networks, not all of these interoperable networks are necessarily publicly available and / or accessible.

[0393] In the context of a particular patent application, a network protocol (such as for communicating between devices of a network) can be characterized at least in part substantially according to a layered description (such as a so-called Open Systems Interconnection (OSI) seven-layer type of approach and / or description). A network computing and / or communication protocol (also referred to as a network protocol) refers to a set of signaling conventions for communication transmission, e.g., as may occur between and / or among devices in a network. In the context of this patent application, the term "between" and / or similar terms are understood to include "among" if appropriate for a particular use, and vice versa. Similarly, in the context of this patent application, the terms "compatible with", "consistent with", and / or similar terms are understood to include substantial compatibility and / or substantial consistency, respectively.

[0394] A network protocol (such as a protocol characterized substantially according to the aforementioned OSI description) has several layers. These layers are referred to as a network stack. Different types of communication (e.g., transmission) (such as network communication) can occur across the various layers. The lowest layer in the network stack (such as the so-called physical layer) can characterize how symbols (e.g., bits and / or bytes) are transmitted as one or more signals (and / or signal samples) via a physical medium (e.g., twisted pair copper wire, coaxial cable, fiber optic cable, wireless air interface, combinations thereof, etc.). Moving up to higher layers in the network protocol stack, additional operations and / or features can be obtained by participating in communication of a particular network protocol that is substantially compatible and / or substantially consistent at these higher layers. For example, higher level layers of a network protocol can affect, e.g., device permissions, user permissions, etc.

[0395] In an embodiment, a network and / or sub-network can communicate via packets and / or frames (such as via participating digital devices) and can be substantially consistent and / or substantially compatible with any (but not limited to) currently known and / or later to be developed versions of the following network protocol stacks: ARCNET, Apple Talk, ATM, Bluetooth, DECNet, Ethernet, FDDI, Frame Relay, HIPPI, IEEE 1394, IEEE 802.11, IEEE-488, Internet Protocol Suite, IPX, Myrinet, OSI Protocol Suite, QsNet, RS-232, SPX, System Network Architecture, Token Ring, USB, and / or X.25. A network and / or sub-network can employ, e.g., the following currently known and / or later to be developed versions: TCP / IP, UDP, DECNet, NetBEUI, IPX, Apple Talk, etc. Versions of the Internet Protocol (IP) can include IPv4, IPv6, and / or other later to be developed versions.

[0396] Regarding aspects related to networks (including communication and / or computing networks), a wireless network can couple devices (including client devices) to the network. The wireless network can adopt independent, ad-hoc, mesh, wireless LAN (WLAN) networks, cellular networks, etc. The wireless network can further include a system of terminals, gateways, routers, etc. coupled via wireless radio links, etc., which can organize itself freely, randomly, and / or arbitrarily, such that the network topology can sometimes change and even change rapidly. The wireless network can further adopt a variety of network access technologies, including Long Term Evolution (LTE), WLAN, Wireless Router (WR) mesh, versions of second, third, or fourth generation (2G, 3G, 4G, or 5G) cellular technologies, etc., whether currently known and / or developed in the future. The network access technology can achieve wide-area coverage of devices with different mobilities, such as computing devices and / or network devices.

[0397] The network can implement radio frequency and / or other wireless type communications via wireless network access technologies and / or air interfaces, such as Global System for Mobile communication (GSM), Universal Mobile Telecommunications System (UMTS), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), 3GPP Long Term Evolution (LTE), Advanced LTE, Wideband Code Division Multiple Access (WCDMA), Bluetooth, ultra-wideband (UWB), 802.11b / g / n, etc. Of course, the wireless network can include almost any type of currently known and / or to-be-developed wireless communication mechanisms and / or wireless communication protocols through which signals can communicate between devices, between networks, within networks, etc., including the foregoing.

[0398] In one exemplary embodiment, as Figure 10 shown, the system embodiment can include a local area network (e.g., device 1404 and medium 1440) and / or another type of network, such as a computing and / or communication network. Thus, for illustrative purposes, Figure 10Embodiment 1400 shows a system that can be used to implement either type or both types of networks. Network 1408 may include one or more network connections, links, processes, services, applications, and / or resources to facilitate and / or support communication, such as the exchange of communication signals between a computing device (such as 1402) and another computing device (such as 1406), where the other computing device may include, for example, one or more client computing devices and / or one or more server computing devices. By way of example and not limitation, network 1408 may include wireless and / or wired communication links, telephone and / or telecommunications systems, Wi-Fi networks, Wi-MAX networks, the Internet, local area networks (LANs), wide area networks (WANs), or any combination thereof.

[0399] In an embodiment, Figure 10 The example devices in may include, for example, the characteristics of client computing devices and / or server computing devices. It should be further noted that the term computing device, whether used as a client and / or server or otherwise, refers at least to a processor and a memory connected by a communication bus. Similarly, in the context of this patent application, at least this is understood to refer to sufficient structure within the meaning of 35 USC § 112(f) such that in particular the use of the term "computing device" and / or similar terms is not intended to involve 35 USC § 112(f); however, if for some reason not immediately apparent it is determined that the foregoing understanding cannot stand and thus it is necessary to imply 35 USC § 112(f) by the use of the term "computing device" and / or similar terms, then the corresponding structures, materials, and / or acts for performing one or more functions are intended to be understood and interpreted in accordance with that statutory section as being at least in Figures 1 - 9 and in the text associated with the foregoing figures of this patent application.

[0400] Now referring to Figure 10 , in an embodiment, the first device 1402 and the third device 1406 may be able to present a graphical user interface (GUI) for, for example, network devices and / or computing devices, such that a user operator can participate in system use. In this illustration, the device 1404 may potentially provide a similar function. Similarly, in Figure 10In this case, the computing device 1402 (the 'first device' in the figure) can interact with the computing device 1404 (the'second device' in the figure). The computing device 1404 can, for example, also include the characteristics of a client computing device and / or a server computing device in the embodiments. A processor (e.g., a processing device) 1420 and a memory 1422 (which can include a main memory 1424 and an auxiliary memory 1426) can communicate through, for example, a communication bus 1415. In the context of this patent application, the term 'computing device' refers to a system and / or device (such as a computing device) that includes the ability to process (e.g., perform calculations) and / or store digital content (such as electronic files, electronic documents, measurement values, text, images, videos, audio, sensor content, etc.) in the form of signals and / or states. Therefore, in the context of this patent application, a computing device can include hardware, software, firmware, or any combination thereof (except for software itself). As Figure 10 The computing device 1404 depicted in the figure is only an example, and the scope of the claimed subject matter is not limited to this specific example.

[0401] For one or more embodiments, a device (such as a computing device and / or a network device) can include any of a wide range of digital electronic devices, including but not limited to desktop and / or laptop computers, high-definition televisions, digital versatile discs (DVDs) and / or other optical disc players and / or recorders, game consoles, satellite TV receivers, cellular phones, tablet devices, wearable devices, personal digital assistants, mobile audio and / or video playback and / or recording devices, Internet of Things (IoT)-type devices, endpoints and / or sensor nodes, gateways, router devices, or any combination of the foregoing. Further, unless otherwise specifically stated, the processes described (such as those referenced in flowcharts and / or others) can also be performed and / or affected, in whole or in part, by a computing device and / or a network device. Devices (such as computing devices and / or network devices) can vary in capabilities and / or characteristics. The claimed subject matter is intended to cover a wide range of potential variations. For example, a device can include a numeric keypad and / or other limited-function displays, such as a monochrome liquid crystal display (LCD) for displaying text. However, conversely, as another example, a web-enabled device can include a physical and / or virtual keyboard, a mass storage device, one or more accelerometers, one or more gyroscopes, a global positioning system (GPS) and / or other location identification type capabilities, and / or a display with a higher functionality, such as, for example, a touch-sensitive color 2D or 3D display.

[0402] As previously suggested, communication between a computing device and / or a network device and a wireless network can be based on known and / or to-be-developed network protocols, including, for example, Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), 802.11b / g / n / h, etc., and / or Worldwide Interoperability for Microwave Access (WiMAX). The computing device and / or the network device may also have a subscriber identity module (SIM) card, which may include, for example, a removable or embedded smart card capable of storing the user's subscription content and / or also capable of storing a contact list. However, it should be noted that the SIM card can also be electronic, meaning that it can simply be stored in a specific location in the memory of the computing and / or networking device. For example, a user may own a computing device and / or a network device or may be a user such as a primary user. The device may be assigned an address by a wireless network operator, a wired network operator, and / or an Internet Service Provider (ISP). For example, the address may include a domestic or international telephone number, an Internet Protocol (IP) address, and / or one or more other identifiers. In other embodiments, the computing and / or communication network may be embodied as a wired network, a wireless network, or any combination thereof.

[0403] A computing and / or network device may include and / or execute a variety of currently known and / or to-be-developed operating systems, their derivatives and / or versions, including computer operating systems such as Windows, iOS, Linux, mobile operating systems such as iOS, Android, Windows Mobile, and / or the like. The computing device and / or network device may include and / or execute various possible applications, such as client software applications that enable communication with other devices. For example, one or more messages (e.g., content) may be transmitted via one or more protocols suitable for communication over email, short message service (SMS), and / or multimedia message service (MMS), including via a network (such as a social network) formed at least in part by a portion of a computing network and / or communication network, including but not limited to Facebook, LinkedIn, Twitter, and / or Flickr, to name just a few examples. The computing and / or network device may also include executable computer instructions for processing and / or transmitting digital content (such as, for example, text content, digital multimedia content, sensor content, etc.). The computing and / or network device may also include executable computer instructions to perform different possible tasks, such as browsing, searching, playing different forms of digital content (including locally stored and / or streamed video) and / or games (such as but not limited to fantasy sports leagues). The foregoing is provided only to illustrate that the claimed subject matter is intended to encompass a wide range of possible features and / or capabilities.

[0404] In Figure 10 , for example, computing device 1402 may provide one or more sources of executable computer instructions in the form of a physical state and / or signal (e.g., stored in a memory state). For example, computing device 1402 may communicate with computing device 1404 via a network connection (such as via network 1408). As previously mentioned, although physical, the connection may not necessarily be tangible. Although Figure 10 computing device 1404 shown has various tangible, physical components, the claimed subject matter is not limited to computing devices having only these tangible components, as other implementations and / or embodiments may include alternative arrangements that may include other tangible components or fewer tangible components, for example, that operate in a different manner while achieving similar results. Instead, the examples are provided only for illustration. It is not intended that the scope of the claimed subject matter be limited to the illustrative examples.

[0405] Memory 1422 may include any non-transitory storage mechanism. Memory 1422 may include, for example, main memory 1424 and secondary memory 1426, and additional memory circuits, mechanisms, or combinations thereof may be used. Memory 1422 may include, for example, random access memory, read-only memory, etc., such as in the form of one or more storage devices and / or systems, such as, for example, a disk drive including an optical disk drive, a tape drive, a solid-state memory drive, etc., to name just a few.

[0406] Memory 1422 may be used to store programs of executable computer instructions. For example, processor 1420 may obtain executable instructions from the memory and proceed to execute the obtained instructions. Memory 1422 may also include a memory controller for accessing a device-readable medium 1440 that can carry and / or make accessible digital content, which may include, for example, code and / or instructions executable by processor 1420 and / or some other device (such as a controller, for example) capable of executing computer instructions. Under the guidance of processor 1420, a non-transitory memory (such as a memory unit storing a physical state (e.g., a memory state), including, for example, a program of executable computer instructions) may be executed by processor 1420 and be capable of generating signals to be communicated via a network, as described previously, for example. The generated signals may also be stored in the memory, as previously suggested.

[0407] Memory 1422 may store electronic files and / or electronic documents, such as those related to one or more users, and may also include a computer-readable medium that can carry and / or make accessible content, including, for example, code and / or instructions executable by processor 1420 and / or some other device (such as a controller, by way of example) capable of executing computer instructions. As previously mentioned, throughout this document, the terms electronic file and / or the term electronic document are used to refer to a set of stored memory states and / or a set of physical signals associated in such a way as to form an electronic file and / or an electronic document. That is, it does not implicitly refer, for example, to the specific syntax, format, and / or method used with respect to the associated set of memory states and / or the associated set of physical signals. It should also be noted that the association of memory states, for example, may be in a logical sense and not necessarily in a tangible physical sense. Thus, although the signal and / or state components of an electronic file and / or an electronic document will be logically related, in an embodiment, their storage, for example, may reside in one or more different locations in a tangible physical memory.

[0408] Algorithmic descriptions and / or symbolic representations are examples of techniques used by those of ordinary skill in the signal processing and / or related arts to convey the substance of their work to others in the art. In the context of this patent application, an algorithm is generally regarded as a self-consistent sequence of operations and / or something similar to signal processing that results in a desired outcome. In the context of this patent application, operations and / or processing involve the physical manipulation of physical quantities. Typically, although not necessarily, such quantities can take the form of electrical and / or magnetic signals and / or states that can be stored, transmitted, combined, compared, processed, and / or otherwise manipulated, such as electrical signals and / or states that are components of different forms of digital content (such as signal measurements, text, images, videos, audio, etc.).

[0409] Primarily for reasons of common usage, it has proven convenient at times to refer to such physical signals and / or physical states as bits, values, elements, parameters, symbols, characters, terms, numbers, numerical values, measurements, content, etc. However, it should be understood that all such and / or similar terms will be associated with appropriate physical quantities and are merely convenient labels. Unless otherwise specifically specified, as is apparent from the above discussion, it should be recognized that throughout this specification, discussions using terms such as "processing", "computing", "operating", "determining", "establishing", "acquiring", "identifying", "selecting", "generating", etc. can refer to the actions and / or processes of specific apparatuses such as dedicated computers and / or similar dedicated computing and / or network devices. Thus, in the context of this specification, a dedicated computer and / or similar dedicated computing and / or network device can process, manipulate, and / or transform signals and / or states (typically in the form of physical electrical and / or magnetic quantities) within the memory, registers, and / or other storage devices, processing devices, and / or display devices of the dedicated computer and / or similar dedicated computing and / or network device. In the context of this specific patent application, as described above, the term "specific apparatus" thus includes general computing and / or network devices, such as a general-purpose computer, once it is programmed to perform specific functions, such as according to program software instructions.

[0410] In some cases, operations of a memory device (e.g., a change in state from binary one to binary zero or vice versa) may include a transformation (e.g., a physical transformation), for example. For a particular type of memory device, such a physical transformation may include a physical transformation of an article to a different state or thing. By way of example and not limitation, for certain types of memory devices, a change in state may involve the accumulation and / or storage of charge or the release of stored charge. Similarly, in other memory devices, a change in state may include a physical change, such as a transformation of magnetic orientation. Similarly, a physical change may include a transformation of molecular structure, e.g., from a crystalline form to an amorphous form or vice versa. In yet other memory devices, a change in physical state may involve quantum mechanical phenomena, such as superposition, entanglement, etc., which may involve, for example, qubits (quantum bits). The foregoing is not intended to be an exhaustive list of all examples in which a change in state from binary one to binary zero or vice versa in a memory device may include a transformation (such as a physical but non-instantaneous transformation). Instead, the foregoing is intended as illustrative examples.

[0411] Referring again to Figure 10 , the processor 1420 may include one or more circuits (such as, digital circuits) to perform at least a portion of a computational program and / or process. By way of example and not limitation, the processor 1420 may include one or more processors, such as a controller, a microprocessor, a microcontroller, an application specific integrated circuit, a digital signal processor, a programmable logic device, a field programmable gate array, etc. or any combination thereof. In different implementations and / or embodiments, the processor 1420 may typically perform signal processing substantially in accordance with the acquired executable computer instructions, e.g., to manipulate signals and / or states, construct signals and / or states, etc., where the signals and / or states are generated in a manner such as being transmitted and / or stored in a memory.

[0412] Figure 10 The device 1404 is also shown as including components 1432 that may operate with input / output devices, e.g., such that signals and / or states may be appropriately communicated between devices (such as, the device 1404 and an input device and / or the device 1404 and an output device). A user may utilize an input device, such as a computer mouse, a stylus, a trackball, a keyboard, and / or any other similar device capable of receiving user actions and / or movements as input signals. Similarly, for a device with speech-to-text capabilities, the user may speak to the device to generate an input signal. The user may utilize an output device (such as, a display, a printer, etc.) and / or any other device capable of providing a signal and / or generating a stimulus (such as, a visual stimulus, an audio stimulus, and / or other similar stimuli) to the user.

[0413] In the foregoing description, various aspects of the claimed subject matter have been described. For purposes of explanation, details such as amounts, systems, and / or configurations have been set forth by way of example. In other instances, well-known features have been omitted and / or simplified so as not to obscure the claimed subject matter. Although certain features have been shown and / or described herein, many modifications, substitutions, changes, and / or equivalents thereof will now occur to those of ordinary skill in the art. Accordingly, it is to be understood that the appended claims are intended to cover all such modifications and / or changes that fall within the scope of the claimed subject matter.

Claims

1. A method, comprising: At a graph router computing device, one or more graph link operations are performed, including: Obtaining a query from a client computing device, where the query includes one or more fields that are specified in a GraphQL schema to one or more links to one or more remote graphs, and where the one or more links to the one or more remote graphs include one or more specified entities and / or entity references; Generating a query plan, at least in part, by accessing one or more schema registries respectively associated with the one or more remote graphs; Executing the query plan, at least in part, by obtaining content from one or more network services at least partially specified by the query plan; and Returning the query result to the client computing device.

2. The method according to claim 1, wherein Generating the query plan includes: determining one or more APIs responsible for serving the one or more specified entities.

3. The method according to claim 2, wherein The one or more specified entities include: one or more GraphQL types with one or more @key directives.

4. The method according to claim 1, wherein The one or more schema registries respectively associated with the one or more remote graphs contain: schemas published to the schema registry under a specific namespace referenced in other graphs.

5. The method according to claim 1, further comprising: Performing runtime validation on the obtained query, where some parts of the query are locally validated, and where a separate GraphQL schema is used to validate one or more link types.

6. The method according to claim 5, wherein, Generating the query plan and / or executing the query plan occur at runtime, and where generating the query plan and / or executing the query plan at runtime includes: query planning and / or resolving fields present in the local schema, and further includes: delegating query planning and / or query execution of parts of the query to one or more linked remote graphs.

7. The method according to claim 6, wherein, To facilitate generating the query plan and / or executing the query plan at runtime, the query includes one or more entity references that specify one or more corresponding entities via one or more respective namespaces, entity types, and / or key (id) fields, enabling the graph router computing device to look up one or more APIs responsible for serving the one or more specified entities.

8. The method according to claim 1, wherein Generating the query plan includes: selecting fields from multiple namespaces without regard for API boundaries, and where the one or more schema registries track the mapping between namespaces and / or schema elements.

9. An apparatus including a diagram router computing device, wherein, To perform one or more graph link operations, the graph router computing device is configured to: Obtain a query from a client computing device, where the query includes one or more links to one or more remote graphs, and where the one or more links to the one or more remote graphs include one or more specified entities and / or entity references; Generate a query plan, at least in part, by accessing one or more schema registries respectively associated with the one or more remote graphs; Execute the query plan by obtaining content at least in part from one or more web services at least in part specified by the query plan; and Return the query result to the client computing device.

10. The device according to claim 9, wherein, To generate the query plan, the graph router computing device is used to determine one or more APIs responsible for serving the one or more specified entities.

11. The device according to claim 10, wherein, The one or more specified entities include: one or more GraphQL types indicated by one or more @ keys.

12. The device according to claim 9, wherein, The one or more schema registries respectively associated with the one or more remote graphs contain: schemas published to the schema registry under a specific namespace referenced in other graphs.

13. The apparatus according to claim 9, wherein The graph router computing device further performs runtime verification on the obtained query, wherein some parts of the query are locally verified, and wherein a separate GraphQL schema is used to verify one or more link types.

14. The apparatus according to claim 13, wherein, The graph router computing device is used to generate the query plan and / or execute the query plan at runtime, and wherein, to generate the query plan and / or execute the query plan at runtime, the graph router computing device is used to execute the query plan and / or resolve fields existing in the local schema, and is further used to delegate the query plan and / or query execution of parts in the query to the one or more linked remote graphs.

15. The apparatus according to claim 14, wherein, To facilitate executing the generation of the query plan and / or executing the query plan at runtime, the query includes one or more entity references that specify one or more corresponding entities via one or more corresponding namespaces, entity types, and / or key (id) fields, enabling the graph router computing device to find one or more APIs responsible for serving the one or more specified entities.

16. The device according to claim 9, wherein To generate the query plan, the graph router computing device is used to select fields from multiple namespaces without regard to API boundaries, and wherein the one or more schema registries track the mapping between namespaces and / or schema elements.

17. An article, comprising: A storage medium having instructions stored thereon that can be executed by a graph router computing device to: perform one or more graph linking operations, wherein the graph router is used to: Obtain a query from a client computing device, wherein the query includes one or more links to one or more remote graphs, and wherein the one or more links to the one or more remote graphs include one or more specified entities and / or entity references; Generate a query plan at least in part by accessing one or more schema registries respectively associated with the one or more remote graphs; Execute the query plan by obtaining content at least in part from one or more data stores at least in part specified by the query plan; and Return the query result to the client computing device.

18. The article according to claim 17, wherein, To generate the query plan, the graph router computing device is used to determine one or more APIs responsible for serving the one or more specified entities.

19. The article according to claim 18, wherein, The one or more specified entities include: one or more GraphQL types indicated by one or more @ keys.

20. The article according to claim 17, wherein The one or more schema registries respectively associated with the one or more remote graphs contain: schemas published to the schema registry under a specific namespace referenced in other graphs.

Images