prv:phd:sbk:hqtest:start [GEIST Research Group]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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.
  - Read an article on HMR notation used in HWEd and HQEd editors presented below.
  - Having in mind the tutorial, try to create the same model as presented therein, but instead of using plain text, use:
    - HWEd editor
    - HQEd editor
  - Fill in the questionnaire for:
    - HWEd editor
    - 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

<code>
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.
</code>

The final model should look like in the Figure below. Your task will be to create the same model in HQEd and HWEd editors.

{{:prv:phd:sbk:hqtest:parking-zones-1.png|}}

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:
<code>
xtype [
  name: hour_type,
  domain: [0.000 to 23.000],
  base: numeric
].
</code>
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**:
<code>
xtype [
  name: day_type,
  domain: [mon/1,tue/2,wed/3,thu/4,fri/5,sat/6,sun/7],
  ordered: yes,
  base: symbolic
].
</code>
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:
<code>
xattr [
  name: hour,
  abbrev: h,
  type: hour_type,
  class: simple,
  comm: in
].
</code>

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 [[http://glados.kis.agh.edu.pl/doku.php?id=pub:software:heartdroid:tutorials::callbacks| callbacks mechanism]].

Similarly, the definition of a day attribute should look as follows:
<code>
xattr [
  name: day,
  abbrev: d,
  type: day_type,
  class: simple,
  comm: in
].
</code>


==== 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:
<code>
xschm tariff: [hour, daytype] ==> [tariff]
</code>

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:
<code>
xschm parkingReminder: [location,tariff] ==> [notification].
</code>

==== 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 [[http://glados.kis.agh.edu.pl/doku.php?id=pub:software:heartdroid:documentation:hmr#rules|HMR grammar]] page):
<code>
xrule tariff/1:
  [
    hour in [10 to 19],
    daytype eq workday
  ]
  ==>
  [
    tariff set pay
  ].#1
</code>

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 [[http://glados.kis.agh.edu.pl/doku.php?id=pub:software:heartdroid:documentation:hmr#rules|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 [[http://glados.kis.agh.edu.pl/doku.php?id=pub:software:heartdroid:documentation:hmr#rules|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 [[http://glados.kis.agh.edu.pl/doku.php?id=pub:software:heartdroid:tutorials:uncertainty_cf|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:
  * The model created in HWEd: {{:prv:phd:sbk:hqtest:parking-zones-1.png?linkonly|Parking zones}}
  * The model created in HQEd: {{:prv:phd:sbk:hqtest:parking-zones-2.png?linkonly|Parking zones}}

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: [[http://glados.kis.agh.edu.pl/HQEd.ova|HQEd.ova]]
Run the virtual machine.
In console type: <code>
cd hqed
./hqed
</code>

Alternativelly you can build it on your own.
To do this, type in your commandline:
<code>
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
</code>



===== Evaluation surveys=====
Fill in the questionnaire for 
  - Web editor (HWEd): go to [[http://sumi.uxp.ie/hwed/|Online Form]]
  - Desktop editor (HQEd): go to [[http://sumi.uxp.ie/hqed/|Online Form]]