# A Modular Framework for Domain-Specific Conversational Systems Powered by Never-Ending Learning
## 3 Architecture
### Natural Language Processing  
The NLU and NLG are the application natural language modules. Both need some adaptation for the specific domain. The NLU module classifies the sentences and identifies the named entities, some of which are domain-independent and domain-dependant. The approach proposes a reduction in rework when using the framework by having the intent classification be domain-independent, which could be one of the following classes: greetings, goodbye, perform, inform, confirm, and not confirm. These intents are enough for the completion of tasks and question-answering in most domains. Should a new intent be added, it would be necessary to change the NLU to produce the new classification and update Policy to handle this intent.  
Other required classifications can be domain-dependent, such as operation, sentiment, and question type. One important aspect is that every possible label for each classification has a one-to-one mapping with an ontology element so that the ontology has the knowledge to address any inquiry detected by the NLU. With this mapping, it is easy for Knowledge Management to find the correct ontology element that the sentence is referring to; the ontology searches for the node with the classification label, and its properties or related nodes are sent to the other modules. This relevant approach allows for the Belief Tracker and Policy modules to process the dialog based on only the intent and Knowledge Management, and thus, it does not need to be changed for new domains unless a feature with a particular dialog flow is needed.  
Figure 4: Proposed scalable architecture of the dialog system framework. Green arrows indicate synchronous communication and blue arrows indicate asynchronous communication.  
The context-independent slots filled by the NLU can be carried out by a general named entity recognition system that recognizes, for example, names, places, and dates. The domain-specific slots, which are needed for the tasks supported by the dialog system and their associated external application, can be implemented by some sentence-tagging algorithm, for example, using a recurrent neural network [19]. It is essential that the slot label also has a one-to-one mapping with ontology elements in both cases. Since Knowledge Management can deliver the mandatory slots for a supported operation, the Policy module can then verify if these slots are filled before triggering an execution for an external application. This approach can be easily used if the slots produced by the NLU have the same label as the required operation properties in the ontology.  
The NLG module can be implemented using templates for each possible action taken by the dialog system, with placeholders for the response slots [3]. Another way is to have a generative model, eliminating the need for the designer to plan all possible responses and create a unique template for each. A machine translation model is an especially well-suited model; it can transform a set of triples from the ontology into a natural language sentence [20]. With this approach, the knowledge of what should be given in response is also contained in the ontology of the system.  
The data needed to train the models of these modules can be created by domain specialists of a curatorship team, who know the users' behavior and language and can produce examples similar to what the user will say with the dialog system. An approach to reducing the amount of manual work and accelerating the application of the framework is to have a semi-automatic process of corpus creation.