I always transcribe down the page rather than across which I find a lot quicker and gets round this problem. Say there are 15 entries of the scan visible on my PC then I will first do the names working down the page for these 15 entries, then the age at deaths, then the districts and finally the page numbers. Regards, David Lang -----Original Message----- From: wishart100.freeserve.co.uk [mailto:james@wishart100.freeserve.co.uk] Sent: 26 September 2003 20:26 To: FREEBMD-DISCUSS-L@rootsweb.com Subject: Transcribing deaths, order of keying A thought from a newbie, sorry if it has been aired before. Would it be possible, as an option, to amend the order in which the data for deaths is keyed in. If the order was:-- surname/first name/district/page/age then the typing of the letters and numbers would be grouped together in their respective parts of the keyboard. In that way the time spent relocating the hands on the keyboard when going from letters to numbers and back, would be reduced. I get the feeling that it would save about 5% in time. regards, jim wishart ______________________________

> >>The Marriages Dec 1889 page range for Gloucester 6a is 499 to 574 >inclusive. > >>Page number 644 cannot therefore be correct. > >But 644 could be "correct" (according to the objectives of FreeBMD): >if the original index contains a typing error. > > >> Now suppose that both transcribers had entered 544,... > >I suspect that might be missed (in my example). But would it really matter? > >Andrew Gough Since searchers are recommended to check the original indexes before ordering certificates then an error/uncertainty in a page number is less important than an error/uncertainty in a name spelling. -- Regards Dick Jones Leigh-on-Sea Essex UK rcjones@rmplc.co.uk

In message <i579nvc781hht8ngnba1qirfntoo9fq9qh@smtp.ukonline.co.uk>, Dave Mayall <david.mayall@ukonline.co.uk> writes >On Fri, 26 Sep 2003 20:48:55 +0100, you wrote: > >>Hi, >>I have been looking at files uploaded by other people and have found what >>seems to be some problem areas. >>Firstly where hand written scans exist it is usual for them to be grouped in >>two, three or even four sections with associated numbers for the scans >>starting from 1. Thus the +PAGE,nnnn numbers can be the same for four >>different files and as there is no rule regarding the format that the >>filenames must take how does the system know which one is relevant? If it >>uses the Surnames then why is the number associated with the +PAGE entry >>important? > >Oh no, not this one again! I suppose we've done the annual bunfight >over full stops, and it's time to do the page numbers one :-) > >The page number is a *part* of the information which is used to link >one page to the next, but it will *ONLY* cause pages to be linked if >the surnames are already sufficiently close to make a link possible. > >>The second problem is that I have found data uploaded, obviously from one >>name studies that is taken from scans with the correct +PAGE,nnnn entry, but >>with some odd entries from the centre of the scan. There were no +BREAK >>entries after the +PAGE,nnnn entry and after the data itself. >> >>Are these problems of no concern > >+PAGE entries in ONENAME files like this are slightly problematic, >but we can deal with them. Switch that computer off and get the packing done if you know what's good for you! (-: -- Philip Powell Looking north across the Derwent Valley and Northumberland to The Cheviot

On Fri, 26 Sep 2003 20:48:55 +0100, you wrote: >Hi, >I have been looking at files uploaded by other people and have found what >seems to be some problem areas. >Firstly where hand written scans exist it is usual for them to be grouped in >two, three or even four sections with associated numbers for the scans >starting from 1. Thus the +PAGE,nnnn numbers can be the same for four >different files and as there is no rule regarding the format that the >filenames must take how does the system know which one is relevant? If it >uses the Surnames then why is the number associated with the +PAGE entry >important? Oh no, not this one again! I suppose we've done the annual bunfight over full stops, and it's time to do the page numbers one :-) The page number is a *part* of the information which is used to link one page to the next, but it will *ONLY* cause pages to be linked if the surnames are already sufficiently close to make a link possible. >The second problem is that I have found data uploaded, obviously from one >name studies that is taken from scans with the correct +PAGE,nnnn entry, but >with some odd entries from the centre of the scan. There were no +BREAK >entries after the +PAGE,nnnn entry and after the data itself. > >Are these problems of no concern +PAGE entries in ONENAME files like this are slightly problematic, but we can deal with them. -- Dave Mayall

Hi, I have been looking at files uploaded by other people and have found what seems to be some problem areas. Firstly where hand written scans exist it is usual for them to be grouped in two, three or even four sections with associated numbers for the scans starting from 1. Thus the +PAGE,nnnn numbers can be the same for four different files and as there is no rule regarding the format that the filenames must take how does the system know which one is relevant? If it uses the Surnames then why is the number associated with the +PAGE entry important? The second problem is that I have found data uploaded, obviously from one name studies that is taken from scans with the correct +PAGE,nnnn entry, but with some odd entries from the centre of the scan. There were no +BREAK entries after the +PAGE,nnnn entry and after the data itself. Are these problems of no concern, and what action is being taken by coordinators to avoid the situation? Regards Brian Smart

