WeRelate talk:Watercooler

This page is for discussing anything you want to discuss unless it relates only to a single page. Let people know what you like and don't like about WeRelate. If you don't want to leave comments on this page, you can email them to dallan@WeRelate.org.

Have a question about how to use WeRelate? Post it to WeRelate talk:Support.

Old topics have been archived: 2007, 2008, 2009, 2010, 2011.

Active discussions taking place at other pages [11 June 2011]

Sources & Repositories and Source Review

New User Support

Announcing a new List Pages function [27 January 2012]

We're happy to announce a new List pages function for listing all of the people in your watchlist, including full names, birth dates and places, and death dates and places! It also has a very fast search function so you can quickly navigate to any of the people in your watchlist. Many thanks to Jdfoote1 who has done the coding on this!

Before adding this to the main menu, we'd love to first get feedback here. If you have any comments or suggestions, please feel free to speak up!--Dallan 11:10, 26 December 2011 (EST)

Love it! I note that the Search function does not seem to work for me - but I'm the one blocking known ad and malware sites (but not "addthis"), so maybe that has something to do with it. The only suggestion I would make, and it might not be possible, is if I follow a link on this list and then use "back", it would be nice if the list was positioned at the link I followed. If this is not possible, that's fine - the list would still be very useful. Thanks. --DataAnalyst 11:48, 26 December 2011 (EST)

I notice that the feature I asked for (positioning the list to the link I selected) actually exists in Firefox - just doesn't work for me in IE8. Thanks. Since you asked for feedback, one more request - if I had a filter on and followed a link, and then used the back button, can you automatically put the same filter on again? Would be nice for sort order, too. (Kind of demanding, aren't I?) I can see this list being very useful for review/cleanup. I just used it to clean up some dead links associated with a particular surname. --DataAnalyst 16:45, 27 December 2011 (EST)

Very nicely done. Thank you. (P.S. Using Linux (Ubuntu 11) and Chrome browser) --ceyockey 12:26, 26 December 2011 (EST)

It doesn't run on my Windows 98 system, no surprise probably. Runs on my newer computer, though the initial load took a while, with no progress bar or other indicator that it was working. Was going to ask if data could be sorted, but noticed clicking on the column heading does that - nice! Was going to ask if removing from watchlist could be added, but since it is only Person pages, guess that would be somewhat limited. Thanks. --Jrich 12:42, 26 December 2011 (EST)

Yes! Love it! Even though the search box did not work for me using Windows XP and IE browser. But it's alpha so is easy to find folks. I especially like that all the folks in my many small trees are all together. This type of layout with dates and locations takes less real estate and is much preferred over the normal search results layout. --Janiejac 16:00, 26 December 2011 (EST)

DataAnalyst and Janiejac - are you both using IE? Would you mind checking out the filtering on this page and see if it is also broken? --Jdfoote1 17:03, 26 December 2011 (EST)

For me on Ubuntu, Firefox and Chrome both work with the test page, but Chrome has a crisp snappy feel while Firefox is slower and feels a bit mushy. --ceyockey 17:47, 26 December 2011 (EST)

On slickGrid I searched for Task 55 and got every title that started with '55'. Still using Windows XP and Internet Explorer. --Janiejac 20:30, 26 December 2011 (EST)

I tried searching the list again using Windows XP and Chrome and searched for Jackson, Azor. It took me right to Azor - so the problem is not with XP - it must be with IE. But using Chrome it did find Azor for me though I would prefer that it take me to the place on the list where he is shown alphabetically and not isolated by himself in a separate window. Also when I used the browser back button after searching it did not take me back to the list - it took me to where I was when I clicked on List. --Janiejac 20:45, 26 December 2011 (EST)

Filtering on this page works for me in both IE8 and Firefox. List pages works for me with Firefox but not IE8. Note: In IE8, as soon as I type one character into the search field, there is a message at the bottom saying "Error on page" Note: I am using Windows7. --DataAnalyst 21:57, 26 December 2011 (EST)

Thank you for the feedback! We'd especially like to know if people would prefer having the surname and given name fields split into separate columns, and how much people would want the ability to view watched pages in other namespaces -- families, mysources, etc. What do people think?

Regarding the comments so far:

• If you press the "back" button, I don't think we can reposition the list to scroll to where your link was, but I'm pretty sure we could re-apply any search text, tree filter, and sort order you had entered.

• DataAnalyst, I'm able to reproduce the error you're seeing with IE8. I'm out of town this week so I'll investigate more when I return. (Jdfoote1, I'll send you some information in a separate email.)

• I think we could look into adding a progress bar on initial load. If not, we could add a "Loading" box like gmail has.

• I'm thinking seriously about having this page replace the "Show and edit complete watchlist" feature of the current Watchlist page. If others like this idea, we can add a "namespace" filter to show different namespaces, and add little trashcan icons at the end of the rows so you can remove pages from your watchlist.

  +1 --ceyockey 13:07, 1 January 2012 (EST)

• What would people think about adding "Star" icons to the left of the rows so you could flag certain pages, like gmail has?

--Dallan 14:02, 28 December 2011 (EST)

I am just looking at this new feature now, because each time I tried before, it didn't seem to work for me. I think because my watchlist is so large, and there was no indication the page was processing, I thought the result was just an empty box. Once I gave it more time, the list appeared.

One feature that may be helpful down the road is a "customize this view" button like RootsMagic has. Then I could check off the fields that I'd like to appear. This could be helpful for cleanup projects. --Jennifer (JBS66) 14:48, 28 December 2011 (EST)

I'm just now getting to it because I had a fatal crash and ended up having to buy a new post-Christmas laptop -- and reinstalling and copying over everything, and then learning about Win7. Strange new keyboard, too. Whattapain. Anyway. My watchlist is 16,000+ pages and it took about 30 seconds to populate that empty box, during which I couldn't tell that anything was happening. I agree that there needs to be a "Working . . ." notification of some kind while it's doing that.

But, more important, the list presently defaults to "All trees" and I wanted to examine just an individual tree. So I picked one -- but there doesn't seem to be a "Do It" button of any kind. And it didn't change trees automatically. Check-boxes at the left to define a working subset would be nice (it doesn't have to be stars) -- but what sort of tasks do you have in mind for that subset? "Create a new tree from selected pages" perhaps? And you would need a menu or list of tasks, of course.

All in all, though, I like the way the list looks. I think it will be much more useful for actually doing work in than the present "bare" list. I wouldn't object at all if it became the default method of seeing the watchlist. --Mike^Talk 10:00, 1 January 2012 (EST)

Couple of comments

• splitting surname and given name in to separate fields - would be good.
• Tree inclusion
  • would be useful to include a 'Trees' column to indicate what tree(s) a name appears in; this would be a guide to further filtering
  • could be useful to include in the header a) number of pages on watchlist (which currently appears on the Watchlist page) and b) the count of returned records after a filter is applied (which might be useful for people who have those ginormous watchlists of 10,000+ pages)
  • I did a filter in my list page and the two returned people do not appear in any of my trees, but I couldn't tell that without selecting each tree as a filter and seeing them disappear each time. Would be useful to include a "no tree" or other named option in the dropdown for this filter.

--ceyockey 13:13, 1 January 2012 (EST)

Thank you for all the feedback. And thank you to Jdfoote1 for doing a lot of the work on this! The list pages function is official. I've put it under a new "List" menu item. A few notes:

• The IE bug has been fixed. I've also upgraded to the latest version of jQuery, which means that the search box in the upper-right corner may no longer work for people running on Windows 98. If you're running Windows 98 or Windows 2000, check out the Opera web browser. I switched from IE6 to Opera on a Windows 2000 computer a couple of months ago and it worked great. If that doesn't work, let me know.
• You'll notice a new loading indicator.
• There's a new "Tree(s)" column to let you know what tree(s) your pages are in. Adding this column means that the initial load takes longer than it used to. Let me know if you'd rather go back to the way it was.
• I'll ask Jdfoote1 about displaying the number of pages and splitting given and surname.
• Having this page replace the full watchlist page (adding a namespace dropdown and a trashcan icon so you can remove pages from your watchlist) is something I'd like to see long-term, but it probably won't happen right away.
• I was thinking that allowing people to "star" pages would be a way to flag or bookmark certain pages, as in gmail. Unless there's a lot of interest in this, it also won't happen right away.

--Dallan 11:51, 5 January 2012 (EST)

We've launched the List function publicly now by putting it on the main menu. I think what Jdfoote1 has done is pretty nice. It didn't sound like there was a strong desire for any of the other features mentioned above, so they haven't been implemented. If we're wrong, and people would really like to see some additional features in the list function, please let us know.--Dallan 13:58, 27 January 2012 (EST)

Citation for a web page - difference in how it appears [28 December 2011]

Check out this source page Source:Zubrinsky, Eugene. Carpenter Sketches, which has a title of "http://carpentercousins.com/carplink.htm Carpenter Sketches" with brackets to indicate it is a web page. If you look at the citation on the source page, it shows the title as "Carpenter Sketches" (followed by the very long subtitle). However, if you look at the citation on a page that refers to the this source page, it shows the title as "http://carpentercousins.com/carplink.htm Carpenter Sketches" with the brackets. The latter is rather ugly and I doubt what was intended. Can you fix this so that the citation on a person page looks the same as the citation on the source page? No rush, since this is just a cosmetic issue. Thanks. --DataAnalyst 15:50, 27 December 2011 (EST)

The problem was that the title field included the link and not just the title. Removing the link from the title field fixed the issue. -- Amy (Ajcrow 15:55, 27 December 2011 (EST)

Thanks for your quick response. The problem is, that I'm betting this is not the only source page that does this (even if there are guidelines against it, which I did not check). This particular publication is only available as an web site (as far as I know), so it does not surprise me that someone (not me) put the link in the title rather than just in the list of repositories (where it also is). Since the citation on the source page is correct, I'm thinking there is code that handles this situation - it just isn't being used on the person pages. If this got fixed, then it wouldn't matter if people put links into titles (which is hard to control). Also, the citation on the source page should match the citation on person pages so that users adding/editing sources know what they are getting. (A small thing, but should be addressed at some point.) --DataAnalyst 16:15, 27 December 2011 (EST)

This seems like a good idea -- I've added it as a suggestion on WeRelate:Suggestions

Ancestral File Numbers - to keep or not to keep, that is the question... [5 January 2012]

As I understand it, the system of Ancestral File Numbers (AFN) was a somewhat abortive attempt by LDS to provide a means for merging information for common individuals in different contributed trees. Many person pages on WeRelate still contain AFN values, which I have generally preserved and added as discrete AFN fact items - if I was editing such a page for any reason. I have observed in other cases, that folks have just chucked this info. Can someone advise on whether there is value in preserving these ids? If so, for cases where more than one candidate id is present, should each potential value get its own AFN fact or should we comma delimit a list in a single fact? If not, then maybe Dallan can rehabilitate his LDS fact removal agent to chuck AFN facts en masse? --jrm03063 10:39, 2 January 2012 (EST)

I find them an annoyance. A while back there was a vote to keep them, so I haven't deleted them. The only purpose I can see that they serve is as source documentation. I would think an appropriate cleanup measure would be to add a source for AF and copy the number into the text. Many persons have several AF numbers. --Judy (jlanoux) 12:25, 2 January 2012 (EST)

I was leaving them undisturbed for a while even though they contain no sources to justify their often ridiculous assertions. But lately I have been erasing them as they are often the very source of the egregious errors that I am cleaning up. Good data must be supported by other sources whether or not an AFN is cited, and the citing of an AFN has no evidentiary value, so a page might as well have no sources listed. In general, it is usually possible to find an AFN to support every alternate theory out there, and they should be used as nothing more than ideas when starting one's research, not as justification for statements of fact. Some are clearly based on good underlying sources, since in some cases, they have the right answer to difficult questions. But because they don't communicate those sources, you can't tell the good ones from the mass of absurd ones, without going through the trouble of finding the real sources for yourself. --Jrich 13:04, 2 January 2012 (EST)

I leave them for the very reason that they are often connected to bad data - data so bad that a traditional merge on import might not pick it up. If we keep them, then we know which record(s) the (hopefully) now beautiful WR page is associated with in case people have the original record in their files.-Amelia 13:45, 2 January 2012 (EST)

See similar conversation recently initiated on the talk page of the Ancestral File source page. I think there is some benefit in keeping the numbers - same reason as Amelia mentioned. I'd rather not move them to the source area - I often remove AF as a source (to avoid giving it any credit) and keep only the AFN as a fact. Dallan should advise on formating (one line per AFN or comma-delimited) - depending on how he might do duplicate checks.--DataAnalyst 14:27, 2 January 2012 (EST)

May I propose that:

• We agree that they be retained as facts (weak ones, but fact items), not sources
• Someone hip to how AFNs work update the Ancestral File page on the preferred fact form and add links to a few examples that use them? --jrm03063 14:43, 2 January 2012 (EST)

May I propose that:

• I doubt you really want people matching GEDCOM records to existing pages based on AFNs for two reasons.
• They are likely to bring along bad data and add it as alternate facts if not overwrite the existing facts. For one thing, if the AFN is really the source of their data, they have not demonstrated particularly good analytical abilities and/or experience.
• At short notice this may not be the best example, but which page would AFN 4W01-50 be attached to: the Person:Abigail Shaw (14) who married Richard Davenport or the Person:Abigail Shaw (2) who married Stephen Bryant? (Extra credit: check out the parents). It is quite likely that some AFNs will have a mismatch between parents and spouse and on the basis of one should be attached to WeRelate page A, and on the basis of the other, attached to WeRelate page B. How much overlap/disagreement is acceptable when this association of WeRelate page and AFN is made? --Jrich 15:16, 2 January 2012 (EST)

Sure - those are arguments against keeping the AFN or, at least, giving it very little weight. Folks who are vetting inbound GEDCOMs presumably are not accepting masses of content supported only by AFNs. The places where I'm seeing AFNs are GEDCOMs that were loaded years ago and for relatively ancient genealogy. We don't even allow GEDCOMs that reach back into those times at this point. For my purposes, I just want to do the right thing with pages that I'm cleaning up cosmetically without repeating the research. I would also say that, whether we keep AFNs or junk them, the problems that you're alluding to should be clearly spelled out in the usage tips for the source. I strongly encourage you to offer revisions to the source page indicating the issues you describe so that others may be on guard. --jrm03063 16:20, 2 January 2012 (EST)

I see little value in AFN's period. They are usually attached to trees with little credibility and horrendous errors (the one listed above is a good example), and there are duplicative AFN's for many persons in the Ancestral File. I've been deleting them, especially if they obviously contain erroneous information and data on pages I've corrected.... I've also noticed that many Gedcoms with AFN's also have "Personal Reference Numbers", which have no value except to the person uploading the Gedcom..... Perhaps we can find a systematic way to exclude both from new Gedcom uploads?

-Jim:)--Delijim 16:37, 3 January 2012 (EST)

I feel about AFNs the same way I feel about World Family Tree as a source -- that they constitute negatively-reliable sources. When I merge pages, as in a GEDCOM upload (my own, that is), I have generally deleted both these "sources" since whatever source I'm citing has got to be better. And if I'm browsing the database, following links from person to person, and I come upon a Person page where the only sources listed are a dozen or more "WFT" citations -- and there's a lot of those around -- I really, really want to go in and delete them all. And then put a "No Sources Cited" template on the page. Okay, I don't often do it -- but I really want to. AFN and WFT as putative sources are -- seriously -- worse than displaying no source citation at all. --Mike^Talk 21:00, 3 January 2012 (EST)

Ok, how about this:

• The folks who have written so eloquently here on the weakness of the Ancestral File and AFNs should review/revise the Ancestral File source page and make sure that it does a good job explaining reasonable uses as well as the problems. We need that regardless of whether we keep AFNs or junk them, now or in the future.
• Next, assuming that the AFNs are retained, we get a consensus on what they should look like (bare facts with a fact per AFN, or a list of AFNs on one fact, or a source w/AFN as a page, or whatever). We add that to the source page as well.
• Finally, when the source page represents the situation and alternatives satisfactorilly, we get guidance from Dallan on how to do a formal election on whether the AFNs are spared for another year or whether they start to get deleted right now (It didn't sound to me like anyone thought these should be kept forever - but I could be wrong...).

--jrm03063 11:29, 4 January 2012 (EST)

How about if we vote on the Ancestral File source talk page: add a +1 to keep (at least for another year) or -1 to start deleting right away followed by your signature. A quick search shows roughly 44,000 people with ancestral file numbers. If we vote to keep them, I'm willing to do a potential-duplicate search based upon same AFN's at some point if there's enough interest in that.--Dallan 11:40, 5 January 2012 (EST)

RootsTech conference [5 January 2012]

Anyone else going to the RootsTech conference? It would be fun to meet in person.--Dallan 12:01, 5 January 2012 (EST)

I'll be there. I have no idea of my schedule, though. (It would be nice if they'd post the program grid. I don't even know when I'm speaking!) -- Amy (Ajcrow) 12:31, 5 January 2012 (EST)

GEDCOM upload/review [26 January 2012]

I've uploaded a GEDCOM for import, asking that it be imported to a tree already in WR. How does the system decide who is the root person on the new import and what difference does it make? The only thing I see is that during the review it tells me how far distant the person is from the root person. But what difference does that make? It isn't even the roots person I would have expected it to be.

The "root" person is the first person in your gedcom file. It used to make a difference in the gedcom review process, but not it's just informational.

And while I'm talking about GEDCM upload, for those interested, I wish you would visit the Suggestion Page and vote for a location button on the GEDCOM review! I think I'll not attempt another upload until that button is in place - and more votes may put it higher on the priority list! Here is my suggestion: When reviewing my GEDCOM for upload, I appreciate the button for "recently created or used sources" being available to click on. Could we also have such a button for locations? I seem to be having to search for the same locations over and over again. I had no idea my locations were so inconsistant, but this upload review has shown me I have a lot of work to do.--Janiejac 14:14, 9 January 2012 (EST)

I have a lot of things like this that I'll do once RootsTech is over.--Dallan 23:22, 26 January 2012 (EST)

Soldiers/Participants vs. Veterans [16 January 2012]

The categories for participants in military conflicts seems to be mostly limited to the term "veteran." Having read a number of talk pages about the structure, I did not find a discussion concerning the term itself. Veterans implies that a person was in the military and was discharged while still alive.

