[Attempto] Pellet vs RACE

[Tobias Kuhn]

I just re-read my own message and encountered this mistake:

> Another problem could be that relational databases rely on the open world assumption, which is not appropriate in all situations.

I wanted to say that relational databases rely on the *closed* world 
assumption, in contrast to ontology languages like OWL that use open 
world reasoning.

Cheers,
Tobias


On 08/10/2010 02:45 PM, Tobias Kuhn wrote:
> 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