Top-down Speci cation of Bayesian Networks and ... - CiteSeerX

Top-down Speci cation of Bayesian Networks and Compact Representation of Repetitive Structures in Bayesiean Networks Olav Bangs

Pierre-Henri Wuillemin

Department of Computer Science Aalborg University { Fredrik Bajers Vej 7 9220 Aalborg, Denmark [email protected]

Abstract Bayesian networks are not easy to design and maintain. It is a time consuming process to update a Bayesian network even though only a small set of nodes with many occurrences has to be changed. In this paper, we describe a solution to these diculties by taking an object oriented approach to constructing Bayesian networks by merging fragments of Bayesian networks. Our approach consists of a new framework based on the framework presented in [Koller and Pfeer, 1997]. Our framework allows top-down methodologies for the design of Bayesian networks, provides an ecient class hierarchy and a compact way of specifying and representing temporal Bayesian networks. Furthermore a conceptual simpli cation is achieved. It will be possible to design, maintain and use each fragment as a unit. Updating such a unit updates each occurence of this unit in the whole Bayesian network.

1 Introduction Designing and maintaining Bayesian networks (BN) can be a time consuming process. Using current tools and techniques, a top-down approach to building BNs is not possible and there is no compact way to represent temporal BNs. Based on the concepts in [Koller and Pfeer, 1997], the goal of this paper is to provide a solution to these diculties by constructing a BN using an object oriented approach. In short, this paper aims at: 

allowing a top-down methodology for the design of Bayesian Networks,

SYSDEF, LIP6 Universite Paris 6 { 4, place Jussieu 75252 Paris Cedex 05, France [email protected] 



supplying an easy-to-use tool for specifying large BNs, especially those with repetitive structures like temporal Bayesian networks, using encapsulation and hierarchy in an object oriented way.

Because our work is an extension and adaption of the framework by Koller and Pfeer [Koller and Pfeer, 1997] to our goals, the major differences between the two frameworks is pointed out throughout this paper. The goals are not exactly the same (neither top-down modeling nor repetitive structures appear in the Koller and Pfeer framework where the main focus is on modularisation and probability functions).

1.1 Limitations of conventional Bayesian network construction Suppose we want to build the BN described in [Andreassen et al., 1994] for evaluating a diabetes patients insulin dose. A natural way to think about this domain conveys a model for each hour with some variables describing the state of the subject during the previous hour together with some static characteristics of the subject (see Figure 1). The whole BN is then just a sequence consisting of this pattern repeated 24 times (with some auxiliary nodes and links between the patterns and the other nodes of the network). So this rather complex and large BN is the repetition of a BN fragment. Each of these fragments is somehow independent from the rest of the network and remains understandable by the user. Using small and 'easy-to-read' pieces of a complex model is an already applied technique for building large Bayesian networks. For instance, [Pradhan et al., 1994] introduces the concept of subnetworks which can be viewed and edited separately

even if they are dierent pieces of the same network; [Srinivas, 1994] adds levels of integration of fragments (using an analogy with boolean circuits); [Laskey and Mahoney, 1997] is concerned with the combination of fragments (using conditional noisyMIN); and [Koller and Pfeer, 1997] presents a framework for such representations. We would like to focus on the fact that this way of thinking about BNs could lead to more than just simplifying the task of modeling. It could allow a very compact speci cation of knowledge (especially if it contains repetitive structures) and it is expedient to allow a top-down modeling process. Each fragment can be viewed as a \black box" that can be speci ed after the speci cation of the structure between \black boxes". The \black boxes" can be used before being designed, knowing that they will be fully speci ed later. The normal building process of BNs does not allow this but requires the designer to simulate this process only by using smart placement (or colors) of nodes and copy-paste operations. Hour 1

Hour 0 Ins Release

Bound

Ins Sens

Met Irr



A node inside an abstract node has parents outside (CHO has a parent Breakfast, Lunch or Dinner outside the abstract node).



A node outside has parents inside (for instance, we want to control the lowest rate of glucose in the blood during the whole day by adding a \min" node outside the abstract nodes, linked to the node BG of each abstract node).

Ra

Ins Dep

BG

BG

Ins Ind

Meal

struction process. We call these fragments templates1 . Each change made inside such a template should update each use of this template. For instance if we change the potential of Glucuria given Renal Cl (Figure 1), we do not want to have to change this manually 24 times; the same goes for structural changes. A template encapsulates nodes and restricts the scope (visibility) of its nodes to the interior (i.e. a node inside a template can not be used from the outside and vice versa). When a template is used inside another template, it is represented by a special node called an abstract node2 . In the BN described above, each hour can be represented by an abstract node of the same template, which should be designed somehow as depicted in Figure 1. The whole BN will then only include 24 abstract nodes of this template, some general nodes like 3 meals and some interaction between the abstract nodes (see Section 4). Even though a template is viewed as a unit, interaction between abstract nodes (and nodes) is needed. More precisely there are two types of interactions:

Renal Cl

Glucuria

Gut Abs CHO

CHO

Meal: Amount of glucose eaten during this hour. CHO: Glucose reservoir in the stomach. Ins Sens: How sensitive is the diabetic subject to insulin. Ins Release: Insulin released into the blood stream during this hour. Gut Abs: Glucose absorbed into the blood stream from the stomach. Bound: Insulin bound in the blood stream. Ra: Glucose released from/absorbed in the liver. Ins Dep: Insulin dependent glucose utilisation. Renal Cl: Glucose removed from the blood by the kidneys Ins Ind: Insulin independent glucose utilisation. Glucuria: Amount of glucose in the urine of the diabetes during this hour. Met Irr: Metabolic irregularities (trap for random uctuations) BG: Amount of glucose is in the diabetes blood during this hour.

Figure 1: The pattern for each hour of the BN for insulin prediction (see [Andreassen et al., 1994])

1.2 A new framework The BN designer should be able to implement the BN fragment by fragment (in any order) and to use each fragment any number of times in any step of the con-

The rst type of interaction is problematic. The potentials of inner nodes (speci ed in the template speci cation) should not be changed in any instantiation of the template. This means that no node inside a template can have parents outside the template. A new type of node (reference node) is therefore introduced to enlarge the scope of a node. A reference node is a special node representing a node (called the referenced node3 ) in another scope. A reference node is like a pointer, except that it has its own speci c characteristics (label, position, etc ) but the type (set of states) and the potential are the same as its referenced node. A reference node is linked to its referenced node by a special link called a reference link (see Figure 3b). For instance, let T be a template modelling an hour :::

1 A template resembles to a \class" in the object oriented paradigm. 2 An abstract node corresponds to an instantiation of a template (class). 3 Note that we explicitly distinguish between \referenced node" and \parent node".

for a diabetic (see Figure 2), and let t1 t24 be 24 abstract nodes of T describing the 24 hours of a day. Then t8.CHO (i.e. the instantiation of the node CHO of T inside the abstract node t8) can depend on an outside node Breakfast (i.e amount of glucose eaten during breakfast). So, we create the node Meal inside T. this Meal node is a reference to an outside node, so it is marked as an import node. Now we can \reference link" t8.Meal to its referenced node Breakfast. So, the potential of each node in t8 (except Meal as it is a reference to Breakfast) is de ned inside the template T and Breakfast is known as the parent of node t8.CHO (inside the abstract node t8). :::

Diabetes Meal

CHO old

Ins Sens

BG old

Gut Abs

Ins Release

Bound Ra Renal Gl

Ins Ind

Glucuria

Ins Dep

X Inside the abstract node t1

Inside the abstract node t4 Y Inside the abstract node t3

E I

Outside the abstract node

a)

Inside the abstract node t2

b) Directed link Reference link

Outside the abstract node

c) Export node Import node

