Steve Hayes wrote: > On Thu, 31 Jan 2008 07:11:12 -0500, Haines Brown > <brownh@teufel.hartford-hwp.com> wrote: > >> A very interesting thread. I hope no one minds if a non-genealogist >> jumps in with questions. >> >> My sense of the distinction of a relation-based and an event based >> structure is clear to me only in the abstract, but not in concrete >> terms. Would someone be willing to offer a simple example of each to >> help make the distinction clearer? > > I've given this a different subject line because it is a different thread. > > I've long felt a need for event-based software that would take a different > approach to ordinary lineage-linked genealogy software and take a different > approach. It woudl be useful for family history research rather than pure > genealogy, and for other kind of historical research as well. > > I've even developed a sort of data model, which I've semi-implemented in > creating a database to illustrate it. > > Let me try to give a concrete illustration of the difference. > > Say you are writing a biography of a person, and you want software to help > you in your research. > > In a hypothetical event-based program you would enter people who impinged on > the life of your subject as you do with genealogy software. Some would be > genealogically related and some not. > > The birth event, for example, would have your subject's birth, with parents > (obviously), but others like midwives, obstetricians and so on also linked. > > Twenty-one years later there might be a 21st birthday party, and you would > have that as an event, and a description of the event, and then link people in > your database to the event -- friends and relatives who attended. > > After entering a lot of events in the subject's life, you could create a > chronology of the events, and of the people associated with your subject at > each stage - parents, friends, teachers, classmates, bosses, and so on. If you > were doing a biography, you could include in notes on various people their > recollections of the subject, and the subjects recollections of them. > > In this hypothetical program, it should be possibly to import family relations > (via GEDCOM) from lineage-linked software, but also from address books etc. > > Such software could be used for other purposes. > > Onme of the things I do research on is African Independent churches. I have > three different databases or datasets -- churches, leaders and events. It > would be useful to be able to link them in a relational database, but I don't > have the skill to design such a database. Also, as software goes obsolete one > would spend more time on redesigning it than entering and manipulating data, > so you would never get any reseach done because you would always be tinkering > with the tools. I once tried to do it with Paradox, but now everyone uses > Access, and it would have to be rewritten from scratch, and I've never found > books on Access that can tell me what I used to know about Paradox. > > So I lumber along using an old DOS program called Inmagic, which serves my > purpose. > > I'm playing with a Windows program called askSam (I also continue to use the > DOS version) which I use for entering raw genealogical data from different > sources and material for other research projects. These are useful research > tools, but an event-based relational program would be a useful addition. > What I have in mind as an ideal would go one step further and be record-based (a record in this sense being a historical record, not a database row). The reason is that a a single event may be documented by more than one record whilst a single record could document more than one event. As a real example of the first a local apothecary documents the death of a patient, John Goddard, his burial a few days later and a few days later than that the death of the patient's wife, name not stated. The parish register documents the burials giving the wife's name as Elizabeth (off-hand I can't remember whether the register gives the dates of death). As a hypothetical example of the second one might have a family bible entry recording a death in childbirth. This would be a single record but two separate genealogical events, a birth and a death. The first section of such a data model would contain a class for the record itself and a class for the source. This section deals with evidence. The next section would be a set of classes for the individuals, events and places named in the record. Each object of such classes would be linked to a single object of the record class. Names of people and placed would be given exactly as they occur in the original record and the role played in the record would be given. (What happens of the name is given twice with different spellings? There would be two records one for each spelling. For instance I have a marriage register entry where the bride's name was filled in as "Kay" but she signed "Kay".) This section deals with analysis of the evidence. Each object would have a globally unique identifier (see Wikipedia for UID or GUID). Once published an object should not be modified. Analysis objects should not be merged. This solves one of Robert Grumbines' problems. We don't need to trace the route by which one of these objects has been acquired: all copies should be the same and if anyone feels that a correction should be made then a new object should be created with a cross reference to the old. The next section would be a set of classes to represent what we believe to be the historical individuals and events and geographical places which we believe underlie those given in the records. As regards people and events these could be quite light-weight objects as the bulk of the information relevant to them is carried in the objects linked to them; their main purpose is to exist as hubs for such links and to provide a standard name for an individual (e.g. "John Goddard of Scholes" as a standard name for an individual who finally settled in that hamlet after at least three previous homes spanning two parishes). This section represents part of our historical reconstruction. My separate classes for analysis and reconstruction individuals is reflected in the discussion of different categories of examples of the PERSONA entity in the GENTECH documentation but there is no differentiation in the actual model. There would be a set of classes ("association classes" in UML terms) used to link analysis objects to reconstruction objects. cf the ASSERTION entity of the GENTECH model. These would give an estimation of the confidence with which we link the reconstructed individual to the analysis objects. These could record negative associations - for instance to state that John of Scholes was not the John Goddard whose death was recorded by the diarist in my early example. There would be another set of classes to represent relationships between reconstructed individuals. These could be families or, in Steve's case, churches. cf GENTECH's GROUP entity. I would have an association class to link relationships to individuals. Again, cf GENTECH's ASSERTION. For instance there would be a relation object for John of Scholes' family with an association class to represent John's role as father. Ideally the reconstruction objects would be stable in much the same way as the evidence classes. The association classes would be less stable - they could be added or subtracted as views change and they provide for the many-to-many links between analysis and reconstruction which would record the multiple candidate situation I've posed in other posts. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk