Hi Barrie, I'm fairly new to Syndicate Co-ordinating but it sounds like a sensible proposal to me. Mike (Ian Brooke syndicate) On 13 July 2010 08:42, FreeBMD Quality Assurance Coordinator < qa-coord@freebmd.org.uk> wrote: > Not long ago I enhanced the upload process so it checks if the > transcription (Sequenced files only) is for a quarter being done by a > syndicate the transcriber is a member of. If it is not a warning > <http://test.freebmd.org.uk:8084/error-help.html#BMDnotinsynd> is shown > asking the user to correct the error or contact their coordinator or > support, but the file _is_ uploaded. > > The purpose of this is to try to catch the error where the wrong quarter > is transcribed, an error that occurs fairly regularly. Sometimes the > transcription specifies the year/quarter/event corresponding to the > entries but sometimes the entries are right and the year/quarter/event > is wrong. > > I would like to change this to an _error_ rather than a warning because > > * with a warning the erroneous file is uploaded and incorrect > entries could get included in an update; with an error the file is > not uploaded > * experience shows that some users are just ignoring the warning > * it really is an error; something is wrong somewhere, even if it is > that the user has not been added to the syndicate > > Please note that transcriptions outside the syndicate > <http://www.freebmd.org.uk/vol_faq.html#5f> can still be uploaded if the > syndicate name is given as "Individual". So pages that have been > incorrectly transcribed can be uploaded and the effort is not wasted. > > I would welcome feedback from syndicate coordinators on this proposal. > > Barrie > FreeBMD Quality Assurance Coordinator > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message >

Happy for you to implement the proposal John -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of FreeBMD Quality Assurance Coordinator Sent: 13 July 2010 08:42 To: freebmd-syndicates@rootsweb.com Subject: Checking transcriptions Not long ago I enhanced the upload process so it checks if the transcription (Sequenced files only) is for a quarter being done by a syndicate the transcriber is a member of. If it is not a warning <http://test.freebmd.org.uk:8084/error-help.html#BMDnotinsynd> is shown asking the user to correct the error or contact their coordinator or support, but the file _is_ uploaded. The purpose of this is to try to catch the error where the wrong quarter is transcribed, an error that occurs fairly regularly. Sometimes the transcription specifies the year/quarter/event corresponding to the entries but sometimes the entries are right and the year/quarter/event is wrong. I would like to change this to an _error_ rather than a warning because * with a warning the erroneous file is uploaded and incorrect entries could get included in an update; with an error the file is not uploaded * experience shows that some users are just ignoring the warning * it really is an error; something is wrong somewhere, even if it is that the user has not been added to the syndicate Please note that transcriptions outside the syndicate <http://www.freebmd.org.uk/vol_faq.html#5f> can still be uploaded if the syndicate name is given as "Individual". So pages that have been incorrectly transcribed can be uploaded and the effort is not wasted. I would welcome feedback from syndicate coordinators on this proposal. Barrie FreeBMD Quality Assurance Coordinator ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hi Barrie, Sounds like a good idea to me. If we can avoid some files being included in the wrong event/year/quarter within the database that has got to be a good thing. It will mean a minor change in my administration procedures, as currently I do not add a new transcriber to the syndicate until after they have uploaded their first file. The reason for not adding transcribers sooner was that if they fail to upload any files, when Allan comes to delete their SubmitterID I would not need to remove them from the syndicate as they had not yet been made part of it. Even given this minor change to my systems I fully support your proposal. Best wishes Kevin. -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of FreeBMD Quality Assurance Coordinator Sent: Tuesday, July 13, 2010 8:42 AM To: freebmd-syndicates@rootsweb.com Subject: Checking transcriptions Not long ago I enhanced the upload process so it checks if the transcription (Sequenced files only) is for a quarter being done by a syndicate the transcriber is a member of. If it is not a warning <http://test.freebmd.org.uk:8084/error-help.html#BMDnotinsynd> is shown asking the user to correct the error or contact their coordinator or support, but the file _is_ uploaded. The purpose of this is to try to catch the error where the wrong quarter is transcribed, an error that occurs fairly regularly. Sometimes the transcription specifies the year/quarter/event corresponding to the entries but sometimes the entries are right and the year/quarter/event is wrong. I would like to change this to an _error_ rather than a warning because * with a warning the erroneous file is uploaded and incorrect entries could get included in an update; with an error the file is not uploaded * experience shows that some users are just ignoring the warning * it really is an error; something is wrong somewhere, even if it is that the user has not been added to the syndicate Please note that transcriptions outside the syndicate <http://www.freebmd.org.uk/vol_faq.html#5f> can still be uploaded if the syndicate name is given as "Individual". So pages that have been incorrectly transcribed can be uploaded and the effort is not wasted. I would welcome feedback from syndicate coordinators on this proposal. Barrie FreeBMD Quality Assurance Coordinator ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hi Barrie Scan2 would be happy for you to implement this as an error (not upload) (saves us work reversing the problem). Cheers Derek At 13/07/2010 03:42 AM, FreeBMD Quality Assurance Coordinator wrote: >Not long ago I enhanced the upload process so it checks if the >transcription (Sequenced files only) is for a quarter being done by a >syndicate the transcriber is a member of. If it is not a warning ><http://test.freebmd.org.uk:8084/error-help.html#BMDnotinsynd> is shown >asking the user to correct the error or contact their coordinator or >support, but the file _is_ uploaded. > >The purpose of this is to try to catch the error where the wrong quarter >is transcribed, an error that occurs fairly regularly. Sometimes the >transcription specifies the year/quarter/event corresponding to the >entries but sometimes the entries are right and the year/quarter/event >is wrong. > >I would like to change this to an _error_ rather than a warning because > > * with a warning the erroneous file is uploaded and incorrect > entries could get included in an update; with an error the file is > not uploaded > * experience shows that some users are just ignoring the warning > * it really is an error; something is wrong somewhere, even if it is > that the user has not been added to the syndicate > >Please note that transcriptions outside the syndicate ><http://www.freebmd.org.uk/vol_faq.html#5f> can still be uploaded if the >syndicate name is given as "Individual". So pages that have been >incorrectly transcribed can be uploaded and the effort is not wasted. > >I would welcome feedback from syndicate coordinators on this proposal. > >Barrie >FreeBMD Quality Assurance Coordinator > >------------------------------- >To unsubscribe from the list, please send an email to >FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >without the quotes in the subject and the body of the message Cheers Derek Derek C Hopkins, Phone +1(450)678-7768 6640, Biarritz, Fax +1(450)678-4252 Brossard, E-Mail derek.hopkins@sympatico.ca QC, Canada, J4Z-2A2. ==== FreeBMD - England and Wales - Birth - Marriage and Death Transcriptions <http://FreeBMD.rootsweb.com> ==== Check out FreeBMD Scan2 Syndicate page (revised daily) Please bookmark our new home http://www.scan2.ca/scan2.html ==== Check out QFHS Marriage Transcription Project page (revised daily) (Quebec Family History Society) Please bookmark our new home http://www.scan2.ca/qfhs.html Check out Abney Park Indexing Project (revised 14 MAR 2008, 195,000 names) <http://scan2.ca/nlisa .html> Check out the Quebec Family History web page <http://www.qfhs.ca/index.html>

