I recently had occasion to order the marriage certificate. William ROUND and Sarah HILL. 1840 Dudley 18 331 1st Qrt I obtained the details, which I checked for both parties, from fiche of the handwritten entries in the BMD records at my local LDS centre. I also have the marriage details (17 Mar 1840) independently from family documents. I was surprised to hear back from the agent that when he checked in the indexes that there was no sign of Sarah Hill. In fact I know there are two Sarah Hills - the other has a page entry different to the one matching William Round. A month or two ago I realised in transcribing 1845 4th Qrt births (including DRAKE to DUNN) that every other physical page was missing from the posted tif images .. (I realised the problem from an obvious break in the forenames in long list with the same surname - the handwritten pages numbers confirmed the missing page.) I went to my local LDS and found that the fiche records that they had were complete - and obtained the missing pages from that source. So - I guess this is to alert you to the possible problem - although it is not hard to spot - and to ask just how common this is? (I see that 1840 was 80% complete as of October 11th) Keith

| Allan Raymond said: | >However the last thing we want is to start a flame war by your out of order comments. | >Please desist from making derogatory comments. Flame war?? I assure you it was not intended to be derogatory, just a play on his Bunkum statement. Lighten up, Allan :-) Garry KIWIZ Syndicate Co-ordinator

John Yep. When I come to update the actual document and pass it via Dave etc it will clarify the point you mentioned. The document at the moment is really just me capturing all the appropriate emails with the respective comments. I will combine all these together into a cohesive instruction, which hopefully will cover all eventualities (perhaps a tall order). Allan Raymond [email protected] http://www.btinternet.com/~allan_raymond/Monarchies_of_Europe.htm FreeBMD - putting birth marriages and deaths on the Internet http://FreeBMD.rootsweb.com/ ----- Original Message ----- From: "John Carpenter" <[email protected]> To: <[email protected]> Sent: 29 October 2001 09:18 Subject: Comment on +PAGE Draft Allan, One thought about your draft web page. You say: "In the (rare) cases where transcribers are submitting files that start or end mid-page, no +PAGE line should be inserted." I guess you mean: "no +PAGE line should be inserted at the beginning or end of the file. Any change of page within the file must have a +PAGE entered each time" Regards, John ============================== Shop Ancestry - Everything you need to Discover, Preserve & Celebrate your heritage! http://shop.myfamily.com/ancestrycatalog

Allan, One thought about your draft web page. You say: "In the (rare) cases where transcribers are submitting files that start or end mid-page, no +PAGE line should be inserted." I guess you mean: "no +PAGE line should be inserted at the beginning or end of the file. Any change of page within the file must have a +PAGE entered each time" Regards, John

Hi All Can we ask Ian to add a thingy to WinBMD that on saving a file it asks "have you transcribed every bit of data or is this just half a page and you're trying to beat the rebuild" or words like that and if the answer is yes it sticks on +PAGE,n+1 If a different number than n+1 is required due to say blanks then it could be entered manually and WinBMD wouldn't ask. Maybe "Is the page finished" is better. Bob Phillips (The John Slann Institute of Transcribers)

In message <[email protected]>, Dave Mayall <[email protected]> writes >On Sun, 28 Oct 2001 09:10:27 -0000, you wrote: > > >>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. > >:-) > >I'm actually rather impressed that so many people worry that it will >be a problem. > >This will be tackled in a number of ways, in order to draw together a >number of discrete units to make up a complete quarter. > >The +PAGE,nnn is part of it and will help build up a number of big >data chunks, with some gaps that we will then have to tie together. > >Another facet, particularly with scanned pages will be the link back >to the scanned pages, which we will be sorting out soon. This will >provide valuable data on data-free pages. > >Please, don't worry! We will be able to work round the blank pages. Thanks for the explanation. It seems to me that the problem is that most of us don't know [not that it is anyone's fault - it's just the way it is] how the process works so we probably worry unduly that things might go wrong. -- Philip Powell

