New Term - eventType

[tucotuco]

New term

• Submitter: John Wieczorek
• Efficacy Justification (why is this term necessary?): The hierarchical Event structure is not currently capable of distinguishing what different Events are for.
• Demand Justification (name at least two organizations that independently need this term): The need for an eventType to distinguish distinct kinds of activities has been promoted in the Interactions Interest Group (The eventType term of dwc:Event class interaction#22), the Camera Trap Data Package repository (What are the Darwin Core equivalents of Camtrap DP terms camtrap-dp#169 (comment) and What are the Darwin Core equivalents of Camtrap DP terms camtrap-dp#169 (comment)), in discussions about the vocabulary for basisOfRecord (umbrella issue related to dwc:basisOfRecord and an Evidence class #302), in the design of conceptual and data publishing models in Diversifying the GBIF Data Model Project (https://tinyurl.com/diversifying-gbif-data), and for OBIS .
• Stability Justification (what concerns are there that this might affect existing implementations?): The addition of this term will affect the definition of the GBIF Event Core, but this addition is already anticipated (see Create initial draft of the eventType vocabulary gbif/vocabulary#107).
• Implications for dwciri: namespace (does this change affect a dwciri term version)?: Yes, an equivalent term in the dwciri: namespace will be required.

Proposed attributes of the new term:

• Term name (in lowerCamelCase for properties, UpperCamelCase for classes): eventType
• Organized in Class (e.g., Occurrence, Event, Location, Taxon): Event
• Definition of the term (normative): The nature of the Event.
• Usage comments (recommendations regarding content, etc., not normative): Recommended best practice is to use a controlled vocabulary. Regardless of the eventType, the interval of the Event should be captured in eventDate.
• Examples (not normative): Sample, Observation, Site Visit, Biotic Interaction, Bioblitz, Expedition, Survey, Project (There is a prospective vocabulary for consideration at https://registry.gbif-uat.org/vocabulary/EventType/concepts, but this proposal is not to define an eventType vocabulary).
• Refines (identifier of the broader term this term refines; normative): None
• Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative): None
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): Not in ABCD

[albenson-usgs]

I believe this would also resolve an OBIS issue in wanting to identify the type of event and previously using type iobis/obis-issues#172
@wardappeltans, @pieterprovoost, @bart-v

[qgroom]

Some more clarification, perhaps in the examples, would help define what an event consists of. Would it include a bioblitz or an expedition for example? From the examples you might think not, but it would be better to be clear.

It might also be worth explicitly stating that an event span should be detailed in dwc:eventDate.

[albenson-usgs]

I don't see the need for an "event span". The event span could be determined based on the first and last eventDate in the dataset.

[tucotuco]

@qgroom It would be a little odd to make the recommendation about the other term just for eventType. What about eventType would be special that it would merit the suggestion to put the date in the eventDate field? We don't do that anywhere else in Darwin Core definitions or commentaries unless the dependency is absolute, such as with a value and its units.

The question of examples to include is extremely important for this term, I think. People will be tempted to use the examples that get shared, so we should spend some effort to get it right enough not to regret what goes in there. Ideally, the formal construction of a vocabulary to go with this term would be advisable, as was done for degreeOfEstablishment, for example, but the range of possible event types is enormous and with complex relationships. A pragmatic way forward, knowing that the term is so badly needed, might be to implement the term with conservative examples that are very broad terms and let the community build up the vocabulary in practice via the GBIF vocabulary service (gbif/vocabulary#107).

[deepreef]

The question of examples to include is extremely important for this term, I think.

I agree completely! I also agree that a pragmatic approach is best, as an exhaustive list would be unwieldy. Perhaps a few examples from a wide range of different categories?

To the proposed list of originally included examples, I would add things like:
expedition
exhibition
imaging process

If you want to cast a broader net, you might include things like:
transaction [e.g., acquisition/loan/borrow/disposal]
preparation [or curation] process
translocation [an event where items are moved from one storage location to another]
geologic

And if you really wanted to go wide you could add things like publication, and other such things bounded in place and time.

There are many other kinds of events that instances of DwC classes participate in, and each of them could have dozens and dozens of "flavors"/children. But the point is, it might be good to use the examples to help convey some sense of the scope of what dwc:Event (potentially) encompasses.

I tend to err on the inclusive (i.e., broad) scoping of these things, so I would allow for any action bounded in space/time (which is consistent with the current definition of dwc:Event)

[qgroom]

I don't see the need for an "event span".

I was not suggesting a new term, only that dwc:eventDate can legitimately hold a data span and this should be used to indicate the length of the event.

The event span could be determined based on the first and last eventDate in the dataset.

This is exactly the issue. dwc:eventDate is normally viewed as an observation level term, so if expedition and bioblitz are legitimate entries in this field there is potential crossover between dataset level information and record level information.
The current examples are suitable for observation level eventTypes and if longer term event types are not the intended usage of this term we should say so, as it is not currently clear. If longer term events are intended usage for eventType then it tends to imply that dwc:eventDate can also be used for dataset level dates.

[deepreef]

I agree with @qgroom: There is definitely a need for eventDate to accommodate a range (span). ALL events span some period of time (even if it's just milliseconds). In pretty-much any database I develop, date data are captured with startDate and endDate (or, as appropriate, startTime and endTime).

That's a topic of discussion better suited for a dedicated issue in GitHub, but in the context of eventType, adding this term sort of elevates instances of dwc:Event to their own standing -- not just playing the role of an intersection of Location+Time to support other DwC classes. As such, I think it's important that each instance of dwc:Event be self-reliant on its own properties, and not dependent on properties inherited from related records (be they child events or occurrences or whatever).

[albenson-usgs]

I agree with @qgroom: There is definitely a need for eventDate to accommodate a range (span).

eventDate already accommodates a range.

I think my concern is with the language "...event span should be detailed..." and "this should be used to indicate the length of the event.". The use of should makes it sound like a requirement and I don't think it is. It's something you might consider doing but in my mind it's not something you have to do. Maybe it's as simple as changing to "consider detailing event span in eventDate".

[ArthurChapman]

I draw your attention to Issue #140 in the Data Quality Interest Groups Tests and Assertions (tdwg/bdq#140) where we have developed a test for dwc:eventDate Duration in Seconds (we don't go below seconds)

[deepreef]

eventDate already accommodates a range.

Yes, but in a somewhat clunky way. Also, the "Not suitable for a time in a geological context" qualifier in the definition precludes defining events on such timescales. Maybe those should not be represented as dwc:Event instances; but in other contexts we have discussed the notion of an organism based on fossil material (e.g., dinosaur) being represented through an occurrence instance associated with the time and location (i.e., Event) of its death. Obviously, such values for eventDate would not conform well to the recommended best practice of formatting in accordance with ISO 8601-1:2019; but it seems to me that dwc:Event should accommodate instances where the value of eventType implies timescales outside the range of the Gregorian calendar.

Or, maybe not -- maybe the scope of dwc:Event instances should be explicitly confined to smaller timescales (as eventDate already implies) -- such as representation through terms organized with the dwc:GeologicalContext class. If so, this would inform what sorts of examples should be included (and, perhaps, explicitly excluded) for values of eventType.

[dr-shorthair]

For times the correct terminology for a time entity with a distinct beginning and end is Interval or Period (not 'range').
The beginning and end each occurs at an Instant.
The separation of the beginning and end (i.e. the size of the interval) is its duration, which is a quantity of seconds/days/years etc.

Perhaps looks nit-picky but it is helpful to keep the terminology clean.

[dr-shorthair]

@deepreef wrote:

ALL events span some period of time (even if it's just milliseconds)

Yes. This is a key part of Allen's theory

[af-97]
Actions and events in interval temporal logic In: Spatial and Temporal Reasoning. O. Stock, ed., Kluwer, Dordrecht, Netherlands, pp. 205-245.. J.F. Allen; G. Ferguson. 1997. URL: http://dx.doi.org/10.1007/978-0-585-28322-7_7
[al-84]
Towards a general theory of action and time. Artificial Intelligence 23, pp. 123-154.. J.F. Allen. 1984. URL: http://dx.doi.org/10.1016/0004-3702%2884%2990008-0

[qgroom]

@albenson-usgs wrote:

Maybe it's as simple as changing to "consider detailing event span in eventDate".

Yes, that is all that is needed. It makes the explicit connection between the eventType and the eventDate. Then it makes it more clear that, for example, if they write biotic interaction in the eventType they should be detailing the or interval of the interaction in eventDate, not the whole period of the expedition. Obviously, few people measure the time interval of an interaction, but if this connection isn't made some events will be recorded with their actual interval and some not, but you will not be able to tell the difference between the two.

It needs to be clear that eventType and eventDate are observation level terms at the bottom of the hierarchy of potential dates and intervals that could be used to describe a dateset.

[tucotuco]

This proposal has been updated to accommodate all comments thus far.