dataesr/scientific-paragraphs-categorization huggingface dataset:
Several species in the plot (in gray), have only a few accessory genes, making impossible to get the right parameter estimates, comprising the endosymbionts of our dataset and Chlamydia trachomatis, a pathogen with an obligate intracellular life-style. The 10 species with the largest coefficient are significantly enriched in pathogen species (p = 0. 024) suggesting that pathogens tend to modify their genome content by gaining and removing blocks of genes that are on average smaller than for non-pathogens. To explore this issue more in detail, we investigated the distribution of the size of accessory gene clusters present in only one of the genomes within a species (singleton gene clusters), which are enriched in horizontally transferred genes  [46] [47] [48]. We found a linear distribution in double logarithmic plots (Additional file 5): most of the clusters are therefore small but the probability of large clusters is greater than for a normal distribution with the same mean.
Conserved gene clusters The analysis on stability reveals a few stable gene associations even at large phylogenetic distances. To go further into the problem, one may wonder which are the genes involved in such associations, their function and phylogenetic distribution. Here we summarize an additional output of our framework and we focus on the gene clusters present in Escherichia coli and in at least 50% of the genomes of the inter-species dataset. We set this threshold to highlight gene clusters whose maintenance responds to widespread selective pressures. We obtained 69 gene clusters of 2 to 22 genes; only 8 gene clusters have more than 4 genes. We use the fraction of edges of the gene cluster that are present in the genome as a conservation score (CS), which also provides an indication about partial occurrences (e.
The GSN is encoded as un undirected graph. Once the GSN for all genomes have been built, they can be compared on a pairwise basis (see Figure  1  and Figure  2 ). We call GGN the network for a given comparison, which is obtained by taking the sum of the adjacency matrices of the two GSNs under analysis. By summing all the GSNs from a group it is possible to extract connected components that are present in a given fraction of the genomes i. e. evolutionary conserved gene clusters. To this purpose we use the Dulmage-Mendelsohn decomposition performed by the matlab function dmperm.
Non linear fitting and model comparison Several non linear functions were fitted to the data using the Curve Fitting Tool in Matlab (Mathworks Inc, r2009b) and the Trust-region algorithm. Comparisons of the estimated models were done taking advantage of the Akaike information criterion (AIC), which combines the goodness of fit of a model and a penalty on the number of parameters in a single score. It is moreover appropriate with non-nested models, which is our case. AIC for regression models is defined below: AIC i = N • ln SS i N + 2 • K i , ( 10 ) where N is the total number of observations, SS i is the total sum of squared errors for model i, and K i = 1 + N parameters. In general, the model with the lowest AIC is Core, number of proteins common to all genomes within the species; Acc. , accessory proteins, present in at least 2 genomes; Sing.
, singleton proteins, present in only one genome; Ref. (id), strain used to perform inter-species comparisons and its project identifier in the NCBI Genome database; Abbrev. is the abbreviation used in the figures; N indicates the number of genomes belonging to each species; Pathogen, X are the pathogens, x indicate species comprising both pathogen and non pathogen strains andis for non pathogens. Plant pathogens are also indicated and opp. indicates opportunist pathogens. P. aeruginosa was considered non-pathogen for probability calculations. Taxonomy is the taxonomy of the species. considered the best approximation to the data. To better quantify the plausibility of each model, it is interesting to estimate the Akaike weights of all models. It holds: L i (model i |data) ∝ exp(-0. 5 • i ),  (11)  where i = AIC i -AIC min.
Selection of the dataset The idea behind this analysis is twofold. On one side, we aim at studying the properties of the gene neighborhood network within each species during evolution to get information on genome stability on the short phylogenetic time. This within-species approach allows to study shortterm gene order stability for each genome under analysis; for most of the species, this is a period where no major changes in life-style/ecological niche happened. We can consequently predict some homogeneity of selective pressures acting on genomes belonging to the same species. Our dataset comprises all prokaryotic species for which at least 4 genomes were available when the data were first downloaded (December 2010), for a total of 277 genomes spread over 40 species (see Table  2 ). This resulted in 1286 pairwise intra-species comparisons.
The reason for setting this minimum number of genomes for each species is explained below. On the contrary, when we consider a wider phylogenetic span for the comparisons, the probability that two genomes come from species with highly similar life-styles is reduced, and we can analyze changes in stability that occurred in ancestors of the present species (long-term stability analysis). This dataset concerns 40 genomes (one for each of the species under analysis), and comprises 780 pairwise comparisons, corresponding to 39 new observations for each reference genome. For the purpose of statistical model fitting only, we add a set of comparisons between genomes belonging to 32 genera (see Additional file 1), and the comparisons were made only within each genus. To be noticed that this dataset is only used for statistical model fitting.
Acknowledgements The research leading to these results has received funding from the  European Research Council  under the European Community's  Seventh Framework Programme  ( FP7/2007-2013)  /  ERC  grant agreement Nr [247073]10. The authors wish to thank two anonymous reviewers: their criticisms about previous versions of the manuscript notably improved the paper. Finally, thank to the  BMC Genomics editors  for according us more time to complete the revisions.
However, with regard to A. suspensa, the observations in these trials and many others cited here for other species of Anastrepha, it cannot currently be recommended for use under trapping conditions in the Cooperative Fruit Fly Detection Program in Florida. We believe that with further development lures that can improve both attraction and retention of flies at the trap and possibly an increase in the From: https://bioone. org/journals/Florida-Entomologist on 25 Jun 2022 Terms of Use: https://bioone. org/terms-of-use capture surface, the Phase 4 trap might have the potential to reduce large scale area-wide fruit fly detection costs without greatly sacrificing the probability of detection. To our knowledge this is the first time that the software PRESENCE has been use to evaluate fruit fly detection probabilities.
ACKNOWLEDGMENTS The authors thank  M. Gill  ( USDA-ARS, Miami, Florida ) and  S. Shea  ( FDACS-DPI ) for coordinating the field tests, and  C. Allen ,  D. Long  and  J. Sanchez  ( USDA-ARS, Miami, Florida ) for technical assistance,  Jonathan Crane  ( UF-TREC, Homestead, Florida ) for access to field sites,  Donald Thomas  ( USDA-ARSW, Edinburg, Texas ) and  Roger Vargas  ( USDA-ARS, Hilo, Hawaii ) for reviews of earlier versions of this manuscript. This article reports the results of research only. Mention of a proprietary product does not constitute an endorsement or recommendation by the  USDA.
Background: In recent years, a large amount of "-omics" data have been produced. However, these data are stored in many different species-specific databases that are managed by different institutes and laboratories. Biologists often need to find and assemble data from disparate sources to perform certain analyses. Searching for these data and assembling them is a time-consuming task. The Semantic Web helps to facilitate interoperability across databases. A common approach involves the development of wrapper systems that map a relational database schema onto existing domain ontologies. However, few attempts have been made to automate the creation of such wrappers. Results: We developed a framework, named BioSemantic, for the creation of Semantic Web Services that are applicable to relational biological databases.
This framework makes use of both Semantic Web and Web Services technologies and can be divided into two main parts: (i) the generation and semi-automatic annotation of an RDF view; and (ii) the automatic generation of SPARQL queries and their integration into Semantic Web Services backbones. We have used our framework to integrate genomic data from different plant databases. Conclusions: BioSemantic is a framework that was designed to speed integration of relational databases. We present how it can be used to speed the development of Semantic Web Services for existing relational biological databases. Currently, it creates and annotates RDF views that enable the automatic generation of SPARQL queries. Web Services are also created and deployed automatically, and the semantic annotations of our Web Services are added automatically using SAWSDL attributes.
Background Currently, the large amount of plant high-throughput data that have been produced by different laboratories is distributed across many different crop-specific databases. Plant biologists and breeders often need to access several databases to perform tasks such as locating allelic variants for genetic markers in different crop populations and in a given environment or investigating the consequences of a mutation at the transcriptome, proteome, metabolome and phenome levels. The integration of these disparate databases would make complex analyses easier and could also reveal hidden knowledge  [1, 2].
However, biological data integration faces challenges because of syntactic and semantic heterogeneity. In their reviews, Stein LD  [3]  and Goble C & Stevens R  [4]  provide a fair criticism of the lack of integrated approaches and provide a similar vision for the future, which is that the Semantic Web (SW) can aid in data integration. According to the W3C, "the SW provides a common framework that allows data to be shared and reused across applications, enterprises, and community boundaries" a. The SW currently provides recommendations (RDF  [5] , SPARQL  [6] , OWL  [7] ) for enabling interoperability across databases. Furthermore, major plant databases, such as TAIR  [8] , Gramene  [9] , IRIS  [10] , MaizeGDB  [11]  and GnpIS  [12] , annotate their data using ontology terms to link different datasets and to facilitate queries across multiple databases.
However, none of these approaches are focused on the automation of business logic  [21]. The implementation of new Semantic Web Services (SWS) can be timeconsuming and requires the developer to know how to manipulate SW and WS standards and to have expertise on the database schema. To our knowledge, there are currently no ongoing efforts in the context of the automation of SWS creation that are both specific to relational databases and based only on W3C standards. Our goal is to develop a framework for the creation of SWS for the field of biology by using both SW and WS technologies. Bio-ontologies result from community reflexions in which each term and each relation are explicitly defined for an application domain. Biological data are annotated with terms from these ontologies, which add a semantic component to them.
In BioSemantic, semantics is given by annotation with ontological terms of heterogeneous relational databases schema. These annotations will be used for automatic SWS creation. They will also be used to add semantics to these SWS by annotating their interfaces (input and output). To make the process of WS development as easy as possible, we have developed a semi-automated framework to accelerate the development of SPARQL queries for relational databases. These queries are automatically added to SWS backbones allowing an easier integration of distributed relational databases. This article focuses on biological relational databases, but because of using only SW and WS standards, BioSemantic can potentially be applied to other science fields.
BioSemantic framework overview The overall architecture of the BioSemantic framework is shown in Figure  1. One advantage of this architecture is that its decoupling takes place in two different steps, which might be achieved by different user profiles. In the first step, the data provider must publish the schema of its relational database. First, the local RDF view of the database schema is automatically created for each relational database to be integrated. Then, the RDF view must be manually annotated by experts with terms from existing bio-ontologies. The RDF views, both created and annotated, are stored in an RDF repository. Once the RDF view is available, the second step is the creation of the SWS. This step is uncoupled from the first step and could be realised by a data consumer without any knowledge of the database schema.
The previous semantic annotations of RDF views are used to automatically create SWS containing SPARQL queries and to use the bio-ontological terms as input/output. SWS are then stored in a Semantic Web Services repository, from which they can be easily detected by clients. These clients can use the SWS as wrappers to overstep the heterogeneity of the relational databases. We will detail below the entire process for generating a BioSemantic SWS, which can be divided into two main parts: (i) the generation and semi-automatic annotation of an RDF view (Figure  2 ) and (ii) the automatic generation of the SWS (Figure  3 ).
Relational database-to-RDF mapping The research in the domain of mapping between databases and ontologies is very active and corresponds to various motivations and approaches  [22]. In BioSemantic, we use the mapping as an intermediate layer between the user and the stored data. This layer provides an abstraction of the database and allows the user to query databases without knowledge of the database schema. These characteristics correspond to the motivation known as "data access based on ontology". For that purpose, we found only two tools that strictly use SW standards: Virtuoso  [23]  and D2RQ  [24] [25] [26]. We have chosen D2RQ because this tool is open source, easy to use and all of the needed functionalities are free. In addition, some bioinformatics projects have successfully used D2RQ.
RDF view description The RDF view created by D2RQ can be seen as a mediator of a mediation system. It is used as an interface between the local schema of a database and the global schema defined by bio-ontologies. It is possible to detect all of the heterogeneous RDF views that are annotated with the same ontological term and then retrieve data from corresponding relational databases. The RDF view generated by D2RQ contains the elements of the database schema: entities, attributes, keys (primary, foreign) and metadata, such as the database driver and host. The data contained in the relational  databases are not included in the RDF view. Instances are retrieved directly from the databases. D2RQ API uses metadata from the RDF views to connect to the databases and to retrieve instances from them.
The RDF view is queried with a SPARQL query; then, the D2RQ API transforms this query into an equivalent SQL query. Thus, there is no problem with keeping data up-to-date because the data are not physically exported. In the RDF view, the database schema is represented by a graph. Each node corresponds to an entity or attribute in the database, and each edge defines a relationship between two nodes. In RDF format, namespaces are used to uniquely identify each node. Namespaces provide a prefix for each node name. For example, the map:marker node (Figure  4 ) indicates the "marker" concept from the "map" vocabulary used by D2RQ to uniquely identify one RDF view and to map relational elements to the RDF view.
Automatic semantic enrichment of the RDF view with BioSemantic The BioSemantic API automatically detects specific information related to the relational database schema and translates it into new properties that can be integrated into the RDF view. These metadata are then used for Figure  3  Automatic generation of Semantic Web Services. The Web Services developer selects the bio-ontological terms to be used as input/ output. All of the mapping files, which are stored in the mapping file repository, are automatically parsed to find a path linking the input and output ontological terms. If such a path is found, it is used to create a SPARQL query. The query is integrated into a semantic Web Service that is then registered in a Web Service registry, such as BioCatalogue. Figure  4  Graph-based representation of annotated RDF views.
Each graph is the RDF representation of some part of a relational database. The d2rq:belongsToClassMap property links a column to a table. The d2rq:primaryKey property defines the primary key of a table. The d2rq:property property links a node to a semantic annotation. The columns marker_name, from the table marker, and snp_name, from the table snp, are both annotated with the same term: genomicFeatureDetector from the GCP domain model ontology  [27]. SPARQL query generation. This step can be seen as a semantic enrichment of the RDF view.
Manual annotation with bio-ontological terms The D2RQ language allows elements of the mapping file to be annotated with bio-ontological terms, which can be interpreted as semantic flags. Such flags can be used directly to query the relational database without any prior knowledge of the database schema or can be used to locate corresponding elements across databases (Figure  4 ). The annotation of the RDF view is performed manually by adding triples to the RDF view using a text editor and must be conducted by an expert familiar with both the database and the bio-ontology. In the plant biology domain, some ontologies are implemented in OBO format and do not provide URLs, in contrast to OWL ontologies. For this reason, the terms used to annotate the RDF view can be explained as URIs that do not resolve.
Shortest-path algorithm with conditions We parse the RDF view as though it were a graph, to find the shortest path linking two bio-ontological terms. These terms correspond to those selected as input and output for our WS. We use a shortest-path detection approach based on the Dijkstra algorithm  [30]. We add conditions to the weight path costs according to the properties classified in the previous step. In the weighting, we favour paths that correspond to binary associations. For the shortest paths that correspond to the rdf:subClassOf property (inheritance, aggregation or composition), we aggregate the different paths found. For example, in Figure  5 , the rdf:subClassOf property allows a study to be considered a genotypingStudy or a phenotypingStudy. The data recorded in these two tables are complementary and are non-redundant.
Use case We have created a use case integrating Oryza sativa (rice) data from distributed relational databases: Gramene  [9] , TropGene  [34]  and Ensembl  [35]. Both the Gramene and TropGene databases have QTL data associated with traits, and these traits can be associated with concepts from the Trait Ontology. We wanted to compare the rice QTLs from the two resources, Gramene and TropGene, and to extract related genomic annotations from the Ensembl rice module. We first used BioSemantic to create the SWS. We then used Taverna  [4]  to create a workflow by connecting BioSemantic SWS with external public WS. In this manner, we could verify the compatibility of BioSemantic SWS with standard WSDL WS. To increase the speed of querying over huge tables, we used a local copy of the Markers tables of Gramene; however, our example performed adequately using a remote access to the Gramene public database.
Steps involving SWS creation and using the BioSemantic Web user interface A simple form must be completed to configure database access and to automatically create RDF views for the TropGene and Gramene databases (Figure  7 ). The RDF views can then be downloaded to perform semantic annotations. In our example, we annotated RDF views using one concept from the EDAM ontology  [31]. The elements of the RDF views were annotated with the same ontological concept, known as edam:1093. For readability, we choose to represent this concept by its name edam:sequence_accession in our example. This annotation is added to triples corresponding to themarker`. `name`column of the RDF View of TropGene. The annotation is represented below in bold type. map:marker_name a d2rq:PropertyBridge; d2rq:column "marker.
name"; d2rq:property edam:sequence_accession; d2rq:belongsToClassMap map:marker; An annotation with the same term is added to triples corresponding to themarker`. marker_acc`column of Gramene. The annotation is represented below in bold type. map:marker_marker_acc a d2rq:PropertyBridge; d2rq:column "marker. marker_acc"; d2rq:property edam:sequence_accession; d2rq:belongsToClassMap map:marker; The same ontological term is then used to annotate different database schemas. The BioSemantic Web interface allows users to upload the annotated RDF views to visualise the list of available RDF views in the repository, to download one of the views in order to view/add/modify <xs:element name="method"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="input" nillable="true" type="xs:string" sawsdl:modelReference="http://gcpdomainmodel.
Workflow creation BioSemantic SWS can be obtained directly with their WSDL localisation. In this use case, we chose to compose SWS as a workflow in Taverna. Taverna makes it possible to easily create a workflow, to visualise the progress of the running workflow and to save the workflow for the purpose of sharing it. Our workflow (Figure  10 ) contains 7 BioSemantic SWS (green boxes). Yellow and purple boxes correspond to bricks that transform the inputs/outputs of the SWS and then allow for composition. For a given trait and QTL maximum size, BioSemantic SWS retrieve the Gramene and TropGene accession numbers of the QTLs along with their mapping positions in Oryza sativa. We have created a Beanshell Taverna brick (orange box) to retrieve the Gramene and TropGene QTLs that are mapped in the same genomic region.
Two other bricks allow for the compatibility of the BioSemantic SWS with the Ensembl BioMart WSs. Indeed, we added Ensembl BioMart WS (blue boxes) to retrieve genes that are present in the mapping genomic interval of a given QTL. The yellow and purple boxes are shims that are added in Taverna. The purples boxes allow Taverna to manipulate BioSemantic SWS input. They are created automatically by Taverna. The yellow boxes are XPath expressions that allow Taverna to be compatible with BioSemantic SWS output. All of the yellow boxes are identical, and their creation is fast. However, the presence of these shims does not allow automation of BioSemantic SWS compositions. In brief, our workflow retrieves the following rice information from TropGene, Gramene and Ensembl: -Accession number of the QTLs associated with a given trait, -Pair-based position of the mapping of these QTLs, -All of the genes in the mapping interval of a given QTL, and -QTLs with a common mapping position between TropGene and Gramene.
Available Semantic Web Services We developed other SWS for our own databases, including TropGene and OryGenesDB, a database of functional rice genomics data  [37] , as well as from external databases such as Gramene and SINGER  [38] , a multi-crop germplasm database. We annotated the database schemas with concepts from the Crop Ontology  [39] , the GCP Domain Model  [15] , the Sequence Ontology  [40]  and the EDAM ontology  [31]. Some of these generated WS are available in the BioCatalogue (Figures  11  and 12 ).