[Intention] New Event Architecture

[atruskie]

Is your feature request related to a problem? Please describe.

A feature request. Our current AcousticEvent class is a poorly-designed one-size-fits-all mess that has been evolved over the entire lifetime of the code base. We want to add more structure to the types of events we detect and report but it will be difficult to add more into AcousticEvent

Describe the solution you'd like

@towsey and I have created the following proposal for a new Event hierarchy. It will allow use encode events with more data, to visualise them better, and to make testing and maintaining the code easier over time.

The intention is that this structure will replace and deprecate AcousticEvent over time.

Describe alternatives you've considered

We could augment AcousticEvent but there is a lot of old code that depends on it's behaviour and quirks. It'd take weeks to fix it all. Our suggested approach would give us the benefits of our new structure now, while allowing us to move away from AcousticEvent over time.

Additional context

@towsey and I have discussed this extensively but we are open to further feedback. Please let us know.

We also want to map ontologies for:

• source metadata (recording, location, datetime, lat/long etc...)
• event source properties (species, bio/geo/anthropo phonicness, vocalisations/stridulations, songs/calls)

but both of these can be added in later via associations and don't need to modelled as part of the event inheritance hierarchy.

[towsey]

It is worth noting that other component events are likely to arise.
Also in the diagram it is not clear in case of the CompositeEvent, that the ComponentEvent refers to the long list of component events to to the right.,