dataesr/scientific-paragraphs-categorization huggingface dataset:
Description of the DNA Isolation, Sequencing, and Assembling Methods The on-going genome of P. agardhii PCC 10110 was obtained from a 40 mL culture. The data of the gene cluster analyzed here are freely available on request to the authors. Nucleic acid extraction of cyanobacterial cells to obtain DNA was carried out as previously described  [62]. Genome sequencing was performed by the Mutualized Platform for Microbiology at Institut Pasteur. The whole-genome sequencing was carried out using the Nextera XT DNA sample preparation kit (Illumina) for 2 × 150 bps paired-end reads (insert size ~300 bps). All sequenced paired-end reads were clipped and trimmed with AlienTrimmer2 (v. 0. 4. 0), and subjected to a sequencing error correction with Musket3 (v. 1. 1) as well as a digital normalization procedure with khmer4 (v.
In Silico Analyses in MicroScope The clustering of the strain PCC 10110 was performed with the three other published genomes to display the genomic similarity between these strains. This clustering was computed from all-pairs distances ≤0. 06 (~94% ANI) that correspond to the ANI standard to define a species group. In addition, natural product gene clusters, including NRPS, PKS, and RiPP genes, were identified using the antiSMASH 4. 0 software  [27]  available through MicroScope platform.
5 pore C 18 column (Thermo, Waltham, MA, USA) at a 300 µL•min -1 flow rate with a linear gradient of acetonitrile in 0. 1% formic acid (5%-90% in 21 min) coupled with a high-resolution mass spectrometer. The eluted metabolite contents were analyzed using an electrospray ionization hybrid quadrupole time-of-flight (ESI-QqTOF) high-resolution mass spectrometer (Maxis II ETD, Bruker) on positive simple MS or on positive autoMS/MS mode with information-dependent acquisition (IDA), on the 50-1500 m/z range at 2 Hz or between 2 and 8 Hz speed, for MS and MS/MS respectively, according to relative intensity of parent ions, in consecutive cycle times of 2. 5 s, with an active exclusion of previously analyzed parents. The data were analyzed with the DataAnalysis 4. 4 software for internal recalibration (<0.
5 ppm) and MGF exports were generated from MS/MS spectra between 1 and 15 min. The raw MS and MS/MS data were investigated with MetaboScape 4. 0 software (Bruker, Bremen, Germany) in order to automatically search and group together all classical adduct forms ([M + H] + , [M + 2H] + , [M + 3H] + , [M + Na] + , [M + K] + , and [M + NH 4 ] + ) using a threshold value of 0. 8 for the co-elution coefficient factor. Metabolite annotation was attempted according to the precise mass of the molecules and their respective MS/MS fragmentation patterns with regards to an in-house database of above 700 cyanobacteria metabolites and confirmed with 36 commercially available standard molecules from the various cyanobacterial specific metabolite families (e. g. , cyanopeptolins, aeruginosins, microginins, anabaenopeptins, aerucyclamides, microcystins, saxitoxins, anatoxins, and cylindrospermopsins) analyzed similarly in our mass spectrometry platform.
Data Treatment and Molecular Networking Using the whole MS/MS data (converted in mgf format) obtained for the four strains taken together, a molecular network was created using the online workflow at Global Natural Products Social Molecular Networking (GNPS) (http://gnps. ucsd. edu) [20]. The data were then clustered with MS-Cluster with a parent mass tolerance of 1. 0 Da and an MS/MS fragment ion tolerance of 0. 5 Da to create consensus spectra. Consensus spectra that contained less than two spectra were discarded. A network was then created where edges were filtered to have a cosine score above 0. 6 and more than five matched peaks. Further edges between two nodes were kept in the network only if each of the nodes appeared in each other's respective top 10 most similar nodes. The spectra in the network were then searched against the GNPS spectral libraries.
All matches kept between network spectra and library spectra were required to have a score above 0. 6 and at least five matched peaks. All results are freely available on the GNPS server (http://gnps. ucsd. edu/ProteoSAFe/status. jsp?task=98e54f0fa2a84efeb82efa0d24e4d974). The clustered spectra of the network were annotated by comparing monoisotopic mass to our in-house cyanobacteria metabolite databases according to MS and MS/MS fragmentation pattern matches. Molecular networks were visualized using Cytoscape 3. 6. 0.
Clustering of Planktothrix visualized on the MicroScope platform, Figure S2: Venn diagram of the pan-genomes of the four Planktothrix strains studied using the MICFAM tool computing the SiLiX software available on MicroScope platform, Figure S3: Cluster PNL1 of unknown products, Figure S4: Quality controls of the MS/MS dataset used for the molecular networking, Data S1-S4: List of annotated metabolites for the NIVA CYA 126/8, PCC 10110, PCC 7805, and PCC 7821 strains, respectively.
Acknowledgments: The LABGeM ( CEA/Genoscope  and  CNRS UMR8030 ), the  France Génomique , and  French Bioinformatics Institute  national infrastructures (funded as part of  Investissement d Avenir program  managed by  Agence Nationale pour la Recherche  contracts  ANR-10-INBS-09  and  ANR-11-INBS-0013 ) are acknowledged for support within the MicroScope annotation platform. M. G. thanks the  Institut Pasteur for funding the collection of Pasteur Culture of Cyanobacteria (PCC)  where the PCC strains studied here are available.
Funding: This work was supported by the grant  ANR-15-CE34-0002 , project  CYPHER , to C. B. , M. G. , and B. M. The mass spectra were acquired at the  Plateau technique de Spectrométrie de Masse Bio-organique, UMR 7245 Molécules de Communication et Adaptation des Micro-organismes, Muséum National d'Histoire Naturelle, Paris, France.
: Clustering of Planktothrix visualized on the MicroScope platform, Figure S2: Venn diagram of the pan-genomes of the four Planktothrix strains studied using the MICFAM tool computing the SiLiX software available on MicroScope platform, Figure S3: Cluster PNL1 of unknown products, Figure S4: Quality controls of the MS/MS dataset used for the molecular networking, Data S1-S4: List of annotated metabolites for the NIVA CYA 126/8, PCC 10110, PCC 7805, and PCC 7821 strains, respectively.
Motivation: Modern genomic breeding methods rely heavily on very large amounts of phenotyping and genotyping data, presenting new challenges in effective data management and integration. Recently, the size and complexity of datasets have increased significantly, with the result that data are often stored on multiple systems. As analyses of interest increasingly require aggregation of datasets from diverse sources, data exchange between disparate systems becomes a challenge. Results: To facilitate interoperability among breeding applications, we present the public plant Breeding Application Programming Interface (BrAPI). BrAPI is a standardized web service API specification. The development of BrAPI is a collaborative, community-based initiative involving a growing global community of over a hundred participants representing several dozen institutions and companies.
Introduction Plant breeding is widely recognized as crucial to feeding a rapidly growing population, especially in developing countries  (Flavell, 2017) , (http://www. fao. org/fileadmin/templates/wsfs/docs/expert_ paper/How_to_Feed_the_World_in_2050. pdf). To meet this demand, it is necessary to breed new varieties that maintain high productivity with reduced inputs and are adapted to new eco-agricultural environments resulting from climate change. Plant breeding is a complex undertaking that necessarily integrates many interrelated disciplines, each with their own conventions for data structure and storage, and increasingly large, multi-faceted datasets. To address the challenges in the size and complexity of breeding data, a number of database systems have been designed over the years to solve specific problems.
Although the power and insights that can be gleaned from large datasets increase with a greater volume and diversity of data sources, these separate systems make data integration difficult. Breeders need seamless access to all relevant data, but each system tends to keep its data siloed with ad hoc formats that hinder the ability to exchange, compare and combine data across research teams. To meet these requirements, numerous groups have been working together to create an Application Programming Interface (API) for breeding data  (Ghouila et al. , 2018). An API specification describes the functions and services available in an application which can be accessed in an automated way by a computer program. It describes what services are available, what inputs are allowed, what the structure of the output data will be, and the protocol used to pass data to a service, often on the web.
Results The Breeding API is a practical tool to help solve problems in accessing, exchanging, and integrating data across systems and applications. Given the multidisciplinary nature of plant breeding, there is a broad range in the particulars of the possible data operations that could be considered. Since a complete list of BrAPI related use cases would grow unmanageably large, we decided to focus on a small number of main use cases to design the primary API elements with a view towards reusability in other use cases.
Field phenotyping apps Trials are often performed in fields that have limited internet connectivity, requiring special solutions for collecting phenotypic data. A popular approach is to collect data using handheld devices paired with custom mobile apps  (Rife and Poland, 2014). Information about the field, the plot and accession identifiers needs to be loaded on the device before phenotypic data collection. After completion, collected data need to be uploaded to the database, when internet connectivity is available. Currently available solutions require custom files to be transferred, often involving significant user intervention. However, a simpler method would be to use an API to retrieve and store the data directly from the database.
Genome visualization and analysis Genome-based breeding requires extensive genotyping, which can be helpful to visualize in different ways to aid in breeding decisions. An example of such a tool is Flapjack  (Milne et al. , 2010) , which can display a number of genotypes and run analyses on the data. BrAPI standardizes the interfaces for such tools, hence they can be used with a much wider range of data sources and without the need for special adaptations for each source.
FAIR data portals One of the challenges of big data is identifying datasets of interest and ensuring their long term availability. This can be addressed by building federations of Findable, Accessible, Interoperable and Reusable (FAIR) data repositories  (Wilkinson et al. , 2016). Interfaces such as BrAPI can help such efforts by standardizing access to the data repositories, thereby creating federations. Portals to the federated data can then be deployed to provide general or community specific data access. This increases the visibility of all datasets and therefore reduces the risk of losing isolated datasets over time. The portals should implement simple searches on standard metadata, such as MCPD or MIAPPE  (C ´wiek-Kupczy nska et al. , 2016; Krajewski et al. , 2015; Milne et al. , 2010).
The 'status' array contains a list of objects with the keys 'code' and 'message'. These status objects should be used to provide additional status or log information about the call. If the call was completed successfully and there are no status objects reported, an empty array should be returned. The 'datafiles' array contains a list of URLs to any extra data files generated by the call. For example, this could be images related to the data returned, or large data extract files which contain more data than that returned in the response payload, see Figure  1  for an example. The data payload 'result' contains the specific model object for the given call response. There are three basic patterns that response objects follow. The 'master' pattern is used for returning all the data associated with a single entity.
Authentication A user or system may have to authenticate to a server to access protected data. BrAPI is a data communication specification, so the authentication scheme used to protect that data is considered outside the scope of the BrAPI specification. However, authentication and authorization are important topics to address whenever any kind of data is moved or presented. In order to facilitate communication of data between tools in a standardized way, the BrAPI community has developed a set of best practices using the OAuth2 architecture for implementing proper authentication with any BrAPI enabled tools and databases. In its most basic form, the OAuth2 architecture is a sessionless, token based architecture. OAuth2 allows users to sign in with user credentials they already have, and provides a token.
Versioning All software projects need the ability to evolve to reflect changing requirements, to cover new use cases, and to incorporate user Provides support for sending sample metadata to an external vendor for processing (ie gene sequencing) 5 Note: In each category, there are one or more calls that provide services to support the corresponding domain of plant breeding data management. Fig. 1. An example BrAPI response object. This object shows a generic response with 'metadata', a 'master' result record and a set of 'data' records feedback. A well defined and rigorous versioning scheme is essential for BrAPI to ensure that client and server communication is well defined and the community can keep track of the changes. In BrAPI, there are major versions and minor versions. The major version is currently 'v1', which is reflected in the URL scheme.
Server implementations BrAPI server implementations have been created for a number of popular breeding, genebank and plant genomics databases. A variety of languages and database systems have been used to develop BrAPIcompliant systems. Web frameworks' languages include Drupal/ Tripal (PHP), Catalyst (Perl), Java Spring (Java), NodeJS (JavaScript), Django (Python) whereas databases and data query systems include Postgres, MongoDB, Elasticsearch, HDF5, and MySQL. Many of these systems are open source, so their code may be adapted for other systems with similar implementation parameters. A list of current BrAPI server implementations is given in Table  2.
Client implementations BrAPI client code libraries have been created in several languages, such as Java (https://github. com/imilne/jhi-brapi), the BrAPI R package (https://github. com/CIP-RIU/brapi), Brapi Drupal for PHP, and brapi. js for Javascript (https://github. com/solgenomics/BrAPI-js). A non-exhaustive list of current client applications is given in Table  3. It is possible for service providers to use BrAPI for the implementation of native website features. Some of these features have been implemented as reusable BrAPI compliant widgets, which we call BrAPI Apps or 'BrAPPs' for short. The available BrAPPs are listed on the BrAPI website (https://brapi. org/brapps. php). Figure  2  shows a screenshot of an example BrAPP which performs graphical filtering of phenotypic values.
Test suites and fixtures Comprehensive testing is very important for any software project. Testing tools are available for both BrAPI server implementations and BrAPI enabled clients. For testing BrAPI enabled clients, a BrAPI test server is available at the brapi. org site (https://test-server. brapi. org/brapi/v1). The BrAPI Test Server has a complete implementation of the BrAPI specification and returns a consistent sample set of data. This allows developers of clients to build tests which are appropriate for their tool, while calling a live BrAPI server implementation. The sample data reported by the test server are completely fabricated, and can be updated at any time upon request.
Discussion and Outlook We have defined a first version of a plant breeding API that defines the key calls needed to exchange information about germplasm, phenotypes, experiments, studies, geographic locations, samples, and genetic markers. This opens the door to a rich set of possibilities for building client applications that can work with any BrAPIcompliant data provider. Since 2015, a diverse group of data providers and client application programmers have been building BrAPI into their software. Client applications can rely on the standard interface to enable integration with any BrAPI data source. Building software using standard interfaces is an efficient and sustainable coding practice which enables the reuse of software components. As the public plant breeding software community is relatively small, this will be essential for creating a feature-rich breeding software ecosystem.
A good example of the efficient reuse of components can be seen in the community developed BrAPPs, which are tools that make extensive use of BrAPI and can be widely shared and deployed on different BrAPI enabled systems. This framework is useful to commercial plant breeding software development efforts and we welcome more engagement with that community. We are continuing our efforts and have initiated work on improved versions of the API. We recognize that the types of data relevant to plant breeding are expanding, and BrAPI will continue to evolve in response. One aspect of the API that we would like to enhance is the ability to handle linked data  (Xin et al. , 2018). For example, linking between datasets can rely on standard variables, vocabularies or ontologies, such as the Crop Ontology for Agricultural Data  (Shrestha et al.
, 2012). To fully enable this, current research and developments are based on adding semantic capabilities to BrAPI, especially through the JSON-LD standard, and some support will likely be included in the next major version of BrAPI. It is also important to improve the clarity and understandability of the BrAPI data for both human and machine. Future development will include documentation of the mapping between BrAPI and other common data specifications, such as MIAPPE and MCPD. This will provide a  Furthermore, it will also provide reference concepts and schemas necessary to integrate BrAPI with other initiatives such as bioschemas. org. Beyond breeding applications, BrAPI has also found a niche in gene bank applications, such as MGIS  (Ruas et al. , 2017) , through compatibility with the Multi-Crop Passport Data standard (MCPD).
Although the initial intent was to enable interoperability between breeding management resources, BrAPI can also be used with other types of databases, such as plant genetic resources databases [i. e. MGIS  (Ruas et al. , 2017) ] and plant genome databases (i. e. SGN, MaizeGDB, etc. ). BrAPI offers a way to link genetic resources distributed by gene banks with materials used in breeding programs. Improved integration between gene banks and plant breeding management databases, and genomic databases has the potential to greatly enhance the management and utilization of plant germplasm collections  (Ruas et al. , 2017; Spindel and McCouch, 2016). Efficient and smart use of genetic diversity is a key for continued progress in plant breeding efforts to address the challenges of increased productivity and adaptation  (Halewood et al.
Acknowledgements The BrAPI consortium gratefully acknowledges The  Bill and Melinda Gates Foundation  for providing funds and support for an organizational meeting in Seattle and three hackathons. We would also like to thank the following organizations for hosting  BrAPI Hackathons: GOBii , The  Boyce Thompson Institute, INRA ,  CGIAR Bioversity International , and  CGIAR   Research Program on Roots, Tubers , and Bananas. We acknowledge Elixir (European Infrastructure for bio-informatic, supported by the  ELIXIR- EXCELERATE  project funded by the  European Commission  within the  Research Infrastructures program of Horizon 2020 , grant agreement numbers  676559  ) and  Phenome EMPHASIS. fr( French Phenotyping Infrastructure  funded by the  Infrastructure Biologie SantO ˜'Phenome-FPPN ' supported by the  French National Research Agency ,  ANR-11-INBS-0012 ) for the adoption and support of the BrAPI.
They suggested that, if the scientific community is able to (i) overcome the production of large training datasets, (ii) more precisely identify and evaluate the error rates, (iii) scale up automated approaches, and (iv) detect novel species, it will then be possible to initiate the development of a generic automated species identification system that could open up vistas of new opportunities for theoretical and applied work in biological and related fields. Since the question raised by  Gaston and O'Neill (Gaston and O'Neill, 2004) , automated species identification: why not?, a lot of work has been done on the topic (e. g. (Lee et al, 2004; Cai et al, 2007; Trifa et al, 2008; Towsey et al, 2012; Glotin et al, 2013a,b; Joly et al, 2014b )) and it is still attracting much research today, in particular on deep learning techniques.
Most existing research before LifeCLEF actually considered only a few dozen or up to hundreds of species, often acquired in wellcontrolled environments  (Goëau et al, 2011a; Nilsback and Zisserman, 2008; Kumar et al, 2012). On the other hand, the total number of living species on earth is estimated to be around 10K for birds, 30K for fish, 400K for flowering plants (cf. State of the Worlds Plants 2017 7 ) and more than 1. 2M for invertebrates  (Baillie et al, 2004). To bridge this gap, it is required to boost research on large-scale datasets and real-world scenarios. In order to evaluate the performance of automated identification technologies in a sustainable and repeatable way, the LifeCLEF 8 research platform was created in 2014 as a continuation of the plant identification task  (Goëau et al, 2013b ) that was run within the ImageCLEF lab 9 the three years before  (Goëau et al, 2011a (Goëau et al, , 2012a (Goëau et al, , 2013a)).
LifeCLEF enlarged the evaluated challenge by considering birds and marine animals in addition to plants, and audio and video contents in addition to images. More concretely, the lab is organized around three tasks: PlantCLEF: an image-based plant identification task making use of Pl@ntNet collaborative data, Encyclopedia of Life' data, and Web data BirdCLEF: an audio recordings-based bird identification task making use of Xenocanto collaborative data SeaCLEF: a video and image-based identification task dedicated to sea organisms (making use of submarine videos and aerial pictures). As described in more detail in the following sections, each task is based on big and real-world data and the measured challenges are defined in collaboration with biologists and environmental stakeholders so as to reflect realistic usage scenarios.
We provide in Fig. 1  an overview of the data that was shared along the years within the PlantCLEF challenge. Each year, the data was considerably enriched and the number of species was increased from 71 species in 2011 to 10,000 species in 2017 (illustrated by more than 1 million images). This durable scaling-up was made possible thanks to the close collaboration of LifeCLEF with several important actors in the digital botany domain. First of all, the TelaBotanica social network. This network of expert and amateur botanists is one of the largest in the world (with about 40 thousand members) and is in charge of many citizen science projects relying on the collection of botanical observations by its members. TelaBotanica develops several collaborative tools dedicated to this purpose, in particular IdentiPlante 10  aimed at revising and validating the identification of the observations shared by the network.