* Advisability of changing Census Roles from default options

[Jean001]

Like you; I think I feel more comfortable entering data from the properties box, facts tab. Part of this is that I'm actually always mentally doing analysis on the data as I enter it and like to have a pseudo-timeline in front of me as I do so. Because I do a lot of French research, I also do a lot of transcriptions and translations prior to entering fact data. I don't currently do a lot of extractions into forms, so auto-text has a limited value in my workflow. Again; your approach seems to be a bit more intuitive (for me). Thank you for sharing your experiences. It helps.

I, too, mentally analyse the data as I enter it and work in the Facts Tab. I work in a 'slow' way: I download new source text/media, then transcribe everything, then add all the Facts individually, especially using 'Witnesses' where I want certain information 'mirrored' in a non-Principal's list of Facts. I'm not so keen on FH's Timeline Fact wording so I have my 'own system'. I used a range of custom Facts before 'going back' to using Witnesses. Using Witnesses is, of course, much the best route as the data is entered once, etc.

I am, perhaps, rather idiosyncratic in how I like to work so some of the time-saving features don't work for me. FH lets me work in my own way.

[AdrianBruce]

Gents; I'm hearing two apparently different views on the subject of witnesses from two very experienced users.

On the one hand, AS doesn't typically include the roles and Nick explained why. On the other, based on Mikes response, it sounds as if some people do use them. I only wish that I had a local user-group that I could have a conversation about the pro and cons of each approach. ...

Without parsing every word, my impression is that Nick was referring specifically to censuses, whereas Mike was answering a more general question about witnesses in general. Hence the slightly different flavour that you see.

I'd kind of agree with Lorna, by the way - to me, your questions come from having an initial understanding of FH, but a sophisticated understanding of (at least some) other genealogy software. So you might get frustrated with stuff designed for a typical newbie...

As for witnesses, if I can throw in my two pennorth (two cents?). I steered clear of witnesses for a long time after they were introduced into FH for reasons not unlike Helen's - they didn't help my compilation of reports. Eventually, I got to the point in my research where I needed to document the transfer of some land between an uncle and nephew. The exact details of the land might be important for identifying other, earlier members of the family. I was about to copy the details from the uncle to the nephew, when I realised that I was about to commit the cardinal sin (to me) of having the same data repeated in two different places. I therefore created a "Land Acquired" event (a new type) with the nephew as the Principal, and the uncle as a witness with role "Grantor". The details of the land were recorded in the Note for the nephew's "Land Acquired" event.

The Grantor's Witness Sentence was set up to read

Code: Select all

<para>{individual} transferred land <{place}> to {principal} <{date}>. {note}

That {note} then repeats the details of the land in the uncle's narrative report, while the details are held just once - against the principal's event.

The key to that story is not about that particular event type - it's unlikely anyone else will need that exact type - rather it's the point that witnesses provided me with a very specific tool to deal with a very specific problem - and in all honesty I've no idea how to distill that into a general piece of advice other than - "Try it and see".

I have used witnesses now for lots of other event types - some the simple stuff like "witnesses" at wedding or "witnesses" to wills, but for also other situations like court cases where again I don't want to repeat text. But which is the principal, which the witness, what the sentences are - it changes for each fact type and the only advice I can give is try each fact type in turn. If that's feasible for you...

[AdrianBruce]

... Using Witnesses is, of course, much the best route as the data is entered once, etc ...

Absolutely!

[Gary_G]

"Jean001";

What you describe is very close to how I typically work on my genealogy.
However; you are the first on FH7 who has said as much.
I'm looking forward to seeing more of your posts on what works for you.
It will likely work for me also.

[RS3100]

"RS3100";

I always meant to ask if anyone had heard whether CP intended to publish an updated book for FH7.
The FH6 one may cover some aspects, but I understood that FH7 made some important changes.

I'm just a user and a customer like you. You would probably have to ask that question of CP, but the FH6 book appeared quite some time after the release of the V6 software. It should be enough to give you a good overview, and combined with the new features list for V7 sequential updates on the CP website, I would have thought you could review many of the changes whilst "playing" in the Sample Project.

