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

[John Deck]

Since the original proposal was from a group of folks, we decided to put
our heads together to construct a general response to the various issues
and ideas expressed on this thread.


John Deck for Rob Guralnick, Ramona Walls, and John Wieczorek


In the text of the  issue submitted for MaterialSample (
https://code.google.com/p/darwincore/issues/detail?id=167) we noted cases
where the current basisOfRecord terms pertaining to the Occurrence class
(Occurrence, PreservedSpecimen, LivingSpecimen, FossilSpecimen,
HumanObservation, MachineObservation) do not adequately cover certain
cases, including: environmental sample (for metagenomic analysis),
transcriptomes (measuring genes but not taxa), and destructive samples
(e.g. tissues destructively sampled in order to generate genomic DNA).  The
term we borrowed from OBI (http://purl.obolibrary.org/obo/OBI_0000747) is
broad enough to be utilized across various cases that fulfill our criteria
while still maintaining a consistent, clear and human understandable
meaning.  For our purposes, we can think of “Material Sample” as any type
of matter that we can use in order derive further evidence needed for
identifications, and taxa, whether it is taxonomically homogenous,
heterogenous, a single individual, sets of individuals, or populations.

How is MaterialSample different from Individual?  The intent of
individualID is fairly clear:  since an Occurrence represents an organism
at a place and time (per Markus’ email), the individualID term allows us to
assign an instance identifier for a particular organism that can be present
in multiple events. MaterialSampleID, on the other hand, is intended to
allow users to say that the basis of an occurence is a material entity
(i.e. matter) that has been sampled according to some particular method.
Whether or not this material entity is an individual (sensu individualID in
DwC) is an independent axis of classification. As was already pointed out,
there is no restriction on specifying that an occurence is associated with
more than one type, so any occurrence can have both an individualID and a
materialSampleID.

We maintain our position on the proposal for MaterialSample as a value for
the basisOfRecord, with an associated materialSampleID to identify
instances of them. Per Steve’s initial comments, we have already withdrawn
the proposal for a MaterialSample class distinct from that in the Darwin
Core type vocabulary, which should make it easier to evaluate the
implications of what we’re discussing.

********************

NOTES, MaterialSample from OBI:

OBI has fairly broad definitions of samples & specimens that are meant to
be utilized across many different scientific activities.  Material Sample
is defined as a “material entity that has the material sample role”, while
a material sample role is defined as “ a specimen role borne by a material
entity that is the output of a material sampling process”, and a material
sampling process is “a specimen gathering process with the objective to
obtain a specimen that is representative of the input material entity”.





On Mon, May 27, 2013 at 11:59 PM, Richard Pyle <deepreef at bishopmuseum.org>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
>
>


-- 
John Deck
(541) 321-0689
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20130529/b503f764/attachment.html