Call Assistant Policy

We will present a call assistant for Ralf, a "Conscientious employee".

Requirements

Ralf wants to train his personal assistant to manage his calls. He wants him to use one out of three options. The first is to allow the phone to ring, the second is to deny the call without an explanation and the the third is to deny the call, explaining, however, the reason for doing so. In general he chooses the first option over the other two. If he is at work, however, that is a reason to deny the call (with or without explanation). When family or friends call he prefers to deny the call with an explanation over denying the call without explanation. When he is at work he prefers to allow family calls over denying them with or without explanation, except when he is in a meeting, when he prefers to deny with explanation over allowing the call. Being in a meeting there is a possibility to prefer to accept a call from his son when he is at school. He will accept it if he believes that his son is ill, otherwise (if he believes that he is not ill) he will prefer to deny the call with an explanation.

Define the alternative options

This task defines the different options of the application problem, given in predicate format with all the relevant parameters. The conflict relation between options is also defined here. The relevat text from the requirements is:

...The first is to allow the phone to ring, the second is to deny the call without an explanation and the the third is to deny the call, explaining, however, the reason for doing so...

In this case he has three options, one is to accept the call, the second to deny the call and the third to deny the call providing an explanation. He launches the Gorgias-B App and selects File->new project. He selects a filename, e.g. ManageCalls3.pl (do not forget the .pl extension) and then the tool automatically launches the Options panel. There he adds the allow option predicate with the parameter Call (see the text boxes on the top of the Figure 1 below). Then, he presses the button "Create option". He does the same for the other options. The options are added in the "Options" list:

• allow(Call)
• deny_with_explanation(Call)
• deny_without_explanation(Call)

Then, he needs to tell the system that these options are incompatible. To do that, he selects the two options in the two combo-boxes in the "Incompatible options" area of the panel and then clicks on the button "Add". Now, he should be able to see the screen in Figure 1.

Figure 1. The Options panel

Define relevant information

The task is a knowledge engineering task required to identify the knowledge needed in order to describe the different application environments which can arise in the application problem domain. This knowledge is inserted in the form of various belief predicates. Beliefs can be decomposed, although not necessarily, into Defeasible and Non-Defeasible beliefs and some of the defeasible beliefs can be designated as abducible beliefs. The non-defeasible part also contains predicates that are used to type all object parameters of the problem that appear in the option and belief predicates. Moreover, we can define any background interrelationships that might exist amongst the non-defeasible predicates generating the background theory in a separate file.

Ralf needs to define non-defeasible predicates for facts regarding calls, such as a business call, a call from his boss, a call from the family or his son. Moreover, he can add contextual facts that are indisputable such as whether he is at work, or in a meeting, or whether his son is at school. He can add this information by the "Edit" menu and the "Non-defeasible knowledge" menu item (see figure 2 below). The "Facts View" allows to insert the predicates with their parameters in parenthesis. Using the "Defeasible knowledge" menu item and the "Beliefs View" he can add defeasible knowledge, i.e. in this case whether his son is ill or not. It is an atom without parameters and by clicking on the "belief is abducible..." check box the system will be able to assume that his son is ill or its negation, i.e. that his son is not ill. We will see later how we can use such knowledge.

Note that this step is optional, he can add the predicates later, when arguing. However, it is strogly recommended to follow this SoDA step along with the following, for sorting the circumstantial facts from general to specific contexts. This will greatly aid the modeler later when trying to decide what supporting information to add to his preferences. The following part of the requirements helps Ralf identify the knowledge that is relevant to his decision making process:

...If he is at work ? When family or friends call ? when he is in a meeting ? call from his son when he is at school? he believes that his son is ill.

Facts (non-defeasible knowledge):

• at_work
• family(Call)
• friends(Call)
• in_meeting
• from_son(Call)
• son_at_school

Belief (defeasible knowledge):

• son_is_ill

Figure 2. Adding beliefs

At this time he can import an existing prolog source file that aids in defining the non-defeasible beliefs. For example he wants to import a background file (backgroundRalf.pl) with the following info:

