Ontop Preferences

Ontop offers many different preferences for users to configure it considering their needs. Ontop can be configured both from the Protege plugin and from the source code.

Configure Ontop from the Protege Plugin

Go to Launcher -> Preferences -> Quest to configure Ontop preferences.

####First Order Reformulation

Enable Query Rewriting: This mode indicates if the query should be rewritten w.r.t. the TBox during query answering. Query rewriting is necessary in such cases that the concepts and roles for atoms in query have many sub-concepts and sub-roles according to TBox.

####Data Configuration Ontop presents two kind of data configuration mode: Virtual ABox and Classic ABox. This configuration defines how data assertions are given to the system.

Virtual Abox Mode: In this mode Ontop functions as a mediator, located on-top of the data source linked to the ontology by means of mappings. Ontop gets as input an RDFS/OWL2QL ontology and an .obda file which includes a set of mappings. By using the mappings, Ontop translates SPARQL queries over the ontology into SQL queries over database.

Classic ABox Mode: In this mode Ontop gets as input an ontology and data triples/ABox assertions. In this respect, Ontop works similarly to a traditional OWL reasoner or triple store. The interesting aspect of this mode is that Quest uses the same mechanism for query answering as the one used in virtual mode. That is, Quest will also use an OBDA model and a RDBMS during query answering; however, in this case the database (schema and data) and the mappings of the OBDA model are defined and managed by Quest itself.

1. Schema organization strategy of Classic ABox: This indicates how to construct the database repository to store the ABox/data of the system. The options for shema organization strategy are Direct and Semantic Index.

• Direct: In this mode Ontop creates one table per each class/property.

• Semantic Index: In this mode Ontop uses one table for each type of assertions, i.e., class, object, and data property assertions (in the last case one for each value domain). In these tables, the class or property is determined by a numeric id (idx) and a set of numeric intervals. The assignment of ids to classes and properties is done taking into account the TBox. In this way the value of idx encodes the implied hierarchical structure of TBox.

2. Database location: This configuration determines the location of the database that will serve as ABox repository in classic mode.

• In-Memory (H2-DB): By enabling this configuration, user lets Ontop to create an H2 in-memory database to hold the ABox.

3. Data Source(s): This mode indicates where the ABox should be read from. The options for this configuration are From active ontology's ABox and From the current mappings in the OBDA model.

• From active ontology's ABox: This option indicates that the ABox data should be read from the loaded ontology.
• From the current mappings in the OBDA model: This option indicates that the ABox data should be read from the OBDA model. Ontop materializes the triples into an in-memory h2 database which are mapped from database to ontology.

Configure Ontop from the Source Code

User should create a .properties file to configure ontop preferences and should set DEFAULT_PROPERTIESFILE string to the name of .properties file. Otherwise default Ontop configurations (i.e. QuestDefaults.properties file) will be in charge.

Content of an example configuration file is as following:

rewrite=true

org.obda.owlreformulationplatform.reformulationTechnique=TreeWitness org.obda.owlreformulationplatform.optimizeTboxSigma=false org.obda.owlreformulationplatform.optimizeEquivalences=true org.obda.owlreformulationplatform.aboxmode=classic

org.obda.owlreformulationplatform.dbtype=semantic org.obda.owlreformulationplatform.obtainFromOntology=true org.obda.owlreformulationplatform.obtainFromMappings=false