Jump to content


Photo

Plz correct configuration of Ancestry Record source template


  • Please log in to reply
17 replies to this topic

#1 Gina

Gina

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 05 July 2017 - 08:35 PM

Where the author is blank or the author is a corporation such as Ancestry.com, the Author field on the built-in Ancestry Record source template is not rendering correctly.
 
I believe the following changes to the Author field will correct the issue without adverse impact.
 
Short Footnote
 
From:
[Author:Surname], <i>[Title:Abbrev]</i><, [Page]>.
To:
<[Author:Surname], |[Author], ><i>[Title:Abbrev]</i><, [Page]>.
 
Bibliography Template
 
From:
[Author:Reverse]. <i>[Title]</i>. <[PubPlace]|N.p.>: <[Publisher]|n.p.>, <[PubDate]|n.d.>.

To:

<?[Author:Surname]|[Author:Reverse]. |[Author]. > <i>[Title]</i>. <[PubPlace]|N.p.>: <[Publisher]|n.p.>, <[PubDate]|n.d.>.

 



#2 Gina

Gina

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 05 July 2017 - 08:41 PM

Actually, those changes do not fix the rendering issue when the author field is blank. It only fixes the issue where an author name is a single word like Ancestry.com.



#3 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7780 posts

Posted 06 July 2017 - 09:06 AM

If the author only has one name like, Ancestry.com you can put a slash around the name /Ancestry.com/. Then you won't have that leading comma, if that is what you were trying to remove.


Renee
RootsMagic

#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 06 July 2017 - 09:51 AM

How would you slash every instance of Ancestry.com?

Is there a sentence template that can handle these variations? I see author content from TreeShare such as "Ancestry.com and The Church of Latter Day Saints" come out as "Saints" and "Saints, Ancestry..."

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#5 Gina

Gina

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 06 July 2017 - 12:43 PM

Rene, while that may work, it is not a viable solution for someone using TreeShare.
 
(I originally posted my comment to the issue forum because this is an issue with the implementation of TreeShare.)
 
Using your solution would require that I update EVERY SINGLE master source brought over using TreeShare where the author is a single name EVERY SINGLE TIME the source is brought over (even if it has been brought over before).
 
I believe the correct fix is for RootsMagic to update the built-in TreeShare-specific source template for Ancestry Record so that the Short Footnote and Bibliography render correctly--that is, without the leading zero, spaces, and periods--by making the changes I outlined in my post.
 
Thank you,
Gina


#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 07 July 2017 - 06:40 AM

Actually, those changes do not fix the rendering issue when the author field is blank. It only fixes the issue where an author name is a single word like Ancestry.com.

Do you see citations from TreeShare with author name that would render correctly in the Ancestry Record template? I haven't and wonder if [author] could be removed from all three sentence templates.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#7 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7780 posts

Posted 07 July 2017 - 09:54 AM

Confirming this has been passed onto development to be looked at.


Renee
RootsMagic

#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 07 July 2017 - 03:42 PM

Here's a possible workaround using a SQLite query to modify the built-in Ancestry Record template. Yes, they can be edited through SQLite but the customisation is lost in a RootsMagic transfer.

 

Original sentences:
TreeShare-AncestryRecordTemplateOriginal

 

Revised sentences:
Tree_Share-_Ancestry_Record_Template_Mod

 

SQLite statement:

UPDATE SourceTemplateTable 
SET      Footnote = '<i>[Title]</i> (<[PubPlace]|N.p.>: <[Publisher]|n.p.>, <[PubDate]|n.d.>)<, [Page]>.'
   ,ShortFootnote = '<i>[Title:Abbrev]</i><, [Page]>.'
   , Bibliography = '<i>[Title]</i>. <[PubPlace]|N.p.>: <[Publisher]|n.p.>, <[PubDate]|n.d.>.'
WHERE TemplateID = 439 -- Ancestry Record template
;

I eliminated the [Author] field completely to avoid the problem of parsing it correctly or the extraneous comma in its absence. I don't know if this will work okay for all possible sources that Ancestry may deliver through TreeShare with this template.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#9 Gina

Gina

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 07 July 2017 - 10:14 PM

Works perfectly. Thank you!



#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2989 posts

Posted 08 July 2017 - 06:52 AM

The conventional wisdom from many experienced RM users is never to use RM's built-in source templates directly because the built-in templates cannot be changed if it turns out that they contain any errors. If you want to use sentence templates and don't want to develop your own, this advice reduces down to the recommendation to make copies of the built-in RM templates that you want to use and to use the copies. But in this case, it is not  the user who is using the built-in template. Rather, it is the TreeShare feature which is using the built-in template. So what is the user to do when the template contains an error (or at least, an apparent error)? Even if you made a copy of the built-in template for Ancestry and corrected the error it contains, the TreeShare feature would not use your template. It would still use the built-in template with the error.
 