I was just thinking and couldn't you just upload a file like the following to deal with these pages: +PAGE,0039 #BLANK +PAGE,0040 #BLANK +PAGE,0041 #B (as in has a large capital B) This way the computer can find the blank pages. This would depend on someone finding all the blank pages which isn't too difficult if you download each of the images. Bye for now Mary Muir [email protected] www.genealogy.bc.ca

On Sun, 28 Oct 2001 15:54:30 -0000, you wrote: >In answer to my comment: > >"For my own reasons I did not use the numbering system as in the September >quarter, thus the March quarter has unique numbers for each file." > >Graham said: > >"My feeling about using your own numbering system is that we lose the >opportunity of matching page to page when we come to match the double >entry keying of that quarter so I would prefer that we all were >consistent." > >It seems to me that nobody has thought through this issue and things have >been left to the Coordinators. This is particularly the case when it comes >to naming files. File naming isn't important (to us, because we don't use it) co-ordinators have the opportunity to issue their own instructions on this point. >If definitive rules were specified, we would not be in the position where we >are trying to formulate them after the work has been done. > >One of the obvious problems, from my point of view, is that as a coordinator >I do not know the way the overall system works. While this may not concern >all coordinators, I feel that if I don't know the system I can't be expected >to make rational decisions. We will try and explain how it works to those who feel the need to know (provided they understand that some of it isn't written yet, and is more in our heads than in reality). The majority wouldn't want to know though (trust me on this one!!) >As a final comment, given that indexes are used to speed the process of >answering peoples search queries what difference does it make which order >the files are collated? It allows us to properly match the double entries and to validate the completeness of the keying. -- Dave Mayall

On Sun, 28 Oct 2001 13:00:13 -0000, you wrote: >These are my personal views, but I believe Dave has enough to do when he starts >the database update without having to remember to send emails or update the site >as appropriate with messages that he is due to start the update. :-) Dave can probably manage a message to a mailing list! I'll send a "the update starts soon" message to Syndicates and Discuss (I haven't the time to deal with the feedback that sending it to Admins would generate). Oh, and I might forget sometimes, because that's the kind of guy I am. -- Dave Mayall

On Sun, 28 Oct 2001 09:10:27 -0000, you wrote: >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. :-) I'm actually rather impressed that so many people worry that it will be a problem. This will be tackled in a number of ways, in order to draw together a number of discrete units to make up a complete quarter. The +PAGE,nnn is part of it and will help build up a number of big data chunks, with some gaps that we will then have to tie together. Another facet, particularly with scanned pages will be the link back to the scanned pages, which we will be sorting out soon. This will provide valuable data on data-free pages. Please, don't worry! We will be able to work round the blank pages. -- Dave Mayall

On Sun, 28 Oct 2001 08:40:04 -0000, you wrote: >Hi > >I could agree with the theory of a full stop showing an abbreviated name if >it wasn't for the following: > >1) They are only found on Death records not on Births or Marriages Wrong. Some Births and Marriages have been found with full stops after forenames. >2) They are found on EVERY Death record in my particular scans, whatever the >preceding Forename(s) or initials may be - Dave has this wrong in (2) below "In my particular scans".... but not in ALL scans. We set policy such that the same consistent rule is applied consistently to ALL transcribing. A rule that said "Transcribe the full stop if it is important" would be farcical. Transcribe what you see, and don't interpret. -- Dave Mayall

On Sun, 28 Oct 2001 19:28:55 +1300, you wrote: >I don't know which page Dave is on about but I have checked out a number of typed >pages here; >http://freebmd.rootsweb.com/GUS/1868/Marriages/March/DB-01 >1868M1-0007.tif >1868M1-0008.tif >1868M1-0009.tif > >The fullstop/period denotes the end of something not the opposite. On these pages, yes. On others no. >| Dave Mayall said >| > Now, if my hypothesis is bunkum...snip > >It's worse than bunkum, I think it's a load of hot smelly air to be honest, Dave!. >And we're all downwind :-). >Logic/common sense has to prevail here at sometime, I'm sure. >THE PERIOD is there to say THE END...... and is NOT 'potentially valuable data'. >What say you?. Have you seen the message about someone having found a name in the index that read "Obed."? Does that full stop mean anything? -- Dave Mayall

