dataesr/scientific-paragraphs-categorization huggingface dataset:
The main characteristics of these algorithms are summarised in Table  1. Concerning the metrics, none are commonly accepted in the literature. Many papers based their evaluations on qualitative analyses. Some papers developed their own quantitative metrics, but these were specific to each algorithm or limited to keypointbased algorithms. This review shows that many papers in the non-medical image stitching literature have improved the methods currently used in laparoscopy. To evaluate how these new methods behave in our domain, we propose to build a realistic dataset of images from multi-camera systems in laparoscopic situations. This is the contribution of the next section. PTIS  [22]  ANAP  [23]  NIS  [24]  REW  [25]  Perazzi  [27]  UDIS  [34]  Alignment over an/along a. • Computationally expensive Overlap • Fails on important parallax issues • Bottleneck of optical flow computation • Do not address the projective distortions.
Material: A New Simulated Environment The development of image stitching techniques in laparoscopy is slowed down for two reasons. Firstly, there is no public dataset of images recorded from multi-camera systems that could be used to evaluate the image stitching algorithms. Secondly, it is difficult and time-consuming to record new in vivo images for each new configuration of a multi-camera system to check the quality of the image stitching. This is why we developed a flexible simulated environment that offers realistic laparoscopic images and is easily configurable to take many laparoscopic scenarios into account. The goal of this environment, developed using Blender (http://www. blender. org (accessed on 6 January 2022)), a 3D modelling and rendering software, was not to achieve anatomical realism, but rather to produce images that could realistically represent laparoscopic conditions as viewed from laparoscopic cameras.
g. , the number/position/orientation of forceps; • Endoscope: the depth inside the abdomen cavity, camera parameters (e. g. , focal, resolution), the power of the LEDs; • Multi-camera system: the position/orientation of the device, camera parameters (e. g. , focal, resolution), the power of the LEDs; • Rendering parameters: the type of rendering engine, output image resolution and exposure. Some examples of the generated images are shown in Figure  2  and other examples are provided in Supplementary Material Figure  S1. Videos can also be generated, with moving forceps or endoscopes, for instance. The simulated environment and some videos/images are publicly available at the following link: https://gricad-gitlab. univ-grenoble-alpes. fr/g uys/laparo_simulated_environment (accessed on 6 January 2022).
• Global homography  [16] ; • Graphcut (global homography and graph cut  [19] ); • Mesh-based models: APAP [21], ANAP  [23] , NIS  [24] , REW  [25]  and PTIS  [22] ; • Two non-mesh-based models: the optical flow-based model Perazzi  [27]  and the neural network-based model UDIS  [34]. These algorithms were selected because they cover the actual algorithms used with prototypes and the main recent advances in image stitching for non-medical applications. Out of all the deep learning approaches detailed in Section 2, we chose to evaluate the unsupervised approach UDIS  [34]  since it does not require a synthetic ground truth dataset (which are "no parallax" biased) and seems more promising for future application in laparoscopy. Out of all these methods, PTIS  [22]  and Perazzi  [27]  were implemented since their authors did not provide any source codes.
Discussion As stated in Section 1, our first goal was to provide a simulated environment that was realistic enough to easily evaluate multi-camera prototypes. Ref. [38]  also introduced a Blender module for the generation of simulated data for surgery. However, its main goal was to generate various types of data, e. g. , depth maps, segmentation masks and optical flow masks in a mono or stereo endoscopic contexts, which are not helpful for the evaluation of image stitching algorithms on multi-camera prototypes. It also offered the possibility to create a 3D scene using an RGB-D recording (which restricts its usage to ex vivo or phantom setups), and some 3D scenes were generated but were not publicly accessible. This motivated us to develop our own simulated environment that would be realistic enough to easily evaluate multi-camera prototypes.
Concerning the level of realism of our dataset, we took care to incorporate realistic tools (in terms of textures, shape and sizes) and organ-like textures with dimensions that were coherent with the literature, and we simulated illumination sources adapted to laparoscopic setups (i. e. , a spotlight source coming from the tip of the endoscope). While we took care to develop a realistic environment, we cannot provide a quantitative metric proving its degree of realism. However, compared to the environments used by researchers who evaluate multicamera prototypes (ex-vivo organs, meat or plastic-like organs  [6, 9, 10] ), we believe that we were able to progress one step further in terms of realism. Moreover, this environment can be well integrated in the iterative prototyping process. The main direction to further improve this environment would be to make it more realistic in terms of anatomy.
This would, however, require a high-quality segmentation. Another alternative could be to rely on the 3D reconstruction of the scene  [7] , at the expense of high computational resources. Concerning the promising neural network approaches, such as UDIS, the straightforward approach to improve them for laparoscopy would be to use them with a huge unlabelled dataset from our simulated laparoscopic environment. However, it might not improve the deep learning training to use thousands of images generated from our environment, which does not yet provide enough variety in backgrounds. One possibility would be to use some of the backgrounds from  [38] , should they become publicly available. This would need to be further investigated, especially to verify that overfitting does not occur as this is a major issue of data-driven techniques.
Funding: This work was supported by the following funding from the  French government , managed by the  French National Research Agency (ANR) : The  DEPORRA2  project ( ANR-14-CE17-0009 ); The  Investissements d'Avenir Programme  ( Labex CAMI)  under reference  ANR-11-LABX-0004 ;  MIAI @ Grenoble Alpes  ( ANR-19-P3IA-0003 ). The study also benefited from the support of  Institut Carnot LSI.
Modern breeding methods integrate next-generation sequencing (NGS) and phenomics to identify plants with the best characteristics and greatest genetic merit for use as parents in subsequent breeding cycles to ultimately create improved cultivars able to sustain high adoption rates by farmers. This data-driven approach hinges on strong foundations in data management, quality control, and analytics. Of crucial importance is a central database able to 1) track breeding materials, 2) store experimental evaluations, 3) record phenotypic measurements using consistent ontologies, 4) store genotypic information, and 5) implement algorithms for analysis, prediction and selection decisions. Because of the complexity of the breeding process, breeding databases also tend to be complex, difficult, and expensive to implement and maintain.
Here, we present a breeding database system, Breedbase (https://breedbase. org/). Originally initiated as Cassavabase (https://cassavabase. org/) with the NextGen Cassava project (https://www. nextgencassava. org/), and later developed into a cropagnostic system, it is presently used by dozens of different crops and projects. The system is web-based and is available as open source software. It is available on GitHub (https://github. com/solgenomics/) and packaged in a Docker image for deployment (https://dockerhub. com/breedbase/). The Breedbase system enables breeding programs to better manage and leverage their data for decision making within a fully integrated digital ecosystem.
INTRODUCTION Modern plant breeding is a data intensive process requiring multiple diverse datasets to be integrated and assessed in decision making. In classical plant breeding, promising individuals are intentionally interbred to generate a diverse population of progeny, from which individuals with the best phenotypic characteristics are selected to be used as elite parents in subsequent breeding cycles or released as improved cultivars  (Breseghello and Coelho 2013). Modern plant breeding extends classical breeding with the use of marker assisted selection (MAS) and genomic selections (GS) to augment phenotypic selection  (Ribaut and Hoisington 1998). Furthermore, with the emergence of high-throughput phenotyping technologies as tools for breeding, the number of potential phenotypes to be tracked has vastly increased  (Andrade-Sanchez et al.
2014; White et al. 2012). The development of inexpensive genotyping technologies allow even small breeding programs to acquire high-density genotyping data for a large portion of their germplasm. The availability of this genomic data has enabled more efficient approaches to evaluate important and complex traits in the breeding process  (VanRaden 2008). One such approach is genomic selection (GS), which combines genomic and phenomic data to develop a predictive model that can be used to estimate genotypic or breeding values  (Meuwissen and Goddard 2001). Since genotyping is both less expensive and faster than phenotypic selection, genomic selection can result in significant acceleration of the breeding cycle with concomitant faster increases in gain. A challenge for genome-based breeding methods is the establishment of an adequate data management infrastructure to integrate the complex datasets spanning the breeding process  (Volk et al.
2021). This represents a severe constraint to mainstreaming predictive breeding to small breeding programs, particularly in developing countries. To address these data management challenges, we initiated a system called Cassavabase (https://cassavabase. org/) for the NextGen Cassava project building on a genomics codebase developed for many years for the Solanaceae called SGN (https://solgenomics. net/)  (Mueller et al. 2005a; Menda et al. 2008; Bombarely et al. 2011; Fernandez-Pozo et al. 2015a). With an initial focus on tomato and sequencing its genome  (Mueller et al. 2005b; Tomato Genome Consortium 2012) , SGN already contained a comprehensive genomics database with a strong phenotype management component  (Menda et al. 2008) , a number of genomics-centric tools  (Mueller et al. 2008; Tecle et al.
2010; Fernandez-Pozo et al. 2015b) , and a rudimentary version of a genotyping storage backend  (Fernandez-Pozo et al. 2015a). Cassavabase is an opensource, web-based breeding data management and analysis system built with the ability to manage the genomic selection process  (Tecle et al. 2014). As more instances of the software were deployed for other crops, the system expanded to better meet each project's needs by adding further breeding-related tools, such as image-based or nearinfrared spectroscopy (NIRS)-based phenotyping tools  (Hershberger et al. 2021 ). To reflect that the underlying software and database are amenable to any crop and to promote adoption by new communities, we named the system "Breedbase" (https://breedbase. org/). Major clonal crops using Breedbase currently are cassava (https://cassavabase.
2019). When data are loaded into a database, many checks can be performed to make sure the data are consistent and in line with specified quality control criteria. Many breeders, especially in smaller programs that cannot allocate resources to data management tools, maintain their data in spreadsheets. While spreadsheets provide a straightforward way to manage data and analyses, they suffer from a number of drawbacks, even with relatively small volumes of data. For example, it is difficult to precisely merge data across different spreadsheets, often resulting in errors and data quality issues, or to visualize or analyze data across spreadsheets. Data in spreadsheets are typically not normalized, resulting in typographical issues, inconsistent identifiers, liberal use of synonyms, and similar issues that make the data hard to aggregate.
Nevertheless, the largest problem with spreadsheets is that their storage is not centralized; in fact, they are often stored on personal computers and laptops, often in multiple inconsistent versions, with potentially limited backup strategies and little recourse if accidental data loss occurs or if a person leaves the breeding program, taking all the breeding data with them. Breeding programs can be very large, encompassing many locations with many collaborators; as such, spreadsheets hinder collaboration because data cannot be accessed in a consistent state by many people at once. Furthermore, with genome-based breeding, spreadsheets become unworkable, as it is difficult to maintain and analyze potentially very large genotypic data sets in spreadsheets in any useful way. It is important to note that using a database is not sufficient for managing a modern breeding cycle -the entire breeding process needs to be integrated around the database to create an efficient digital ecosystem.
Implementation The Breedbase data architecture is built around a Postgres (https://postgresql. org/) relational database with a schema that is mainly derived from Chado  (Jung et al. 2011) , with some historic, pre-Chado tables from SGN, as well as minor customizations  (Fernandez-Pozo, Menda, et al. 2015 ) (Figure  1a ). In relational databases, information is systematically structured into concepts represented as tables ("normalization"), a format that facilitates many aspects of data management. The information in the different tables can be joined based on primary and foreign keys, which are usually numeric values assigned to every row in a table. For some data types, such as genotypic data, Breedbase uses non-SQL extensions built into Postgres, such as JSONb-based data structures  (Morales, Bauchet, et al.
2020). The application layer is implemented in Perl, using the Moose object system, based on the Model-View-Controller (MVC) Catalyst web framework (http://www. catalystframework. org/), with Mason as the templating toolkit (https://metacpan. org/pod/Mason). The system uses an object-relational layer based on DBIx::Class, with the main Chado classes organized in the Bio::Chado::Schema namespace. For statistical analyses and some of the data visualizations, the R language and add-on R packages (https://r-project. org/) are used. Image analyses and machine learning models are implemented in Python TensorFlow (https://www. tensorflow. org/) and OpenCV (https://opencv. org/) (Morales, Kaczmar, et al. 2020). The frontend graphical user interface (GUI) development has recently transitioned away from Mason components to JavaScript, with a heavy reliance on asynchronous JavaScript requests.
Almost all functionalities are implemented as RESTful services, allowing for a more interactive user experience and reusable codebase. JavaScript frameworks used for the GUI include JQuery (https://jquery. org/), D3. js (https://d3js. org/), Bootstrap (https://getbootstrap. com/) and Brapi. js (https://brapi. org/). The entire Breedbase system is built on open source software and is packaged in a Docker image for deployment (https://docker. com/). For interoperability with other breeding database and tools, Breedbase implements the BrAPI 2. 0 specification  (Selby et al. 2019). In terms of user interface, the goal of Breedbase is to provide a standard, modern web interface for all breeding tools. Breedbase is essentially a cloud-based app, obviating the need for the user to install any software.
Development Process The development process can be broadly described as agile  (Shore, Chromatic, and Warden 2008; Beck and Andres 2004) , in which shorter-term goals are defined and implemented, and subsequently further refined based on new feedback from users; agile teams provide for short release cycles and continuous improvement to the software (Figure  1b ). Progress is tracked using a version control system with built-in issue tracking software (GitHub, https://github. com/). New features are discussed with breeders and other stakeholders. Issues and bugs discovered in Breedbase are tracked on the public GitHub issue tracker. A programmer is then assigned to a ticket, and will create an issue-specific topical git branch in the relevant code repositories, and implements the required changes in the branch, including tests and edits to the user documentation.
Ontologies A key aspect of data integration is the necessity of standardization. Breedbase is based on the Chado database schema, which relies heavily on controlled vocabularies and ontologies to describe its data, and requires numerous ontologies for its internal functioning. In many ways, it can be described as an ontology-based database. For the breeding application, data standardization in the form of trait catalogs is especially important when several sites or breeding programs share data in the database. Without standardization, the data would not be comparable, limiting the utility of an integrated database. The creation and maintenance of trait ontologies is a considerable task. The Crop Ontology (CO) project was developed by CGIAR to define and maintain relevant breeding ontologies  (Shrestha et al.
2012). All the RTBbases use the Crop Ontology vocabularies and collaborate with Crop Ontology and breeders to improve and expand these vocabularies  (Arnaud et al. 2020). If no ontologies are available, they have to be created, which can be a lengthy and arduous task. The Protégé tool (https://protege. stanford. edu/) (Musen 2015)  is commonly used by curators for editing ontologies before upload to Crop Ontology and Breedbase. The Trait Dictionary Template along with the Guidelines  (Pietragalla et al, 2020) , available in the CO website, remain useful to collect the trait details from the research community and reach consensus. Each species is allocated a code by the CO coordination team to identify the ontology and crop repositories are created in the Planteome Github to secure the ontology version management.
Interoperability and BrAPPs Databases must interoperate with a variety of tools to perform their functions in data acquisition, analysis, and data export. Recently, a standard called the Breeding Application Programming Interface (BrAPI; https://brapi. org/) was developed to exchange breeding data  (Selby et al. 2019) , which breeding databases can implement to provide a standard interoperability layer. Standardized application programming interfaces (APIs) allow Breedbase to integrate and interface with a broader set of BrAPI enabled applications, or BrAPPs, that can be written across diverse programming languages including Android, R, and Javascript. The BrAPI R package allows data retrieval from Breedbase for further statistical processing within the R environment. Javascript based BrAPPs provide dynamic visualization of plant breeding data, such as pedigrees exploration, experimental field maps, and data from multiple trials.
BrAPPs can interact with data from any BrAPI compliant database, such as Breedbase or the Breeding Management System (BMS) (Figure  1a ). Activities such as dynamic data filtering, trial comparison, box plotting, and a comparative genetic map viewer are also implemented with BrAPPs on Breedbase. Breedbase fully supports BrAPI version 2. 0 and is committed to updating the system for future versions of this essential infrastructure.
The Search Wizard and Datasets The Search Wizard allows users to slice their data in different dimensions, such as breeding programs, locations, years, and so forth. The data in the database can be thought of as a multi-dimensional cube which is cut along different dimensions, providing an intersection that represents the data of interest. This approach is conceptually related to a query method called Online Analytical Processing (OLAP)  (Celko 2006). The current Wizard presents four boxes, for four different dimensions, which can be selected using pull down menus (Figure  2 ). For example, a user who is interested in the performance of cassava clones evaluated by IITA in 2017 and 2018 at the Mokwa station in Nigeria can use the wizard to find this information. Working from left to right, the user selects as the first dimension "Breeding Programs", which displays all the breeding programs in the database in the first box.
The user then selects "IITA" from the individual breeding programs listed in the box. When the user selects "Years" in the second box, all the years for which data for IITA exist are listed. In this example, the user selects 2017 and 2018. Finally, after selecting locations in the third box, the user specifies "Mokwa". When trials or accessions are selected, phenotypic and genotypic data corresponding to the selection can be downloaded using buttons below the Wizard boxes. The Wizard also allows the combination of current selections to be stored in the database under a user-given name, representing an intersect of data of interest in the database. This stored selection is called a "dataset". Datasets are used across Breedbase to efficiently reference a complex query with a simple, assigned name.
Special searches Topic specific searches are available from the Search menu, including a trial search, a trait search, searches for genotyping data (including genotyping protocols, projects and plates), an image search that searches image descriptions and associated tags, and a user search that searches the users of the database. All these searches work in a straightforward and consistent way: a search form is filled in with search criteria, and the search is submitted to the database. A list with matched search results is displayed, from which links are provided to the corresponding detail pages.
Analysis Tools Breedbase is more than a static collection of data, as it enables users to explore and analyze data in the database. Once data is uploaded to the database, users can view summary statistics, evaluate phenotypic variances, and identify observations with missing or outlier data. They can filter observations in a trial based on a range of trait or traits values. For an experiment phenotyped in multiple environments, they can evaluate trait performance across environments using pairwise comparison scatter plots and histograms. Breedbase also has tools for ANOVA, correlation, principal component analysis, data partitioning using K-means clustering, genomic prediction, genome wide association study, selection index calculation, genetic gain visualization, and linear mixed models. With the Search Wizard, as explained above, users can construct datasets that can be used as inputs to various tools.
Most tools follow a similar blueprint in terms of user interface: (1) select the dataset of interest from a drop-down menu of all available datasets, (2) adjust parameters for the tool, (3) submit the calculation for analysis, and (4) display the results. For some tools that require heavy computation, an email can be optionally sent to the user with a link to the results. Query implementation is a relatively complex task in the programming of a tool, but the Wizard enables the modularization of algorithms into Breedbase with relatively little glue-code, facilitating tool coverage expansion. Results such as predictions from solGS and adjusted means from mixed models can be saved in the database as analysis results. These results can be used like primary data in downstream analyses such as the selection index tool to help identify favorable germplasm.