* Hiding personal info in a citation template

[Gary_G]

Re: Personal Correspondence template of the Advanced Collection

I note that this template from Calico Pie does not allow for selectively hiding personal address info and substituting a phrase like, "Address for personal use only", in report citations. The method that FH7 uses to hide info in reports is not the same as that of RM9. What is the best way to achieve the desired behaviour in FH7?

[AdrianBruce]

My instinct was to include the address in privacy brackets ( [[ ]] ) - however, when I tried to produce a narrative report including an address in a source linked to that template, I found that the [[ and ]], together with the enclosed words, still printed, even though I had the report options set to exclude [[ private ]] Notes. I think that while it might exclude private Notes, there are other bits where the [[ ]] are not respected - inside a citation, I guess is one.

If I have the diagnosis correct, it has been like this for a considerable number of years.

[Gary_G]

Adrian;

This topic is one that will be dear to the hearts of EE-Style followers and those who post their reports online.

I wonder if one can set a field/flag somewhere in FH7 that templates could globally "see" and use in their logic. Perhaps FH7 already has that. If I really had to fudge it, I'm sure I could. Perhaps; a fake list (or some such construct) and have it be tested by a template to see if a privacy flag was set.

I'm sure one of the old hands will have a suggestion.

[LornaCraig]

I'm sure one of the old hands will have a suggestion.

As you'll see from Adrian's profile he joned FHUG 20 years ago so I'd say he's an old hand!

As Adrian has mentioned, double square brackets [[like this]] can be used to enclose private text which can be excluded from reports using the Report Options. This includes address fields where they are text fields. However I see from another recent topic of yours that the address in a template definition is not a text field but an AD- field, which probably explains why it doesn't work in that context.

It might be worth raising this with CP.

[tatewise]

Ok, let me review what we are talking about here.
Firstly, templated Source record and Citation-specific metafield values never appear directly in the Sources section of Reports.
What appears in Sources are formatted Footnotes, Short Footnotes and Bibliography values.

So Gary is asking whether a metafield value can be conditionally included in a formatted text value.

One option might be to use a {=Textif( ... )} function to conditionally include a metafield value.
However, it is not obvious what could be tested in this case to form the condition for a specific fact or individual.

Others have mentioned the [[ privacy brackets ]] which can be used in some fields to enclose private text.
Their inclusion in Reports is governed by the Report > Options > Contents/Main tab Inc. [[private]] Notes tick option.
A little experiment revealed that works as expected for Note and Address generic fields and also for Address (~AD-) metafields that are included in formatted text values such as Footnotes.
It does not work for any other type of templated metafield in formatted text values.
It might be reasonable to add that feature to Text (~TX-) and Enum (~EN-) and URL (~UL-) metafields that essentially hold text strings, but would be unreasonable for the others that are record links or date fields.

[ColeValleyGirl]

It might be reasonable to add that feature to Text (~TX-) and Enum (~EN-) and URL (~UL-) metafields that essentially hold text strings, but would be unreasonable for the others that are record links or date fields.

Although it might make sense to add the feature to all metafield types for consistency and because almost certainly somebody will come up with an edge case that needs it...

[tatewise]

Although it might make sense to add the feature to all metafield types for consistency and because almost certainly somebody will come up with an edge case that needs it...

In that case, adding the feature to all field types everywhere might make sense.
If it can work for Name, Date, Place & Repository type metafields then why not Name, Date, Place, etc, generic fields?

[Gary_G]

Mike got exactly what I was trying to achieve.

By way of explanation...
The Evidence Explained (EE) correspondence template in FH7 seems to have avoided selectively hiding individuals address data. This is something that is definitely not per the EE book, as Shown Mills is VERY particular about selectively hiding personal information in all her citation examples. Given how such info can be misused, I assume this would be a concern to many users that post their reports. Since the FH7 version of the EE-style template did not include this feature, I suspect that it likely wasn't easy to do as illustrated in the book. In fairness; I should note that most genealogical programs struggle with this capability and only a few have successfully implemented something that addresses it.

