New technology for the church

At present all the data is stored on Gedcoms.
I wish to automate the handling of this data
To do that, as the Gedcoms are mere text files, I want to be able to ASK the Gedcom questions and get answers
"When was person A born and where
Who were his parents
Where and when did they marry
and so on"

Is this best done
BEFORE I load the gedcom into my computer as a tree
or
Straight from the Gedcom saved in my computer
or
another way

Many thanks

GEDCOM files are intended to transfer data from one program to another, NOT to be used as a data source file. That means you should have a database program that will import the GEDCOM file into it's data file and then do data queries.

KenRichins wrote:GEDCOM files are intended to transfer data from one program to another, NOT to be used as a data source file.

This doesn't imply that it can't be used as a data source. The problem is, as with all text file, the search algorithm. In fact text file can be read only sequentially. This means that you must start always from the begin of the file when you search data.
Non mentioning the fact that you can find data only comparing word by word what you are looking for!
This is a waste of time.
Much better let this work to a program that import such a data into structured database. It doe's it only once and you can quickly go through them onward and forward, using index, eccetera, eccetera.

Thanks both of you.

Yes I use Legacy

But I have a far more powerful program, QB64, which I am able to use to do remarkable things way beyond what Lagacy can do! And I undestand what it is doing, how it does it and its limitations! A vast improvement!


So you are saying I should use it to read the data AFTER Legacy has downloaded it into a tree

But a tree is merely ANOTHER format - no easier for a COMPUTER to read than was the Gedcom!

In QB64 I can read ANY text file.
But how do I get it to tell MY COMPUTER (not me!) who THIS gedcom reckons is the grandfather of my uncle's wife?
Or even my father's place of birth for that matter!


The QUESTIONS are easy to formulate in QB64.
I could even do it DIAGRAMETICALLY - via a tree skeleton in which every relationship is shown - as in a tree- by its geometrical POSITION.
How do I then get the answers one by one in the automated sequence that I program my computer to adopt?

Please understand that this particuar human is FED UP with the GUESSWORK he has to use to decide if THIS John Free is really the SAME one he is thinking of or looking for.
Our computers are here, anxious and willing to help us!
Let's use them.
It would be a major advance for Mormon technology.

There are programs that are designed to help you "view" a GEDCOM file, much like a Genealogy program, but without having to import it. I found Gedview, but I'm sure there's more. I'm just not finding it right now.

mrwhy wrote:So you are saying I should use it to read the data AFTER Legacy has downloaded it into a tree

But a tree is merely ANOTHER format - no easier for a COMPUTER to read than was the Gedcom!

It's true that a tree is simply another format, but actually, it's much easier for an application to deal with a tree, or a database, or some other data structure, than simply reading a text file. A text file is no more than a series of characters, until you read it and parse it, and store it in some sort of data structure.

mrwhy wrote:In QB64 I can read ANY text file.

True enough. But reading a file does not necessarily imply understanding its structure and the relationships that are stored in it.

mrwhy wrote:But how do I get it to tell MY COMPUTER (not me!) who THIS gedcom reckons is the grandfather of my uncle's wife?
Or even my father's place of birth for that matter!

That's why applications store data in some sort of linked structure. It makes it much easier to show those relationships, or to look up data.

mrwhy wrote:The QUESTIONS are easy to formulate in QB64.
I could even do it DIAGRAMETICALLY - via a tree skeleton in which every relationship is shown - as in a tree- by its geometrical POSITION.
How do I then get the answers one by one in the automated sequence that I program my computer to adopt?

Once you have read and structured the data, you can do anything with it you want. Given a linked structure, you can easily answer questions such as "who is the grandfather of my uncle's wife?"

mrwhy wrote:Please understand that this particuar human is FED UP with the GUESSWORK he has to use to decide if THIS John Free is really the SAME one he is thinking of or looking for.

You're not the only one. But this question is much more complex than simply reading and parsing a GEDCOM file. A GEDCOM file represents a set of conclusions about genealogical data. Sometimes you can say that a particular person is the same as another person with 100% certainty, but in most cases there will be some doubt. Computers can aid in presenting all the relevant data to you, but some human will usually have to make the judgment as to whether two individuals are actually the same person.

In New FamilySearch, when you look at Possible Duplicates, you will often see a long list of possible matches. Some may be listed as "probably a match" and others as "may or may not be a duplicate"; it never says "these are 100% guaranteed to be duplicates."

mrwhy wrote:Our computers are here, anxious and willing to help us!
Let's use them.
It would be a major advance for Mormon technology.

We're already using computers extensively in genealogical research. There are plenty more advances that can be done -- we just need people to exercise their ingenuity in creating and using tools to move the work forward.

