Patent ID: 12222986

DETAILED DESCRIPTION

Existing architectures, such as that described in relation toFIG.1above, maintain a forced technical, and sometimes physical, separation between the processing logic and the data. As previously stated, the technical and physical separation of data and processing logic can be inhibitive to the types of architectural systems that can be created. Furthermore, the complexity of n-tier architectures, and their strict separation of functionality (layers), can severely impact system real-time processing performance. This, in turn, leads to processing delays or latency which reduces the applicability of such architectures being used in time-critical application settings such as medical devices, autonomous vehicles, and real-time control systems. In addition, the central storage of all data within a single database or database layer (e.g., the database layer108show inFIG.1) restricts the ways in which a user may access, maintain, and manage their personal data stored by an enterprise within the single database or database layer.

The present disclosure is directed to executable graph-based models which dynamically combine data and data processing functionality at run-time whilst their separability may be maintained when at rest. This is illustrated inFIG.2.

FIG.2illustrates an executable graph-based model202according to an embodiment of the present disclosure.

The executable graph-based model202is generally formed of a data structure (i.e., a graph-based model, or graphical model) comprising a plurality of nodes204-208which can be functionally extended with processing logic via the use overlays210,212. Each overlay comprises processing logic, such as processing logic214and216which are associated with overlays210and212respectively. At run-time, data such as data218,220is associated with nodes within the executable graph-based model202and the overlays210,212provide the functionality to respond to stimuli and interact with, manipulate, or otherwise process the data. As such, the structure and functionality of the data processing is separate from the data itself when offline (or at rest) and is combined dynamically at run-time.

As such, the executable graph-based model202maintains separability of the data and the data processing logic when offline thereby allowing the data to maintain control over their data. Moreover, by integrating the data and the data processing logic within a single model, processing delays or latency are reduced because the data and the processing logic exist within the same logical system. Therefore, the executable graph-based model202is applicable to a range of time-critical systems where efficient processing of stimuli is required.

FIG.3shows a system300for execution, management, and configuration of executable graph-based models according to an embodiment of the present disclosure.

The system300comprises an executable graph-based model302as described in brief above in relation toFIG.2. The system300further comprises an interface module304, a controller module306, a transaction module308, a context module310, a stimuli management module312, a data management module314, an overlay management module316, a memory management module318, a storage management module320, a security module322, a visualization module324, an interaction module326, an administration module328, an operations module330, and an analytics module332.FIG.3further shows a configuration334, a context336, data338, stimuli340, a network342, and an outcome344.

The skilled person will appreciate that the present description of the system300is not intended to be limiting, and the system300can include, or interface with, further modules not expressly described herein. Moreover, the functionality of two or more of the modules can be combined within a single module. Conversely, the functionality of a single module can be split into two or more further modules which can be executed on two or more devices. The modules described below in relation to the system300can operate in a parallel, distributed, or networked fashion. The system300can be implemented in software, hardware, or a combination of both software and hardware. Examples of suitable hardware modules include, a general-purpose processor, a field programmable gate array (FPGA), and/or an application specific integrated circuit (ASIC). Software modules can be expressed in a variety of software languages such as C, C++, Java, Ruby, Visual Basic, Python, and/or other object-oriented, procedural, or other programming language.

The executable graph-based model302corresponds to application-specific combination of data and processing functionality which is manipulated, processed, and/or otherwise handled by the other modules within the system300. As stated above, the structure and functionality of the data processing is separate from the data itself when offline (or at rest) and is combined dynamically at run-time. As such, different executable graph-based models are utilized for different application areas and problem domains. The skilled person will appreciate that whilst only one executable graph-based model302is shown inFIG.3, in some embodiments a system stores and maintains more than one executable graph-based model.

Each element within the executable graph-based model302(both the data and the data processing functionality) is a node. As will be described in more detail in relation toFIG.4Abelow, a node forms the fundamental building block of all executable graph-based models. As such, the executable graph-based model302comprises one or more nodes which can be dynamically generated, extended, or processed by one or more other modules within the system300(e.g., by the data management module314and/or the overlay management module316).

The interface module304provides a common interface between internal components of the system300and/or external sources. The interface module304provides an application programmable interface (“API”), scripting interface, or any other suitable mechanism for interfacing externally or internally with any module of the system300. In the example shown inFIG.3, the configuration334, the context336, the data338, and the stimuli340are received by the interface module304of the system300via the network342. Similarly, outputs produced by the system300, such as the outcome344, are passed by the interface module304to the network342for consumption or processing by external systems. In one embodiment, the interface module304supports one or more messaging patterns or protocols such as the Simple Object Access protocol (SOAP), the REST protocol, and the like. The interface module304thus allows the system300to be deployed in any number of application areas, operational environments, or architecture deployments. Although not illustrated inFIG.3, the interface module304is communicatively coupled (i.e., connected either directly or indirectly) to one or more other modules or elements within the system300such as the controller module306, the context module310, the executable graph-based model302and the like. In one embodiment, the interface module304is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The controller module306handles and processes interactions and executions within the system300. As will be described in more detail below, stimuli (and their associated contexts) provide the basis for all interactions within the executable graph-based model302. Processing of such stimuli may lead to execution of processing logic associated with one or more overlays within the executable graph-based model302. The processing of a stimulus within the system300may be referred to as a system transaction. The processing and execution of stimuli (and associated overlay execution) within the system300is handled by the controller module306. The controller module306manages all received input stimuli (e.g., the stimuli340) and processes them based on a corresponding context (e.g., the context336). The context associated with a stimulus determines the priority that is assigned to processing the stimulus by the controller module306. This allows each stimulus to be configured with a level of importance and prioritization within the system300.

The controller module306maintains the integrity of the modules within the system300before, during, and after a system transaction. The transaction module308, which is associated with the controller module306, is responsible for maintaining integrity of the system300through the lifecycle of a transaction. Maintaining system integrity via the controller module306and the transaction module308allows a transaction to be rolled back in the event of an expected or unexpected software or hardware fault or failure. The controller module306is configured to handle the processing of stimuli and transactions through architectures such as parallel processing, grid computing, priority queue techniques, and the like. In one embodiment, the controller module306and the transaction module308are communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

As stated briefly above, the system300utilizes a context-driven architecture whereby a stimulus within the system300is associated with a context which is used to adapt the handling or processing of the stimulus by the system300. The context module310manages the handling of contexts within the system300and is responsible for processing any received contexts (e.g., the context336) and translating the received context to an operation execution context. In some examples, the operation execution context is larger than the received context because the context module310supplements the received context with further information necessary for the processing of the received context. The context module310passes the operational execution context to one or more other modules within the system300to drive the execution of the stimulus associated with the operational execution context. Contexts within the system300can be external or internal. While some contexts apply to all application areas and problem spaces, some applications may require specific contexts to be generated and used to process received stimuli. As will be described in more detail below, the executable graph-based model302is configurable (e.g., via the configuration334) so as only to execute within a given execution context for a given stimulus.

The stimuli management module312processes externally received stimuli (e.g., the stimuli340) and any stimuli generated internally from any module within the system300. The stimuli management module312is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302to facilitate processing of stimuli within the executable graph-based model302. The system300utilizes different types of stimuli such as a command (e.g., a transactional request), a query, or an event received from an external system such as an Internet-of-Things (IoT) device. As previously stated, a stimulus can be either externally or internally generated. For example, a stimulus can be an event internally triggered (generated) from any of the modules within the system300. Such internal stimuli indicate that something has happened within the system300such that subsequent handling by one or more other modules within the system300may be required. Internal stimuli can also be triggered (generated) from execution of processing logic associated with overlays within the executable graph-based model302. The stimuli management module312communicates and receives stimuli in real-time or near-real-time. In some examples, stimuli are scheduled in a batch process. The stimuli management module312utilizes any suitable synchronous or asynchronous communication architectures or approaches in communicating the stimuli (along with associated information). All stimuli within the system300are received and processed (along with a corresponding context) by the stimuli management module312, which then determines the processing steps to be performed. In one embodiment, the stimuli management module312processes the received stimuli in accordance with a predetermined configuration (e.g., the configuration334) or dynamically determines what processing needs to be performed based on the contexts associated with the stimuli and/or based on the state of the executable graph-based model302. In some examples, processing of a stimulus results in one or more outcomes being generated (e.g., the outcome344). Such outcomes are either handled internally by one or more modules in the system300or communicated via the interface module304as an external outcome. In one embodiment, all stimuli and corresponding outcomes are recorded for auditing and post-processing purposes (e.g., by the operations module330and/or the analytics module332).

The data management module314manages all data or information within the system300(e.g., the data338) for a given application. Operations performed by the data management module314include data loading, data unloading, data modelling, and data processing. The data management module314is communicatively coupled (i.e., connected either directly or indirectly) to one or more other modules within the system300to complete some or all of these operations. For example, data storage is handled in conjunction with the storage management module320(as described in more detail below).

The overlay management module316manages all overlays within the system300. Operations performed by the overlay management module316includes overlay and overlay structure modelling, overlay logic creation and execution, and overlay loading and unloading (within the executable graph-based model302). The overlay management module316is communicatively coupled (i.e., connected either directly or indirectly) to one or more other modules within the system300to complete some or all of these operations. For example, overlays can be persisted in some form of physical storage using the storage management module320(as described in more detail below). As a further example, overlays can be compiled and preloaded into memory via the memory management module318for faster run-time execution. The design and functionality of overlays is discussed in greater detail in relation toFIG.4Abelow.

The memory management module318is configured to manage and optimize the memory usage of the system300. The memory management module318thus helps to improve the responsiveness and efficiency of the processing performed by one or more of the modules within the system300by optimizing the memory handling performed by these modules. The memory management module318uses direct memory or some form of distributed memory management architecture (e.g., a local or remote caching solution). Additionally, or alternatively, the memory management module318deploys multiple different types of memory management architectures and solutions. (e.g., reactive caching approaches such as lazy loading or a proactive approach such as write-through cache may be employed). These architectures and solutions are deployed in the form of a flat (single-tiered) cache or a multi-tiered caching architecture where each layer of the caching architecture can be implemented using a different caching technology or architecture solution approach. In such implementations, each cache or caching tier can be configured (e.g., by the configuration334) independently to the requirements for one or more of modules of the system300. For example, data priority and an eviction strategy, such as least-frequently-used (“LFU”) or least-recently-used (“LRU”), can be configured for all or parts of the executable graph-based model302. In one embodiment, the memory management module318is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The storage management module320manages the temporary or permanent storage of data within the system300. The storage management module320is any suitable low-level storage device solution (such as a file system) or any suitable high-level storage technology such as another database technology (e.g., relational database management system (RDBMS) or NoSQL database). The storage management module320is directly connected to the storage device upon which the relevant data is persistently stored. For example, the storage management module320can directly address the computer readable medium (e.g., hard disk drive, external disk drive, or the like) upon which the data is being read or written. Alternatively, the storage management module320is connected to the storage device via a network such as the network342shown inFIG.3. As will be described in more detail below in relation toFIGS.12and13, the storage management module320uses “manifests” to manage the interactions between the storage device and the modules within the system300. In one embodiment, the storage management module320is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The security module322manages the security of the system300. This includes the security at a system level and at a module level. Security is hardware related, network related, or software related, depending on the operational environment, the architecture of the deployment, or the data and information contained within the system300. For example, if the system is deployed with a web-accessible API (as described above in relation to the interface module304), then the security module322can enforce a hypertext transfer protocol secure (HTTPS) protocol with the necessary certification. As a further example, if the data or information received or processed by the system300contains Personally Identifiable Information (PII) or Protected Health Information (PHI), then the security module322can implement one or more layers of data protection to ensure that the PII or PHI are correctly processed and stored. In an additional example, in implementations whereby the system300operates on United States of America citizen medical data, the security module322can enforce additional protections or policies as defined by the United States Health Insurance Portability and Accountability Act (HIPAA). Similarly, if the system300is deployed in the European Union (EU), the security module322can enforce additional protections or policies to ensure that the data processed and maintained by the system300complies with the General Data Protection Regulation (“GDPR”). In one embodiment, the security module322is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302thereby directly connecting security execution to the data/information in the executable graph-based model302. The security module322thus acts as a centralized coordinator working in conjunction with the data management module314and overlay management module316for managing and executing security-based overlays.

