I'm borrowing Adrian's model, and marking it up. This entity type represents the current information known about an event that may have affected or involved one or more persons, groups or locations. E.g. it might contain information about: the San Francisco earthquake; an individual's birth - with details of their parents; the residence of a group of people in a location; a marriage ceremony; the merger of several railroads; the split of a US Territory location into State locations, etc.
Note this is not designed to record comprehensive data about historical events - rather to summarize them in relation to family history.
Note 2 - I have concerns if an EVENT can affect entities of mixed types - e.g. if an event can affect both PERSONs and LOCATIONs, say. This might make the data model tricky to negotiate. I am inclined to place a restriction on them to say an EVENT can only affect one type at once.
- Event-type - mandatory - defines what type of event this is, e.g. "birth", "residence", "merger". Values need to be defined by BG standard to accommodate all GEDCOM attributes or events that map over to BG EVENTs. In addition, BG must allow the user to extend this list of definitions as per current GEDCOM. User extensions must be identified in such a way as to be permanently safe from confusion with any new event-types defined by future BG standards (e.g. user extension values might be prefixed by underscore as in current GEDCOM).
- Event-name - optional - name or short description of this event - in some instances, no name is necessary because the type and the related people etc (with their roles) is sufficient to define the event. In other cases, a name (e.g. "San Francisco earthquake") may be of use.
- Date - optional - date or date range (coded up somehow), during or between which the event is believed to happen.
- Location-pointer - optional - points to the LOCATION entity for the location at which this event takes place.
- Location-qualifier - optional - if omitted, assume that the event takes place at the location in question. Possible values are codes corresponding to "at", "near", "from" or "to".
- Additional-location-pointer - optional - points to the LOCATION entity for an additional location of relevance to this event. For instance, "emigration" really requires two locations, to define from where someone emigrates and to where.
- Additional-location-qualifier - optional - if omitted, assume that the event takes place at the additional location in question. Possible values are codes corresponding to "at", "near", "from" or "to".
- Surety - optional - a value on a scale indicating how certain the data is.
- An EVENT may involve one or more PERSONs
- An EVENT may involve one or more GROUPs
- An EVENT may involve one or more LOCATIONs
restriction that only one of the above three relationship types may hold at once for one EVENT - see above)
- An EVENT may take place at one LOCATION (note attribute to define this relationship is already written above - location-pointer)
- An EVENT may additionally take place at one LOCATION (note attribute to define this relationship is already written above - additional-location-pointer)
- An EVENT may have one or more RESEARCHERs. May want to add either internal to EVENT or separately unique data for each RESEARCHER (such as a date).
- An EVENT may have one or more SOURCEs. May want to add either internal to EVENT or separately unique data for each SOURCE.