On Fri, 26 Sep 2003 20:26:20 +0100, you wrote: >A thought from a newbie, sorry if it has been aired before. >Would it be possible, as an option, to amend the order in which the data for >deaths is keyed in. >If the order was:-- surname/first name/district/page/age then the typing of >the letters and numbers would be grouped together in their respective parts >of the keyboard. In that way the time spent relocating the hands on the >keyboard when going from letters to numbers and back, would be reduced. I >get the feeling that it would save about 5% in time. But the indexes that you are keying *from* aren't in that order! I suspect that any improvement in speed would be at the expense of accuracy as people keyed data in a different order to that in which it appeared in the original, and FreeBMD puts MUCH greater store in getting it right than doing it fast. Your suggestion would work well if our transcription was being done by experienced key-to-disk operators, but for amateurs accuracy is more likely if we maintain the same order. -- Dave Mayall

Using the +FORMAT syntax, you can enter the fields in any way you want providing you specify what you're doing and are consistent. I find it easier though to let my eyes travel along the line rather than darting back and forth. also personally I usually use the numbers above the QWERTY keys for typing. The "Flat File" format page is probably the most relevant one from FreeBMD Project to answer the question. http://freebmd.rootsweb.com/Flat.html Mark Hattam -- james@wishart100.freeserve.co.uk wrote: > A thought from a newbie, sorry if it has been aired before. > Would it be possible, as an option, to amend the order in which the data for > deaths is keyed in. > If the order was:-- surname/first name/district/page/age then the typing of > the letters and numbers would be grouped together in their respective parts > of the keyboard. In that way the time spent relocating the hands on the > keyboard when going from letters to numbers and back, would be reduced. I > get the feeling that it would save about 5% in time. > regards, > jim wishart

A thought from a newbie, sorry if it has been aired before. Would it be possible, as an option, to amend the order in which the data for deaths is keyed in. If the order was:-- surname/first name/district/page/age then the typing of the letters and numbers would be grouped together in their respective parts of the keyboard. In that way the time spent relocating the hands on the keyboard when going from letters to numbers and back, would be reduced. I get the feeling that it would save about 5% in time. regards, jim wishart

Quoting John Fairlie <john.fairlie@blueyonder.co.uk>: > I know in the past I suggested a bit of code that would shortlist all > entries that contained uncertain characters, []_* etc. > > If that same piece of code (Dave!!) also listed entries that were out of > sequence alphabetically, out of page range for the district and quarter > concerned, and (finally), those records where there were too many entries on > a register page...... Then that must scoop up almost all entries that are > worth a second look. Such a piece of code was (part) written, and even worked for a while. The growing size of the database means that something a bit more efficient will be needed. > I would also like this to be able to be run on my own entries only, i.e., > for FBMD to produce all the shortlists for each transcriber, and e-mail them > to us, or make them available for downloading like scans are. Is this how > you were going to do it Dave? Probably not. That would eltimately lead to us *telling* transcribers that they were to correct an entry, whilst the ethos of FreeBMD is that transcribers transcribe what they see. Where the later stages of the process decide that a transcriber has made an error, it is intended that the co-ordinator of the later stage will upload an amendment file in his own name which will take precedence over the original transcription. -- Dave Mayall ---------------------------------------------- This mail sent through http://www.ukonline.net

I know in the past I suggested a bit of code that would shortlist all entries that contained uncertain characters, []_* etc. If that same piece of code (Dave!!) also listed entries that were out of sequence alphabetically, out of page range for the district and quarter concerned, and (finally), those records where there were too many entries on a register page...... Then that must scoop up almost all entries that are worth a second look. I would also like this to be able to be run on my own entries only, i.e., for FBMD to produce all the shortlists for each transcriber, and e-mail them to us, or make them available for downloading like scans are. Is this how you were going to do it Dave? I shall now duck my head below the parapet!! John Fairlie Mail us at ..... john@fairlie.plus.com john.fairlie@blueyonder.co.uk Home page... http://www.fairlie.plus.com -----Original Message----- From: Dave Mayall [mailto:david.mayall@ukonline.co.uk] Sent: Friday, September 26, 2003 12:54 PM To: FREEBMD-DISCUSS-L@rootsweb.com Subject: RE: DOUBLE KEYING - a different point! Quoting andrewgough@ftnetwork.com: > > >>The Marriages Dec 1889 page range for Gloucester 6a is 499 to 574 > inclusive. > >>Page number 644 cannot therefore be correct. > > But 644 could be "correct" (according to the objectives of FreeBMD): if the > original index contains a typing error. Oh, indeed, but the point remains that we can analyse the data to identify the VAST majority of entries worth a second look! -- Dave Mayall ---------------------------------------------- This mail sent through http://www.ukonline.net ============================== To join Ancestry.com and access our 1.2 billion online genealogy records, go to: http://www.ancestry.com/rd/redir.asp?targetid=571&sourceid=1237

