Rod Page has assembled a knowledge graph that incorporates a classification of the Australian fauna (via the Atlas of Living Australia), associated taxonomic names and publications (from the Australian Faunal Directory), augmented by data from BioStor (Page 2011) and the Biodiversity Literature Repository (Egloff et al. 2017). For details of the construction of this knowledge graph ("Ozymandias") see Page 2018. Additionally, a web interface is available at https://ozymandias-demo.herokuapp.com. Ozymandias contains only a subset of the elements included in the biodiversity knowledge graph illustrated in Page 2016, so for the workshop Page investigated adding additional entities such as GBIF specimen data, GenBank records, and DNA barcodes. Specimens were of particular interest, given that Steve Baskauf has done extensive work on representing Darwin Core occurrence records in RDF (Baskauf and Webb 2016), and having specimen data would expand the set of questions that could be asked using the knowledge graph. For example, Fontaine et al. 2012 reported that the average lag time between the discovery of a specimen representing a new species and the description of that species is 21 years. Having specimen data in Ozymandias would enable us to see whether this pattern also applied to the Australian fauna.

The hosts of the workshop at Agriculture and Agri-Food Canada (Joel Sachs, James Macklin, Jocelyn Pender, Beatriz Lujan-Toro) are working on an Integrated Flora of Canada resource, based on their Semantic MediaWiki representation of Flora of North America (Pender et al. 2018, floranorthamerica.org). Although desperately needed, a Flora of Canada does not exist. The Integrated Flora of Canada project seeks to replace the laborious process of composing a de novo Canadian Flora by mashing together pre-existing data sources and curating these to produce up-to-date, ontology-driven, dynamic treatments. To achieve this, the team is parsing botanical treatments into machine readable qualitative and quantitative properties that can be queried and exported en masse within the Integrated Flora (Cui 2010). The goals at the workshop for the Integrated Flora of Canada were to explore the use of Wikidata or Wikibase as a technology for the data store and to investigate the integration of existing biodiversity data (i.e., sequence, soil microbiome, habitat data).

Zacchaeus Compson is leading a project that aims to create trait-based food webs (or heuristic food webs) by combining taxa lists generated from DNA metabarcoding with traits that are found in literature using text mining. Visualizing food webs requires knowledge of taxa and their trophic habits, but sampling limitations and a lack of readily available prior knowledge make this challenging. Recent advances in genomics and computational analysis show promise for overcoming some of these challenges. Using DNA to characterize the composition of communities can be effective because it is non-invasive, sensitive, and provides a standardized detection method that circumvents the need for trained taxonomists. Meanwhile, text-mining provides a method for targeted data-mining, allowing trait data to be gathered for specific taxa across large PDF databases (e.g., Google Scholar, Web of Science). We used a scalable engine for semantic automatic discovery and integration to query online databases for knowledge on benthic macroinvertebrate traits (e.g., trophic links, body size). Previously, we have generated heuristic food webs using taxon lists from matched DNA and morphology samples for the Peace and Athabasca River deltas in the Mackenzie Basin, Alberta, Canada, and have explored how metrics of these food webs vary through space and time. In Compson et al. (2018), we describe both text mining and trait-based food web pipelines that can be used for rapid construction of heuristic food webs. For this workshop, we explored ways of integrating the pairwise contingency matrix generated from our food web pipeline with information from other existing databases in order to make knowledge graphs for these trait-based food webs.

