Loading ...
Sorry, an error occurred while loading the content.

Re: [gensoft] Re: Historical research database

Expand Messages
  • Steve Hayes
    ... 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
    Message 1 of 32 , Dec 1, 2009
    • 0 Attachment
      On 2 Dec 2009 at 2:40, ray_murphy aus wrote:

      > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@...> wrote:
      > >> For example, instead of the diary text reading:
      > >> "Commodore Smith attended the gathering ..."
      > >> It could be changed to:
      > >> "Commodore Smith [1186] attended the gathering ..."
      > >> then when the printout is produced, you have the [1186] 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 [1184].

      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 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
      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

      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 W.
      St
      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
      DOCNUM/1
      NOTES/1
      COMMENTS/1
      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 "Green, Fred"
      as "Green, Frederick Thomas [144]" in the people field, and search for
      "[144]" (which isd his RIN in my linage-linked programs.

      But a relational database program (like MS Access) does not allow repeating
      fields.

      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.
      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 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
      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 information in a
      relational database.

      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.

      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.




      --
      Steve Hayes
      E-mail: shayes@...
      Web: http://hayesfam.bravehost.com/stevesig.htm
      Blog: http://methodius.blogspot.com
      Phone: 083-342-3563 or 012-333-6727
      Fax: 086-548-2525
    • ray_murphy aus
      ... [....] ... [....] [Update] A much better version of the VB program has been uploaded to the Files section of this group s website. It s called GENEVENTS2
      Message 32 of 32 , Dec 12, 2009
      • 0 Attachment
        --- In gensoft@yahoogroups.com, "ray_murphy aus" <raymurph@...> wrote:
        >
        > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@> wrote:
        > >
        > > On 3 Dec 2009 at 19:11, ray_murphy aus wrote:
        > >
        > > > --- In gensoft@yahoogroups.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.

        [....]

        [Update]

        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.

        Ray
      Your message has been successfully submitted and would be delivered to recipients shortly.