Darwin-SW: Darwin Core-based terms for expressing biodiversity data as RDF

2.2.1. Relationships among classes

Many existing biodiversity data are managed as part of relational databases where tables contain data related to particular Darwin Core classes. Figure 1 is an entity-relationship diagram that shows how those tables would be related in a standard relational database under the Darwin-SW model. This diagram shows the most normalized database structure likely to be used by a provider that uses Darwin Core as the basis for its records. The table relationships shown in the diagram using “crow’s feet” notation [7] do not represent cardinality restrictions, but rather the relationship types that are likely to exist between instances of the classes. For example, many Events may be associated with a Location, while the reverse is not likely to be true. The structure of Fig. 1 was influenced30

If a provider with such a relational database chose to expose its data as RDF, each record in a table would be represented as a node in the RDF graph. The cardinality of relationships shown in Fig. 1 indicates the way we would expect arcs to link nodes representing instances of the linked classes. For example, the one-to-many relationship between the Location and Event classes indicates that we expect that a node representing a Location instance could be linked to many Event nodes, and not the reverse. Darwin-SW does not enforce cardinality through object property restrictions; Fig. 1 simply indicates the cardinality expected based on data from typical database implementations.

Section 2.2.2. through 2.2.4. provide additional details about key classes in the model.

A key addition of the DSW model was the inclusion of an Organism class. An instance of the Organism class is not restricted to a single biological organism: it can be any sort of organism, clone, colony, or group of organisms that is typically observed or sampled over time. An additional requirement is that Organism instances should be taxonomically homogeneous because they intended be the objects of taxonomic determinations (i.e. Identification instances). A third feature of an Organism is that it serves as an anchor point for resources derived from it, such as specimens, images, and samples. So although an Organism can be described in conceptual terms by comparison with biological organisms, from the standpoint of the DSW model, an Organism is a node that connects Occurrences, Identifications, and derived resources [1].

The existence of this class was implied by the existing Darwin Core term dwc:individualID which was defined as “An identifier for an individual or named group of organisms represented in the Occurrence. Meant to accommodate resampling of the same individual or group for monitoring purposes.” The definition of dwc:individualID suggested features that were incorporated in the DSW concept of Organism. During the public comment on the proposal to add the class to Darwin Core, the necessity for taxonomic homogeneity was recognized. On 2014-10-26, the dwc:Organism class, which has the features described in this section, was added to Darwin Core and the term dwc:individualID was deprecated in favor of dwc:organismID.31

The Darwin Core Occurrence class (dwc:Occurrence) originally functioned effectively as a superclass of specimens and observations. However, in the email discussion it was clear that many participants favored a more abstract notion of Occurrence as an organism at a time and place. This notion resulted in the placement of Occurrence between Organism and Event in the DSW model. On 2014-10-26, the definition of dwc:Occurrence in the Darwin Core standard was changed to reflect the more abstract notion. A more exact definition of Occurrence that places it in an OBO-style32

Taxa are an important component of any biodiversity model and significant effort has been expended towards defining the meaning of the terms “taxon” and “taxon concept” [5]. The TDWG Taxon Concept Transfer Schema (TSC) standard33

2.3.1. Properties linking to agents

In addition to the object properties intended to link its main classes, DSW also makes use of the object properties dwciri:georeferencedBy, dwciri:recordedBy, and dwciri:identifiedBy, which DSW asserts to have non-literal ranges (foaf:Agent) and which are analogues of the Darwin Core literal value terms dwc:georeferencedBy, dwc:recordedBy, and dwc:identifiedBy.

OPEN IN VIEWER

Fig. 2.

Properties used to link evidence to key classes in the Darwin-SW model. Bold arrows are transitive dsw:derivedFrom properties. Dashed arrows are object properties that link to supporting evidence. For clarity, inverse object properties are not shown. rdf:type assertions are shown in gray. bio: is an abbreviation for the real namespace http://bioimages.vanderbilt.edu/. ncu: represents a fake namespace that contains identifiers for specimen images. See Fig. 4 in the Appendix for a serialization of this graph.

