Multiple workspace database engine

In various example embodiments, multiple workspaces have access to modify values in a graph database. The graph database can comprise a collection of entity nodes, where each entity node is connected to an identifier node and one or more state nodes. An update to an entity node can be recorded by generating a new state node to store the update and connecting the new state node to the entity node. How each workspace views the database is based, at least in part, on which state nodes are associated with each workspace. The workspaces are independent of one another, and changes made to an entity node in one workspace do not affect how another workspace views the same entity node. By managing database data for each of the workspaces using the same graph database and recording changes in state nodes in an additive manner, the computational overhead is greatly reduced and simplified.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to database operations and, more particularly, but not by way of limitation, to managing multiple workspaces using a database engine.

BACKGROUND

Databases are used to manage data for networked systems. In some cases, multiple administrators have access to and manage the same database in parallel. Multiple administrators having management-level access to the same database causes consistency issues. In some cases, each of the different administrators requires different views of a database. For example, a first administrator may want to view the database arranged in a first way, while a second administrator may want to view the same database arranged in a second way, different from the first way. The administrators may further make changes to values in the database from different views. Keeping a database consistent while allowing multiple administrators management-level access, while allowing each of the administrators to manage the database in potentially different views, and while tracking changes made from different views is a complex task that requires large amounts of computational overhead.

DETAILED DESCRIPTION

In various example embodiments, multiple workspaces have access to modify values of a graph database that is organized as a collection of entity nodes, where each entity node is connected to an identifier node and one or more state nodes. Connections between nodes correspond to relationships between nodes. For example, an entity node may be stored as a data object that references which other nodes the entity node is connected to. Connections may in some example embodiments be visually depicted by lines or edges connecting the nodes in the graph database. An entity node corresponds to a data item to be tracked in the graph database. Changes to entity nodes are recorded by generating a new state node to store the change and connecting the new state node to the entity node. How each workspace views the database is based, at least in part, on which state nodes are associated with each workspace. The workspaces are independent of one another, and changes made to an entity node in one workspace do not affect how another workspace views the same entity node in the graph database. By managing database data for each of the workspaces using the same graph database and recording changes in state nodes in an additive manner, the computational overhead is greatly reduced and simplified.

FIG. 1is a block diagram illustrating various functional components of a multi workspace engine implemented in a network architecture100, according to some example embodiments. A networked system102provides server-side functionality via a network104(e.g., the Internet or a wide area network (WAN)) to one or more client devices110. In some implementations, a user (e.g., user106) interacts with the networked system102using the client device110.FIG. 1illustrates, for example, a web client112(e.g., an Internet browser), an application114, and a programmatic client116executing on the client device110. The client device110includes the web client112, the application114, and the programmatic client116alone, together, or in any suitable combination. AlthoughFIG. 1shows one client device110, in other implementations, the network architecture100comprises multiple client devices110.

In various implementations, the client device110comprises a computing device that includes at least a display and communication capabilities that provide access to the networked system102via the network104. The client device110comprises, but is not limited to, a remote device, work station, computer, general-purpose computer, Internet appliance, hand-held device, wireless device, portable device, wearable computer, cellular or mobile phone, personal digital assistant (PDA), smart phone, tablet, ultrabook, netbook, laptop, desktop, multi-processor system, microprocessor-based or programmable consumer electronic system, game console, set-top box, network personal computer (PC), mini-computer, and so forth. In an example embodiment, the client device110comprises one or more of a touch screen, accelerometer, gyroscope, biometric sensor, camera, microphone, Global Positioning System (GPS) device, and the like.

The client device110communicates with the network104via a wired or wireless connection. For example, one or more portions of the network104comprises an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the public switched telephone network (PSTN), a cellular telephone network, a wireless network, a Wireless Fidelity (WI-FI®) network, a worldwide interoperability for microwave access (WiMax) network, another type of network, or any suitable combination thereof.

