Hi folks,

In our meeting today everyone was kind enough to give me a couple of minutes to make a survey about how a Humboldt Extension record is expected to relate to an Event record. I think it is of extreme importance that users of the extension understand how this is supposed to work, and that our paper explains it. If done correctly, consumers of the data won't actually need to understand it, because the results will already be explicit and not possible (famous last words) to interpret incorrectly.

I made a couple of graphics to help show how the extension records are supposed to relate to events, and how not. Thanks for requesting this, Anahita.

[image: image.png] Figure 1. Humboldt Extension records contain metadata about Surveys. The combination of a Survey record with its Event counterpart effectively creates a Survey Event (an Event that also has Survey metadata) - you could combine the Event terms and Survey terms into a single row in a spreadsheet. A Survey Event can, but doesn't have to, have a parent Event. As usual, the parent Event (a project, in the example) has to encompass the Surveys and other Events that are its children, both temporally and spatially. This model describes the relationship as a one-to-(zero-or-one) between Event and Survey.

[image: image.png] Figure 2. Diagram of a model with a one-to-many relationship between Event and Survey. Such a model would allow an Event record to have zero, one, or multiple Survey records. The spreadsheet shows an example that would be valid in this model, with one Project Event and its related Survey records. One would interpret the data in the spreadsheet to mean that the Project Event event1 has multiple Surveys. The issue is that a Survey record contains metadata about a Survey, not about a Project. Without the specific protocol, temporal and spatial context information the Event is supposed to provide, the Survey is effectively disabled.

The lesson is that the Event structure is supposed to be entirely within the Event, using the parentEventID to create the hierarchy between Events of different types and scales, not the relationship to Surveys. Surveys are just one of the different types of Events, and those have the Humboldt Extension, while the other types of Events do not. The other types of Events might have their own distinct extensions (e.g., Occurrence Extension).

For the sake of partial completeness, the same reasoning applies to Occurrences. Occurrences are Events too )"Occurrence Events". The occurrenceID needs to correspond to an eventID for the Event that gives the context and protocol for the Occurrence. Those Occurrences can be the result of a Survey, but a) they won't have a Humboldt Extension record attached to them and b) the Survey Event they are a result from would be given by the Occurrence Event's parentEventID.

I hope that last paragraph doesn't confuse the issue I was trying to address about the Event/Survey relationship. It is just a parallel example and you can ignore it if it muddles rather than clarifies.

Cheers,

John