A key innovation of Darwin-SW is the recognition of the role of evidence in documenting the occurrences and identifications of organisms. DSW recognizes organism-related evidence by explicitly defining the class dsw:Token. A Token is essentially a physical, digital, or conceptual voucher that provides some kind of evidence about an Organism. A Token may be part of the Organism or the Organism itself in living or preserved form (i.e. as a specimen). It may also be an image, sound, sample, DNA sequence, or human or machine observation.

Tokens are linked to the Organism from which they originated by the transitive object property dsw:derivedFrom and its inverse dsw:hasDerivative (Table 2, Fig. 2). Thus dsw:derivedFrom serves as a mechanism for documenting the provenance of diverse resources used as evidence. A wide variety of types of resources can serve as evidence and most Token instances will have one or more additional rdf:type declarations. There is also an expectation that the Token or at least the metadata about that Token will be preserved and made accessible to anyone who may want to verify the assertions made about the Organism, its Occurrences, and its Identifications.

DSW defines two pairs of object properties that can be used to indicate the evidence on which an assertion about an occurrence is based (Table 2; Fig. 2). dsw:hasEvidence and dsw:evidenceFor link an Occurrence to a Token that vouches for the recording of the Occurrence. Several forms of evidence (e.g. images, material samples, and specimens) may be archived to document a single Occurrence. In this way, the time and place metadata (inherent in the Occurrence) for the Tokens can be efficiently shared. dsw:idBasedOn and dsw:isBasisForId link an Identification to a Token that was used to make a taxonomic determination. Zero to many Tokens may be linked as the basis for an identification (with zero representing the case where there is no known token preserved to document the Identification).

3.3.1. Linking duplicates

It is common practice in the collections community to collect multiple specimens from the same organism, colony, or local population (a taxonomically homogeneous entity and therefore a dwc:Organism). Such specimens are called “duplicates”. They are often distributed to other institutions to safeguard records of occurrence and as a courtesy to help build collections. Linking of duplicates is an important use case that has been addressed by projects such as FilteredPush35

Unfortunately, records of duplicate exchanges are often poor, particularly when the specimens are old. This creates a problem when new information is linked to one duplicate without the knowledge of other institutions holding duplicates.

Despite the colloquial meaning of the word “duplicate”, it would be incorrect to assert equivalence between duplicate specimens since they are distinct entities with different post-collection histories. But because of the nature of the origin of duplicate specimens, it would be correct to state that each duplicate was derived from a single Organism, and it would be appropriate to link each duplicate to the same Organism instance using dsw:derivedFrom. Similarly, it would also be appropriate to link each duplicate to the same Occurrence instance using dsw:evidenceFor if the collection time and location of the duplicates were the same.

For example, if Provider 1 described a specimen like this:

Provider 2 could assert that another specimen was a duplicate using:

If the specimen were collected from the same Organism but as part of a different Occurrence (i.e. at a different time and possibly a different place), Provider 2 could create a different Occurrence instance while still asserting a dsw:derivedFrom relationship to the same Organism.

In a case where the duplicate status were initially unknown, it would be likely that each institution that databased one of the duplicate specimens would mint a separate URI for the Organism from which its specimen was derived. A later discovery that the specimens were duplicates would imply that the two Organism URIs were simply different identifiers for the same resource.

Two URIs identifying an identical resource can be linked using the predicate owl:sameAs. The semantics of owl:sameAs37

For example, Provider 3 might have described a specimen in its collection like this:

If Provider 3 discovered later that the specimen was a duplicate documenting the same Occurrence as Provider 1’s specimen, it could document that discovery by making the following assertions:

If the specimen were collected from the same Organism, but at a different time or location, Provider 3 could indicate that by asserting only:

Documenting duplicates in this way creates links that facilitate discovery of any new information related to the linked resources. For example, if a new taxonomic determination were made based on Provider 1’s specimen:

Providers 2 and 3 could discover this new information related to their specimens because their specimens were linked to the same Organism instance. The following section describes methods that can be used to make such discoveries.

Organisms and specimens have increasingly become the source of a variety of derived resources obtained through physical and electronic means. Tissue samples, DNA sequences, digital images, telemetry, digital sound recordings, and video may be generated directly from organisms or from resources derived from organisms. As they are generated, these resources may pass to new institutions, and new metadata about the resources may be created without the knowledge of holders of related resources.

