Expert System Modeling

Application of a network object-oriented knowledge base in modeling an expert system based on a semantic neural network

The implementation of a production expert system whose knowledge base is made on the basis of a semantic neural network is described. The implementation of a semantic neural network based on a network object-oriented database is described. The implementation of a network object-oriented database in the Microsoft .NET Framework 1.1 environment is described.

Features and system architecture

The main goal of this development is to create a virtual machine supporting neural networks with free topology and the number of neurons up to 2 billion in one repository. This possibility is provided by implementing the management system of the network object-oriented knowledge base (PSBN). The current version of Cerebrum CSSR is a single-user file (desktop) database. Single-user single-level transactions are supported. During a transaction, the file storage is disabled, and all changes to objects are accumulated in RAM. In the future, it is planned to implement support for hierarchical transactions, object locking, versioning (versioning) of objects, concurrent access, multi-user mode, and a client-server architecture.

The control system of the network object-oriented knowledge base has the following capabilities:

• Save the current state of the object graph or neural network in the PSBB between user sessions. Including the current topology of the network of objects. When you restart the application, you do not need to re-create the network of objects.
• With a larger number of instances of objects, limit the amount of memory used by the object graph or neural network. The most frequently used objects remain in RAM, the rest are pushed into the file storage and loaded into RAM as needed. When an instance is loaded into RAM, it displaces other, rarely used objects.
• Limiting the amount of memory allows you to get rid of the use of the paging file of the operating system, which significantly improves the performance of modeling networks with a large number of object instances (with the total size of all instances larger than the size of the current free memory in the system). In case the volume of the network of objects is less than the size of the current free memory in the system, the entire network is in RAM and there is no loss of performance associated with serialization-deserialization.
• The use of the OBJP does not impose any restrictions on the business logic used or the mathematical model of the neuron, which can be implemented as methods of the objects located in the URLR. The main requirement is to organize communications between objects in the network not by using pointers, but by using object IDs.

VNPI Core Level - storing and managing object lifetime

The core of the system includes the level of interaction with the operating system and the level of storage and management of objects. The level of interaction with the operating system must ensure that the functions of the operating system are adapted to the needs of the virtual machine implementing the neural network. The object storage level should provide storage and quick access to objects and their connections, as well as management of object lifetime. The set of APIs of all levels of the virtual machine, for definiteness, is called the Virtual Neural Programming Interface, hereinafter referred to as VNPI.

The effectiveness of the implementation language of the virtual machine kernel, emulating a neural network with many millions of emulated neurons, increased demands. The core needs to be developed considering modern component technologies. The VNPI core provides base-level components for implementing the object-network base. It includes components of interaction with the operating system, memory management with the garbage collection subsystem, management of a structured storage of objects, subsystem caching objects and managing their lifetime in memory.

Bridge Level .NET-VNPI

The implementation level of user objects should be convenient for use by application programmers. At the moment, this requirement is most consistent with the Microsoft .NET Framework. To integrate the .NET Framework and the VNPI kernel, a VNPI bridge is needed - .NET. VNPI Bridge - .NET provides access to VNPI from the .NET Framework. It also allows you to implement objects in a .NET environment driven by the VNPI kernel subsystems.

Given the different goals and requirements facing the .NET Framework and VNPI, the ideology of the garbage collection system is completely different. So in .NET, the destruction of an object is possible only after there is no possibility of using it in the current process. In contrast, in the VNPI core, garbage collection is performed when the memory allowed for object allocation has been exhausted. In this case, unnecessary objects are pushed onto the long-term storage device. Destruction of objects is part of the domain model and therefore is performed only manually. The bridge counts references to the VNPI core objects used by .NET and prevents objects from being preempted that can be accessed through calls from the .NET context.

The system has its own version of the Garbage Collector with an alternative execution algorithm. When memory is exhausted, the oldest objects are pushed onto the disk, freeing up more needed space at the moment. Thus, the objects that are in use, you need to protect against the forced unloading of RAM. If you do not lock, the object can be destroyed in memory before the end of its modification. A typical use case of a method call to a user object is as follows:

• NativeHandle someObjectHandle = ...;
• IConnector someConnector = ...;
• using (IContainer container = someConnector.GetContainer () as IContainer)
• {
• using (ICon connector connector
• = container.AttachConnector (someObjectHandle))
• {
• (connector.Component as CMyType) .MyMethod ();
• }
• }

The system itself monitors the lifetime of user objects in memory. You do not need to initiate saving objects manually. The least frequently used objects are automatically pushed onto the long-term storage system, freeing up RAM. Therefore, at any moment it is possible that the system will have to repress and destroy some kind of user object.

Level of network object-oriented base