Not long ago I enhanced the upload process so it checks if the transcription (Sequenced files only) is for a quarter being done by a syndicate the transcriber is a member of. If it is not a warning <http://test.freebmd.org.uk:8084/error-help.html#BMDnotinsynd> is shown asking the user to correct the error or contact their coordinator or support, but the file _is_ uploaded. The purpose of this is to try to catch the error where the wrong quarter is transcribed, an error that occurs fairly regularly. Sometimes the transcription specifies the year/quarter/event corresponding to the entries but sometimes the entries are right and the year/quarter/event is wrong. I would like to change this to an _error_ rather than a warning because * with a warning the erroneous file is uploaded and incorrect entries could get included in an update; with an error the file is not uploaded * experience shows that some users are just ignoring the warning * it really is an error; something is wrong somewhere, even if it is that the user has not been added to the syndicate Please note that transcriptions outside the syndicate <http://www.freebmd.org.uk/vol_faq.html#5f> can still be uploaded if the syndicate name is given as "Individual". So pages that have been incorrectly transcribed can be uploaded and the effort is not wasted. I would welcome feedback from syndicate coordinators on this proposal. Barrie FreeBMD Quality Assurance Coordinator

Yes, remembering will be a problem. At least the pages are in the second quarter which gives me more time to notice that 1870 deaths have been allocated for their second transcription. I wonder if Allan's "master spreadsheet" (if it exists) has space to include a "reminder note". Christopher Richards Barrie wrote: > It seems eminently sensible to avoid duplication; the only problem I > have is how we remember to notify the syndicate, when one is allocated, > that you have these files and need to be added to the syndicate! > > Barrie > > On 19:59, Christopher Richards wrote: > >> <div class="moz-text-flowed" style="font-family: -moz-fixed">At the >> beginning of the project I transcribed a number of pages from 1870 >> deaths 2nd quarter. They were pages 1-14 and 204,205. The latter two >> was because they included a surname I was interested in. The current >> "last modified" date is 2008 but they were originally done in about 2002. >> If I've understood you correctly they need to be flagged up as >> "individual transcriber". I see that no syndicate has yet been >> allocated to do the second transcription of that quarter. When it is >> I would be happy to join that syndicate so that my work doesn't have >> to be repeated. >> >> Christopher Richards >> >> Barrie wrote: >> >>> I have recently been analysing and reviewing transcriptions where >>> transcribers have uploaded files where they are _not_ members of the >>> syndicates transcribing the quarter. This can happen for a number of >>> reasons >>> >>> * The syndicate coordinator forgot to add the transcriber to their >>> syndicate when the transcriber first registered with FreeBMD >>> * The transcriber has done transcriptions for a syndicate without >>> being added to the syndicate (having been registered with another >>> syndicate) >>> * The transcriber is doing individual transcriptions >>> >>> Rather than ask coordinators to look at (yet another) listing I am >>> emailing coordinator individually identifying the users involved and >>> requesting that the users are added to their syndicate. >>> >>> This is not a particularly straightforward task because there are nearly >>> 1500 files involved so I am starting with the first category. I have >>> already sent out some emails to coordinators and more will follow. Where >>> there is an obvious (and significant) example from the second category I >>> have added that as well. >>> >>> It is important that we get the syndicate membership right so that >>> utilities like upload report and suspect files work correctly. It is >>> also important for coordinators so they can check the completeness of >>> their quarters. >>> >>> So, this is to alert coordinators that this exercise is taking place and >>> to ask your indulgence if you get multiple requests. At the moment the >>> list I have is rather overwhelming and I need this first pass so I can >>> get my mind round it! >>> >>> You may be wondering about the last category. I have only relatively >>> recently become aware that we have some transcribers who are working >>> outside of any syndicate (although they are members of one or more >>> syndicates) and we have introduced the concept of 'Individual' >>> transcribers (i.e. members of a notional syndicate called 'Individual') >>> to cover this situation. This is not something we encourage but we >>> equally don't disallow it. Transcriptions that fall into this category >>> are identified by having a syndicate name of 'Individual' in the file >>> header (i.e. in the first comment line). This category is also useful >>> for FreeBMD administration if, for some reason, we need to create a >>> transcription. At the moment it is mystery to me how Individual >>> transcribers choose what pages to transcribe but more research may >>> provide some illumination. >>> >>> Barrie >>> FreeBMD Quality Assurance Coordinator >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> without the quotes in the subject and the body of the message >>> >>> >> </div> >> > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message >

