A hands-on introduction to querying evolutionary relationships across multiple data sources using SPARQL

The increasing use of Semantic Web technologies in the life sciences, in particular the use of the Resource Description Framework (RDF) and the RDF query language SPARQL, opens the path for novel integrative analyses, combining information from multiple data sources. However, analyzing evolutionary data in RDF is not trivial, due to the steep learning curve required to understand both the data models adopted by different RDF data sources, as well as the equivalent SPARQL constructs required to benefit from this data – in particular, recursive property paths. In this article, we provide a hands-on introduction to querying evolutionary data across several data sources that publish orthology information in RDF, namely: The Orthologous MAtrix (OMA), the European Bioinformatics Institute (EBI) RDF platform, the Database of Orthologous Groups (OrthoDB) and the Microbial Genome Database (MBGD). We present four protocols in increasing order of complexity. In these protocols, we demonstrate through SPARQL queries how to retrieve pairwise orthologs, homologous groups, and hierarchical orthologous groups. Finally, we show how orthology information in different data sources can be compared, through the use of federated SPARQL queries.


Amendments from Version 1
-We have added all the queries presented in the article to the BioQuery 1 interface online, (available at http://biosoda.expasy. org), in Section "Information on Homologous Gene queries", making it easier for readers to try them out directly without requiring copy-pasting the SPARQL queries from the text of the article. Furthermore, we have also created clickable links that point users directly to the corresponding query results in the relevant SPARQL endpoint webpage, in the form of purl. org/orthology/q0 to purl.org/orthology/q9, where the ids Q0-Q9 correspond to the queries presented in the "Protocols" section.
-We have added a subsection "Applicable Ontologies", in the "Materials" section, explaining the ontologies relevant to the orthology domain, used by the four data sources described in the article (OMA, OrthoDB, MBGD and EBI).
-We have improved the explanations regarding the choice of relevant URIs for formulating SPARQL queries targeting the orthology domain, while clarifying the specific challenges of querying orthology data with SPARQL.
-We have improved the OrthoDB data model figure with small corrections.
-We have included a subsection about "retrieving OrthoDB pairwise orthologs".

Introduction
Gene classification based on evolutionary history is essential for many aspects of comparative and functional genomicsreviewed in (Gabaldón & Koonin, 2013); (Glover et al., 2019). On the one hand, evolutionary relations are often described as binary relations. Two genes that share a common ancestor are defined as homologs. We can classify homologs into orthologs, which originate from a speciation event; paralogs, which originate from a gene duplication; and xenologs, which originate from horizontal gene transfer (Fitch, 1970). On the other hand, Hierarchical Orthologous Groups (HOGs) are hierarchical clusters of corresponding genes where each level in the hierarchy refers to a common ancestral gene at a taxonomic level of reference (Altenhoff et al., 2013). Further details about orthology, paralogy, xenology and various kinds of groupwise orthology relationships are described in (Fernández et al., 2020). Identifying orthologs and HOGs is valuable in several contexts such as gene function inference, gene evolution dynamics and comparative genomics.
To query and interoperate biological databases, Semantic Web Technologies are being increasingly adopted, in particular the use of the Resource Description Framework (RDF) and SPARQL protocol and RDF query language (SPARQL Query Language for RDF, n. , there are still significant challenges that limit their use for the larger scientific community. In particular, analysing evolutionary relationship data in RDF poses the following challenges: 1) complex data models -for example, while storing data in a hierarchical structure (HOGs) results in significant performance benefits for common analyses, such as computing orthologs of a specific gene in a different model organism, the hierarchy also results in requiring advanced knowledge of the SPARQL language (in particular, recursivity) in order to benefit from the RDF representation of HOGs. In this article, we present a series of hands-on examples, in increasing order of complexity, to familiarise the reader with the basic concepts needed to query evolutionary relationships in orthology databases.
2) heterogeneous data models -understanding the data model of a single orthology database might not be sufficient in general, since different databases have made different design decisions. We help overcome this challenge by depicting how the following major Orthology Databases structure their data in RDF, as well as how they can be queried using SPARQL: the Orthologous MAtrix (OMA) ( 3) overhead of integration into existing analysis pipelines. The limited rate of adoption of Semantic Web Technologies can be explained by the reluctance of bioinformaticians to change their existing workflows in order to accommodate new data formats based on the RDF framework. For example, retrieving orthology information using public SPARQL endpoints instead of the more traditional file-based data exchange or full database dumps. A SPARQL endpoint is an access point for receiving and processing SPARQL protocol requests. In this article, we show through concrete examples that integrating the results of SPARQL queries into existing analyses is a straightforward task -more specifically, we show how to transform the results into regular Pandas dataframes in Python. Furthermore, we provide an accompanying Jupyter notebook where all the examples presented in this article can be directly tested and further refined. This article has several goals: (1) Understanding Orthology Data Models. Become familiar with how evolutionary relationships are represented in RDF across several databases. Learn about the data modelling decisions: common points as well as differences between these data sources to support the choice of one or more of them for a given analysis. (3) Integrating external sources. Leverage connections to other external bioinformatics resources that make their data available in public SPARQL endpoints based on cross-references. In particular, learn about the role of UniProt cross-references as a bridge between different data sources in integrative analyses.
In addition, we show how to use SPARQL to make metaanalyses combining multiple orthology databases. For instance, for a given gene, which are the orthologs in a given database which are not present in another one? Finally, we show how to leverage SPARQL aggregations in order to get useful statistics about orthology data available in the sources.
Finally, learn how to leverage SPARQL results in downstream analyses by converting them to Pandas dataframes. This is illustrated through a series of hands-on exercises in the accompanying Jupyter notebook (exercises provided in Python).
The protocols presented in this article are aimed at bioinformaticians who are already familiar with the basics of SPARQL and wish to learn how orthology data can be integrated in their research analyses programmatically, through the use of (federated) SPARQL queries.