The level of the network object-oriented database is responsible for creating instances of user objects, as well as for working with the attributes of objects. Each object of a network object-oriented database may have several attributes. The attribute values ​​can be other objects or simplest (scalar) data types. Objects of the same type (with compatible sets of attributes) are conveniently represented by tables and managed by means of a user-friendly table-oriented user interface. Objects of the same type have the same set of attributes. Therefore, it is possible to present collections of similar objects in the form of a table in which the dates are objects, and the columns are attributes of these objects.

To create objects, you must have information about their types. Means network object-oriented database, you can implement a table structure similar to the structure of a relational database. Therefore, to unify information about the types of objects used by this level, organized in the form of related tables. Information about objects registered in the system is organized in the form of several Types, Attributes, Tables tables. This allows you to define in the database the types of .NET objects in a unified form. However, the properties of tables, rows and columns in the OO database are different from the properties adopted in relational databases. An object-oriented database allows storing not rows of tables, as is customary in tabular databases, but instances of objects. In the Cerebrum.Reflection namespace, these tables correspond to the classes TypeDescriptor, AttributeDescriptor, TableDescriptor. The MemberDescriptor class is a base class from which the TypeDescriptor, AttributeDescriptor, TableDescriptor classes are inherited.

• public class MemberDescriptor: Cerebrum.Integrator.GenericComponent
• {
• public string Name
• public string DisplayName
• public string Description
• }

where Name is the name of the instance; DisplayName - friendly instance name presented to the user; Description - the description of this instance. MemberDescriptor is the base class for classes that have name, friendly name and description attributes. Many objects can have such attributes, so it is convenient to inherit such objects from MemberDescriptor.

A table column is an entity that is separate and independent from the table. The same column may belong to different tables. A table column describes some attribute of an object. The Attributes table contains information about the attributes of objects that are in a network object-oriented database. This table contains instances of the AttributeDescriptor class. An attribute descriptor describes the name of an attribute of an object. It extends the MemberDescriptor object by adding the AttributeType, AttributeTypeHandle properties and the GetTypeDescriptor () method.

• public class AttributeDescriptor: MemberDescriptor
• {
• public Cerebrum.Runtime.NativeHandle AttributeTypeHandle
• public System.Type AttributeType
• public Cerebrum.Runtime.IConnector GetTypeDescriptor ()
• }

where AttributeType returns the type of the attribute; AttributeTypeHandle returns a handle of type; GetTypeDescriptor () returns a descriptor object of the type of this attribute. If the database contains several objects that have an attribute name, then the values ​​for this attribute (column) are the names of these objects. Attributes (columns) are also objects of OODB. For example, the object attribute "Object name" also has a name, since the AttributeDescriptor class inherits from the MemberDescriptor class. Obviously, the value of the attribute "Object Name" for an instance of the AttributeDescriptor class that describes the name of the object is the string "Object name".

Consider an example. For the Name property of the MemberDescriptor object in OODD, an instance of the AttributeDescriptor object is created with the property values ​​respectively:

• Name = “Name”;
• DisplayName = “Name”;
• Description = “Object name”;
• AttributeType = typeof (System.String);
• GetTypeDescriptor () = TypeDescriptor instance describing System.String.

Thus, instances of the AttributeDescriptor class describe the properties of objects stored in OODB, including the properties of the AttributeDescriptor class itself. The Types table contains a description of data types (including user data) that are known to the system and on the basis of which the system creates instances of objects that are placed in a network base. This table contains instances of TypeDescriptor classes.

• public class TypeDescriptor: MemberDescriptor
• {
• public string QualifiedTypeName
• public Cerebrum.Runtime.KernelObjectClass KernelObjectClass
• public System.Type ComponentType
• }

where QualifiedTypeName - returns the name of the .NET class on the basis of which user objects are created, for example, “System.String”; KernelObjectClass - returns the type of the VNPI core object associated with instances of the described type; ComponentType - returns typeof (QualifiedTypeName), that is, the .NET type described by the descriptor. Properties inherited from MemberDescriptor were described earlier. Consider an example. An instance of AttributeDescriptor is created for the QualifiedTypeName property

• Name = “QualifiedTypeName”
• DisplayName = “Qualified Type Name”
• Description = “.NET Qualified Type Name”
• AttributeType = typeof (System.String)
• GetTypeDescriptor () = TypeDescriptor instance describing System.String

This structure allows you to describe the types of object classes contained in OODB. Type descriptors are also objects contained in OODB. Therefore, type descriptors describe themselves.