The visualization module324and the interaction module326facilitate display and interaction of the executable graph-based model302and other parts of the system300. As described in more detail below in relation toFIGS.9A-9G, the visualization module324provides one or more displays, or visualizations, of the executable graph-based model302for review by a user of the system300, whilst the interaction module326processes user interactions (e.g., inputs, commands, etc.) with the displays, or visualizations, and/or any other module within the system300. The visualization module324and the interaction module326provide complex interactions capabilities such as standard two- and three-dimensional device interactions using a personal computer or mobile device and their attachable peripherals (e.g., keyboard, mouse, screen, etc.). Additionally, or alternatively, visualization module324and the interaction module326provide more advanced multi-dimensional user and visualization experiences such as virtual reality (“VR”) or augmented reality (“AR”) solutions. In one embodiment, the visualization module324and the interaction module326are communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The administration module328manages all configurable aspects of the system300and the associated modules therein. Configuration is either directly embedded within the modules of the system300(for example, via hardware, bios, or other systems settings that are preset in the manufacturing process or software development and installation processes) or provided as dynamic configurations (e.g., via the configuration334). Such dynamic configurations are controllable and changeable by an end-user with the appropriate administrative privileges. In one embodiment, the degree of administrative privileges associated with an end-user are contained within a received context (e.g., the context336). Here, the end-user is a person connected to the administration module328via the interface module304or a system user directly connected to the administration module328. In one embodiment, the administration module328provides read-only access to all configuration settings or allows some (or all) of the configuration settings to be changed by specific user groups defined in the administration module328(e.g., all users associated with a user group having sufficient access privileges). In embodiments where configurations are pre-set or predetermined, the administration module328provides capabilities to reset or return the system300to its initial state or “factory settings”. In one embodiment, the administration module328is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The operations module330tracks operational metrics, module behavior, and the system300. Operational metrics tracked by the operations module330include the running status of each module, the operating performance of transactions performed, and any other associated metrics to help determine the compliance of the entire system, or any module thereof, in relation to non-functional requirements. In one embodiment, the operations module330is communicatively coupled (i.e., connected either directly or indirectly) to one or more overlays within the executable graph-based model302.

The analytics module332performs any analytical processing required by the modules within the system300. The analytics module332processes any data embedded, or overlay contained, within the executable graph-based model302or created separately by the system300(e.g., the operation metrics produced by the operations module330). As such, the analytics module332is communicatively coupled (i.e., connected either directly or indirectly) to one or more nodes and/or one or more overlays within the executable graph-based model302.

Having now described the system300for executing and managing executable graph-based models, the description will now turn to the elements of an executable graph-based model; specifically, the concept of a node. Unlike conventional graph-based systems, all objects (e.g., data, overlays, etc.) within the executable graph-based model (e.g., the executable graph-based model302) are implemented as nodes. As will become clear, this allows executable graph-based models to be flexible, extensible, and highly configurable.

FIG.4Ashows the general structure of a node402within an executable graph-based model, such as the executable graph-based model302shown inFIG.3, according to an embodiment of the present disclosure.

FIG.4Ashows a node402which corresponds to the core structure of an executable graph-based model (e.g., the executable graph-based model302shown in the system300ofFIG.3) and which forms the foundational building block for all data and data processing logic within the executable graph-based model. The node402comprises properties404, inheritance identifiers406, and node type408. The node402optionally comprises one or more attributes410, metadata412, a node configuration414. The properties404of the node402include a unique identifier416, a version identifier418, a namespace420, and a name422. The properties404optionally include one or more icons424, one or more labels426, and one or more alternative identifiers428. The inheritance identifiers406of the node402comprise an abstract flag430, a leaf flag432, and a root flag434. The node configuration414optionally comprises one or more node configuration strategies436and one or more node configuration extensions438.FIG.4Afurther shows a plurality of predetermined node types440which include a data node type442, a value node type444, an edge node type446, a role node type448, and an overlay node type450.

The unique identifier416is unique for each node within an executable graph-based model. The unique identifier416is used to register, manage, and reference the node402within the system (e.g., the system300ofFIG.3). In some embodiments, the one or more alternative identifiers428are associated with the unique identifier416to help manage communications and connections with external systems (e.g., during configuration, sending stimuli, or receiving outcomes). The version identifier418of the node402is incremented when the node402undergoes transactional change. This allows the historical changes between versions of the node402to be tracked by modules or overlays within the system. The namespace420of the node402, along with the name422of the node402, is used to help organize nodes within the executable graph-based model. That is, the node402is assigned a unique name422within the namespace420such that the name422of the node402need not be unique within the entire executable graph-based model, only within the context of the namespace420to which the node402is assigned.

The node402optionally comprises one or more icons424which are used to provide a visual representation of the node402when visualized (e.g., by the visualization module324of the system300shown inFIG.3). The one or more icons424can include icons at different resolutions and display contexts such that the visualization of the node is adapted to different display settings and contexts. The node402also optionally comprises one or more labels426which are used to override the name422when the node is rendered or visualized.

The node402supports the software development feature of multiple inheritance by maintaining references (not shown) to zero or more other nodes, which then act as the base of the node402. This allows the behavior and functionality of a node to be extended or derived from one or more other nodes within an executable graph-based model. The inheritance identifiers406of the node402provide an indication of the inheritance-based information, which is applicable, or can be applicable, to the node402. The inheritance identifiers406comprise a set of Boolean flags which identify the inheritance structure of the node402. The abstract flag430of the inheritance identifiers406allows the node402to support the construct of abstraction. When the abstract flag430takes a value of “true”, the node402is flagged as abstract meaning that it cannot be instantiated or created within an executable graph-based model. Thus, a node having the abstract flag430set to “true” can only form the foundation of another node that inherits from it. By default, the abstract flag430of a node is set to “false”. The leaf flag432of the inheritance identifiers406is used to indicate whether any other node can inherit from the node402. If the leaf flag432is set to “true”, then no other node can inherit from the node402(but unlike an abstract node, a node with a leaf flag set can still be instantiated and created within an executable graph-based model). The root flag434of the inheritance identifiers406is used to indicate whether the node402inherits from any other node. If the root flag434is set to “true”, then the node402does not inherit from any other node. The node402is flagged as leaf (i.e., the leaf flag432is set to “true”) and/or root (i.e., the root flag434is set to “true”), or neither (i.e., both the leaf flag432and the root flag434are set to “false”). The skilled person will appreciate that a node cannot be flagged as both abstract and leaf (i.e., the abstract flag430cannot be set to “true” whilst the leaf flag432is set to “true”).

As stated above, all elements of the executable graph-based model are defined as nodes. This functionality is in part realized due to the use of a node type. The node type408of the node402is used to extend the functionality of the node402. All nodes within an executable graph-based model comprise a node type which defines additional data structures and implements additional executable functionality. A node type thus comprises data structures and functionality that is common across all nodes which share that node type. The composition of a node with a node type therefore improves extensibility by allowing the generation of specialized node functionalities for specific application areas. Such extensibility is not present in prior art graph-based models. As illustrated inFIG.4A, the node402and the node type408are one logical unit which are not separated in the context of an executing system at run-time (i.e., in the context of execution of an executable graph-based model).

FIG.4Ashows the plurality of predetermined node types440which provides a non-exhaustive list of node types which can be associated with a node, such as the node402.

The data node type442(also referred to as a vertex or vertex node type) comprises common data structure and functionality related to the “things” modelled in the graph—i.e., the data.

The value node type444comprises common data structures and functionality related to a shared attribute stored at the associated node. Whilst shared attributes are discussed in more detail below, a node having the value node type444comprises an attribute value (i.e., the attribute state) which is shared between nodes within the executable graph-based model.

The edge node type446comprises common data structures and functionality related to joining two or more nodes. A node having the edge node type446can connect two or more nodes and thus the edge node type446constructs associations and connections between nodes (for example objects or “things”) within the executable graph-based model. The edge node type446is not restricted to the number of nodes that can be associated or connected by a node having the edge node type446. The data structures and functionality of the edge node type446thus define a hyper-edge which allows two or more nodes to be connected through a defined set of roles. As will be described in more detail below, a role which defines a connective relationship involving an edge is either a (standard) role, as is known within standard hyper-graph theory such that the role merely defines a connection between the edge and another node, or the role is a node having the role node type448. These concepts are illustrated inFIGS.5and5Bdescribed below.

FIG.5illustrates the concept of a hyper-edge connecting two or more nodes through a defined set of roles, according to an embodiment of the present disclosure.

FIG.5shows a simplified representation of an edge node502which comprises an edge node type504(within the context of the example shown inFIG.4A, the edge node502corresponds to the node402where the node type408is the edge node type446). The edge node type504comprises a plurality of roles which each define a connective relationship involving the edge node502, e.g., a connective relationship between the edge node502and another node. The plurality of roles of the edge node type504comprises a first role node506and a role508. The plurality of roles optionally comprises a further role in the form of a second role node510. The first role node506is a node having a role node type (i.e., the role node type448shown inFIG.4A) and defines a connective relationship between the edge node502and a first node512. The role508defines a connective relationship between the edge node502and a second node514. The second role node510is a node having the role node type and defines a relationship without expressly defining the node to which the edge connects. Whilst the example inFIG.5shows the edge node type504having two, or even three, roles, the number of roles (and thus the number of connections) that an edge node type can have is not so limited.

As stated above, a role defines a connective relationship involving the edge node502(via the edge node type504) and can be either a (standard) role, such as the role508, or a role node, such as the first role node506or the second role node510. The standard role simply defines a connective relationship between an edge node and another node. Thus, in the example shown inFIG.5, the role508defines the connection between the edge node502and the second node514(via the edge node type504). A role node is a node having a role node type (i.e., the role node type448shown inFIG.4A) and, like the (standard) role, defines a connective relationship involving an edge. However, because a role node is a node, a role node gains the capabilities, functionality, and extensibility of a node (as described in relation toFIG.4A). A role node thus describes a potentially more complex connective relationship than a (standard) role. In the example shown inFIG.5, the first role node506defines a connective relationship between the edge node502and the first node512(via the edge node type504). Beneficially, by utilizing the first role node506to define the connective relationship between the edge node502and the first node512the capabilities afforded to a node are provided to the first role node506. For example, and as will be described in more detail below, one or more overlay nodes can be associated with a role node to imbue the role node with processing logic thus allowing the role node to process data, respond to stimuli, etc. Moreover, a role node need not define a connective relationship to a node, as illustrated by the second role node510. Because the second role node510is itself a node, the second role node510encompasses the data structures and functionality of a node thereby avoiding the need to define the connecting node directly.

Referring once again toFIG.4A, the plurality of predetermined node types440further comprise the overlay node type450. As will be described in more detail below, the overlay node type450is used to extend the functionality of a node, such as the node402, to incorporate processing logic.

The one or more attributes410correspond to the data associated with the node402(e.g., the data represented by the node402within the executable graph-based model as handled by a data management module such as the data management module314of the system300shown inFIG.3). Because not all nodes within an executable graph-based model is associated with data, a node need not have any attributes. Each of the one or more attributes410are stored in any suitable format such as a data triplet of name, value type, and value. The one or more attributes410represent a complex data type—each attribute of the one or more attributes410is composed of an attribute behavior, as shown inFIG.6.

FIG.6illustrates attribute behaviors according to embodiments of the present disclosure.

FIG.6shows a plurality of attributes602including a first attribute604, a second attribute606, a third attribute608, and a fourth attribute610. In an embodiment, one or more of the plurality of attributes correspond to the one or more attributes410of the node402shown inFIG.4A. Each of the plurality of attributes shown inFIG.6is composed of an attribute behavior which defines the behavior of the corresponding attribute. The first attribute604is composed of a standard attribute behavior612, the second attribute606is composed of a reference attribute behavior614, the third attribute608is composed of a derived attribute behavior616, and the fourth attribute610is composed of a complex attribute behavior618. The attribute behaviors of the plurality of attributes are configured by associated attribute configurations. These attribute configurations are all examples of attribute configuration extensions which are node configuration extension (i.e., they are part of the one or more node configuration extensions438of the node402shown inFIG.4A). The standard attribute behavior612is configured by a standard attribute configuration620, the reference attribute behavior614is configured by a reference attribute configuration622, the derived attribute behavior616is configured by a derived attribute configuration624, and the complex attribute behavior is configured by a complex attribute configuration626.