It seems eminently sensible to avoid duplication; the only problem I have is how we remember to notify the syndicate, when one is allocated, that you have these files and need to be added to the syndicate! Barrie On 19:59, Christopher Richards wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">At the > beginning of the project I transcribed a number of pages from 1870 > deaths 2nd quarter. They were pages 1-14 and 204,205. The latter two > was because they included a surname I was interested in. The current > "last modified" date is 2008 but they were originally done in about 2002. > If I've understood you correctly they need to be flagged up as > "individual transcriber". I see that no syndicate has yet been > allocated to do the second transcription of that quarter. When it is > I would be happy to join that syndicate so that my work doesn't have > to be repeated. > > Christopher Richards > > Barrie wrote: >> I have recently been analysing and reviewing transcriptions where >> transcribers have uploaded files where they are _not_ members of the >> syndicates transcribing the quarter. This can happen for a number of >> reasons >> >> * The syndicate coordinator forgot to add the transcriber to their >> syndicate when the transcriber first registered with FreeBMD >> * The transcriber has done transcriptions for a syndicate without >> being added to the syndicate (having been registered with another >> syndicate) >> * The transcriber is doing individual transcriptions >> >> Rather than ask coordinators to look at (yet another) listing I am >> emailing coordinator individually identifying the users involved and >> requesting that the users are added to their syndicate. >> >> This is not a particularly straightforward task because there are nearly >> 1500 files involved so I am starting with the first category. I have >> already sent out some emails to coordinators and more will follow. Where >> there is an obvious (and significant) example from the second category I >> have added that as well. >> >> It is important that we get the syndicate membership right so that >> utilities like upload report and suspect files work correctly. It is >> also important for coordinators so they can check the completeness of >> their quarters. >> >> So, this is to alert coordinators that this exercise is taking place and >> to ask your indulgence if you get multiple requests. At the moment the >> list I have is rather overwhelming and I need this first pass so I can >> get my mind round it! >> >> You may be wondering about the last category. I have only relatively >> recently become aware that we have some transcribers who are working >> outside of any syndicate (although they are members of one or more >> syndicates) and we have introduced the concept of 'Individual' >> transcribers (i.e. members of a notional syndicate called 'Individual') >> to cover this situation. This is not something we encourage but we >> equally don't disallow it. Transcriptions that fall into this category >> are identified by having a syndicate name of 'Individual' in the file >> header (i.e. in the first comment line). This category is also useful >> for FreeBMD administration if, for some reason, we need to create a >> transcription. At the moment it is mystery to me how Individual >> transcribers choose what pages to transcribe but more research may >> provide some illumination. >> >> Barrie >> FreeBMD Quality Assurance Coordinator >> >> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> without the quotes in the subject and the body of the message >> > > > </div> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

