Starting from this page the reader can access a number of tutorials and examples on how to use Gorgias-B and develop decision policies following the SoDA methodology. At the end of each tutorial you can download the generated files.
The following tutorials are currently available and done using the Gorgias-B version 1.3:
- Install Gorgias-B in your Windows system (video)
- Develop a simple call assistant policy (html)
- Develop a cognitive call assistant with three different options (html),
- Develop a conflicts resolution policy (html),
- Develop a cognitive assistant for providing assistance (video),
- Develop a data access policy (html).
There are some tutorials for Gorgias-B version 1.2.
Lina is a fictitious character that needs to model a decision problem. She needs a cognitive assistant that will help her decide whether or not she should receive a phone call. She wants the assistant to allow or deny a call depending on her context.
She has the following policy: In general all calls are accepted. When she is at work she does not want to take family calls. However, if they are from her son she wants them. One exception to this is when she is in a meeting. However if he is at school and she believes that he is ill she will take the call. If she does not believe him to be ill she does not take the call even if he is at school. Another reason for which she will not take a call is in the case that she is in a family outing and the call is related to business. The only exception to this is in the case that her boss is calling, when she will take the call.
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.
In this case she has two options, one is to accept the call and the other to deny the call. She launches the Gorgias-B App and selects File->new project. She selects a filename, e.g. ManageCalls2.pl (do not forget the .pl extension) and then the tool automatically launches the Options panel. There she adds the allow option predicate with the parameter Call (see the text boxes on the top of the Figure 1 below). She could select to "add this options negation as an option" (i.e. not allow), however she prefers to have another predicate for denying the call. Then she presses on the button "Create option". She does the same for the other option (deny). The options are added in the "Options" list.
Then she needs to tell the system that these options are incompatible. To do that she selects the two options in the two combo-boxes in the "Incompatible options" area of the panel and she clicks on the button "Add". Now you should be able to see the screen in Figure 1.
Figure 1. The Options panel
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 necessary, 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.
For our problem we need to define non-defeasible predicates for facts regarding calls, such as a business call, a call from the boss, a call from the family or her son. Moreover, she can add contextual facts that are indisputable such as whether she is at a family outing, at work or in a meeting, or whether her son is at school. She 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" she can add defeasible knowledge, i.e. in this case whether her son is ill or not. It is an atom withut parameters and by clicking on the "belief is abducible..." check box the system will be able to assume that the son is ill or its negation, i.e. that her son is not ill. We will see later how we can use such knowledge.
Note that this step is optional, she can add more predicates later, when arguing.
Figure 2. Adding beliefs
At this time she can import an existing prolog source file that aids in defining the non-defeasible beliefs. For example she wants to import a background file (background.pl) with the following info:
business(Call) :- from_boss(Call).
family(Call) :- from_son(Call).
She can do that using the File->Import Prolog file dialog.
Finally she needs to have a clear view on the contexts hierarchy. She will use this hierarchy in the next tasks (for example a call from her son is more specific context than a call from her family).
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.
She will write rules using the family and business calls contexts combined with being at a family outing or at work (note that all these are independent contexts). She cannot have the possibility of being in a meeting at this level (it is a more specific context to being at work), neither the possibility of having a call from her boss (it is a more specific context to having a business call).
In figure 3 you see her arguments. The first one is about generally allowing calls. She just selected the allow(Call) option from the combo box and clicked "Add argument". For the second argument she selected the deny(Call) option. Then, she selected the at_family_outing/1 predicate and clicked "Add predicate". Subsequently, she selected the business/1 predicate with the Call parameter and again clicked "Add predicate". Note that the combo box for selecting the predicate helps me remember how many parameters it has by showing their arity. Finally, she added the second argument by clicking "Add argument". She follows the same process for the third argument. You can see in figure 3 the last predicate that she added : family(Call).
Note that while she is building her argument she can see its status on the left of the "Add argument" button. If you no longer want an argument you 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 you proceed to the Argue panel - see next topic.
Figure 3. Defining the arguments
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 two scenarios, one between the first and second arguments and one between the first and third arguments (see figure 3).
In the first scenario in general she prefers to deny a business call while in a family outing (first model in figure 4) however, if the call is from her boss she prefers to allow it (first model in figure 4). Note that a call from her boss is more specific context to business calls (context of the previous level). In the dialog she first selects the scenario, see the two available ones in the combo box, then she selects the preferred option from the next combo box. Then, if she does not have more contextual information to add, she clicks on the "Add model" button. If she has more information to add (like in the second case of figure 4) she clickes "Add predicate", one or more times and then "Add model". Note that she 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.
The next scenario is family calls at work. Here she has more specific contexts to both cases. Being in a meeting is more specific to being at work, and a call from her son is more specific to a family call. So she has to decide what happens in general, what happens when she is in a meeting and what happens if her son calls. To tell you the truth she is not sure what happens in general, thus she enters no such model. However, she knows that if she is in a meeting she does not want to be bothered. Additionally she knows that if her son calls she wants to take the call. Thus, she makes two models, the ones you see in figure 5.
Figure 4. Arguing about whether to accept or not business calls when at a family outing
Figure 5. Arguing about whether to accept or not family calls when in a meeting
Now she is finished with level 2. She chooses level 3 on the combo box at the top of the argue panel. Again she has two scenarios, one coming from the two models of figure 4 and one from the models of figure 5. Regarding the first she just selects to allow the call and that's it. Thus, a call from her boss in a family outing will be allowed.
Regarding the second she has more work to do. She has two conflicting contexts in level 2, a call from her son at work is allowed and a call while in a meeting is denied. What happens when the call is from her son and she is in meeting? Here you can see how she can merge contexts in a higher level. Now she knows that she wants to accept calls from her son when he is at school and when she believes him to be ill. Thus, being ill is a specific context to being at school. Therefore she will only deal with school at this level. Thus, she has a default model for denying the call and a model when her son is at school that she allows the call. See both models in figure 7.
Figure 6. Arguing about whether to accept or not calls from boss when at a family outing
Figure 7. Arguing about whether to accept or not calls from son when at a meeting
Now she is finished with level 3. She chooses level 4 on the combo box at the top of the argue panel. Now she only has one scenario stemming from the conflict in level 3 about whether to allow or deny a call when her son is at school. Now if she believes her son to be ill she allows the call, while if she believes that he is not ill she denies the call. See the models in figure 8.
The situation is now resolved. If she goes to level 5 she finds no scenarios to work upon. Gorgias-B has understood that the two models in level 4 do not lead to a new scenario as sonIsIll and not sonIsIl are impossible to be true at the same time (see figure 9). She is finished!
Figure 8. Arguing about whether to accept or not calls from son, when he is at school and when she is at a meeting
Figure 9. End of arguing
Gorgias-B allows to test the developed decision model through an execution engine using prolog in the background. From the menu Run->Execute she can instantiate facts and test her decision policy. For example she adds the facts that you see in figure 10 one after the other. Note that now that she is adding facts the predicates parameters must be grounded, i.e. start with lowercase letter. So you see she is asking her cognitive assistant whether call_1 should be allowed, taking into account that it is from her son at school and she is in a meeting. The answer is that there is an argument for allowing the call assuming that her son is ill. She gets this answer because she defined this belief as abducible.
Figure 10. The execution panel
You can download this tutorial's files from the following links:
Then, start Gorgias-B and select File->Import Gorgias File and open the ManageCalls2.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...