Decomposing intensional knowledge

The reasons to decompose and store a Prolog program in RDBMS are:

• it allows to get access to intensional knowledge using SQL; no other communication methods are introduced,
• it provides easy modification or extension of existing intensional knowledge^8.2,
• rules can be reused in different programs, so it will be possible to have logic programs sharing some of the rules,
• it simplifies future design and development of a CAD tool, which can visualize knowledge and allow its editing in some comprehensive and efficient way (i.e. a similar system to the one presented in [27]),
• the database remains a uniform source of data and knowledge,
• the technology enables modular programming; for such programming no knowledge of Prolog language is necessary.

The same communication method, which is SQL, is used to create, alter or delete both extensional and intensional data.

The decomposition and storing a program in RDBMS addresses a more general problem which is how to represent knowledge. This issue is out of the scope of this dissertation but it is widely discussed in [27,11,12,14,13,10,9].

Summarizing:

• Extensional knowledge is provided by the database; it is covered by relations.
• Intensional Knowledge is expressed by a Prolog program.
• The Prolog program is decomposed and stored in RDBMS.
• The Prolog program consists of an ordered set of rules^8.3.
• Inferred data are perceived as a dynamically generated view.

Figure 8.1: Decomposing Rules, Improved Diagram.

Table 8.1: A decomposed clause and its description.

clause
id	name	order	preconditioned	symbol
1	sibling	NULL	NULL	1
2	parent	1	1	2
3	parent	2	1	2
4	$\backslash$==	3	1	4

argument
name	position	clause
X	1	1
Y	2	1
X	1	2
Z	2	2
Y	1	3
Z	2	3
X	1	4
Y	2	4

logical operator
id	symbol
1	:-
2	,
3	;
4	.

attribute	description
clause.id	primary key for clause
clause.name	name of the predicate in the head or body
clause.order	an arbitrary integer denoting the order of predicates in the body
clause.preconditioned	the foreign key referring to clause.id, if not NULL it means that the predicate is in the body of a clause referred by it
clause.symbol	the foreign key referring to logical operator.id, the logical operator at the end of predicate
argument.name	name of the predicate argument
argument.position	position of the argument in predicate, an arbitrary integer
argument.clause	foreign key referring to the predicate clause.id
logical operator.id	primary key for logical operator
logical operator.symbol	the operator symbol

Figure 8.2: Decomposing a clause.

The ER diagram visualizing the decomposition is given in Figure 8.1. The program is targeted by the goal which is given as a predicate denoted by predicate and arity. Each program consists of some number of ordered clauses. The order of clauses is provided by clause order.

Each complex clause is composed of the head and the body. The head is a predicate name, denoted as name (clause entity) and a list of parameters, denoted as argument entity. Each of the parameters has a name and position.

The body consists of some number of ordered subgoals (preconditioned relationship). Each subgoal is described by clause entity. The subgoals are separated by logical operators (logical operator entity), which are a comma (',') or a semicolon (';'). Additionally, there should be two more operators defined: an implication (denoted as ':-', which is equivalent to $\leftarrow$) to separate the head and the body, and a period ('.') at the end of the complex clause.

For example, having the following complex clause (it is the first clause from Figure 6.2):

  sibling(X,Y) :- parent(X,Z), parent(Y,Z), X \== Y.

It will be decomposed into the relations given in Table 8.1. The decomposition process is visualized in Figure 8.2.

The program could be decomposed further covering non-atomic values of parameters: structures and lists. But having a parameter which is a structure, it is allowed that such a structure has some parameters which could also be structures, and so on. Such decomposed parameters will require a recursive query, to follow all the subsequent parameters: parameters which are structures, which have parameters which are structures, and so on. It may have tremendous impact on the performance. And this is the reason why parameters of predicates are not subject to further decomposition.

A parameter may be a structure or list but it will be decomposed as an atomic one. Summarizing: constants, variables, structures and lists are all perceived as atomic arguments, so there will be a single record for a single parameter.

Assuming that the goal is to find some siblings, a proper record has to be added to program. It indicates what is the goal name (predicate name) and its arity. Furthermore, a many-to-many relationship has to be created between program and clause. It indicates which clauses belong to which programs. It is provided by program-clause and it implements consists_of relationship (see Figure 8.1). The above relations and their description are given in Table 8.2.

Table 8.2: Goal and its description.

program
id	predicate	arity
1	sibling	2

program-clause
program	clause	clause order
1	1	10

attribute	description
program.id	primary key for program
program.predicate	predicate name which will be used as the goal clause.id
program.arity	goal arity
program-clause.program	foreign key referring to program.id
program-clause.clause	foreign key referring to clause.id
program-clause.clause order	an arbitrary integer denoting the order of clauses in the program

Usually, considering Prolog, the search is bounded by the arguments passed to the goal. The goal arguments are not specified here. They will be given from outside as program parameters.

The decomposition resembles catalog-driven approach present in the most of the relational systems. The relational systems store information about databases, tables, columns, etc., in system catalogs (Some systems call this the data dictionary). The catalogs appear to the user as tables like any other, but the RDBMS stores its internal bookkeeping in them. The decomposed logic program may be perceived as an extension of the regular system catalogs, which allows to store intensional knowledge. It is just a step forward comparing with the system catalog of todays RDBMS.