Figure 3: The import/export scheme: a) E, a node of the abstract node t1, is a parent of two nodes outside t1. b) X is a 'parent' of two nodes inside the abstract node t2. c) Y, an export of the nested abstract node t4, is a parent of two nodes outside the abstract node t3.

Met Irr

CHO BG

Figure 2: A template describing an hour for a diabetic. The nodes with dotted edges are import nodes, and the shaded nodes are export nodes. Note that another instantiation, say t12, of T can have a dierent outside parent by \reference linking" the instantiation of Meal (t12.Meal) with a dierent outside node (say Lunch), provided has the same type (or number of states) as Breakfast. As mentioned above, reference nodes are just references to a node that contains the proper potential. Changing the potential of a node in a reference to it is not possible. This means that a reference node can not have parents. However, to simplify speci cation, we allow reference nodes to have a `default prior distribution' used when no referenced node is given. (The import node Meal has a default prior saying that no glucose has been eaten during this hour. It is used when the node is not \reference linked" to an outside node like Breakfast or Lunch). The type of interaction where outside nodes have inside parents presents no problem. Any node of a template, except import nodes, can be marked as an export node and making it a possible parent of nodes outside (see Figure 3a). A node which is neither import nor export is called a hidden node4 . 4 The

Outside the abstract node

