dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments-We thank  Hanna Cieszynski  for her assistance operating the SEM and  Kathrin Jung  for sample preparation. DH is grateful for a Europlanet grant to the London Natural History Museum that was essential for this study. Europlanet 2020 RI has received funding from the  European Union 's  Horizon 2020 research and innovation program  under grant agreement No. 654208. This study was funded by the  Deutsche Forschungsgemeinschaft (DFG)  grants  HE 5352/10-1  and  PA 346/50-1. We thank  G. Libourel  and  A. N. Krot  for their thorough and helpful reviews, as well as associate editor  K. Righter  for handling the manuscript. Editorial Handling-Dr. Kevin Righter.
UDEAL was designed to take data automatically every day. Since the water purification system supplies clean water at the bottom of the tank and draws from the top, a water transparency gradient is expected: cleaner at the bottom and more impurities as we move to the top. Hence, these measurements are done by taking samples from three different ports inside the tank situated at the top, center, and bottom of the tank, 4990, 3320, and 1660 mm from the tank top respectively, see Figure  5a. One LL15 measurement per day per sampling position covering all wavelengths is taken.
ACKNOWLEDGEMENTS We gratefully acknowledge the cooperation of the  Kamioka Mining and Smelting Company. This work was supported by the  JSPS KAKENHI  Grant Numbers  JP21224004 ,  JP26000003 ,  JP24103004  and  JP17H06365. Funding support was provided by  Kavli IPMU (WPI) , the  University of Tokyo  and the  US Department of Energy. We thank the " Consorcio Laboratorio Subterraneo de Canfranc" (Spain)  and the  Boulby Underground Research Laboratory  and in particular the staff of the  BUGS facility (UK)  for supporting the low-background materials screening work. Some of us have been supported by funds from the  European Union   H2020 RISE-GA641540-SKPLUS , the.
General evolution of the SARS-CoV-2 virus Using the available sequence data gathered in the SARS-CoV-2 GISAID database (https://www. gisaid. org) we have, like others  [14, 15] , reconstituted a phylogenetic tree of the evolution of the virus. As the sequences of each viral genome, as well as the date of identification of these sequences are known with fairly great precision, this tree makes it possible to explore the orderly lineage of the mutations which appear over time. In particular, unless we can suspect a recombination event due to the infection of the same patient by two or more viruses, when two identical mutations appear in separate branches of the tree, we can assume that this is the result of evolutionary convergence  [16]. The reasons for this convergence are discussed on a case by case basis when analysing each relevant mutation.
Reversal of the tendency of the viral genome to lose its cytosine residues We have here retained two examples of a situation where, from an upstream branching point in the evolution tree, it appears that the descendants of the virus stop losing their cytosines, and may even tend to regain them. These examples are as follows (Figure  4 ). In dataset 1, there are two sub-trees, the first of which is more of an Asian sub-tree with the root of the node associated with the M2 and M3 mutations. The second contains samples from North America and Oceania, and its root node is related to the M6 and M7 mutations. The first tree arises from the succession of C8782U (synonymous), U28144C (Leu84Ser) mutations in the Orf8 protein, whose function was discussed above. It defines a major clade of variants of the virus  [24] , C24034U (synonymous), and finally the doublet U26729C (synonymous), G28077C (Val62Leu), in the Orf8 protein again.
Finally, the last two samples, USA/WI-33 and USA/WI-28, were derived from the transversion from A to C at position 29567, a mutation at the end of ORF9b. For dataset number 2, this reversal of the trend concerns mostly Latino-American strains. The succession of mutations C241U, C14408U, then A23403G discussed in relation to the generation of end of translation codons in the virus genes, is followed by C3037U (synonymous), and the triplet G28881A, G28882A, G28883C, overlapping the codons at position 203-204 of the N nucleocapsid N gene. They mutate an arginine-glycine dipeptide into a lysine-arginine dipeptide. This alters the positive charge of the protein and may help improve its role in the assembly of the virus genome in the capsid, as discussed below in relation to the appearance of blooms  (36).
The total number of sequences retained at the end of the treatment is 4,088 sequences. A second dataset of 3,246 sequences, 510 of which are common with the first dataset, was retrieved on July 6, 2020 using directly the Nextstrain API  [48]. We note here that, over time, data availability kept being altered, with some sequences deleted from the samples, while other ones entered the database. Furthermore, it was generally difficult to extract large samples of sequences so that it was extremely difficult to build up a consistent data repository where correct statistical approaches could be implemented. It seems very awkward that the bulk of the sequences of a virus of worldwide importance has not been made available at the International Nucleotide Sequence Database despite recommendations of the major research institutions  [49, 50].
Phylogenetic reconstruction The reconstruction process begins with aligning all of the sequences to the reference sequence. Insertions and deletions of genome regions were not taken into account. It was out of the question here to take into account nucleotide insertions and deletions. We retained only the potential one to one substitutions. We used program MAFFT  [51]  to generate these alignments. Some ambiguous positions were highlighted during the alignment process. For example, some regions of the genome may display high instability and wide variability depending on the parameters of the algorithm used to perform the alignment. To overcome this problem, we used the same masks as those used by the Nextstrain team. Sites 18529, 29849, 29851, 29853, as well as the first 130 and last 50 sites of the genome were therefore omitted from the substitution analysis.
We used a General Time Reversible (GTR) model to infer the substitution process at work using the IQTREE software  [52]. This first tree is a fairly raw version which does not take into account the temporal aspect of evolution. The Treetime software  [53]  allows you to refine this tree by also taking into account the sampling dates of the sequences. It then reconstructs the tree with maximum likelihood compared to the sampled sequences. Using maximum likelihood approaches it also infers the compositions of the ancestral sequences of the samples, as well as a 90% confidence interval around the most likely date of these common ancestors. Once the tree has been created, we could then reconstruct the order in which the mutations in each sample appeared, in the sense of maximum likelihood. For the visualization of the tree and the production of Figures  2 to 6 , we used the Auspice program developed by Nextstrain, to which we made some modifications to display the parameters we were interested in.
Acknowledgements AL would like to thank the  Centre Interdisciplinaire de Recherche en Biologie (CIRB, Collège de France)  for its funding, as well as the members of the  SMILE (Stochastic Models  for the  Inference of Life Evolution ) team of the CIRB for many fruitful discussions on the modelling of the COVID-19 epidemic. AD thanks  Stellate Therapeutics  for the support of his laboratory.
Section 3 introduces background information for the cycle of processes implemented in a CAS and the IRRINOV ® method. The next section describes the development process of the complete system and the two ontologies. Section 5 provides an example of the development presented in Section 4. Section 6 presents and compares the results after implementing the system using real experimental data provided by Arvalis. Also, this section discusses the limitations of the IRRINOV ® method, the limitations of the Arvalis dataset and the limitations of the DSS system. Finally, a brief conclusion sums up the system and presents the perspectives.
• The different decisions produced by the method. Second, it was necessary to communicate with specialists of Arvalis and INRAE to clarify the IRRINOV ® method. Some of the questions formulated to the experts were as follows: What is the difference between an irrigation period and a watering cycle? What are the possible values of maize growth stages? How are we to observe a growth stage? Third, to generalize the system, it was necessary to derive standard definitions and concepts in the agriculture domain. This work was carried out by querying a web retrieval system. The selected resources were articles referenced in publications and from well-known organizations. For example, the different maize growth stages are defined in a publication from the University of Iowa  [14]. Fourth, the analysis of the Arvalis dataset provided a better understanding of the computing processes on sensor measurements, as well as the experimental details such as the type of soil and the code names of the sensors.
The specification requirements activity identifies each process belonging to one workflow dedicated to one stream and determines its input, its output and its parameters (thresholds). For example, the workflow dedicated to the soil moisture stream starts with a measurement process from a soil tensiometer probe. Then, those measurements are the input data of a sequence of aggregation processes. The last aggregation value is compared to a threshold to produce a state of a soil moisture entity. This example is precisely outlined in Section 5. Second, the Arvalis dataset provided the parameters to precisely determine the aggregation processes used in the IRRINOV ® method. Examples of such information are the watering cycle duration and the threshold for soil moisture.
• Virtual sensors: read data from Excel files. • Aggregators: run functions to produce aggregated data. • Inference engine: The core is OWLAPI (https://github. com/owlcs/owlapi) and SWRLAPI (https://github. com/protegeproject/swrlapi). This module uses a set of SWRL rules, and all the data provided from the previous module to infer the high-level context. The aggregations are encoded in Python as a function. The deductions are executed by the SWRLAPI Drool inference engine integrated into Ontogen. In detail, the reasoning process of the inference engine in Ontogen can be explained as follows. First, Ontogen generates an OWL file that contains all the individuals and the IRRIG ontology necessary for the rule engine; it creates all the individuals that describe sensor measurements. It also creates the individuals, instances of caso:Deduction, necessary to define the daily deduction per instance of the class caso:Property.
The file name is the concatenation of the feature of interest name and the beginning date. Second, it launches the Drools rule engine and applies it to the individuals previously created. The Drools engine updates the caso:Deduction instance. It links an instance of the class caso:State with an instance of caso:Deduction via the object property caso:hasResultState. Then, it creates a new OWL file that contains the results of the inference engine. The OWL file is updated from the previous file. The rule for Drools is coded in SWRL. There are a total of 25 rules in SWRL and two queries in semantic query-enhanced web rule language (SQWRL): • 5 rules for crop growth. • 1 rule for rain intensity. • 1 rule for root zone soil moisture level. • 16 rules for crop water need. • 2 SQWRL queries for the results after the reasoning.
Each rule is put in a rule file with a ". rule" extension. The rule files are available on the GitLab repository of INRAE via the following link https://gitlab. irstea. fr/irrig/public/tree/master/Rule. The DSS consists of (1) a knowledge base and an inference engine, mostly for high-level context inference, and (2) several functions for numeric data calculation. Except for the case of SleepingDuration, it is a numeric value, but the inference engine produces its value. The knowledge-base contains a rules-base and a facts-base. Technically speaking, the DSS is a part of the Ontogen program. Each day, the DSS takes phenomenon observations as input and produces an irrigation decision. Please note that the Arvalis dataset does not provide the sensor measurements but the daily aggregated values of those measurements.
The fact integrates rules as axioms. After determining the fact, the DSS can launch the Drools inference engine to infer the state of CropGrowth for day d-1. Next, the DSS runs the functions to obtain the value of the root zone average moisture of day d-1 and to obtain the number of delay days. The function to obtain the value of root zone average moisture takes the value of the average moisture of day d-1 corresponding to each soil tensiometer from the Arvalis dataset. Additionally, the function to obtain the number delay days takes the value of the total rain quantity of day d-1 from the Arvalis dataset. The DSS collects all calculated results and retrieves the other rules related to RainIntensity, RootZoneMoistureLevel and CropWaterNeed properties and updates them. Later, the Drools inference engine infers the state of the three mentioned properties and the value of SleepingDuration.
Ontology Evaluation The presented ontologies have been evaluated following three approaches: checking the absence of bad practices, coverage and data-oriented validation. To check the absence of bad practices or common errors in the ontology, the online pitfall scanner OOPS!  [25]  has been applied to IRRIG and CASO. After executing the system, the following changes were made: (1) define some properties as the inverse of corresponding properties, (2) add metadata as rdfs:label and rdfs:comment for ontology elements, and (3) properly enter some ontology elements as OWL classes or properties. Regarding the competency questions coverage, the IRRIG ontology, which as already mentioned contains CASO, has been compared to the CQ previously defined. For each CQ, the ontology elements need to answer the questions that have been identified.
• When the soil tension is low, the crops require less energy to extract soil water. In other words, when a tensiometer returns a high value, the soil moisture level is low. • When the soil tension is high, the crops must use a large amount of energy to extract soil water. The IRRINOV ® method evaluates the water needs of crops by estimating the root zone moisture. Root zone moisture is the quantity of "water remaining in the depth of soil accessed by a plant"  [29]. It depends on the soil type, root depth and irrigation method. Its goal is to evaluate the amount of irrigation water required by the plants  [30]. The system uses six tensiometers to evaluate the root zone moisture. RootZoneMoistureLevel is an observational property of the root zone feature of interest. The RootZoneMoistureLevel property is qualitative data represented by a state.
These states are determined based on tensiometer measurements. Each tensiometer is placed at a specific depth in the soil. Thus, the RootZoneMoistureLevel property depends on the following quantitative data properties: • Soil30cmDepthMoisture: the moisture of a new feature of interest that represents the soil layer at a 30 cm depth (Soil30cmDepth). • Soil60cmDepthMoisture: the moisture of a new feature of interest that represents the soil layer at a 60 cm depth (Soil60cmDepth). • Soil30cmDepthDailyAverageMoisture: the daily average moisture of the feature of interest Soil30cmDepth. It equals the daily average of the property Soil30cmDepthMoisture. • Soil60cmDepthDailyAverageMoisture: the daily average moisture of the feature of interest Soil60cmDepth. It equals the daily average of the property Soil60cmDepthMoisture.
Aggregation Processes of Soil Measurement The first aggregation process is the computation of the daily aggregated soil moisture of the soil tensiometer. In the Arvalis dataset, each observation was stored as two datapoints: (1) the daily aggregated soil moisture in cbar and (2) the date of observation (year, month, day). Three soil tensiometers observe the moisture at a 30 cm depth, and three others observe the moisture at a 60 cm depth. The soil tensiometers used in the IRRINOV ® method are Watermark probes. Watermark probe p measures the soil moisture at time t of day d. The unit of the Watermark probe is the cbar. Please note that a measurement value of 199 cbar indicates an error in the measurement process. Thus, the cleaning process is applied to remove all 199 cbar values. The function getValidMoistureProbe(p,t) returns only the valid moisture value measured by probe p at time t.
If the moisture value is not valid, the function returns nothing. The function getDailyAggregatedMoisture(p,d) returns the average value of all the valid moisture values measured by probe p during the interval [d 00:00:00, d+1 00:00:00[. Table  3  presents the calculation of getDailyAggregatedMoisture(p,d) for one probe. Please note that the data recorded in the Arvalis data are, in fact, the value of the function getDailyAggregatedMoisture(p,d). Suppose that p1, p2, and p3 are the three probes at a 30 cm depth, and p4, p5, and p6 are the three probes at a 60 cm depth. The function getRootZoneDailyAverageMoisture(d) returns the sum of the two median values: (1) the median of the getDailyAggregatedMoisture(p, d) values of three probes at a 30 cm depth, and (2) the median of the getDailyAggregatedMoisture(p, d) values of three probes at a 60 cm depth.
This moisture property is represented by the individual irrig:observableProperty_soil30cmDepth_moisture. Two necessary and sufficient conditions are defined: (1) All instances of the class irrig:Soil30cmDepthMoistureObservation are linked to the individual irrig:observableProperty_soil30cmDepth_moisture via the sosa:observedProperty object property; (2) All instances of irrig:Soil30cmDepthMoistureObservation are linked to the individual irrig:featureOfInterest_soil30cmDepth via the sosa:hasFeatureOfInterest object property. Each instance of irrig:Soil30cmDepthMoistureObservation is linked to a sensor to describe which tensiometer made the observation and how. First, the measurement data are stored in the system under the IRRIG model. Figure  11  presents an example of one measurement from one soil tensiometer.
It is also an instance of the class saref4agri:SoilTensiometer. Arvalis identifies their tensiometers by a number and depth, as presented in Section 4. 1. We reuse this information to create a name for each instance of saref4agri:SoilTensiometer. For example, Figure  11  contains the individual arvalis:soilTensiometer_1_30cm. A tensiometer measurement is an instantaneous observation. Please note that the measurements of tensiometers are unavailable in the Arvalis dataset. Thus, we can imagine that tensiometer measurements may happen at any time of the day. Figure  11  presents a measurement that happens at 08:00:00 on 14/08/2013. To store the time of the measurement, we create an instance of the class time:Instant. The time:inXSDDateTimeStamp data property stores the associated date time value.
The sosa:phenomenonTime object property links the observation individual to the instant individual. To present the time when the node tensiometer generates the measurement, we use the sosa:resultTime datatype property to links the observation individual to the xsd:dateTime value corresponding to a precise time. In Figure  11 , this precise time is at 08:00:00 on 14/08/2013. The result of tensiometer measurement is presented by an instance of the class sosa:Result. This result is described by a value and a unit. The instance of sosa:Result is linked to the data value via the om:hasNumericValue datatype property. The instance of sosa:Result is linked to the individual om:millibar, an instance of the class om:Unit, via the om:hasUnit object property. Please note that in the Arvalis dataset, the unit of tensiometer measurement is the cbar.
By definition, individuals of irrig:Soil30cmDepthMoistureObservation are linked to the individual irrig:observedProperty_soil30cmDepth_dailyAverageMoisture, an instance of the class irrig:MoistureProperty, and to the individual irrig:featureOfInterest_soil30cmDepth. The observation individual is linked to the sensor that produces the result, i. e. , a software program that computes the daily average of several measurements. We do not have information on the agent that produces this computation in the Arvalis dataset. It is possible that the same software, located on a server, computes the average for all the measurements. Alternatively, the IRRINOV station may contain two different processing devices. Each device can compute the average for all the tensiometers located at the same depth. To avoid errors, we create a software agent for each tensiometer based on the tensiometer name: arvalis:aggregator_getDailyAggregatedMoisture_1.
The individual that represents the software is an instance of the class sosa:Sensor. The observation individual is linked to the software agent via the sosa:madeBySensor object property, as shown in Figure  12. The software program produces the result once per day at a precise time. In the Arvalis dataset, there is no information about the hour, minute and second of the computation. For synchronization purposes, we fix it to the time of the deduction computation [d+1 06:00:00]. At this time, all the tensiometer measurements were available for the computation of the average. To store the time of the computation, we use the sosa:resultTime datatype property to links the observation individual to the xsd:dateTime corresponding to the precise time [d+1 06:00:00]. This is presented in Figure  12.
The software program is named arvalis:aggregator_getRootZoneDailyAverageMoisture. This individual is an instance of the class sosa:Sensor. The observation individual is linked to the sensor via the sosa:madeBySensor object property, as shown in Figure  13. The software computes at a precise time when all its inputs are available. There is no information about the hour, minute and second of the computation. For synchronization purposes, we fix it to the time at [d+1 06:00:00]. To store the time of the computation, we use the sosa:resultTime datatype property to links the observation individual to the xsd:dateTime value corresponding to the precise time [d+1 06:00:00]. This is presented in Figure  13. The computation calculates the daily average. Figure  13  presents the computation for the 14/08/2013.
Testing of the Reasoning Process in the Soil Moisture Workflow This section focuses on the testing results. In each test scenario, the system takes an input value and produces an output result. It is possible to evaluate the system by comparing the inferred output results to the expected outputs. There are a total of 21 test scenarios: • 14 unit tests: Input values are boundary values given by the testers around the threshold. Expected outputs are manually calculated by the testers using the IRRINOV ® method. • 7 sample tests: Input values are samples chosen in the Arvalis dataset. Expected outputs are manually calculated by the testers using the IRRINOV ® method. Table  6  shows the results of the 14 unit test scenarios. This table includes the four following columns.