At the beginning of the project I transcribed a number of pages from 1870 deaths 2nd quarter. They were pages 1-14 and 204,205. The latter two was because they included a surname I was interested in. The current "last modified" date is 2008 but they were originally done in about 2002. If I've understood you correctly they need to be flagged up as "individual transcriber". I see that no syndicate has yet been allocated to do the second transcription of that quarter. When it is I would be happy to join that syndicate so that my work doesn't have to be repeated. Christopher Richards Barrie wrote: > I have recently been analysing and reviewing transcriptions where > transcribers have uploaded files where they are _not_ members of the > syndicates transcribing the quarter. This can happen for a number of reasons > > * The syndicate coordinator forgot to add the transcriber to their > syndicate when the transcriber first registered with FreeBMD > * The transcriber has done transcriptions for a syndicate without > being added to the syndicate (having been registered with another > syndicate) > * The transcriber is doing individual transcriptions > > Rather than ask coordinators to look at (yet another) listing I am > emailing coordinator individually identifying the users involved and > requesting that the users are added to their syndicate. > > This is not a particularly straightforward task because there are nearly > 1500 files involved so I am starting with the first category. I have > already sent out some emails to coordinators and more will follow. Where > there is an obvious (and significant) example from the second category I > have added that as well. > > It is important that we get the syndicate membership right so that > utilities like upload report and suspect files work correctly. It is > also important for coordinators so they can check the completeness of > their quarters. > > So, this is to alert coordinators that this exercise is taking place and > to ask your indulgence if you get multiple requests. At the moment the > list I have is rather overwhelming and I need this first pass so I can > get my mind round it! > > You may be wondering about the last category. I have only relatively > recently become aware that we have some transcribers who are working > outside of any syndicate (although they are members of one or more > syndicates) and we have introduced the concept of 'Individual' > transcribers (i.e. members of a notional syndicate called 'Individual') > to cover this situation. This is not something we encourage but we > equally don't disallow it. Transcriptions that fall into this category > are identified by having a syndicate name of 'Individual' in the file > header (i.e. in the first comment line). This category is also useful > for FreeBMD administration if, for some reason, we need to create a > transcription. At the moment it is mystery to me how Individual > transcribers choose what pages to transcribe but more research may > provide some illumination. > > Barrie > FreeBMD Quality Assurance Coordinator > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message >

I have recently been analysing and reviewing transcriptions where transcribers have uploaded files where they are _not_ members of the syndicates transcribing the quarter. This can happen for a number of reasons * The syndicate coordinator forgot to add the transcriber to their syndicate when the transcriber first registered with FreeBMD * The transcriber has done transcriptions for a syndicate without being added to the syndicate (having been registered with another syndicate) * The transcriber is doing individual transcriptions Rather than ask coordinators to look at (yet another) listing I am emailing coordinator individually identifying the users involved and requesting that the users are added to their syndicate. This is not a particularly straightforward task because there are nearly 1500 files involved so I am starting with the first category. I have already sent out some emails to coordinators and more will follow. Where there is an obvious (and significant) example from the second category I have added that as well. It is important that we get the syndicate membership right so that utilities like upload report and suspect files work correctly. It is also important for coordinators so they can check the completeness of their quarters. So, this is to alert coordinators that this exercise is taking place and to ask your indulgence if you get multiple requests. At the moment the list I have is rather overwhelming and I need this first pass so I can get my mind round it! You may be wondering about the last category. I have only relatively recently become aware that we have some transcribers who are working outside of any syndicate (although they are members of one or more syndicates) and we have introduced the concept of 'Individual' transcribers (i.e. members of a notional syndicate called 'Individual') to cover this situation. This is not something we encourage but we equally don't disallow it. Transcriptions that fall into this category are identified by having a syndicate name of 'Individual' in the file header (i.e. in the first comment line). This category is also useful for FreeBMD administration if, for some reason, we need to create a transcription. At the moment it is mystery to me how Individual transcribers choose what pages to transcribe but more research may provide some illumination. Barrie FreeBMD Quality Assurance Coordinator --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

