E Gaye

A Le Bot

J P Talarmin

R Le Calloch

S Belaz

M Dupont

P Tattevin
email: pierre.tattevin@chu-rennes.fr

Cerebral aspergillosis: an emerging opportunistic infection in patients receiving ibrutinib for chronic lymphocytic leukemia? Aspergillose cérébrale : une infection opportuniste émergente chez les patients traités par ibrutinib pour leucémie lymphoïde chronique ?

Keywords: aspergillose cérébrale, ibrutinib, leucémie lymphoïde chronique chronic lymphocytic leukemia, ibrutinib, cerebral aspergillosis

Introduction

Ibrutinib is a novel oral covalent inhibitor of Bruton's tyrosine kinase (BTK). It has been approved for the treatment of relapsing chronic lymphocytic leukemia (CLL), or CLL with high-risk cytogenetic abnormalities . Several cases of invasive aspergillosis have recently been reported in ibrutinib-treated patients. We report two cases of cerebral aspergillosis in CLL patients treated with ibrutinib.

Case reports

First case patient

A 75-year-old man was admitted for prolonged fever. He had been initiated on ibrutinib (280 mg daily) 12 days earlier, along with oral prednisone (1 mg/kg/day) for relapsing CLL complicated by autoimmune hemolytic anemia (AIHA). Previous CLL treatments included obinutuzumab, chlorambucil, rituximab, and bendamustine. The physical examination performed upon admission was unremarkable, except for fever (body temperature 38°C). The neutrophil count was <0.1 G/L, serum gamma globulins were 3.8 g/L. Chest computed tomography (CT) scan revealed bilateral nodules and enlarged mediastinal lymph nodes. Bronchoalveolar lavage (BAL) yielded Aspergillus fumigatus. Serum Aspergillus galactomannan antigen (enzymatic immuno-assay Platelia® Aspergillus Ag Bio-Rad, Marnes-la-Coquette, France) was 1.9 (index, normal values <0.5). The patient was treated with voriconazole 200 mg BID after a loading dose. The dose was then gradually increased to 500 mg BID, which allowed trough serum concentrations to reach the therapeutic target of 1-6 µg/mL throughout treatment. Filgrastim was introduced and ibrutinib was discontinued.

Three days later, while the neutrophil count was >0.5 G/L, the patient complained of visual impairment and ataxia. The brain MRI revealed several abscesses (Fig. 1). The cerebrospinal fluid (CSF) analysis was normal (no white cells, proteins 0.36 g/L), and no pathogen was identified on Gram staining, culture, and tests for galactomannan as well as Cryptococcus antigen. On Day 13 the Ibrutinib was not reintroduced.

Second case patient

A 65-year-old man was diagnosed with CLL, Binet stage C, with a high-risk cytogenetic abnormality of 17p13 deletion, complicated with AIHA non-responsive to corticosteroids. He was started on ibrutinib (420 mg/day) associated with rituximab (500 mg/m 2 every two weeks) and prednisone (1.5 mg/kg/day). Two months later, the patient was admitted for acute dyspnea and cough. The physical examination was unremarkable. Laboratory tests revealed hemoglobin level of 8.9 g/dL and neutrophil count of 7.1 G/L. The chest CT scan revealed left pleural effusion and bilateral nodules (Fig. 2A). The direct examination of BAL revealed alveolar hemorrhage and mononuclear cell infiltrates. BAL, tracheal aspiration, and sputum culture all yielded Aspergillus fumigatus. Serum Aspergillus galactomannan antigen was 0.8 (index).

The patient was treated with oral voriconazole. Therapeutic drug monitoring was performed, with levels constantly >1.5 µg/mL in the serum. Ibrutinib dosage was reduced to 140 mg/day because of drug-drug interaction with voriconazole. Prednisone was reduced to 20 mg/day and rituximab was discontinued. Cough and dyspnea gradually resolved over two weeks, and serum Aspergillus galactomannan antigen was <0.5 (index) at two months.

A c c e p t e d m a n u s c r i p t

One month later, while the patient was still receiving voriconazole therapy, he was admitted for light-headedness, balance disorder, and right hemiparesis. The brain MRI revealed multiple nodular lesions (Fig. 2B). The CSF analysis was normal, with no meningitis, normal protein and glucose values, and negative galactomannan antigen, β-D-glucan, and Aspergillus PCR. Voriconazole levels were within therapeutic targets (i.e., respectively 2.04 and 1.47 µg/mL in serum and CSF). The lung CT scan revealed significant decrease in pleural effusion and nodules, and galactomannan antigen in serum was <0.5 (index).

Voriconazole was associated with intravenous liposomal amphotericin B at 350 mg/day. Neurologic signs resolved within 10 days. The brain MRI and chest CT scan were normal after three months of combination antifungal therapy, allowing discontinuation of liposomal amphotericin B.

Voriconazole was discontinued after 12 months with good tolerability. The ibrutinib dose was increased to 420 mg/day after voriconazole discontinuation. No sign indicative of aspergillosis relapse was observed during a 5-month follow-up after voriconazole discontinuation.

Discussion

Invasive aspergillosis is a fungal opportunistic infection mainly ascribed to neutrophil and macrophage phagocyte function deficiency, which enables the growth of Aspergillus spores and tissue invasion. The at-risk population has been well identified, including patients presenting with prolonged (>10 days) and severe (<0.5 G/L) neutropenia, prolonged corticosteroid use, inherited severe immunodeficiency, or treatment with T cell immunosuppressants [START_REF] De Pauw | Revised definitions of invasive fungal disease from the European Organization for Research and Treatment of Cancer/Invasive Fungal Infections Cooperative Group and the National Institute of Allergy and Infectious Diseases Mycoses Study Group (EORTC/MSG) Consensus Group[END_REF].

Ibrutinib is an oral covalent inhibitor of BTK, an enzyme produced by B-cell monocytes and macrophages that plays a role in down-regulating BCR and NF-κB signalling pathways in CLL cells and may also contribute to hypogammaglobulinemia [START_REF] Herman | Ibrutinib inhibits BCR and NF-κB signaling and reduces tumor proliferation in tissue-resident cells of patients with CLL[END_REF]. The immunosuppression induced by ibrutinib inhibition of BTK may lead to an increased susceptibility to fungal infection. The two case patients reported herein presented with additional risk factors for invasive fungal infections, as they received prolonged corticosteroids or/and prior myelosuppressive therapies. Yet, they neither had prolonged A c c e p t e d m a n u s c r i p t neutropenia nor lymphopenia before and during BTK-inhibitor-therapy. This suggests the potential key role of ibrutinib as a predisposing factor for invasive aspergillosis in CLL patients.

Lung is the primary site of invasive aspergillosis; cerebral aspergillosis is rare [START_REF] Lortholary | Epidemiological trends in invasive aspergillosis in France: the SAIF network (2005-2007)[END_REF]. Its clinical presentation is variable and nonspecific: meningitis, meningoencephalitis, seizures, or focal neurological signs related to abscesses. To date, nine cases of documented invasive aspergillosis have been reported in CLL patients receiving ibrutinib. Of note four of them (44%) had cerebral aspergillosis [START_REF] Ruchlemer | Ibrutinib for Chronic Lymphocytic Leukemia[END_REF][START_REF] Baron | Fungal infections in patients treated with ibrutinib: two unusual cases of invasive aspergillosis and cryptococcal meningoencephalitis[END_REF] (Table 1). The additional two cases of cerebral aspergillosis reported herein are in line with those findings, and suggest that central nervous system may be a sanctuary site for invasive aspergillosis in CLL patients treated with ibrutinib. Accordingly, careful and repeated neurological examinations are required in patients presenting with invasive aspergillosis after ibrutinib treatment, with a very low threshold for prescribing brain MRI. Surprisingly, our second patient presented with neurological signs after three months of optimal treatment for invasive aspergillosis (voriconazole, with therapeutic drug monitoring).

