Hi, I'm not sure that two aspects of what you say are correct Stephen. 1. There definately isn't a limit of one page per file - I don't believe there is any upper limit and I have transcribers who regularly upload files containing multiple pages. However, these don't really differ from your description except that there are additional +PAGE,n+1 in the 'middle' of the file. 2. I'm unsure about your scenario #3. Assuming (and I think this is correct) that the 'complete page' matching routine uses nothing but the +PAGE lines to decide if a page is complete then I don't see how it could do anything with a file with no opening +PAGE. I have no idea though what such a file would look like, nor indeed why anyone would want to do this (it seems to make much more sense to simply add the later lines to the end of the first and upload the file again). I would guess though that the 2nd file should look like the first, ie have the same opening +PAGE,n but this time have a closing +PAGE,n+1 - this is a pure guess though! I too am interested in the answer to the other question that someone raised - how does one close the last page in a quarter when, by definition there is no page n+1. Is it done by a simple +PAGE or by PAGE,n+1 regardless of the fact that nothing will ever match n+1. I suspect that either of these is acceptable but again this is a guess. Regards Ian ----- Original Message ----- From: "Stephen Carter" <[email protected]> To: <[email protected]> Sent: Sunday, October 28, 2001 12:11 AM Subject: Re: half page explained > Graham, at 01:16 28/10/2001, you wrote: > > >Hi Garry, > > > >lat one before I go to bed ! > > > >Kiwiz Syndicate wrote: > > > > > > Another point that needs clarification: > > > It is not 'half page' but split page, wrongly named IMHO. > > > The only time +PAGE is left out is when a 300 name page is split into > > two files. The > > > +PAGE is omitted on the first file only. A rare occurence I'm told. > > > >Dave wrote on the admins list > > > I used the term "half page". I should have said "part transcribed > > > page". > > > > > > >so I think we are in agreement about the wording of half page :) > > Sorry to milk this even further, but it seems to me there are four distinct > scenarios. > > 1) If someone starts transcribing a page from the 1st entry and completes > it to the last entry - in which case there should be a +PAGE,n [n = page > number] in the first line of the file and a +PAGE, (n+1) in the last line > of the file. > > 2) If someone starts transcribing a page from the 1st entry, and closes > the file before completing the transcription of that page, there should be > a +PAGE,n in the first line of the file and no +PAGE at all at the end of > the file. > > 3) If someone starts transcribing a page from an entry other than the > first one and completes the page to the last entry, there should be no > +PAGE,n in the first line of the file but there should be a +PAGE,(n+1) in > the last line of the file. > > 4) If someone starts transcribing a page from an entry other than the > first one and closes the file before completing the page to the last entry, > there should be no +PAGE lines at all, either at the beginning or the end > of the file. > > Is this a correct understanding? ( I am assuming that there is a maximum > of one page per file - this understanding does not allow for there being a > complete page, between two other +PAGE lines, in the middle of the file). > > > Stephen > > Revd S H Carter > [email protected] > > United Benefice of Coalbrookdale, Ironbridge and Little Wenlock > http://www.rectorshouse.freeserve.co.uk/benefice/benframe.html > > > ============================== > Visit Ancestry's Library - The best collection of family history > learning and how-to articles on the Internet. > http://www.ancestry.com/learn/library > >

Ian said > I too am interested in the answer to the other question that someone > raised - how does one close the last page in a quarter when, by definition > there is no page n+1. Is it done by a simple +PAGE or by PAGE,n+1 > regardless of the fact that nothing will ever match n+1. I suspect that > either of these is acceptable but again this is a guess. I anticipate being told off again but I promise to take it in good part. Here is the scenario transcriber A has a block of transcriptions which run from 1846B1-G-P-1156.tif to 1846B1-G-P-1165.tif and dutifully finishes of with +PAGE,n+1. Transcriber B is allocated pages that run from 1846B1-G-P-1166.tif to 1846B1-G-P-1175.tif. Sadly on down loading these are all blanks. So nothing is transcribed and nothing is uploaded and no record will exist of files in this range will exist when the Range Check is run for this quarter. The next download with data for transcription is 1846B1-G-P-1176.tif . Now various kind people have tried to explain that this is not a problem, but I cannot get my mind round their explanations. I do not see how this can be when one file ends expecting to find a file that stems from 1846B1-G-P-1166.tif, but there is no record of this. The next file in sequence actually stems from 1846B1-G-P-1176.tif . In case any one thinks I am banging on about a theoretical situation these file numbers have been taken from my records and reflect what has been reported to me. If anyone thinks it is an isolated instance there are 19 runs of blanks in 1846 BQ1 reported to me so far. This means if someone else has to do the range check in my place they have at least 190 pages of gaps to investigate to be sure all data that should be present is present I would be more than happy to let this matter die, but I will not rest easy in my mind until I have understood the explanations that Dave and others have given so far. I would dearly love to rest my case. John