Many thanks to all for the enlightening replies. From my days in the newspaper/magazine industry, I recall that odd number pages were on the right-hand side of a spread, and even numbers on the left - as they are in any book you read today. If by some chance the page numbering in the scan sequence is the reverse of this, then it would seem we are looking at two sheets of parchment, each written on two sides, which have been bound into the wrong GRO volume, 1839 September Deaths instead of June. That would explain the oddity (or eventy). Richard Oliver Madrid, Spain richol@arrakis.es ----- Original Message ----- From: "Allan Raymond" <allan_raymond@btinternet.com> To: <freebmd-syndicates@rootsweb.com> Sent: Tuesday, June 22, 2010 2:43 PM Subject: Re: "Suspect" file Martin You've just beat me to my response. There are no "Unknown" surname scans showing in the Sept Quarter and when I checked out scans 776 to 793 in the June quarter there is an obvious error in the alphabetical listing of the scans. As you mention it does look as if scans 776, 777, 782 and 783 belong possibly to the September quarter leaving scans 778, 779, 780 & 781 in the June quarter. I would suggest rather than depend on system entries to correct the problem with the scans we should approach the GRO to get a definitive answer and if necessary move and renumber the scans into their correct quarter and sequence. This will avoid future problems regarding this particular issue. Perhaps the link on the Suspect Page for reporting queries against compliant files should be made a little more bold? Allan Raymond ----- Original Message ----- From: Martin Cope To: freebmd-syndicates@rootsweb.com Sent: Tuesday, June 22, 2010 1:16 PM Subject: Re: "Suspect" file Hi Richard, This particular case was investigated by myself and Bob Phillips two or three years ago when it was possible to inspect the original books at the FRC. It appears to be due to a mis-assembly of the books at some time long ago. So the scans are in the 'correct' place. We did however add system entries so that the entries on scans 776, 777, 782 and 783 will appear when searching in the Sep 1839 quarter. The text at the top of the Suspect Files page says how you can get a compliant file such as your team member's removed from the list. I note that Croscan user Stargazer also has two files in a similar situation. best regards, Martin ----- Original Message ----- From: "Richard Oliver" <richol@arrakis.es> To: <freebmd-syndicates@rootsweb.com> Sent: Tuesday, June 22, 2010 11:57 AM Subject: "Suspect" file >I don't know whom to contact, so please excuse my posting this query on the >list. > > One of my team is most indignant that I pointed out his having produced a > 'suspect' file that has appeared following the latest update. > > The file is numbered 1839D2U0776 and the corresponding scan image is at > GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. > > It transpires that this page consists of a list of 40 "Unknown" male > corpses, and it would appear to belong to a different Quarter and/or > Year - which would explain why over half the page numbers are > out-of-range. A cursory check suggests the scan should be reassigned to > 1839 September Deaths, where the page ranges fit much better. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Yes, we've sort it out! However, I think it is worth commenting on the 'most indignant' issue. Please would coordinators try to convey to transcribers that listings like SuspectFiles are there to help improve quality not to judge their transcriptions. The transcription in question is a good example. It is a correct transcription but SuspectFiles enables us to find anomalies like mis-bound pages. Barrie On 19:59, Richard Oliver wrote: > Sorry, my query of yesterday is no longer valid; I think it was covered only three months ago, with the help of Barrie, and doesn't need further correspondence! > > Richard Oliver > Madrid, Spain > richol@arrakis.es > ----- Original Message ----- > From: Richard Oliver > To: freebmd-syndicates@rootsweb.com > Sent: Tuesday, June 22, 2010 12:57 PM > Subject: "Suspect" file > > > I don't know whom to contact, so please excuse my posting this query on the list. > > One of my team is most indignant that I pointed out his having produced a 'suspect' file that has appeared following the latest update. > > The file is numbered 1839D2U0776 and the corresponding scan image is at GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. > > It transpires that this page consists of a list of 40 "Unknown" male corpses, and it would appear to belong to a different Quarter and/or Year - which would explain why over half the page numbers are out-of-range. A cursory check suggests the scan should be reassigned to 1839 September Deaths, where the page ranges fit much better. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

