Comments inline

Richard Pyle wrote:
My turn to respond after traffic-jam reflections.... 

  
What we need to realize is that in doing this, we are 
establishing establishing dwc:Individual as the de facto 
"aggregation" unit of the sort we have talked about 
previously.  I suppose that is OK as long as we provide 
sufficient means for humans or semantic reasoners to be able 
to know what they are getting information about when they 
retrieve metadata about an Individual.  That can be done for 
humans by making appropriate comments in the proposed 
dwc:individualRemarks .  For machines, I have been 
re-thinking the idea of having dwc:individualCount being a 
property of an Individual.  In an earlier post, I suggested 
that it should remain a property of Occurrences, since the 
number of Individuals can change over time (think wolf pack 
or plant deme over time).  
    

In my mind, if the "Individual" is something like a wolf pack, and the wolf
pack changes composition over time, then you're really dealing with
different instances of a "wolf pack" (not just different occurrences of the
same individual).  There may be a desire to relate the two Wolf Packs
together in some semantic way, of course.

  
If we go down the road we seem to be traveling now, I think we must allow a wolf pack to be an Individual.  It is a definable aggregation of biological individuals which can be assigned an identifier that can be the subject of repeated Occurrences and it can reliably be identified to some taxon.  The definition we have doesn't (at this point) forbid that or say that the number of biological individuals in an Individual must stay the same over time.  It is very convenient for the use case that got this all started (having a small patch of plants of the same species) that we don't require that the number change.  A major feature of Individual is to allow sampling over time (a la the definition of individualID) and if the number of individuals changes between Occurrences I shouldn't have to redefine a new individual.  It is quite likely that I won't know or don't care whether the number has changed.  Case in point: http://bioimages.vanderbilt.edu/ind-baskauf/51273
I have photographed this same patch of corn gromwell several times.  I have no idea how many individual plants are in it nor do I care.

  
However, in the current context, 
something like dwc:individualCount (if not individualCount 
itself) that is a property of Individual could have 
controlled values of "1" and ">1".  
    

Hmmm....I'd rather keep individualCount as a numeric value (rather than a
controleld vocabulary), to allow specific values to be provided for numbers
of specimens in a lot, numbers of individuals seen in an observation, etc.

If you want a controlled vocabulary for semantic purposes, I'd favor
something like a new term "individualScope" being used for such purposes.
Values in a controlled vocabulary might include things like "Single",
"Group", "Aggregate" "Absent", etc., each with carefully worded definitions.

  
I agree.  I think something "like individualCount" is what we need, but its probably best to leave individualCount where it is (in the Occurrence class) for now so that the count can change over time.  I would suggest that if Individual is accepted, those who want to use it can experiment with something like individualScope and find out what works.  Then bring it up as a possible term addition.

  
The other issue would be how to indicate that one of these "aggregate"
(individualCount>1) Individuals was segregated into several 
Individuals at a lower taxonomic level (e.g. partially sorted 
lots of marine organisms get more sorted, fossil aggregations 
get separated into individual fossils, an image of a forest 
has individual trees delineated).  Rich has stated that this 
would be necessary any time subsets of the original 
Individual were given divergent Identifications and I agree 
totally.  Assigning new GUIDs to these new Individuals would 
be no problem and I suppose Pete's suggestion of using 
"hasPart" and "isPartOf" could be used to establish the 
relationships between the original Individual and its "children".
    

Yup, I think we're on the same page on this one.

  
If the 
proposed addition goes through, we need to have a really good 
Google Code entry that summarizes the understanding that we 
have come to in this discussion (if we have come to one! :-).
    

Agreed.  We also need to be clear on what terms that currently fall within
the Occurrence class should properly move to a new Individual Class.  My
vote would be for:

individualID (unless moved to Record-level terms)
  
Move to record level terms
individualCount
  
leave (see above)
preparations
disposition
  
I think leave in Occurrence for now.  I think that if we come up with a DwC that will work with RDF, we will be forced to create a PhysicalSpecimen class and these things will be in it.  Time will tell...  But they are closer to an Occurrence than an Individual. 
previousIdentifications
  
Hmm.  I suppose yes, but better to just have another instance of Identification.  Why not?
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.
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)
Some of these are certainly debatable.  For example, the
PreservedSpecimen-centric "preparations" and "disposition" really do seem to
me to be properties of the Individual, not of the Occurrence at which the
Individual was extracted from nature. But I can see a problem when the same
Individual is first seen in nature, then is extracted later as a specimen;
in which case it seems weired to include these properties at the level of
Individual.
  
I haven't said this before, but are we allowing Individuals to be dead?  I would have said "no", but now I'm not sure.  I have convinced myself that if John's proverbial wildebeast calf (or whatever it was) gets captured and becomes a LivingSpecimen in a zoo, it is still an Individual but now one with curation (i.e. there is no such thing as a LivingSpecimen, it's just an Individual with curation).  However, I'm having trouble doing the same thing with PreservedSpecimen.  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?  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?  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.
I think if we were going to be really pure about this, we should generate
two instances of Individual for each PreservedSpecimen: one representing
effectively an observation at the moment of capture (which would technically
have as basisOfRecord "LivingSpecimen" or "HumanObservation", and is linked
to the Occurrence), and the other representing the preserved specimen after
it is curated and processed (linked appropriately to the first Individual
instance).

But I think that's going too far.
  
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.
Steve
OK, enough for a while....

Aloha,
Rich


.

  

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