<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Finding Levi S Baker (or how to use new search interface to find him)</title>
	<atom:link href="http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him</link>
	<description>The official blog of Ancestry.com</description>
	<lastBuildDate>Tue, 21 May 2013 21:32:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: Anne Mitchell</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19883</link>
		<dc:creator>Anne Mitchell</dc:creator>
		<pubDate>Thu, 11 Sep 2008 17:56:03 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19883</guid>
		<description>Re, #98 and #99, New Search UI, Old Search UI, neither one is &quot;married to&quot; a tree search.  Both are purely record base searches, that have absolutely nothing to do with trees and how those records relate to any tree. Interesting theory, but not true.

Most records are keyed off of Names, and then dates and locations when that is available.  

&quot;New Fuzzy&quot; is only a label for the new search interface when you are  in basic and NOT advanced. If you go to advanced, you have a lot of different controls over what is exact and what is not.  And now that the exact bug has been fixed -- Fuzzy really only applies to basic. You have so much more control over what you choose to be exact or not.

I talk about marriages and why there are issues in my next post, &lt;a href=&quot;http://blogs.ancestry.com/ancestry/2008/09/10/what-i-learned-at-fgs-2008/&quot; rel=&quot;nofollow&quot;&gt;What I learned at FSG 2008...&lt;/a&gt;.

