* A plea for Updated V7 Video Tutorials Please please…please

[LornaCraig]

I would just add that if if Calico Pie ever produce a 'Getting the Most From ... ' book for V7 it is very likely to take the same approach. The early chapters will be written with new users in mind. If you look at the V7 Help files and follow a trail through Introduction to Source-Driven Data Entry and Source Driven Data Entry and Sources and Source Templates you'll see that CP set out the pros and cons of templated sources vs generic sources but recommend using templated sources, and then go on to recommend starting with the ready-made set of Essentials templates. They don't say "this is the way it has to be done" but in practice it's the way most new users will do things because that's the way they will be steered.

Users who come with 'baggage' from other genealogy programs, or from using ealier versions of FH where they (we) developed our own style, may choose to do things differently but probably don't need an introductory video.

[Mal]

Des,

I’d like to go back to your original post and offer thoughts on how to proceed. Three areas were concerning you:

1. Videos
I think the video tutorial aspect has been covered by knowledgeable and experienced FHUG members in earlier posts. I reckon Calico Pie are best placed to produce, or sub contract, what you are looking for. I suspect they might counter by saying they have provided the functionality requested by FHUG members, expressed in the Wishlist and elsewhere. And that their job is now done. But that’s speculation. If you feel strongly why not raise the issue with the company directly and ask them to reveal their plans for producing user guidance and training materials (written and audiovisual) covering the source-driven data entry aspects of FH7. Please share any response with the FHUG.

2. Confusion about Source-driven data entry
You are not alone in feeling as you do. At the heart of the matter is the fact that there is no universally agreed definition of the source-driven approach, nor what level of precision is required to acceptably define a source or a citation. To be more direct - there are even differences of emphasis and opinion within the FHUG. This is not a criticism, it’s merely the way things are.
I can live with the generality and lack of specifics though because I don’t believe it matters at all.

I say this because the source-driven concept is a convenient shorthand for a general approach. It can be (and is) interpreted differently by different people. And, many different user interpretations may be equally valid.

This is good news for you. It means that the data you have already keyed into Family Historian may be perfectly OK. Although this will need to be confirmed, you shouldn’t worry for now. Let’s look on the bright side.

3. Re-entering your data to improve Source & Citation aspects
You mentioned the size of your database (2804 individuals 856 families) and hinted at the possibility of re-keying, with a view to improving source driven aspects. This would be a huge task and may not of itself take you much further forward. If you have adopted the genealogists golden rule - Record all of the information you have found/not found - you will have a solid foundation. It matters not whether its recorded in FH so long as you are content it is recorded somewhere and you can find it again.

Were I in your position, my instinct would be to pause for breath and take stock. I would initially assume that the data entries were acceptably defined and adequately supported by an acceptable level of proof. Acceptable in this sense means whatever is acceptable to you. After all this is your hobby and you get to make your own rules - simple or complex; it’s your choice. Those who have good reasons for academic precision, or desire forensic levels of proof might choose different rules.

A review would then be needed to identify gaps/problems and decide what to do about them.

Additionally, I would temporarily suspend any thought of changing previously entered data, and stop entering new data.

Suggested way forward
1. Mull over the above. Take a break from trying to make sense of the source-driven stuff, sources, citations, DEAs, templates etc. Just be aware that it is straightforward to populate FH with high quality data and reliable evidence, without recourse to Automatic Source Citations or any of the so-called, source-driven, functionality in FH7.

2. After reflection I would encourage you to address this question: Do I still have doubts about my FH7 data, and why? Then think about what you’d like to improve, in general terms. To do nothing is always a choice. If you have supporting evidence for your FH data, even though the evidence, or reference to it, isn’t included in FH, it should be straightforward to come up with a practical fix or workaround that suits you. I’m not asking you to identify fix options at this stage, but you can if you wish.

Once you’ve scoped the problem I’ll be happy to assist further, as I’m sure FHUG colleagues will too.

Regards: Malcolm

[Jean001]

I thoroughly agree with Malcolm's comments.

[BevSmallwood]

I also get the impression from Forum comments that FH V7 is not "lumper" (Method 2?) friendly.

I'm new here and I'm a lumper. I didn't see any problems. Can you tell me in what way this is a problem in FH7?

I only created one source and it was a learning experience!

-
Bev

[tatewise]

Bev, exactly what kind of Source Citation did you create?
Did you use a generic Source Citation or a templated Source Citation?

The generic Source Citation methods fully support both 'splitter' Method 1 and 'lumper' Method 2.

In the latter case which Source Template did you choose to use?
Most of the Source Templates only support 'splitter' Method 1.
However, the problems may not become apparent until you try to add more Source Citations.

[LornaCraig]

Mike, in another topic Creating Source Templates and Sharing (20820) Bev talked about creating a source template, not using an existing one. And it looks like a "lumper" style template.

Bev, the comment someone made about FH7 not being "lumper" friendly is just because, as Mike has said, most of the ready made templates are designed for "splitter" sources, as you will see from the Description field in the templates. An exception is the one for Civil Registration index, which is designed for one source record per index . But there is nothing to stop you creating your own templates, as you have found, and using them for "lumper" sources. You just need to be aware that when you add details to the citation, such as Text or Notes, you add them to the Citation and not to the Source record itself.

[Vyger]

For visual learning, I would also highly recommend Jackson Eagleson (Vyger)'s GenealogyReviews YT channel. He has a few videos about the various features on FH7, and I am sure that he has more in the works. Genealogy Software Showcase also did a video series on using the various features of FH7. It is always useful to see how other people are using the program.

I really should come here more often but firstly thank you to sbell95 for the recommendation.

So in a sort of introduction let me first say in my 25 (only) years around genealogy I always found sourcing a hindrance, I was never intending to write a manuscript, I was only wanting a path back to where I found the original information, the result is much of my old data has little sourcing as I was always rushing to a conclusion. I am no expert in Sourcing but I know the Splitter/Lumper argument is one which will never rest, FTR, I am a Lumper and a Book, Register or letter is a Source, the place it is stored is a Repository and the Details contained in that Source related to my data is a Citation and many Details may stem from the same Source so different Citations. People are always free to do as they please but I would ask why we have relational databases rather than simple long lists, the answer is relational databases are more efficient and space saving, relational databases liken to Lumping, long lists liken more to Splitting. I find these differing approaches (which serve the same goal) are often from personal style preferences or a habit formed in years gone by to achieve a particular result in some software package.

I'm happy to produce videos for two reasons,

1. They help me learn the software both in prep and afterwards in discussion, Family Historian is relatively new to me after spending around 20 years with Buzbee&Co during the Family Origins and Rootsmagic days.

2. All software has problems and shortcomings, with respect, many old time users accept these shortcomings and have clever workarounds they are happy to share, that's not restricted to FH users. However the software should be clever and intuitive and users should not need heavy user manuals just to get to grips with it. I am happy to visually highlight such shortcomings (in the hope development listen and respond) whilst demonstrating the various positives so users can benefit.

My efforts to provide user feedback and analysis to Rootsmagic failed so I am happy to engage with CP in the hope of a more intuitive and productive future for all, that may also fail but I am willing to invest the time. I find very few gaps in FH but I do not find it intuitive so there are many barriers which frustrate new trial users often resulting in them reverting to their previous platform, and that stunts FH growth. If any of my videos help a user embrace a buried possibility within FH then that is a win for both and so far comments have suggested that to be true.

Transcending the request for videos, which I believe are very valuable to visual learners, I believe the "Getting the most from Family Historian" publication should be PDF, so always fully up to date without the constraint of Print. It could still be sold as a digital download with a unique key for downloading updates as the software evolves therefore software development would not become an artificial barrier to going to print in the first place. Piracy, yes I hear it loud and clear and yes there would be some shares without purchase but ask this question, "What is every genealogist in the world had a copy of an eBook detailing the powers within Family Historian?" what do you believe that would do for sales and growth?

I'm just happy to achieve more research benefits within well thought out and intuitive software, I suppose that is a slightly selfish goal which helps motivate me, if I see a problem I am happy to report it. I prefer to do that visually as I find that approach the most successful at getting my point across. When I press Start in my car I expect it to start, I don't want a car where I need to complete a pre-flight check list for every time I want to nip to the shops.

