dataesr/scientific-paragraphs-categorization huggingface dataset:
All source terms were inferred from the combination of facility events, radiological observations, meteorological and dispersion modelling. The total release considered over the three days varied by a factor of 7 (3. 1-21. 4 PBq) for 137 Cs and a factor of 9 (46-400 PBq) for 131 I between the different source terms. In this study, two observation datasets are used. The first dataset consists of the hourly concentrations of 137 Cs retrieved by Tsuruta et al. (2014). The data were obtained from the automated air quality monitoring network and give information on the temporal variation of 137 Cs concentration close to ground level (108 stations). The second observation dataset is gamma dose rate measurements, provided by automated.
Acknowledgement. CONFIDENCE is part of the  CONCERT  project. This project has received funding from the  Euratom  research and training programme  2014-2018  under grant agreement No. 662287. The authors would also like to thank  O. Saunier  and  A. Quérel  for their contribution on the Fukushima case study. Disclaimer (Art. 29. 5 GA). This publication reflects only the author's view. Responsibility for the information and views expressed therein lies entirely with the authors. The European Commission is not responsible for any use that may be made of the information it contains.
Concept of estimation In the frequentist approach, the parameter of interest q is unknown, but is considered constant. The parameter q is estimated, considering that everything we know about q comes from the data. Therefore, this estimation relies solely on the likelihood and probability of the data under H0. H0 has no probability in itself. In the IMMERSION study, the Bayesian approach reports a primary outcome measure comparing the mean diuresis between the two study groups. Previous knowledge of an expected mean difference in diuresis of 100 ml between the groups, under the assumption of an SD of 100 ml diuresis in each group, was only used in the sample size determination. The principle of Bayesian estimation is to consider the parameter q as unknown. What is unknown is uncertain and is thus given a probability distribution (see Bayesian definition of probability).
). The prior distribution specifies what is known about the difference of interest. Clinically relevant differences to be tested are specified before the study. (ii) From the observed data and the prior distribution, the posterior distribution is calculated by simulation (using software such as BUGS, JAGS, etc. ). The main objective of the IMMERSION study is the same as in a classical framework. (iii) Evaluation of the goodness of fit of the model and the implications on the resulting posterior distribution. Using the suitable model, software, and technique, for the main outcome, the mean difference (in favour of the bath group) and its 95% CrI are computed, thanks to the posterior distribution, and the probability that the difference is positive and that the difference is >0. 835 ml kg À1 h À1 , which corresponds to a diuresis difference of 50 ml h À1 , standardised on the mean study participant weight (59.
(iii) It constitutes the only ER system that runs seamlessly both on stand-alone computers and clusters of computers -through the parallel implementation of all algorithms in Apache Spark. (iv) It supports two different end-to-end workflows for carrying out batch ER (i. e. , budget-agnostic), a schema-agnostic one based on blocks, and a schema-based one relying on similarity joins. (v) It adapts both end-to-end workflows to budget-aware (i. e. , progressive) ER. We present in detail all features of JedAI, stressing the core characteristics that enhance its usability, and boost its versatility and effectiveness. We also compare it to the state-of-the-art in the field, qualitatively and quantitatively, demonstrating its state-of-the-art performance over a variety of large-scale datasets from different domains.
This is demonstrated by the experiments in Section 9, which involve a wide range of large datasets from various domains (e-commerce, bibliographic data, census data etc). An additional advantage of JedAI is its high usability. JedAI conveys non-learning methods that require minimal human intervention, as neither domain knowledge nor training sets are needed. Users are only required to select the methods that will form an end-to-end workflow. Optionally, the internal parameters of each method can be fine-tuned for optimal performance. In case of no relevant experience, the default configurations can be used, as they have been experimentally verified to consistently achieve high performance across various, diverse datasets  [9, 10]. In this way, JedAI allows non-experts to create complex pipelines of high performance with minimal human intervention, almost in a hands-off manner.
Thus, we facilitate not only the use of JedAI, but also its extension with more methods and modules. • We perform an extensive experimental evaluation that involves 10 real-world and 7 synthetic datasets, whose sizes range from few thousand to few million entities. We evaluate the relative performance of all types of end-to-end pipelines created by JedAI (batch, progressive, schemabased, schema-agnostic, serialized and parallel ones), providing useful insights into their pros and cons. • We compare JedAI with the state-of-the-art, qualitatively and quantitatively, highlighting the limitations of existing tools and explaining how we go beyond them. The rest of the paper is structured as follows: Section 2 provides background knowledge, while Section 3 presents JedAI's modular architecture. The back-end is analytically described in Section 4, the front-end in Section 5 and the data model in Section 6.
JedAI should facilitate its enrichment with new techniques or even workflow steps by power users. • (G6) High time efficiency. JedAI should process large datasets quickly, not only in commodity, stand-alone systems, but also in powerful computer clusters. Goal G1 is accomplished through JedAI's flat entity model, which consists of a string-valued entity id (e. g. , URI) and a set of textual name-value pairs. This simple model is capable of accommodating the main structured and semi-structured data formats, while supporting noisy attribute names or values, tagstyle values (which are not associated with any attribute name) and entity links, where the URI of an entity is given as an attribute value to the associated entity. See Section 6 for details. To meet G2, JedAI comprises numerous methods that support four different end-to-end ER workflows (cf.
Section 4). For G3, JedAI's code is released under Apache License V2. 0, which supports both academic and commercial applications. The former are further facilitated through JedAI's benchmarking functionality; its intuitive GUI allows every user to easily evaluate the relative performance of a large variety of end-toend pipelines, in case a ground-truth is available (as is common in academic applications). To additionally support commercial applications, any workflow built by JedAI can operate independently of a ground-truth, producing its own detected matches. To address G4, JedAI equips novice users with a wizard-like GUI, with documentation and with default parameters for every implemented method. In case a ground-truth is available, they can also use two ways of automatic parameter fine-tuning (see Section 4.
Budget-& schema-agnostic workflow Figure  3  depicts this end-to-end pipeline along with the available methods per workflow step. All methods are inherently crafted for highly noisy and heterogeneous data, despite their learning-free functionality. They rely on a schema-agnostic functionality that leverages all attribute values in each entity rather than employing a particular set of attributes. Thus, they are resilient to errors in attribute values. Excluding the input and output steps, which are described in Section 6, the processing steps are the following: 1) Schema Clustering (SC). This is an optional step, suitable for highly heterogeneous datasets with a schema comprising a large diversity of attribute names. In these settings, it significantly improves the overall precision at a limited cost on recall by grouping together attributes that are syntactically similar, but are not necessarily semantically equivalent  [12, 13].
Note that any combination of the above methods is possible. Usually, this is necessary for highly noisy datasets, e. g. , those including both character-and token-level errors. 3) Block Cleaning (BC). This is an optional step that cleans the original blocks from those dominated by the redundant and the superfluous comparisons. Removing these comparisons improves precision at a minor cost in recall  [10]. The core assumption in BC is that the larger a block is, the less likely it is to contain unique duplicates, i. e. , matches co-occurring in no other block (e. g. , a block corresponding to a stop word). In this context, Size-based Block Purging  [21]  discards all blocks exceeding a certain number of entities, Cardinality-based Block Purging  [15]  discards all blocks exceeding a certain number of comparisons, Block Filtering  [22]  retains every entity in a subset (r%) of its smallest blocks, and  Block Clustering  [23]  ensures that all blocks remain within a user-specified range of sizes.
4) Comparison Cleaning (CC). This optional step also targets redundant and superfluous comparisons, but operates at the level of individual comparisons, achieving higher accuracy than BC at the cost of a higher time complexity. It includes primarily Meta-blocking techniques  [10] , of which only one can be added in an end-to-end pipeline. The simplest approach is Comparison Propagation  [24] , which eliminates all redundant comparisons from a set of overlapping blocks. Instead of hashing all executed comparisons in memory, an approach that does not scale to large datasets, it performs a pairwise comparison c i, j in block b k only if k is the least common block index of e i and e j. All other methods of this step extend Comparison Propagation so that it discards superfluous comparisons, as well.
Budget-agnostic, schema-based workflow This type of workflows leverages domain knowledge to achieve both high effectiveness and high efficiency. This is usually the case in datasets where a single attribute contains values that are distinctive enough to identify matching entities. As an example, consider the title attribute in bibliographical data. In such cases, the user needs to define a matching rule that consists of two parameters: the distinctive attribute, and a similarity threshold, above which two values are considered to indicate duplicate entities. The steps of this end-to-end budget-agnostic, schema-based workflow appear in Figure  4 (a). After data reading, JedAI allows users to detect the most reliable attribute in terms of noise and distinctiveness through the data exploration functionality (see  Section 5).
Budget-aware, schema-based workflow This pipeline implements the same workflow as its budgetagnostic counterpart, which is depicted in Figure  4 (a). The only difference is that it implements a single method, namely the Top-k Similarity Join  [47]. This algorithm is crafted for tokenbased joins and applies seamlessly to both Dirty and Clean-Clean ER. During the initialization phase, it constructs an index similar to that of Prefix Filtering. During the emission phase, it iteratively emits pairs of candidate matches in nonincreasing order of estimated similarity (usually Jaccard). This is carried out in two ways: globally, by considering all comparisons across the entire dataset, or locally, by considering the top-k comparisons per entity.
To address this issue, this component offers four solutions that apply to every method: 1) Default configuration. Every parameter is a-priori set to a value that has been verified to achieve high performance through an extensive experimental analysis over a series of established benchmark datasets  [9, 10]. This parameterization is the default choice in JedAI and requires no input by the user, thus being ideal for lay users. 2) Manual configuration. Expert users are able to leverage their deep ER knowledge by determining the value of any parameter with the help of the Documentation component. 3) Grid search. In case a ground-truth is available for the data at hand, this approach automatically detects the best parameterization in a brute-force way. For categorical parameters (e. g. , the weighting scheme in Meta-blocking), it considers all possible values, while for numeric parameters, it considers all values specified by the Documentation component.
Instead, holistic configuration is crafted for identifying the global maximum. Combining it with grid search, though, might lead to an exponential computational cost. Text Processing. As explained above, JedAI is crafted for integrating datasets that are dominated by textual values. This component provides the techniques that are necessary for identifying similarities between sets of textual values that represent individual attributes (in Schema Clustering) or individual entities (in Entity Matching). In more detail, this component comprises a series of established, state-of-the-art representation models, which transform a set of textual values in a format that is suitable for applying various similarity measures. The cornerstone approach is the vector model  [49] , which converts every value into a set of character or token n-grams.
The code of the Web application is available here: https://github. com/GiorgosMandi/JedAI-WebApp. 2) Command-line Interface. This interface implements the basic functionalities of JedAI. First, it asks users to select one of the four end-to-end workflows and then to select one or more methods per workflow step. This can be repeated multiple times in the context of benchmarking different workflows, with a screen summarizing the experimental results so far. It also provides access to the Documentation component, allowing users to retrieve information about individual methods or specific parameters. 3) Jyputer Notebook. To integrate JedAI with Python's data analysis ecosystem, we augmented JedAI-core with a Python wrapper based on pyjnius  [57]. Thus, JedAI can be seamlessly used in a Jupyter Notebook, following the guidelines that are available in its code repository  [7].
Data Flow We now describe the data structures that are used in JedAI's workflow steps with the aim of achieving high time efficiency and low memory footprint in then serialized execution. JedAI leverages the data structures of GNU Trove, which operate on primitive types, instead of the default ones in java. util. Collections, which rely on the wrapper classes; e. g. , GNU Trove uses a 4-byte int, rather than a 16-byte java. lang. Integer. In this way, the memory footprint is minimized across all operations of JedAI. Input Data. The first step in all pipelines is Data Reading, which loads from disk into main memory the dataset(s) to be processed along with the ground-truth, if available. The corresponding entities are converted into a flat model that represents them as sets of property-literal and relation-URI pairs.
In this way, JedAI supports the main structured data formats (relational databases and CSV) along with the main semi-structured data formats, i. e. , SPARQL endpoints and RDF, XML, OWL, HDT and JSON files. Any mixture of those formats is possible in the case of Clean-Clean ER. No additional contextual or domain knowledge (e. g. , ontology) is required as part of the input. Data Reading also assigns to every entity a unique integer id so that all subsequent steps avoid using its original, textual URI. Output Data. JedAI allows for storing final or intermediate results (for debugging purposes) in any of the supported data formats through the Data Writing workflow step. Block Building. This step converts the input entities into an inverted index (hash table), which points from String blocking keys to int entity ids.
Parallel Execution We now describe the methods and the data structures we used for adapting all algorithms implemented by JedAI to the parallel execution on top of Apache Spark. The implementation in Scala is available here: https://github. com/scify/ JedAI-Spark. Budget-and schema-agnostic workflow. Block Building receives as input an RDD of entity profiles and essentially builds an inverted index that points from String blocking keys to int entity ids. The adaptation to the MapReduce paradigm is straightforward for most methods, like Token Blocking: the Map phase extracts the blocking keys from each entity, while the Reduce phase aggregates all entity ids that correspond to the same blocking key. Each key with more than two associated entities creates a separate block. For Sorted Neighborhood, we use the MapReduce algorithm proposed in  [58].
Experimental Analysis The goal of our experimental study is manifold: (i) to evaluate the relative performance of the two types of budget-agnostic (i. e. , batch) end-to-end workflows, (ii) to assess the benefits of the budget-aware (i. e. , progressive) end-to-end workflows over the corresponding budget-agnostic ones, (iii) to demonstrate the scalability of JedAI's parallelization of all methods and workflows over Apache Spark, and (iv) to quantitatively compare JedAI with state-of-the-art systems. Experimental Setup. All methods and experiments are implemented in Java 8. The code for the experiments is publicly available in JedAI's code repository  [7]. The experiments were ran on a server with Intel Xeon E5-4603 v2 (2. 2GHz, 16 physical cores), 128 GB RAM, running Ubuntu 14. 04. 5 LTS. For all time measurements, we repeated the experiments 10 times and report the mean values.
We also report memory requirements per experiment and dataset. Datasets. The technical characteristics of the 17 datasets we use in our experiments are reported in Tables  1  and 2  for Dirty ER and Clean-Clean ER, respectively. All of them have been widely used in the literature  [14, 1, 64, 9, 10]  and are publicly available through JedAI's code repository  [7]. The Dirty ER datasets in Table  1  include two real-world collections: D cddb , which contains entity profiles describing CDs randomly extracted from freeDB. org, and D cora , which contains entity profiles with bibliographical information for scientific papers. The rest of the datasets are synthetic, involving census data artificially generated by Febrl  [65]  through the following procedure: duplicate-free entity profiles were initially formed based on frequency tables for real names (given and surname) and addresses.
Then, duplicates were randomly generated based on real error characteristics and modifications (e. g. , inserting, deleting or substituting characters or words). Each entity was subject to at most 10 modifications, of which up to 3 modifications for the same attribute value. 40% of the resulting entities are duplicates, with less than 10 matches per entity. The Clean-Clean ER datasets in Table  2  exclusively contain real-world collections. D c1 includes entity profiles that describe restaurants from the Fodor's and Zagat restaurant guides. D c2 contains product entities from the online retailers Abt. com and Buy. com. D c3 matches products from Amazon with those from Google Base. D c4 involves publication entities from DBLP and ACM Digital Library. D c5 matches products from Walmart and Amazon.
D c6 aligns curated publication entities from  DBLP with noisy publication entities from Google Scholar. D c7 conveys a collection of movie entities shared by DBPedia and IMDB. D c8 matches two versions of the DBPedia Infobox Data Set, which chronologically differ by two years. D c8 is actually the only dataset with high schema heterogeneity, as in all other cases, any discrepancies in the schema can be manually fixed. D cora D cddb D 10K D 50K D 100K D 200K D 300K D 1M D 2M |E| 1, Budget-and schema-agnostic workflow. This workflow consists of the following methods: Block Building, Block Purging, Block Filtering, CNP, Profile Matcher and Connected Components or Unique Mapping Clustering in case of Dirty and Clean-Clean ER, respectively. The first four methods are exclusively considered with their default configurations, because the pipeline they form consistently exhibits an excellent performance across the diverse datasets we have considered, as shown in Table  4 (a): blocking recall (PC) exceeds 90% in most cases, while blocking precision (PQ) is very high, since the number of pairwise comparisons is bounded by the number of input entities.
On average, CNP retains at most 11 comparisons per entity. As a result, this workflow has three degrees of freedom, i. e. , parameters that need to be fine-tuned: the representation model and the similarity measure used by Profile Matcher for executing the pairwise comparisons as well as the similarity threshold simT h of the Entity Clustering method. Using grid search, we estimated the configuration that maximizes the F-Measure for each dataset to yield the corresponding best configuration. The resulting parameters per dataset appear in Table  3 (a). We also determined the default configuration of this workflow as the parameter settings that achieve the maximum average F-Measure across all datasets. recall that both schema-agnostic workflows used the default configuration for the methods in the first three workflow steps, i.
e. , Token Blocking, Block Purging, Block Filtering and CNP. For Entity Matching, we employ character 4-grams with TF-IDF weights with cosine similarity and simT h=0. 15 in the case of Clean-Clean ER, while for Dirty ER, we use character 2-gram graphs with graph value similarity and simT h=0. 65. Looking into Table  4 (b), we observe that the default configuration achieves a very high effectiveness, with an F-Measure well above 0. 8 in 7 out of 10 datasets. Two of the datasets with low effectiveness, namely D c3 and D c5 , contain so high levels of noise that F-Measure remains below 0. 8 for all other approaches we consider. We also observe that most datasets are processed in few seconds with much less than 1 Gb of main memory -even D c6 which contains than 60,000 entities. Overall, this workflow combines high effectiveness with high efficiency, despite requiring no parameter fine-tuning.
05, 0. 95] with a step of 0. 05 to all attributes. The only exception is D c8 , where we exclusively considered the attribute "name", which has the highest coverage for both individual datasets  (43,34%). Note also that edit distance is not suitable for most datasets, as they involve a large number of tokens per attribute. For each dataset, we consider the matching rule that maximizes F-Measure and use PPJoin to accelerate it. Unique Mapping Clustering or Connected Components is then applied for Clean-Clean or Dirty ER, respectively, using the same similarity threshold as the matching rule. The resulting performance is reported in Table    [66]  Table  4 : Performance of JedAI's budget-agnostic workflows and the main baseline methods over the real data. D c1 D c2 D c3 D c4 D c5 D c6 D c7 D c8 D cora D cddb Representation C2G C2G.
4(d), while the exact matching rules are reported in Table 3(b). We observe that this workflow underperforms the best schema-agnostic (blocking-based) one in all cases. Its F-Measure is also significantly lower than the default blockingbased workflow for 8 datasets. However, it reduces the memory footprint up to 50% and the running time even by a whole order of magnitude. For example, it process the 3. 35 million entities of D c8 within just 15 minutes. The reason is that it reduces the search space for duplicates to the values of a single attribute, unlike the blocking-based workflow that considers all attribute values per dataset. Overall, we can conclude that the schema/join-based workflow achieves excellent performance in some cases, with its F-Measure exceeding 0. 8 for minimum running time and memory footprint.