# Towards Interactive Analytics over RDF Graphs
## 6 Translation of HIFUN Queries to SPARQL
### Cases Where the Prerequisites of HIFUN Are Not Satisfied  
Let us now discuss the problem of translation for the case where the requirements for applying HIFUN (as described in Section 5.1) do not hold, as well as when features (as described in Section 5.4) are required. Consider that the running example of Figure 2 contained a property \"ex:birthYear\" with domain the class \"ex:Person\" and range an integer-typed literal. Now suppose that we would like to compute a single number being the average birth year of the founders of the products that were sold. Here the problem of incomplete information arises, i.e., the dataset may not contain information about the founders of all products, let alone their birth year, therefore the path \(delivers.brand.founder.birthYear\) will not be \"applicable\" to several invoices. If we formulate such a query in HIFUN, it will be translated to a SPARQL query that will be evaluated successfully; however the results will not be complete, i.e., only the invoices for which the path \(delivers.brand.founder.birthYear\) exists will be considered. Moreover, we may encounter the problem of multiple values, i.e., when a brand was founded by more than one person. In that case, even if our dataset contained complete information, the path \(delivers.brand.founder.birthYear\) would not be functional. If we formulate such a query in HIFUN, it will be translated to a SPARQL query that will be evaluated successfully; however the results will not be accurate, i.e., all paths will be taken into account; valuating more than one birth year per product, not only one birth year per product. If we wanted to associate each product with only one birth year (before taking the average over all products), then in case of multiple founders, we could define a feature that computes the average birth year of each individual product. Having this feature enables the subsequent formulation of a HIFUN query, that would compute the accurate answer. There are several possible methods to define such features using the query language (as mentioned in Section 5.4). In our example, the average birth year of the founder(s) for each individual product can be computed by one query that yields a variable for that feature:  
\(qf=\)  
SELECT?x2 AVG(?x5) as productFoundBirthYearAvg  
WHERE {  
?x1 ex:delivers?x2. ?x2 ex:brand?x3. ?x3 ex:founder?x4. ?x4 ex:birthYear?x5. GROUP BY?x2  
To compute accurately that we want to (i.e., average birth year of the founders of the products that were sold), we can exploit the notion of SPARQL subqueries (that was mentioned in the last part of Section 5.4) to \"embedded\" the aforementioned query \(qf\). Please note that subqueries are a way to embed SPARQL queries inside other queries to allow the expression of requests that are not possible otherwise. Subqueries are evaluated first and then the outer query is applied to their results. Only variables projected out of the subquery (i.e., appearing in its SELECT clause) are visible to the outer query. Therefore the features can be expressed as subqueries that can be placed in the WHERE clause. In our case, the HIFUN query that computes the average birth year of the founders of the products would have the following form: \(Q=(\epsilon,product.productFoundBirthYear\)_Avg\(,\)_AVG\()\), where \(productFoundBirthYearAvg\) is a feature (according to Table 1 we would write \(productFoundBirthYearAvg=delivers.brand.founder.birthYear.avg\)); note that \(\epsilon\) denotes the empty grouping function, since in our example we do not want to group the results, just to apply \(AVG\) to the entire set. To compute this feature we can use a subquery that returns two variables, one for the objects and one for the corresponding feature value, say \(vf1\) and \(vf2\) respectively, while ensuring that \(vf1\) should the same with the variable used in the outer query for these objects.