The visual XTT2 model is represented by means of a human readable, algebraic notation, also called the XTT presentation syntax, or HeKatE Meta Representation (HMR).
The representation can be directly run by the HeKatE RunTime environment HeaRT.
HMR file is in fact a legal Prolog code that can be interpreted directly (number of custom operators are defined).
Therefore HeaRT prototype is implemented in Prolog and provides the implementation for number of inference solutions including the three described before.
HMR can be used to write rules directly, or it can be generated by the HQEd XTT2 editor from the visual XTT2 model.
The same rule-based knowledge can be serialized to XML-based HML.
See the HaDEs page for an overview.
Example
An example excerpt of HMR is given below:
xschm th: [today,hour] ==> [operation].
xrule th/1:
[today eq workday,
hour gt 17]
==>
[operation set not_bizhours].
xrule th/4:
[today eq workday,
hour in [9 to 17]]
==>
[operation set bizhours].
The first line defines an XTT table scheme, or header, defining all of the attributes used in the table.
Its semantics is as follows:
The XTT table th has two conditional attributes: today and hour and one decision attribute: operation.
This information is determined from the conceptual design phase using the ARD method.
Then two examples of rules are given.
The second rule can be read as:
Rule with ID 4 in the XTT table called th: if value of the attribute today equals (=) value workday and the value of the attribute hour belongs to the range (in) <9,17> then set the value of the attribute operation to the value bizhours.
HMR language
HMR language was created to provide simple and human-readable text representation for XTT diagrams. The HMR language is fully Prolog compatible, which means that it is interpreted directly by Prolog interpreter, without any additional parser.
The HMR file consists of the following elements:
Mandatory types definitions (predicate xtype)
Optional types groups definitions (predicate xtpgr)
Mandatory attributes definitions (predicate xattr)
Optional attributes groups definitions (predicate xatgr)
Mandatory schemas definitions (predicate xschm)
Mandatory rules definitions (predicate xrule)
Optional states definitions (predicate xstat)
Optional callbacks definitions (predicate xcall)
Optional actions definitions (predicate xactn)
Generated by verification plugin predicates containing verifications reports (predicate xhalv)
Generated by inference engine predicates containing information about system's states changes during inference process (predicate xtraj)
All HMR elements are described below. Following notation was introduced:
All mandatory fields are preceded by + sign
All optional fields are preceded by ? sign
If there is more than one possible value of the field following notation will be used {value1 | value2 | value3}; the notation means that the filed can take either value1, balue2, or value3.
%STRING% means a string in Prolog.
%NUMBER% means either integer or floating point number.
%LIST% means a list in Prolog
%CLAUSE% means any valid Prolog goal.
Types definitions
Types in HMR language are used to define kind, structure and domain for further attributes definitions. Type definition looks as follows:
xtype [ +name: %STRING%,
+base: {numeric | symbolic},
+domain: %LIST%,
?scale: %NUMBER%,
?ordered: {yes | no},
?desc: %STRING%].
name - a field that contains type's name
base - a field describing base of the type. It can be either numeric, or symbolic
domain - a filed that contains a list of all acceptable values for this type. For ordered symbolic domains, it is possible to assign weights to the values. For instance in the example below, every day has it's own number assigned, that allows referring to the values using this number instead of symbolic name. If a symbolic domain is marked as ordered, and there are no weights assigned explicitly to the domain's values, default numbering is assumed that starts from 1 and ends on n, where n is the number of elements in the domain.
scale - a field denoting precision for floating point numbers
ordered - a field indicating whether domain is ordered or not. Every numeric type has ordered domain by default.
desc - a filed containing longer description of the type
Type definition may look as follows:
xtype [ name: days,
domain: [mon/1,tue/3,wed/5,thu/7,fri/9,sat/10,sun/20],
ordered: yes,
desc: 'Days of the week'].
Attributes definitions
Attributes in HMR language denotes instances of defined types. Every attribute in the HMR language must have a type assigned. Only one type can be assigned to one attribute. Type definitions looks as follows:
xattr [ +name : %STRING%,
+class: {simple | general},
+type: %XTYPE_NAME%,
+comm: {in | out | inter | comm},
?callback: %LIST%,
?abbrev: %STRING%,
?desc: %STRING%].
name - a field contains attribute's name
call - a field that denotes weather the attribute is simple (represents simple values) or general (represents set values).
type - a field that contains a name of a type defined as xtype. This field denotes the attribute's type.
comm - a field that describes attribute's relation to the world. If the attribute is in it means that a value of it is supposed to be given by the user; if the attribute is out it means that the value of it should be presented to the user; if attribute is inter it means that its value is set by the system as a result of inference process, but it;s not relevant to the user; if the attribute is comm, it means that it's both in and out.
callback - a field that contains an information about which callback is supposed to be fired for the attribute. The list should look as follows:
[callback_name, [callback_parameters] ], where callback_name is a name of defined callback (see
callbacks_definitions), and callback_parameters is a list of parameters that the callback takes.
abbrev - a field that contains short name of the attribute.
desc - a field that contains longer description of the attribute.
Atribute definition may look as follows:
xattr [name: day,
abbrev: day,
class: simple,
type: days,
comm: in,
callback: [ask_console,[day]]].
Types and attributes groups definitions
Groups contain sets of attributes' or types' names. It is possible to refer to a group of attributes or types using group name instead of each type's or attributes name separately. Groups were designed for future use in HeaRT interpreter.
Groups definitions looks as follows:
xtpgr [ +name : %STRING%,
?abbrev: %STRING%,
+types: %LIST%
].
xatgr [ +name : %STRING%,
?abbrev: %STRING%,
+types: %LIST%
].
Schemas definitions
Schemas represents XTT tables in HMR language. However, they cannot be considered as entities filled with rows containing rules. Schema is only a representation of relation between attributes that rules falling into this schema realizes.
Definitions of schema looks as follows:
xschm +%STRING1%/?%STRING2% : +%LIST1% ==> +%LIST2%.
+%STRING1% - a field containing obligatory schema name
%STRING2% - a field containing an optional schema description,
+%LIST1% =⇒ +%LIST2% - represents relation that given schema describes. First list denotes attributes that are required to be known by the rules that falls in this schema, and the second list denoted attributes that values are calculate by the rules in given schema. For instance: [month] =⇒ [season].
An example of schema definitions may look as follows:
xschm ms: [month] ==> [season].
Rules definitions
Rules in HMR language are defined as follows:
xrule %STRING1%/%NUMBER%: %LIST1% ==> %LIST2% **> %LIST3% : %STRING2%.
%STRING1% - a field that contains name of the schema that the rule falls into.
%NUMBER% - a field that represents rule ID inside the schema
%LIST1% - contains a list of firing conditions for the rule. Each condition has to be valid ALSV(FD) expression of the form attribute_name ALSV_OPERATOR value
%LIST2% - contains decisions that has to be fired when conditions are true. Decision is of the form attribute_name set value
The value can be an expression including basic operators like (+,-,/,*) and functions like union, intersect, except
%LIST3% - contains list of actions with its parameters of the form [action_name, [action_parameters]]. Those actions are fired when rule's conditions are true. Actions cannot change system's state.
%STRING2% - is a schema (table) name that should be given a token when inference mode is set to Token-Driven.
An example of a rule definition is shown below.
xrule dt/1:
[day in [mon,tue,wed,thu,fri]]
==>
[today set workday]
**>
[tell_console,['Today is a workday']]
:th.
States definitions
State in HMR language is a set of attributes and corresponding values that describes system's status. State definitions looks as follows:
xstat %STRING%: %LIST%.
%STRING% - is a name of the state. Because each xstat record describes only one attribute's value, the name is not unique. If a system contains n attributes, that have to be described by HMR state, there have to be n xstat records - each for every attribute.
%LIST% - is always a two-elements list containing attribute's name and value.
An example of xstat record may look as follows:
xstat s1: [month, january]
Callbacks definitions
Callback is an operation that is fired at the certain point of inference process, and can change system's state. Callbacks are defined as follows:
xcall %STRING% : %LIST% >>> (%CLAUSE%).
%STRING% - is a callback name
%LIST% - is a list of variables that have to be unified with some values in order to reach a goal defined by %CLAUSE%
%CLAUSE% - is any Prolog code describing a goal.
An example of xcall record is shown below:
xcall ask_console : [AttName] >>> (write('Type value for attribute: '),
write(AttName),nl,
read(Answer),
alsv_new_val(AttName,Answer)).
Actions definitions
Action is an operation that is fired when rule's firing conditions are true. Actions cannot change system's state.
xactn %STRING% : %LIST% >>> (%CLAUSE%).
%STRING% - is a action name
%LIST% - is a list of variables that have to be unified with some values in order to reach a goal defined by %CLAUSE%
%CLAUSE% - is any Prolog code describing a goal.
An example of xactn record is shown below:
xactn tell_console : [AttName] >>> (write('Attribute '),
write(AttName),
write(' output value is '),
xstat(current:[AttName,V]),
write(V),nl).
Verifications reports
Predicates containing versification's reports are generated automatically by the HeaRT interpreter. Every record contains only one message generated by verification plugin. All messages generated during verification are grouped within a set of xhalv/1 predicates of the same ID (name).
Definition of xhalv/1 looks as follows:
xhalv %STRING% : %LIST%.
%STRING% - is an unique ID (or name of a set of xhalv records) that is automatically generated every time a verification process is fired.
%LIST% - is a message generated by the verification process. The list can look differently depending on which verification was performed:
contradiction: [rule_id, description], where rule_id is a rule that contradicts with other rule; a description is text message describing in details anomaly that was detected.
reduction: [rule_id, description], where rule_id is a rule that with other rule; a description is text message describing in details anomaly that was detected.
completeness: [description], where description is a text message describing in details anomaly that was detected.
Trajectory traces
Predicates containing trajectories of the system's inference process are automatically generated by the HeaRT and saved as xtraj/1. A single xtraj/1 record contains information about one inference process from the start until the end.
Definitions of xtraj/1 are build as follows:
xtraj %STRING% : %LIST%.