> I think an event is a valid concept between evidence & persona. In many > cases there will be a 1:1 relationship between evidence & event (if one > discounts implied events). > > However, consider an evidential statement such as "William Brown's wife > Mary died giving birth to their son John on 2 May 1738". This single > piece of evidence records two events, the birth of the child and the > death of the mother. Note also that Mary has two roles, as deceased in > the death and as mother in the birth. To hold this we need a structure > which imposes both event and role between evidence and persona. > > Note also that the statement implies a third event, the marriage of > William and Mary. It's very much vaguer - no date except for 2 May 1738 > as a /terminus ad quem/, no surname for Mary and no assurance that it > actually happened, they may just have been living as man and wife. So > it would be a matter of the user's discretion as to whether to add this > to a database. However, if we do add such records then a great many > records which seem to be 1:1 with events become 1:2. > > -- > Ian Ian, Again, I agree. I think there are three ways that event/relationship information should be able to "get into" our databases, and the three ways stem from the contexts in which the information is given: 1. If we get simple information about a vital event about a person (birth, death), then this info can be just added as an attribute of the persona. This is the GEDCOM approach. In my many posts on this subject I call this a "vital event" even though it's not really an event record per se. 2. If we get simple information about a relationship between two people (father, mother), then we just link the two persona records together with a link that carries as an attribute the type of relationship. 3. If we get detailed event information, with place, date, all the major role players, then we go whole hog and create an actual event record and persona records for all the role players. We link the personas to the event with role references and vice versa. The relationships are inherent in the roles and can be inferred by software. Let me analyze your evidence statement: "William Brown's wife Mary died giving birth to their son John on 2 May 1738". First there are three personas, William Brown, Mary ____, and John Brown. Since the three are named in the context of the birth, I would create an independent birth event with the three persons as role players in them. Since the word wife was used, but no details about the actual marriage are given, I would not create an independent marriage event. But I would link William Brown to Mary with a spouse link and vice versa. The point being the relationship implies the event just fine. Software can count this as a marriage just as easily as if there were a marriage event. Lastly I would add a "death vital event" directly to Mary, that is, not create an independent event for her death. I would add the cause of her death as being childbirth. And since I'm a good little researcher I also need to create a source record that says where the evidence statement came from, with the other records linking to it. In summary, I'd have records that look like this, here expressed in a JSON-like syntax: persona: {id: i1; name: William Brown; role: {type: father; event: e1}; relation: {type: spouse; person: i2}; source: s1} persona: {id: i2; name: Mary; role: {type: mother; event: e1}; relation: {type: spouse; person: i1}; death: {date: 2 May 1738; cause: childbirth}; source: s1} persona: {id: i3; name: John Brown; role: {type: child; event: e1}; source: s1} event: {id: e1; type: birth; date: 2 May 1738; role: {type: father; person: i1}; role: {type: mother; person: i2}; role: {type: child; person: i3}; source: s1} source: {id: s1; ... attributes of the source ...} In my humble opinion this is the optimal way to capture all the information in Ian's evidence statement as codified persona records, with an event record with the common event data, and a source record to document where the evidence comes from. All the pertinent facts are captured here and all are immediately amenable to computer processing, computer display, and so forth. Tom