Terry's ORA Tips

Template Tips and Tricks

This page updated 25 Apr 2023

 

This article describes some tips and tricks that I've found assist when working with Templates with Online Repository Assistant (ORA). Other articles in my ORA Section cover more specific topics about using the software.

Topics Included in this Article
Saving Images Made Easier
Letting ORA Help when saving Images of documents
Making User Fields Accessible
Make the fields created by Text Templates easy to find  updated 25 Apr 2023
Separate OraSettings Window
Keep both the OraSettings window and Collection window in view
Copying Templates
Copying Templates from one Collection to another
Templates Designed to Copy
A method to make Templates simpler to copy to another Collection
Collecting Data Not Indexed
Dealing with data in the image but not indexed by the repository

This article describes a number of techniques I've found useful in working with Templates in ORA to copy data from online repositories to my genealogy program. When each section below mentions use of an ORA feature there is a link to my article describing that feature.

Saving Images Made Easier

I like to save copies of all source documents I use from online repositories when images of them are provided. I find I can find them more quickly on my own computer should I need them again in the future than I can by trying to locate them again on the online repository.

Saving the images involves two steps, both of which I find ORA can assist with. The first is composing the filename to replace the gibberish offered by the repository with something meaningful to me. I have a preferred format for each type of document, and in almost every case the elements required to construct the filename are included in data ORA collects. With ORA's ability to re-format and assemble data elements I find in most cases ORA can create the filename as I want it, only in a few cases requiring me to manually edit some details.

The second step is to locate the correct folder in which to save the image. I have a set of folders that creates a unique location for the images from most Collections. I find as I work on research for a person or family that I frequently change Collections, and thus the target folders for the images being saved. As a result, virtually each image being saved requires that I locate a different folder than used for the prior one. Including the path to the target folder in the Template that generates the filename completely eliminates this step, as it is pasting it into the File Save dialog along with the filename itself gets the file placed in the correct folder.

My article on an Example Filename Template explains how to construct a Template that automates one or both of these steps.

Making User Fields Accessible

All fields created by Text Templates, and by Persistent Assignment Variables in Auto Type Templates, appear in the OraPanel. But they can be difficult to see, especially in Collections with many indexed fields. The default location, at the bottom of the OraPanel, may require scrolling to bring them into view. Several options and techniques described here make these fields easier to spot.

First, I find it helps to move the fields created by Text Templates to the top of the OraPanel. To do that, check the "Add Fields at Top" box in the Template Options section of the OraSettings page:

Second, ORA marks user added fields with distinctive styling, but the default settings make the values bold. Since some of my values, like filenames, are long this makes them take up more space, as shown below on the left. I prefer more subtle styling, as shown below on the right.

The styling of the User fields is controlled by settings in the Template Options section of the OraSettings page. The styling on the example on the right above was created with the settings shown below:

Third, I like to add a divider graphic between the fields created by my Text Templates and those created by ORA from the page or added by Persistent Assignment Variables in Auto Type Templates. An example of this is also shown on the right above. I explain how to do this in my Template Examples – Library Templates article.

Separate OraSettings Window

Switching back and forth between the OraSettings window and the window containing the OraPanel and the record you are working with as you create or modify Templates can be annoying and confusing. I find that dragging the browser tab for the OraSettings window off to the side so it appears in a new browser window helps a lot. You can then view the available fields as you construct the Template, and view the Template code as you trouble-shoot any issues in getting a Template to do just what you want. The screenshot below shows how this can work if your monitor is large enough to view both windows, which works even if the windows have to overlap some.

Thank to John Nunnally for reminding me about this technique.

Copying Templates

ORA Templates are specific to each repository, and with a given repository that has multiple Collections, they are specific to a given Collection. This is necessary because different Collections often record different items of data, and even similar Collections in a repository may use different names for the same type of data. ORA cannot know that "Birth Date" in one Collection is really the same as "Event Date" in a similar Collection.

Still, once you have created a Template, or set of Templates, for one Collection you may want to copy that Template or set of Templates to a similar Collection even though some edits may be required for the new Collection. My article on Template Basics includes a section describing the Export/Import Collection feature ORA offers to make this process easier.

As that article explains, you can find a suitable Template or set of them in a Collection for which you have previously created Templates, export them to the clipboard, and import them to the new Collection. But that requires remembering which Collection you used before and finding it in a possibly long list before you can start the process.

Alternatively, you can export the Templates to a file when you create them and are satisfied with the result, so they are available for future import when needed. By default, the exported Templates are saved with a filename based on the Collection for which they were created, as shown in those outlined in red below:

This is helpful because you don't have to actually find the desired Collection to export the Templates to the clipboard, but you do still have to recognize the one you want to use, potentially from a long list of similar Collections.

