[tdwg-humboldt] Humboldt Extension Public Review preparations

Mon Aug 14 01:48:50 UTC 2023

Thanks Yani and all,

I have to apologise for being a bit absent over the past few weeks, too many other competing things I’m afraid.

The recent contributions from Ming, John and Steve especially are great and I think it is looking really good. I tend to agree that the inclusion of bycatch terms at this late stage could compromise our October target timeline. I think that, whilst including these terms would be useful, they are not essential for the application of the standard. We would therefore be better to move towards getting the standard through the next stages of the ratification process as soon as possible so that it can start to be used. The bycatch terms augment the current terms, so adding them later should not be problematic.

Peter

From: tdwg-humboldt <tdwg-humboldt-bounces at lists.tdwg.org> On Behalf Of ys628
Sent: Monday, 14 August 2023 3:09 AM
To: Humboldt Core TG <tdwg-humboldt at lists.tdwg.org>; Wesley M. Hochachka <wmh6 at cornell.edu>; tuco at berkeley.edu
Cc: Markus Döring (GBIF) <mdoering at gbif.org>; Peter Desmet <peter.desmet.work at 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 Life<https://mol.org/> | Center for Biodiversity and Global Change<https://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 at lists.tdwg.org<mailto:tdwg-humboldt-bounces at lists.tdwg.org>> on behalf of John Wieczorek <tuco at berkeley.edu<mailto:tuco at berkeley.edu>>
Sent: Saturday, August 12, 2023 2:42 AM
To: Humboldt Core TG <tdwg-humboldt at lists.tdwg.org<mailto:tdwg-humboldt at lists.tdwg.org>>; Wesley M. Hochachka <wmh6 at cornell.edu<mailto:wmh6 at cornell.edu>>
Cc: Markus Döring (GBIF) <mdoering at gbif.org<mailto:mdoering at gbif.org>>; Peter Desmet <peter.desmet.work at gmail.com<mailto:peter.desmet.work at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tdwg.org/pipermail/tdwg-humboldt/attachments/20230814/a4860a66/attachment-0001.html>