Types of question
Two interrogation methods
Implementing the techniques for retrieving
information from the database is somewhat trickier than setting up the information in
the first place. One way of getting to grips with the requirements is to think of the
user as asking questions of the computer in order to check the facts it
knows. Viewed in this light, there are two types of user question which you might
usefully distinguish.
Sometimes the user will want merely to establish (or not) the the truth of some
particular fact - e.g. the question Does John like Mary? expects an
answer Yes or No. But sometimes it might be more useful to
be able to ask about specific aspects of facts - e.g. Who
likes Mary? or John likes what? - so that
whatever particular facts provided answers to these questions could be retrieved. You
are probably already familiar with this distinction as one between yes/no
questions and wh-questions (or question word questions).
Pattern
matching in yes/no questions
A yes/no question such as Does John like
Mary? can be paraphrased with no damage to its intention as Is it true
that John likes Mary? or more appropriately from our point of view - since
truth is the same as existence in the database - as Is it a (known) fact that
John likes Mary? This last paraphrase brings out clearly what must be involved
in handling our equivalent of a yes/no question. The user is effectively seeking to
establish whether or not some sentence is matched by a fact stored in the
database.
If no more were to be required of the system than responding to yes/no questions in
this way, we could soon have done with the problem by taking advantage of the Logo
primitive member? to deal with the business of matching a query with a
corresponding fact. Is it a (known) fact that John likes Mary? should
generate a YES, or some such positive response, if the list [John likes Mary]
is a member of :facts and a NO or DON'T KNOW otherwise. The definition of a
command called is.it.a.fact.that could in other words look like this:
to is.it.a.fact.that :fact
if member? :fact :facts [pr [Yes]] [pr [I don't know]]
end
Of course, in following this line we are prejudicing the interpretation of the notion
match, which we introduced earlier, since, under this definition,
is.it.a.fact.that :fact will only print out the answer YES if :fact and
some sub-list of of the database are identical. This is a defensible stand
to take, but it is a restrictive one and not the only possibility. It means, for
example, that [butter is yellow] matches [butter is yellow] but does
not match [all butter is yellow]. On that account you might prefer
to consider that :fact matches a sub-list, S, of the database when
:fact forms a sub-sequence of (or is contained in)
that sub-list, S. You will then need to decide whether such a sub-sequence
should be continuous or could be interrupted. If only
continuous sub-sequences are allowed to guarantee genuine matches, then [butter is
yellow] will not match [butter is always yellow] but, much more sensibly,
it will not not match [butter is not yellow] either.
Pattern matching in wh questions
It is perhaps not a good idea to commit
ourselves to any decision about the interpretation of the notion match at
this stage without looking first at the other type of question which we expect the
system to respond to, the wh-question.
If we look around for a paraphrase of Who can fly? which suits our needs,
we soon see that pattern matching, though of a more complicated type, is involved
again. Who can fly? could readily be glossed as: Is there any fact
in the database which matches the pattern 'X can fly' (where X is any word)?
Similarly John hates what? could be thought of as equivalent to:
Is there any fact in the database which matches the pattern 'John hates X'
(where X is any word)?
In this view, then, the wh-words in
the English questions are no more than temporary place-holders for the
more specific and hence more informative words which the response will supply when a
match is found. In more normal database terminology, who and
what would be considered to be wild-cards which, in the
search for a match, are allowed to act as substitutes for single words.
Coping with the syntax of 'normal' wh questions
It will not have escaped your
attention that English questions of the typeWhat does John hate? and
When does John come home have been carefully avoided so far. Normal
English wh-questions place the wh-word (what, who,
when, where . . .) at the beginning of the question and
distinguish the place to be occupied by the substitute in any response sentence by
both the choice of the particular wh-word and the use of a few other tricks (which you
can think about). What does John hate? expects the answer John
hates SOMETHING/SOMEONE. Who hates John? expects the answer
SOMETHING/SOMEONE hates John. Accepting such question forms as
database queries would probably overtax our skills at this stage. But an obvious
alternative to the normal English syntax would be to use a single wild-card for any
substitute and identify the place of the substitute by the place of the wild-card in
the query. Using ? as the wild-card, we can in this way easily turn any
English wh-question into the simpler standard form we anticipated earlier. Who loves
John? can be turned with no loss of function into ? lovesJohn ,
Who does John hate? into John hates ? and Who likes
who? into ? likes ?.
A query command
Let us suppose, then, that the user of the database will ask
the equivalent of natural language questions by using a command called query which takes as
input a list. This list may contain one or more occurrences of the ? wild-card, in which case it corresponds to a wh-question. For example, [? can fly] would be a legitimate input to query corresponding to the question What/Who
can fly?. The input list may, on the other hand, contain no wild-card. In this case, it is taken to be the equivalent of a yes/no question. If, therefore, the input to query is [Pigs can fly], the intention is simply to establish whether Pigs can fly is, or is not, a (known) fact.
Implementing the query command
Ron Brasington
Department of Linguistic Science
The University of Reading
Reading
UK
E-mail: ron.brasington@rdg.ac.uk