We describe a visualization method for general logic clauses as the first step of a visualization of logic programs. Since we think inclusion is essential to represent an outline of knowledge, we propose a method based on Euler diagrams to visualize inference rules represented as a set of general logic clauses which consist of literals with no variable. We develop a prototype system and show that complex rules which are hard to understand in text are easy to understand by diagrams</p

Sasakura, Mariko

Okayama University Scientific Achievement Repository

EngineeringIndustrial & Management Engineering fieldsOkayama University Year 2001A visualization method for knowledgerepresented by general logic programsMariko SasakuraOkayama UniversityThis paper is posted at eScholarship@OUDIR : Okayama University Digital InformationRepository.http://escholarship.lib.okayama-u.ac.jp/industrial engineering/38A visualization method for knowledge represented by general logic programs Mariko Sasakura Department of Information Technology, Okayama University Tushima 3- 1 - 1, Okayama, 700-8530, Japan sasakura@momo.it.okayama-u.ac.jp Abstract In this paper; we describe a visualization methodfor gen- eral logic clauses as the first step of a visualization of logic programs. Since we think inclusion is essential to represent an outline of knowledge, we propose a method based on Euler diagrams to visualize in$rence rules represented as a set of general logic clauses which consist of literals with no variable. We develop a prototype system and show that complex rules which are hard to understand in text are easy to understand by diagrams. 1. Introduction We are interested in visualizing an outline of knowledge intuitively. In this paper, we discuss a visualization method, which we call inclusion diagrams. An inclusion diagram is an extension of an Euler diagram. We can visualize general logic programs by inclusion diagrams. We have known diagrams help us to understand complex or huge mount of information. For example, Euler diagrams are often used to explain sets theory for education. Also, Euler already found an inference rule can be represented by sets so they can be represented by Euler diagrams. How- ever, Euler diagrams have two drawbacks to represent a set of large amount of inference rules. The first is that Euler di- agrams are very hard for human to draw in hand if there are many sets. The second, that is more essential than the first, is that Euler diagrams can represent relation among only three sets precisely. It is very difficult for Euler diagrams to represent all combinations among more than three sets. In spite of the drawbacks, Euler diagrams are very useful for us to grasp relations between sets. Therefore, we try to extend Euler diagrams and to use for visualizing relations between large amount of sets. For the first drawback, we develop automatic drawing system for diagrams. On the second drawback, we will draw intuitive diagrams instead of precise diagrams. So, we combine precise diagrams on less than four sets and intuitive dmgrams on more than three sets so that we draw diagrams on relations among sets with no misunderstanding. In this paper, we consider a general logic program as a directed graph, and visualize it by a method based on Euler diagrams. A general logic program is defined as a set of general program clauses. A general program clause is defined as the following: A t B1,. . ., B,,- C l , .  . . , -  C,(m 2 O,n 2 0) where A ,  B1,. . . , B,, Cl,. . . , C, are atoms and - means negation. The left side of t is called as “head”, and the right side is called as “body”, In this paper, for the first step to visualize a general logic program, we deal with the clauses of which body consists of a literal. And to make a problem simple, we assume all literals have no variable. So, the clauses we deal with in this paper like the following: A - B  or A t - C  In section 2, we explain basic ideas of inclusion diagrams which we propose in this paper. In section 3, we show a prototype system of inclusion diagrams and mention some implementation issues. We mention related works in section 4. And we give a conclusion in section 5. 2. Ideas 2.1. Euler diagrams Euler diagrams represent relations between sets. For ex- ample, the region in the circle of figure 1 represents a set A.  The region out of the circle and in the rectangle represents a set of not A.  A general program clause can be represented by Euler diagrams. For example, there is a general program clauses A - B  135 0-7695-1195-3/01 $10.00 0 2001 1E;EE Figure 1. Euler diagrams Figure 2. Euler diagrams for a general pro- gram clause As well-known, this can be written A V T B .  If A is a set of cases in which A is true and B is a set of cases in which B is true, then the clause is equal to: A > B  Thus, this can be represented by Euler diagrams as figure 2. 2.2. Inclusion diagrams Euler diagrams are very useful to grasp relations between sets intuitively. However, they have the following problems to visualize general program clauses. 0 In Euler diagrams, we divide a space into two regions by a circle that represents a set. If there are several sets, we expect a space will be divided into the number of the combination of the sets. However, for more than three sets, Euler diagrams cannot represent all combi- nations. 0 In Euler diagrams, a “not” set like - A is represented as the region of out side of a circle. Thus, i t  is not easy to draw a diagram like B +-- A. Therefore, we design inclusion diagrams as the follow- ing. 1 .  A circle corresponds to a literal in a general program clause. The inside of a circle represents the correspond literal is true. The outside of a circle represents the correspond literal status is unknown. For example, the Figure 3. An inclusion diagrams for three nodes with negation inside of the circle corresponds to a literal A means the cases of A is true. Similarly, the inside of the circle corresponds to a literal - A means the cases of A is false. 2. We prefer intuitive understanding to preciseness. Therefore inclusion diagrams does not guarantee to represent precise information about sets if there are more than three sets in a diagram. They may allow users to grasp relations between sets intuitively. But, if there are less than four sets, inclusion diagrams can represent precise information about the sets. Users can understand precise relations among the sets by the di- agram. Also, a positive literal and a negative literal on the same atom should not have intersections in logic, but we don’t mind if they have intersections in a dia- gram. 3 .  To avoid drawing complex diagrams, we make several diagrams to represent the whole sets represented by general program clauses. Each of the diagrams rep- resents some sets, and every set is represented in at least one of the diagrams. The details of how we de- cide which set will be drawn in which diagram will be mentioned in section 3. For example, if there are general program clauses: A t B  A t C  A t - D  then an inclusion diagram is figure 3.  B,  C and - D are drawn similarly. In the case of four sets, we make figure 4, for example. This figure gives us intuitive understanding about four sets, but i t  is not precise. The regions correspond to A A C but don’t care about B and D ,  and B A D but don’t care about A and C are not represented. 136 A Figure 4. An inclusion diagrams for four nodes Here, we should show whether inclusion diagrams can represent any logic program or not. It is trivial that any logic program is represented as directed graphs. In the di- rected graphs, a literal is represented as a node. Therefore, we consider whether inclusion diagrams can represent any directed graph produced by logic: programs. Inclusion diagrams draw the r4:lation between nodes only by the inclusion of circles. So, they cannot draw general directed graphs.. When there arc: loops in directed graphs, we cannot generate inclusion dia,grams. Therefore, consider whether logic programs produce loops in the correspond di- rected graphs or not. Case 1: loops with direction For example, the following program clauses produce a loop. A c E 3  B +- A We assume A is a set of cases in which A is true and B is a set of cases in which B is true. Then, above clauses can be rewritten as: A > B A E I 2 A  These mean A = B.  Therefore, we regard A and B as one literal. Thus we can avoid loops ,with direction. Case 2: loops with no direction There are cases that program clauses produce a loop with no direction. For example, A t € 1  B +- Cr A-C‘ produce a loop with no direction. In this case, we are puz- zled as to where we draw C .  But. we think a proper way to draw three clauses is that we ignore the third clauses, since the third clauses is lead by the first and second. Therefore if we have several passes between two literal, that is there is a loop with no direction, we cut the shorter pass then the loop will be removed. Now, we know we can make inclusion diagrams for any program clauses of which body consists of 1 literal. A general program clause can have negative literal in its body. Therefore, there are the cases that progmm clauses produce conflicts. In this paper, conflict means the situa- tion which A and N A also exist in same time. In a directed graph, it means A and N A appear in the same pass. We can draw an inclusion diagram if there is a conflict in directed graph, but the diagram is not suite to our intuition. So, we remove clauses that cause conflicts. The details about con- flicts will be discussed in section 3.1. 3. Implementation We develop a prototype system that visualizes a logic program by our inclusion diagrams automatically. The sys- tem consists of two parts. The first part makes and ma- nipulates directed graphs and the second part visualizes the graphs. 3.1. Graph manipulation part The graph manipulation part of the prototype system 1 .  makes directed graphs from a set of general program clauses, 2. manipulates the graphs to draw diagrams, (a) reduces loops, (b) extracts conflicts, and 3.  sets a level for each node of the graphs. At first, we make directed graphs from a set of general program clauses. A node of the graphs corresponds to a literal in the general program clauses. An arc corresponds to a relation “c”. If there is a rule A c B, then we call A is a child of B and B is a parent of A. The node that has no child is called a leaf node. The node that has no parent is called a root node. Then, we check and reform the graphs if there is any loop or conflict in the graphs. Regarding a set of general program clauses as a directed graph, loops with direction in the clauses make a strongly connected component in the graph. We extract a strongly connected component from a directed graph and replace it as a node. The algorithm to find a strongly connected com- ponent in a directed graph is known[8]. 137 We deal with loops with no direction in the drawing part. So we will discuss it in section 3.2. To find a conflict we mentioned in section 2.2, we check if we can reach from a positive literal to a negative literal of the same atom or vice versa. For example, if there are A and N A in the same directed graph and we can reach form N A to A,  they cause a conflict. In practice, after making directed graphs, we check that all negative literals have their positive literal as an ancestor. Because negative literals must be appeared in a body of a clause, so a node corresponds to a negative literal must be a root node. If we find a conflict, we cut the pass from the negative literal to the positive literal. Thus we can remove the conflict. At last, we set a level for each node. The level decides which node will be drawn in which diagram, when we make several diagrams to represent a directed graph. A level of a node will be decided the following way: 1. 2. 3. 3.2. The level of a leaf node is 0. If the level of a node is n, then the level of parents nodes of it  are n + 1. If different number of levels will be assigned to a node, we choose bigger one. Drawing part We will draw a set of general program clauses as several diagrams. The number of diagrams must be not too many because many diagrams confuse users. But, we should also avoid making a complex diagram which has too many nodes in it. Therefore, basically, we draw nodes that are in the same level in a diagram. If users want to see the parents of one of the nodes, they select a menu for the node then we make a new diagram for the parents node. But, in the following cases, we draw parent nodes in the same diagram of the children nodes. 0 There is only one node in a diagram. 0 The all nodes drawn in a diagram have the same par- ents. Now, we explain how we draw a diagram from a directed graph. A node is represented as a circle. First, we draw all leaf nodes. If there is only a leaf node or all leaf nodes have the same parents nodes, then we draw the parents nodes in the diagram. An algorithm to draw a diagram is shown in table 1. This algorithm will draw circles until the condition is not satisfied. So, in some cases there will be too many nested circles in a diagram. Therefore we explicitly restrict the number of recursive calls of procedure draw. Currently we restrict the number as 5 experimentally. In the procedure drawcircles, we may draw several nodes. The node in the list of the parameter of drawcir- cles should not include the other node in the list. If there is such a node, it means there is a loop with no direction. Therefore, we check there is such a node in the list at the first of the procedure drawcircles. If there is, we remove the included node from the l ist  Then, we draw the nodes in the list like an Euler dia- gram. If there are A and C in the list, a diagram is figure 5. Similarly, 10 nodes should be represented as figure 6. To make this figure, we draw 10 circles shifting a center of circles on a circle by 2 * ~ / 1 0  radian. 3.3. Examples In this section, we show two example diagrams gener- ated by our prototype system. Our prototype system is im- plemented by Java. Example1 shows how negative literals are drawn in a di- agram. The diagram of this example is shown in figure 7. In this example, B +-- A and A +- B cause a conflict. So, these two clauses are not shown in a diagram. The inmost circles of the diagrams are A,  C, D and - C. As we can see in the diagram, negative literals are drawn as same as positive literals. There should be no intersection between C and - C, but in the diagram there is. It is too complicated to draw precise diagrams. So, we don’t mind if C and N C have an intersection. We think such intersections are not obstacles to users’ intuitive understanding. Example2 is a a little big example to feel usefulness of the visualization. Table 3 is an example that consists of 14 rules. Even 14 rules, it is not easy to grasp an outline of rules written in text. Our prototype system visualizes this example as figure 8, 9, 10. The first figure is figure 8. C and D have parents that are not appeared in this figure. So, the menu “More ...” is appeared to allow users show their parents. If we select C from the menu then figure 9 is appeared. If we select D, figure 10 is appeared. 4. Related Works In this paper, we describe a visualization method for logic programs. There have been several studies on visu- alizing logic programs. However, almost of them propose visual logic programming[7, 5, 6, I] ,  that is, they visualize syntax of logic programs. We are influenced by the studies in [2]. However, our work differs from logic reasoning with diagrams. A theo- retical background on Euler diagrams are discussed in [4]. In this paper, we visualize a logic program as a di- rected graph. Although there are many studies in graph drawing[3], we don’t find a study about graph drawing based on VennEuler diagrams. 138 Table 1. An algorithm to draw a diagram list := a list of leaf nodes; draw(1ist); procedure draw(list) begin n = the number of list; if n = 0 then return else if n = 1 then begin parent := a list of parents of list; draw(parent); end begin parent := a list of parents of list; draw(parent); end drawcircles(1ist); end else if parents of all member:< of list are the same then Table 2. Example1 B c - A  E t - A  A t B  B t E  E t C  E t - C  E + D  Table 3. example: 14 rules G c A H c F  H c B F t H  J t B J c H  A + - C C + I  A + - D D + J  A + K A + - L  F c E A c M  5. Conclusion In this paper, we describe a method to visualize a re- stricted logic program. Our method is based on Euler dia- grams. We show examples generated by our prototype sys- tem. In future, we will expand this method to general logic programs. References Figure 5 .2  nodes File I A [ I ]  J. Agusti, J. Puigsegur, and D. Robertson. A visual syntex for logic and logic programming. Journal of Visual Languages and Computing, 9(4):399427, August 1998. [2] G. Allwein and J. Barwise, editors. Logical Reasoning wifh Diagrams. Oxford University Press, 1996. [3] G. D. Battista, P. Eades, R. Tamassia, and I.  G. Tollis. Graph Drawing. Plentice Hall, 1999. [4] E. Hammer and S.-J. Shin. Euler and the role of visualiza- tion in logic. Languages, Logic and Computation: The 1994 Moraga Proceedings, pages 21 1-286, 1994. Vlp: a visual logic program- ming language. Journal of Visual Languages and Computing, [5]  D. Ladret and M. Rueher. 2(2):163-188, 1991. [6] M. Najork. Programming in three dimensions. Journal of Visual Languages and Computing, 7(2):219-242, 1996. [7] L. Pau and H. Olason. Visual logic programming. Journal of Visual Languagesand Computing, 2(1):3-15, 1991. [8] R. Sedgewick. Algorithms in C. Adison-Wesley, 1990. Figure 6.10 nodes 139 Figure 7. A diagram for example1 Figure 8. The first diagram for example2 Figure 9. The diagram for node C of example2 U 1 Figure I O .  The diagram for node D of exam- ple2 140 

A visualization method for knowledge represented by general logic programs

Abstract

Similar works

Full text

Available Versions

Okayama University Scientific Achievement Repository

Okayama University Digital Information Repository