Indicating living versus deceased status in Darwin Core
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
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:dynamicProperties>liveStatus=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
There is probably another (external to TDWG) vocab / ontology that could handle this?? (which, I think, we ought to be encouraging anyway???) Kevin -----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of John R. WIECZOREK Sent: Thursday, 28 January 2010 6:02 p.m. To: Jason Holmberg Cc: TDWG Content Mailing List; tdwg-tag Subject: Re: [tdwg-content] [tdwg-tag] Indicating living versus deceased status in Darwin Core 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:dynamicProperties>liveStatus=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
_______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
On Jan 28, 2010, at 4:17 PM, Kevin Richards wrote:
There is probably another (external to TDWG) vocab / ontology that could handle this?? I'm not certain at this time. However ....
(which, I think, we ought to be encouraging anyway???) Concur. We are falling into the realm where a generic observation model would be useful. Otherwise, we will encounter an increasing number of ad hoc treatments for other attributes, without a consistent underlying framework.
May I point, as a matter of interest, to the SONet Project: https://sonet.ecoinformatics.org/ Best regards, Flip
Thanks for the responses! If I'm understanding this correctly...should I then propose a new term as discussed by John? As background, we have a successful multi-user, Web-based mark-recapture software platform at www.whaleshark.org that we would like to open source. Before open sourcing it, I would like it to be as "standards-based" as possible. One measure of this is to use DarwinCore attributes in the database tables, allowing for the easy mapping of TapirLink into the db and therefore easier data exposure. If this group can think of other standards that it would be goods to support, please let me know. I would like to build interoperability directly into the software before releasing it, allowing adopters of the platform to expose data meaningfully with minimal effort. Thanks, Jason On Thu, Jan 28, 2010 at 5:25 PM, Phillip C. Dibner <pcd@ecosystem.com>wrote:
On Jan 28, 2010, at 4:17 PM, Kevin Richards wrote:
There is probably another (external to TDWG) vocab / ontology that could
handle this??
I'm not certain at this time. However ....
(which, I think, we ought to be encouraging anyway???)
Concur. We are falling into the realm where a generic observation model would be useful. Otherwise, we will encounter an increasing number of ad hoc treatments for other attributes, without a consistent underlying framework.
May I point, as a matter of interest, to the SONet Project: https://sonet.ecoinformatics.org/
Best regards, Flip
participants (4)
-
Jason Holmberg -
John R. WIECZOREK -
Kevin Richards -
Phillip C. Dibner