[tdwg-content] New Darwin Core terms proposed relating to material samples

[Steve Baskauf]

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:
> 1) 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
>
>
> .
>
>   

-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 351634
Nashville, TN  37235-1634,  U.S.A.

delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235

office: 2128 Stevenson Center
phone: (615) 343-4582,  fax: (615) 322-4942
If you fax, please phone or email so that I will know to look for it.
http://bioimages.vanderbilt.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20130601/0845dcdf/attachment.html