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