In some example embodiments, the client device110includes one or more of the applications114(also referred to as “apps”) such as, but not limited to, web browsers, book reader apps (operable to read e-books), media apps (operable to present various media forms including audio and video), fitness apps, biometric monitoring apps, messaging apps, electronic mail (email) apps, and e-commerce site apps (also referred to as “marketplace apps”). In some implementations, the application114includes various components operable to present information to the user106and communicate with the networked system102.

The web client112accesses the various systems of the networked system102via the web interface supported by a web server122. Similarly, the programmatic client116and application114access the various services and functions provided by the networked system102via the programmatic interface provided by an application programming interface (API) server120. The programmatic client116can, for example, be a seller application (e.g., the Turbo Lister application developed by EBAY® Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the networked system102in an offline manner, and to perform batch-mode communications between the programmatic client116and the networked system102.

Users (e.g., the user106) comprise a person, a machine, or another means of interacting with the client device110. In some example embodiments, the user106is not part of the network architecture100, but interacts with the network architecture100via the client device110or another means. For instance, the user106provides input (e.g., touch screen input or alphanumeric input) to the client device110and the input is communicated to the networked system102via the network104. In this instance, the networked system102, in response to receiving the input from the user106, communicates information to the client device110via the network104to be presented to the user106. In this way, the user106can interact with the networked system102using the client device110.

The API server120and the web server122are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers140. The application server140can host a multi workspace engine150, which comprises one or more modules or applications, each of which can be embodied as hardware, software, firmware, or any combination thereof. The application server140is, in turn, shown to be coupled to one or more database servers124that facilitate access to one or more information storage repositories or databases126. In an example embodiment, the database126is a storage device that stores information in a graph database155. The graph database155can be accessed by administrators operating through different client devices110. In some example embodiments, the multiple administrators access data from the graph database155through different workspaces. Different workspaces are different in that they are kept as distinct environments that display data from the graph database155. In some example embodiments, each administrator accesses a workspace using login credentials (e.g., username, password).

Additionally, a third party application132, executing on a third party server130, is shown as having programmatic access to the networked system102via the programmatic interface provided by the API server120. For example, the third party application132, utilizing information retrieved from the networked system102, supports one or more features or functions on a website hosted by a third party. Further, while the client-server-based network architecture100shown inFIG. 1employs a client-server architecture, the present inventive subject matter is, of course, not limited to such an architecture, and can equally well find application in a distributed, or peer-to-peer, architecture system, for example. The various systems of the application server140(e.g., the multi workspace engine150) can also be implemented as standalone software programs, which do not necessarily have networking capabilities.

FIG. 2illustrates a block diagram showing various functional modules of the multi workspace engine150, according to some example embodiments. The components themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, so as to allow information to be passed between the applications or so as to allow the applications to share and access common data. Furthermore, the components access the one or more databases126via the database server124. As illustrated, the multi workspace engine150comprises an interface engine210, a workspace user interface (UI) engine220, a graph database engine230, and a transfer engine250. The interface engine210manages communications with different network components (e.g., communications with the third party server130or the client device110) over the network104. The workspace UI engine220is responsible for generating user interfaces for different workspaces and their corresponding node datasets. According to some example embodiments, a workspace is a user interface environment that allows a user to make changes to data being tracked by a database126. A workspace may include a displayed user interface, as well as configuration data used to configure the given workspace. The configuration data, in some example embodiments, includes node set data which defines which nodes of the graph database155a given workspace displays and manages. Examples of workspaces are illustrated inFIGS. 5A, 5B, and 7. The data displayed in the workspaces is tracked on the backend, e.g., in the graph database155. For example, inFIG. 7, the Lewis Carroll data element505is tracked by entity node410(FIG. 6).

According to some example embodiments, a given workspace displays data according to with which nodes of a graph database155the given workspace is associated. The nodes which a given workspace can view, edit, or manage are in the given workspace's node set. For example, assume that a graph database155comprises five nodes: A, B, C, D, and E, and further assume that the graph database155is viewable through two workspaces: workspace_1and workspace_2. Workspace_1may be associated with nodes A, B, and C, but not associated with nodes D or E. Accordingly, workspace_1can display data values from nodes A, B, and C, in a user interface (e.g., workspace user interface500ofFIG. 5A). However, workspace_1does not display data values from nodes D and E because workspace_1is not associated with nodes D and E (e.g., nodes D and E are not in workspace_1's node set). Similarly, if workspace_2is associated only with node D, workspace_2only displays node D data in its user interface.

