Jump to content


Photo

Preparing an RM Descendant Narrative Report for a Family Reunion for This Year


  • Please log in to reply
27 replies to this topic

#21 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 29 May 2017 - 09:13 AM

On your question about the "new paragraph after every fact" option: I don't use it, but I might if I were starting from scratch today. In the whole history of Family Origins and RootsMagic, it's a fairly new option so before it came along I had to come up with other ways force a fact to begin on a new line. For a very long time, I did so by including a carriage return as the last bit of data in the fact note for the immediately preceding fact. It was an awkward technique, but it worked. It also had the virtue of working for the pre-RM6 Web pages that you can create from RM.

 

But the pre-RM6 Web pages have been deprecated and probably will not be available in the rewrite of RM for RM8. I don't know for a fact that the pre-RM6 Web pages will not be available in RM8, but it seems likely that they will not since they have been deprecated. So I'm doing my Web pages a different way now that does not depend on RM so I'm free to do my "new paragraph" things a different way. My different way is to put the carriage returns into the sentence templates. I really only use about a dozen different fact types, so it wasn't that many different sentence templates to change.

 

Putting the carriage returns in the sentence templates works fine, but the RM report option for a "new paragraph after every fact" might also work fine. The thing that gives me pause with the RM report option is that it is unconditional. If turned on, it always puts every fact in a new paragraph. There might be a case someday where I don't want a new paragraph for a  particular fact, and the way I do it with the carriage returns in the sentence templates allows me to be very targeted as to when there is and when there isn't a new paragraph. Well, RM offers one more report option where you can condition the new paragraph on whether or not the previous paragraph includes a note. It might meet my needs, but I would have to make massive changes to my database at this point to use it. What I'm doing is very simple, it gives me great control over my reports, and it "just works".

 

Jerry

 



#22 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 29 May 2017 - 09:32 AM

I understand your trepidation about changing RM's default sentence templates, but they are easy to change back. What is really needed is for RM to support libraries of sentence templates, where you can have Default sentence templates and you can also have other sets of sentence templates available. For example, you might have a set of Point Form sentence templates available such as mine, you might have a set of Verbose sentence templates available, you might have a set of Terse sentence templates available, you might have a set of French sentence templates available, you might have a set of Norwegian sentence templates available, etc. And if such things were available, users should be able to develop their own sets of sentence templates and exchange them with each other. Doing it this way, you could change between one set of sentence templates and another set with a couple of clicks and you could establish your own sentence templates without changing any of the default ones. This request is in the RM wish list, but I do not have any high hopes that the wish will be fulfilled in RM8.

 

One other sentence template item that really needs to be addressed is that there are bits and pieces of RM narrative reports that are not under control of any sentence templates. One is example is what I call the "spouse sentence" - the sentence that provides the name, birth information, and parents for the spouse of the current person. RM pretty much produces what it wants to produce for this sentence, not what's in any sentence template. The other example is the sentences for children in NGSQ and NEHGS reports when the children are carried forward to the next generation. Again, RM produces what it wants for these sentences. For example, if you developed French sentence templates for your narrative reports, these "carry forward" sentence would still be in English - not a good situation.

 

I would regard the provision of libraries of sentence templates to be a new feature, and a wonderful new feature. I would regard getting all aspects of narrative reports to be under control of sentence templates to be a bug fix, and a much needed bug fix. It really wouldn't be a new feature. It would be fixing a defect in an existing feature.

 

Jerry



#23 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 29 May 2017 - 09:48 AM

One more question you asked was about things such as Namesake: and Gravemarker: in my reports. At the time I first posted the first message in this thread, data such as this was entered as a part of a fact note. The Namesake: thing was entered into the birth fact note. The Gravemarker: thing was entered into the burial fact note. It's easy in a note to begin information on a new line and to make it bold.

 

Since then, I have been switching over to things like Namesake and Gravemaker being their own separate fact types. It's more work on my part to do it this way, but I find that there are two advantages to doing so. One advantage is that facts can be included or excluded from things like narrative reports and GEDCOM exports on a fact type by fact type basis. So for example, I could easily produce a narrative report that did or did not include such information for everyone in the report. The other advantage is that doing it the new way makes it possible to target sources more closely to the precise information for which the source is the appropriate citation. A source for a namesake might not provide any information about a birth place or date, and a source for a birth place or name might not provide any information about a namesake. Etc.

 

Jerry

 



#24 draydev1

draydev1

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 29 May 2017 - 10:55 AM

For the Namesake and Gravemarker facts, do you leave the sentence template null or do you have <[date]><[place]> and just leave them blank?  I have a few facts that I have no sentence template and they work pretty good. I will be going back to them, though, and adding the template to make the heading bold.

 