import and export nodes of a template form the template interface, the visible (from the outside) part of the template. An abstract node of a template only shows its interface

Sometimes it might be useful to have a nested abstract node as export. For instance (in Figure 3), a node inside t4 is needed as a parent of two nodes outside t3, but t3 encapsulates t4. Using abstract nodes as exports might lead to some confusion and it might make it harder to get an overview of the templates. Therefore, using abstract nodes as import or export nodes is not allowed. Instead, another use of reference links and reference nodes is given. To enlarge the scope of a node in a nested abstract node to the outside of the encapsulating template, export nodes can be reference nodes. This allows an export node in a nested abstract node to be visible outside the encapsulating template (see Figure 3c). Nodes outside an abstract node can be parents of nodes inside a nested abstract node using chains of import nodes in the same way. So, to summarise export nodes can be reference nodes, import nodes must be reference nodes. A template is a fragment of a BN (nodes and directed links) containing special nodes (abstract nodes and reference nodes) and special links (reference links) with two special sets of nodes: import nodes (which are all reference nodes) representing outside nodes used in the template and export nodes (the nodes of the template that outside nodes can have as parents). Clearly, the class of templates includes the class of BNs (a BN can be viewed as a template with no abstract nodes, no reference nodes and empty import and export sets). The scope of a template consists of all its nodes and all the import and export nodes of the abstract nodes it contains. The Koller and Pfeer framework uses an \Object-Oriented" terminology (class/object) (see

[Koller and Pfeer, 1997]). We prefer the speci c terminology (template/abstract node) to avoid confusion. We use the term \instantiation" though. The concepts introduced in this paper has been implemented so that given a template description a BN corresponding to it can be obtained. See [Bangs and Wuillemin, 1999] for further information on the implementation. Section 2 of this paper gives more formal de nitions of the concepts introduced. Section 3 illustrates how to use this framework for a top-down process of constructing a BN. Section 4 explains how to use this framework for a compact time slice representation. Section 5 enhances this framework with an Object Oriented hierarchy.



 

Node de nitions - A node in a template is either: 

2 Template de nitions The terminology for template representations of BNs is described below.  



Template - is a fragment of a Bayesian network.

Its speci cation can use abstract nodes. Abstract node - is an instantiation of a template within the speci cation of another template. There can be several abstract nodes of a single template5 . Underlying BN - of a template is the BN corresponding to the template. The underlying Bayesian network, T , of a template T can be constructed by compiling T, at any step of the BN speci cation ([Bangs and Wuillemin, 1999]). BN

De nition 1 A template T is a DAG over ( , , ). I

 



H

E

is a set of import nodes, H is a set of hidden nodes (including abstract nodes of templates which do not contain abstract nodes of T: no recursion), E is a set of export nodes.

I

For a template T with I , H and E as import, hidden and export sets and for each abstract node t of T with 6 It , Ht and Et as import, hidden and export sets :  I , H , E are pairwise disjoint. 5 \an abstract node of a template"