Each table has two collections of pointers to objects. The collection of attributes (columns) and the collection of components (rows). Each row of any table is also an object. If the pointer to the table itself is included in the collection of pointers to rows, the table will become its own row. Tables contain itself as a string. Both the Tables table and the Tables row in the Tables table are the same instance of the same TableDescriptor class. This instance is located at the same address in memory. Values ​​for the columns of the table are the values ​​of attributes of objects located in the rows of the table. And the value of its column "SelectedAttributes" is the collection of columns of the same table. Although it is desirable to keep objects of the same type in the same table — this is not at all necessary. The main thing that these objects had attributes, at least partially coinciding with the columns of this table. I recommend keeping objects in one table whose classes are inherited from some base class that contains all the columns of this table as their own attributes. For example, the column "Object name" has washed away in almost any table. Objects can be simultaneously in different tables as their rows. Object attribute descriptors are themselves objects and are registered in the attribute table. The TableDescriptor class describes a table of instances of some objects. Properties inherited from MemberDescriptor respectively describe the name, friendly name and description of this table.

• public class TableDescriptor: MemberDescriptor, System.ComponentModel.IListSource
• {
• public Cerebrum.Runtime.NativeVector GetSelectedAttributesVector ()
• public Cerebrum.Runtime.NativeVector GetSelectedComponentsVector ()
• public System.Type ComponentType
• }

where GetSelectedAttributesVector - the method returns a collection of table attributes; GetSelectedComponentsVector - the method returns a collection of rows of the table; ComponentType - the property returns the type of objects contained in the rows of the table. The GetSelectedAttributesVector method corresponds to an instance of AttributeDescriptor for which

• Name = “SelectedAttributes”
• DisplayName = “SelectedAttributes”
• Description = “SelectedAttributes collection”
• AttributeType = typeof (System.ComponentModel.IBindingList)

The GetSelectedComponentsVector method returns a collection of objects - strings; an AttributeDescriptor instance corresponds to this method.

• Name = “SelectedComponents”
• DisplayName = “SelectedComponents”
• Description = “SelectedComponentscollection”
• AttributeType = typeof (System.ComponentModel.IBindingList)

All AttributeDescriptor instances are listed in TableDescriptor.Name = “Attributes”. All TypeDescriptor instances are listed in TableTableDescriptor.Name = “Types”. All TableDescriptor instances are listed in the TableDescriptor.Name = “Tables” table. An instance of the class AttributeDescriptor.Name = “Name” is contained in the collection of rows of the Attributes table, while the attacks in the collections of attributes (columns) of the tables “Attributes”, “Types” and “Tables”. An instance of the class TableDescriptor.Name = “Tables” is stored in its same collections of strobe tables (SelectedComponents). Therefore, the use of tautology for emulating DDB based on RDBD is justified and useful. It should be noted that instances of objects can simultaneously be included in different tables, while it is important that they support all the attributes that are columns of the tables in which they appear as rows.

The user has the ability to create new tables by adding new entries to the Tables table. Created instances of tables, attributes, and other objects do not need to be registered in the corresponding tables either. However, the practice of registering such objects in the corresponding tables is recommended, as it allows changing their attributes through a unified user interface. The requirement is to register a custom type in the Types table. In this case, Integrator.Acivator will automatically create a new instance if necessary. Otherwise, the programmer will be obliged to implement his own version of the IActivator interface.

Full-featured C # objects are supported in OODB, methods, properties, fields, and events are supported for objects. In this development, the static methods of the classes are just ordinary static methods in .NET and the instance methods are the usual methods of objects. It is recommended to create properties for the attributes supported by the class. The mechanism of delegates and events will not be supported if the connection is implemented between objects stored in the database. This is due to restrictions on the lifetime of copies. At the time when the database is stopped, all objects are stored in a serialized (serialized) form. If the lifetime of the receivers or sources of messages can be isolated from the lifetime of the database objects, then the mechanisms of the delegates - messages work within the subnet of the objects deployed in the .NET Framework memory. The system is developed primarily to support neural networks with a free topology and the number of neurons up to 2 billion in one repository. Therefore, only part of the OO DB is currently in RAM. Most of the objects are frozen in the file storage and deserialized as needed.

Semantic Neural Network Level

The next logical level is a neural network. The neural network is based on the VNPI core. Each neuron is a collection of objects of simpler objects. Neurons can be of various types. The most interesting are neurons receptors, effectors and internal neurons. In order to emulate the simultaneous parallel operation of a set of neurons on a sequential computer, it is necessary to sequentially process the states of all neurons in the network for each time slice. Consider the implementation of the quasi-parallel processing of neurons in the semantic neural network that implements the expert system. The performance of neurons in the neural network is performed by bars. Tacts are performed until the moment when there is not a single neuron in the network that needs to be processed. After completion of all cycles on the effectors, the current decision made by this section of the network is displayed.When the information on the receptors changes, new cycles are launched, and after they end, the specified solution is set up on the effectors. The work of the expert system takes place either in one cycle, by setting all the input fuzzy data on the receptor layer, or iteratively, as this data is accumulated. Each measure consists of several passes. The pass is a mailing of messages to all registered neurons. At the same time, for each neuron, a special function is performed by the message handler corresponding to the given message.