Skip to content

ObdalibQuestConfiguration

Guohui Xiao edited this page Sep 18, 2013 · 4 revisions

Configuration

The behavior of Quest, the way it deals with data and OBDA models, the optimizations it applies, and every aspect of the query answering process in Quest is configured by the user at initialization time. Now we list the relevant configuration parameters.

Note that the default configuration that ships with Quest generally offers the highest performance. You should only need to modify the mode in which Quest is working according to your needs, either virtual or classic OBDA modes. Changes in the rest of the parameters should only be done if you are experimenting with the reasoning techniques.

General configuration parameters

  • org.obda.owlreformulationplatform.reformulationTechnique. Possible values: (PerfectRef, UCQ-based). Indicates which rewriting techniques should be used.'PerfectRef' direct implementation of the PerfectRef algorithm as defined in the paper "DL-Lite: a tractable family of description logics". UCQ-based is a reformulation algorithm based on the basic principles of PerfectRef, however improved in many ways to avoid the generation of redundant queries.
 '''RECOMMENDED VALUE''': UCQ-based
  • org.obda.owlreformulationplatform.aboxmode. Possible values: (classic, virtual). Indicates if the Quest should work on classic or virtual mode.
  • org.obda.owlreformulationplatform.optimizeEquivalences. EXPERIMENTAL. Possible values: (true, false). Optimize the TBox used by Quest during reformulation by locating equivalences between classes and properties, and removing all but one class/property per equivalence set. RECOMMENDED VALUE: true

Classic-Mode only parameters

  • org.obda.owlreformulationplatform.dbtype Possible values: (direct, semantic) Indicates how to construct the database repository to store the ABox/data of the system. RECOMMENDED: semantic
 * DIRECT: this is a simple way to create the interntal database schema, one table per class, one table per property.
 * SEMANTIC: A way to construct the interntal database that already takes into account the semantics of the ontology and allows to considerably simplify the rewriting process. The particular technique is called ''Semantic Index'' (see publications related to Quest).
  • org.obda.owlreformulationplatform.obtainFromOntology. Possible values: (true, false) Tells Quest to import data triples (i.e., ABox assertions) from the input ontology or not.
  • org.obda.owlreformulationplatform.obtainFromMappings. Possible values: (true, false) Tells Quest to import data triples (i.e., ABox assertions) from the input OBDA model or not.
  • org.obda.owlreformulationplatform.optimizeTboxSigma. EXPERIMENTAL. Possible values: (true, false). Optimize the TBox using information about the state of completeness of the internal database repository, as described in the article "Dependencies: Making OBDA work in practice". This optimization only acts when the data repository is a "semantic index" repository. RECOMMENDED VALUE: true
Clone this wiki locally