means that this abstract node is an instantiation of the template. When we want to say that an abstract node belongs to a template (is an abstract node in the template), we use the terms 'encapsulation' or 'nesting'. 6 It is the instantiation of I and so on.

A node of It has no parents in t (none speci ed for I in T), it has no children outside t and it can have at most one referenced node outside t. A node of Et has no parents outside t. A node of Ht has no children or parents outside t.



Simple node is either:  Real node represents a chance variable.  Reference node speci es import and export

nodes only. A reference node can have only one referenced node and is a placeholder for it. An optional default prior distribution is used when no referenced node is speci ed. A reference node can not have parents, but it may have children. All import nodes are reference nodes. An export node can be a reference node (when an export node of an abstract node is used as an export node of the template encapsulating it). A hidden node can not be a reference node. Abstract node the instantiation of a template inside another template.

The Koller and Pfeer framework allows structured types for import and export nodes. We have chosen to simplify the template construction without any loss of expressive power by forcing import and export nodes to be simple nodes, at the expense of exibility. Discrete typing - For discrete nodes, a type consists of a nite set of value labels. Each of them represents a possible value of that variable. When type checking pairs of nodes we allow weak as well as strong typing. Two nodes with the same number of value labels are type consistent, using weak typing. If the labels have a natural order, it will be assumed that values are sorted in the same order in the two types if no one-toone mapping between them is explicitly given. When using strong typing, the value labels of the two nodes should be the same, and in the same order. Link de nitions - The links are de ned as:  

Directed links (Simple node!Simple node) Links as in normal BNs. Construction links (node9 9 Knode) A9 9 KB means the node A and the node B will have to be linked in some manner. We allow construction links to be directed and undirected. A



and/or B can be abstract nodes. Construction links have no impact on the underlying BN, they are just a help during speci cation, and will not be described in further detail. Reference links (Simple node)Reference node) A)B means \A is referenced by B". B is the reference node and A is the referenced node. In the underlying BN, A and B will be merged into one node. To avoid redundancy, we introduce the restrictions that reference links may not be speci ed between two simple nodes in the same template, and no node may be the referenced node for more than one reference node in the same template.

Reference tree - Each set of nodes connected via

reference links forms a tree (for each reference node there can be only one referenced node). Such a tree will be called a reference tree. A path in such a tree is called a reference chain and the root of a reference tree is called the referenced root as it is the node all other nodes in the tree are referencing. The restriction on reference links means that: 







Import nodes can not be used as referenced nodes for simple nodes speci ed in the same template (i.e. the import, the hidden and the export nodes) but only for import nodes of nested abstract nodes. Two import nodes in an abstract node can not have the same referenced node. Export nodes can be used as referenced nodes for export nodes in the encapsulating template, and import nodes in a dierent abstract node in the encapsulating template. Two export nodes of the same template can not have the same referenced node. Hidden nodes can be used as referenced nodes for import nodes of abstract nodes only. Hidden nodes will always be referenced roots if they occur in a reference tree, as they can never be reference nodes. A chain of reference links can go in both directions (further inside templates or further out) but once once a chain goes deeper inside the nesting of abstract nodes, it can not go out again (see Figure 4b).

These restrictions do not aect the expressive power of our framework (see [Bangs and Wuillemin, 1999]). The two frameworks (the Koller and Pfeer framework and ours) provide a one-to-one map between each import of an object/abstract node and an attribute/node

a- Two reference chains

b- An illegal reference chain

Figure 4: a) Two reference chains. b) Reference links between two nodes in the same template are illegal and, because import nodes can only be referenced nodes for other import nodes, once a chain goes deeper inside the nesting of abstract nodes it, can not go out again. of the encapsulating object/template. Because of the complexity of the inputs, the Koller and Pfeer framework needs a more abstract de nition of this map. In our framework the expressive power is the same but we are able to allow import nodes without a referenced node whereas Koller's and Pfeer's inputs always need annotations. This seems a minor dierence but it is the result of the main conceptual gap between the two frameworks. the Koller and Pfeer framework considers the inputs of an object as parameters of a function. It does not allow inner properties inside the inputs (which are not objects). This representation (OOBN as a function) implies that each import must have a referenced node. This prevents de facto topdown modeling. We shall see later other implications of this point (section 5).

