Hi folks,
Thanks for this input, Kate.
It seems we are of divided opinions about when to address non-target organisms than whether to do so. Assuming it will be done eventually, here is an attempt to get the issues on the table.
Kate is proposing terms from the Occurrence perspective in the sense that they would be populated for child-most Occurrence Events (I'll use eco: isNonTargetOrganism). That is, The Event record associated with the Occurrence would have a Humboldt extension term eco:isNonTargetOrganism populated).
Last Wednesday Anahita was proposing terms at a parent Event level (I'll use eco:hasNontargetTaxa, eco:areNontargetOrganismsFullyReported, and eco:nonTargetTaxa). This parent Event perspective alerts a user about what to expect among the children. It should be possible to confirm the expectations among the children by investigating them.
These two approaches are very different. The first approach seems like a bit of a contorsion to me in that the term really ought to be an Occurrence term, and yet it would be going into the Event extension. A second problem I see is that it would be a challenge for users to know whether a data set, or a particular Event within a data set, is potentially fit for their purpose because all of the child Occurrences would have to be investigated to see if there were relevant non-target taxa.
The second approach circumvents the issues mentioned above. The term eco:hasNontargetTaxa for an Event would be a single boolean that could immediately alert a user about what to expect among the child Occurrences. It could also be populated for the Occurrence Events, serving the role intended for eco:isTargetOrganism. The term eco:nonTargetTaxa could actually list those taxa so the user would know what was considered non-target. The term eco:areNontargetOrganismsFullyReported seems extremely important, but it is also extremely problematic, the problem being that it seems like the value of this term would almost ALWAYS have to be 'false'.
So, there are clearly things to discuss, but here is an attempt to jump-start term definitions at least.
eco:hasNontargetTaxa
- definition: One or more dwc:Organisms of taxa outside the target taxonomic and organismal scopes were detected and reported for this dwc:Event. - comments: Should be empty if no taxonomic scope is declared. Should be 'true' if Occurrences of taxa outside the taxonomic and organismal scopes as defined at the time of the dwc:Event are included for the dwc:Event. Should be 'false' if no Occurrences of taxa outside the taxonomic and organismal scopes as defined at the time of the dwc:Event are included for the dwc:Event. - examples: 'true'; 'false'
eco:nonTargetTaxa
- definition: A list (concatenated and separated) of taxa reported during the dwc:Event that are outside of the eco:targetTaxonomicScope. - comments: Non-target taxa can be reported at any taxonomic level. Recommended best practice is to separate multiple values in a list with space vertical bar space ( | ). - examples: `Parabuteo unicinctus | Geranoaetus melanoleucus`; `Cetoniinae | Aclopinae | Cyclocephala modesta`
eco:areNontargetOrganismsFullyReported
- definition: Every dwc:Organism that was outside the eco:targetTaxonomicScope, and was detected during the dwc:Event, and was detectable using the given protocol, was reported. - comments: This term is only relevant if the dwc:Event used restricted search or open search methods and the value should otherwise be empty. If all dwc:Organisms not included within the eco:targetTaxonomicScope and detected during the dwc:Event were reported, the value should be 'true'. If all dwc:Organisms not included within the eco:targetTaxonomicScope and detected during the dwc:Event were not reported, the value should be 'false'. - examples: 'true; 'false'
Cheers,
John
On Mon, Aug 14, 2023 at 5:09 AM Kate Ingenloff kathryn.ingenloff@gmail.com wrote:
Hi John, Steve, Yani, et al.,
Thank you so much John and Steve. The landing page looks great! I'll be happy to help look over documentation this week.
As for bycatch, as Yani said, we've discussed this several times and I think it's important to include a couple of the obvious terms for data providers to denote if individual occurrences within a survey are bycatch (e.g., isBycatch or isNonTargetOrganism,) or perhaps to identify is a separate dataset (Event) of some level is nothing but bycatch (e.g., allBycatchReported or allNonTargetOrganismsReported). I think we would be remiss to not include a couple of relevant terms prior to public review. Discussion shouldn't have to take too long and feedback from the first round of review can help fill in the rest (if more than those two terms are necessary).
Just my two cents :)
Cheers, Kate
On Sat, Aug 12, 2023 at 2:43 AM John Wieczorek tuco@berkeley.edu wrote:
Hi folks,
Steve and I have been working through and finished (to the extent we can) the preparations of the documents needed for the public review of the Humboldt Extension. The idea is that the basic entry point to the review would be this landing page https://github.com/tdwg/hc/blob/main/docs/index.md and that everything to review would be accessible from there.
We need the Task Group to finalize all documents to be included and to authorize the Darwin Core Maintenance Group to initiate the review. When authorized, the Darwin Core Task Group will send a message introducing the submission and how people should review it. It would be great to have a brief statement presenting the proposal from the Task Group to have at the beginning of that message. The DwC Maintenance Group will also solicit the TDWG Outreach folks to publicize the public review via various channels and social media. Anyone will be welcome to further publicize it in any community that TDWG misses.
The issue of new terms for by-catch came up late in last Wednesday's meeting after several people had to leave. I don't feel comfortable including anything official from that conversation without the Task Group making decisions. There are a few reasonable options.
The first option for the "by-catch" terms is to add those terms now and include them in the proposal. That means work up front to make sure the terms are well-defined and thought through. Think of this ratification process very much as if it was the publication of a manuscript with peer review. As such, an important goal is to try to avoid avoidable public discussion, which has the potential to slow things down or even derail ratification.
A second option might be to propose the new terms during public review and see if there is buy-in. This strategy is likely to make the ratification process slower, and runs a risk (that I might be inventing) that if such an added proposal came from people in the Task Group, reviewers might view that our work was submitted unfinished.
A third option might be to leave the proposal as is without additional terms, get it through ratification, and sometime afterwards propose new terms. This follows the normal evolution process of Darwin Core, so there would not be anything odd about it. It would also guarantee that there is demand for such terms, as that is a prerequisite for accepting new term proposals.
It isn't for the Darwin Core Maintenance Group to decide the strategy the Task Group should take, but rather to advise and facilitate in the search for a successful proposal
I hope this feels like we are getting close.
Cheers,
John and Steve on behalf of the Darwin Core Maintenance Group _______________________________________________ tdwg-humboldt mailing list tdwg-humboldt@lists.tdwg.org https://lists.tdwg.org/mailman/listinfo/tdwg-humboldt
--
Kate Ingenloff, PhD Pronouns: she/her(s) (+45) 51 44 13 23
"When one tugs at a single thread in nature, he finds it attached to the rest of the world." ~John Muir