Re: Genealogical evidence and data model

On Sat, 02 Feb 2008 13:58:29 GMT, Haines Brown
<brownh@[EMAIL PROTECTED]
> declaimed the following in
soc.genealogy.computing:

> Obviously I was confused by TMG's proprietary meanings. Data entry seems
> to define a steady state, rather than event in the sense we normally
> use the word. The term "role" refers to a functional relation, but for
> it to generate an event it must be a causal relation. GEDCOM includes
> functional relations, but not event-generating causal relations.
>
	Does a "bride" (role) "cause" a marriage (UFT: event; TMG: tag)? <G>

	Events/Tags do***ent that <something> took place,
principles/witnesses (generic terms, roles may be specified for each)
identify the individuals associated with that <something> and perhaps
how they participated (<something> without principles is /not/ -- a
marriage with no bride or groom is /not/).
 
> causal rather than a formal relation of individuals, which therefore
> can't be represented in a flat file. These two contradictory aspects are
> interdependent. An event changes the data, while the data constrains
> event generation.
>
	At one time, the structure for TMG (version 4) database schema was
available for download. Definitely nothing one could call a flat file.
The only genealogical data I know of represented as "flat file" would be
a printed journal narrative <G> (and even those imply a hierarchical
layering of generations).

	But do you have the same meaning I associate with "flat file", or
could you be meaning a "heap file". To me, a "flat file" is one in which
all records share the same structural layout, whereas a "heap file",
while record oriented, does not mandate each record looks similar to the
previous or next. GEDCOM files can be considered a form of flat file if
you look at it from the view of

data-level	data-key	associated data values

where data-key identifies what type of data follows on the line.

OTOH, if one were to indent each record based upon the data-level value
(and then remove the data-level field) one gets something very
hierarchical in structure -- essentially the structure that one would
get if one were to design an XML-like syntax (though XML ignores the
white-space and uses start/end <> markers for "data-key").

	A "heap file" would be the computer equivalent of a filing cabinet
filled with assorted scraps of paper. There is no shared structure from
one piece of paper to another.

> If so, then how do we represent this unity of quite different things?
> What comes immediately to mind is an object-oriented database. "Objects"
> have both a state and a behavior. In terms of a programming language,
> the former is called a "field" and the latter a "method". We could
> combine an object-oriented language such as Java with a way to store
> data, such as XML. 
>
	XML is a lousy way to store data -- it was optimized for data
transfer between programs, but practically every program that has to
modify XML data essentially has to read the entire file into some
format, navigate that format to find the node to be changed, then write
the data back out as XML...  
-- 
	Wulfraed	Dennis Lee Bieber		KD6MOG
	wlfraed@[EMAIL PROTECTED]
(Bestiaria Sup****t Staff:		web-asst@[EMAIL PROTECTED]
)
		HTTP://www.bestiaria.com/