109Re: An event database
- Nov 18, 2006--- In firstname.lastname@example.org, "Paul Blair" <pblair30@...> wrote:
>--- In email@example.com, "Ray Murphy" <raymur@> wrote:[....]
>>>So I wonder if anyone knows of the existence of such a program,
>>>or if anyone else has felt the need for it.
>I've not heard of such a program...but Google is your friend!
>>>As I see it, it would be useful not just to genealogists and
>>>family historians, but to general historians, biographers and
>>>Has anyone felt the need for such a program? Can anyone else see
>>>that it might be useful?
>>>So this is really a half-baked idea and I'm hoping that someone
>>>will be willing to bake it.
>>> Steve Hayes
>>Ideally what I need is a modified genealogy program that does theRM: Yes, ACS is too expensive to buy as an extra, but it is only
>>(1) Stores more detail about birth location, i.e. latitude and
>>longitudes and time zones (incl Daylight Saving) via a plug in
>>module called ACS Atlas, which handles most places in the world.
>ACS is a $200 product, which wouldn't encourage its broad use.
>There are other geographical databases (eg the US Board on Geographic
>Names [BGN]) that are free, if cumbersome. Google Maps are free, and
>places can be "spotted" for lat/long in traditional and decimal
about $50 (AU) if it's bought as an extra with popular programs.
I suppose any type of 'atlas' (gazetteer) could be used - including
self-populating ones that are filled in on the fly as required. Users
would only need to select their default atlas in a listbox, but
they could also have their own special atlas that they could
crank-up for those old or tiny place names in their own state which
included the abbreviations that were commonly used. High precision
coordinates wouldn't be needed for genealogy.
It wouldn't matter what format was used by a gazetteer to input
geographic coordinates - DDMMSS or DD,MM or DD (decimal) if the
program knew which style the gazetteers used. In any case the
genealogy program developers could easily settle on a visible (and
printable) format that was most popular amongst users.
>There is no GEDCOM standard for defining places - it was proposedRM: I've found in the work I'm doing that 3 fields are suitable for
>for (I think) 5.5, which never made it to finality. So there is
>absolutely no standard way to code a conversion utility from , eg
most places, but India really needs 4 - with the last field being
Unfortunately the U.S. is out of kilter with the rest of the world
in relation to place names and expects everyone to memorise their
state name abbreviations. I found that it was easy enough to
overcome that in a program by shifting the last "Place" (say CA or
GA) back one field and then placing "U.S." in the Country field.
I think that strictly speaking some American states ARE actually
countries, but that's another story.
>>(2) Allows the retrieval and export (in csv format) all data thatRM: Yes, events mostly, but it could be used for anything at all.
>>fits relationship category pairs such as Mother-Child;
>>Mother-Son; Father-Daughter; Person-Great Grandfather,
>All what data is this? In this context, I guess events?
For example personal details or characteristics could also be
entered and automatically placed with "events" (using the birth date
as the artificial event date) so they could be exported. That could
include family health problems and cause of death. With such a system
all (recorded) cases of gout or depression etc could easily be found.
>>(3) Stores (suitable) dates in an extra column in DATE format,RM: One date field could feed the other. The default could be real
>>so that sorting is possible and accurate dates can be separated
>>from approximate dates.
>Legacy uses MS Access, and has a way of storing dates as text,
>that allows eg Abt 1948 to fit between 1.1.1947 and 1.1.1949 - but
>this requires quite a bit of coding to make it work. Even if you
>store accurate dates in one field and "about" dates in another field,
>they have to be "married" to derive a chronology.
dates, but each time an "illegal date" was entered (such as Abt
1926) the program could say "Press the option button to allow the
insertion of an approximate date". Such a system could help mimimise
errors in day-of-year (and year) for places that did not adopt the
Gregorian calendar. (It took 350 years from 1582 for the whole world
to accept it but many people are not aware of it). I'd imagine that
in some cases genealogists are scratching their heads and wondering
how a certain person could have been born in a certain year when they
have alternative documentary evidence that indicates otherwise.
>>(4) Allows the retrieval and export of all Names + Events of aRM: I'm not familiar with Legacy, but it seems that genealogy
>>particular category, (selected from a Listbox) including such
>>things as marriage, engagement, childbirth, death, migration,
>>illnesses. In fact any event at all (literally).
>>Currently I'm developing a (non-genealogy) program that does all
>>the above things for 600 categories, but it cannot import from
>>gedcoms in a meaningful way yet, so I'm trying to make an MS Access
>>'intermediate' program to bridge the gap. It only took a few
>>minutes to create the link between people and the
>>standard(genealogy)Events, but I need to somehow place *people* in
>>the family tree in the Events table.
>>When I arrived here I saw that there was an MS Access event
>>database already in this group's Files section. I've also had a
>>look at the discussion about it, and even though I'm avidly
>>interested in the whole topic of relational databases and people's
>>events, it hasn't all sunk in fully yet - partly because I don't
>>understand the full capability of relational databases.
>Again, Legacy is Access. Their structure, briefly, is that all
>data "hangs" from individual records. Marriages, families, events are
>all constructed on an "individual" record matched with some other
>record (or records).
programs are designed to go back only one generation when looking for
anything. For example I doubt if they can bring together sets of two
people who are 4 generations apart.
>>Besides that I'm still trying to see how lots of people can beRM: Yes, the connections are there alright for weddings, but would
>>related to ONE event, although I feel that Steve Hayes is right and
>>that genealogy needs what he's suggesting. The easiest way to be
>>certain is for all of us to dream up examples of what might (or
>>might not) be needed.
>Think of a wedding with 100 guests. There's an event with lots of
99% of people really have any use for an extra line of type which
says "Mrs Broadbent attended Christine O'Hara's wedding 04.04.1907"?
>>I can certainly see the value of it from my own (research) pointRM: It sounds interesting, although I have no concept yet of how the
>>of view - where I see each person as the technical equivalent of an
>>"event". In my own case if I entered the latitude & longitude of
>>the birthplace of a g.g.g.grandfather, I'd know that with such a
>>system that Steve is promoting, that information effectively goes
>>out to every ancestor or descendant, although it's obviously not
>>visible or wanted until immediately prior to export.
>>An extremely good reason for adding a decent Events module to
>>genealogy programs is that it will enable everyone on the planet
>>with a PC to contribute towards genetic research on a scale that is
>>impossible at the moment. The latitude & longitude preference (of
>>my own) would also help geneticists to easily see what regions have
>The broadest genie software "church" I can think of is PhpGedView.
>This is open source, and contributors add modules that extend
>software functionality. Its use is server based, which is quite an
>advantage for collaboration.
program might work for ordinary people.
- << Previous post in topic Next post in topic >>