What I'm hearing (just to confirm) is that FH7 cannot currently do this type of in-citation logic. I understand that there is a feeling that it is possible for Calico Pie to include it, but some disagreement as to whether they should. My view on the subject is already clear.

Possible work around?...
If I were to include a custom "privacy" field in a repository definition and set/clear it as required, could that field be used to drive the logic to selectively print the address info or a phrase like "address for personal use"? As I have defined a few specific repositories for correspondence, perhaps setting such a flag is a pragmatic solution. It would seem that it would not be a big impact on my workflow.

[tatewise]

Since EE seems to be talking about address data, why can't you use the [[ privacy brackets ]] feature in a template Address (~AD-) metafield as I described?

I'm not sure which specific template you are referring to. Is it the Advanced - Personal Correspondence?
Which of its metafields holds the individual's address data we are discussing?

[Gary_G]

Mike;

The specific template is, "Personal Correspondence" in the "Advanced" collection.
Both the "Bibliography Format" and the "Footnote Format" of that template use the metafield "{Contact_Information}".
The template does not define any address or place fields, but uses text instead. {Contact_Information} can be altered to be an address field and the square brackets used for hiding, however it does not help with the question of printing alternate text.

The following is a typical example of "E-Mail & Instant Messages" citations per the EE book, but physical letters use the same technique for addressing personal info. Here; the text in square brackets indicate that the content can be either the actual info or the message shown. Note that I've substituted the titles of the sections to match the terms used in the template editor screen.

BIBLIOGRAPHY
Fleming Research Files. Privately held by Ann Carter Fleming [(E-ADDRESS), & STREET ADDRESS FOR PRIVATE USE], Chesterfield, Missouri. 2015.

FOOTNOTE
Kay Haviland Freilich, Wayne, Pennsylvania [(E-ADDRESS FOR PRIVATE USE),] to Ann Carter Fleming, e-mail, 14 November 2003, “Elusive 1870 census entry,” Personal Correspondence Folder, Fleming Research Files; privately held by Fleming, [(E-ADDRESS), & STREET ADDRESS FOR PRIVATE USE], Chesterfield, Missouri, 2015.

SHORT FOOTNOTE
Freilich to Fleming, e-mail, 14 November 2003.

Mills, Elizabeth Shown. Evidence Explained: Citing History Sources from Artifacts to Cyberspace: 3rd edition revised (p. 154-155). Genealogical Publishing Company. Kindle Edition.

[tatewise]

Ah! I see what you mean.
In that case, your previous proposed Possible work around?... should provide a solution.

[Gary_G]

Thank you, Mike.

I will include a "Privacy" field in the repository and logic in the template such that the "redaction" text will be used only when the custom field is defined and has a value. If I'm not mistaken, such custom fields are referenced in a way that returns a null value, and not generate an error, if the field is not defined in the repository. That behaviour should be able to be used to ensure that the "redaction" text won't be shown just because one doesn't happen to have the custom field in their repository structure. [I'm thinking of reuse by others here].

If I'm mistaken in my assumption about returning a null value, please let me know.

[Gary_G]

I had a look at what I could actually do with the Repository structure to see if I could solve my issue. Using the hashtag, #PRIVATE_ADDRESSES, in the Notes field of the repository should enable a template to sense whether to switch from showing the address data to showing a redaction message. I don't believe that this is likely to "upset" any reports.

[Gary_G]

I'm having good success with selecting what to print based upon the content of the note field in the repository record.

The following construct seems to work quite well to select between to strings;
{=TextIf(ContainsText(%SOUR.~RP-REPOSITORY>NOTE2%,"#PRIVATE_ADDRESSES"),"Street Address for private use","Street Address for public use")}

This means I should actually be able to do what is required by the EE-Style book.

