Putting families together
Since the whole aim of indexing is to put families together, the instructions sometimes are confusing to indexers. They say not to take names from others in the entry, that should be the sponsors, etc. not the family members. A child at a baptism should be given the name of the father, and or mother in some cases. In all the Irish records now being indexed, many indexers are only putting the child's first name. In some cases only a fragment of a name is given, like, Michl. To just put Michl down is of no help to those who will be searching for this child, unless it has a surname attached to it. Can't the instructions be rewritten to make sure this occurs?
Ann Somerville
Comments
-
The whole aim of indexing has nothing to do with putting families together. The aim of indexing is to help people find records.
If the name is abbreviated as Michl, we can guess that the person was probably called Michael -- unless that thing we're reading as M is actually an N and he was called Nicholas. It is not the indexer's task to resolve such questions. We index what we see, and leave the research to the people using the index.
Ditto for filling in surnames that aren't recorded: yes, most children got their father's surnames -- except when they didn't. Most indexing projects make it explicit in their instructions that if the record does not specify a person's surname, then no surname should be indexed for that person.
Yes, there is a mismatch between indexing instructions and the search algorithm's behavior, but the way to solve that is not to corrupt hundreds of thousands of index entries with guesses, but to ask FS engineers to fix the algorithm -- and in the meantime, to work around this known shortcoming by adjusting our search inputs: leave the main surname blank, and use the "Father" and "Mother" search fields.
2 -
The aim of indexing is to help people find records.
Which then allows the indexer to take off their indexing hat, put on their researcher hat - and then attach the record to a Tree profile - which 'puts families together'. Or if you prefer AI - seed/fruit (whichever) - the Tree with profiles/Record Hints built from records. Either way - you are correct - records (and thus their indexes) contain relational data which can be extracted or linked to Tree profiles.
There are a couple ways of looking at the abbreviated name problem:
1. If the name abbreviation contains a superscript final letter (Mich^l) - then in my opinion - the indexer could enter Mich*l - which would find results if a researcher input Mich[anything]l in their Search parameters.
2. FamilySearch does handle common name variants when returning Search results. Michael for Michl is probably one of these (but you'll probably get Michelle too - though I can't recall ever seeing that name in Irish records - so if you think it's a male name - add the Sex filter in your search).
As mentioned - it would be best to get direction from FamilySearch for how they would like such to be handled. To date I have not seen such direction - which to my interpretation - means the indexer can decide 'how they best interpret' the indexing instructions.
On the problem of no Surname being indexed:
As mentioned - indexing instructions may specifically request that a surname not be entered/supposed - when not specifically entered on the original record/image copy. Other prior indexes of Irish parish registers likely do contain a surname - even when the record does not specifically record it (their indexing rules probably included common surname inheritance). This could mean FamilySearch's index will be an industry cooperative effort (to compare indexes). In my limited experience - Irish children without a surname listed on the record - will typically have/inherit the surname of the father - unless the record lists them as illegitimate.
Also to look forward to - the AI index/review index (this should produce yet another index which could be compared). Also to look forward to - the 'edit every field' solution - for post-publication editing of indexes - this produces a 'practically complete' transcription of the record - including relationships for witnesses/godparents and even the priest performing the christening/baptism (which was typically the same name for a large number of parishioners during a particular time period). This means that in the future these opportunities should provide 'richer'/more complete searchable transcripts of records rather than only the typical indexes of the past generation. I have no idea how this will affect indexing batches - but would expect indexers to become reviewers/transcribers of AI produced indexes (the computers are becoming quite good - except when they don't - and of course are faster at producing indexes).
0 -
Firstly, as many indexers are not members of the LDS Church (and, I believe, the majority of Family Tree users are not, either) many reading this will not be able to relate to the statement, "... the whole aim of indexing is to put families together". I look upon the process as being a way to find individuals, although maybe I am being a little pedantic, as naturally I will try to link them to their family branches.
On the issue of what "Michl" represents, it is probably an abbreviation of "Micheal" - not "Michael", unless the family anglicised the name.
Finally, on the point of only adding a surname to the father, I'm afraid I cannot agree with the name not being added to the child, too, in instances that it is practically certain that the child was known by his father's name. The current FamilySearch "rule" of indexing "exactly" what is recorded is very unhelpful for researchers, as 9 out of 10, I bet, would (at least initially) conduct their searches by inputting the surname against the child. It is not made clear in guidelines that one often needs to carry out two searches in order to trace the children of a given set of parents. I have never had any problems in locating children's baptisms, on any other website, by using the name solely against the child, so do find this FamilySearch practice rather unhelpful in helping its researchers find individuals - which, to me, is the prime purpose of indexed records.
2 -
Finally, on the point of only adding a surname to the father, I'm afraid I cannot agree with the name not being added to the child, too,
Totally agree @Paul W . The point is surely that (in my experience) the vast majority of baptisms & christenings are already indexed with the father's surname against the child as well, even though the child has no surname on the page. That is what people are used to. To suddenly take an opposite view is, in my view, confusing, self-defeating, contrary to historical practices, and simply out of step with the rest of the providers.
Further, the omission of the surname from the bit relating to the child was intentional. It was understood that the child would be given the father's surname. Are we telling our ancestors that they didn't know what they were doing?
It gets worse. If you look at the (Civil Registration) Birth Indexes for England & Wales, they include the name of the father against the child. But if you look at the certificate that is being indexed, there is no surname assigned to the child until 1969 - the certificate only has the given names of the child and the full names of the parents. The entry is indexed from the parental surname(s). If we are to omit a child's surname from their baptism, should we go through and remove the surname from their Birth Indexes for England & Wales pre-1969 to be consistent? Should we, as researchers, remove the surname from our tree because there's no direct evidence?
None of this denies that there are potential issues with the child's surname in baptisms - if the child is recorded as "John son of Thomas Smith and Mary Jones", when the rest of the page has names of the form "John son of Thomas and Mary Smith", then it's a sure bet that the child is illegitimate - or, of course, their father's full name is "Thomas Smith Jones" (it happens). Then, you have to look at the image and think about it.
1 -
It shouldn't be hard for the search algorithm to include parents' last names when searching for a record. It might already do so.
But naming conventions vary wildly from place to place, and over time. If the last name of the child isn't included in the record, it should not be in the index. The indexer may not be familiar with the naming conventions for the area, and should not be expected to infer information that is not included on the record.
When the last name of the child is not included in the record, the clerk entering that record considered the name obvious from the rest of the record. But what the clerk considered obvious is not necessarily what we, today, of European culture, would assume. Even in European areas, the convention was NOT always the father's name. Listing the last name of the mother did NOT always indicate illegitimate. The index must list the names as entered on the record.
0 -
I believe part of the issue here may result from the format used especially in older Irish baptismal registers. The surname of the father is often not specifically recorded. The format was basically -
John Smith son of John [surname of father implied but not stated] and Mary Jones
One of the earlier indexing efforts of the Irish registers undertaken by another genealogy provider failed to recognize that format. The result was that the father was given the mother's maiden surname in the search parameters.
0 -
As mentioned - Mich*l would include Michael, Micheal, Michail ... Mich[anything]l. Mick would/should also probably be included in the Search results... In comparison Nick/Nicholas is not a very common Irish name in my experience.
0 -
I seem to recall that FS's search algorithm used to include matches to the parents' names when the index didn't have a surname for the child. This was almost certainly true back in the days when IGI/Genealogies matches were listed below the regular results. I think the current strict behavior, where inputting anything for the surname excludes half the database, is newish -- perhaps folded in with all of the various changes when the new search interface was launched.
When an indexing project's instructions call for leaving the surname blank if it's not explicitly recorded, this does not necessarily mean that the final index will have all surnameless children: the post-processing often includes automated population of one field based on another. Such processes are unfortunately often misguided (such as whatever it is that's making all of the recently-indexed Hungarian civil marriage registrations look consanguinous), and I don't think they're a good solution to the disconnect between indexing and searching, but they can be a stopgap.
Paul's point about Michael versus Micheal nicely illustrates why indexers should not expand even the most "obvious" abbreviations. (The house I grew up in is on Michael Drive, so Micheal never even occurred to me.) The search algorithms recognize some of the more common abbreviations, anyway.
To Áine's comment about those misinterpreted Irish records: Hungarian records sometimes skip the father's surname like that, but it's quite clear what goes where when the surname is first: Kovács János, son of János and Szabó Mária. I just have to be careful when translating such a record, because if I don't repeat the surname (in brackets), people inevitably misinterpret it: "why is the son's surname different from his parents?"
3 -
As mentioned - the 'edit every field' solution can resolve many of these issues - if/when it is implemented on these collections (in the future) - and IFF contributors are careful.
0 -
Sorry for drifting off the original topic, but just wanted to provide examples of what you would miss by inputting "John Smith" as the child's name, as opposed to entering "John" - father's name shown as "John Smith" in both searches:
In the first case there are 11 results (see https://www.familysearch.org/search/record/results?count=20&q.birthLikeDate.from=1829&q.birthLikeDate.to=1829&q.birthLikePlace=middlesex&q.birthLikePlace.exact=on&q.fatherGivenName=john&q.fatherGivenName.exact=on&q.fatherSurname=smith&q.fatherSurname.exact=on&q.givenName=john&q.givenName.exact=on&q.surname=smith)
Extract of page:
In the second, 13 will be presented (see https://www.familysearch.org/search/record/results?count=20&q.birthLikeDate.from=1829&q.birthLikeDate.to=1829&q.birthLikePlace=middlesex&q.birthLikePlace.exact=on&q.fatherGivenName=john&q.fatherGivenName.exact=on&q.fatherSurname=smith&q.fatherSurname.exact=on&q.givenName=john&q.givenName.exact=on
Extract of page (note the "John" that would be missed if I searched for him as "John Smith"):
Sorry haven't reduced enough to show the whole of the pages, but using URLs provided will illustrate fully.
1 -
If the last name of the child isn't included in the record, it should not be in the index.
But there are millions (and for once, I don't think I'm exaggerating) of indexes where the family name of the child is not in the original but is in the index. However, "correct" its omission is, it really is standing in the face of the oncoming storm to attempt to do otherwise.
The indexer may not be familiar with the naming conventions for the area, and should not be expected to infer information that is not included on the record.
There are two aspects to this. Firstly, as @Julia Szent-Györgyi mentions "the post-processing often includes automated population of one field based on another". I wouldn't have any major objection to the indexer leaving the child's family name empty and having it populated automatically. (Well, the automatic population will get it wrong sometimes so will be inferior to an informed human). Secondly, if the indexer is not familiar with the naming conventions for the area, why are they being allowed to index data that inevitably needs interpretation? They might need to acquire that knowledge by reading project instructions that document the naming conventions and by also having access to subject-area experts to cover the inevitable holes in the instructions. But they must not be set adrift to interpret foreign language words as names, e.g., or to misunderstand what's being presented.
1 -
Years ago there was a huge batch of Norwegian parish registers that were indexed. The registers only had the child's first name with no last name. So the indexing process added the father's surname.
Every single child's last name was wrong!
It took about 20 years or more, but they finally took off all the surnames for the children so now the index has only the children's first name again.
The problem? They turned, for example, Hans who was the son of Ole Jonsson, into Hans Jonsson making it impossible to find him because he was never, ever, Hans Jonsson. He was Hans Olsson.
Please continue to have indexing only include just what is the record and not make up extra information.
3 -
Mich*l would include Michael, Micheal, Michail ... Mich[anything]l
There are two ways to accomodate name variants.
Wildcards are one method but are unsatisfactory in that they require action from the screen's user. Nonetheless, they may be the only possible way forward.
Many genealogical database searches use tables of variant names so a search on "John" will also accept index entries for "Jno" (e.g.). This also allows things like "Jos" to appear as a variant for both "Josiah" and "Joseph". I think FS has some sort of name variant matching - therefore there shouldn't be any need to expand "Jos" to, err....
0 -
The problem? They turned, for example, Hans who was the son of Ole Jonsson, into Hans Jonsson making it impossible to find him because he was never, ever, Hans Jonsson. He was Hans Olsson.
But surely the point there is that the indexing instructions should have said "Scandinavia - patronymics? What do we do?" With the decision to ...
Whereas the instructions for a baptismal register for England & Wales can follow decades of precedent and include the father's family name as the child's family name (except where....)
Because no, I really don't trust the FS search routines to deal with looking in the father's family name where the child doesn't have an indexed family name - especially when that's just as bad a solution for patronymic searching as making one up.
1 -
If you read Adrian's comments carefully you will see he is asking for the customs and practices of various countries / cultures to be taken into account. Hence, anyone experienced in dealing with Norwegian parish registers would never have made this mistake. Likewise, in dealing with English records it would be correct in 99% of cases to assume John, the son of John and Mary Smith, shared the same surname.
Adrian also provides the excellent example of English birth registrations. My own birth certificate shows my name as "Paul" - no surname - but I am rightly indexed on the GRO website, as well as FreeBMD and FamilySearch as "Paul Wrightson".
As I have argued before, it is just plain silly to index "John, son of John Smith" (one one page) as "John", but (when found on the next page of the same register) to index "William Smith, son of John", as "William Smith". No wonder FamilySearch users are missing siblings baptisms when their names are being indexed in a totally different manner just because the clerk decided to change his recording format between years!
As illustrated, even FamilySearch does not present records in a consistent manner and their methods (indexing or post-indexing) do not seem to comply with the accepted practice of other websites whose indexed baptisms I encounter.
Everybody seems to agree here that indexes should act as a finding aid, but FamilySearch's strict adherence to "only record exactly what is written" has not been helpful to me on many occasions (say where I have missed a child or two in a family of six). It is really so sad that common sense plays no part in project instructions. I even read advice that the "last day of February" should never be indexed as "28 February", even when the year was clearly not a leap year. I assume the same goes when "Lady day" is recorded in an old English register, instead of "25 March". If there is any serious doubt, of course don't make assumptions - otherwise, please don't continue to be so pedantic, "FamilySearch" - it's making some individuals far more difficult to find than need be.
2 -
Yes, he and I were writing at the same time. So I was making a general comment, not commenting on any thing he wrote. I would hope that the instructions can be tailored to be more specific for each situation.
1 -
As an aside, if "Index exactly what's written and no more" is creating a pedantic mindset that's unhelpful to research in many (but not all) cultures, is it any wonder if people dealing with the 1940 US Census want to enter the exact text "Same House" as a residence for 1935 on the person's profile in FamilyTree , instead of the text of the actual address? Just to be clear, I do think that the text "Same House" should appear in the "index" as it's often very difficult to decide what the actual address should be for the indexer.
1 -
if the indexer is not familiar with the naming conventions for the area, why are they being allowed to index data that inevitably needs interpretation?Records sometimes cover areas that have different conventions within it. Many record sets cover the entire country of Germany, but a section of Germany used the Hof naming system, instead of strictly patronymic. Since the Hof naming system is no longer in use, there is no reason for most modern Germans to understand it.
The record should be indexed as written. The search algorithm can be written to allow for assumptions.
0 -
Since the Hof naming system is no longer in use, there is no reason for most modern Germans to understand it.
The record should be indexed as written. The search algorithm can be written to allow for assumptions.
I think that shifting the interpretation into the search algorithm carries the risk of simply transferring the problem without approaching a solution. If the people creating the indexing project rules don't understand what they are indexing sufficiently well to interpret the resultant names, then why should we expect the software designers to have the required understanding? They will be IT people who need to be told the requirements. Who will tell them those requirements?
I find it difficult to expect all that knowledge to be available in one place to the FamilySearch software designers - I would have thought it more likely to be available separately across the globe where it can be accessed by people creating indexing projects.
Indexing what's written without understanding it, carries the risk of interpreting words as names, when they are nothing of the sort. IIRC, there are or were instances of children being indexed with a name that was actually the word for stillborn in the relevant language. No amount of software algorithm will overcome that basic issue. It has to be tackled at the start by people with the required understanding.
1 -
There are probably at least two ways to proceed with indexing - with understanding of the records being indexed or without (meaning index what you see). Since it is obvious FamilySearch has instructed the later - this method implies the index is only meant as a finding aid and that understanding of the record is left to the researcher. Of course - as mentioned - this chosen path may limit finding of the record. I guess it is hoped that subsequent AI and 'index every field' solutions may resolve these situations. Eventually the closer to a transcription the index - the easier it should be for the researcher (understanding the records) to locate them.
...there shouldn't be any need to expand "Jos" to, err....
If there is an abbreviation - a wildcard is not an expansion - only an indication of letters than were left out.
1 -
The search algorithm needs something to search for. If the child's last name is not recorded, a search for 'Johann' will not be very useful.
The search algorithm is being used here, in this time. A reasonable assumption for this place and time would be for the search algorithm to use the parents' last name. That may or may not be correct, but it does not change any actual records, just the method of searching. The person doing the searching should have an understanding of how the search works. The child may not have the same name as the parents, but it would be reasonable for someone to search for that name, as well as the correct name.
When I am searching for someone, I search on the correct name, as a child of the father, and as a child of the mother. One of those usually finds whatever name the child was recorded. Searching as the child of the mother also finds many children recorded with strange, mangled names, that are also part of the family.
1 -
There is a level of basic understanding of the language and culture that should be required of indexers, but demonstrably is not: there are indeed many, many examples where "stillborn" or "father unknown" were indexed as names, and my personal store of "favorites" includes things like the word for "Reverend" completely misread and turned into a new Fitz- surname, and one where the father's occupation and religion were turned into a mother's name. This kind of fundamental unsuitability to the task cannot be fixed by search algorithms or indexing project instructions; I think it is the price we pay for using volunteer indexers rather than professionals.
There is an intermediate level of lack-of-understanding that perhaps could be addressed by a change in process, and farm names are a prime example. They require the indexer to understand the naming culture well enough to determine whether the name-like-thing is part of a person's name, or just an address. The volunteer also needs to understand the indexing project's structure and instructions well enough to know where to put a farm name. A random page plucked from a random register is not going to teach the indexer either of these things, and even someone familiar with the concept may have a hard time determining which way to go with the particular clerk's notational habits -- and researching the question will be not only difficult, but also of limited applicability, because the next batch the indexing process serves up will likely be from a different clerk in a different register.
Other organizations that do volunteer-based indexing solve this intermediate problem by assigning much larger batches than FS does. It is well worth the indexer's time and effort to research the particular clerk's habits and learn about the neighborhood of the particular church, because he'll be doing all of the indexing for that entire register. I'm not sure how such a setup could be implemented on FS.
Absent such fundamental reorganization of indexing, we're forced to deal with the database we have using the search tools available. Knowing that the indexer was given scant information and little or no opportunity to become familiar with the material, we have to acquire that information and familiarity ourselves. For example, if we notice that baptisms were recorded as "X, son/daughter of Y Z and M, P", and that nearly every entry has either P or Q in that last position, we can figure out that it's the family's residence, not the mother's surname. If we then see that the indexers often put the P or Q as the mother's name, and we're looking for a family from P, we can do a search with P in the mother's surname field, and/or evaluate the search results knowing that none of the mother's surnames are actually surnames.
Seeing the "X, son of Y Z" structure, and knowing the current search algorithm's quirks, we'll know to do a search with the primary surname field left blank -- but this is one problem that could be solved by a revision to the algorithm. An index entry for child = X, father = Y Z should be at least a tentative match to a search for either X Y or X Z.
2 -
Although paid indexers also get it quite wrong. An example that annoys me every time I see it comes from handwritten indexes of Irish church records. The helpful compiler put "féach" - the equivalent of "cf." or "see also" on a cross-reference list.
It has been indexed on another website variously as a surname and as a placename.
1 -
In the batch of Hungarian civil registration indexes that was just released this week (which painted my fan chart a nearly solid blue again), I came upon an illustration of why indexing shouldn't fill in surnames that aren't actually in the record.
The hinting system brought up a record on my grandmother's profile for a "Paulovkin Erzsébet Gizella". I'm like, who the ::ehem:: is Paulovkin Erzsébet Gizella, and why does the algorithm think she's relevant to my grandmother?
Oh. Right. Her parents got married when she was a year old. But she was retroactively legitimized by that marriage, so she never actually had the surname Paulovkin. That's what the first addendum reference in the remarks column refers to -- but of course the indexer (whether human or computer) couldn't know that.
Which is why the index should have left her surname blank.
1 -
I can accept there are going to be issues like yours, but have already stated that project instructions can, and should, take into account the customs and practices at different times and different countries.
My main argument agrees with the idea you have expressed on several occasions (and I and many other genealogists would agree with) that indexes should act as a finding aid. So, okay, in this instance indexing without the surname against her name would have been the better option. But what about those 99% of cases I encounter in parish parishes where the format, "John, son of William Smith" will always mean "John" was known as "John Smith" throughout his life. Of course there will always be exceptions - even when using the "finding aid" argument.
Hence my "John Wall" who was baptised to "John" and Elizabeth (maiden name) "Harwood", but was known as "John Harwood" throughout his life, as the couple never married - John Wall appearing to have deserted his child and the mother. Obviously, the child did have to be indexed as "John Wall" here, but it took me about ten years to discover this baptism applied to John Harwood, in spite his name being correctly indexed.
(Note: column above "Harwood" headed "Maiden name" and pages out of alignment):
Incidentally, in this example, the father's name has been indexed incorrectly, as "John Wall", when it should have been indexed as simply "John", according to FamilySearch indexing instructions:
Maybe the above is not a good example of the issue in question, but shows indexing does not always prove to act as a useful finding aid, even when the child's name is indexed exactly as written.
Whilst I almost withdrew this example from my post - as it adds complications to what should be a perfectly straightforward issue (in how to index the child's and parents' names, in accordance to how they were actually recorded). So I have left the example here to show there is no "black and white" solution in the "indexing as a finding aid" and "indexing as written" arguments.
However, my conclusion remains the same: FamilySearch must at least make it far clearer that with its database, at least two searches are necessary to ensure names are not missed: one search based on the child having no last name - i.e., the last name being applied just to the parents - usually just the father) and one search using first and last name for the child, and just the first name(s) for the parent(s).
Find My Past, Ancestry and every other website I use (for genealogical research) appear to manage to get around this issue (possibly only by way of their post-indexing procedures), so why does FamilySearch make it so difficult to find baptisms of certain children of the same family, just because the clerk* recorded their names inconsistently?
*If only he had had a set of "project instructions" to hand when recording these names, showing him the child should always be recorded in a format that included its last name - for the sake of researchers living some two to three hundred years after the event!
0