Despite substantial improvements in invasive aspergillosis treatment [START_REF] Herbrecht | Voriconazole versus amphotericin B for primary therapy of invasive aspergillosis[END_REF], the mortality rate of cerebral aspergillosis remains high, with a 12-week overall mortality of more than 45% [START_REF] Lortholary | Epidemiological trends in invasive aspergillosis in France: the SAIF network (2005-2007)[END_REF]. Recent guidelines of the infectious diseases society of America (IDSA) recommend primary treatment with voriconazole for CNS aspergillosis, because of its good CNS penetration. Combination with liposomal amphotericin B is used as salvage treatment. Our two patients developed pulmonary and CNS aspergillosis soon after ibrutinib was introduced. Both had favorable outcome with prolonged voriconazole treatment, associated with ibrutinib discontinuation, and resolution of neutropenia for the first patient; liposomal amphotericin B combination, and reduction of the ibrutinib dose for the second patient.

Conclusion

Impaired T-cell mediated immunity in CLL together with prolonged corticosteroids and BTK inhibition through ibrutinib may create a perfect storm for the development of invasive aspergillosis, Funding. The authors did not receive any specific funding for this case report.

Conflicts of interest.

The authors report no conflict of interest.

  s c r i p t patient presented with signs of intracranial hypertension with generalized seizure. The brain MRI revealed a significant increase in the abscess size. A stereotactic biopsy was performed: the histopathological examination confirmed the diagnosis of abscesses with septate hyphae compatible with Aspergillus sp., and positive Aspergillus PCR. Prednisone (40 mg/day) was added to voriconazole. The patient's condition gradually improved, and prednisone was gradually tapered until discontinuation on Day 60. On Day 180 the chest CT scan was normal, and the brain MRI revealed significant decrease in brain lesions. Voriconazole was discontinued. No sign indicative of aspergillosis relapse was observed during the 3-month follow-up after voriconazole discontinuation.

A

  c c e p t e d m a n u s c r i p t with a special predisposition for cerebral aspergillosis. Careful clinical and biological monitoring for invasive aspergillosis should be performed in CLL patients treated with ibrutinib, with a low threshold for prescribing brain imaging. Contribution of authors A. Le Bot and E. Gaye wrote the article. J.-P. Talarmin, R. Le Calloch, S. Belaz, M. Dupont, and P. Tattevin critically revised the article. All authors read and approved the final version of the article.

Figure 1 .

 1 Figure 1. First case patient, coronal FLAIR-weighted cranial MRI on admission.

Figure 1 .

 1 Figure 1. Coupe coronale de l'IRM cérébrale initiale du cas n°1, séquence FLAIR.

Figure 2A .

 2A Figure 2A. Second case patient, chest CT scan. Bilateral nodules.

Figure 2A .

 2A Figure 2A. TDM thoracique du cas n°2, nodules bilatéraux.

Figure 2B .

 2B Figure 2B. Second case patient, transversal FLAIR-weighted cranial MRI on admission.

Figure 2B .

 2B Figure 2B. Coupe transversale de l'IRM cérébrale initiale du cas n°2, séquence FLAIR.

  A c c e p t e d m a n u s c r i p t

Table 1 .

 1 Invasive aspergillosis in patients receiving ibrutinib : litterature review

	Context,	Description	Time from	Risk factors for invasive	Treatment, outcome
	reference Phase 3 trial [7] Phase 2 trial [8] Case report [4]	Two patients with pulmonary aspergillosis Multifocal aspergillosis Three patients with CNS aspergillosis	ibrutinib start to aspergillosis diagnosis, months NC 2.1 < 2	aspergillosis NC Rituximab, fludarabin, corticosteroids Corticosteroids m a n u s c r i p t voriconazole + amphotericin B, ibrutininib NC discontinued, aspergillosis controlled discontinuation, died day 26 -Patient 2 : voriconazole + amphotericin B, ibrutinib -Patient 1 : voriconazole + amphotericin B, ibrutinib
	Case report [9] Case report [10]	Pulmonary aspergillosis + mucormycosis Pulmonary aspergillosis. A c c e p t e d 7 fludarabin, corticosteroids Neutropenia, rituximab, 1.5 Rituximab, fludarabin, neutropenia	discontinuation, cured (1 year follow-up) -Patient 3 : amphotericin B, outcome NC voriconazole, ibrutinib discontinuation, died voriconazole, ibrutinib discontinuation, aspergillosis cured, but died 5 months later due to CLL

Acknowledgments. We would like to thank Pr Gangneux J.P., Dr Lemaitre F., Dr Revest M., and Dr Poinot M. for their support. A c c e p t e d m a n u s c r i p t


Sébastien Ferré
email: ferre@irisa.fr

A SPARQL 1.1 Query Builder for the Data Analytics of Vanilla RDF Graphs

Keywords: Data Analytics, RDF Graphs, SPARQL 1.1, OLAP, Expressivity, Query Builder, Natural Language Interface

As more and more data are available as RDF graphs, the availability of tools for data analytics beyond semantic search becomes a key issue of the Semantic Web. Previous work has focused on adapting OLAP-like approaches and question answering by modelling RDF data cubes on top of RDF graphs. We propose a more direct -and more expressive -approach by guiding users in the incremental building of SPARQL 1.1 queries that combine several computation features (aggregations, expressions, bindings and filters), and by evaluating those queries on unmodified (vanilla) RDF graphs. We rely on the NF design pattern to hide SPARQL behind a natural language interface, and to provide results and suggestions at every step. We have implemented our approach on top of Sparklis, and we report on three experiments to assess its expressivity, usability, and scalability.

INTRODUCTION

Data analytics is concerned with groups of facts whereas search is concerned with individual facts. Consider for instance the difference between Which films were directed by Tim Burton? (search) and How many films were produced each year in each country? (data analytics). Data analytics has been well studied in relational databases with data warehousing and OLAP [START_REF] Chaudhuri | An overview of data warehousing and OLAP technology[END_REF], but is still in its infancy in the Semantic Web [START_REF] Colazzo | RDF analytics: lenses over semantic graphs[END_REF][START_REF] Hoefler | Linked Data Query Wizard: A Tabular Interface for the Semantic Web[END_REF][START_REF] Höffner | CubeQA -Question Answering on RDF Data Cubes[END_REF][START_REF] Kämpgen | Transforming statistical linked data for use in OLAP systems[END_REF][START_REF] Sherkhonov | Semantic Faceted Search with Aggregation and Recursion[END_REF]. Existing work on data analytics for RDF has generally proposed solutions to reproduce the features of OLAP on top of RDF graphs. Typically, data cubes are derived from RDF graphs by specifying what are the observations, the dimensions, and the measures [START_REF] Cyganiak | The RDF data cube vocabulary[END_REF]. Traditional OLAP user interfaces can then be used for cube transformations and visualizations. The first limit of this approach is that end-users have no direct access to RDF graphs, and can only explore the cubes that have been defined by some admin-user. This limit is mitigated in [START_REF] Colazzo | RDF analytics: lenses over semantic graphs[END_REF] by an Analytical Schema (AnS), from which end-users can derive themselves many different cubes. However, there is still the need for an admin-user to define the AnS. The second limit is expressivity. OLAP cubes and their transformations only allow for one level of aggregation, and end-users cannot derive new dimensions or measures from existing one by computation (e.g., population density from total population and area). Semantic Faceted Search (SFS) supports direct exploration of RDF graphs but is even more limited in expressivity w.r.t. data analytics [START_REF] Sherkhonov | Semantic Faceted Search with Aggregation and Recursion[END_REF].