In some embodiments, a plurality of workspaces display data from the same graph database155, and each of the workspaces has a corresponding node set made up of nodes in the graph database155. In some embodiments, to simplify workspace management, each workspace is isolated from the other workspaces in that changes in each workspace do not affect nodes displayed in another workspace.

The graph database engine230manages updating and managing the database126including the graph database structure155(FIG. 1). In at least some example embodiments, the graph database engine230is configured to generate entity nodes as sets of nodes, where each entity node is generated with a connected identification (ID) node and a connected state node. The ID node persistently (e.g., permanently) identifies its connected entity node in the system. The state node stores the current value of the entity node. In some embodiments, an entity node is connected to a default state node that stores the original value (e.g., initial value) of the entity node. In some example embodiments, the default value is the value assigned to the entity node upon the entity node being created in the graph database155. In some example embodiments, the default state is the initial state for the entity node before one or more state changes to the entity node occur. In some example embodiments, the default state node is set to a newly created node. For example, an entity node may have an original default state node, and a current state node that reflects an update to the entity node. In those example embodiments, the default state node can be set to the current state node, and subsequent updates cause newer current state nodes to be created. In this way, when resetting nodes to their default value, the default value can be shifted to different times and values.

In some example embodiments, changes to the default state node are stored in subsequently created current state nodes, which are created and connected to the entity node. In some embodiments, when the value of a given entity node is updated, the graph database engine230does not delete the default state node (or the existing current state node) but rather connects a new current state node and stores a latest update value in the most recently created current state node. The changes made by a first workspace may cause the graph database engine230to create a new current state node for an entity node, while maintaining the previous state node for other workspaces to track and use (e.g., the previous state nodes are in the node sets of the other workspaces).

The transfer engine250manages transferring one or more nodes between workspaces. In some example embodiments, all nodes are tracked in a single graph database155, which is portioned off into node sets for different workspaces to use. When one or more nodes are to be transferred from a source workspace to a destination workspace, the transfer engine250may reset the transferred entity nodes to their default state node values.

FIG. 3Adisplays multiple client devices performing updates to a graph data structure, according to some embodiments.FIG. 3Adisplays an interaction diagram300depicting network interactions between a client device110a, a client device110b, and a multi workspace engine150which is managing a graph database155. Each column of the interaction diagram300corresponds to actions performed by the entity at the top of the column. For example, the client device110aperforms operations320,330, and345. Data values generated at a given operation may be transferred over the dotted lines which can signify, in some example embodiments, transfers over the network104.

In the example embodiments illustrated inFIG. 3A, the client device110ais making changes in a first workspace, through a first workspace user interface. The first workspace is associated with a first node set comprising nodes in the graph database155. Similarly, the client device110bis making changes in a second workspace, through a second workspace user interface. The second workspace is associated with a second node set comprising nodes in the graph database155. The nodes in the first and second node sets can overlap. For example, each of the first and second node sets may make changes to the same entity node.FIG. 3Ashows an example method of two different workspaces both making changes to the same entity node.

At operation310, the multi workspace engine150transmits workspace user interfaces to the client devices110a,110b. For example, the multi workspace engine150transmits the first workspace user interface of a first workspace to the first client device110aand transmits the second workspace interface of a second workspace to the second client device110b. At operation320, the client device110adisplays the first workspace user interface. At operation330, a user106of the client device110asubmits a first update to an entity node. For example, the user106changes the entity node value from “published year” to “book condition”. At operation335, the multi workspace engine150receives the change to the entity node, and connects a state node storing the value of “book condition”. At operation337, the multi workspace engine150updates the first node set so that the first workspace is associated with the state node storing the value “book condition”, and de-associates the state node storing the value “published year” from the first node set.