3 Top-Down construction of a Bayesian network Using the nodes and links described above it is possible to take a top-down approach to speci cation of a BN (see Figure 5). It is possible to use abstract nodes of a template even if it has not been completed. The construction link feature has been added to the template framework as a help for top-down modeling. A construction link is the indication of a kind of relation between two entities before knowing the entities as much as needed to specify a probabilistic or a reference link relation between them (or between parts of them). The default prior for reference nodes ensures that any abstract node of a template can be used even though the way it should be used is not yet known. So, a template with abstract nodes of other templates can be compiled and manipulated, without all used templates being completed or all reference nodes having a

referenced node. Output of T1 specified

Template 1

The self-reference links are treated in the following manner: Input of T2 specified

Template 2

Template 1 Template 2

 Template 1

Template 1



Template 2



N >

N

Output node input node

Contruction link Join link

Figure 5: Four possible states in the modeling of the relation between two abstract nodes. From the beginning, where the designer knows that there will exist a link between them, to the end where the two abstract nodes and their links are fully speci ed.

4 Time slice representation In a BN, the same structure is sometimes repeated several times. The repeated structure might be representing a collection of identical structures or the same part of the world at dierent times. Therefore some kind of structure between the representations can be needed (e.g. The Diabetes example in [Andreassen et al., 1994]). These structures are called time slices. To specify a time slice, at least the basic structure to be repeated must be speci ed. The basic structure of a time slice is represented using a template where some restrictions are relaxed. In the speci cation of such a template, it is legal to specify directed cycles, provided one of the links is a reference link to an import node of the template (a self-reference link). In Figure 6, the directed cycle between BG and BG old is legal. The meaning of such a cycle is that BG old7 is a parent of BG in the rst time slice, and BG is a parent of BG old's children in the next time slice.

4.1 Instantiations of a time slice template An instantiation of a time slice template is represented by an abstract node containing the number of copies requested (say ), import nodes for the initial imports self-referenced from inside the template, and one import for every other import node for each copy. The abstract node also contains export nodes for each copy. N

ing template

N >

>

Template 2

7 or the referenced node of BG

N

i < N

Output of T1 specified

Input of T2 specified

If = 1, self-reference links are ignored in the abstract node. If 1, then every self-reference link A)I (I is an import node of the template, and A is a visible node8 in the template) means that A i= I (i+1) for 1  . If 1 and there are no self-reference links in the template, the abstract node contains copies of the template. This may seem like a strange set of time slices, but it can be used for making multiple instantiations of a template in one abstract node.

old from the encapsulat-

To allow a node to be a parent of all copies of a node, without specifying all the links, the reference all operator is introduced. If A is reference linked to all the copies of import node I in the abstract node t of the template T, A is reference linked to t.I i 8 2 f1 g, written as A)t.I *(see Figure 7, Ins Sens is referenced by all John.Ins Sens nodes in the abstract node). If all copies of an export node are parents of a node, the linkall operator is used. The linkall is speci ed in the potential for the child node, e.g. if all copies of the export node E of the abstract node t should be parents of B in the encapsulating template for t , the speci cation of the potential for B will include t.E * (e.g. potential (Bjt.E *). In Figure 7 all John.BG are parents of BG max and BG min). The problem of handling nodes with that amount of parents is not addressed in this paper. i

;::: ;N

4.2 The Diabetes example In [Andreassen et al., 1994], the basic structure of the time slice (see Figure 2) can be easily transformed into the template in Figure 6. The time slice template in Figure 6 represents an hour for a diabetic. It is used to nd out how much insulin the diabetic needs to take by monitoring how much food the diabetic eats and measuring the value of the blood sugar. In Figure 7, an abstract node with 24 copies of the template in Figure 6 is shown together with some general nodes. The import nodes Meal, and Ins Release indicate that there are unreferenced copies of them in the abstract node. The other import and export nodes are all linked to nodes outside the template. Meal init, CHO init and BG init, represent the initial values for the day. Ins Sens is a constant for the person, and is therefore reference alled to the Ins Sens of John 8A

