The Interchange Format for Bayesian Networks |
The goal of the current implementation is to agree on a format that can represent networks with discrete variables. Several extensions will be entertained for next releases of the format.
This document gives a brief overview of the basics of the proposed Interchange Format. Open issues are emphasized in bold font.
White spaces, tabs and newlines are ignored; the C/C++ style of comments (//... and multi-line /*...*/ comment sequences) are adopted. Two other characters are also ignored when they occur between tokens: "," and "|". These characters can be used to separate variables in the definition of a probability distribution.
The basic unit of information is a block: a piece of text which starts with a keyword and ends with the end of an attribute list (to be explained later). Arbitrary characters are allowed between blocks. This allows the user to insert arbitrarily long comments outside the blocks, and reserve the //, /* */, comments to be placed inside blocks. It also allows user-specific blocks and commands to be placed outside the standard blocks.
Other than blocks, the Interchange Format refers to three entities: words, non-negative integers and non-negative reals.
A word is a contiguous sequence of characters, with the restriction that the first character be a letter. Characters are letters plus numbers plus the underline symbol (_) plus the dash symbol (-).
A non-negative integer is a sequence of numeric characters which is not followed by a decimal point or an exponent. The first character of a non-negative integer has to be larger than zero. A non-negative real is a sequence of numeric characters, containing a decimal point or an exponent or both. Notice that there is no overlap between non-negative integer and reals; for example the sequence "88" is an integer but not a real, and the sequence "88.0" is a real but not an integer. Finally "088" is not an integer nor a real. These conventions roughly follow the Java language and are also used by many C compilers (should these conventions be changed?).
block-type block-name { attribute-name attribute-value; attribute-name attribute-value; attribute-name attribute-value; }with as many attributes as necessary. The closing semicolon is mandatory after each attribute.
There are three possible blocks: network, variable and probability blocks.
network Robot-Planning { property version 1.1; property author Nobody; }
variable Leg { type discrete[2] { long, short }; property temporary yes; }
probability ( Leg | Arm ) { table 0.1 0.9 0.9 0.1; }The blocks occur in the following order:
The attribute property can appear in all types of blocks. A property is just a string of arbitrary text to be associated with a block. Examples of properties:
property size 12; property name "Trial number ten";Any text is valid between the keyword property and the ending semicolon. 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.
The type attribute is specific to variable blocks. type lists the values of a discrete variable:
type discrete[ number-of-values ] { list-of-values };The number-of-values token is a non-negative integer which indicates how many different values this variable may assume (the size of the list-of-values). The list-of-values is a sequence of words, each one the name of a variable value. At this point continuous variables are not supported (should they be?).
There are attributes that are specific to probability blocks (these attributes are discussed in the next section):
probability(GasGauge | Gas, BatteryPower) { (yes, high) 0.999 0.001; (yes, low) 0.850 0.150; (yes, medium) 0.000 1.000; (no, high) 0.000 1.000; (no, low) 0.000 1.000; (no, medium) 0.000 1.000; }As explained before, the symbols "|" and "," are ignored between tokens so they do not affect the list of variables given after the keyword probability. The variables however must be enclosed by parenthesis.
The example above uses the entry attribute, which is different from the other attributes in that it has no keyword. It simply starts with an opening parenthesis, and has a list of values for all the conditioning variables. After the closing parenthesis, a list of probability values for the first variable is given (note the user must provide numbers that add to one but this is not mandatory).
The probability vectors can be listed in any order, since the names in parentheses uniquely identify the parent instantiation.
In addition to the entry attribute, the Interchange Format supports the concept of a default entry. So the above CPT could have been specified equivalently as:
probability(GasGauge | Gas, BatteryPower) { default 0.000 1.000; (yes, low) 0.850 0.150; (no, medium) 0.000 1.000; }Note that each number is a separate token, so we can use "," and "|" between numbers; these symbols are ignored.
Another way to define a probability distribution is through the table attribute. The body of such attribute is a sequence of non-negative real numbers, in the counting order of the declared variables (if all variables were binary, we would say binary counting with least significant digit in the right). So, for the example above, we could simply say:
probability(GasGauge | Gas, BatteryPower) { table 0.999 0.850 0.0 0.0 0.0 0.0 0.001 0.15 1.0 1.0 1.0 1.0; }
There are some subtle rules that regulate these declarations.
Noisy functions are characterized by the property that the probability vectors for each entry can be derived from the probability vectors of the parent instantiations. This proposal has not settled yet in a general format for noisy functions.
Currently the Interchange Format adopts the suggestion from the BNIF, noting that all that is necessary to reconstruct a noisy-or/max/sum is the name of the function and the probability that the child is true given that each parent singly is true. For example if there are four parents, each taking values 0 and 1, we need the rows for the instantiations 1 0 0 0, 0 1 0 0, 0 0 1 0, 0 0 0 1.
From the BNIF proposal:
Noisy functions are characterized by the property that the probability vectors for each combination of conditional variables can be derived from the probability vectors of the leak parent instantiation and the parent instantiations in which one and only one parent assumes a value different from its leak value. Conceptually, the leak parent instantiation represents the situation in which none of the parents is causing the child node to be in a abnormal state, and hence the probability vector associated with the leak instantiation models influences on the child node that are not explicitly accounted for the parents.
Currently, we suggest the use of a property "function" to insert information about the particular noisy function. For example:
probability(GasGauge | Gas, BatteryPower) { property function max; (0, 0): 0.999, 0.001; // leak term (0, 1): 0.850, 0.150; (0, 2): 0.000, 1.000; (1, 0): 0.000, 1.000; }Other formats for noisy-functions will be considered for implementation.
network Internal-Network{ //18 variables and 18 probability distributions } variable Alternator{ //2 values type discrete[2] { Ok Faulted }; property position = (47, 42) ; } variable FanBelt{ //3 values type discrete[3] { Ok Slipping Broken }; property position = (154, 42) ; } probability ( BatteryPower Charge BatteryState ) { //3 variable(s) and 8 values table 1 0 0 0 0 1 1 1 ; } probability ( GasInTank ) { //1 variable(s) and 2 values table 0.5 0.5 ; }
ftp ftp.cs.cmu.edu (login as anonymous) cd /afs/cs/project/lri-3/ftp/outgoing/JavaBayes/ binary get InterchangeFormat.tarYou have to use the cd command only once; you cannot cd into intermediate directories. Now use the tar utility to create the distribution from the InterchangeFormat.tar file. The distribution should have:
The bytecodes for the Test program should be in the Classes directory in the parser distribution. To run it as an application, go to that directory and run java Test. A frame will be created; you will be asked to insert the name of a file (with the path to it, if necessary). Then click the Load button, and the Test program will run the parser in the file. A BayesNet object will be constructed and displayed, and some basic checks will be made. If you see the word "Result" popping out followed by some numbers, the file was successfully read. Check the console to see the BayesNet object printed (if you are running an applet, open the Java console window from your browser). If there were problems with the file, a brief error message will be displayed in the Test program frame; check the console to get a more descriptive message.
To run Test as an applet, you will need a small piece of HTML to call the program. The file Test.html contains a minimal HTML document which calls the Test program.
The Test applet is displayed below. If you have a Java compatible browser you should see the Test program frame. Type the name of one of the files (at this point only server side files are allowed; you can choose between the examples dog-problem.bif, elimbel2.bif and car-starts.bif. Type one of these names and press the Load button. You will see messages indicating the files are fetched and read; to observe the full messages with the BayesNet objects, open the Java console in your browser.