Quoting andrewgough@ftnetwork.com: > > >>The Marriages Dec 1889 page range for Gloucester 6a is 499 to 574 > inclusive. > >>Page number 644 cannot therefore be correct. > > But 644 could be "correct" (according to the objectives of FreeBMD): if the > original index contains a typing error. Oh, indeed, but the point remains that we can analyse the data to identify the VAST majority of entries worth a second look! -- Dave Mayall ---------------------------------------------- This mail sent through http://www.ukonline.net

>>The Marriages Dec 1889 page range for Gloucester 6a is 499 to 574 inclusive. >>Page number 644 cannot therefore be correct. But 644 could be "correct" (according to the objectives of FreeBMD): if the original index contains a typing error. >> Now suppose that both transcribers had entered 544,... I suspect that might be missed (in my example). But would it really matter? Andrew Gough ___________________________________________________________________________________________________ Visit the web site of the Financial Times at http://www.ft.com

I think it would be recognised Ian. The Marriages Dec 1889 page range for Gloucester 6a is 499 to 574 inclusive. Page number 644 cannot therefore be correct. The aliasing team would pick this up! Best wishes Chris Preece Barossa Vineyards South Oz > ---------- > From: Iain Archer[SMTP:ia_gen@montaigne.demon.co.uk] > Sent: 25 September 2003 05:01 > To: FREEBMD-DISCUSS-L@rootsweb.com > Subject: Re: DOUBLE KEYING - a different point! > > [Transferred from FreeBMD-Admins-L@rootsweb.com] > > Dave Mayall <david.mayall@ukonline.co.uk> wrote to > FreeBMD-Admins-L@rootsweb.com on Fri, 12 Sep 2003: > > >On Thu, 11 Sep 2003 19:47:24 +0200, you wrote: > > > >>Marriages Dec 1889 > >> > >>FERRIS Fanny Gloucester 6a [56]44 > >> > >>Ferris Fanny Gloucester 6a 544 > >> > > >>Question: is there some clever software which in time will recognize > >> these duplications and merge them into a singe (bold) entry? Because > >>in the meantime they are distorting the number of "unique" records > >>which FreeBMD claims in its home page.... > > >No, ultimately all unmatched entries will be investigated and resolved > >by experienced transcribers. > > Who will presumably be able to determine whether the page should be > entered as 544, 644, or even [56]44, and that at least one > of the transcribers had made an error. > > Now suppose that both transcribers had entered 544, or 644, or [56]44. > What is the probability in each case that not just one, but both, have > made an error? And would that error be recognised? > -- > Iain Archer > > > ============================== > To join Ancestry.com and access our 1.2 billion online genealogy records, go > to: > http://www.ancestry.com/rd/redir.asp?targetid=571&sourceid=1237 > > >

In message <c235nvk6s9ipe72ingqr03kd6rb52sgq4j@smtp.ukonline.co.uk>, Dave Mayall <david.mayall@ukonline.co.uk> writes >On Wed, 24 Sep 2003 20:31:50 +0100, you wrote: > >>[Transferred from FreeBMD-Admins-L@rootsweb.com] >> >>Dave Mayall <david.mayall@ukonline.co.uk> wrote to >>FreeBMD-Admins-L@rootsweb.com on Fri, 12 Sep 2003: >> >>>On Thu, 11 Sep 2003 19:47:24 +0200, you wrote: >>> >>>>Marriages Dec 1889 >>>> >> >>FERRIS Fanny Gloucester 6a [56]44 >> >> >> >>Ferris Fanny Gloucester 6a 544 >> >> >> >>>>Question: is there some clever software which in time will recognize >>>> these duplications and merge them into a singe (bold) entry? Because >>>>in the meantime they are distorting the number of "unique" records >>>>which FreeBMD claims in its home page.... >> >>>No, ultimately all unmatched entries will be investigated and resolved >>>by experienced transcribers. >> >>Who will presumably be able to determine whether the page should be >>entered as 544, 644, or even [56]44, and that at least one >>of the transcribers had made an error. >> >>Now suppose that both transcribers had entered 544, or 644, or [56]44. >>What is the probability in each case that not just one, but both, have >>made an error? And would that error be recognised? > >At some point in the future, I will complete coding of the module >which analyses the data to find entries which are out of place. > >In the example you give, it is unlikely that Gloucester extends to >page 644, so it would be caught that way. Alternatively, it will show >up due to an incorrect number of entries on a page. I'm glad Dave provided that as I was sure it would be possible. Page range checking will pick up many, but not all, possible errors. I'm currently compiling a page range for my syndicate co-ordinator [yes, I know the FreeBMD database does it]. With a couple of exceptions, every error it has thrown up has been a typo on my part when I've checked back. Of course, page range checking won't find every error but it should find most where the hundreds digit is wrong or there is an option such as above -- Philip Powell Looking north across the Derwent Valley and Northumberland to The Cheviot

