Instruction for evaluation of HWEd

Below the roadmap of the evaluation process is presented. Detailed description of tasks will be given in the following sections.

  1. Read an article on HMR notation used in HWEd and HQEd editors presented below.
  2. Having in mind the tutorial, try to create the same model as presented therein, but instead of using plain text, use:
    1. HWEd editor
    2. HQEd editor
  3. Fill in the questionnaire for:
    1. HWEd editor
    2. HQEd editor

Introduction to HMR and XTT2 syntax

Use case

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 final model should look like in the Figure below. Your task will be to create the same model in HQEd and HWEd editors.

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.

Attributes and Types

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:

  • hour (0 to 23)
  • day type (weekend/workday)
  • day (Monday to Sunday) which will be used to determine day type
  • location or zone (pay zone / free zone)
  • tariff (pay / free)

There is also one additional attribute that can be considered as a final attribute that determines the action for the system:

  • notification (free to park / pay for parking)

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 *.hmr file:

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
].

The name and abbrev entries are self-explanatory. The type entry defines the type of the attribute (in this case it is a hour_type defined by us previously). The class entry says if the attribute can take a single value at a time (simple) or is it allowed to take set values (generalised). Finally, the comm entry defines the type of the attribute. The attribute can be in,out or 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

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 pay or free The tariff depends on the current hour and 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 tariff and location will look as follows:

xschm parkingReminder: [location,tariff] ==> [notification].

Rules

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

The 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 simple and generalised attributes. The list can be found in HMR grammar page.

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 # sign. More about the certainty factors can be found in Managing uncertainty with certainty factors algebra tutorial.

Evaluation task

This task does not require form you any knowledge engineering skills. It aims at measuring the usability features of the two editors, so your work will be completely reproductive in terms of building knowledge base.

Having in mind the tutorial, try to create the same model as presented in the figure at the beginning of the web page, but instead of using plain text, use HWEd and HQEd editors.

The models that need to be recreated with aforementioned editors are presented below:

Instructions for running the editors are presented below.

HWEd editor

To launch HWEd, open http://glados.kis.agh.edu.pl/hwed in your internet browser.

HQEd editor

To launch the HQEd editor, install VierualBox and import following virtual device int your VBox: HQEd.ova Run the virtual machine. In console type:

cd hqed
./hqed

Alternativelly you can build it on your own. To do this, type in your commandline:

sudo apt-get install git qt4-default  qt4-qmake libqt4-dev sqlite3 libsqlite3-dev libqt4-sql-sqlite
git clone https://bitbucket.org/sbobek/hqed
cd hqed
qmake && make
./hqed

Evaluation surveys

Fill in the questionnaire for

  1. Web editor (HWEd): go to Online Form
  2. Desktop editor (HQEd): go to Online Form
prv/phd/sbk/hqtest/start.txt · Last modified: 2016/12/28 06:20 by sbk
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0