EVENT


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.

Attributes
Relationships
(Possible restriction that only one of the above three relationship types may hold at once for one EVENT - see above)


Comments

hrworth 2010-11-30T07:04:41-08:00
Location Qualifier
On the Page, is says:

"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?

Thank you,

Russ
greglamberson 2010-11-30T09:38:03-08:00
Russ,

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.
brianjd 2010-11-30T09:56:21-08:00
Russ,

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.
brianjd 2010-11-30T10:12:51-08:00
Greg makes the most important factual statement that needs to always be in our minds.

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.