As stated in more detail below, an attribute behavior defines the behavior of the corresponding attribute. The standard attribute behavior612, associated with the first attribute604, is a behavior which allows read-write access to the data of the first attribute604. The reference attribute behavior614, associated with the second attribute606, is a behavior which allows read-write access to the data of the second attribute606but restricts possible values of the data to values defined by a reference data set. The reference attribute configuration622(which is used to configure the reference attribute behavior614) includes the appropriate information to obtain the reference data set of possible values. The derived attribute behavior616, associated with the third attribute608, is a behavior which allows read-only access to the data of the third attribute608. The data of the third attribute608is derived from other data, or information, within the executable graph-based model in which the node of the third attribute608is used. The data is derived from one or more other attributes associated with the node or is derived from more complex expressions depending on the application area. In one embodiment, the derived attribute configuration624(which is used to configure the derived attribute behavior616) includes mathematical and/or other forms of expressions (e.g., regular expressions, templates, and the like) that are used to derive the data (value) of the third attribute608. The complex attribute behavior618, associated with the fourth attribute610, is a behavior which allows the fourth attribute610to act as either a standard attribute behavior612if the data of the fourth attribute610is directly set, or a derived attribute behavior616if the data of the fourth attribute610is not directly set.

Referring once again toFIG.4A, the node402optionally comprises metadata412(e.g., data stored as a name, value type, and value triplet) which is associated with either the node402or one or more of the one or more attributes410of the node402.

An attribute within the one or more attributes410may either have independent or shared state. An independent attribute has data which is not shared with any other node within the executable graph-based model. Conversely, a shared attribute has data which is shared with one or more other nodes within the executable graph-based model. For example, if two nodes within an executable graph-based model both comprise a shared-data attribute with a value state shared by both nodes, then updating the data (e.g., the value) of this shared attribute will be reflected across both nodes.

The node configuration414provides a high degree of configurability for the different elements of a node. The node configuration414optionally comprises one or more node configuration strategies436and/or one or more node configuration extensions438which are complex data types (as described above in more detail below in relation toFIG.6). An example of a concrete node configuration strategy is an identifier strategy, associated with the configuration of the unique identifier416of the node402, which creates Snowflake identifiers. A further example of a concrete node configuration strategy is a versioning strategy, associated with the configuration of the version identifier418of the node402, which supports major and minor versioning (depending on the type of transactional change incurred by the node402).

According to an embodiment of the present disclosure, the structure and functionality of the node402(as described above) can be dynamically extended using the concept of an executable node. As described in relation toFIG.4Bbelow, an executable node provides processing functionality (i.e., processing logic) for a base node via one or more associated overlay nodes.

FIG.4Bshows an executable node452, according to an embodiment of the present disclosure.

The executable node452comprises a base node454and an overlay manager456. The overlay manager456registers and maintains one or more overlay nodes associated with the base node454, such as the first overlay node458and the second overlay node460. The first overlay node458has a first overlay node type462and the second overlay node460has a second overlay node type464.

The executable node452is itself a node; that is, the executable node452extends the node402(or is a subtype of the node402) such that all the functionality and properties of the node402extend to the executable node452. The executable node452also dynamically extends the functionality of the base node454by associating the overlays maintained by the overlay manager456with the base node454. The executable node may thus be considered a composition of a base node and an overlay node and may alternatively be referred to as a node with overlay. For example, the base node454may have a data node type associated with a user, and the overlay manager456may comprise an encryption overlay which has processing logic that encrypts the attribute values of the base node454prior to the values being saved or output from the system. Therefore, the executable node452acts as a decorator of the base node454adding the functionality of the overlay manager456to the base node454.

The skilled person will appreciate that the base node454refers to any suitable node within an executable graph-based model. As such, the base node454can be a node having a type such as a data node type, a value node type, or the like. Alternatively, the base node454can itself be an executable node such that the functionality of the base (executable) node454is dynamically extended. In this way, complex and powerful processing functionality can be dynamically generated by associating and extending overlay nodes.

The overlay manager456registers and maintains one or more overlay nodes associated with the base node454, such as the first overlay node458and the second overlay node460. The assignment of an overlay node to a base node (via the overlay manager456) endows the base node with processing logic and executable functionality defined within the overlay node. Extending the functionality of a base node through one or more overlay nodes is at the heart of the dynamic generation of executable graph-based models according to an embodiment of the present disclosure. As illustrated inFIG.2above, the data (e.g., a data node as represented by the base node454inFIG.4B) and the functionality which acts upon that data (e.g., an overlay node) can be separated and independently maintained offline, but at run-time, an association between the data node and the overlay node is determined and an executable node is generated (e.g., the executable node452shown inFIG.4B).

An overlay node, such as the first overlay node458or the second overlay node460, is a node having an overlay node type (alternatively referred to as an overlay type) assigned to its node type. As shown inFIG.4B, the first overlay node458has the first overlay node type462and the second overlay node460has the second overlay node type464. Different overlay node types are used to realize different functionality. Example overlay node types include an encryption overlay node type, an obfuscation overlay node type, an audit overlay node type, a prediction overlay node type, and the like. For example, if the first overlay node type462is an obfuscation node type and the second overlay node type464is an encryption node type then the functionality of the base node454is extended to provide obfuscation and encryption of attribute values of the base node454. The skilled person will appreciate that the list of overlay types is in no way exhaustive and the number of different overlay types that can be realized is not limited. Because an overlay node is itself a node, all functionality of a node described in relation to the node402ofFIG.4Ais thus applicable to an overlay node. For example, an overlay node comprises a unique identifier, a name, etc., can have attributes (i.e., an overlay node can have its own data defined), supports multiple inheritance, and can be configured via node configurations. Furthermore, because an overlay node is a node, the overlay node can have one or more overlay nodes associated therewith (i.e., the overlay node is an overlay with overlay node). Moreover, the processing functionality of an overlay node extends to the node type of the node to which the overlay node is applied.

An overlay node, such as the first overlay node458or the second overlay node460, is not bound to a single executable node or a single executable graph-based model (unlike nodes which have non-overlay node types). This allows overlay nodes to be centrally managed and reused across multiple instances of executable graph-based models.

Unlike non-overlay nodes, an overlay node comprises processing logic (not shown inFIG.4B) which determines the functionality of the overlay node. The processing logic of an overlay node comprises a block of executable code, or instructions, which carries out one or more operations. The block of executable code is pre-compiled code, code which requires interpretation at run-time, or a combination of both. Different overlay nodes provide different processing logic to realize different functionality. For example, an encryption overlay node comprises processing logic to encrypt the data (i.e., attributes) of a data node associated with the encryption overlay node, whilst an auditing overlay node comprises processing logic to record changes to the nodes state of a node associated with the auditing overlay node.

The overlay manager456of the executable node452is responsible for executing all overlays registered with the overlay manager456. The overlay manager456also coordinates execution all associated overlay nodes. In the example shown inFIG.4B, the executable node452associates the base node454with two overlay nodes—the first overlay node458and the second overlay node460. Thus, the overlay manager456employs a strategy to manage the potentially cascading execution flow. Example strategies to manage the cascading execution of overlays include the visitor pattern and the pipe and filter pattern. Further examples include strategies which apply either depth-first or depth-first processing patterns, a prioritization strategy, or a combination therefor. All execution strategies are defined and registered with the overlay manager456and are associated with an overlay via a node configuration extension for the overlay.

Before describing an example executable graph-based model, the description will turn to the decomposition of an executable node for persistent storage, as shown inFIG.4C.

FIG.4Cillustrates the decomposition of an executable node466for storage, according to an embodiment of the present disclosure.

The executable node466(e.g., the executable node452shown inFIG.4B) comprises a composition of a base node468and an overlay node470. The executable node466comprises a state472with an identifier474, the base node468comprises a state476with an identifier478, and the overlay node470comprises a state480with an identifier482. A manifest484-488is generated for each of the executable node466, the base node468, and the overlay node470. The manifest484associated with the executable node466comprises an identifier490and an overlay identifier492. The manifest486associated with the base node468comprises an identifier494and the manifest488associated with the overlay node470comprises an identifier496.

The state472of the executable node466comprises all data required to reconstruct the executable node466(e.g., attributes, properties, etc.). The state472of the executable node466is persistently stored along with the identifier474. The manifest484is generated for the executable node466and comprises the identifier490(which is the same as the identifier474), the storage location of the state472of the executable node466, and the overlay identifier492(which is the same as the identifier496). The overlay identifier492thus identifies the manifest488associated with the overlay node470. A manifest state (not shown) is then generated for the manifest484and persistently stored along with the identifier490.

The state476of the base node468comprises all data required to reconstruct the base node468(e.g., attributes, properties, etc.) and is persistently stored along with the identifier478. The manifest486is generated for the base node468and comprises the identifier494and the storage location of the state476of the base node468. The identifier478of the state476and the identifier494of the manifest486is the same as the identifier474of the state472of the executable node466(which is also the same as the identifier490of the manifest484of the executable node466). A manifest state (not shown) is then generated for the manifest486and persistently stored along with the identifier494. Thus, the states, manifests, and manifest states for the executable node466and the base node468all comprise the same, shared, identifier. A shared identifier can be used in this instance because the states, manifests, and manifest states are stored separately.

The state480of the overlay node470comprises all data required to reconstruct the overlay node470(e.g., attributes, properties, processing logic, etc.) and is persistently stored along with the identifier482. The manifest488is generated for the overlay node470and comprises the identifier496, which is the same as the identifier482. A manifest state (not shown) is then generated for the manifest488and is persistently stored along with the identifier496.

As will be described in more detail in relation toFIGS.12and13below, an executable graph-based model may be stored (and loaded) using the above described decomposition. Beneficially, each component is stored separately thereby allowing a user to maintain and store their data independently of the storage of the structure and functionality of the executable graph-based model.

Having described the structure and function of the node402(FIG.4A) and the executable node452(FIG.4B), which form the foundation of an executable graph-based model, an example executable graph-based model will now be described to provide further understanding of the aspects/embodiments described above.

FIG.7Aillustrates a system700to be modelled by an executable graph-based model, according to an embodiment of the present disclosure.

The system700comprises a gear pump702, a vale704, and a flow limiter706. The valve704comprises a sensor708configured to obtain one or more pressure measurements from the valve704. The flow limiter706comprises a sensor710configured to obtain one or more pressure measurements from the flow limiter706. The gear pump702comprises an outlet712which is in fluid communication with an inlet714of the valve704. The valve704comprises a first outlet716and a second outlet718. The first outlet716of the valve704is in fluid communication with a waste outlet720of the system700. The second outlet718of the valve704is in fluid communication with an inlet722of the flow limiter706. An outlet724of the flow limiter706is in fluid communication with an outlet726of the system700.

The system700shown inFIG.7Ais a simplified industrial system whereby a fluid (e.g., a gas or a liquid) is pumped via the gear pump702to the valve704. During normal operation, the valve704is set such that the fluid flows through the flow limiter706to the outlet726. The flow limiter706acts to restrict the amount of fluid that passes out of the system700through the outlet726. The sensor710measures the pressure at the flow limiter706such that if the pressure exceeds a predetermined threshold amount (e.g., due to a malfunction in the flow limiter706or an exceptional surge of liquid through the system700) then the valve704can be adjusted such that the fluid is diverted straight to the waste outlet720.

The skilled person will appreciate that the system700described above is deliberately simplified to provide an example through which the application of an executable graph-based model to a control system can be described. As such, the system700is not intended to provide a detailed working embodiment of a fluidic control system but is rather illustrative for the purpose of explaining the functionality and benefits of the executable graph-based model when applied to such real-world systems. Moreover, the system700is not intended to be limiting and the skilled person will appreciate that executable graph-based models can be applied to any suitable application area or problem domain.

To avoid damage to components connected to the outlet726of the system700, the sensor710of the flow limiter706requires real-time pressure monitoring. Furthermore, a low latency response to instruct the valve704to direct fluid to the waste outlet720should be made to limit damage to components as a result of potential surges. The executable graph-based model as described above in relation toFIGS.3,4A and4Bprovides such a low latency, real-time, system as described below.

FIG.7Bshows an executable graph-based model728of the system700illustrated inFIG.7A.

The executable graph-based model728comprises a gear pump node730, a valve edge node732, and a flow limiter edge node734. The gear pump node730extends a pump node736which is an executable node (as indicated by the outer circle encompassing the pump node736) having an audit overlay node738. The valve edge node732comprises an inlet role node740and an outlet role node742. As such, the valve edge node732defines the connective relationship between the gear pump node730, the flow limiter edge node734, and the outlet role node742. The valve edge node732is an executable node having a sensor overlay node744(which is itself an executable node comprising the audit overlay node738and a conversion overlay node746). The inlet role node740is an executable node having the audit overlay node738. The valve edge node732has a further role (not shown) which connects to the flow limiter edge node734. The flow limiter edge node734has an outlet role node748and a further role (note shown) which connects to a pressure node750. The pressure node750is an executable node which has an overlay structure comprising the sensor overlay node744, a forecast overlay node752and an alert overlay node754.

The gear pump702, the valve704, and the flow limiter706of the system700shown inFIG.7Aare modelled in the executable graph-based model728by the gear pump node730, the valve edge node732, and the flow limiter edge node734.

In general, the executable graph-based model728periodically receives sensor readings from components of the system700shown inFIG.7Aand uses these sensor readings to update the (observed) states of one or more nodes within the executable graph-based model728. For example, a pressure value for the flow limiter706shown inFIG.7Amay be received every 1 second and used to update a value for a pressure attribute of the pressure node750. Because the data and processing logic of the executable graph-based model728are integrated, the forecast overlay node752of the pressure node750utilizes the updated value of the pressure attribute of the pressure node750along with a suitable model of the system (e.g., a state space model, machine learning model, or the like) to predict, or forecast, a pressure at the flow limiter706at a future time point (e.g., 1 second in the future, 2 seconds in the future, 5 seconds in the future, or the like). The alert overlay node754of the pressure node750then issues an alert if the predicted pressure value at the future time point exceeds a predetermined threshold. This alert may then be used to adjust or control the valve704and divert the fluid to the waste outlet720.

FIG.7Balso illustrates further functionality of the executable graph-based model728. For example, the audit overlay node738logs state changes made to the pump node736, the inlet role node740, and the sensor overlay node744. For example, when the executable graph-based model728is first executed, the audit overlay node738may record details related to the pump node736and the inlet role node740to a log. In addition, sensor readings received by the sensor overlay node744may also be recorded to the log. The conversion overlay node746shown inFIG.7Bis configured to transform the sensor measurements received by the sensor overlay node744(e.g., convert from one unit of measurement to another).

FIG.7Cshows a sequence diagram756of an example execution of the executable graph-based model728shown inFIG.7B.

The sequence diagram756shown inFIG.7Cillustrates an example execution sequence involving the sensor overlay node744, the conversion overlay node746, the valve edge node732, the pressure node750, the forecast overlay node752, and the alert overlay node754of the executable graph-based model728shown inFIG.7B.

The execution sequence starts with a stimulus758being received by the sensor overlay node744. Within the context of the wider system within which the executable graph-based model functions (e.g., the system300shown inFIG.3), the stimulus758and corresponding context are received by the system and processed by a stimuli management module (e.g., the stimuli management module312of the system300). The stimuli management module312is communicatively coupled to the relevant overlay managers of the nodes within the executable graph-based model (e.g., the overlay manager456shown inFIG.4B) such that the stimuli management module312is operable to pass the stimulus and context to the relevant overlay management module which then passes the stimulus and context to the relevant overlay(s) for processing/execution. In the example shown inFIG.7C, the effect of the above process is that the stimulus and context cause execution of the processing logic of the sensor overlay node744.

As shown inFIG.7C, upon receiving the stimulus758at the sensor overlay node744, a further stimulus760is fired which causes execution of the processing logic of the conversion overlay node746. In one embodiment, the further stimulus760is fired and the processing logic of the conversion overlay node746is executed prior to the processing logic of the sensor overlay node744being executed. For example, the overlay manager of the pressure node750(which is the base node of the sensor overlay node744and the conversion overlay node746) is configured to cause execution of the processing logic of the conversion overlay node746prior to causing execution of the processing logic of the sensor overlay node744when stimuli having certain context(s) are received (e.g., if the context associated with a stimulus indicates that the stimulus is a sensor reading). In an alternative embodiment, the further stimulus760is fired as part of the execution of the processing logic of the sensor overlay node744. For example, the sensor overlay node744determines from the sensor reading that a conversion of the reading is required.

A stimulus762is fired once the conversion overlay node746has finished transforming the sensor reading which results in the sensor overlay node744firing a first stimulus with context764or a second stimulus with context766. The first stimulus with context764is fired if the context associated with the stimulus758indicates that the sensor reading is associated with the valve704. The first stimulus with context764results in a value of an attribute of the valve edge node732being updated. The second stimulus with context766is fired if the context associated with the stimulus758indicates that the sensor reading is associated with the flow limiter706. The second stimulus with context766results in a value of an attribute of the pressure node750(which is associated with the flow limiter edge node734as shown inFIG.7B) being updated.

As shown inFIG.7C, in consequence of the value of the attribute of the pressure node750being set, a stimulus768is fired which causes execution of the processing logic of the pressure node750. Consequently, a stimulus770is fired which causes execution of processing logic of the forecast overlay node752. As stated above, the processing logic of the forecast overlay node752is configured to predict a future pressure of the flow limiter706based on the current state of the system700(i.e., based on the sensor readings). After the forecast has been made a stimulus772is fired if the predicted future pressure exceeds a predetermined threshold. The stimulus772causes execution of the processing logic of the alert overlay node754.

Thus, the executable graph-based model728provides a reusable, scalable, and efficient approach to modelling and processing data. Because the data and data processing logic is separate while offline, the two components can be managed separately by their respective owners. Because the executable graph-based model728integrates the data and the data processing functionality at run-time, the model is able to respond efficiently to stimuli and therefore reduce the latency of the system.

The visualization of the executable graph-based model728shown inFIG.7Bcorresponds to a visual representation of various elements within an executable graph-based model. As will be described in more detail below in relation toFIGS.8and9, this visual representation, and the corresponding interactive user interface functionality, provides an efficient man-machine interface for exploring the functional structure of an executable graph-based model whilst maintaining the contextual information provided by the topological layout of the graph (i.e., the knowledge graph component).

FIG.8shows an executable graph-based model800, according to an embodiment of the present disclosure.

The executable graph-based model800comprises a user node802which extends a person node804. The user node802is connected to an edge node806via a role (not shown). The edge node806further connects a second node (node shown) via a role node808. The user node802is an executable node comprising an encryption overlay node810, an audit overlay node812, and an obfuscation overlay node814. The audit overlay node812is an executable node comprising an encryption overlay node816. The person node804is an executable node comprising an audit overlay node818.

The executable graph-based model800shown inFIG.8includes a complex overlay structure and a complex node structure. The user node802, which is an executable node comprising multiple overlay nodes, extends the person node804which is itself an executable node comprising an overlay. Moreover, the audit overlay node812of the user node802is an executable node comprising an overlay. Therefore, the overlay and node structure comprise a form of hierarchical structure which cannot be easily visualized in conjunction with other elements of the executable graph-based model800without causing visual clutter or losing key contextual information (e.g., by hiding or occluding parts of the executable graph-based model to display the overlay structure).

FIGS.9A-9Gillustrate the visualization of hierarchical overlay structures, according to an embodiment of the present disclosure.

FIG.9Ashows a device902upon which a user interface904is displayed. A graphical representation906of an executable node is displayed within the user interface904. The graphical representation906comprises a first display element908and a second display element910. A graphical representation912of an edge node and a graphical representation914of a role node are also displayed within the user interface904. A first selector916and a second selector918are also displayed within the user interface904. The first display element908comprises a label920and an icon922.

The graphical representation906of the executable node, the graphical representation912of the edge node, and the graphical representation914of the role node correspond to visual representations of nodes within the executable graph-based model shown inFIG.8. As such, the graphical representation906is associated with the executable node comprising the composition of the user node802and its associated overlays. Specifically, the first display element908is associated with the user node802and the second display element910is associated with the overlays of the user node802. The graphical representation906provides a visualization of the executable node at a first level of detail whereby the information conveyed is simplified—i.e., a user of the device902is informed that the user node represented by the first display element908comprises at least one associated overlay because the graphical representation906further comprises a second display element910in the form of a shape (i.e., a circle) encompassing the first display element908. This is in contrast to the graphical representation912of the edge node and the graphical representation914of the role node which are identified as being non-executable nodes because the graphical representations comprise only a single display element.

The label920and the icon922provide information regarding the node associated with the first display element908. In this example, the label920corresponds to a value of a first name attribute of user node associated with the first display element908(i.e., the user node802shown inFIG.8). The icon922is indicative of a property of the user node associated with the first display element908—in this instance, the icon922indicates the associated user node is a female.

Further attributes and features associated with nodes displayed within the user interface904are viewable via an information window as illustrated inFIG.9B.

FIG.9Bshows the user interface904illustrated inFIG.9Awith the additional of an information window924.

The information window924is display within the user interface904as a result of a user input926being received. In this example, the user input926is a touch or selection gesture (e.g., via a mouse or other pointing device) at a location within the user interface904corresponding to the first display element908. As such, the user input926corresponds to a selection by a user of the device902of the first display element908(i.e., a selection to view more information regarding the user node represented by the first display element908).

The information window924displays the attributes and attribute values associated with the selected node. The information window also includes tabs for describing and configuring all other aspects of the selected node.

In addition to being provided with a mechanism by which to explore the attributes of nodes within the executable graph-based model (i.e., view the data component, or knowledge graph component, of the executable graph-based model), according to an embodiment of the present disclosure a user is also able to explore the functional structure of the executable graph-based model whilst maintaining the relational structure of the executable graph-based model.

As stated above, the graphical representation906of the executable node is displayed at a first-simplified-level of detail. That is, the overlay structure associated with the user node (i.e., the encryption overlay node810, the audit overlay node812, the obfuscation overlay node814and the audit overlay node818associated with the user node802and the person node804shown inFIG.8) is represented solely by the second display element910. A user explores different levels of detail of the overlay structure by means of the first selector916and the second selector918.

In the example shown inFIG.9B, the first selector916and the second selector918correspond to interactive display elements (e.g., buttons, selectors, or the like) which are displayed at a predetermined and location within the user interface904. In other embodiments, the first selector and the second selector are displayed at other locations within the user interface904or the functionality afforded by these selectors are provided by means of other input mechanisms such as speech input, text-based commands, interaction with physical buttons or elements of the device902and the like.

In general, the first selector916is used to increase the level of detail of the visual display of the overlay structure of one or more executable nodes within the executable graph-based model whilst the second selector918is used to decrease the level of detail of the visual display of this overlay structure. InFIGS.9A and9B, the second selector918is visually different to the first selector916indicating the second selector918is disabled because the executable graph-based model is being displayed at the simplest level of detail.

To increase the level of detail of the visualization of the overlay structure, a user selects the first selector916resulting in the display shown inFIG.9C.

FIG.9Cshows the overlay structure of the executable node associated with the graphical representation906at a second level of detail. The second level of detail is greater than the first level of detail shown inFIGS.9A and9B.

The graphical representation906of the executable node shown at the second level of detail inFIG.9Ccomprises a display element which includes a plurality of visual indicators928-932associated with a plurality of overlays within the overlay structure. The plurality of visual indicators928-932are proximate to, and optionally contiguous with, the graphical representation906. The display element optionally comprises a further visual indicator934associated with an overlay associated with the base executable node which the executable node represented by the graphical representation906extends. The display element shown inFIG.9Calso includes the second display element910. As such, the display element shown inFIG.9Crepresents the overlay structure of the executable node at a second level of detail greater than the first level of detail.

When comparing the first level of detail shown inFIGS.9A and9Bwith the second level of detail shown inFIG.9C, it can be seen that more information regarding the overlay structure associated with the executable node is displayed at the second level of detail. The user is provided with information regarding the number of overlays there are that are associated with the executable node by means of the display of the plurality of visual indicators928-932(and optionally the further visual indicator934).

