If people are agreeable to Yani’s suggestion that we go with the terms we have now, then maybe we can shoot for our Wednesday meeting be focused on reviewing everything to make sure everything is ready to go and officially submit right after that. I agree with what Yani said about use running out of time if we want this done before the annual meeting on October.

Is the hierarchical events document ready to be turned into Markdown? If so, I will do that before Wednesday. If I make the conversion, we can still make changes, but they would need to be done to the Markdown and not to the Google Doc after the conversion.

Steve

-- Steven J. Baskauf, Ph.D. he/him/his Data Science and Data Curation Specialist / Librarian III Jean & Alexander Heard Libraries, Vanderbilt University Nashville, TN 37235, USA

Biodiversity Information Standards (TDWG) Executive Committee/Technical Architecture Group Chair https://baskauf.github.io/

From: tdwg-humboldt tdwg-humboldt-bounces@lists.tdwg.org on behalf of ys628 yanina.sica@yale.edu Date: Sunday, August 13, 2023 at 12:09 PM To: Humboldt Core TG tdwg-humboldt@lists.tdwg.org, Wesley M. Hochachka wmh6@cornell.edu, tuco@berkeley.edu tuco@berkeley.edu Cc: Markus Döring (GBIF) mdoering@gbif.org, Peter Desmet peter.desmet.work@gmail.com Subject: Re: [tdwg-humboldt] Humboldt Extension Public Review preparations Hi John, Steve and all,

Thanks John and Steve for proving the Darwin Core Maintenance Group guidance on how to move forward with the bycatch. Also, the landing page looks awesome!

I am inclined to go for your third option (leave the proposal as is without additional terms, get it through ratification, and sometime afterwards propose new terms) mainly because of time. If we would like to have the extension at least on the way to be ratified, the public review process needs to be initialized ASAP and I do not think that is compatible with including 2 more terms. Developing the definition, comments and examples for 'bycatch terms' and providing a proper description of the concept of bycatch will necessarily take a few weeks and we are already in mid-August.

To provide some background, we are considering bycatch as all non-target species recorded in the event. Right now, occurrences of any taxa that are not included in eco:taxonTaxonomicScope are assumed to be bycatch. So, an end user that needs to work with targeted species only, needs to identify and filter out the non-target species by having a clear understanding of the taxonomic target.

We all agree that including a term that flags if bycatch (or non-target) species were included in the dataset would be very useful for that type of user (an also for completeness in case of future taxonomic changes). But for including such a term, it might also be very useful to include a term specifying if ALL bycatch species were reported (maybe only certain species were included and others not) or even a term where data providers can list their bycatch species or taxa.

We have discussed the addition of terms related to bycatch a couple of times before and we never reached an agreement. I believe such terms need to be discussed and properly elaborated on, that's why I think it could take quite a while.

Do not get me wrong, I think these terms are useful and important BUT I think they could come as a response to potential comments during the public review or just as soon as the vocabulary is ratified. This is the nice thing about community developed standards, it is a never-ending story 😉

But I am happy to go with the majority here, I think it is completely fine if people feel the need to have these terms as part of the vocabulary from the very beginning.

Hope everybody is fine! Sorry for a Sunday email...

All the best,

Yani

Yanina V. Sica, PhD Lead Data Team Map of Lifehttps://mol.org/ | Center for Biodiversity and Global Changehttps://bgc.yale.edu/ Yale University pronouns: she/her/hers If you are receiving this email outside of your working hours, I am not expecting you to read or respond. ________________________________ From: tdwg-humboldt tdwg-humboldt-bounces@lists.tdwg.org on behalf of John Wieczorek tuco@berkeley.edu Sent: Saturday, August 12, 2023 2:42 AM To: Humboldt Core TG tdwg-humboldt@lists.tdwg.org; Wesley M. Hochachka wmh6@cornell.edu Cc: Markus Döring (GBIF) mdoering@gbif.org; Peter Desmet peter.desmet.work@gmail.com Subject: [tdwg-humboldt] Humboldt Extension Public Review preparations

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 pagehttps://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

Ahh, good point on that John.

I will amend my vote to support option 2. :)

On Mon, Aug 14, 2023 at 3:38 PM John Wieczorek tuco@berkeley.edu wrote:

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

Herein lies the problem of not having eco:nonTargetTaxa:

"Assuming everything that is not the target is non-target..."