In contrast, SPARQL 1.1 [START_REF]SPARQL 1.1 Query Language[END_REF] supports multiple aggregations, nested aggregations with sub-queries, expressions and bindings on numbers, dates, and strings to derive new dimensions/measures [START_REF] Kaminski | Semantics and expressive power of subqueries and aggregates in SPARQL 1.1[END_REF]. Those features can be mixed with graph patterns with a lot of flexibility. We give concrete use cases that show the need for such a high expressivity. The main reason that prevents end-users to use SPARQL for data analytics is the difficulty to write queries. Question Answering (QA) systems [START_REF] Lopez | Is Question Answering fit for the Semantic Web?: A survey[END_REF], which offer to translate spontaneous user questions to SPARQL, have only recently been extended to RDF data cubes [START_REF] Cyganiak | The RDF data cube vocabulary[END_REF], and to statistical question answering thanks to a new task at QALD-6 [START_REF] Unger | 6th Open Challenge on Question Answering over Linked Data (QALD-6)[END_REF]. However, they exhibit the same limits about direct access and expressivity.

In this paper, we propose an alternative approach that is at the same time more direct and more expressive. More direct by allowing its application to vanilla RDF graphs, i.e. RDF graphs not customized to data analytics. More expressive by allowing complex and varied combinations of the computation features of SPARQL 1.1 (aggregations, expressions, bindings and filters). Section 2 lists a number of use cases to motivate the need for SPARQL 1.1 expressivity. Section 3 discusses related work. Section 4 presents the principles of our approach, and Section 5 formalizes it as a query builder that guides users in the combination of SPARQL computations. We rely on the NF design pattern [START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF] to hide SPARQL behind a natural language interface, and to provide results and suggestions at every step. Section 6 presents the implementation of our approach, and Section 7 reports on three experiments on real data, comparing our approach to SPARQL and QA systems, with both IT and non-IT users. Section 8 concludes this paper. Online material1 related to the paper includes a Web application, the permalinks of about 70 analytical queries, and screencasts.

USE CASES

We here present a set of use cases for data analytics on RDF graphs, in the form of questions, in order to clarify our objectives, and to motivate our approach. We first give a few use cases for each kind of SPARQL computation feature (aggregations, and expressions in bindings and filters), and we then give a few use cases combining several computation features. The SPARQL translations of those use cases are given in Figure 1. Use cases are based on a concrete dataset, Mondial [START_REF] May | Information Extraction and Integration with Florid: The Mondial Case Study[END_REF], to make them more vivid and easier to (A1) SELECT (COUNT(?c) AS ?n) WHERE{?c a :Country; :encompassed :Europe.} (A2) SELECT ?k (AVG(?p) AS ?ap) (AVG(?a) AS ?aa) WHERE { ?c a :Country; :encompassed ?k; :population ?p; :area ?a. } GROUP BY ?k (E) SELECT ?c (?p/?a AS ?d) WHERE{?c a :Country;:population ?p;:area ?a.} (C) SELECT ?c ?G ?p ?g ?ag WHERE { ?c a :Country; :gdpTotal ?G; :population ?p. BIND(?G*1e6/?p AS ?g) {SELECT (AVG(?g) AS ?ag) WHERE { ?c a :Country;:gdpTotal ?G;:population ?p. BIND(?G*1e6/?p AS ?g)}} FILTER(?g > ?ag)} (N1) SELECT (AVG(?sa) AS ?asa) WHERE { {SELECT ?I (SUM(?a) AS ?sa) WHERE { ?i a :Island; :belongsToIslands ?I; :area ?a.} GROUP BY ?I } } (N2) SELECT ?ci (COUNT(?I) AS ?cI) WHERE { {SELECT ?I (COUNT(?i) AS ?ci) WHERE { ?i a :Island; :belongsToIslands ?I.} GROUP BY ?I } } GROUP BY ?ci Figure 1: SPARQL queries for the different use cases grasp. However, they have nothing specific to that dataset, and could easily be transposed to other datasets. Mondial contains geographical knowledge on countries, cities, continents, bodies of water, etc., and includes the CIA World Factbook. Compared to the BowlognaBench [START_REF] Demartini | BowlognaBench -Benchmarking RDF Analytics[END_REF], our use cases are at the same time more focused because they consider only computations, and wider because they cover a much larger expressivity range.

Aggregations. A basic aggregation is the application of an aggregation operator on a set of entities or values, resulting in a single value. Use case (A1): How many countries are there in Europe?. A simple aggregation consists in making groups out of a set of values according to one or several criteria, and then applying an aggregation operator on each group of values. An aggregation defines a cube, where the grouping criteria are its dimensions, and where the aggregated values are its measures. A multiple aggregation extends simple aggregation by having several aggregated values for each group. Use case (A2): Give me the average population and the average area of countries, for each continent. In SPARQL, aggregations rely on the use of aggregation operators in the SELECT clause, and on GROUP BY clauses. OLAP-like approaches, including existing approaches for RDF, are limited to this category or a subset of it.

Expressions in Bindings and Filters. Direct data analytics sometimes requires other computations than aggregations: e.g., computations on numbers, dates/times, or strings. They correspond to expressions in SPARQL, and can be used either in BIND or FILTER constructs. Use case (E): Give me the population density for each country, from population and area. Semantic Faceted Search systems are limited to comparisons between a variable and a literal.

Complex Combinations. A complex combination mixes the previous features in a same question, in any order, and/or several instances of a same feature. SPARQL puts no limit to such combinations. Use case (C) combines a binding, an aggregation, and a filter: Which countries have a GDP per capita above the average?. This example requires to compute the GDP per capita as (total GDP ×10 6 / population) for each country (binding), to average GDP per capita over all countries (basic aggregation), and to select countries whose GDP per capita is higher than the average (filter). This use case serves as a running example through Sections 5 and 6.

An interesting kind of complex combination is nested aggregation, i.e. an aggregation (basic, simple or multiple) that applies to the result of another aggregation, which can be a nested aggregation itself. Use case (N1): What is the average area of archipelagos? (given that the area of each archipelago has first to be summed up from the area of individual islands). Note that the aggregation operator of the nesting aggregation can not only apply to aggregated measures of the nested aggregation but also to dimensions. Use case (N2): Give me for every number of islands in an archipelago, the number of archipelagos having that number of islands. In SPARQL, nested aggregations rely on subqueries.

RELATED WORK

To the best of our knowledge, our approach is the only one in data analytics of RDF graphs that does not assume the data to be modelled as -or converted to -a datacube at some point. It is also the only one that covers a range of analytical questions beyond the simple aggregations or OLAP cubes.

Most existing approaches rely on OLAP. Kämpgen and Harth [START_REF] Kämpgen | Transforming statistical linked data for use in OLAP systems[END_REF] propose a pipeline to convert statistical linked data for use in OLAP systems. Colazzo et al. [4] propose analytical schemas as views over RDF data from which OLAP cubes can be queried in a flexible way. Linked Data Query Wizard [START_REF] Hoefler | Linked Data Query Wizard: A Tabular Interface for the Semantic Web[END_REF] is an interface to explore RDF cubes or tables. It supports the filtering of a column (e.g., by a keyword or a numeric value), and simple aggregations. Höffner and Lehmann introduced Question Answering (QA) on RDF Data Cubes (RDCQA) as a subfield of question answering, and designed Task 3 of QALD-6 as a benchmark [START_REF] Höffner | CubeQA -Question Answering on RDF Data Cubes[END_REF]. Two RDCQA systems have been developed and evaluated in QALD-6: CubeQA by the same authors, and QA 3 [START_REF] Atzori | QA 3 : a natural language approach to statistical question answering[END_REF]. Unlike our approach, OLAP-based approaches (a) require the data to be modelled along the RDF Data Cube Vocabulary [START_REF] Cyganiak | The RDF data cube vocabulary[END_REF] so as to identify datasets, dimensions, and measures; (b) are limited to simple aggregations; and (c) require dataset-specific preprocessing and/or templates.