The term "veteran" excludes soldiers who died while in service and inadvertent participants. I give two examples for inadvertent participants (1) The teamsters who were at the Bloody Brook massacres, were not soldiers. However, being among the attacked, they (presumably) fought and they died in that battle. (2) A father [for the life of me I cant find the person's name] went to visit his sons at the Battle of Bennington, took up arms and was killed by a Tory soldier (militiaman).

Question is.. are we trying to categorize participants, soldiers, or veterans?

It doesn't seem efficient to have separate categories within a conflict for each type of combatant. Inadvertent participants would likely be a small number and may not require categorization. However, there are many soldiers, who never became veterans.

Question - Can/should the name within the categories be changed? Perhaps to read, "War of 1812 Soldier", World War I Soldier, King Philips War soldier. And then there are veterans (and non-veterans) with military service during peacetime.--Kpb2011 09:03, 14 January 2012 (EST)

By the same token, the word "soldier" implies those who fought with an army and excludes those who fought in the navy. The categories are intended to include all military participants, regardless of whether they survived the war. While "veteran" might technically apply only to those who fought and were later discharged, making such a distinction would only serve to make the categories more fractured and, thus, less meaningful. Also, the term "veteran" denotes military participation, while "participant" could include civilians, such as sutlers. We could add a note on the categories that include the word "veteran," but I don't think that changing the term itself would be beneficial. -- Amy (Ajcrow) 09:28, 14 January 2012 (EST)

If I understood correctly, the purpose for the categories is to identify those who have a military service record. That is, they enlisted or were conscripted/impressed or were somehow recognized as being part of a military unit by some governmental authority. Casual or inadvertent participants would generally be excluded (like the residents of Gettysburg were participants in the battle to some degree, but it was not military participation). It is governmental acknowledgement of a military record that is intended; the fact that the DAR, SAR, or some other membership organization recognizes participation is too broad (because they recognize committee of safety, etc.). The membership organizations would need to recognize military service in some military unit.

I am not trying to split hairs (promise!) whether the father is categorized as a Vermont Revolutionary War veteran is not as important as understanding what this site intends the categories to be used for. In the case of the father at the Battle of Bennington, he could be a "veteran" if his widow was granted a pension or he is listed as being part of a unit during the battle, not just a walk-on. With regard to the teamster at Bloody Brook, they are not "veterans," even though they were the whole purpose of the military escort, none appear to have been credited with service under Capt. Lathrop by the colonial government.--Kpb2011 10:26, 14 January 2012 (EST)

Since the military service categories are organized by name of unit, I have assumed the subject would have to be a listed member of a military unit under some higher authority. Whether that means federal or state troops, regular army or militia, is not relevant. (I haven't had to deal with service in anyone's navy, so I'm ignoring that. . . .) I've been adding people who served in militia units raised during the Texas Revolution, so it's not all "U.S." or "C.S.A.", either. I think the issue of "peacetime" service is pretty minor, since we don't include living persons and nearly all the Regular Army in the late 18th & all of the 19th century may be regarded as participants in the various Indian wars (and that's how the NARA service records for that period are classified). That leaves only deceased members of the Regular Army between 1918 and 1942 (who did not later participate in WWII) -- and they will still be found listed in organized units, which could be the basis of a "Peacetime" category, if you think that's necessary.

Incidentally, I have several people in my notes who were listed members of 17th-century Train Bands in Massachusetts & Connecticut; would you include them in the categorization system if they didn't take part in a specific war? I also have a couple of people in the expedition against Fourt Louisburg; what war would you consider that to be part of, for our purposes? --Mike^Talk 21:08, 14 January 2012 (EST)

Am currently working on a list of Colonial War veterans now. I have begun categories see Category:American Colonial War veterans. That will cover a long time line 1609-1763. The 1745 Louisburg Expedition is Category:King George War veteran (1744-1748)

There are a few wars not yet added (Cherokee, Pequod, perhaps others).

As I understand it, American Rev War is organized by Continental Army and State Militas. The Overall structure begins here Category:Veterans--Kpb2011 21:25, 14 January 2012 (EST) Added: At the moment, I have not organized the Colonial units. King Phillips War had a relatively small number of participants, although there are records that would break them down in to units, but not sure that is needed.

The thing is, most of the participants in King Philip's War are well documented, mostly because of all the folks who want to qualify for Order of Colonial Wars and also Founders and Patriots, so they're easy to identify & prove (and therefore categorize) --Mike^Talk 08:56, 16 January 2012 (EST).

Are you suggesting then, that for Colonial veterans, the categories get broken down from the state level to a subordinate level? Example, Capt. Lathrop's troop and Moseley's troop, should they have their own category under the King Philips War category? The war category gives the context, would that additional detail in a category name confuse rather than enhance? Would it read something link "Category: Massachusetts Colonial War Veteran Capt. Lathrop Troop (King Philips War 1675-1676)" or "Category: Colonial War Veteran Capt. Lathrop Troop (King Phillips War 1675-1676)". For the average user, inclusion of the dates seems important, since many are not likely to know which war occurred when nor able to differentiate Queen Anne's War from King George's. Frankly, I have to look up the dates to match service to appropriate conflict. Seeing "Queen Anne's War" gives me some context, whereas, "Queen Anne's War 1702-1713" provides me with much more. What I am saying is that because these conflicts happened so very long ago, the category names need to be meaningful without becoming overly long, nor require a level of knowledge beyond that of most users to actually assign a category.

The King George War (1744-1748 in the Colonies) was part of the European War of the Austrian Succession. There the numbers get larger and there are records where they could be broken down into regiments. However, I am not sure that that level of detail is needed. Most people do not know that history and would find naming the regiments, like Col. Samuel Moore's regiment not meaningful. Other ideas are welcome.

I'm very familiar with the Austrian Succession. The colonial action was indeed just a sideshow, in the same way that what Americans call the French and Indian War was really just a small part of the Seven Years' War. Still, I think those conflicts in the American colonial period that traditionally have been separated out from what one might call the continual "background" warfare that went on all the time could reasonably each have their own categories.

I definitely agree that the named Colonial Wars should have their own category and I suggest defining those as pre-1775. The later conflicts could be handled as you propose. Although, I have not given them much thought, as my ancestors were not generally known to have been involved in them.

OTOH, for the 19th century, because there were several Cherokee wars, ditto wars with the Creeks, Seminoles, etc, and because they were fought by a mix of regular U.S. Army troops and state militias -- and because the same men often took part in several of them -- I'm not sure it's useful to try to separate those out. I would just lump them together as "Indian Wars." Otherwise, you can slice this whole thing unnecessarily fine. As I noted before, that's also how NARA deals with the records, and it's how the later official campaign medals were categorized. The Library of Congress, being a government agency, followed this same breakdown in assigning subject headings (though they're more detailed), so you will also find there a good, ready-made list of U.S. military conflicts. --Mike^Talk 08:56, 16 January 2012 (EST)

Announcing a new name-variants database [31 January 2012]

We're now using a different approach for finding name-variants during searches, one that I think scales better than the previous approach, and which is easier to make publicly available. This new approach replaces the Related names on the Givenname and Surname pages. I've copied all of the variants that people had added to those pages into the new database.

You can find out more about the new approach here. The new approach is more generous in including variant names in searches than the old one was. If you find that very different names are showing up in your searches, you can improve the search function for you and everyone else by removing the very different names from the database. A link taking you to the variant-names project homepage appears in the lower-right corner of the results page whenever you search for people or families. The names that you add or remove will take effect immediately.

• I am curious about why you have not accommodated the inclusion of supporting information for name variants, which was at least marginally supported in the previous, poorly scaling solution. I would speculate that perhaps you want to get out of the business of building up a potentially redundant name origins information space and rather focus on the core genealogy content, which is OK, but it would be useful to know if that is or is not the case ... rather than my just speculating. Thanks. --ceyockey 18:26, 27 January 2012 (EST)

The primary goal is to create a resource that other websites can use, and also to correct some problems with our current solution:

• if you add name X to name Y, you also have to add name Y to name X (the new system does that automatically),
• we didn't have a good solution for names that didn't have a wiki page (the new system includes twice as many names, and has a good solution for names that aren't in the system),
• the current solution left out a lot of good name variants (the new solution is overly-generous, but it's easier to remove names than to add them).

I'm hoping that by allowing people to edit name variants in a simple form and encouraging other websites to use the database, this will encourage contributions from people who might be intimidated by a wiki and who wouldn't use WeRelate for their family history. People would still have to register at WeRelate to edit name variants though. And yes, I wouldn't mind if someone like FamilySearch took over the variant-names database so that we could focus more on the core genealogy content.

There are two things we don't have in the new implementation that I wasn't sure if I should add back in: sources for variant names, and the ability to watch for changes to a specific name. They were extra work to add to the new implementation, so I thought I would omit them and see if people missed them.

• Do people think the source information is worthwhile - should I add it back in? It would make the forms longer vertically, because instead of multiple columns we'd probably have one variant per row, followed by an input box for the source.
  • I think that providing links to wikipedia for surnames would be a useful adjunct; if this could be done in a semi-automated manner, all the better. Wikipedia:Wikipedia:WikiProject Anthroponymy has within its scope the composition and enhancement of articles about surnames. Most surname pages here do not look to address origin information. I think most relevant for genealogy studies is how a surname changed within a line of descent, while surname origin information tends toward the population level ... and population level finds do not always translate to what happened in a particular line. Enhancing the ability for WeRelate to help people to track such lineal changes would be useful; such research findings taken in the aggregate would contribute to the overall body of work related to specific one-name studies. --ceyockey 18:43, 29 January 2012 (EST)
• Similarly, is it important to have the ability to watch for changes to specific names?
  • Not in my opinion. --ceyockey 18:43, 29 January 2012 (EST)

--Dallan 11:27, 29 January 2012 (EST)

The database is being given away freely to any software vendor or website that wants to use it. The overall goal is that we'll eventually have better search experiences wherever we go on the Web. I hope that people get involved in this project and fine-tune the variants that appear for the names that they search frequently. Thank you!

Now that the new database is in place, the next questions are:

• What do we do with the Givenname namespace? I'm wondering if we should delete it altogether. Following is a list of all givenname pages that have text added to them. Jrich, you're the author of most of these pages; what do you think? If we don't delete them, we should at least remove the related names: Seth Brightwell Scudder John Serafina Eusebia Obediah Zerubbabel Zarubabel Zerubabel Zorobabel Zebadiah Eleazer Eliazar Eliazer Eliezar Eliezer Eleazor Hatsell Jasinder Manjit Lellia Obadiah

For some names, I would add the wikipedia entry giving the name's origin merely as a vague way of suggesting a preferred spelling for a family of variants. I don't have a problem with deleting them. It seems that people do tend to use the spelling of the source they are looking at, and have long wondered if there might be potential benefits in readability from guiding them toward preferred spellings (at least, say, prior to 1830, when spelling was largely phonetic). But with this better searching, it probably matters less. --Jrich 15:14, 27 January 2012 (EST)

That's what I'm hoping -- that this database would tie the variant spellings together for searches so people could use the spelling as it appeared on the source.--Dallan 11:27, 29 January 2012 (EST)

That only works for the first one in. At least prior to 1830, 1840, 1850 when spelling somewhat became standardized, every (primary) source is likely to have a different spelling. Secondary sources seem to chose the spellings that the author liked best. Have to be careful with a philosophy like that, it could encourage a bunch of meaningless renames. Better answer is to faithfully use the source's spelling in the abstract/transcription of the source, but use a more standardized spelling in the name fields/title. I.e., Elizabeth, never Elisabeth? But standardized is somewhat subjective, so unless WeRelate provides such an authority, again meaningless renames such as Ann for Anne, or vice versa. --Jrich 12:08, 29 January 2012 (EST)

• What do we do with the Surname namespace? I'm wondering if we should delete all surnames that haven't been human-edited, or that don't link to any existing pages. We should at least remove the related names from any surnames pages that we don't delete.--Dallan 14:17, 27 January 2012 (EST)

Given names: I did a quick spot check. I see problems with common nicknames not being included. First one I checked, "Lindy"/"Malinda", neither includes the alternate. Then I checked "Ann" which correctly includes such variants as Nan and Nancy, but includes a long list of names that have nothing to do with Ann. There seems to be much emphasis on computer algorithms and not actual usage. While I agree that it is excessive to require a "source" for each entry, it would be very helpful to include space for discussion of certain variants. Many are specific to place or culture/ethnicity. It is usually helpful to have lists of translations from one language to the next. Also, I often wonder how certain names came into common usage and a place to record discussions of these would be useful to other curious souls. If this will not be available with the new system or if it will possibly transfer into new hands, I would like to see the given name pages stay for these purposes. --Judy (jlanoux) 12:38, 29 January 2012 (EST)

Surnames: Agree with copying only human-edited changes to the new database. As with given names, I would like to see surname pages remain as a place for discussion about origins and such as well as for pointers to family projects. However, it would be nice if there could be one master page and not one for each variant spelling. I assume the next search thingy would turn up the page no matter which someone searched on. This would probably best be done by humans. So maybe you could remove the pages which have never been edited. Anyone could create new if they want to have a page for their content. A link to the new variant page would be handy. --Judy (jlanoux) 12:38, 29 January 2012 (EST)

The nicknames were added by hand by me. I added the ones that were on WeRelate already, as well as any additional ones I could think of. I knew about Ann/Nancy, but not about Lindy/Malinda. This is where I hope that the community will help.

To start, the names database is going to look like the result of a computer algorithm because 90% of the variants came from a computer. The algorithm has been shown to be better than Soundex, and it's better than the algorithm used to generate the variants on our Givenname and Surname pages, but it's still just a computer. I'm hoping that people who really know the names a lot better than I do will remove the spurious variants.

How about instead of a source for each name, I'll add a discussion area to the bottom of each name. I'll populate it initially with a list of variants that have been human-generated, from WeRelate or BehindTheName.

Automated links to Wikipedia surname pages and developing an authority for names seem like good ideas, but I think better as suggestions for the future.

Unless someone speaks up for them, I'll delete all of the Givenname pages, and those Surname pages that don't have any text on them.--Dallan 11:13, 31 January 2012 (EST)

Third para from the bottom -- I agree wholeheartedly. I'm not sure that I could come up with a source for variants of names I have been following for many years. They are just familiar, from many sources. But availability of discussion areas seems very important, not only for working on the database itself, but for other information. Of one line, Spelling X seems to stabilize in those who moved west. Spelling Y stabilized among those who moved south. Another line, the spelling stabilized early across the pond, and seems to have stayed the same here. Another line, spelling wobbled everywhere, and fairly late. These can be useful discussions. --LindaS 19:30, 31 January 2012 (EST)

New place matcher [12 February 2012]

I've been working on a new place matcher. It hasn't been installed yet (that will have to wait until after RootsTech), but as far as I can tell it does a much better job at matching places in gedcoms than our current place matcher. Feel free to check it out and leave feedback.

You can help improve the new matcher by following the link and clicking on Choose the best match. This will present you with one of several thousand ambiguous place texts that have been found in GEDCOMs over the years. Please click on the best match. This will provide examples to use for improving the matcher, so that it picks the best match when place texts are ambiguous.

I took a look at this. No one can choose the "best" match when the input is ambiguous. This is the problem we have with the current matching. If the intent is not clear then there should be no match created and a red link left. Grabbing any old arbitrary match is introducing errors which are hidden because the original input is displayed and not the match.--Judy (jlanoux) 12:07, 29 January 2012 (EST)

In that case, please select the I can't tell which place this should be button. That will help me know when places are truly ambiguous, and when I shouldn't match to a specific place. Working through places on the "Choose the best match" link, and either selecting one of the places listed when the best match is apparent, or selecting I can't tell which place this should be when the place is not apparent, is the best way for you to help improve the place matcher that we'll be using. As you might imagine, it's difficult for a computer to tell which place an ambiguous text should match. Take "Virginia" for example: is this the state, or the city of Virginia in Minnesota? What happens when a text matches both a city and a township? We don't want to leave all ambiguous place texts red-linked; that would leave a lot of obvious matches red-linked. We need to teach the computer when a text is truly ambiguous and when the correct match is apparent. That's what using the "Choose the best match" link will do -- it will give me data that I can use to teach our upcoming place-matcher how to do its job better.--Dallan 11:27, 31 January 2012 (EST)

Like the name variants database, the places database is also being made freely available to other websites.--Dallan 14:46, 27 January 2012 (EST)

• Wondering whether you considered using the OpenStreetMap Nominatim place names resource, likely enriching that resource with content from WeRelate? --ceyockey 18:29, 27 January 2012 (EST)

I've looked at OpenStreetMap in the past and I'd love to integrate their content. I know from past experience in integrating Wikipedia, the Getty Thesaurus of Geographic Names, and the Family History Library Catalog place database, that integrating a new source without creating a bunch of duplicates is a big job. I'm hoping that by making the database available to others, we'll get people interested in volunteering to improve it. I was thinking initially that this would happen by making hand-edits to the Place pages at WeRelate, but if someone wanted to integrate a new data source (integrating a database of all US Townships would also be really helpful), I'd love to help them. I could write a robot to add the new places to WeRelate or to update existing Place pages with additional information for example.--Dallan 11:27, 29 January 2012 (EST)

You might take a look at how ShareMap.org has implemented place lookup. Their Search results are broken into three sections: Wikiepdia (GeoNames), Places (GeoNames) and Nominatim (MapQuest). It appears from recent work I've done with ShareMaps that the address resolution data from MapQuest has been integrated in some way with the OpenStreetMap Nominatim solution. It might be worth a contact with the Sharemap folk to see how they are handling the draws and updates to power this search. On the broader topic of Places, I am of the opinion that any place which is contributed to WeRelate through a person surveying that place (such as a cemetery) should be reflected in OpenStreetMap such that the "division of labor" is geoinformatics in OSM and genealogical use in WeRelate. There are a number of solutions out there which provide specialized maps based on the OSM layers and which provide a feedback mechanism to contribute content to OSM; the ones which I have used most OpenLinkMap and OpenStreetBrowser. --ceyockey 23:42, 30 January 2012 (EST)

Thanks for the pointers. I'll contact ShareMap.org and OpenStreetMap to see about passing data back and forth.--Dallan 11:27, 31 January 2012 (EST)

It's cool to see you using GitHub for these projects. I'm betting that you'll get a lot more organic engagement than the previous model of having to ask for the sources.

Have you thought at all about how updates get managed if you're successful and Places/Names are adopted by others? Ideally there'd be some type of federated update system to not only push out WeRelate updates, but also receive updates from other sites which are also working on improving the data.--Tfmorris 18:22, 28 January 2012 (EST)

I haven't thought a lot about this. I think it depends upon who gets involved. We have a number of options:

• We could ask people to update WeRelate directly as the "master" database. That's more or less what Wikipedia does when people use copies of their data.
• I could write an API that other websites could use to push their changes to WeRelate and receive changes from WeRelate.
• If an organization like FamilySearch wanted to be the "master" database for names, and maybe also for places, and would commit their resources to improving them, I'd be open to that, so long as they reciprocated with an API that would allow us to push and pull changes.

--Dallan 11:27, 29 January 2012 (EST)

How minor is minor? [29 January 2012]

When editing a page I've been filling in the window to say what changes I made even though I considered the edit to be a minor one. Then I found that such notes aren't listed on the Contribution list but only "Propagate changes to ..." Do watchers get notice of minor changes? Fortunately, on most of my pages, I'm the only watcher, but what if there were watchers and all I did was add a source for their unsourced date . . . or add a date where they had no date? Are these minor edits and would a watcher be notified? --Janiejac 15:43, 28 January 2012 (EST)

"Propagate changes to" are actually changes coming as a result of a change on another page (the preposition seems backwards to me). I believe they are always marked minor by the system.

They are.--Dallan 11:27, 29 January 2012 (EST)

When I am editing I tend to mark minor anything that doesn't change a date or add a spouse, most especially just adding a source that doesn't change the data that is there. There is a big gray area in between however, where it depends on whether I think somebody descended from this person will care. So if I fix the spelling of the town name, no, but if I move them to a different town, maybe if I think it is significant. If I add double dating to a date that had none, no, but if I change double dating that was already there, yes. Checking the watchlist shows both kinds of changes, and email notification can be configured to only be major changes, or both, so I figure it's better to err on the side of minor when in doubt. If people want minor changes, it easy enough to get them. There doesn't seem to be any uniformity to this, though, as it seems that some people mark everything major. --Jrich 16:40, 28 January 2012 (EST)

Here's the Wikipedia definition [1]. It's consistent with Jrich's practice.

What's most important is to use the summary field - then users can tell whether they need to click on the link. Which is actually one way to decide if you should click minor (as explained in the WP article) - if no one is going to care or dispute the edit, mark minor. Specific to WR maintenance work, please hit minor if you are making the same change over and over again, like adding categories or templates. --Amelia 22:42, 29 January 2012 (EST)

Help editing text in Wiki. Method for creating a tabular column [31 January 2012]

See Person:Thomas Coker (13). Below the 1840 census data is an account of the sale of inventory. I would like the dollar sale amounts to line up in a column but I don't wish to have a table with headings and don't need a table. The only way I have figured out for it to work is to use the pre tag but that is not allowed. Help. --Beth 12:42, 29 January 2012 (EST)

You could use <code> to set off this section instead of bullets. Then your formatting would be preserved.--Judy (jlanoux) 12:52, 29 January 2012 (EST)

I suspect wiki tables have a lot of functionality I don't know about, and may be able to have a borderless table with no special formatting of the first line, but certainly suspect you can do something like this using HTML tables. My experience suggests it is a good idea to exactly pair up tags with their closing tags, even say <TD> and </TD> tags, which HTML doesn't seem to require. --Jrich 12:59, 29 January 2012 (EST)

Thanks so much to both of you. I seem to have it working. I had to add a break tag and the test defaults to a monospaced font within the tag. What do y'all think? Haven't finished yet. The image is now on FamilySearch; that is fantastic.--Beth 15:23, 29 January 2012 (EST)

Actually, XHTML, the current standard, is less lenient than old-fashioned HTML and does require opening and closing tag-pairs, even for paragraphs (using <p> </p>) and breaks (where the syntax is now <br />, a sort of "portmanteau" tag), so I would recommend always using them. As Judy says, using the <code> </code> pair will maintain formatting. But the wiki handles text differently in the text box attached to a source (where formatting will be retained, apparently, no matter what you type in there) than in the big box labeled "Personal History" (where text behaves in typical wiki fashion if no tags are included to force formatting). In the source-connected text box, for instance, I've been just typing up (or copy-pasting) census listings in Wordpad (to ensure plain text), tidying them up, and then copying them as-is to the WR page with no tags at all. Works fine. I would think that would work with your inventory sale, too, provided it didn't have too many columns to display horizontally on the page. --Mike^Talk 15:35, 29 January 2012 (EST)

I removed the Template:DNA reference which had been put on the page because it screws up the formatting of the text. It isn't a complete template, and not needed when you don't have any DNA. -Moverton 12:44, 31 January 2012 (EST)

Question about Savage [3 February 2012]

I'm thinking about some work with this source, and am considering the full text versions (such as this) as a starting point. Does anyone know if this version (other than the OCR defects) was the definitive published version? Thanks... --jrm03063 11:13, 3 February 2012 (EST)

Deleting page that does not exist [7 February 2012]

How may I delete this page, [2]? There was a page created for this family, see Family:Thomas Finley and Zeporiah McGee (1). --Beth 10:16, 7 February 2012 (EST)

Since the page never existed, there is nothing to delete. Are you seeing a reference to this page somewhere? --Jennifer (JBS66) 10:20, 7 February 2012 (EST)

Non WeRelate user emailed me the link to the empty page. I have no idea how she found it. I did not find it using the search engine. --Beth 10:55, 7 February 2012 (EST)

I have noticed times when emailing WR links, the automatically generated URL in the email will drop the index number, so if you click on it, you will be directed to the wrong WR page. The person who emailed you may have also omitted the index number themselves. --Jennifer (JBS66) 10:59, 7 February 2012 (EST)

Okay, thanks. I checked the email and the index number was dropped. --Beth 11:07, 7 February 2012 (EST)

probability vs certainty [8 February 2012]

Reviewing a GEDCOM upload - when I have a birth location of 'prob Oyster Bay' the system links this to Oyster Bay. I unlink it and leave it a red location because I don't want to leave off the probability - it is not a documented location; just my conclusion. It is similar to having 'abt' in front of a date which the system does handle. Isn't there some way to accommodate for the probable location? --Janiejac 16:41, 7 February 2012 (EST)

I just go ahead and link it, then add something like "probable place" in the description (eg. here). -Moverton 17:55, 7 February 2012 (EST)

Yes, but...when I have just uploaded a large GEDCOM with the probabilities removed, and I go to check out the pages, I'm not going to remember which ones were probabilities. At least if I leave them red, I'll have something visual to remind me to 'fix it'. I may not make it back to check all the pages anyway and think it safer to leave it red. That doesn't look good, but at least folks will understand that it is not a sure thing. I was just hoping for an future fix so the system would keep the 'prob' and I wouldn't have to go back to fix each one. --Janiejac 21:08, 7 February 2012 (EST)

I think it does what you want... if you match "prob Oyster" to Oyster Bay, the resulting page should have "Oyster Bay|prob Oyster" in the place field and display as "prob Oyster." At least I'm pretty sure that's what happened to non-standard places in my last upload.--Amelia 22:53, 8 February 2012 (EST)

Saving access to the SSDI [17 February 2012]

Recently, the Social Security Death Index (SSDI) has come under fire as being something that can be used by identity thieves. A handful of cases have been found where the Social Security number of a recently deceased person was used to fraudulently claim that person as a dependent on a federal tax return. Four U.S. Senators contacted Ancestry.com about removing the SSDI; Ancestry removed it from RootsWeb, although it is still available to Ancestry.com subscribers behind the pay wall. Legislation has recently been introduced that would effectively close the SSDI to the public.

Rather than being a source for identity thieves, the SSDI is actually a source to combat identity theft. If the IRS had checked the fraudulent tax returns against the SSDI, they would have discovered that the Social Security number that was given actually belonged to a dead person.

A Senate subcommittee held a hearing last Thursday (February 2) about the SSDI. Genealogists were specifically barred from providing testimony. Genealogists are being made to be the scapegoat.

The Records Preservation and Access Committee (RPAC) -- a joint committee of the Federation of Genealogical Societies, the National Genealogical Society, and a number of other organizations -- has started a campaign: "Stop ID Theft NOW!" Rather than making genealogists out to be the bad guy, this campaign shows that genealogists do care about the issue of identity theft. This campaign calls for the SSDI to be used for its intended purpose: to show that someone is deceased.

If the SSDI is closed to the public, identity theft will actually increase, as the general public and small businesses (who can't afford access to high-priced data services) will not be able to verify whether or not a Social Security number being presented actually belongs to someone who is deceased.

You can help! RPAC has started a White House petition. We need 25,000 signatures before March 8, 2012 for this petition to be reviewed by the administration. You need to register for a WhiteHouse.gov account (free). It takes just a couple of minutes to create the account and then click the link to "SIgn Petition."

For more information:

• RPAC press release about "Stop ID Theft NOW!" campaign
• Records Preservation and Access Committee

If you care about records access, please become involved. If these records close and we do nothing, we have only ourselves to blame.

--Amy (Ajcrow)--Ajcrow 09:46, 8 February 2012 (EST)

Thank you. I signed. I also referred folks to the petition on LinkedIn, the Group "Genealogy...Beyond the brick walls!" ... where, by the way, WeRelate appears to be unknown (based on responses to an inquiry I made). --ceyockey 19:55, 8 February 2012 (EST)

Thanks for the heads up. But unfortunately, in the eyes of many, genealogists are to privacy concerns, identity theft and public records access as the NRA is to the new interpretation of the 2nd ammendment, gun control, and the right to bear arms. Probably another losing cause as all our rights are dimminished. --BobC 23:48, 8 February 2012 (EST)

Bob -- that's exactly why the campaign is centered around "Stop Identity Theft NOW," rather than "Save the SSDI." We're showing that we do care about identity theft and that one way to do that is for the IRS to use this fabulous tool that would show them that a Social Security number belongs to a deceased person. RPAC has posted a FAQ page that covers this very issue. If we wring our hands and say this isn't going to work, then we've already lost. -- Amy (Ajcrow) 07:37, 9 February 2012 (EST)

Amy, you're singing to the choir. I was part of the unsuccessful letter-writing campaign some years ago when Social Security announced they were raising the fee for copies of the original application forms from $9.00 (or whatever it was at the time) to $27.00. I like the approach better this time and will join the effort and will encourage others to do so too, but my crystal ball says we're blowing sand in the wind. I think the decision has already been made and they are just going through the typical ritual misguided legislative and bureaucratic process. Common sense, professional analysis, and fact-based reality have little to do with the laws our legislators enact and the regulations our public administrators force down our throats. --BobC 10:50, 9 February 2012 (EST)

It is always disappointing when people point to a few bad apples then ask the government to destroy the entire crop! -Moverton 19:29, 17 February 2012 (EST)

Templates for transcribing standardized source documents? [9 March 2012]

Hi,

I've been playing around with Template:Scotland. Statutory Marriage Record as a means to transcribe information from Scottish records. I'm sure others have done similar things, but I haven't been able to find other templates or methods for this. Does anyone know anything about this sort of thing? I'm imagining it'd apply to all BMD certificates, and maybe indexes as well...

My basic idea is to set up a MySouce for a certificate and include all information from the certificate in it, as well as the image of the original. Probably not an original idea!  :-) I'm also wondering about developing a standard categorisation system for these transcriptions. Good idea?

— Sam Wilson ( Talk • Contribs ) … 20:30, 26 February 2012 (EST)

I've done a handful of relatively specific transcriptions that are presented on MySource pages:

* MySource:WeRelate/Obituary of William Montagu, 5th Duke of Manchester

* MySource:Jrm03063/Dennett, Helen Marion. Last Will and Testament

* MySource:WeRelate/Dame. Family Bible Entries

* MySource:WeRelate/Tuttle, Joseph S. Family Bible Entries

* MySource:Jrm03063/Mason, James R. Interview with James C Mason

I think WeRelate has so far taken the view that needed semantic properties for the page will tend to be explicit parts of the page type. Perhaps that's not realistic, but it's what I've seen playing out thus far. Still, I think your idea has a lot of promise. If every mysource page, representing a marriage record/certificate, has a template that identifies it as a marriage certificate - that's information we aren't currently recording in a way that can easily be extracted. Likewise other common certificates - birth and death. Knowing all the mysource records of one type or the other could be handy.

I'm not sure it makes sense to put in the template EVERYTHING that might come from the original. Rather, put in the stuff where you want to designate useful semantics that are not otherwise available. For example, it would be an odd marriage record that didn't indicate date, place, both parties and their parents, but all that can be inferred from a single reference to the Family page associated with the marriage. There may be a few nuggets of interest not easy to get otherwise - witnesses, person officiating, religion. Birth and death certificates might only need a template marking them as a birth or death certificate - along with a pointer to the name of the person. From the person page itself, you'll get the date of birth or death and municipality - so again, no need to create redundant information. Hospitals are generally not places, so that might be useful to add. Birth certificates may indicate which birth this is for the mother, and whether it is a multiple birth, which could be helpful.

Also, don't worry about the case of resolving multiple conflicting documents - since you can represent alternate dates and places for birth, marriage and death - and just check which source supports which fact to get the facts associated with a particular source.

Hmmm - it's interesting. Perhaps smaller templates that serve mostly to mark the type of document and a few key additional facts? --jrm03063 22:30, 26 February 2012 (EST)

One more thing (it was late when I gave the answer above, so I missed some obvious things). At present, the common way to handle a birth, death or marriage certificate is simply as an image. You'll notice that images are allowed to act as supporting evidence for a fact on Person and Family pages. I have a number of such examples:

• Image:Case William_Davenport-death certificate.jpg
• Image:Marden Adelle-death certificate.jpg

Still, the essence of your insight remains valid. There's no fundamental way for a program to come along and know that the images above are documents - let alone a death certificate - and that the image below is a portrait.

• Image:Case William Davenport-in uniform 1943.jpg

A template/semantic block (I'm afraid I'm not a really wiki terminology/formatting expert - please forgive me) that allows you to assert that an image is a particular type of document, and that a particular WeRelate Person page is the subject - WOULD INDEED be a useful item. I suppose you could infer some things by looking at what pages include the image, and what facts are supported by the image - but that seems just too flimsy for practical purposes. --jrm03063 10:56, 27 February 2012 (EST)

Yes, I'm not sure how much detail to transcribe. I'll keep playing with it and see what I can do. My initial motivation is just to be able to see what GRO certificates people have already uploaded here, in case any are of use to my research. (And of course a bit of a compulsion to aim for some weird idea of completion!) I'd also like to include in the MySource page the info from the BDM indices.

One thing I'm wondering, in my prototyping, is the etiquette for modifying other people's MySource pages? I mean, I'd like to create pages for certificates already uploaded, but they don't belong under Source:, nor really under MySource:Samwilson/ ... although, it doesn't really matter and I'll just stick em in the latter for now...

I agree with your concern. There's a decree that Wills, for example, are a MySource, but if the will is being transcribed or copied from a book - it's not really proper to say that I have special possession of the source. While some people don't like it - I rename such pages to "MySource:WeRelate/xxxxxxx" --jrm03063 14:08, 7 March 2012 (EST)

The only missing link I've found is that of a MyPlace sort of page, for individual streets etc. -- I think categories, automatically populated via the transcription templates, could serve. (Oh, now I'm just brainstormign... ignore me, till I get something actually done!) — Sam Wilson ( Talk • Contribs ) … 02:33, 28 February 2012 (EST)

I think it's a good idea to do proper transcriptions of all the documents we rely on, and many (notably birth, marriage and death certificates and census returns) are pretty standard. Where those documents are originally in table format, I think it is best to transcribe them as a table so that our transcription matches the format of the original. See, for example, the marriage certificate transcription on this family page: Family:William Harry and Jane Drake (1), or the baptism, censuses and death certificate on this person page: Person:Margaret Rice (13). If templates are to be created, we do need to bear in mind that the questions asked and column headings did occasionally change - Scottish birth certificates being a good example. When they first started in 1855 they asked for loads of (very useful) genealogical information - but quickly realised the system too cumbersome and costly, so from 1856 scaled back the questions, only to then reintroduce some of them in the 1860s. I've been doing mine as tables in the source fields on the person or family pages rather than MySources, as it keeps them all on the same page and it's often useful to see multiple sources alongside each other.--RichardK 15:44, 28 February 2012 (EST)

Topic: Templates for transcribing standardized source documents?

I would be interested in knowing how you went about constructing the tables for source citations for Person:Margaret Rice.

They certainly stand out a lot better than the lists of phrases I have been entering today. (Tree:HWLyle, Person:Elizabeth Atkinson).

Censuses from Kirkcudbrightshire are yet to be added to my trees, but I know their form. --goldenoldie 17:00, 7 March 2012 (EST)

I'm not sure which method the contributor of the page data used to do it, but I've found that putting the data in an Excel spreadsheet first and then using an Excel-to-Wiki Converter is an excellent way to accomplish it and doesn't require an extensive learning curve to achieve very acceptable results. If you use it, let me know if it makes your work easier. (BTW, thanks to WeRelate User Jlanoux for finding it.) --BobC 19:26, 7 March 2012 (EST)

I've been creating my tables in Excel, to which I've added formulae which partially convert the tables into the necessary formatting, but then there's still an element of manually adding the wiki-table formatting. Hence it's a bit cumbersome and if someone can come up with a nice simple way of doing it, that would be handy. I go through waves - sometimes I put in the effort to do the tables because they are clearer to read, sometimes I don't put in the tables because they're too time-consuming (for example my William May - not that dissimilar from your Elizabeth Atkinson, goldenoldie). Of course, tables don't always work - on my Margaret Rice page I didn't do the 1911 census in a table format because it would be too wide to display sensibly on your average computer - particularly as many of the columns had massively wordy column headings but had been left blank below.--RichardK 16:44, 8 March 2012 (EST)

I've started collecting transcription templates together in a category. My current idea is to be able to use these on Transcription: namespace pages, which can then be transcluded wherever (e.g. in the body of a MySource citation). — Sam Wilson ( Talk • Contribs ) … 22:31, 8 March 2012 (EST)

Redundancy, Wikipedia, and External links [19 May 2012]

I have a question on redundancy. I'm a newbie here and I have been trying to figure out how to handle this. I don't think there is a single right answer, but I was wondering what other folk's thoughts were on this.

Situation:

I have a 1906 copy of Source:Kenaga, William F. Historical Encyclopedia of Illinois and History of Kankakee County. Searchable pdf files for this book is available at the Family History Archives. The first part of volume 2 is history and information on Kankakee county. The second part is biographies. I originally set up a template page for the source so I could post the transcripts of a few biographies associated with my people and wikify them. These biographies are very Pando, what with migration patterns and local families intermarrying and all. At first I was only thinking of linking from transcripts to person pages. Then I figured I might also link to place pages and other pages, such as articles on military units. My question of redundancy starts when I wonder if I should always try to link to WeRelate pages or if I should link to Wikipedia pages. I've noticed in biographies on person pages that there are sometimes external links, frequently to Wikipedia. They are for events or things which involved the person, but for which there is no WeRelate page.

I see editing Wikipedia on general things and including genealogy related Wikipedia sections, such as history on WeRelate as a way to reduce redundancy, but once a place page gets an active WeRelate user editing the WeRelate page, the Wikipedia page does not get edited. WeRelate has some excellent military pages where the corresponding Wikipedia page is a skimpy boiler-plated article.

My solution would be very obvious - link from the transcripts to WeRelate pages when one exists, or ought to exist, and link to Wikipedia pages for other important topics. If people choose to edit WeRelate pages over Wikipedia pages, well, at least the information is getting put out there somewhere, and WeRelate is a friendly comfortable place to put information -- the more the better. However now I have another dimension to consider. Kankakee has a local wiki and it would be nice if at least Part I of this book was on that wiki to be wikified. At first, two transcriptions of the same book to be wikified sounded really, really ugly, but then I figured even if a full copy of the book existed on each site, it really would not be completely redundant and might be the best solution. Two sites, two different purposes. Persons and places and other articles on WeRelate could have an external link to the corresponding KanWiki pages, if any get created and sufficiently developed, just like an external link would be made to any other web page of significant interest.

This whole situation made contemplate the problem of redundancy. What goes here on WeRelate? What goes on Wikipedia? How much linking to external sites should there be? What about linking to the FamilySearch Research Wiki, Ancestory's wiki which Ancestory has populated with the Red Book and The Source, and also other research and information web sites? Is linking to Wikipedia preferred over other similar pages?

I am very new here, but I have been looking over the Help pages, the Support pages, the Watercooler, and various pages used as examples or which have been fixed. Just wondering here about other people's opinions on redundancy, Wikipedia, and external links. --LeeHollenbeck 00:10, 28 February 2012 (EST)

All good questions; I've been trying to figure them out also, lately. My approach is basically this:

• Every person and place gets a page on WeRelate;
• Where possible, these include the {{source-wikipedia}} template so that their info is brought in weekly from Wikipedia;
• Sources such as books and other documents go on Wikisource and are linked to from Source pages here;
• Other sources such as BDM certificates, which wouldn't be accepted on Wikisource, are transcribed here (and I'm working on some templates to help with this).

I favour WMF wikis over others, and then open content licenced wikis (such as WeRelate, OpenStreetMap, etc.), and then the Internet Archive, and then my own person web spaces. Under no circumstances do I think it worthwhile contributing to closed-access or closed-licenced websites. Ancestry give us nothing for free, so I'm not going to help them build a walled-garden of genealogical data! ;-) — Sam Wilson ( Talk • Contribs ) … 02:17, 28 February 2012 (EST)

I'm pleased to see folks concerned about using Wikipedia and Werelate to their mutual best advantage. There's truthfully no way to enforce good practice in this regard, but we have a Help Page that outlines a relatively shared sense of what we consider to be good practice (and some of the nuts and bolts of doing so). Beyond that, I've been working a personal wikipedia inclusion project for the last several years. My practices described there take something from the help page and include a fair bit of my own heresy. At present, there are over 19,000 person pages that are associated (in a programatically recognizable way) with backing Wikipedia biographies. I'm hoping to find ways that WP and WeRelate can be mutually supporting, but I'm afraid I'm a bit of a dreamer... --jrm03063 09:39, 28 February 2012 (EST)

I had not thought of WikiSource. That is an idea -- something connected to their Illinois portal like the McLean County History. Maybe I'll keep doing the biographies here, they are like garland on the Pando tree, and Part I could go on WikiSource or KanWiki.

I also had not thought to check if the had a talk page. Lots of discussion there. I'll have to look more at the personal wikipedia inclusion project. So far, my MyRelate person pages have no Wikipedia pages.

I'm very pleased to have come across such a positive approach to cross-wiki collaboration (as a contributor to both Wikipedia and Werelate). Can I also add the FreeBMD family of resources as something people should consider contributing to and linking in: http://www.freebmd.org.uk/ and also, to a lesser extent as they are not free copyright but are charitable, http://www.genuki.org.uk AndrewRT 17:30, 19 May 2012 (EDT)

The weekly contest [2 March 2012]

The weekly contest notice on the home page says a new contest starts at noon each Friday. But it doesn't say what time zone the presenter is using. --goldenoldie 10:51, 2 March 2012 (EST)

WeRelate now has a Transcript of Savage's Dictionary [17 May 2012]

Through the courtesy of Dr. Robert Kraft, we now have a transcript of the Genealogical Dictionary of the First Settlers of New England.

Users are encouraged to edit individual pages of the transcript to add links to corresponding Person pages (while leaving the narrative content as is). For example, volume 1, page 16 refers to Thomas Adams and his family. In addition, a template has been created that allows a page specification to also serve as a link to the corresponding page of the transcript, for example, {{savagepg|1|16}} -> 1:16.

The origin and creation process for the transcript is described in detail on the associated about page. The existing Source page for Savage has also been updated to reflect hints and tips appropriate to use of the transcript.

--jrm03063 19:18, 4 March 2012 (EST)

cool. Playing with this might be actually draw me back to WR.... Jillaine 21:03, 17 May 2012 (EDT)

Wondering about unknown vs. blank [26 March 2012]

In searching, I believe Unknown is treated as the literal name 'Unknown' (since doing a search for a name with Unknown brings back pages of Unknowns at the top of the list). Which means Unknown name fields should be left blank, which will be treated as unspecified by the search engine and so match anything. Is that correct?

Aesthetically I like having Unknown in the field (especially when it is the first name), and have seen others adding it so gather others do too, but as it may mess up searching, this probably shouldn't be done?

Unless search could be changed to treat Unknown as a wild card? Of course, this should probably be done in both the target (i.e., John Unknown finds John Doe or John Smith or John Unknown equally well) or in the result search potential (searching for John Doe would score John Doe higher than John Unknown which is higher than John Smith)? --Jrich 17:18, 22 March 2012 (EDT)

But what if you really did want to search for a John whose surname was not known? (Perhaps because you previously created the page and were trying to find it to make updates.) Then not having Unknown as a wild card would be preferred. Maybe there should just be a message notifying people that they should leave it blank instead of using Unknown when they really don't know it. -Moverton 15:17, 23 March 2012 (EDT)

If you made the edits recently, searching your Watchlist or Contributions would probably be nearly as effective. If you made the edits some time ago, then there's no guarantees the name hasn't been changed from Unknown by somebody else, so it seems like you would want the wildcard anyway in that case. I also imagine the searching logic gets used in lots of places besides straight searching, like adding new people, finding duplicates, etc.

Even if unknown name fields are supposed to be blank, the tendency to use Unknown will probably always be there because that is what is seen in page titles. So it would probably be useful when saving pages to convert Unknown in the name fields to blank. Though, again, a blank given name is awkward. --Jrich 16:08, 23 March 2012 (EDT)

Unknown and blank are treated similarly by the search engine: If you search for Givenname=John and Surname=Smith and set the drop-down at the bottom of the to "Exact and close match", then people whose given name is "Unknown" and people whose given name is blank are not returned. If you change the drop-down to "Exact, close, & partial", then people whose given name is "Unknown" and people whose given name is blank are both returned, but ranked lower than an exact or close-matching given name. Eventually I may have the search engine distinguish between a "missing" name and a known name and rank people with missing names higher than people with names that differ from what you searched for, but if I do, I'll treat Unknown and blank both as missing, and you'll still be able to search for "Unknown" names as you can today.--Dallan 20:07, 26 March 2012 (EDT)

Free webinar on Copyright Law for Genealogists [27 March 2012]

Since we address copyright issues on WeRelate, this free webinar should be of interest to users. Details below. Clipped from email received from The Association of Professional Genealogists. --Beth 20:53, 27 March 2012 (EDT)

APRIL'S WEBINAR Facts, Photos and Fair Use: Copyright Law for Genealogists Wednesday, April 25, 2012 — 9:00 p.m. Eastern Daylight Time Presented by Judy G. Russell, CG

Materials and records created by others are the bread-and-butter of genealogy. But whether copyright law allows use of old photographs, reports and articles can be murky at best. Join "The Legal Genealogist" Judy G. Russell as she sheds light on what’s copyrighted and what isn’t, when and how copyrighted materials can be used, and how to handle copyright issues with our own clients.

• Reserve your Webinar seat now at:*

https://www1.gotomeeting.com/register/353574385

System Requirements: PC-based attendees Required: Windows® 7, Vista, XP or 2003 Server

Macintosh®-based attendees: Required: Mac OS® X 10.5 or newer

iPad, iPhone and Android attendees Required: Free GoToMeeting app from the App Store or Android Market

We hope you enjoy them!

The APG Professional Development Committee

Sorting out Canadian History [11 April 2012]

About ten days ago I put up a problem on a Place or Source Talk page, hoping someone would see it and sort out the parts I can't do for myself.

At the moment the WRsource for all Canadian 1851 census entries start off

Canada East, United Province of Canada. 1851 Census of Canada. (Ottawa, Ontario, Canada: Library and Archives Canada), followed by our specific reference to microfilm reel, section and page.

This is fine if you are working in Canada East (now Quebec), but doesn't fit if you are working in Canada West (now Ontario).

Canada went through four different reorganizations between 1763 and 1867:

1. Prior to 1763 the whole area now known as Canada was in French hands and was called New France (except for Nova Scotia which was called Acadia).

2. In 1763 it became British territory and was broken into the separate colonies of Nova Scotia, New Brunswick and Canada. Nova Scotia and New Brunswick did not link up with Canada until 1867.

3. In 1791 Canada was broken into two administrative divisions: Lower Canada (Quebec) and Upper Canada (Ontario).

4. In 1841 the two divisions were renamed Canada East and Canada West and further governmental reorganization occurred. Wikipedia refers to Canada East and Canada West as the United Province of Canada. I do not know what they base this on, but it is much more likely that the entity was called the United Provinces of Canada. Canada East and Canada West were two equal parts of a whole. This is not so when it comes to places in WeRelate.

5. In 1867 Upper and Lower Canada became Ontario and Quebec, respectively, and joined with New Brunswick and Nova Scotia to become the British Dominion of Canada. The other present provinces of Canada eventually joined the confederation independently of each other. The word Dominion has since disappeared from the description.

There were two censuses covering Canada West and Canada East--one in 1851 and one in 1861. The titles used as WR Sources should be the same for each except for the year. New Brunswick had a census in 1851 but it was entirely separate from that in the United Provinces and should have a separate Source. (Nova Scotia may have had one at the same time, but I have not seen any reference to published data.) All original data for all censuses (1851-1911) is held by Library and Archives Canada (LAC) at Ottawa. Transcriptions have been carried out by external organizations and some are available online as free and pay websites. LAC itself has originals online (but not necessarily transcriptions) for all censuses except 1861 which I understand is due this year.

Canada West did not have a system of civil registration and therefore the two censuses of 1851 and 1861 are vital for genealogists trying to trace their families during in the mid-nineteenth century.

Summarizing, could we please have a group of places described as

New France (to 1763)

Canada (1763-1791) -- and I wish I could think of a more descriptive name here

Lower Canada (1791-1841) and Upper Canada (1791-1841)

Canada East and Canada West = United Provinces of Canada (1841-1867)

Canada (post 1867)-- I am sure this is in place now

Thanks --goldenoldie 07:28, 11 April 2012 (EDT)

The general rule on WeRelate is to title place pages as they were around the year 1900. Each place page provides fields for defining alternate place names and the year ranges those names were in place. So, for Place:Ontario, Canada, we could add alt names of Canada West and Upper Canada.

Regarding the source titles, our Help:Source page titles page states that at the county level, the census sources for Canada should be titled County name, Province name, Canada. YYYY Census of Canada. I agree the census source page titles should be consistent throughout the years. --Jennifer (JBS66) 10:02, 11 April 2012 (EDT)

For the U.S. census, I put the locality in the "Record name" field of the source citation on the person's page, and I only reference the main U.S. source. This results in a citation that looks like "ED 46, 3rd Ward Kansas City, Jackson, Missouri, in United States. 1930 U.S. Census ...". When I look at this source's description of the census, I can see a case to be made that there should be three subordinate source pages for each of the censuses in the united Province of Canada, Nova Scotia, and New Brunswick. (Notice in that source it only refers to the "Province of Canada", not the "United Province of Canada" or plural "United Provinces of Canada". But I don't know what is more accurate.)

On the page Source:Canada. 1851 Census of Canada, for example, the problem is that the system only shows the first item in the "Places covered" list in the citation. If you use the three subordinate sources instead, you solve the problem as each of those sources only needs one place in its list. For the main Canada page, I suggest either removing the list of places and replacing it with just "Canada", or just add Canada as the first place in the list. That way you will not see the wrong place on so many of your citations. -Moverton 13:03, 11 April 2012 (EDT)

Jennifer, I must admit I have not seen the recommendation you quote for titling census sources for Canada.

I don't think it is workable because Canadian census districts are based on federal electoral districts and not on counties within the provinces. Electoral district boundaries changed every ten years as the census indicated population imbalances in the size of the various districts. The next census was based on the new boundaries. There might have been a point when an electoral district and a county was one and the same, but in many areas this passed before 1900. To reference a location with the LAC you must give the whole name or number of the electoral or census district or your question gets a null response.

When I started to look for census sources on WeRelate a couple of months ago I immediately selected the national source for the year in question. The census was organized on a national level, therefore I expected to use a national source. The frustration was in discovering that the group of censuses were presented in such a non-uniform way.

Even five years ago the common method to find a family on a Canadian census was to search an individual FHL microfilm covering a specific geographical area. At that point referencing the county and its province made sense. But now the census for the entire country is online at various websites as both original material and as transcriptions. We can dip into this database here and there as our wandering families oblige.

I want to have a go at altering the organization of the names of the Canadian censuses but some re-titling at the Place Category level must come first.--goldenoldie 16:56, 11 April 2012 (EDT)

WeRelate standard of place names in 1900 versus Wikipedia articles [14 May 2012]

If the WeRelate standard is to use place names as they appear in 1900, why do place name descriptions start with a paragraph out of Wikipedia that gives the population and the political organization of the place in 20xx?

Often the history section of Wikipedia articles includes material useful to genealogists, but the first section can give a false impression of the area where an ancestor was living a century or more ago.--goldenoldie 10:04, 27 April 2012 (EDT)

Because it is easier than starting from scratch. Wikipedia has its own design goals and motivations and these won't necessarily align completely with WeRelate. Using historical names is also likely to "give a false impression of the area where an ancestor was living" as they appear to reside in differently named locations without ever moving, and using dates with an about qualifier could make it impossible to decide on the correct name. No system is perfect, but the system in use seems relatively functional in most cases given the limited resources available. --Jrich 12:20, 27 April 2012 (EDT)

Let me further add, that if a place is known with sufficient precision - say a particular plot in a cemetery, a historical residence or garrison house - GIS coordinates, using the googlemap template can eliminate the problem of historical name ambiguity.

Even GIS co-ordinates need to be used carefully. Yesterday I found a Contained Place in an Ontario, Canada county situated (according to the accompanying Google Map) just north of the Himalayas. I don't know my modern Asian geography well enough to be able to report what country it is now in, but twenty years ago we could safely have said it was in the USSR.

Sure enough, someone had ended the co-ordinates with an E instead of a W. A correction has now been made--after another check with Google Earth.

Perhaps, but isn't the real problem there a failure to critically evaluate your information? I generally don't use GIS that I pick up from elsewhere. It's a matter of specifying a location that I know with certainty - opening a mapping site, zooming in, and lining up the cross hairs to get a reading. Then verify that your reference does what you expect. --jrm03063 17:06, 27 April 2012 (EDT)

As I've said before, I think the 1900 standard is kind of dumb. Even the LDS geographic names are not consistent with that date. It would make a lot more sense for WR, as a genealogy tool of the future, to set a more modern date like 2000. In any event, if the 1900 date is going to continue to be used, perhaps what the site needs is a useful 1900 geography resource, including maps from public domain sources (1900 atlases, 1900 encyclopedias, etc.), and a comprehensive gazetteer that's also taken from a reliable 1900 source. Now, where's Mr. Peabody and the Wayback Machine when you need him? — Parsa 23:09, 14 May 2012 (EDT)

Person page display suggestion [16 May 2012]

I'd like to suggest a small display change for certain Person pages, with Person:Omer Claiborne (1) as an example. (I've been building a large and extended Claiborne family network on WR lately.) If there's a date or place of marriage, or a source cited for a marriage, then a line shows up on the Person page under "Facts and Events," beginning "Marriage," with the spouse's name and so on. Well and good. But if there is no other data than the mere fact of marriage -- which often happens when you pick up a spouse's name from a joint grave marker at Find-a-Grave, for instance, and choose not to include that as a source -- then it appears that no such line is generated on the Person page.

Now, because the subject's parents & siblings appear at the top-right, and then the subject's own spouse(s) & children below that, if there are a lot of siblings, then the only mention of the spouse's name -- or even that there is a spouse at all -- is likely to drop "below the fold," and you have to scroll down to make sure you're not overlooking them.

In the case of Col. Omer Claiborne, noted above, his daughter was the famous "Liz" Claiborne, and I picked up her mother's name from Liz's own Wikipedia page. Even Omer's obit doesn't mention his wife's name, for whatever reason. I dislike being forced to make up an approx. date just to get the display to work the way I think it ought to. And I dislike, for various reasons, to cite Wikipedia for any fact that doesn't bear directly on the subject of the Wikipedia page. And I will chase down further documentation on those several relationships when I have the chance -- but in the meantime, it seems obvious to me that Omer's page ought to mention his wife's name without having to scroll down the page. (Okay, Omer, specifically, doesn't happen to have a lot of sibs, but I have seen this issue come up recently in cases where there were a dozen of them.) A "Marriage" line could be generated under "Facts and Events" by the mere fact of the existence of a Family page involving that person -- right? It could be just "Marriage [blank date] [blank place] SpouseName." I'm guessing the programming involved here would be pretty minor, a "Yes/No" thing. Anyone have a reaction to all this? Am I simply overlooking something? --Mike^Talk 12:08, 7 May 2012 (EDT)

This problem is can be especially misleading if there are two or three marriages and some have dates and some don't. Then some marriages appear in the Facts and some don't, while the various spouse info boxes are not visible. However, even if the dateless marriage was forced to appear, estimated dates would still be desirable to have the order reflected correctly in the list of facts.

I would also like to suggest that if there are intentions/publishment of a marriage but no marriage date (what is the proper tag? Marriage Banns?) that it be displayed in the infobox "int. 30 Jun 1700" in lieu of the missing marriage date, the same way christenings are displayed in lieu of a missing birth date. If the marriage date is there, it would go in the infobox, and the intentions not. There are many couples for whom only their intention is known, but no marriage. Intentions should really be entered as separate facts, since the location may be different than the location of the marriage, but I find that adding an intention and also adding marriage dates of "Aft. 30 Jun 1700" just to make the marriage appear in the facts and to get the infoboxes ordered correctly is kind of kludgy.

Finally, I noticed that people with multiple marriages only list one spouse in search results. For example, it I search for Thomas Prence, Person:Thomas Prence (1) is listed showing only spouse Patience Brewster and none of the other three wives he had. I don't know if this was a recent change, or if this has always been so and I just noticed it. It would be useful to see all the spouses names displayed. Many, many times, the perspective that one has when working, doesn't encompass the entire life of a person being searched for, like when attaching a single child to just one of his marriages, so displaying only one spouse can make it difficult to identify the page as the right one. And it isn't always the first wife, so I am guessing it is the first Family page created, which makes it somewhat unpredictable. --Jrich 13:01, 7 May 2012 (EDT)

I agree with Jrich. I have encountered some of the same problems. I am wondering if the "missing" spouses in search results might be one of the reasons I find so many duplicate marriages? If you don't find what you are looking for in the search results it is easy to conclude the family doesn't already exist in the database - then you add it and now there are duplicate families, often with duplicate spouses.

I also try to use Before or After estimated dates when there are multiple marriages as a way to force them into the correct sequence. In my contributions there is a person with 8 recorded marriages to 7 different spouses - possibly not a record but certainly a good argument for being able to find all of them when searching, and trying to get them displayed in the correct order!--Jhamstra 17:07, 7 May 2012 (EDT)

As it happens, I came up with a similar problem just this morning, with the Rev. John Peter Livengood. He had four wives and only for the first one do I have a marriage date, or any other info. The other three names came from a county history and they spread over, probably, 30-40 years, so I hate to have to make really pointless guesses as to the dates. But they appear on his Person page, at least, because I did make notes on each of the Family pages as to order of marriage & the number of kids they had. --Mike^Talk 07:46, 15 May 2012 (EDT)

Not that hard to put estimates in that mean something: the first wife died 1843, so you could put Aft 1843 for estimated date of second marriage. 1850 census shows second wife with kids 5 4 3 2 and 1 month (plus 7 year old that is probably left from first marriage), so that accounts for the 5 you mention, and one can conclude that she probably died soon after, and you could put Aft 1850 or say Abt 1852 for third marriage. One could then guess Abt 1855 for third allowing time for number of children you show. However, Find A Grave turns out to be a rich source, giving deaths of wives in 1843, 1852, 1854 and 1887 respectively. So now you can make good estimates. --Jrich 09:44, 15 May 2012 (EDT)

• I fixed the order of marriages for you. All you have to do, is edit the person page and drag the family pages shown in the list into the correct order. As you move your mouse's cursor onto the left border of the box around the listed family page, the cursor changes to indicate that you can drag the item. It isn't really obvious that you can do this, but this feature prevents you from having to enter dates solely for the purpose of sorting the marriages. Moverton 16:27, 16 May 2012 (EDT)

lipstick on a pig [19 May 2012]

Am I the only one getting tired of all the meaningless cleanup that is going on? How people that know nothing about a person waste time prettying up a fact that is obviously wrong, or mangle a fact into an error to make it look presentable, or even change data into their preferred form when the existing form is not wrong, and in the process, alert all the watchers: alert! come see the meaningless change to this page. What have I seen in the last week or so? Towns in Massachusetts move to England, towns in Massachusetts are fixed to go from red to blue on a fact dated before the Mayflower, dates are put into lower case even though most GEDCOMS force them to upper case, Sr. is changed to Senior, "Abt" is changed to "abt" or "ca". When these kinds of changes are the only changes made to a page, well, then it is pretty clear a lot of mindless busy work is going on.

It is one thing to come along and combine 3 or 4 alternate birth dates into one researched birth and provide a quality source citation to prove it. That is good stuff that improves the page and increases the value of the WeRelate website! Is is another to studiously change all 4 months to lower case without trying to resolve the confusion. That is not a change worth bothering the watchers about and should probably be deferred until you, or somebody else, actually cares enough to take the time to do some real genealogy and figure out which alternate is right.

I'd like to suggest that when you see a page that needs cleanup, try to find something to add to it, to improve it. It may take an hour or two of searching to find sources, but add that missing death date, add the rest of the children, cite the source the justifies the data that is on the page. Then maybe you have some claim to cleanup the cosmetics. At least when you bother the watchers with the notification that changes occurred, there'll be some substance there. If you can't commit that much to a page, then perhaps you should just leave it alone. After all, every piece of information that goes on a page should have a basis, and if you haven't done any research then you don't know that basis, and you are in danger of making a wrong assumption about the intended meaning of a potentially wrong fact already on the page, thereby completely obscuring a recognizable error with an additional mistake. --Jrich 12:16, 17 May 2012 (EDT)

Once again today I apologize for annoying you. I will cease and desist. I was actually removing the UID #'s which annoy me and along the way attempted to cleanup some other data. Obviously incorrectly. So not to worry I will leave the pages alone with the UID's. Have a great day. --Beth 12:33, 17 May 2012 (EDT)

Beth, this has been going on a long time, and the post was not focused on you, who showed up in my watchlist only this morning, and in fact, not the only one doing so this morning. Rather, this was motivated by what seems to be a growing trend (admittedly, your respected user name adds weight to my perception of trends) to simply make cosmetic changes to a page without apparent research or significance. (Most pages having UIDs are in significant need of more research, so it's not hard to find some improvement that will allow you to make the changes significant.) Some mornings it seems like that's all people spent their time doing, as dozens of such meaningless changes often show up in my watchlist. One of the reasons for posting this is to see what others think. My opinion is clear, I think, but perhaps I am out of step with the others. What 99% of the pages need is more research and sources, and that can't be done by computer, and cleaning up wrong facts almost seems like a waste of time until that is done. --Jrich 14:29, 17 May 2012 (EDT)

I believe you have a valid point, and I am pleased that you pointed out the problem of the numerous emails with no significant changes made to the pages. Rather ironic I know, but because I have workers here doing home improvements and am likely to be interrupted at any time for consultation, I was looking for a "mindless" task and decided to remove UIDs from pages. I did not think about the numerous emails users would would receive. Since this is a Wiki, I do not think it practical to place limitations on editing pages, but I do agree with you and will find some other "mindless" task. Maybe I will even clean the rest of my house. <g> I would ask when one is improving a page by adding something significant would they please also delete the UIDs and RIN numbers because they are of no significance on a community page? --Beth 16:24, 17 May 2012 (EDT)

Is there an agreed convention for capitalization of months? If so then perhaps a checker to warn when not following the convention would be useful? Otherwise there is no point in debating this? Personally follow the dd Mon yy convention but apparently this has not been agreed upon?--Jhamstra 19:00, 17 May 2012 (EDT)

Yes, there is an agreed convention for capitalization of months. See Help:Style guide Dates.--Beth 19:36, 17 May 2012 (EDT)

Dates are only one issue.

GEDCOM specifies that months are case insensitive. So data coming in from GEDCOM uploads depend on the software. If I were to upload a GEDCOM, my software would make all the dates be upper case, as is seen on Person:Judith Carter (6) which is a remnant of a trial I made of GEDCOM upload. I checked some other people's recent GEDCOM uploads and see both lower and upper case dates suggesting to me that WeRelate takes what it is given and it comes in both styles. Changing the case of these dates really makes no difference in usability. Does it need to be changed? Does it need to be changed so badly that it can't wait for a more comprehensive edit?

Another area is place aliases. The pipe alias on locations is legal. So when is it allowed to remove or add aliases according to one person's preferences assuming the previous value represented another person's preference? Is Boston, Suffolk, Massachusetts, United States|Boston, Mass. worth respecting or worth removing? Is Boston, Suffolk, Massachusetts, United States|Boston, Suffolk County, Massachusetts Bay Colony worth respecting or worth removing? They are legal. Yet people do edits where all they do is remove or add these aliases Does it need to be changed? Does it need to be changed so badly that it can't wait for a more comprehensive edit?

There are other cases where changes are made that seem motivated solely by personal preference without increasing anybody's knowledge of the genealogy or the pages usability. It doesn't seem necessary to me. --Jrich 21:09, 17 May 2012 (EDT)

Just want to point out that not everyone has the time, opportunity or access to do research on a given page but they may have enough time to do clean up ala lipstick on a pig. They should not be discouraged from doing so. They could be encouraged to select "minor edit," however, to avoid filling watchers' inboxes. Jillaine 21:13, 17 May 2012 (EDT)

Unless I am missing something, any kind of change that can be done without research falls into the obvious and meaningless category, such as changing "DEC" to "Dec" (in accordance with style guidelines but not honored by GEDCOM), or "Abt" to "abt" (a common occurrence despite being in contradiction to style guidelines). If WeRelate users really want this kind of uniform formatting, then I recommend that everybody go to the Suggestion page and endorse some suggestion for a bot to fix these formats, and leave people free to do the hard work that only people can do, which turns out, to be... research! How can you clean up a date of 4-5-1644 without doing research? This could be Apr, May, Jun or Jul. How can you cleanup 3 or 4 alternate birth dates without research? This is the type of cleanup that needs to be encouraged. Or some of the other "cleanup" that only appears meaningless, such as: deciding if the red location "Yarmouth" is in England or Massachusetts, or merging people based on the unsourced data already on their pages (which is often wrong because it comes from some Internet site that confused two different people to begin with), or renaming John Doe and Jane Doe to John Doe to Jane Unknown. All these last cleanup activities should only be done when one has time to do a research. So I completely disagree. People should be discouraged from making changes to a page they haven't researched. --Jrich 23:28, 17 May 2012 (EDT)

It seems like it would be pretty simple to create a bot to automate some of these things (standardizing month name capitalization, for example). Are there any active bots, or any in development? Jdfoote1 22:03, 17 May 2012 (EDT)

Wow. I for one am thrilled with anyone who will take on mindless tasks that need to be done. Just use the summary field and hit "minor edit" -- which exists for *precisely* this reason--and this entire problem disappears!--Amelia 00:32, 18 May 2012 (EDT)

Well, my watchlist works differently than yours. It shows all pages that have changed, whether major or minor. And often, if the last change was minor, the change is shown as minor even when it was immediately preceded by a major edit (in my own edits, it is not infrequent that the last edit is minor: "fixed typo", but that is fixing a major edit I had just made immediately before that). Not to mention that a propagated major edit turns into a minor edit after they propagate. So I think the problem isn't disappearing, it's being ignored. Which is maybe why I'm complaining about it, and you're not.

Then there is the mindless part. It is that. Yesterday I had one person cleaning up pages by adding pipe aliases, and another person doing cleanup by removing pipe aliases. Maybe we could coordinate and agree to add pipe aliases on even days, and remove them on odd days?

Finally, there is the "need to be done" part. Well, I find that what needs to be done is not changing the spelling of DEC to Dec, but to find the source that tells how it is we know the answer is December in the first place. I've seen plenty of pretty websites, but I've learned through experience, if the sources aren't there, they're not worth the time it takes to read them. One cleanup yesterday got me looking at the page in more detail. Four facts had been nicely cleaned up. I spent an hour searching on books.google.com and promptly deleted two of them as impossible and modified the other two because they were less precise than current knowledge of primary sources allows (adding those sources to the page of course). So nothing is left of the cleanup. What a waste of lipstick! What "needs to be done" is for people to spend time productively, doing research, not doing mindless cleanup that probably should be automated, and in truth represents more personal preference than it represents need or value or improvement. --Jrich 09:02, 18 May 2012 (EDT)

First, I'm quite certain my watchlist works the same way as yours. I was talking about emails, which is what I thought you were complaining about, and there is an option not to receive emails for minor changes. Minor changes are also clearly marked on the webpage list, if only people use them. I'm watching 14,000 people, and I really don't have the issue you describe. Second, you seem to have a problem with the concept that not everyone has long blocks of time when they can concentrate on this site. There are many, many things that can be done here when one is multi-tasking or brain dead, and there are many things that should only be done when one is paying attention. Implying that one can do the latter when their schedule allows only for the former is not productive. And your rant serves only to discourage anyone from doing anything that they don't think lives up to your extremely high standards. I think it's unproductive and that you are making a mountain out of a molehill, to borrow another phrase. A more productive undertaking would be to make a list of other minor changes that would be productive - like removing old gedcom sources, strings of nonsense in note fields, etc., so that people who are trying to help would have a more productive place to start.--Amelia 11:47, 18 May 2012 (EDT)

Well, Amelia, that was an important change we were both just notified on. It wasn't marked minor, so I know you got an email about it and got to share in the excitement. --Jrich 16:41, 19 May 2012 (EDT)

All of us are long time users of WeRelate and useful contributors. We need to work together for the health of WeRelate. Kinder comments and kinder critiques are preferred. We definitely need more users and don't want to scare new users off by our disagreements. If you Jrich prefer to watch every edit including the minor edits then you will definitely have more emails with the number of pages that you watch. This is a great opportunity for you educate new users tactfully and help them understand how WeRelate works. It is also an opportunity to figure out how we may alert users of important additions to WeRelate. I did not know of the existence of the Style Guide until recently or didn't remember it. I also found the Find A Grave templates on my own. Perhaps y'all know of a better way to communicate the additions to WeRelate. Warmest regards. --Beth 19:44, 19 May 2012 (EDT)

Genetic Genealogy [21 May 2012]

Could I ask what is your attitude to including information about genetic genealogy here? In particular, information about Y chromosomes, which would be common to many people with the same surname and all (subject to mutations) male line descendants of a given person. If you would welcome it here, where could it be placed? Presumably the Person: Surname: and Category: namespaces would be ok? Thanks. AndrewRT 17:44, 19 May 2012 (EDT)

We use the Surname page for this purpose. There are several Family Tree DNA adminstrators on site but not sure that any of us have actually posted the results on WeRelate. We have posted links to the site on the surname page.We welcome your additions in genetic genealogy to WeRelate. Our YDNA results template is in need of an overhaul. Thanks so much for participating.--Beth 19:55, 19 May 2012 (EDT)

thanks! Are there any good examples you could show of how this template has been used? AndrewRT 08:07, 20 May 2012 (EDT)

The template has not been used. If you search WeRelate; all; keyword DNA, you will find a variety of DNA pages. There is not a standard entry template. So however you choose to display your data, I would still either use the surname page or place a link on the surname page to your DNA project. The category DNA testing does not have a parent category and is not on all of the DNA related pages.--Beth 10:12, 20 May 2012 (EDT)

ok. is there any easy way to get a list of people on werelate who have data on ysearch or another public source? Are there copyright issues if we copy other peoples results? Would you work with me to design a template? AndrewRT 12:57, 20 May 2012 (EDT)

I do not know how to get a list of people on werelate who have data on ysearch. Maybe someone else does. Category:DNA Testing is now a page. I am searching WeRelate and adding this category to the relevant pages using the pipe and surname to sort correctly. I am not any good at designing templates, but I found that Parsa has created a table for results from 1 to 37 markers. See User:Parsa/DNA. This looks good to me. Maybe Parsa or someone else could convert this to a template and add tables for the other markers. --Beth 14:31, 20 May 2012 (EDT)

Had a look through these pages and it seems ripe for expansion and organisation. I'll make a start on creating a template we can use. Few questions:, to summarize discussions so far:

1. Is generic genealogy information welcome on werelate -- seems answer is yes.

2. Should y chromosome info be added to Surname page? The issue I have with this is what about polygenetic names like Smith, where you can have lots of very different y results? Even a monogenetic name like Tulloch can have multiple results due to cases where estate workers have taken their laird's surname, not to mention cases like adoption, unmarried mothers, remarriage and cuckoldry. Finally, I have one example of two descendants of one person several centuries earlier having slightly different results due to genetic mutation.

3. Should info be added to person pages? Most testers are living so wouldn't have pages themselves. However, info could be added to male line relatives, and could also include the relationship to the tester so that conflicts such as above could be described.

These considerations affect the template design so would want to agree it as part of design process.

All thoughts appreciated! AndrewRT 15:07, 20 May 2012 (EDT)

Unless you were able to do an actual genetics test on one of your ancestors, I imagine that the Person pages would only contain genetic information if it can be determined that all of his descendants had the same common markers. I haven't gotten too deep into the DNA stuff, but I think it would be interesting to get many different male descendants from different branches of a tree to sign up for testing to see if it would confirm the tree and establish common markers on the different lines. -Moverton 12:54, 21 May 2012 (EDT)