hidden or an export node of the template, or an export of an encapsulated abstract node.

problems, we use a template hierarchy framework. A template hierarchy has the same goals as a class hierarchy in the Object Oriented Paradigm (OOP):

Diabetes

Meal

CHO old

Gut Abs

Ins Sens

BG old

Ins Release

CHO



Bound



Ra Renal Gl

Ins Dep



Ins Ind Glucuria

Met Irr

BG

Figure 6: Diabetes, a time slice template representing an hour for a diabetic (note the dierences to Figure 2; e.g. CHO does not need to be an export node).

to simplify speci cations of similar templates to allow automatic updates in templates sharing some properties. to organize knowledge in a hierarchical way

Creating a subclass in OOP consists of taking a class (with all its attributes and methods) and adding or changing some attributes and methods. In the same way, creating a subtemplate of a template consists of taking a template (with all its nodes and potentials, etc.) and changing some of them and/or adding new ones.

De nition 2 A template S over ( S S a subtemplate of a template T over ( T I

(John.Ins Sens *). Breakfast, Lunch and Dinner represent that John eats three times during the day, and his meals are at the 8'th, 12'th and 18'th hour of the day (they are reference linked to John.Meal 8,12 and 18). He gets insulin 4 times a day at regular intervals (7, 11, 15 and 19). Instead of reference linking all Meal and Ins Release nodes to an outside node, the default prior is used, so that any of these nodes not reference linked is in the state indicating that no glucose or insulin has been administered. The exports John.BG 1-24 are all linked to BG max and BG min that gives the maximal and minimal value of the blood sugar. Patient Meal init

Ins Release 1

Lunch

CHO init

BG init

Ins Sens

Ins Release 2

Dinner

Breakfast

Ins Release 3

;H I

S ) can be T ; ET ), if

;E

;H

IT  IS , HT  HS and ET  ES , written as SbT. Equality between nodes means that they are identical. If a template A is a subtemplate of two other templates B and C then either BbC or CbB.

De nition 2 means that a subtemplate has at least the same set of nodes, as the supertemplate, but it states nothing about the way the nodes are linked and reference linked. Note also that this de nition de nes a relation on templates which is transitive but not anti-symmetric. To avoid cycles, we require that a subtemplate of a template can not also be a supertemplate of that template. A

B

Ins Release 4

C Meal

CHO old

BG old

Ins Sens *

Ins Release 7

Meal 12

Ins Release 15

D Ins Release

Meal 8

John:Diabetes

Meal 18

Ins Release 11

E

Ins Release 19

A

Template X

B

G

A

B

BG * 24

C BG max

F

C

BG min

D

Figure 7: A template representing a day for a diabetic. Figures 6 and 7 fully specify a whole network with 271 nodes. The hidden nodes of an abstract node are not shown.

5 Template hierarchies The problem of building similar but not identical templates still remains. Even if they share a large part of their speci cations, each template has to be completely and independently de ned. To solve these kinds of

E

H

Template Y

D

E

Template Z

Figure 8: A template X and two subtemplates Y and Z of X. As shown in Figure 8, creating a subtemplate from a template consists of creating new nodes (import, hidden and/or export nodes) and rede ning any part of the potentials. Y has only one new hidden node, F, and two 'new' potentials: ( j ), which is a new potential, and ( j ), which is a rede nition of the potential of . The speci cation of Y includes only this P F B

P E F

E

new node and these two new potentials. Z de nes new import and export nodes as well. As the Koller and Pfeer framework is aimed at modularisation of BN models rather then top-down modelling they can not handle a \not connected" input. Because an object has to be able to be exchanged with an object of a subclass, they need to have a non-intuitive de nition of sub-classes, saying that an interface type = (I ( ) E ( )) is a subtype of = (I ( ) E ( )) if I ( )  I ( ) and E ( )  E ( ), meaning that a subtype has a \smaller" input set and a \larger" output set. Because we have a default prior for the import nodes, we can allow import nodes without referenced nodes and have this more usual de nition of inheritance. These de nitions fully specify a consistent template hierarchy. What is important to note about this template structure is: t

