--- In email@example.com
, "Steve Hayes" <hayesstw@...> wrote:
> On 2 Dec 2009 at 2:40, ray_murphy aus wrote:
> > --- In firstname.lastname@example.org, "Steve Hayes" <hayesstw@> wrote:
> > >> 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 .
> I think we have a misunderstanding here.
> 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
> print, used in that particular database to search full-text fields.
RM: I see. I thought you must have expanded on that MS Access table and got Access doing queries to produce output like that, but apparently it's another program.
> 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
> hunting expedition.
> People: 1. Green, Fred
> 2. St John, William Jones
> 3. Dawson, William
> 4. de Smidt, Johannes
> Sources: 1. St John, Diary, p. 54
RM: The wording of the above text makes it look like a "Fred Green" event which would not be printed anywhere else with that wording.
For a search for all "Fred Green" material, wouldn't it be just a matter of printing:
(a) All of Fred Green's Events
(b) All of Fred Green's Characteristics (not discussed yet)
(c) All mentions of THIS Fred Green in anyone else's Event list
(d) All mentions of Fred Green in a global Event list
> That is a formatted report from the database, but the underlying record in
> the database looks like this:
> ID 220
> EVDATE/1 2-Mar-1853
> EVPLACE/1 Orange River Sovereignty, Bloemfontein
> EVENT/1 Fred Green goes on hunting expedition from Bloemfontein with
> John, Johannes de Smidt & William Dawson.
> EVNOTE/1 Fred Green set out with William St John, an officer of the
> Artillery, from Bloemfontein to A.H. Bain's farm at Tempe,
> they had dinner, and on to Kwaggafontein, from where they set
> 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
> UPDATE/1 16-Apr-2004
> 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
> Fred" as "Green, Frederick Thomas " in the people field, and search
> "" (which isd his RIN in my linage-linked programs.
> But a relational database program (like MS Access) does not allow
> repeating fields.
RM: That part about repeating fields hasn't sunk in for me yet.
> 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
> table to link them, and would point to Record 220 in the Events table.
RM: Well, like I indicated above, the event was worded as a Fred Green
event, so I cannot see why you would want to link it to other people for later retrieval with the same wording - as if it was *their* event
> 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
> they are not linked. I have to look up source details separately.
RM: I think most people using relational databases would find it a bit hard to visualise all the connections once they start getting a bit complex, but there could be an easier way to test out some ideas - simply write ordinary code in Visual Basic to tell the program where to go to retrieve the required information and where to add it. That's all MS Access is doing anyway - sending a long set of instructions in relatively plain English - so if we can begin thinking in those terms instead of staring at MS Access graphical
representations of the instructions and trying to imagine what goes where - or wondering why we cannot get Access cannot do a particular thing.
So if a prototype in VB can be made to work, then it's just a matter of translating the VB written instructions into MS Access mouse clicks etc., and if that doesn't work, just use the slower VB code in partnership with Access.
> 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.
> ISBN: 0-7981-2243-9
> 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
> useful, and that can be done using a relational database.
RM: I can see no reason why anything like that cannot be done in VB,
once the programmer knows what is required.
> 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 searching.
> 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
> in a relational database.
RM: It boils down to explaining in very clear language what you want a
*program* to do - not what you want a relational database to do. Some
or all of the work might be done more easily ~outside~ of a relational
database - or even outside of MS Access altogether. In some cases a
sophisticated relational database would work 100 times faster than VB
but hey, will genealogy people be complaining if they have to wait for
1000 milliseconds instead of waiting only 10 milliseconds for something to pop into view?
> 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 users.
RM: From my experience with a similar project, I'd say that there should be no limit on what kind of information is eventually stored on anyone's program. Besides being a good idea, it completely eliminates arguments and resulting hold-ups.
The question of where information should be stored depends on the program design, or whether there are both personal-use databases, as well as large industrial-strength databases. Smaller amounts of data could be stored in simple csv files, and large amounts in MS Access or separate csv files that are called when needed.
> 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.
Another obvious one, is geneology people simply looking at such a printout for an individual and searching for clues in the text that fit in with other people or events.