[Attempto] Pellet vs RACE

[Tobias Kuhn]

Hi George,

> For layer 2, if complex statements not likely to involve gobs of memory could be
> identified, i'd start them right away at low priority rather than waiting, to
> conserve cpu and user time.

This seems to be a good approach to me. I see one major problem (or 
challenge): when the ontology is changed while such a low priority 
reasoning task is running, the result of the reasoning process is 
potentially outdated.

> As you say, retaining performance with scale has to be solved to achieve non-R&D
> utility.  What about the idea to stick the wiki data in a SQL engine?  Is
> modern, Turing-complete SQL too incapable somehow compared with Prolog?  Would
> Datalog be a cost-effective compromise?

In order to avoid confusion, we should be clear about what kind of 
languages in what kind of situations we are talking about.

SQL is primarily a language for querying and modifying data bases, even 
though SQL can also be used as a programming or knowledge representation 
language. You can *represent* knowledge in SQL in several ways, but SQL 
is mostly used to *query* and *modify* knowledge. (I use "knowledge" and 
"data" synonymously here.) The databases themselves implement a form of 
the relational database model that does not directly depend on SQL. This 
relational database model corresponds to a subset of first-order logic, 
and overlaps with OWL (because n-ary relations are supported, it is not 
a subset of OWL). More complex facts can be expressed in SQL with the 
"CREATE ASSERTION" keyword. It would be interesting to investigate how 
SQL databases could be used to store complex knowledge relying on 
relation tables and assertions (probably this has already been done...). 
However, I assume that current database management systems are not 
optimized for a high number of highly complex assertion statements. 
Thus, you might end up with a performance loss instead of a gain. 
Furthermore, I assume that SQL assertions are only checked against the 
relation data but not against each other. Another problem could be that 
relational databases rely on the open world assumption, which is not 
appropriate in all situations.

Prolog builds upon a subset of first-order logic (i.e. Horn clauses). 
Note that we use Prolog only as a programming language, but not as a 
knowledge representation language. ACE is translated into Discourse 
Representation Structures (DRS), which are a notational variant of 
first-order logic. These DRSs can be represented in Prolog but without 
making use of the Horn clause semantics of Prolog. DRSs can be 
represented in Prolog, as OWL can be represented in XML. Prolog or 
Datalog can be used as knowledge representation languages for 
ontologies, but they lack many useful features, e.g. negation (other 
than negation as failure).

The bottom line is that languages like SQL or Datalog can certainly be 
worth exploring as alternatives for AceWiki, but it's definitely more 
than just "to stick the wiki data in a SQL engine".

For these reasons, I try to improve AceWiki with the current approach of 
using OWL reasoners. With the latest version of AceWiki, external 
reasoners like FaCT++ can be used, which greatly improves the 
performance of AceWiki. Furthermore, the reasoning in AceWiki can now be 
restricted to a certain OWL 2 Profile (EL, QL or RL). In this way, 
complex statements are not considered for reasoning, and the knowledge 
base can grow much bigger without negative performance effects. I just 
had the idea that the statements that are excluded this way could still 
be checked for consistency against the core knowledge base, but not 
against each other (like assertions in SQL). This could be done 
manually, or periodically in an automatic way.


Cheers,
Tobias