That assumption isn't supportable because the taxonomic opinions applied to the taxa (target, excluded, and nonTarget) can differ over time and between people. Thus, a taxon that might have been out of scope at the time of the Event could come into scope later analysis by virtue of changes in taxonomy. It seems to me never safe to make any assumptions in this respect and that would mean that the eco:nonTargetTaxa is actually required in order to make inferences if any non-target Occurrences are reported. These terms are in support of post-facto use of the data, and it's becoming clear thinking about it that inventory data can be very fragile for some purposes, and the down-stream researcher will have to do a lot of due diligence to be able use them wisely.

On Mon, Aug 14, 2023 at 11:48 AM Yi Ming Gan ymgan@naturalsciences.be wrote:

Thank you so much everyone! John I appreciate your attempt to jump-start the term definition.

In my humboldt opinion, eco:hasNontargetTaxa and eco:areNontargetOrganismsFullyReported are certainly helpful! eco:hasNontargetTaxa + eco:isTaxonomicScopeFullyReported can also help to differentiate whether an Event caught something vs nothing.

Assuming everything that is not the target is non-target, eco:nonTargetTaxa is helpful, but I feel like it could get complicated - for example, taking into account of lifeStageScope etc. (adult fish is *not* a target, but larvae and juvenile are) User can look in the Occurrences to search for whatever not in eco:targetTaxonomicScope (and other scopes) to determine which of those Organisms are non-target. So I suggest to have this implicit, instead of having every non-target listed out in eco:nonTargetTaxa. It is much easier to have those non-target in Occurrence, because they have their own lifeStage, degreeOfEstablishment etc field. I hope this makes sense.

Thanks again!

Cheers Ming

---

*From:* tdwg-humboldt tdwg-humboldt-bounces@lists.tdwg.org on behalf of Kate Ingenloff kathryn.ingenloff@gmail.com *Sent:* 14 August 2023 16:00 *To:* tuco@berkeley.edu tuco@berkeley.edu *Cc:* Wesley M. Hochachka wmh6@cornell.edu; Markus Döring (GBIF) < mdoering@gbif.org>; Peter Desmet peter.desmet.work@gmail.com; Humboldt Core TG tdwg-humboldt@lists.tdwg.org *Subject:* Re: [tdwg-humboldt] Humboldt Extension Public Review preparations

Ahh, good point on that John.

I will amend my vote to support option 2. :)

On Mon, Aug 14, 2023 at 3:38 PM John Wieczorek tuco@berkeley.edu wrote:

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

--

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

This reminds me of the “detectability” discussions we had in Finland with Panu Halme (one of his thesis papers dealt with that). I think I gave this example before:

Say, there are 240 polypore species in Finland as frozen by then-latest book in 2006, 280 species (splitting, discovery) according to the book from 2020. The very same forest is inventoried for polypores by three different people in 2009, 2011 and 2021. Each of us field workers knows and can reliably identify only a subset of then-available national mycota – e.g. I am bad with Skeletocutis, but my colleague is hopeless with Antrodia. We were interested in dynamics of the species composition in the same site. To adequately merge the data for the analysis, we only analyzed the species that were potentially detectable by any of three of us on all inventory year. This conservative approach narrows down the targets quite a lot to only potentially detectable / known species, but we then concluded this is the cleanest way ahead (while per site per inventory the target was always broader than a combined target for three inventories). I would be very curious to know would you do this differently? How would you capture such a case in HC?

This is likely a sidetrack, a box to the mail discussion, please ignore if this is not helping.

Thanks in advance, Dmitry

From: tdwg-humboldt tdwg-humboldt-bounces@lists.tdwg.org On Behalf Of John Wieczorek Sent: Monday, 14 August, 2023 19:15 To: Yi Ming Gan ymgan@naturalsciences.be Cc: Wesley M. Hochachka wmh6@cornell.edu; Markus Döring mdoering@gbif.org; Peter Desmet peter.desmet.work@gmail.com; Humboldt Core TG tdwg-humboldt@lists.tdwg.org Subject: Re: [tdwg-humboldt] Humboldt Extension Public Review preparations

Herein lies the problem of not having eco:nonTargetTaxa:

"Assuming everything that is not the target is non-target..."

That assumption isn't supportable because the taxonomic opinions applied to the taxa (target, excluded, and nonTarget) can differ over time and between people. Thus, a taxon that might have been out of scope at the time of the Event could come into scope later analysis by virtue of changes in taxonomy. It seems to me never safe to make any assumptions in this respect and that would mean that the eco:nonTargetTaxa is actually required in order to make inferences if any non-target Occurrences are reported. These terms are in support of post-facto use of the data, and it's becoming clear thinking about it that inventory data can be very fragile for some purposes, and the down-stream researcher will have to do a lot of due diligence to be able use them wisely.

