Next: Acknowledgement Up: Conclusion Previous: The main results Contents
There are some improvements which can be applied to the current system, concerning both its design and implementation issues. There are the following domains they may be applied to:
The decomposition may go a little bit further, as it was described in Section 8.3. Full decomposition of predicate arguments could be worth investigation. Such a decomposition is not provided right now because of the performance reasons.
This full decomposition is especially tempting along with an attempt of tight integration of the inference engine and the database. Such an experimental database could be created. A pretty straightforward choice is starting with an existing database (see Section 10.1) i.e. PostgreSQL. PostgreSQL uses system catalogs heavily, which provide information about data types, relations, attributes, inheritance, integrity constraints, etc., so extending them towards inference is feasible and could be interesting. Extending the functionality of the system catalog and the tight integration by tapping into the query processor could evolve the database towards fully functional Relational-Deductive Database Management System. What is more, it would be even in the PostgreSQL spirit. It has always been an experimental RDBMS incorporating many unique and modern features (which does not imply that it is not a productive environment).
The second improvement is design and implementation oriented. Currently the system is written as a hybrid of C and Prolog languages. Such a choice was made because of the way how the communication among the user, database, and inference engine, is provided, and because of the performance reasons. Having C language, ODBC transmissions can be handled efficiently, and the ODBC driver can be created easily. Furthermore, C language can interact with the inference engine through its foreign language interface.
But Prolog could be used instead of C language as well. Most of the modules of ReDaReS may be rewritten in Prolog, perhaps except for the ODBC Server (see Section 11.3 and Figure 10.5). Then a better design could be achieved in terms of the code behind the application, however the performance could suffer. This issue could be investigated.
The third improvement concerns uploading Extensional Knowledge to the inference engine. As it was pointed out before, the preload method works more efficient than the on demand one. However, there is a drawback: extensional knowledge has to be downloaded from the database, before the inference process may take place. Because of that, starting the inference process is delayed, not mentioning memory overhead - the data is uploaded and stored by the inference engine.
To improve this technical issue the two methods of acquiring data: the preload and on demand, could be combined together, creating a smart buffered preload. The smart buffering should download extensional knowledge from the database, only when it is necessary for the current inference process. When the inference engine tries to consult extensional knowledge, it can be downloaded from the database in chunks. If the inference engine requests more extensional knowledge, a new chunk is brought. Each time a chunk in downloaded it should be merged with extensional knowledge the inference engine already possesses. As soon as the first chunk arrives the inference may proceed. Downloading chunks should be transparent to the inference engine. Technically, it could be solved using dynamic database capabilities of Prolog language and the foreign language interface.
Another proposed improvement is a CAD system which can be used to support the design of intensional knowledge. Creating such a tool is not complicated from a technical point of view, as long as the logical programs are modularized and decomposed into relations. However, there is a separate issue here. It concerns knowledge representation and visualization. So, the CAD system should provide an easy, intuitive, and powerful way for the design of Jelly Views.
And last but not least, the database can be populated with ready-to-use modules. The modules are decomposed Prolog clauses which can be applied to solve some typical problems like: common Subset Selection Problems, Tree or Graph Traversal etc. It can make the system more user friendly. A user without any knowledge about Prolog language programming could use such modules to solve a given problem.
Igor Wojnicki 2005-11-07