Why do online searches provide so much shrapnel?
Steve Stone
I work with desktop, server and legacy databases, tables, as well as GIS
(geocoding).
Once I get to understand a table or database structure and rules I can
usually write the SQL
needed to get exactly or very close to the answers I was looking for.
Why do online sites like LDS and Ancestry continue to implement
a user front end that creates vague queries that result in thousands of
useless lines of data that do not
come close to the searchers intentions, or lock you into exact spelling
that you know will not help because you
have seen your ancestors surname spelled 12 different ways.. or why
can't I search on a mother and father combination in LDS and come up
with the children? Sometimes I find a mother and father, I know they are
correct, but I can not directly search for them, probably because those
fields are not indexed. I'd love to exclude a couple of tables in some
of my searches at these sites, but there seems to be no easy way to
exclude tables or drill down into the data without plodding thru slowly
refreshing screens.
This is so very crude and rudimentary for the year 2010.
The only excuse a pay per view site has for this is you might have
subscribers hanging on for more months if you bury them in horse pucky.
Ten years ago even AltaVista would let you write some boolean as a
search argument.
Sorry, frustrated over the marketing hype o some sites and then weeding
thru the reality.
saki
> Why do online sites like LDS and Ancestry continue to implement
> a user front end that creates vague queries that result in thousands of
> useless lines of data that do not
> come close to the searchers intentions....
You can delimit by date, type of record, age of individual, country of
origin, etc. Does this help with your searches?
> ...or lock you into exact spelling
> that you know will not help because you
> have seen your ancestors surname spelled 12 different ways.
The wildcard feature isn't as flexible as one would like, certainly, and
Soundex is often too broad.
> ...or why
> can't I search on a mother and father combination in LDS and come up
> with the children?
You can, but you need to be in the IGI database and use the father's
full name, the mother's first, leave the child's name blank, and specify
the country of origin. If your data has been transcribed from microfilm
records you'll find it with the film number sourced, no guarantees though.
> Sorry, frustrated over the marketing hype o some sites and then weeding
> thru the reality.
I understand. I think the needs of the sophisticated user has outpaced
the abilities of the programmers at LDS and ancestry.com sites.
Al Lenkner
I don't have your experience. I did work on a GIS system 20 years
ago and computers have been my hobby for over 30 years but I agree
with you 100% as to the stupidity of the search engines. I'm not
sure that your reason is valid. Rather I suspect that they don't pay
their programmers much more than minimum and you know the old
maxim....... "You only get what you pay for. " Unfortunately,
while not paying much for the opportunity, we do pay in time wasted.
Al
>-------------------------------
>To unsubscribe from the list, please send an email to
>GENCMP-...@rootsweb.com with the word 'unsubscribe' without the
>quotes in the subject and the body of the message
>Content-Type: multipart/alternative;
> boundary="=======AVGMAIL-0A7D1AC1======="
>
>
>--=======AVGMAIL-0A7D1AC1=======--
>
>No virus found in this incoming message.
>Checked by AVG - www.avg.com
>Version: 9.0.716 / Virus Database: 270.14.105/2561 - Release Date:
>12/12/09 14:39:00
Ian Goddard
> Steve Stone wrote:
>> ...or why can't I search on a mother and father combination in LDS and
>> come up with the children?
>
> You can, but you need to be in the IGI database and use the father's
> full name, the mother's first, leave the child's name blank, and specify
> the country of origin. If your data has been transcribed from microfilm
> records you'll find it with the film number sourced, no guarantees though.
But there are, however, some stupidities about this. If you know that
the parents were living in, say, the last quarter of the C18th it would
be sensible if you could restrict the search to that time. If you knew
they were living in a particular county it would be sensible if you
could restrict the search to that county. But the search entry screen
throws a hissy fit if you try to do either of these things. The result,
as the OP put it, is shrapnel.
It used to be possible to put in simply a surname, dates and county. I
found that useful for mapping surname distributions at a given time
which could be quite informative (for instance in the first 40 years of
PRs the Goddard surname, outside of the inevitable London blob) occurred
mostly in 4 geographic clusters, not at all what I expected. Now you
can't do that, you have to provide a Christian name as well.
--
Ian
The Hotmail address is my spam-bin. Real mail address is iang
at austonley org uk
Ian Goddard
> It used to be possible to put in simply a surname, dates and county [on IGI]. I
> which could be quite informative (for instance in the first 40 years of
> PRs the Goddard surname, outside of the inevitable London blob) occurred
> mostly in 4 geographic clusters, not at all what I expected. Now you
> can't do that, you have to provide a Christian name as well.
Actually, thinking about that some more I remember that it always did
require an entry for a first name but you could supply an asterisk as a
wild card. Now you get the response "Do not use only punctuation marks
in searches. However, you can use apostrophes, hyphens, and periods with
letters."
Bob LeChevalier
>> ...or lock you into exact spelling
>> that you know will not help because you
>> have seen your ancestors surname spelled 12 different ways.
>
>The wildcard feature isn't as flexible as one would like, certainly, and
> Soundex is often too broad.
LDS's fuzzy search seems to be better than Soundex.
>> ...or why
>> can't I search on a mother and father combination in LDS and come up
>> with the children?
>
>You can, but you need to be in the IGI database and use the father's
>full name, the mother's first, leave the child's name blank, and specify
>the country of origin. If your data has been transcribed from microfilm
>records you'll find it with the film number sourced, no guarantees though.
Note that LDS has been developing an entirely new search function -
actually two of them. One can be used on the pilot.familysearch.org
website (which has a link on the main homepage as a "prototype", I
believe). It has no restriction of what fields you have to fill in.
In the as-yet-nonpublic new.familysearch.org (only church members have
access now, though it will eventually be opened to all), which will
eventually replace the main search function, you have the same kind of
search functionality, but it searches all the church's accumulated
tree data, and does so in a way that greatly reduces the duplicate
problem - and the design has been targetted to eventually reduce it
further.
The rollout has been very slow, because they are still developing it,
and because the millions of Mormons are already an enormous load
volume.
I believe that both LDS and ancestry share the same problem - possibly
among the highest number of users of any database system of that kind,
and the fact that those users are for the most part entirely
untrained.
The kind of search engine most useful for a serious researcher who
knows computers and database technology is a lot different from the
kind designed for random dilettantes who are still intimidated by
computers, and don't know how to do anything online beyond email (and
some not even that). And unfortunately that is the dominant portion
of their audience.
>> Sorry, frustrated over the marketing hype o some sites and then weeding
>> thru the reality.
>
>I understand. I think the needs of the sophisticated user has outpaced
>the abilities of the programmers at LDS and ancestry.com sites.
Ancestry has once or twice in their user questionnaires asked about
allowing full wild-card searches (instead of the limitation that you
provide the first three characters), which suggests that it is
technologically possible. But the fact that they haven't done so also
suggests that either the demand isn't that high or that it is
sufficiently difficult a challenge as to not yet be cost-effective to
implement.
Both ancestry and LDS are going through a phase of enormously
increasing the amount of data available. LDS is putting much of its
microfilm library online, and ancestry is getting some of that as well
by teaming up on the indexing. I suspect that the technological
problems of expanding their data volume by orders of magnitude is
taking precedence over the improvement of search technology.
lojbab
---
Bob LeChevalier - artificial linguist; genealogist
loj...@lojban.org Lojban language www.lojban.org
Ian Goddard
> Note that LDS has been developing an entirely new search function -
> In the as-yet-nonpublic new.familysearch.org ... searches all the church's accumulated
> tree data
Does this mean it will consist /entirely/ of member submissions or
similar, often imaginative, reconstructions?
Bob LeChevalier
>Bob LeChevalier wrote:
>> Note that LDS has been developing an entirely new search function -
>> actually two of them.....
>> In the as-yet-nonpublic new.familysearch.org ... searches all the church's accumulated
>> tree data
>
>Does this mean it will consist /entirely/ of member submissions or
>similar, often imaginative, reconstructions?
Newfamilysearch at present only searches member submissions, but
greatly improves on the existing system by allowing and documenting
challenges to information, and direct comparison of conflicting info,
encouraging proper sourcing (though I think they need to improve this
aspect - it is cumbersome to enter source info now, and there is no
repeat function).
It doesn't eliminate the imaginative data (and indeed they say nothing
will ever be removed), but it does start a weeding process so that
eventually I presume the better stuff will float to the top. But I am
not sure exactly how the search algorithm works underneath, having
used the program only a little bit.
The small amounts of *new* tree information that I've seen added by
people under the new system seems to be of better quality than the
older bulk submissions. But then the people I've seen at the local
center using the new system are mostly serious researchers.
You may be able to go to your local family history center and someone
can show you how it works, even though only members can get accounts
so far. (I'm not sure that all LDS regions have been given access
yet).
The pilot family search site (which the public can use already)
includes NO submitted trees, only microfilmed data, not all of which
has been indexed - they add a new chunk of data every couple of weeks.
If they've put up a database that is useful to you, it is very useful
indeed.
I assume that at some point, the two search pages will be integrated
so that one can search both kinds of data from one screen, but again I
haven't seen much on future plans.
(I've only been using newfamily search for a couple of weeks, and only
intermittently at that, but the pilot site has been useful for more
than a year - again if they've put data you are interested in into the
mix - you can see what databases they have and the date ranges for
each and thus judge for yourself).
Mick
> Steve,
>
> I don't have your experience. I did work on a GIS system 20 years ago
> and computers have been my hobby for over 30 years but I agree with you
> 100% as to the stupidity of the search engines. I'm not sure that your
> reason is valid. Rather I suspect that they don't pay their programmers
> much more than minimum and you know the old maxim....... "You only get
> what you pay for. " Unfortunately, while not paying much for the
> opportunity, we do pay in time wasted.
>
> Al
singhals
> saki <sa...@ucla.edu> wrote:
>
>>>...or lock you into exact spelling
>>>that you know will not help because you
>>>have seen your ancestors surname spelled 12 different ways.
>>
>>The wildcard feature isn't as flexible as one would like, certainly, and
>> Soundex is often too broad.
>
>
> LDS's fuzzy search seems to be better than Soundex.
>
>
LDS spent time, effort, and money inventing their own twist
on Soundex so it considers letter-placement as well as
letter-value.
The current search engines are working for a majority of the
users the majority of the time. As A. Lincoln alledged
said, you can't please all the people all the time. And if
either site has to choose between suiting the high-end users
and putting more data on-line, I know where my vote goes.
(g) In a halycon world, they'd ask us before they did
anything (oh, wait, Ged 5.0... ), but welcome to reality.
Cheryl
Al Lenkner
Mick,
Who said anything about the monkeys being "trained"?
Al
>-------------------------------
>To unsubscribe from the list, please send an email to
>GENCMP-...@rootsweb.com with the word 'unsubscribe' without the
>quotes in the subject and the body of the message
>Content-Type: multipart/alternative;
> boundary="=======AVGMAIL-395726BD======="
>
>
>--=======AVGMAIL-395726BD=======--
Ian Goddard
> Note that LDS has been developing an entirely new search function -
> actually two of them. One can be used on the pilot.familysearch.org
> website (which has a link on the main homepage as a "prototype", I
> believe). It has no restriction of what fields you have to fill in.
This is geographically challenged in my experience. Take, for instance,
the parishes of Kirkburton & Almondbury. They were historically in the
West Riding of Yorkshire but Yorkshire would be accurate if less
precise; in fact Yorkshire is the only version in the old search.
Official records will sometimes describe Yorkshire as "County of York".
Note "County of"; *not* to be confused with just plain "York" which is
a city. In 1974 government meddling reorganised counties so those
parishes are now in West Yorkshire and York the *city* is in North
Yorkshire.
What happens if I put in a name and a date range of 1700 - 1800?
When I type either parish name I then get a drop-down box offering me a
selection of the parish as being in
Yorkshire (first selection)
York
York, North Yorkshire
West Yorkshire.
In the second of these "York" turns out to mean "County of York" (see
below) but looks as if the city is meant although neither parish is
anywhere near it. The last, for the given date range, is an
anachronism. The third is worse, not only is it an anachronism but
someone dealing with the indexing of places has confused the county and
city and then, because the city is in modern North Yorkshire,
transplanted the parishes there.
If I choose the first of the four alternatives I get no hits. I only
get them on the second alternative which one might be inclined to ignore
if the apparent first choice has nothing.
OK, I can sort out that lot because I know the area. But what sort of
traps are lying in wait for me in areas with which I'm unfamiliar if I
use the pilot?
LDS have churches all over the place. In this particular case the
nearest is in Huddersfield, maybe about 10 miles from the most distant
part of either parish. Why don't they run their geographical
attributions past someone in a local church? If the database design is
anything like properly normalised they don't have to look at each
baptism in the parishes - just the entries in the location table.
Ian Goddard
> LDS spent time, effort, and money inventing their own twist on Soundex
> so it considers letter-placement as well as letter-value.
It also knows about diminutives, e.g. Elizabeth & Betty which can be
useful. Mind you, our ancestors coul still fool it without investing
any time, effort or money especially with surnames - who would have
thought that Kenworthy & Kennerley were synonyms?
>
> And if either site has to choose between
> suiting the high-end users and putting more data on-line, I know where
> my vote goes.
It's a trade-off that doesn't have to exist. As I've said in another
post you used to be able to put in wild cards in IGI searches and to be
able to use more restrictive filters in circumstances where you now
can't. So they've put development effort into making things /less/
suitable for the high-end users.
singhals
> singhals wrote:
>
>>LDS spent time, effort, and money inventing their own twist on Soundex
>>so it considers letter-placement as well as letter-value.
>
>
> It also knows about diminutives, e.g. Elizabeth & Betty which can be
> useful. Mind you, our ancestors coul still fool it without investing
> any time, effort or money especially with surnames - who would have
> thought that Kenworthy & Kennerley were synonyms?
>
Or Canady and Kennedy -- particularly when the family
involved says Kuh-NAW-day ...
>
>>And if either site has to choose between
>>suiting the high-end users and putting more data on-line, I know where
>>my vote goes.
>
>
> It's a trade-off that doesn't have to exist. As I've said in another
It /was/ a conditional. *IF* that's the choice to be made,
I want more data. (g)
> post you used to be able to put in wild cards in IGI searches and to be
> able to use more restrictive filters in circumstances where you now
> can't. So they've put development effort into making things /less/
> suitable for the high-end users.
I b'lieve that's a POV; there's another POV that says
they've made it easier to find someone when you have no data
but a name?
But then again, I'm the one who actually browsed
old-fashioned card catalog(ue)s for fun.
Cheryl
Robert G Eldridge
<godd...@hotmail.co.uk> wrote:
>It also knows about diminutives, e.g. Elizabeth & Betty which can be
>useful.
I feel quite sure that my mother, Betty, feels that she is in no way
smaller than or a product of anyone who may be named Elizabeth. ;-)
--
Bob
Bob LeChevalier
>OK, I can sort out that lot because I know the area. But what sort of
>traps are lying in wait for me in areas with which I'm unfamiliar if I
>use the pilot?
>
>LDS have churches all over the place. In this particular case the
>nearest is in Huddersfield, maybe about 10 miles from the most distant
>part of either parish. Why don't they run their geographical
>attributions past someone in a local church? If the database design is
>anything like properly normalised they don't have to look at each
>baptism in the parishes - just the entries in the location table.
While I understand your objection, I also think I understand what they
are attempting to do by forcing the use of standardized names. You've
described a situation where someone might have to try 4 different
searches to find what he is looking for. But without normalized
names, you have to deal with every typo possible, along with people
who leave out the county name entirely, who use abbreviations, people
who enter place names in non-hierarchical order and non-standard
punctuation, and those who have no clue where the parish is and just
guess. I am sure that there is somewhere, someone who has entered the
place name as "England - Yrksh : Huddleston".
Remember that most people who use these websites have no clue as to
any sort of standard for any kind of data. And if you add in
recognizing historical geographical divisions as a requirement on top
of modern ones, you'd probably lose more people trying to do genealogy
than you would gain - and the Mormons want *everyone* in their church
doing genealogy.
Ian Goddard
> Ian Goddard <godd...@hotmail.co.uk> wrote:
>> OK, I can sort out that lot because I know the area. But what sort of
>> traps are lying in wait for me in areas with which I'm unfamiliar if I
>> use the pilot?
>>
>> LDS have churches all over the place. In this particular case the
>> nearest is in Huddersfield, maybe about 10 miles from the most distant
>> part of either parish. Why don't they run their geographical
>> attributions past someone in a local church? If the database design is
>> anything like properly normalised they don't have to look at each
>> baptism in the parishes - just the entries in the location table.
>
> While I understand your objection, I also think I understand what they
> are attempting to do by forcing the use of standardized names. You've
> described a situation where someone might have to try 4 different
> searches to find what he is looking for. But without normalized
> names, you have to deal with every typo possible, along with people
> who leave out the county name entirely, who use abbreviations, people
> who enter place names in non-hierarchical order and non-standard
> punctuation, and those who have no clue where the parish is and just
> guess. I am sure that there is somewhere, someone who has entered the
> place name as "England - Yrksh : Huddleston".
Standardising names is a good thing to do but only if you do it
systematically and correctly. There is no excuse for so many options in
the example I gave especially given that the North Yorkshire one has no
basis whatsoever.
> Remember that most people who use these websites have no clue as to
> any sort of standard for any kind of data. And if you add in
> recognizing historical geographical divisions as a requirement on top
> of modern ones, you'd probably lose more people trying to do genealogy
> than you would gain - and the Mormons want *everyone* in their church
> doing genealogy.
Anyone doing genealogy needs to get a firm grasp of the ecclesiastical
and civil administrative arrangements of the areas where their ancestors
lived and the changes with time. These factors affect how one reads
records and even where one looks to find those records.
For instance I've come across forum posts suggesting that someone moved
from Almondbury to Holmfirth. Probably all that really happened is that
they lived in the Almondbury part of Holmfirth Chapelry but married in
the parish church because there were no marriages in the chapel. Their
children, however, could have been baptised in the Holmfirth CoE,
Wesleyan or Lane Independent chapels. Depending on where and when they
lived they may then have been found in Hinchliffe Mill in the 1841
Census, buried in the new Holmbridge parish graveyard and had their
deaths registered in the Huddersfield Registration area. They may also
have been mentioned in Wakefield manorial records and all this without
changing residence. This is confusing enough without having badly done
standardisation of records to cope with.
Steven Gibbs
news:hg55b6$7gn$1...@news.eternal-september.org...
>
> Anyone doing genealogy needs to get a firm grasp of the ecclesiastical and
> civil administrative arrangements of the areas where their ancestors lived
> and the changes with time. These factors affect how one reads records and
> even where one looks to find those records.
Are you not completely ignoring the huge differences in methodology between
the way we do things in Great Britain and the way they do things in the
U.S.? Here, we have Censuses back to 1841 and Civil Registration back to
1837 (or 1855). Consequently we learn to use the IGI only for extracted
records for the last 200 years or so, by which time we are mostly competent
enough researchers to learn to disregard patron submissions (except as
potential clues, if desperate) in research of older periods.
In the U.S., as I understand it, with limited birthplace information on the
census, and Vital Records variable from state to state (some starting only
very recently), very much more attention is, of necessity, paid to the sort
of records we wouldn't touch with a bargepole. I have no recollection of
anyone researching a U.S. line ever pointing out the difference between
patron submissions and extractions. In fact, I don't recall ever having
seen an extracted batch in the IGI of American origin (maybe because I'm not
researching the U.S., except for the occasional stray, but even so ...).
Americans have to use all the clues at their disposal, patron submissions,
printed genealogies, etc., and I suspect this is from where the differences
between you and Bob arise.
Steven
Ian Goddard
The thing is that a lot of US researchers end up looking in the UK.
They are likely to have no direct experience of the areas where their
ancestors lived and fictitious location information can only make things
worse. The early C19th was a time of substantial change in both parish
& civil records, especially in the N of England where the large ancient
parishes were broken up about this time. For instance IIRC until a new
church was built under the Million Act Liverpool was no more than a
chapel of Chester.
It's interesting to compare the IGI approaches on both the regular and
pilot searches with FreeBMD where the locations are historically based,
where most of the district and county entries on the search screen are
historically bounded and with the LDS search of the 1881 census where
the drop down screens for location go to quite fine detail and where, in
consequence, it's much easier to avoid the shrapnel effect.
Bob LeChevalier
The serious genealogists I know here in the US do indeed distinguish
between extractions and patron submissions. There are some who in
fact won't even look at the LDS site because they don't want to bother
distinguishing the difference.
(I personally use three categories, assigning two distinct levels to
submissions - a patron submission with exact dates and places PROBABLY
ultimately derives from a creditable source, whereas approximate
dates, or exact dates with no place name are more likely to be some
sort of hearsay.)
But most people doing genealogy in the US aren't in the least bit
"serious genealogists". A goodly percentage of the Mormons doing
genealogy are doing it because the church tells them to, and quite
often are perfectly happy to put the first name that comes along that
seems to fit in the slot on their chart. A lot more will get
information from family members, sometimes half-remembered, and have
no interest in checking the data.
There are plenty of extracted records in the IGI for the US, but each
chunk is specific to some parish or county (and our counties are much
smaller than British ones - Texas alone has more than 250 counties)
and for a limited period of time.
Finding them, however, is a matter of luck, and unfortunately the
newfamilysearch site support for IGI information makes it that much
harder, since the source info isn't on the same page as the data (you
have to click on "sources").
If new patron submissions are entered with sources attached, in the
long run things should generally improve.
Here is how the detail information for one person I added data for
appears on one of my pages
<Person identifier: 27HB-4NP
<
<Name Information Contributors
<Name: Pasquale Pietro ("Patsy") Sirianni Edit lojbab
<Name: Pasquale Pietro Sirianni Edit Multiple
<
<Gender Information Contributors
<Gender: Male Edit Multiple
<
<Event Information Contributors
<Birth: 17 April 1892
<Aprigliano, Cosenza, Italy Edit lojbab
[the following two lines are struck through on my display, because I
disputed it based on a specific source. Someone else looking up this
person would presumably see both dates, neither struck through, though
I haven't run across such an example yet.]
<Birth: 19 April 1892
<Aprighiano, Cosenza, Italia Edit Multiple
<
<Death: 26 September 1973
<Tacoma, Pierce, Washington, United States Edit lojbab
<Death: [Date and place not provided]
< Edit LDS Church Temple Records
Here is the detail information for another person (whom I have never
researched, but I know that the locale is one that has extracted birth
data:
<Person identifier: MZY9-L66
<Name Information Contributors
<Name: Antoine Syler Edit Multiple
<
<Gender Information Contributors
<Gender: Female Edit Multiple
<
<Event Information Contributors
<Birth: 29 December 1883
<Calumet, Houghton, Michigan Edit Multiple
<
<Death: [Date and place not provided]
< Edit LDS Church Temple Records
For the latter person, I include part of the source info
< Antoine Syler
<Birth date: 29 December 1883
<Place: Calumet, Houghton, Michigan
<Individual Sources
<Contributor FamilySearch Extraction Program
<Source Source type: Other, Media type: Microfilm, Repository name: Family History Library, Repository address: 35 N West Temple Street, Repository city: Salt Lake City, Repository state: UT, Repository country: USA, Repository postal code: 84150, Call number: 1008257, Event date: , Reference number: 1008257, Batch number: C737775, Time period: ?-?, Contributor: EXTRACTION, Contributor of repository: FCH
<Source Source type: Other, Author: The Church of Jesus Christ of Latter-day Saints, Event date: , Batch number: C737775, Contributor: EXTRACTION
<Add a source about this individual
<Sources about Gender
< Female
<Contributor LDS Church Temple Records
<Source Source type: Other, Repository name: The Temples of The Church of Jesus Christ of Latter-day Saints, Repository city: Salt Lake City, Repository state: UT, Repository country: USA, Repository postal code: 84150, Event date: 27 Jan 2008, LDS temple record number: 304082062, Contributor: TEMPLE, Contributor of repository: DATA_ADMIN
<Source Source type: Other, Repository name: The Temples of The Church of Jesus Christ of Latter-day Saints, Repository city: Salt Lake City, Repository state: UT, Repository country: USA, Repository postal code: 84150, Event date: 19 Mar 2007, LDS temple record number: 304082048, Contributor: TEMPLE, Contributor of repository: DATA_ADMIN
Alas the mere 4 pieces of data listed have a total of 18 "sources"
attached, all of the rest of which are copies of the above (the
"TEMPLE" contributor means, I think, that someone did the church
ordinance rituals for the person, based on some unmentioned
submission, which really isn't a distinct source).
I find the LDS church source boilerplate to be so voluminous and
repetitious as to be hard on the eyes, and it really doesn't convey
any more information than of they used on the stuff specific to the
data item:
<Event date: 19 Mar 2007, LDS temple record number: 304082048, Contributor: TEMPLE
with all of the rest implicit, given that information. But that is my
personal bugaboo. Some people probably want sources to be written out
in full bibliographic format, even if it is largely content-free, and
doing so automatically often generates excess verbiage.
But you can at least clearly see that an extraction was one source.
A different page, a tree chart, shows the parents, which you can click
on, and see that each is sourced to the same extraction source record
(which is a birth record).