dataesr/scientific-paragraphs-categorization huggingface dataset:
66), if compared to VP10/39 (Glide score = -7. 22). However, poses (binding modes) of VP10/12 and VP10/39 are not similar to poses of known ligands of Keap1-DC. This trend was confirmed by MMGBSA rescoring (Table  1 ). On the contrary, curcumin (Glide score = -5. 74) complexed at Keap1-DC alike a crystallized Keap1-DC/ligand complex (PDB:4ZY3)  [46]  (Figure  8(a) ). Docking score differences between VP10/12 and VP10/39 at the Keap1 DC domain did not explain the capability of VP10/39 to induce HO-1. Worthy of note, MMGBSA binding energy was more negative for binding of ligands at the DC domain than binding of ligands at the BTB domain. However, MMGBSA rescoring for docking at DC and BTB cannot be compared, because of significant differences in simulated complex formation: noncovalent binding versus covalent binding.
gov "antioxidant AND diabetic retinopathy") and AMD (clinicaltrial. gov "antioxidant AND age related macular degeneration"). Furthermore, there are clinical trials about improvement of visual function in patients with diabetic retinopathy treated with curcumin supplementation (NCT02984813, NCT01646047). Besides preclinical promising results  [24, 25, 35] , no clinical studies have been reported about either curcumin as a treatment of AMD or CAPE as treatment of both DR and AMD. We hereby hypothesized that a HO-1 inducer with a NOreleasing moiety would be promising for protection of retinal pigmented epithelium against oxidative stress, because NO can also induce HO-1. Both VP10/12 (curcumin-NO-releasing derivative) and VP10/39 (CAPE-NO-releasing derivative) were able to decrease ROS concentration and LDH release.
The main goal of this study was to use a genome-wide single nucleotide polymorphism (SNP) data set to infer the demographic history associated with the recent phenotypic diversification of replicate sympatric dwarf and normal Lake Whitefish species pairs. Using RAD-seq SNP data to document the Joint Allele Frequency Spectrum (JAFS) in each species pair, we specifically test for the role of temporal and genomic variations in the rate of gene flow for each species pair separately, controlling for both effective population size and migration. We then performed historical gene flow analyses among lakes to determine how the different scenarios independently inferred within each lake collectively depict a parsimonious evolutionary scenario of diversification. Finally, we document how the complex interplay between historical contingency, demography, and selection jointly shaped the continuum of divergence among sympatric whitefish species pairs.
7Â10 6 of reads. We also sequenced six European Whitefish (Coregonus lavaretus), a sister species closely related to the North American Lake Whitefish, to provide an outgroup for identifying ancestral and derived alleles at each polymorphic site within the Lake Whitefish. European Whitefish were sampled in Skrukkebukta Lake (Norway, 69 34 0 11. 6 00 N-30 02 0 31. 9 00 E), which also harbors postglacial sympatric whitefish species pairs  (Amundsen et al. 2004; Østbye et al. 2006). RAD libraries were prepared for three individuals from each ecotype population, using the same procedure as for American Lake Whitefish  (Amundsen et al. 2004; Østbye et al. 2006). The C. lavaretus raw sequence data set was filtered using the same criteria as for C. clupeaformis  (Gagnaire, Pavey et al. 2013). After sequence demultiplexing, the reads were trimmed to a length of 80 bp to avoid sequencing errors due to decreasing data quality near the end of reads.
w AIC ¼ e ðÀDAIC i Þ 2 P R i¼1 e ðÀDAIC i Þ 2 : (2) To estimate parameter uncertainty, we used the Godambe information matrix method from @a@i v1. 7. Nonparametric bootstrapping was used to generate 1,000 bootstrapped data sets to estimate confidence intervals (CIs) using the standard-error of maximum likelihood estimates (se). Finally, we converted estimated demographic parameters into biologically meaningful units in order to compare informative parameter values among lakes (e. g. , timing and strength of gene flow). These estimates were only used for indication and comparative purpose, since we were missing crucial information about the per generation mutation rate in Lake Whitefish. We used the optimal multiplicative scaling factor theta between model and data to estimate the ancestral effective population size (N ref ) before split for each lake: N ref ¼ h 4Ll (3) with l being the mutation rate (fixed at 10 À8 mutations per site per generation) and L the effective length of the genome explored by our RAD-Seq experiment and estimated as: L ¼ zy80 x (4) where x is the number of SNPs that were originally detected from y RAD-tags of 80 bp present in the initial data set, and z is the number of SNP retained for @a@i analyses in the lake considered.
Patterns of Shared Ancestry and Admixture among Lakes We also searched for signatures of shared ancestry and gene flow among replicate species pairs to provide a broader understanding of the divergence history in whitefish. The four lake-specific data sets used for demographic inferences were merged together with the Webster Lake data set, added here to get a more thorough understanding of the system as a whole. Only polymorphic loci that were retained after filtering in all five lakes were considered (42,558 SNPs in total, without the outgroup). For each lake, we determined the fraction of private polymorphisms, the fraction of SNPs shared with at least one other lake or shared across all five lakes. We then measured the proportion of SNPs that were shared between species and private to each species within each lake, as well as among lakes.
To visualize the overall genetic structure and relationships among lakes and species, we performed a discriminant analysis of principal components (dAPC) in Adegenet v2. 0. 0  (Jombart et al. 2010). We first imputed missing genotypes within each population using a Random Forest regression approach  (Poland et al. 2012). Imputation was performed using ten iterations with 150 trees using the randomForestSRC v1. 6. 1 package in Stackr v. 0. 1. 5 (Gosselin and Bernatchez 2016)  and imputed subdata sets were subsequently merged to perform the dAPC. Finally, we used TreeMix v1. 12 (Pickrell and Pritchard 2012) to infer historical relationships among populations. This method uses the covariance structure of allele frequencies between populations and a Gaussian approximation for genetic drift to build a maximum likelihood graph relating sampled populations to their common ancestor, taking migration events into account to improve the fit to the inferred tree.
Acknowledgments We would like to thank  Nicolas Bierne ,  Anne-Laure Ferchaud ,  Martin Laporte ,  Anne-Marie Dion-Co  ˆte, and  Charles Perrier  for insightful discussions,  Thierry Gosselin  for stackr inputs, as well as  Anne C. Dalziel  for commenting an earlier version of this manuscript. We are grateful to  Guillaume Co  ˆte,  Melissa L. Evans ,  William Adam , and the staff of  Maine Department of Inland Fisheries and Wildlife (David J. Basley and Jeremiah Wood)  for all of their help sampling whitefish and sharing information about watersheds histories, and to  Kim Praebel  for Coregonus lavaretus RAD-seq data. We are also grateful to  Editor Bill Martin  and  Associate Editor Judith E. Mank  as well as three anonymous reviewers for their constructive inputs, which improved a previous version of this paper.
Biologists and biochemists have at their disposal a number of excellent, publicly available data resources such as UniProt, KEGG, and NCBI Taxonomy, which catalogue biological entities. Despite the usefulness of these resources, they remain fundamentally unconnected. While links may appear between entries across these databases, users are typically only able to follow such links by manual browsing or through specialised workflows. Although many of the resources provide web-service interfaces for computational access, performing federated queries across databases remains a non-trivial but essential activity in interdisciplinary systems and synthetic biology programmes. What is needed are integrated repositories to catalogue both biological entities and-crucially-the relationships between them.
Such a resource should be extensible, such that newly discovered relationships-for example, those between novel, synthetic enzymes and non-natural products-can be added over time. With the introduction of graph databases, the barrier to the rapid generation, extension and querying of such a resource has been lowered considerably. With a particular focus on metabolic engineering as an illustrative application domain, biochem4j, freely available at http://biochem4j. org, is introduced to provide an integrated, queryable database that warehouses chemical, reaction, enzyme and taxonomic data from a range of reliable resources. The biochem4j framework establishes a starting point for the flexible integration and exploitation of an ever-wider range of biological data sources, from public databases to laboratory-specific experimental datasets, for the benefit of systems biologists, biosystems engineers and the wider community of molecular biologists and biological chemists.
Introduction A detailed understanding of metabolism is critical to systems and synthetic biology approaches to biomedicine, drug discovery and development, and metabolic engineering for bioprocessing and industrial biotechnology. While biochem4j has a potentially broad appeal in a range of areas including fundamental physiology, evolution and understanding of pathogenicity, this initial work considers its application towards metabolic engineering. Within this context, a range of tasks, including designing synthetic pathways, collating organism-specific metabolic reconstructions, and interpreting metabolomics data, involves the drawing together of information from existing databases and ontologies. For example, the ChEBI ontology  [1]  catalogues chemicals and their relationships; KEGG provides a compendium of metabolic reactions and catalysing enzymes  [2] ; and NCBI Taxonomy describes the tree of life, providing an indication of how organisms (and therefore their enzymes) are related from an evolutionary perspective  [3].
However, as yet there are few integrated data resources that covers all of these aspects  [4] , despite efforts having been made to incorporate such federated resources into workflow systems  [5, 6]. Consequently making queries across these databases remains a major challenge. Introduced here, biochem4j enables complex queries by linking numerous well-known and widely used chemical, biochemical and biology resources within a novel graph database. This implementation of a graph database not only provides a versatile resource for systems biologists and biosystems engineers, but also establishes the general concepts and techniques that will allow others to expand and modify the resource to meet their own requirements in a flexible manner. biochem4j offers an initial framework into which a wide variety of other data sources, including additional public databases and in-house experimental data, can now be incorporated.
biochem4j is built on the freely available graph database, neo4j (Neo Technology, Inc. , Malmo ¨, Sweden; https://neo4j. com/) and is structured as follows. Organisms are represented and organised into their taxonomical tree based on information from the NCBI Taxonomy database. The organisms are linked to enzymes encoded in their genomes based on data extracted from UniProt  [7]. Enzymes are linked to reactions that they catalyse using data from KEGG and Rhea  [8]. Reaction definitions are extracted from MNXref  [9] , providing links to chemicals that participate in each reaction. Chemicals themselves are related to one another through data extracted from the ChEBI ontology. Specific entities of these data types (Taxonomy, Enzyme, Reaction, Chemical) are represented as nodes in the network and each node in the network contains metadata describing the entity.
Thus, Chemicals contain terms such as molecular mass, and formula; Reactions contain Enzyme Classification (EC) numbers; enzymes hold UniProt IDs; and Organisms contain synonyms. (Full details are given in Table  1. ) Nodes contain references to a number of external data resources, facilitating identifier In biochem4j, nodes have a label (e. g. Chemical) and a number of associated properties, which can be used for both querying and in information retrieval. Not all nodes of a given label contain all of the available associated properties. For example, a generic chemical class such as "fatty acid" will not have a molecular mass, or a given reaction may not be represented in all source databases and therefore may not have a specific reference to Reactome. https://doi. org/10. 1371/journal. pone.
0179130. t001 mapping across resources. These nodes are connected through defined relationships. For example, Organisms contain expresses relationships towards Enzymes, and Reactions contain has_reactant relationships towards a Chemical. (Full details of all relationships are given in Table  2. ) biochem4j therefore provides an integrated graph that allows complex queries to be performed across all of these linked nodes, along with a clear, interactive, visual representation of the network. (See Query 1 and Fig 1, below. ) A key feature of graph databases is their flexible architecture, which supports customisation, extension and further development  [10]. This distinguishes them from the relational databases that are currently routinely used to store and query biological databases  [11]. As system requirements develop and additional data sources become available, it is trivial to add new data types and relationships to extend the graph database.
The addition of these new types has no effect on the existing structure of the resource, and will not affect existing operations. In the context of biological databases such as biochem4j, this might mean, for example, that a graph database initially designed to store metabolic reactions could later easily be extended to also hold (and query) experimental postgenomic molecular profiling data without a wholesale redesign of the underlying schema. Similarly, it would also be trivial to extend the scope of the database to include encoding genome sequences, kinetic parameters and structural information linked to the enzyme data. The use of graph databases in bio/cheminformatics is a recent development. Examples of existing work include a study into the use of graph databases and their application to substructure searching in cheminformatics  [12] , in the collation and analysis of individual biochemical pathways  [13, 14] , and in the storage of a genome scale model of human metabolism  [15].
The Such relationships can be considered to be "triples" in an analogous fashion to Resource Description Framework (RDF) representations. For example, "triples" exist from Reactions to Enzymes in the fashion "Reaction-catalysed_by-Enzyme". Note that these relationships are all directional from the From label to the To label. 1 Relationships between Reactions and Chemicals are either of the type "has_reactant" or "has_cofactor". Cofactors are considered to be either low molecular mass compounds (less than 44 Da) or pairs of metabolites that are frequently occurring in the network (e. g. ATP and ADP). Frequency of occurance is calculated at the time of database loading (see source code: https://github. com/synbiochem/biochem4j). ease with which disparate resources can be combined in a single integrated graph database means that it becomes considerably easier to perform queries and detect patterns across the whole range of available information.
Results biochem4j links together data from a range of primary resources to provide a repository holding data on 1,544,257 named organisms, 2,457,504 enzymes, 36,765 reactions and 256,230 chemical species. These nodes are connected by 23,298,434 relationships, such as "Organism A expresses Enzyme X" or "Reaction Y has_cofactor Chemical Z". Types of nodes and their properties are listed in Table  1. Relationships and their properties are available in Table  2. Details on the number of nodes and relationships are given in Table  3. The database can be updated through running a simple script, which is publicly available (see Methods). Like all neo4j databases, biochem4j can be queried through use of the CYPHER query language. It should be noted that this language is not immediately intuitive for novice users; we would not envisage that future applications built upon the biochem4j framework would require biologists to construct their queries directly in CYPHER.
Instead, domain-and taskspecific user interfaces would facilitate the interaction with the database, just as is the case for more conventional relational databases. Due to its linking of taxonomical, enzyme, metabolic reaction and chemical data, a range of queries may be raised across all of these data types simultaneously. Concrete examples are given in Results, but more general queries that may be posed include: • What are the known biochemical pathways from metabolite X to metabolite Y? • What enzymes would be required to transform metabolite X to metabolite Y? • Which organisms can perform pathway X? • Which chemical transformations can metabolite X undergo? The following query example illustrates the structure of the database, showing how chemical, reaction, enzyme and taxonomy data are related.
The query asks, 'does the reaction ATP:D-glucose 6-phosphotransferase (KEGG reaction R00299) occur in Escherichia coli K-12 (NCBI Taxonomy 83333)?', essentially determining whether a link exists between the reaction node, an enzyme node, and the E. coli K-12 node in the database. Additionally, to demonstrate to connectivity between node types within the database, chemicals involved in the reaction, and the parent node of E. coli K-12 in the NCBI Taxonomy tree, are also returned. Note that implementing such a query across the individual databases used to populate biochem4j would be almost impossible using manual browsing-and would be computationally tedious even in an integrated relational database holding the same information. The results of the query are shown in Fig  1. A further useful feature of biochem4j is that the user interface, as shown in Fig  1 , is interactive.
Nodes can be expanded by clicking, so one may click on a Chemical node to see in which other Reactions the chemical participates, thus allowing the user to "walk" along the metabolic network in a stepwise fashion. Similarly, by clicking on a Reaction node, a synthetic biologist would quickly be able to determine how many homologous enzymes catalyse the reaction, and from which organisms do they originate. Due to the broad scope of the CYPHER query language, far more complex queries can be written. Moreover, such queries can readily span multiple domains. The following examples of more complex queries, which integrate chemical, biochemical and taxonomical data, illustrate the power and flexibility of this approach, compared to conventional manual browsing of individual data sources. To take an example from metabolic engineering, biochem4j can be used to perform a preliminary investigation into chemical space.
Discussion The above examples give a flavour of potential queries that can be submitted to the biochem4j system, although the full range of queries is limited only by the user's imagination. CYPHER is an extremely powerful (and continually developing) query language and as such, technically interested readers are encouraged to consult the CYPHER user guide for further details on the syntax and range of potential queries (https://neo4j. com/developer/cypher-query-language/). It is acknowledged that querying biochem4j directly with CYPHER may prove challenging for many biologists. However, the structure of the data model and the ease of development via the supplied neo4j web service should enable bioinformaticians to support wet-lab biologists through the development of specialised applications to support their desired queries.
A key difference between graph databases such as neo4j and RDF triple stores are in the way in which data is held internally. In RDF triple stores, statements (subject-predicate-object) typically specify objects that are primitives, such as integers, strings or floats. <http://biochem4j. org/reaction/1>: has_name "R00299" <http://biochem4j. org/reaction/1>: is_catalysed_by <http://biochem4j. org/enzyme/1> <http://biochem4j. org/enzyme/1>: has_name "Glucokinase" Whereas the neo4j equivalent, a single representation links two nodes that contain properties: (a:Reaction {name: "R00299"})-[:catalysed_by]->(b:Enzyme {name: "Glucokinase"}) An RDF representation provides a collection of atomic statements, while graph databases specify relationships between more richly defined nodes, each of which being an individual database object.
Such a representation increases ease of querying, an example of which is provided in S3 Appendix. It is clear that a resource incorporating chemical, reaction, enzyme and taxonomic data will have applications in individual research fields that utilise these data types and the user may choose to query just one aspect of the resource. For example, metabolomics experts might consider chemical space, while evolutionary biologists might only have interest in the links between taxonomy and enzymes, ignoring the chemistry aspects of the system entirely. The text mining community may use the database as a source of synonyms for chemicals and enzymes. However, many fields, especially those based around metabolism, metabolic systems biology and industrial biotechnology, may wish to utilise all aspects of the resource simultaneously.
Numerous queries, and applications, can therefore be built on top of biochem4j, primarily utilising the computer-readable web service interface that is provided by neo4j. The simplicity of both querying and populating such graph database systems means that the user is free to extend the current system in whichever direction they wish. There is no limit to the additional node types and relationships that can be added to the system. Thus, extensibility into more bespoke data management solutions, including perhaps the storage of experimental data, is already supported. From a synthetic biology perspective, a key consideration of biochem4j is this ability to grow over time. Current experimental approaches, not least the application of directed evolution to enzymes and exploitation of enzyme promiscuity, mean that such a repository needs to be able to handle the addition of novel enzymes and chemicals and the relationships between them.
While existing enzymology resources such as BRENDA  [34] , ExplorEnz  [35]  and SABIO-RK  [36]  provide excellent coverage of wild type enzymology data (including results from a limited number of mutagenesis studies), there is still a requirement for an extensible repository that can handle the Big Data challenge that large-scale directed evolution studies provides. biochem4j in its current release primarily covers known, existing metabolic pathways, enzymes and naturally occurring metabolites. However, the structure is such that its extension into a more comprehensive synthetic biology repository, including large-scale enzyme variants libraries and their ability to produce non-naturally occurring metabolites, would be trivial to implement. Further future directions of this work could also utilise the database as a source of mathematical models, with the ability to query for pathways and export results in standard modelling formats such as Systems Biology Markup Language (SBML)  [37].