User:Jrich

Research

I have placed some summarizing charts of my research areas at User:Jrich/Ahnentafel.

Genealogy in print and film

One of my favorite genealogical references in the movies come from the movie Amistad.

First, Joseph Cinque says that he will ask his ancestors to help him, and they must, because... "For, at this moment, I am the only reason they have existed at all." [Descendant-oriented]

Later, John Quincy Adams is staring at a statue of his father John Adams, and says, "We've long resisted asking you for guidance. Perhaps we've feared in doing so we might acknowledge that our individuality, that we so revere, is not our own." [Ancestor-oriented]

An excellent book with genealogical overtones is "The Voyage" by Philip Caputo, a novel about a woman investigating three teenage brothers, one her grandfather, whose father sent them away on a sailboat voyage to brave the Atlantic Ocean on their own.

Sources

In WeRelate, we are collaborating with people we don't know. This means you cannot expect other people to simply take your word for something. Since no living persons should be entered, it is likely neither person has personal knowledge of the target being documented, or at best, it is so long ago as to be rendered questionable by the failings of normal human memory. So providing good sources is the only way of "proving" what we assert. Presenting data on a WeRelate page is like trying a case in court, where you must marshal evidence to prove your case, and disprove the other case(s).

People that do not provide the sources for the data they input are not helping the process of collaboration, and they should not be surprised if their data gets changed without consultation or respect. It will be impossible for people merging duplicates to have any clue why their data value should be preserved. Without sources, it becomes too easy to assume somebody misidentified the person, or made a typo, etc. Only by providing sources, can one show that there is actually reason for believing the facts they have presented.

It seems to me that the process of identifying sources at WeRelate is the same process as dealing with the genealogical data: collaboration. Meaning that expecting sources to only look mature, polished and complete is unreasonable. Instead, just like the data they support, they are often part of an immature research project. But such work can still give a base to build on. For that reason, I don't think any source or data should be removed simply because it fails to met somebody's idea of a good source, unless that person has a better-quality source to contribute. Merely recognize that situation for what it is: early in the process. If it bothers you, make it better, but don't disrespect the work somebody did getting that far. It is often the result of years of searching even to find poor sources for some facts, but this very iffy piece of data may be all some other researcher needs to then find good sources, and solidify the toehold. If you remove the bottom rungs of the ladder, only a tall person can start climbing to the top.

I believe the key is to crowd out bad genealogy with good genealogy, not simply to remove bad genealogy. Removing the bad stuff simply paves the way for somebody else to come along and reenter it.

The most important thing in identifying sources, is to let other people find them. Unfortunately, it is hard to say only there is a standard way of doing this. There are multiple styles of bibliography. A recent search I did yielded six major styles, and that list didn't mention Elizabeth Shown Mills, which seems to be the accepted style used by many genealogists. Most of these styles have much more ambitious agendas than simply making it possible to locate that source and inspect it. I think too many people get hung up on dotting the i's and crossing the t's, without regard to the very small percentage of times these issues make a difference. And when it does make a difference, I suspect collaboration will make sure that an entry has the i's dotted and the t's crossed. This is not arguing for sloppiness and inaccuracy. It is only suggesting more tolerance for less than perfect work, if said work meets the minimum standard of identifying the source so another person can find it. If not, then collaborate, by improving it.

Distinguishing People: A Suggestion to WeRelate Users

After many months of adding pages where I try to ensure I am not creating duplicate pages, out of exasperation, I would like to humbly suggest that users should try not to create a page where the only information displayed is the name of the person. Relationships help (though they in turn are just names), but dates and locations are critical for identifying a person. If you don't have information beyond the name, my opinion is that the proper thing to do is not to create a page for that person. This is particularly true if all or part of the person's name is Unknown. There is no reason to create a page for Mary Unknown, unless you need to store a birth date, death date, or some other fact that distinguishes this Mary Unknown from the literally millions of other Mary Unknowns.

A page with only a name matches too many searches, when the person found is not even remotely of interest, and is an impediment to other researchers. It is frustrating to be searching for, say, John and Jane Doe in colonial times, and have to scan 4 or 5 pages named this, often following links two or more generations away to determine dates and locations, only to find out the page titled John and Jane Doe are modern people living nowhere near the area of interest. If the page even had a estimated marriage date, or a location, chances are it could have been ruled out from the search page with no digging. Taking the time to add such distinguishing information is merely being considerate of others who will be looking at the page you create.

For example, if you have a marriage with a date, create the Family page. But do not create the Person page for the husband and wife unless you have some information that needs to go there. If you know somebody's parents' names, but nothing else, do not create the Family page, merely note the relationship in the notes on the child's page, and leave it for another researcher to create a robust Family page.

Source Renaming Project

There are several issues concerned with the recent Source Renaming Project that I would like to discuss. I have posted some of this on the project page, but decided it is better to move it here, 1) to stop distracting people who are working very hard to get a job done, and 2) to indicate clearly it is simply one person's opinion.

Some responses to this will be found on my talk page.

Place and authored oriented titles for source pages

I do not expect at this stage in Beta for WeRelate to make a major change in how things are laid out. But it appears that initially a design flaw was introduced by using active data (title) for the primary key of a source page in the wiki database (i.e., its page title). This was addressed on Person pages by adding a sequence number, but this solution was not used with Source pages. Several moves that strike me as extremely non-intuitive, and therefore difficult for the newcomer to learn to use, appear to me to be attempts to work around this problem, instead of working towards a solution of the original problem. I do not understand the internals of wiki software well-enough to feel comfortable suggesting what is easy and what is not, and there may not be time to solve this now, but I suspect some kind of bibliographic normalcy will eventually require fixing this design issue.

