RacerPro 2.0 : A system overview:
System core: The inference engine
RacerPro has an onion-like architecture. The reasoning kernel in the middle is the core of the system and implements a highly optimized tableaux calculus for deciding the ABox consistency problem of the description logic SRIQ(D-) (w.r.t. a background TBox). Certain highly optimized special-purpose inference procedures for sublanguages of SRIQ(D-) are integrated in the kernel as well and applied automatically whenever applicable to the input problem for maximal performance. The sound and complete inference algorithm with the highest performance is thus selected automatically.
Formats and syntaxes
Ontologies or knowledge bases can be feed in various syntaxes and formats into RacerPro: for example RDF(S), OWL Lite, OWL DL, and a native Racer Syntax (an extended KRSS format), etc.. Regarding OWL syntax, the user can chose between "OWL XML" syntax, or use the standard "OWL RDF/XML" serialization. Also, OWL1.1 functional is supported (to be upgraded to "OWL2 functional" soon). The new expressive means and axiom types of OWL2 are already recognized and supported on a syntactic level by the input parsers of RacerPro 2.0. Internally, these knowledge bases / ontologies are always translated into SHIQ(D-) (or a sublanguage), no matter what syntax is used. Instance data (e.g., RDF data) is represented in the so-called "ABox" (assertional box), whereas the background knowledge (axioms) are represented in the so-called "TBox" (terminological box). Consistency of these two boxes can be checked individually, e.g., consistency of an OWL document then means that the TBox as well as the ABox is consistent. The maximal supported DL of the kernel is still SHIQ(D-), so expressive means such as nominals in OWL DL, or the complex role inclusion axioms of OWL2 and the new role axioms of OWL2 (irreflexivity etc.) are currently ignored for reasoning. For classic description logic knowledge bases, either Racer native or DIG syntax is available.
Input/output connectivity
Knowledge bases and/or ontologies in any of these formats can either be loaded (and also saved!) via file IO, or via a variety of server interfaces. RacerPro supplies two socket-based interfaces — the full functionality of RacerPro is provided over the native TCP socket, offering a heavily extended KRSS-like API. Also, a completely new API for supporting the OWLAPI (the so-called "NOSA" API) is available over the native TCP socket.
Whereas the native IP socket offers a Lisp/KRSS-like string-based API over TCP, the HTTP/DIG socket supports two "XML over HTTP"-based protocols, namely DIG, and its successor, OWLlink. Both use an XML-based syntax. Whereas DIG uses a proprietary XML syntax for its messages and (concept) arguments, OWLlink build on standards such as OWL(2) XML for the message arguments. Both protocols offer tell and ask messages. However, OWLlink supports many more messages and queries than DIG, and also supports OWL2 (unlike DIG, which wasn't intended for OWL at all).
APIs
A numer of standard tools such as Protege 3, Protege 4, and RacerPorter, as well as custom applications attach to RacerPro through the interfaces described next. For AllegroGraph, Gruff can be used, the RDF triple store browser of Franz Inc. Protege 3 uses DIG, and Protege 4 the OWLAPI.
OWLAPI
Regarding the OWLAPI, the native socket offers the new set of API functions dedicated to support the abstractions and methods of the OWLAPI — the NOSA-API. Many OWLAPI tell and ask functions, as well as the OWL2 axioms types, and the core abstractions of the OWLAPI (reasoners, ontologies, axioms, changes, supported query functions, ...) have direct correspondences in the NOSA, thus making the implementation of a Java-side OWLAPI adapter much easier and, regarding processing speed, much faster then without the NOSA API. Still, a reasoner adapter is required for the Java-side of the OWLAPI Java-framework. The RacerPro adapter, exploiting the NOSA, is available from Olaf Noppens / Ulm University.
JRacer
Whereas for Java programmer the OWLAPI is the perfect solutions, other programmers which have HTTP and XML processing frameworks available should simply use the OWLlink protocol and talk to the HTTP/DIG socket of RacerPro in order to access its services. In order to exploit the full functionality, however, the native socket must be used. Also, sometimes a HTTP / XML processing framework can cause too much overhead, and a more lightweight solution can do the job. The JRacer library offers a simple socket-based solution for RacerPro clients in Java. With JRacer, Java client programs can send native RacerPro messages as strings to RacerPro via a socket connection to the native socket, and receive RacerPro's results as Java strings. The parsing and transformation of these strings into meaningful Java object graphs, however, is left to the client.
LRacer
A similar solution if available for Common Lisp users, which can use the LRacer library. Here, the whole native RacerPro API is available as Lisp functions and macros, so there is no need to compose request strings and parse them. Instead, Common Lisp data structures are used (S-expressions). The ideal solution for Lisp programmers.
Extensibility
RacerPro is not only extensible with plugins (which are the analog of the class files of Java and have to be supplied either by Racer Systems or by someone who can operate a Common Lisp compiler), RacerPro also offers is own extension language called MiniLisp which can be used to define "ad hoc" server extension in a termination-safe functional programming language.
Unique rule and query engine (nRQL)
nRQL is the ABox query answering machine of RacerPro. It supports unions of grounded conjunctive queries with additions and is relationally complete, i.g., supports classical negation, negation as failure, and "closed domain" universal quantification (the (neg (project-to ...)) construct). Internally, SWRL rules are mapped to nRQL rules. nRQL ABox queries can also be posed in Sparql syntax. This turns RacerPro into an OWL inference-aware Sparql ABox query engine, since also the inferred rdf:type predicates and inferred (OWL) object properties are considered. RacerPro is currently the only OWL DL inference-aware Sparql engine on the market. However, this only works for Sparql queries which represent ABox queries.
nRQL also offers some unique features, such as non-recursive Horn rules with CWA negation and abductive query answering w.r.t. to a TBox and a set of such Horn rules. Recently, an ABox difference operator has been implemented, and some aggregation (count, sum, ...) operators have been added to nRQL as well.
nRQL queries are optimized and compiled into machine code which gives the engine a good performance. Moreover, the engine supports concurrent queries and is thus multi-threaded. Incremental query answering (tuple-at-a-time) and set-based query answering (set-at-a-time mode) is supported, as well as incomplete query answering modes which have some similarity with what is now called RDFS++ query answering.
In combination with the server programming language MiniLisp, nRQL is very flexible, since users can define new query atom predicates in MiniLisp, or add computed items to a knowledge base using nRQL rules and lambda expressions in rule consequences, etc. MiniLisp can do all kinds of things, e.g., create KBs programmatically, create HTML reports from query reports, etc.
Persistency and triple store
RacerPro 2.0 includes AllegroGraph 3.2, the Web 3.0 RDFS++ database of Franz Inc. RacerPro 2.0 can use AllegroGraph as an ontology repository. RacerPro can read OWL XML/RDF or RDF(S) data from an AllegroGraph triple store. Also, RacerPro 2.0 can be used to create AllegroGraph triple stores, or to materialize OWL inferences in AllegroGraph triple stores. The triple stores created in that way can visualized and operated upon with other tools from Franz Inc., e.g. the RDF(S) browser "Gruff".
Moreover, AllegroGraph offers a W3C Sparql engine. Whereas nRQL can process only a subset of Sparql, but takes the OWL DL semantics of rdf:type and of the properties seriously (e.g., takes transitivity etc. into account), the integrated Sparql query answering engine of AllegroGraph can be used if full (but plain) W3C RDF Sparql querying answering without OWL DL inference is required. The full W3C Sparql standard is available over sparql-answer-query if :native t is supplied. Also, there is an RDFS++ query answering mode in which the AllegroGraph Sparql engine does some shallow taxonomic OWL reasoning (regarding subclassing of OWL classes without complex definitions), and also considers some properties of OWL object properties, e.g., transitivity, domain and range restrictions, etc. These queries even work on the persistent database and are thus not limited by main memory, unlike the nRQL queries.
The integrated AllegroGraph with its Sparql engine allows to create an ontology repository. RacerPro can materialize inferences in that repository, and the materialized inferences in the persistent RDF TripleStore can be queried with Sparql without having to worry about main memory limitations during query answering. However, materialization relies on a proper segmentation of the repository so that RacerPro 2.0 can load a segment at a time into main memory and compute the inferences for that segment. For one segment, main memory must not be exceeded.