At operation340, the multi workspace engine150transmits the updated first workspace user interface to the client device110afor display within the first workspace user interface. At operation345, the first client device110adisplays the first workspace user interface per the updated first node set, which now reflects the value of the entity node as “book condition”.

As discussed, the changes by different workspaces do not affect other workspaces. Thus, the changes by the client device110ain the first workspace do not affect the client device110bin the second workspace. Thus, according to some example embodiments, the client device110bdisplays the second workspace with the entity node still reflecting the “published year” value. Continuing at operation325, the second client device110bdisplays the second workspace user interface that was received from the multi workspace engine150. At operation350, the second client device110bsubmits a second update to the same entity node that was modified in operation330by the client device110a. As the two workspaces are independent, the second workspace still sees the entity node as having the “published year” value in its state node. The update to the entity node performed at operation350may, for example, request that the entity node value be changed from “published year” to “book size”.

At operation355, the multi workspace engine150receives the second state node update from the second workspace user interface, generates a new current state node storing the value “book size”, and connects the state node to the entity node in the graph database155.

After the graph database155has been updated, the change still needs to be reflected in the second workspace. Thus, at operation357, the multi workspace engine150updates the second node set for the entity by removing the state node storing the value of “published year” from the second node set, and inserting the state node storing the value of “book size” in the second node set.

At operation360, the multi workspace engine150transmits an updated second workspace user interface to the second client device110b. At operation365, the second client device110bdisplays the second workspace user interface that displays the value of “book size” for the entity node.

FIG. 3Billustrates a method370for performing multi workspace database updates on the same machine, according to some embodiments. For example, in some embodiments, the same server may manage the graph database operations, generate and display the first and second workspace user interfaces, and make changes to the graph database155and workspaces. At operation372, the multi workspace engine150provides the first and second workspace user interfaces for display on the display screen of the client device110. At operation374, the multi workspace engine150receives an update request from the first workspace user interface. At operation376, a new state node is generated in the graph database structure. At operation378, the first workspace user interface node set is updated to include the new state node such that the first workspace user interface displays values from the new state node update. At operation380, the multi workspace engine150provides the first workspace user interface with the updated value for display on the client device110. At operation382, the multi workspace engine150displays or provides for display the second workspace user interface that retains the default value of the node, not updated.

FIG. 4illustrates a graph data structure405comprising a plurality of nodes, according to some example embodiments. In some example embodiments, the graph data structure can be displayed on a user interface of a computer, such as graph database user interface400generated from a graph database application (e.g., Neo4j). The nodes in the graph data structure405are represented by circles. The edges connecting the nodes are depicted as lines that connect the circles (e.g., nodes). In the graph data structure405, an entity node corresponds to a data item to be managed for display or tracking in the graph data structure405. For example, an entity node410corresponds to “Lewis Carroll”, the author. The Lewis Carroll entity node410is a parent to an entity node425, which corresponds to “Phantasmagoria”, a title of a book that Lewis Carroll wrote. The entity node410is also parent to an entity node440which has a value of “Alice”, which is a short version of “Alice's Adventures in Wonderland”, which is another book that Lewis Carroll wrote. Thus, the graph data structure405is managing books that a given author (Lewis Carroll) wrote. It is appreciated that the graph data structure405can be used to track any sort of data items, and not just authors and books.

According to some example embodiments, each entity node has two nodes associated with it, an ID node and a default state node. For example, the Lewis Carroll entity node410has an ID node415and a default state node420connected to it. InFIG. 4, the ID node415has an identifier key value of 5487. As explained, in some example embodiments, the ID node for a given entity node stays the same, and functions as a persistent (e.g., permanent) identifier for the connected entity node. Changes to the entity node are recorded in the state nodes, not the ID node. As explained above, the default state node420captures the default value or state of the Lewis Carroll entity node410. Not all state nodes need store a default value for a connected entity node. For example, the default state node420does not store a value for the Lewis Carroll entity node410, as indicated by the example null hashtag “#”. Referring to the entity node425, which is the entity node for “Phantasmagoria”, one of Lewis Carroll's books, the associated ID node430has a key value of 5488 and the default state node435reflects the year “1869”, which is the yearPhantasmagoriawas published. Similarly, the Alice entity node440has an ID node445with a key value of 5489. The Alice entity node440is further associated with a default state node450, which has a value of the year “1865”, which is the year thatAlice's Adventures in Wonderlandwas first published.