On Wed, 24 Sep 2003 20:31:50 +0100, you wrote: >[Transferred from FreeBMD-Admins-L@rootsweb.com] > >Dave Mayall <david.mayall@ukonline.co.uk> wrote to >FreeBMD-Admins-L@rootsweb.com on Fri, 12 Sep 2003: > >>On Thu, 11 Sep 2003 19:47:24 +0200, you wrote: >> >>>Marriages Dec 1889 >>> > >>FERRIS Fanny Gloucester 6a [56]44 > >> > >>Ferris Fanny Gloucester 6a 544 > >> > >>>Question: is there some clever software which in time will recognize >>> these duplications and merge them into a singe (bold) entry? Because >>>in the meantime they are distorting the number of "unique" records >>>which FreeBMD claims in its home page.... > >>No, ultimately all unmatched entries will be investigated and resolved >>by experienced transcribers. > >Who will presumably be able to determine whether the page should be >entered as 544, 644, or even [56]44, and that at least one >of the transcribers had made an error. > >Now suppose that both transcribers had entered 544, or 644, or [56]44. >What is the probability in each case that not just one, but both, have >made an error? And would that error be recognised? At some point in the future, I will complete coding of the module which analyses the data to find entries which are out of place. In the example you give, it is unlikely that Gloucester extends to page 644, so it would be caught that way. Alternatively, it will show up due to an incorrect number of entries on a page. -- Dave Mayall

[Transferred from FreeBMD-Admins-L@rootsweb.com] Dave Mayall <david.mayall@ukonline.co.uk> wrote to FreeBMD-Admins-L@rootsweb.com on Fri, 12 Sep 2003: >On Thu, 11 Sep 2003 19:47:24 +0200, you wrote: > >>Marriages Dec 1889 >> >>FERRIS Fanny Gloucester 6a [56]44 >> >>Ferris Fanny Gloucester 6a 544 >> >>Question: is there some clever software which in time will recognize >> these duplications and merge them into a singe (bold) entry? Because >>in the meantime they are distorting the number of "unique" records >>which FreeBMD claims in its home page.... >No, ultimately all unmatched entries will be investigated and resolved >by experienced transcribers. Who will presumably be able to determine whether the page should be entered as 544, 644, or even [56]44, and that at least one of the transcribers had made an error. Now suppose that both transcribers had entered 544, or 644, or [56]44. What is the probability in each case that not just one, but both, have made an error? And would that error be recognised? -- Iain Archer

unsubscribe for short break due to moving house

I've just started on a new batch of 1858 Q2 Deaths. When I filed the transcripts in my system ready for uploading I realised I had a conflict. Some time ago I had 1858 Q2 Deaths with the same page numbers BUT a different initial eg 1858D2-H-0341 and now 1858D2-V-0341 Speedbmd won't allow this as a page number. Obviously I can rename the file in Notepad but........ What is the correct procedure? Thanks John Ellwood

16 September 2003 19:17:54 Hello, Angela, Jean, Steve, & Leo, Please accept my sincere thanks for your prompt replies, Now back to the coalface :o) -- Best regards, Tony mailto:Horler@one-name.org Bright,Victoria,Australia Earlier today I wrote; Whilst transcribing 1884 deaths I have found this entry; McKeon Michael. 40 or 50 Gateshead 10a 528 WINBMD will not let me enter what I see, How do I get around this slight problem ?

Whilst transcribing 1884 deaths I have found this entry; McKeon Michael. 40 or 50 Gateshead 10a 528 WINBMD will not let me enter what I see, How do I get around this slight problem ? -- Best regards, Tony mailto:Horler@one-name.org