HeaRTDroid is a rule-based inference engine both for Android mobile devices, and desktop solutions
Imagine you need to model a rule-based system that will automatically turn on and off parking meter with your mobile phone. The system for paying for parking with mobile phone exist, so the only thing you need to do is to determine if someone parked the car in a pay zone, and send request to the system to trigger the payment. For the purpose of this tutorial we focus only on very (very) basic aspects of such model.
Several factors may have an impact on whether we should pay for parking or not. It depends on our localization: when you are not in a pay zone you will not have to pay for parking for sure. However, you may also not be charged a parking fee in a pay zone if you park during a weekend, or after business hours (this is how it is in Krakow, Poland).
So, the informal specification of the model should look as follows
If you are in free zone, then you do not pay If you are in pay zone and it is weekend, then you do not pay. If you are in pay zone and the hour is between 10 and 20 (not inclusive) and it is a workday, then you pay Otherwise you do not pay.
The XTT2 model build upon this specification could look as presented in Figure below.
The next sections will discuss in more details the stages which knowledge engineer has to follow in order to create such a model in HMR+ notation.
The full model can be downloaded here: Parking Model
You can try running the inference by providing manually values of these attributes with HaQuNa commandline shell. The comman for running the inference can look as follows:
java -cp haquna.jar:. haquna.HaqunaMain --model urban-helper-easy.hmr \ --tables ['parkingReminder'] --inference gdi \ --initial-state [day=mon,hour=14,location=pay_zone]
For more information on how to configure the inference process, see Configuring inference process tutorial.
Looking at the informal specification presented in previous section one can think on several attributes that should be used to build a model. These are:
There is also one additional attribute that can be considered as a final attribute that determines the action for the system:
The attributes listed above were given possible values in round brackets. This possible values are called domains in HMR+ and are determined by types.
Determining attributes and types, together with their domains should be the first phase of modelling process.
Taking all of the above we can distinguish six types, each assign to separate attribute (this is not always like that – attributes may share types).
We create a type in HMR+ using xtype keyword.
For instance to create type for hour we would put the following code in our
xtype [ name: hour_type, domain: [0.000 to 23.000], base: numeric ].
It says that the name of he type is
hour_type, it is a numeric type (so the values should be treated as numbers, not strings) and the domain is from 0 up until 23 (these are the allowed values for the attribute that will have this type assigned).
Numeric types are by default floating point numbers.
We can do the same for the remaining types. Take for instance type for attribute day:
xtype [ name: day_type, domain: [mon/1,tue/2,wed/3,thu/4,fri/5,sat/6,sun/7], ordered: yes, base: symbolic ].
The above definition says that this is the symbolic type, so its domain consists of nominal values.
However, it also provides an information that the type is ordered.
It means that we can refer to the elements of the domain providing their ordering numbers.
For instance instead of typing mon for Monday, you can use ordering number assigned to it.
This also allows you to define ranges of nominal values, for instance
[mon to fri] or
[1 to 5].
Once all the types are defined one can start defining attributes. This is done in HMR+ with xattr keyword. For instance a definition of a hour attribute should look as follows:
xattr [ name: hour, abbrev: h, type: hour_type, class: simple, comm: in ].
abbrev entries are self-explanatory.
type entry defines the type of the attribute (in this case it is a
hour_type defined by us previously).
class entry says if the attribute can take a single value at a time (
simple) or is it allowed to take set values (
comm entry defines the type of the attribute.
The attribute can be
inter, which plays a role when using callbacks mechanism.
Similarly, the definition of a day attribute should look as follows:
xattr [ name: day, abbrev: d, type: day_type, class: simple, comm: in ].
Schemas define dependencies between attributes that provide skeletons for rules. In other words schemas define headers of XTT2 tables.
Looking at the informal specification presented at the beginning of the tutorial, we would like to have rules that will determine whether current tariff is
tariff depends on the current
daytype, therefore the schema describing this relation will look as follows:
xschm tariff: [hour, daytype] ==> [tariff]
The schema is defined with xschm keyword, followed by the name of the schema. After that the two sets are given in square brackets: first denotes the attributes that will be later used as rules' conditions, the second denotes attributes that will be used in rules' conclusions in this particular schema.
Similarly, the schema that will determine the value of a
notification attribute that depends on the
location will look as follows:
xschm parkingReminder: [location,tariff] ==> [notification].
Rules in HMR+ notation encodes knowledge. Every rule has to be assigned to exact one schema and cannot use other attributes in its conditional and decision parts other than specified by the particular schema.
Rules are created with xrule keyword.
For instance one of the rules that determine the
tariff (therefore is part of
tariff schema) could look as follows (the complete and more formal definition of rule can be found in HMR grammar page):
xrule tariff/1: [ hour in [10 to 19], daytype eq workday ] ==> [ tariff set pay ].#1
tariff/1 is a name of the rule that specifies the schema to which the rule is assigned and its position in the XTT2 table.
Later the list of conditions is given.
Every condition is of the form of
attribute operator value.
There exist two separate lists of operators for
The list can be found in HMR grammar page.
Furthermore, the operators can be time-parametrised to allow capture dynamics of the procesess.
For more details on the time-based operators see Time-based operators andStatistical operators tutorials.
After the list of conditions followed by
==> (then) operator, there goes the list of conclusions of the form
attribute set value/expression.
The expression should be a value from the attribute's domain, or more complex expression involving mathematical and statistical operators and functions.
The list of admissible expressions for the conclusion can be found in HMR grammar page.
Finally, at the end there is a certainty factor value assigned to the rule.
It denotes the confidence of the rule.
The certainty factor is proceeded with
More about the certainty factors can be found in Managing uncertainty with certainty factors algebra tutorial.