Some approaches allow direct computations on RDF graphs, generally limited to simple filters and aggregations. Neumayr et al. [START_REF] Neumayr | Towards Ontology-Driven RDF Analytics[END_REF] propose ontology-driven RDF analytics to systematically infer statistical facts about classes (e.g., the average age of men, women, people). Sherkhonov et al. [START_REF] Sherkhonov | Semantic Faceted Search with Aggregation and Recursion[END_REF] propose to extend Semantic Faceted Search (SFS) with filters limited to comparisons between a variable and a number; and with simple aggregations limited to one grouping variable and one triple in the aggregated pattern. Ferré [START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF] has not those limitations on aggregations but is still limited to simple aggregations. Our ambition is to support all combinations of those computations, only avoiding Cartesian products. The latter restriction is not only for the sake of tractability, but also for the sake of interpretability of results. Combinations naturally include arbitrary chains of computations, e.g., use cases (N1, N2). However, chains are not enough. For example, use case (C) has a filter that compares two columns that are in two different computed tables (the binding and the aggregation). The two tables need to be joined before applying the filter. This situation is not uncommon as it occurs whenever one wants to compare (aggregated) values at different granularity levels (here, GDP at country level vs average GDP at world level).

DIRECT AND EXPRESSIVE DATA ANALYTICS OF RDF GRAPHS

The problem of extracting the initial tables from an RDF graph amounts to the problem of composing a SPARQL graph pattern. The table of a graph pattern P is the result of the SPARQL query SELECT * WHERE {P }. Semantic faceted search enables non-IT users to interactively build such patterns over RDF graphs. It makes it unnecessary to rely on experts to prepare tables of data, and it therefore allows for direct analysis of RDF data. The two most advanced systems seem to be Sparklis [START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF] and SemFacet [START_REF] Arenas | Faceted search over RDF-based knowledge graphs[END_REF]. While the latter supports OWL2 reasoning, the former supports a much larger set of patterns: i.e., projection of several variables, cycles (not only tree patterns), negation (MINUS), and optionals (OPTIONAL). In particular, the capability to project several variables, i.e. to produce tables and not only sets, is essential to data analytics. Note that, as our approach only assumes an initial table to start with, it is also applicable to any context where such tables are available (e.g., relational databases, spreadsheets, OLAP cubes).

Compared to relying on RDF data cubes [START_REF] Cyganiak | The RDF data cube vocabulary[END_REF], direct data analytics on vanilla RDF graphs offers the following advantages. Arbitrary graph patterns can be built to specify the observations, dimensions, and measures of cubes, without the need for RDF data cube modelling or pre-processing. For example, to answer the question What is the total area of lakes per country?, other approaches would need a data cube where countries and lakes are two dimensions, and where the area is a measure. However, a better and more natural RDF modelling is to have a property from lakes to their countries, and another property from lakes to their area. In fact, we think that RDF data cube models have more to do with query patterns than with data models. Indeed, a data cube can be seen as a SPARQL query template where it remains to choose the projected variables (dimensions), and the aggregation operators.

BUILDING ANALYTICAL QUERIES

We address the problem of composing analytical queries by guiding users in the incremental building of SPARQL computation queries, and by hiding SPARQL behind a Natural Language Interface (NLI). We formalize our approach using the NF design pattern [START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF]. Its purpose is to bridge the gap between a natural language (NL) Table 1: Table queries, along with their columns C (T ), their dimensions D(T ), and their well-formedness conditions

table query T C(T ) D(T ) well-formedness conditions Pattern(X , P ) X X X ⊆ Vars(P ) Bind (T 1 , x, E) C (T 1 ) ∪ {x } D(T 1 ) X E ⊆ C (T 1 ), x fresh
Filter (T 1 , E) C (T 1 ) D(T 1 ) X E ⊆ C (T 1 ), E Boolean Aggreg(T 1 , X , Y , G, Z ) X ∪ Z X X ⊎ Y ⊆ C (T 1 ), Z fresh T 1 ▷ T 2 C (T 1 ) ∪ C (T 2 ) D(T 1 ) D(T 2 ) ⊆ D(T 1 ),
and a formal language (FL, here SPARQL). Figure 2 summarizes NF. The user stands on the NL side, and does not understand the FL. The machine, here a SPARQL endpoint, stands on the FL side, and does not understand the NL. The central element of the bridge is an abstract query. In short, it is a representation of the user's question in a language that is intermediate between NL and FL. That language is designed to make translations from abstract queries to both NL (verbalization) and FL (formalization) as simple as possible. A sub-query of the abstract query is distinguished as the query focus, and the remainder is called query context. NF includes the query builder approach, where the structure that is incrementally built is precisely the abstract query. The abstract query is initially the simplest query, and it is incrementally built by applying transformations. A transformation may insert or delete a query element, or move the focus. NF also includes the faceted search approach, where transformations are suggested by the machine based on query semantics and actual data, and controlled by users. Like queries, transformations are verbalized in NL. This section successively defines abstract queries, their formalization in SPARQL, their verbalization in English, their transformations, and finally the type-based suggestion of transformations. All definitions are illustrated on complex use case (C).

Abstract Queries

We call our abstract queries table queries (T ) because their evaluation returns tables. Table queries are recursively composed of other table queries, and are also composed of expressions.

Definition 1 (Expressions). An expression is one of:

• n, where n is an RDF node (URI or literal),

• ?x, where x is a table column, • E 1 op E 2 ,
where op is a binary SPARQL operator (e.g., +) applied to two sub-expressions, • f (E 1 , . . . , E n ), where f is a SPARQL function (e.g., str) applied to a tuple of sub-expressions as arguments, • ??, representing an undefined expression (yet to be built).

We note X E the set of columns occuring in expression E.

Definition 2 (Table qeries). Table queries take one of the forms given in

Bind (T 1 , x, E ) Pattern T 1 BIND (expr E AS ?x ) Filter (T 1 , E ) Pattern T 1 FILTER (expr E ) Aggreg(T 1 , X, Y, G, Z ) {SELECT . . . ?x i . . . (д j (?y j ) AS ?z j ) . . . WHERE { Pattern T 1 } GROUP BY . . . ?x i . . . } T 1 ▷ T 2 Pattern T 1 Pattern T 2
Table 1 also gives for each form the resulting set of columns C (T ), the set of dimensions D(T ) ⊆ C (T ), and well-formedness conditions. D(T ) plays the role of a key for the resulting table T (i.e., at most one row for each valuation of D(T )).

Pattern(X , P ) represents an initial table from the SPARQL pattern P, where the set of columns X is a subset of the variables in P. Bind (T 1 , x, E) extends T 1 with a new column x computed by expression E over T 1 's columns. Filter (T 1 , E) filters the rows of table T 1 based on the Boolean expression E. Aggreg(T 1 , X , Y , G, Z ) defines an aggregated view over T 1 , grouping by columns in X , and aggregating each column y j ∈ Y with aggregator д j ∈ G into aggregated column z j ∈ Z . Finally, T 1 ▷ T 2 is a restricted form of join where D(T 2 ) ⊆ D(T 1 ) (the key of T 2 is a subset of the key of T 1 ), so that each T 1 -row has at most one corresponding T 2 -row.

Example. In order to illustrate our language of abstract queries, and show its expressive power, we show below the table query T for the complex use case (C) of Section 2. For readability, we decompose the table query by naming each sub-query (T 0 ,T 1 ,T 2 ). This also avoids the duplication of T 1 , which is used twice.