Sorry, my query of yesterday is no longer valid; I think it was covered only three months ago, with the help of Barrie, and doesn't need further correspondence! Richard Oliver Madrid, Spain richol@arrakis.es ----- Original Message ----- From: Richard Oliver To: freebmd-syndicates@rootsweb.com Sent: Tuesday, June 22, 2010 12:57 PM Subject: "Suspect" file I don't know whom to contact, so please excuse my posting this query on the list. One of my team is most indignant that I pointed out his having produced a 'suspect' file that has appeared following the latest update. The file is numbered 1839D2U0776 and the corresponding scan image is at GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. It transpires that this page consists of a list of 40 "Unknown" male corpses, and it would appear to belong to a different Quarter and/or Year - which would explain why over half the page numbers are out-of-range. A cursory check suggests the scan should be reassigned to 1839 September Deaths, where the page ranges fit much better. Richard Oliver Madrid, Spain richol@arrakis.es

Martin You've just beat me to my response. There are no "Unknown" surname scans showing in the Sept Quarter and when I checked out scans 776 to 793 in the June quarter there is an obvious error in the alphabetical listing of the scans. As you mention it does look as if scans 776, 777, 782 and 783 belong possibly to the September quarter leaving scans 778, 779, 780 & 781 in the June quarter. I would suggest rather than depend on system entries to correct the problem with the scans we should approach the GRO to get a definitive answer and if necessary move and renumber the scans into their correct quarter and sequence. This will avoid future problems regarding this particular issue. Perhaps the link on the Suspect Page for reporting queries against compliant files should be made a little more bold? Allan Raymond ----- Original Message ----- From: Martin Cope To: freebmd-syndicates@rootsweb.com Sent: Tuesday, June 22, 2010 1:16 PM Subject: Re: "Suspect" file Hi Richard, This particular case was investigated by myself and Bob Phillips two or three years ago when it was possible to inspect the original books at the FRC. It appears to be due to a mis-assembly of the books at some time long ago. So the scans are in the 'correct' place. We did however add system entries so that the entries on scans 776, 777, 782 and 783 will appear when searching in the Sep 1839 quarter. The text at the top of the Suspect Files page says how you can get a compliant file such as your team member's removed from the list. I note that Croscan user Stargazer also has two files in a similar situation. best regards, Martin ----- Original Message ----- From: "Richard Oliver" <richol@arrakis.es> To: <freebmd-syndicates@rootsweb.com> Sent: Tuesday, June 22, 2010 11:57 AM Subject: "Suspect" file >I don't know whom to contact, so please excuse my posting this query on the >list. > > One of my team is most indignant that I pointed out his having produced a > 'suspect' file that has appeared following the latest update. > > The file is numbered 1839D2U0776 and the corresponding scan image is at > GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. > > It transpires that this page consists of a list of 40 "Unknown" male > corpses, and it would appear to belong to a different Quarter and/or > Year - which would explain why over half the page numbers are > out-of-range. A cursory check suggests the scan should be reassigned to > 1839 September Deaths, where the page ranges fit much better. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hello Richard I think we have been down this road before. In the Syndicates mailing list I found the answer. Link is http://archiver.rootsweb.ancestry.com/th/read/freebmd-syndicates/2010-03/1269853820 text is From: Barrie <freebmd@myarcher.net> Subject: Re: Suspect files... OK, but why? Date: Mon, 29 Mar 2010 10:15:21 +0100 References: <5FB922DCDD9140C59F92BEE92CF7665D@Richard1> In-Reply-To: <5FB922DCDD9140C59F92BEE92CF7665D@Richard1> Richard, We run a number of Quality Assurance checks on files to try to pick up systematic errors and when we find such problems the files are reported as "suspect". We don't know they are wrong but they are worth investigating. If, after investigation, we find that they are correct we exclude them from the listing. There is a link on the Suspect Files page to report files that should be excluded. Regarding these two files, if you crtl+click on the two files in the Suspect Files listing you will see that they are both predicted to be 1839D3 not 1839D2. As Bob has mentioned this is probably due to mis-binding the index. The content of page 782 supports this theory - it is out of sequence putting 'Male' entries in the middle of 'Female' entries. Also there are no 'Unknowns' for 1939D3. If you do a FreeBMD search on 'Unknown' in 1839D2 and 1839D3 you will find that System Entries have been created to handle the situation. I don't know if we have previously reported this to the GRO but I will do so. I am not hopeful that they will do anything because I doubt they have a process to handle such an eventuality, and without a process... I will exclude these files from the Suspect Files listing. Barrie On 19:59, Richard Oliver wrote: > Two files, 1839D2U0777 and 1839D2U0782, uploaded by submitterID bobj274, a > member of my Syndicate, have appeared in the "Suspect files" list > following last week's update. The reason for including them is that both > files contained entries with over 60% of the page numbers "out of range". > > I am curious to know why! My transcriber has Typed What He Saw, working > from scans of exceptional clarity, and as far as I can see with impeccable > accuracy. > > Since we are second-keying 1839 June Deaths, the expected page ranges are > at http://www.freebmd.org.uk/district-page-reverse-map-index.html and it > is a fact that quite a number of the numbers are out of range. If anyone > is "suspect", though, it is the clerk who compiled these pages of the > Index. Or is there some other angle? The Deaths in question are from the > list of "Unknown" or "Not Named", which may itself give an explanation. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > > > Cheers Bob Phillips ----- Original Message ----- From: "Richard Oliver" <richol@arrakis.es> To: <freebmd-syndicates@rootsweb.com> Sent: Tuesday, June 22, 2010 11:57 AM Subject: "Suspect" file >I don't know whom to contact, so please excuse my posting this query on the >list. > > One of my team is most indignant that I pointed out his having produced a > 'suspect' file that has appeared following the latest update. > > The file is numbered 1839D2U0776 and the corresponding scan image is at > GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. > > It transpires that this page consists of a list of 40 "Unknown" male > corpses, and it would appear to belong to a different Quarter and/or > Year - which would explain why over half the page numbers are > out-of-range. A cursory check suggests the scan should be reassigned to > 1839 September Deaths, where the page ranges fit much better. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message