I find it works better to edit the default filename when exporting to something like those outlined in green above. I have created a "master" set of Templates for each of the several different types of Collections I commonly use, so when I encounter a similar one for a new location I can import my "master" of that type and edit as needed.

Templates Designed to be Copied

The previous section describes how to copy Templates from one Collection to a similar one. Often the new Collection, even if similar, has differences requiring editing of the copied Templates. This section describes a method I have found helpful to simplify that editing and make it less error-prone, particularly when a set of several Templates is being copied and the same Variables appear in multiple Templates, each potentially needing to be edited for the new Collection.

The concept involves two parts:

  1. Create a set of "output" Templates designed to output data from a group of similar Collections, for example Birth Indexes. In constructing these Templates, try to accommodate all the data that might be extracted from any Collection in the group. Use a "standardized" set of Variables, which may be real Variables used in one such Collection, or Variables invented for the purpose. The intent is that these Templates not need to be edited for each new Collection they are copied to.
  2. Create an associated set of Text Templates that "translate" the field names and content as needed to the "standard" Variables used in the "output" Templates. By placing each "translation" in a separate Text Template it is easy to locate and edit if needed, and only needs to be edited once with the result carried automatically to each "output" Template.

This use of the output of one Template by another is described in my article on Text Template Fields.

The method is probably more easily understood from an example. This example is for Birth Indexes. For this type of record I use a "lumper" type source, where a single source is defined in my genealogy program for the entire Collection. My "output" Templates are designed to create citations to that source for a Name record (also used for the Parent/Child relationship record) and for the Birth Event. Additional "output" Templates would be needed for other types of indexes, for example Marriage or Death Indexes.

Since most often I use such indexes to add details to existing Name and Birth records, I do not include Templates to type into these records themselves, but only to create new citations for records which most of the time already exist in my database.

The two Auto Type "output" Templates are:

Citation for Name Tag:

Example output:

Template:

{F4}[Source No]{tab}record for [Subject]<, citing cert. no. [Cert No]>{tab}2

Citation for Birth Tag:

Example output:

Template:

{F4}[Source No]{tab}record for [Subject]<, citing cert. no. [Cert No]>, shows date<[?:Place:split:,:-3], city><[?:Place:split:,:-2], county><[?:Place:split:,:-1] and state>{tab}22<[?:Place:splitCount:,=1]1|2>

In both cases the Templates start with the F4 Control Sequence, the keystroke that opens the Citation screen in TMG; types in the source number; then tabs to the Citation Detail field. There it types in the literal text "record for " followed by the name of the subject person, and if available, the certificate number preceded by the literal text ", citing cert no. ".

The Birth Tag Template then adds information about which data was found. It always types the literal text ", shows date" since that is almost always present in such indexes, followed by text about which, if any, place data is present. This is done with a series of Conditional expressions, each testing with a Value Test Variable testing a split of the Place Variable to determine whether a given place level (city, county, and state) is present. When the level is present the Conditional expression outputs literal text naming that level.

Finally, each Template tabs to the Surety fields and types in the numbers for each appropriate Surety value.

As described above, these two Templates use "standard" Variable names which may or may not be used by the fields in a given Collection. The field names in a given Collection are "translated" to the "standard" Variable names with a set of Text Templates, which in some cases also do processing of the data to ready it for use by the two output Templates.

The Headings of these Text Templates must be the same as the names of the "standard" Variables used in the two output Templates. That is essential, as the Text Template then creates a field in the OraPanel that can be used by the Variables in the "output" Templates.

The simplest case is when you just need to insert data that appears with a different field name than your "standard" Variable name and does not need any other processing. It can also be used to insert data that is always the same for the Collection but is not indexed, for example the source number used for this type of record by your genealogy program. Here are two examples of that type:

Cert No

[Certificate Number]

This Template places the value in the "Certificate Number" field, which is what the field containing the reference number is called in this Collection, to the "standard" Variable [Cert No]. All that is required is to insert the Variable name, which can be typed in or inserted with the Insert Field button.

Source No

3669

This Template assigns the source number in my database that I use for this Collection to the "standard" Variable [Source No]. That number is edited when the set of Templates is copied to a new Collection after identifying the correct source number in my database. The source number to be used for the current Collection is just typed in to the Template.

You may find that you want to process the data indexed for a given field so that it will be available in a standardized format by the Auto Type Templates. To do that, start the Templates an Assignment Variable to transfer the value of the field as found in the current Collection to a "temporary" Variable that is used only within this Text Template. In my examples I used the same name for the "temporary" Variable as as the name of the Template, but that is not required.

That "temporary" Variable is then modified with one or more Transforms to obtain the desired format. Important: the last element in the Template must actually output the processed value so that it is available for use by the Auto Type Templates.

Here are two examples of this type of Template:

Subject

[=:Subject:[Name]]

[Subject:replace:\b([a-z])[ ]:$1. ]