FIG. 5Aillustrates a workspace user interface500generated from graph database data, according to some embodiments. The graph data structure405can be used as a data source to generate user interfaces such as the workspace user interface500, illustrated inFIG. 5A. In some example embodiments, the workspace user interface500shows a display of what will be generated and available on the front-end (e.g., public facing) side of a given website. Workspaces have the ability to view data elements in a what you see is what you get (WYSIWYG) manner. The data elements are generated from data values from the graph data structure405. In particular, a data element505corresponds to the entity node410, a data element510corresponds to the entity node440, a data element520corresponds to the entity node425, a data element515corresponds to the default state node450, and a data element525corresponds to the default state node435. The workspace user interface500may be generated from programmatic code that specifies which data values to retrieve from the graph data structure405. For example, the data element515may be generated from programmatic code configured to display, as the data element515, the current value of the node having the permanent ID of 5489. The graph database engine230determines that the Alice entity node440is associated with the ID node445(which is identified by the permanent ID value 5489). The graph database engine230then retrieves the current value for display as the data element515. As the current value of the Alice entity node440is the value of the default state node450, the graph database engine230returns the value of the default state node450, which is the year “1865”, for display as the data element515, as illustrated inFIG. 5A. Other data elements inFIG. 5Aare populated in a similar manner (e.g., identifying nodes using the ID nodes, and retrieving the current values for display as data elements in the workspace user interface500).

FIG. 5Billustrates a workspace user interface500with an edit area503, according to some example embodiments. As illustrated, the workspace user interface500is configured to allow a user106to view the data elements in the WYSIWYG view alongside the edit area503, which is configured to make changes to the WYSIWYG view. It is appreciated that, in some example embodiments, the front-end WYSIWYG view is optional and may, for example, be displayed on pages completely independent from an edit interface, such as the edit area503.

