<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Again this email is not related to the material sample proposal, but
rather to the email quoted below.<br>
<br>
Rich,<br>
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. <br>
<br>
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:<br>
- in RDF terms as a node to which other types of resources are linked,
and<br>
- in database terms as a join between various tables (hopefully I'm
using this terminology correctly).<br>
<br>
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
<a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase">http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase</a> . 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>. <br>
<br>
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 <br>
<bird specimen> dsw:hasIdentification <Corvus caurinus><br>
<bird specimen> dsw:hasIdentification <Corvus
brachyrhynchos><br>
<skeleton> dsw:hasIdentification <Corvus caurinus><br>
<skeleton> dsw:hasIdentification <Corvus brachyrhynchos><br>
<skin> dsw:hasIdentification <Corvus caurinus><br>
<skin> dsw:hasIdentification <Corvus brachyrhynchos><br>
<image> dsw:hasIdentification <Corvus caurinus><br>
<image> dsw:hasIdentification <Corvus brachyrhynchos><br>
etc.<br>
<br>
we would just say that<br>
<bird> dsw:hasIdentification <Corvus caurinus><br>
<bird> dsw:hasIdentification <Corvus brachyrhynchos><br>
<br>
and then connect derived things to <bird> using dsw:derivedFrom,
e.g. <br>
<bird specimen> dsw:derivedFrom <bird><br>
<skin> dsw:derivedFrom <bird specimen><br>
<br>
Because dsw:derivedFrom is transitive, a client could reason<br>
<skin> dsw:derivedFrom <bird><br>
<br>
and because dsw:hasDerivative is the inverse of dsw:derivedFrom, a
client could also reason<br>
<bird> dsw:hasDerivative <bird specimen><br>
<bird specimen> dsw:hasDerivative <skin><br>
<bird> dsw:hasDerivative <skin><br>
<br>
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.<br>
<br>
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:<br>
<br>
?Individual dsw:hasIdentification <Corvus caurinus>.<br>
?Specimen dsw:derivedFrom ?Individual.<br>
?Specimen a dsw:PreservedSpecimen.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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><br>
instances to create additional facts like:<br>
<skeleton> dsw:hasIdentification <Corvus novum><br>
<skin> dsw:hasIdentification <Corvus novum><br>
<stomach> dsw:hasIdentification <Corvus novum><br>
<br>
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.<br>
<br>
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.<br>
<br>
Steve<br>
<br>
To try out this actual SPARQL query, follow the instructions on
<a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase">http://code.google.com/p/darwin-sw/wiki/BioBlitzUseCase</a> . 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:<br>
<br>
SELECT DISTINCT ?Specimen WHERE {<br>
?Individual dsw:hasIdentification ?Identification.<br>
?Identification dsw:toTaxon ?TaxonConcept.<br>
?TaxonConcept tc:hasName ?Name.<br>
?Name tn:genusPart "Corvus".<br>
?Name tn:specificEpithet "caurinus".<br>
?Specimen dsw:derivedFrom ?Individual.<br>
?Specimen a dsw:PreservedSpecimen.<br>
}<br>
LIMIT 50<br>
<br>
Here is another query which finds all images of any kind of resource
which is derived from individuals identified as "Corvus caurinus":<br>
<br>
SELECT DISTINCT ?Image WHERE {<br>
?Individual dsw:hasIdentification ?Identification.<br>
?Identification dsw:toTaxon ?TaxonConcept.<br>
?TaxonConcept tc:hasName ?Name.<br>
?Name tn:genusPart "Corvus".<br>
?Name tn:specificEpithet "caurinus".<br>
?Resource dsw:derivedFrom ?Individual.<br>
?Resource foaf:depiction ?Image.<br>
}<br>
LIMIT 50<br>
<br>
Richard Pyle wrote:
<blockquote cite="mid:00d801ce5b25$6cbbd610$46338230$@bishopmuseum.org"
type="cite">
<pre wrap="">Hi Markus,
Great question! Particularly because this is exactly the sort of use case
we designed our model around.
</pre>
<blockquote type="cite">
<pre wrap="">if you take a tissue sample of the same tree every year, would the
</pre>
</blockquote>
<pre wrap=""><!---->identifier
</pre>
<blockquote type="cite">
<pre wrap="">in individualID be the same for all of them or be different? WIth the
</pre>
</blockquote>
<pre wrap=""><!---->current
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->things
</pre>
<blockquote type="cite">
<pre wrap="">into one definition.
</pre>
</blockquote>
<pre wrap=""><!---->
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
.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>