There is not a straight-forward way within the RM user interface to change a Master Source from one source template to another after the Master Source has been created. (The template is associated with the Master Source, not with the citation. The citation inherits the template from its owning Master Source). For example, if you use one of the built-in templates, discover it has an error, make a copy of the template and fix the error in the copy, then there is not a straight-forward way to change existing Master Sources over to your new template with the fix. Well, I think there is a way within the user interface to create a new Master Source using the new template and to merge the new Master Source with the old one. I don't quite understand the process, so what I do instead is to use a very simple SQLite script that changes the template ID from the old template to the new one. It's not a better way to do it than the way that Tom did it, just a a different way. As compared to Tom's way of doing the SQLite, it has the following advantages: it does not involve changing one of the built-in templates, and having done it you can subsequently make additional changes in your copy of the template directly from the RM user interface. As compared to Tom's way of doing the SQLite, it has the following disadvantage; you would have to keep running it periodically to change any newly created Master Sources to use your version of the template.
 
A problem with RM's source template facility is that there are too many of them. For example, there are 17 different source templates for books. It makes it hard for users to know which one to use, and surely RM could get by without having so many. Once upon a time I looked at a few of RM's source templates for books to see if I could figure out why there are so many. It turned out that two of them were identical except that one of them included the variable [Author] in the bibliography sentence and the other one included the variable [Author:Reverse] in the bibliography sentence. The former is designed for books where the author is an organization (e.g., The Boondock County Historical Society) and the latter is designed for books where the author is an individual (e.g., John W. Doe). It seems to me that for this particular difference, the template instead could collect a piece of data from the user which would be a flag as to whether the author was an individual or an organization (and with an appropriate default if the user didn't provide this flag), and that the piece of data could then be used in the template as a value switch to reverse or not reverse the surname as appropriate.
 
I don't know if this technique could reduce the number of RM's book templates from 17 all the way down to 1, but sure the number of book templates could be reduced significantly. I use templates of my own design and they are heavily invested in value switches. So far, I have been able to get by with only a single template for books.
 
If the RM developers had considered this issue and if they had done the Ancestry template like the book templates, the TreeShare feature would have included two different templates for Sources brought into RM by TreeShare. TreeShare would then have picked the correct template depending on the Author. But your template with the value switch is much the better solution.
 
Finally, even with Tom's fix for the template in place, you may wish to go back and look at the Master Sources that were created with RM's original version of the template. Their sentences may not be quite right. If you just look at them, for example, from the Edit Person screen, the sentences will appear to be correct. But if you actually run a report and look at the footnote, endnote, short footnote, and bibliography sentences that appear, they will probably reflect the original template rather than the fixed template. 
 
To fix this problem, I think it is sufficient to look at each Master Source which used the original version of the template. You don't have to change anything in the Master Source. Just edit the Master Source and then close it out. That's what I mean by "look at it".
 
RM contains what I think is a design flaw in that the report engine doesn't actually look at the source templates. Rather, the process of creating and editing Master Sources looks at the source templates and stores the sentence information in the Master Source. The report engine then generates the sentences from the sentence information stored in the Master Source rather than from the information stored in the source template. So if you change a source template, you then have to trick RM into updating the sentence information in existing Master Sources by editing each such Master Source without actually changing any of the Master Sources.
 
The problem I described in the previous paragraph often is not really be quite as onerous as it sounds. If I discover that I need to make a change in one of my source templates, I usually do not have to go back and edit all my existing Master Sources that use the template. That's because I'm usually making a change to the template that doesn't actually affect the existing Master Sources. I'm usually introducing some new variable into the template that is not used by existing Master Sources. But even with Tom's fix in place, you may wish to take a brief look at your existing Master Sources that are based on the Ancestry template to see if they need to be "looked at" to force them to use the corrected version of the template.
 
And as I said, the only way to know for sure if you have the problem is to run a report and look at the footnote/endnote/short footnote/bibliography sentences that result. Or if there are few enough existing Master Sources using the Ancestry template, just look at them all very briefly from Lists->Source List. It will feel like you are not accomplishing anything. But you are. You are forcing RM to update the sentence information in the Master Source based on the current value of the source template.
 
Jerry
 
 
P. S. I just realized that as compared to my approach of changing the template ID after the fact, Tom's approach of changing the built-in Ancestry source template has the huge advantage that newly created Master Sources with be correct from the get go. You will not have to go back and "look" at each Master Source that is based on the Ancestry template after the fact to persuade RM to regenerate the sentence with the correct template. But you still might need to "look" at the Master Sources that were created before you installed Tom's fix to be sure their sentences are really correct and don't just look correct in the Edit Person screen.


#11 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 08 July 2017 - 08:37 AM

P. S. I just realized that as compared to my approach of changing the template ID after the fact, Tom's approach of changing the built-in Ancestry source template has the huge advantage that newly created Master Sources with be correct from the get go. You will not have to go back and "look" at each Master Source that is based on the Ancestry template after the fact to persuade RM to regenerate the sentence with the correct template. But you still might need to "look" at the Master Sources that were created before you installed Tom's fix to be sure their sentences are really correct and don't just look correct in the Edit Person screen.

When I first read your post, Jerry, I was thinking that, damn, I had forgotten about 'touching' the sources to effect an update. Went back in to check for myself and have been freely changing this one template and seeing the intended results in reports immediately. Came back to respond only to see your P.S., which I must have failed to get to on first reading or you added it after I was there  :P .

 

A problem with the [author:reverse] variable is you get this:

Bibliography: Saints, Ancestry.com and The Church of Jesus Christ of Latter-day. 1881 England Census. Provo, UT, USA: Ancestry.com Operations Inc, 2004.

 

and with [author:surname], this:

Short Footnote: [1]. Saints, 1881 England Census, Class: RG11; Piece: 1504; Folio: 141; Page: 66; GSU roll: 1341363.

 

Including [author], here's an example of footnotes:

[1]. Ancestry.com, 1911 England Census (Provo, UT, USA: Ancestry.com Operations, Inc., 2011), Class: RG14; Piece: 8138; Schedule Number: 184.

[1]. FreeBMD, England & Wales, Civil Registration Birth Index, 1837-1915 (Provo, UT, USA: Ancestry.com Operations Inc, 2006).

[1]. Ancestry.com and The Church of Jesus Christ of Latter-day Saints, 1881 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2004), Class: RG11; Piece: 1504; Folio: 141; Page: 66; GSU roll: 1341363.

