The main task required for the solution is how to ensure that the knowledge base corresponds to the current knowledge in this domain and how to ensure their continuous improvement.
The relevance of knowledge (knowledge base) is achieved in three main ways (Dodonov and Landje 2011; Kryazhych 2015; Gribova and Kleshchev 2016): adaptability (interactive change of the knowledge base), adaptability - using KBSs machine learning methods (means of inductively generating knowledge from selected precedents, means of knowledge discovery from “big data”, or a combination thereof).
The “success” of adaptability (interactive change) depends on the domain ontology and the user interface of the knowledge base editor, which must meet the requirements and expectations of domain experts. At the same time, the ontology is a structural basis of both tools for experts (editing tools) and software components of KBSs (solvers of intellectual problems and user interfaces).
Thus, the traditional architecture of KBSs - “knowledge base (KB) + fact base + intellectual problem solver + intellectual GUI” (Finn 2014) - expands with a new component: “ontology + knowledge base + fact base + ontology-oriented problem solver + intellectual GUI”.
5.1 Architectural properties of systems based on declarative knowledge
In the domain ontology, the types of statements (allowing solving domain problems) and restrictions on the interpretation of the meaning of concepts (terms) are defined. For example, for the diagnosis of processes, one of the most common types of sentences (statements) is < deviation classk, characteristicj, range of valueskj of characteristicj>; sentences like “a necessary condition for the existence of the process”, “a variant of the process of changing the values of the attribute”, etc.).
The knowledge base contains domain knowledge that is presented explicitly. They are generated manually or inductively, including from training samples from archives and databases (inductive generalization in machine learning (Finn 2014), Bayesian classifiers, clustering algorithms, and reinforced learning (Nikolenko and Tulupiev 2009; Golenkov et al. 2018)).
The base of facts contains a set of facts (statements) observed or objectively measured in the situation under consideration, regarding which the problem is being solved.
The explicit representation (and grouping) in the ontology of all structural types of statements (and the separation of the ontology from the knowledge base) necessitates the "replacement" of decision-makers, interpreting production rules, with specialized ontology-based algorithms.
An ontological-oriented algorithm (ontological reasoner) searches for or refutes hypotheses bypassing the (declarative) knowledge base. Such an ontology-oriented problem solver “sorting through” the KB statements of each type related to the hypothesis. He compares these sentences of input information (about the object). The algorithm for bypassing the knowledge base and comparing its statements with the elements of the structure of domain objects is generally simple, because the number of “matching rules” is determined by the types of KB statements corresponding to the problem being solved.
The implementation of the bypassing the declarative knowledge base mainly consists in searching for the values of input data in the knowledge base. (Example: the implementation of the bypassing the declarative Diagnostic Knowledge Base usually consists in searching for the values of the signs (symptoms) of the diagnosed object and comparing them with the areas of (expected) values in order to reject or confirm the corresponding hypotheses about the classes of deviations). Thus, the “structural” complexity of an ontology-oriented algorithm is usually small. Its complexity is determined by:
• The number and complexity of the types of axioms (statements) of the ontology,
• The length of the chains of cause-effect relations between the hypotheses and observations – the elements of the description of the domain objects,
• The number of observations (description elements) of the objects and/or the number of restrictions / target conditions, for example, in the designing problem, the conditions will relate to the sizes and different properties of the constructed object (bridge, hardware complex, ...); in the treatment task restriction is “the object must become healthy”). The processing time (calculation) depends on the size of the knowledge base.
Such solvers can become reusable, because, firstly, a set of traditionally solved problems (diagnostics, forecasting, control, designing, planning ...) is known (Clancey 1985; Kleschev and Shalfeeva 2015), and secondly, a traditional set of types of relationships in domains with cause-effect relations (for solving the problems of diagnostics, forecasting, and object state control) (Clancey 1985; Kleschev and Shalfeeva 2015) is limited. Reuse consists in choosing a task in accordance with the classification of tasks and their correction in accordance with the domain characteristics (additional types of relations in the ontology), finding a problem solver and, possibly, adapting it to the format of the result of the work (explanation).
Using an ontology to form a knowledge base, data (facts), as well as an explanation structure makes it possible to generate a user interface (GUI) in terms (concepts) that are understandable to a specialist, and also, as a rule, generate a dialogue scenario corresponding to the structure of explaining the results.
KBSs as a variety of software can also:
• Include databases for storing reference or other information,
• Accept files or databases with operational information (about the situation regarding which a decision is required),
• Create as a result files or databases with the results of the work and an explanation of solution.
Thus, viable system of explainable AI should include: knowledge base described in terms of ontology, ontology-based solver (it can to put forward and explain hypotheses), ontology-dependent adaptive and adaptable user interface. It is high-level architectural design model of KBS.
The most characteristic properties of KBSs related to viability are:
• Regular updating of knowledge base;
• The admissibility of the improvement of the decision-making method;
• The permissibility of changing or adding functions (for example, the formation of additional results);
• Adaptability of the user interface due to changes in the input data;
• The permissibility of expanding the ontology (adding concepts, relationships).
Changes in the ontology, as a rule, lead to the adjustment of all components of KBSs; in this case, it is advisable to talk about a new version of the KBS.
As a result, the structure of KBS and its components does not require changes due to the current maintenance and sustainable development (Chhabra 2017).
5.2 Ontological approach to support and evolving of KBSs
Ontology more often corresponds to one class of problems being solved or to one class of problems in one subject area. To design applied KBSs, not one ontology may be required, but their set of ones for interconnected problems. The examples of related problems are diagnosing and fix-planning or predicting.
A toolkit for constructing application systems with declarative knowledge is based on the ontology of the subject area, since algorithms process information from subject area. An formalized information being processed in their algorithms is a laws of the subject area, a real facts, an archived data and documents stored.
Knowledge and other information should be formed in terms of unified terminological concepts of subject area and in accordance with the structure determined by ontology of domain - ontology of knowledge and of reality's data. Ontological agreements on the rules of matching facts to knowledge should be known to developers of algorithms for solving problems.
Let's call the toolkit that allows create KBS components on base of domain ontology the specialized development environment for KBSs.
A specialized environment for manufacturing and development of knowledge-based systems should at least provide:
• KB Editor,
• Database Editor,
• Editor of solution results' explanations structure,
• A library of reusable software solvers corresponding to the classes of tasks to be solved
• A library of software units (the components of software solvers),
• Search and selection tools for KBS components - KBs and software solvers,
• Tools for integration of knowledge bases and solvers,
• Specialized UI editor.
Note
In a situation where the possibility of making changes to domain ontology is not ruled out even after building knowledge bases, manufacturing environment of KBSs should provide an ontology editing tool. The introduction of additional concepts or new relationships between concepts in the ontology does not violate operability of AI software solvers. The ontology-oriented solver has this property because it processes only concrete types of sentences from Knowledge Base.
To form the solvers you will need:
• Coding tools for new software units (SU) or their new versions,
• Tools \ means of Cataloging of SU for reuse,
• Tools of integrating of reusable units and new ones into new solvers or their new versions.
Note
The ability to create program units for the solver may turn out to be unnecessary if the ready-made solver is according with the statement of the problem, and “building up” additional functionality is not supposed.
The complete architecture framework of knowledge based system is < set of KBs, set of software solvers, set of UI- components, set of factBases, set of software units>.
Due to the importance of developing and evolving knowledge bases, only those KBSs that are integrated with knowledge base management system (KBMS) should be seriously considered. So the software components for evolving and checking of knowledge bases are desirable to be the part of the “integrated architecture”. Then the manufacturing environment has to provide:
• Tools of checking and assessing of knowledge bases,
• Tools of evaluating quality of knowledge bases by archives of solved problems,
• Tools of inductive formation of knowledge bases or fragments of knowledge bases.
KBS acquire the aforementioned vitality properties with these KBMS tools from specialized environment for its development.
The property 1 - support for updating knowledge.
The property 2 - support for changing configuration of an ontology-oriented solver (in connection with the replacement of a component that implements a different decision strategy or method of obtaining the result, or in connection with the addition of a component that implements an additional function, for example, generating an additional result).
The property 3 - Support for improving the UI in connection with a change in functions.
The property 4 - support for change in ontology.
The property 5 - support for improving UI of the expert (and UI of the user) in connection with updating the ontology.
The property 6 - support for coding new versions of software units of an ontology-oriented solver or support for solver code changes. The example of changes is adaptation of algorithm of processing Knowledge Base in connection with updating an ontology of knowledge.
5.3 An example of the implementation of KBSs manufacturing environments
The example of tools for creating environments for manufacturing of KBSs is the instruments implemented on the IACPaaS platform for processing ontological information resources (such resources are being generated in terms of an explicitly presented ontology or “meta-information”) (Gribova et al. 2018). The ontology defines the rules for forming information, and the limitations of its interpretation. The structure of the information generated and a number of interpretation restrictions are determined by the users of the IACPaaS platform for their own information resources formation. Usually a cognitologist makes this work for the community of experts, specialists, and users.
KBSs is a special case of applicated software services on the IACPaaS platform (IACPaaS services) (Fig. 1).
This toolkit also contains tools for managing software components of KBSs (Fig. 2):
• “Master” of the formation of declarative parts of SUs (IACPaaS agents),
• Solver constructor from the root IACPaaS agent and processing agents (they are being represented only by declarative part),
• Generator of code workpieces (blanks) for new IACPaaS agents (or new versions),
• Byte code loader integrated with declarative part of agent,
• Tools for testing SU and preparing them for the library of SUs (agents).
The set of tools for formation of KBS’ information components is as follows:
• IACPaaS ontology editor (Fig. 3a),
• IACPaaS-editor of knowledge base, generated in terms of ontology with a self-adaptive UI (when changing an ontology) (Fig. 3b),
• IACPaaS Data Base Editor (with self-adaptive UIs) (Fig. 3c).
This toolkit also contains tools for managing software components of KBSs:
• "Master" of the formation of declarative parts of SUs (IACPaaS agents),
• Solver constructor from the root IACPaaS agent and processing agents (they are being represented only by declarative part),
• Generator of code workpieces (blanks) for new IACPaaS agents (or new versions),
• Byte code loader integrated with declarative part of agent,
• Tools for testing SU and preparing them for the library of SUs (agents).
IACPaaS agents are encoded in Java. The Java Development Kit (JDK) for Java SE 8, 9, … 13 is recommended for writing source codes and creating agent byte codeThe environment for KBS manufacturing implies coding of new versions of agents (when it is necessary to process new terms or new relations of terms) or coding of new IACPaaS agents (when it is necessary to make a change in the decision-making process). JDK can be local to the programmer (or hosted on the IACPaaS platform).
Note
On the IACPaaS platform, the “master” of formation declarative parts of solver and SU are both the Editors generated in terms of corresponding meta-information. This meta-information is the part of ontology of the IACPaaS technology. A self-adaptive UI for forming data and knowledge and for viewing the results of KBSs provides three visualization views, one of which is graphical.
Thus, the manufacturing of KBSs using ontology-oriented environments fundamentally increases their viability by significantly increasing the role and share of controls (for making changes to declarative components) vs. coding and factoring tools (for making changes to the source code).
The KBS design technology in the proposed environment provides for a sequence of activities.
1. Create a problem ontology or search for ready-made ontologies of knowledge base about a particular task and data ontologies. If the IACPaaS platform does not yet have a portal for the problem under consideration, then the knowledge engineer uses the Ontology editor to create a resource "Knowledge ontology" — a description of a set of concepts, relationships, and restrictions used by specialists when solving problems (and / or when transferring knowledge between specialists). It should be sufficient to provide all the necessary knowledge about the decision process. One of the most important works is the formation of the domain thesaurus (names of objects, their attributes, and possible values for each attribute or ranges of values). Often, an engineer, together with an expert, fixes a set of rules for making decisions, called "agreements".
2. Formation of the knowledge base by the domain experts. It is important to note that the IACPaaS platform has a Knowledge Base Editor Generator that automatically generates expert-oriented editors based on the knowledge ontology. As a rule, the creation of KB is a collective process..
3. Designers and programmers create new software components (if a portal with an already created solver is not found on the IACPaaS platform). To do this, the designer uses the Ontology editor to create an Ontology of explanation (the result of KBS's work must be an explanation). Next, the solver components (agents) are declared and implemented using software engineering methods.
Note
Creating the solver and knowledge bases are parallel processes. Some library may already contain a set of solvers or program units (agents) for the problem to be solved. Then creating a solver is not required. The main work is reduced to the formation of new knowledge. The ontological framework ensures the compatibility of components within the formed portals.