Hi Richard, This particular case was investigated by myself and Bob Phillips two or three years ago when it was possible to inspect the original books at the FRC. It appears to be due to a mis-assembly of the books at some time long ago. So the scans are in the 'correct' place. We did however add system entries so that the entries on scans 776, 777, 782 and 783 will appear when searching in the Sep 1839 quarter. The text at the top of the Suspect Files page says how you can get a compliant file such as your team member's removed from the list. I note that Croscan user Stargazer also has two files in a similar situation. best regards, Martin ----- Original Message ----- From: "Richard Oliver" <richol@arrakis.es> To: <freebmd-syndicates@rootsweb.com> Sent: Tuesday, June 22, 2010 11:57 AM Subject: "Suspect" file >I don't know whom to contact, so please excuse my posting this query on the >list. > > One of my team is most indignant that I pointed out his having produced a > 'suspect' file that has appeared following the latest update. > > The file is numbered 1839D2U0776 and the corresponding scan image is at > GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. > > It transpires that this page consists of a list of 40 "Unknown" male > corpses, and it would appear to belong to a different Quarter and/or > Year - which would explain why over half the page numbers are > out-of-range. A cursory check suggests the scan should be reassigned to > 1839 September Deaths, where the page ranges fit much better. > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message

I don't know whom to contact, so please excuse my posting this query on the list. One of my team is most indignant that I pointed out his having produced a 'suspect' file that has appeared following the latest update. The file is numbered 1839D2U0776 and the corresponding scan image is at GUS/1839/Deaths/June/UKD-01/P-Z/1839D2-P-Z-0776.tif. It transpires that this page consists of a list of 40 "Unknown" male corpses, and it would appear to belong to a different Quarter and/or Year - which would explain why over half the page numbers are out-of-range. A cursory check suggests the scan should be reassigned to 1839 September Deaths, where the page ranges fit much better. Richard Oliver Madrid, Spain richol@arrakis.es