t ;

t

0

t

t

0

0

t

;

t

0

t

t

t

0



Only the new speci cations are explicitly written in a subtemplate speci cation.



In Figure 8, if the potential of C is changed in X, it is also changed in Y but not in Z.



The hierarchical organization is explicit and treestructured



An abstract node of a template, can be used instead of an abstract node of any of its supertemplates, because it has at least the same import, and export nodes.

6 Conclusion In this paper we have presented a new framework for the construction of Bayesian networks. The result is a tool allowing exible top-down speci cation of BNs, and signi cant improvements for maintaining and modifying such BNs. We think that the great advantage of this tool is the simplicity in use. The concepts used are not far from the usual BN concepts. The need and the goal of new concepts (reference links, construction links and reference nodes) seem to be straightforward and the restrictions on these objects (e.g. the restrictions on the reference tree) are clear and can be automatically checked. It seems that our framework and the Koller and Pfeffer framework have the same expressive power though we allow top-down modelling (see Section 3). Our framework provides an easy-to-use tool for compact time slice template representation and speci cation (see Section 4) and it contains an ecient and intuitive class hierarchy (see Section 5). Also we nd this

new framework conceptualy simpler than previously proposed frameworks. We have implemented the basic data structures for a template-based speci cation of BNs, and we are able to generate a le in a net le language format corresponding to the underlying BN of a template. A graphical tool to manipulate and build templates is under construction. Another issue should be to use this template structure of a model to enhance the propagation scheme. We already have a way of building MSBNs as de ned in [Xiang et al., 1993] corresponding to a template (see [Bangs and Wuillemin, 1999]).

Acknowlegments The authors would like to thank Finn V. Jensen, Ue Kjrulf, Lars M. Nielsen and Kristian G. Olesen for their valuable input and comments.

References [Andreassen et al., 1994] Andreassen, S., Benn, J., Hovorka, R., Olesen, K. G., and Carson, E. R. (1994). A probabilistic approach to glucose prediction and insulin dose adjustment: Description of a metabolic model and pilot evaluation study. Computer Methods and Programs in Biomedicine, 41:153{165. [Bangs and Wuillemin, 1999] Bangs, O. and Wuillemin, P.-H. (1999). Object oriented hugin { a framework for topdown speci cation of large bayesian networks with repetitive structures. Technical report, Department of computer science. [Koller and Pfeer, 1997] Koller, D. and Pfeer, A. (1997). Object-oriented bayesian networks. In Geiger, D. and Shenoy, P. P., editors, Proceedings of the Thirteenth Conference on Uncertainty in Arti cial Intelligence, pages 302{313, San Francisco. Morgan Kaufmann Publishers. [Laskey and Mahoney, 1997] Laskey, K. B. and Mahoney, S. M. (1997). Network fragments: Representing knowledge for constructing probabilistic models. In Geiger, D. and Shenoy, P., editors, Proceedings of the Thirteenth Conference on Uncertainty in Arti cial Intelligence, pages 334{341, San Francisco, California. Morgan Kaufmann Publishers. [Pradhan et al., 1994] Pradhan, M., Prova, G., Middleton, B., and Henrion, M. (1994). Knowledge engineering for large belief networks. In Proceedings of the Tenth Conference on Uncertainty in Arti cial Intelligence, pages 484{490, San Francisco, California. Morgan Kaufmann Publishers.

[Srinivas, 1994] Srinivas, S. (1994). A probabilistic approach to hierarchical model-based diagnosis. In Proceedings of the Tenth Conference on Uncertainty in Arti cial Intelligence, pages 538{545, San Francisco, California. Morgan Kaufmann Publishers. [Xiang et al., 1993] Xiang, Y., Poole, D., and Beddoes, M. P. (1993). Multiply sectioned Bayesian networks and junction forests for large knowledgebased systems. Computational Intelligence, 9(2):171{220.