<!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">
For those of you who triage emails and don't read long emails, the
bottom line is that although I agree with some of Rich's points, I
think that the suggestion that parts of Individuals should be
classified as Individuals does not fit the definition that is on the
table for the proposed class dwc:Individual. I argue that allowing
pieces of organisms to be called Individuals defeats the purpose of
having the Individual class. I suggest an alternative approach that I
think is the most straightforward method of separating tokens from the
occurrences they document. The acceptance or rejection of Individual
as a new class does not hinge on my suggested approach. Development of
a system to handle more complicated resource relationships can take
place independently of the proposal for the Individual class.<br>
<br>
Responses inline below:<br>
<br>
Richard Pyle wrote:
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">...<br>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">previousIdentifications
</pre>
</blockquote>
<pre wrap="">Hmm. I suppose yes, but better to just have
another instance of Identification. Why not?
</pre>
</blockquote>
<pre wrap=""><!---->
When the data are structured that way at the source, yes. But a number of
DwC terms exist because many content sources have not parsed/normalized all
their data to the full extent of the DwC classes. Therefore, I think
previousIdentifications should be kept, and if so, it should be part of the
Individual class.
</pre>
</blockquote>
Got it. It should go with Individual.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">associatedSequences
</pre>
</blockquote>
<pre wrap="">
I suppose you won't agree on this, but I don't see sequences
as any different than other tokens/evidence types that I
think we should allow to document Occurrences. I would like
this term to eventually go away, at least for people using
RDF who will explicitly create resources for tokens and then
type them.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, well I guess "Sequences" per se are functionally equivalent to images,
in that they are not the organism themselves, but rather a representation of
some aspect of the organisms (in this case, a representation of the
molecular structure of the DNA molecules contained within the cells of the
organism, rather than a representation of light waves reflected off the
exterior of an organism in the case of an image, or of x-ray waves
transmitted through an organism in the case of a radiograph image). I was
thinking more in terms of tissue samples -- which I will much more
stubbornly defend as being in the Individual class -- but I guess more in
terms of "individualScope".
</pre>
</blockquote>
OK, as usual you are warping my brain into thinking about things in a
different way. I'm going to separate the issue of "dead" from the
issue of "pieces" (for the moment I'm going to accept that it doesn't
matter if a whole organism is dead or not). The advantage of letting
pieces of the organism be considered as a type of Individual is that it
allows us to avoid creating another class of things called
"PreservedSpecimen" (although in a sense we already have it because of
dwctype:PreservedSpecimen, which when used as a rdf:type would imply
membership in some rdfs:Class called "PreservedSpecimen"). The pieces
could share properties that one might want to also apply to the whole
organism. One could differentiate among the two by the value of
"individualScope". <br>
<br>
But after another long commute to think about this, I'm realizing that
pieces of organisms really must not be Individuals. First of all, the
definition that is under consideration is "The category of information
pertaining to an individual organism or a group of individual organisms
that can reliably be known to represent a single taxon." [the Google
Code entry, with substitution of "taxon" for "species (or lower
taxonomic rank if it exists)" as was discussed]. That definition as it
stands applies to an organism or group of organisms, but does not
include parts of organisms. Obviously the definition could be changed,
but if you consider the comment, which describes the primary function
of Individual: "Instances of this class can serve the purpose of
connecting one or more instances of the Darwin Core class Occurrence to
one or more instances of the Darwin Core class Identification" it
becomes clear that making parts of organisms Individuals defeats this
primary purpose for the term. <br>
<br>
The major selling point for having
Individuals at all is to get out of the business of applying
determinations to all of the pieces of evidence such as specimens,
images, sounds, etc. that get collected
from the same biological individual through multiple Occurrences. This
has the benefit that if one applies an Identification to the
Individual, all physical and information resources that are derived
from the individual automatically get associated with the
Identification and hence the taxonomic informations referenced by the
Identification. If we
call preserved specimens that are pieces of organism Individuals having
a value of
individualScope="part", then do we do the same thing to them as we do
with
Individuals at higher levels, namely apply Identifications to them? If
so, then we are back in the business of assigning Identifications to
all of our derivative resources rather than the biological individuals
from which
they came. If we just say that we'll skip assigning separate
Identifications to the derivative resources, then we have something
that doesn't fit the functional role for which Individual was
designed. In that case an "Individual"
which is an organism part is such a different thing that one might as
well call it as something
else (i.e. a PreservedSpecimen). <br>
<br>
The case of a whole organism (live as a LivingSpecimen or dead as a
PreservedSpecimen) is different because in that case we would have a
single resource serving as the evidence (the whole organism itself).
By definition, there can't be many of those (there would just be one)
and it would already have an Identification assigned to it, because it
is the same Individual that it is providing evidence for. So there is
no superfluous assignment of Identifications in that case. <br>
<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">Here's one thing I'm not so certain about, though. An in-situ image of an
organism is clearly a token of an Occurrence, because it is evidence of the
organism at the place/time. An image of the preserved specimen in a Museum,
or an x-ray, etc., is not really a token of an Occurrence, because it's not
evidence of the organism at the place/time of its capture. Same goes for
Sequences -- they are a token of the Individual organism, not of the
occurrence of the organism at a place and time. This is why I have a hard
time thinking of such things as tokens of an Occurrence, when they are
really more tokens of the Individual.
</pre>
</blockquote>
I think the solution to this is to not call it a "token of the
Occurrence". Let's say that the token is derived from the Individual
and that it MAY serve as evidence for an Occurrence. <br>
<br>
I think that the solution is
something like you suggest: link the chain of derivation of tokens to
the Individual and not to the Occurrence. Then have a reference in the
Occurrence record to the particular token that was created or collected
during the event of the Occurrence. See
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/tree-branch.gif">http://bioimages.vanderbilt.edu/pages/tree-branch.gif</a> . I have had the
tendency of
thinking that the tokens supported the Occurrence, but there does not
need to be just one purpose for the token. They also support the
existence of the Individual. This should probably make you
happy, because the pieces of the Individual (preserved specimens,
tissue samples) would be derived from the Individual. The "provenance"
if you want to call it that, traces the connection of the tokens to the
Individual. The chain of derivation can be traced using the property
that I've called "derivedFrom". The branch specimen is "derivedFrom"
the Individual and the specimen image is "derivedFrom" the specimen.
Your desire to differentiate between things that are physically derived
from the Individual vs. things that aren't can be handled by the
"isPartOf" property. The branch specimen "isPartOf" the Individual
tree, but the image is not a part of the branch. A token could have
both the isPartOf property and the derivedFrom property (if it's a
piece of the Individual), or only the derivedFrom property (if it's
not). <br>
<br>
In this diagram, the term "hasEvidence" is a property of the
Occurrence. It has the branch specimen as its object, but not the
image of the specimen because as you note, the event marking the
creation of the image is not the same as the event documenting the
Occurrence of the Individual (i.e. the collection of the branch
specimen). Either of the "tokens" (the specimen or the image) could be
used as
evidence for the Identification (we could have a property of the
Identification called "basedOn" that could have the specimen, the
image, or both as its object - I did something similar to this in the
Biodiversity Informatics paper). <br>
<br>
Please note that for each of the properties I've listed on the diagram,
there could and probably should be inverse properties (not shown):
hasDerivative for derivedFrom, hasPart for isPartOf, isEvidenceFor for
hasEvidence, and usedIn for basedOn. All of the "tokens" and the
Occurrence could have the property individualID which would relate the
resource directly to the Individual and its Identifications. <br>
<br>
I have created a number of similar charts showing how these
relationships could apply to various types of tokens:<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/tree-branch.gif">http://bioimages.vanderbilt.edu/pages/tree-branch.gif</a> (tree branch
PreservedSpecimen)<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/tree-image.gif">http://bioimages.vanderbilt.edu/pages/tree-image.gif</a> (image of a live
tree)<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/whale-dna.gif">http://bioimages.vanderbilt.edu/pages/whale-dna.gif</a> (tissue sample and
DNA sequence from a whale)<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/bird-observation.gif">http://bioimages.vanderbilt.edu/pages/bird-observation.gif</a> (bird
observation)<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/wildebeest.gif">http://bioimages.vanderbilt.edu/pages/wildebeest.gif</a> (wildebeest calf
captured and put in zoo)<br>
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/botanical-garden.gif">http://bioimages.vanderbilt.edu/pages/botanical-garden.gif</a> (twig
removed and turned into a living specimen in a botanical garden)<br>
<br>
Note that in every case, the "token" is typed based on the kind of
thing that it is. We don't try to make it an Occurrence (my previous
mistake) or an Individual (what I'm saying is Rich's mistake).
Physical things that are a part of the Individual have the special
status of "isPartOf", electronic representations never do. Only the
token that was created during the event associated with the Occurrence
record is connected to the Occurrence record. The token serving as
evidence for the Occurrence can be anything - there is no special class
called "token". In fact, the "token" can be the organism itself if the
organism is curated (John's favorite wildebeest calf in the zoo or a
whole dead fish in a jar). The token can be another individual such as
a living specimen that originates as a clone (maybe also seed) from the
Individual being documented in the Occurrence. We (DwC) only get into
the business of creating types and properties of tokens if they don't
already exist in other vocabularies. DwC needs to do that for
specimens, but not for images that are already covered by MRTG. An
observation may or may not have a token depending on whether there is
some kind of evidence that can be referred to (see bird example). <br>
<br>
In these diagrams a single Occurrence and a single "line" of derived
tokens is shown. But there can be many tokens per Occurrence and many
tokens per Individual. There can also be many Occurrences per
Individual. I didn't try to show this on the diagram because it would
be too complicated. Obviously many users will want to make this
"flatter" and less complicated. But I think this model allows for just
about any kind of relationship among occurrence-documenting resources
that people want to handle. It was the kind of thing I was trying to
do in the Biodiversity Informatics paper (e.g.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/conceptual-scheme-insect.gif">http://bioimages.vanderbilt.edu/pages/conceptual-scheme-insect.gif</a>) but
better because I'm letting the tokens be what they are rather than
trying to force them all to be Occurrences.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">This also assumes that dwc:catalogNumber and dwc:otherCatalogNumbers be
re-assigned to Record-level terms. Was there some reason this isn't
appropriate?
I think it is appropriate because they should be usable with at
least two classes: Individual (for living specimens) and
Occurrences (e.g. preserved specimens, images)
</pre>
</blockquote>
<pre wrap=""><!---->
Hmmm...on that basis, should individualCount and the various tokens also be
Record-level terms -- on the basis that they can apply either to an
Occurrence, or to an Individual? Actually, in the case of DNA Barcodes and
such, isn't it possible to also represent a DNA Sequence as an attribute of
a Taxon as well? If the purpose of Record-level terms is to aggregate terms
that apply to more than one class, then perhaps that is the solution for a
number of these things (including disposition, and maybe even preparation --
depending on how broadly those things are defined)?
</pre>
</blockquote>
individualCount would be metadata that results from an Occurrence, so I
think that's the only place it belongs. Tokens aren't properties of
anything, they are resources in their own right that are connected by
some property term (e.g. hasDerivative/derivedFrom) to an Occurrence in
which
they were collected/recorded and to the Individual from which they
derived (e.g. derivedFrom and hasDerivative). A DNA sequence is
another resource that isn't an attribute of anything. It could be the
object of numerous properties that could have a variety of subjects.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">I haven't said this before, but are we allowing Individuals
to be dead?
</pre>
</blockquote>
<pre wrap=""><!---->
Errr....fossils? Preserved specimens? Are they not Individuals? I know you
think of them in terms of tracking a living organism over time. But that's
only one of the reasons why I support an Individual class (not even the main
reason). To me, the main reason is that an "Individual" represents the
actual organism(s), separate from an Occurrence, which represents the
presence of an organism at a particular place and time.
</pre>
</blockquote>
I think I am prepared to accept this as long as they are the whole
thing and not pieces. There could be some issues with a fossil since
in many cases the tissues of the organism are replaced by minerals.
But there is still a one-to-one relationship, so the problem I
described in the long paragraph above doesn't apply.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">If we put it in a jar of alcohol
and cut it into many separately-cataloged pieces, are
all of the pieces still some of the Individual?
</pre>
</blockquote>
<pre wrap=""><!---->
This is why we need two things for an Individual:
individualScope (which can range anywhere from the aggregates of multiple
individuals, all the way down to the smallest parts of individuals)
</pre>
</blockquote>
See above.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">And, a mechanism to track series of "derived from" Individuals. The ASC
model covered this, I think (right, Stan?)
</pre>
</blockquote>
I didn't see it in the flow chart, but it could be there somewhere. I
had something like this in sernec:derivativeOccurrence and
sernec:derivedFrom (<a class="moz-txt-link-freetext"
href="http://bioimages.vanderbilt.edu/rdf/terms.htm">http://bioimages.vanderbilt.edu/rdf/terms.htm</a>)
when I was making every token an Occurrence. But it's better to do as
you suggest here which is what I did in the examples above. <br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<blockquote type="cite">
<pre wrap="">I think Pete might have been suggesting modeling
things that way with "partOf". What if we cut a
branch from a tree, glue part of it to a page
and turn part of it into a DNA sample that
get sequenced. Are those all a part of an
Individual?
</pre>
</blockquote>
<pre wrap=""><!---->
It seems to me that each unit could represent a separate instance of
Individual, but the "parts" need to be clearly aggregated around the
single-organism parent Individual, which itself may be a part of another
Individual instance that is an aggregate lot of specimens, which itself
could be a subsampling of another Individual instance that represents a
population in nature.
</pre>
</blockquote>
Let the supporting evidence (tokens) be whatever type of thing they are
rather than call them Individuals. Link them together through
hierarchical relationships to the single-organism parent Individual.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">In my mind, we parse all of these things as separate instances of
Individuals, but join them via a hierarchical (parent/child) relationship.
If I'm not mistaken, this is how the ASC model managed instances of
BiologicalObject (again....right, Stan?)
</pre>
</blockquote>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<blockquote type="cite">
<pre wrap="">I don't really want them to be, but maybe I must?
Somehow we need to be able to handle road-kill,
which will be dead when we make the
observation/collection. If we cut a branch from
a tree (an Individual), root it, and grow it in
a botanical garden, do we call the resulting tree
in the garden the same Individual? I would assign
it a new identifier and call it a new Individual.
I guess my point is that I would only apply the
term Individual to dead stuff, pieces of dead stuff,
and living pieces of things with extreme caution.
</pre>
</blockquote>
<pre wrap=""><!---->
Why extreme caution? What are the risks that we are cautioning ourselves
against?
</pre>
</blockquote>
The risk that we make the definition of Individual so broad that it
can't perform any of the functions it was defined to serve. We've
already lost one of them (the ability to infer duplicates) when I
agreed to the broader definition, but that's the subject of another
post.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">These are some principles that I always try to keep in mind when discussing
these things:
- DwC is a data exchange standard, not so much a physical data model.
- There is a necessary balance between structuring DwC around how data
actually exist in content-provider databases, and how data *should* be
represented in a normalised world
- When in doubt, DwC should be accomodating, rather than restrictive --
especially when more restrictive needs can be met via associated data
filtering
</pre>
</blockquote>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">There are other principles as well, but these are the ones I keep having to
remind myself of.
</pre>
</blockquote>
I think that what I I have suggested above is very unrestrictive. We
let
evidence be the type of things that they are (PreservedSpecimens,
Individuals, StillImages, SoundRecordings, DNA sequences, etc.). We
don't determine their type by what we want to use them for. That was
the mistake that I made in the Biodiversity Informatics paper. If we
follow this approach, then a StillImage can fill any role that we want:
evidence that an Occurrence happened, information to support an
Identification, a character for a visual key, a logo, etc. We let it
fulfill those roles by giving it an identifier and connecting it to
other resources using appropriate terms (hasEvidence, derivedFrom,
mrtg:attributionLogoURL, etc.<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I think maybe so. Maybe the appropriate course
of action here as well is to let people try
different approaches out and if they turn out
to work and be needed, then we talk about
applying them to Darwin Core.
</pre>
</blockquote>
<pre wrap=""><!---->
Ultimately, I think people will use it in accordance to what terms are
nested within it -- which is why I think it's important to have this
conversation we're having now.
</pre>
</blockquote>
As I indicated at an earlier time, I think that there are very few
terms that should be properties of Individual since it is primarily a
node that connects Occurrences to Identifications (and I guess now to
derived tokens). <br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">Aloha,
Rich
</pre>
</blockquote>
Looking forward to responses! But I don't think development of these
ideas should hold up the proposal for the class Individual, which can
stand on its own with its current (revised) definition.<br>
Steve<br>
<blockquote cite="mid:2ACC6BD9E73A433D9D160E8EA82E7A03@RLPLaptop"
type="cite">
<pre wrap="">.
</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:
VU Station B 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) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>