And with that I am closing this one down.</description>
		<content:encoded><![CDATA[<p>Re, #98 and #99, New Search UI, Old Search UI, neither one is &#8220;married to&#8221; a tree search.  Both are purely record base searches, that have absolutely nothing to do with trees and how those records relate to any tree. Interesting theory, but not true.</p>
<p>Most records are keyed off of Names, and then dates and locations when that is available.  </p>
<p>&#8220;New Fuzzy&#8221; is only a label for the new search interface when you are  in basic and NOT advanced. If you go to advanced, you have a lot of different controls over what is exact and what is not.  And now that the exact bug has been fixed &#8212; Fuzzy really only applies to basic. You have so much more control over what you choose to be exact or not.</p>
<p>I talk about marriages and why there are issues in my next post, <a href="http://blogs.ancestry.com/ancestry/2008/09/10/what-i-learned-at-fgs-2008/" rel="nofollow">What I learned at FSG 2008&#8230;</a>.</p>
<p>And with that I am closing this one down.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19635</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Wed, 10 Sep 2008 02:48:22 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19635</guid>
		<description>Another New Search strangeness.

Cecil Owens was born 1902 in Tennessee.  Gladys Underwood was born 1905 in Tennessee.  They were married in 1923 in Tennessee.  I have more details than that about their dates and places, but the details don&#039;t matter for this story.

I was looking for their 1930 census entry.  I started by already being in the 1930 census, and didn&#039;t do a generic search.  This was a real research task, not just an example I was putting together for the blog.

As is nearly always the case, I was using exact search.  Because Owens is often spelled Owen, I entered it as owen*.  I entered Cecil as cec*, just because I could even though Cecil is not often misspelled.  Because Gladys is often spelled strangely (e.g., Gladis, and numerous other variations), I entered her name as glad*, and there was no reason to enter her last name because her married name in the census should be Owens.  For her, I was dealing with a field that combined first name and last name, anyway.  Finally, I entered Cecil&#039;s birth information as 1902+/-5 in Tennessee.  The search box does not allow the entry of birth information for the second spouse.

There were no matches.  Numerous variations on this same basic theme failed to find the couple.  For example, leaving out the birth year and/or the birth place didn&#039;t help.  Leaving out Cecil&#039;s last name and keeping his first name didn&#039;t help.  Leaving out Cecil&#039;s first name and keeping his last name didn&#039;t help. Etc.

After about 45 minutes of trying lots of different searches and being very frustrated, I switched to old search, went to the 1930 census, and entered the data as described above.  There was a match immediately.  They were in Knox County, Kentucky.

It turns out that their names were spelled completely correctly by the census enumerator, and their names were indexed completely correctly by the indexer.  Armed with that knowledge, I went back to New Search and entered their complete information - Cecil Owens, born 1902+/-5 in Tennessee, spouse Gladys.  There was a match.  If I hadn&#039;t been so concerned about spelling variations the first time through New Search, I would have found them the first time through New Search.

A little experimentation revealed that the wildcards in Cecil&#039;s first name and last name were fine.  New Search ran into a problem with wildcards in Gladys&#039;s name, and wouldn&#039;t match if there were an * anywhere in her name.  No matter that glad* matches Gladys, New Search didn&#039;t like it.  I assume that&#039;s got to be a bug.

Until the bug is fixed, it&#039;s going to make certain searches much harder with New Search than they ought to be.  For example, what if the 1930 enumerator really had written her name as Gladis or Gladius or something like that?  If so, then it wouldn&#039;t have matched if I had entered gladys nor if I had entered glad*.</description>
		<content:encoded><![CDATA[<p>Another New Search strangeness.</p>
<p>Cecil Owens was born 1902 in Tennessee.  Gladys Underwood was born 1905 in Tennessee.  They were married in 1923 in Tennessee.  I have more details than that about their dates and places, but the details don&#8217;t matter for this story.</p>
<p>I was looking for their 1930 census entry.  I started by already being in the 1930 census, and didn&#8217;t do a generic search.  This was a real research task, not just an example I was putting together for the blog.</p>
<p>As is nearly always the case, I was using exact search.  Because Owens is often spelled Owen, I entered it as owen*.  I entered Cecil as cec*, just because I could even though Cecil is not often misspelled.  Because Gladys is often spelled strangely (e.g., Gladis, and numerous other variations), I entered her name as glad*, and there was no reason to enter her last name because her married name in the census should be Owens.  For her, I was dealing with a field that combined first name and last name, anyway.  Finally, I entered Cecil&#8217;s birth information as 1902+/-5 in Tennessee.  The search box does not allow the entry of birth information for the second spouse.</p>
<p>There were no matches.  Numerous variations on this same basic theme failed to find the couple.  For example, leaving out the birth year and/or the birth place didn&#8217;t help.  Leaving out Cecil&#8217;s last name and keeping his first name didn&#8217;t help.  Leaving out Cecil&#8217;s first name and keeping his last name didn&#8217;t help. Etc.</p>
<p>After about 45 minutes of trying lots of different searches and being very frustrated, I switched to old search, went to the 1930 census, and entered the data as described above.  There was a match immediately.  They were in Knox County, Kentucky.</p>
<p>It turns out that their names were spelled completely correctly by the census enumerator, and their names were indexed completely correctly by the indexer.  Armed with that knowledge, I went back to New Search and entered their complete information &#8211; Cecil Owens, born 1902+/-5 in Tennessee, spouse Gladys.  There was a match.  If I hadn&#8217;t been so concerned about spelling variations the first time through New Search, I would have found them the first time through New Search.</p>
<p>A little experimentation revealed that the wildcards in Cecil&#8217;s first name and last name were fine.  New Search ran into a problem with wildcards in Gladys&#8217;s name, and wouldn&#8217;t match if there were an * anywhere in her name.  No matter that glad* matches Gladys, New Search didn&#8217;t like it.  I assume that&#8217;s got to be a bug.</p>
<p>Until the bug is fixed, it&#8217;s going to make certain searches much harder with New Search than they ought to be.  For example, what if the 1930 enumerator really had written her name as Gladis or Gladius or something like that?  If so, then it wouldn&#8217;t have matched if I had entered gladys nor if I had entered glad*.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19608</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Wed, 10 Sep 2008 01:18:41 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19608</guid>
		<description>So, after a couple of months reading that things have been somewhat corrected, I give New Fuzzy Almost-A-Search-Function another try.

I enter, all exact, the information for my father, with &quot;tell us more to getter better results&quot; and all.  I&#039;m pretty sure he existed, but New Fuzzy tells me that he didn&#039;t.

So I uncheck &quot;match all terms exactly&quot; and try again.

Now I get 74,853 hits, sorted by category.  Maybe Dad did live after all.  But 74,853 is way too much to scroll through, so I change the &quot;view&quot; to &quot;sorted by relevance&quot;.

Now I have 68,566 &quot;matches&quot; listed.  Apparently even Fuzzy Search realizes that 6,287 of those previous hits weren&#039;t exactly relevant.

I am not convinced anything has improved here.</description>
		<content:encoded><![CDATA[<p>So, after a couple of months reading that things have been somewhat corrected, I give New Fuzzy Almost-A-Search-Function another try.</p>
<p>I enter, all exact, the information for my father, with &#8220;tell us more to getter better results&#8221; and all.  I&#8217;m pretty sure he existed, but New Fuzzy tells me that he didn&#8217;t.</p>
<p>So I uncheck &#8220;match all terms exactly&#8221; and try again.</p>
<p>Now I get 74,853 hits, sorted by category.  Maybe Dad did live after all.  But 74,853 is way too much to scroll through, so I change the &#8220;view&#8221; to &#8220;sorted by relevance&#8221;.</p>
<p>Now I have 68,566 &#8220;matches&#8221; listed.  Apparently even Fuzzy Search realizes that 6,287 of those previous hits weren&#8217;t exactly relevant.</p>
<p>I am not convinced anything has improved here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reed</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19479</link>
		<dc:creator>Reed</dc:creator>
		<pubDate>Mon, 08 Sep 2008 20:24:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19479</guid>
		<description>Anne,

Jade&#039;s recent comment (#98) offers a very plausible hypothesis that would explain a number of fundamental problems with New Search.

Is Jade correct?  Is New Search more-or-less wedded to Ancestry&#039;s (or the individual users&#039;) collection of family trees?  

Do tree-focused search criteria take priority over database/index-focused search criteria?

Inquiring minds want to know…

—Reed</description>
		<content:encoded><![CDATA[<p>Anne,</p>
<p>Jade&#8217;s recent comment (#98) offers a very plausible hypothesis that would explain a number of fundamental problems with New Search.</p>
<p>Is Jade correct?  Is New Search more-or-less wedded to Ancestry&#8217;s (or the individual users&#8217;) collection of family trees?  </p>
<p>Do tree-focused search criteria take priority over database/index-focused search criteria?</p>
<p>Inquiring minds want to know…</p>
<p>—Reed</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jade</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19468</link>
		<dc:creator>Jade</dc:creator>
		<pubDate>Mon, 08 Sep 2008 16:34:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19468</guid>
		<description>Jerry in #94 made an excellent distinction regarding meaning of dates (events rather than range in life-path), expanding the issue pointed to by Reed in #63.

I think the problem in a Global search, (of New Fuzzy&#039;s not finding numerous databases in which target persons do appear) is related to this.

I think the underlying reason is that New Fuzzy was based on a Tree search.  Trees typically consign data on people other than event dates to notes and added links to transcripts or document images on Ancestry.

This is why Anne posted an item in her #67 regarding how the search engine should interpret place-names combining commas.  This particular issue is due to the flawed gedcom code shortcut regarding place names.

This Tree orientation is the reason that New Fuzzy has trouble interpreting vital dates as date-ranges for data in database indexes and for actual date ranges of particular databases.  Such databases as the 1860s IRS reports do not appear to have the dates of the reports *indexed*, and New Fuzzy cannot find them as having relevance to the Event Dates.

This is an indexing problem for New Fuzzy, but not for Old Search, which by and large is not dependent upon Event Dates.

Those who have not posted Trees on Ancestry.com which New Fuzzy can use as a search basis, who are doing database research on persons who may or may not be related to their or anyone else&#039;s Ancestry.com tree, or who are looking for types of records other than BMDs, will not find the New Fuzzy approach very user-friendly.

Those who are searching mainly for records 1620-1870 will also find New Fuzzy not very congenial because Ancestry&#039;s database of BMD records in this period is quite limited.  The concept that &#039;nunmber of hits in a database&#039; is a sign of value based on same-surname *or* same first name, is what produces the ridiculous unrelated-date search results from such items as the England and Wales BMD indexes.</description>
		<content:encoded><![CDATA[<p>Jerry in #94 made an excellent distinction regarding meaning of dates (events rather than range in life-path), expanding the issue pointed to by Reed in #63.</p>
<p>I think the problem in a Global search, (of New Fuzzy&#8217;s not finding numerous databases in which target persons do appear) is related to this.</p>
<p>I think the underlying reason is that New Fuzzy was based on a Tree search.  Trees typically consign data on people other than event dates to notes and added links to transcripts or document images on Ancestry.</p>
<p>This is why Anne posted an item in her #67 regarding how the search engine should interpret place-names combining commas.  This particular issue is due to the flawed gedcom code shortcut regarding place names.</p>
<p>This Tree orientation is the reason that New Fuzzy has trouble interpreting vital dates as date-ranges for data in database indexes and for actual date ranges of particular databases.  Such databases as the 1860s IRS reports do not appear to have the dates of the reports *indexed*, and New Fuzzy cannot find them as having relevance to the Event Dates.</p>
<p>This is an indexing problem for New Fuzzy, but not for Old Search, which by and large is not dependent upon Event Dates.</p>
<p>Those who have not posted Trees on Ancestry.com which New Fuzzy can use as a search basis, who are doing database research on persons who may or may not be related to their or anyone else&#8217;s Ancestry.com tree, or who are looking for types of records other than BMDs, will not find the New Fuzzy approach very user-friendly.</p>
<p>Those who are searching mainly for records 1620-1870 will also find New Fuzzy not very congenial because Ancestry&#8217;s database of BMD records in this period is quite limited.  The concept that &#8216;nunmber of hits in a database&#8217; is a sign of value based on same-surname *or* same first name, is what produces the ridiculous unrelated-date search results from such items as the England and Wales BMD indexes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reed</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19435</link>
		<dc:creator>Reed</dc:creator>
		<pubDate>Mon, 08 Sep 2008 06:43:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19435</guid>
		<description>Rather than fill up more column inches with more of my experiences, let me just say that my New Search experiences (re Levi S. Baker) have been 100% the same as Jerry Bryan&#039;s in #95 &amp; #97 (among other examples). 

FYI, other sources that New Search does NOT find include a number of interesting leads in what Old Search categorized (separately) as &quot;Stories &amp; Publications.&quot; One of my favorite finds was in A.T. Andreas&#039;s &quot;History of Chicago&quot; in the informative chapter on the Grain business, including a reference to &quot;old Mr. Baker,&quot; an expert on Chicago&#039;s grain elevators.  

[Admittedly, I did not find this reference with an Exact &quot;Levi S. Baker&quot; search; I know Levi B. had worked in the grain business and I searched for Name=Baker and Keywords=grain, elevator, Chicago.  The point is, this was very quick and easy to do in Old Search.]

New Search also fails to find the Chicago Tribune obits of Levi S. Baker or his wife Lucetta (in which Levi S. Baker is named).  Both were found with Old Search in the collection of  &quot;Historical Newspapers, Birth, Marriage, &amp; Death Announcements, 1851-2003.&quot;  (Perhaps they can be located via New Search, but not by me!)

Which brings me back to a real (non-metaphorical) sore point:  New Search is a pain in the fingers to navigate!  Fellow-blogger Jim wrote (#78):

&quot;Now here is where I have a problem with the old search: Suppose I want to examine other candidates in a particular census year. I filter to that year. Good. But if I want to refine my search, I find that the search box only kept the name. All of the other criteria is empty.&quot;

On the one hand, Jim is correct, in focusing on a particular census year (having already searched for &quot;Levi Baker,&quot;  In &quot;Illinois&quot; for example), &quot;Levi&quot; and &quot;Baker&quot; and &quot;Illinois&quot; SHOULD be filled in automatically.  Why this is not so is a mystery but—for me—only a minor annoyance since (1) the search boxes will continue to auto-fill after I re-type the info for the first detailed search of this database and (2)  ALL the search fields AND the Exact/Soundex pull down menu are easily accessible and selectable with the TAB, ARROW and RETURN keys.  No pointing and mouse-clicking.  AND, if any of the search fields are out of view, they automatically scroll into view as I TAB from field to field.

Jim also remarked:  &quot;I also dislike the (refine) search box at the bottom of the page. I prefer to see my search criteria along side the results.&quot;

I would be less picky about this if—and it&#039;s a big if— ALL the search fields were visible at least most of the time.  For me, even on my 22&quot; monitor, this is NEVER the case with New Search; instead it&#039;s scroll-up &amp; scroll-down, over and over and over again… Old Search search fields (*and results*) are displayed in a much more compact &amp; economical layout.

Another nice thing about the Old Search advanced/detailed layout (at the bottom of the screen) is that I can access all the available search fields with a quick press of the END key on my keyboard, type my search parameter changes, hit RETURN and look at my results, scan through them with the UP and DOWN arrows, HOME &amp; END keys and repeat as needed.  I can change search parameters quickly, with many fewer keystrokes and hardly any mouse-clicks.  It&#039;s faster, more ergonomic and much, much more productive per unit of time worked.

Cheers,
—Reed</description>
		<content:encoded><![CDATA[<p>Rather than fill up more column inches with more of my experiences, let me just say that my New Search experiences (re Levi S. Baker) have been 100% the same as Jerry Bryan&#8217;s in #95 &amp; #97 (among other examples). </p>
<p>FYI, other sources that New Search does NOT find include a number of interesting leads in what Old Search categorized (separately) as &#8220;Stories &amp; Publications.&#8221; One of my favorite finds was in A.T. Andreas&#8217;s &#8220;History of Chicago&#8221; in the informative chapter on the Grain business, including a reference to &#8220;old Mr. Baker,&#8221; an expert on Chicago&#8217;s grain elevators.  </p>
<p>[Admittedly, I did not find this reference with an Exact "Levi S. Baker" search; I know Levi B. had worked in the grain business and I searched for Name=Baker and Keywords=grain, elevator, Chicago.  The point is, this was very quick and easy to do in Old Search.]</p>
<p>New Search also fails to find the Chicago Tribune obits of Levi S. Baker or his wife Lucetta (in which Levi S. Baker is named).  Both were found with Old Search in the collection of  &#8220;Historical Newspapers, Birth, Marriage, &amp; Death Announcements, 1851-2003.&#8221;  (Perhaps they can be located via New Search, but not by me!)</p>
<p>Which brings me back to a real (non-metaphorical) sore point:  New Search is a pain in the fingers to navigate!  Fellow-blogger Jim wrote (#78):</p>
<p>&#8220;Now here is where I have a problem with the old search: Suppose I want to examine other candidates in a particular census year. I filter to that year. Good. But if I want to refine my search, I find that the search box only kept the name. All of the other criteria is empty.&#8221;</p>
<p>On the one hand, Jim is correct, in focusing on a particular census year (having already searched for &#8220;Levi Baker,&#8221;  In &#8220;Illinois&#8221; for example), &#8220;Levi&#8221; and &#8220;Baker&#8221; and &#8220;Illinois&#8221; SHOULD be filled in automatically.  Why this is not so is a mystery but—for me—only a minor annoyance since (1) the search boxes will continue to auto-fill after I re-type the info for the first detailed search of this database and (2)  ALL the search fields AND the Exact/Soundex pull down menu are easily accessible and selectable with the TAB, ARROW and RETURN keys.  No pointing and mouse-clicking.  AND, if any of the search fields are out of view, they automatically scroll into view as I TAB from field to field.</p>
<p>Jim also remarked:  &#8220;I also dislike the (refine) search box at the bottom of the page. I prefer to see my search criteria along side the results.&#8221;</p>
<p>I would be less picky about this if—and it&#8217;s a big if— ALL the search fields were visible at least most of the time.  For me, even on my 22&#8243; monitor, this is NEVER the case with New Search; instead it&#8217;s scroll-up &amp; scroll-down, over and over and over again… Old Search search fields (*and results*) are displayed in a much more compact &amp; economical layout.</p>
<p>Another nice thing about the Old Search advanced/detailed layout (at the bottom of the screen) is that I can access all the available search fields with a quick press of the END key on my keyboard, type my search parameter changes, hit RETURN and look at my results, scan through them with the UP and DOWN arrows, HOME &amp; END keys and repeat as needed.  I can change search parameters quickly, with many fewer keystrokes and hardly any mouse-clicks.  It&#8217;s faster, more ergonomic and much, much more productive per unit of time worked.</p>
<p>Cheers,<br />
—Reed</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19432</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Mon, 08 Sep 2008 05:06:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19432</guid>
		<description>Re: Mark B&#039;s #96.  There seems to be a problem in searching for all records for Levi Baker in Illinois from 1827 to 1910 with New Search.  Either you have to omit dates from your search criteria altogether, which typically will make the search too expansive.  Or you have to give something like a birth date or a death date, which typically will fail to show many, many databases where the records themselves have dates but where the records do not include a birth date or a death date.

I&#039;ve not found a way with New Search to give dates for records, only dates for events such as births, marriages, and deaths.  &lt;b&gt;Is there is a New Search way to accomplish the search I described in #95, namely records in Illinois for Levi Baker from 1827 to 1910?&lt;/b&gt;  

The Lived In search box is the best candidate, but it does not include a date range.  Besides which, I just did an exact search with New Search for Levi Baker and Lived in Illinois, USA, and it failed to find the IRS database and numerous other databases found with Old Search.  The only way to get the IRS database to show up with an exact search was to search for Levi Baker with nothing else at all, not even the Lived in Illinois.</description>
		<content:encoded><![CDATA[<p>Re: Mark B&#8217;s #96.  There seems to be a problem in searching for all records for Levi Baker in Illinois from 1827 to 1910 with New Search.  Either you have to omit dates from your search criteria altogether, which typically will make the search too expansive.  Or you have to give something like a birth date or a death date, which typically will fail to show many, many databases where the records themselves have dates but where the records do not include a birth date or a death date.</p>
<p>I&#8217;ve not found a way with New Search to give dates for records, only dates for events such as births, marriages, and deaths.  <b>Is there is a New Search way to accomplish the search I described in #95, namely records in Illinois for Levi Baker from 1827 to 1910?</b>  </p>
<p>The Lived In search box is the best candidate, but it does not include a date range.  Besides which, I just did an exact search with New Search for Levi Baker and Lived in Illinois, USA, and it failed to find the IRS database and numerous other databases found with Old Search.  The only way to get the IRS database to show up with an exact search was to search for Levi Baker with nothing else at all, not even the Lived in Illinois.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark B</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19427</link>
		<dc:creator>Mark B</dc:creator>
		<pubDate>Mon, 08 Sep 2008 03:38:37 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19427</guid>
		<description>As was stated in #95, &lt;i&gt;&quot;Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918.&quot;&lt;/i&gt;
I thought the search automatically searches every category (as in &quot;all categories&quot;)  Am I missing something?</description>
		<content:encoded><![CDATA[<p>As was stated in #95, <i>&#8220;Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918.&#8221;</i><br />
I thought the search automatically searches every category (as in &#8220;all categories&#8221;)  Am I missing something?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Bryan</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19423</link>
		<dc:creator>Jerry Bryan</dc:creator>
		<pubDate>Mon, 08 Sep 2008 03:03:44 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19423</guid>
		<description>My sense is that this thread is close to being closed out, and Anne is likely to post a new example fairly soon.  To that end, I want to reinforce one particular thing that Reed said in #63.  Reed made numerous good points in #63, but I want to hone in on the following:

&lt;i&gt;I rather like Old Search’s starting and ending date-categories being labeled “Year Range,” rather than “Birth” and “Death.” Imperfect as Old Search is, it seems to do a much better job at including useful information and excluding off-target databases with these starting and ending Year Ranges. Perhaps us “Exact Searchers” need the ability to specify starting and ending dates for the *records* in addition to (or instead of) exact (or probable) dates of birth and death. As it is, New Search is hopelessly inept at this.&lt;/i&gt;

Irrespective of all the other problems with New Search, the loss of the functionality described in Reed&#039;s paragraph above is perhaps the greatest deficiency in New Search as compared to Old Search.  So let&#039;s do the Levi S. Baker example in that style.  Old Search, exact, search for Levi Baker (not Levi S. Baker), lived in USA, state Illinois (can&#039;t refine it down to Chicago or Cook County, which is ok for our purposes), year range 1827 to 1910.

Such a search typically yields a goodly number of false positives, and the search for Levi Baker certainly does.  But the total number of matches is typically quite manageable, and it is manageable in the search for Levi Baker.  The false positives are a very good trade off for the expansive list of databases that usually show up, especially since the overall number of matches is manageable.

In this case, there is 1 match in 1850, not our guy (the L. S. Baker problem).  There are 3 matches in 1860, and it&#039;s easy to eyeball which one is our guy.  There are 5 matches in 1870, and it&#039;s easy to eyeball which on is our guy.  Etc.

But more importantly, there are matches for Illinois marriages, which I might not have thought to look in.  In this particular case, none of the matches appear to be our guy, but it&#039;s easy to determine that our guy is not there, and it&#039;s good information to know.

Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918.  I think the match is our guy.  As interesting as the match might be, it does not appear to me to provide any data that would very much advance our research on Levi S. Baker.  But I have found this database extremely valuable for rural counties because for rural counties it usually lists the number of acres the person owned.  One of the mantras for difficult research problems is &quot;follow the land&quot;, which typically means things like land grants, deeds, and tax records.  But given the number of counties I research where the courthouse was destroyed by fire or that was destroyed in the Civil War, any extra land record can be a godsend.  I never would have thought of looking in the IRS Tax Assessment database for Levi S. Baker unless it had shown up in the Old Search version of exact search.

There are other databases that show up in this manner from time to time as well.  As Reed said, you really can&#039;t accomplish the same kind of search with New Search no matter what you do (or at least if you can, I haven&#039;t figured out how to do it).</description>
		<content:encoded><![CDATA[<p>My sense is that this thread is close to being closed out, and Anne is likely to post a new example fairly soon.  To that end, I want to reinforce one particular thing that Reed said in #63.  Reed made numerous good points in #63, but I want to hone in on the following:</p>
<p><i>I rather like Old Search’s starting and ending date-categories being labeled “Year Range,” rather than “Birth” and “Death.” Imperfect as Old Search is, it seems to do a much better job at including useful information and excluding off-target databases with these starting and ending Year Ranges. Perhaps us “Exact Searchers” need the ability to specify starting and ending dates for the *records* in addition to (or instead of) exact (or probable) dates of birth and death. As it is, New Search is hopelessly inept at this.</i></p>
<p>Irrespective of all the other problems with New Search, the loss of the functionality described in Reed&#8217;s paragraph above is perhaps the greatest deficiency in New Search as compared to Old Search.  So let&#8217;s do the Levi S. Baker example in that style.  Old Search, exact, search for Levi Baker (not Levi S. Baker), lived in USA, state Illinois (can&#8217;t refine it down to Chicago or Cook County, which is ok for our purposes), year range 1827 to 1910.</p>
<p>Such a search typically yields a goodly number of false positives, and the search for Levi Baker certainly does.  But the total number of matches is typically quite manageable, and it is manageable in the search for Levi Baker.  The false positives are a very good trade off for the expansive list of databases that usually show up, especially since the overall number of matches is manageable.</p>
<p>In this case, there is 1 match in 1850, not our guy (the L. S. Baker problem).  There are 3 matches in 1860, and it&#8217;s easy to eyeball which one is our guy.  There are 5 matches in 1870, and it&#8217;s easy to eyeball which on is our guy.  Etc.</p>
<p>But more importantly, there are matches for Illinois marriages, which I might not have thought to look in.  In this particular case, none of the matches appear to be our guy, but it&#8217;s easy to determine that our guy is not there, and it&#8217;s good information to know.</p>
<p>Another database of interest which I might not have thought to look in is the U.S. IRS Tax Assessment Lists, 1862-1918.  I think the match is our guy.  As interesting as the match might be, it does not appear to me to provide any data that would very much advance our research on Levi S. Baker.  But I have found this database extremely valuable for rural counties because for rural counties it usually lists the number of acres the person owned.  One of the mantras for difficult research problems is &#8220;follow the land&#8221;, which typically means things like land grants, deeds, and tax records.  But given the number of counties I research where the courthouse was destroyed by fire or that was destroyed in the Civil War, any extra land record can be a godsend.  I never would have thought of looking in the IRS Tax Assessment database for Levi S. Baker unless it had shown up in the Old Search version of exact search.</p>
<p>There are other databases that show up in this manner from time to time as well.  As Reed said, you really can&#8217;t accomplish the same kind of search with New Search no matter what you do (or at least if you can, I haven&#8217;t figured out how to do it).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nancy Rogers</title>
		<link>http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19417</link>
		<dc:creator>Nancy Rogers</dc:creator>
		<pubDate>Mon, 08 Sep 2008 00:47:41 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.ancestry.com/ancestry/2008/08/25/finding-levi-s-baker-or-how-to-use-new-search-interface-to-find-him/#comment-19417</guid>
		<description>I have a question about the way that ancestry has set up it&#039;s new main page.  What good does it do to have a box that supposely shows what records have recently been added when the last record that it currently shows is the US Public Records index which was updated on August 30, 2008, while when you go to the labled &quot;Genealogy Databases Posted or Updated Recently&quot; there have been over 20 other new databases added since August 30, 2008?  Why can they not automically update the small box on the main page when they add the databases to the main data base page?  Again is this an effort to minimize the importance of various data bases.  Here we are again back to the problem of acquiring and updating and indexing correctly the data bases versus spending money on getting new members.</description>
		<content:encoded><![CDATA[<p>I have a question about the way that ancestry has set up it&#8217;s new main page.  What good does it do to have a box that supposely shows what records have recently been added when the last record that it currently shows is the US Public Records index which was updated on August 30, 2008, while when you go to the labled &#8220;Genealogy Databases Posted or Updated Recently&#8221; there have been over 20 other new databases added since August 30, 2008?  Why can they not automically update the small box on the main page when they add the databases to the main data base page?  Again is this an effort to minimize the importance of various data bases.  Here we are again back to the problem of acquiring and updating and indexing correctly the data bases versus spending money on getting new members.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