This Template transfers the value in the "Name" field, which is what the field containing the person's name is called in this particular Collection, to the "temporary" Variable [Subject]. It then outputs the value of [Subject] after using the :replace Transform to add a period after any stand-alone initial that may appear in the name.

Place

[=:Place:[Birth Place]]

[=:Place:[Place:replace:, USA:]]
[=:Place:[Place:replace:, United States:]]

[Place]

This Template transfers the value in the "Birth Place" field, which is what the field containing the place of birth is called in this Collection, to the "temporary" Variable [Place]. It then uses two Assignment Variables, with :replace Transforms, to remove the country name that sometimes appears in either of two formats (the two Transforms could be chained together, but were left separate since that seems to make it simpler to add another if yet a different format is found in a future Collection). Finally it outputs the now modified value of [Place].

After editing these Text Templates, the output is not available for processing by the output Templates until the OraPanel is refreshed, either by moving again to a new record, or by clicking the "refresh" arrow in the upper left corner of the OraPanel. Failure to refresh when testing will lead to unexpected results.

If you do not want the output of the various Text Templates to appear at the bottom of the OraPanel, prefix the name of the name of the Text Template with "var." -- for example name the "Place" Template "var.Place". Then be sure to edit each reference to that Variable in the Auto Type Templates to include the "var." as part of the Variable name.

This set of Templates (including both the Auto Type Templates and the associated Text Templates) can then be saved as a "master" for this type of record. Do that by using the Export Collection button. I find it works best to edit the default filename to reflect its purpose as a "master," for example it might be named Birth Index Master.

The Templates are copied to a new Collection by using the Import Collection button in the new Collection. With only the name of the field in the first line of each of each of these four Text Templates should need to be changed to the name used in the new Collection for that item. However the results should be tested with the new Collection in case some unexpected variation in the way the data is entered by the repository requires some additional processing of the values.

Collecting Data Not Indexed

Often times I find that data items I want to record from a record appear in the image of the original document offered by a repository, but are not included in the detail page for the record. Therefore they are not available to be automatically included in ORA's Templates. Examples include ages sometimes appearing on tombstone images on FindAGrave.com, and items included in some years but not others in U.S. Census records on Ancestry.com, such as ages, family numbers, or film numbers.

I have tried two methods to deal with such missing data, and find each has its advantages in different cases. Both methods apply mainly to Auto Type Templates rather than to Text Templates. They are described below:

Have the Template Include Attention-Getting Text

With this method the Template is designed to output the available data, and insert some obviously out-of-place characters, such as " ### " where the missing data should be to draw attention to the need to manually enter the correct data.

If you know that data will always be missing for that Collection, you can just include the desired characters as literal text in the template, as in this Template fragment:

{tab}###{tab}

If the data may or may not be missing for a given record, either because it is only sometimes omitted for that Collection or because you are designing a Template that you want to copy to other similar Collections, construct a Conditional expression to output the data when available and the desired characters when it is not, as in this example:

{tab}<[Family Number]|###>{tab}

With either case, a review of the completed data input screen is required to spot the missing data and type it in manually.

Have the Template Ask for the Missing Data

An alternate method is to have the Template prompt you to enter the missing data in a dialog box, and then have the Template type this data along with that collected by ORA from the repository's details page into the data input screen. The "prompt" is created with an Assignment Variable:

[=:Family Number]

When the Template is used it will pause and create a dialog box prompting you to enter the missing data, as illustrated on the right.

If the data may sometimes be recorded in a given record you can have the prompt only appear when the data is missing by use of an Alternative Conditional expression and the Value Test Variable as in the following example:

<[?:Family Number]|[=:Family Number]>

With this method, the Value Test Variable tests to see whether there is a value in the Family Number field. If there is, the Variable returns "true" and the Alternatives Conditional is satisfied. If not, the second part of the Alternatives Conditional comes into play, and the Assignment Variable creates the prompt.

In either case, the ORA Template now has a value for the variable, and it can be used in the template just as if the data had been collected by ORA from the repository details page, for example with this Template fragment:

{tab}[Family Number]{tab}

Using Assignment Variables as described here to create prompts is best done only in Auto Type Templates. If this method is used in Text Templates the prompt will appear each time you view a record in the Collection or refresh the OraPanel for that Collection, which will quickly become annoying.

Choosing between these two methods is a matter of personal preference.

I find the "prompt" method works best when I may forget to check for missing values. For example Ancestry.com does not record "Township" when that is part of the correct place name in census record, and I want to include it when applicable. So I have added a prompt to be sure I check the image.

When the missing data is not readily visible and I have to look it up, as is the case with the NARA film number on Ancestry for some census years, I find I prefer to type it in after the Template has been run.

 

ReigelRidge Home Terry's Tips Home Contact Terry

 

 

Copyright 2000- by Terry Reigel