* Can a plugin call a plugin?

[JoopvB]

You've got a point.

I'll try to make it work first and then, if it works as expected, try a few real world scenario's.

Thanks for the ideas and keeping my thinking as uncluttered as possible (which, as my assures me, is a challenge ).

[JoopvB]

@Helen - I have been thinking about how to come up with the easiest solution possible and maybe, maybe...

Suppose I have a plugin (DEA) that is specifically aimed at distilling data from a number of websites and enters the data into the Source's fields and Text to Source. But that's not all, the plugin also writes the websites data in a temporary file in a well defined format. The format is mainly determined by what the second plugin (DEA) needs to create persons, families, facts etc.

I could create the first plugin. Actually, I have one and all I need is the format for the follow-up plugin.

For the second plugin (DEA): is it feasible to modify one of the existing DEA's in such a way that the starting point will be a Lua table (read from the temp file) with data about persons, roles, events and attributes and then have it do what it already does (create the data items)?

The benefits would be:
- maximum use of local (as in other countries, other languages, other websites etc.) knowledge to create a number of the first plugin's;
- optimal use of knowledge of FH datatypes, iup, GEDCOM etc. and only a small number of this second plugin's is needed (the data in the interface table can largely determine what the second plugin can and will do).

If this sounds like not too bad of an idea, I'd be happy to provide the first plugin with any format that you need.

[ColeValleyGirl]

Let me think about this a while, Joop. I'm currently working on creating a set of components for building DEAs such as the ones here: Some new Data Entry Assistant plugins for testing (V7) (18293).

The components will include:

1. a function delivering set of selectors (for Principal, Spouse, parents, godparents etc)
2. a function delivering a grid to allow the user to enter information gathered from the source
3. a function generating individuals, families and facts from the grid
4. a function handling options for the DEA

Items 2 and 3 will be table driven (using a table for the fhutils getparam function)

Initially, I was intending to use the components to provide a set of generic birth death marriage burial/cremation baptism DEAs, but then perhaps make them available to others to speed up the creation of other DEAs. (Censuses is going to need a bit more thought).

I need to think of there's any dovetailing between your proposal and what I'm doing, but one problem I can see is that most websites supporting e.g. English Welsh Scottish and Irish sources have a vast number of different formats from which you'd need to distill data -- it's a very different environment than for example WieWasWie.

[JoopvB]

but one problem I can see is that most websites supporting e.g. English Welsh Scottish and Irish sources have a vast number of different formats from which you'd need to distill data -- it's a very different environment than for example WieWasWie.

Exactly true! And that's the very reason I think, that the local part has to be 'local' and the FH part has to be 'central'. The 'local' plugins doing the website, language and cultural dependent stuff mainly need knowledge of Lua to massage the data in the interface format. They can use the local language if necessary etc. etc.
The 'central' plugin(s) can do the heavy lifting of getting the data into the correct fields (with the correct links etc.) in the FH database. The starting point would be a completely filled source record and a temp file with a Lua table in the defined format.

I agree that WieWasWie is one of the (if not the) easiest site to parse, but my plugin already supports a number of other genealogy websites too and they could all pass the data in one single format for: birth, marriage, death, baptism, church marriage, burial and census registrations. Think of it as a poor man's GEDCOM interface.

Please send me some URL's of the English Welsh Scottish and Irish websites to see how they are different. Helps me better understand the challenges you face.

[ColeValleyGirl]

Joop, most of the sites with UK/US/Australian sources are subscription-based, but there's always familysearch.org. Are you familiar with it?

You could also try freecen.org.uk (census) and freereg.org.uk (parish registers) and freebmd.org.uk (civil registration indexes) but the coverage of the first two is limited, so most people use the subscription sites.

[ColeValleyGirl]

P.S. If you identify some records from those sources, I can track them down on the paid sites and post screenshots here.

[JoopvB]

Helen, yes, I know familysearch.org and mainly use it for scans that are not (yet) available in the Dutch repositories. Too bad you have to work with paid websites. Don't know if it's affordable, but it made me realize the luxurious position we in The Netherlands are in (in as far as access to Genealogy data is concerned ).

I had a look at the websites you named.
The fields of the census data are quite comparable to our census data.
The Freebmd.org data are just indexes and therefore it is not a very valuable data source on it's own.
I am interested what transcribed data the paid sites make available. Could you post a screenshot (doesn't the site allow downloading the transcription in readable format?) of a few of them (maybe a birth, marriage and baptism)? Just a randow person/couple that you have available. I'm mainly interested in a kind of field comparison to see if the if the two-phase DEA approach is feasible across country borders.

Thanks for all your help!