dataesr/scientific-paragraphs-categorization huggingface dataset:
Interactive database exploration Supporting Interactive Data Exploration (IDE) attracts a lot of attention these days  [1]. In their survey, Idreos et al. adopt a top-down viewpoint and classify the existing approaches in three main categories: user interaction, middleware and database layer. Techniques range from visual optimization (like query result reduction  [25] ), automatic exploration (like query recommendation  [26] ), assisted query formulation (like data space segmentation  [27] ), data prefetching (like result diversification  [28] ) and query approximation  [29]. One of the conclusion of this survey is that data navigation systems should be able to optimize exploration tasks, with user profile and navigation histories as corner stones of this optimization. We believe that our work contributes in this direction.
OLAP exploration of data warehouses is a particular use case of database exploration that enables to work with simplifying assumptions. Precisely, the multidimensional star schema or the regularities of multidimensional queries (as presented in Section 2) make possible the definition of simple, intuitive features like level depth, relative edit distance, etc. (see Section 3). Many approaches have been specifically developed to support OLAP exploration. For example, the PROMISE pre-fetching approach  [30]  predicts a query based on a Markov Model constructed out of the server's log. Sarawagi  [2]  proposes an advanced OLAP operator based on entropy maximization to detect surprising cells of a cube, based on the user's current exploration. Collaborative recommendation techniques have been used to recommend OLAP explorations based on the user's histories and a user's current navigation  [31].
Assessing database exploration The database community enjoys a variety of popular benchmarks to assess and compare the performance of database systems. The TPC  3 proposes benchmarks that include metrics covering time, performance, price, availability or energy consumption. However, while TPC acknowledges the importance of the explorative nature of decision support queries (see e. g. , the OLAP interactive queries in the TPC-DS benchmark), none of the existing TPC metrics are appropriate for measuring database exploration support. In other words, the existing benchmarks adopt a system-centric viewpoint, measuring the efficiency of data retrieval, and are not appropriate to measure exploration efficacy under a user-centric angle. Recently, Eichmann et al. discuss the need for new, user-centric benchmarks  [9].
Conclusion In this work, we have proposed an approach to automatically assess the quality of interactive OLAP explorations of data cubes. Our approach is based on a model of query contribution built using supervised learning and the assessment of the exploration relates to the user's skill of writing queries that contribute to the exploration. The tests conducted on both real and artificial explorations showed the validity of our approach. Our future works will first investigate the refinement of our model of query contribution, in particular by including complex features like Sarawagi's advanced OLAP operators  [2]. Another short term goal is to relax the assumption of multidimensional schema and query language, and target SQL explorations over less normalized databases. We identified SQLShare  [37] ) as a promising dataset to work with.
Figures 5 and 6 represent on the horizontal axis all the explorations considered for the experiment (39 for open dataset and 103 for enterprise dataset), and on the vertical axis the prediction of the level of expertise of the user provided by our KT model. The colors represent the assessments made by human experts. For the open dataset, it appears clearly that our model provides consistent evaluations, giving users a rating that corresponds to the assessment made by the expert. The distinction between competent analysts (A and B) and non-competent analysts (C) is clearly marked, in contrast to the distinction between A and B which is less pronounced. This can be explained by the fact that it is difficult for an expert to distinguish between a good analyst and a very good one. However, the distinction between a good and an unqualified analyst.
Range, average, standard deviation and computation time for the 25 features on the open dataset color, the greater the positive correlation, the darker the blue color, the greater the negative correlation. Medium tones indicate correlation close to 0. As an example, in the symmetric correlation matrix used to plot the heat map for the open dataset, the highest value (diagonal excluded) is 0. 95 while the lowest value is -0. 54. Out of the 300 coefficients, only 10 values are lower than -0. 3 and only 18 values are greater than 0. 6.
Figures 5 5 Figures 5 and 6 represent on the horizontal axis all the explorations considered for the experiment (39 for open dataset and 103 for enterprise dataset), and on the vertical axis the prediction of the level of expertise of the user provided by our KT model. The colors represent the assessments made by human experts. For the open dataset, it appears clearly that our model provides consistent evaluations, giving users a rating that corresponds to the assessment made by the expert. The distinction between competent analysts (A and B) and non-competent analysts (C) is clearly marked, in contrast to the distinction between A and B which is less pronounced. This can be explained by the fact that it is difficult for an expert to distinguish between a good analyst and a very good one. However, the distinction between a good and an unqualified analyst.
In addition, classes of the third level relate to various simulator classes that provide a set of services and basic non-energy functions. Figure  6  shows the UML class diagram of OMNeT++ energy model. The OMNeT++ energy model supports two forms of calculation, either using power and energy and their units are Watt and Joule respectively, or using charge and current, one of which uses Colomb and Ampere. Although, it is possible to switch from one form to another mathematically, the models in the simulator are built separately. This adds a layer of complexity and causes a repetition of the structure and calculations many times in the code line with only different units used. TOSSIM Energy model: TOSSIM includes the simplest energy model among all the studied models. The model is object-oriented and it does not include a battery model.
pdf), while for the 802. 15. 4 scenario was used the data sheet of CC2420 RF Module (http://www. ti. com/lit/ds/swrs041c/swrs041c. pdf). Each simulator was con-figured to use the models of the protocols with the values of the standards. The values of the energy consumption for each module is shown in Table  2. Step 5: Evaluate the measurable criteria. NS2 is only evaluated in Linux, since it is the only platform that supports its installation. OMNeT++/INET is installed on both Windows and Linux. The NS2 version used is the 2. 35 (https://sourceforge. net/projects/n-snam/), for OMNeT++, it is 5. 4. 1 (https://github. com/omnetpp/omnetpp/tree/omnetpp-5. 4. 1), and for INET, it is 4. 1. 0-810053f713 (https://github. com/inet-framework/inet/tre-e/v4. 1. 0). TOSSIM (PowerTOSSIM z) is not installed in none of the systems, since it has a poor level of support for the recent Operating System (OS) versions and it is not possible to install it on the SO used.
Thus, PowerTOSSIM z is not evaluated in terms of measurable criteria. We show how the quantitative criteria are measured as follows. Performance scenarios: In these scenarios, the CPU utilization is evaluated for the simulators during 100 seconds of simulation. Results of the evaluation of CPU utilization for different BCs are shown in Figure  9. NS2 tends to consume all available CPU cycles, whatever the number of the BCs is, while OMneT++ consumes the CPU differently in Linux than in Windows. Figure  9  shows that the CPU utilization in Windows is always less than Linux when the same scenario is implemented. In both OS, as the number of BCs increases, the average value of CPU utilization increases as well. Figure  10  represents the results of memory usage for both simulators on a logarithmic scale as the number of BCs increases.
NS2 shows proper memory usage when the BCs are 4 or less. After that, the usage tends to follow an exponential orientation. On both OS, OMNeT++ shows a strictly controlled memory usage as the number of the BCs increases. The memory usage in Windows shows lower values compared to Linux when the same scenario is being implemented. To obtain the execution time in OMNeT++, the express-mode is used, since the normal mode was intentionally built to run slowly to allow the user to trace the events that are occurring during the simulation. Figure  11  represents the execution time for the simulators on a logarithmic scale. We note that NS2 has lower execution time for the scenarios with less than 16 BCs, while OMNeT++ has lower execution time for the scenarios that have 16 BCs or more. The execution time of OMNeT++ in Windows and Linux are similar.
OMNeT++ stores information about the simulations in files, that can be exported in multiple formats for later data processing. OMNeT++ shows the same results both on Windows and Linux, regarding the energy consumption evaluation. Therefore, the results of the energy consumption scenario in OMNeT++ are presented only once and without mentioning the OS. The energy model in both simulators trace only the energy consumption of RF module, i. e. , the consumption of the node CPU and the sensors are not included. By comparing the results for the same scenarios obtained from NS2 and OMNeT++, there are differences and similarities. In the 802. 11b scenarios, both simulators have the capability to accurately simulate the CSMA/CA mechanism, including parameters of PHY and MAC layers of each frame sent during each phase of the mechanism, such as RTS and CTS frames.
Additionally, the data and ACK frames are simulated as well. The implementation uses the standard guideline to define the length of each frame used in the protocol, as well as the preamble length and the PHY header. The time spent sending RTS, CTS, and ACK frames are similar for both simulators as shown in Table  3. But the time spent to send data frames is higher in the OMNeT++ simulator as Table  4  shows. By examining one of the repeated interval of the simulation (i. e. , the time that includes sending one ping message), the results show that the energy consumption of both sim-ulators are not the same. Figure  12  shows the energy consumption in an interval when the frequency is 1 Hz, for the 802. 11b scenario, for both simulators. Each pair of columns represents a payload size; the columns to the right is for results obtained from OMNeT++, while the column to the left is for results obtained from NS2.
In general, when the same scenario is implemented, the reported energy consumption in OMNeT++ is slightly higher than NS2 (less than 5%). It is possible to trace the results obtained from the simulators in Table  3  and Table  4 , there are different values for the same activities when sending and receiving data frames. These differences between the time spent in sending each frame appears in all the scenarios for 802. 11b. It is the cause of the difference in energy consumption between the two simulators. In the 802. 15. 4 scenarios, both simulators present different implementations of the proto-col, this, in turn, affects the energy consumption. Figure  13  shows the energy consumption for one interval of 802. 15. 4, when frequency is 1 Hz. Step 6: Elaborate a discussion. From the methodological process, it is possible to detect advantages and disadvantages of the three analyzed WSN simulators.
In the following, the analysis is divided into three sections based on the discussed subject. On qualitative criteria: NS2 is a generic data network simulator that was later adapted to suit WSN, while OMNeT++, was built to support the WSN from the beginning. TOSSIM, is an emulator for TinyOS, which is an OS widely used for embedded systems. The principal drawback of TOSSIM is that it is not compatible with the modern OS. It was not possible to install and run the evaluation scenarios in TOSSIM. Thus, only the qual-itative parameters are available for the comparison with the other simulators. Although, NS2 is only supported on Linux, and despite the fact that it is no longer maintained in favor of NS3, it is one of the most cited simulators in the research domain, meaning that NS3 has not completely replaced NS2.
NS3 is still in development and many protocols supported in NS2 have not been yet implemented in NS3. OMNeT++ is supported both on Linux and Windows. The project is still maintained and regularly updated. On energy models: Energy modeling in WSN simulation includes three aspects: the harvesting, storage, and consumption of energy. The studied simulators handle these aspects in different manners. NS2 does not include energy harvesting. However, storage and consumption are considered and modeled. Energy stored in watts, and each activity taking place in the node consumes a specific amount of energy that is calculated based in different parameters. For example, when sending data packets, bit rate and payload lengths impact energy consumption. The machine state, shown in Figure  4 , controls the the sequence of the activities.
OMNeT++ has an object-oriented energy model that links together different models for harvesting, storage, and consumption of energy. As illustrated in Figure  6 , the structure of the model allows the creation of different models under each category. There are two possibilities for the units to be used: charge and current or power and energy. The user is to choose a possibility before running the simulation. Then, the transformation is not possible. Both in NS2 and OMNeT++, the consumption model is limited to the RF module, thus sensors processing units activities are not included, although they are responsible for a considerable amount of consumed energy  [46]. TOSSIM model is simple and easy to use, but it has some drawbacks. First, the design includes the use of different functions to provide the same service, the only difference is the corresponding circuit, i.
Additionally, although scalability was included in the proposed criteria, outlines can be drawn for this item by analyzing the results obtained from the previously mentioned items. -CPU consumption: NS2 shows the same behavior regardless of the number of nodes, it uses all available CPU cycles. This leads to a very low execution time when the number of nodes is small. On the other hand, OMNeT++ is more conservative. In Windows, the CPU consumption starts around 70% for scenarios with a small number of nodes. Then, the consumption grows as the number of nodes increases. In Linux, OMNeT++ shows similar behavior except for the starting threshold raises to 90%. In general, from a CPU consumption point of view, OMNeT++ in Windows consumes the CPU the least, when the same scenarios are being executed.
Related Work. Over the last two decades, we have witnessed the establishment of several software tool competitions  [33, 1, 21, 23, 22, 8]  with the goal of advancing the state-of-the-art in the computer-aided verification technology. In particular, in the area of software verification, there are three related competitions: SV-COMP  [8] , VerifyThis  [22]  and the RERS Challenge  [21]. SV-COMP targets tools for software model checking, while CRV is dedicated to monitoring tools analyzing only a single program's execution using runtime and offline verification techniques. While in software model checking the verification process is separated from the program execution, runtime verification tools introduce instead an overhead for the monitored program and they consume memory resources affecting the execution of the program itself.
Offline Track Online C Track Online Java Track AgMon  [25]  E-ACSL  [13]  JavaMOP  [24]  BeepBeep3  [19]  MarQ  [2]  JUnitRV [12] Breach RiTHM-1  [28]  Larva [9] CRL  [30]  RTC  [27]  MarQ  [2]  LogFire  [20]  RV-Monitor  [26]  Mufin  [11]  MonPoly  [7]  TimeSquare  [10]  RV-Monitor [26] MarQ  [2]  OCLR-Check  [15]  OptySim  [14]  RiTHM-2  [28]  RV-Monitor  [26]  3. Clarification Phase. The benchmarks resulting from the previous phase were made available to participants. This phase gave participants an opportunity to seek clarifications from the authors of each benchmark. Only benchmarks that had all clarifications dealt with by the end of this phase were eligible for the next phase. 4. Monitor Phase. In this phase, participants were asked to produce monitors for the eligible benchmarks. Monitors had to be runnable via a script on a Linux system.
Monitor code should be generated from the participant's tool (therefore the tool had to be installable on a Linux system). 5. Evaluation Phase. Submissions from the previous phase were collected and executed, with relevant data collected to compute scores as described later. Participants were given an opportunity to test their submissions on the evaluation system. The outputs produced during the evaluation phase were made available after the competition. Input Formats. The competition organizers fixed input formats for traces in the offline track. These were based on XML, JSON, and CSV and evolved between the first and second years of the competition based on feedback from participants. The CSV format proved the most popular for its simplicity and is now used by many RV tools. See the competition report from 2015  [18]  for details.
Participants. Over the first three years of the competition 14 different RV tools competed in the competition in the different tracks. These are summarized in Table  1. One of these tools, Mufin, was written specifically in response to the competition and all tools were extended or modified to handle the challenges introduced by the competition. Benchmarks. Benchmarks, as submitted by the participants, should adhere to requirements that ensured compliance with the later phases of the competition. This also ensured uniformity between benchmarks and was also the first step in building a benchmark repository dedicated to Runtime Verification. A benchmark contains two packages: a program/source package and a specification package. The program/source package includes the traces or the source of the program as well as scripts to compile and run it.
Results were available through the Web interface. Winners. Table  2  indicates the winners in each track in each year. The detailed results are available from the competition website and associated reports  [3, 5, 18]. In 2014, the scores in the Online Java track were so close that a joint winner was announced. In 2016, only one participant entered the C track and the track was not run. (We note that, more tools have been developed for monitoring Java programs thanks to the AspectJ support for instrumentation. ) Issues. The early years of the competition were successful in encouraging RV tool developers to agree on common formats but the number of participants dropped in each year with two main issues identified: 1. The amount of work required to enter was high. This was mainly due to the need to translate each benchmark into the specification language of the entered tool.
II. STATE OF THE ART Recent advances in smart building methodologies have focused on human occupancy in order to increase the performance of buildings. Several approaches have been proposed by researchers in the field for activity recognition and occupancy analysis. The learning generally involves creating a probabilistic or statistical model trained via large training or learning dataset. The aim of the model is to learn and recognize patterns that differentiate classes in the training data and apply this knowledge for the prediction/classification of test data in order to solve the problem without necessarily providing it with domain-specific knowledge. Since the problem emanates from pattern recognition, or data analysis such methods are termed data-driven. Reference  [6]  identifies such data-driven approaches and classified them into (a) a generative modeling  [7] , (b) discriminate modeling  [8] , and (c) heuristic-based modeling  [9].
However, we expect complex correlations between the typical symptoms of a given disease. Indeed we can imagine two symptoms very plausible individually but which rarely occur together (or even never in the case of incompatible symptoms like for example microcephaly and macrocephaly). Note also that the assumption of conditional independence would make it possible to present a disease without having any of the symptoms related to this disease in the database (when there is no B i such that P[B i | D] = 1), which should be impossible. Generally speaking if we had enough empirical data, we would no longer need the experts. Conversely, without empirical data, our model must be based entirely on experts. We detail here two different approaches to deal with intermediate regime where we do not have enough data to do without the a priori given by the experts but where we have enough data to correct and specify this initial a priori.
The construction of a Bayesian network implies first of all to infer its structure, i. e. to determine the nodes that must be linked by an edge of those that can be considered conditionally independent to the rest of the graph (structure learning). Then, learning the network implies learning the parameters, i. e. the probabilities linking the nodes (parameter learning). It is therefore natural to also find in this area of the literature works that aimed at mixing expert and empirical data. In  [31]  the experts' indications take a particular form since they indicate by hand correlations, positive or negative, between variables. The approach of  [7]  is also quite distant because it is preferably based on data. [7]  only uses expert indications for additional variables for which there are no data, typically rare events never observed in the database.
Conclusion and perspectives In this work we have presented a way to combine expert knowledge, taking the form of marginal probabilities and rules, together with empirical data so as to estimate a given discrete probability distribution. This problem has emerged from our application where we aim to learn the probability distribution of the different combinations of symptoms given the disease. For this objective we have an initial a priori consisting of the marginal distributions coming from the medical literature and clinical data collected as the decision support tool is used. The particular form of the prior does not allow us to simply adopt a maximum a posteriori (MAP) approach. The absence of an obvious a priori to modelize the parameter's distribution naturally leads us to the idea of maximum entropy : if no model seems more plausible to us than another, then we will choose the least informative.
Acknowledgements Rémi Besson  thanks  Frédric Logé-Munerel  for fruitful discussions about this work. This work is supported by a public grant overseen by the  French National research Agency (ANR)  as part of the " Investissement dAvenir" program , through the " IDI 2017 " project funded by the  IDEX Paris-Saclay ,  ANR-11-IDEX-0003-02.