Bottom line, there is no right and wrong way just methods which produce better results than others, some general shared goals we all benefit from and some particular to individuals needs. Again I am not writing a manuscript, I simply want the detail I need to point me back to where the data originated and I want the ability to enter that data as quickly as possible, I know your mileage may differ.

Jackson

[NickWalker]

FTR, I am a Lumper and a Book, Register or letter is a Source, the place it is stored is a Repository and the Details contained in that Source related to my data is a Citation and many Details may stem from the same Source so different Citations

So much of this is just semantics. You have a source for a letter ("Letter from Jo Bloggs 04/07/1803") and call yourself a lumper even though that is effectively what a splitter does. Others might have a single source for all the letters sent by a particular person ("Letters from Jo Bloggs") and I'd certainly agree that's an example of lumping. Others might decide to have a half-way house between those ("Letters from Jo Bloggs in 1803") and again this is an example of lumping. These are all sources and it makes no difference really as to which is used. These 3 ways of recording sources for a letter are the same as the decision to have "Census 1881 Warrington Jo Bloggs" as a source (Splitter), "England/Wales Census" (lumper), or "England/Wales Census 1881" (lumper).

The only reason that there is any debate between FH users about the splitter/lumper decision is to do with where any additional data regarding the citation is stored. Users wishing to provide any kind of transcription, or links to images will end up with data duplication if they 'lump' because of the way that GEDCOM (and therefore FH) stores the data. As a relational database 'expert' l hate the idea of data duplication which is why I usually 'split'.

[mjashby]

@Vyger,

Good to 'see' you here and am sure the offer of help will be accepted positively in FHUG.

Transcending the request for videos, which I believe are very valuable to visual learners, I believe the "Getting the most from Family Historian" publication should be PDF, so always fully up to date without the constraint of Print. It could still be sold as a digital download with a unique key for downloading updates as the software evolves therefore software development would not become an artificial barrier to going to print in the first place. Piracy, yes I hear it loud and clear and yes there would be some shares without purchase but ask this question, "What is every genealogist in the world had a copy of an eBook detailing the powers within Family Historian?" what do you believe that would do for sales and growth?

I don't disagree with desire for a 'PDF' user guide, but there relatively easy workarounds for those who want/need to be able to consult a Help feature which sits outside the FH program, as that can be easier to manage than an internal software help system, or having to use the online Help Pages in a Browser. however, some users seem to believe that the PDF/Hard Copy 'Manuals' that were available with previous versions of FH somehow provided more guidance not otherwise available, but, from the comparisons I've undertaken they were more or less identical in form and structure to the program Help File, already available within FH; and now also online.

Workaround: The help files in the FH7 Program installation, i.e. fh.chm and fh_plugins.chm can be displayed directly in any 'reader' software capable of handling .chm files (e.g. KchmViewer or SumatraPDF are the one's I'm most familiar with); and can also be imported by the electronic library/book management program 'Calibre' which can convert them to PDF, ePub or many other formats that can then be viewed on Computers/Tablets, or even printed. These three software options are all 'free to use' and, whilst it may not be as convenient as a direct PDF download from Calico Pie, they are not at all difficult to install/use.

Mervyn

[Vyger]

Users wishing to provide any kind of transcription, or links to images will end up with data duplication if they 'lump' because of the way that GEDCOM (and therefore FH) stores the data. As a relational database 'expert' l hate the idea of data duplication which is why I usually 'split'.

Nick, I haven't counted the Gedcom lines and compared between splitting and lumping, it would be an interesting test. Each Source is detailed once in Gedcom so on the face of it Many Master Sources (splitting) equals many more Gedcom Lines. In the case of Lumping each Master Source would only be defined once so less lines, the Detail needs to be recorded in either case so moot in many ways, an interesting test for someone with time on their hands.

The letter was a really bad example but if there is only one letter then again the splitter/lumper argument is also moot. The previous point on data storage is the very principle behind relational databases, i.e. save storage space and increase efficiency, I have no idea how FH maximises those benefits. I would never suggest someone changes their ways but I have understood these personal choices were often made many years ago based on software in use and not always sound logic.

[tatewise]

The distinction that Nick is making between 'splitter' & 'lumper' and the data duplication only arises in particular scenarios.

