dataesr/scientific-paragraphs-categorization huggingface dataset:
Trihalomethane Indices When available, we used raw data to calculate the country average, SD, and median THM levels, and we weighted the estimations by the population served in each reporting area using the function weight = area population in STATA (version 12; Stata Corp. ). For Cyprus, Germany, Greece, Italy, Luxemburg, and Romania, we built separate databases in Microsoft Excel 2010 using the available THM reports to estimate the populationweighted average THM for the reported areas, which we then assigned to the whole country. We obtained the distributions of country-specific population size and age in 2016 from the Global Burden of Disease 2016 study  (IHME 2016b). The area-specific population size was either included in the provided database or report or we obtained it from the latest published country census.
We excluded the outliers and assigned half the value of the reporting laboratory's detection limit when measurements were undetected. For countries that provided information on individual THMs only (chloroform, bromodichloromethane, dibromochloromethane, and bromoform,) we calculated the total THMs by adding the individual THMs. We used the mean values of THMs instead of the median values, despite the skewedness of some Environmental Health Perspectives 017001-4 128(1) January 2020 data, because many countries provided mean values and published literature commonly reports means. For the minimum and maximum values, we used the nonweighted THM levels to show the actual range. When only the mean THM of a country was provided to us, we used it as is. For the estimation of the EU population-weighted mean of THMs, we used the information from 26 EU countries that provided data, thus excluding Bulgaria and Romania, since the data were nonrepresentative (in Romania, the population coverage was 7.
However, the quality of THM data for Romania was low (few published studies with very low population coverage) and may not accurately reflect the current country average. Romania accounted for 16% of all attributable bladder cancer cases; therefore, if THM levels were overestimated for Romania, attributable bladder cancer cases would have been overestimated for the country and for the European Union as a whole. We estimated a PAF of 4. 6% for France (737 attributable cases/year), which is lower than estimates reported by  Corso et al. (2017)  (PAF = 16%; 1,485 attributable cases/year) based on a nationwide study that used 2011 estimates of bladder cancer incidence in men from the French network of cancer registries  [FRANCIM (INCa and InVS 2011)  vs. the 2016 Global Burden of Disease study used in our analysis], THM levels at the outlet of all French water treatment plants from the national database SISE-Eaux (http://www.
For future estimates, sources of error include changes in population structure and incidence rates, since the European population is growing and getting older (Eurostat), and the bladder cancer incidence is expected to increase in some European countries and decrease in others over the next decade  (Antoni et al. 2017; Wong et al. 2018 ). We used incidence data for bladder cancer from the Global Burden of Disease 2016 study, which uses multiple sources depending on the country (e. g. , WHO mortality data, national registries, vital statistics, modeling from neighboring regions, etc. ). Accuracy may differ, since not all keep nationwide cancer registries or there Environmental Health Perspectives 017001-10 128(1) January 2020 may be discrepancies with national databases. In the French study, for example  (Corso et al.
Similarly in Greece, for large cities including Thessaloniki and Larisa, THM data were not available. However, we do not have this type of information for all the countries, and we cannot generalize and anticipate the impact on the EU population-weighted THM estimate. The reporting situation differs widely among countries. According to the European Council (EC) Drinking Water Directive, countries are obliged to report the drinking water quality to the public and the EC in a 3-year report. However, only the number of THM analyses and percentage of noncompliant measurements are presented and not the actual monitoring or even descriptive data  (EC 1998). Only some countries maintain a centralized electronic database of THM measurements and only Ireland (U. S. EPA 2015) and Denmark (GEUS) have this database publicly available.
It is therefore important for these countries to set up centralized electronic databases to monitor drinking water quality and for these databases to be publicly available, both to the EC and also to the public and scientific community. This is also in line with the proposal for the new EC directive (EC 2018) on the quality of water intended for human consumption that requires the establishment of centralized databases and better publicity of the results of water quality analyses. However, in the new directive, there is no provision to lower the maximum permissible limit for THMs of 100 lg=L or to include information on the actual monitoring results in these databases, although it proposes to regulate additional DBPs such as HAAs, chlorite, and chlorate. Another source of heterogeneity in THM levels is the diversity of monitoring sampling sites (e.
Acknowledgments This work was funded by the  EU   Seventh Framework Programme EXPOsOMICS Project  (grant agreement no. 308610 ),  Human Genetics Foundation  agreement  17-080 ISG , and  CIBER Epidemiología y Salud Pública (CIBERESP). ISGlobal is a member of the  Centres de Recerca de Catalunya (CERCA) Programme ,  Generalitat de Catalunya. We would like to thank the members of the  European Programme for Intervention Epidemiology Training (EPIET) Alumni Network (EAN)  for their assistance in identifying appropriate national focal points in specific countries. We would also like to thank the people from the national and local authorities and universities for the provision of THM data:  Sofie Dewaele  ( Leefmilieu Brussel-BIM/Bruxelles Environnement-IBGE Afd. Inspectie en verontreinigde bodems, Dpt.
The Core Scientific Dataset (CSD) model with JavaScript Object Notation (JSON) serialization is presented as a lightweight, portable, and versatile standard for intra-and interdisciplinary scientific data exchange. This model supports datasets with a p-component dependent variable, {U 0 ,. , U q ,. , U p-1 }, discretely sampled at M unique points in a ddimensional independent variable (X 0 ,. , X k ,. , X d-1 ) space. Moreover, this sampling is over an orthogonal grid, regular or rectilinear, where the principal coordinate axes of the grid are the independent variables. It can also hold correlated datasets assuming the different physical quantities (dependent variables) are sampled on the same orthogonal grid of independent variables. The model encapsulates the dependent variables' sampled data values and the minimum metadata needed to accurately represent this data in an appropriate coordinate system of independent variables.
Introduction A frustrating and common problem faced by scientists in many disciplines is the lack of a portable scientific dataset format and universal standards for exchanging and archiving multidimensional datasets-both experimental and computational. Scientific datasets are too often saved in vendor-specific file-formats using proprietary software, making archiving and dataexchange problematic even within a discipline, let alone across disciplines. A majority of scientists rely on vendor-specific proprietary software to interact with their datasets. These scientists are at a constant risk that the original dataset files could become unreadable if a future version of the software stops supporting older file formats or the vendor stops supporting the software, or even worse, goes out of business.
LinearDimension object. The ordered set of N k uniformly spaced coordinates along the k th LinearDimension object are given by X k ¼ Dx k ðJ k À Z k Þ þ b k 1; ð3Þ where Δx k and b k are the ScalarQuantity objects in the increment and coordina-tes_offset attributes, respectively, and J k is an ordered set of coordinate indexes along the k th dimension, J k ¼ ½0; 1; 2. ; j k ;. ; N k À 1�: ð4Þ Here, N k is the Integer object in the count attribute. As before, the absolute coordinates along the k th dimension are given by Eq  (2). Again, the ScalarQuantity objects Δx k , b k , and o k must all share the same unit dimensionality. The Z k variable in Eq (3) is an integer with a value of Z k = 0 when the LinearDimension attribute complex_fft is false. The complex_fft is set to true when a complex fast Fourier transform (FFT) has been applied to the dataset along the k th dimension, and then the value of Z k becomes T k /2, where T k = N k and N k -1 for even and odd values of N k , respectively.
There are two reasons for the inclusion of the attribute complex_fft and the different values of Z k. First, it provides the metadata needed for determining whether a forward (false) or reverse (true) complex FFT should be performed on the dataset. Second, a value of Z k = T k /2 in Eq (3) when complex_fft is true associates b k with the zero "frequency" after a complex FFT. This definition makes b k independent of count and the increment in the Reciprocal dimension, i. e. , the dimension before the complex FFT.
Generic application objects-Beyond the CSD model As stated earlier, the objective of the CSD model is to encapsulate the data values and the minimum metadata needed to accurately represent the data in an appropriate coordinate system, that is, the minimum metadata for defining the current state of the dataset. Thus, the goal of the CSD model is to always remain relevant as the state of the dataset changes. In our refinement of the CSD model, we identified any metadata attribute as extraneous if it could become irrelevant as the state of the dataset changes. Metadata attributes extraneous to the CSD model could generally be classified as belonging in one of four broad and somewhat overlapping categories: acquisition, process, analysis, and presentation. The design of models organizing these extraneous metadata attributes tends to be scientific domain specific, although some commonalities exist.
g. , "com. A. acquire")? On the one hand, company B could retain the company A specific metadata (as found) in the generic application object using the "com. A. acquire" key as well as serialize its own metadata using the "com. B. process" key. If the company B application made any modification to the dataset, however, it runs the risk that parts of the company A application-specific metadata are now irrelevant or logically inconsistent with the newly saved dataset-potentially causing company A's application to crash when it tries to open this newly saved dataset. On the other hand, company B could decide to discard the company A specific metadata, in which case the company A application can safely open the dataset saved by company B, but will have lost all of its previously saved metadata.
Finding a consistent solution to this dilemma is critically important as one can easily envision a workflow where a dataset passes through many applications as it progresses from the raw dataset to the final "product. " During such a workflow there is often an expectation of an audit trail, which most likely could be determined from application metadata saved by each application used during the workflow. One approach that could solve this dilemma is to allow the CSDM file to contain a timeordered array of CSDM objects. In other words, company B would simply append a second CSDM object with only company B metadata to the array that already contains the CSDM object created by company A. No application metadata would be lost, and the metadata in each CSDM object would be relevant and logically consistent with its respective datasets.
In this approach, the CSDM "array" file would grow as each application completes its task in the overall workflow. It is our opinion, however, that it is better to delegate such a task of managing a timeordered array of CSDM objects to the operating system. In this approach, we envision the workflow associated with a particular dataset to result in a folder containing a series of CSDM files, each a snapshot from the workflow as it progresses from the raw dataset to the final "product. " When each application is finished with its workflow task a CSDM file is saved with the read_only flag set to true, so that any future work on the dataset would be performed on a copy of the CSDM dataset, leaving the "read-only" file with application metadata intact. Typically, the read_only flag would be set to true immediately after the acquisition of raw data, after processing is complete, or after analysis of a dataset.
The serialization file names are designated with two possible extensions:. csdf and. csdfe, the acronyms for Core Scientific Dataset Format and Core Scientific Dataset Format External. When all data values are stored within the file, i. e. , there are no instances of an ExternalDependentVariable object in the serialization, then the. csdf file extension is allowed, otherwise, the serialization file name must use the extension. csdfe. This difference in extensions is intended to alert the end-user to a possible risk of failure if the external data file is inaccessible when deserializing a file with the. csdfe file extensions. 3 dD{p 0 , p 1 ,.
} example datasets In this section we examine the CSD model in a number of illustrative examples. We use a shorthand notation of dD{p} to indicate that a dataset has a p-component dependent variable defined on a d-dimensional coordinate grid. In the case of correlated datasets the number of components in each dependent variable is given as a list within the curly braces, i. e. , dD{p 0 , p 1 , p 2 ,. }. Efforts have been made to include examples across disciplines, although given our expertise in magnetic resonance spectroscopy, we include multiple examples from this field. It is worth noting, however, that magnetic resonance datasets prove to be excellent test cases for the CSD model as they are diverse and often multi-dimensional in nature. We have converted a variety of datasets from various fields to the CSD model format.
1D{1} examples In this section, we examine the JSON serialization for illustrative cases of 1D{1} datasets. These are the simplest cases, with one dimension, d = 1, and one single-component dependent variable, p = 1. The supplementary material gives further 1D{1} examples from FITR, UV-vis, and EPR spectroscopies. GMSL. csdf. An example of a JSON serialized CSD model holding a 1D{1} dataset is shown in Listing 1. This dataset is a measurement of the global mean sea level  [8]  (GMSL) based on the satellite altimeter data from 1993-2009. Listing 1. CSD model depiction of the global mean sea level dataset. A JSON serialized CSD model describing the global mean sea level dataset. The listing was created by the authors using data from reference  [8]. At the root level is the csdm key, an acronym for the core scientific dataset model.
A plot of the dataset is shown in Fig 2. Note that meta-data on how a dataset is presented in a plot or otherwise is not included in the CSD model. While such presentation metadata is outside the scope of the core model, it can be included in an application dictionary. blochDecay. csdf. Another simple example of a 1D{1} dataset, acquired by the authors for this work, is shown in Listing 2. This example corresponds to a 13 C free induction decay signal from a nuclear magnetic resonance spectroscopy of ethanol. The value of the dimensions key is an array (lines 12-26) with a single JSON serialized LinearDimension object (lines 13-25) representing a temporal dimension with 4096 coordinate positions sampled every 0. 1 ms starting at -0. 3 ms. The coordinate values along the dimension are evaluated using Eq (3).
In this example, the first and the last complex numbers of the signal in Fig  3 are (-8899. 406 -i1276. 773) and (-193. 923 -i67. 065), respectively. Note that the length of the ordered data array is 2M for complex numeric types, where M is the total number of sampled data points. acetone. csdf. In Listing 3 is an illustration of a 1D{1} mass spectrum dataset  [9]  serialized with sparse sampling. Here the InternalDependentVariable object (lines 17-43) holds a SparseSampling object (lines 23-34) in the sparse_sampling key. Inside the SparseSampling object are the three keys dimensions_indexes, sparse_grid_ vertexes, and unsigned_integer_type. The dimensions_indexes key holds an array of integers specifying the indexes of the dimensions along which the dependent variable is sparsely sampled.
In this case, it is the zeroth dimension, i. e. , the only dimension in the dataset. The sparse_grid_vertexes key holds an array of integers specifying the vertexes on the one-dimensional sparsely sampled grid. Again, in this example with only one dimension, the array of integers corresponds to the sampled sparse grid vertexes, i. e. , the coordinate indexes, j 0 , along the zeroth dimension. The value uint8 for the unsigne-d_integer_type key is the numeric type used when importing the JSON serialized integer array from the sparse_grid_vertexes key.
2D{1} examples TEM. csdf. In Fig 4 is an intensity plot of a Transmission Electron Microscopy (TEM) dataset of a section of the early larval brain of Drosophila melanogaster used in the analysis of neuronal microcircuitry  [10]. The CSDM JSON serialization for this 2D{1} dataset is given in Listing 4. This dataset has two dimensions, d = 2, and one single-component dependent variable, p = 1. The value of the dimensions key is an array with two JSON serialized LinearDimension objects, defined in-between lines 8-12 and 13-17. Both these objects describe a linearly sampled spatial dimension with 512 points sampled every 4 nm. As before, Eq (3) gives the ordered list of the coordinates along the respective dimensions. The value of the depen-dent_variables key is an array containing a single JSON serialized InternalDepen-dentVariable object (lines 20-26).
Unlike the previous examples, the value of the components key is an array with a single element. This element is a Base64 encoded string, as indicated by the encoding key, and decodes to an array of binary data values which are interpreted as an array of numerical values with a uint8 numeric type. The array of numerical values is then mapped to the 512 × 512 coordinate grid according to Eqs  (7)  and  (8). bubble. csdfe. In Fig  5  and in Listing 5 we present a 2D{1} astronomy dataset of the bubble nebula acquired at 656 nm wavelength by the Hubble Heritage Project [11] team. In this example, the value of the dimensions key is an array with two JSON serialized LinearDimension objects defined in lines 8-15 and 16-23. Both these objects describe a linearly sampled angular dimension. The value of the dependent_variables key is an array with a single JSON serialized ExternalDependentVariable object, described in lines 26-32.
In this example, the value of the type key is external, indicating that the data values are stored in an external file located at the Uniform Resource Locator (URL) address given by the compo-nents_url key. In this case, the address corresponds to a local file, designated by the file scheme of the URL, relative to the location of the bubble. csdfe file. The external file holds an ordered array of 11592 × 11351 binary values, which are specified by the numeric_type key as 32-bit floating-point numbers. Listing 5. CSD model depiction of an astronomy image dataset. JSON serialized listing of the astronomy dataset describing the bubble nebula observed at 656 nm wavelength. The listing was created by the authors using data from reference  [11].
satRec. csdf. A monotonic dimension is employed when measurements are not uniformly spaced or span several orders of magnitude along a dimension. An example of a 2D{1} dataset with a monotonic dimension, acquired by the authors, is given in Listing 6. Here the dataset comes from a 29 Si NMR magnetization recovery measurement of a highly siliceous ZSM-12 zeolite sampled on a 2D rectilinear grid. The value of the dimensions key is an array with two JSON serialized Dimension objects (lines 18-30 and 31-38). The first is a LinearDimension object, labeled as t 2 , describing a temporal dimension with 1024 points sampled at every 80 μs with a coordina-tes_offset of -41. 04 ms. Additionally, this LinearDimension object contains a Reci-procalDimension object serialized as the value of the reciprocal key.
The second is a MonotonicDimension object, labeled as t 1 , with the coordinates associated with grid vertexes along the dimension explicitly given in the ordered set of values in the coordinates key. The value of the dependent_variables key is an array with a single JSON serialized InternalDependentVariable object (lines 41-47) describing the signal response. Here, the data values are encoded as an array with one Base64 string in the components key. This listing also gives an example of the use of the application key in the csdm dictionary. Here an application owning the domain name physyapps. com has placed an attribute in the application dictionary using the reverse domain name key com. physyapps. rmn. Domain name owners are free to place any valid JSON object as the value of their respective reverse domain name attribute inside the application dictionary.
The dimension_indexes key holds an array of integers specifying the indexes of the dimensions along which the dependent variable is sparsely sampled, in this case, the k = 1 dimension. The sparse_grid_vertexes key holds an array of integers specifying the vertexes on the one-dimensional sparsely sampled grid. Since there are two dimensions in the dataset the array of integers corresponds to the coordinate indexes, j 1 , along the k = 1 dimension. In this example, the dependent variable values are fully sampled along the k = 0 dimension. The value of the unsigned_integer_type key holds the numeric type used in importing the integer array from sparse_grid_vertexes. [12]. As before, the sparse_sampling key holds a Spar-seSampling object with the dimension_indexes, sparse_grid_vertexes, and unsigned_integer_type attributes.
2D{3} example RGB_image. csdf. A simple example of a 2D dataset with multiple components is a color image  [13] , such as the one shown in  Fig 9. This is a 2D{3} dataset, with two LinearDimension objects and one three-component dependent variable, p = 3. The CSDM serialization is shown in Listing 9. The dimensions key holds an array with two JSON serialized Linear-Dimension objects (lines 8-13 and 14-19) with 1024 and 768 points, respectively, and a unit sampling interval. The dependent_variable key holds an array with a single JSON serialized InternalDependentVariable object (lines 22-34) containing an image dataset as indicated by the pixel_3 value of the quantity_type key. The first part, pixel, indicates pixel data, and the last part, 3, gives the number of pixel components. An array holding to the three components, i.
e. , the red, green, and blue color intensities with each encoded as a Base64 string, is the value of the components key. The Base64 decoded binary data values are then interpreted as an array of 8-bit unsigned integer (uint8), for each component, and subsequently mapped onto a 1024 × 768 coordinate grid. The value of the component_labels key is an array of the labels ordered to match the order of the components. Listing 7. CSD model depiction of a sparse NMR dataset with one sparse dimension. JSON serialized listing of 13 C-15 N NMR HSQC dataset containing one single-component DependentVariable object and two Dimension objects. The listing was created by the authors using data from reference  [12].