dataesr/scientific-paragraphs-categorization huggingface dataset:
However, it is not implemented yet. The next best systems are GOODS and CoreKG, with five out of six features implemented. However, they are black box metadata systems, with few details on metadata conceptual organization. Thus, the Ground metadata model may be preferred, since it is much more detailed and almost as complete (four out of six features). Eventually, two of the six features defined in Section 4. 4. 1 may be considered advanced. Data polymorphism and data versioning are indeed mainly found in the most complete systems such as GOODS, CoreKG and Ground. Their absence from most of metadata systems can thus be attributed to implementation complexity.
Pros and Cons of Data Lakes In this section, we account for the benefits of using a data lake instead of more traditional data management systems, but also identify the pitfalls that may correspond to these expected benefits. An important motivating feature in data lakes is cheap storage. Data lakes are ten to one hundred times less expensive to deploy than traditional decisionoriented databases. This can be attributed to the usage of open-source technologies such as HDFS  [26, 53]. Another reason is that the cloud storage often used to build data lakes reduces the cost of storage technologies. That is, the data lake owner pays only for actually used resources. However, the use of HDFS may still fuel System Type SE DI LG DP DV UT SPAR  [14]  [1] [55] Constance  [18]  GEMMS  [44]  ♦ CLAMS  [12]  [54] ♦ [50]  [13]  GOODS  [20]  CoreDB  [3]  Ground  [21]  ♦ KAYAK  [32]  CoreKG  [4]  [9] ♦ [36] CODAL  [48]  MEDAL  [49]  ♦ : Implementations ♦ : Metadata models : Model or implementation akin to a data lake Table  2  Comparison of data lake metadata systems  [49]  misconceptions, with the concept of data lake remaining ambiguous for many potential users.
It is indeed often considered either as a synonym or a marketing label closely related to the HDFS technology  [1, 17]. Another feature that lies at the core of the data lake concept is data fidelity. Unlike in traditional decision-oriented databases, original data are indeed preserved in a data lake to avoid any data loss that could occur from data preprocessing and transformation operations  [15, 53]. Yet, data fidelity induces a high risk of data inconsistency in data lakes, due to data integration from multiple, disparate sources without any transformation  [40]. One of the main benefits of data lakes is that they allow exploiting and analyzing unstructured data  [15, 29, 53]. This is a significant advantage when dealing with big data, which are predominantly unstructured  [37]. Moreover, due to the schema-on-read approach, data lakes can comply with any data type and format  [6, 15, 26, 33].
Thence, data lakes enable a wider range of analyses than traditional decision-oriented databases, i. e. , data warehouses and datamarts, and thus show better flexibility and agility. However, although the concept of data lake dates back from 2010, it has only been put in practice in the mid-2010's. Thus, implementations vary, are still maturing and there is a lack of methodological and technical standards, which sustains confusions about data lakes. Finally, due to the absence of an explicit schema, data access services and APIs are essential to enable knowledge extraction in a data lake. In other words, a data access service is a must to successfully build a data lake  [1, 23] , while such a service is not always present. Next, an acclaimed advantage of data lakes over data warehouses is real-time data ingestion.
Moreover, when considering data gravity  [33] , virtual data integration becomes a relevant solution. Yet, mediation approaches are likely to require new, big data-tailored query optimization and caching approaches  [43, 52]. Unstructured datasets, although unanimously acknowledged as ubiquitous and sources of crucial information, are very little specifically addressed in data lake-related literature. Index storage and text mining are usually mentioned, but there is no deep thinking about global querying or analysis solutions. Moreover, exploiting other types of unstructured data but text, e. g. , images, sounds and videos, is not even envisaged as of today. Again, although all actors in the data lake domain stress the importance of data governance to avoid a data lake turning into a data swamp, data quality, security, life cycle management and metadata lineage are viewed as risks rather than issues to address a priori in data lakes  [33].
campaign and 13,219 dogs and 1,044 cats during the 2020 campaign. The vaccination data were recorded with the GDL and visualized via REB. Subsequent GIS-analysis using gridded population data revealed a suboptimal vaccination coverage in the great majority of grid cells (82%) with a vaccination coverage below 50%. Spatial regression analysis identified the number of schools, estimated human density, and adult dog population were associated with the vaccination performance. However, there was an inverse correlation to human densities. Nonetheless, the use of the GDL improved data capturing and monitoring capacity of the campaign, enabling the Namibian government to improve strategies for the vaccination of at-risk areas towards achieving adequate vaccination coverage which would effectively break the transmission of rabies.
Study area The use of the new data collection tool was exemplarily implemented in four neighboring regions of the NCAs including Oshana, Oshikoto, Omusati and Ohangwena (Fig 1A ), in which targeted MDV campaigns were conducted in selected rabies hot spot areas during August/September 2019 and June/July 2020. The study area comprising of 22,000 km 2 was set up in regions of good access with high human density and high numbers of reported rabies cases based on a 20 km X 20 km grid cell basis covering both urban and rural settings (Fig 1B  and 1C ). The 2018-2019 rabies surveillance data (laboratory diagnoses cases) maintained in the national animal disease database were used to map and identify the rabies hotspots for targeting mass dog vaccination campaign (Fig 1D ).
GARC Data Logger (GDL) training and application in Namibia Twenty GDL devices were procured to capture and monitor the MDV activities. The GDL was developed as a labile, hand-held data collection device that consist of a robust hard-wearing plastic casing, touch-activated buttons and indicator light-emitting diodes (LEDs), which make it rather resistant to damage and breakage  [24]. The GDL can collect the most important data associated with every vaccinated animal (animal species, sex and age) in the field within approximately three seconds. Once data capturing has been confirmed, the GDL also automatically records the GPS coordinates using satellite triangulation, as well as the date and time of vaccination. Data that was captured and stored on the device (with an internal memory that can store up to a maximum of 500 recordings) is subsequently connected to a computer using a universal serial bus (USB) type-C cable and downloaded using a custom-developed software program called the "GDL Manager" (version 1.
11)  [24]. Prior to the implementation of the GDL devices, a one-day training for the vaccination teams on the GDL application and data management was provided in the four NCA regions at their respective State Veterinary Offices. All of the relevant staff were trained on downloading and transferring the data to the Rabies Epidemiological Bulletin (REB). The REB is a free-to-use web-based data platform that was developed by GARC in 2016 using the District Health Information System 2 (DHIS2) platform  [24, 25]. The main purpose of the REB is to provide governments of rabies-endemic countries with a data analysis platform that facilitates the establishment and routine use of rabies-specific data-allowing the governments to make data-driven decisions with regards to their own rabies elimination efforts  [25].
In addition to managing the nationallevel data, the REB also has additional functionality that allows governments to effectively manage data that has been collected during dog vaccination campaigns, human rabies treatment events and active or passive rabies surveillance campaigns. For example, the REB enables data that has been collected during dog vaccination campaigns to be automatically displayed as vaccination points on various interactive maps as shown in S1 Fig, while also automatically generating graphs of the total number of vaccinated animals with the data disaggregated by species, age and sex. By utilizing the REB's functionality the campaign managers and the veterinary authorities that had been granted the relevant permission could visualize the vaccination data in near real time.
3:1  [21]. Data on the number of individual dogs vaccinated in the four NCA regions as captured by the GDLs was also linked to the same grid cells and the estimated vaccination coverage was calculated per grid cell. The bar graph, box plot and 95% binomial confidence interval (CI) for each grid cell vaccination coverage was calculated and plotted as error bars in R version 3. 6. 1  [26]. The data from three grid cells in 2019 were excluded from the analysis since they contained outliers likely due to inaccuracy in the estimated dog population (see regression analysis below). The vaccination data aggregated by age and sex were also analysed. The vaccination team efficiency was also assessed by calculating the daily/hourly number of animals vaccinated by each team. All spatial analyses including extraction of the human population and vaccination data from each grid cell, vaccination coverage estimation and mapping were performed using the count by polygon vector analysis feature in Quantum GIS version 3.
In addition, post-vaccination surveys to assess the vaccination coverage and the validity of the gridded cell/ area approach are also being planned for future implementation. With 1. 2 million people spread out over 263,376 km 2 the dog rabies control program in the NCAs is logistically challenging, also considering the monitoring of the campaigns  [21]. Initially, mobile phone technology using the EpiCollect platform  [31, 32]  had been implemented to attempt to monitor MDV campaigns, but the wide-scale implementation failed due to lack of government supplied mobile phones. Thus, the GDL was the preferred choice because of its versatility, ease of handling and the constant technical support provided by GARC  [24]. Despite overcoming many of the shortcomings associated with mobile phone technology, one limitation to the use of the GDL devices was the inability to upload data to the REB in the field if a laptop with an internet connection was not available.
Nevertheless to overcome a potential limitation posed by the GDL's limited current internal memory, GARC has developed an offline version of the software that downloads the data to a laptop in a format that is ready for upload at a later time when an internet connection is available. In addition, GARC has developed a freely available mobile phone application that relies on a user-friendly interface that is similar to that of the GDL to collect vaccination data. In addition to relying on a similar interface, the mobile phone application allows far more data to be stored and uploaded to the REB whenever a stable internet connection is available. Due to the government's hesitation to use mobile phone, the GDL was the only viable option for the Namibian rabies elimination project. Initially, we procured only 20 GDL units for the vaccination campaign at a cost of approximately USD100 per unit.
More specifically, one of the GDLs had malfunctioned during the campaign causing the data to corrupt. The loss of data was resolved by counting the number of spent vaccine doses at the vaccination stations, and manually entering the data on the REB. Despite the benefits and limitations associated with the use of newer technology, the continued future implementation of modern data digital data collection tools such as the GDL and sophisticated real-time data analysis will enable the Namibia government to take greater strides towards the elimination of dog-mediated rabies by 2030. The ability to easily and accurately track and trace each individual dose of vaccine, and in so doing each and every animal vaccinated, is a powerful capacity that should form part and parcel of all future vaccination campaigns.
Introduction Monte Carlo simulations play an important role in the data analysis of neutrino telescopes. Simulations are used to design reconstruction algorithms for neutrino events, as well as to estimate cosmic and atmospheric signals in various physics analyses. GENIE  [1]  is a neutrino event generator focused mainly on the low-energy range (≤ 5 GeV) and presently valid up to 5 TeV. It is currently used by many experiments working in the neutrino oscillation field e. g. [2, 3, 4, 5, 6, 7]. The project's goal is the development of a reference neutrino interaction Monte Carlo simulation tool whose validity extends to PeV scales. The gSeaGen code simulates events induced by all flavours of neutrinos and detectable by a neutrino telescope, using GENIE to simulate the neutrino interactions.
In particular, it allows electron, muon and tau neutrino events to be generated. Depending on the steering parameters it can produce events from multiple (anti)neutrino flavours within one execution of the program (e. g. ν µ + νµ ); simulate charged current (CC) and/or neutral current (NC) interactions; and simulate neutrinos arriving isotropically or from point or extended sources. The code was developed for KM3NeT  [8]. Although applicable both to underwater and under-ice neutrino detectors, the code terminology, as well as the description presented in this paper, follow those of underwater detectors.
Generation of neutrino events A flux driver class implementing the standard GENIE GFluxI class  [12]  has been developed within gSeaGen and used to configure the GENIE event generation driver. The interface generates the neutrino energy and the track information needed to simulate the interaction. The gSeaGen flux driver is able to generate neutrinos coming from diffuse sources (e. g. atmospheric neutrinos) or from point-like and extended astrophysical sources. The neutrino energy is always generated according to a power law spectrum. However, the code provides for each event a weight that can be used to re-weight the generated neutrino events to the chosen astrophysical or atmospheric neutrino spectrum. The neutrino generation algorithm implemented in the gSeaGen flux driver is described in this section.
Corrections for parallax are also neglected since they are irrelevant for the distant astrophysical neutrino sources  [13]. The user also has the possibility to generate the events in a given time interval, simulating neutrinos from transient sources. In this case the modified Julian day (MJD) is uniformly extracted between the two selected dates. The value of the LST at the extracted MJD is then calculated to determine the horizontal coordinates of the source. Finally, gSeaGen gives the possibility to simulate neutrinos coming from an extended astrophysical source with a small angular radius R s (R s < ∼ 10 • ). The generation proceeds as in the case of a point-like source with astronomical coordinates coincident with the extended source centre. Then, the neutrino directions are randomly generated according to a uniform distribution within a disk of radius R s.
Installing the code The gSeaGen source code can be downloaded from zenodo. org/record/3715310 [16]. Its compiling requires a Linux-like operating system and some basic tools, such as the gcc compiler suite, make and PERL. A minimal installation of gSeaGen requires only GENIE 2  as external package. A number of environmental variables must be defined: • GSEAGEN pointing at the top level gSeaGen directory; • GENIE pointing at the top level GENIE directory; • ROOTSYS pointing at the top level ROOT directory. gSeaGen has been written using the GENIE Auk production release series and tested with GENIE version 2. 12. 10. It is also possible to link gSeaGen with the new Bear release series (GENIE v3. 0. 0 and later). In this case the GENIE environmental variables for compiling are: • GENIE pointing at the top level GENIE Generator directory; • GENIE REWEIGHT pointing at the top level GENIE Reweight directory.
When the environmental variables are set, a minimal installation of gSeaGen is obtained typing: $ cd $GSEAGEN $. /configure $ make The configuration script allows enabling/disabling features and specifying paths to external libraries such as the MUSIC and PROPOSAL propagators. The command $. /configure --help lists the configuration options. The configuration script also creates the shell scripts setenv. sh and setenv. csh, helping the user to prepare the environment to run the code.
-point source_info Activates the generation from point-like and extended sources and specifies the source information (see Sec. 11. 4 for details). -prop prop_code [default: PropaMuon] Sets the muon propagation code. Possible choices are: PropaMuon (internal code), MUSIC and PROPOSAL if enabled at compile-time. -r run_number [default: 100000000] Specifies the Monte Carlo run number. -rt [default: can] Set option to define the generation area radius R T. Possible choices are: 1) -rt can the generation surface will be a circle covering the detector can projected onto a plane perpendicular to each neutrino direction; 2) -rt vol the generation surface will be a circle covering the interaction volume projected onto a plane perpendicular to each neutrino direction; 3) -rt proj the generation surface will be the detector can projected onto a plane; 4) -rt value the generation surface radius with R T = value (in meters).
Output File The native gSeaGen event output is a ROOT file containing two "trees": Header and Events. The Header tree reports the general information about the simulation: • gSeaGenVer (string): gSeaGen version; • GenieVer (string): GENIE version; • RunTime (string): running time; • RunNu (int): run number; • RanSeed (int): random generator seed; • EventGeneratorList (string): list of simulated interaction channels; • InpXSecFile (string): cross-section spline file; • NTot (double): total number of generated incoming neutrinos; • EvMin, EvMax (double): generated neutrino energy range (GeV); • CtMin, CtMax (double): generated neutrino arrival cos θ range; • Alpha (double): generation spectral index; • NBin (int): number of energy bins; • Can1, Can2, Can3 (double): Z min can , Z max can and R can of the can (m); • HRock, HSeaWater, RVol (double): interaction volume: height in rock and water and radius (m); • SiteDepth (double): site depth (m); • SiteLatitude, SiteLongitude (double): detector latitude and longitude (rad); • Agen (double): area of the generation surface (m 2 ); • RhoSW, RhoSR (double): SeaWater and Rock densities (g/cm 3 ); • TGen (double): generation time (s); • PropCode (string): muon propagation code; • GenMode (string): simulated livetime mode (DIFFUSE or POINT); • SourceFile (string): input file name with source information (POINT mode); • SourceName (string): name of the simulated source (POINT mode); • Declination, RightAscension (double): source declination and right ascension (rad) (POINT mode); • SourceRadius (double): source angular radius (rad) (POINT mode); • MJDStart, MJDStop (double): source simulated interval in MJD (POINT mode only).
Applications The gSeaGen code has been developed to provide the possibility to use maintained neutrino interaction codes/libraries. The code has been used as a cross-check for GENHEN  [21] , the reference neutrino simulation code for the ANTARES experiment  [22] , written in FORTRAN, and presently used also by the KM3NeT Collaboration for the ARCA detector [8] simulation. As an example, muon neutrinos have been generated up to the present GENIE maximum valid energy of 5 TeV. The spectrum of generated events has been weighted according to the Bartol atmospheric muon flux model  [23]. The results are shown in Fig. 9. GENHEN is not optimised at energies below ∼ 100 GeV and can not be used to simulate interactions below 10 GeV. Moreover, it does not allow for the evaluation of systematics due to neutrino interaction models.
For these reasons, the gSeaGen code was used by the ANTARES Collaboration in the final data analysis to measure atmospheric neutrino oscillation parameters  [25]. These limitations of GENHEN at lower energies are especially important for the KM3NeT Collaboration, hence gSeaGen has been chosen as the reference code for the simulation of the ORCA detector which is optimised to detect neutrinos of a few GeV and is aiming at measuring the neutrino mass hierarchy. The gSeaGen code was used to optimise the detector geometry and to estimate the expected performances published in the KM3NeT Letter of Intent  [8]. At present, the code is used to carry out the Monte Carlo simulations for the ORCA data analysis  [26]. Furthermore, both DeepCore and Upgrade detectors, which are the existing and the future infills of the existing IceCube neutrino telescope  [27] , also aim at measuring neutrino oscillations in the GeV range.
These detectors are located in glacial Antarctic ice and sit above a layer of bedrock. While the code default values and naming convention specify an in-water detector, gSeaGen will also be suitable for modelling these experiments, with an adaptation of medium properties. It is planned to extend the use of gSeaGen to the KM3NeT-ARCA and ANTARES high energy analyses when the GENIE extension at the PeV scale will be available  [11]. Finally, gSeaGen can be used for GVD  [28] , a nextgeneration neutrino telescope being constructed in Lake Baikal. gSeaGen should be well-suited to generate interactions at energies from a few TeV up to 100 PeV for GVD.
Conclusions The gSeaGen code, written in C++ and based on the GENIE neutrino interaction code, has been developed within the KM3NeT Collaboration. The gSeaGen code generates all flavour neutrino interaction events detectable in a Cherenkov neutrino telescope. It can simulate neutrinos coming from diffuse sources (e. g. atmospheric neutrinos) and from point-like or extended astrophysical sources, according to several neutrino fluxes. The gSeaGen code provides the possibility of changing the composition and the density of the neutrino target medium surrounding the detector, allowing the study of systematic uncertainties due to medium composition and also considering both under-water and under-ice detectors. Presently, gSeaGen is the reference code for the simulation of the KM3NeT-ORCA detector, aiming at the study of neutrino physics and optimised to detect neutrinos in the GeV energy range.
Acknowledgements The authors acknowledge the financial support of the funding agencies:  Agence Nationale de la Recherche  (contract  ANR-15-CE31-0020 ),  Centre National de la Recherche Scientifique (CNRS) ,  Commission Européenne (FEDER fund and Marie Curie Program) ,  Institut Universitaire de France (IUF) ,  IdEx program  and  UnivEarthS Labex program at Sorbonne Paris Cité  ( ANR-10-LABX-0023  and  ANR-11-IDEX-0005-02 ),  Paris Île-de-France Region, France ;  Shota Rustaveli National Science Foundation of Georgia  (SRNSFG, FR-18-1268), Georgia;  Deutsche Forschungsgemeinschaft (DFG) ,  Germany ; The  General Secretariat of Research and Technology (GSRT), Greece ;  Istituto Nazionale di Fisica Nucleare (INFN), Ministero dell'Istruzione, dell'Università e della Ricerca (MIUR) ,  PRIN 2017 program  (Grant  NAT-NET 2017W4HA7S ) Italy;  Ministry of Higher Education, Scientific Research and Professional Training, Morocco ;  Nederlandse organisatie voor Wetenschappelijk Onderzoek (NWO) , the  Netherlands ; The  National Science Centre, Poland  ( 2015/18/E/ST2/00758 );  National Authority for Scientific Research (ANCS) ,  Romania ;  Ministerio de Ciencia, Innovación, Investigación y Universidades (MCIU) :  Programa Estatal de Generación de Conocimiento  (refs.