T = Filter(T 1 ▷ T 2 , (?g > ?ag))
where T 2 = Aggreg(T 1 , (), (g), (AVG), (ag)) and T 1 = Bind(T 0 , g, ((?G * 1e6) / ?p)) and T 0 = Pattern({c,G,p}, ?c a :Country ; :gdpTotal ?G ; :population ?p .)

T 0 is the initial table based on a SPARQL pattern relating countries to their total GDP (in M$), and their population. T 1 extends T 0 with a binding computing the GDP per capita (column д). T 2 performs an aggregation over T 1 to produce a one-row one-column table containing the average GDP per capita (column aд). Finally, T filters the join T 1 ▷ T 2 by comparing columns д from T 1 and column aд from T 2 . The join is here necessary in order to make the two columns accessible to the filter expression from a same table. For final table T , the set of columns is C (T ) = {c, G, p, д, aд}, and the set of dimensions is D(T ) = {c, G, p} because д and aд are introduced by a binding and an aggregation, respectively.

Formalization in SPARQL

We here provide a formalization and semantics for abstract queries by translating them to SPARQL. Although the translation of each table query and expression is relatively straightforward (see Table 2 for tables), it is complicated by the fact that the table query to be translated depends on the current query focus. Indeed, the idea is to give access not only to the final table, but also to the initial table and every intermediate table (each T i in the above example). The current focus can be used to select the sub-query to translate. For example, in use case (N1), the user can choose between: (1) islands and their archipelagos and area, (2) archipelagos and their total area, and (3) the average area of archipelagos.

However, it is also desirable to show as much information as possible, by joining the table at focus with other compatible tables. For example, in use case (C), when the focus is on the initial table about countries, it is valuable to include the column on "GDP per capita" from the binding (T 1 ), and also the "average GDP per capita" from the aggregation (T 2 ). In particular, it makes it possible to compare side-by-side for each country its GDP per capita to the average. To formalize this intuition, we define the saturation of a table sub-query. Definition 3. Let T be a query table, and T i be a sub-query of T (or T itself). The saturation of T i is

T ▷ i = T i ▷ {T j ⊆ T | T j T i , D(T j ) ⊆ D(T i )}, i.e.
the join of T i with all other sub-queries of T whose dimensions are a subset of the dimensions of T i .

In the above example query T , the saturation of T 0 is T ▷ 0 = T 0 ▷ T 1 ▷T 2 ▷T , which simplifies to T ▷ 0 = T thanks to the following rules:

T ▷ Bind (T , x, E) = Bind (T , x, E), and T ▷ Filter (T , E) = Filter (T , E). The saturation of T 1 is the same. The saturation of T 2 is T ▷ 2 = T 2 because D(T 2 ) = ∅, unlike other sub-queries. Definition 4. The SPARQL translation of a table query T is SELECT * WHERE { Pattern T ▷ focus },
where T focus is the sub-query that has focus, T ▷ focus is its saturation, and Pattern T ▷ focus is defined recursively on table queries by Table 2.

In Table 2, expr E represents the translation of our abstract expression E to SPARQL expressions. The translation of expressions is trivial but the focus and undefined expressions (??) have to be taken into account again. First, when an expression under focus contains the undefined expression ??, the encompassing BIND or FILTER is removed from the translation because the expression cannot yet be computed. Second, when the focus is on a sub-expression, the rest of the expression is ignored in the translation in order to give access to the values of that sub-expression. For example, if the focus is on (?G * 1e6) in use case (C), then the rest of the expression (/ ?p) is ignored, and column д contains values of the "total GDP in dollars" instead of values of the "GDP per capita".

Example. The formalization of use case (C) when the focus is on one of T 0 ,T 1 ,T , and not on a sub-expression is the following. Note the duplication of the initial pattern and the binding, coming from the two occurences of T 1 in table query T . When the focus is on T 2 , the formalization is only the aggregation query, i.e. a subquery of the previous one.

SELECT (AVG(?g) AS ?ag) WHERE {

?c a :Country ; :gdpTotal ?G ; :population ?p . BIND(?G*1e6/?p AS ?g) }

Verbalization in English

Before defining the verbalization of expressions and table queries, we have to define the verbalization of column names. We assume that a noun is associated to each column of a Pattern-query: ex., 'country' for c, and 'total GDP' for G in the running example.

Columns introduced by bindings can be named by users: ex., 'GDP per capita' for д. Otherwise, the verbalization of the binding expression is used instead. Finally, the verbalization of each aggregated column z is the verbalization of д(y) (e.g., 'the number of y', 'the average y').

The verbalization of expressions results from the nesting of the verbalization of its functions and operators It mixes mathematical notations and text depending on which is the clearer: 'E 1 + E 2 ' is clear to everybody and less verbose than 'the addition of

E 1 and E 2 ', while 'E 1 or E 2 ' is less obscure than 'E 1 || E 2 '
for non-IT people. The verbalization of table queries is a matter of templates (optional parts are between [ ]), given the verbalization of columns, aggregated columns, and expressions.

• Bind (T 1 , x, E): 'give me [x =] E' • Filter (T 1 , E): 'where E' • Aggreg(T 1 , X , Y , G, Z ): '[for .
. . each x i . . . ,] give me . . . д j (y j ). . . ' All sub-queries in a table query are verbalized once -hence avoiding duplications for sub-queries that have several occurences (e.g., T 1 in use case (C)) -and coordinated with 'and'. Sub-queries are put in dependency ordering, starting with the initial table. In agreement with formalization, if the focus is on sub-query T i then the subqueries that do not appear in the saturation T ▷ i are dimmed in the display to show that they are inactive at the current focus. Here is the verbalization of use case (C), whose first line is the verbalization of the initial pattern, as done in Sparklis [START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF].

give me a country that has a total GDP, and that has a population and give me GDP per capita = the total GDP * 1e6 / the population and give me the average GDP per capita and where the GDP per capita > the average GDP per capita

Query Transformations

A query transformation applies changes to an abstract query at and around its focus. This notion of focus is essential to target the part of the query to be changed, and to simplify the definition of the transformations. Each of our transformations is represented in the following way:

focus@context transf -----→ focus ′ @context ′
where a pair focus@context exhibits the split of an abstract query between the sub-query or sub-expression at focus, and its context, i.e. the surrounding query. For example, E@Filter (T , _) denotes the query Filter (T , E) with focus on E.

The simplest way to have a complete set of transformations would be to have a focus for each table sub-query and sub-expression, and to have an insertion transformation for each form of table queries and expressions: i.e., bindings, filters, aggregations, joins, nodes, columns, operators, and functions. However, this would not be satisfying for several reasons. First, it would force users to think in terms of table queries (e.g., bindings, filters), whereas it is more natural to think in terms of entities, values, and function/operator

(0) x@T f [1]
----→ f (?x, ??)@Bind (T ▷ , x, _) ??

--→

(1) E@E ′ f [1] ----→ f (E, ??)@E ′ ?? --→

(2) ??@E ′ n -→ n@E ′ ?? --→

(3) ??@E ′ x -→?x@E ′ ?? --→ (4) ??@E ′ f -→ f (??, ??)@E ′ ?? --→

(5) E@Bind (T , x, _)

type(E )=bool -----------→ E@Filter (T , _)

(6) E@Filter (T , _) type(E ) bool -----------→ E@Bind (T , x * , _) (7) y@T д -→ z * @Aggreg(T ▷ , (), (y), (д), (z * )) (8) c@Aggreg(T , X , Y , G, Z ) group by x ---------→ x@Aggreg(T , (Xx ), Y , G, Z ) (9) c@Aggreg(T , X , Y , G, Z ) д(y )
----→ z * @Aggreg(T , X , (Yy), (Gд), (Zz * ))