The object property dsw:derivedFrom is used to link an organism-derived resource to its parent resource, which may be either an Organism or another organism-derived resource. In essence, dsw:derivedFrom provides generic way to track the provenance of organism-related resources by establishing links from them to each of their ancestral resources. Other class-specific terms such as foaf:depicts or dcterms:isPartOf can be used to establish more specific kinds of relationships with parent resources.

In Fig. 2, the specimen image is linked to its parent specimen by the triple:

and that specimen is linked to its parent Organism (a tree) by the triple:

A reasoner can infer the triple

which links the specimen image directly to its more distant ancestor (the tree) based on the transitivity of dsw:derivedFrom. Since a properly designed SPARQL query can construct triples for entailed but unexpressed dsw:derivedFrom relationships, those triples can be added to a large multi-institution graph efficiently by a client designed to conduct a limited set of reasoning tasks. In SPARQL 1.1, arbitrary length path matching can be used to traverse chained dsw:derivedFrom links without materializing every possible entailed relationship, making it easier to take advantage of the transitivity. For example, the query:

would find all resources derived from the Organism in Fig. 2.

One implication of the transitivity of dsw:derivedFrom is that a reasoner will infer a dsw:derivedFrom relationship from a resource to every ancestral resource from it up to the original Organism. Similarly, a reasoner will infer dsw:hasDerivative relationships from an Organism to every descendant resource that is linked to the Organism though a chain of explicit parent/child dsw:hasDerivative links. This creates a powerful tool for querying because once a reasoner has constructed triples for all entailed dsw:derivedFrom and dsw:hasDerivative relationships, it becomes a simple matter to conduct queries that apply to all derivatives of a particular Organism. For example, this simple query:

would discover new resources derived from the Organism in Fig. 2 that were created after the beginning of 2012.

This is an uncomplicated illustration because it involves a single Organism with few dsw:derivedFrom links. However, variations on this approach provide a powerful way to discover less apparent information in situations that are more complex. For example, a provider of images of organisms or organism specimens would be interested in knowing if organisms from which its images were derived had been assigned new determinations. It would probably be unaware of those determinations if they were based on some evidence other than an image in its collection (e.g., based on specimens held elsewhere). This query:

would discover any new determinations that were made after the start of 2012 that were relevant to any images in the collection identified by the URI http://biocol.org/urn:lsid:biocol.org:col:15495. This would include determinations for duplicate specimens if they were linked as described in Section 3.3.1. The image provider could discover a new determination made based on a duplicate specimen without the holder of the duplicate even knowing that the provider’s image existed.

OPEN IN VIEWER

Fig. 3.

Diagram of a graph structure that can be used to represent observations of organisms that also have identifications. Note that the diagram shows links between instances of classes, but for simplicity only the class URIs of those instances are indicated in the ovals. rel:has_part is an abbreviation for http://purl.obolibrary.org/obo/BFO_0000051 and rel:bearer_of is an abbreviation for http://purl.obolibrary.org/obo/RO_0000053. See Section 4 of the text for more details.

In these two examples, the chain of derived resources was relatively short. However, one can imagine realistic scenarios where the chain of derived resources was much longer. For example, consider a bird that is captured and banded by Institution A. A tissue sample collected during the capture is sent to Institution B which extracts and sequences DNA, with the sequence deposited in the repository of Institution C. At a later time the bird is found dead and given to Institution D which accessions the bird skin and associates the specimen with the earlier collection event based on the information on the band. Institution D loans the skin to Institution E, where an expert makes a determination based on comparison with other skins in the collection at Institution E. If each institution linked its resource to the parent resource from which the institution’s resource was derived using dsw:derivedFrom, and if the graphs of metadata from all institutions were merged, a reasoner could link all descendant resources directly to the bird Organism instance. Institution C’s DNA sequence repository could use a simple query similar to the examples in this section to discover the determination made at Institution E without tracking or even knowing about the intervening chain of resources between its sequence and the determination.

These examples illustrate how a relatively uncomplicated set of RDF properties combined with simple queries can discover kinds of information that would be very difficult to track using conventional database methods. The challenge therefore becomes more social than technological since the barriers to achieving that kind of discovery require community efforts such as adoption of standard vocabularies, commitment to persistent URI identifiers, reuse of identifiers assigned by others, and establishment of a consensus triple store into which graphs from various institutions would be merged.