Materials
In the following paragraphs, we briefly describe the orthology databases considered in this article.
OrthoDB (Zdobnov et al., 2017) contains orthologous genes along with evolutionary and functional annotations. It relies on HOGs to enable different orthology information resolutions with regards to more closely related species. The 2018 OrthoDB version covers thousands of eukaryotes, prokaryotes, and viruses. OrthoDB data is available in RDF through the public SPARQL endpoint at https://sparql.orthodb.org/sparql. We note here that the timeout for the public SPARQL endpoint is limited to 100 seconds -more precisely, queries with longer estimated execution time will not be allowed to run. II. Homologous groups are sets of homologous genes without any hierarchical grouping ("flat"). All members are homologous to all other members, with no distinction of paralogy or orthology. However, the kind of homologous groups considered in this tutorial do not contain "out-paralogs"-i.e. paralogs which result from gene duplications which took place prior to the last common ancestor of all species in the databases. Furthermore, each homologous group can still be associated with a taxonomic level, which indicates to which species clade its members belong. Example of orthology databases from which we can extract these homologous groups are OMA, OrthoDB and MBGD.

MBGD
III. Pairwise orthology. Apart from the aforementioned orthologous groups, evolutionary data can also be provided in the form of pairwise orthologous genes. Among the sources that provide this type of information in RDF, we consider in this article EBI, OMA, OrthoDB and MBGD.
We mention that the SPARQL endpoints of the databases may sometimes be temporarily unavailable, for example, for maintenance purposes. In these cases, the queries provided in this article may not be able to run or may become unresponsive due to the unavailability of the corresponding SPARQL endpoint. Should these issues persist for a longer period of time, it is advised to contact the respective database support through the email address indicated on the SPARQL endpoint webpage.

