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.
"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"."
Is this a Data Entry "qualifier" or Data Presentation Options?
Does this imply, that when entering data into the database, there should be an option for the End User to put one of the Qualifiers and that field would be entered into the BetterGEDCOM?
Or when the data is displayed in a report generated from the database, that "qualifiers" would be presented in the report with the appropriate syntax based on the other Location attributes?
All this implies is that the application developer has a mechanism to qualify and categorize the data, should they choose to use it. That's it. As you know, BetterGEDCOM isn't conceived as a database into which users will directly input data. We're just making allowances for data (which could be equated to an application feature or function) that a developer MIGHT use. They could also make no allowances for qualifiers, requiring users to enter things like "near" as text. In such a case, the BetterGEDCOM location qualifier would simply not be used.
I used Adrian model here, I thought it was a good base to work from.
My understanding is, we'd allow certain values in the location-qualifier to indicate that an event is either a point of origin or a point of destination, or is an approximate or precise location.
So, I'd say a data presentation option, but also, a part of the actual location in some cases.
Sometimes, an event comes from a history/news article or a personal letter, and may be qualified as near someplace, rather than at someplace. I think it's actually a neat feature. One which researchers could easily ignore, but provides useful information as a data element itself.
We will have absolutely zero control over how developers deploy the model we build.
All we can do is design the model. There are exactly four things we can do to encourage compliance with the model.
1) Make it robust enough to handle the necessary data.
2) Keep it compact (i.e. I don't want to see a fifty page standard, and definitely won't consider one 5000 pages long).
3) Have a process that will verify compliance, and certify those applications as compliant that pass say 80-85% of the standard, with a 100% on certain portions. There might even be levels of compliance: Bronze (conforms to base), Silver (80-89%), Gold (90-94%), Platuinum (95-100%).
Yes, I know, I think too much.