On Fri, 26 Oct 2001 16:11:00 EDT, you wrote: >Hello, >I see a new DB rebuild cycle has begun. >Is there any way you could let us know ahead of time when you're planning to >do another rebuild-- say post it on the website? >Does the rebuild usually start about 5pm (UK time) on the last Friday of the >month? No. The rebuild usually starts at about 14:00 (UK) on the 23rd of the month, but I wouldn't like to promise it. This month it was late starting because I was waiting for some software changes that we needed. I didn't know when they would be ready, and started the update about 10 minutes after putting the software live (because we were already late) -- Dave Mayall

G'day Graham Thanks heaps for your clear & nicely worded explaination, I understand the situation much clearer now. And I 'think' I'm doing it right ;) Cheers! Teri -- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.273 / Virus Database: 156 Release Date: 25/10/2001

On Sat, 27 Oct 2001 18:17:25 +0100, you wrote: >I agree with a lot of what Andrew says, but I am also in favour of having a >central person who fields the do you think you have found a mistake queries. >This volunteer could then contact the transcriber to request they look again >at the information. >I realise that there are more urgent fixes required - periods etc, but >perhaps this could also be looked at in the future. this is already being written :-) Transcribers will be able to opt to be "ex-directory" -- Dave Mayall

On Fri, 26 Oct 2001 18:49:15 +0100, you wrote: >Anyway getting back to your query, where else on the site would you suggest we put >a "bold" message warning off potential researchers? > >Unless the researcher makes a concerted effort to look around the site I can't >think how a researcher would know your email address other than when he gets the >result of a search with details of the transcriber as I mentioned at the start of >my response. One area of interest is that Barrie is re-writing this functionality to allow transcribers to opt out of being contactable. The facility was originally written on the basis that people could read. Regrettably, there seems to be a hard core of people who can't understand the notice. -- Dave Mayall

| Dave Mayall said: | > > 1) There are cases where there is quite distinctly a period following a forename, | > > separate from and different to the row of dots that follow. | > > 2) The use of such a period would appear to be against some but not all records | > > on a page | > > 3) we can conclude that either it means something or is poor typesetting | > > | > > We know that a period following a single letter means that the letter is a | > > contraction of a name to an initial, so I propose a hypothesis that a period | > > following a forename MAY indicate that there are further forenames not indexed snip I don't know which page Dave is on about but I have checked out a number of typed pages here; http://freebmd.rootsweb.com/GUS/1868/Marriages/March/DB-01 1868M1-0007.tif 1868M1-0008.tif 1868M1-0009.tif The fullstop/period denotes the end of something not the opposite. My dictionary says 'Complete cessation'. IMHO the period signifies the end of the forenames, NOT the possible continuance of. Notice they use a comma after a surname MEANING more follows. - Contrary to 2) above: There is a period at the end of EVERY Forename on each page above and if it's not there it's been obliterated. - If there are two forenames the period is only entered after the second name. - Some names have three F'names ie Mary Ann B., the period is at the end (this period must be entered as it's an abbrev.). - I tried to find a 4+ F'name example but could not. But I assume they would write it Mary Ann B C. Maybe someone could give us an example of a name longer than 3 F'names. | Dave Mayall said | > Now, if my hypothesis is bunkum...snip It's worse than bunkum, I think it's a load of hot smelly air to be honest, Dave!. And we're all downwind :-). Logic/common sense has to prevail here at sometime, I'm sure. THE PERIOD is there to say THE END...... and is NOT 'potentially valuable data'. What say you?. Garry KIWIZ Syndicate Co-ordinator

