An Event entity represents a date, or range of dates, for which source information exists. This is slightly different to the everyday usage as something that happened at a particular time and place but the definition is deliberate in order to construct substantiated histories, and effectively provides the where-and-when context for subject-entity references within those sources.
A given source may support a number of Events to different levels:
Events are not specific to a single subject entity, such as a Person, and as many subject entities as required can be associated with the same Event. Effectively, those subject entities are the thing of interest mentioned in the supporting sources. Information derived from a source is nearly always going to be associated with a given time and place — even if implicit — and this is why STEMMA associates sources with its Event entities (see Evidence and Where to Stick It for more details).
There may even be zero subject entities associated with an Event, as in the case of a country-wide census. This allows a high-level definition of the census Event that fixes the date, place, event-type, etc. Other, more-specific Events can then be defined in terms of the higher-level one in order to refer to a particular household, and hence individual Persons. Although the associated Place is syntactically optional, for a non-abstract Event one must at least be inherited from a base Event, or be determinate from the largest common Place of any child Events, or be provided by the context (e.g. the use of an Eventlet within a Place entity). In other words, all Events must have an effective Place. When loading the definition of a specific Event, though, any explicit start/end dates or place specified by a hierarchical parent must be correctly bounded any explicit equivalents in the loaded Event; for dates, this might involve the use of implicit constraints between the parent and child Events.
The narrative sections of a Person, Place, Animal, or Group could describe an event in an informal long-hand style, and could even embed computer-readable dates. However, if the event is deemed to be of sufficient importance (e.g. affecting the lives of more than one Person) then the description should be formalised as a top-level Event entity. That Event entity can then be connected to the relevant subject entities, and this is recommended since that common reference point then links the subject entities to give a better account of their history.
Although less common, an Event can be associated with a Place that is a subject entity rather than the Event’s primary Place. An example would be the commencement of a voyage that records the intended final destination.
If an event is only relevant to a single subject entity then it can still be formalised without having to create a top-level Entity for it. The Eventlet is a slightly cut-down version of an Event that can be embedded within the relevant subject entity, and which does not require a unique Key associated with it. The other main differences from an Event entity are that an Eventlet does not have any hierarchical relationship, or a <BaseEventLnk> element, or any external IDs. They are primarily a syntactic convenience and offer no functional advantage over top-level Events. Every Eventlet could be converted to a valid Event if necessary. NB: A <SourceLnk> element within an Eventlet must refer to an enclosing subject entity (e.g. by a <PersonLnk> element), without an explicit Key value, and no others of the same entity type; other types being unrestricted. This prevents an Eventlet trying to represent a shared event.
Simple Events represent just one date but protracted Events represent both a start and an end date. This means protracted Events have a duration associated with them.
<Event Key=’key’ [Abstract=’boolean’]>
[ <Title> event-title </Title> ]
[ <Type> event-type </Type> ]
[ <SubType> event-subtype </SubType> ]
[ PLACE_LNK ]
<When [Value=’std-date’] [DATA_ATTRIBUTE] ... >
[ DATE_ENTITY ] [ EVENT_CONSTRAINTS ]
[ TEXT_SEG ] ...
</When>
[ <Until [Value=’std-date’] [DATA_ATTRIBUTE] ... >
[ DATE_ENTITY ] [ EVENT_CONSTRAINTS ]
[ TEXT_SEG ] ...
</Until> ]
[ <ParentEventLnk Key=’key’>
[ TEXT_SEG ] ...
</ParentEventLnk> ] ...
[ <BaseEventLnk Key=’key’>
[ TEXT_SEG ] ...
</BaseEventLnk> ]
[ EV_SOURCE_LNK ] ...
[ EXTERNAL_ID ] ...
[ TEXT_SEG ] ...
</Event>
<Eventlet>
[ <Title> eventlet-title </Title> ]
[ <Type> event-type </Type> ]
[ <SubType> event-subtype </SubType> ]
[ PLACE_LNK ]
<When [Value=’std-date’] [DATA_ATTRIBUTE] ... >
[ DATE_ENTITY ] [ EVENT_CONSTRAINTS ]
[ TEXT_SEG ] ...
</When>
[ <Until [Value=’std-date’] [DATA_ATTRIBUTE] ... >
[ DATE_ENTITY ] [ EVENT_CONSTRAINTS ]
[ TEXT_SEG ] ...
</Until> ]
[ EV_SOURCE_LNK ] ...
[ TEXT_SEG ] ...
</Eventlet>
The Properties associated with each subject entity mentioned in the supporting sources are attached to the corresponding Event-to-subject link (see Timelines, Multi-Source Events, and Personal Events). If there is no corresponding subject entity (e.g. a reference to an incidental person) then an unkeyed <PersonLnk>, <AnimalLnk>, <PlaceLnk>, or <GroupLnk> element may be used.
One of the design goals of STEMMA was to not simply date individual items, such as photographs and Property values, but to associate the aggregate with a single Event (or Eventlet). If, for instance, a source described someone changing their occupation, residence, and personal name — all at the same time — and there were several photograph taken at that same time, then the aggregate knowledge could be associated with the corresponding change Event; this being more informative than simply duplicating the same date and source details on each item.
Each Event can have one-or-more <SourceLnk> elements to represent summarised information from specific supporting sources. References to people, animals, places, or groups, can be assembled into these elements as sets of associated Property values (e.g. name, occupation). These summary forms can be connected to specific subject entities if a correspondence has been deduced. A Property that references another named subject entity, such as a place or relative, can be done using a PlaceRef-type Property with a Key attribute. NB: Properties for the Event itself (e.g. the dates and the place) would be provided separately in the <SourceLnk> element. When SourceLnk is employed within an <EventLet> element then only a single un-keyed <PersonLnk> element (or <PlaceLnk>, etc., depending on the enclosing entity type) can be specified of the same type as the enclosing entity.
<SourceLnk Key=’key’>
[ PERSON_LNK ] ...
[ ANIMAL_LNK ] ...
[ PLACE_LNK ] ...
[ GROUP_LNK ] ...
[ EVENT_PROPERTY ] ...
[ TEXT_SEG ] ...
</SourceLnk>
The <BaseEventLnk> element may nominate an Abstract Event from which data may be inherited by the current Event, in much the same vein as base classes and derived classes in software programming. An Abstract Event must define no embedded Keys and can only reference other abstract entities. It is also allowed to omit the <PlaceLnk> element.
The event-type provides a coarse grouping of similar event-subtypes such as Union, Birth, Death, Religious, Legal, Travel, and Military. See Event Types and Roles for a list of these and their relationship to roles, and see Extended Vocabularies for custom event types.
The start of the Event can be specified either through a combination of a date and Event constraints, or by reference to a different Event. A date may have error margins associated with it (see Dates), and Event constraints (see Constraints) allow it to be limited by the dates of one-of-more other Events. These may be used separately or together to express something similar to ‘Event1 happened in c1810 but it was after Event2 and before than Event3’. When the start of an Event is simply defined in terms of a specific other Event then it inherits the start date definition of that other Event.
Notice that the Event has an optional definition of an end date. This effectively defines a protracted Event that spans a period of time. Examples of this might include a long sea voyage which has both a date of emigration and a date of immigration, or WWI which has a date that war broke out and a separate date for Armistice Day. Each of the start and end dates can be defined in terms of discrete Events. This approach allows the two end-points to have independent Place references, which then has an obvious application for a journey. It further allows the individual end-points to be referenced separately. For instance, if something in a person's family history was relevant specifically to the outbreak of WWI or to the ceasing of hostilities then a direct reference to the sub-Event can be made.
For a protracted Event, if the <Until> element is defined in terms of a specific other Event then it inherits the end date definition of that other Event. If the specified Event is a simple Event then its only date is always applicable.
Dates may be specified either as a compact date-value (using the Value= attribute) or a more powerful date-entity (using the DATE_ENTITY structure). These should be considered mutually exclusive.
<PropertyDef Name=’When’ Type=’Date’/>
The date at which the event commenced.
<PropertyDef Name=’Until’ Type=’Date’/>
The date at which the event finished. Defaults to the commencement date.
<PropertyDef Name=’Where’ Type=’PlaceRef’/>
The place at which the event took place.
Any custom Event properties can also be used in the context of EVENT_PROPERTY. See Extended Properties.