FO[ID]¶
Goal¶
The goal of FO[ID] is to allow defining concepts in terms of other concepts, in a modular way. The definition can be inductive. ID stands for “Inductive Definition”.
Lexicon¶
Token 
Pattern 
Example 

DEF 


FORALL 

Syntax¶
FO[ID] adds these production rules:
Assertion ← { ANNOT } '{' Rule { Rule } '}';
Rule ← { ANNOT } { FORALL Quantee {',' Quantee} ':' }
Head [ DEF Expression ] '.';
Head ← NAME_S '(' [ Expression {',' Expression } ] ')'
[ '=' SumMinus ];
Wellformedness¶
The
Variable
occurring in a rule must be in the scope of a quantifier that declares it. The scope of the quantifiers in the head of aRule
is the whole rule.NAME_S
must have been declared in the vocabulary.The number and types of
Expression
applied toNAME_S
must match its type signature.The
=
sign must occur in rule whereNAME_S
has been declared as a nonboolean function. The type of theExpression
after=
must be the same as the type ofNAME_S
.The
Expression
afterDEF
must be boolean.
Semantics¶
An inductive definition specifies a unique interpretation for a predicate (or function) symbol, given the interpretation of its parameters. The parameters of a definition are the symbols that occur in it (by contrast, the tuple of arguments are the values applied to its symbol).
The semantics of a predicate definition is the wellfounded semantics [Den00].
When the predicate is welldefined, i.e., the definition is not a paradox like { p() ← ¬p(). }
,
the definition can be seen as the description of a constructive process.
The construction process starts with an empty relation, i.e., the predicate is false
for any tuple of values.
Whenever the body of a rule (i.e. the Expression
after DEF
) is true
, the tuple of values in the header is added to the relation.
The process continues until a fix point is reached, i.e., no tuple of values can be added to the relation.
The construction process is similar for a function.
The process starts with the function being undefined for every tuple of arguments.
Whenever the body of a rule is true
, the mapping of tuple of arguments to a value described in the header
is added to the function interpretation.
The process continues until a fix point is reached, i.e., no mapping can be added to the function interpretation.
The knowledge engineer should make sure that a defined function is defined over its whole domain, i.e., that the rules are such that the function is defined for every tuple of arguments in its domain, and for any interpretation of the parameters of the definition. He should also make sure that the rules of a function definition are not conflicting. Conflicting rules specify 2 different values for the same tuple of arguments. A reasoning engine may help him satisfy these requirements.
Examples¶
[Definition of convex]
{ convex() ← [All angles are below 180°]
∀n ∈ Side_Nr: angle(n)<180. }
angle
is a parameter of the definition of convex
.
convex
is a nullary predicate: it does not take any argument.