- 1.1 Network description
- 1.2 Nodes description
- 1.3 Links description
- 1.4 Relations description
- 1.5 Representation of numerical information in relations

The Elvira specification format allows to represent different kind of networks in a file (normally with extension .elv). These networks are related with the treatment of uncertainty in artificial intelligence. It can represent a general Network, Bayesian network, an Influence Diagram. In general, a network will contain a set of nodes, a set of links and a set of relations among the nodes. Nodes can have a finite number of possible states or they can have a continuous domain. Each relation express normally numerical information for a set of nodes of the network, but it is possible to have a relation without any numerical information. Numerical information can be represented in different ways. For example, by means of a table, a tree, a function, etc. A relation can be representing a conditional probability distribution, a convex set of conditional probabilities, an utility function in an Influence Diagram, etc.

An elvira file (see production rule Elvira) has two parts:

- The head: it describes the kind and the name of the network we are defining. See production rules NetworkDeclaration and NetworkClass.
Currently we admit the following kinds of networks:

*Network*: The elvira file represents a general network. In this case the file begins with`network`

.*Bayesian network*: The elvira file represents a Bayesian network. In this case the file begins with`bnet`

.*Influence diagram*: The elvira file represents an influence diagram. In this case the file begins with`idiagram`

.

- The body: it describes the different elements of the network. See production rule NetworkContent

Within the body of the network there are four basic parts in an elvira file.

- Network description: This section contains general information about the network and the other sections.
- Nodes description: It contains properties for each one of the nodes of the network.
- Links description: It contains properties for each one of the link of the network.
- Relations description: It contains properties for each one of the relations of the network.

As an example of the elvira format we can see a file containing a Bayesian network:

bnet Asia { title="Red bayesiana para el diagnostico de cancer metastasico"; comment="Es el ejemplo mas famoso de red bayesiana"; author="Greg Cooper"; whochanged="Equipo Proyecto Elvira"; whenchanged="22/04/98"; default node states=(ausente presente); node Cancer { title="Cancer metastasico"; comment="Indica si se da la enfermedad o no"; } node Calcio { title="Elevacion del calcio serico"; states=(normal elevado); } node Tumor { title="Tumor cerebral"; states = (presente ausente); } node Coma; node Jaquecas; link Cancer Calcio; link Cancer Tumor; link Calcio Coma; link Tumor Coma; link Tumor Jaquecas; relation A { comment = "Prevalencia del cancer metastasico"; kind-of-relation=conditional-prob; values= table (0.2 0.8 ); } relation B A { values= table (0.8 0.2 0.2 0.8 ); } relation C A { values= table (0.05 0.2 0.95 0.8 ); } relation E B C { comment = "Tanto la elevacion del calcio serico como el tumor cerebral pueden producir coma"; values= table(0.2 0.95 0.2 0.2 0.8 0.05 0.8 0.8); } relation D C { values= table (0.8 0.6 0.2 0.4 ); } }

1.1 Network description

*Property*: It describes general information about the network such as the author name, a title, current version, etc. There are several predefined properties, but on an elvira file each property is optional to appear. Actually the properties (see production rule Property) accepted in the Elvira Format are:*title**comment**consistency*: still not functional*author**whochanged**whenchanged**locked**version*`<WORD><EQUAL>(<BOOLEAN>|<WORD>|<STRING>|<STRING_DECIMAL>|<DECIMAL_LITERAL>)`

:*User defined network property*(still not functional).

*Default and Every Declarations*: A*default declaration*gives the value that takes a property for one element of the network (node, link or relation) by default (when it is not specified within its definition). For example, the following lines are default declarations:default relation kind-of-relation=conditional-prob; default node states=(ausente presente); default node(finite-states) states=(ausente presente);

First line express that a relation is by default of kind

`conditional-prob`

, and second line express that the states of a node (type`finite-states`

) are by default`ausente`

and`presente`

