Re: [gensoft] Re: Historical research database
- On 2 Dec 2009 at 2:40, ray_murphy aus wrote:
> --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@...> wrote:I think we have a misunderstanding here.
> >> For example, instead of the diary text reading:
> >> "Commodore Smith attended the gathering ..."
> >> It could be changed to:
> >> "Commodore Smith  attended the gathering ..."
> >> then when the printout is produced, you have the  automatically
> >> omitted.
> >> The relational database wouldn't care if Commodore Smith was
> >> recorded as "Commodore P.J. Smith, RAN". It only needs his number
> >> to know that he needs to be mentioned as a person of interest at an
> >> event.
> >> I suppose strictly speaking there *IS* no (personal) relationship for a
> >> relational database to find on your behalf. The program merely wants to
> >> know "Do we print this person or not - as a person worth mentioning every
> >> time the name pops up in Event-text?" If it sees a number in the Event-text
> >> in brackets, then it knows that the preceding name needs to be added at the
> >> end of the Event-text. The hard part for the program could be figuring out
> >> where the name actually began in the text if it wasn't identical to the
> >> file card name.
> > In a program like MS Access (or other relational database program) it is
> > done by giving each event record a unique key field, and having a link
> > record that links the event record to the person record through the key
> > fields. It doesn't have to look for references in the text field at all. To
> > link them.
> RM: That's what I was saying too, but also that the ID key for each person
> needs be included in the Event-text next to each name so it can be used. If
> your current system is modified to do that, you won't need to use approximate
> search arguments like "fred w3 >green", you can simply search for his ID
> number. If you want to place those ID's in all of the events quickly, just
> have a sub routine that searches the entire database and swaps a name like:
> "Bill Smith" -- for "Bill Smith .
The report I sent was given as an example of the *kind* of report that
should be produced in the sort of program I would like to see. The mechanism
of producing such a report comes later.
The sample report was produced using a "flat file" text database program. The
"fred w3 green" search argument is just one way of finding the records to
print, used in that particular database to search full-text fields.
In the sample I gave, consider this record:
2-Mar-1853 Orange River Sovereignty, Bloemfontein
FRED GREEN GOES ON HUNTING EXPEDITION FROM BLOEMFONTEIN
WITH W. ST JOHN, JOHANNES DE SMIDT & WILLIAM DAWSON.
Fred Green set out with William St John, an officer of
the Royal Artillery, from Bloemfontein to A.H. Bain's
farm at Tempe, where they had dinner, and on to
Kwaggafontein, from where they set out on a fortnight's
People: 1. Green, Fred
2. St John, William Jones
3. Dawson, William
4. de Smidt, Johannes
Sources: 1. St John, Diary, p. 54
That is a formatted report from the database, but the underlying record in
the database looks like this:
EVPLACE/1 Orange River Sovereignty, Bloemfontein
EVENT/1 Fred Green goes on hunting expedition from Bloemfontein with W.
John, Johannes de Smidt & William Dawson.
EVNOTE/1 Fred Green set out with William St John, an officer of the Royal
Artillery, from Bloemfontein to A.H. Bain's farm at Tempe, where
they had dinner, and on to Kwaggafontein, from where they set out
on a fortnight's hunting expedition.
PEOPLE/1 Green, Fred
PEOPLE/2 St John, William Jones
PEOPLE/3 Dawson, William
PEOPLE/4 de Smidt, Johannes
SOURCE/1 St John, Diary, p. 54
KEYWORDS/1 ORS Greenfam
The $ sign at the beginning of the line is the "end-of-record" signifier.
This particular program allows repeating fields, and in this record there are
four people in the PEOPLE field. I can (and should have) record "Green, Fred"
as "Green, Frederick Thomas " in the people field, and search for
"" (which isd his RIN in my linage-linked programs.
But a relational database program (like MS Access) does not allow repeating
So if this record were to be in a relational database program, there would be
NO people field at all. Instead there would be four records in a "People"
table, which would then have links to this record, using a "People-Event"
table to link them, and would point to Record 220 in the Events table.
The same thing with the "Source" field. In this example there is only one
entry in the field, but there could be several sources with information on
the same event. But in a relational database these could be linked to the
"Source" table which would have fuller information on each source. I have a
database using the same flat file text datasbase program (Inmagic) which does
have details of the source, but because it is not a relational program they
are not linked. I have to look up source details separately. A report from
that database gives more information on the source as follows:
Schoeman, Karel. 1988. The Bloemfontein diary of Lieut W.J. St
John. Cape Town: Human & Rosseau.
William Jones St John was an officer of the
Royal Artillery stationed in Bloemfontein
during the time of the Orange River
Sovereignty. he had a lot of time on his
hands, and spent most of it hunting. Charles
and Fred Green were in town early in 1853, and
he hunted and played billiards with them, and
with Arthur and Henry Green as well, spending
a lot of time with Andreww Hudson Bain.
In a relational database, it would be possible to include both in the same
report, because "Source" and "Event" would be two linked tables in the same
database. In a "flat file" database like Inmagic, there are no links between
them except in the researcher's mind. The Inmagic database I have created is
useful, but I'm trying to think of ways of making it more useful, and that
can be done using a relational database.
So I'm not looking for different ways of searching for records in Inmagic --
"fred w3 green" works just fine, and there are plenty of other ways of
What I'm looking for, and what I think would be useful to other researchers
as well, is a way of linking these different kinds of information in a
What I think we ought to discuss is what kind of information should be
stored, and where and how should it be stored, to make it most useful to most
The examples I gave show (I hope) how such a database would be useful to:
1. Someone writing a biography of Fred Green
2. Someone writing a history of the Green family
3. Someone writing a history of the Orange River Sovereignty
4. Someone writing a regimental history of the Royal Artillery
and that's just a few possible uses.
Phone: 083-342-3563 or 012-333-6727
- --- In email@example.com, "ray_murphy aus" <raymurph@...> wrote:
> --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@> wrote:
> > On 3 Dec 2009 at 19:11, ray_murphy aus wrote:
> > > --- In email@example.com, "Steve Hayes" <hayesstw@> wrote:
> RM: I've already got that test VB program working and displaying all the required events, sources and people, but as it turned out, it didn't need MS Access or its complex linkage system at all.[....]
> The user-interface being used would be the same under any system,
> and irrespective of what was happening in the background with tables,
> linkages or arrays.
A much better version of the VB program has been uploaded to the Files section of this group's website. It's called "GENEVENTS2"
It can be used to store literally anything that one could ever imagine because users can add their own categories for Events, Facts or Relationships between people.
Any date system can be used, but if full automatic sorting is required for print-outs, then we need to use the YYYY,MM,DD format. If however some dates are not in the correct format (and order in a printout) then they can be simply re-positioned by Copy/Paste in the print-out panel.
If "Connected People" are required for event descriptions, then just click on their names and they will be automatically inserted.
If Sources of information are required for events etc, then they simply need to be entered with the event.
The program has a concise Help section in the Menu, so most questions will be answered there.
This latest version should make it easy for anyone to create a database with a SUITABLE 5.5 Gedcom and start seeing future potential or current weaknesses with the system.