1. Significant details are recorded such as a transcript in Text From Source &/or linked Media images.
2. Identical citations linked to multiple facts derived from the same source.

Those criteria are discussed in FHUG KB Citing Sources: Method 1 and Method 2.

In the FH/GEDCOM data model consider the 'splitter' & 'lumper' lines needed to hold a transcript of say 10 lines of text.
With only one Citation both 'splitter' & 'lumper' only need 10 lines of GEDCOM in the Source record for a 'splitter' or in the Citation for a 'lumper'.
With five facts each needing a Citation a 'splitter' still only needs 10 lines of GEDCOM in the Source record.
However, for a 'lumper' each Citation duplicates the transcript so needs 5 x 10 = 50 lines of GEDCOM.

Conversely, if there is no transcript then the number of Source records is the governing fact for the number of lines.
Assume a Source record needs 3 lines of GEDCOM.
For a 'splitter' needing 10 Source records with one Citation each that results in 10 x 3 = 30 lines of GEDCOM.
For a 'lumper' only one Source record is needed with 10 Citations and thus needs only 3 lines of GEDCOM.

So it is not users that are 'splitters' & 'lumpers' but the nature of the Source Citation details.
So some Source Citations such as Census records typically need fewer GEDCOM lines if 'split'.
Whereas, Source Citations for GRO Index records usually need fewer GEDCOM lines if 'lumped'.

Other products often do not follow the GEDCOM model and the same Citation database entity can be linked to multiple facts, so the duplication does not arise and the distinction between 'splitter' & 'lumper' has no impact on database size.

[TimpsonsLane]

I have been building my tree for 60 years, and belatedly I need to add all the sources and citations so that I can leave something worthwhile. I would welcome a straightforward video, and soon!

[Mark1834]

It’s got nothing to do with database size. IMO, the determining factor is the number of distinct facts that the citation supports. A census supports multiple facts, so if lumped, very significant data duplication occurs, with significant risk of corruption if modified. A GRO index entry is commonly lumped, but as it usually supports only one or two facts, the duplication is manageable.

I’m completely with Nick on this one - data duplication and potential corruption is far more important than database size to anybody who has worked in database design and management.

We’re getting off topic, but I couldn’t leave that uncommented...

[davidf]

Data duplication (on the citation) is only an issue because the current structure does not recognise where we want to hold data and we all hold data in slight ly different ways and prioritise particular data differently.

I might take a source as "1851 England and Wales Census (Ancestry)" and want to hold information specific to that entity (Date of Census, missing schedules, the fact that images for a particular area may be better on the FMP version, browsing history - yes I have paged through whole Enumeration Districts! - "Looked for Blaylock in Carlisle April 2015, repeated for Blacklock May 2017"). A note on the source is the logical place if I am a lumper. If I am a splitter I have the potential duplication issue - writ large. Unless I put such information on a shared note and remember to attach that note to all relevant split sources - or just remember the note is there?

A census citation attached to an individual would "logically" only contain information relevant to that individual.

• Is that the schedule line (in which case there is no duplication - and you just paste the relevant individual bit of an Ancestry of FMP transcription (before checking it))
• Or do you want to show the individual in the context of the household or even the neighbourhood? Even a splitter might end up duplicating for a neighbourhood

At the moment I am putting household transcriptions on a shared note, attaching that note to the head of household census fact source citation (via the All tab - which is not ideal - result one foreign key) and then I copy and edit that census fact to the other members of the household, so they each hold the foreign key (to the shared note) thereby eliminating "entered data" duplication.

The problem is FH (and GEDCOM at root) has too flat a data structure - I think I want to see a "group at point in time" entity, being:

• a birth (attached to mother and child)
• a marriage party (attached to the members of a wedding party)
• a census household (attached to the members of that household, institution etc.)
• a school class (leavers of 1897)?
• a battalion at a particular battle?
• etc.

Then media and transcripts of that media are logically attached to the "group in time" - as are lumped sources

Links or attachments are fine from a database management perspective and by helping normalising data it avoids duplication and ensures subsequent legitimate edits (e.g. to a 1939 Register Household as data is un-redacted) don't introduce data corruption.

But that won't happen, so we all have to compromise to find ways to handle ultimately the limitations of GEDCOM.