I'm still trying out combinations of the sentence templates with/without the carriage return and also the option of RM's with/without new paragraph after facts.  I do agree with your reasoning for adding it before the sentence template for the times you may not want facts separated.  It makes it easy to go into the sentence for that one or two facts (just under a certain person) and change it, without affecting the fact for everyone.  At least that's how I think I would do it.  Things for me to think about.

 

Thanks again.  You've been a tremendous help!

 

Kim



#25 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 29 May 2017 - 01:11 PM

Ok, so what I really do these days for death events is to enter up to three different facts if I have that much data - death, obituary, and death certificate. And sometimes there may be multiple obituary facts if there are multiple sources for obituaries and if the obituaries from the multiple sources are different. I'm probably going to rename "death certificate" as my fact type to being "death record" because sometimes I have an official death record that is not actually a death certificate. In the sentence templates below, I am denoting a carriage return as {cr} but of course in RM itself you just hit the enter key on your keyboard. What is stored in the RM database is actually a carriage return/line feed sequence (or CTL-M, CTL-J or 0x0D0A if you are into that sort of thing). What may look a little funny is that these templates may appear not to be doing very much in a couple of cases. That's because the note field is always included. It's as if there were a [Note] variable in RM's sentence template language and if it were always there. For example, the Obituary fact is mostly just its note and so too is the Death Certificate fact. As an aside, I should mention that I think that RM would be much better served if it did actually have a [Note] variable in its sentence template language.

{cr}
<b>Death:</b>< [Desc]>< [Date:Plain]>< [person:Age:plain:commas]>< [PlaceDetails]>< [Place:plain]>.

{cr}
<b>Obituary:</b> 

{cr}
<b>Death Certificate:</b> 

Similarly, what I really do for burial events these days is to enter up to three facts if I have that much data - burial, burial inscription from the stone, and burial GPS. I actually go to burial sites with my handheld GPS device - a very accurate one that I also use for hiking and other back country activities - and I get GPS coordinates down to the individual burial site. Smart phones these days will usually geo-tag photos with GPS coordinates so that is another way to do it. But I don't think such coordinates are quite as accurate as are the ones from my hiking GPS. In the case of the Burial GPS fact, I use both the description field (which you can see in the sentence template) and the note field (which appears in reports even though it is not in the sentence template). I place the coordinates in the description field which is great for looking at in RM's People View. I place a URL in the note which will take you to a Web page with a Google map with a pin on the grave marker. I make it a private note and don't print the URL in reports on paper but I do publish the URL when I make Web sites. In the case of the burial inscription itself, I place it in the description field instead of the note field because it's very short and because it will then show up very nicely in RM's People View. Again, the {cr} denotes that you hit the Enter key on your computer's keyboard.

{cr}
<b>Burial:</b>< [Date:Plain],>< [PlaceDetails]>< [Place:Plain]>.

{cr}
<b>Burial inscription:</b>< [Desc]>

{cr}
<b>Burial GPS:</b>< [Desc]>

Jerry



#26 draydev1

draydev1

    Advanced Member

  • Members
  • PipPipPip
  • 49 posts

Posted 29 May 2017 - 03:46 PM

That's exactly how I was thinking you did the sentences.  Thanks again!

 

Kim



#27 Dick-TMG

Dick-TMG

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 28 August 2017 - 08:49 AM

Jerry,

 

Impressive work.

 

First a word of caution.

 

I converted from TMG almost 3 years ago after working in TMG for 15+ years. TMG provided significantly more capability in formatting reports than RM does now. I made extensive use of their capabilities and could produce a report conforming to anyone’s standards. I was able to produce a 400 page report that was well worded and conformed to the register style format including all the correct fonts, indentations, footnotes, etc. My one complaint was that when reproducing a report with pictures I did not have a way to place those pictures in the report with their proper placement and formatting of the picture. Seems like a very trivial complaint to me now. All worked well until 2014 when I was forced to move my data to another platform. I am still cleaning up artifacts of what I was able to do in TMG.

 

Even today I find other products have a certain function that RM does not and because I don’t need facts and sentence structures or roles and for those functions I can utilize the GEDCOM export/import.

 

Note: I have copies of TMG, LegacyFamilyTree, FamilyTreeMaker and Rootsmagic, and I did an analysis of Family Historian.  After all that I chose RootsMagic because I felt it was the best so I am not being negative towards RM.

Just a word of caution from someone who had to make the switch.

 

