This paper reports on a program for the development of cognitive systems based on user specifications expressed in Natural Language in the form of high-level guidelines for the desired behaviour of those systems. Language analysis from existing NLP tools is used to generate scenarios based on the users' description of their preferences in the provision of the service by the system. These scenarios are combined with the SoDA Methodology to develop and generate an argumentation theory that captures the guidelines of operation given in the natural language description of the user. The intended architecture of a fully automated system that generates argumentation based cognitive systems from natural language is presented, together with a first analysis of the challenges posed and evaluation of progress in addressing them. This system is called Gorgias-NL, reflecting the central task of the approach to provide a natural language interface to the Gorgias argumentation system.
We are today experiencing a dramatic increase in the
interest of developing systems that have a human-like
behaviour in providing personalized services to users. This
is mainly driven by the market for systems that will be able
to help people in their every day life in a naturally
intelligent way. Such systems, fall under the area of Cognitive
Systems
For example, we would like a user to be able to specify her/his guidelines for their own Cognitive Assistant for online shopping in the following manner: “The quality of food is very important for me. When possible try to economize. I like to eat organic food. I am not diabetic but I like to avoid sugary foods. I prefer not to eat red meat except for special occasions.” This would be followed by implicit evaluations of purchases suggested or made by the cognitive assistant, e.g.: “The fish last night was very good but not enough.” Such advanced expressions of specification forms the ultimate final goal of our work, namely, to be able to automatically capture these natural language specifications and their contextual meaning so that we can build automated systems whose operation is influenced or governed by these guidelines. This goal can be addressed, to a large extent, modularly in two stages. In the first stage the challenge is the linguistic extraction of (i) the predicate relations expressed in the natural language text and (ii) the preference meaning conveyed explicitly or implicitly in the text.
This preference information is relative amongst different entities at various levels, e.g. in the example above a preference of quality over economy is expressed as well as that of organic food over non-organic food. Terms like quality or economy of food do not have a full meaning until they are immersed into common sense knowledge in the context of the application discourse. Acquiring, organizing and using the relevant common sense knowledge forms a second part of our program for the development of these systems, outside the scope of this paper. 1.1
The basis of our approach will be that of argumentation and
its computational form as developed in Artificial Intelligence
over the last two decades (see e.g.
Specifically, our approach aims to produce, from the
natural language user guidelines, an argumentation theory
composed of arguments, a conflict relation between arguments
and preference information that would give strength of some
arguments over others. As mentioned above, we will separate
the task into two phases. In the first phase we use standard
Natural Language Processing (NLP) tools, such as that of
Stanford Core NLP
Preference information is also based on the linguistic analysis of the text and patterns of expression in the text which contain implicitly the preferences of the user. The aim is to capture these through refined scenarios where the options sanctioned differ from those of the more general scenario. For example, we would have a general scenario where “food that contains red meat is sanctioned as not suitably to buy” but a refined scenario of “food that contains red meat for a special occasion is sanctioned as suitably to buy”. Sometimes this would be clear from the text but not always. For example what is the preference of the user above for food of high-quality but also of high-price? Such combined scenarios could be put to the user for expressing more directly her/his preferences or could be kept “in mind” by the system waiting for further information on the possible user preference.
The consideration of combined application scenarios
follows the SoDA (Software Development through
Argumentation) Methodology
Our approach is implemented in a system, called GorgiasNL, whose aim is to pipeline together these different stages of analysis from the natural language text of the user to the Gorgias argumentation code that captures this. 1.2
Our approach falls within the general effort of developing
human-like AI systems that link directly with their human
users in Natural Language. Such systems include proprietary
personal assistants, e.g. Alexa, Cortana, Siri, and Google
Assistant. Their development is driven by their direct link
to the market and they use methods targeted to the specific
needs of their application. Google Assistant1 and Alexa2 use
phrase matching, which triggers the appropriate action or
event. Siri3 registers specific vocabulary to identify user’s
intents. Cortana analyses queries using bag-of-words models
and a classifier, after eliminating noise (non-alphabetic and
non-English words) and applying stemming
Other notable assistants are the open-source projects Lucida4 and Mycroft5. Lucida uses OpenEphyra, a Java framework, as an internal parser to extract textual information and answer queries, plus a Wikipedia database stored in Lemur’s Indri format. Mycroft’s parsers take in a sentence and attempt to find user’s intention by searching for matching words and phrases from registered intents and vocabulary.
In comparison, our approach rests on argumentation as a principled foundation for capturing human reasoning. The emphasis is not so much on the underlying learning technology for analysing natural language input but on the subsequent use of the information extracted. Our aim is to attempt to give this information a symbolic logical form, using argumentation as a basis for common sense logical reasoning, rather than a direct operational meaning. Also unlike many methods for Natural Language Understanding our linguistic analysis does not aim to translate directly the text into some formal logical (classical or non-classical) language but rather to form typical scenarios or partial models that capture the meaning of the text.
After a brief review of argumentation, the next section describes the extraction of the predicate relations expressed in the natural language text. It also gives the overall architecture of the Gorgias-NL system that implements our approach. The functionality of the system is illustrated through an example of scenario generation and argument extraction. The initial evaluation, challenges concerning open NLP problems, and the challenges emerging through our development and evaluation process are presented in Section 4. Finally, in Section 5 we conclude with a brief description of future work needed to complete our program of work.
2
In this section we briefly review the basic theory of
argumentation on which our approach rests and the SoDA
Methodology used for developing the argumentation code that
capture the user’s guidelines. This framework was proposed in
Application requirements are captured via argumentation theories composed of arguments at different levels. Object level arguments support the possible decisions, or options, in the specific application domain, while first-level priority arguments express preferences on the object level arguments in order to resolve possible conflicts. Higher-order priority arguments are also used to resolve potential conflicts between priority arguments of the first or subsequent levels.
Argumentation theories are expressed in this framework in the language of rules and priorities on rules. An argumentation theory is a pair (T ; P) whose sentences are rules of the form L Body, where Body is a conjunction of positive or negative literals. Rules in T capture argument schemes for building object level arguments. On the other hand, rules in P represent argument schemes for building priority arguments. The head L of these rules has the general form, L =pref er(rule1; rule2), where rule1 and rule2 are atoms naming two rules and pref er refers to an (irreflexive) higher priority relation amongst the rules of the theory.
The semantics of an argumentation theory is defined via
the standard notion of admissibility within an abstract
argumentation framework < Args; Att > associated to any given
theory (T ; P). In this the attack relation is defined through
the conflicts between literals or between opposing priorities,
prefer(r,r’) and prefer(r’,r) and a notion of relative strength
for the attacking argument that is build through the priority
rules that the arguments contain (see
The simplicity of this argumentation framework facilitates the systematic “Software Development for Argumentation”(SoDA) methodology for developing applications of argumentation through a process of directly mapping the user or system requirements to an argumentation theory. The main feature of this methodology is the incremental consideration of scenarios in which the developer is asked to state the default preferred behaviour (i.e. preferred options) of the system and subsequently to consider refinements of the scenarios where this preference changes. The methodology concentrates on scenarios where conflicting options can occur and for each such case a process of refinement is initiated. A tool, called Gorgias-B (http://gorgiasb.tuc.gr), helps the developer to consider his/her application according to the SoDA methodology and offers a high-level environment through which the software code of the underlying argumentation theory is automatically generated.
The important characteristic of the methodology that stems from the declarative nature of the underlying argumentation framework is that the interaction with the developer is carried out in the high-level application language and hence no technical knowledge is needed by the developer. This is very important in our work as it indeed allows the users to express their requirements in Natural Language without the need to consider how this will be mapped into an argumentation theory or rules and priority rules.
Our approach is based on extracting typical scenarios representing the user’s preferences from the text document. A two step process is used. First, initial scenarios are extracted via a natural language analysis. Subsequently, the SoDA Methodology is applied, where the combined and refined scenarios are extracted. These scenarios constitute a complete argumentation software which implements the user’s preferences. 3.1
A Cognitive Assistant must be capable of extracting the general and specific contexts via language analysis, without the need for detailed operational instructions. The user’s language and vocabulary used in this domain consist of a subset of a Natural Language concerning everyday tasks.
The user will set the general guidelines and probably place an emphasis on distinct cases, possibly expressing exceptions to the guidelines s/he sets. This interaction has not necessarily an order or a time frame. New guidelines or exceptions can arise, as the user needs, the environment, and the cognitive system evolve. A guideline can contain conditions, exceptions, actions, or any combination of them.
The extraction of guidelines and preferences involves finding important words of a sentence and generating a knowledge representation corresponding to the user’s guidelines. Combined with a representation of commonsense knowledge, the Cognitive System can reason over user preferences and user queries expressed using the same subset of Natural Language. These would typically provide information about the user’s current needs and request a recommendation on what decision to take. The query, considers the current environment of the user and returns options that fall under the personal guidelines of the user. 3.2
Gorgias-NL is based on a modular design, which is depicted in Fig. 1. All modules can function independently, and they communicate using simple specifications. Firstly, the user’s text input concerning preferences and policies, is processed by the NLP module. The NLP module relies on state-ofthe-art NLP software to obtain the language analysis for the given text input. Language analysis includes coreference resolution, i.e. determining possible expressions that refer to the same person, object or thing. At the current stage of implementation, those are performed by Stanford NLP, but any other software that outputs CoNNL-U data can be used with minor modifications.
Afterwards, the module responsible for scenario extraction uses the language analysis input to generate the preliminary scenarios. Although developed as a module for Gorgias-NL, it can be used independently as it generates conditions and options/actions from natural language. Within Gorgias-NL, the generated scenarios capture the user’s general preferences.
Scenario generation is followed by application of the SoDA Methodology, to obtain the refined scenarios which capture the general user preferences. They form a consistent set of arguments, to be later used at the decision level. Text Input
Speech to text
The derived final argumentation software captures the preferred guidelines of operation of the user, while being consistent. Combined with the common sense knowledge, the environment, and user specific knowledge, queries can be answered or actions can be taken.
For the scenario generation, the prototype is using a strict grammar-to-model parser. Syntactic structures are translated to predicates, along with their corresponding terms, in order to extract the first level symbolic information. Predicates derived from the root of the sentence, identify the option or the decision of the scenario. An overview of this is as follows: Copular Verbs The predicate is the conditional clause, while the subject is a term (e.g. “the coupon is out-of-date” generates the predicate out of date(coupon)). Auxiliary Verbs At this initial stage of our work we are assuming that auxiliary verbs do not form part of the predicate. Such verbs can qualify the predicate and its link to other information in the sentence but this would only be important if it makes a difference on a typical scenario. Verbs The other verbs are predicates, while their respective subjects, objects, and noun modifiers are terms. In the domain of a “cognitive assistant”, a greater focus needs to be given in imperative mood.
Adjectives Adjective phrases are predicates, and the corresponding noun is the term (e.g. “Pick up some cheap wine. . . ” is cheap(wine)).
Adverbs Adverbs and adverb phrases can be terms (e.g. “Wake me up tomorrow” is wake me up(tomorrow)), or can be ignored.
Prepositions Prepositions are used as a variation of the predicate (e.g. “When I’m at work. . . ” is at work), or can be ignored.
Lemmatisation Predicates and terms are lemmatised. Exceptions to this include gerund, participles, and past tense. Preference Several adverbs and prepositions can state explicitly a user preference (e.g. “Normally allow calls”, “I prefer fish over meat”).
This analysis can ignore some words of a sentence. While
some information can be lost, it is not always essential.
Similar to
The generated scenarios are of the form <scenario id, sentence id, fConditionsg, Options>. The notation is as follows: scenario id is a number used to identify the scenario, sentence id is a list of numbers corresponding to the natural language sentence(s) which the scenario refers to, Conditions is a list of zero or more predicates defining the context that constitutes the scenario, and Options is a list of one or more predicates corresponding to decision options and which are valid in the scenario.
To illustrate how scenarios are extracted from the guidelines text consider the following example concerning the management of discount offers. “Normally, discard coupons. If a coupon is related to my wish list, save it, unless it is expensive. If a coupon offers a large discount, save it. Discard the coupons that are out-of-date.” After coreference resolution and language analysis performed by Stanford NLP, the scenario generation yields the following scenarios: <1, 1, fg, discard(Coupon)> <2, 2, frelated to(Coupon,wish list)g, save(Coupon)> <3, 2, fexpensive(Coupon), related to(Coupon,wish list)g, neg(save(Coupon))> <4, 3, flarge(discount),
offer(Coupon,discount)g, save(Coupon)> <5, 4, fout of date(Coupon)g, discard(Coupon)>
As shown above, each sentence can generate more than one scenario, e.g. if an exception is included. The latter part of the second sentence “unless the coupon is expensive” implies an additional scenario which includes the extra condition expensive(Coupon) and the unique option neg(save(Coupon)). This option is derived from the initial natural language sentence which does not provide an alternative option, thus the negation is used. For simplicity, we will assume that we have additional information to identify the two options of not saving and discarding. 3.4
Given a set of primary scenarios extracted directly from the text as in the above example we then need to consider combinations of these scenarios to further capture the guidelines. The SoDA methodology helps us to consider such combinations in a structured and systematic way. For example, considering the combination of scenarios 2 and 5 we get a new combined scenario: <6, f2,4g, frelated to(C,wish list), out of date(C)g, fsave(C), discard(C)g> where initially both options are possible. At this stage, we consider the task of making a combined scenario more deterministic by trying to ascertain if the user has some (implicit) preference in such a scenario. For example, we can use pragmatic information that comes from the common sense knowledge that typically out of date coupons to give preference to the discard option. This is a heuristic process that can also be captured through argumentation, namely using the common sense and practical information to support arguments for the various options in a combined scenario, as in the example above where we have a strong argument to discard. In cases, where it is not possible to decide in favour of a smaller set of preferred options in a combined scenario we can either ask the user for extra information on this or we can wait until some information that can help with this is acquired by the cognitive assistant. In our running example one possible outcome of this process could give the following combined scenarios. <7, f3,4g, flarge(discount), offer(C,discount), out of date(C)g, discard(C)> <8, f2,3g, fexpensive(C), related to(C,wish list), large(discount), offer(C,discount)g, fsave(C), discard(C)g> <9, f2,3,4g, fexpensive(C), related to(C,wish list),large(discount), offer(C,discount), out of date(C)g, discard(C)>
An algorithm is then applied that results in the generation of a Gorgias argumentation theory from such context scenarios extracted from the text. This algorithm first constructs a context graph that puts scenarios in levels from the more general contexts to more specific ones. The context graph is a graph whose nodes correspond to scenarios. The nodes have a name (corresponding to a scenario), a set of options that are valid in the node’s scenario and a level integer. Its root (first node that has only outgoing edges) is a node named true.
The algorithm to transform scenarios to such a graph starts from the “true scenario” at the root and then gradually adds scenarios from simple ones to more complex connecting with an edge those that are more specific contexts of others. Fig. 2 shows this initial graph for our example. Note that each node has its name on its label. For simplicity of representation, and since we only have two options, the valid option at each node is denoted by the colour of its background, white for discard(C) and grey for save(C). Hence a note which is half white and half grey, e.g. node 4.1, designates that both options are possible. The context graph is refined in two passes. The first one removes all edges that connect nodes whose source node and target node have the same set of options. The second pass removes all nodes that are not the root and there is no edge having them as targets. The final context graph for our example is shown in Fig. 3.
The algorithm then transforms the context graph into a structure called threads in the SoDA methodology. This considers any path from the root to a leaf for each pair of options and creates a corresponding thread by defining all the possible contexts - combinations of conditions - from the most general to the more specific, under which a decision between a pair of options is reached. In general, a thread, T ij , is based on a pair of conflicting options Oi and Oj , and is a sequence, fP kg (1 k n), where each P k has the form, P k =< Sk; Cikj ; Cjki >, where Sk; Cikj ; Cjki are sets of scenario conditions, such that Sk = Sk 1 [ Cikj 1 [ Cjki 1 (and hence S1 S2 ::: Sn). Here Cikj and Cjki are contextual conditions (possibly empty) such that Oi is preferred over Oj in the consistent scenario Sk [ Cikj and Oj is preferred over Oi in the consistent scenario Sk [ Cjki.
Hence, in a thread based on two conflicting options we iteratively consider (consistent) refinements of an application scenario and at each such level, k, of iteration new contextual information is considered, denoted by Cikj or Cjki, under which one of the options is preferred over the other. Contextual information can be given for none of the preferences (in which case both Cikj and Cjki are equal to the empty set), for one or for both preferences between the two options Oi and Oj . In the special case of the contextual information not imposing any further refinement of the current scenario, i.e. when Cikj = ftrueg (or Cjki = ftrueg), we have a default preference (at level k) of Oi over Oj (resp. Oj over Oi) and the thread stops.
Algorithm 1 shows the process of transforming the context graph to threads. Figure 4 shows the four threads for our example. The first thread T1 is given below, where it should be noted that the node with two valid options causes the T1 thread to fork creating T12 and T11: for each pair of conflicting options do for each path that contains these options do
Start a new thread for each node starting from the root to the leaf do add P level =< Slevel = fnode nameg; Ciljevel = fg; Cjleivel = fg > if (Oi is valid in node)) then
Ciljevel = ftrueg if (Oj is valid in node)) then
Cjleivel = ftrueg if Ciljevel 6= fg ^ Cjleivel 6= fg then
This is the special case where both options are valid in this node. Fork the thread and make the Ciljevel = ftrueg in the existing thread and Cjleivel = ftrueg in the other thread for each next node starting from level towards the leaf do if (Oi 2 option(next node)) ^ Ciljevel = fg then
Ciljevel = fname(next node) name(node)g node = next node
Algorithm 1: For generating the scenarios graph T 1(O1 = discard(C); O2 = save(C)) = f P 0 =< S0 = ftrueg; C102 = ftrueg;
C201 = frelated to(C; wish list)g >; P 1 =< S1 = frelated to(C; wish list)g;
C112 = fexpensive(C)g; C211 = ftrueg >; P 2 < S2 = frelated to(C; wish list);expensive(C)g;
C122 = ftrueg; P 3 =< S3 = frelated to(C; wish list); expensive(C); large(discount); off er(C; discount)g; C132 = fout of date(C)g; C231 = ftrueg >; P 4 =< S4 = frelated to(C; wish list); expensive(C); large(discount); off er(C; discount); out of date(C)g;
C142 = ftrueg; C241 = fg >g T 12(O1 = discard(C); O2 = save(C)) = f P 3 =< S3 = frelated to(C; wish list); expensive(C); large(discount); off er(C; discount)g; C132 = ftrueg; C231 = fg >; T 11(O1 = discard(C); O2 = save(C)) = f P 1 =< S1 = frelated to(C; wish list)g;
C112 = fout of date(C)g; C211 = ftrueg >; P 2 =< S2 = frelated to(C; wish list); out of date(C)g; C122 = ftrueg; C221 = fg >g
From the threads we can automatically generate a
corresponding Gorgias argumentation theory that captures the
arguments for each of the options involved in a thread and
their relative strength at each level of the thread. This is done
by generating argument rules that support the priority of one
argument rule over another at the previous level. The full
details of this are omitted due to lack of space. They can be
found in
The generated argumentation theory can be executed using the Gorgias-B tool (http://gorgiasb.tuc.gr) to reach decisions under given current circumstances. For our coupons example, given a specific coupon c1 for which we know it offers a large discount Gorgias-B will return the decision save(c1) together with the explanation: “When [offer(c1, discount), large(discount)] choose save(c1)” based on the arguments that support this decision. If in addition we know that this coupon is out of date (e.g. as time passes) Gorgias-B will now return the decision discard(c1) together with the new explanation: “When [offer(c1, discount), out of date(c1), large(discount)] prefer discard(c1) over save(c1)”.
These explanations can now be transformed into natural language to be presented to the user if and when requested. 4
Our initial evaluation sought to establish evidence for the feasibility of our approach, to uncover possible weaknesses in the implementation and to point out future challenges. We describe here briefly our plans for evaluation of our approach. 4.1
There is no widely accepted evaluation data or tests relevant to the domain of a cognitive assistant. In order to obtain a preliminary evaluation of the prototype system, we asked a group of users to express their preferences in a very short paragraph in natural language, on a task of their own choice. The generated scenarios captured satisfactory the overall preferences of roughly 70% of the sentences expressed by the users. Examples of user preferences are: (i)“Categorize work emails by their code in the subject. If I’m cced, put the email in the relevant folder. If the email is personal, read the subject of the email to me, except if I’m at a doctor.” and (ii) “If I have a meeting with a client, make sure the appropriate documents according to the client are on my desktop. If I have a meeting with Mr. Doe interrupt us after 10 minutes with something urgent! Remind me to pick up my kids every day at 3:00 except from Tuesday, when you should remind me at 1:00.”. Examples like the last two sentences were only partially captured, due to duration, date and time mentions, which the prototype did not support during the evaluation stages.
We have used this evaluation exercise to help improve our natural language parser into scenarios. In future we will continue to perform such evaluation exercises, with larger groups of users, for early feedback on the system’s performance.
We also note that the evaluation process has reveal interesting and useful information about how human users perceive cognitive systems/assistants. For example, initially no user expressed a high-level policy or an exception within a policy. Some users expressed simple if-then rules or simple commands (those are excluded from the above results). Other users, initially expressed sentences containing an excessive amount of non-essential information. More complex cases with exceptions, and without inessential information were expressed after an example was given, or after specific instructions to express themselves more freely, as in a conversation with an “intelligent” human. One example concerning a shopping assistant, specified by a user, is the sentence “I would like you to inform me or alert me when you find through Google medium dresses for the summer in green or white colour.”, which our parser failed to capture. After a request to repeat the same guideline as it would be addressed to a human personal assistant, the user rephrased the sentence as “Tell me if you find medium summer dresses in green or white.”, which the parser captured. This raises interesting questions about how people perceive an artificial cognitive assistant and how thus they behave when interacting with such a system. 4.2
Challenges concerning the interaction of the user with a cognitive system through automatic NLP include:
Language analysis, coreference and ellipsis resolution of NLP software is not, yet, perfect. Furthermore, the analysis of complex sentences depends on the right punctuation of user’s input. One example is the phrase “If I have a meeting with a client, make sure the appropriate documents, according to the client, are on top of the desk”. Depending on where the commas are, the language analysis differs, and the respectively generated scenarios do not necessarily capture the user’s preferences.
Language variability: Reasoning on the generated scenarios can be impossible without using the context, even for relatively simple inputs. Consider the following sentences: Normally allow calls. If an advertiser calls, don’t answer the call. If the parser is strictly based on grammar and structures, the generated first scenario is <1,1,fg,allow(Call)>. In the second sentence, the word “calls” is a verb, unlike the word “calls” in the first sentence which is a noun and the direct object. That will lead to different predicates and terms comparing e.g. to the sentence “Deny calls from advertisers”. Moreover, the possible different predicates e.g. allow, answer and deny, don’t answer, are the same, respectively, in the context of how to handle a phone call, given this simple policy. Communication between human and computer in a context of a Cognitive Personal Assistant requires identification of the type of a sentence. A given sentence can be a query (e.g. “Where is my car?”), a command (e.g. “Turn off the lights.”), a fact (e.g. “I parked my car at. . . ”), or part of a policy (e.g. “Normally discard coupons.”). Identifying the type of the sentence is can benefit from work on question and intent classification.
Together with these challenges we also plan to explore other state of the art methods and tools for NLP such as neural networks with grammar-to-model training, or the use of Combinatory Categorial Grammars, e.g. openCCG 6 and compare their utility.
5
We have presented the design of Gorgias-NL, an argumentation-based system for building cognitive personal assistants, together with its first implementation. Gorgias-NL is based on a modular design, which uses a NLP parser that generates scenarios from user guidelines and a module following the SoDA methodology to generate an argumentation theory capturing the guidelines.
We plan to continue the process of further development of the system together with an evaluation with human users so that we can test early the ecological validity of our design decisions. In a fully automated system we aim to allow the user to confirm or not its recommendations or if the user wishes to engage into a (structured) dialogue with the system in order to be persuaded or not about the recommendation of the cognitive assistant. This dialogue will form a new input for the system that could enrich the argumentation theory capturing the user’s guidelines.
The most important future development is that of exploring the use of common sense knowledge in the approach and the design of our systems. Its use will be important at various levels. For example, it can be used in helping to understand implicit preferences of the user and thus resolve conflicts when we consider combinations of scenarios under the SoDA Methodology.
Common sense Knowledge will also be important when
our cognitive systems, once build, are deployed in a real
environment where they will need to decide on what options
are best suited for their users. During their execution they
will need to link the current “sensory information” that the
system will be getting from its application environment with
6http://openccg.sourceforge.net/
the high-level concepts used to express the personal user
guidelines. Common Sense Knowledge will help recognize
which of these high-level concepts hold in any given current
situation and hence which arguments apply in the current
case of reasoning by the system. This recognition can be
done as a subsidiary argumentation process on the beliefs of
the system based on common sense arguments, sanctioning
them from the sensory information framework (see