dataesr/scientific-paragraphs-categorization huggingface dataset:
, 2020). Alongside RDF, labeled-property graph (LPG) databases have emerged, currently led by Neo4j, which are fundamentally designed to improve graph traversal by directly storing on disk all existing edges between nodes. A benchmark from  Khayatbashi et al. (2022)  comparing RDF triple-stores and LPG databases with twelve queries shows that Neo4j is in fact more efficient to traverse multiple layers of data. Neo4j databases offer high flexibility by adding key-value properties to nodes and edges to effectively compact information, consequently making the modeling easier to read and to incrementally improve  (Donkers et al. , 2020; Neo4j, 2023b). Considering these assets, Neo4j databases were found advantageous to manage dense networks of information required for systems biology. The Reactome database  (Fabregat et al.
, 2018)  and its plant counterpart Plant Reactome  (Naithani et al. , 2019)  have already switched from an RDBMS database to a Neo4j database, since metabolic pathways are intrinsically connected as a graph structure. In fact, using a graph database dropped the average query time of Reactome by 93 %  (Fabregat et al. , 2018). While a graph is intuitive when representing a biological pathway, the value of such modeling extends to many applications, including translational research. For instance, orthologous relationships across genes required for translational research, could be modeled in a Neo4j database with an "IS_ORTHOLOGOUS_TO" relationship between the two "Gene" nodes. Information regarding the gene identifier or annotation could be stored as internal node properties, available for querying.
As the system is adaptable, new layers of data can successively be added and articulated. Omics Database Generator (ODG) is the first LPG designed for translational research as defined by  Guhlin et al. (2017). ODG is a Neo4j graph-database, developed primarily for annotation transfer to non-model species of bacteria and plants. The structure of ODG has been made available for researchers to import their own data. Indeed, the comparison of newly generated data with existing data can confirm hypotheses or help to generate new ones. This is especially useful when datasets do not yield results supporting the initial research hypothesis, end up being set aside and remain unpublished  (Raciti et al. , 2018). It is therefore crucial to use as many available and high-quality datasets as possible, whether published or unpublished, as valuable sources of knowledge.
(faba bean) are examples of grain legumes that produce protein-rich seeds and play a key role in sustainable cropping systems  (Guiguitant et al. , 2020; Rubiales et al. , 2021; Semba et al. , 2021). Because of their large genomes, sometimes up to 30 times larger than the genome of the model legume M. truncatula  (Jayakodi et al. , 2023) , the creation of -omics data on these species has lagged behind. In addition, data on a given species were mostly produced by the research community in the country of production, as the dominant production areas are sometimes different. Several databases have been developed that attempt to inventory the diversity of published datasets and provide tools to analyse and visualize them, including Soybase  (Grant et al. , 2010) , the Pulse Crop Database  (Humann et al.
, 2019) , KnowPulse  (Sanderson et al. , 2019)  and the Legume Information System  (Berendzen et al. , 2021). However, there is still a lack of options to link multi-species datasets together for further study. LegumeIP is a relational database, initially created to transfer knowledge from model to crop legume species, and recently transformed into an integrative platform to support translational research, hosting homology, gene annotation and expression data for 17 legume species in its latest version  (Li et al. , 2012 (Li et al. , , 2016;; Dai et al. , 2021). Some recently sequenced cool-season legumes are however missing, including P. sativum  (Kreplak et al. , 2019) , L. culinaris  (Ramsay et al. , 2021)  and V. faba  (Jayakodi et al. , 2023). In addition, the interface of LegumeIP is designed to facilitate pairwise comparisons, from model species to less studied crop species, making the current design unsuitable for simultaneous comparison of multi-species experiments.
Here, we developed Ortho_KB, a robust framework for translational research in diploid plant species. We developed a first pipeline to compute homology and define syntenic chromosomal regions across species. This method was chosen to identify putative orthologs among homologs, thus establishing links between corresponding genes and connecting chromosomes. We designed a second pipeline to execute custom scripts that reformat all heterogeneous data files, including -omics datasets, for input into the database. Users can integrate published and unpublished information related to their species of interest including genephenotype associations from QTL data and expression information from transcriptomic resources and use the provided framework to get the most out of their data. Ortho_KB provides an intuitive database model that can be queried using Cypher language, to extract meaningful information in comma-separated values (CSV) files for further analysis.
The framework has been applied to a subset of legume species, resulting in a database called OrthoLegKB, a multi-species and multi-omics graph-based database for collecting, integrating and querying heterogeneous data. OrthoLegKB currently allows the comparison of genetic, and -omic data from 5 legume species, i. e. , P. sativum, V. faba, L. culinaris, Vigna radiata (L. ) R. Wilczek and M. truncatula. Finally, a use-case is described to demonstrate how the combination of quantitative genetics and expression data is possible in OrthoLegKB and can benefit translational research.
Orthology and synteny As illustrated in Figure  1A , in order to identify homologous genes and syntenic regions, genome FASTA and annotation files as well as an optional conversion table for chromosomes are used as input files. The conversion table must include the original chromosome ID and the desired ID in the database. Unique chromosome and scaffold IDs across species are more convenient for querying and are also required by syntenyvisualization tools such as SynVisio  (Bandi and Gutwin, 2020). The steps for synteny and orthology discovery are the following: (1) curate annotation files using the agat_convert_sp_gxf2gxf. pl parser from agat v0. 9. 1 by automatically removing duplicated features and/or IDs, inferring missing IDs or parent features; (2) filter annotation files to keep only the longest isoform using the agat_sp_keep_longest_isoform.
pl script; (3) extract coding DNA sequences (CDS) using the agat_sp_extract_sequences. pl script  (Dainat et al. , 2022) ; (4) generate protein sequences using the Seqkit v2. 3. 0 translation module  (Shen et al. , 2016) ; (5) submit protein sequences in FASTA format to OrthoFinder v2. 5. 4 with its default parameters using Diamond v2. 0. 12 in ultra_sensitive mode for the alignment instead of BLAST  (Emms and Kelly, 2015, 2019; Buchfink et al. , 2021). Finally, to connect homologous chromosomal regions, the OrthoFinder output is used to obtain syntenic blocks. First, alignment files are filtered to retain only pairs of proteins that are part of the same orthogroup. Second, these filtered alignment files are provided to MCScanX along with a merge of annotation files from all considered species  (Wang et al.
Functional gene annotation Functional annotations were conducted by manually submitting CDS sequences to annotation tools either available on online platforms or to be run locally. The TRAPID online tool returned gene families, RNA families, and Gene Ontology (GO) terms associated with submitted genes  (Bucchini et al. , 2021). The structural pipeline computing homology between genes and synteny across chromosomal regions from selected annotated genomes. All processes included in the pipeline, except those producing the mandatory final outputs, are represented by dark red circles. Processes producing the mandatory final outputs are represented by green circles. (B) General overview of the steps leading to the construction of an instance of Ortho_KB. Datasets that can be managed include RNA-seq data, QTL and functional annotations.
As an example, we develop the treatment of an RNA-seq dataset from public or private origin. Alongside a regular extraction of counts, metadata of the samples must be annotated using ontologies to describe in particular the tissue of origin (Plant Ontology) and the experimental conditions to which the sample was subjected to (Plant Experimental Conditions Ontology). The functional pipeline will process inputed files and in this case the annotated metadata file will produce "Sample" and "Condition" nodes in the graph. This last node will also be connected by relationships to "Resource" nodes corresponding to the ontologies, thereby conserving the metadata information in the Neo j graph database. The graph database is included in a Docker container, as shown on the right-hand side of the schema.
Transcriptomic data extraction and expression quantifications RNA-seq datasets were manually selected from NCBI. Sample IDs associated within a BioProject were collected in each case using esearch from entrez-direct v16. 2  (Kans, 2013). The sample list was fed into nf-core/fetchngs pipeline v1. 7 with the option "nf_core_pipeline rnaseq" to obtain all FASTQ files along with a metadata file  (Patel et al. , 2022). The nfcore/rnaseq v3. 8 pipeline  (Patel et al. , 2023)  was then run with the genome files, metadata file and FASTQ files with the arguments "skip_alignment", "pseudo_aligner salmon" and "salmon_quant_libtype A" to automatically assess strandedness  (Patro et al. , 2017). Salmon result files were finally processed into matrices for downstream analyses using tximport  (Soneson et al.
Graph database conceptualization The current release of Ortho_KB was built as a NoSQL database framework to store and display data in a graph structure, using the Neo4j Community Edition v4. 4. 18 (Neo4j, 2023b). We chose the Neo4j graph-database management system because of (1) its efficiency in handling highly connected data, (2) the graph algorithms already implemented and (3) the expressive Cypher query language it uses and (4) its capacity to import/export data using semantic web technologies. Entities, also called nodes, and edges, also referred to as relationships, were designed in a way to carry the biological information. Each gene or transcript is represented by a node and each gene is linked to its corresponding transcript by a relationship (e. g. , gene A has a transcript RNA A1).
Input files processing A Nextflow pipeline called functional pipeline, was created to process heterogeneous data from the previously described sources. The pipeline requires genome files, functional annotation files, RNA-seq files and QTL files to run. For the functional annotations, the pipeline includes a set of scripts to filter and format them into nodes and relationships, following the database model. For the GO annotations obtained from TRAPID, by default, only the most specific GO terms are retained for each gene by selecting those with parameter "is_hidden" equal to 0, resulting in a 90% reduction in the number of GO terms directly associated to genes. The GO W3C Web Ontology Language (OWL) file is downloaded and parsed to import the "is_a" and "part_of " predicates as relationships in the graph to allow graph traversal  (W3C, 1994).
Similarly, the provided annotation files from MapMan are used to create an ontology in TURTLE syntax using rdflib v. 4. 2. 2  (Grimnes et al. , 2023). For RNA-seq, salmon pseudo-counts are by default filtered to retain only genes for which the sum of TPM across samples is >5, to avoid creating many relationships for non-expressed genes. Gene expressions in all samples from the same condition are averaged, and both arithmetic and geometric means are stored on the edge between the "Gene" and the "Condition" nodes. For genetic data, previously formatted files are processed to identify genes included in the confidence interval of QTL using pybedtools v. 0. 9. 0  (Quinlan and Hall, 2010; Dale et al. , 2011). Briefly, for all processes, the pipeline creates CSV files to populate the database and a summary file listing all CSV files to be imported in a format readable by Neo4j.
Database implementation A Bash script was written to create and populate the database. It includes three steps. The first step prepares the import environment by building a Docker container. Running the Docker container will start the database, by default available at http://0. 0. 0. 0:7474/browser/. The second step performs the import to populate the Neo4j database using the neo4j-admin import command. The third step imports the PO, PECO, GO and MapMan ontologies using the n10s. onto. import. fetch method from the neosemantics (n10s) plugin  (Barrasa, 2022). The import creates a node per term, connected to broader terms by a "SCO" relationship obtained from the property rdf:subClassOf. The nodes of the resulting subgraph are then labeled according to their source (PO, PECO etc. ) and connected to the rest of the graph using a set of Cypher queries.
Data visualization The visualization of the graph model was created using Arrows (Neo4j, 2023a). The UpSet plot was created using UpSetR  (Conway et al. , 2017). Visualization of large-scale synteny was performed with the SynVisio online tool  (Bandi and Gutwin, 2020)  or with tailored R scripts, while microsynteny was plotted using the R package gggenomes  (Hackl and Ankenbrand, 2023).
Ortho_KB is a framework for translational research in plant species Studying a particular trait or gene often requires the collection of different types of information available on different websites and databases, for the species of interest as well as for close species. We have created Ortho_KB, a database framework built with successive pipelines to facilitate the exploration of all data relevant to a trait or gene of interest in a single environment. Ortho_KB provides a unique and multi-functional structure that can be populated with datasets of interest and then queried for comparative and functional genomics studies. The current Ortho_KB modeling aims at enabling translational research across a wide range of selected species by making data easily searchable and the process more straightforward.
The framework relies heavily on orthology and synteny relationships to build bridges between species, and transfer and/or compare genetic and genomic information between them. A Nextflow pipeline, called the structural pipeline (Figure  1A ), first identifies groups of homologous genes -orthogroups -based on protein sequence similarity. It then looks for conserved gene order between pairs of chromosomes, within or between species, to highlight collinear regions. Homologs in collinear regions are more likely to be orthologs and therefore have similar functions. A second Nextflow pipeline, called the functional pipeline, connects information from the first pipeline and additional data available from separate tables including gene annotation, gene expression and QTL positions (Figure  1B ). All heterogeneous data are thus properly formatted for integration into the database.
Ortho_KB uses Neo j graph-database management system The Neo4j graph-database management system handles entities as nodes and their connections as relationships. In Ortho_KB, the data model revolves around "Gene" nodes, characterized by their start and stop positions on chromosomes (Figure  2 ). The "Gene" nodes are connected to their putative transcript ("RNA") nodes, themselves connected to the predicted proteins ("Protein") resulting from the translation of their RNA sequences. Homology and collinearity information computed using the structural pipeline create bridges across species at the gene and the chromosome levels, respectively. The current version of Ortho_KB includes 29 core categories of nodes tagged either by a single label, like "Gene" nodes or by a set of labels, like "RNASeq" supplemented by "Condition".
OrthoLegKB was developed with Ortho_KB to provide a translational tool for grain legumes To prove how Ortho_KB can serve translational approaches and the research goals of a scientific community, we chose to apply it to five diploid legume species belonging to the Galegoid (cool-season legumes) and Milletoid (warm-season legumes) clades creating the OrthoLegKB database. To leverage data from all five species using comparative genomics, we started by searching for orthologs with the structural pipeline using the latest genome assemblies. The pipeline was run for 740 CPU hours with 20 CPUs allocated (7 h 40 in real time), with a maximum physical memory usage of 46 Gb. In total, 14,565 out of 29,428 total orthogroups (49. 49 %) were shared by all five species and 8. 24 % by all species excluding V.
radiata, the only representative of the Milletoid clade (Figure  3 ). Then, public datasets with QTL and RNA-Seq data were mined, annotated with the ontologies used in Ortho_KB and included in the database using the functional pipeline. The pipeline was run for 11 CPU hours (14 min in real time), with a maximum physical memory usage of 2 Gb. A list of these datasets is available in Supplementary Table  S1. OrthoLegKB currently contains more than 815,000 nodes and close to 15,000,000 relationships associated to the different types of data. The exact number of nodes in each category can be found in Supplementary Table  S4. OrthoLegKB can be used to address various scientific questions including the conservation of the control of flowering time in legumes As a use-case to demonstrate how to exploit OrthoLegKB, we searched for the orthologs of a previously-studied flowering time regulator, the FLOWERING LOCUS T from M.
Synteny between chromosome 3 from P. sativum (Ps03), chromosome 6 from L. culinaris (Lc06), chromosome 5 from V. faba (Vf05) and Mt07 at the MtFTa1 locus was revealed highlighting the orthologs (Figure  5A ). The syntenic blocks in L. culinaris and V. faba displayed each one orthologous FTa1 gene, while two possible orthologous genes were detected in P. sativum namely Psat3g090720 and Psat3g090680 (Figure  5B ). According to the conservation of protein length and domains' annotation information from the PANTHER database stored in OrthoLegKB, Psat3g090720 seemed to be more similar to MtFTa1 (Figure  6 ). In fact, Psat3g090680 corresponds to FTa2 described in  Hecht et al. (2011). To examine any possible links with flowering control and thus function conservation, we searched for all QTL related to flowering contained in the previously identified syntenic blocks, allowing to also return QTL that did not include FTa1 genes in their confidence intervals (Supplementary Table  S5 ).
6-2_1. qDTF. 6-2_1 is a number of days to flowering QTL from  Haile et al. (2021) , and close to the qDTFL-6A_1 from  Yuan et al. (2021)  related to the number of days to flowering under low red/far-red light quality. Regarding expression, the MtFTa1 gene is known to be mainly expressed in leaves and stems in M. truncatula  (Laurie et al. , 2011; Thomson et al. , 2019). Therefore, we sought to investigate the top three tissues from the shoot system in which its orthologs were mostly expressed. Thanks to the inference allowed by the annotation of conditions with ontologies, we show that in the collection of RNA-seq datasets available for M. truncatula in OrthoLegKB, MtrunA17Chr7_39606925_39618489 was mainly expressed in vegetative shoot apex, reproductive shoot apex and vegetative shoot system.
Discussion This paper presented the use of knowledge graphs to integrate genetic and -omics data with the aim of facilitating translational research. The main philosophy was to provide a single environment where heterogeneous datasets from multiple species can be FIGURE Illustration of the query used to search for putative orthologs of MtFTa in OrthoLegKB. Putative orthologs in pea (psat), lentil (lcul), faba bean (vfab) and mung bean (vrad; top panel) were queried in Cypher (middle panel), and several properties were returned in CSV format (bottom panel). Genes belonging to the same orthogroup as MtFTa were selected and their positions on the respective chromosomes were returned. Note that relationships' names were not displayed in the query section to keep it concise but were specified when running the query.
The number of records returned in the output table and the average response time of the query are shown in light gray below the table. accessed and examined with quasi-instantaneous querying time, thus allowing to address relevant biological questions, generate hypotheses, and transfer information from a single or group of species to others. The current version of the framework handles genome annotations, QTL and transcriptomic data. Users can identify orthologs, highlight candidate genes for specific traits, pinpoint possible pleiotropy and reveal conserved functional synteny. Ortho_KB gives the opportunity to capitalize on both published and unpublished datasets for further valorisation. The interest of such a database was demonstrated by populating Ortho_KB to create OrthoLegKB, a database dedicated to research on legume crop species, and supported by a use-case study focusing on a flowering-time gene.
Ortho_KB leverages recent analytical workflows and ontology standards to host high-quality data and ensure comparability across datasets The Ortho_KB framework was built with the hypothesis that homologous genes found in collinear regions are most likely to be orthologs. Collinearity mitigates the effects of genome duplication and fractionation and thus most likely pinpoints true orthologs  (Tang et al. , 2008). Besides bridges between genomes based on orthology, additional information layers were incrementally integrated and connected to gene entities, taking advantage of the modeling flexibility allowed by Neo4j. The integration of such information was planned following homogenization rules for quality purposes. For expression data, we chose to use a single pipeline to process all transcriptomic datasets and avoid prejudice related to discrepancies in bioinformatic analysis protocols including alignment procedure, GC bias treatment.
In this case, the integration of non-genic regions such as promoters and enhancers in the database could be evaluated. Ortho_KB should be constantly evaluated to maintain performance and to facilitate its integration in the current databases ecosystem As more biological data and data types are included, the Ortho_KB framework will have to be regularly fine-tuned to find the optimal graph model, but also in terms of the underlying configuration. In fact, for both the orthology backbone and the additional layers of the graph, single-property indexes have been created on properties that are regularly used as anchors to improve search performance at a small cost in storage space. Further guidance on the configuration of Neo4j has been previously published and will help to ensure high efficiency and scalability of Ortho_KB  (Yoon et al.
, 2017). Several platforms already exist to study comparative genomics  (Lyons and Freeling, 2008; Van Bel et al. , 2022). The goal of Ortho_KB is different, since it mainly uses orthology and synteny as a way to transfer curated knowledge across species. Therefore, any created instance can be queried freely to answer complex tailored questions in a comprehensive manner. As OrthoLegKB is primarily populated with published datasets, interoperability with already existing databases is essential. For RNA-seq, the NCBI Sequence Read Archive stores datasets according to defined rigorous standards  (NCBI, 2023). QTL data, on the other hand, are typically scattered across multiple databases that store the information in different formats. Unlike the GWAS Catalog available for human  (Sollis et al.