applications. Therefore the focus should be on a column or an expression instead. Second, it would force to compose expressions top-down, which would require anticipation of the whole expression. It should be possible to compose expressions in a mixture of top-down and bottom-up, and even to insert functions/operators in the middle of an expression.

Definition 5 (qery focus).

There are two kinds of query focus:

• x@T sets the focus on one column x ∈ C (T ) of table query T ;

• E@E ′ sets the focus on an expression E, whose context is E ′ . Context E ′ can be refined into Bind (T , x, _) or Filter (T , _).

Definition 6 (qery transformations). The query transformations of table queries and expressions are listed in Table 3. The starred columns represent the introduction of fresh columns. The trailing ( ??

--→) in Transf. (0-4) represents an automatic move of the focus to the next undefined expression if there is any, or to the whole expression otherwise, in order to save manual focus moves.

Transf. (0) introduces a binding by applying function f to column x, as the 1st argument of f . Transf. (1) inserts a function call on any expression focus. For brevity, those two transformations are only given for binary functions and 1st arguments, but they are also defined for operators, other function arities, and other argument positions (e.g., * [START_REF] Arenas | Faceted search over RDF-based knowledge graphs[END_REF], concat [START_REF] Atzori | QA 3 : a natural language approach to statistical question answering[END_REF]). Transf. (2,3,4) replace an undefined expression with one of: a node n, column x (when x ∈ C (T ), where T is the focus table), or a call to function f with arguments waiting to be defined. Transf. [START_REF] Cyganiak | The RDF data cube vocabulary[END_REF][START_REF] Demartini | BowlognaBench -Benchmarking RDF Analytics[END_REF] represent automatic switches between bindings and filters based on the type of the expression being Boolean or not. Transf. [START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF] introduces an aggregation by applying aggregator д to column y. Transf. [START_REF] Ferré | SPARKLIS on QALD-6 Statistical Questions[END_REF][START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF] respectively add a grouping by column x (when x ∈ C (T ) \ X \ Y ) and an aggregated column д(y) (when y ∈ C (T ) \ X ) to an aggregation. Note the use of saturation when introducing bindings (Transf. (0)) and aggregations (Transf. [START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF]) in order to give access to as many columns as possible for defining the binding or aggregation. In fact, there is no transformation to insert a join, and all joins are automatically inserted in this way. For brevity, we have omitted additional transformations for removing query elements. They are not necessary in theory but they are very useful in practice for undoing insertions in a different order to their insertion. In addition to those transformations, the focus can be moved freely.

Only transformations that are applicable to the current focus, and that respect type constraints are suggested (see Section 5.5). The suggested operators and functions in Transf. (0,1,4), and the aggregators in Transf. [START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF][START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF] are selected from the list of SPARQL-supported operators, functions, and aggregators, according to type constraints. The suggested columns in Transf. (3) are the columns C (T ▷ focus ) of the saturation of the focus table. The suggested columns in Transf. [START_REF] Ferré | SPARKLIS on QALD-6 Statistical Questions[END_REF][START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF] are taken among the columns of the aggregated table T , according to the well-formed conditions of Aggreg-tables (Table 1). Finally, the nodes in Transf. ( 2) are obtained by asking the user to fill an input field, and by checking the input according to type constraints.

Example. The sequence of transformations that leads, in use case (C), from the initial table (T 0 ) to the complete query (T ) is the following, where each transformation, and each focus move (e.g., G@T 0 ), is followed by the table query that has been created or modified. In the latter, the query focus is underlined. We recall that transformations are not written by the user but selected (by click) in a suggestion list.

step transf. created or modified table query 1 G@T 0 T 0 ← Pattern({c,G,p},. . . ) 2

*[1]
T 1 ← Binding(T 0 , g, (?G * ??))

3 1e6 T 1 ← Binding(T 0 , g, (?G * 1e6)) 4 /[1]
T 1 ← Binding(T 0 , g, ((?G * 1e6) / ??)) 5 p T 1 ← Binding(T 0 , g, ((?G * 1e6) / ?p)) 6 AVG T 2 ← Aggreg(T 1 , (), (g), (AVG), (ag)) 7 g@T 1 T 1 ← Binding(T 0 , g, ((?G * 1e6) / ?p)) 8

> [START_REF] Arenas | Faceted search over RDF-based knowledge graphs[END_REF] T ← Filter(T 1 ▷ T 2 , (?g > ??)) 9 ag T ← Filter(T 1 ▷ T 2 , (?g > ?ag)) The above sequence of transformations can be informally presented in a narrative way (imagine the user talking to herself): from the initial table, "select the total GDP... multiply it by... 10 6 ... and divide the result by... the population (the result is the GDP per capita)... get the average of that... select the GDP per capita... it should be greater than... the average GDP per capita". It can be observed that 9 steps are sufficient to build the whole table query although it contains 5 sub-queries, and 8 sub-expressions. It can also be observed that every applied transformation is either referring to a column (2 focus changes, 2 column insertions), or inserting a computing element (3 operators, 1 number, 1 aggregator). Therefore, users can think in terms of which computations should be applied to which columns, and table queries are implicitly created/modified as needed. Note that, despite T 1 having two occurences in T , it needs only be built once thanks to the automatic joins.

Type-Based Suggestions

Among the possible transformations presented in Section 5.4, only those that lead to well-typed expressions and aggregations should be suggested to users. For example, when the focus is ??@(?G * _), i.e. on the right-hand side of a product, only numeric literals, columns and functions can be inserted. We have implemented a type inference mechanism that determines two type constraints: the focus type and the context type. The focus type comes from the analysis of the query focus, and possibly the focus values. If the query focus is an expression, then the focus type is infered from the type signatures of its functions and operators. Similarly for aggregations. If the query focus is a pattern column, the focus type is infered from the datatype of its values in the SPARQL results. If the query focus is an undefined expression, which happens when inserting an n-ary function, the focus type is undefined. The context type comes from the analysis of the query context. If the query context is a function/operator argument, then the context type is the type of that argument, otherwise it is undefined. By definition of the transformations, at least one of the two constraints is defined. From there, the suggested aggregators, functions, and operators are simply those that can be inserted at the focus while satisfying the defined type constraints. In fact, there is a distinct transformation for each function argument (Section 5.4), and only function arguments compatible with focus type are suggested. The type constraints are also used to check user inputs of literals.

In practice, a few additional complications must be dealt with for the sake of robustness w.r.t. real datasets. First, the focus values may have several incompatible types (e.g., URIs and strings). In this case, the focus type is a set of types, and if the inserted function is only compatible with one of them, the resulting expression will only be partially defined (there will be blank cells in the results). Second, the focus values may be improperly typed, thus requiring to explicitly apply conversion functions. The common case is numerical literals having no datatype (e.g., QALD-6 datacubes) or non-standard datatypes (e.g., DBpedia USdollar). We parse literals independently of their datatype to recognize numbers, and implicitly apply conversion functions in the SPARQL formalization as necessary.

IMPLEMENTATION

We have fully implemented the proposed approach on top of Sparklis [START_REF] Ferré | Sparklis: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language[END_REF], a semantic search tool that is also based on the NF design pattern. It allows end-users to build SPARQL graph patterns that arbitrarily combine basic graph patterns, UNION, OPTIONAL, and MINUS. It also supports ORDER BY clauses. It therefore provides everything needed for the building of Pattern-table queries, and our proposed approach fits well with Sparklis.

