Family Historian User Group

Hi all,

I would like to be able to export a single object -- source, media, or place -- to GEDCOM so that I can copy it to another FH database.

Writing a plugin to do this is pretty simple, but I thought I'd check first to see if there's another way to do it before I invest the time.

Shosh

You could make a copy of your gedcom and delete everything except the single record you want. File>Split Tree Helper would speed this up by enabling you to delete specified categories of records completely, but there would still be some manual intervention needed for the record type where you want to preserve one record. Then merge the stripped-down gedcom to the second gedcom.

But if you are likely to do this frequently it would be quicker to write a plugin!

How were you planning to import such records into the other Project?

Perhaps by using File > Merge/Compare File.

In that case the exported record(s) must be embedded in a full Gedcom structure with Header and Trailer.

Remember that a Media record must be accompanied by its Media file.

Beware that once merged into the other Project they will probably have different Record Id.

With that sort of data overlap, it begs the question: Why not merge the Projects?

Hi Mike,

The main thing that I want to be able to do is to share source and place records between projects, specifically between my database and my husband's databases. The data for individuals and families in each of our files is quite different, however, we do share many of the same "master" sources and some places as well.

So, I guess I'm off to write a new little plugin.

Regard,
Shoshana

Having pondered the problem, I suspect the way forward is to Copy your Project, and run the Plugin on the Copy. Select what you want to keep, and the Plugin would delete every other record, leaving just the selected few. Don't forget to allow for Media, Repository, Note, etc, records linked to your selected records.

Mike,

I guess I'm not being too clear.

I want to export a single source (or just a few) so that it (they) can be shared in other project(s).

The source definitions are quite complex because they each contain a template definition in the source note, which is used by a custom plugin which creates method 1 style sources for data found in various online databases.

The plugin allows me to cut and paste the "transcription" from a search result page, enter the URL and accessed date (actually automatically generated, but I can override it) and then creates a source, formatted as I wish, and attaches it to the relevant facts. It's quite a time-saver. I create a "master source" for each online db that I use.

Like I said, exporting a single object is pretty trivial, so I'll go ahead and do that.

Shoshana

Why not just copy & paste the Source Note template text, and fill in the rest by hand?

My husband and I work on different computers. It's kind of hard to cut and paste...

Ok, then Email the text.

Just thought it might be quicker and easier than a Plugin.

Mike,

You really seem to be against the idea of exporting a single object to GEDCOM.

Why? Do you foresee some kind of problem?

Shoshana

Just seems a lot of work when there is a simple alternative.