aebrown wrote:
You're not the only one. But this question is much more complex than simply reading and parsing a GEDCOM file. A GEDCOM file represents a set of conclusions about genealogical data. Sometimes you can say that a particular person is the same as another person with 100% certainty, but in most cases there will be some doubt. Computers can aid in presenting all the relevant data to you, but some human will usually have to make the judgment as to whether two individuals are actually the same person.

We just need people to exercise their ingenuity in creating and using tools to move the work forward.

You are quite right - Kleinbottle and all! And clearly you uinderstand the nature of research.
I have tried all manner of ways to be ingenious for 70 years. My Dad called my Mr Why from age 5.

But first we have to BEGIN!
Gather the data from alternative gedcoms.
THEN use computer power to decide which bits of which gedcom are less likely to be in error
This is a "simple" search-and-compare in N-dimensional space (so who WERE this person's claimed ancestors and descendants). And to sound clever, if that sort of person, you use jargon like "correlation coefficients" (auto or any kind you care to imagine).
That is what Thinking is - experimental imaginings.

At the end of the day humans must decide. But AFTER they have taught themselves how to get the most help they can via computers and all other means.

So I am asking for your advice HOW to get the data into my QB64 program.
Maybe this is the same question as "Into what "pattern" should I arrange the data?"
My brain only understands examples. Can you please give me one?.

I have written many programs that teach themselves how to "work better".
The problem often is the human being (me) cannot SEE either how nor why they succeeded. Thus we really miss out entirely on "understanding" . We know EXACTLY what the prog DID. This is so often the OPPOSITE of knowimg why or how it worked!
(Can't see the wood for the trees, MAYBE. Probably far more subtle than that)

Would it help you help me if I invented two gedcoms and showed how a COMPUTER can help us see where and why one is better than the other?
Clearly if one says my mother was 45 when I was born in 1936 and the other says 35 this should be included in the reckoning that SOMETHING may be fishy about my birth or hers or the typological inexactududes of scribes or eyesight of readers or veracity and motives of the people involved! From EACH of these suppositions ideas can be carried forwards that HELP US evaluate other parts of the gedcoms of those people, districts and time periods.

I think you already know GED struct.
I don't know QB64 very well. But if it has an ODBC you can parse GED file and put data into a structured DB.
Then you can inquiry DB for the answer.
Structure example (two tables).
Family :
Family ID, Husband, Wife

Individual:
Family ID, Individual ID, Birth Date, Place[, others]

marianomarini wrote:I think you already know GED struct.
I don't know QB64 very well. But if it has an ODBC you can parse GED file and put data into a structured DB.
Then you can inquiry DB for the answer.
Structure example (two tables).
Family :
Family ID, Husband, Wife

Individual:
Family ID, Individual ID, Birth Date, Place[, others]

Yes thank you, what you say is potentially very helpful
I am slowly beginning to see what you mean.
My problem is with the technical terms and abbreviations that you use.
Once I begin to understand them we can get started.

What is OBDC?
Parse is a word last uses 65 years ago when they were trying to teach me how to break up an English sentence into what they called "Subject" and "Predicate". They went on to teach me what THEY meant by the jargon-words adverb, adjective, noun, conjunction etc etc.
Structure I knw well from engineering and "Tables" from MSExcel.

I suspect you are using "Tags"
In Excel these "tags" might be the column headings
I can give the columns names like this:
Family name, Person full name, When born, Where born, ever married and so on.
SOME of these, for example "Yes" in answer to "Ever married" seem to demand we "Open a new page" that allows us to enter as many marriages as we wish and as many children and children's children as we wish

So I BEGIN to se it is "trees within trees"
But that is NOT the same as seeing how to handle it.

QB64 can handle text (Identify two words as the same)
It is a GREAT language as its instructions (to the computer) are written in a kind od "pidgin" English - so you can actually READ the program and realise what is going on.


I think what I am saying is thanks to your helpful message I have an idea:
Write the gedcom information into a SET of Excel-like tables in which the entry in row 34, column 17 might well be "See data sheet ref qt347"

THEN all I have to do is teach QB64 (or get it to teach itself!) how best to READ that data.

THEN the real fun starts with it TEACHING ITSELF what "things done with all the dats" work best as regards signalling back to me that gedcom #679 has doubtful entries "here" and "here" and its most reliable entries are here and here.

You may say "but HOW do you know".
The answer is there IS INDEED SOME data we are reasonably sure of
Such as when we were born and perhaps who our mother was.
Or (maybe more reliable - but more likely to be falsified) - who the king was when and when his eldest son was born.

So like "intelligence tests", if you "agree with the tester" and "think like him" then you are intelligent!!

Many thanks
I begin to see a light

mrwhy wrote:What is OBDC?

It's ODBC

You might also look into how XML is processed. While GEDCOM is not XML, they are both structured text files. I'd think you could use some of the XML ideas to write routines that do the same thing for GEDCOMS.

Parse is exactly what was teached to you.
As RussellHltn said, GEDCOM is a text structured file, so you have to know this structure and distinguish data from other informations.