An Object-Oriented Network is a network (i.e., Bayesian network or (limited-memory) influence diagram) that, in addition to the usual nodes, contains instance nodes. An instance node is a node representing an instance of another network. In other words, an instance node represents a subnet. Of course, the network of which instances exist in other networks can itself contain instance nodes, whereby an object-oriented network can be viewed as a hierarchical description (or model) of a problem domain. There are three main advantages of constructing a network using instance nodes:
The model construction activity most often involves repeated changes of level of abstraction. That is, it is performed in a top-down fashion, a bottom-up fashion, or a mix of the two. Such repeated changes of focus are due partly to the fact that humans naturally think about systems in terms of hierarchies of abstractions and partly due to lack of ability to mentally capture all details of a complex system simultaneously. The use of instance nodes provides support for working with different levels of abstraction in constructing network models.
As systems often are composed of collections of identical or almost identical components, models of systems often contain repetitive patterns (i.e., commonly occurring solutions or problem types). In Bayesian networks and influence diagrams, such patterns are network fragments. The notion of instance nodes makes it very easy to construct multiple identical instances of a network fragment.
Describing a network in a hierarchical fashion often makes the network much less cluttered, and thus provides a much better means of communicating ideas among knowledge engineers and users.
An instance node connects to other nodes via some of the (basic) nodes in the copy of the network (the master) of which it is an instance. (Note that an instance node should be thought of as a copy of the network of which it is an instance.) These nodes are known as interface nodes. As we wish to support information hiding, the interface nodes only comprise a subset of the nodes in the master network. Interface nodes are subdivided into a set of input nodes and output nodes:
Input nodes of an instance of a master network are not real nodes but only to be considered as placeholders for (basic) nodes of the network(s) containing instances of the master network. These basic nodes are said to be bound to the input nodes (and vice versa). Note that if an input node of an instance hasn’t been bound, a default potential (probability table) will be associated with it. The probabilities in this table is specified in the master network.
Output nodes of an instance of a master network are real nodes that can be specified as parents of nodes in the network containing the instance node or can be bound to an input node of another instance node of the network.
Instance nodes can be displayed in two different modes: Expanded (showing its interface nodes) and collapsed (having the same size as other nodes). To avoid problems with overlapping nodes and increased node distances when expanding and collapsing an instance node, respectively, the HUGIN Graphical User Interface provides a rudimentary feature for moving nodes that would otherwise overlap with the instance node or be placed too far away from it when expanding or collapsing, respectively, the instance node. This feature can be enabled or disabled by clicking the “Fit network when expanding notes” check box of the OOBN tab of the Network Properties Pane (see Figure 1).
When connecting a node to an to input nodes in an OOBN instance two nodes must be consistent. To be consistent, they must have the same “Category” and “Kind”. The Category indicates whether it is a chance node, a decision node, a utility node, or an instance node. The Kind indicates whether a chance or a decision node is discrete or continuous. Furthermore, if the kind of the node is discrete, it must have the same number of states, and finally, if it is Numeric, the state values must be the same. The Hugin Graphical User Interface offers to check whether these rules are satisfied while the model is being constructed or only when the model is compiled. To disable the checks while the model is constructed un-check the box labelled “Check consistency when adding a link to an input node” (see Figure 1).
The tutorial on object-oriented networks shows how to construct an object-oriented network using the HUGIN Graphical User Interface.