The edit area503has one or more control objects, such as a control interface527. The control interface527allows the user106to change the state of the entity nodes. In the illustrated example ofFIG. 5B, the control interface527has text entry fields for values to be appended after the title of each book. Assuming, for example, that the user106wants the listings to display the state of the book (e.g., book being sold) instead of the year a given book was published, the user106can then input into a first text box528the term “NEW”, which indicates that the first book (Alice's Adventures in Wonderland) is in a new condition. The user106can further input into a second text box529the term “USED”, which indicates that the second book (Phantasmagoria) is in a used condition. Upon the user106pressing “submit”, the workspace UI engine220receives the data input into the first text box528and second text box529, and passes the received data values to the graph database engine230. The graph database engine230then creates new current state nodes and stores the received values in them.FIG. 6shows an illustrative example.

In particular.FIG. 6shows the graph data structure405updated per changes received from a workspace, according to some examples. The value received from the first text box528(“NEW”) is stored in a current state node475which is connected to the Alice entity node440. The value received from the second text box529(“USED”) is stored in a current state node470, which is connected to the entity node425. The workspace UI engine220then updates the node set for the first workspace by removing default state nodes (e.g., default state node435and default state node450) and adding the current state node470and current state node475. In some example embodiments, the node set is further updated to include data indicating which current state node is connected to which entity node (e.g., the current state node470is connected to the entity node425, and the current state node475is connected to the entity node440). For example, the user106can choose to display condition instead of publisher year. Assuming the user106does select to display the condition of the book instead of displaying the publisher year, the graph database structure illustrated will be modified by adding a new state node with the new value for that workspace.FIG. 6shows the resulting changes to the graph data structure405, as a result of the data input through the control interface527. As illustrated, the “Phantasmagoria” entity node425is connected to the current state node470, which stores the input data value “used”. Likewise, the “Alice” entity node440is connected to the current state node475, which stores the input data value of “new”.

FIG. 7illustrates the workspace user interface500updated with data from the updated graph data structure405, according to some embodiments.FIG. 7is similar toFIG. 5Awith the exception of the data element515, which has a value of “NEW” instead of “1865”, and with the exception of the data element525, which has the value of “USED” instead of “1869”. As discussed, the newly created state nodes are connected in an additive manner. That is, new changes from a workspace cause new state nodes to be created, and previously existing state nodes (e.g., default state node435, default state node450) are not removed.FIG. 7may be illustrating a workspace user interface500of the workspace that submitted the changes (e.g., changes switching the listings from the published year value to the book condition value), while other workspaces may still show the listings as having published year values.

FIG. 8illustrates an architecture diagram805depicting nodes being transferred between two workspaces, according to some example embodiments. When nodes are transferred from one workspace to another workspace, the state of each entity node is reset to the value of the default state node for each respective entity node. Resetting the nodes to their default state values can, in some example embodiments, simplify node management as nodes are transferred between different workspaces. In the example embodiment illustrated inFIG. 8, a set of nodes is transferred from a source workspace810to a destination workspace815. Continuing the above example, assume that the default state nodes contain the published year data, but that current nodes have been connected to entity nodes storing the newer book condition data. At operation820, each of the entity nodes is reset to its default current node value. Thus, upon being displayed in the destination workspace815, the transferred nodes will again display the published year data for each of the entity nodes. In some embodiments, the values can be reset to different points in time, or to different state nodes, upon being transferred to the destination workspace815. For example, in some example embodiments, assume that an entity node has five state nodes connected to it: a default state node, a first state node, a second state node, a third state node, and a current state node. Each of the state nodes stores values for changes made to the entity node, in a time sequential manner. That is, for example, the default state node was initially created and stored an default value for the entity node, then the first state node was created to store a value at a first point in time, the second state node was created to store a value at a later second point in time, and the current state node stores the last received change to the entity node.

In some example embodiments, resetting to different state nodes is implemented by changing what state node is assigned as the default state node. The nodes that reflect updates occurring after the update to the currently assigned state node can be reset to whatever node is currently assigned as the default state node.

In some example embodiments, entity nodes are reset to state nodes that are not the default state nodes and not the current state node. For example, the entity node having five state nodes may be transferred to the destination workspace815and be reset to the second state node value during the transfer. In some example embodiments, the nodes are configured to be reset to the relative offset (e.g., reset entity node to the third from last state node). In some example embodiments, the transfer engine250identifies whether the transferred entity node existed at one point in time in the destination workspace815, and sets the transferred entity node to the last state node that the entity node was assigned in the destination workspace815. In some example embodiments, the transferred entity node already exists in the destination workspace815, and the transferred node is not transferred.

In some embodiments, the state node currently active or in the node set of the source workspace810is used to override the value of the already existing entity node in the destination workspace815. For example, assume that the source workspace810and destination workspace815both manage the Phantasmagoria entity node425. Further assume that the source workspace810displays the Phantasmagoria listing with the published year data and the destination workspace815displays the Phantasmagoria listing with the book condition data. In some example embodiments, the user106may select a group of nodes for transfer to the destination workspace815. The multi workspace engine150may be configured to overwrite existing values of nodes in the destination workspace815. Thus, upon the Phantasmagoria entity node425being transferred, the destination workspace815has its node set updated so that the Phantasmagoria listing from the destination workspace815shows the published year data. In this way, transferred nodes can be reset to different state node values because all state node values are tracked in the same graph database155and all workspaces share the graph database155to manage data.

FIG. 9illustrates a flow diagram of a method900for transferring nodes between workspaces, according to some example embodiments. At operation910, the transfer engine250receives instructions to transfer nodes to the destination workspace815. At operation920, the transfer engine250transfers the selected nodes to the destination workspace815. At operation930, the transfer engine250updates the node set for the destination workspace815. In some example embodiments, the transfer engine250sets the state of the entity nodes to a pre-configured value upon transfer. For example, the pre-configured value may be the default state node; thus, upon transferring the selected nodes, the transfer engine250resets the transferred nodes to their default state node vales (e.g., by updating the node set of the destination workspace815to include the default state nodes for the transferred entity nodes). Similarly, the transfer engine250may reset the transferred nodes to different values of different state nodes, as discussed above with reference toFIG. 8.

FIG. 10is a block diagram illustrating components of a machine1000, according to some example embodiments, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically.FIG. 10shows a diagrammatic representation of the machine1000in the example form of a computer system, within which instructions1016(e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine1000to perform any one or more of the methodologies discussed herein can be executed. For example, the instructions1016can cause the machine1000to execute the flow diagrams ofFIGS. 3A, 3B, and 9. Additionally, or alternatively, the instructions1016can implement the interface engine210, the workspace user interface (UI) engine220, the graph database engine230, the transfer engine250, and so forth. The instructions1016transform the general, non-programmed machine1000into a particular machine1000programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine1000operates as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine1000may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine1000can comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions1016, sequentially or otherwise, that specify actions to be taken by the machine1000. Further, while only a single machine1000is illustrated, the term “machine” shall also be taken to include a collection of machines1000that individually or jointly execute the instructions1016to perform any one or more of the methodologies discussed herein.

The machine1000can include processors1010, memory/storage1030, and I/O components1050, which can be configured to communicate with each other such as via a bus1002. In an example embodiment, the processors1010(e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) can include, for example, a processor1012and a processor1014that may execute the instructions1016. The term “processor” is intended to include multi-core processors1010that may comprise two or more independent processors1012,1014(sometimes referred to as “cores”) that can execute the instructions1016contemporaneously. AlthoughFIG. 10shows multiple processors1010, the machine1000may include a single processor1012with a single core, a single processor1012with multiple cores (e.g., a multi-core processor), multiple processors1012,1014with a single core, multiple processors1012,1014with multiples cores, or any combination thereof.

The memory/storage1030can include a memory1032, such as a main memory, or other memory storage, and a storage unit1036, both accessible to the processors1010such as via the bus1002. The storage unit1036and memory1032store the instructions1016embodying any one or more of the methodologies or functions described herein. The instructions1016can also reside, completely or partially, within the memory1032, within the storage unit1036, within at least one of the processors1010(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine1000. Accordingly, the memory1032, the storage unit1036, and the memory of the processors1010are examples of machine-readable media.

In further example embodiments, the I/O components1050can include biometric components1056, motion components1058, environmental components1060, or position components1062among a wide array of other components. For example, the biometric components1056can include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram based identification), and the like. The motion components1058can include acceleration sensor components (e.g., an accelerometer), gravitation sensor components, rotation sensor components (e.g., a gyroscope), and so forth. The environmental components1060can include, for example, illumination sensor components (e.g., a photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., a barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensor components (e.g., machine olfaction detection sensors, gas detection sensors to detect concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components1062can include location sensor components (e.g., a Global Positioning System (GPS) receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

Communication can be implemented using a wide variety of technologies. The I/O components1050may include communication components1064operable to couple the machine1000to a network1080or devices1070via a coupling1082and a coupling1072, respectively. For example, the communication components1064include a network interface component or other suitable device to interface with the network1080. In further examples, the communication components1064include wired communication components, wireless communication components, cellular communication components, near field communication (NFC) components, BLUETOOTH® components (e.g., BLUETOOTH® Low Energy), WI-FI® components, and other communication components to provide communication via other modalities. The devices1070may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a Universal Serial Bus (USB)).

The instructions1016can be transmitted or received over the network1080using a transmission medium via a network interface device (e.g., a network interface component included in the communication components1064) and utilizing any one of a number of well-known transfer protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, the instructions1016can be transmitted or received using a transmission medium via the coupling1072(e.g., a peer-to-peer coupling) to the devices1070. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions1016for execution by the machine1000, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.