The plurality of visual indicators928-932are visually associated with the executable node by their position relative to the graphical representation906. That is, the plurality of visual indicators928-932are displayed along an edge, or perimeter, of the second display element910. In this way, the user is provided with immediate visual feedback linking the overlays represented by the plurality of visual indicators928-932with the node to which they relate—in this case, they are all overlays of the node represented by the first display element908. This is in contrast to the further visual indicator934which is displayed along an edge, or perimeter, of the first display element908thus indicating that the overlay represented by the further visual indicator934is associated with a (hidden) base node which the node represented by the first display element908extends (in the example shown inFIG.8, the further visual indicator934is associated with the audit overlay node818of the person node804, which is the base node of the user node802).

As can be seen fromFIG.9C, the overlay structure of the executable graph-based model is displayed at a second level of detail whilst maintaining display of the first display element908, the graphical representation912of the edge node and the graphical representation914of the role node. As such, the functionality of the executable graph-based model (i.e., the overlay structure) can be explored whilst maintain the integrity of the display of the knowledge graph portion of the executable graph-based model (i.e., the topology of the graph). This provides an efficient man machine interface since a user is able to expand and collapse portions of the overlay structure whilst retaining a visual representation of the overall layout of the executable graph-based model.

In the example shown inFIG.9C, the second selector918is no longer disabled thereby enabling a user to decrease the level of detail of the overlay structure displayed within the user interface904. Selection of the second selector918when the overlay structure is displayed at the second level of detail (as shown inFIG.9C) would thus result in the overlay structure being presented at the first level of detail (as shown inFIGS.9A and9B).

Selection of the first selector916(e.g., by means of a user input upon or in relation to the first selector916) whilst the overlay structure is displayed at the level of detail shown inFIG.9Cresults in the level of detail of the overlay structure increasing as shown inFIG.9D.

FIG.9Dshows the overlay structure of the executable node associated with the graphical representation906at a third level of detail. The third level of detail is greater than the second level of detail shown inFIG.9C.

The graphical representation906of the executable node shown at the third level of detail inFIG.9Dcomprises a display element which includes a plurality of further display elements936-940associated with a plurality of overlay nodes within the overlay structure. The display element thus comprises a structural representation of the overlay structure. The display element optionally comprises an additional display element942associated with the audit overlay of the base node. In one embodiment, the display element shown inFIG.9Dalso includes the plurality of visual indicators928-932. However, the plurality of visual indicators928-932, when acting as selectors, now decrease the level of detail of the overlay structure (as described in more detail below). As can be seen inFIG.9D, the graphical representation906further includes a display element908-2associated with the person node (i.e., the base node from which the user node represented by the first display element908is extended). As such, at this level of detail a user is able to discern that the audit overlay (as represented by the additional display element942) is associated with the person node (as represented by the display element908-2).

As shown inFIG.9Dbecause the audit overlay associated with the display element936of the plurality of further display elements936-940is an executable node (i.e., an overlay node having an overlay node associated therewith) a visual indicator944is displayed. The visual indicator944indicates to a user that the overlay structure related to the audit overlay (i.e., related to the display element936) can be further explored. The visual indicator944is thus a selector which a user may select (i.e., click or press) to expand the level of detail as shown inFIG.9E.

FIG.9Eshows the overlay structure of the executable node associated with the graphical representation906at a fourth level of detail. The fourth level of detail is greater than the third level of detail shown inFIG.9D. At the fourth level of detail, a display element946is shown which replaces the display element (i.e., the visual indicator944) shown at the third level of detail. The display element946reveals that the audit overlay associated with the display element936comprises an encryption overlay associated with the display element946.

Because the fourth level of detail corresponds to the greatest (i.e., most complex) level of detail that can be displayed, the first selector916is disabled. However, selection of the second selector918would result in the overlay structure being displayed at the third level of detail as shown inFIG.9C.

The above examples shown inFIG.9A-9Erelate to a global change in the level of detail of the overlay structure. That is, selection of the first selector916or the second selector918result in the level of detail of all overlays (overlay nodes) within the overlay structure being changed. This is illustrated most clearly in the transition from the second level of detail shown inFIG.9Cto the third level of detail shown inFIG.9D. In some embodiments, the first selector916and the second selector918increase the level of detail of all overlay structures within the executable graph-based model displayed within the user interface904. However, a user is able to explore a portion of an overlay structure by means of the visual indicators.

FIG.9Fshows the user interface904ofFIG.9C(at the second level of detail) after a user selection of the first visual indicator928of the plurality of visual indicators928-932.

In consequence of the user selection of the first visual indicator928the overlay structure related to the audit overly (represented by the first visual indicator928) is expanded and shown at a further level of detail. As such, the first visual indicator928shown inFIG.9Cis replaced by the display element936associated with the audit overlay. In some embodiments, the first visual indicator928also changes so as to indicate that the local overlay structure can be collapsed. InFIG.9Fthis is shown by the first visual indicator928which corresponds to a selectable icon with a “−” sign. Selection of the first visual indicator928by a user results in the user interface904shown inFIG.9Cbeing display.

Because the audit overlay represented by the display element936is an overlay with overlay, the user is provided with the visual indicator944which can be selected to further explore the local overlay structure of the audit overlay node.

Selection of the visual indicator944results in the user interface904shown inFIG.9Gwhich shows the user interface904shown inFIG.9Fbut with the addition of a display element946associated with the encryption overlay of the audit overlay associated with the display element936. In some embodiments, the visual indicator944also changes so as to indicate that the local overlay structure can be collapsed. InFIG.9Gthis is shown by the visual indicator944which corresponds to a selectable icon with a “−” sign. Selection of the visual indicator944by a user results in the user interface904shown inFIG.9Fbeing display.

The description will now turn to methods which operate in conjunction with the systems and functionality described above.

FIG.10shows a method1000for execution of executable graph-based models, according to an embodiment of the present disclosure.

The method1000comprises the steps of obtaining1002an executable graph-based model, receiving1004a stimulus, and causing1006execution of an overlay node based on the received stimulus. In one embodiment, the method1000is performed by a system such as the system300described above in relation toFIG.3.

In general, the method1000describes the execution process of an executable graph-based model. As stated previously, an executable graph-based model combines data and data processing functionality at run-time whilst maintaining their separability when at rest. The executable graph-based model provides clear separation of data and data processing functionality thereby allowing data owners greater control over the data used by such models. Furthermore, the integration of the data and the data processing functionality with a single model helps reduce the latency between stimuli being received, processing logic being executed, data being accessed, and outcomes being produced. Therefore, the executable graph-based model of the method1000is an efficient data structure which reduces processing delays or latency.

At the step of obtaining1002, an executable graph-based model is obtained. The executable graph-based model comprises a first overlay node and a first node having the first overlay node associated therewith. The first overlay node comprises processing logic operable to interact with one or more associated nodes of the executable graph-based model.

The executable graph-based model obtained at the step of obtaining1002corresponds to any suitable executable graph-based model described in the present disclosure. Further description of the architecture and functionality of a node, an overlay node, and an executable node is given above in relation toFIGS.4A and4B.

At the step of receiving1004, a first stimulus associated with the first overlay node is received.

Stimuli provide the basis for all interactions within an executable graph-based model. The first stimulus has a type such as a command (e.g., a transactional request), a query, or an event from an internal or external system. The first stimulus is either externally or internally generated (triggered). For example, the first stimulus may be associated with an event related to an external device which is then received by the executable graph-based model. Alternatively, the first stimulus may have been generated by processing logic within the executable graph-based model.

At the step of causing1006, execution of said processing logic of the first overlay node is caused in response to the first stimulus being received. Execution of said processing logic of the first overlay node is based on the first node.

In an embodiment, the first stimulus comprises a first context such that execution of the processing logic of the first overlay node is based on the first context. For example, the first context comprises information necessary for the processing logic to be executed.

The first node comprises a state which, in some embodiments, is shared by the first node and a second node of the graph-based model (as described in more detail in relation toFIG.4Aabove). The execution of the processing logic caused at the causing1006step, can cause a change in the state of the first node. For example, if the first node is a data node comprising an attribute, then the execution of the processing logic can cause a value of the attribute to be set. In a further example, execution of the processing logic can cause a new attribute to be generated for the first node and may also set a value for the new attribute. The execution can also leave the state of the first node unchanged. For example, the execution of the processing logic can cause a value of the attribute to be output.

As stated previously, processing within the executable graph-based model is driven by stimuli. Consequently, execution of the processing logic caused by the causing1006step may cause a second stimulus to be generated (fired). For example, a second stimulus associated with a second node within the executable graph-based model is fired and subsequently received by a second overlay node. In consequence of the second stimulus being received, processing logic of the second overlay node is executed.

FIG.11shows a method1100for dynamically generating an executable graph-based model, according to an embodiment of the present disclosure.

The method1100comprises the steps of obtaining1102a graph-based model, obtaining1104a first overlay node, determining1106an association between a first node of the graph-based mode and the first overlay node, and generating1108an executable graph-based model. The method1100further comprises the optional steps of receiving1110a first stimulus and causing1112execution based on the first stimulus being received. In one embodiment, the method1100is performed by a system such as the system300described in relation toFIG.3above.

At the step of obtaining1102, a graph-based model comprising one or more nodes is obtained.

At the step of obtaining1104, a first overlay node is obtained. The first overlay node comprises processing logic operable to interact with at least one node of an associated graph-based model.

At the step of determining1106, an association between a first node of the graph-based model and the first overlay node is determined.

At the step of generating1108, an executable graph-based model is generated. The executable graph-based model includes a first executable node comprising a composition of the first node of the graph-based model and the first overlay node based on the association between the first node of the graph-based model and the first overlay node.

At the optional step of receiving1110, a first stimulus associated with the first overlay node is received.

At the optional step of causing1112, execution of said processing logic of the first executable node is caused in response to the first stimulus being received.

As stated above, the first stimulus can comprise, or be associated with, a context. In such examples, execution of the processing logic of the first executable node is based on the first context. For example, a stimulus associated with an event occurring outside of the system could be handled by different overlays within the executable graph-based model. A context associated with the stimulus can be used to indicate which of the overlays the stimulus (event) relates. In the example described above in relation toFIGS.7A-7C, the sensor overlay node744is operable to receive stimuli associated with sensor readings of the valve704or the flow limiter706. The context associated with stimuli is thus used to identify whether the sensor reading is from the valve704or the flow limiter706.

In one embodiment, execution of the processing logic of the first executable node in response to the first stimulus being received causes a second stimulus to be generate and fired (e.g., sent or broadcast within the system). The second stimulus is associated with a second overlay node within the executable graph-based model. In response to the second stimulus being fired, processing logic associated with the second overlay node is caused to execute.

FIG.12shows a method1200for storage management of executable graph-based models, according to an embodiment of the present disclosure.

The method1200comprises the steps of obtaining1202an executable node, extracting1204node states, determining1206storage locations, generating1208an overlay manifest, generating1210a first manifest, generating1212a second manifest, generating1214manifest states, and storing1216the manifest states. The method1200further comprises the optional step of storing1218the node states. In one embodiment, the method1200is performed by a system such as the system300described above in relation toFIG.3.

At the step of obtaining1202, an executable node is obtained. The executable node comprises a composition of a first node and a first overlay node (e.g., the executable node466shown inFIG.4Ccomprises a composition of the base node468and the overlay node470). The executable node obtained at the obtaining1202step forms a part of an executable graph-based model. As such, the obtaining1202step may be performed as part of decomposing an executable graph-based model for persistent storage. In embodiments, the first node is associated with a node type such as a data node type, a value node type, an edge node type, or a role node type.