Our implementation, called Sparklis-Analytics, incorporates Sparklis, and adds 3500 lines of code to the existing 5000. The NF design pattern helped us to integrate table queries and expressions in a modular way. First, new data structures were defined beside patterns for table queries and expressions. Second, the algorithms for the formalization in SPARQL and the verbalization in English were extended to those new data structures. Third, the set of suggestions was augmented with our computation-oriented transformations. Finally, type-checking mechanisms were added for the filtering of suggested transformations.

Availability. Sparklis-Analytics is available on-line2 as a client-side application that works on top of SPARQL endpoints. A few endpoints are proposed (e.g., DBpedia, Mondial, Nobel Prizes) but any endpoint can be explored by simply entering its URL. A few configuration options allow to adapt to different endpoints (e.g., GET/POST method, sending with credentials), and to specify labelling properties. It also includes the YASGUI editor [START_REF] Rietveld | YASGUI: Not just another SPARQL client[END_REF] to let advanced users access and modify the SPARQL translation of the query. The application page links to a list of clickable examples including the use cases of Section 2 (and more), and the 50 test questions from the QALD-6 challenge. A number of examples have a screencast on YouTube to show their incremental building.

Example. Figure 3 shows a screenshot of Sparklis-Analytics, taken at the last step of use case (C), just before inserting 'the average GDP per capita' (column aд) in the filtering expression 3 . The user interface has three main parts, from top to bottom: the query, the suggested transformations organized in three lists, and the table of results. In the query, the focus is on the right-hand side of operator >, and the left-hand side is dimmed because it is not under focus. The middle list suggests column names whose type is compatible, and entry fields for compatible types (here, numeric types). The right list suggests functions and operators whose type is compatible (here, operators returning a number). The left list is not relevant for computations, it is used for building graph patterns (suggesting classes and properties). In the table of results, we can see the active column names, and the first row. Both the computed 'GDP per capita' and 'average GDP per capita' are active, which allows to compare them side by side. The last column is added to show the Boolean value of the comparison expression under building but it contains only blank cells because the focus is undefined at this stage.

Expressivity and limits. Our approach and its implementation covers almost all SPARQL 1.1 computations. The non-covered features are: (a) a few technical functions like SHA256, (b) the customization of the separator in the GROUP_CONCAT aggregator, and (c) the application of COUNT to a row of variables (e.g., COUNT(*)). The limits therefore do not lie in the computation features but in their combinations. A hard limit is that a query cannot contain several disconnected patterns because our join (T 1 ▷ T 2 ) is the only way to combine several patterns, and its restriction (D(T 2 ) ⊆ D(T 1 )) implies that the two patterns share variables, and hence are connected. An example of question that cannot be answered in our approach is "Are there more cities than rivers?", because cities and rivers are not connected. However, it is possible to answer the question "Are there more cities than rivers in France?", because cities and rivers are now connected through entity France. A soft limit is that some questions, although answerable in our approach, are awkward to build. The typical example is the computation of proportions, and more generally, the combination of aggregations on different filterings of a table query: e.g., "What proportion of cities in China have more than 1 million inhabitants?".

Scalability. The addition of computation features to Sparklis has not much impact on scalability, apart from the SPARQL evaluation of aggregations that are intrinsically costly, in particular in complex combinations. Bindings and filters do not impact subtantially efficiency as they are evaluated row-wise. The cost of the translations from abstract queries to SPARQL and English is negligible compared to the cost of evaluating SPARQL queries by the endpoint. The type-based choice of suggestions is cheap because it can be computed on the client side without any request to the SPARQL endpoint. Our experiments in real settings (Section 7) confirm those theoretical observations.

EXPERIMENTS

We here report on three experiments in order to evaluate our approach. The first is a user study that compares the usability of our approach to the writing of SPARQL queries. The second reports on our participation to the QALD-6 challenge, and compares our results to question answering systems. The third evaluates the adequecy of our approach w.r.t. real needs at Persée, a dataset used by researchers in social sciences.

Comparison with Writing SPARQL Queries

Methodology. The objective of this user study is to evaluate the usability of our approach compared to writing SPARQL queries directly. The subjects were 24 post-graduate students working in pairs. They had all recently attended a Semantic Web course with about 10h of teaching and practice of SPARQL. The task given to subjects was to answer two series of 10 questions on the Mondial dataset, covering all categories presented in Section 2. The questions in the two series involve exactly the same kinds of computations in the same order, they only differ by the initial pattern: e.g. Give the average population of European countries vs Give the average area of Mediterranean islands. The subjects had to use two different systems, one for each series of questions: (a) YASGUI [START_REF] Rietveld | YASGUI: Not just another SPARQL client[END_REF], a SPARQL query editor improved with syntax highlighting, and (b) our tool Sparklis-Analytics. The subjects had only a 1h presentation of our tool before, and no practice of it. Each subject was randomly assigned an order (YASGUI first vs Sparklis-Analytics first) to avoid bias. For each system/series couple, they were given 10min for setup, and 45min for question answering. To help the writing of SPARQL queries, they were given the list of classes and properties used in Mondial. Finally, the subjects filled a questionnaire at the end to report their feelings and comments.

Questions. Question 1 is a simple pattern. Question 2 is a binding, and Question 3 is a filtering. Questions 4-7 are aggregations with different numbers of groupings. Question 8-9 are complex combinations of an aggregation and a binding or filtering. Question 10 is a nested aggregation.

Objective results. With YASGUI, the subjects managed to produce answers for 1-3 questions, 1.67 on average. The rate of correct answers was 71%. The best subject answered to 3 questions, all correctly, and with an average of 15min per question. In comparison, with Sparklis-Analytics, the subjects managed to produce answers for 3-10 questions, 6.17 on average. This is 3.7 more questions, and the weakest result for our tool is equal to the strongest result for YASGUI. The rate of correct answers is also higher at 85%. Most errors (8/13) were done by only 2 subjects out of 12. The most common error is the omission of groupings in aggregations, suggesting to make them more visible in the user interface. The best subject answered to 10 questions, 8 of which were correct, and with an average of 4.5min per question. The time spent per question is generally higher for the first 2 questions, and generally stays under 10min for the other questions, although they are more complex, and can be as low as 2-3min. Those results demonstrate that, even without practice of our tool, subjects quickly learned to use it, and are much more effective with it. The weakest subject on Sparklis-Analytics is still as good as the strongest subject on YASGUI. Moreover, all subjects had better results with the former than with the latter.

Subjective results. As a first question, we asked subjects whether they (1) clearly prefer YASGUI, (2) would rather use YASGUI, (3) have no preference, (4) would rather use Sparklis-Analytics, or (5) clearly prefer Sparklis-Analytics. Over the 12 subjects, 9 clearly prefer Sparklis-Analytics and 3 would rather use Sparklis-Analytics, hence unanimous preference for our tool. As a second question, we asked them to evaluate the two systems on a 0-10 scale. YASGUI got marks between 2 and 8, 4.8 on average. Sparklis-Analytics got marks between 7 and 10, 8.3 on average (6/12 subjects gave 9-10 marks). From two other questions, we know that (a) 11/12 subjects think that knowledge about Semantic Web technologies is not necessary to use Sparklis-Analytics, and (b) 10/12 subjects said that non-IT people would quickly learn how to use Sparklis-Analytics. When asking them what they preferred in our tool compared to writing SPARQL, most said that "it is easyto-use and intuitive", and that "it is not necessary to make searches out of the application to find classes and properties".

QALD-6 Datacube Challenge

