ObdalibQuestModes - ConstantB/ontop-spatial GitHub Wiki
Quest can work in two modes that determine the location of the data about individuals, these modes are described in this page.
This mode is one of the main features of Quest. In this mode, Quest will read the intentional knowledge from the ontology (e.g., subClassOf axioms, subPropertyOf axioms, etc.), however, the data about the individuals will be inferred from the '''mappings''' of an OBDA model.
More importantly, the data is kept in the data source, it is always fresh and it does not utilize more space that the one it already uses. If your data source is a database federation tool you can also do semantic data integration in virtual mode.
Quest relies on query rewriting techniques to do reasoning.
The performance of the virtual mode depends of several factors. One basic factor is the speed of the SQL queries used in the mappings. If have a lot of data and use computationally expensive queries (e.g., aggregations, group by, etc.) you might bring down the performance of the system. To keep performance high try to assure fast queries in the mappings, making sure that you have defined appropriate indexes in columns that will be used for JOINs or WHERE clauses.
A second aspect that affects performance is the number of queries generated by quest during the query reformulation process. At the moment, Quest only implements basic query rewriting in virtual mode. This has as a consequence that queries that involve many mappings and big hierarchies might have bad performance. This will be solved when we implement the T-mappings methods described in the paper Dependencies: making ontology based data access work in practice. This method is the equivalent of the Semantic Index technique available in the Classic mode and produces similar boosts in performance.
Overall, you can already expect very good performance in Virtual mode. We have been able to get split-second response time for many use cases, even in the presence of large databases (> 100GB).
This mode is the usual mode for OWL reasoners, i.e., Quest reads all the data of the ontology from the input (e.g., from the OWL ontology) and uses this data to answer the users queries.
Behind the curtains, Quest still relies on the virtual mode to implement the classic mode. In particular, Quest reads the data about individuals from the ontology, and creates an H2 database to store the data. The structure of the database created by quest depends on the your choice, which can be direct or semantic index. For best performance always use Semantic Index mode
In this mode, Quest stores the data in tables similar to universal tables. Quest will create two tables concept[x, idx] and role[x,y,idx] and uses those tables to store the ABox assertions (i.e., the data triples). Quest assigns an index to each Class and Property of the ontology, and uses these indexes when it stores the data. The peculiarity of this mode which allows Quest to provide excellent performance is that these indexes are not arbitrary, they are computed from the knowledge of the ontology itself in such a way that Quest can use range queries to retrieve data associated to a hierarchy, instead of unions of queries.
This method is a way to expand data virtually. In comparison with RDFS forward chaining reasoning, virtual data expansion sometimes allows for dramatic savings in storage with (almost) the same performance. For more information about the semantic index technique and virtual expansion please see the publications about dependencies and expansion in this link. For benchmarks related to the Semantic Index follow [SemanticIndex].
In this mode Quest constructs one table per Class/Property of the ontology and uses these tables to store all the data (triples). This is the traditional way of storing ABoxes.
This mode is not available at the moment.