business(Call) :- from_boss(Call).
family(Call) :- from_son(Call).
familyOrFriends(Call) :- family(Call).
familyOrFriends(Call) :- friends(Call).

He can do that using the File->Import Prolog file dialog.

Finally, he needs to have a clear view on the contexts hierarchy. He will use this hierarchy in the next tasks (for example a call from his son is more specific context than a call from his family).

Contexts (General -> Specific):

1. at_work
2. family(Call), friends(Call)
3. in_meeting
4. from_son(Call), son_at_school
5. son_is_ill

Define the arguments

This task begins the process of capturing the application requirements. It aims to define for each option, the different problem environments, i.e. the sets of preconditions in terms of non-circumstantial predicates where the option is possible.

In figure 3 his arguments are presented. The first one is about generally allowing calls. He just selected the allow(Call) option from the combo box and clicked "Add argument". Likewise the other two are inserted in the arguments list.

Note that while he is building his argument he can see its status on the left of the "Add argument" button. If he no longer wants an argument he can select it and delete it using the "Remove selected argument" button. Such buttons exist in all panels and can be used to delete erroneous information or arguments. By clicking on the "Resolve conflicts" button he proceeds to the Argue view - see next topic.

Figure 3. Defining the arguments

Argue

This final task iteratively defines sequences of increasingly more specific partial models or scenarios of the world and considers how options might win over others. This starts with information from the arguments to precondition the world and iterates, getting each time more specific contextual information. At each level of iteration, it defines which option is stronger over another under the more specific contextual information. In the final iteration, the winning options (if they exist) for each partial model are defined without extra information.

The dialog starts at the 2nd level of arguing. The possible scenarios are the combinations of conflicting arguments of the previous level. Therefore there are three scenarios, one between the first and second argument, one between the second and the third argument, and one between the first and the third argument. The following requirements apply:

...In general, he chooses the first option over the other two. If he is at work, however, that is a reason to deny the call (with or without explanation)? When family or friends call he prefers to deny the call with an explanation over denying the call without explanation...

In the first scenario Ralf has to set his preference between denying without explanation and allowing a call. In general he prefers to allow the call, however, when he is at work he has reason to deny the call without explanation. Thus, he firstly selects the allow(Call) from the combo box on the right and then clicks the Add model button. The first preference is added to the list at the bottom of the View. Then, he selects the deny_without_explanation(Call) option and selects the at_work predicate from the combo box titles Select predicate. He reviews the preference below and as it is the one he wants he click the Add model button and the new preference is added to the list. Note that he can also add conditions. Conditions are expressions between variables and constants. Conditions can use the =, \=, =:=, <, =<, >=, > operators (prolog system predicates) with exactly one atom (grounded, Variable, number or string) on the left and one on the right hand side of the expression. In figure 4 the defined preferences are presented.

Figure 4. Arguing at the second level (1)

Ralf does the same for the second general scenario, where he has to set his preference between denying with explanation and allowing a call (see figure 5).

Figure 5. Arguing at the second level (2)

In the third general scenario Ralf needs to set his preference among denying with explanation and denying without explanation (see figure 6). He just knows that when it is from family or friends he prefers the first over the second. This is what he writes using the auxillary predicate familyOrFriends(Call).

Figure 6. Arguing at the second level (3)

Now he is finished with level 2. Then, he selects level 3 (from the combo box at the top of the view). The possible scenarios are the combinations of the premises of the preferences at the previous level. There are two scenarios where in both Ralf is at_work and in the first the options allow(Call) and deny_without_explanation(Call) compete, while at the second one the allow(Call) and deny_with_explanation(Call) compete. The relevant requirements are:

• ...If he is at work, however, that is a reason to deny the call (with or without explanation)...
• ...When he is at work he prefers to allow family calls over denying them with or without explanation...

The two scenarios preferences are shown in figures 7 and 8.

Figure 7. Arguing at the third level (1)

Figure 8. Arguing at the third level (2)

Level 4, scenario: at_work, family(Call)

Requirements:

