dataesr/scientific-paragraphs-categorization huggingface dataset:
To provide stable and responsive public SPARQL query services, data providers enforce quotas on server usage. Queries which exceed these quotas are interrupted and deliver partial results. Such interruption is not an issue if it is possible to resume queries execution afterward. Unfortunately, there is no preemption model for the Web that allows for suspending and resuming SPARQL queries. In this paper, we propose SaGe: a SPARQL query engine based on Web preemption. SaGe allows SPARQL queries to be suspended by the Web server after a fixed time quantum and resumed upon client request. Web preemption is tractable only if its cost in time is negligible compared to the time quantum. The challenge is to support the full SPARQL query language while keeping the cost of preemption negligible. Experimental results demonstrate that SaGe outperforms existing SPARQL query processing approaches by several orders of magnitude in term of the average total query execution time and the time for first results.
Then, the client can resume query execution by sending S i back to the Web server. Web preemption adds an overhead for the Web server to suspend the running query and resume the next waiting query. Consequently, the main scientific challenge here is to keep this overhead marginal whatever the running queries, to ensure good query execution performance. The contributions of this paper are as follows: • We define and formalize a Web preemption model that allows to suspend and resume SPARQL queries. • We define a set of preemptable query operators for which we bound the complexity of suspending and resuming of these operation, both in time and space. This allows to build a preemptive Web server that supports a large fragment of the SPARQL query language. • We propose SaGe, a SPARQL query engine, composed of a preemptive Web server and a smart Web client that allows executing full SPARQL queries 3.
• We compare the performance of the SaGe engine with existing approaches used for hosting public SPARQL services. Experimental results demonstrate that SaGe outperforms existing approaches 3 The SaGe software and a demonstration are available at http://sage. univ-nantes. fr arXiv:1902. 04790v1 [cs. DB] 13 Feb 2019 PREFIX dbo : < h t t p : / / d b p e d i a. o r g / o n t o l o g y / > PREFIX r d f s : < h t t p : / / www. w3. o r g / 2 0 0 0 / 0 1 / r d f -schema # > SELECT ? a c t o r ? name ? b i r t h P l a c e WHERE { ? a c t o r a dbo : A c t o r ; r d f s : l a b e l ? name ; dbo : b i r t h P l a c e ? c i t y. ? c i t y a dbo : C i t y ; r d f s : l a b e l ? b i r t h P l a c e. } by several orders of magnitude in term of the average total query execution time and the time for first results.
Web Preemption Model We consider a preemptive Web server, hosting RDF datasets, and a smart Web client, that evaluates SPARQL queries using the server. For the sake of simplicity, we only consider read-only queries 7  in this paper. The server has a pool of server workers parameterized with a fixed time quantum. Workers are in charge of queries execution. The server has also a query queue to store incoming queries when all workers are busy. We consider an infinite population of clients, a finite server queue and a finite number of Web workers. The preemptive Web server suspends and resumes queries after the time quantum. A running query Q i is represented by its physical query execution plan, denoted P Q i. Suspending the execution of Q i is an operation applied on P Q i that produces a saved state S i ; Suspend(P Q i ) = S i.
Preemptable Index Loop join: The Index Loop join algorithm  [12]  exploits indexes on the inner triple pattern for efficient join processing. This algorithm has already been used for evaluating BGPs in  [16]. SaGe extends the classic Index Loop joins to a Preemptable Index join Iterator (PIJ-Iterator) presented in Algorithm 5. To produce solutions, the iterator executes the same steps repeatedly until all solutions are produced: (1) It pulls solutions mappings µ c from its predecessor. (  2  A PIJ-Iterator supports preemption through the Stop, Save and Load functions. The non-interruptible section of GetNext() only concerns a scan in the dataset. Therefore, in the worse case, the iterator has to wait for one index scan to complete before being interruptible. As with the merge join, the Save and Load functions needs to stop and resume the left join input.
SaGe smart Web client The SaGe approach requires a smart Web client for processing SPARQL queries for two reasons. First, the smart Web client must be able to continue query execution after receiving a saved plan from the server. Second, as the preemptable server only implements a fragment of SPARQL, the smart Web client has to implement the missing operators to support full SPARQL queries. It includes SERVICE, ORDER BY, GROUP BY, DISTINCT, MINUS, FILTER EXIST and aggregations (COUNT, AVG, SUM, MIN, MAX), but also ▷◁, ∪, ▷◁ and π to be able to recombine results obtained from the SaGe server. Consequently, the SaGe smart client is a SPARQL query engine that accesses RDF datasets through the SaGe server. Given a SPARQL query, the SaGe client parses it into a logical query execution plan, optimizes it and then builds its own physical query execution.
EXPERIMENTAL STUDY We want to empirically answer the following questions: What is the overhead of Web preemption in time and space? Does Web preemption improves the average workload completion time? Does Web preemption improves the time for first results? What are the client overheads in terms of numbers of requests and data transfer? We use Virtuoso as the baseline for comparing with SPARQL endpoints, with TPF and BrTPF as the baselines for LDF approaches. We implemented the SaGe client in Java, using Apache Jena 11. As an extension of Jena, SaGe is just as compliant with SPARQL 1. 1. The SaGe server is implemented as a Python Web service and uses HDT  [9]  (v1. 3. 2) for storing data. Notice that the current implementation of HDT cannot ensure loд b (n) access time for all triple patterns, like (?s p ?o).
Experimental setup Dataset and Queries: We use the Waterloo SPARQL Diversity Benchmark (WatDiv 13 )  [1]. We re-use the RDF dataset and the SPARQL queries from the BrTPF  [15]  experimental study 14. The dataset contains 10 7 triples and queries are arranged in 50 workloads of 193 queries each. They are SPARQL conjunctive queries with STAR, PATH and SNOWFLAKE shapes. They vary in complexity, up to 10 joins per query with very high and very low selectivity. 20% of queries require more than ≈ 30s to be executed using the virtuoso server. All workloads follow nearly the same distribution of query execution times as presented in Figure  6. The execution times are measured for one workload of 193 queries with SaGe and an infinite time quantum. Approaches: We compare the following approaches: • SaGe: We run the SaGe query engine with various time quantum: 75ms and 1s, denoted SaGe-75ms and SaGe-1s respectively.
Experimental results We first ensure that the SaGe approach yield complete results. We run both Virtuoso and SaGe and verify that, for each query, SaGe delivers complete results using Virtuoso results as ground truth. What is the overhead in time of Web preemption? The overhead in time of Web preemption is the time spent by the Web server for suspending a running query and the time spent for resuming the next waiting query. To measure the overhead, we run one workload of queries using SaGe-75ms and measure time elapsed for     the Suspend and Resume operations. Figure  7  shows the overhead in time for SaGe Suspend and Resume operations using different sizes of the WatDiv dataset. Generally, the size of the dataset does not impact the overhead, which is around 1ms for Suspend and 1. 5ms for Resume.
Such queries verify conditions for using BindLeftJoin and OptJoin. They are challenging for the BindLeft-Join as they generate many mappings; they are also challenging for the OptJoin as all joins yield results. Table 3(b)  shows the results when evaluating OPTIONAL queries with OptJoin and BindLeft-Join approaches. We observe that, in general, OptJoin outperforms BindLeftJoin. Furthermore, OptJoin is improved when using a higher quantum, as the single subquery sent is evaluated more quickly. This is not the case for BindLeftJoin, as the number of requests still depends on the number of intermediate results. Finally, we re-use 166 SELECT queries from Feasible  [23]  with the DBpedia 3. 5. 1 dataset, which were generated from real-users queries. We excluded queries that time-out, identified in  [23] , and measure the number of requests sent to the server.
SaGe opens several perspectives. First, for the sake of simplicity, we made the hypothesis of read-only datasets in this paper. If we allow concurrent updates, then a query can be suspended with a version of a RDF dataset and resumed with another version. The main challenge is then to determine which consistency criteria can be ensured by the preemptive Web server. As SaGe only accesses the RDF dataset when scanning triple patterns, it could be possible to compensate concurrent updates and deliver, at least, eventual consistency for query results. Second, we aim to explore how the interface of the server can be extended to support named graphs and how the optimizer of the smart client can be tuned to produce better query decompositions, especially in the case of federated SPARQL query processing.
A Preemptable Index Scan Iterator, evaluating a triple pattern tp using an index Require: tp: triple pattern, D: RDF dataset queried, I tp : clustered index over tp Data: t: last matching RDF triple read 1 Function GetNext(): ← next RDF triple matching tp in D 4 let µ ← set of solutions mappings such as µ(t) = tp Save(): 7 return ⟨tp, id(t)⟩ 8 Function Load(id): 9 t ← I tp. Locate(id) // Locate the last triple read Basic Graph patterns (AND):. A Basic Graph pattern (BGP) evaluation corresponds to the natural join of a set of triple patterns. Join operators fall into three categories [11]: (1) Hash-based joins e. g. , Symmetric Hash join or XJoin, (2) Sort-based joins, e. g. , (Sort) Merge join, (3) Loop joins, e. g. , index loop or nested loop joins.
A Preemptable Merge Join Iterator I , joining the output of two iterators I left and I right. Require: I left : the outer join input, I right : the inner join input, µ l : the last element read from I left , µ r : the last element read from I right , D: RDF dataset queried 1 Function Stop(): left. Stop() right. Stop() 4 Function Save(): 5 let s l ← I left. Save() 6 let s r ← I right. Save() ⟨s l , s r , µ l , µ r ⟩ Load(s l , s r , µ ′ l , µ ′ r )left. Load(s l ) right. Load(s r ) A Preemptable Index Join Iterator I i : a preemptable join operator used by SaGe for BGP evaluation Require: I left : the iterator responsible for the evaluation of the outer join input, tp r : the inner join input, D: RDF dataset queried. 1 Function Open(): left. Open() find ← a PreemptableIndexScanIterator over ∅ ¬I find.
Algorithm 3 : 3 t 5 return µ 6 Function 3356 A Preemptable Index Scan Iterator, evaluating a triple pattern tp using an index Require: tp: triple pattern, D: RDF dataset queried, I tp : clustered index over tp Data: t: last matching RDF triple read 1 Function GetNext(): ← next RDF triple matching tp in D 4 let µ ← set of solutions mappings such as µ(t) = tp Save(): 7 return ⟨tp, id(t)⟩ 8 Function Load(id): 9 t ← I tp. Locate(id) // Locate the last triple read Basic Graph patterns (AND):. A Basic Graph pattern (BGP) evaluation corresponds to the natural join of a set of triple patterns. Join operators fall into three categories [11]: (1) Hash-based joins e. g. , Symmetric Hash join or XJoin, (2) Sort-based joins, e. g. , (Sort) Merge join, (3) Loop joins, e. g. , index loop or nested loop joins.
Algorithm 4 : 2 I 3 I 7 return 8 Function: 9 I 10 I 11 µ l ← µ ′ l 12 µ r ← µ ′ r Algorithm 5 : 2 I 3 µ c ← nil 4 I 5 Function GetNext(): 6 while 8 if µ c = nil then 9 return nil 10 I 13 return µ ∪ µ c 14 Function 15 tp r ← tp ′ 16 if µ ′ nil then 17 µ c ← µ ′ 18 I 19 I 21 let t ← the last triple read by I find 22 return ⟨tp r , µ c , t⟩ 23 Function Stop(): 24 I 25 I 4237891011125234568910131415161718192122232425 A Preemptable Merge Join Iterator I , joining the output of two iterators I left and I right. Require: I left : the outer join input, I right : the inner join input, µ l : the last element read from I left , µ r : the last element read from I right , D: RDF dataset queried 1 Function Stop(): left. Stop() right. Stop() 4 Function Save(): 5 let s l ← I left. Save() 6 let s r ← I right.
Save() ⟨s l , s r , µ l , µ r ⟩ Load(s l , s r , µ ′ l , µ ′ r )left. Load(s l ) right. Load(s r ) A Preemptable Index Join Iterator I i : a preemptable join operator used by SaGe for BGP evaluation Require: I left : the iterator responsible for the evaluation of the outer join input, tp r : the inner join input, D: RDF dataset queried. 1 Function Open(): left. Open() find ← a PreemptableIndexScanIterator over ∅ ¬I find. HasN ext() do 7 µ c ← I left. GetN ext() find ← PreemptableIndexScanIterator over ⟦µ c (tp r )⟧ D 11 non interruptible 12 let µ ← I find. GetN ext() Load(tp ′ , µ ′ , t): find ← PreemptableIndexScanIterator over ⟦µ c (tp i )⟧ D find. Load(t); 20 Function Save(): left. Stop() find. Stop().
In this work, we present the development of models for the prediction of the Equivalent Alkane Carbon Number of a dead oil (EACNdo) usable in the context of Enhanced Oil Recovery (EOR) processes. Models were constructed by means of data mining tools. To that end, we collected 29 crude oil samples originating from around the world. Each of these crude oils have been experimentally analysed, and we measured property such as EACNdo, American Petroleum Institute (API) gravity and C 20 À , saturate, aromatic, resin, and asphaltene fractions. All this information was put in form of a database. Evolutionary Algorithms (EA) have been applied to the database to derive models able to predict Equivalent Alkane Carbon Number (EACN) of a crude oil. Developed correlations returned EACNdo values in agreement with reference experimental data.
[16]. The use of our model for the prediction of live crude oil EACN  [14]  would gain in relevancy developing methods to predict crude oil EACNdo. A crude oil contains thousands of diverse chemicals and the exact composition is never known, as a consequence the combined use of above mentioned models and mixing rules to predict EACNdo is unrealistic. During the past decade, we considered the use of data mining based approaches to extract information from databases and predict properties of complex fluids  [17]. These approaches known by the acronym QSPR aim at identifying non-obvious correlations between property values of the matter and some features rendering information about the matter  [18, 19]. In this work, we propose (i) the creation of a database containing experimental EACNdo values as well as results of experimental analysis for a series of crude oils, (ii) the application of machine learning methods to derive models for the prediction of crude oil EACN values, and (iii) the use of developed models for the prediction of live oil EACN for a set of crude oils.
Experimental data and database creation Wan et al. proposed a review and comparisons of applicable approaches to experimentally determine the EACN of a dead crude oil  [20]. As detailed in previous works  [7, 8] , all EACNdo values reported hereafter were obtained following the method referred to as the direct method by Wan et al. This method is mainly based on the use of equation  (1)  and consists in performing several phase diagrams for a {brine/surfactant/crude oil} system varying the salt concentration, i. e. a salinity scan. The S* for the {brine/surfactant/crude oil} system is reached when the phase diagram exhibits an equal repartition of the microemulsion between the oil and the aqueous phase. The so-obtained salinity scan and the S* value are then compared to those previously obtained for similar conditions (surfactant formulation, temperature, brine composition.
Data sets The accuracy of predictive QPPR (similarly to QSPR) is in part related to the quality of data, hence the quality of the database is a keystone for the success of such modeling works. Possible correlations between descriptors have been investigated by generating a correlation matrix by means of the Materials Studio software  [31]. No evidence of highly correlated descriptors has been found, and the highest values in the correlation matrix were obtained for couples: Res. with Aro. and Res. with C 20 À. Fan and Buckley proposed on the basis of six medium-gravity dead crude oils (with API gravity values from 22. 6 to 37. 2) a relation between API gravity and SARA fractions  [25]. No evidence of such a relation has been found in our data set. The best found correlation between API gravity and SARA fractions has a low coefficient of determination (R 2 ' 0.
4). Data presented in the Table  1  have been used to constitute our database. As a preprocessing of the data, we performed a Principal Component Analysis (PCA) applied on API gravity, C 20 À and SARA fractions measured for the 29 crude oil samples. Figure  1  presents projections of the 29 crude oils in the space formed by the three main principal components resulting from the PCA. The diagram thus provides a representation of crude oil distributions in the chemical space of our database. This distribution reveals that one crude oil (crude oil #02) is isolated from all other samples that thus confirms crude oil #02 as an outlier. In Figure  1 , each symbol is filled as a function of their EACNdo value, and there is no obvious relation between the location of a crude oil on the diagram and the value of its EACNdo.
Application of external validation has been shown as necessary to validate model's robustness when predicting new compound property values, meaning candidates not used during the model development  [32]. One of the popular methods is the n-fold Cross-Validation (n-CV) in which the data set is randomly divided in approximately equal n portions, the leave-one-out being its extreme version with n equals the number of samples in the database. An aggregate of (nÀ1) portions forms the Training set used to optimize predictive models, the remaining portion constituting the Test set. We emphasize that no data point belonging to external sets is used to derived models. This procedure is repeated n times choosing at each new fold another portion of data as a Test set. From conclusions drawn during the preprocessing of the database, we choose to impose crude oils #01 and #02 in all Training sets in order to keep EACNdo ranges constant.
The 27 remaining crude oils were randomly distributed into nine portions, therefore the Training sets and Test sets represent 90% and 10% of the database, respectively. Perfomances of models are evaluated on both Training and Test sets calculating values for some statistical indicators such as the Mean Absolute Error (MAE), Root Mean Square Error (RMSE), R 2 , and the Concordance Correlation Coefficient (CCC)  [33]. Chirico and Gramatica have shown that the use of this latter coefficient is advocated considering various scenarios such as location shifts, scale shifts, and location plus scale shifts  [34, 35].
Descriptor Descriptor Constant Function Function Fig. 2. Schematic representation of a tree. Function stands for a mathematical operator belonging to the function set (see Tab. 2), for instance +, À, Â or Ä. Descriptor denotes either API gravity, fractions of C 20 À , Sat. , Aro. , Res. , or Asp. During the development of GFA based models, the maximum number of variables allowed to form equations was set to four. This value meets the statistical criteria n ! 4k, where k and n are the number of variables in the model and the number of data points in the Training set, respectively  [39]. GFA based models were optimized following a 9-fold cross-validation procedure. Samples #01 and #02 are fixed in Training sets, and therefore each of the nine folds contains three randomly selected crude oils.
Equation (  4 ) presents the so-obtained model. This model is composed of three descriptors weighted by k i coefficients, and a constant k 0 as follows: EACNdo ¼ k 0 þ k 1 C 20 À þ k 2 Sat: þ k 3 Asp:; ð4Þ k i values obtained considering successively each fold as external data (not used during the optimization procedure) are reported in Table  3. Equation (  4 ) is in line with some physical intuitions. For instance, the negative value of k 1 agrees with the fact that EACNdo should decrease with increasing C 20 À fractions (the light fraction of the crude oil). The opposite effect is observed through out the positive values for k 2 and k 3 , i. e. EACNdo values should increase with Sat. and Asp. fractions (heavy fractions of the crude oil). Note that the value obtained for k 0 roughly corresponds to the average of EACNdo values in the database (12.
Considering both the database content and the Training/Test splitting, a reasonable value for the maximum number of genes is 6. Regarding settings dedicated to tree's structure, the maximum number of nodes per tree and the maximum depth of tree have been set to 12 and 4, respectively. For settings related to convergence of calculations, the maximum number of generations and the maximum number of runs have been set to 2000 and 40, respectively. In order to allow a great possibility in nonlinear models, we have chosen a large number of mathematical operators such as addition, subtraction, multiplication, division, square root, exponential, logarithm. We propose an approach to optimize the numbers of runs, generations, genes, and nodes that will further be used to develop a model. The convergence matter was first addressed, and the trade-off between convergence, computational time, and accuracy was treated as follows: (i) The numbers of genes and nodes were set to their respective maximum possible value in order to generate models with the highest complexity.
We then compared model's performances exploring the space formed by the number of generations discretized as follows: 100, 500, 1000, and 2000, and by the number of runs discretized as follows: 1, 5, 10, 15, 20, 25, 30, and 40, as indicated in Table  2. Performances were evaluated using the RMSE statistical indicator calculated over all samples in the dataset. No Training and Test sets division was considered in this step as the idea is to roughly select appropriate numbers of runs and generations, leading to reasonable accuracy and computational time. Figure  4  presents the power law evolution of model's performance as a function of numbers of runs and generations. Clearly, models poorly perform when optimized with only 100 generations. Considering 500, 1000 or 2000 generations leads roughly to similar performances after 20 runs.
For each point of the space, sum of squared errors were calculated for Test sets, and the optimum numbers of genes and nodes were determined minimizing the total sum of squared errors on Test sets. The optimization procedure led to a number of nodes of 8 and a number of genes of 4. The proposed optimization procedure applied to our regression problem led to numbers of runs, generations, genes, and nodes of 30, 500, 4, and 8, respectively. Nine GPTIPS based models were optimized following a 9-fold crossvalidation procedure, noting that the nine folds generated for the GFA based model development have been reused. Performances of models are presented in Table  5. All models outperform GFA based models, and exhibit RMSE values in between 0. 97 and 1. 40. The model that best generalizes the database has been developed using Fold-08 as Test set.