I recently wanted to copy a few people within my project. Basically 2 similar families got mixed up (lots of Williams and Thomas' with common surname). I went down the route Lorna suggested of exporting the 'mixed up' family, then importing, then deleting/ amending the now 2 separate families. The other option would have been to use the plugin clone any record for each individual, but that would have been more time consuming and would need to create many links.

Lorna's solution (as mine above) seems the safest, albeit messy and time consuming, but I suppose a plugin to export a selection of objects or whole individuals would be nice, as would the plugin clone any record if it catered for multiple items and not just one.

Shosh, what almost certainly would be easier is a Plugin that checks that those Source record templates exist or creates them from scratch. Then when you need a new template, just update the Plugin and run it in each Project.

Mike,

You've given me a direction for thought...

The templates could actually be stored in the plugin data directory, I suppose. I chose the store them as "master sources," since that seemed the easiest way to deliver them, but there's no reason that they couldn't be stored as individual files. Instead of asking the user (myself and my husband at this point) to select a source via the standard method, I could present a list of templates. Just thinking out loud here...

I have rather a lot on my plate right now (my husband just wants the templates, doesn't care how he accesses them) but this could actually be an improvement. I anticipate that there will probably be a fair number of "master sources" and this would move them out of our list of actual sources.

Hmm... lots to think about.

Thank you,

Shosh

Shosh,
You said that you and your husband work on different PC, so it would be better to hold all the Source template text within the Plugin script. Then only the Plugin needs to be copied frorm PC to PC. Remember that Source records, from the perspective of a Plugin, do not exist as a file, but as a number of text fields. Then you just need an LUA table of Source fields and a very simple Plugin loop to check if matching Source records exist, and if not create/update them.

Mike,

There is one plugin. There will be many templates. I want to store the templates separately from the plugin.

Shosh

Why?

That means you must copy every template, as well as the Plugin, to every PC.

What format were you thinking of for those templates?

BTW: A single Plugin can contain as many templates as you like.

Mike,

Here is an example of a template, for processing a record for the SSDI found on Ancestry. This is what is currently stored in Evernote.

Title: "U.S., Social Security Death Index," database, "Ancestry" (http://search.ancestry.com/search/db.aspx?dbid=3693), citing citing U.S. Social Security Administration, "Death Master File," database (Alexandria, Virginia: National Technical Information Service, ongoing)

Type: Death Index (SSDI)
Short Title: ~DB SSDI (Ancestry)

Author:

Custom ID: MS-1007

URL: http://search.ancestry.com/search/db.aspx?dbid=3693

Template (copy to note):
[[
Text from source: Y

Params: Name,Surname,Given,BirthDate,DeathDate,UpperSurname,DeathYear,LastResidence,ResidenceCounty,ResidenceState,ResidencePlace

Name: #textfromsource,Name
Surname: #surname,Name
Given: #given,Name
BirthDate: #textfromsource,BORN
DeathDate: #textfromsource,Died
UpperSurname: #upper,Surname
DeathYear: #year,DeathDate
LastResidence: #textfromsource,Last Residence
ResidenceCounty: #part,2,LastResidence
ResidenceState: #part,3,LastResidence
ResidencePlace: #template,{ResidenceCounty}, {ResidenceState}, USA

Title: "U.S., Social Security Death Index," database, "Ancestry" (http://ancestry.com : {#accessed}), {Name}, {DeathDate}; citing citing U.S. Social Security Administration, "Death Master File," database (Alexandria, Virginia: National Technical Information Service, ongoing)

Short Title: DEAT - {UpperSurname}, {Given} ({DeathYear}) - index (SSDI)

PathMedia: media\Death\
FileMedia: {UpperSurname}-{Given}_Death-index-ssdi_USA_{DeathYear}
TitleMedia: {UpperSurname}, {Given} - Death Index (SSDI) - {DeathYear}
Transcript: Y
FormatT: pdf
Image: N
FormatI: jpg

Events: BIRT,BirthDate, , ,3,N|DEAT,DeathDate, , ,3,N|RESI,DeathDate,ResidencePlace, ,3,Y

INDIName: Name,3
]]

If I understand correctly, each template is a simple text string currently held in the Note field of a series of Source records.
An example text string is the text between Template (copy to note): [[ and ]] in your Evernote example.

You said earlier you use "a custom plugin which creates method 1 style sources for data found in various online databases."
I suggest you embed those template text strings within that Plugin.
So instead of reading a Source record Note containing the template, it reads an internal text string containing exactly the same template text.

I often use such a technique in my Plugins, e.g. Lookup Missing Census Fact
The LUA for such a template text string just happens to use the same square bracket syntax and is:
StrTemplate = [[
Text from source: Y

Params: Name,Surname,Given,BirthDate,DeathDate,UpperSurname,DeathYear,...

Name: #textfromsource,Name
Surname: #surname,Name
: : : : : :
INDIName: Name,3
]]

To cater for many such templates, just list them in a dictionary table:
DicTemplates =
{
TemplateOne = [[
Text from source: Y

Params: Name,Surname,Given,BirthDate,DeathDate,UpperSurname,DeathYear,...

Name: #textfromsource,Name
Surname: #surname,Name
: : : : : :
INDIName: Name,3
]];

TemplateTwo = [[
Text from source: Y
: : : : : : :
INDIName: Name,3
]];
}

The Plugin could offer the names of the templates in the table in a drop-list to select one, and then after reading the template text would create the new Source record exactly as it does now
Then as you say, there is a single Plugin, and no dummy Source record templates.
All we have done is move the template text from FH Source records in the Gedcom to table entries in the Plugin.

The syntax to access any template is DicTemplates.TemplateOne or DicTemplates.TemplateTwo and so on.
If StrCurrent holds the name of a template, e.g. StrCurrent = "TemplateOne" then DicTemplates[StrCurrent] will access that template text.

Mike,

Your suggestion would definitely work and, as you say, would simplify distribution of the templates. It's also quite easy to implement.

However, I am somewhat concerned that the plugin could grow to be quite long. I'm concerned that I'm going to suffer a performance hit. The template in the example is 42 lines. I'm just getting started, but I would guess that many templates will be of a similar length. Others will be longer, but let's say that, for the purpose of calculation that, on average, a template will be 50 lines in length. I haven't prepared a list of templates (I'm just creating them as we proceed in our do-over) but based on a quick scan of my current source list, I anticipate that I will need over 100 templates; the number might even approach 200. So, let's say that I will have 150 templates, each 50 lines long. That's 7500 lines of code. I'm concerned that I'm going to suffer a performance hit.

My second concern is that editing the plugin every time I want a new template or to modify an existing template could potentially corrupt existing code.

One last point... At the moment, I create these templates by hand. It would be nice to be able to maintain them via either a plugin or external program. That wouldn't be an option if the templates were embedded in code, correct?

Shosh

Shosh,
If you really are just creating these source templates now for the first time, as you proceed with your do-over, why not create them each in their own one-record gedcom? Your original post asked about exporting a single object to gedcom, so why not create them that way?

Lorna,

In order to use them, they need to be in my project. As far as I know, a plugin can't reference objects in another GEDCOM.

Shosh

Understood. It was just that from your original post I assumed you planned to merge a copy of the single object gedcom into whatever project needed it. I guess your plans have now changed direction somewhat.

Shosh, don't worry about Plugin performance. Complex executable code or very repetitive code can affect performance, but simply large amounts of static text will not be a problem.

Editing the Plugin falls into two categegories:

1. Simply changing or adding the text of a template is no more likely to cause problems than changing or adding Source record templates.
2. Changing the algorithm code has the same risks as changing your existing Plugin that processes templates.

So simply moving the template text within the Plugin does not significantly change the risks.

A Plugin script is just a plain text file, so it is perfectly possible for another Plugin or an external Program to edit that script file and alter the template text. I have performed similar operations with one Plugin editing another Plugin.

BTW: Plugins can access files anywhere, so they can manipulate image files in the Media folder (I have done that), they can manipulate custom files in the ProgramData folder (I have done that), so it is possible to manipulate any Gedcom files, but only as plain text files, and not structured data via the Plugin FH API.