obda_functors

Using functors to limit the interaction of mappings

The following example shows how function symbols (functors) that generate ontology objects from values in the database can be used to limit the interaction between queries in the system, allowing you to define models that have better performance and achieve the desired effect.

Suppose that you have the following 4 mappings (SQLN means an arbitrary SQL):

M1: DatiBilancio(dati_bil($cd_ngr,$ts_iniz_val)), timestampI(dati_bil($cd_ngr,$ts_iniz_val),$ts_fine_val) <--- SQL1
M2: timestampF(dati_bil($cd_ngr,$ts_iniz_val),$ts_fine_val) <--- SQL2

M3: DatiX(dati_x($cd_ngr,$ts_iniz_val)), timestampI(dati_x($cd_ngr,$ts_iniz_val),$ts_fine_val) <--- SQL3
M4: timestampF(dati_x($cd_ngr,$ts_iniz_val),$ts_fine_val) <--- SQL4

and you have that:

DatiBilancio ISA Dati
DatiX ISA Dati

And you have the query

q($d, $t1, $t2) :- Dati(x), timestampF($x, $t1, $t2),  timestampI($x, $t1), timestampF($x, $t2)

Then, you won't have to worry about the interaction between mappings M1,M2 and M3,M4 when it comes to their "dati" objects. The reasoner wont condier using combinations of both mappings when you ask to join atoms on positions that correspoind to dati objects because you used different functor, i.e., dati_x and dati_bil. In this case the only queries that would be considered are

SELECT $d, $t1, $t2 FROM (SQL1, SQL1, SQL2) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL3, SQL3, SQL4) join all over on cd_ngr and join on ts_iniz_val

This would be the same situation would have been the same if you had the same function but with different cardinality (using different amount of parameters). At the moment, types are not being considered, but in the near future, if the functions are the same, the have the same cardinality but the type of the values being passed to the functions are different, the situation will be the same.

All this allows you to model in such a way that the system knows that mappings are not relevant when used with other mappings if those refer to different types of objects. The key concept there is the JOIN position.

Note also that, if the join position of the query was indeed joinable across all mappings, i.e., the mappings would have the same function symbols and the same arity, then all mappings would have been considered to create the SQL and there wouldn't be 2 SQL's sent to the reasoner, but 8!

As in:

SELECT $d, $t1, $t2 FROM (SQL1, SQL1, SQL2) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL1, SQL3, SQL2) join all over on cd_ngr and join on ts_iniz_val

SELECT $d, $t1, $t2 FROM (SQL1, SQL1, SQL4) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL1, SQL3, SQL4) join all over on cd_ngr and join on ts_iniz_val

SELECT $d, $t1, $t2 FROM (SQL3, SQL1, SQL2) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL3, SQL3, SQL2) join all over on cd_ngr and join on ts_iniz_val

SELECT $d, $t1, $t2 FROM (SQL3, SQL1, SQL4) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL3, SQL3, SQL4) join all over on cd_ngr and join on ts_iniz_val

If you already know that some of these will be empty, or that there is no sense of considering some of these combinations because of application reasons, then the extra queries are a possible big amount of wasted effort done by the DBMS.

Note

Using QuOnto with the latest version of the partial evaluation based unfolding, the query's that are actually generated are

SELECT $d, $t1, $t2 FROM (SQL1, SQL2) join all over on cd_ngr and join on ts_iniz_val
SELECT $d, $t1, $t2 FROM (SQL3, SQL4) join all over on cd_ngr and join on ts_iniz_val

because we realize that in each of this query , SQL1, SQL1 and SQL3,SQL3 are redundant, so we remove one of each them.