I finally finished entering the text of all my blogs into my blog manager
program, as I
proposed to do
six and a half months ago! It's not that it was difficult to do this; some
days I would remember to enter 30 blogs and some days I would just forget.
Anyway, having done so has given me the chance to reconnect with some historic
blogs.
For some reason, I was considering the 'db Prolog' program that I
wrote
about almost 13 years ago! I thought that I could use the 'temp table'
technique that I documented
here to store the values of variables used in a rule. Maybe this will work,
but I think that it will be easier to use a string table consisting of values
such as '17=abraham'. I'll explain the 17 in a minute.
Before I could get to solving rules though, I would first need to store them
somehow. The original blog left this to be done in the future. When I write
'rules', I mean statements like
father (X, Y):- male (X), parent (X, Y).
This means that someone (represented by X) is the father of someone else
(represented by Y) if that someone is male and that the someone is a parent of
the other person. After considering this, I decided to take an SQL approach to
this and store the rule in three separate tables: one table contains an id, the
arity (number of variables) in the rule and the name of the rule, i.e. 3, 2,
father. The second table contains parameters of this rule, one tuple for X and
one tuple for Y. Doing so allows me to assign to these parameters actual values
(e.g. 17 and 18). The third table contains the clauses of the rule, along with
the parameters; in the above case, there are three tuples - one with a pointer
to the 'male' table and parameter 17, and two with a pointer to the 'parent'
table, one with parameter 17 and one with parameter 18. Parsing the above rule
into the tables was surprisingly difficult, although I admit that I was using an
ad hoc approach with little preparatory thinking.
I also added a 'listing' command to the program so that I could see the entire
database, both facts and rules, in one dialog. This also was fairly
complicated as it requires turning several what might termed 'vertical' data
(i.e. tuples in tables) into one 'horizontal' datum. Some of the ideas here
might be useful when I get to actually solving a query using a rule.
Prolog is very strong on
backtracking; using linked lists, this is normally achieved by means of a recursive
subroutines, so turning this into a series of SQL statements is going to be
awkward. Normally an SQL query will return several results, but backtracking
will probably require that only one result be returned at a time. Let's say
that I have the following database
male (abraham).
male (isaac).
female (sarah).
parent (abraham, isaac).
parent (sarah, isaac).
father (X, Y):- male (X), parent (X, Y).
When the query ? father (X, Y) is issued, a Prolog interpreter will first
try to solve the subquery male (X); there are two such lines. Using the
first line, male (X) will succeed with X being bound to the value
'abraham' (this is where the temp table may come in use). Then the query
parent (X, Y) has to be solved, but as X is abraham, it becomes
parent (abraham, Y); this is solved by the fourth line. Prolog will then
restart the query, where male (X) will match male (isaac). But
there is no line matching parent (isaac, Y), so this time the query will
fail. I'm not saying that this is easy to achieve with a recursive subroutine
but it's probably easier than working with SQL. The backtracking would be
clearer if the order of the first two lines were reversed.
I shall have to brush up on the Firebird dialect of SQL to find how I can
retrive only the second tuple in a table (i.e. retrieve one tuple starting
with tuple 2). This isn't something that I regularly do so I don't recall the
syntax required.
On another topic, I see that automatic emails were sent for the last two blogs, even though they contained pictures, so the hypothesis that emails are sent only for blogs with no pictures has been disproved. This behaviour doesn't appear to be consistent.