I'm not "quite" there yet, because I still need to cast the output from a TextPart call as a string. That is, I need to substitute what is returned by {=TextPart(%SOUR.~RP-REPOSITORY>ADDR%, 1, 0, TIDY)} for "Street Address for public use". I know that FH7 must have such a construct and I'm sure I've seen it, but I can't quite remember where... yet...

[Gary_G]

Got it! I was overthinking the issue. The following snippet does the job nicely and can be tweaked to get just the syntax required per the EE-style. It senses if "#PRIVATE_ADDRESSES" is present in the notes field of a repository and sets the returned text to "Street Address for private use"; otherwise it returns the actual repository street address. Now I can construct the rest of the template around it and that's one more nasty piece of work done.

{=TextIf(ContainsText(%SOUR.~RP-REPOSITORY>NOTE2%,"#PRIVATE_ADDRESSES"),"Street Address for private use",TextPart(%SOUR.~RP-REPOSITORY>ADDR%, 1, 0, TIDY))}

Mike; It's getting easier...

[sbell95]

Gary, I've really been enjoying reading your posts and seeing you work through the issues to adhere to EE as much as possible from within FH7. Personally, I decided that there is probably never an instance where I would want my address (or anyone's) published in any output I create, so I have left my personal 'repository' as simply my current town and country of residence. But I appreciate your implementation and explanation!

[Gary_G]

"sbell95";

Thanks for your kind words. Happy you find my journey interesting and hope that it suggests possibilities for your own work. It wouldn't be possible without the valuable input of the FH7 user-community.

With a bit of ingenuity and persistence in template design, Family Historian appears to be able to turn out a reasonably compliant EE-style citation.

My relationship with EE-style citations is a bit of a love/hate affair. While I find the style to be useful, I also find the non-deterministic nature of a "purest" EE-style to be frustrating. It tends to result in publication-quality citations, but totally ignores the pragmatic issues of handling massive numbers of similar ones. What you are seeing is my attempt to tweak it, just a bit, so that the format is more regular and amenable to computerization.

[Gary_G]

I've now a fully working EE-Style citation template for citing "Personal Correspondence" for any country. It was needed, as the FH7 Advanced templates did not implement any privacy features for mailing and email addresses.

This template is perhaps one of the most complex EE-Style templates to write, regardless of the platform. In FH7, the "Footnote" definition alone is just over 1,000 characters, yet FH7 executes it flawlessly and without any noticeable delay. As I'm quite new to FH7, let's call this one of my "learning opportunities".

The template is based on the concept that Personal Correspondence essentially transfers something from an originators repository to a recipients repository via a medium of some sort (like email). In the FH7 world; it requires that the two noted repositories be set up and contain the relevant mailing and email addresses. This means that one will need to add the standard address sub-fields into the repository address field, as they appear not to be defined in the as-shipped FH7. This concept actually works rather well, as it avoids typing addresses for repeat communications and one will also end up building a handy address book. It is worth noting that mailing addresses are not the same as what is in the geographical address/place lists. This is an important distinction, since the citations require the actual contact info for those involved and not their geographical location.

The template also implements a "privacy switch" on a repository-by-repository basis. This means that when the Notes field of a repository contains the hashtag, "#PRIVATE_ADDRESSES", the template will replace the email and street address with a note saying that the e-mail and mailing address are for private use. This is a handy feature and uses logic that could not be implemented using the existing FH7 privacy features.

Once I have completed and tested my basic EE-Style templates as a set, I will likely write documentation for them and see how it can be made available to others.

[ColeValleyGirl]

Once I have completed and tested my basic EE-Style templates as a set, I will likely write documentation for them and see how it can be made available to others.

You may not have explored the Downloads section of the KnowledgeBase yet. Source Templates is intended to allow people to contribute their templates for others to use.

[Gary_G]

Thanks, Helen.
I saw that there was an area, but wasn't sure if any vetting was required prior to uploading.
Once I have a well-tested set with proper documentation, I'll upload them.
The documentation is important, because there is a tiny bit of planning/setup required.