(but this declaration is only admissible if now the default node type is`finite-states`

, because only finite-state nodes have the property`states`

. Third line express the same thing as second line but now this can be used whatever the default type node is.Also a

*default declaration*can specify that a node belong by default to a given class (a node is by default continuous or finite states). For example, next line express that nodes are by default of type`continuous`

:default node type-of-variable = continuous;

An

*every declaration*gives the value that must take a property for all the elements of the network. Also, an*every declaration*can specify that all elements belong to a given class (for example all nodes must be continuous or finite states). See production rule DefaultDeclaration.**Note**:*every declarations*still are not functional.A

*default declaration*or an*every declaration*only affect from the point it appears in the file to the end of the file, unless the same property is changed again with a new*default*or*every*declaration.

*Element Declaration*: There are tree kinds of elements (see production rule ElementDeclaration)in an elvira file: nodes, links and relations.

1.2 Nodes description

`finite-states`

: A`finite-states`

node is a node with a discrete number of possible states.`continuous`

: A`continuous`

node is a node with a continuous domain.

`node`

followed by the `name`

of the node and a declaration that determines the type of node we have. This last declaration can be one of the following three:
`DefaultNodeDeclaration(T)`

(see production rule DefaultNodeDeclaration): This declaration express that the node is of the default node type. Initially, the default node type is`finite-states`

, but this default node type can be changed using a`DefaultDeclaration`

(see production rule DefaultDeclaration). For example, the following lines contains the declaration of the node`Calcio`

in this way:node Calcio { title="Elevacion del calcio serico"; states=(normal elevado); }

`FiniteDeclaration(T)`

(see production rule FiniteDeclaration): This declaration express that the node`Calcio`

is of`finite-states`

type. For example, the following lines contains the declaration of a node in this way:node Calcio(finite-states) { title="Elevacion del calcio serico"; states=(normal elevado); }

`ContinuousDeclaration(T)`

(see production rule ContinuousDeclaration): This declaration express that the node is of`continuous`

type. For example, the following lines contains the declaration of the node`VALOR`

in this way:node VALOR(continuous) { title = "Valoracion del proceso"; kind-of-node = utility; type-of-variable = continuous; pos_x =428; pos_y =405; relevance = 7.0; min = 0.0; max = 100.0; precision = 2; }

A node can contain a set of properties that describes it. The properties common to all type of nodes are the following (see production rule NodeProperty):

*title*:*comment*:*kind-of-node*(`chance`

,`decision`

or`utility`

)::`pos_x`

:`pos_y`

*relevance*:`<WORD><EQUAL>(<STRING>|<STRING_DECIMAL>|<DECIMAL_LITERAL>)`

:*User defined node property*(`<DECIMAL_LITERAL>`

is still not functional).

When we declare a node in an elvira file, then all its properties are initialized with his default value. There are two default nodes, the *default finite states node* and the *default continuous node*. See next sections to know the values of the properties of these default nodes.

Production rule FiniteBody tell us that the body of a finite states node can contain a set of finite node properties (`FiniteNodeProperties`

). Finite states node properties (`FiniteNodeProperties`

) are defined by production rule FiniteNodeProperties. This last production tell us that a finite states property can be a general node property (described in previous section) or a specific finite states property (see production rule FiniteProperty). Specific finite states properties are the following:

`states = "(" ListWords() ")"`

`type-of-variable = finite-states`

`num-states = <DECIMAL_LITERAL>`

(still not functional)

The states of a node can be defined as in the following examples:

`states = (absent, present)`

A list of words without quotes.`states = ("amp-wa", "mv=8")`

A list of words with quotes. We need this form when the words contain characters as`"/"`

,`","`

,`"{"`

,`"}"`

,`"["`

,`"]"`

,`"("`

,`")"`

,`"="`

,`";"`

,`"|"`

,`"*"`

,`"`

"+,`"-"`

.`states = (2 4 6)`

A list of decimal numbers.`states = (true false)`

Two boolean values.

When we use a decimal number for the name of one state, then this name must be enclosed with quotes when used in a relation. For example, in the next example the names of states must be enclosed with quotes in the relation:

node A(finite-states) { states = (1 3); } relation A { values = table ( ["1"]= 0.3; ["3"]= 0.7; ); }If you do not use quotes for the names of states in the relation then you could define an erroneous relation. In a relation, a decimal number without quotes means the state number for that node begining with . For example, previous relation could be defined, too:

node A(finite-states) { states = (1 3); } relation A { values = table ( [0]= 0.3; [1]= 0.7; ); }

The order in which we specify the states of a finite states node can be important to specify the values of a relation for the node with a TableDeclaration. This is so when a value in such relation is specified whithout specifing the state of the node. For example:

node Calcio{ states = (low hight); } relation Calcio{ values=table (0.3 0.7); }

Previous declaration does not defined the same relation as the following:

node Calcio{ states = (hight low); } relation Calcio{ values=table (0.3 0.7); }

See production rule TableDeclaration for details.

Initially, the default finite states node takes the following values for its properties:

- General properties:
`title`

:`""`

`comment`

:`""`

`kind-of-node`

:`chance`

`pos_x`

: 0`pos_y`

: 0`relevance`

: 7.0

- Specific finite states properties:
`states`

=`(absent,present)`

`type-of-variable`

=`finite-states`

`num-states`

= 2

Production rule ContinuousBody tell us that the body of a continuous node can contain a set of continuous node properties (`ContinuousNodeProperties`

). Continous node properties (`ContinuousNodeProperties`

) are defined by production rule ContinuousNodeProperties. This last production tell us that a continuous property can be a general node property (described in section 1.2) or a specific continuous property ((see production rule ContinuousProperty). Specific continuous properties are the following:

`type-of-variable = continuous`

`min=<DECIMAL_LITERAL>|<INTEGER>|<FLOAT>|<FLOATSCI>`

`max=<DECIMAL_LITERAL>|<INTEGER>|<FLOAT>|<FLOATSCI>`

Initially, the default continuous node takes the following values for its properties:

- General properties:
`title`

:`""`

`comment`

:`""`

`kind-of-node`

:`chance`

`pos_x`

: 0`pos_y`

: 0`relevance`

: 7.0

- Specific continuous properties:
`type-of-variable = continuous`

`min=0.0`

`max=1.0`

1.3 Links description

*Undirected*links*Directed*links

Production rule LinkDeclaration express that the declaration of a link begins with the reserved work `link`

, followed by the name of the two nodes this link joins. Optionally we can have a set of properties (see production rule LinkProperties) describing the link.

Currently elvira format allows the following link properties (see LinkProperty):

`directed=<BOOLEAN>`

: To specify if the link is directed or undirected.`comment=<STRING>`

: To append a comment to the link.

When a new link is found in an elvira file, it takes the value of its properties from the *default link* unless the property is explicitly changed in the definition of the link. *Default link* takes the following values for its properties:

`directed=false`

`comment=""`

For example a declaration of an undirected link between the nodes `Calcio`

and `Cancer`

could be:

link Calcio Cancer{ directed=true }

The value of one property of the *default link* can be changed using a *default declaration* (see section 1.1).

1.4 Relations description

`value`

(see bellow). A potential can represent a conditional probability distribution, an a priori probability distribution, a convex set of probabilities, an utility function, a density function for a continuous variable, etc. Potentials can be represented by means of tables, trees and functions.
Production rule RelationDeclaration express that a relation begins with the reserved word `relation`

followed by the name of the nodes this relation relates. Optionally a set of properties can be attached to the relation (see production rule RelationProperties).

Currently elvira format accepts the following relation properties (see production rule RelationProperty):

`comment=<STRING>`

`active=<BOOLEAN>`

`name-of-relation=<WORD>`

`kind-of-relation= potential | conditonal-prob`

;`values =`

TableDeclaration`|`

TreeDeclaration`|`

ConvexSetDeclaration`|`

FunctionDeclaration`|`

ContinuousTreeDeclaration

When a new relation is found in an elvira file, it takes the value for its properties from the *default relation* unless the property is explicitly changed in the definition of the link. *Default relation* takes the following values for its properties:

`comment = ""`

`active = true`

`name-of-relation = ""`

`kind-of-relation = conditonal-prob`

`values = null`

The property `kind-of-relation`

express the kind of relation. Currently we have the following kinds of relations:

`potential`

: Express a function with a finite set of variables (finite states and continuous).`conditional-prob`

: It is also a function with a finite set of variables (finite states and continuous), but now it express a conditional probability distribution. This imply that numerical values of a variable, compatibles with every configuration of the parents of such variable, must add 1. In a Bayesian network all relations must be`conditional-prob`

.

`value`

describes numerical information in the
relation. Let see the different ways this numerical information can be represented:

1.5.1 Tables: TableDeclaration

`table`

and can take two formats (see TableDeclaration):

- A list of assignments (see ListAssignments): In this way we specify for each configuration of variables in the relation the numerical value associated to it. Configurations can be in any order. For example next relation is represent in this way:
relation Calcio Cancer { values=table ([elevado,presente]=0.7, [elevado,ausente]=0.3, [normal,presente]=0.2, [normal,ausente]=0.8); }

A ListAssignments can contain one DefaultAssignment. This default assignment specify a numerical value for all non specified configurations (**Note:**This is not functional yet). Example:relation Calcio Cancer { values=table ([elevado,presente]=0.7, [elevado,ausente]=0.3, default = 0.5); }

- A list of floats (see ListFloats): In this case we do not specify a configuration of variables for each numerical value. Numerical values appear directly. Now configurations are implicit. We suppose configurations of variables are ordered, considering right variable the lest meaningful variable. For example, previous relation can be represented in this way as:
relation Calcio Cancer { values=table (0.7 0.3 0.2 0.8); }

A TreeDeclaration begins with the reserved word `tree`

. Next we put reserved word `case`

and the name of the desired root variable, or a numerical value (in this case all configurations take this numerical value). Within the body of `case`

we specify the different cases the root variable can take. It is possible also to use DefaultAssignment as in tables
(TableDeclaration). Probability tree in figure 1 will appear in an elvira file as:

relation Coma Calcio Tumor { values=tree ( case Coma{ presente=case Calcio{ elevado=0.7; normal=case Tumor{ presente=0.8; ausente=0.05; } } ausente=case Calcio{ elevado=0.3; normal=case Tumor{ presente=0.2; ausente=0.95; } } } ); }

A convex set (see production ConvexSetDeclaration) begins with the reserved work `convex-set`

followed be a finite set of TableDeclaration. For example, next declaration defines a convex set with two extreme points:

relation Cancer { values=convex-set( table (0.2 0.8) table (0.3 0.7) ); }

Every table declaration (TableDeclaration) can take one of the two formats described in section 1.5.1. For example next declaration defines also a convex set with two extreme points:

relation ErrLowOutput { values=convex-set( table ( [True] = 0.05, [False] = 0.95, ) table ( [True] = 0.08, [False] = 0.92, ) ); }

relation n1 n2 n3 { values = function Normal( 0.7, 0.2); }Previous definition express that value for a given configuration of variables

`n1 n2 n3`

is obtained with the function `Normal`

, the two parameters (0.7 and 0.2 in this case) and the configuration of variables `n1 n2 n3`

.
Arguments of a *function* can be float numbers and other relations. When a relation is argument of a function in another relation, then it must be defined as non active (`active=false`

). Also, it is neccesary to give an unanimous identifier (with property `name-of-relation`

) to the argument relation when is defined. For example, next definitions represent a relation (`relation n1 n2 n3`

) with a relation (`relation n1 n2`

) as an argument:

relation n1 n2{ active = false; name-of-relation = name1; values = table { 0.2, 0.8, 0.3, 0.7} } relation n1 n2 n3{ values = function OneFunction(0.3, 0.8, name1); }

In this case the numerical value for a given configuration of variables of the relation is got evaluating in first place the argument relations. When we evaluate an argument relation for the given configuration of variables, we obtain a float number. Once we evaluate all argument relations then main relation can be evaluate obtaining again a float number.

Available functions are:

`AddNormIdf`

:`NormIdf`

:`IctNeo`

:`SumNormIdf`

:

where , and are continuous variables.

It is possible to have different functions depending on the values of some of the variables. For example, a function with only continuous variables could be:

where , and are continuous variables.

Another example where we have continuous and finite states variables could be:

A *continuous probability tree* is a tree where internal nodes can be labeled with finite states variables or continuous variables and leaf nodes are labeled with functions of the shape described in previous examples. Behaviour of internal nodes labeled with finite states variables is completly the same as in *discrete probability trees* (TreeDeclaration) (the node will have as many outgoing arcs as possible values the variable it represents has). Nodes labeled with a continuous variable will have as many outgoing arcs as discretization intervals we want to use for this continuous variable. For example, function in formula 2 is represented with the *continuous probability tree* of figure 2.

As another example, function in formula 3 is represented with the *continuous probability tree* in figure 3

A ContinuousTreeDeclaration begins with the reserved word `continuous-tree`

, followed by the body (BodyContinuousTree) of the continuous tree. The body can take two shapes:

- Declaration of a density function FinalCT. In this case the tree is only a leaf node (previous density function).
- Expansion of a node ExpansionCT. In this case the body of tree begins with the reserved word
`case`

followed by the name of the node to be expanded (finite states or continuous). Depending on the type of node:- If the node to be expanded is a finite states variable, then it follows a list of discrete options ListDiscreteOptions. This list contains the possible values the finite states variable can take. For each possible values a new body of continuous tree BodyContinuousTree appears.
- If the node is a continuous variable, then it follows a list of floats FloatsToVector, corresponding to the list of discretization points for such continuous variable. Previous list is followed by a list of continuous options ListContinuousOptions. Each continuous option ContinuousOption consists of an integer number (begining at 0) followed by a new body of continuous tree BodyContinuousTree. Previous integer numbers identify the interval of discretization of the continuous variable. First interval is identified with 0, second with 1, and so on.

Continuous probability tree of figure 2 (formula 2) will be represented in an elvira file with the following relation:

relation X1 X2 X3{ values= continuous-tree ( case X1(0.0,5.0,10.0) { 0=0.3 * exp(-0.2 X1 + 0.4 X2) + 0.7 * exp(0.4 X2 + 0.3 X3) + 0.4; 1=0.4 * exp(-0.3 X1 + 0.3 X2) + 0.6 * exp(0.7 X2 + 0.1 X3) + 0.1; } ); }

Continuous probability tree of figure 3 (formula 3) will be defined with the following relation in an elvira file:

relation X1 X2 X3 X4{ values= continuous-tree ( case X4{ yes=case X1(0.0,5.0,10.0) { 0=0.3 * exp(-0.2 X1 + 0.4 X2) + 0.4; 1=0.4 * exp(-0.3 X1 + 0.3 X2) + 0.1; } no=0.6 * exp{0.7 X2 + 0.1 X3} + 0.1 } ); }