Hi Jason,
The (only) slightly more appropriate place to post this is the tdwg-content list, which I've cc'd. You've posed an interesting scenario that I suspect was never imagined during Darwin Core development. I know I didn't. More and more discussion about individuals and their status over time is emerging, and I find the process of "testing" Darwin Core against these interesting. I think there are lots of ways to accommodate the information you've mentioned using the Darwin Core as it is. Some are more satisfying and reusable than others. And if Darwin Core as it now stands ends up failing, there are ways to extend it.
Here are a few ways the sighting information could be accommodated now.
1) Use the dwc:behavior term. This would be particularly suitable if you had a richer vocabulary that just alive or dead, but could be used nevertheless as long as no one gets too upset about alive and dead not being traditional behavior descriptors. Well, maybe if we assume that "dead" is a hypothesis and think about the animal "acting dead" then there might be fewer objections. ;-)
2) Use the dwc:eventRemarks term. I'm loathe to suggest this because I hate putting data with analytical potential into an ad hoc field where it can get lost or misunderstood for not having a strong context.
3) Use the dwc:dynamicProperties term. The intention of this term is pretty well documented on the Simple Darwin Core page under "Doing More with Simple Darwin Core" (http://rs.tdwg.org/dwc/terms/simple/index.htm#domore). Here's the relevant verbiage from the Simple Darwin Core page to get the full idea, along with the pros and cons of this technique.
"Another way to get more out of the Darwin Core without adding a term is to "payload" the dynamicProperties term as shown in the example below, to contain a list of key-value pairs. The keys in this case would act as new unofficial terms. This is perfectly legal, since it doesn't compromise the meaning of the term. Some of the weaknesses of payloading are that it is prone to errors, inconsistencies, and lack of stable or well-defined semantics. Still, this might be a reasonable way to at least allow you to share all of your data, even if there might be problems with people using it reliably."
Basically, for your example, you could include in this field the key-value pair for your data field, whatever you call it. Suppose you called it liveStatus. You could load information in Darwin Core records via the dwc:dynamicProperties term that included "liveStatus=alive" or "liveStatus=dead". In XML that could look something like this:
dwc:dynamicPropertiesliveStatus=alive</dwc:dynamicProperties>
4) Finally, if none of the above are fully satisfying, you can propose that a new term be added to the Darwin Core. The process for doing so is documented on the Namespace Policy page under the Term Change Policy section (http://rs.tdwg.org/dwc/terms/namespace/index.htm#classesofchanges), specifically section 3.4 Addition of Darwin Core term declarations to existing Darwin Core namespaces. And though that section says that requests for changes should be submitted to the TDWG-TAG, there is a well-documented procedure and infrastructure for it on the Darwin Core Project Site for Discussion and Development. The details can be found on the wiki page about Submitting Issues (http://code.google.com/p/darwincore/wiki/SubmittingIssues). It's worth reading the whole thing, despite that the section of particular interest in this case is the one called "New Term Request", accessible from the link with that title.
5) Of course, you can start making your own library of terms and give them a namespace to use in tandem with Darwin Core. This may be necessary if you can't make a strong enough case for a new term - for example, because it is too specialized to be of use across communities. I'm not saying that's the case here, only that this would be cause to have to define your own namespace and terms for those specialized concepts. The advantage of creating a new Darwin Core term is that it will definitely reach a wider audience than something project based, and will thereby promote re-use and integration between data sets.
Temptations I would avoid include the following:
I would not use occurrenceStatus, as its meaning is pretty clear. An animal would be present, whether alive or dead.
I also wouldn't use dwc:lifeStage, not because death couldn't be argued to be a life stage, but because it would be a mix of semantics to include "alive" when the term is meant to capture something about categorical ages.
Now you're an expert! Good luck and respond here to tdwg-content if you have further queries about this or similar Darwin Core Issues.
Cheers,
John
On Wed, Jan 27, 2010 at 10:32 AM, Jason Holmberg holmbergius@gmail.com wrote:
Hello! Apologies for the newbie question, which I am hoping has reached the correct list.
I'm altering the names of tables in a mark-recapture database to reflect Darwin Core labels as part of a larger open source initiative. I need to indicate in a new field whether a whale shark sighting (occurrence) represents a living or deceased whale shark. Which Darwin Core field would best represent this? A look through the terms in the Quick Reference did not yield an immeidate match for me, but apologies if I missed the obvious. Can you recommend an appropriate field?
Thanks in advance! Jason Holmberg ECOCEAN Whale Shark Photo-identification Library http://www.whaleshark.org
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag