Again this email is not related to the material sample proposal, but rather to the email quoted below.
Rich, I have been pondering your series of emails and wanted to flesh out in my mind the way that you envision implementing "individual" instances sensu Pyle/Whitton vs. "IndividualOrganism" instances sensu DSW. Once again, I recognize the deficiencies of those term names, but use them for convenience.
As was noted in the previous emails, dwc:individualID was minted as a way to tie together instances of repeated sampling/observing instances. In the 2010 discussion about the creation of a dwc:Individual class, it was noted that an "individual" (sensu vague) could not only tie together multiple occurrences (with "occurrence" defined as an organism recorded at a particular time and place) but also could tie together multiple identifications. In DSW, we can tie a third thing to dsw:IndividualOrganism: physical objects that are removed from the IndividualOrganism and which may constitute part or all of the dsw:IndividualOrganism. (For convenience at the moment, I'm going to talk about dsw:IndividualOrganism as if it were actually an individual organism but recognize that it could also represent some of the taxonomically homogeneous things in nature like herds, clones, and colonies.) So with some variation on what kinds of things one wants to connect to an "individual", an individual instance could be described: - in RDF terms as a node to which other types of resources are linked, and - in database terms as a join between various tables (hopefully I'm using this terminology correctly).
In DSW, we would prefer for there to be a single instance of dsw:IndividualOrganism for each set of resources that one would like to link. To make this more concrete, I'm going to introduce an example that I had already created a few months ago. You can see it at http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase . I'm going to focus on the first example called "Bird at BioBlitz". Although the example is described in detail in RDF, you can just look at the diagram and read the little story to get a feel for the situation. I'm going to use the following convention in talking about the example: the globally unique and persistent identifier for a resource is in angle brackets, e.g. <bird specimen> is the identifier for the bird specimen instance. (The RDF example has assigned actual fake URIs to each resource, but this convention should be easier to follow.) Anyway, you can see that in the example, <bird> is in the role I've just described for dsw:IndividualOrganism. There are two dwc:Identification instances linked to it and one dwc:Occurrence instance linked to it (the occurrence when the bird was shot and collected as a specimen). Although not included in the example, one could link N additional dwc:Occurrence instances to <bird> for instances when the bird was banded, observed, radio-tracked, etc. In the example, <bird specimen> is also linked to <bird>. In this particular case, the whole bird is collected, but one could imagine situations where specimens or material samples were collected without causing the bird to cease to exist in the environment (blood sample, toe clip, collect a feather or whatever). In the example, there is a branching series of derived material objects that came from <bird> which includes: <bird specimen>, <skeleton>, <skin>, <stomach>.
In DSW, these derived material objects are linked to their parent object by a transitive property, dsw:derivedFrom, which has an inverse transitive property, dsw:hasDerivative. In DSW, dsw:derivedFrom/dsw:hasDerivative is not limited to linking physical things to physical things and can be used to link any kind of resource to its parent resource, including information resources such as digital images or DNA sequences. To indicate that a physical thing is derived from another physical thing, we suggest dcterms:hasPart which is not transitive, but one could use other terms that are transitive (I think there is a BFO hasPart term that is transitive). Anyway, the point of using dsw:derivedFrom/dsw:hasDerivative is to get away from having to link multiple resources to the identification instances. We would not say <bird specimen> dsw:hasIdentification <Corvus caurinus> <bird specimen> dsw:hasIdentification <Corvus brachyrhynchos> <skeleton> dsw:hasIdentification <Corvus caurinus> <skeleton> dsw:hasIdentification <Corvus brachyrhynchos> <skin> dsw:hasIdentification <Corvus caurinus> <skin> dsw:hasIdentification <Corvus brachyrhynchos> <image> dsw:hasIdentification <Corvus caurinus> <image> dsw:hasIdentification <Corvus brachyrhynchos> etc.
we would just say that <bird> dsw:hasIdentification <Corvus caurinus> <bird> dsw:hasIdentification <Corvus brachyrhynchos>
and then connect derived things to <bird> using dsw:derivedFrom, e.g. <bird specimen> dsw:derivedFrom <bird> <skin> dsw:derivedFrom <bird specimen>
Because dsw:derivedFrom is transitive, a client could reason <skin> dsw:derivedFrom <bird>
and because dsw:hasDerivative is the inverse of dsw:derivedFrom, a client could also reason <bird> dsw:hasDerivative <bird specimen> <bird specimen> dsw:hasDerivative <skin> <bird> dsw:hasDerivative <skin>
There are many other dsw:derivedFrom and dsw:hasDerivative relationships in the diagram which for brevity I won't mention here, but they are explicitly stated in the Appendices to the example for anyone who is interested.
So the point of this method of organizing resources is to make querying simple. Assuming that a client has inferred all dsw:hasDerivative/dsw:derivedFrom relationships that aren't explicitly stated (by virtue of the inverse and transitive properties), it is a relatively simple matter to construct a query to discover all specimens identified as Corvus caurinus. Set up the query pattern:
?Individual dsw:hasIdentification <Corvus caurinus>. ?Specimen dsw:derivedFrom ?Individual. ?Specimen a dsw:PreservedSpecimen.
and then have the query engine find all instances of ?Specimen that fit the pattern (this query pattern is oversimplified because the identification is actually linked to a taxon concept instance; see real example at end). One could easily change the pattern to find all images of things derived from Individuals, all images of the Individuals themselves, all specimens that come from individuals identified as Corvus caurins and which also have DNA sequences derived from that individual, etc., etc.
If I'm understanding individual sensu Pyle correctly, in the example <bird>, <bird specimen>, <stomach>, <skin>, and <skeleton> would all be typed as individuals and possibly there would be no distinction between <bird> (the living thing that could be the subject of repeated Occurrence instances) and <bird specimen> (the dead bird in a drawer). In contrast, DSW would only type <bird> as dsw:IndividualOrganism and would type the other four things as dsw:LivingSpecimen (or dwctype:LivingSpecimen). From a philosophical point of view, one could take either position - the constraints on "individual" would just be different. As a practical matter, the DSW approach that I described above is desirable if one presupposes that the metadata will be expressed as RDF triples, that clients capable of inferring triples from transitive and inverse properties will be used, and that querying (i.e. SPARQL) will be performed on the triples. If one does NOT presuppose those things and simply lives in a relational database world, then some other approach (possibly the Pyle approach to individuals) might be better.
So what I'm wondering is: what are the advantages of typing <stomach>, <skin>, and <skeleton> as individual sensu Pyle? In the email below, you say "Any Individual can have derivatives that are themselves unique Individual instances." and "Individuals are arranged hierarchically, and certain properties can be inherited up or down the hierarchy, depending on the properties and their associated logical constraints." If someone asserts a third identification for <bird> as "Corvus novum", must that identification be inherited by <stomach>, <skin>, and <skeleton> instances to create additional facts like: <skeleton> dsw:hasIdentification <Corvus novum> <skin> dsw:hasIdentification <Corvus novum> <stomach> dsw:hasIdentification <Corvus novum>
It seems to me like some of the advantage of having some kind of "individual" instance as a central node or connection point gets lost if one starts proliferating related instances of "individual" because it requires duplicating assertions which one makes about one individual instance to all of the other related individual instances.
I have a number of other questions, but I'll stop there in the interest of limiting the scope of this email to one question. If anyone is interested in the actual SPARQL query that corresponds to the example above, I will list it below.
Steve
To try out this actual SPARQL query, follow the instructions on http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase . These instructions give the URL for the triplestore sandbox that already has all of the triples for the example loaded (step 3). They also have the namespace abbreviations for cut and paste in step 4. Here is the actual query to paste below the namespace abbreviations:
SELECT DISTINCT ?Specimen WHERE { ?Individual dsw:hasIdentification ?Identification. ?Identification dsw:toTaxon ?TaxonConcept. ?TaxonConcept tc:hasName ?Name. ?Name tn:genusPart "Corvus". ?Name tn:specificEpithet "caurinus". ?Specimen dsw:derivedFrom ?Individual. ?Specimen a dsw:PreservedSpecimen. } LIMIT 50
Here is another query which finds all images of any kind of resource which is derived from individuals identified as "Corvus caurinus":
SELECT DISTINCT ?Image WHERE { ?Individual dsw:hasIdentification ?Identification. ?Identification dsw:toTaxon ?TaxonConcept. ?TaxonConcept tc:hasName ?Name. ?Name tn:genusPart "Corvus". ?Name tn:specificEpithet "caurinus". ?Resource dsw:derivedFrom ?Individual. ?Resource foaf:depiction ?Image. } LIMIT 50
Richard Pyle wrote:
Hi Markus,
Great question! Particularly because this is exactly the sort of use case we designed our model around.
if you take a tissue sample of the same tree every year, would the
identifier
in individualID be the same for all of them or be different? WIth the
current
dwc:individualID definition it would be the same for all samples. If I understand you correct each sample would have its own "individual" identifier in your proposal? It can't see how you can collapse these two
things
into one definition.
No, that is not how we would handle it.
In our model, there would be one IndividualID to represent the tree, spanning the time period beginning (more or less) when the seed was germinated, until the time at which the entire physical structure of the tree was disintegrated. It is an individual tree.
There would be multiple Occurrence instances, for each time that someone observed or sampled or otherwise wished to document some condition of that tree. All of these Occurrence instances would refer to the same individualID value (i.e., the "tree"). In the example above, this means there would be a different Occurrence instance for each year that a sample is taken -- because in each case, an assertion that the full tree existed at a certain time and place can be made (I understand that trees tend not to move around very much, so the Location for each event associated with each Occurrence would, in this case, remain the same; but the other Event properties -- such as eventID, samplingProtocol, samplingEffort, eventDate, eventTime, startDayOfYear, endDayOfYear, year, month, day, verbatimEventDate, habitat, fieldNumber, fieldNotes, eventRemarks -- would be documented accordingly for each sampling Occurrence instance).
Suppose that the tree is visited every month, but only sampled once per year. In that case, there would be an Occurrence record for every monthly visit. In other words, an Occurrence instance exists regardless of whether a physical sample was made or not. Any in-situ images made of the tree would likewise be associated with the specific Occurrence instance, and each image would represent a separate instance of "Evidence".
Now, let's focus on the annual samplings. Every time a new sample is taken from the tree, at least one new instance of Individual (with a unique individualID value) is created to represent the sample. This sample (individual instance) may be a "gathering" (set of multiple individual specimens gathered at the same time), or it may be a single specimen, or it may be simply a tissue sample intended for destructive analysis. In any case, it's a new individual instance derived from the "parent" individual instance representing the whole tree. In our implementation, "Individual" can be hierarchical, such that a whole-organism tree can be sub-sampled with many "child" instances of "gatherings" (say, one gathering each year), and each gathering may have multiple child "specimen" individuals (e.g. individual botanical sheets created from the multiple items of a single gathering), and each specimen may have further "child" subsamples extracted for DNA analysis (or whatever), and the hierarchy can continue on down to whatever derivatives that people feel a need to keep track of (e.g., aliquot).
The point is, all Individual instances are well-defined physical objects (or well-defined sets of physical objects), and they can be arranged in a n-tiered hierarchy.
Moreover, each Individual that can be characterized as a "sample" (what we refer to as a "CollectionObject") may also have a property value for "CollectionOccurrenceID" -- which refers to the specific Occurrence instance at which the sample was obtained.
So, for example, if the tree is visited on May 27, 2013 and a specimen (sample) is taken, then:
- An Event instance is generated to represent the event where the tree was
visited; 2) An Occurrence instance is generated, which refers to the new EventID, and the existing IndividualID for the whole tree, and includes whatever other Occurrence properties are relevant for the tree at the time of this Occurrence 3) An Individual instance is generated for the specimen, which has a property value for parentIndividualID that refers to the individualID for the whole tree, and a property value for collectionOccurrenceID that refers the Occurrence instance where the specimen was collected.
So, to summarize the answer to your question:
- There are multiple Occurrence instances that refer to the same Individual
instance representing the whole tree (and, hence can be collapsed to the same IndividualID value).
- Any Individual can have derivatives that are themselves unique Individual
instances.
- Individuals are arranged hierarchically, and certain properties can be
inherited up or down the hierarchy, depending on the properties and their associated logical constraints.
At some point, I will assemble a set of other specific use cases, and how we manage them through our use of the "Individual" instance (although I will probably not use the word "Individual", as this seems to cause too much confusion in these discussions).
Aloha, Rich
.