I have a sneaking suspicion we're at cross purposes with this. Those of us who don't want to include the full stops are talking about pages where every single record has a full stop at the end of the Forenames and it's always followed by a blank space. The alignment dots don't start until after whatever is the next field. I don't have a problem with those pages which only include a full stop after a few Forenames. I'll agree it's used as an abbreviation then. I just had a look at the scan page for some examples. After 1883 all the Death records had the full stop and space as described above. I don't think that can be called a small sub-set. I also had a look at Garry's pages of 1868 Marriages and again there's a full stop and a space. The alignment dots don't start until after the District name. So, it would seem these 'problem' pages are quite easy to identify. They all have full stops on every record after the forenames and then spaces. I suspect the problem has only just arisen as very few Syndicates are, as yet, working on such pages. No doubt more will be in the future!! Sue E Sussex, UK My Family Tree Website is at http://freepages.genealogy.rootsweb.com/~sadovaston ----- Original Message ----- From: "Mary Trevan" <[email protected]> To: "Sue Burton" <[email protected]>; <[email protected]> Sent: 28 October 2001 17:42 PM Subject: Re: Fullstop - Obed. was from a marriage index > Sue, > > At the risk of inflaming an already hot topic, I omitted to mention that the > Obed. and Eliza. examples from my earlier email are actually from a marriage > index, and co-incidentally from the same page as each other. > > >I could agree with the theory of a full stop showing an abbreviated name if > >it wasn't for the following: > > > >1) They are only found on Death records not on Births or Marriages > <SNIP> > > The point I was trying to make was not that they are abbreviations, but that > we cannot know from the index alone whether they are abbreviated names or > full names. > > The Obed. example, which is the first one I spotted, is on a particularly > clear part of a print-out from a microfilm, and the 'missing alignment > dots', if that is what they are, are not part of a stripe of damage down the > film. The corresponding characters in the several rows above and below are > present and easy to read. The following line is Ohed. with all the other > data being identical, which suggests that the handwritten index was > difficult to read when it was transcribed and the typeset version produced. > > >The only instances we've seen (so far) where this theory could be correct > is > >after Eliza and Obed - which could be a shortened form but are also names > in > >their own right > Quite right. My point is that there is ambiguity here, not that they ARE > abbreviations. Also, a search engine supporting wildcards, like already > exists on the FreeBMD site (or name aliasing or some other matching > technique) would easily find these two example cases. > > Mary Trevan > >

Brian Naming of files is shown in our Scan page documentation at: http://freebmd.rootsweb.com/scan-source2.html Which is visible to anyone who needs to download scans. When I set up a batch of new Syndicates (yours included) about 6 to 9 months ago I provided some temporary documentation because I realised there was a gap in suitable instructions on the FreeBMD site. My temporary instructions were then transferred to the official FreeBMD site, viz. http://freebmd.rootsweb.com/Synsetup.html If you believe there are deficiencies in these instruction, please let me know (via the DISCUSS list) I will leave Dave or Graham answer your final point, but from my simplistic understanding, collation of the files allows for a check to be made of any missing pages when we come to officially close a quarters worth of transcriptions. Allan Raymond [email protected] http://www.btinternet.com/~allan_raymond/Monarchies_of_Europe.htm FreeBMD - putting birth marriages and deaths on the Internet http://FreeBMD.rootsweb.com/ ----- Original Message ----- From: "Brian Smart" <[email protected]> To: <[email protected]> Sent: 28 October 2001 15:54 Subject: RE: +PAGE In answer to my comment: "For my own reasons I did not use the numbering system as in the September quarter, thus the March quarter has unique numbers for each file." Graham said: "My feeling about using your own numbering system is that we lose the opportunity of matching page to page when we come to match the double entry keying of that quarter so I would prefer that we all were consistent." It seems to me that nobody has thought through this issue and things have been left to the Coordinators. This is particularly the case when it comes to naming files. If definitive rules were specified, we would not be in the position where we are trying to formulate them after the work has been done. One of the obvious problems, from my point of view, is that as a coordinator I do not know the way the overall system works. While this may not concern all coordinators, I feel that if I don't know the system I can't be expected to make rational decisions. As a final comment, given that indexes are used to speed the process of answering peoples search queries what difference does it make which order the files are collated? Brian Smart > -----Original Message----- > From: Graham Hart [mailto:[email protected]] > Sent: 28 October 2001 14:57 > To: Brian Smart > Cc: [email protected] > Subject: Re: +PAGE > > > Hi Brian, > > Brian Smart wrote: > > > > Having moved the following to a different list, could I > please have an > > answer! > > You may have noticed its been somewhat busy today ! ... and > answers need > to be thought out .. I may not be the best person to answer a > particular > query ..... etcetcetc > > > > > > The explanation I was given regarding the need for > +PAGE,???? on the end of > > a file was as follows. > > The data compiler looks for the +PAGE entry to know which > is the next file > > in the sequence. I had no problems with that, and it seems perfectly > > logical. > > > > How is the following explained? > > > > In the 1845 births there are three strands of numbers all > starting from 1. > > Thus unless action is taken to avoid it, there will be > three files with the > > same +PAGE number at the end of the file. Although at > present +PAGE has not > > been added, two files that show this are 45B3A002 and 45B3J002. > > > > If the data compiler can overcome this, is +PAGE really needed? > > Yes, without the +PAGE we have no idea where a page starts > and ends and > can't easily identify missing pages. > > The +PAGE gives us checkpoints for the matching process. > > Where there are multiple strands of page numbers, I would have thought > that the alphabetical sequence would make it clear which was which .. > when the matching starts, the code should be able to warn > that the page > sequence dropped from z back to n or whatever. This can then be > investigated and checked. > > > For my own reasons I did not use the numbering system as in > the September > > quarter, thus the March quarter has unique numbers for each file. > > My feeling about using yor own numbering system is that we lose the > opportunity of matching page to page weh we come to match the double > entry keying of that quarter so I would prefer that we all were > consistent. However, I am not thinking clearly at the moment > (headache) > and have a nagging doubt on this ... Dave is probably better > positioned > to answer it when he returns to the fray. > > Cheers > > Graham > > > > > Regards > > > > Brian Smart > > > > ============================== > > Ancestry.com Genealogical Databases > > http://www.ancestry.com/rd/rwlist2.asp > > Search over 2500 databases with one easy query! > ============================== Visit Ancestry's Library - The best collection of family history learning and how-to articles on the Internet. http://www.ancestry.com/learn/library

Sue, At the risk of inflaming an already hot topic, I omitted to mention that the Obed. and Eliza. examples from my earlier email are actually from a marriage index, and co-incidentally from the same page as each other. >I could agree with the theory of a full stop showing an abbreviated name if >it wasn't for the following: > >1) They are only found on Death records not on Births or Marriages <SNIP> The point I was trying to make was not that they are abbreviations, but that we cannot know from the index alone whether they are abbreviated names or full names. The Obed. example, which is the first one I spotted, is on a particularly clear part of a print-out from a microfilm, and the 'missing alignment dots', if that is what they are, are not part of a stripe of damage down the film. The corresponding characters in the several rows above and below are present and easy to read. The following line is Ohed. with all the other data being identical, which suggests that the handwritten index was difficult to read when it was transcribed and the typeset version produced. >The only instances we've seen (so far) where this theory could be correct is >after Eliza and Obed - which could be a shortened form but are also names in >their own right Quite right. My point is that there is ambiguity here, not that they ARE abbreviations. Also, a search engine supporting wildcards, like already exists on the FreeBMD site (or name aliasing or some other matching technique) would easily find these two example cases. Mary Trevan