Hi Ian, Ian Brooke wrote: > > Hi, > I'm not sure that two aspects of what you say are correct Stephen. > 1. There definately isn't a limit of one page per file - I don't believe > there is any upper limit and I have transcribers who regularly upload files > containing multiple pages. However, these don't really differ from your > description except that there are additional +PAGE,n+1 in the 'middle' of > the file. There is no limit to the number of pages inside a file, that is correct. (file size is the limit, I suppose nd I don't thnk we are gonna hit that !) > 2. I'm unsure about your scenario #3. Assuming (and I think this is > correct) that the 'complete page' matching routine uses nothing but the > +PAGE lines to decide if a page is complete then I don't see how it could do > anything with a file with no opening +PAGE. I have no idea though what such > a file would look like, nor indeed why anyone would want to do this (it > seems to make much more sense to simply add the later lines to the end of > the first and upload the file again). I would guess though that the 2nd > file should look like the first, ie have the same opening +PAGE,n but this > time have a closing +PAGE,n+1 - this is a pure guess though! This scenario is less likely to occur these days with the scan syndicates, but is more common in separately transcribed entries which are not from scans or are from a one named study. E.g. if I transcribed the HARTs they could start in the middle of a page and cross a page boundary. > I too am interested in the answer to the other question that someone > raised - how does one close the last page in a quarter when, by definition > there is no page n+1. Is it done by a simple +PAGE or by PAGE,n+1 > regardless of the fact that nothing will ever match n+1. I suspect that > either of these is acceptable but again this is a guess. Yes, I suspect that you are correct and using +PAGE,n+1 is the sensible way in this instance. As far as the matchign is concerned, remember that the way we match at the moment and the way we will match with completed double entry runs will be slightly different. When a quarter is complete, it will be 'cleaned' as far as possible whilst keeping the integrity of the transcription. Part of this cleaning mechanism should be to split it into pages. When the double entry is then available for matching, the pages can be matched against each other as opposed to the long strings of entries that tends to happen today. When splitting into pages, the osftware can easily count, check and throw up apparent differences in page numbers etc which could then be checked against the scans. I think, and Dave will correct me if I am wrong, that this area is one that we wiil be able to identify problems programmatically and go back and tweak during the checking phase. This will highlight missing pages, blanks, places where people have the page number wrong etcetc... However, that doesn't mean that we shouldn't get it right first time where possible :)) And it does have an impact on the matching process as it stands which is where this discussion came from in the first place. Hope that helps Cheers Graham > Regards > Ian > > ----- Original Message ----- > From: "Stephen Carter" <[email protected]> > To: <[email protected]> > Sent: Sunday, October 28, 2001 12:11 AM > Subject: Re: half page explained > > > Graham, at 01:16 28/10/2001, you wrote: > > > > >Hi Garry, > > > > > >lat one before I go to bed ! > > > > > >Kiwiz Syndicate wrote: > > > > > > > > Another point that needs clarification: > > > > It is not 'half page' but split page, wrongly named IMHO. > > > > The only time +PAGE is left out is when a 300 name page is split into > > > two files. The > > > > +PAGE is omitted on the first file only. A rare occurence I'm told. > > > > > >Dave wrote on the admins list > > > > I used the term "half page". I should have said "part transcribed > > > > page". > > > > > > > > > >so I think we are in agreement about the wording of half page :) > > > > Sorry to milk this even further, but it seems to me there are four > distinct > > scenarios. > > > > 1) If someone starts transcribing a page from the 1st entry and completes > > it to the last entry - in which case there should be a +PAGE,n [n = page > > number] in the first line of the file and a +PAGE, (n+1) in the last line > > of the file. > > > > 2) If someone starts transcribing a page from the 1st entry, and closes > > the file before completing the transcription of that page, there should be > > a +PAGE,n in the first line of the file and no +PAGE at all at the end of > > the file. > > > > 3) If someone starts transcribing a page from an entry other than the > > first one and completes the page to the last entry, there should be no > > +PAGE,n in the first line of the file but there should be a +PAGE,(n+1) in > > the last line of the file. > > > > 4) If someone starts transcribing a page from an entry other than the > > first one and closes the file before completing the page to the last > entry, > > there should be no +PAGE lines at all, either at the beginning or the end > > of the file. > > > > Is this a correct understanding? ( I am assuming that there is a maximum > > of one page per file - this understanding does not allow for there being a > > complete page, between two other +PAGE lines, in the middle of the file). > > > > > > Stephen > > > > Revd S H Carter > > [email protected] > > > > United Benefice of Coalbrookdale, Ironbridge and Little Wenlock > > http://www.rectorshouse.freeserve.co.uk/benefice/benframe.html > > > > > > ============================== > > Visit Ancestry's Library - The best collection of family history > > learning and how-to articles on the Internet. > > http://www.ancestry.com/learn/library > > > > > > ============================== > Shop Ancestry - Everything you need to Discover, Preserve & Celebrate > your heritage! > http://shop.myfamily.com/ancestrycatalog