In this paper, a Cognitive Architecture leveraging Natural Language Processing and First Order Logic Inference is presented, making usage of di erent kinds of knowledge bases interacting one another. Such a framework is able to make reasoning on queries requiring also combinations of axioms, represented by means of a rich semantic, using Abduction as pre-stage of Deduction. As application test a Telegram chatbot system has been implemented, supported by a module which automatically transforms polar and wh-questions into one or more likely assertions, in order to infer boolean values or snipplets with variable length as factoid answer. Furthermore, such a chatbot does not need script updates or code refactory when new knowledge has to income, but just the knowledge itself in natural language.
Among the applications leveraging Natural Language Processing (NLP), those
related to Chatbots systems are growing very fast and present a wide range of
choices depending on the usage, each with di erent complexity levels, expressive
powers and integration capabilities. The rst distinction between the chatbot
platforms divides them into two big macro-categories: goal-oriented and
conversational. The former is the most frequent kind, often designed for business
platforms support, assisting users on tasks like buying goods or execute
commands in domotic environments. In this case, it is crucial to extract from a
utterance the intentions together with the related parameters, then to execute
the wanted operation, providing then a proper feedback to the user. As for
conversational ones, they are mainly focused on having a conversation, giving the
user the feeling to communicate with a sentient being, returning back reasonable
answers optionally taking into account discussions topics and past interactions.
The early shared aim for conversational chatbot systems was to pass the Turing
test, hence to fool the user about his interlocutor; the state-of-art of such chatbot
systems can be probed in the scope of the Loebner Prize Competition [
One of the most common platforms for building conversational chatbot is
AIML [
In this work, we present a cognitive architecture called AD-CASPAR based
on NLP and First Order Logic (FOL) Reasoning, as baseline platform for
implementing scalable and exible chatbots with both goal-oriented and
conversational features; nevertheless, this architecture leverages Question Answering
techniques and is able of combining facts and rules in order to infer new
knowledge from its own Knowledge Base. This rst prototype is not yet capable of
implementing a chatbot with complex dialog system, but di erently from other
platforms, in order to handle additional question-answer couples, the user has
to provide just the related sentences in natural language. After the agent has
parsed every sentence, a FOL representation is asserted in the Knowledge Base;
in such a process, as we will show in the next sections, the Knowledge Base is
able to act as a deductive database [
AD-CASPAR inherits most of its features directly from its predecessor
CASPAR[
This paper is structured as follows: Section 2 shows in detail all the architecture's components and underlying modules; Section 3 shows how ADCASPAR deals with polar and wh-questions; Section 4 summarizes the content of the paper and provides our conclusions, together with future work perspectives. A Python prototype implementation of AD-CASPAR is also provided for research purposes in a Github repository2.
Sensor Instance ASR CHAT Dependency
Parser MST Builder FOL Builder Uniquezer
PHIDIAS Engine
STT
Front-End Translation Service
Reactive Reasoner
Direct Commands
Parser Routines Parser
Beliefs KB Sensor Instances
QA Shifter Definite Clauses
Builder
Physical Sensors
Devices Smart Environment
Interface FOL Reasoner High Clauses KB Low Clauses KB Cognitive Reasoner
Smart Home The main component of this architecture, namely the Reactive Reasoner (central box in Fig.1), acts as "core router" by delegating operations to other components, and providing all needed functions to make the whole system fully operative.
The Knowledge Base (KB) is divided into two distinct parts operating separately, which we will distinguish as Beliefs KB and Clauses KB : the former contains information of physical entities which a ect the agent and which we want the agent to a ect; the latter contains conceptual information not perceived by agent's sensors, but on which we want the agent to make logical inference. Moreover, the Clauses KB is divided into two di erent layers: High Clause KB and Low Clauses Kb (bottom right box in Fig.1). The totality of the knowledge is stored in the low layer, but the logical inference is achieved in the high one,
whose clauses will be the most relevant for the query in exam, taking in account of a speci c con dence threshold which will be discussed later.
The Beliefs KB provides exhaustive cognition about what the agent could expect as input data coming from the outside world; as the name suggests, this cognition is managed by means of proper beliefs that can - in turn - activate proper plans in the agent's behaviour.
The Clauses KB is de ned by the means of assertions/retraction of nested First Order Logic (FOL) de nite clauses, which are possibly made of composite predicates, and it can be interrogated providing answer to any query (True or False).
The two KBs represent, somehow, two di erent types of human being
memory: the so called procedural memory or implicit memory[
As well as in human being, in this architecture, Belief KB and Clauses KB can interact with each other in a very reactive decision-making process. 2.1
This component (left box in Fig. 1) is a pipeline of ve modules with the task of
taking an utterance in natural language and translating it in a neo-davidsonian
FOL expression inheriting the shape from the event-based formal representation
of Davidson [
is represented by the following notation:
9e stabbed(e, Brutus, Caesar) ^ suddenly(e) ^ in(e, agora)
where the variable e, which we de ne as davidsonian variable, identi es the
verbal action related to stabbed. In the case a sentence contains more than one
verbal phrase, we'll make usage of indexes for distinguish ei from ej with i 6= j.
As for the predicates arguments, in order to permit the sharing of qualitative
features between predicates, whether we include (for instance) the adjective evil
related to Brutus, the 2 can be changed as it follows:
9e stabbed(e, Brutus(x), Caesar(y)) ^ evil(x) ^ suddenly(e) ^
in(e, agora(z))
Furthermore, in the notation used for this work each predicate label is in the
form L:POS(t), where L is a lemmatized word and POS is a Part-of-Speech tag
from the Penn Treebank [
The rst module in the pipeline, namely Sensor Instance, can include either a module of Automatic Speech Recognition (ASR) or a module getting plain text from a chatbot environment; the former allows a machine to understand the user's speech and convert it into a series of words.
The second module is the Dependency Parser, which aims at extracting the
semantic relationships, namely dependencies, between all words in a utterance.
All the dependencies used in this paper are part of the ClearNLP[
The third module, the Uniquezer, aims at renaming all the entities within each dependency taking in account of the words o set, in order to make them unique. Such a task is mandatory to ensure the correctness of the outcomes of the next module in the pipeline (the Macro Semantic Table), whose data structures need a distinct reference to each entity coming from the dependency parser.
The fourth module, de ned as MST Builder, is made of production rules leveraging semantic dependencies, with the purpose of building a novel semantic structure de ned as Macro Semantic Table (MST). The latter summarizes in a canonical shape all semantic features in a sentence, in order to derive FOL expressions. Here is a general schema of a MST, referred to the utterance u:
MST(u) = fACTIONS, VARLIST, PREPS, BINDS, COMPS, CONDSg where
ACTIONS = [(labelk, ek, xi, xj),...] VARLIST = [(x1, label1),...(xn, labeln)]
PREPS = [(labelj, (ek | xi), xj),...]
BINDS = [(labeli, labelj),...] COMPS = [(labeli, labelj),...]
CONDS = [e1, e2,...]
All tuples inside such lists are populated with variables and labels whose indexing
is considered disjoint among distinct lists, although there are signi cant relations
which will be clari ed shortly. The MST building takes into account also the
analysis done in [
ROOT(stabbed, stabbed) advmod(stabbed, suddenly) dobj(stabbed, Caesar) prep(stabbed, In) det(agora, The) pobj(in, agora) from the couple nsubj/dobj it is possible to create a new tuple inside ACTIONS as it follows, taking also in account of variables indexing counting: and inside VARLIST as well:
(stabbed, e1, x1, x2) (x1, Brutus), (x2, Caesar) Similarly, after an analysis of the couple prep/pobj it is possibile to create further tuples inside PREPS and VARLIST like it follows, respectively: (in, e1, x3), (x3, agora) The dependency advmod contains informations about the verb (stabbed ) is going to modify by means the adverb suddenly. In light of this, the tuple (e1, suddenly) will be created inside VARLIST.
As for the BINDS list, it contains tuples with a quality-modi er role: in the case the 1 had the brave Caesar as object, considering the dependency amod(Caesar, brave) a bind (Caesar, brave) will be created inside BINDS.
As with BINDS, COMPS contains tuples of terms related to each other, but in this case they are part of multi-word nouns like Barack Hussein Obama, which will be classi ed with the compound dependency.
The CONDS lists contains davidsonian variables whose related tuples within the MST subordinate the remaining others. For instance, in the presence of utterances like:
if the sun shines strongly, Robert drinks wine or
while the sun shines strongly, Helen smiles in both cases, the dependencies mark(shines, If), mark(shines, while) will give informations about subordinate conditions related to the verb shines; in those cases, the davidsonian variable related to shines will populate the list CONDS. In the same way, in presence of the word when a subordinate condition might be inferred as well: since it is classi ed as advmod like whatever adverb, it might be considered as subordinate condition only when its POS is WRB and not RB, where the former denotes a wh-adverb and the latter a qualitative adverb. Unfortunately, such POS-based distinction is not su cient, since also the adverb where is classi ed in the same way, which is indicative of a location where conditions related to some verbal action take place. So, depending from the domain, for achieving a comprehensive strategy in such a direction, a grammatical analysis is also required.
The fth and last module, de ned as FOL Builder, aims to build FOL
expressions starting from the MSTs. Since (virtually) all approaches to formal
semantics assume the Principle of Compositionality3, formally formulated by
Partee [
(3) As e ect of the Uniquezer processing before the MST building, which concatenate to each lemma its indexing in the body of the sentence among more occurrency of the same word, the related MST is:
ACTIONS = [(shine01:VBZ, e1, x1, x2),
be01:VBZ(e2, x3, x4)] VARLIST = [(x1, sun01:NN), (x2, ?), (x3, Robert01:NNP), (x4, happy01:JJ)]
CONDS = [e1] The nal outcome will be an implication like the following: shine01:VBZ(e1, x1, ) ^ sun01:NN(x1) =) be01:VBZ(e2, x3, x4) ^
Robert01:NNP(x3) ^ happy01:JJ(x4)
Since the MST Builder is made of production rules whom takes in account of relations (dependencies) between words, as long as such such relations are treated properly, the accuracy of the conversion from natural language can be considered equal to the accuracy of the dependency parser.
In order to obtain a disambiguation between words as well, which will be
re ected on the predicate's labels, a naive strategy (inherited from CASPAR) is
to possibly exploiting the doc2vect [
As already mentioned, this component (central box in Fig. 1) has the task of letting other modules communicate with each other; it also includes additional modules such as the Speech-To-Text (SST) Front-End, IoT Parsers (Direct Command and Routines), Sensor Instances, and De nite Clauses Builder. The Reactive Reasoner contains also the Beliefs KB, which supports both Reactive and Cognitive Reasoning.
The core of this component processing is managed by the BDI framework
Phidias [
they are syntactically combined." reasoning (in Prolog style) and lets developers write reactive procedures, i.e., pieces of program that can promptly respond to environment events.
The agent's rst interaction with the outer world happens through the STT Front-End, which is made of production rules reacting on the basis of speci c beliefs asserted by a Sensor Instance; the latter, being instance of the superclass Sensor provided by Phidias, will assert a belief called STT(X) with X as the recognized utterance, after the sound stream is acquired by a microphone and translated by the ASR or acquired from a chatbot environment.
The Direct Command and Routine Parsers have the task of combining FOL expressions predicates with common variables coming from the Translation Services, via a production rules system. The former produces beliefs which might trigger operation executions, while the latter produces pending beliefs which need speci c conditions before being treated as direct commands.
The De nite Clauses Builder is responsible of combining FOL expression predicates with common variables, through a production rules system, in order to produce nested de nite clauses. Considering the 3 and its related FOL expression producted by the Translation Service, the De nite Clauses Builder, taking in account of the Part-of-Speech of each predicate, will produce the following nested de nite clause: shine01:VBZ(sun01:NN(x1), ) =) be01:VBZ(Robert01:NNP(x3), happy01:JJ(x4)) The rationale behind such a notation choice is explained next: a de nite clause is either atomic or an implication whose antecedent is a conjunction of positive literals and whose consequent is a single positive literal. Because of such restrictions, in order to make MST derived clauses suitable for doing inference with the Backward-Chaining algorithm (which requires a KB made of de nite clauses), we must be able to incapsulate all their informations properly. The strategy followed is to create composite terms, taking into account of the Part-of-Speech tags and applying the following hierarchy to every noun expression as it follows: IN(JJ(NN(NNP(x))), t) (4) where IN is a preposition label, JJ an adjective label, NP and NNP are noun and proper noun labels, x is a bound variable and t a predicate.
As for the verbal actions, the nesting hierarchy will be the following:
ADV(IN(VB(t1, t2), t3)) where ADV is an adverb label, IN a preposition label, VB a verb label, and t1, t2, t3 are predicates; in the case of imperative or intransitive verb, instead of respectively t1 or t2, the arguments of VB will be left void. As we can see, a preposition (IN) might be related either to a noun or a verb. 2.3
This component (upper right box in Fig.1) provides a bidirectional interaction
between the architecture and the outer world. A production rules system is used
as reactive tool to trigger proper plans in the presence of speci c beliefs. In
[
This component (right bottom box in Figure 1) allows an agent to assert/query the Clauses KB with nested de nite clauses, where each predicate argument can be another predicate and so on, built by the De nite Clauses Builder module as shown in 2.2.
Beyond the nominal FOL reasoning with the known Backward-Chaining
algorithm, this module exploits also another class of logical axioms entailed from
the Clauses KB: the so-called assignment rules. We refer to a class of rules of the
type "P is-a Q" where P is a predicate whose variable travels across one
handside to another of an implicative formula, as argument of another predicate Q.
For example, if we want to express the concept: Robert is a man, we can use the
following closed formula:
(5)
(6)
8x Robert(x) =) man(x)
But before that, we must consider a premise: if predicates are built from semantic
dependencies, the introduction of such rules in a KB can be possible only by
shifting from a strictly semantic domain to a pure conceptual one, because in
a semantic domain we have just the knowledge of morphological relationships
between words given by their syntactic properties. Basically, we need a medium
to give additional meaning to our predicates which is provided by WordNet [
FI : PS ! PC
FArgs(FI ) : XSn ! YCn FI is the Interpreter Function between the space of all semantic predicates which can be yield by the MST sets and the space of all conceptual predicates PC having a synset as label; it is not injective, because a single semantic predicate might have multiple corrispondences in the codomain, one for each di erent synset containing the lemma in exam. FArgs(FI ) is between domain and codomain (both with arity equal to n) of all predicate's argument of FI . For instance, considering the MST derived FOL expression of Robert is a man:
be:VBZ(e1, x1, x2) ^ Robert:NNP(x1) ^ man:NN(x2) After an analysis of be, we nd the lemma within the WordNet synset encoded by be.v.01 and de ned by the gloss: have the quality of being something. This is the medium we need for the domain shifting which gives a common sense meaning to our predicates.
In light of above, in the new conceptual domain given by (6), the same expression can be rewritten as: where VBZ indicates the present tense of be.v.01, Robert NNP(x) means that x identify the person Robert, and man.n.01 NN(x) means that x identify an adult person who is male (as opposed to a woman).
Considering the meaning of be.v.01 VBZ, it does make sense also to rewrite the formula as: 8y Robert NNP(y) =) man.n.01 NN(y) (7) where y is a bound variable like x in (5).
Having such a rule in a KB means that we can implicitly admit additional clauses having man.n.01 NN(y) as argument instead of Robert NNP(y).
The same expression, of course, in a conceptual domain can also be rewritten as a composite fact, where Robert NNP(y) becomes argument of man.n.01 NN(y) as it follows: man.n.01 NN(Robert NNP(y)) (8) which agrees with the hierarchy of 4 as outcome of the De nite Clauses Builder.
As claimed in [
Question Answering In this section is shown how this architecture deals with Question-Answering. Di erently from its predecessor CASPAR, which works with a single/volatile Clauses KB, AD-CASPAR can count on a two-layer Clauses KB: High Clauses KB and Low Clauses KB. Every assertion is made on both the layers, but the logical inference is made only on the High one. As for the queries, whether a reasoning fails, the Low Clauses KB is used to populate the High one with relevance-based clauses, taking in account of the presence of common features between the clause-query and the clauses stored in the Low Clauses KB. Each record in the Low Clauses KB is stored in a NoSQL database and is made of three elds: Nested De nite Clause, Features Vector and the sentence in natural language. The Features Vector is made of all the labels composing the clause. For instance let the sentence to be stored be:
Barack Obama became president of United States in 2009 In this case, the record stored in the Low Clauses KB will be as it follow4: { In IN(Become VBD(Barack NNP Obama NNP(x1), Of IN(President NN(x2),
United NNP States NNP(x3))), N2009 CD(x4)) { [In IN, Become VBD, Barack NNP Obama NNP, Of IN, President NN,
United NNP States NNP, N2009 CD] { Barack Obama became president of United States in 2009
The abductive strategy of transfer from Low Clauses KB to High Clauses KB takes in account of a metric de ned Con dencec as it follows, between a records in the Low Clauses KB and the query:
Conf idencec = j T(F eatsq; F eatsc)j jF eatsqj (9) where Featsq is the Features Vector extracted from the query, and Featsc is the Features Vector in a record stored in the Low Clauses KB.
Once obtained the sorted list of all Con dences, together with the related clauses, the two most relevant clauses will be copied in the High Clauses KB. Such an operation is accomplished in a fast and e cient way by leveraging NoSQL collections indexes and the function aggregation5 of MongoDB. The threshold Con dence of the clauses admitted to populate the High Clauses KB, can be de ned at design time by changing a proper parameter in the le config.ini of the Github repository; of course, the more high the Con dence threshold the more relevant to the query will be the clauses transferred from the Low Clauses KB to the High one. 3.1
Polar questions in the form of nominal assertion (excepting for the question mark at the end) are transformed in de nite clauses and treated as query as they are, while those beginning with an auxiliary term, for instance:
can be distinguished by means the dependency aux(said, Has) and they will be treated by removing the auxiliary and considering the remaining text (without the ending question mark) as source to be converted into a clause-query.
Github repository. 3.2
Di erently from polar questions, for dealing with wh-question we have to transform the question into assertions one can expect as likely answer. To achieve that, after an analysis of several types of questions for each category6, by leveraging the dependencies of the questions, we found it useful to divide the sentences text into speci c chunks as it follows:
[PRE AUX][AUX][POST AUX][ROOT][POST ROOT][COMPL ROOT] The delimiter indexes between every chunk are given by AUX and ROOT related words positions in the sentence. The remaining chunks are extracted on the basis of the latters. For the likely answers composition, the module QA Shifter has the task of recombining the question chunks in a proper order, considering also the type of wh-question. Such a operation, which is strictly language speci c, is accomplished thanks to an ad-hoc production rule system. For instance, let the question be:
In this case, the chunks sequence will be as it follows: [PRE AUX][could][POST AUX][be][the president of
America][COMPL ROOT] where only the AUX, ROOT and POST ROOT chunks are populated, while the others are empty. In this case a speci c production rule of the QA Shifter will recombine the chunks in a di erent sequence, by adding also another speci c word, in order to compose a proper likely assertion like it follow: [PRE AUX][POST AUX][the president of
America][could][be][COMPL ROOT][Dummy] At this point, joining all the words in such a sequence, the likely assertion to use as query will be the following:
The meaning of the keyword Dummy will be discussed next. In all verbal phrases where ROOT is a copular verb7 (like be), i.e., a non-transitive verb but identifying the subject with the object (in the scope of a verbal phrases), the following sequence will also be considered as likely assertion.
in a con guration le. For further details we refer the reader to the documentation in this work's Github repository.
All wh-questions for their own nature require a factoid answer, made of one or more words (snipplet); so, in the presence of the question: Who is Biden? as answer we expect something like: Biden is Something. But Something surely is not what we are looking for as information, but the elected president of United States or something else. This means that, within the FOL expression of the query, Something must be represented by a mere variable and not a ground term. In light of this, instead of Something, this architecture uses the keyword Dummy; during the creation of a FOL expression containing such a word, the Translation Service will impose the Part-of-Speech DM to Dummy, whose parsing is not expected by the Clauses Builder, thus it will discarded. At the end of this process, as FOL expression of the query we'll have the following literal: Be VBZ(Biden NNP(x1), x2) (10) which means that, if the High Clauses KB contains the representation of Biden is the president of America, namely:
Be VBZ(Biden NNP(x1), Of IN(President NN(x2), America NNP(x3))) querying with the 10 by using the Backward-Chaining algorithm, as result it will return back a unifying substitution with the previous clause as it follows: fv 41: x1, x2: Of IN(President NN(v 42), America NNP(v 43))g (11) which contains, in correspondence of the variable x2, the logic representation of the snipplet: president of America as possible and correct answer. Furthermore, starting form the lemmas composing the only answer-literal within the substitution, with a simple operation on a string it is possible to obtain the minimum snipplet of the original sentence containing such lemmas. 4
Conclusions and Future Works In this paper we have presented a Cognitive Architecture called AD-CASPAR, based on Natural Language Processing and FOL Reasoning, capable of Abductive Reasoning as pre-stage of Deduction. By the means of its module Translation Service, it parses sentences in natural language in order to populate its KBs with beliefs or nested de nite clauses using a rich semantic. Moreover, the module QA Shifter is able to rephrase wh-questions into likely assertions one can expect as answer, thanks to a production rule system which leverages also a dependency parser. The combination of Translation Service/De nite Clause Builder and QA Shifter makes the Telegram Bot proposed in this work easily scalable on the knowledge we want it to deals with, because the user has to provide just the new sentences in natural language at runtime, like in a normal conversation.
As future work, we want to include a module for the design of Dialog Systems, taking in account also of contexts and history. Furthermore, we want to exploit external ontologies for getting richer answers, and to design an additional module inspired to the human hippocampus, to let the agent spontaneously link together knowledge for relevance in order to enhance the Dialog System.