Feature Request - collecting event consolidation

[tucotuco]

Is your feature request related to a problem? Please describe.
This feature request is related to a problem in interpreting which occurrences establish a relationship between organisms.

Describe what you're trying to accomplish
While developing a potential data publishing model for biotic interactions as part of the Diversifying the GBIF Data Model project, I tried to use organism relationships ('host of', parasite of', 'ate') in Arctos as a test case. I can successfully make biotic interactions with Arctos relationships, but only under a very specific set of conditions - that the organisms on both sides of the relationship have one and only one occurrence (and even then I have to make an assumption that the two occurrences are actually at the same place and time.

This set of detectable biotic interaction is a rather limited compared to what Arctos could theoretically do.

Describe the solution you'd like
One part of a possible solution is allow collecting events on specimens across collections to be merged. An alternative might be to enable two collecting events (again, across collections) to be specified as the same without having to make any changes to either of them.

Describe alternatives you've considered
Trying to establish programmatically that two collecting events are the same from their content can be challenging. The two can differ from each other in ways that do not mean they are distinct.

Priority
Depends on how important it is to be able to answer the would-be answerable question of when a parasite was actually found on its host as opposed to one of the many times the host was captured.

[Jegelewicz]

allow collecting events on specimens across collections to be merged.

We allow that and if they are exactly the same, it just happens eventually.

[Jegelewicz]

Trying to establish programmatically that two collecting events are the same from their content can be challenging. The two can differ from each other in ways that do not mean they are distinct.

See above. Related records don't always get entered at the same time or even by the same person/collection so it often happens that slight differences in capitalization mean that events don't merge. It takes people to figure this out and do the work of merging - we need more people, time and resources to do this.

[Jegelewicz]

Depends on how important it is to be able to answer the would-be answerable question of when a parasite was actually found on its host as opposed to one of the many times the host was captured.

The problem again is resources. Apparently this is VERY important, but we do not apply resources to do it right (ideally, the parasite would share an event with the host, but have a secondary collection event when it was removed from the host?).

[dustymc]

exactly the same

That's the problem - they're usually not, we have TONS of denormalizers in the model (error 1KM vs 1000M), that makes usage difficult. If we can do better then we clearly should if we want our records to support this kind of usage.

takes people to figure this out

Some of it, yes. Some of it's the structure of the model and resistance to automation and such.

problem again is resources.

Some of it, but some of it's "us." Eg we've come full-circle around to the idea that cataloging "occurrences" is better than cataloging "individuals" and that turns out to be very true for this use case. It also leads to the problem of eg 'parasite has two hosts,' which can (hopefully...) be addressed with good identifiers - eg if the hosts share "12" (bare collector number or something) then they're just going to get rejected from the analysis, if they share something like https://arctos.database.museum/guid/arctos:Entity:10 (clear GUID, possibly even carrying metadata) then maybe not. We've sorta accidentally made this problem much more approachable than it would have been even from Arctos a decade ago, but we also still seem to have some improvements which could be made. (There's plenty of recent resistance to less-ambiguous identifiers, for example.) This is rare feedback from a user who's trying to make a precise analysis of the data, and it should be used to shape our models, practices, and recommendations going forward.

I asked for this to be posted here, there are clear problems in how data are recorded, not (only, perhaps) in how they're passed to aggregators - this is not an aggregator issue.