MLN Syntax

General conventions

• All constant symbols that aren't integers must begin with an upper-case letter
• Domain symbols must begin with a lower-case letter
• Identifiers may contain only alphanumeric characters, "-", "_" and "'"

MLN Files

An MLN file may contain:

• Comments
  C++-style comments are admissible, i.e. // this is a comment and /* this comment may span multiple lines */

• Domain declarations
  to assign a set of constants to a particular type/domain
  e.g. domFoo = {A, B, C}

• Predicate declarations
  to declare a predicate and the types/domains that apply to each of its arguments\
  e.g. myPredicate(domFoo, domBar)
  A predicate declaration may coincide with a rule for mutual exclusiveness and exhaustiveness (see below).

• Rules for mutual exclusiveness and exhaustiveness
  to declare that for a particular binding of some of the parameters of a predicate, the value assignments of the remaining parameters are mutually exclusive and exhaustive, i.e. that the remaining parameters are functionally determined by the others.
  For example, you can add the rule myPredicate(domFoo, domBar!) to declare that the second parameter of myPredicate is functionally determined by the first (i.e. that for each binding of the first parameter, there is exactly one binding of the second for which the predicate is true).

• Formulas with attached weights
  as constraints on the set of possible worlds that is implicitly defined by an MLN's set of predicates and a set of (typed) constants with which it is combined.
  A formula must always be specified either along with a weight preceding it or, in case of a hard constraint, a period (.) succeeding it.
  Usually, a weight will be specified as a numeric constant, but when using PyMLNs, weights can also be specified as arithmetic expressions, which may contain calls to functions of the Python math module (and the special function logx which returns -100 when passed 0). Note, however, that the expression must not contain any spaces. For example, you could specify an expression such as log(4)/2 instead of 0.69314718055994529.

  The formulas themselves may make use of the following operators/syntactic elements (operators in order of precedence):

  • existential quantification, e.g. EXIST x myPred(x,MyConstant) or EXIST x,y (myPred(x, y) ^ foo(y)). Quantification applies only to the formula that follows immediately after the list of quantified variables, so if it is a complex formula, enclose it in parentheses.
  • equality, e.g. x=y
  • negation, e.g. !myPred(x,y) or !(x=y)
  • disjunction, e.g. myPred(x,y) v myPred(y,x)
  • conjunction, e.g. myPred(x,y) ^ myPred(y,x)
  • implication, e.g. myPred(x,y) ^ myPred(y,z) => myPred(x,z)
  • biimplication, e.g. myPred(x,y) <=> myPred(y,x)

  When a formula that contains free variables is grounded, there will be a separate instance of the formula for each grounding of the free variables in the ground Markov network (each having the same weight).
  Note that while ProbCog's inference mechanisms may perform a CNF conversion of the formulas, they do not not decompose the CNF formulas if they are made up of more than one conjunct in order to obtain individual clauses. In ProbCog, all formulas are indivisible (in contrast to the Alchemy system, for example).

• Formula templates

  • Literal variants
    An atom in a formula can be prefixed with an asterisk (e.g. *myPred(x, y)) to define a template that stands for two variants of the formula, one with the positive literal and one with the negative literal.
  • Constant-specific formula variants
    A variable that is an argument of an atom can be prefixed with a + character (e.g. myPred(+x,y)) in order to define a template that will generate one formula for each possible binding of that variable to one of the domain elements applicable to that argument.

• Probability constraints on formulas (PyMLNs only)

  ProbCog supports two types of probability constraints on formulas. Any formulas for which a constraint is specified must also be part of the MLN (i.e. you must add them to the MLN, with some weight).

  Note: Probability constraints are extensions of the original MLN formalism.

  • Prior probability constraint, e.g. P(myPred(x,y)) = 0.75 or P(myPred(x,y) ^ myPred(y,x)) = 0.9

    You may want to require that certain formulas have a fixed prior marginal probability regardless of the size of the domain with which a model is instantiated. This is accomplished by dynamically adjusting the weight of the formula when instantiating a ground Markov network.

  • Posterior probability constraint, e.g. R(myPred(X,Y) v myPred(Y,X)) = 0.8

    You may want to require that the posterior marginal probability of a ground formula be fixed. This essentially corresponds to a specification of soft evidence (see below)

Limitations

• No support for functions, numbers/numeric operators or anything that is related to it
• Formulas must always be preceded by a weight or be terminated by a period, even if they are only to be used in an input MLN for parameter learning
• No definition can span multiple lines

Database/Evidence files

A database file may contain:

• Comments (C++-style, as above)
• Positive and negative ground literals, e.g. myPred(A,B) or !myPred(A,B)
• Soft evidence on ground atoms, e.g. 0.6 myPred(A,B)
  Note that soft evidence is supported only by PyMLNs and only when using an inference or learning algorithm that supports soft evidence (e.g. MC-SAT, which corresponds to MC-SAT-PC when using soft evidence) and IPFP-M.
  Note that soft evidence on non-atomic formulas can be handled using posterior probability constraints (see above).
• Domain extensions Specified using the same syntax as domain declarations (see above); useful if you want to define constants without making any statements about them.