Another Middlesex parish batch with no indication of record type
It looks like others are having some trouble with these older records with no indication of what kind of record they are. Could you take a look at this one? UK, England, Middlesex—Parish Registers, 1539–1988 [Part B][MSPD-TMM]. There is no heading on earlier pages except for Month and year, but a few pages later, the heading is Burials. Do I assume they are baptism records or burial records?
Thank you.
Best Answers
-
Hello Heather,
Yes, Melissa is correct, these are burial records and they should be indexed as such.
Thank you, for helping to index these records accurately.
0 -
So since this thread has been hijacked, with apologies, I want to make sure that @HeatherNelson3 has the correct answer to her question since it is also buried in all of this stuff.
THESE RECORDS ARE BURIALS and SHOULD be indexed as BURIAL/DEATH RECORDS. Heather, if you accept this as an answer to your question, it will post right underneath your post which may be helpful to others.
1
Answers
-
Dear Heather,
These are baptismal records. Thank you for your diligence in indexing these difficult to read records.
1 -
I would hold on to this batch for a minute. It could be a burial since "a few pages later the heading is Burials".
0 -
Would it not be advisable/ whenever possible that record type be assigned to pages by Project Admin and then allow Indexers to change record type in those rare circumstances where batches include multiple record types?
Advantage: The field is set accurately by Project Administration but remains flexible for the Indexer.
Disadvantage: higher administrative overhead.
0 -
genthusiast, Some projects are set so that they can have multiple types of documents in the same batch so yes that is sometimes necessary.
0 -
@EVHLHM I understood that to be the case - but my reply was to question whether the default record type for pages 1-40 could be entered as x and pages 41-200 as a different type by a project administrator for ease of indexing? Of course leave the field editable and available for other record types because I have run across those too - but in my experience generally the record type doesn't change too much on a batch. So the indexer would already know this batch/image is baptism, marriage, or death record type but keep an eye open for others to add in. Essentially this would mean separating a batch into multiple passes - one by Project admins to do what they want to help set it up for Indexers, another pass for Indexers, then on to the Review pass(es). I'm just wondering why it's not done that way and only pass it directly to the Indexer. Is there no Project Administration/setup pass?
0 -
If you would like to suggest this in the Ideas section of Communities you are welcome to do so. FamilySearch always welcomes input from it's guests.
0 -
I think it would be a major waste of time to go through hundreds of thousands of images just to enter the entry type. Indexers should able to identity the documents. The 1st clue on this one was that i was a burial was "a few pages later the heading is Burial". The 2nd clue was that baptisms are more detailed, with at least the gender and the father. Marriages have two parties. If they are unsure, they should Return the batch for someone else to pick up. Looking at the entire collection and finding the image will also provide the answers. It took me about 5 minutes to figure out it was a record of burials.
0 -
@Melissa S Himes Hmm, so it would be a major waste of time to enter one field? That sounds familiar. I guess I'll just have to agree to disagree. It would be majorly simple if they were all the same record type and from what @Cecilia Espinoza de Montoya CHF SAS said here many Project Instructions state to ONLY index the record type indicated. So especially for those projects it would be majorly simple to enter that record type for all the records in the batch before it got to the Indexer.
@EVHLHM I am just pointing out what could be done. Ideas ... 😣 It seems like it's a common enough issue that could be resolved proactively through another indexing pass - an administrative/setup pass - that would remove it from being a problem for the Indexer.
0 -
Please post your suggestion in Ideas for Indexing.
Enter the title of your suggestion followed by a detailed explanation of your suggestion/idea.
Thank you.
0 -
@Mirevo Wow, thanks for ganging up on me guys and gals. I feel like you don't want my contribution here. Just a bunch of moderators protecting each other - circle the wagons...
I know how to enter ideas and do so regularly...
Thanks
0 -
We were simply making a suggestion as to where you could post your idea that others could see and respond. It is a good place so techs can see ideas easily as well. Since you already post there then that is great.
0 -
@genthusiast 1, I am not a moderator, not a church member, and have no need to get or offer protection. But, you are comparing apples to oranges in the comment addressed to me. Think of it this way, an image on a parish record could have 5 christenings, 4 marriage banns, and a funeral all conducted on the same day. Someone would physically have to read each image and enter 10 entry types just to make it easy for an indexer to fill in the blanks. Cecilia was simply pointing in answer to that post that generally, we do not create a second baptismal record when the entry was a marriage.
I've reviewed in excess of 250,000 entries and maybe 15 were recorded on the wrong entry form. It simply isn't a big deal for most collections. This set of old parish records has been particularly tough and probably should have been considered an Advanced project.
1 -
@EVHLHM Part B is Intermediate. This batch was from Part B.
1 -
@Melissa S Himes That's amazing! thank you for your Reviewing contribution! I am really not comparing anything. I'm just stating a way to resolve the question is to have another pass on the image prior to the Indexer receiving it. You state from your amazing amount of reviews a batch containing multiple record types is not common - am I understanding you correctly? So entering the record type then as a default entry prior to Indexers receiving it would be majorly simple. Am I aware that this is an idea - yes. Am I aware that is an idea you don't like - yes. But I like it because it resolves the concern plus allows the Project Owner to indicate what record type and fields they want indexed. You are right - that would be an increased administrative load on the Project. Maybe it wouldn't need to be an administrator doing a record type index pass - and those passes could be majorly simple as i expressed before. Enter the default type, etc, etc. anyway ... ideas ... 😣 Additionally I like the idea of having a setup pass where the indexer is instructed to count the number of records and adjust appropriately from the default amount the project contains. Anything to help setup the Project and make entry for the Indexer easier goes a long way in my opinion. It would just take implementing that type of system.
Ok, so here I will try to be persuasive... I believe in the power of crowdsourced indexing. I believe that power could be increased by allowing single field entries from users all over the world - an idea I have posted in ideas. Can you imagine if people in their spare time chose to enter 1 entry rather than index an entire batch with multiple fields - it just takes a lot longer to index an entire batch. Some people don't have that time to dedicate to indexing - but they can do 1 field, 10 fields - x fields in a day. Would that help if that were the way indexing were setup? I believe yes - you believe no - we each believe what we believe. I have suggested the idea....
As the system is setup currently this idea is not an appealing option for most indexers - the user has to download an entire batch index x fields and return the batch - I don't know too many people - wanting to index fewer fields than a batch that would want to index that way. I am just stating that I believe indexing could have many more Indexers/Reviewers doing contributions smaller than an entire batch. Would it be worth it to setup the indexing system to do it that way? Probably not unless it were easy to change the system - but I'm not a web app programmer and don't know if it would be easy to do or not - still I believe in the idea.
It appears from the following graphic that column entry could be setup for the types of passes I am suggesting - so maybe it's not so far fetched afterall (it just might take the capability of locking other entry columns - personally I don't care if it's vertical or horizontal as long as other columns or form fields were locked for these types of passes):
0 -
You are correct @genthusiast 1 . I am saying that it is rare that indexer chooses the incorrect entry type. It is also time consuming to ask an indexer to count the number of records before beginning a project. I can say without a doubt that if I had to do that, indexing would be over for me. There are already enough burdensome steps. Heck, in the beta test, a few of us complained about the confetti when a batch is completed. So, I am not too worried that many changes will be made since the confetti still falls. LOL
There is a project that is similar to what you are describing currently being indexed on Zooniverse: HMS NHS: The Nautical Health Service - Transcribing a hundred years of seafarer's medical data from the Dreadnought Seamen's Hospital in Greenwich, 1826-1930.
I've been working on it on and off. It is kind of fun to only index one column of the records when I'm tired or have a quick minute. You might find the stats interesting.
0 -
@Melissa S Himes Whether hijacked or not [yes i know what thread hijacking is and I don't believe that is what I have done. I am suggesting an alternative proactive indexing approach that could be done in the current indexing application that addresses the question being asked AND referencing another idea for a different indexing system that I have already suggested in Ideas. Hijacking bad - alternative approaches and ideas good.] it appears we are more in agreement than I think you believe. I am not saying record Indexers should have to index only one field/column. I am saying in the Project there could be multiple indexing 'passes' some of which could be preparatory for the Indexer who indexes the record. Record type pass, count and adjust the amount of records type pass, those who didn't want to participate in these types of passes wouldn't have to - they just might be surprised when they open the batch that the record type is already there and the number of records is 'close' to accurate rather than a project default.
I regularly count up the number of records and adjust the record count/lines. I find that this typically allows me to duplicate the record type field and other <BLANK> fields efficiently. Then if I need to change something as I go along I can do so - otherwise the field is done.
0 -
If a person wants to do one entry at a time they can do it any time. Do an entry and send it back. Next person does what they want, usually all the entries. We have always had that option.
0
