Dean Pentcheff wrote:
OK. I think this makes sense to me.

Seeing how my "jar of semi-identified scunge" example plays now:

Setting: A jar full of stuff collected from a coral reef. In it I can
see larval fish, sphaeromatid isopods, one "Diadema antillarum"
urchin, and a green alga.

"Individual"ization:
1. The record for the jarful of scunge is _not_ eligible to be an "Individual".
  
I think under the definition as it stands and the way the discussion has been going, it could be an Individual with an Identification of urkingdom=Eukarya (or however taxonomists prefer to call it) because since there is are animals and algae in it, that would be the lowest taxon common to all organisms known to be in the jar.  Whether this would be wise or whether you would actually want to do it or not is for you to decide.  But I think it's allowed in the definition. 
2. I can create four additional records, each of which is designated
as "partOf" the jar record, each of which can be an "Individual" with
a higher-level or species-level determination attached to it.
  
Yes, as long as each of those four Individuals isn't Identified to a level below the lowest taxon common to all organisms known to be in that lot.
Two years from now, I sort and ID the sphaeromatid isopods and
determine that they are indeed all in the Family Sphaeromatidae, and
split them out to three separate jars, each of which is a different
genus. Each of those jars can be referred to as an "Individual" (one
or more objects from a single taxon collected at a single time/place).
Has the older family-level record now lost its "Individual"ness, now
that it's clear it's a composition of three lower-level taxa? Or does
it still record the correct fact that a group of independently
locomoting bugs from one collecting instance all belonged to the same
family, and hence is still an "Individual" record, indicating that
higher-level taxon group of bugs?

  
The older jar Identified to family=Sphaeromatidae is still an Individual.  It has three "child" Individuals, each of which isPartOf the Sphaeromatidae Individual.  Each of the "child" Individuals can have an Identification to genus.  You could continue this process until you have every individual isopod in a separate jar identified to species or whatever the lowest taxon is that you believe in.  What I'm saying in my post is that it is NOT allowed by the definition (or useful based on the reason why the Individual class was proposed) to cut the isopods into pieces and then call the pieces Individuals (for the reasons I gave and won't repeat here).  You can call the pieces PreservedSpecimens, choppedOrganismParts, derivedLifeBits, or whatever the community decides this kind of thing should be.  But my assertion is that you can't call them Individuals. 

Steve
[As a side issue, note that I have IDed them to genus, not species, to
sidestep the debate on the specialness of the species taxon.]

-Dean
--
Dean Pentcheff
pentcheff@gmail.com
dpentche@nhm.org

On Fri, Nov 5, 2010 at 12:29 PM, Steve Baskauf
<steve.baskauf@vanderbilt.edu> wrote:
  
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.

Responses inline below:

Richard Pyle wrote:

...

previousIdentifications


Hmm.  I suppose yes, but better to just have
another instance of Identification.  Why not?


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.


Got it.  It should go with Individual.



associatedSequences



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.


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".


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".

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.

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

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.

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.


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.

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
http://bioimages.vanderbilt.edu/pages/tree-branch.gif .  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).

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

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.

I have created a number of similar charts showing how these relationships
could apply to various types of tokens:
http://bioimages.vanderbilt.edu/pages/tree-branch.gif  (tree branch
PreservedSpecimen)
http://bioimages.vanderbilt.edu/pages/tree-image.gif  (image of a live tree)
http://bioimages.vanderbilt.edu/pages/whale-dna.gif  (tissue sample and DNA
sequence from a whale)
http://bioimages.vanderbilt.edu/pages/bird-observation.gif (bird
observation)
http://bioimages.vanderbilt.edu/pages/wildebeest.gif  (wildebeest calf
captured and put in zoo)
http://bioimages.vanderbilt.edu/pages/botanical-garden.gif  (twig removed
and turned into a living specimen in a botanical garden)

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

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.
http://bioimages.vanderbilt.edu/pages/conceptual-scheme-insect.gif) but
better because I'm letting the tokens be what they are rather than trying to
force them all to be Occurrences.



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)


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)?



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.



I haven't said this before, but are we allowing Individuals
to be dead?


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.


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.



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?


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)


See above.

And, a mechanism to track series of "derived from" Individuals.  The ASC
model covered this, I think (right, Stan?)



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
(http://bioimages.vanderbilt.edu/rdf/terms.htm) 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.

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?


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.


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.

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?)



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.


Why extreme caution?  What are the risks that we are cautioning ourselves
against?


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.

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


There are other principles as well, but these are the ones I keep having to
remind myself of.


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.




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.


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.


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

Aloha,
Rich




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.
Steve

.



--
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
http://bioimages.vanderbilt.edu

_______________________________________________
tdwg-content mailing list
tdwg-content@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-content


    
_______________________________________________
tdwg-content mailing list
tdwg-content@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-content
  

-- 
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
http://bioimages.vanderbilt.edu