The Interchange Format for Bayesian Networks


Introduction

The objective of this web site is to summarize and distribute information on an effort to standardize formats for representation of Bayesian networks and other related graphical models.

The goal of the current effort is to specify a XML-based format that is very simple to understand and yet can represent directed acyclic graphs with probabilistic relations, decision variables and utility values. The current format is referred to as XMLBIF version 0.3.

Historic backgroud

Several members of the UAI community have felt that a common format for Bayesian networks would significantly enhance the exchange of knowledge and experimental results in the community. In the spirit of fostering such exchange, several attempts have been made at creating a standardized format. A panel was organized at the UAI conference 1996, and formats such as the BNIF and the BIF were then proposed; eventually, a a group was formed to debate issues related to a possible standard. As these discussions proceeded, it became evident that defining a single all-encompassing format would likely be too hard a task at the current stage of knowledge.

During UAI conference 1998, a new panel was formed to assess the strategy to be followed in the direction of a standard format. The panel suggested that it would be a good idea to base it on XML (the Extensible Markup Language), as XML is now receiving industry wide support as a mechanism for data specification. The idea is that XML can provide an inicial layer of standardization. Even if different formats are proposed by different groups, the fact that they are based on XML makes translation much simpler. And the fact that XML-compliant parsers are freely available makes the whole process much smoother.

Following the panel discussion, a number of meetings among members of the UAI community suggested that another step in the path to standardization could be taken. It would be a good idea to try to define a very simple standard format in XML. Such a standard would have to be simple so that people could understand it quickly and construct parsers for it without too much work. The standard would be beneficial to familiarize people with XML and to indicate how to proceed in future standardization efforts.

These discussions led to the present standardization effort. A very simple format has been defined during conversations between Fabio Cozman and members of the GeNie project, notably Marek Druzdzel and Daniel Garcia. This format is described below, and is current referred to as the XMLBIF (XML-based BayesNets Interchange Format) version 0.3.

The XMLBIF format is being implemented in the JavaBayes and GeNie systems; there have been signs that implementations in the Netica and Hugin systems are in the works.

The XMLBIF working group

A number of people have contributed to the XMLBIF format. The format has been designed primarily by Fabio Cozman, with important contributions from Marek Druzdzel and Daniel Garcia. Akihiro Shinmori has contributed with his expertise in XML issues. Brent Boerlage, Frank Jensen and Bruce D'Ambrosio have supported the idea and contributed to the discussion.

Anyone can join the group and contribute.

The XMLBIF format

The goal of the current XMLBIF format is to represent directed acyclic graphs that can be associated to conditional probability measures for discrete variables, with the possibility that decision and utility variables be present in the graph.

The format emphasizes internationalization by adopting XML's guidelines for document specification (the XML documentation explains this at lenght; it amounts to the adoption of Unicode as the standard for character representation, case-sensitive documents, and tags for indicating document encodings).

XML is very similar to HTML and most structures used in HTML appear in XML.

Every file in XMLBIF must contain an initial XML tag that displays basic information about the document:

<?xml version="1.0"?>

The version attribute is mandatory. Other attributes, coming after the version attribute, are optional. For example:

<?xml version="1.0" encoding="US-ASCII"?>
Other XML tags may come after this initial tag. The XML specification details the possible tags. Essentially, the XML document may contain several indications regarding the grammar that must be enforced by the XML parser. The most interesting possibility is to embed the whole document specification in the top of the document through a !DOCTYPE tag. Here is the complete XML specification of XMLBIF version 0.3 (this is called a Document Type Definition, or DTD):
<!DOCTYPE BIF [
	<!ELEMENT BIF ( NETWORK )*>
	      <!ATTLIST BIF VERSION CDATA #REQUIRED>
	<!ELEMENT NETWORK ( NAME, ( PROPERTY | VARIABLE | DEFINITION )* )>
	<!ELEMENT NAME (#PCDATA)>
	<!ELEMENT VARIABLE ( NAME, ( OUTCOME |  PROPERTY )* ) >
	      <!ATTLIST VARIABLE TYPE (nature|decision|utility) "nature">
	<!ELEMENT OUTCOME (#PCDATA)>
	<!ELEMENT DEFINITION ( FOR | GIVEN | TABLE | PROPERTY )* >
	<!ELEMENT FOR (#PCDATA)>
	<!ELEMENT GIVEN (#PCDATA)>
	<!ELEMENT TABLE (#PCDATA)>
	<!ELEMENT PROPERTY (#PCDATA)>
]>

This tag contains the whole Document Type Definition (DTD) for
XMLBIF version 0.3, and it can be included in any XMLBIF
version 0.3 document.

The DTD shows all the tags that are used by XMLBIF version 0.3. 
The networks represented
in a file must be enclosed by BIF tags; the opening BIF tag must contain
the version of the format. For example:

<BIF VERSION="0.3">

Network here

Another network here

</BIF>
Each network is enclosed by NETWORK tags. A network is defined through a NAME tag and a sequence of PROPERTY, VARIABLE and DEFINITION tags (note that no order is imposed on PROPERTY, VARIABLE and DEFINITION tags).
<BIF VERSION="0.3">
<NETWORK>
<NAME>Dog-Problem</NAME>
<PROPERTY>date Sunday, 19 July, 1998</PROPERTY>
<PROPERTY>author John</PROPERTY>

	variables and probabilities go here

</NETWORK>
</BIF>

A property is just a string of arbitrary text to be associated with a block. Examples of properties:

    <PROPERTY>size 12</PROPERTY>
    <PROPERTY>comment Trial number ten</PROPERTY>
Any text is valid in the string inside the PROPERTY opening and closing tags. The idea is to store information that is specific to a particular system or network in the properties. Any number of property attributes can appear in a block. Properties can be associated to a NETWORK, a VARIABLE or a DEFINITION.

Variables are defined by their names, types and properties:

<VARIABLE TYPE="nature">
	<NAME>light-on</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (73, 165)</PROPERTY>
</VARIABLE>
Currently the content of a TYPE attribute must be the keyword either ``nature'' or ``decision'' or ``utility''.

Conditional probability densities are specified inside the DEFINITION tag. One example is:

<DEFINITION>
	<FOR>hear-bark</FOR>
	<GIVEN>dog-out</GIVEN>
	<TABLE>0.7 0.3 0.99 0.01 </TABLE>
</DEFINITION>

There is no mandatory order of variable and probability blocks.

The TABLE tag is specific to the DEFINITION block (note that a definition can be a probability distribution, a set of decision values or a set of utility values, depending on the TYPE attributes of the referred variable). DEFINITION blocks are used to define the actual network topology, by specifying conditional probability tables.

An example of a standard probability block is:

<DEFINITION>
	<FOR>GasGauge</FOR>
	<GIVEN>BatteryPower</GIVEN>
	<GIVEN>GasInTank</GIVEN>
	<TABLE>1.0 0.0
                   0.0 1.0
                   0.2 0.8
                   0.0 1.0 </TABLE>
</DEFINITION>
for a variable GasGauge that is defined with TYPE equal to ``nature''. The body of the TABLE tag is a sequence of non-negative real numbers, in the counting order of the declared variables, taking the GIVEN variables first and then the FOR variables (if all variables were binary, we would say binary counting with least significant digit in the right). If multiple table declarations exist, only the last one is valid.

Here is the dog-problem Bayesian network, based on the discussion in Charniak, E., Bayesian Networks without Tears, AI Magazine, 1991.

<?xml version="1.0" encoding="US-ASCII"?>


<!--
	Bayesian network in XMLBIF v0.3 (BayesNet Interchange Format)
	Produced by JavaBayes (http://www.cs.cmu.edu/~javabayes/
	Output created Wed Aug 12 21:16:40 GMT+01:00 1998
-->



<!-- DTD for the XMLBIF 0.3 format -->
<!DOCTYPE BIF [
	<!ELEMENT BIF ( NETWORK )*>
	      <!ATTLIST BIF VERSION CDATA #REQUIRED>
	<!ELEMENT NETWORK ( NAME, ( PROPERTY | VARIABLE | DEFINITION )* )>
	<!ELEMENT NAME (#PCDATA)>
	<!ELEMENT VARIABLE ( NAME, ( OUTCOME |  PROPERTY )* ) >
	      <!ATTLIST VARIABLE TYPE (nature|decision|utility) "nature">
	<!ELEMENT OUTCOME (#PCDATA)>
	<!ELEMENT DEFINITION ( FOR | GIVEN | TABLE | PROPERTY )* >
	<!ELEMENT FOR (#PCDATA)>
	<!ELEMENT GIVEN (#PCDATA)>
	<!ELEMENT TABLE (#PCDATA)>
	<!ELEMENT PROPERTY (#PCDATA)>
]>


<BIF VERSION="0.3">
<NETWORK>
<NAME>Dog-Problem</NAME>

<!-- Variables -->
<VARIABLE TYPE="nature">
	<NAME>light-on</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (73, 165)</PROPERTY>
</VARIABLE>

<VARIABLE TYPE="nature">
	<NAME>bowel-problem</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (190, 69)</PROPERTY>
</VARIABLE>

<VARIABLE TYPE="nature">
	<NAME>dog-out</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (155, 165)</PROPERTY>
</VARIABLE>

<VARIABLE TYPE="nature">
	<NAME>hear-bark</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (154, 241)</PROPERTY>
</VARIABLE>

<VARIABLE TYPE="nature">
	<NAME>family-out</NAME>
	<OUTCOME>true</OUTCOME>
	<OUTCOME>false</OUTCOME>
	<PROPERTY>position = (112, 69)</PROPERTY>
</VARIABLE>


<!-- Probability distributions -->
<DEFINITION>
	<FOR>light-on</FOR>
	<GIVEN>family-out</GIVEN>
	<TABLE>0.6 0.4 0.05 0.95 </TABLE>
</DEFINITION>

<DEFINITION>
	<FOR>bowel-problem</FOR>
	<TABLE>0.01 0.99 </TABLE>
</DEFINITION>

<DEFINITION>
	<FOR>dog-out</FOR>
	<GIVEN>bowel-problem</GIVEN>
	<GIVEN>family-out</GIVEN>
	<TABLE>0.99 0.01 0.97 0.03 0.9 0.1 0.3  0.7 </TABLE>
</DEFINITION>

<DEFINITION>
	<FOR>hear-bark</FOR>
	<GIVEN>dog-out</GIVEN>
	<TABLE>0.7 0.3 0.01 0.99 </TABLE>
</DEFINITION>

<DEFINITION>
	<FOR>family-out</FOR>
	<TABLE>0.15 0.85 </TABLE>
</DEFINITION>


</NETWORK>
</BIF>

Outside XML

It is important to note that there are some facts about the format that cannot be made explicit through XML. For example, if a DEFINITION contains several TABLE tags, only the last is valid. Another example is that XMLBIF version 0.3 accepts real numbers that are represented in scientific notation as specified in the ANSI C or Java language definitions.

XMLBIF version 0.3 is designed to make use of XML facilities; as such, it accepts Unicode characters. But as current implementations of parsers must, in many cases, rely on systems that do not have good Unicode support, we suggest that only ASCII characters are used in XMLBIF version 0.3 files for the moment. Also, identifiers (the name of the network, names of variables and names of outcomes) can be expressed in any Unicode character; however, we have some problems with this level of freedom. First, there are difficulties in writing customized parsers that can support the full range of Unicode. Second, there are questions related to the manipulation of mathematical expressions involving variables with arbitrarily complex names. For these reasons, we require that identifiers in XMLBIF version 0.3 satisfy somewhat restrictive conditions: any identifier must be a sequence of letters and digits, and the sequence must begin with a letter. A letter is any character in the sequences [a-z] and [A-Z] plus the underscore _. A digit is any character in the sequence [0-9]. It is possible that in the future a less restrictive set of conditions will be given for identifiers, along the lines of the Java language identifiers.

The most important aspect of the current format that is not captured by XML is the semantics of the contents of a TABLE tag. All distributions and utility values are specified as arrays of real numbers; XMLBIF version 0.3 does not require these numbers to be non-negative nor that they sum up to one. Such consistency conditions must be checked by the parser if desired. The important point is how tables are organized:

The probabilities for a binary variable can be specified in a simple manner:

0.15, 0.85

Let's consider a more complicated example. The conditional p(d|f,b) (the probability of d given f and b, where all variables are binary) is defined as

0.99, 0.01, 0.90, 0.1, 0.97, 0.03, 0.3, 0.70

The logic is simple: proceed as if you were filling a table, where the indices of the table vary from the right to left, with the conditional variables coming first (in the example above, it is like binary counting because all variables have only two values).

A more complicated example would be a function p(A|B,C) where A has 3 values, B has 2 values and C has 4 values. The function is represented as:

p(A1|B1 C1) p(A2|B1 C1) p(A3|B1 C1)


p(A1|B1 C2) p(A2|B1 C2) p(A3|B1 C2)


p(A1|B1 C3) p(A2|B1 C3) p(A3|B1 C3)


p(A1|B1 C4) p(A2|B1 C4) p(A3|B1 C4)


p(A1|B2 C1) p(A2|B2 C1) p(A3|B2 C1)


p(A1|B2 C2) p(A2|B2 C2) p(A3|B2 C2)


p(A1|B2 C3) p(A2|B2 C3) p(A3|B2 C3)


p(A1|B2 C4) p(A2|B2 C4) p(A3|B2 C4)


Fabio Gagliardi Cozman
1998-08-13