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
.