The field of cognitive architectures is rich of approaches featuring a wide range of typical abilities of human mind, like perception, action selection, learning, reasoning, meta-reasoning and others. However, those leveraging Natural Language Processing are quite limited in both domain and reasoning capabilities. In this work, we present a cognitive architecture called CASPAR, based on a Belief-Desire-Intention framework, capable of reactive reasoning using a highly descriptive semantic made of First Order Logic predicates parsed from natural language utterances.
In the last decade, a large number of devices connected together and controlled by AI has entered in millions of houses: the pervasive market of Internet of Things (IoT). Such a phenomenon is extended also in domains other than the domestic one, such as smart cities, remote e-healthcare, industrial automation, and so on. In most of them, especially the usual domestic ones, vocal assistants assume an important role, because voice is the most natural way to give the user the feeling to deal with an intelligent sentient being who cares about the proper functioning of the home environment. But how intelligent are these vocal assistants actually? Although there can be more definitions of intelligence, in this work we are interested only in those related to autonomous agents acting in the scope of decision-making.
Nowadays, companies producing vocal assistants aim more at increasing their pervasiveness than at improving their native reasoning capabilities; with reasoning capabilities, we can intend not only the ability to infer the proper association command → plan from utterances, but also to be capable of combining facts with rules in order to infer new knowledge and help the user in decision-making tasks.
Except the well known cloud-based vocal assistants [
In light of the above, in this paper our aim is the design of a cognitive architecture, called
CASPAR, based on Natural Language Processing (NLP), that makes it possible the implementation
of intelligent agents able to outclass the available ones in performing deductive activities. Such
agents could be used for both domotic purposes and any other kind of applications involving
common deductive processes based on natural language. As a further motivation, we have to
highlight that, as claimed in [
Although cognitive architectures should be distinguished from models that implement them, our architecture can be used as domotic agent as is, after the definitions of both the involved entities and the I/O interfaces.
This paper is structured as follows: Section 2 describes the state of the art of related literature; Section 3 shows in detail all the architecture’s components and underlying modules; Section 4 shows the architecture reasoning heuristic in the presence of clauses made of composite predicates, taking into account possible argument substitutions as well; Section 5 summarizes the content of the paper and provides our conclusions, together with future work perspectives. A Python implementation of CASPAR is also provided for research purposes in a Github repository1.
The number of existing cognitive architectures has reached several hundreds according to
the authors of [
In [
The authors of [
ASR Dependency
Parser MST Builder FOL Builder Translation Service
Direct commands
Parser Routines Parser
Beliefs KB Sensor
Instances
STT Front-End
Definite clauses
Builder
Reactive Reasoner Physical Sensors
Devices Devices Groups SmarItnEtenrvfaircoenment Clauses KB FOL Reasoner Cognitive Reasoner Uniquezer
PHIDIAS Engine Smart Home inference engine which takes into account prior cases decisions and a knowledge base with a formal representation of moral quality-weighted facts. Such facts are extracted from natural language by using a semi-automatic translator from simplified English (which is the major weakness of such approach) scenarios into predicate calculus.
The DIARC architecture [
In general, probing the existing cognitive architectures leveraging NLP, we have found that most of them are limited in both domain of application and in term of semantic complexity.
The name that has been chosen for the architecture presented in this paper is CASPAR. It derives from the following words: Cognitive Architecture System Planned and Reactive, whom summarize its two main features. In Figure 1, all interacting components are depicted, filled with distinct colours.
The main component of this architecture, namely the Reactive Reasoner, acts as "core router" by delegating operations to other components, and providing all needed functions to make the whole system fully operative.
This architecture’s 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 afect the agent and which we want the agent to afect; the latter contains conceptual information not perceived by agent’s sensors, but on which we want the agent to make logical inference.
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 defined by the means of assertions/retraction of nested First Order Logic (FOL) definite 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 diferent kinds of human being memory: the so
called procedural memory or implicit memory[
As well as in human being, in this architecture the two KBs can interact with each other in a very reactive decision-making process.
This component (left box in Figure 1) is a pipeline of five modules with the task of taking a sound
stream in natural language and translating it in a neo-davidsonian FOL expression inheriting
the shape from the event-based formal representation of Davidson [
(1) is represented by the following notation:
∃e stabbed(e, Brutus, Caesar) ∧ suddenly(e) ∧ in(e, agora) The variable e, which we define davidsonian variable, identifies the verbal action related to stabbed. In the case a sentence contains more than one verbal phrases we’ll make usage of indexes for distinguish e from e with ̸= .
As for the notation used in this work, it does not use ground terms as arguments of the predicates,
in order to permit the sharing of diferent features related to the same term like it follows,
whether we include the adjective evil:
∃e stabbed(e, Brutus(x), Caesar(y)) ∧ evil(x) ∧ suddenly(e) ∧ in(e,
agora(z))
which can also be represented, ungrounding the verbal action arguments, as it follows:
∃e stabbed(e, x, y) ∧ Brutus(x) ∧ Caesar(y) ∧ evil(x) ∧ suddenly(e) ∧
in(e, z) ∧ 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 (POS) tag from the Penn Treebank
tagset[
The first module in the pipeline, i.e., the Automatic Speech Recognition [
The second module is the Dependency Parser, which aims at extracting the semantic
relationships, namely dependencies, between all words in a utterance. In [
The third module, the Uniquezer, aims at renaming all the entities within each dependency 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, defined as MST Builder, has the purpose to build a novel semantic structure defined as Macro Semantic Table (MST), which summarizes in a canonical shape all the semantic features in a sentence, starting from its dependencies, in order to derive FOL expressions.
Here is a general schema of a MST, referred to the utterance u:
MST(u) = {ACTIONS, VARLIST, PREPS, BINDS, COMPS, CONDS} where
ACTIONS = [(label, e, x, x),...] VARLIST = [(x1, label1),...(x, label)]
PREPS = [(label, (e | x), x),...]
BINDS = [(label, label),...] COMPS = [(label, label),...]
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 significant relations which will be clarified
later. 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 new a 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 like it follows: and inside VARLIST: The dependency advmod contains informations about the verb (stabbed) is going to modify by means the adverb suddenly. In light of this, a further tuple inside VARLIST will be created as it follows: (in, e1, x3) (x3, agora) (e1, suddenly) amod(Caesar, brave)
(Caesar, brave)
As for the BINDS list, it contains tuples with a quality modifiers role: in the case the 1 had the brave Caesar as object, a further dependency amod will be created as it follow: In this case, a bind between Caesar and brave will be created inside BINDS as it follows:
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, whose nouns after the first will be classified as compound by the dependency parser.
As for the CONDS lists, it contains davidsonian variable whose related predicates subordinate the remaining others. For instance in the presence of utterances like: or if the sun shines strongly, Robert drinks wine while the sun shines strongly, Helen smiles in both cases, the dependency mark will give information about subordinate conditions related to the verb shines, which are mark(shines, If) and mark(shines, while). 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; but since any adverbs are classified as advmod (as we have seen for suddenly before), it will be considered as subordinate condition only when its POS is WRB and not RB; the former denotes a wh-adverb, the latter a qualitative adverb.
The fifth and last module, defined as FOL Builder, aims to build FOL expressions starting
from the MSTs. Since (virtually) all approaches to formal semantics assume the Principle of
Compositionality2, formally formulated by Partee [
For each tuple (var, lemma:POS) in VARLIST the following predicate will be created: lemma:POS(var) which represents a noun, such as tiger:NN(x1) or Robert:NNP(x1)3. var can also be a davidsonian variable when POS has the value of RB. In such cases, the tuples represent adverbs, such as Hardly:RB(e1) or Slowly:RB(e2).
For each tuple (lemma:POS, dav, subj, obj) in ACTIONS, the following predicate will be created:
lemma:POS(dav, subj, obj) representing a verbal action, such as be:VBZ(e1, x1, x2) or shine:VBZ(e2, x3, x4). For each tuple (lemma:POS, dav/var, obj) in PREPS the following predicate will be created:
lemma:POS(dav/var, obj) where dav/var is a variable either in a tuple of ACTIONS or of VARLIST, respectively, while obj is a variable in a tuple of VARLIST. Such predicates represent verbal/noun prepositions. For each tuple (lemma:POS1,lemma:POS2) in COMPS, whose first entity lemma:POS1 is in a tuple of VARLIST, a predicate will be created as follows:
lemma:POS2(var) where var is the variable of a the tuple in VARLIST with lemma:POS1 as second entity. In case of multi-word nouns, each further noun over the first of them in VARLIST will be encoded 2“The meaning of a whole is a function of the meanings of the parts and of the way they are syntactically combined.” 3Without considering entities enumeration. within COMPS.
As for CONDS, its usage will be explained next with an example. Let the sentence in exam be:
(2) 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] It has to be noticed the numeration of the entities within each list, as efect of the Uniquezer processing before the MST building. As final outcome we’ll have an implication like the following: shine01:VBZ(e1, x1, _) ∧ sun01:NN(x1) =⇒ be01:VBZ(e2, x3, x4) ∧
Robert01:NNP(x3) ∧ happy01:JJ(4)
As already mentioned, this component (central box in Figure 1) has the task of letting other modules communicate with each other; it also includes additional modules such as the SpeechTo-Text (SST) Front-End, IoT Parsers (Direct Command Parser and Routine Parser), Sensor Instances, and Definite 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 Belief-Desire-Intention Framework
Phidias[
The agent’s first interaction with the outer world happens through the STT Front-End, which is made of production rules reacting on the basis of specific words asserted by an Instance Sensor; 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 the microphone and translated in text by means of the ASR.
The Direct Command Parser has the task of combining FOL expressions predicates with common variables coming from the Translation Services, via a production rules system. The ifnal outcome of such rules is a belief called INTENT, which might trigger another rule in the Smart Environment Interface. A similar behaviour is reserved to the Routine Parser, when subordinating conditions within an IoT command are detected; it produces two types of beliefs: ROUTINE and COND, linked together by a unique code. The belief ROUTINE is a sort of pending INTENT, which cannot match any production rule and execute its plan until the content of its related COND meets those of another belief asserted by a Sensor Instance and called SENSOR. Then, the ROUTINE belief will be turned into INTENT and get ready for the execution as direct command, as shown in lines 2, 3, 5, 7, 8 of Listing 1 in the Appendix
The Definite Clauses Builder is responsible of combining FOL expression predicates with common variables, through a production rules system, in order to produce nested definite clauses. Considering the 2 and its related FOL expression producted by the Translation Service, the production rule system of the Definite Clauses Builder, taking in account of the POS of each predicate, will produce the following nested definite clause: shine01:VBZ(sun01:NN(x1), _) =⇒ be01:VBZ(Robert01:NNP(x3), happy01:JJ(4)) The rationale behind such a notation choice is explained next: a definite 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 works only with KB made of definite clauses), we must be able to incapsulate all their informations properly. The strategy followed is to create composite terms, taking into account of the POS tags and applying the following hierarchy to every noun expression as it follows:
IN(JJ(NN(NNP(x))), t) (3) 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 intransitive or imperative verb, instead of respectively t2 or t1, the arguments of VB will be left void. As we can see, a preposition might be related either to a noun or a verb.
This component (upper right box in Fig.1) provides a bidirectional interaction between the
architecture and the outer world. In Listing 1 in the Appendix, a simple example is shown, where
a production rules system is used as reactive tool to trigger proper plans in the presence of
specific asserted beliefs. In [
Such an interface includes a production rules system containing diferent types of entities definitions and operation codes involving the entities themself, which trigger specific procedures containing high level language (e.g., lines 11 and 12 in Listing 1 in the Appendix). The latter should contain all required functions for driving each device in order to get the desired behaviour, whose implementation in this work is left to the developer. Each production rule contains also subordinating conditions defined as Active Beliefs: lemma_in_syn(X, S) checks the membership of the lemma X to the synset S, to make the rule multi-language and multisynonimous (after having defined the entities depending on the language); while, the Active Belief eval_cls(Y) lets Belief KB and Clauses KB interact with each other in a very decisionmaking process, where the agent decides either to execute or not the related plan within the square brackets, accordingly to the reasoning of the query Y; the latter in line 12-13 of Listing 1 in the Appendix is the representation of the sentence an inhabitant is at home.
Finally, this module contains also production rules to change routines into direct commands according to the presence of specific belief related to conditionals, which might be asserted or not by some Sensor Instance (see lines 2, 3, 5, 8, 9 of Listing 1 in the Appendix).
This component (bottom right box in Figure 1) allows an agent to assert/query the Clauses KB with nested definite clauses, where each predicate argument can be another predicate and so on, built by the Definite Clauses Builder module (within the Reactive Reasoner).
Beyond the nominal FOL reasoning with the known Backward-Chaining algorithm, this
module exploits also another class of logical axioms, 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 hand-side to another, with respect to the implication symbol. For example, if we want to
express the concept: Robert is a man, we can use the following closed formula:
∀x Robert(x) =⇒ Man(x)
(4)
but before that, we must consider a premise: the introduction of such rules in a KB can be
possible only by shifting all its predicates 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 [
F 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 P ; it is not injective, because a single semantic predicate might have multiple corrispondences in the codomain, one for each diferent synset containing the lemma in exam. F ( ) is between domain and codomain of all predicate’s argument of F , which have equal arity. For instance, considering the FOL expression of (4):
be:VBZ(e1, x1, 2) ∧ Robert:NNP(x1) ∧ man:NN(2) After an analysis of be, we find the lemma within the WordNet synset encoded by be.v.01 and defined 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 (5), the same expression can be rewritten as: be_VBZ(d1, y1, y2) ∧ Robert_NNP(y1) ∧ man_NN(y2) where be_VBZ is fixed on the value which identify y 1 with y2, Robert_NNP(x) means that x identify Robert, and man_NN(x) means that x identify a man.
Considering the meaning of be_VBZ, it does make sense also to rewrite the formula as: ∀y Robert_NNP(y) =⇒ man_NN(y) whrere y is a bound variable like x in (4).
Having such a rule in a KB means that we can implicitly admit additional clauses having man_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(x) becomes argument of man_NN(x) as it follows: (6) man_NN(Robert_NNP(y)) (7) which agrees with the hierarchy of 3 as outcome of the Definite Clauses Builder.
As claimed in [
The aim of the Cognitive Reasoner is to query a KB made of nested clauses that are also made closer to any possible related query, thanks to an appropriate pre-processing at assertion-time. Such a pre-processing, which creates a runtime expansion of the KB for every asserted clause, takes advantage of assignment rules for derivation of new knowledge.
The Backward-Chaining algorithm, as is, in presence of clauses where argument manipulation is required, might not be efective. To achieve such a goal, when required clauses are not present in the KB but deductible by proper arguments substitutions, the clauses evaluations at reasoningtime can be quite heavy and not feasible in term of complexity, because the process requires unifications at every single step. Instead, we will show how, by expanding properly the KB at assertion-time, the reasoning itself can be achieved acceptably. In order to obtain such a goal, CASPAR extends the radius of the nominal Backward-Chaining through the expansion of the Clauses KB with new knowledge generated starting from arguments substitutions on copies of specific clauses already asserted before.
For instance, let us consider a KB made at most of one-level4 composite predicates as follows: 4Supposing a zero-level composite predicate be P(x). P1(G1(x1)) ∧ P2(G2(x2)) =⇒ P3(F3(x3))
P1(F1(x1))
P2(F2(x2)) F1(x) =⇒ G1(x) F2(x) =⇒ G2(x)
H3(x) =⇒ F3(x)
Querying such a KB with P3(H3(x)), for instance, using the Backward-Chaining algorithm, it will return False because there are neither any unifiable literals present nor as consequent of a clause. Instead, by exploiting H3(x) =⇒ F3(x), we can also query the KB with P3(F3(x)) which is present as consequent of the first clause and it is surely satisfied together with P3(H3(x)): that’s what we define as Nested Reasoning.
Now, to continue the reasoning process, we should check about the premises of such clause, which is made of the conjunction of two literals, namely P1(G1(x1)) and P2(G2(x2)). The latters, although not initially asserted, can be obtained starting by argument substitution on copies of other clauses from the same KB. Such a process is achieved by implicitly asserting the following clauses together with P1(F1(x1)) and P2(F2(x2)):
P1(F1(x1)) =⇒ P1(G1(x1))
P1(F1(x1)) =⇒ P2(G2(x2))
Since we cannot know in advance what a future successful reasoning requires, considering all possible nesting levels, along with the previous clauses also the so-called Clause Conceptual Generalizations will be asserted:
P1(G1(x1)) ∧ P2(G2(x2)) =⇒ F3(x3)
F1(x1)
F2(x1) where the antecedent of the implication is unchanged to hold the quality of the rule, while F1(x1), F2(x1), F3(x3), as satisfiability contributors of respectively P1(F1(x1)), P2(F2(x2)), P3(F3(x3)), are assumed asserted together with the latters. In other terms, the predicates: P1, P2, P3 can be considered as modifiers of respectively F1, F2, F3.
A generalization considering also the antecedent of the implicative formula is possible only through a weaker assertion of the entire formula itself, by changing =⇒ with ∧ as it follows: ∃ x1, x2, x3 | G1(x1) ∧ G2(x2) ∧ F3(x3) which is not admitted as definite clause, being not a single positive literal. In any case, the mutual existence of x1, x2, x3 which satisfies such a conjunction, is already subsumed by the implication.
After such a theoretic premise, let’s make a more practical example considering the following natural language utterance:
When the sun shines hard, Barbara drinks slowly a fresh lemonade The corresponding definite clause will be (omitting the POS tags for the sake of readability): Hard(Shine(Sun(x1), __)) =⇒ Slowly(Drink(Barbara(x3),
Fresh(Lemonade(x4)))) Considering as modifiers adjectives, adverbs and prepositions, following the schema in Table 1: all the clauses generalization (corresponding to the first three rows of the table, while the forth is the initial clause) can be asserted as it follows:
Hard(Shine(Sun(x1), __)) =⇒ Drink(Barbara(x3), Lemonade(x4))) Hard(Shine(Sun(x1), __)) =⇒ Slowly(Drink(Barbara(x3), Lemonade(x4))) Hard(Shine(Sun(x1), __)) =⇒ Drink(Barbara(x3), Fresh(Lemonade(x4))) As said before, the antecedent (whether existing) of all generalizations remains unchanged to hold the quality of the triggering condition, while the consequent shape will range on all possible variations of its modifiers, which will be 2 with as number of modifiers. Here the adverb Hard, being common part of all the antecedents composition, is always Applied.
Although in such a case the number of generalizations is equal to 4, in general it might be quite
higher: it has been observed, after an analysis of more text corpus from the Stanford Question
Answering Dataset[
In such a scenario, of course, the more the combinatorial possibilities, the more the number
of clauses in the Clauses KB. It will appear clear, for the reader, that this approach sacrifices
space for a lighter reasoning, but we rely on a three distinct points in favor of our choice:
1. An eficient indexing policy of the Clauses KB, for a fast retriving of any clause.
2. The usage of the class Sensor of Phidias for every clauses assertion, which works
asynchronously with respect to the main production rules system, will make the agent
immediately available after every interrogation without any latency, while additional clauses
will be asserted in background.
3. We point to keep the Clauses KB as small as possible, in order to limit the combinatorial
chances. In this paper we assume the assignment rules properly chosen among the most
likely which can get the query closer to a proper candidate. As future works, a reasonable
balancing between two distinct Clauses KB working on diferent levels might be a good
solution: in the lower level (long-term memory) only clauses pertinent with the query will
be searched, then put in the higher one (short-term memory) for attempting a successful
reasoning. Similar approaches have been used with interesting outcomes in some of the
widespread Cognitive Architectures[
As result evaluation, we consider a slightly rephrased KB (Colonel West) treated in [
In Section 3.3 we have also shown how a direct command or routine can be subordinated by a clause. Although in the example (see lines 12-13 of Listing 1 in the Appendix) the production rule contains the representation of An inhabitant is at home, even a clause involving the Nested Reasoning might trigger such a rule; for instance, a simple toy scenario could include a facial recognizer among the domotic devices, which obtains information about known/unknown faces when someone is detected in the environment. Such a recognition could generate a clause representing (for instance) Robert is at home, which, combined with another clause representing Robert is an inhabitant, will produce the representation of An inhabitant is at home; the latter will trigger the production rule (related to a direct command or routine) that will turn of the alarm in the garage. This will not happen whether a thief or a domestic animal is detected, thus it provides indeed a valid example about how Beliefs KB and Clauses KB interact with each other, in a non-trivial process of deduction.
In this paper, we have presented the design of a cognitive architecture called CASPAR able to implements agents capable of both reactive and cognitive reasoning. Nevertheless we want to mark a way towards a comprehensive strategy to make deduction on Knowledge Bases whose content is parsed directly from natural language. This architecture works by using a Knowledge Base divided into two distinct parts (Beliefs KB and Clauses KB), which can also interact with each other in decision-making processes. In particular, as long as the Clauses KB increases, its cognitive features improve due to an implicit and native capability of inferring combinatorial rules from its own Knowledge Base. Thanks to the Nested Reasoning and the Clause Conceptual Generalizations, CASPAR is able to transcend the limit of the known Backward-Chaining algorithm due to the nested semantic notation; the latter is as highly descriptive as compact. Furthermore, agents based on such an architecture are able to parse complex direct IoT commands and routines, letting the user customize with ease his own Smart Environment Interface and Sensors, with whatever Speech-to-Text engine.
As future works, we want to test CASPAR capabilites with other languages than english and evaluate other integrations, like Abductive Reasoning and Argumentations. Even chatbots applications can take advantage of this architecture’s features.
Finally, we want to exploit Phidias multiagent features by implementing standardized communication protocols between agents and exploit other ontologies as well.
In this appendix, a simple instance of Smart Environment Interface is provided (Listing 1) together with an example of how Clauses Knowledge Base changes, after assertions (Listing 2).
Listing 1: A simple instance of Smart Environment Interface 1 > +STT("Nono is an hostile nation") 2 3 Be(Nono(x1), Nation(x2)) 4 Be(Nono(x1), Hostile(Nation(x2))) 5 Nono(x) ==> Nation(x) 6 Nono(x) ==> Hostile(Nation(x)) 7 8 > +STT("Colonel West is American") 9 10 Be(Colonel_West(x1), American(x2)) 11 Colonel_West(x) ==> American(x)) 12 13 > +STT("missiles are weapons") 14 15 Be(Missile(x1), Weapon(x2)) 16 Missile(x) ==> Weapon(x) 17 18 > +STT("Colonel West sells missiles to Nono") 19 20 Sell(Colonel_West(x1), Missile(x2)) ==> Sell(American(v_0), Missile(x4)) 21 Sell(Colonel_West(x1), Missile(x2)) ==> Sell(American(x3), Weapon(v_1)) 22 Sell(Colonel_West(x1), Missile(x2)) ==> Sell(Colonel_West(x1), Weapon(v_2)) 23 Sell(Colonel_West(x1), Missile(x2)) 24 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(Colonel_West(x1), Missile(x2)), Nation(v_4)) 25 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_5), Missile(v_6)), Nation(v_4)) 26 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_7), Weapon(v_8)), Nation(v_4)) 27 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(Colonel_West(v_9), Weapon(v_10)), Nation(v_4)) 28 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(Colonel_West(x1), Missile(x2)), Hostile(Nation(v_11)) 29 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_12), Missile(v_13)), Hostile(Nation(v_11)) 30 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_14), Weapon(v_15)), Hostile(Nation(v_11)) 31 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(Colonel_West(v_16), Weapon(v_17)), Hostile(Nation(v_11)) 32 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_18), Missile(v_19)), Nono(x3)) 33 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(American(v_22), Weapon(v_23)), Nono(x3)) 34 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) ==> To(Sell(Colonel_West(v_26), Weapon(v_27)), Nono(x3)) 35 To(Sell(Colonel_West(x1), Missile(x2)), Nono(x3)) 36 37 >+STT("When an American sells weapons to a hostile nation, that American is a criminal") 38 39 To(Sell(American(x1), Weapon(x2)), Hostile(Nation(x3))) ==> Be(American(x4), Criminal(x5)) 40 41 >+STT("reason") 42 43 Waiting for query... 44 45 > +STT("Colonel West is a criminal") 46 47 Reasoning............... 48 49 Query: Be_VBZ(Colonel_West(x1), Criminal(x2)) 50 51 ---- NOMINAL REASONING --52 53 Result: False 54 55 ---- NESTED REASONING --56 57 Result: {v_211: v_121, v_212: x2, v_272: v_208, v_273: v_209, v_274: v_210, v_358: v_269, v_359: v_270, v_360: v_271} Listing 2: CASPAR Clauses Knowledge Base changes and reasoning, after assertions