[tdwg-content] "Individual" use case

Tue Nov 2 21:40:04 CET 2010

I was thinking about how to deal with the issue of "sets" of individuals in
an occurrence.

I have not modeled this yet to see if it would work, but one way that I
thought of is to add a predicate called "occurrenceCount"

If the occurrence count is greater than 1, then substitute "#Set" for
"#Individual.

Then occurrencehasSet and setHasOccurrence.

The other data that would have been assigned to the #Individual would not be
used for the #Set.

This would allow an #Occurrence to have a #Set of individuals rather than
one #Individual.

If you had samples from a mosquito trap with 500-5,000 specimens separated
into 10 different species, then the records would show that there are 10
occurrences that have a count and a #Set in which information about the
specimen jar etc. is recorded. For a number of mosquito studies, all of the
individuals are not saved. It would however make sense to keep at least one
representative of each species as a voucher.

In the example above this would mean that you would have 10 representative
"voucher" specimens for the collection event described above.

In a sense, this would create a record with the following meaning.

*This voucher specimen represents what I identified as Aedes vexans in this
set of specimens.*

Since a lot of this identification is being done by student helpers, this
provides some specimens to go back and look at if needed.

Respectfully,

- Pete

On Tue, Nov 2, 2010 at 3:33 AM, Richard Pyle <deepreef at bishopmuseum.org>wrote:

>  Thanks, Dean -- you've reminded me of something that hadn't come up
> previously in the "Individual" discussion.  Several times the assertion has
> been made (perhaps even by me?) that an Individual is assumed to be a single
> taxon.  This assertion always triggered something int he depths of my brain,
> but I couldn't figure out what -- but now I remember, the need to deal with
> multi-taxon "lots" of organisms, and track them with sspecimen-like (and
> hence Individual-like) properties.  I believe Stan Blum dealt with this
> extensively in the ASC data model (CollectionObject, I think it was called),
> and it needed to accomodate not only multi-taxon lots of the sort that you
> describe, but also things like fossil specimens that have multiple phyla, or
> even Kingdoms, permanently combined within the same "CollectionObject".
>
> But this is only an asterisk, because it doesn't really break the notion of
> "same taxon" for an Individual, as long as the scope of "taxon" stretches
> all the way up to Domain.  Even the sample with plants, animals, and
> bacteria fall within the taxon circumscription of "life".
>
> But in any case, I agree with your general approach to "derived"
> specimens/samples -- which happens a lot in the DNA tissue sampling world.
> We can start with a multi-phylum aggregated lot, then split it out not only
> to the individual organism, but all the way into the parts and tissue
> samples realm.
>
> I don't know how DwC handles this (ResourceRelationship class?), but it's
> certainly important (and increasingly so) in the natural history specimens
> realm.
>
> Rich
>
>  ------------------------------
> *From:* tdwg-content-bounces at lists.tdwg.org [mailto:
> tdwg-content-bounces at lists.tdwg.org] *On Behalf Of *Dean Pentcheff
> *Sent:* Monday, November 01, 2010 10:05 AM
> *To:* tdwg-content at lists.tdwg.org
> *Subject:* [tdwg-content] "Individual" use case
>
> Count me in as another late entry to this discussion, lurking under the
> rumbling flight paths of the VLPs (Very Large Postings).
>
> Here's a potential case to consider in the whole "how to file all the
> parts" issues that seem to be arising. It's a parent/child scheme that we're
> implementing for our marine invertebrate specimen database. We think we are
> being reasonable in the way we thought of this. We hope that this concept
> could be accomodated by DwC. That's the sum of the contribution for
> consideration: we hope DwC can/will cope with this. It may well be that it
> happily does so under all of the "Individual" interpretations that are
> bouncing around. But hey, we thought we'd toss it in just to make sure.
>
> With marine invertebrates, we very often find ourselves subsampling
> collected things (yes, "thing" is deliberately vague to avoid misusing any
> heavy-baggage words). It is intrinsic to the nature of the collections.
> Things often arrive as unsorted lots (think of a jar full of coral rubble in
> 95% alcohol, sitting on our shelf). We want to have a record for that jar in
> our database, so it gets one, with a recordID.
>
> Months later, we sort the jar to phylum level, and each of those jars gets
> a record, each with a recordID, and those jars go on a shelf. We treat those
> records as children of the unsorted-lot-record, and they each have a pointer
> back to that unsorted-lot parent record.
>
> Then we later sort one of those phylum-level jars into species jars. Those,
> in turn, each get a record with a recordID, and point to their parent
> phylum-level-jar record. And so forth down to individuals in jars, and
> tissue samples of individuals, and DNA extracts of those tissues.
>
> To complete the picture: many specimens do, of course, come in simply as an
> individual in a jar. Those just get a record, and that's that: no parent, no
> child (no child yet... until there's a tissue sample).
>
> Key points:
> 1. We never know how many levels of subsorting there will be. That differs
> from the "preparation" orientation of many vertebrate collections (for
> example), where there's a predefined set of preps that can come from each
> collected individual. We very often don't start with individuals.
> 2. Each thing, whether it comes in the door directly or is derived from
> something that did, gets a first-class catalog record, and the sole unifying
> feature that gets us the full information on a thing are the parent-child
> relationships of the data records. Information has to continue to reside in
> those records and be accessible from the "children" (an example would be a
> transfer to a different preservative when pulling one individual into a
> specimen jar from a lot jar: you need to know the preservative this thing is
> in now, and you also need to know what preservative its parent thing was
> in).
> 3. One field of each record has to document whether the item still exists:
> a thing may be completely subdivided into subparts leaving nothing left over
> to put back on the shelf. But in that case, we still keep the data record
> since it's still the parent of the subsorted things and still holds the
> relevant historical information.
>
> So one day when we push these data out into the Wild World in a DwC
> context, the thing we'd like to see accomodated is the ability of systems
> outside our own walls to resolve back up that chain of subsorting to build
> the whole information set for a thing, including the relevant information
> from its logical "parents".
>
> OK, now we'll be delighted to hear that this scheme was obviously
> accomodated all along, or alternately, that this whole concept is a pretty
> dumb way of cataloging our holdings.
>
> -Dean
> --
> Dean Pentcheff
> Research Associate, Natural History Museum of LA County
> pentcheff at gmail.com
> dpentche at nhm.org
>
>
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>

-- 
---------------------------------------------------------------
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies
Knowledge Base <http://lod.geospecies.org/>
About the GeoSpecies Knowledge Base <http://about.geospecies.org/>
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20101102/903244c2/attachment.html 