* Can non-autogenerated template fields be made to persist?
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Can non-autogenerated template fields be made to persist?
For those who are using a Splitter-style, there can be a number of templated fields that are invariant over several entries. eg. those that reflect a common origin of the records
Is there some setting to cause non-autogenerated template fields to persist until reset?
Is there some setting to cause non-autogenerated template fields to persist until reset?
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Thanks for the reply, Nick.
For me, this is one of the perplexing issues with Splitting. I need to use some invariant template fields to be able to fully mimic EE-style citations, but those fields tend to have to be manually reentered over and over. Not sure, yet, how to efficiently address this in my workflow. I'm still setting up and playing with FH7 and AS7, so perhaps something will occur to me in the process.
For me, this is one of the perplexing issues with Splitting. I need to use some invariant template fields to be able to fully mimic EE-style citations, but those fields tend to have to be manually reentered over and over. Not sure, yet, how to efficiently address this in my workflow. I'm still setting up and playing with FH7 and AS7, so perhaps something will occur to me in the process.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
It's a reasonable thing to want, it's just that AS doesn't do it yet. I tend to add features based on either things I think about implementing or things other people suggest. Whether it happens is dependant on a combination of factors such as time to implement, perceived demand for the feature, complexity and my own enthusiasm.
If I used templated sources myself I can imagine I'd have implemented this request by now. But as I don't I rely on others to make suggestions based on their experience
If I used templated sources myself I can imagine I'd have implemented this request by now. But as I don't I rely on others to make suggestions based on their experience
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
A very reasonable approach, Nick. Your time is precious.
Just because I mention something, please don't think I expect you to implement it.
It's just something for consideration.
---
Thank you, Nick, for being so patient in answering my questions. By way of explanation...
My transition from RM9 to FH7 has uncovered a host of obstacles that I need to overcome. Frankly; RM9 was clearly designed for Lumpers who use the Evidence Explained Methodology. This doesn't mean Splitters and Non-EE supporters can't use RM9; it's just more difficult. Calico Pie has done a wonderful job of importing just about everything from RM9, but it doesn't quite make the transition totally painless. In a Lumper+EE-style the the date of access for a website is typically recorded in the citation part and the use of that data is in both the footnote and the bibliography. Because of its use in the bibliography, a Lumper often can't produce an EE-style bibliography within FH7. To follow EE-style in FH7 one really needs to become a splitter. Unfortunately; that transition in FH7 is a major headache, as you can infer from my various posts. In the end, I think I'll likely just open RM9 to cut-and-paste all my citation data into a FH7 Splitter template via AS. Then I'll blow away any citation connected to an RM9 template. It's a cleaner solution, but so much work that I've been trying any way to avoid it.
Just because I mention something, please don't think I expect you to implement it.
It's just something for consideration.
---
Thank you, Nick, for being so patient in answering my questions. By way of explanation...
My transition from RM9 to FH7 has uncovered a host of obstacles that I need to overcome. Frankly; RM9 was clearly designed for Lumpers who use the Evidence Explained Methodology. This doesn't mean Splitters and Non-EE supporters can't use RM9; it's just more difficult. Calico Pie has done a wonderful job of importing just about everything from RM9, but it doesn't quite make the transition totally painless. In a Lumper+EE-style the the date of access for a website is typically recorded in the citation part and the use of that data is in both the footnote and the bibliography. Because of its use in the bibliography, a Lumper often can't produce an EE-style bibliography within FH7. To follow EE-style in FH7 one really needs to become a splitter. Unfortunately; that transition in FH7 is a major headache, as you can infer from my various posts. In the end, I think I'll likely just open RM9 to cut-and-paste all my citation data into a FH7 Splitter template via AS. Then I'll blow away any citation connected to an RM9 template. It's a cleaner solution, but so much work that I've been trying any way to avoid it.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- cwhermann
- Famous
- Posts: 155
- Joined: 20 Mar 2021 22:04
- Family Historian: V7
- Location: New Hampshire, US
Re: Can non-autogenerated template fields be made to persist?
Gary,
I moved from RM8, follow EE methodology and would consider myself to be a moderate to heavy lumper. I also had a go around with both CP and RM folks about the use of the access date field in the bibliography. I came to the conclusion that even though the RM software allowed it, it did not work if you printed a report with a bibliography that contained a record/source you had accessed more than once. I solved the problem by creating an source level field {Years} to enter in the information RM used from the access date. In addition I found this also provided the flexibility to enter YYYY or YYYY - present or YYYY-YYYY.
I have also customized most all templates because I have taken the approach to (in EE lingo) use the author or jurisdiction as the lead element when ever possible. I also structure my FamilySearch citations with waypoints directly to the image rather than via collections/databases. (Like Gary, I got tired of typing "FamilySearch" in to a more generic template.) I have found that by structuring the level of lumping around the information contained in the bibliography and using the {Years} field, I can maintain an acceptable level of lumping and closely follow EE methodology. I have attached a screen shot of a template and a resulting citation showing this approach. Given the flexibility FH offers, I don't see any reason one cannot operate anywhere they would like along the lumping/splitter spectrum. Full disclosure - I have not looked at AS and how it would work with the way I structure my templates.)
I found there was a significant amount template clean up needed after my import. The way FH used my field hints to create the field names, the difference in field operators and having to learn how the special handling for top level text impacted the templates required several months. I will admit this took me longer to work through because I took advantage to clean up/establish a media linking protocol, incorporate some rich text formats in my text from source and create some auto-text templates. Despite way more "work than anticipated" after the conversion, I am happy I made the change and can now start to use so many of the features to handle my data.
I moved from RM8, follow EE methodology and would consider myself to be a moderate to heavy lumper. I also had a go around with both CP and RM folks about the use of the access date field in the bibliography. I came to the conclusion that even though the RM software allowed it, it did not work if you printed a report with a bibliography that contained a record/source you had accessed more than once. I solved the problem by creating an source level field {Years} to enter in the information RM used from the access date. In addition I found this also provided the flexibility to enter YYYY or YYYY - present or YYYY-YYYY.
I have also customized most all templates because I have taken the approach to (in EE lingo) use the author or jurisdiction as the lead element when ever possible. I also structure my FamilySearch citations with waypoints directly to the image rather than via collections/databases. (Like Gary, I got tired of typing "FamilySearch" in to a more generic template.) I have found that by structuring the level of lumping around the information contained in the bibliography and using the {Years} field, I can maintain an acceptable level of lumping and closely follow EE methodology. I have attached a screen shot of a template and a resulting citation showing this approach. Given the flexibility FH offers, I don't see any reason one cannot operate anywhere they would like along the lumping/splitter spectrum. Full disclosure - I have not looked at AS and how it would work with the way I structure my templates.)
I found there was a significant amount template clean up needed after my import. The way FH used my field hints to create the field names, the difference in field operators and having to learn how the special handling for top level text impacted the templates required several months. I will admit this took me longer to work through because I took advantage to clean up/establish a media linking protocol, incorporate some rich text formats in my text from source and create some auto-text templates. Despite way more "work than anticipated" after the conversion, I am happy I made the change and can now start to use so many of the features to handle my data.
- Attachments
-
- Screenshot 2023-04-02 235936.jpg (183.13 KiB) Viewed 1145 times
-
- Screenshot 2023-04-02 235408.jpg (213.72 KiB) Viewed 1145 times
Curtis Hermann
FH 7.0.15
FH 7.0.15
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
"cwherman";
Your solution to the bibliographic years problem is exactly what I did in Roots Magic, because I really didn't like having multiple bibliographic references simply due to having accessed the source in several years. The issue is how to determine the span to set. It can't be done automatically, but perhaps a plugin could be written to scan the database and set it appropriately. Something I might mention, though, is you will notice that the posts by Elisabeth Shown-Mills (EE author) never seem to address bibliographic entries. She focuses almost exclusively on the Footnote content and format. This appears to be because only a few types of publications include a bibliography. So; does including the date in a bibliography add significant value? Sometimes, I wonder...
I also did something similar to your approach for my templates in general. My RootsMagic Master Sources reflected the invariant repository and category of document in that repository. So; I had a 3 Master Sources for each French departmental archive; État civil, Census and Military. Because of the template logic, all used the same template. It made things so simple.
Then I came to FH7... Everything transferred over and everything except the bibliographic dates worked. FH7 promoted extreme splitting, but nobody addressed how a splitter would handle repeating data in every citation. I assume that this is because bare-bones FH7 data entry allows cloning entries, so clone and edit is possible.
AS attacks things a bit differently and would seem to need some way of making invariant data persist until changed. From what Nick says, Ancestral Sources can actually be configured to handle Lumper templates. However; I'm not sure how/if it handles the invariant data in the associated Lumper template fields. Perhaps Nick can explain how a Lumper can work templates in AS.
Your solution to the bibliographic years problem is exactly what I did in Roots Magic, because I really didn't like having multiple bibliographic references simply due to having accessed the source in several years. The issue is how to determine the span to set. It can't be done automatically, but perhaps a plugin could be written to scan the database and set it appropriately. Something I might mention, though, is you will notice that the posts by Elisabeth Shown-Mills (EE author) never seem to address bibliographic entries. She focuses almost exclusively on the Footnote content and format. This appears to be because only a few types of publications include a bibliography. So; does including the date in a bibliography add significant value? Sometimes, I wonder...
I also did something similar to your approach for my templates in general. My RootsMagic Master Sources reflected the invariant repository and category of document in that repository. So; I had a 3 Master Sources for each French departmental archive; État civil, Census and Military. Because of the template logic, all used the same template. It made things so simple.
Then I came to FH7... Everything transferred over and everything except the bibliographic dates worked. FH7 promoted extreme splitting, but nobody addressed how a splitter would handle repeating data in every citation. I assume that this is because bare-bones FH7 data entry allows cloning entries, so clone and edit is possible.
AS attacks things a bit differently and would seem to need some way of making invariant data persist until changed. From what Nick says, Ancestral Sources can actually be configured to handle Lumper templates. However; I'm not sure how/if it handles the invariant data in the associated Lumper template fields. Perhaps Nick can explain how a Lumper can work templates in AS.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
The Ancestral Sources Method 2 (Lumper) doesn't currently allow templated sources to be used, but can be used for generic sources. I developed the templated source support before Family Historian 7 (which introduced source templates) was released. All of the relevant built in templates that are included in FH are splitter templates and I knew that this would lead to lots of confused method 2 users who would try out source templates only to find they didn't work as expected and for most users it would be a step too far to have to create their own lumper templates in FH. I did always have it in mind that if I started to get lots of requests for method 2 to support templated sources that I would build in support for this but that hasn't happened.Gary_G wrote: ↑03 Apr 2023 12:18AS attacks things a bit differently and would seem to need some way of making invariant data persist until changed. From what Nick says, Ancestral Sources can actually be configured to handle Lumper templates. However; I'm not sure how/if it handles the invariant data in the associated Lumper template fields. Perhaps Nick can explain how a Lumper can work templates in AS.
As has often been commented upon (e.g. in my Sources video), Family Historian lumper sources end up recording a lot of duplicated data which is anathema to me because of my database design experience. Templated sources used with lumper sources leads to even more duplicated data so it isn't something I particularly want to encourage users of AS to do.
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Nick;
Thanks for the explanation/clarification.
---
Side note:
I've been trying to figure out how to switch to splitting, so I could use more of the available FH7 features and those of AS7. Sadly; I can still see no clear way to accomplish the changeover without completely re-entering my RM9 imported data, since the current Lumper->Splitter plugin generates individual identically named sources that all reference the original Lumper-specific template.
There is also the issue of efficiently populating invariant template fields of Splitter templates, which doesn't just affect AS7 data-entry. If one is a Splitter, the invariant data actually needs to be entered in each instance of the template, which is a time/efficiency issue even in FH7 proper. I'm hoping someone has advice on that front.
Thanks for the explanation/clarification.
---
Side note:
I've been trying to figure out how to switch to splitting, so I could use more of the available FH7 features and those of AS7. Sadly; I can still see no clear way to accomplish the changeover without completely re-entering my RM9 imported data, since the current Lumper->Splitter plugin generates individual identically named sources that all reference the original Lumper-specific template.
There is also the issue of efficiently populating invariant template fields of Splitter templates, which doesn't just affect AS7 data-entry. If one is a Splitter, the invariant data actually needs to be entered in each instance of the template, which is a time/efficiency issue even in FH7 proper. I'm hoping someone has advice on that front.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
I do understand this and am thinking about how I could improve the situation in AS. Just to clarify, can you specify the particular 'invariant' fields you're referring to? Invariant suggests they never change, so those values could be specified in the AS Source Template editor. I was assuming you meant fields such as 'Collection' or 'URL' which are the 2 fields in the Census essentials template that AS can't populate for you from the data you enter.There is also the issue of efficiently populating invariant template fields of Splitter templates, which doesn't just affect AS7 data-entry. If one is a Splitter, the invariant data actually needs to be entered in each instance of the template, which is a time/efficiency issue even in FH7 proper. I'm hoping someone has advice on that front.
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Nick;
When I made my Lumper templates, I defined the fields in the RM9 Template "Master Citation" based on them being invariant for a specific repository/website and not something where one would typically be able to get the info from the specific image being evaluated. So; perhaps the following screen-capture of what was in that section of my RM9 template would help.
If there were a checkbox beside the template editor fields to mark them as persistent (ie. keep them from being cleared for each new item documented) that might do the trick. I believe that most people would find themselves working on a particular set or subset of records from a repository as a group. So; this would likely work for the majority of users. Of course, the checkbox settings and field values might also be saved (for convenience) in the AS configuration for the template. That means one could essentially set a default and "override" them as required.
Make any sense?
When I made my Lumper templates, I defined the fields in the RM9 Template "Master Citation" based on them being invariant for a specific repository/website and not something where one would typically be able to get the info from the specific image being evaluated. So; perhaps the following screen-capture of what was in that section of my RM9 template would help.
If there were a checkbox beside the template editor fields to mark them as persistent (ie. keep them from being cleared for each new item documented) that might do the trick. I believe that most people would find themselves working on a particular set or subset of records from a repository as a group. So; this would likely work for the majority of users. Of course, the checkbox settings and field values might also be saved (for convenience) in the AS configuration for the template. That means one could essentially set a default and "override" them as required.
Make any sense?
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
Yes that makes sense and is as I thought. I'll see what I can do.
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Wonderful!
That would make it possible for one to do something in AS7 that is not exactly easy/possible in FH7 itself.
That would make it possible for one to do something in AS7 that is not exactly easy/possible in FH7 itself.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- tatewise
- Megastar
- Posts: 27075
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
Thinking outside the box, would a suitably named Repository record and metafield offer an alternative solution?
If the Repository record name includes all those invariant text values then its metafield link will include all that text in the Biography Format by using the {Repository} metafield.
AS has a convenient method of shortlisting Repository entries.
The Repository record itself can contain further details of that specific repository/website.
They can be included in the Biography Format by using {%SOUR.~RP-REPOSITORY>ADDR%} to access the Address field and similarly for any other Repository record fields.
If the Repository record name includes all those invariant text values then its metafield link will include all that text in the Biography Format by using the {Repository} metafield.
AS has a convenient method of shortlisting Repository entries.
The Repository record itself can contain further details of that specific repository/website.
They can be included in the Biography Format by using {%SOUR.~RP-REPOSITORY>ADDR%} to access the Address field and similarly for any other Repository record fields.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Mike;
I see what you are saying, but that approach assumes that all the persistent fields are fixed for a given repository. One couldn't represent a situation in which a repository had several collections without creating a separate repository for every collection. The originally proposed solution is much more flexible and allows the end user make quick tweaks/changes as they work their way through the data to be entered.
I should also note that while the image I posted may seem to imply that all persistent fields in a template are associated with a repository, that isn't necessarily the case.
I see what you are saying, but that approach assumes that all the persistent fields are fixed for a given repository. One couldn't represent a situation in which a repository had several collections without creating a separate repository for every collection. The originally proposed solution is much more flexible and allows the end user make quick tweaks/changes as they work their way through the data to be entered.
I should also note that while the image I posted may seem to imply that all persistent fields in a template are associated with a repository, that isn't necessarily the case.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Nick;
I was taking a walk (where I do my best thinking) and realized that the proposed solution fully addresses the case when the record doesn't exist. However; when a record is already there, the template should use the pre-existing template values, just as the main body of AS7 does. This is a bit of a wrinkle, but at this point I defer to your experience. I haven't yet done much editing of existing records.
I was taking a walk (where I do my best thinking) and realized that the proposed solution fully addresses the case when the record doesn't exist. However; when a record is already there, the template should use the pre-existing template values, just as the main body of AS7 does. This is a bit of a wrinkle, but at this point I defer to your experience. I haven't yet done much editing of existing records.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
AS doesn't edit existing sources/citations (except in a very specific circumstance where it can help AS users to convert their census method 1 sources to templated and/or richtext), it generates new ones. I think you are possibly expecting too much of it. It will offer to copy citations into a fact being replaced but that's generally in case there are other sources for the fact that would otherwise disappear (e.g. Another existing marriage source may be a newspaper notice). If you are wanting to keep your existing sources for e.g. a parish baptism but have AS enhance it, then that's not what it does.
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Nick;
I was only being careful to ensure that I hadn't overlooked some aspect. As noted, I am "starting" to get the feel for using AS, but haven't got all the workflow figured out.
I was only being careful to ensure that I hadn't overlooked some aspect. As noted, I am "starting" to get the feel for using AS, but haven't got all the workflow figured out.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!
- NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Re: Can non-autogenerated template fields be made to persist?
The next version of AS will include the facility to 'carry forward' Source Template field values that are not automatically generated, to the next entry. In the screenshot below the red C icons show that those 2 entries are carried forward from the previous. The red circle next to Register Type indicates that one hasn't been carried forward.
Gary: Don't worry, I know that it's possible you won't end up using AS but don't feel guilty. Your suggestion of being able to make the non-autogenerated fields persist was a good one and not one I'd previously considered because I'm not a template source user. I'm sure other users of AS will appreciate this feature.
Gary: Don't worry, I know that it's possible you won't end up using AS but don't feel guilty. Your suggestion of being able to make the non-autogenerated fields persist was a good one and not one I'd previously considered because I'm not a template source user. I'm sure other users of AS will appreciate this feature.
-
Gary_G
- Superstar
- Posts: 304
- Joined: 24 Mar 2023 19:05
- Family Historian: V7
- Location: Calgary, Alberta, Canada
Re: Can non-autogenerated template fields be made to persist?
Nick;
It looks good! You've been busy.
The example you provided is a great one to illustrate the capability.
Believe me; if AS saves me time, I'll be using it.
I've decided to re-enter my RM9 data, because there are things that are better done a certain way in FH7.
It looks good! You've been busy.
The example you provided is a great one to illustrate the capability.
Believe me; if AS saves me time, I'll be using it.
I've decided to re-enter my RM9 data, because there are things that are better done a certain way in FH7.
Gary Gauthier
Hunting History in the Wild!
Hunting History in the Wild!