Working through the tutorials and the help file was a steep learning curve for me, but I'm very glad I did it before committing my own data to the program.

[Gary_G]

Adrian;

While the issue of witnesses came up wrt. census entries, I've also use them in much the same fashion as you. There are times when a relative is a witness at a birth, marriage or death, but not a person in my family tree. Sometimes their presence supports a case I'm trying to make.

A very good example of how useful it can be is the mystery surrounding my Father's very strange 3rd given name. I found that it was intended to be the same as one of the witnesses at his baptism and that my father's name was incorrectly rendered in the record. Because I recorded the witnesses, I was able to actually locate the fellow's widow, who was able to confirm some of the stories my father told me.

[fhtess65]

As another RM refugee, this is what I've ended up doing - for now, focussing on my main line. If I win the lottery and have all the time in the world, then I'll also do the same for everyone in my tree

With RM and FTM, I was always told there is only ONE WAY to do things. Like you, I soon learned that FH is far more flexible and I had to find a workflow that worked for me. It's been a long haul (over a year), but I'm now pretty much there.

Right now I'm working only on my English side - I may face more challenges when it comes to redoing the Polish side with its very different records. I'll cross that bridge etc. etc.

Teresa

<SNIP>
My current situation is that I'm seeing a lot of issues due to importing data from RM9 and the way it represented information. So; I "think" it may be safest if I kept the tree structure and re-entered all my facts "a la FH7" using my custom EE-Style templates. I'm not really sure that there is an another way to ensure that old RM9 data doesn't impact the way FH7 behaves and sends me "chasing ghosts".
<SNIP>

[Gary_G]

Thanks, Teresa.

When I try a new piece of software, I'm very hesitant to start my data entry all over again. (for obvious reasons)
Up to now, I hadn't heard of all that many who transitioned to FH7 from RM and the approach they took.
So; I've been struggling with whether to start over or try to may the import work. Hence the questions about witnesses etc.
Sounds like the former is what others have ended up doing.

[NickWalker]

Just to be clear, my comments earlier regarding witnesses were all related to census records as that is the title of this thread and what was asked about. Witness roles work well with the other source types e.g. witnesses at weddings. They work where someone is related to an event in a secondary way. It doesn't work (for me) for census because all people in a census are the main subjects and not secondary.

[tatewise]

I think some of my description of Fact Witnesses has been misunderstood.

I was only talking about Census Fact Witnesses, and in particular where the Roles are the relationship to the Head of Household.
It was specifically in response to Gary's question about whether such relationships are included in Reports.
They are NOT part of the Events & Attributes section of Reports unless you use Census Fact Witnesses with relationship Roles.
As I said, some users have chosen to use that feature.

In no way does that contradict the standard recommendation to have local Census events for each household member, which is crucial for some FH features, although that list of features has been reduced in FH V7.
( It is feasible to have both Census events for each household member AND Census Fact Witnesses. )
In FH V7, the Individual Census Report can now include Witnessed Census Events, and the Lookup Missing Census Facts plugin does now detect Census Fact Witnesses. However, all the other drawbacks still apply.
( I will update the KB article tomorrow. )

IMO Census household members are all effectively equal Principals in the Census in the same way that the Bride & Groom are equal Principals in the Marriage. Whereas, other people in a Marriage ceremony are not Principals but people who witnessed the event such as Bridesmaids, Best Man, and Witnesses. I have no problem with such Fact Witnesses.

[Gary_G]

Mike;

Just want to make sure I'm quite clear on one of your points, because you note that it is rather important.
You use the term "local Census events for each household member". I haven't seen that particular description outside of the FHUG.
By that term do you mean that each household member is given their own separate census fact (but shares a common source)?

[tatewise]

You use the term "local Census events for each household member". I haven't seen that particular description outside of the FHUG.
By that term do you mean that each household member is given their own separate census fact (but shares a common source)?

Yes.

[Jean001]

By that term do you mean that each household member is given their own separate census fact (but shares a common source)?

It's a 'Yes' from me too.

[tatewise]

I have updated the Recording from a Census Record article.