[tdwg-humboldt] Humboldt Extension Public Review preparations

Sun Aug 13 18:36:20 UTC 2023

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 at lists.tdwg.org> on behalf of ys628 <yanina.sica at yale.edu>
Date: Sunday, August 13, 2023 at 12:09 PM
To: Humboldt Core TG <tdwg-humboldt at lists.tdwg.org>, Wesley M. Hochachka <wmh6 at cornell.edu>, tuco at berkeley.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> on behalf of John Wieczorek <tuco at berkeley.edu>
Sent: Saturday, August 12, 2023 2:42 AM
To: Humboldt Core TG <tdwg-humboldt at lists.tdwg.org>; Wesley M. Hochachka <wmh6 at cornell.edu>
Cc: Markus Döring (GBIF) <mdoering at gbif.org>; Peter Desmet <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/20230813/c7a6d66c/attachment-0001.html>