Applicable Ontologies
The main existing ontology to represent and structure the orthology information is the Orthology (ORTH) Ontology ( on an internal data model while the fragment of EBI relevant to this article mainly reuses the "is orthologous to" pairwise property from the Semanticscience Integrated Ontology (SIO).
In the context of the four databases depicted in this article, a way to possibly identify relevant URIs (Uniform Resource Identifiers) for properties of interest such as "in taxon", "is orthologous to", but also for taxonomic identifiers etc, is the Ontology Lookup Service (OLS), available online at https://www.ebi.ac.uk/ ols/index.
We note below the other main underlying ontologies, controlled vocabularies and taxonomies used by at least one of the four data sources. Further details are depicted in Table 1 in the Extended data available in (Sima & Mendes de Farias, 2020).
-The Gene Ontology (GO) to specify molecular functions, for example.
-The Relation Ontology (part of the Open Biological and Biomedical Ontology (OBO) Foundry) for properties such as "in taxon".
-SIO for properties such as "protein encoded by" and "gene encodes protein".
-ENSEMBL for gene identifiers.
-The National Center for Biotechnology Information (NCBI) taxonomy.
-Dublin Core Initiative Metadata (DCMI) terms to state identifiers and descriptions in OMA and MBGD databases.
-UniProt core ontology -for scientific/common names of species, as well as cross-references.
In the Section "Data Models" we provide a more detailed introduction to how each of the four data sources considered in this article structures orthology data. We illustrate through concrete examples the commonalities as well as differences between the data sources.

Data models
In this section we provide a brief introduction to the data models of the orthology databases considered in this article, in order to facilitate the understanding of the SPARQL queries presented in the Protocol Section.
We first present a simple example to illustrate how SPARQL queries can be formulated, starting from a given data model. Figure 1 illustrates a simplified graph abstraction of an RDF data model targeting proteins and genes that encode these proteins, and their related species (taxa). Furthermore, the model includes cross-references to the corresponding UniProt entries. These cross-references can be useful in formulating federated SPARQL queries. Federated queries can retrieve information from multiple RDF data sources, using the UniProt entry as an intersection ("join point"). Figure 1 can be used as a guide to formulate simple SPARQL queries that aims to answer questions of interest. Such questions can be related to, for example, proteins found in a given species, or those corresponding to a specific UniProt accession number. For readability, we omitted specific namespaces and exact URIs. Instead, we use the human readable labels of properties, such as "in taxon". The URIs that represents these terms (e.g. Protein, Gene, in taxon) depend on the underlying database being queried. Nevertheless, if the database is reusing existing vocabularies to model their data, a reference for mapping these terms to their corresponding identifiers (URIs), is the Ontology Lookup Service (OLS), and the Linked Open Vocabularies (LOV) https://lov.linkeddata.es. For example, searching for "in taxon" in OLS will result in the first answer returned being the OBO URI http://purl.obolibrary.org/obo/ RO_0002162. An example question for which the corresponding SPARQL query can be formulated, based on the simplified query graph in Figure 1, could be: "What are Rattus Norvegicus proteins available in the database?" In order to retrieve this information, we can start from the ?protein1 variable, of type Protein, illustrated in the top right corner of the figure, which we need to connect to the taxon scientific name ("Rattus Norvegicus") via "organism". Note that the SPARQL users can define variable names as they want by following the SPARQL syntax where the question mark (?) means that is a variable. Following the arrows from ?protein1 to ?taxon (in Figure 1, from right to left) we can formulate the following SPARQL query, which can be executed in the OMA SPARQL endpoint: Changing the target species of interest only requires changing the corresponding text in between quotes. For example, to find the human proteins available in the data source, change "Rattus norvegicus" to "Homo sapiens" (note: the query is case-sensitive).
Any additional information can be retrieved by adding the corresponding triple pattern to the query, while also making sure to add any relevant variables to the select statement. For example, to also retrieve the corresponding UniProt entries for the proteins, we can apply the following modification (changes highlighted in bold, see last line of the query statement): For a more complete introduction to SPARQL and RDF in the context of biological databases see (Sima et al., 2019). Next we will introduce the data models of the orthology databases considered in this article. Figure 2 illustrates a few of the members of a HOG, the main data structure in MBGD. In particular, this MBGD cluster has the identifier 28799. Members of an MBGD orthologous cluster can be either genes, domains or other clusters. These nested orthologous clusters are built at specific taxonomic levels in the hierarchy. For example, the cluster highlighted in blue in Figure 2 was built at taxonomic level 32, Myxococcus. The hierarchy needs to be traversed in order to reach genes, such as mxa:PL1911 that is highlighted in red in Figure 2, or domains (sub-gene level) which belong to an orthologous cluster at a given taxonomic level.
The RDF model is more suitable for representing such hierarchical data structures than the relational data model (  . This can be achieved in SPARQL through a recursive graph pattern, using the hasHomologous* property path 1 -a graphical abstraction of the RDF representation is provided in Figure 3. 1 https://www.w3.org/TR/sparql11-query/#propertypaths Based on Figure 3, SPARQL queries can be formulated by following the directions and labels of arrows in order to formulate triple patterns. For example, to retrieve all genes (i.e. instances of the orth:Gene class) of a given HOG, we can follow the graph structure from root to leaf members by performing the query as shown in the code fragment below. In other words, the ?gene1 variable values illustrated as the left-side member in the cluster ?hog_cluster (see Figure 3).  Figure 3, nodes are either classes or variables, and edges are RDF properties. The terms preceded by a question mark (e.g. ?gene1) represent variables assigned with either zero or more literals or URIs. Dashed edges illustrate the orth:hasHomologous property that can be stated zero or more times, recursively. URI prefixes were omitted. MBGD is gene-centric and contains taxonomic ranges where HOGs are built are not directly available in RDF -in some cases these can be extracted from the cluster URI (e.g. http://mbgd.genome.ad.jp/rdf/resource/cluster/2018-01_tax32_8537) corresponds to taxonomic identifier 32, Myxococcus). By contrast, the taxonomic information per gene entry is richer in MBGD than in OMA, including explicit Superkingdom and Phylum information. Example SPARQL queries based on this graph abstraction are provided in the "Protocols" section, as well as in the accompanying Jupyter notebook. The pairwise orthology information is not directly available (e.g. through an RDF property), but can be extracted from the Orthologs Cluster (to highlight this, the "isPairwiseOrthologous" is shown in green with a dashed arrow).
This SPARQL query will retrieve all the genes in the MBGD Hierarchical Orthologous Group represented with the identifier 28799. Similarly, the HOG structure in OMA is abstracted in Figure 4. Both figures can be used as a guide in formulating SPARQL queries, by following the directions of the arrows in order to formulate triple patterns. Since both the MBGD and the OMA models rely on the ORTH ontology (Fernández-Breis et al., 2016), the two graph structures are very similar and therefore SPARQL queries can be formulated with only minor differences for both data sources. Figure 5 illustrates the data model of the portion of the EBI RDF graph describing orthology information. In contrast to OMA, OrthoDB and MBGD, EBI only provides pairwise orthologous genes.  Figure 4, dashed edges illustrate the orth:hasHomologousMember property that can be stated zero or more times, recursively. OMA is proteincentric, however the corresponding genes that encode the proteins are also available in RDF through the "is encoded by" property (a cross-reference to Ensembl identifiers is also provided). Furthermore, the taxonomic ranges where HOGs were built are asserted through the "hasTaxonomicRange" property. The pairwise orthology information is not directly available (e.g. through an RDF property), but can be extracted from the Orthologs Cluster (to highlight this, the "isPairwiseOrthologous" is shown in green with a dashed arrow). Note: URI prefixes were omitted.

Figure 5. Directed graph abstraction of a portion of the EBI RDF graph related to pairwise orthologous genes. Moreover, as opposed
to the RDF representations in OMA and MBGD, here the pairwise orthology is explicitly asserted through the "is orthologous to" property (more precisely, http://semanticscience.org/resource/SIO_000558) as shown in Figure 5. However, there is no information available regarding orthologous clusters. Moreover, the Gene class here is in fact the OBO (not ORTH) class, i.e. http://purl.obolibrary.org/obo/SO_0000704. Instances of these genes can be specified either through their cross-reference to UniProt (the http://rdf.ebi.ac.uk/terms/ensembl/DEPENDENT property) or directly through their ENSEMBL identifier, by fixing the value of ?gene to the concatenation of http://rdf.ebi.ac.uk/resource/ ensembl/ and the corresponding Ensembl identifier. Finally, the taxonomic identifiers are provided via instances of the BioSource class, http:// www.biopax.org/release/biopax-level3.owl#BioSource. Figure 6 illustrates the structure of Orthologous Groups in the OrthoDB RDF. Here, genes are direct members of OrthoGroups built at a given taxonomic level (Clade), e.g. Cyanobacteria. We mention that OrthoDB provides information in RDF, including sequence length, number of exons for gene members, as well as evolutionary rates, functional category and others for orthologous groups (for more details see Extended data in (Sima & Mendes de Farias, 2020)).

Choosing the relevant target gene identifiers in RDF (URIs)
One of the challenges in formulating SPARQL queries is identifying the relevant URIs for the resources of interest. In the case of queries targeting the orthology domain, the resources of interest will usually consist of target genes, for which the orthologous genes need to be retrieved from the RDF data store. A simple way to obtain the relevant URIs in the case of the four data sources considered in this article, is to start from the UniProt accession numbers for the target gene of interest. This accession number can be identified through the online search interface of UniProt at www.uniprot.org, by searching for the gene name of interest, for example, "HBB" (or "human HBB"). The column "Entry" in the result page contains the corresponding UniProt accession number. From here, the URI can be obtained by concatenating the UniProt namespace prefix: http://purl.uniprot.org/ uniprot/ with this accession number.
For example, in the case of human HBB, the URI will be http:// purl.uniprot.org/uniprot/P68871. Using this information and the cross-reference properties available in each of the four databases (OMA, OrthoDB, MBGD and OrthoDB), the appropriate SPARQL queries can be formulated, according to the examples shown previously in Figure 3- Figure 6 6. In the "Protocols" section we give concrete examples of queries for each of the four data sources, which can be directly executed in the corresponding SPARQL endpoints.

Protocols - SPARQL queries
In this section, we provide four protocols to (i) retrieve pairwise orthologs through SPARQL queries from EBI, OMA, MBGD, as well as (ii) homologous groups from OMA, MBGD and OrthoDB (iii) restrict the search to a given taxonomic level (iv) perform meta-analyses across multiple data sources providing orthology information, and aggregations using the entire data available in a given data source. All protocols presented below are included in the accompanying Jupyter notebook.
For the sake of simplicity, genes are identified with either their Ensembl identifiers or their cross-reference to the UniProt accession number. In this article, we assume the reader already knows the UniProt primary accession number of the searched gene. In general, this number can be found by searching for the corresponding gene name in the UniProt webpage, for example, "HBB" (i.e. "hemoglobin subunit beta" In this protocol we illustrate the basic task of retrieving the pairwise orthologs of a given gene, for example the HBB (Hemoglobin subunit beta) human gene. This is illustrated on Figure 6. Directed graph abstraction of a portion of the OrthoDB RDF graph related to orthologous groups. Note that the abstract relation "?gene1 isPairwiseOrthologous ?gene2" is derived by considering the concrete property path "?gene1 :memberOf / :hasMember ?gene2" that further implies the following joint triples: "?gene1 :memberOf ?group. ?group :hasMember ?gene2.". In Figure 6, genes are direct members of OrthoGroups built at a given taxonomic level (Clade), e.g. Cyanobacteria, available through the "ogBuiltAt" property. The crossreferences to UniProt (as well as Ensembl and Entrez) are available through a 2-triple pattern (for examples see "Protocols" section).
the four orthology databases that provide pairwise orthology information in RDF: OrthoDB, EBI, OMA and MBGD. The corresponding SPARQL queries to retrieve the pairwise orthologs can be formulated as shown below. We note that the resulting orthologs are also provided using their "clickable" crossreference link to UniProt. This can directly be used to find out more information about the resulting genes (e.g. name, location, expression) and has the added advantage that results originating from different orthology databases can then be compared against each other. All Protocol 1 queries retrieve a set of 2-tuples (?a, ?b), where ?a is the gene given as an input to look for its orthologous genes, which are assigned to ?b. Therefore, the 2-tuple (?a, ?b) set represents the binary relation "?a is orthologous to ?b". In all queries except for Q2, these genes are represented with UniProt entries, more specifically, UniProt URIs (see subsection "Choosing the relevant target gene identifiers in RDF" for further details). In Q2, the input gene is represented with an Ensembl gene URI as depicted in b).

a) Retrieving OrthoDB pairwise orthologs
The following code fragment shows the SPARQL query to retrieve pairwise orthologs of the human HBB gene from the OrthoDB database. The following link http://purl.org/orthology/q0 is provided to directly execute the query at the OrthoDB SPARQL endpoint. We denote this query as Q0.

b) Retrieving EBI pairwise orthologs
The following code fragment, which we will denote as Q1, depicts a SPARQL query to retrieve pairwise orthologs of the human HBB gene from Ensembl dataset at the EBI RDF platform (see Figure 5 for the respective data schema).
You can execute this query directly at the EBI SPARQL endpoint by clicking on the following link: http://purl.org/ orthology/q1.

c) Retrieving OMA pairwise orthologs
The following code fragment shows a SPARQL query to retrieve pairwise orthologs of the human HBB gene which are derived from the HOGs in the OMA database (see Figure 4 for the respective data schema). The following link http://purl.org/orthology/q3 is provided to directly execute the query at the OMA SPARQL endpoint webpage. We denote this query as Q3.

