dataesr/scientific-paragraphs-categorization huggingface dataset:
A data cube is a multidimensional representation of data where cells represent measure values, and coordinates represent analysis criteria values. In a flattened representation, a data cube corresponds to a table with multiple entries where axes (columns and rows) represent analysis criteria, and cells represent measure values. Data cubes can be implemented in three main ways: (a) pre-computation and storage in optimized multidimensional arrays (Multidimensional OLAP (MOLAP)); (b) storage in relational databases (ROLAP); and (c) Hybrid OLAP (combination of ROLAP and MOLAP). The relational implementation presented in Section 2. 3 remains the most dominant implementation. Decision makers explore these data cubes by navigating through dimension hierarchies and performing OLAP operators. Common OLAP operators are the following: "Slice", which defines a selection on one dimension of the cube; "Dice", which performs a selection on two dimensions or more; "Roll-up", which decreases the granularity of the measure values by aggregating them along a dimension hierarchy; and "Drill-down", which is the reverse of Roll-up.
A basic indicator (bbBasicIndicatorNN) is defined as a set of aggregations that apply to one measure. For example, the "Average population" is a basic indicator. A derived indicator is defined as an expression over basic indicators and may concern many measures. In Table  2 , we summarize all necessary stereotypes to understand the cube models of Section 5. 1. Finally, our profile for DWs has been implemented with a UMLbased tool called MagicDraw. 1 This implementation allows designers to design the DW conceptual model graphically using our UML profile and to check its validity (the absence of errors and contradictions in the model). We have also developed a code generator to transform DW models automatically and designed our profile into implementations (DW and OLAP physical schemas).
Data marts can be fed with data sources or DW data. DWs and DMs are managed using a Relational DataBase Management System (DBMS) such as PostgreSQL. The DW/DM data can be structured following three schema types: star, snowflake or starflake. In the star schema, every dimension is represented by one table containing all its aggregation level attributes as columns. In the snowflake schema, dimensions are normalized, and each aggregation level is mapped into one table. The starflake schema combines the two representations by normalizing some dimensions or parts of dimensions and denormalizing others. In all of these schema types, each analysis subject (fact) is represented by one table that references the dimension tables by using foreign keys. The well-known constellation schema (a constellation of stars, or snowflakes, or starflakes) is obtained when the MD model is composed of two or more cubes, which eventually share some dimensions.
(Bédard et al. , 2007; Miquel et al. , 2010). However, only  Chen et al. (2007) ,  McGuire and Gangopadhyay (2006) , and  Wang and Guo (2013)  investigate this technology in the specific domain of water quality management. McGuire and Gangopadhyay (2006)  present a multidimensional data model that allows the analysis of only one hydrobiological water quality parameter (The Fish Index of Biotic Integrity) at multiple spatial resolutions. The data model was implemented in a relational database management system and linked with a GIS that provides users with visualizations of data on different spatial scales. As the authors exploit a GIS (ArcGIS), using this solution may require a certain level of experience in geographic systems. Additionally, using the proposed solution in other application domains can be difficult because no detail is provided for the general architecture.
0 was adopted to integrate qualified data resources, and an OLAP was designed to analyze water quality data from distributed resources. In the domain of environmental risk management, some recent papers investigate using (S)OLAP for hydrological pollutants analysis. The authors  Alexandru et al. (2010)  study the analysis of natural pollution risks presenting a multidimensional model where the pollution value is described per pollutant and group of pollutants, in the same way as Vernier et al. (  2013 ) define a SOLAP system for the analysis of agricultural pollutants. Pollution has been addressed also by  Radulescu and Radulescu (2008) , by defining classical pollutant value measures and some risk alert measures: the number of values that exceed the alarm level for a pollutant or a category of pollutants and the number of values that exceed the maximum admissible concentration level for a pollutant or a category of pollutants.
In  Boulil et al. (2013b) , we developed an OLAP system to store and to analyze pesticide transfer data generated by a simulation model called MACRO, to validate the model and compare its different versions. The use of DW and OLAP technologies for the analysis of environmental simulation model results has particularly been investigated in  Mahboubi et al. (2013 Mahboubi et al. ( , 2010)). In the domain of public health monitoring,  Bédard et al. (2003)  propose an application that allows for SOLAP analysis of cancers/diseases, deaths and hospitalizations of individuals following disease/death causes, sex, age, date (time), and location and using meaningful indicators (comparative figures). This work provides a comparison between SOLAP and traditional GIS technologies. Scotch and Parmanto (2006)  propose the Spatial OLAP Visualization and Analysis Tool (SOVAT), which combines OLAP and GIS technologies, allowing for spatial and numerical queries.
To achieve these objectives, an Information System (IS) has been designed that provides knowledge discovery and data analysis tools such as OLAP and different data mining algorithms with necessary data. The global architecture of the IS is shown in Fig. 2. The integrated Fresqueau database integrates datasets collected from 20 public databases having different access protocols, different use rights and different formats  (Lalande et al. , 2013). The integration issues are beyond the scope of this paper. These public databases are owned and provided by 12 public institutions such as water agencies, the National Geographic Institute (IGN), the ministries of agriculture and ecology, the European Environmental Agency (EEA), and research units, etc. For example, physicochemical and biological data are produced by French Water Agencies in North-East (Rhin-Meuse watershed) and South-East (Rhône-Méditerranée watershed) of France.
Definition of data cubes for water quality assessment In this section, we introduce two data cubes for water quality assessment: a data cube for physicochemical data and another data cube for hydrobiological data. In Section 5. 1, we present their conceptual design using our UML profile for data cubes. In Section 5. 2, we describe their implementation in a ROLAP architecture. In Section 5. 3, we present practical solutions to address measurement unit heterogeneity and to define complex indicators; our solutions are discussed and compared to existing solutions in related work. These data cubes have been defined with the help of domain experts (mainly hydrobiologists) who are the end users of the OLAP system. The hydrobiologists have mainly chosen the hierarchies, the interesting dimension levels at which they want to visualize data, and the way data had to be aggregated to compute the desired indicators.
The ETL tier The ETL tier allows for periodically populating the data marts with data from the data sources, which are in our application the integrated Fresqueau DataBase and some Excel files. The ETL tier consists of a set of data extraction and transformation JAVA programs implemented and performed using free ETL tools that are Spatial Data Integrator (SDI) 2  and Talend Open Studio (TOS). 3 Spatial Data Integrator is used particularly for the integration of spatial data.
The DW tier The data storage tier or the project DW tier, which consists of two related 4  data marts (we have defined a data mart for each data cube), is implemented using a DataBase Management System (DBMS) PostgreSQL. 5  These data marts are defined following the star schema. As stated above (Section 2. 3), this implementation schema defines one dimension table for each conceptual dimension. This schema type allows denormalized representations of dimensions. All of the aggregation levels of a dimension are stored in the same table. For example (Fig. 10 ), both levels of the "Indices" dimension ("Indices" and "Category") are mapped into the table "Indices", all levels of the "Stations" dimension into the "Stations" table, etc. Denormalization is used very often in DWs. This method produces redundancies (repetitions) of values but vastly improves the data access time.
The star schema (as other DW schema types) uses a fact table to store measure values at the most detailed levels of dimensions. The fact table defines columns to represent conceptual measures and foreign keys that reference dimension tables to link these measure values to dimension data. For example, the fact table "Indices_results" stores index scores, sample abundances, taxonomic varieties, faunal groups, etc. , by station, indices, day, support, sampler, laboratory, and supplier. In terms of the sizes of the datasets, the total size of both data marts is approximately 4055 MB. The physicochemical fact table contains 14 602 580 rows, the hydrobiological fact table (Indices_results) contains 34 415 rows.
The OLAP server and client tiers Additionally, we chose two other popular tools to explore and display data: Mondrian 6  as the OLAP server and JRubik 7  as the OLAP client. Mondrian is an open-source OLAP server that builds OLAP logical structures (e. g. , dimensions, measures) on top of any DB on the basis of a specific XML file, called the Mondrian OLAP schema. This schema provides XML definitions for data cubes, dimensions, hierarchies, analysis indicators and their mappings to the DW/data mart data structures. In this schema, the XML definition of each dimension is between the XML elements bDimensionN and b/DimensionN, and every analysis indicator definition is between bMeasureN and b/MeasureN. Finally, JRubik is a software package that provides a graphical presentation layer on top of Mondrian.
Complex indicators In addition to hierarchies, the definition of analysis indicators is one of the fundamental parts of data cubes. As stated before in Section 3, analysis indicators, which can be simple or complex, are computed by aggregating measures using aggregate functions along hierarchies. A simple indicator involves a common aggregate function, a measure and all dimensions. Common aggregate functions are functions supported by DBMSs and OLAP tools (e. g. , Sum, Avg and Count). A complex indicator can be defined as an application of different functions on different measures and along different dimensions, or as an application of a noncommon or complex aggregate function to a measure. 5. 3. 1. 1. Complex aggregate functions. Complex aggregate functions are not supported by OLAP tools and need ad hoc definitions and developments by designers.
In our project, examples of complex functions are standard deviation, percentile 10, median (percentile 50), percentile 90, and mode (the most frequent value). The standard deviation function is supported by the DBMS but not by the OLAP server Mondrian. The percentile P and mode functions are supported neither by the DBMS nor by the OLAP server. To consider these functions in this application, we first added them to our conceptual framework (the UML profile) and then mapped them into implementations in ROLAP server and data storage tiers. Adding these functions to our UML profile allows designers to reuse them in other applications. For example, to consider the functions percentile 1, …, and percentile 99, we extend our profile with the aggregate function (bbaggregatorNN) percentile (P) where 1 b = P b = 99, and propose implementations (i) in the data storage tier (PostgreSQL DW) in terms of PL/pgSQL stored procedures, and (ii) in the ROLAP server tier (Mondrian) in terms of MDX expressions.
MDX (MultiDimensional eXpressions language) is a standard language to query multidimensional and OLAP databases, just like SQL for the relational databases. These implementations are easily transferable to other platforms (e. g. , Oracle, MySQL, etc. ). In Fig. 11 , we show an example of usage of the percentile The MDX implementation of the indicator "Percentile10_ parameter_values" is: This implementation uses a PL/pgSQL stored procedure "percentile_cont" that is implemented in PostgreSQL DBMS and allows for calculating all percentiles. The behavior of this procedure is identical to the PERCENTILE_COUNT Oracle function. 8 5. 3. 1. 2. Counting the presence/absence of parameters. Counting the presence/absence of physicochemical parameters such as pesticides is important to see, for example, how the appearance/disappearance of those parameters influences the water quality.
Multiple heterogeneous measurement units The correct aggregation of measures, known as summarizability, is a key issue in data cubes. To avoid incorrect indicator values, structural (such as the strictness of aggregation relationships-for example, a water quality station must be linked to one municipality in the Stations administrative hierarchy) and semantic conditions have to be verified by OLAP data structures/engines. The compatibility of measurement units is stated as one of the fundamental semantic conditions because aggregating measure values having different measurement units generally leads to meaningless results (e. g. , summing micrograms per liter with grams per liter of physicochemical parameter values). In the Fresqueau project, physicochemical results are provided by data suppliers with multiple heterogeneous measurement units (microgram per liter, centimeter per minute, cubic centimeter, gram, gram per meter squared, etc.
). This heterogeneity is essentially because each laboratory has its own objectives and management rules as well as different objectives and conventions for the source databases. To address this problem of measurement unit heterogeneity and allow correct and meaningful aggregate values, we use two solutions. (1) Define the "Measurement units" as a dimension of the physicochemical cube. This definition is very important to control the measure aggregation (prevent summing results with incompatible measurement units, for example, grams with liters) and also for information rendering aspects (displaying measurement units is necessary for end users to understand and to interpret results). This solution can be applied independently of the convertibility between measures. In the OLAP client, this control can be automated or not.
OLAP analysis OLAP analysis is generally performed in an exploratory way following a top-down approach  (Sapia, 1999). In an OLAP analysis session which is a sequence of queries, the user starts by formulating a first coarser query by selecting (on the OLAP client interface) the indicators and dimensions level (that he/she wants to display in the result) at their most coarse granularity levels. Based on this result, the user can perform further finer analysis by clicking on interface components (buttons, maps, etc. ) that trigger OLAP operations, or by formulating other combinations of dimensional elements. In this section, we present examples of different types of OLAP analysis, thematic, temporal, spatial, spatiotemporal and multiscale analysis, using the hydrobiological data cube, to show the feasibility and the productivity which can be gained by end users by using OLAP solutions in the field of water quality assessment.
IBGN, IBMR, and IPS values are positive real numbers in the range of  [0, 20] ; IOBS values are in the range of [0, 10]; and IPR values are in the range of [0, ∞]. For the IBGN, IBMR and IPS, the best score is 20; the IOBS best score is 10 and the IPR best score is 0. Fig. 12 (a) shows a pivot table representation of the results, and Fig. 12 (b) shows a histogram diagram representation. With these representations, we can rapidly see, for example, that the IOBS is particularly low, and an expert can conclude that for this dataset, pollutionsensitive oligochaetes have disappeared and sediments most likely are in a bad state. The statistical diagram representation is synchronized with the pivot table representation: every change in the pivot table representation is instantaneously reproduced in the diagrammatic representation.
Conclusions and future work In this paper, we have shown an application of the OLAP technology to the field of water quality assessment. Based on our framework for data cubes  (Boulil et al. , 2013a) , we developed a free tool-based and extensible ROLAP system composed of two data cubes: (1) a data cube for the OLAP analysis of physicochemical water quality data, and (2) a data cube for the OLAP analysis of hydrobiological data. We proposed standards-based (UML, SQL and MDX) and generic solutions to model and implement complex indicators using complex aggregates such as percentiles by extending our framework with these functions. Other complex analyses are defined by introducing useful dimensions and using common aggregate functions. Additionally, we proposed two practical solutions to address the summarizability problem of heterogeneous measurement units.
Finally, to validate our system and to show the productivity that can be gained by water quality practitioners when using OLAP, we provided the reader with a number of examples of OLAP analysis. This work has been achieved in the context of the Fresqueau project which aims to develop new methods for collecting, analyzing and interpreting all available data related to water quality parameters. The built data cubes proved to be relevant and usable tools to help domain experts (mainly hydroecologists) exploring, selecting and analyzing the huge and complex datasets collected in the Fresqueau database. These users are very satisfied with the rapidity, interactivity and facility of the analyses that can be performed using the developed OLAP system, the variety of results according to the   various aggregation levels, and the new viewpoints on data they can thus obtain.
The next steps in this work are to extend/enrich our ROLAP system by: (1) other data cubes (such as a data cube for hydromorphological data of water bodies, a data cube for environmental forcing variables such as flows, etc. ), (2) linking the data cubes to each other to allow drill-across OLAP operations, to answer the questions related to interdependencies between the water quality parameters such as the influence of physicochemical state of water bodies in the appearance/ disappearance of faunal and floristic specifies, the influence of hydromorphological characteristics of water bodies in their physicochemical states, etc. Another perspective is to study the possibilities offered by spatial OLAP tools  (Bédard et al. , 2007; Miquel et al. , 2010). These tools may help end users to understand water quality data better by allowing map visualizations and explorations of data.
Finally, we also plan to develop an architecture that integrates or connects the OLAP tool to a data mining module consisting of different data mining algorithms  (Wang and Guo, 2013). The OLAP module will be used for a first and rapid exploration of the data. Based on the OLAP exploration results, the end user can execute an adequate algorithm of the data mining module on the adequate dataset to discover additional knowledge such as existence or absence of correlations between water quality parameters, etc.
Finally for a we took 1 17 7 11  23 13. We used our software geomsolvex described in Section 5. 1 and computed at least one point per connected component of Γ. Timings are reported in Table  1. We used the SVN revision number 8738 of Mathemagix and compared with version 3. 21 of the RAGLib library developed in Maple (TM) by M. Safey El Din  [28] , which in its turn relies on the FGb version 1. 58 of J. -C. Faugère  [15]. Our platform uses one core of an Intel(R) Xeon(R) CPU X5650 at 2. 67 GHz and disposes of 48 GB. We observed that RAGLib is much faster in small input sizes. Nevertheless its cost increases faster than the one of our probabilistic algorithm.
partially supported by the following Argentinian, French and Spanish grants:  CONICET Res 4541-12 ,  PIP 11220090100421 CONICET, UBACYT 20020100100945  and  20020110100063 ,  PICT-2010-0525 ,  Digiteo DIM 2009-36HD  " MaGiX " grant of the  Région Ile-de-France ,  ANR-2010-BLAN-0109-04  " LEDA ",  MTM2010-16051.
A. MPSoC Model Our work is based on the generic hardware model showed in Figure  2. MPSoC components include processors, memory blocs, peripherals and a communication network. Processors are computational units including general purpose processors, cores or accelerators. They are organized in a two-level hierarchy. Homogeneous processors form groups we call nodes. Thus there may be a node with audio processing units and another specialized in video decoding. In a node, processors have access to and communicate through a shared memory bloc. Among nodes, memory is distributed and a processor from one node cannot access the memory of another node without passing through inter-node network connections. Peripherals are the devices ensuring data exchange between the MPSoC and the external environment.
Peripherals may include sensors, keyboards, screens, microphones, etc. The data they capture is communicated to the processors via the memory or the network. The network connections organize components in a hierarchical way. As for MPSoC software, our assumptions are the following. The software execution is composed of a set of execution flows which is statically partitioned and scheduled on the MPSoC nodes. The execution flows scheduled on the same node communicate using the shared memory bloc and via synchronization. The execution flows scheduled on different nodes communicate using message-passing through the network. Data from peripherals is acquired either by polling, or using interruptions.
The second situation concerns non blocking reception operations. In this case, the reception operation relies on a verification of the data availability (probe) which is itself non deterministic. To trace and deterministically replay network communications, we have used the solution proposed in  [3] ,  [4]. For blocking network communications, the detection of race reception primitives is based on vector clocks. For non blocking reception operations, there is a need to record the number of executed probes, as well as their outcome (message available or not). This solution has minimal intrusion as it traces only race reception operations. Output operations have no effect on replay techniques. Input operations, however, are important, as they influence the execution path of MPSoC software. Input operations are based either on interrupts, or on busy waiting (polling).
Interrupts, however, are a challenge to embedded record-replay  [5]. We have decided to limit the intrusion of our mechanism by not recording interrupts and only consider polling requests. We suppose that the content of the input data is recorded by specific devices. We only record the input size in the reference execution trace (Step 1). During replay, the trace is read to decide that there is an input operation which is in turn acquired by executing a polling request to the specific recording device.