At the step of extracting1204, a node state is extracted from each of the executable node, the first node, and the first overlay node. That is, a first node state is extracted from the executable node (e.g., the state472of the executable node466shown inFIG.4C), a second node state is extracted from the first node (e.g., the state476of the base node468shown inFIG.4C), and a third node state is extracted from the first overlay node (e.g., the state480of the overlay node470shown inFIG.4C). The node state of the executable node and the node state of the first node both comprise a shared identifier (e.g., the identifier474of the state472inFIG.4Cis the same as the identifier478of the state476). At the step of determining1206, a storage location for the node state of each of the executable node, the first node, and the first overlay node is determined. That is, a first storage location is determined for the node state of the executable node, a second storage location is determined for the node state of the first node, and a third storage location is determined for the node state of the first overlay node. Here, determining a storage location corresponds to identifying or determining the file path, or location (e.g., URL), at which the node state will be, or has been, saved. In some embodiments, the optional step of storing1218the node states (as described in more detail below) is performed after or as part of the step of determining1206the storage locations.

At the step of generating1208, an overlay node manifest is generated. The overlay node manifest is associated with the first overlay node (e.g., the manifest488associated with the overlay node470shown inFIG.4C). The overlay node manifest comprises an overlay identifier (e.g., the identifier496shown inFIG.4C) and the storage location of the node state of the first overlay node. Thus, the overlay node manifest comprises all the information necessary for reconstructing the first overlay node from its constituent components.

At the step of generating1210, a first node manifest is generated. The first node manifest is associated with the executable node (e.g., the manifest484shown inFIG.4Cis associated with the executable node466). The first node manifest comprises: the shared identifier (e.g., the identifier490inFIG.4Cwhich is the same as the identifier474), the overlay identifier (e.g., the overlay identifier492inFIG.4Cwhich is the same as the identifier496), and the storage location for the node state of the executable node. Thus, the first node manifest comprises all the information necessary for reconstructing the executable node from its constituent components.

At the step of generating1212, a second node manifest is generated. The second node manifest is associated with the first node (e.g., the manifest486inFIG.4Cis associated with the base node468). The second node manifest comprises the shared identifier (e.g., the identifier494inFIG.4Cwhich is the same as the identifier474, the identifier478, and the identifier490) and the storage location for the node state of the executable node. Thus, the second node manifest comprises all the information necessary for reconstructing the first node from its constituent components.

At the step of generating1214, a manifest state is generated for each of the overlay node manifest, the first node manifest, and the second node manifest. The manifest state generated for the first node manifest and the manifest state generated for the second node manifest both comprise the shared identifier. The manifest states generated at the step of generating1214correspond to the lowest level representation of a node (i.e., a manifest state cannot be decomposed into any further part or parts).

At the step of storing1216, the manifest state for each of the overlay node manifest, the first node manifest and the second node manifest are stored. As such, by decomposing the elements into separate elements using the method1200, the different elements (i.e., the structure of an executable graph-based model, the functionality of the overlays used by an executable graph-based model, and the data which exists at run-time within an executable graph-based model) can be managed and stored separately.

To verify the integrity of the executable graph-based model, a first verification code is generated for each node state and subsequently associated with the corresponding manifest state such that the corresponding manifest state comprises the first verification code. For example, a first node state associated with a first node comprises a first verification code which is then associated with the manifest state for the first node such that a confirmation can be made during loading that the node state matches the manifest.

At the optional step of storing1218, the node state of each of the executable node and the first node are stored at their respective storage locations. As stated above, the step of storing1218is performed as part of (or after) the step of determining1206storage locations, or after (or as part of) the step of storing1216the manifest states. In one embodiment, the storage location of the node state of the executable node is at a first device and the storage location of the node state of the first node is at a second, different, device. For example, the first device could be an enterprise facility managed by a company offering a service involving the executable graph-based model within which the executable node is contained, and the second device could be a device of a user of the executable graph-based model. As such, the user is able to maintain their personal data separately from, and independently to, the enterprise facility managed by the company. Similarly, the node state of the overlay node may be stored at a storage location involving a third device which can be different to both the first and the second device. As such, the re-usable processing functionality of the executable graph-based model (i.e., the overlay structure) can be maintained and managed by a third party.

FIG.13shows a method1300for loading executable graph-based models, according to an embodiment of the present disclosure.

The method1300comprises the steps of obtaining1302a first manifest state and a second manifest state, generating1304a first manifest and a second manifest, obtaining1306an overlay manifest, obtaining1308node states, generating1310a first node, generating1312an overlay node, generating1314an executable node, associating1316the executable node with the first node and the overlay node, and generating138an executable graph-based model. In one embodiment, the method1300is performed by a system such as the system300described in more detail above in relation toFIG.3.

At the step of obtaining1302, a first manifest state and a second manifest state are obtained based on a first, shared, identifier. Both the first manifest state and the second manifest state comprise the first identifier. The first manifest state is associated with a first node and the second manifest state is associated with an executable node. The executable node comprises a composition of the first node and an overlay node.

At the step of generating1304, a first manifest and a second manifest are generated from the first manifest state and the second manifest state respectively. The first manifest comprises the first identifier and a first node state storage location associated with the location at which a node state for the first node is stored (e.g., the manifest486and the identifier494shown inFIG.4C). The second manifest comprises the first identifier, an overlay identifier, and a second node state storage location (e.g., the manifest484, the identifier490, and the overlay identifier492shown inFIG.4C). The second node state storage location is associated with the location at which a node state for the executable node is stored. The overlay identifier is associated with an overlay manifest, or overlay manifest state, associated with the overlay node (e.g., the overlay identifier492of the manifest484shown inFIG.4Cis the same as the identifier496of the manifest488associated with the overlay node470).

At the step of obtaining1306, an overlay manifest is obtained based on the overlay identifier. The overlay manifest comprises the overlay identifier and overlay node state storage location (e.g., the manifest488and the identifier496shown inFIG.4C). In one embodiment, the overlay manifest is obtained by first obtaining an overlay manifest state based on the overlay identifier and subsequently generating the overlay manifest based on the overlay manifest state.

At the step of obtaining1308, a first node state is obtained from the first node state storage location (e.g., the state476shown inFIG.4C), a second node state is obtained from the second node state storage location (e.g., the state472shown inFIG.4C), and an overlay node state is obtained from the overlay node state storage location (e.g., the state480shown inFIG.4C).

At the step of generating1310, the first node is generated based on the first manifest and the first node state (e.g., the base node468shown inFIG.4Cis generated based on the manifest486and the state476).

At the step of generating1312, the overlay node is generated based on the overlay manifest and the overlay node state (e.g., the overlay node470shown inFIG.4Cis generated from the manifest488and the state480),

At the step of generating1314, the executable node is generated based on the second manifest and the second node state (e.g., the executable node466is generated from the manifest484and the state472).

At the step of associating1316, the executable node is associated with the first node and the overlay node (e.g., the composition of the base node468and the overlay node470which forms the executable node466shown inFIG.4C).

At the step of generating1318, an executable graph-based model is generated, where the executable graph-based model comprises the executable node.

FIG.14shows a method1400for the interactive display of an overlay structure, according to an embodiment of the present disclosure.

The method1400comprises the steps of obtaining1402an executable graph-based model, displaying1404a graphical representation comprising a first display element and a second display element, displaying1406a first selector, receiving1408a user input associated with the first selector, and replacing1410the second display element with a third display element. In one embodiment, the method1400is performed by a device comprising a display and a user input mechanism such as that described in relation toFIG.15below. In an alternative embodiment, the method1400is performed by a system such as the system300described above in relation toFIG.3.

In general, the method1400corresponds to the functionality described in relation toFIGS.9A-9Gabove which allows a user to explore the functionality of an executable graph-based model (i.e., the overlay structure) whilst maintaining display of the layout (topology) of the graph thus maintaining key contextual information.

At the step of obtaining1402, an executable graph-based model is obtained. The executable graph-based model comprises an executable node which comprises a composition of a first node and a first overlay structure. The first overlay structure is associated with the first node.

At the step of displaying1404, a graphical representation of the executable node of the executable graph-based model is displayed (e.g., the graphical representation906shown inFIGS.9A-9D). The graphical representation comprises a first display element associated with the first node and a second display element associated with the first overlay structure (e.g., the first display element908and the second display element910shown inFIGS.9A-9G).

The second display element represents the first overlay structure at a first level of detail. In the example shown inFIG.9A, the second display element910represents the overlay structure at a simple level of detail because the overlay structure is represented by the circle encompassing the first display element908(which represents the first node of the executable node). In the example shown inFIG.9C, the second display element represents the overlay structure at a more complex level of detail than that ofFIG.9A. InFIG.9Cthe overlay structure is represented in the second display element by the plurality of visual indicators928-932which identify the three overlays within the first overlay structure of the executable node.

At the step of displaying1406, a first selector associated with the graphical representation of the executable node is displayed.

As stated in detail above in relation toFIGS.9A-9D, the first selector corresponds to any selectable object (e.g., button) which is operable to cause a change in the level of detail of the displayed executable graph-based model. For example, the first selector can be the first selector916or the first selector can be one of the plurality of visual indicators928-932.

At the step of receiving1408, a first user input associated with the first selector is received.

At the step of replacing1410, the second display element of the graphical representation of the executable node is replaced with a third display element in response to the first user input being received (e.g., the second display element910shown inFIGS.9A and9Bare replaced by a third display element comprising the plurality of visual indicators928-932as shown inFIG.9C). The second display element is replaced with the third display element whilst maintaining display of the first display element. The third display element represents the first overlay structure at a second level of detail. The second level of detail is greater than the first level of detail. Alternatively, the second level of detail is less than the first level of detail.

FIG.15shows an example computing system for carrying out the methods of the present disclosure. Specifically,FIG.15shows a block diagram of an embodiment of a computing system according to example embodiments of the present disclosure.

Computing system1500can be configured to perform any of the operations disclosed herein such as, for example, any of the operations discussed with reference to the functional modules described in relation toFIG.1A. The computing system1500can be implemented as a conventional computer system, an embedded controller, a laptop, a server, a mobile device, a smartphone, a set-top box, a kiosk, a vehicular information system, one or more processors associated with a television, a customized machine, any other hardware platform, or any combination or multiplicity thereof. In one embodiment, the computing system1500is a distributed system configured to function using multiple computing machines interconnected via a data network or bus system.

The computing system1500includes one or more computing device(s)1502. The one or more computing device(s)1502of computing system1500comprise one or more processors1504and memory1506. One or more processors1504can be any general purpose processor(s) configured to execute a set of instructions. For example, one or more processors1504can be a processor core, a multiprocessor, a reconfigurable processor, a microcontroller, a digital signal processor (“DSP”), an application-specific integrated circuit (“ASIC”), a graphics processing unit (“GPU”), a neural processing unit (“NPU”), an accelerated processing unit (“APU”), a brain processing unit (“BPU”), a data processing unit (“DPU”), a holographic processing unit (“HPU”), an intelligent processing unit (“IPU”), a microprocessor/microcontroller unit (“MPU/MCU”), a radio processing unit (“RPU”), a tensor processing unit (“TPU”), a vector processing unit (“VPU”), a wearable processing unit (“WPU”), a field programmable gate array (“FPGA”), a programmable logic device (“PLD”), a controller, a state machine, gated logic, discrete hardware component, any other processing unit, or any combination or multiplicity thereof. In one embodiment, one or more processors1504include one processor. Alternatively, one or more processors1504include a plurality of processors that are operatively connected. For example, the one or more processors1504can be multiple processing units, a single processing core, multiple processing cores, special purpose processing cores, co-processors, or any combination thereof. One or more processors1504are communicatively coupled to memory1506via address bus1508, control bus1510, and data bus1512.

Memory1506can include non-volatile memories such as read-only memory (“ROM”), programmable read-only memory (“PROM”), erasable programmable read-only memory (“EPROM”), flash memory, or any other device capable of storing program instructions or data with or without applied power. The memory1506can also include volatile memories, such as random-access memory (“RAM”), static random-access memory (“SRAM”), dynamic random-access memory (“DRAM”), and synchronous dynamic random-access memory (“SDRAM”). The memory1506can comprise single or multiple memory modules. While the memory1506is depicted as part of the one or more computing device(s)1502, the skill person will recognize that the memory1506can be separate from the one or more computing device(s)1502.