d) Retrieving MBGD pairwise orthologs
In a similar manner to the previous code fragment, the following depicts a SPARQL query to retrieve pairwise orthologs of the human HBB gene which are derived from the HOGs in the MBGD database (see Figure 3 for the respective data schema).
To obtain the results for this query, denoted as Q4, by using the MBGD SPARQL endpoint, we can click on the following link: http://purl.org/orthology/q4. In further details, the Q5 query retrieves a set of 4-tuples (?cluster, ?protein2_OMA_URI, ?protein2_uniprot_URI, ?tax_name). The ?cluster variable represents the homologous group built at a taxonomic level of reference (i.e. ?tax_name) that contains the gene represented with a given UniProt entry (e.g. P68871). The ?protein2_OMA_URI and ?protein2_ uniprot_URI variables are assigned the homologous genes defined as OMA and UniProt entries, respectively. These genes belong to the same homologous group (i.e. ?cluster). Because of the fact that the SPARQL results are in a tabular form, to solely retrieve the members of a homologous group that are represented as a UniProt entry, we mainly need to project the ?protein2_uniprot_URI. To do so, we have to replace the line containing the SELECT keyword in Q5 with the following instruction: SELECT DISTINCT ?protein2_uniprot_URI.

b) MBGD Homologous Groups derived from the HOGs
The HOGs in MBGD do not provide explicit taxonomic levels at the root level of a HOG. However, the taxon NCBI identifiers of subHOGs (i.e. sublevels) can be extracted in some cases from the cluster URI. Since this requires more advanced knowledge of SPARQL (in particular, for parsing the cluster URIs), we only make it available as part of the Extended data in (Sima & Mendes de Farias, 2019).