The changes in approach to webpages.

I believe web pages are valid sources, some being as valid, or more so, than many of the titles listed in the FHL catalog that the WeRelate source pages were primed with. A lot of old sources were published because there was no Internet around, but they are the same style of undocumented family trees that have given Internet family trees such a bad name. Even many highly respected genealogies did not identify their sources or indicate what primary documents justified their conclusions. Such good practices did not become widespread much before 1900. It is easy to put things on the Internet, and unfortunately this has resulted in many that do not follow good practices. But equally indisputable, some do use good practices and deserve to be cited, and be promoted as reliable sources.

There are clear technical challenges with webpages, mostly regarding their potential to change, move or disappear without notice. But this is true of all webpages. A good example is the recent upheaval in the whole rootsweb series of pages. Whether you create a Source page, or a MySource page, such changes to website could end up with outdated information or broken links. Even if you just cite the URL on the Person page, and avoid creating any kind of source page that relies on web-based information, you could still end with a dangling link on your Person/Family page. Any webpage has this problem, so all webpages should be handled the same in regard to this issue.

During the project, the way that webpages are to be typed has changed multiple times, midstream, as it were. Now, it appears they are supposed to be created as MySources, meaning they will not be returned in a typical search, unless you think they will be of interest to other people. This criteria is impossibly ambiguous, since a poorly documented cousin collection of 100,000 names could be argued to be of interest to lots of people, or likewise, a webpage mentioning just one person, but multiplied by 10 generations, or a high quality webpage because it cites high quality sources for each fact presented. It is hard to think of a webpage/website that you couldn't rationalize into being of interest to some number of other persons. My feeling is that if somebody cited a webpage, it is the highest quality source they have for a fact, and so it has value.

Lumping together sources that are not identical on one source page

Some sources are identical due to photographic duplication, and they should be able to be used interchangeably. However, any copying/transcription introduces the possibility of error. This introduces the possibility that data could be cited and somebody else can't find it because they are looking at a copy. This could easily happen since there is nothing distinguishing the listing of the two sources, and so no way a WeRelate reader can tell which one is being referred to. Admittedly, this is a relatively small probability error, so this may be acceptable, but it actually seems contrary to modern genealogical practice, so would seem likely to generate questions by new users.

More worrisome is grouping together sources that do not even intend to be identical. For example, census index books with the underlying census records. Besides the fact that somebody had to transcribe the handwritten census records to index them, and may introduce different spellings, etc., there is the possibility of them adding information. Finally, the index book is undoubtedly titled differently than the title for the census.

So, there is the question of a person trying to locate the source. Because the index is listed under the title of the census itself, it is quite possible somebody may not realize the index exists as a possible source of information. They would never notice it in the card catalog because they would probably be looking up the wrong title. Finally, there is the issue of educating new users to follow a practice that was probably never taught in any high school English lesson on bibliography, that of listing some source under a title other than its own.

There was talk of combining various vital records sources onto one page. Fortunately, the "book" issue seems to have preserved some bibliographic normalcy in this case.

While I don't get too uptight about strict bibliographic rules, I believe the title is what the title page says.

Too many source pages

Just a quick comment about too many source pages. This has been used as an argument in regards to not listing each webpage-based transcription on a separate page. I am not paying the server bills, but this seems a little specious. If the number of source pages is an issue, then why not list each decennial census as a single source page, and add the location as part of the locating information in the citation instead of having one source page for each county. After all, the federal census was all sponsored by one agency, and used one set of rules and forms.

In reality, once there are one or two serviceable transcriptions of a source on the Internet, the motivation to go through all the work of providing new ones will lessen greatly, and projections of huge numbers of essentially duplicate transactions will never materialize.

Gensmarts

There has been some discussion of "GenSmarts-like source referral feature" and this appears to provide some motivation for this whole exercise, in that it appears to be a future direction.

I am not familiar with this particular item, but I assume it is a little like features I have seen in various genealogy software packages that attempt to build a list of pertinent websites you should search to research a given person. The software I have used ended up taking me through a gazillion cemetery websites associated with the death location, with no guarantee that my ancestor was actually listed there, and in fact, he wasn't. After paging through a mind-numbing list of sites that were less focused that a well-constructed Google query would return, I gave up. Many of the websites that were returned matched only at the state level, and there was virtually no chance that my subject would have been included.

It is unfair to assume that GenSmarts might be as lame as the software I experienced. But it seems like some infrastructure to be put into place before this can be made useful. To explain:

There is a need for a standard protocol to query websites, so such searching can be automated, and a human need not do this tedious, enervating drudgery. It will never be able to find everything but I think it could do a good first pass. The protocol would describe how to send a query to some server on the Internet. One would imagine that it would allow you to send name of the subject and associated information like possibly birth and death, locations, etc. The website on the Internet would take your query and automatically search for matches in its data. The protocol would then describe how the results will be returned, so your computer could interpret and display the results, if any. Presumably, it would support Soundex matching on the name (though I find even Soundex is not quite up to colonial spelling and perhaps some new algorithm is needed to deal with spelling variations).

There are other approaches for allowing such automated search, but the point is that some infrastructure and standardization is required to be widely accepted (i.e., by more than one company). I doubt much useful can be done with this idea until that happens.