<!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">
Comments inline<br>
<br>
Richard Pyle wrote:
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">My turn to respond after traffic-jam reflections.... 

  </pre>
  <blockquote type="cite">
    <pre wrap="">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).  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
</blockquote>
If we go down the road we seem to be traveling now, I think we must
allow a wolf pack to be an Individual.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; It
is quite likely that I won't know or don't care whether the number has
changed.&nbsp; Case in point:
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/ind-baskauf/51273">http://bioimages.vanderbilt.edu/ind-baskauf/51273</a><br>
I have photographed this same patch of corn gromwell several times.&nbsp; I
have no idea how many individual plants are in it nor do I care.<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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 "&gt;1".  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
</blockquote>
I agree.&nbsp; 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.&nbsp; 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.&nbsp; Then bring it up as a possible term addition.<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">The other issue would be how to indicate that one of these "aggregate"
(individualCount&gt;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".
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yup, I think we're on the same page on this one.

  </pre>
  <blockquote type="cite">
    <pre wrap="">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! :-).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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)
  </pre>
</blockquote>
Move to record level terms<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">individualCount
  </pre>
</blockquote>
leave (see above)<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">preparations
disposition
  </pre>
</blockquote>
I think leave in Occurrence for now.&nbsp; 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.&nbsp; Time will
tell...&nbsp; But they are closer to an Occurrence than an Individual.&nbsp; <br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">previousIdentifications
  </pre>
</blockquote>
Hmm.&nbsp; I suppose yes, but better to just have another instance of
Identification.&nbsp; Why not?<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">associatedSequences
  </pre>
</blockquote>
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.&nbsp; 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.<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 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?
  </pre>
</blockquote>
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)<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">
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.
  </pre>
</blockquote>
I haven't said this before, but are we allowing Individuals to be
dead?&nbsp; I would have said "no", but now I'm not sure.&nbsp; 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).&nbsp; However, I'm
having trouble doing the same thing with PreservedSpecimen.&nbsp; 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?&nbsp; I think
Pete might have been suggesting modeling things that way with
"partOf".&nbsp; 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.&nbsp; Are
those all a part of an Individual?&nbsp; I don't really want them to be, but
maybe I must?&nbsp; Somehow we need to be able to handle road-kill, which
will be dead when we make the observation/collection.&nbsp; 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?&nbsp; I would assign it a new identifier and call it a new
Individual.&nbsp; 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.<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">
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.
  </pre>
</blockquote>
I think maybe so.&nbsp; 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.<br>
Steve<br>
<blockquote cite="mid:14A1E95371A04347A83F0C1CE8794DDD@RLPLaptop"
 type="cite">
  <pre wrap="">
OK, enough for a while....

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