c) OrthoDB Homologous Groups
The following code fragment denoted as Q6 retrieves homologous groups that contains the human HBB gene identified with its corresponding UniProt entry accession number P68871. The query can be executed at the OrthoDB SPARQL endpoint webpage at https://sparql.orthodb.org. To inspect the results, we can execute Q6 by accessing the following link: http://purl.org/ orthology/q6 This SPARQL query will retrieve flat homologous groups that contains the human HBB gene in OrthoDB. More specifically, these homologous groups are indeed orthologous groups, similarly to groups in which all genes are related to each other by pairwise orthologous relations (Zahn-Zabal et al., 2020). Moreover, the HBB gene is represented with its related UniProt entry (i.e. the UniProt URI http://purl.uniprot.org/uniprot/ P68871).
In more details, the Q6 query retrieves a set of 6-tuples (?group ?species_name ?protein1_uniprot ?gene1 ?taxLevel_ uniprot ?taxLevel ). The ?group variable represents the homologous group built at a taxonomic level of reference (i.e. ?taxLevel) that contains the gene represented with a given UniProt entry (e.g. P68871). The ?gene1 and ?protein1_uniprot variables are assigned the orthologous genes defined as OrthoDB and UniProt entries, respectively. These genes belong to the same homologous group (i.e. ?group). In addition, ?species_name and ?taxLevel_uniprot variables are assigned, respectively, a species scientific name where ?gene1 is found, and ?taxLevel_uniprot is the corresponding UniProt URI of a ?taxLevel value (i.e. a taxonomic level name, e.g. "Primates"). To solely retrieve the members of an OrthoDB orthologous group that are represented as UniProt entries, we just need to project the ?protein1_ uniprot variable in the SELECT query form.

Protocol 3: Retrieve Hierarchical Orthologous Groups (HOG)
In this protocol we show how to retrieve the HOGs containing a target gene, such as the human HBB gene, in the three orthology databases OMA, MBGD and OrthoDB. The Ensembl dataset in the EBI RDF platform is not considered because it does not provide HOG information.

a) Retrieving HOGs from OMA
The following code fragment denoted as Q7 retrieves hierarchical orthologous groups (HOGs) that contains a gene identified with the UniProt entry accession number P68871. Q7 can be executed at the OMA SPARQL endpoint webpage at https:// sparql.omabrowser.org/lode/sparql. The query along with its results are available at http://purl.org/orthology/q7. This SPARQL query will retrieve the root hierarchical orthologous group that contain the human HBB gene in the OMA database. The HBB gene is represented with its related UniProt entry (i.e. the UniProt URI http://purl.uniprot.org/uniprot/P68871). More specifically, the Q7 query retrieves a set of 5-tuples (?root_hog, ?species_name, ?protein1_uniprot, ?protein1_ OMA, ?taxLevel). The ?root_hog variable represents the root HOG (i.e. the deepest common ancestor for all the present species) that contains the gene represented with a given UniProt entry (e.g. P68871). The ?protein1_OMA and ?protein1_uniprot variables are assigned the genes defined as OMA and Uni-Prot entries, respectively. These genes belong to the same root HOG (i.e. ?root_hog). In addition, ?species_name and ?taxLevel variables are assigned, respectively, the species scientific name and the taxonomic level (e.g. "Tetrapoda") where the gene is found. Moreover, the taxonomic levels implicitly represent speciation events and ancestral genes in the context of HOGs.

b) Retrieving HOGs from MBGD
The SPARQL query to retrieve HOGs from MBGD is similar to the previous query over OMA and therefore we make it available as Extended data in (Sima & Mendes de Farias, 2020). As a reminder, although both the OMA and MBGD databases rely on different versions of the ORTH ontology, they structure their HOG data similarly.