My regular reminder to Syndicate Co-ordinators about the ongoing process to delete from the FreeBMD database those volunteers who haven't uploaded any records even though they have been registered on FreeBMD for 8 months or so. Co-ordinators are advised in advance of any volunteer to be deleted from the database and given a nominal two weeks in which to respond. (Note: Any Co-ordinator who doesn't wish to receive the advance notification is quite welcome to advise me of this requirement, in fact it saves me some work - see list at bottom of "opt" out Co-ordinators) Co-ordinators are requested to check their "Syndicate Maintenance" for details of any volunteers deleted by me as explained in http://www.freebmd.org.uk/delete_submitterID.html . The deleted volunteers are shown at the bottom of the "Current Submitters" window of the Maintain Syndicate page. This will give Co-ordinators opportunity to reallocate any transcription work given to the deleted volunteers. As this is a two way exercise, I would highly recommend to all Co-ordinators they check their "Upload Reports" via http://www.freebmd.org.uk/cgi/upload-report.pl in conjunction with "Show file" at: http://www.freebmd.org.uk/cgi/show-file.pl to establish if long standing allocations to their volunteers have been transcribed and uploaded to FreeBMD. I have assumed this process to be part of the checking process adopted by all Co-ordinators. This check should identify volunteers who registered a while ago but have not uploaded any files. This will prevent me inadvertently deleting a volunteer in error. There are safeguards in place to prevent me deleting a volunteer who has uploaded one or more records. Regards Allan Raymond Co-ordinators who have previously advised they DO NOT wish to receive advance notification. Syndicate Coordinator Ian Brooke Syndicate - Ian Brooke (no longer the Coordinator) Free Loaders - Tony McHugh Debz Syndicate, N.Z - Debbie Valentine KSH Double - Kevin Howell Western Oz Synd - Teri Williams

Thanks Allan I have forwarded on your email Regards Debz On 28/05/2010 9:02 a.m., Allan Raymond wrote: > Debz > > Does http://www.freebmd.org.uk/vol_faq.html#3h provide the answer? > > "If a character is not included in the WinBMD Special Characters list it cannot be used in a transcription and you should use the unaccented character instead." > > Allan Raymond > ----- Original Message ----- > From: Debz > To: freebmd-syndicates@rootsweb.com > Sent: Thursday, May 27, 2010 9:14 PM > Subject: Special Characters > > > Hi > Sorry if this arrives twice. > I recieved this email from one of my transcribers > I have no idea what the ruling is on Special Characters > I am transcribing scan 1940M2So185 and have come across a accent code > (German I think) which I cannot find > using the F4 function which is the “show special character table” > > > > The names I have discovered so far are Schon, Schonfeld, Schonmann > > The letter “o” has a character above it which I do not recognise. > > > > Any Ideas please??? > I recieved this email from one of my transcribers and did't know the > answer myself > does anyone have a idea > > Thanks > Debz > Debz Syndicate N.Z. > > ------------------------------- > To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message > > ------------------------------- > To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message > >

Hi Sorry if this arrives twice. I recieved this email from one of my transcribers I have no idea what the ruling is on Special Characters I am transcribing scan 1940M2So185 and have come across a accent code (German I think) which I cannot find using the F4 function which is the “show special character table” The names I have discovered so far are Schon, Schonfeld, Schonmann The letter “o” has a character above it which I do not recognise. Any Ideas please??? I recieved this email from one of my transcribers and did't know the answer myself does anyone have a idea Thanks Debz Debz Syndicate N.Z.

The 1940M2-S-0185 page shows that these entries were originally typed with plain letter o, then rather clumsily altered by hand to represent o-umlaut (o with two dots above it) which is in the f4 character table in WinBMD, six rows down and 5 columns across. You may judge it appropriate to add #COMMENT lines after these entries along the guidance in TKB 6(d). #COMMENT Handwritten amendment of original typed surname Schon Incidentally the change of meaning of 'schon' by adding the umlaut changes a word meaning 'already' to a word meaning 'beautiful', a fairly common component of German placenames and surnames. Jeff ----- Original Message ----- From: "Allan Raymond" <allan_raymond@btinternet.com> To: <freebmd-syndicates@rootsweb.com> Sent: Thursday, May 27, 2010 10:02 PM Subject: Re: Special Characters Debz Does http://www.freebmd.org.uk/vol_faq.html#3h provide the answer? "If a character is not included in the WinBMD Special Characters list it cannot be used in a transcription and you should use the unaccented character instead." Allan Raymond ----- Original Message ----- From: Debz To: freebmd-syndicates@rootsweb.com Sent: Thursday, May 27, 2010 9:14 PM Subject: Special Characters Hi Sorry if this arrives twice. I recieved this email from one of my transcribers I have no idea what the ruling is on Special Characters I am transcribing scan 1940M2So185 and have come across a accent code (German I think) which I cannot find using the F4 function which is the “show special character table” The names I have discovered so far are Schon, Schonfeld, Schonmann The letter “o” has a character above it which I do not recognise. Any Ideas please??? I recieved this email from one of my transcribers and did't know the answer myself does anyone have a idea Thanks Debz Debz Syndicate N.Z. ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message