In this experiment, we evaluated our approach on a large and real dataset, and on a challenging set of questions. The QALD-6 challenge (Question Answering over Linked Data) introduced a new task (Task 3) on "Statistical question answering over RDF datacubes" [START_REF] Unger | 6th Open Challenge on Question Answering over Linked Data (QALD-6)[END_REF]. The dataset contains about 4 million transactions on government spendings all over the world, organized into 50 datacubes. Note that organisation into datacubes is not required by our approach, Questions. All 100 training questions and 50 test questions are basic or simple aggregations, except for two questions (training Q23 and test Q23) that are complex combinations (comparisons of two aggregations). The limitation to simple aggregations comes from the limited expressivity of existing systems. As a consequence, all questions can be answered with Sparklis-Analytics, and its "Examples" page provides the solutions to the 50 test questions as "Open" links.

Methodology. We participated to the challenge by going through the 150 questions, building a table query in Sparklis-Analytics for each question, and submitting the found answers for the 50 test questions. In order to estimate the usability of our approach on real and large data, we also asked a non-IT person to go through the same process. Her education is in business studies, she works mostly with Excel, and had never used our tool before the experiment. We therefore submitted two set of answers: expert and beginner. We wanted to involve more non-IT subjects but going through that experiment was quite time-consuming (10h in total for the beginner user). Still we believe that because of the very different profiles of those users our experiment is instructive from a qualitative point of view, and shows promising results. At the least, it demonstrates the possibility for a non-IT user to answer a large range of questions on real and complex data. To the best of our knowledge, no other tool achieves a similar result. During the test phase, we measured the clock time, including: question reading and understanding by the user, user actions in the tool, and computations by the tool and the endpoint.

Results and interpretation. Table 4 compares the performances of the expert and beginner users. The performance of the expert shows that virtually all questions (94%, F 1 = 0.95) can be answered accurately and (half questions answered in less than 1'30"), once the user is fluent in the use of the tool. Although the median time of the beginner is nearly three times higher (4') than for the expert, the success rate of 76% (F 1 = 0.82) is very satisfying for a beginner given the complexity of the data, and the novelty of the tool compared to Excel. Also, the maximum time per question does not differ drastically between the two users. The clock time measures of the expert imply that our tool is responsive because each question requires about 10 steps, each of which involves user action and SPARQL evaluation in addition to the computations specific to our approach. To compare with other challenge participants, which used automated question answering approaches, their success rate is 50% for QA 3 (F 1 = 0.53), and 38% for CubeQA (F 1 = 0.44).

The difference in success rate between expert and beginner is mitigated when looking at the cause of errors. Among the 6 beginner errors, 1 is explained by a lack of attention because the missed action was performed in several other questions, 3 are explained by a lack of exposure to a similar case during the training phase ("When" questions, numeric filters like "more than 10000000"), and 2 are explained by the difficulty to find the right property and value in a datacube. The 2 expert errors come from ambiguity in questions Q35 and Q42, which admit several equally plausible answers (e.g., several URIs have the same label). The explanation for unanswered questions is generally that the datacube is not explicit in the question. This requires to catch a first entity by string matching (e.g., "Research into Infrastructure" in Q33), which appeared to be inefficient and unreliable on the SPARQL endpoint. During the training phase, the expert user found a few errors in the manually crafted golden standard, which were reported to the organizers. At the QALD-6 workshop during ESWC'16, we were invited to give a talk in order to present our approach and results to the challenge (see [START_REF] Ferré | SPARKLIS on QALD-6 Statistical Questions[END_REF] for detailed results).

Data Analytics at Persée

Persée4 is a French organization that provides free access to more than 600,000 scientific publications, notably in the domain of humanities and social sciences. It maintains a SPARQL endpoint that gives access to their metadata5 , and they had already adopted Sparklis as an exploration and querying tool. We have contacted them in order to evaluate their need for analytical questions, in order to measure the adequacy of our approach to their needs. Without explaining them our approach or the range of questions that we cover, we collected a set of spontaneous questions they were interested in. To our surprise, those questions cover all kinds of uses cases presented in Section 2. We had rather expected simpler queries like retrieval queries, e.g. all publications of some author after some date. We here list a sample of representative questions, and then comment on them: Q1 How many documents a given person (e.g., Pierre Bourdieu) has co-authored with each of his co-authors? Q2 For each author, get the number and the list of the titles of his documents. Q3 How does the average number of authors per document evolves through time? Q4 Are there persons whose death date is before the birth date, thus revealing errors in data? Q5 Sort authors by decreasing duration of their activity period, computed as the difference between the maximal and the minimal publication date of their documents. Q6 For each publication year, get the number of articles published that year, and whose title matches a given term (e.g., "rural"), in order to study the evolution of that term across time.

Q1 and Q2 are aggregations, with two aggregators in Q2 ("the list of" translates to GROUP_CONCAT). Q3 is a nested aggregation, first counting authors per document, then averaging that count per publication year. Q4 involves a filter whose expression combines two properties of persons (birth date and death date). Q5 and Q6 are complex combinations of aggregations and bindings. In Q5, first two aggregations, a maximum and a minimum, then a binding for the difference, and finally a sorting. In Q6, first a filtering, then an aggregation. We did not receive any question that could not be answered with Sparklis-Analytics. This validates the relevance of our use cases, and the expressivity range of our table queries. Note that the Persée's dataset is not at all organized into data cubes, and does not even contain numerical data, apart from dates. The central property is the one relating documents to authors, which is an n-n relationship. As the above questions show, both documents and authors can be used either as a dimension or as a measure (counting authors per document or counting documents per author). This real use case therefore validates our direct approach to RDF data analytics.

CONCLUSION AND FUTURE WORK

We have shown how the expressivity of SPARQL 1.1 can be leveraged to offer rich data analytics on vanilla RDF graphs. This includes OLAP-like analytical queries, and goes beyond with nested aggregations, and combinations with bindings and filters. We have also shown how to make it accessible to people without knowledge of SPARQL, through a NLI. We have implemented our approach, and validated its expressivity, usability, and scalability in real settings. Future work includes the addition of higher-level constructs (e.g., 'the proportion of') to simplify frequent complex combinations of computations; and the graphical visualization of results (e.g., charts, maps, timelines).

Figure 2 :

 2 Figure2: Principle of the NF design pattern[START_REF] Ferré | Bridging the Gap Between Formal Languages and Natural Languages with Zippers[END_REF]

Figure 3 :

 3 Figure 3: Screenshot of Sparklis-Analytics at the last step of use case (C)

Table 1

 1

(left column). A Pattern-query is a primitive table query, ▷ is a binary operator, and Bind, Filter, Aggreg are unary operators. Those unary operators represent the computation of a table as a function of another table, as informally presented in Section 4.

Table 2 :

 2 Translation of table queries to SPARQL patterns

	T	Pattern T
	Pattern(X, P )	P

Table 3 :

 3 Query transformations (seeDefinition 6)

Table 4 :

 4 Performance on QALD-6 statistical questions by two different users

	user	answered	correct	min/median/max
		questions	answers	time
	expert	49/50 = 0.98 47/50 = 0.94	31"/1'30"/6'20"
	beginner 44/50 = 0.88 38/50 = 0.76	1'/4'/10'

unlike in other approaches. There are about 16M triples in total. For the evaluation, we used our tool with the following configuration: http://cubeqa.aksw.org/sparql as endpoint, and rdfs:label as labelling property for entities, classes and properties.

http://bit.ly/sparklis-analytics

http://bit.ly/sparklis-analytics.

We warmly invite the reader to look at the full screencast (2'54") of example (C) at https://youtu.be/MPiYMwxasFo.

http://www.persee.fr/

http://data.persee.fr/

Acknowledgement. I wish to thank QALD organizers for the datacube task, Pierre-Antoine Champin and Cécile Almonté for valuable feedback and suggestions, and Eléonore Jouffe and the Miage students at Univ. Rennes 1 for their participation to the user studies.

supported by ANR project IDFRAud (ANR-14-CE28-0012-02).

, ,