Closed hartig closed 4 months ago
I have addressed this issue in commit https://github.com/LiUSemWeb/HeFQUIN/commit/a99c5d72166f3022ff10fa5f1bf7ca9f4cd1a713 Therefore, HeFQUIN should be able now to run the RSAs of FedShop :-) (but I don't think it would be very fast, because these queries use some features (e.g., LIMIT and DISTINCT) that we do not yet push into the engine itself, but that are run by Jena after the HeFQUIN engine has produced the complete query result)
In FedShop, the RSA queries are run on Jena, a simple engine whose only purpose is to evaluate parts of input queries on different target endpoints (virtuoso). The goal is to provide an independent baseline to which other engines can compare. That said, there is no need to support it on your engine. Nonetheless, it's a nice-to-have feature
I know, but HeFQUIN currently doesn't have a serious source selection component. In contrast, it was envisioned to be an engine that supports queries for which the source selection has been done already, most likely by the application developer using it (which, I would claim, for many use cases know what their federation looks like and where each subquery should be matched).
Having said that, it is certainly possible to add a proper source selection component in the future. The relevant Java interfaces are already in place and integrated into the query planning process. In fact, we even have an implementation of these interfaces. Yet, that one simply produces the exhaustive source assignment, so it is not very useful in practice.
In any case, source selection component or not, it is interesting to use the RSAs to see how efficient the engine can execute them, what the optimizer does for them, etc. Federated query processing is not only about source selection ;-)
The Reference Source Assignments (RSAs) of FedShop are provided in the form of queries that contain a VALUES clause and SERVICE clauses that have a variable instead of an IRI. That is, these queries look something like the following one.
HeFQUIN cannot handle such queries at the moment, and "simply" adding support for VALUES to the engine is not going to help either. Instead, these queries need to be rewritten by substituting the SERVICE variables right away, before passing these queries even to the Jena process. For instance, the example query above should be rewritten as follows.
/cc @Chat-Wane @mhoangvslev @chengsijin0817 @huanyu-li @keski