dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction The corpus of bioinformatics resources is huge and expanding rapidly. Life scientists face a growing challenge in selecting tools that fit the desired purpose, especially cross-domain researchers who may be unfamiliar with expert terminology. To address this, the European Infrastructure for Biological Information (ELIXIR)  [1]  is supporting a systematic approach  [2]  towards a com-Downloaded from https://academic. oup. com/bib/advance-article-abstract/doi/10. 1093/bib/bbz075/5560007 by guest on 04 June 2020  Utility for text mining and mapping to EDAM ontology biit. cs. ut. ee/edammap/github. com/ edamontology/edammap prehensive registry of tools and databases for all domains of bioinformatics, provided under a single portal (https://bio. tools). bio. tools aims to provide, by a community-driven curation effort, concise and consistent metadata that are sufficient to inform end users about the main tool functionalities, to find and compare relevant software and to follow links where resources may be downloaded or used.
A variety of platforms, often with overlapping scope but serving different audiences, aggregate or maintain tool and database information. The coordination and technical integration of bio. tools with these resources are at various levels of maturity. For several major institutional collections such as the ExPASy portal to bioinformatics tools and databases  [3] , tools developed by the IFB platform (https://www. france-bioinformatique. fr/ en/services/tools) and EBI services  [4] , there is a common curation effort coordinated by ELIXIR. Collaborations around the sharing of data and expertise include also community projects such as the ms-utils. org Wiki (https://msutils. org) of software for analysis of mass spectrometry data, DebianMed  [5]  packages for medicine, pre-clinical research and life sciences and the Bioimage Informatics Search Engine (http://biii.
eu/) for image analysis software. In the case of database metadata, there is scope for bio. tools and portals such as Identifiers. org [6]  (an identifier resolution service for data collections) and FAIRSharing  [7]  (a portal for databases in context of standards and policies) to integrate their curation efforts, for example by co-maintaining a common set of descriptors in a public repository such as GitHub. In contrast, there are commercial portals (e. g. [8] ) that aim to provide tailored solutions to paying customers. The bio. tools initiative aims to foster individual tool developers, online service providers and scientific communities to share and curate their software productions to a common standard. To these ends, a rigorous foundation for software cataloguing (Figure  1 , Tables  1  and 2 ) is being laid: biotoolsSchema-a general purpose description model for bioinformatics resourcesdefines a comprehensive list of common software attributes.
It provides a rigorous structure and syntax allowing for software metadata validation. biotoolsSchema uses the EDAM ontology  [9] , which contains terms and synonyms for prevalent bioinformatics concepts, including types of data and data identifiers, data formats, operations and topics. It provides rigorous semantics for description of scientific aspects. An emerging Tool Information Standard, based on biotoolsSchema and EDAM, describes what attributes should be provided at various tiers of detail and quality. The standard refers to bio. tools Curation Guidelines, which specify how tool information should be specified: stylistic or other aspects that cannot conveniently be expressed in a formal schema or ontology. While a technical foundation is doubtlessly required, the problem of curation remains fundamentally social; a diligent manual effort is required to ensure the corpus of resource Downloaded from https://academic.
oup. com/bib/advance-article-abstract/doi/10. 1093/bib/bbz075/5560007 by guest on 04 June 2020 We describe here the practical means by which scientific communities, including individual developers and projects, through major service providers and research infrastructures, can describe their own software and database productions and share these via bio. tools. The paper is structured as follows. We begin with some general considerations and a summary of sources of resource information. We then summarize biotoolsSchema and EDAM in the context of the Tool Information Standard and key considerations such as the annotation of tool function. Various methods and utilities for resource annotation are presented, as works in progress, with a note on how these can be applied to the description of one or a few tools or to larger collections.
Resource descriptors biotoolsSchema defines the data model used to describe the resources included in bio. tools. It defines general, scientific and technical attributes for resource description and includes a simplified model of tool function that makes use of the EDAM ontology for the scientific description of tool inputs, output and operations. These aspects are summarized below. biotoolsSchema biotoolsSchema defines some 50 general software attributes such as name, description and homepage URL. It provides, through regular expression patterns and 16 controlled vocabularies, a precise syntax and nomenclature for the general characterization of tools, including: (i) Tool type-the type of application software, e. g. 'Commandline tool' (ii) Language-name of programming language the software source code was written in, e.
g. 'C' (iii) Operating system-the operating system supported by a downloadable software package, e. g. 'Linux' (iv) Accessibility-whether the software is freely available for use, e. g. 'Open access' (v) License-software or data usage license, e. g. 'GPL-3. 0' (vi) Download type-type of download that is linked to, e. g. 'Source code' (vii) Link type-the type of data, information or system that is obtained when the link is resolved, e. g. 'Helpdesk' (viii) Documentation type-type of documentation that is linked to, e. g. 'API documentation' (ix) Version-Version information (typically a version number) of the software applicable to the bio. tools entry, e. g. '1. 0' biotoolsSchema is supported by the bio. tools API and UI for registration purposes (see Curation tooling below). It supports metadata specification in a choice of serialization formats (XML and JSON currently) and can (through widely and freely available tools) be used to validate tool descriptions prior to registration in bio.
Model of tool function bio. tools uses a model of tool function (Figure  2 ) defined within biotoolsSchema. A tool can have one or more basic functions (modes of operation), each function performing one or more specific operations. In turn, an operation may have one or more primary inputs and outputs, each of a defined type of data and listing supported format(s). bio. tools does not mandate that all of this information is specified; however, careful consideration of the level of required detail is recommended before annotation commences. In the simple use case of describing tools to make them more discoverable, it may suffice to simply annotate the major operations performed by the tool. In the more challenging case of tool interoperability, explicit annotation of data types and formats may be required.
the expected inputs and outputs of an operation as stated in EDAM). Importantly, the browser provides a live display of the number of annotated resources and links to various databases that use this term, including bio. tools, IFB's BioSphere cloud (https://biosphere. france-bioinformatique. fr/) and TeSS  [12]. Furthermore, any user may directly request a modification on an existing concept or the addition of a new concept, via a form that gathers all necessary information and directly formats the suggestion as an issue ready to be submitted by the user to EDAM GitHub issue tracker. EDAM Browser has a plug-in framework, allowing links Downloaded from https://academic. oup. com/bib/advance-article-abstract/doi/10. 1093/bib/bbz075/5560007 by guest on 04 June 2020 to new databases with usage counts to be easily set up.
The resource name and at least one source of information are mandatory. Several parameters can be adjusted, enabling users to find settings that are most appropriate for the information they have in hand. By default, EDAMmap outputs three suggestions for each of the EDAM Topic and Operation branches, but this can be adjusted, along with the parameters of the mapping algorithm and weights of different information sources. The command line version requires information sources to be specified in a CSV file and can output suggestions for many resources at a time. Accurate annotation, of course, relies heavily on expert domain knowledge, and EDAMmap is intended to support but cannot replace the curator. Several other utilities are under active development (see http://github. com/bio-tools/) and promise to improve the curation process and reuse of bio.
tools data. We highlight a few here to encourage participation in these open projects: (i) edamToolAnnotator (https://github. com/bio-tools/ edamToolAnnotator) is a utility for annotating a tool using EDAM terms. It will eventually replace the corresponding functionality in the bio. tools registration interface. (ii) bio. tools Sum (https://github. com/bio-tools/biotoolssum) is a client-side web application for rendering reports on local websites of tool collections from bio. tools. A working example customized for tools and services from the ELIXIR Czech node is available. The utility can be customized for use by other sites and communities. (iii) ReGaTE  [13]  (https://github. com/C3BI-pasteur-fr/ReGaTE) is a command line utility that facilitates the registration of the tools installed on any given Galaxy portal in bio.
tools. As a future work we will improve the method, to enable the linking of multiple servers providing a given tool as Galaxy-based services, to a single bio. tools entry. (iv) ToolDog  [14]  (https://github. com/bio-tools/ToolDog) is a utility that uses bio. tools to generate tool descriptions for use in workbench environments including Galaxy  [15]  and Common Workflow Language (https://www. commonwl. org/).
Curation process The curation process should be tailored to the specific requirements, expertise and capacity of the community in question, so it is impossible to prescribe a process that works for everyone. Curation can involve editing existing bio. tools entries as well as creating new ones. A few broad pointers follow. (i) Enumerate commonly used software and databases. A comprehensive list of key resources should be compiled including tools already in bio. tools, specialized registries and Wikis or lists of tools from the Web. This can be augmented by searches of the Web and the scientific literature. The minimum information requirement (tool The above process should work in general but should be optimized depending upon specific circumstances around the community and existing coverage in EDAM and bio.
Information and instructions for new contributors are available online (Table  2 ) for bio. tools and EDAM and include details of mailing lists, how to make suggestions and requests, tasks and feature management, forthcoming meetings and events and so on. Direct assistance with bio. tools is available by emailing registry-support@elixir-dk. org. The preferred option for communication, and especially for bug reports and suggestions, is GitHub (http://github. com/bio-tools/ biotoolsregistry/). Downloaded from https://academic. oup. com/bib/advance-article-abstract/doi/10. 1093/bib/bbz075/5560007 by guest on 04 June 2020.
Discussion We have summarized, as a work in progress, the means by which software and databases can be described and shared via bio. tools, putting this in context of the various open projects and community-driven initiatives that are being fostered by the ELIXIR infrastructure. Such efforts provide the best hope for the sustainable provision and maintenance of high-quality software information in the long term, required for various contexts and use cases. Beyond merely improving the findability of tools and the dissemination of basic information, the data have exciting applications, for example, in the automated construction and evaluation of alternative bioinformatics pipelines  [16, 17]. Such applications are only possible if carefully assigned functional annotation is available. To both ends, much work remains to be done and will include production of 'gold standard' tool descriptions for specific communities, provision of the bio.
tools biotools. readthedocs. io/en/latest/contributors_guide. html biotoolsSchema docs Documentation for the biotoolsSchema resource description model biotoolsschema. readthedocs. io EDAM docs Documentation for the EDAM ontology edamontologydocs. readthedocs. io EDAM-getting involved How to get involved with EDAM, including guidelines on how to request additions and changes edamontologydocs. readthedocs. io/en/latest/contributors_guide. html#requests EDAM requests Request additions and other changes to EDAM via GitHub (using documented issue templates or free-form requests) github. com/edamontology/edamontology/issues descriptions is reasonably comprehensive and is kept up to date with new tools or changes to existing ones. The most challenging part, especially given the complexity of modern software and scientific disciplines that constantly evolve, is providing the practical annotation of tool scientific function.
, 2017; Dlugosch, Anderson, Braasch, Cang, & Gillette, 2015; Lavergne & Molofsky, 2007; Lawson Handley et al. , 2011; Parker, Rodriguez, & Loik, 2003; Peischl & Excoffier, 2015; Prentis, Wilson, Dormontt, Richardson, & Lowe, 2008; Rius & Darling, 2014). However, there is evidence that not all invasive species experience the negative effects of reduced genetic diversity when initial founder populations are large  (Holle & Simberloff, 2005; Roman & Darling, 2007)  or when reproductive assurance is provided by selffertility  (Daehler, 1998; Schoen et al. , 1996). Varied scenarios like these may explain why lag phases range from nearly no delay to over 300 years  (Crooks & Soulé, 1999). For example, 197 of 257 datasets on invasive species in the Midwest region of the United States exhibited clear lags that ranged from 3 to 140 years while the remaining species showed no sign of a lag phase during the invasion process  (Larkin, 2012).
, 2009; Li et al. , 2015; Marushia et al. , 2012; Marushia, Cadotte, & Holt, 2010; VanTassel et al. , 2014; Winkler, Gremer, Chapin, Kao, & Huxman, 2018) , no research has been conducted to examine the genetic structure of this invasive. Identifying introduction sites and understanding how the species has, and is, spreading via population genomics is a critical first step to elucidating the mechanisms by which species invasions can rapidly occur over large distances. In this study, we use genotyping by sequencing to generate genome-wide polymorphism data from across the invaded range of Sahara mustard in the western United States. We used these data along with historical distribution records to answer three questions: What is the current population structure of the species throughout its invaded range? What does population structure imply about the number of introductions and their locations? Has the geography and ecology of the western United States shaped the species distribution? Given anecdotal evidence and invasion studies of other species, we expected distribution records to reveal a lag phase as Sahara mustard established and spread in the United States.
| Historical range expansion We utilized distribution and locality records from herbaria to examine the geographic spread of Sahara mustard in North America through time. We realize these data often provide an incomplete picture of a species range perhaps due to uneven collection efforts that do not accurately represent invasion patterns  (Williamson, 2006). Nevertheless, distribution records can provide insights into invasion patterns and can be considered a conservative underestimate of range expansion  (Crawford & Hoagland, 2009; Delisle, Lavoie, Jean, & Lachance, 2003). We obtained 2,834 records with collection dates and spatial data from three online databases: the Consortium of California Herbaria (http://ucjeps. berke ley. edu/ conso rtium/ ), the Global Biodiversity Information Facility (http:// www.
gbif. org), and the Southwest Environmental Information Network (http//:swbiodiversity. org/seinet/index. php). We also included observation data from our field collections, bringing our total number of localities to 2,915. We estimated the spread of Sahara mustard populations using distribution record locality data by counting the number of spatial units that the species occupied across time. Spatial units were delimited by rounding geographic degrees to the nearest hundredth. Thus, records were classed into ca. 1 km 2 units across the invaded range. We created accumulation curves of the number of spatial units occupied by Sahara mustard per year. Ranges are expected to expand exponentially, but lag phases can alter this curve  (Crawford & Hoagland, 2009; Crooks, 2005). As such, we tested for a lag phase by examining fit of a linear regression on log 10 transformed cumulative range expansion, estimated by herbaria records, while acknowledging that these rates are likely conservative underestimates given the inherent biases often found in herbaria records  (Delisle et al.
, 2015). The remaining sequences were then mapped to a reference created using abundant reads across the combined set of samples using the program BBmap v. 35. 40 (http://sourc eforge. net/proje cts/bbmap ; sensu  Russello et al. , 2015). A total of 16 individuals were removed from the final dataset due to >75% missing data. In total, 1,525 SNPs were identified across the 744 sequenced individuals. We took 1,000 reads randomly from each sample for comparison to known sequences in the NCBI database via BLAST (https ://blast. ncbi. nlm. nih. gov/Blast. cgi) to test for contamination from species other than Sahara mustard. No plausible contamination was detected in the tested reads.
We visualized mean membership of sample sites using the LEA R package  (Frichot & François, 2015). We used the mean membership values from the ten TESS runs of the optimal k value to visualize admixture at each site by overlaying results onto a map of the sampling range. As a compliment to TESS analyses, we visualized the population structure of sequenced individuals using a principal component analysis (PCA) that constructs population differentiation relationships  (François et al. , 2010; Gross, Hosoya, & Queloz, 2014; Ma & Amos, 2012). We then calculated the number of overall and per-cluster rare variants (minor allele frequency <10%) to identify the most likely origins of clusters identified by TESS  (Cubry, Vigouroux, & François, 2017). To accomplish this, we interpolated the density of rare variants on a map of the invaded area using a kriging approach without trend surface in the fields R package  (Nychka, Furrer, & Sain, 2017)  in order to estimate likely ancestral regions of Sahara mustard in the United States  (Alvarado-Serrano & Hickerson, 2018; Cubry et al.
| Population structure We gathered 744 plants from 52 locations and identified 1,525 SNPs that we analyzed with the program TESS, in order to identify potential population structure. TESS analyses revealed population structure across the invaded range of Sahara mustard, with three genotypic clusters (Figures  3a  and S1 ). Cluster 1 included plants from across most of the species invaded range; Cluster 2 was focused on Palm Springs in the Coachella Valley but also included isolates from Coachella, CA, Parker, AZ, and Roosevelt, AZ; Cluster 3 was limited to Nipomo, CA. TESS also identified apparent admixture occurring between Clusters 1 and 2. Individuals from Palm Springs, CA had the highest probability of assignment to Cluster 2, but the Coachella, CA, Parker, AZ, and Roosevelt, AZ sites also had some significant probability of assignment to this cluster (Figure  3a ).
I G U R E 5 Density of rare variants indicating introduction sites in the invaded range of Sahara mustard (Brassica tournefortii). (a) Complete dataset highlighting Nipomo, CA as the most recent introduction site, with a decrease in rare variant density with distance from Nipomo (inset); (b) excluding the Nipomo, CA variants reveals Palm Springs in the Coachella Valley of California as the most likely origin for Cluster 2, with a decrease in rare variant density with distance from Palm Springs, CA (inset); (c) excluding all but the largest population (Cluster 1) highlights Malibu, CA as the most likely introduction point, with rare variant density generally decreasing with distance from Malibu (inset).
This research was supported by the Tubb Canyon Desert Conservancy, the Robert Lee Graduate Student Research Grant through the Joshua Tree National Park Association, the Howie Wier Memorial Conservation Grant through the Anza-Borrego Foundation, the Forrest Shreve Student Research Fund through the Ecological Society of America, the Mildred E. Mathias Graduate Student Research Grant through the UC Natural Reserve System, the Mayhew Graduate Research Award through the Boyd Deep Canyon Desert Research Center, a Graduate Assistance in Areas of National Need Research Grant (GAANN), UCI's Department of Ecology & Evolutionary Biology, the UCI Data Science Initiative at the University of California, Irvine, and the Victor and Virginia Voth Family Trust. Plant material was collected under the following permits from the National Park Service: DEVA-2015-SCI-0015,.
F I G U R E 5 Density of rare variants indicating introduction sites in the invaded range of Sahara mustard (Brassica tournefortii). (a) Complete dataset highlighting Nipomo, CA as the most recent introduction site, with a decrease in rare variant density with distance from Nipomo (inset); (b) excluding the Nipomo, CA variants reveals Palm Springs in the Coachella Valley of California as the most likely origin for Cluster 2, with a decrease in rare variant density with distance from Palm Springs, CA (inset); (c) excluding all but the largest population (Cluster 1) highlights Malibu, CA as the most likely introduction point, with rare variant density generally decreasing with distance from Malibu (inset).
Introduction Currently, the activities of universities, researchers, the results of their work are widely disseminated on the Internet. Specialized and transdisciplinary databases such as Scopus or Web of Science allow the exploitation and processing of these results. Locally and for research institutes, the management of their activity involves the use of a Current Research Information System (CRIS) or Research Information System (RIS). CRIS as Research Intelligence is a central database or federated information system that can be used to collect, manage and provide information on research activities and research results. The relevance of such a system is to be able to process a large volume and variety of data, to record thousands of daily interactions and to make relevant segmentation based on factual data, like projects, publications, patents, awards etc.
(Azeroual et al. 2018; Azeroual & Schöpfel, 2019). It is powered by different data sources from users. The latter after authentication, have access to the system via several interfaces and can enter their data or constantly update the database. It will be solicited by complex decision requests. The sustainability of information systems is a permanent challenge that must be addressed, because of the risk of inherent and intrinsic problems  (Leymann, 2009). In this context, data security appears to be a vital demand because of the challenges it presents and the issues it implies. This security request materializes on several operative levels of the treatment and circulation of information  (Mell & Grance, 2011). In the case of CRIS, university administrations and researchers attach great importance to the quality and security of their data  (Azeroual & Abuosba, 2017).