[1]. Ancestry.com, 1871 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2004), Class: RG10; Piece: 1441; Folio: 47; Page: 43; GSU roll: 828784.

[1]. Ancestry.com, 1891 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2005), Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. Ancestry.com, 1901 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2005), Class: RG13; Piece: 1386; Folio: 154; Page: 39.

[1]. Ancestry.com, England & Wales, Civil Registration Death Index, 1916-2007 (Provo, UT, USA: Ancestry.com Operations Inc, 2007).

[1]. Ancestry.com, 1871 England Census, Class: RG10; Piece: 1441; Folio: 47; Page: 43; GSU roll: 828784.

[1]. Ibid.

[1]. Saints, 1881 England Census, Class: RG11; Piece: 1504; Folio: 141; Page: 66; GSU roll: 1341363.

[1]. Ancestry.com, 1891 England Census, Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. Ancestry.com, 1901 England Census, Class: RG13; Piece: 1386; Folio: 154; Page: 39.

[1]. Ancestry.com, 1911 England Census, Class: RG14; Piece: 8138; Schedule Number: 184.

[1]. Ancestry.com, England & Wales, National Probate Calendar (Index of Wills and Administrations), 1858-1966, 1973-1995 (Provo, UT, USA: Ancestry.com Operations, Inc., 2010).

[1]. Ancestry.com, England & Wales, Civil Registration Death Index, 1916-2007.

[1]. Ancestry.com, 1891 England Census, Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. FreeBMD, England & Wales, Civil Registration Marriage Index, 1837-1915 (Provo, UT, USA: Ancestry.com Operations 

 

Ignore the footnote numbers - they are hyperlinks in Word and the serial number doesn't paste over here. Plus some weird change in font.

 

Without the [author]:

[1]. 1911 England Census (Provo, UT, USA: Ancestry.com Operations, Inc., 2011), Class: RG14; Piece: 8138; Schedule Number: 184.

[1]. England & Wales, Civil Registration Birth Index, 1837-1915 (Provo, UT, USA: Ancestry.com Operations Inc, 2006).

[1]. 1881 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2004), Class: RG11; Piece: 1504; Folio: 141; Page: 66; GSU roll: 1341363.

[1]. 1871 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2004), Class: RG10; Piece: 1441; Folio: 47; Page: 43; GSU roll: 828784.

[1]. 1891 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2005), Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. 1901 England Census (Provo, UT, USA: Ancestry.com Operations Inc, 2005), Class: RG13; Piece: 1386; Folio: 154; Page: 39.

[1]. England & Wales, Civil Registration Death Index, 1916-2007 (Provo, UT, USA: Ancestry.com Operations Inc, 2007).