The biggest challenge in adding specimen data ("occurrences") to Ozymandias is deciding how to model occurrences. One approach is to treat occurrence records as "flat" data structures, in much the same way that occurrence data is currently served by GBIF. Existing RDF providers, such as members of the Consortium of European Taxonomic Facilities (CETAF), adopt this approach (Güntsch et al. 2017). In contrast,  describe a more elaborate model of an occurrence that separates entities, such as events, localities, identifications, and specimens. This is the model that Page adopted during the workshop, and a small number of GBIF records for type specimens were added to Ozymandias. A SPARQL query was devised to compute the difference in dates between the type specimen of a species being collected and the date the species description was published. For example, the species Amplirhagada cambridgensis Solem was described in 1988 (Solem 1988) and there is a paratype specimen in GBIF that was collected in 1984 (https://www.gbif.org/occurrence/1065115500); hence, the lag between species collection and description was four years (Fig. 1).

Figure 1.  

Screenshot of Ozymandias displaying information for the snail Amplirhagada cambridgensis (taxon https://bie.ala.org.au/species/urn:lsid:biodiversity.org.au:afd.taxon:3b488c3b-b55c-47ef-b624-43d1038c6e6d). The data in this display is generated from SPARQL queries to the underlying knolwedge graph. The addition of occurrence data from GBIF in this workshop makes it possible to compute the lag between species collection and description (in this case four years).

At the workshop, the Integrated Flora of Canada team developed a wish list of data integrations for the future platform, explicitly outlining identifier and data providers. In addition, we worked on developing federated SPARQL queries that used Wikidata and Uniprot SPARQL endpoints to discover and collect sequence and reference data. Using these queries as a starting point, discussions around the added capabilities of a flora with up-to-date sequence and reference information ensued. For example, with updated references, one could construct a reference timeline. This would allow us to ask questions such as, “is research on a particular taxon still ongoing?”, and if so, “who are the current experts?” This has applications for directing treatment revisions to the most appropriate botanists.

Additionally, one of the outcomes for the Integrated Flora of Canada project was clarifying its value proposition. There are many services available online that aggregate data from elsewhere. What the Integrated Flora of Canada provides, beyond aggregating relevant resources, is parsed morphological data from flora documents, which we are currently working to prepare. Once complete, the user will be able to query quantitative and qualitative properties (e.g., leaf coloration), across all taxa represented in the flora.

Stimulating discussions about the future of floras were also part of the workshop. For example, how far away are we from automatically generated floras using existing data sources? Can we generate treatments on the fly as a database query?

Lastly, we hacked at our existing Flora of North America data to convert it into RDF and to experiment with Metaphactory as a platform for hosting our data.  The source data was an XML file Suppl. material 1) used to generate a text version of a floral treatment through the Semantic MediaWiki platform. Because the data were in XML format, it was relatively easy to use an XQuery script (Suppl. material 2) to convert the data to RDF/XML (Suppl. material 3). Once the RDF file was loaded into Metaphactory, it could be queried using the SPARQL interface.  For example, the following query could be used to determine which taxa had yellow petals.

PREFIX bios: <http://www.github.com/biosemantics/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    SELECT DISTINCT ?name ?description
    WHERE { 
        ?treatment rdfs:label ?name. 
        ?treatment bios:hasMajorPart ?major.
        FILTER(CONTAINS(?description, "yellow"))
        OPTIONAL { 
            ?major bios:majorDescription ?description. 
            ?major bios:majorName "petals". 
        } 
        OPTIONAL { 
            ?major bios:hasMinorPart ?minor. 
            ?minor bios:minorDescription ?description. 
            ?minor bios:minorName "petals". 
        }
    }

One appealing feature of the Metaphactory platform is that it can generate graph diagrams from data based on screening criteria specified by graph patterns in SPARQL CONSTRUCT queries.  To generate the diagram, a page is created using Metaphactory's semantic-map page template by enclosing the query within a <semantic-graph> XML element:

<semantic-graph height="1000" query="
      [insert query here]
"></semantic-graph>

In doing this, we were able to generate a diagram visualizing the paths that one could take to arrive at a determination using the Cucurbitaceae key present in the treatment (Fig. 2).  

Figure 2.  

Graphic representation of the key of the family Cucurbitaceae from the Flora of North America treatment.

The primary limitation of modelling our data in RDF was the inability to order nodes (i.e., we were unable to designate the 1st discussion node, 2nd discussion node, and 3rd discussion node in order). However, we learned what Metaphactory could afford us in terms of semantic property searches, including semantic auto suggestion, faceted search and exploration of item collections, and translation of keyword queries into SPARQL queries.

In order to use the Metaphactory tools to visualize food web data from the Peace-Athabasca Delta, it was necessary to convert data from several spreadsheets into RDF.  Within the spreadsheets, some columns contained identifiers linking the described consumer to known resources. Other columns contained metadata about the consumers and resources.  Whenever possible, the metadata columns were mapped to well-known vocabulary terms in the Darwin Core, Dublin Core, or RDF Schema (RDFS) vocabularies. After establishing the mappings, an RDF graph was created for each spreadsheet using CSV to RDF conversion software (Baskauf 2016a). 

The specific data converted to RDF is shown in Figs. 3 through 6. The spreadsheet containing basic data about genera included in the study included columns whose headers are shown in the table at the lower left of Fig. 3.  That table shows how each column was mapped to standard terms that served as predicates of the RDF triples. The Turtle serialization at the lower right shows how data for one row of the table (for the genus Anax) was converted to RDF. In order to create valid RDF, fake URIs were created by appending the genus name to the made-up namespace "http://unb.ca/taxa/". Fig. 3 shows part of the graph in diagram form, with most of the literal-value properties omitted. Another spreadsheet contained columns of notes about the genera. Since all columns were essentially equivalent comments about the genus, all of the columns were mapped to rdfs:comment properties (Fig. 4).

Figure 3.  

Graph generated from CSV spreadsheet containing data about genera.

Figure 4.  

Graph generated from CSV spreadsheet containing notes about genera

The food web data were collected during sampling events (i.e., collected at a particular location on a particular date; see Compson et al. 2018 for details). A CSV table with two columns related genera to the event at which they were observed. The link from event to genus present was made with a made-up predicate "unb:hasGenus", and a fake URI for the event was made by appending the event code to the namespace "http://unb.ca/sample/". The graph resulting from this spreadsheet is illustrated in Fig. 5.

Figure 5.  

Graph generated from CSV spreadsheet detailing genera present at sampling events.

The actual food web relations were contained in a fourth CSV table.  Each row of the table documented a known predation relationship, with columns stating the participants in the relationship (consumer and resource), a code for the source of the information, and a locally unique identifier for the relationship. The predation relationship was defined in RDF by linking the predation event to the consumer via the made-up predicate "unb:consumer" and to the resource it consumed by the made-up predicate "unb:resource". An example of one predation relationship is shown in Fig. 6, along with the RDF/Turtle serialization of the portion of the graph that was diagrammed.

Figure 6.  

Graph constructed from CSV file containing observed comsumption relationships among genera.

After each of the CSV spreadsheets was converted to RDF/Turtle, the four graphs were loaded into the Metaphactory triplestore to create a single graph that was the union of the four graphs.  A small portion of the merged graph is shown in Fig. 7.  In the figure, each of the diagrams in Figs 3, 4, 5, 6 are highlighted in different colors to show how the four individual spreadsheets contributed to the overall knowledge graph.

Figure 7.  

Food web knowledge graph formed from the union of the graphs generated from four spreadsheets.

Once the four RDF/Turtle files generated from the spreadsheets were loaded into the Metaphactory triplestore, it was possible to construct SPARQL queries to ask questions that could not be answered by examining a single spreadsheet. For example, the query in Fig. 8 asks what genera of food resources known to be utilized by the genus Anax were observed at sampling events with Anax

Figure 8.  

Metaphactory SPARQL query interface showing a query to determine what species were eaten by the genus Anax at events where both species were documented as present.

The semantic-graph feature of Metaphactory can be used to create a visualization of all of the predation relationships that might be present among genera that were present in a particular sampling event. For example, a diagram for the Aug2012-11A event can be generated using the following query:

PREFIX unb: <http://unb.ca/vocab/>
    CONSTRUCT {
        ?consumer :eats ?resource.
    }
    WHERE {
        <http://unb.ca/sample/Aug2012-11A> unb:hasGenus ?consumer.
        <http://unb.ca/sample/Aug2012-11A> unb:hasGenus ?resource.
        ?relationship unb:consumer ?consumer.
        ?relationship unb:resource ?resource.
      }

 where :eats is a made-up predicate that connects a consumer directly to a resource.

The resulting visualization is shown in Fig. 9. Although Metaphactory had no problem creating the diagram, there was clearly too much information when the entire food web was displayed, as indicated by the clutter of the resultant figure. However, the visualization was interactive and click-and-drag could be used to drag individual nodes from the mass of nodes to examine individual links in the food web (e.g. Arrenurus eats Callibaetis, Notodromas, and Caenis).

Figure 9.  

Food web visualization showing all species present at one sampling event

We created a more meaningful visualization by restricting the display to parts of the web that met particular criteria. For example, consider the case where genus1 eats genus2, which eats genus3, which eats genus4. For genera present in the Aug2012-11A sampling event, we can ask “in what cases does genus1 also eat genus3 and genus4?” In other words, are there cases where a genus eats broadly down the food chain? To answer this question, we set up the following page template:

<semantic-graph height="1000" query="
PREFIX unb: <http://unb.ca/vocab/>
    CONSTRUCT {
        ?consumer :eats ?resource1.
        ?consumer :eats ?resource2.
        ?consumer :eats ?resource3.
        ?resource1 :eats ?resource2.
        ?resource2 :eats ?resource3.
    }
    WHERE {
        ?relationship1 unb:consumer ?consumer.
        ?relationship1 unb:resource ?resource1.
        ?relationship2 unb:consumer ?consumer.
        ?relationship2 unb:resource ?resource2.
        ?relationship2 unb:consumer ?consumer.
        ?relationship2 unb:resource ?resource3.
        ?relationship3 unb:consumer ?resource1.
        ?relationship3 unb:resource ?resource2.
        ?relationship4 unb:consumer ?resource2.
        ?relationship4 unb:resource ?resource3.
    }
">
</semantic-graph>

Fig. 10 shows that this rarely occurred. By dragging the nodes around, we could identify the cases. Lethocerus eats Blethisa, which eats Chaetogaster, which eats Limnesia, while Lethocerus also eats Chaetogaster and Limnesia lower down on the chain. There were several more cases and we could see that there were also a few cases where this pattern occurred though five trophic levels (e.g. Lethocerus, Sisyra, Blethisa, Chaetogaster, Piona).

Figure 10.  

Food web diagram showing only cases where top-level species ate broadly down the food chain.

These exercises and visualizations illustrate that the utility of Metaphactory as a data exploration tool is only limited by our ability to imagine SPARQL queries that reflect interesting ecological questions that we might want to ask about the food webs. Additionally, Metaphactory’s use as a food web visualization tool is restricted when the amount of information displayed is too great.