On Mon, Aug 14, 2023 at 11:48 AM Yi Ming Gan <ymgan@naturalsciences.bemailto:ymgan@naturalsciences.be> wrote: Thank you so much everyone! John I appreciate your attempt to jump-start the term definition.

In my humboldt opinion, eco:hasNontargetTaxa and eco:areNontargetOrganismsFullyReported are certainly helpful! eco:hasNontargetTaxa + eco:isTaxonomicScopeFullyReported can also help to differentiate whether an Event caught something vs nothing.

Assuming everything that is not the target is non-target, eco:nonTargetTaxa is helpful, but I feel like it could get complicated - for example, taking into account of lifeStageScope etc. (adult fish is not a target, but larvae and juvenile are) User can look in the Occurrences to search for whatever not in eco:targetTaxonomicScope (and other scopes) to determine which of those Organisms are non-target. So I suggest to have this implicit, instead of having every non-target listed out in eco:nonTargetTaxa. It is much easier to have those non-target in Occurrence, because they have their own lifeStage, degreeOfEstablishment etc field. I hope this makes sense.

Thanks again!

Cheers Ming ________________________________ From: tdwg-humboldt <tdwg-humboldt-bounces@lists.tdwg.orgmailto:tdwg-humboldt-bounces@lists.tdwg.org> on behalf of Kate Ingenloff <kathryn.ingenloff@gmail.commailto:kathryn.ingenloff@gmail.com> Sent: 14 August 2023 16:00 To: tuco@berkeley.edumailto:tuco@berkeley.edu <tuco@berkeley.edumailto:tuco@berkeley.edu> Cc: Wesley M. Hochachka <wmh6@cornell.edumailto:wmh6@cornell.edu>; Markus Döring (GBIF) <mdoering@gbif.orgmailto:mdoering@gbif.org>; Peter Desmet <peter.desmet.work@gmail.commailto:peter.desmet.work@gmail.com>; Humboldt Core TG <tdwg-humboldt@lists.tdwg.orgmailto:tdwg-humboldt@lists.tdwg.org> Subject: Re: [tdwg-humboldt] Humboldt Extension Public Review preparations

Ahh, good point on that John.

I will amend my vote to support option 2. :)

On Mon, Aug 14, 2023 at 3:38 PM John Wieczorek <tuco@berkeley.edumailto:tuco@berkeley.edu> wrote: 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.commailto: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.edumailto: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 pagehttps://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.orgmailto: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

-- ------------------------------ 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

I loved reading “final pre-public review meeting”. Thanks John, the bycatch terms look great and consistent (I only added one comment which relates eco:hasNonTargetTaxa with eco:nonTargetTaxa).

Also, thanks for reminding me that there have been changes to eco:taxonCompletenessReported. If anybody has comments regarding this definition, please let us know ASAP.

On my end, we are good to go with all terms!

cheers,

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Aug 23, 2023 at 6:45 PM John Wieczorek tuco@berkeley.edu wrote:

Hello all,

After today's final pre-public review meeting, I modified the definitions of the four new bycatch-related terms to reflect what we agreed on plus reworked the wording to be consistent with other terms in the proposal. Their final form can be found in the bycatch document https://docs.google.com/document/d/184BjPL-Kd9lv_x39sVGNxFKFlb4hY_Xsli5_dmnBMqs/edit?usp=sharing. I will wait for final authorization from our fearless leader (Yani) before putting these plus the modified definition and comments for taxonCompletenessReported (below for reference) into the change documents to pass to Steve, from which the public review versions of documents will be constructed.

Cheers,

John

*taxonCompletenessReported* *Definition*: Statement about whether the taxonomic completeness of the dwc:Event was assessed. *Comments*: This term is meant to alert users that the inventory was conducted in such a way that all of the target taxa (the combination of eco:targetTaxonomicScope and eco:excludedTaxonomicScope) should have been detectable if they were present during the dwc:Event. This term can provide data users with a qualitative measure of how comprehensively an area has been surveyed, which assists in interpreting species populations, areas of occupancy, inferring species absences, etc. This term is only relevant if the dwc:Event used restricted search or open search methods. If taxonomic completeness was assessed, the methods used or an explanation of the basis of the completeness should be stated in eco: taxonCompletenessProtocols. Recommended best practice is to use a controlled vocabulary. *Examples*: `not reported`; `reported complete`; `reported incomplete`

---

tdwg-humboldt mailing list tdwg-humboldt@lists.tdwg.org https://lists.tdwg.org/mailman/listinfo/tdwg-humboldt