My second point is when I look at what you produced it appears that most of the well worded text comes from the RM note field. It is outside of any conventional footnote standard that I have ever seen so the entire note is unsourced based on the output I see. This is not your fault Jerry as I think the reason is in RM itself. If I look at a fact I can put in a Date, Place, and Description (limited to 100 characters?). These are the only fields that are included in any source footnotes Most of us must put any significant data into the note field.

 

I think that this can be corrected by providing an additional field within the fact itself that can handle significant data. Personally I would add an additional field in the line above the “Details” line that would work just like a note but be included as a part of the fact. This is where I would put all the actual data for a fact. I would then use the note field to place thing like a proof statement that would justify my conclusions as to the fact itself. Then I could have the choice of printing out just the fact without the note field without losing any data and have it all properly footnoted.

 

The GEDCOM standard 5.5.1 lists note as: “Additional information provided by the submitter for understanding the enclosing data.” By using a CONC in GEDCOM any amount of data should be transferred that way.

 

Just what I would see as a beneficial addition to RM.

 

I like what you did Jerry. It looks great.



#28 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 28 August 2017 - 01:04 PM

Thank you for your kind comments.

 

As far as my RM data being able to be converted to any other software platform, I share your concerns. The way I have come to think about the problem, the best approach is to separate data from metadata. That means that I have an expectation that any other software platform will retain things like facts and notes and sources. But that  also means that I don't have any particular expectation that any other software platform will retain things like my sentence templates and my source templates. Well, in the case of my source templates, the loss of the templates in another software platform is ok as long as the citation sentences themselves are preserved, and this is pretty much the case with my data. 

 

I agree that not being able to provide sources for notes is a serious problem in RM. There is not a really good solution. The only thing I've done that sort of tends in that direction is that the point form report that I first posted in this thread has since evolved even further. I used to include transcripts of death certificates and obituaries in the note for RM's death fact. I now have three "death facts" - the standard death fact, a death certificate fact, and an obituary fact. The death certificate fact and the obituary fact are essentially facts which only have a note. So an obituary itself serves as evidence (a source - a citation - a source citation - or whatever) for the obituary fact and for the death fact. A death certificate itself serves as evidence for the death certificate fact and for the death fact. This approach lets me be slightly more targeted with my sourcing, and it also lets me if I wish to produce reports that don't include obituary transcriptions or death certificate transcriptions. I'm doing the same thing with several other kinds of facts where I break the fact into component parts be creating new user defined facts (birth certificate fact, birth notice in the newspaper fact, tombstone transcription fact, tombstone GPS fact, etc.). Even though I say I'm being more targeted with my sourcing for notes such as obituaries and death certificates, the citation superscript comes before the note instead of as a part of the note or after it. There is really nothing I can do in RM to correct this situation.

 

Well, there kind of is a way in RM I could have gotten the citation superscript to the end of a note, but it's so obnoxious that I didn't want to go there and it would have caused data not to be shared well with other software platforms. Namely, I could have created a "citation only" fact where the sentence template was completely null. I could have put such a fact after the note and the citation would have been in the correct place. I got the idea from RM's direct import of TMG data. TMG has a way to provide evidence for parentage, e.g., a place in the data to which such evidence can be attached. RM has no such place for evidence of parentage, except in the sense that you can attach such evidence to the "general person" data for a person. So when RM imports evidence of parentage from TMG into RM, RM creates sort of a dummy fact called ChildParent to which the evidence of parentage is attached. The ChildParent fact which RM creates has a null sentence template. That way, the evidence of parentage is not lost on import from TMG to RM, and there is even a citation superscript when RM prints a report. The only problem is that the citation superscript is sort of dangling in midair since it has no sentence to which it is connected.

 

Back to RM data and other software platforms, as a former TMG user you are surely familiar with a software platform called SecondSite which makes Web pages from TMG data and with a new product called GedSite. GedSite is very much like SecondSite except that it makes Web pages from GEDCOM and the GEDCOM can come from any software platform that can make GEDCOM. (Disclaimer: GedSite is not an RM product and might be viewed as a competitor to the Web pages that RM itself can make.) GedSite is very clever in reading GEDCOM from other software platforms in that if said GEDCOM includes metadata such as sentence templates, then GedSite will take advantage of such metadata and format Web pages appropriately. GedSite does an excellent job of interpreting RM's GEDCOM and in formatting RM's data based on RM's sentence templates. But I have nevertheless found it very advantageous to ignore that capability of GedSite and instead to enter metadata such as sentence templates and date templates directly into GedSite and to tell GedSite to ignore RM's own metadata. This is very consistent with my notion of separating data from metadata as way of not having to worry about my RM data in other platforms.

 

Jerry