Memory1506can store information that can be accessed by one or more processors1504. For instance, memory1506(e.g., one or more non-transitory computer-readable storage mediums, memory devices) can include computer-readable instructions (not shown) that can be executed by one or more processors1504. The computer-readable instructions can be software written in any suitable programming language or can be implemented in hardware. Additionally, or alternatively, the computer-readable instructions can be executed in logically and/or virtually separate threads on one or more processors1504. For example, memory1506can store instructions (not shown) that when executed by one or more processors1504cause one or more processors1504to perform operations such as any of the operations and functions for which computing system1500is configured, as described herein. In addition, or alternatively, memory1506can store data (not shown) that can be obtained, received, accessed, written, manipulated, created, and/or stored. The data can include, for instance, the data and/or information described herein in relation toFIGS.1to14. In some implementations, the one or more computing device(s)1502can obtain from and/or store data in one or more memory device(s) that are remote from the computing system1500.

The one or more computing device(s)1502further comprise I/O interface1514communicatively coupled to address bus1508, control bus1510, and data bus1512. The I/O interface1514is configured to couple to one or more external devices (e.g., to receive and send data from/to one or more external devices). Such external devices, along with the various internal devices, may also be known as peripheral devices. The I/O interface1514may include both electrical and physical connections for operably coupling the various peripheral devices to the one or more computing device(s)1502. The I/O interface1514may be configured to communicate data, addresses, and control signals between the peripheral devices and the one or more computing device(s)1502. The I/O interface1514may be configured to implement any standard interface, such as a small computer system interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel, peripheral component interconnect (“PCI”), PCI express (“PCIe”), serial bus, parallel bus, advanced technology attachment (“ATA”), serialATA (“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, various video buses, and the like. The I/O interface1514is configured to implement only one interface or bus technology. Alternatively, the I/O interface1514is configured to implement multiple interfaces or bus technologies. The I/O interface1514may include one or more buffers for buffering transmissions between one or more external devices, internal devices, the one or more computing device(s), or the one or more processors1504. The I/O interface1514may couple the one or more computing device(s)1502to various input devices, including mice, touch screens, scanners, biometric readers, electronic digitizers, sensors, receivers, touchpads, trackballs, cameras, microphones, keyboards, any other pointing devices, or any combinations thereof. The I/O interface1514may couple the one or more computing device(s)1502to various output devices, including video displays, speakers, printers, projectors, tactile feedback devices, automation control, robotic components, actuators, motors, fans, solenoids, valves, pumps, transmitters, signal emitters, lights, and so forth.

Computing system1500further comprises storage unit1516, network interface1518, input controller1520, and output controller1522. Storage unit1516, network interface1518, input controller1520, and output controller1522are communicatively coupled to the central control unit (i.e., the memory1506, the address bus1508, the control bus1510, and the data bus1512) via I/O interface1514. The network interface1518communicatively couples the computing system1500to one or more networks such as wide area networks (“WAN”), local area networks (“LAN”), intranets, the Internet, wireless access networks, wired networks, mobile networks, telephone networks, optical networks, or combinations thereof. The network interface1518may facilitate communication with packet switched networks or circuit switched networks which use any topology and may use any communication protocol. Communication links within the network may involve various digital or analog communication media such as fiber optic cables, free-space optics, waveguides, electrical conductors, wireless links, antennas, radio-frequency communications, and so forth.

Storage unit1516is a computer readable medium, preferably a non-transitory computer readable medium, comprising one or more programs, the one or more programs comprising instructions which when executed by the one or more processors1504cause computing system1500to perform the method steps of the present disclosure. Alternatively, storage unit1516is a transitory computer readable medium. Storage unit1516can include a hard disk, a floppy disk, a compact disc read-only memory (“CD-ROM”), a digital versatile disc (“DVD”), a Blu-ray disc, a magnetic tape, a flash memory, another non-volatile memory device, a solid-state drive (“SSD”), any magnetic storage device, any optical storage device, any electrical storage device, any semiconductor storage device, any physical-based storage device, any other data storage device, or any combination or multiplicity thereof. In one embodiment, the storage unit1516stores one or more operating systems, application programs, program modules, data, or any other information. The storage unit1516is part of the one or more computing device(s)1502. Alternatively, the storage unit1516is part of one or more other computing machines that are in communication with the one or more computing device(s)1502, such as servers, database servers, cloud storage, network attached storage, and so forth.

Moreover, for example, the present technology/system may achieve the following configurations:1. A system for dynamic generation of executable graph-based models, the system comprising processing circuitry and a memory unit operatively coupled to the processing circuitry and having instructions stored thereon that, when executed by the processing circuitry, cause the processing circuitry to:obtain a graph-based model comprising one or more nodes;obtain a first overlay node comprising processing logic operable to interact with at least one node of an associated graph-based model;determine an association between a first node of the graph-based model and the first overlay node; andgenerate an executable graph-based model, wherein the executable graph-based model includes a first executable node comprising a composition of the first node of the graph-based model and the first overlay node based on the association between the first node of the graph-based model and the first overlay node.2. The system of 1, wherein the instructions, when executed by the processing circuitry, further cause the processing circuitry to:receive a first stimulus associated with the first overlay node; andin response to the first stimulus being received, cause execution of said processing logic of the first executable node.3. The system of 2, wherein the first stimulus comprises a first context such that execution of said processing logic of the first executable node is based on the first context.4. The system of 2, wherein the first node comprises a state.5. The system of 4, wherein the state is shared by the first node and a second node of the graph-based model.6. The system of 4, wherein execution of said processing logic of the first executable node causes a change in the state of the first node.7. The system of 6, wherein the state of the first node comprises a first attribute.8. The system of 7, wherein execution of said processing logic of the first executable node causes a value of the first attribute to be set.9. The system of 7, wherein execution of said processing logic of the first executable node causes a value of the first attribute to be output.10. The system of 7, wherein execution of said processing logic of the first executable node cause a second attribute to be generated for the state of the first node.11. The system of 10, wherein execution of said processing logic of the first executable node causes a value for the second attribute to be set.12. The system of 2, wherein execution of said processing logic of the first executable node causes a second stimulus associated with a second overlay node to be fired.13. The system of 12, wherein the instructions, when executed by the processing circuitry, further cause the processing circuitry to:receive the second stimulus associated with the second overlay node; andin response to the second stimulus being received, cause execution of processing logic associated with the second overlay node.14. The system of 2, wherein the instructions, when executed by the processing circuitry, further cause the processing circuitry to:in response to the first stimulus being received, cause execution of processing logic of a second executable node in the executable graph-based model, wherein the second executable node comprises a composition of a second node of the graph-based model and the first overlay node.15. The system of 1, wherein the first node is derived from a second node.16. The system of 15, wherein the first node is derived from the second node and a third node.17. The system of 1 wherein the first node comprises a unique identifier, one or more attributes each having corresponding attribute values, a version, a name, a namespace, and associated metadata.18. The system of 1, wherein the association between the first node of the graph-based model and the first overlay node is determined based on a predetermined configuration.19. The system of 1, wherein each node is associated with a node type.20. The system of 19, wherein the node type of the first node is a data node type.21. The system of 19, wherein the node type of the first node is a value node type.22. The system of 19, wherein the first overlay node is a node associated with an overlay node type.23. The system of 19 wherein the first overlay node defines the node type of the first node.24. The system of 19, wherein the first node comprises a composition of a second node of the graph-based model and a second overlay node.25. The system of 24, wherein execution of the first executable node causes execution of said processing logic of the first overlay node and said processing logic of the second overlay node.26. The system of 25, wherein execution of said processing logic of the second overlay node is dependent upon execution of said processing logic of the first overlay node.27. The system of 25, wherein execution of said processing logic of the first overlay node is dependent upon execution of said processing logic of the second overlay node.28. The system of 19, wherein the node type of the first node is an edge node type such that the first node is a first edge node.29. The system of 28, wherein the first edge node connects a plurality of nodes within the executable graph-based model.30. The system of 29, wherein the plurality of nodes within the executable graph-based model are connected by the first edge node via a corresponding plurality of roles, wherein each role in the corresponding plurality of roles corresponds to a node associated with a role node type.31. The system of 30, wherein each role in the corresponding plurality of roles defines a relationship between the first edge node and a respective node of the plurality of nodes connected by the first edge node.32. The system of 1, wherein the graph-based model is executable.33. The system of 1, wherein the graph-based model is a graph-based data model.34. A method for dynamic generation of executable graph-based models, the method comprising:obtaining, by processing circuitry, a graph-based model comprising one or more nodes;obtaining, by the processing circuitry, a first overlay node comprising processing logic operable to interact with at least one node of an associated graph-based model;determining, by the processing circuitry, an association between a first node of the graph-based model and the first overlay node; andgenerating, by the processing circuitry, an executable graph-based model, wherein the executable graph-based model includes a first executable node comprising a composition of the first node of the graph-based model and the first overlay node based on the association between the first node of the graph-based model and the first overlay node.35. A non-transitory computer-readable medium storing instructions which, when executed by processing circuitry, cause the processing circuitry to:obtain a graph-based model comprising one or more nodes;obtain a first overlay node comprising processing logic operable to interact with at least one node of an associated graph-based model;determine an association between a first node of the graph-based model and the first overlay node; andgenerate an executable graph-based model, wherein the executable graph-based model includes a first executable node comprising a composition of the first node of the graph-based model and the first overlay node based on the association between the first node of the graph-based model and the first overlay node.36. A method for storage management of executable graph-based models, the method comprising:obtaining, by processing circuitry, an executable node comprising a composition of a first node and a first overlay node;extracting, by the processing circuitry, a node state from each of the executable node, the first node, and the first overlay node, wherein the node state of the executable node and the node state of the first node both comprise a shared identifier;determining, by the processing circuitry, a storage location for the node state of each of the executable node, the first node, and the first overlay node;generating, by the processing circuitry, an overlay node manifest associated with the first overlay node, wherein the overlay node manifest comprises an overlay identifier and the storage location for the node state of the first overlay node;generating, by the processing circuitry, a first node manifest associated with the executable node, wherein the first node manifest comprises the shared identifier, the overlay identifier, and the storage location for the node state of the executable node;generating, by the processing circuitry, a second node manifest associated with the first node, wherein the second node manifest comprises the shared identifier and the storage location for the node state of the first node;generating, by the processing circuitry, a manifest state for each of the overlay node manifest, first node manifest, and the second node manifest, wherein the manifest state of each of the first node manifest and the second node manifest comprises the shared identifier; andstoring, by the processing circuitry, the manifest state for each of the overlay node manifest, first node manifest, and the second node manifest.37. The method of 36 further comprising:storing, by the processing circuitry, the node state of each of the executable node and the first node at their respective storage locations.38. The method of 37 wherein the storage location of the node state of the executable node is at a first device.39. The method of 37 wherein the storage location of the node state of the first node is at a second device.40. The method of 36 further comprising:storing, by the processing circuitry, the node state of the overlay node at the respective storage location.41. The method of 40 wherein the storage location of the node state of the overlay node is at a third device.42. The method of 36 wherein the first node state of the first node comprises a first verification code.43. The method of 42 wherein the manifest state associated with the first node comprises the first verification code.44. The method of 36 wherein the first node is associated with a node type.45. The method of 44 wherein the node type of the first node is one of: a data node type, a value node type, an edge node type, or a role node type.46. A device comprising processing circuitry and a memory storing instructions which, when executed by the processing circuitry, cause the processing circuitry to:obtain an executable node comprising a composition of a first node and a first overlay node;extract a node state from each of the executable node, the first node, and the first overlay node, wherein the node state of the executable node and the node state of the first node both comprise a shared identifier;determine a storage location for the node state of each of the executable node, the first node, and the first overlay node;generate an overlay node manifest associated with the first overlay node, wherein the overlay node manifest comprises an overlay identifier and the storage location for the node state of the first overlay node;generate a first node manifest associated with the executable node, wherein the first node manifest comprises the shared identifier, the overlay identifier, and the storage location for the node state of the executable node;generate a second node manifest associated with the first node, wherein the second node manifest comprises the shared identifier and the storage location for the node state of the first node;generate a manifest state for each of the overlay node manifest, first node manifest, and the second node manifest, wherein the manifest state of each of the first node manifest and the second node manifest comprises the shared identifier; andstore the manifest state for each of the overlay node manifest, first node manifest, and the second node manifest.47. A non-transitory computer-readable medium storing instructions which, when executed by processing circuitry, cause the processing circuitry to:obtain an executable node comprising a composition of a first node and a first overlay node;extract a node state from each of the executable node, the first node, and the first overlay node, wherein the node state of the executable node and the node state of the first node both comprise a shared identifier;determine a storage location for the node state of each of the executable node, the first node, and the first overlay node;generate an overlay node manifest associated with the first overlay node, wherein the overlay node manifest comprises an overlay identifier and the storage location for the node state of the first overlay node;generate a first node manifest associated with the executable node, wherein the first node manifest comprises the shared identifier, the overlay identifier, and the storage location for the node state of the executable node;generate a second node manifest associated with the first node, wherein the second node manifest comprises the shared identifier and the storage location for the node state of the first node;generate a manifest state for each of the overlay node manifest, first node manifest, and the second node manifest, wherein the manifest state of each of the first node manifest and the second node manifest comprises the shared identifier; andstore the manifest state for each of the overlay node manifest, first node manifest, and the second node manifest.48. A method for loading executable graph-based models, the method comprising:obtaining, by processing circuitry and based on a first identifier, a first manifest state and a second manifest state, wherein the first manifest state and the second manifest state both comprise the first identifier;generating, by the processing circuitry, a first manifest and a second manifest from the first manifest state and the second manifest state respectively, wherein the first manifest comprises a first node state storage location, and the second manifest comprises a second node state storage location and an overlay identifier;obtaining, by the processing circuitry, an overlay manifest based on the overlay identifier, wherein the overlay manifest comprises the overlay identifier and an overlay node state storage location;obtaining, by the processing circuitry, a first node state from the first node state storage location, a second node state from the second node state storage location, and an overlay node state from the overlay node state storage location;generating, by the processing circuitry, a first node based on the first manifest and the first node state;generating, by the processing circuitry, an overlay node based on the overlay manifest and the overlay node state;generating, by the processing circuitry, an executable node based on the second manifest and the second node state;associating, by the processing circuitry, the executable node with the first node and the overlay node; andgenerating, by the processing circuitry, an executable graph-based model comprising the executable node.49. A device comprising processing circuitry and a memory storing instructions which, when executed by the processing circuitry, cause the processing circuitry to:obtain, based on a first identifier, a first manifest state and a second manifest state, wherein the first manifest state and the second manifest state both comprise the first identifier;generate a first manifest and a second manifest from the first manifest state and the second manifest state respectively, wherein the first manifest comprises a first node state storage location, and the second manifest comprises a second node state storage location and an overlay identifier;obtain an overlay manifest based on the overlay identifier, wherein the overlay manifest comprises the overlay identifier and an overlay node state storage location;obtain a first node state from the first node state storage location, a second node state from the second node state storage location, and an overlay node state from the overlay node state storage location;generate a first node based on the first manifest and the first node state;generate an overlay node based on the overlay manifest and the overlay node state;generate an executable node based on the second manifest and the second node state;associate the executable node with the first node and the overlay node; andgenerate an executable graph-based model comprising the executable node.50. A non-transitory computer-readable medium storing instructions which, when executed by processing circuitry, cause the processing circuitry to:obtain, based on a first identifier, a first manifest state and a second manifest state, wherein the first manifest state and the second manifest state both comprise the first identifier;generate a first manifest and a second manifest from the first manifest state and the second manifest state respectively, wherein the first manifest comprises a first node state storage location, and the second manifest comprises a second node state storage location and an overlay identifier;obtain an overlay manifest based on the overlay identifier, wherein the overlay manifest comprises the overlay identifier and an overlay node state storage location;obtain a first node state from the first node state storage location, a second node state from the second node state storage location, and an overlay node state from the overlay node state storage location;generate a first node based on the first manifest and the first node state;generate an overlay node based on the overlay manifest and the overlay node state;generate an executable node based on the second manifest and the second node state;associate the executable node with the first node and the overlay node; andgenerate an executable graph-based model comprising the executable node.51. A device comprising:a display;an interface unit configured to receive one or more user inputs; andprocessing circuitry operatively coupled to the display and the interface unit, wherein the processing circuitry is configured to:obtain an executable graph-based model comprising an executable node, wherein the executable node comprises a composition of a first node and a first overlay structure associated with the first node;display, on the display of the device, a graphical representation of the executable node of the executable graph-based model, the graphical representation comprising a first display element associated with the first node and a second display element associated with the first overlay structure, wherein the second display element represents the first overlay structure at a first level of detail;display, on the display device, a first selector associated with the graphical representation of the executable node;receive, from the interface unit, a first user input associated with the first selector; andin response to the first user input being received, replace the second display element of the graphical representation of the executable node with a third display element whilst maintaining display of the first display element, wherein the third display element represents the first overlay structure at a second level of detail.52. The device of 51 wherein the second level of detail is greater than the first level of detail.53. The device of 52 wherein the second display element comprises a first shape encompassing the first display element.54. The device of 53 wherein the third display element comprises the first shape and one or more visual indicators associated with one or more overlays within the first overlay structure.55. The device of 54 wherein the one or more visual indicators are displayed along an edge of the first shape.56. The device of 54 wherein the one or more visual indicators comprise one or more shapes.57. The device of 54 wherein the one or more visual indicators comprise one or more icons.58. The device of 52 wherein the second display element comprises one or more visual indicators associated with one or more overlays within the first overlay structure.59. The device of 58 wherein the one or more visual indicators are displayed along an edge of a first shape encompassing the first display element.60. The device of 58 wherein the one or more visual indicators comprise one or more shapes.61. The device of 58 wherein the one or more visual indicators comprise one or more icons.62. The device of 58 wherein the first selector is a first visual indicator of the one or more visual indicators, the first visual indicator associated with a first overlay of the one or more overlays within the first overlay structure.63. The device of 62 wherein the third display element comprises a structural representation of the first overlay.64. The device of 63 wherein the one or more visual indicators comprise a second visual indicator associated with a second overlay of the one or more overlays within the first overlay structure.65. The device of 64 wherein the third display element comprises the structural representation of the first overlay and the second visual indicator associated with the second overlay.66. The device of 51 wherein the second level of detail is less than the first level of detail.67. The device of 51 wherein the processing circuitry is further configured to:display, on the display of the device, a layout of the executable graph-based model such that the graphical representation is displayed as part of the layout.68. The device of 67 wherein the layout comprises one or more further graphical representations of one or more further elements of the executable graph-based model.69. The device of 68 wherein the second display element is replaced by the third display element, in response to the first user input being received, whilst maintaining display of the one or more further graphical representations within the layout.70. The device of 68 wherein the one or more further elements of the executable graph-based model include one or more of: a node, an edge, a role, and an overlay.71. The device of 51 wherein the first selector is displayed proximate the graphical representation of the first node.72. The device of 51 wherein the first selector and the graphical representation are contiguous.73. The device of 51 wherein the first display element associated with the first node comprises a shape.74. The device of 73 wherein the shape is a circle.75. The device of 51 wherein the first display element associated with the first node comprises an icon indicative of the first node.76. The device of 51 wherein the first display element associated with the first node comprises a label.77. A method for interactive visualization of executable graph-based models, the method comprising:obtaining, by processing circuitry, an executable graph-based model comprising an executable node, wherein the executable node comprises a composition of a first node and a first overlay structure associated with the first node;displaying, by the processing circuitry, a graphical representation of the executable node of the executable graph-based model, the graphical representation comprising a first display element associated with the first node and a second display element associated with the first overlay structure, wherein the second display element represents the first overlay structure at a first level of detail;displaying, by the processing circuitry, a first selector associated with the graphical representation of the executable node;receiving, by the processing circuitry, a first user input associated with the first selector; andin response to the first user input being received, replacing, by the processing circuitry, the second display element of the graphical representation of the executable node with a third display element whilst maintaining display of the first display element, wherein the third display element represents the first overlay structure at a second level of detail.78. A non-transitory computer-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to:obtain an executable graph-based model comprising an executable node, wherein the executable node comprises a composition of a first node and a first overlay structure associated with the first node;display a graphical representation of the executable node of the executable graph-based model, the graphical representation comprising a first display element associated with the first node and a second display element associated with the first overlay structure, wherein the second display element represents the first overlay structure at a first level of detail;display a first selector associated with the graphical representation of the executable node;receive a first user input associated with the first selector; andin response to the first user input being received, replace the second display element of the graphical representation of the executable node with a third display element whilst maintaining display of the first display element, wherein the third display element represents the first overlay structure at a second level of detail.79. A system comprising:an executable graph-based model, the executable graph-based model comprising:a first overlay node, wherein the first overlay node comprises processing logic operable to interact with one or more associated nodes of the executable graph-based model; anda first node having the first overlay node associated therewith; anda processing unit configured to:receive a first stimulus associated with the first overlay node; andin response to the first stimulus being received, cause execution of said processing logic of the first overlay node, wherein execution of said processing logic of the first overlay node is based on the first node.80. The system of 79 wherein the first stimulus comprises a first context such that execution of said processing logic of the first overlay node is based on the first context.81. The system of 80 wherein the first node comprises a state.82. The system of 81 wherein the state is shared by the first node and a second node of the graph-based model.83. The system of 81 wherein execution of said processing logic of the first overlay node causes a change in the state of the first node.84. The system of 83 wherein the state of the first node comprises a first attribute.85. The system of 84 wherein execution of said processing logic of the first overlay node causes a value of the first attribute to be set.86. The system of 84 wherein execution of said processing logic of the first overlay node causes a value of the first attribute to be output.87. The system of 84 wherein execution of said processing logic of the first overlay node cause a second attribute to be generated for the state of the first node.88. The system of 87 wherein execution of said processing logic of the first overlay node causes a value for the second attribute to be set.89. The system of 80 wherein execution of said processing logic of the first overlay node causes a second stimulus associated with a second overlay node of the executable graph-based model to be fired.90. The system of 89 wherein the processing unit is further configured to:receive the second stimulus associated with the second overlay node; andin response to the second stimulus being received, cause execution of processing logic associated with the second overlay node.91. The system of 79 wherein the first node is derived from a second node.92. The system of 91 wherein the first node is derived from the second node and a third node.93. The system of 79 wherein the first node comprises a unique identifier, one or more attributes each having corresponding attribute values, a version, a name, a namespace, and associated metadata.94. The system of 79 wherein each node within the executable graph-based model is associated with a node type.95. The system of 94 wherein the node type of the first node is a data node type.96. The system of 94 wherein the node type of the first node is a value node type.97. The system of 94 wherein the first overlay node is a node associated with an overlay node type.98. The system of 94 wherein the first overlay node defines the node type of the first node.99. The system of 94 wherein the first node comprises a composition of a second node of the graph-based model and a second overlay node.100. The system of 99 wherein execution of said processing logic of the first overlay node causes execution of processing logic of the second overlay node.101. The system of 94 wherein the node type of the first node is an edge node type such that the first node is a first edge node.102. The system of 101 wherein the first edge node connects a plurality of nodes within the executable graph-based model.103. The system of 102 wherein the plurality of nodes within the executable graph-based model are connected by the first edge node via a corresponding plurality of roles, wherein each role in the corresponding plurality of roles corresponds to a node associated with a role node type.104. The system of 103 wherein each role in the corresponding plurality of roles defines a relationship between the first edge node and a respective node of the plurality of nodes connected by the first edge node.105. A method comprising:obtaining, by one or more processors, an executable graph-based model, the executable graph-based model comprising:a first overlay node, wherein the first overlay node comprises processing logic operable to interact with one or more associated nodes of the executable graph-based model; anda first node having the first overlay node associated therewith;receiving, by the one or more processors, a first stimulus associated with the first overlay node; andin response to the first stimulus being received, causing, by the one or more processors, execution of said processing logic of the first overlay node, wherein execution of said processing logic of the first overlay node is based on the first node.106. A non-transitory computer-readable medium storing instructions which, when executed by processing circuitry, cause the processing circuitry to:obtain an executable graph-based model, the executable graph-based model comprising:a first overlay node, wherein the first overlay node comprises processing logic operable to interact with one or more associated nodes of the executable graph-based model; anda first node having the first overlay node associated therewith;receive a first stimulus associated with the first overlay node; andin response to the first stimulus being received, cause execution of said processing logic of the first overlay node, wherein execution of said processing logic of the first overlay node is based on the first node.