• ...When he is at work he prefers to allow family calls over denying them with or without explanation...
• ...except when he is in a meeting, when he prefers to deny with explanation over allowing the call...

Again, we have two scenarios with the same facts and the two different sets of competing options. The resulting preferences are shown in figures 9 and 10.

Figure 9. Arguing at the fourth level (1)

Figure 10. Arguing at the fourth level (2)

Level 5, scenario: at_work, family(Call), in_meeting

Requirements:

• ...except when he is in a meeting, when he prefers to deny with explanation over allowing the call...
• ...Being in a meeting there is a possibility to prefer to accept a call from his son when he is at school...

Now there is only one scenario with the competing preferences of allowing and denying the call with an explanation. The resulting preferences are shown in figure 11.

Figure 11. Arguing at the fifth level

Level 6, scenario: at_work, family(Call), in_meeting, from_son(Call), son_at_school

Requirements:

• ...He will accept it if he believes that his son is ill, otherwise (if he believes that he is not ill) he will prefer to deny the call with an explanation....

Again there is only one scenario with the competing preferences of allowing and denying the call with an explanation. The resulting preferences are shown in figure 12.

Figure 12. Arguing at the sixth level

Execute scenarios

Gorgias-B allows to test the developed decision model through an execution engine using prolog in the background. From the menu Run->Execute, Ralf can instantiate facts and test his decision policy. He tries a scenario where: at_work, in_meeting, from_son(call), son_at_school hold. Notice that in from_son(call) the call is started with a lower case letter, it is not a variable now, it is a specific call. Figure 13 shows the view and the results.

Figure 13. The execution view (1)

The abducible belief son_is_ill allowed to produce an argument for allow(call). then, Ralf tries a scenario where: at_work, in_meeting, from_son(call), son_at_school, not son_is_ill hold. Now there is no solution for allow(call). Figure 14 shows the output.

Figure 14. The execution view (2)

Download the Gorgias-B project files

You can download this tutorial's files from the following links:

Ralf.pl, backgroundRalf.pl.

Then, start Gorgias-B and select File->Import Gorgias File and open the Ralf.pl file. The file assumes that you have unzipped the Gorgias-B system in C:\ and that you stored the downloaded files in the C:\GorgiasB folder. If something is different in your system then, after importing the Gorgias file, select File->Gorgias Lib Folder and select the gorgias-src-0.6d folder (it is located in the GorgiasB installation folder). Subsequently, select File->Import Prolog file and select the background.pl file. Now you are ready to work with this project...

Request Assistance Policy

This is a policy that allows an agent (human or artificial) to decide how to respond to a request for a resource. The agent has three options in its response: challenge, accept or refuse a request for a resource.

Normally, he challenges (asks why) a request from another agent for a resource. If he needs the resource himself, he refuses the request, unless the request is for a common project. If the request comes from his manager, he accepts to give it except when he is already using it. Possible scenaria are the:

<1, {request(ag,res)}, challenge(ag,res)>

<2, {request(ag,res), need(res)}, refuse(ag,res) >

<3, {request(ag,res), need(res), com_project(ag,res)}, challenge(ag,res)>

<4, {request(ag,res), manager(ag)}, accept(ag,res)>

<5, {request(ag,res), manager(ag), using(res)}, challenge(ag,res)>

Then, we extend the program with the additional policy requirement: When his manager is abroad, he challenges a request for a resource from him/her.

The following videos explain the process of developing and extending this policy.

Video 1. Gorgias-B v1.3 tutorial - Request Assistance Policy

Video 2. Gorgias-B v1.3 tutorial - Request Assistance Policy - Extended

Download files

You can download this tutorial's file from the following link:

request_resource_policy.pl, request_resource_policy_extention.pl

Then, start Gorgias-B and select File->Import Gorgias File and open the desired file. The file assumes that you have unzipped the Gorgias-B system in C:\ and that you stored the downloaded files in the C:\GorgiasB folder. If something is different in your system then, after importing the Gorgias file, select File->Gorgias Lib Folder and select the gorgias-src-0.6d folder (it is located in the GorgiasB installation folder). Now you are ready to work with this project...