* Improving Templated Sources display and compatibility?

[Mark1834]

I'm experimenting with creating a templated source for the 1939 Register.

Starting with the Essentials Census Template, I've deleted the template source level fields for Repository and Reference, and replaced them with the generic Repository and Publication fields. I then changed the Format specifiers to use {%SOUR.REPO%} and {%SOUR.PUBL%} rather than {Repository} and {Reference}, respectively, and modified the Property Box settings to display the generic fields.

It appears to me that I've improved both the compatibility for export and how the templated sources display in the Records Window in a mixed templated/generic source project (and realistically, any project that is not started from scratch in FH7 will have mixed source types), without compromising any of the other potential advantages of templated sources.

Are there any gotchas I've missed? It seems like a worthwhile change if you are prepared to do a bit of tinkering in the initial setup.

[tatewise]

I'm with you Mark and consider such hybrid Generic/Templated Source Citations perfectly reasonable.
However, when I suggested such concepts before they were not well received and only fully Generic or fully Templated Source Citations were considered acceptable options.

[Mark1834]

Acceptable to whom, I wonder?

As a general approach, I suspect that is an argument that was lost some time ago when the FH7 design was fixed. Rightly or wrongly, CP have bet the farm on their Source Driven Data Entry - Prepared Citation - DEA approach. User tweaks like this compromise that model, as it would presumably stop DEAs working.

Personally, I like the concept of dipping my toe in and customising to suit. I just have to ignore the elements of FH7 UI design that try to drive you down their preferred route.

[tatewise]

I don't see why such tweaks compromise that model or stop DEAs from working.
Yes, some DEA may need adjusting if they involve the changed field(s) but that is true for any field changes.
A DEA is only a Plugin that can access any fields whether Generic or Templated.

[ColeValleyGirl]

User tweaks like this compromise that model, as it would presumably stop DEAs working.

Not necessarily. It might limit what a DEA can do to minimise duplicated data entry though, if it can't find fields it needs/expects or a field isn't in the expected format. I've written DEAs that work with Generic sources where there's no chance of deriving anything useful from the source contents.

[ColeValleyGirl]

Yes, some DEA may need adjusting if they involve the changed field(s) but that is true for any field changes.

Effectively, of course, that is a barrier to very many users... the vast majority who don't want to be fiddling around with Lua.

[Mark1834]

Yes, I should have said "stop DEAs working fully". Only a tiny handful of users would be prepared to modify them to adapt to their customisations, so while they are sold as a potentially more open and customisable option than AS, that is not the reality for how they are used for the vast majority.

[Mark1834]

This is my final hybrid source for the 1939 Register - I chose this one deliberately as it had only limited fields that were worth templating.

I'm reasonably happy with it, as it displays well in the Records Window while also capturing the more structured information around location and address. However, there is one big irritant - I can't get rid of the spaces inside the address parentheses in the automatically generated title. They're not in the template or the definition - FH decides that I can't be trusted to write my own template and inserts spaces.

1939.png (16.23 KiB) Viewed 718 times

It's not just untidy, it is wrong according to every style guide that I've consulted. I feel another bug report coming on...

[tatewise]

The spaces 'problem' has arisen and been discussed several times. It is as CP say 'by design'.
All top-level items in your template are separated by a space unconditionally.
To avoid the spaces, enclose that part of the template in < chevrons > to push it down a level.

See the Help for Source Template Formats Special-Handling for Top-Level Text towards the bottom, where it explains that most top level items are separated by a space, which can be inhibited by enclosure in angle brackets.
See also Source template formatting (21287).

[Mark1834]

Excellent - thanks, Mike. I tend not to take much notice of threads discussing the finer points of text formatting. My report output is mainly temporary stuff for proofreading etc, and I don't worry about the odd untidiness in footnotes and the like, but it does annoy me when it's in my face on the main forms.

I suspect I have some more reading to do...

[Mark1834]

This is working out very well. I have a dozen or so custom templates, mostly based on the Essentials collection, but with my own modifications. My existing generic sources are sufficiently well structured that it has been viable to generate a fairly simple plugin to go with each source type that extracts the field data (who, where, when, what, etc) from the source, ready to convert the sources to templated and populate the fields. It runs first in "display" mode, to list the data and highlight the inevitable inconsistencies. Once I've corrected those that are definite errors, I run it again in "update" mode where it does the actual conversion.

These hybrid sources and remaining generic sources co-exist in perfect harmony. Both the Records Window and report output look fine, once I've tweaked formats to my preferred style.

However, there is a design decision that I have to make. For things like death, burial or probate relating to a married woman, I use a generic source title of the form Burial Register, Chelsea St Luke, Middlesex: 1845 - Mary Smith (Jones), where Mary Smith is the name in the source, and Jones the assumed maiden name.

That's not so easy with templates. If it's not in the field data, it can't be in the automatic title. There are (at least) four options I've toyed with, all with their pros and cons:

1. Discard the maiden name when converting, and do not record it in the future. More rigorous, as I'm not including anything not in the original source, but not as convenient.
2. Record the name as Mary Smith (Jones), with the name field defined as a name. OK, but causes inconsistent display when queried, as FH misinterprets what the surname should be.
3. As 2, but convert the name field to simple text. More consistent, but I lose the potential benefits from having it as a name.
4. Create an additional name field, Assumed Maiden Name, that is populated only for married women where the information is known. Less rigorous academically, but convenient and consistent with my current practice.

I'm leaning towards option 4, but we all have our own individual balance between rigour and convenience. It's not something unique to my data, so how do other people cope with that situation?

[AdrianBruce]

In my generic sources I have ignored anything not in the source - ie, the equivalent of your option 1. If I need to find a source relating to a married woman going under her married name - ie probably not Scotland! - I tend to go via the individual's record.

None of it's particularly swift, but it seems to work - and avoids even more complexity when she was married twice.

[ColeValleyGirl]

I do the same as Adrian -- nothing that isn't in the source, and navigate via the individual to find the relevant sources.

[Mark1834]

Thanks folks - I’ve decided not to make a final decision yet, although I’m still leaning towards keeping the extra field.

The only data cleansing I am doing before converting my live database are inconsistencies and errors that prevent the automatic conversion working properly. I have also created a custom query for each template so that I can tabulate all the fields. Once the conversion is complete, I can spend time on tidying up and optimising.

At least with templated sources it will be a simple modification to add or delete fields, or change title formats (especially as CP fixed titling updates so quickly).