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@bishopmuseum.orgwrote:
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@lists.tdwg.org [mailto: tdwg-content-bounces@lists.tdwg.org] *On Behalf Of *Dean Pentcheff *Sent:* Monday, November 01, 2010 10:05 AM *To:* tdwg-content@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:
- 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@gmail.com dpentche@nhm.org
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content