On Sun, 03 Feb 2008 07:51:46 -0500, Haines Brown
<brownh@[EMAIL PROTECTED]
> declaimed the following in
soc.genealogy.computing:
> OK, I understand. The event tag does not reference the cause of a change
> in state but merely provides data associated with one of several kinds
> of change in state. The "event" in TMG apparently remains tied to static
> data. Is any kind of event allowed besides the obvious ones of birth,
> marriage and death?
>
What would you like?
{You'll have to mentally unwrap the lines. Lines where my name is not
given are events/tags in which I am listed as a witness}
List of Events Associated with Dennis Lee
James Bieber (1)
Date------------------- Tag Type-- Prin1 Last, Given-------------
City---------------- State--------
-------
Winter 1979 Anecdote Bieber, Dennis Lee James Allendale
Michigan
5 Apr 1958 Birth Bieber, Dennis Lee James San
Antonio Texas
c 1960 Residence Weiser, Marianne Grand
Rapids Michigan
b 1964 Residence Bieber, James Ivan San
Pedro CA
1964 Residence Bieber, James Ivan Bamberg
1966 Residence Bieber, James Ivan Ft.
Rucker Alabama
c 1967 Communion1 Bieber, Dennis Lee James Ft.
Rucker Alabama
1968 Residence Weiser, Marianne Lowell
Michigan
1969 Residence Bieber, James Ivan Ft.
Leonard Wood Missouri
c Dec 1970 Confirmatn Bieber, Dennis Lee James Ft.
Leonard Wood Missouri
1971 Residence Bieber, James Ivan Ano
Glyfadda
Jan 1974 Residence Bieber, James Ivan Junction City
Kansas
Sep 1974 Living Weiser, Marianne Lowell
Michigan
6 Jun 1976 Graduation Bieber, Dennis Lee James Lowell
Michigan
Aug 1978 Funeral Weidenfeller, Florence Elizabe
7 Jun 1980 Graduation Bieber, Dennis Lee James Allendale
Michigan
17 Nov 1980 Employment Bieber, Dennis Lee James Sunnyvale
CA
1 Dec 1980 Living Bieber, Dennis Lee James Sunnyvale
CA
10 Apr 1982 Occupation Bieber, Dennis Lee James
20 Aug 1983 Marriage Downer, Marcia Ann Wyoming
Michigan
31 Mar 1984 Occupation Bieber, Dennis Lee James
b 26 Sep 1987 Occupation Bieber, Dennis Lee James
c 1993 Occupation Bieber, Dennis Lee James
c 1995 Religion Bieber, Dennis Lee James
28 Aug 1995 Ordination Bieber, Dennis Lee James Sunnyvale
CA
12 Sep 2002 Employment Bieber, Dennis Lee James Sunnyvale
CA
7 Apr 2003 Employment Bieber, Dennis Lee James Sunnyvale
CA
7 Apr 2003 Occupation Bieber, Dennis Lee James
6 Jun 2004 Graduation Bieber, Stefany Marie Lowell
Michigan
Printed on: 3 Feb 2008
Prepared by:
Dennis Lee Bieber
bieber.genealogy@[EMAIL PROTECTED]
need to add the entry for the graduation of the other neice
<G>}
I've not used half the event/tag types available, and have also
created a few custom ones for use when I have conflicting information
(like, two death dates that can not be reconciled). Loading the VFP
tables via ODBC into Access/JET, there are 346 "event type names" in
table _t. Many of these do NOT have GEDCOM equivalent tags (none of the
relation****p options have a defined GEDCOM data record)
>
> No, I wasn't thinking of a heap. A heap is an array or tree structure
> that orders people according to lineage. It seems very old fa****oned
I'd call that a hierarchical file structure... or simply a tree. At
least when I took comp.sci., a heap file was just that -- an unsorted
stack of dis-similar records; one had to read the record in order to
even figure out what the data represented.
>
> Incidentally, what kind of data structure is used in TMG? Do all
> genealogical applications use the same data structure?
>
TMG is built upon Visual FoxPro tables. Very many of them --
approximately 29 separate tables. There'll be a table just for peoples
names (name variations are one of the event/tag types: name-var,
name-nick, name-marr, etc.). A table of sentence templates for the tags,
a table of places (TMG does not store places as:
ID address city county state country
1 1630 Ot.. SV SC CA USA
but instead as
placeID placeStyle fieldID value
1 1 1 1630 Ot...
1 1 2 SV
1 1 3 SC
1 1 4 CA
1 1 5 USA
{if a field is blank, no record for that fieldID is stored}
using a place style table to correlate field IDs to field labels
Heck, names aren't stored as "first middle last" either... The _nd
table has, for example (sorted on the value field)
uid value
1 Bieber
....
1038 Dennis L.
1266 Dennis Lee
2 Dennis Lee James
Another table (_npv) has:
recno uid type id
1 1 8 8
1 2 3 3
1 2 9 9
1 1 5 5
an _npt table shows:
id value type
3 GivenName 3
....
5 Surname 5
....
8 SortSurname 8
9 SortGiven 8
In order to get the name "Dennis Lee James Bieber" one has to do a
self join (I'm ignoring the part of the process that is looking for a
name-style, which would involve using the _npt tables):
select g.value as given, s.value as surname from _npv as gv
join _npv as sv on gv.recno = sv.recno and gv.type = 3 and sv.type = 5
join _nd as g on gv.uid = g.uid
join _nd as s on sv.uid = s.uid
where gv.recno = 1;
The first join will result in:
gv.recno gv.uid gv.type gv.id sv.recno sv.uid sv.type sv.id
1 2 3 3 1 1 5 5
the second "appends"
.... g.uid g.value
2 Dennis Lee James
the third "appends"
.... s.uid s.value
1 Bieber
and the select throws away all but g.value and s.value
g.value s.value
Dennis Lee James Bieber
> My comment was only speculative, trying to define a philosophical
> framework, not meant as a recommendation ;-). But as for the
> practicality issue, I modify XML data every day without reading the file
> into some other format. I create, navigate and modify XML files
> directly. While my situation is hardly typical, is not the procedure to
> which you object in effect what applications such as TMG actually do to
> enable you to modify a GEDCOM file? I'm in general ignorant of
> genealogical applications, but typically don't they im****t and ex****t
> GEDCOM to and from a database designed to facilitate operations such as
> removal and insertion, where GEDCOM is an open format for the exchange
> of data rather than its manipulation?
Your last sentence is the key -- GEDCOM is (not technically open --
the LDS defines the format) a format for /exchange/ of data between
researchers, but not for storage/manipulation.
None of the genealogy programs I'm familiar with can "modify" data
/in/ a raw GEDCOM. They all perform batch loads into a database schema
-- where data is not a sequential text format -- manipulate the data in
that format, store the data in that database, etc. New events for a
person are not physically positioned near any other events for the same
person (in my above listing, adding a witness event to another
graduation will not add a graduation record anywhere near my other data
-- the record will be added to the end of the relevant database table,
which may have had a few hundred other events already added [since I've
been slowly working a second data set in the same project, and it has a
few hundred people, all their data was appended after my primary data
set was last modified]).
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed@[EMAIL PROTECTED]
(Bestiaria Sup****t Staff: web-asst@[EMAIL PROTECTED]
)
HTTP://www.bestiaria.com/
|