[1]. 1871 England Census, Class: RG10; Piece: 1441; Folio: 47; Page: 43; GSU roll: 828784.

[1]. Ibid.

[1]. 1881 England Census, Class: RG11; Piece: 1504; Folio: 141; Page: 66; GSU roll: 1341363.

[1]. 1891 England Census, Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. 1901 England Census, Class: RG13; Piece: 1386; Folio: 154; Page: 39.

[1]. 1911 England Census, Class: RG14; Piece: 8138; Schedule Number: 184.

[1]. England & Wales, National Probate Calendar (Index of Wills and Administrations), 1858-1966, 1973-1995 (Provo, UT, USA: Ancestry.com Operations, Inc., 2010).

[1]. England & Wales, Civil Registration Death Index, 1916-2007.

[1]. 1891 England Census, Class: RG12; Piece: 1169; Folio: 123; Page: 48; GSU roll: 6096279.

[1]. England & Wales, Civil Registration Marriage Index, 1837-1915 (Provo, UT, USA: Ancestry.com Operations Inc, 2006).

 

I don't see that I've lost any key information required to find the reference again.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2989 posts

Posted 08 July 2017 - 09:56 AM

One more little tidbit on this topic is that through the years, users have identified a number of RM's built-in source templates that have errors. Most such errors are very minor - an extra blank or a missing blank, a comma out of place - that sort of thing. Renee asked us all to submit our corrections with the idea that all the corrections would be released at the same time rather than dribbling them out a few at a time.

 

I don't think the corrections have ever been released, and I have been guessing that they will be released in RM8. But no matter when they are released, something will need to be done to "touch" all the Master Sources that depend on the fixed templates, or else the design of the report engine will need to be changed to use the source templates directly rather than storing the sentence information in the Master Source. Similarly, if RM releases a fix for the Ancestry template, either they or the users will have to worry about Master Sources created from the Ancestry template before it was fixed. I.e., such Master Sources will need to be "touched".

 

Jerry



#13 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 08 July 2017 - 10:47 AM

Didn't my test demonstrate that (some) report engines in RM 7.5 do read the changes in the built-in templates? I don't see that my SQLite update should have any different effect from RM incorporating a change.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2989 posts

Posted 08 July 2017 - 11:13 AM

Didn't my test demonstrate that (some) report engines in RM 7.5 do read the changes in the built-in templates? I don't see that my SQLite update should have any different effect from RM incorporating a change.

 

The issue isn't whether the template being changed is a built-in one or not. Changes to any template should apply just fine to any Master Sources created from the template after the template is changed. The issue is whether a "touching" is required for Master Sources that might have existed prior to their template being changed. I'm not sure I'm following your example exactly, but it's difficult to see how any Master Source could ever be changed when its template is changed unless the Master Source itself were "touched".

 

So depending on what your example is telling us, it seems to me that there are only three possibilities. One is that you are changing a template and previously existing Master Sources using the template aren't really changing. Two is that you are changing a template and then looking at a previously existing Master Source to see if the change worked, and the act of looking at the Master Source served to "touch" it to trigger the application of the changes in the template. Three is that you are changing a template and somehow or other the TreeShare code is doing the "touching" required to trigger the application of the changes in the template. My money is on option two. (Secret option number four is that I am completely wrong. :) )

 

Jerry



#15 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 08 July 2017 - 11:49 AM

I vote for Option 4!

In my test I generate a report, execute a script to change the Ancestry Record source template sentence templates, return to the report viewer and go back to report settings and regenerate the report. The footnotes and bibliography have changed.

I think the 'touching' is needed if you change the source template field definitions. These do not get reflected in the source or citation Fields cell (an XML datastore) without opening the source and citation editors and resaving (touching).

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#16 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2989 posts

Posted 08 July 2017 - 05:20 PM

I vote for Option 4!

 

Yep. Secret option #4. I hate it when that happens.

 

Simply changing fixed text (like fixing blanks and commas) does not require "touching". Changing variables does.

 

Also, I confirm that the default Ancestry source template produces incorrect results. Gina's replacement works great.

 

Jerry



#17 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5784 posts

Posted 08 July 2017 - 06:01 PM

We could gather all the needed corrections to Source Templates sentence templates into one SQLite script. That would be an interim benefit until RM Inc programs them in.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#18 ToRoot57

ToRoot57

    Member

  • Members
  • PipPip
  • 8 posts

Posted 12 March 2018 - 11:52 PM

How about the RM developers put in a fix in the next update and gives us an option to select the Source Template we want as we are transferring a source using TreeShare (from Ancestry.com to our RM database) that way would not have to being doing all this tweaking around.