Structured species/ecotype/pod tags on bouts, for downstream consumers

[rainhead]

This was generated by AI during triage.

Context. SalishSea.io — a sister project in the Acartia data cooperative — maps marine-mammal occurrences across the Salish Sea. We'd like to surface OrcaSound acoustic activity on the map as first-class occurrences alongside visual sightings.

What we found. The /api/json/bouts endpoint is the right grain to consume — bouts are human-curated, unlike raw detections. Of ~196 bouts, the 134 biophony ones carry the biological signal. Reading their name text, the mix is roughly:

• ~70% killer whales, often identified to ecotype and pod (e.g. "SRKW J pod", "Bigg's T090s", "T419, T420, T421")
• ~9 humpback
• a tail of sea lion, fish, birds, mystery / OrcaHello false-positives, and some non-animal sounds mistagged as biophony

The problem. All of that identity lives only in the free-text name. A downstream consumer has to regex names to learn whether a bout is even a marine mammal, let alone which species/pod — fragile and lossy, and it discards the moderator's knowledge.

Proposal. Establish a small controlled tag vocabulary for bouts and apply it during curation. Bouts already have a tags relationship exposed on the JSON:API (Bout includes [:feed, :tags]), so no new endpoint or schema change is needed — only slug conventions and a moderator habit. Suggested namespaces:

• ecotype:srkw, ecotype:biggs
• pod:j, pod:k, pod:l
• matriline:t090 (etc.)
• species:humpback, species:steller-sea-lion, species:harbor-seal, species:ca-sea-lion, …
• unconfirmed / false-positive for the mystery bucket, so consumers can drop those cleanly

With that in place, SalishSea.io mirrors bouts + their tags verbatim and translates the tags into our taxonomy at ingest — no name-parsing, and the moderator's judgment is preserved end to end.

Happy to help define the vocabulary and seed the tags if that's useful. Tracking issue on our side: salish-sea/salishsea-io#178.

[dthaler]

Looks like a good proposal to me. The PODS-AI inference has the data for ecotype and species (humpback and orca, anyway) but currently has to put it in comments/description.

[rainhead]

@paulcretu or @skanderm do you have an opinion?

[scottveirs]

I'm starting to gravitate towards salishsea.io being a source of taxonomic authority for apps like orcasite. True to its domain suffix ".io", Salish Sea would take a request from an app for taxonomy of the Salish Sea ecoregion, query all relevant sources for the latest standardized labels (understanding both source and receiver data schemes), and provide only the requested resulting taxonomy.

As an example of how this model would work for a J pod bout, a UI in orcasite (e.g. the moderator interface for bouts) would need taxonomic labels for the signal source(s) and the signal type(s). The source and signal taxonomies would evolve over time and be derived from a changing suite of sources and communities.

The source labels would come from first from iNaturalist as species names (e.g. Orcinus orca). Then salishsea.io would know (from community agreement within the salishsea-io repo) that the Orcinus orca species has 4 ecotypes that have occurred within Orcasite's ecoregion (SRKW, Biggs, offshore, NRKW). Leveraging further community agreement about the best/current source of authority for each ecotype, salishsea app would check to be sure it has the current/complete taxonomy for each ecotype. At the moment, it could query finwave.io for the Bigg's ecotype; soon I expect it could query the SRKW health database for the SRKW ecotype; NRKWs might eventually come from DFO or OrcaLab or finwave; offshores may eventually come from DFO. In each case, salishsea would get for each ecotype: pods, matrilines, individuals (alive and dead; alphanumeric labels and any "common" names as soon as a calf is confirmed viable). The source(s) of authority will very probably evolve; in an ideal future world, a government federation like NOAA+DFO would be such a source... but for now it seems to be NGOs like MERS/DFO in Canada for Bigg's and the Center for Whale Research in the US for SRKWs.

The signal labels would come from the listening community. I've drafted an example in the signals-SRKW repo. So as soon as a moderator refined/confirmed biophony to the species and/or ecotype level, the standard signal labels would be pulled from the relevant repo(s). Call, whistle, click, and percussive would be labels common to both Bigg's and SRKWs, but if SRKW is confirmed, then more granular acoustic labels would come from signals-SRKW repo]. Other apps downstream of orcasite, like MAIPL for group-annotation of Orcasound bouts to signal type, would also leverage these labels...

All orcasite (or another regional app) needs to know is the source of authority for the geography of a hydrophone where a bout has occurred. Right now, all hydrophones are deployed within the Salish Sea, so salishsea.io would be the authority. If we someday build humpbacksound.net from Alaska to Columbia, humpback hydrophones in the Salish Sea would get their source taxonomy from salishsea.io whereas hydrophones in Central America might harmonize acoustic labels across the whole range of humpbacks (e.g. from future signals-humpback repo that has standardized signal type labels in Spanish).

[scottveirs]

Also @rainhead -- to clarify the current state of "moderator habit" in the bout definition UI:

I'm the only moderator who does this (I've not onboarded Val or David Bain), but during alpha testing I've "standardized" the tag field by trying hard to start typing free text, but then carefully selecting any matching labels that I've previously created. In this sense, the free text labels are standardized, but in a brittle way, with the hope that they could be used to sort the bouts.

Here's a bout with tags:

Here's the tag completion UI I use to check if a label already exists or to create a new one:

[rainhead]

Thanks, Scott. There's a lot to talk about here, and we can dig into it a bit on Friday. But it helps me in understanding more of your vision. One question that will be relevant in the near term is whether you want to support the "+L?" label. It looks like you didn't create a tag for it in your example, so I'm guessing it's puntable. From the perspective of salishsea.io, the question is whether this bout should come up in any form when searching for L-pod occurrences.

You've talked a bit about where data would come from. What other needs drive the effort, besides tagging sightings on salishsea.io and bouts on orcasound?

[rainhead]

https://github.com/salish-sea/animals/ has a lot of documentation on how the animal register will work, its scope, etc. There are open questions in its issue tracker. There's a lot of thought going into its design, but consuming it should be fairly straightforward. The main gist is:

• the scope is: individual animals and groups observed and tracked by Orcasound and SalishSea.io.
• any individual animal or group of animals gets its own synthetic identifier in the "SSA:" namespace, for "Salish Sea Animal".
• the register can be used to look up relationships, labels, and third party identifiers from the synthetic identifier, or to resolve "J123" to an "SSA:" id.
• the register is small and slow-changing, and consuming it should not introduce a runtime dependency. It will be published as a TSV build artifact.
• mechanisms are defined for how data changes over time, allowing for the deprecation and replacement of identifiers.
• https://github.com/orcasound/signals-srkw would eventually be built out similarly.

These identifiers would be used by any of our systems to identify animals in messages on the wire, or in archival storage.

This doesn't say how we should model tags. There are a bunch of open design questions that maybe Orcasound itself doesn't need resolved as long as tags are mostly consumed by people. They become more important as we integrate third party systems, build data exploration tools, and publish datasets in standardized formats. For example,

• maybe the most urgent question here is, "how do we capture uncertainty"? "J123?" makes sense to a human consumer; maybe
• SalishSea.io also has an existing need to model presence and absence simultaneously: "J123s minus J234".

These questions (and proposals) don't currently live anywhere. This thread is as good a place as any, for now.