c) Retrieving HOGs from OrthoDB
The following code fragment denoted as Q8 retrieves hierarchical orthologous groups that contain the human HBB gene in the OrthoDB database. The HBB gene is represented with its related UniProt entry (i.e. the UniProt URI http://purl.uniprot. org/uniprot/P68871). The query can be executed at the OrthoDB SPARQL endpoint webpage at https://sparql.orthodb.org. To execute Q8 and inspect its results, we provide the following link: http://purl.org/orthology/q8. Note that unlike OMA root HOGs where a gene can only be in one root HOG, in OrthoDB a gene can belong to multiple "root" HOGs. This is because OrthoDB might not explicitly relate the orthologous group built at the highest taxonomic level (i.e. the actual root) to lower level orthologous groups in the hierarchy. For example, for the HBB gene the Q8 query retrieves three distinct "root HOGs" with the following highest taxonomic levels: Eukaryota, Metazoa, and Vertebrata. In further details, the Q8 query retrieves a set of 6-tuples (?hog_ root ?species_name ?protein1_uniprot ?gene1 ?taxLevel_uniprot ?taxLevel ). The ?hog_root variable represents the "root HOG" that contains the gene represented with a given UniProt entry (e.g. P68871). The ?protein1_uniprot and ?gene1 variables are assigned the genes defined as UniProt and OrthoDB entries, respectively. These genes belong to the same root HOG (i.e. ?hog_root). In addition, ?species_name and ?taxLevel variables are assigned, respectively, the species scientific name and the taxonomic level (e.g. "Eukaryota") where the gene is found. The ?taxLevel_uniprot is the corresponding UniProt URI of a ?taxLevel value.
Protocol 4: Meta-analysis -comparing data across OMA and MBGD orthology In this protocol, we show how to compare orthology information across multiple databases with SPARQL 1.1. Although the example in the following code fragment is restricted to OMA and MBGD, similar queries over different combinations of the orthology databases mentioned in this article can be derived based on the Code Fragments in Protocols 1, 2 and 3.
For a given UniProt entry such as the accession number K9Z723, retrieve orthologs that are only in MBGD, but not in OMA. Alternatively, to retrieve only those that appear in both sources, simply remove the "NOT" keyword in the FILTER clause below. To execute the query below denoted as Q9 at the OMA SPARQL endpoint, https://sparql.omabrowser.org/lode/sparql, we provide the following link: http://purl.org/orthology/q9 This federated SPARQL query will retrieve pairwise orthologous genes of the Cyanobacterium-aponinum psb27 gene that are found in the MBGD database but are not present in OMA. The psb27 gene is represented with its related UniProt entry, thus the UniProt URI http://purl.uniprot.org/uniprot/K9Z723.

Aggregations in SPARQL:
Combining data from multiple resources By exploiting orthology databases that represent information with the same framework for data interchange (i.e. RDF) allow us to further query the data with the same query language (i.e. SPARQL). As a result, we can aggregate and combine data from multiple databases more efficiently. This is because we avoid the needs of syntactic conversions and changes in the original data models and structures by using SPARQL and RDF. These conversions and changes are often required by traditionals methods that combines different file-based data exchange formats or full database dumps.
In the Extended data, we provide additional examples showing how to retrieve the top 10 entries with most orthologs in OMA and MBGD for a given species, e.g. 'Drosophila melanogaster '. These examples illustrate a few more advanced SPARQL features, such as aggregation and ordering by a criterion in order to select the top N results.

Conclusion
We provide four protocols that show how to query evolutionary relationships (pairwise orthologs, as well as HOGs) across four major databases available through SPARQL 1.1 endpoints: EBI, OMA, MBGD and OrthoDB. These protocols can serve as a useful starting point for readers interested in an introduction to the RDF data models of these data sources, as well as the basics of retrieving orthology information through SPARQL queries. Finally, we have shown how aggregations in SPARQL can be used to quickly generate an overview of the data available in each considered database, and how this data can be compared across the data sources.
To sum up, we hope these protocols provide a useful introduction into analysing evolutionary relationships among genes with SPARQL, as well as enriching these analyses by integrating information from external data sources, through federated queries. We have also integrated the queries in this article in the BioQuery search interface (Sima et al., 2019) available at http:// biosoda.expasy.org/. Researchers to directly execute or further refine these queries in a more user-friendly environment.
We encourage readers to experiment with the example queries presented in this article, which are provided in the accompanying Jupyter notebook, to be directly re-used or integrated into existing research analysis pipelines. This project contains the following extended data:

Data availability
• Table 1. "Cheat sheet" for RDF data available in the four sources considered in this tutorial. (*) GO annotations can be retrieved from the UniProt RDF store through UniProt cross-references.

• Aggregation queries
Data are available under the terms of the Creative Commons Zero "No rights reserved" data waiver (CC0 1.0 Public domain dedication).

Software availability
All the queries presented in the "Protocols" section are also now part of the BioQuery interface (Sima et al., 2019) available online at http://biosoda.expasy.org/. We included the queries in the "Information on Homologous Genes" section. Alternatively, they can be highlighted by searching for the database name, for example MBGD, in the search field on the top-left corner of the webpage.
Furthermore, the accompanying Jupyter notebook allows for integration with other existing analysis tools by illustrating how to query SPARQL endpoints in Python, as well as how to export SPARQL query results as Pandas data frames.
Online Data Access SPARQL endpoints (all links include further example queries): • This is an interesting point, basically applicable licenses prevent proper reuse or reproducibility of research data, which should concern us. All in all, I am pleased with the responses and additions and think it is an excellent paper that is a good example of how semantic web technologies can be applied in the life sciences.

Competing Interests:
No competing interests were disclosed.
I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.

Version 1
Reviewer Report 29 June 2020 https://doi.org/10.5256/f1000research.23139.r64153 © 2020 Kushida T. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
Tatsuya Kushida 1 National Bioscience Database Center, Tokyo, Japan 2 RIKEN BioResource Research Center, Tsukuba, Japan It can be useful to leverage orthologous gene knowledge in genome data analysis like gene function annotations, and the inference. The authors attempted to introduce how to retrieve the orthologous genes for several RDF databases such as OMA, MBGD, OrthoDB, and EnsemblRDF, using concrete SPARQL query examples. In particular, I highly evaluate that the authors explain through appropriate examples of the methods to retrieve the information of the complicated orthologous structures. It is expected to facilitate the understanding of the knowledge, and it would make contributions to increase the usage for genome data analysis. Moreover, the authors provided the Python codes' information to extract orthologous genes from the RDF databases and incorporate them into existing analysis pipelines. That is also worth appreciating. It is essential to further appeal the merits to bioinformaticians and experimental researchers in order to disseminate the orthologous RDF data.
I realized that as stated in the section: Aggregations in SPARQL: Combining data from multiple resources (page 11), I can aggregate the data more efficiently using the SPARQL than traditional procedure (file-based data exchange or full database dumps.) On the other hand, the authors did not sufficiently mention the advantage of the RDF and SPARQL compared with the traditional procedure. I hope that the authors would more strongly emphasize the advantage.

Is the rationale for developing the new method (or application) clearly explained? Yes
Is the description of the method technically sound? Partly

Are sufficient details provided to allow replication of the method development and its use by others? Partly
If any results are presented, are all the source data underlying the results available to ensure full reproducibility? Yes Are the conclusions about the method and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed.

I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.
Author Response 08 Jul 2020 Tarcísio Mendes, University of Lausanne, Lausanne, Switzerland Dear Tatsuya Kushida, We would like to thank you for the insightful comments and suggestions for improvements. We have revised the article in order to take all comments into account. We thus hope that this new version takes into account the remarks and answers the questions raised.
In summary, we have made the following changes: We have added all the queries presented in the article to the BioQuery3 interface online, (available at biosoda.expasy.org), Section "Information on Homologous Gene queries", making it easier for readers to try them out directly without requiring copypasting the SPARQL queries from the text of the article. Furthermore, we have also created clickable links that point users directly to the corresponding query results in the relevant SPARQL endpoint webpage, in the form of purl.org/orthology/q0 to purl.org/orthology/q9, where the ids Q0-Q9 correspond to the queries presented in the "Protocols" section.
We have added a subsection "Applicable Ontologies", in the "Materials" section, explaining the ontologies relevant to the orthology domain, used by the four data sources described in the article (OMA, OrthoDB, MBGD and EBI).

○
We have improved the explanations regarding the choice of relevant IRIs for formulating SPARQL queries targeting the orthology domain, while clarifying the specific challenges of querying orthology data with SPARQL.

○
We have improved the OrthoDB data model figure with small corrections.

○
We have included a subsection about "retrieving OrthoDB pairwise orthologs".

○
The following paragraphs list the issues identified by the reviewers, along with our corresponding answers. Below we provide detailed answers to your comments. Natural Sciences, Okazaki, Japan In this manuscript, the authors provide introductory examples showing how to query hierarchical orthology databases in RDF format using the SPARQL query language. Although these semantic web technologies are promising for integrating various biological resources, they still seem to be utilized by only very limited researchers. In this respect, this kind of introductory paper may be helpful for more biologists to utilize these technologies. However, for this purpose, I think that this manuscript has a serious defect that it is not easily understandable unless the readers have sufficient knowledge and skills of BOTH SPARQL and homology/orthology concepts (I do not think that this article contains any specific new ideas for such experts). Therefore, the authors should add some more explanation to improve the understandability for those who are not very familiar with either of these fields in order to achieve the goal of this article. At the first example in "Data models" section (page 4), the authors should add some explanation about how to make a query based on a given RDF graph (with some figure).
Such an explanation in addition to the RDF graphs of the actual databases can help understand the subsequent SPARQL codes. 1.
Here, protocols are shown for extracting three types of homology/orthology information: pairwise orthologs, homologous groups, and hierarchical orthologous groups (HOGs), but the exact definitions of the extracted information are not clearly given. Moreover, the specifications of the protocols including their purposes and outcomes are not clearly explained. In fact, all of these protocols retrieve some kinds of pairwise homology/orthology relationships of a given UniProt entry, but the differences of them are not very obvious. Therefore, it is not easy for readers to understand these protocols exactly, and even impossible to check the correctness of the code, without any appropriate explanation.

2.
Related but somewhat minor comment: homologous group considered here seems to correspond to orthologous group that contains only orthologs and in-paralogs, while I think homologous group can generally also contain out-paralogs.

3.
Most readers are probably not satisfied with just a copy-and-paste of the given examples, but want to modify them for their own purposes, so it is desirable to give some hints on how to make modifications to each query.

4.
Some codes containing double quotation marks did not work well when I did copy and paste them from the article web site, probably because these characters were converted into non-ASCII characters.

5.
In the last example, the URIs of the same UniProt entry are appeared repeatedly. Can't you use a common variable to specify the query URI only once? 6.

Is the description of the method technically sound? Partly
Are sufficient details provided to allow replication of the method development and its use We would like to thank you for the insightful comments and suggestions for improvements. We have revised the article in order to take all comments into account. We thus hope that this new version takes into account the remarks and answers the questions raised.
In summary, we have made the following changes: We have added all the queries presented in the article to the BioQuery3 interface online, (available at biosoda.expasy.org), Section "Information on Homologous Gene queries", making it easier for readers to try them out directly without requiring copypasting the SPARQL queries from the text of the article. Furthermore, we have also created clickable links that point users directly to the corresponding query results in the relevant SPARQL endpoint webpage, in the form of purl.org/orthology/q0 to purl.org/orthology/q9, where the ids Q0-Q9 correspond to the queries presented in the "Protocols" section.

○
We have added a subsection "Applicable Ontologies", in the "Materials" section, explaining the ontologies relevant to the orthology domain, used by the four data sources described in the article (OMA, OrthoDB, MBGD and EBI).

○
We have improved the explanations regarding the choice of relevant IRIs for formulating SPARQL queries targeting the orthology domain, while clarifying the specific challenges of querying orthology data with SPARQL.

○
We have improved the OrthoDB data model figure with small corrections.

○
We have included a subsection about "retrieving OrthoDB pairwise orthologs".

○
The following paragraphs list the issues identified by you, along with our corresponding answers. Below we provide detailed answers to your comments.

Authors:
To improve understandability we have added better explanations and citations throughout this article (see further details in the answers below).
At the first example in "Data models" section (page 4), the authors should add some explanation about how to make a query based on a given RDF graph (with some figure). Such an explanation in addition to the RDF graphs of the actual databases can help understand the subsequent SPARQL codes.

Authors:
We have added a new figure in the beginning of the "Data Models" section as well as an explanation regarding how to write a basic SPARQL query starting from this (simplified) graph model. We now also refer readers to an introductory book chapter we recently published on the topic.
Here, protocols are shown for extracting three types of homology/orthology information: pairwise orthologs, homologous groups, and hierarchical orthologous groups (HOGs), but the exact definitions of the extracted information are not clearly given. Moreover, the specifications of the protocols including their purposes and outcomes are not clearly explained. In fact, all of these protocols retrieve some kinds of pairwise homology/orthology relationships of a given UniProt entry, but the differences of them are not very obvious. Therefore, it is not easy for readers to understand these protocols exactly, and even impossible to check the correctness of the code, without any appropriate explanation.

Authors:
We agree that the terminology is confusing. In fact, in the meantime, we have published a separate F1000 paper which introduces the various types of orthologs used in OMA (https://f1000research.com/articles/9-27). We now refer to this, and have also added better explanations of the retrieved results for each query type (e.g. pairwise orthologs, homologous groups, and HOGs). To check the correctness of the retrieved results, the reader has to rely on potentially more time consuming alternative solutions provided by each independent database (e.g. RESTful APIs, Python libraries) or perform interactive searches on the omabrowser.org website.
Related but somewhat minor comment: homologous group considered here seems to correspond to orthologous group that contains only orthologs and in-paralogs, while I think homologous group can generally also contain out-paralogs.

Micelio, Antwerp, Belgium
The authors describe how RDF and SPARQL can be instrumental in combining various resources with knowledge on homologs. The authors take the readers by the hand through some well thought examples of SPARQL queries. They have selected four resources. OMA, OrthoDB, EBI and MBGD. For each resource SPARQL queries are given. The paper is well written and a welcome contribution to the field. However, there are some issues: The paper could be improved with a section on applicable ontologies. This maybe as a subsection under materials, where the authors list the resources. Similarly, the used underlying ontologies/controlled vocabularies could be addressed. They are implicitly described in the data model sections, but since this is paper is also presented as a guideline on how to apply SPARQL, it would help the reader to understand how IRIs which are core to the semantic web are selected.
Maybe also describe which ontologies in general apply to the narrative of this paper. See Malone et al 1 .
On various places in the paper the authors argue that SPARQL has a steeping learning curve. I disagree, SPARQL is not different from any other query language. I often argue the contrary, i.e. RDF and SPARQL are rather simple to learn. It is nothing more than wrapping your data in triples and select the proper iri's to represent the knowledge. It can't get any simpler. However, identifying the applicable IRIs and finding a balance between creating IRIs and reusing IRIs makes the process difficult.
"Software availability". I would not call a SPARQL endpoint "software". I suggests that the mentioned SPARQL endpoints can be downloaded and installed locally. Maybe change to "online data access"?
The paper would benefit from a software section, though. If possible it would be nice to show some tool integration. Similar to work by Putman T. et.al. 2 where linked data (through Wikidata) is rendered in a webapp.
"If any results are presented, are all the source data underlying the results available to ensure full reproducibility?" I answered partly, because the SPARQL example queries do not always get results. The SPARQL query ran on the SPARQL endpoint of the EBI did not get results (The query under "a) . Retrieving EBI pairwise orthologs"). Would it be possible to add captions and referencable numbers to the queries. The authors suggest to copy and paste the query to the applicable sparql endpoint. This might lead to coding issues, due different keyboard layouts that exist, worldwide. I would recommend using clickable links that lead to either a query (e.g. https://w.wiki/CrW) or its results (e.g. https://w.wiki/CrX).
To deal with this (temporarily?) unavailability of the SPARQL endpoint, I would recommend storing the underlying data as rdf in the github repository which also contains the jupyter notebook mentioned. Or at least a subset big enough to demonstrate the results.
It is than possible to reproduce the results using for example the following python gist ====== from rdflib import Graph localGraph = Graph() localGraph.parse( query = """ SELECT * WHERE { .... ....} """ localGraph.query(query) etc ====== Dear Andra Waagmeester, We would like to thank you for the insightful comments and suggestions for improvements. We have revised the article in order to take all comments into account. We thus hope that this new version takes into account the remarks and answers the questions raised.
In summary, we have made the following changes: We have added all the queries presented in the article to the BioQuery3 interface online, (available at biosoda.expasy.org), Section "Information on Homologous Gene queries", making it easier for readers to try them out directly without requiring copypasting the SPARQL queries from the text of the article. Furthermore, we have also created clickable links that point users directly to the corresponding query results in the relevant SPARQL endpoint webpage, in the form of purl.org/orthology/q0 to purl.org/orthology/q9, where the ids Q0-Q9 correspond to the queries presented in the "Protocols" section.

○
We have added a subsection "Applicable Ontologies", in the "Materials" section, explaining the ontologies relevant to the orthology domain, used by the four data sources described in the article (OMA, OrthoDB, MBGD and EBI).

○
We have improved the explanations regarding the choice of relevant IRIs for formulating SPARQL queries targeting the orthology domain, while clarifying the specific challenges of querying orthology data with SPARQL.

○
We have improved the OrthoDB data model figure with small corrections.

○
We have included a subsection about "retrieving OrthoDB pairwise orthologs".

○
The following paragraphs list the issues identified by you, along with our corresponding answers. Below we provide detailed answers to your comments.

Authors:
We have added the subsection "Applicable Ontologies" in the "Materials" section. We explained the ontologies relevant to the orthology domain used by the four data sources described in the article (OMA, OrthoDB, MBGD and EBI). In particular, we described the Orthology Ontology (ORTH), but also several other controlled vocabularies used across the four data sources, such as GO annotations, the NCBI taxonomy etc.
On various places in the paper the authors argue that SPARQL has a steeping learning ○ curve. I disagree, SPARQL is not different from any other query language. I often argue the contrary, i.e. RDF and SPARQL are rather simple to learn. It is nothing more than wrapping your data in triples and select the proper iri's to represent the knowledge. It can't get any simpler. However, identifying the applicable IRIs and finding a balance between creating IRIs and reusing IRIs makes the process difficult. Authors: We have rephrased the abstract to better point out the specific challenges of querying evolutionary data with SPARQL, in particular, formulating property paths to traverse the hierarchical orthologous groups (HOGs). We have also added the new subsections "Applicable Ontologies" and "Choosing the relevant target gene identifiers in RDF" with improved explanations to identify possible relevant IRIs (for example, based on the applied vocabularies) to compose SPARQL queries in the context of the orthology domain. These queries use UniProt accession numbers as a starting point, and use crossreferences available in each of the four data sources (OMA, OrthoDB, MBGD and EBI), to retrieve relevant data for target genes of interest. "

Authors:
We have created clickable links accordingly. These links point readers directly to the corresponding query results in the relevant SPARQL endpoint webpage. The links are in the form of purl.org/orthology/q0 to purl.org/orthology/q9 where the suffixes q0-q9 after the namespace "purl.org/orthology/" correspond to the Q0-Q9 queries presented in the "Protocols" section (and are clearly marked in the article as such).
To deal with this (temporarily?) unavailability of the SPARQL endpoint, I would recommend storing the underlying data as rdf in the github repository which also contains the jupyter notebook mentioned. Or at least a subset big enough to demonstrate the results.
○ Authors: Given that copying the data fragments to our github repository might lead to several issues due to licensing problems, as well as to data size, we have made available a preview of the results directly in the Jupyter notebook. We have included this explanation in the article. We have also added a clarification regarding the availability of the SPARQL endpoints and the relevant support addresses to contact (the support provided by each database owner) in case of long unavailability.