WeRelate talk:Watercooler

Sources & Repositories and Source Review

New User Support

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, 2012.

Handling of parentage contenders? [5 January 2013]

In talking over the evidence for parentage of immigrant Richard Kimball, the discussion seemed to be heading towards consensus that neither the currently linked parents nor those suggested in The Great Migration were adequately supported.

This raises the general question of how this situation should be presented on WeRelate. What do people here think? Should no parents be linked for the person, or should both sets of parents should be linked as ("duplicate") parents? Presumably in either case the text of the Person: page should include some mention of the candidate parents and the issues. --Robert.shaw 04:24, 18 December 2012 (EST)

Since I was party to that discussion, I should make a comment. What I stated there was my preference; having duplicate parents will confuse readers. The man doesnt have 4 parents. But in Richard Kimball's case, there is insufficient proof for either set, so it would be wrong to link either sets as if they were equally true. My preference, as always, is to have a note on the person page discussing the problem, linking the sets of parents within said comment, but leaving them out on the actual 'parents' field. JRich and I came to similar compromise when I was still new here. Daniel Maxwell

The man doesn't have zero parents either. It would actually be clear to readers if two sets of parents were on the page that the page represents confusion about his parentage, and then when they read the notes it become clear why. There are people out there that are going to have one set, or the other set. So for searching purposes, having both sets will help either set of people looking for this page. Also, some GEDCOM may come that gives Richard Kimball one or the other set of parents, so that the one set will then be added as if they are the only candidates. Having both parents seems to be the best answer, because it would ensure that the uncertainty would continue to be represented through GEDCOM uploads, it would give good results for people searching for either case.

One distinction should be made clear. There is actually circumstantial evidence for both sets of parents (currently documented on the Talk page). They are not random guesses. Better to correctly indicate uncertainty than to indicate the wrong answer with certainty. --Jrich 10:04, 18 December 2012 (EST)

I dont mind having them both on the page. I only do not want them linked. Otherwise 'having' both in a discussion at the bottom doesnt bother me. What you have is evidence, not proof (there is a difference), and in that case I think it is wrong to pretend that it is proof. Daniel Maxwell

I would prefer that we avoid having multiple parents - since that's the sort of thing we want to be able to look for as a consistency item in mass sweeps of the database. I deal with situations like this with a narrative section called "disputed lineages" (search on that for examples). The content of the section would make note of the different potential parents and relevant facts. The section would be reproduced on the person page and the family pages for both sets of parents. If one set of parents is not only considered more probable than the other - but indeed likely - only then should it be hooked in fact. --jrm03063 11:33, 18 December 2012 (EST)

Is anyone aware of any system used by any other genealogy programme or website for potential relationships? I've never come across it, although it may be something that WeRelate could look to design that would give us an advantage over other websites. For now, I would agree that a narrative comment in the main text would be the best place for it, with no parents linked given that neither is proved. Although I acknowledge your point about future GEDCOM uploads - could this broader issue be addressed by somehow having a field that says that x should not be added as the parent of y? AndrewRT 18:23, 19 December 2012 (EST)

I don't think that we should ever represent that the results of a GEDCOM upload will ever be complete on any given page. The load should save on possible clerical work and errors, but a user should still expect to review every page they create (at least eventually). What I could imagine doing is providing fact types that allow us to make positive assertions about missing information. For examples:

• Person not known to have ever married
• Person married but spouse not known
• Person married but children of marriage are not known
• Person married but family not believed to have had children
• Parents of person not presently known

We could make the GEDCOM upload smart enough to refuse to override these situations within the context of an upload. --jrm03063 18:38, 19 December 2012 (EST)

We could presumably come up with 5 new template along the lines of nomerge, that can only be removed by manual editing, and modify the GEDCOM upload to respect these. They don't exist now, and software changes seem to have a long lead time, so that's not much of an answer at the present. The other question is search, in case somebody searches for the Richard Kimball who is son of one or the other candidate parents, and nothing matches.

Nobody has duplicate parents in real life, but the state of our knowledge doesn't always quite know the actual situation. Clearly duplicate parents are listed because there are inadequate sources. But that is exactly the state of our collective knowledge in some cases, and when not, this is easily cleaned up by adding the definitive source and removing the wrong parents.

In a collaborative environment, it would seem there is value in being able to represent alternative theories. For example, by putting Richard Kimball into both families, you essentially involve the watchers of both Family pages in attempts to resolve it. Plus it makes it more likely that obvious contradictions with one answer, or the other, aren't overlooked.

Insisting on "proof" in order to enter data seems very problematic. First all, that would imply sources would be required, which they aren't. Second, it is clear that the varying standards for proof among researchers would make this a very ambiguous standard. Finally, there is many an accepted line based on significant amounts of assumption and circumstantial evidence, i.e., on less evidence than either of Richard Kimball's proposed parents. --Jrich 19:46, 19 December 2012 (EST)

Sources not being required? Is that not, in fact, the whole purpose of this website, rather just another gedcom dumping ground? The 'evidence' out there apparently hasnt lead to anyone else leaping to the conclusion of the other couple as the parents, so if it isnt up to any professional's standards why should it be up to 'ours'? Daniel Maxwell

Re Sources: I believe the official position is that sources are desired, not required. It seems to me that, at some point, some numbers were published, but if I recall correctly, it seems to me that the vast majority of pages didn't have sources. And no, the single most important point of this website would be collaboration. Now I might argue that collaboration requires sources so that things remain impersonal and objective, but there are clearly some who don't seem to think sources are needed.

Personally, I take all genealogist's statements as opinions, and want to see the evidence. Even good genealogists make mistakes and even bad ones get things right. Truth doesn't depend on who says it. In this case, there is no proof, and while there are sources on both sides, they all amount to guesses and opinions. So any kind of strict proof means no parents are listed. I just don't think that is the most useful presentation. --Jrich 21:02, 19 December 2012 (EST)

There is another way to deal with the uncertain spouses or parents when there is no preferred candidate --

1. Create an Unknown Family (for parents) and/or Person page.

2. Create Alt Names for each of the candidates. I believe Alt Names now show-up in search results?

3. Create Notes and/or Sources for each of the Alt Names with the relevant discussions/evidence.

And now for my question of what do you do when someone was adopted and there is no record of the birth parents?

--Jhamstra 22:57, 19 December 2012 (EST)

I never create an adopted child as the conventional child of the adopted parents. Instead, I will indicate the adoption as a fact on the family page, pointing at the person being adopted. Likewise, I'll create a fact on the person page indicating the adoption and pointing at the adoptive parents. --jrm03063 11:25, 20 December 2012 (EST)

"1. Create an Unknown Family (for parents) and/or Person page." - When I see this occasionally, I delete them. It seems like a waste of room, and by definition you cant really source it. Even if the majority of what is on WR is unsourced, the goal should be to strive toward sourced pages. There is however one exception to this - two persons are known to be siblings but the parents themselves are unknown. Honestly I dont see whats wrong with when seeing a page with no parents and the source says nothing about them, then they must not be known. "And now for my question of what do you do when someone was adopted and there is no record of the birth parents?" - well, their adopted parents arent really their parents. It would seem that if their biological parents arent known, that you dont add anything at all or have a note to that effect. Daniel Maxwell

I certainly support deletion of Unknown pages that do not contain any useful information. However if there is useful information, such as identifying siblings or other family members (eg parents), discussion of potentially who these people might have been, etc, then you should NOT be deleting the page. To me Unknown should mean unknown identity which is different than saying that nothing whatsoever is known about these persons. Sometimes much useful information can be known about someone whose name has not yet been established.

If we are going to operate from the assumption that Unknown pages should not exist then maybe we should title cases where the name has not been established as Uncertain rather than Unknown. But unless that convention is agreed and applied then blanket deletion of Unknown pages is a BAD PRACTICE.

--Jhamstra 09:35, 20 December 2012 (EST)

Let me clarify; by 'delete' I mean 'remove the link to'. I have no power to delete pages beyond the ones I created where I am the sole watcher. Several times I have run into an end of line 'John Smith' who for no reason has a stub 'Unknown Smith' and 'Unknown Mrs Smith' linked to him (in one case with 2 generations of 'Unknown'!). Thats the only thing I remove. I dont remove those in the case where there are known siblings but nothing is known of the parents. In fact, I did one of these recently when I was finishing up the early John Marsh of CT line. A sourced example - Person:Unknown Marsh (9). Daniel Maxwell

Feel free to mark such pages with the speedy delete template before cutting them loose. Also, when nominating a page for delete, don't feel that you have to be absolutely certain that the page is wrong. Probably is good enough. Also consider the difficulty of re-creating the page. If the page is essentially empty, or doesn't contribute a potentially useful link, it's no harder to re-create later than if you leave the page for now. In other words, the bar for speedy delete is very low for empty end-of-line pages. --jrm03063 11:22, 20 December 2012 (EST)

It occurs to me that my suggestion may not have been clear enough - I meant to do (1) and (2) and (3) - not (1) or (2) or (3). Creating an Unknown page with no further information does not add value to the database

Let me also offer another example of how I have dealt with the problem of uncertain parentage and known adoption. Consider Richard Stansell. There are no VRs for Livingston County MI in the 1830s. Circumstantial evidence seems to point to Richard being a son of Henry and Mary Stansell, however some researchers consider Richard to have been the fourth child of Nicholas and Susannah Stansell who reportedly died unmarried. After the death of his parents Richard was adopted by Linus and Phoebe Clark. Depending on who were his parents they either died before 1850 or after 1860.

--Jhamstra 09:58, 20 December 2012 (EST)

Replying to Jrich: "We could presumably come up with 5 new template along the lines of nomerge, that can only be removed by manual editing, and modify the GEDCOM upload to respect these. They don't exist now, and software changes seem to have a long lead time, so that's not much of an answer at the present" - yes I think that would be an excellent development, with benefits in several areas including this one. I understand the development time is fairly long at the moment but I think that's ok - surely that's one of the benefits of "beta" that we can still have these discussions? AndrewRT 16:03, 20 December 2012 (EST)

Yes, we could do this after the fashion of nomerge - but positive assertions about negative information are useful plain-sight facts. They also have potential utility in an exported GEDCOM, even if other systems couldn't use them automatically. --jrm03063 18:59, 20 December 2012 (EST)

How did we manage to have a duplicate topic on the Watercooler? This topic is duplicated twice. I do not support "duplicate" parents. My preference is to indicate the possible parents in the narrative with links to the parents. Regarding known siblings whose parents are unknown; I know of no way to link them without creating unknown parents. In the future WeRelate plans to have an interactive genealogy program. Our decisions should be compatible with a genealogy program. I do not know if any genealogy program supports duplicate parents. --Beth 19:36, 20 December 2012 (EST)

Hopefully I only removed the duplicated part (left by a previous poster).

Few genealogy programs are designed for use by more than one person at a time so if the person favors one theory, he simply enters it. The collaborative environment introduces new needs. In this case, I think there is general agreement the answer is unknown, but other cases there have been camps that feel strongly one way, other camps that feel strongly another way, and some people that think both are possible (e.g, magazine articles written when the argument was raging over how many wives Person:Thomas Prence (1) had, were passionate and presented believable evidence both ways). Usually, after the straightforward attempts are made to resolve such problems, the next step is to branch out to siblings and other close relations looking for clues that might solve such problems (such as real estate inherited, or descriptions of relationships mentioned in wills and deeds), so keeping such links has value in illustrating the impact of the proposed relationship. As mentioned before, the presence of two parent links pretty clearly indicates the links are unproven, as opposed to the typical case of one parental link.

We could add notes to explain this, if duplicate links were not to be used, though to be thorough, that involves adding notes to at least three pages, Richard Kimball's and the two prospective parents, each saying there is a possible connection, because really all three are affected by the potentiality of the prospective connection. The way WeRelate works, the adding of a Richard Kimball page by a new user could start in any of those three pages. The failure of a new user to see the note could result in a duplicate page, or adding one set of parents, or the other, because the new user is merely following the one source they have in front of them.

So, if duplicates aren't allowed and no parents are to be listed, I guess the protocol becomes every time some new user or GEDCOM adds one set of parents, or the other, the watchers inspect the provided sources, and simply remove the parents again, unless the author has cited some primary basis that can't be explained away? --Jrich 13:00, 21 December 2012 (EST)

I think it best to not link parents when there is insufficient evidence to establish their identity. To me this this is because we are trying to present truth here, and having a link to a parental family implies the (collaborative) site's assertion of adequate support for the relationship. This is true whether there is a known alternative hypothetical set of parents or not. So one should not keep a link to an unsupported parental family whether or not one can add an additional link to another unsupported parental family as well. Of course we should show on the person's page the conjectures for parentage and what limited supporting evidence there may be for or against them; they should just not be shown as formal parents.

From the discussion to this point it seems to me that this is the consensus: that neither of the contending sets of parents should be linked as parents. As brought up, there are some advantages to the alternative, but overall it sounds like people think it best to leave then unlinked.

The suggestions for flagging the problem with a template seems good to me. Maybe someday a software enhancement can use the flag to limit linking by GEDCOM upload, merging, or whatever. Even before that, though, I think a visible notification on the person page can be helpful in alerting people to the situation. This should reduce the attempts to add parents without adding supporting evidence but will not eliminate them, so we can expect to have to remove unsupported parents from time to time in spite of using such a template.

Towards this end, I have set up a draft template at Template:Parents Unknown. Please feel free to improve it, or discuss changes on the talk page there (or, of course, discuss the advisability of having it at all right here). --Robert.shaw 17:56, 21 December 2012 (EST)

Thanks for pushing the question. I agree that we should only link a parent, spouse, family, etc., when there's a very strong case to do so. Perhaps not perfect, but strong. If there are contenders, then we should indicate as much in a disputed lineages section on the person page and respective family pages (even though the text is duplicated - you can write it generically and often copy paste.

I want to be a little more careful on how we do the information/added fact templates. We want to allow for the description of a number of situations, and do so in a way that is easy to find and recognize (by humans AND software) later on. Let's get a full list of the things we know we want to assert. Then we can decide whether each one is a template on its own - or whether we can do this as a smaller number of templates with parameters. Even if there are multiple templates - we'll want to do them all in a similar manner. We should probably move that discussion somewhere else...I'm writing a suggestion called "assertions". --jrm03063 22:54, 21 December 2012 (EST)

You are speaking of missing info or known factual info; what about known errors? In my Jackson line there is a known error attributing the wrong parent to the wife of a Revolutionary soldier. The error was accepted by the DAR for years and so researchers accepted it. The DAR was notified and now does not accept applications based on that error. But numerous genealogy trees using that info are still floating around. I can describe the problem on her talk page but that wouldn't stop erroneous GEDCOM uploads. How could a template be worded to refuse to upload erroneous parental information? And how many folks would have to agree that it is erroneous before using such a template? --janiejac 15:12, 22 December 2012 (EST)

Very true. I'm not sure about handling it automatically, but that doesn't mean we shouldn't try to come up with a standard way to declare/structure this sort of thing. I'll take this over to the suggestions page on assertions... --jrm03063 19:18, 22 December 2012 (EST)

I don't know if this is the same conversation or a different one, but I think a key thing we can do in developing standards for a true pando is to tag relationships where there are a significant number of people elsewhere who have asserted it to be true but we have good reason to believe either it is false or suspect. Stage 2 is then to integrate this into GEDCOM uploads so that they aren't added in by future activity. AndrewRT 19:31, 22 December 2012 (EST)

I think it's the same conversation. For starters, the assertions couldn't do more than give us a standard way to note some key things. We would keep in mind that we want to make automatic use of such data, and try to make sure that people AND programs could understand it, but it would probably be some time before we had programs making use of it. I don't think there's a sane way to objectively represent more than one structure at a time in WeRelate. When there are differing interpretations, I don't see that we can do much better than choosing the best of the bunch (presuming one is considered to be the most likely), or choosing nothing. My practice would be to discuss both the prevailing and minority opinions in "Disputed Lineages" - and to carry that "Disputed Lineages" content to the different pages implied by the various interpretations. --jrm03063 00:20, 23 December 2012 (EST)

From a more theoretical point of view - I suppose you could create a genealogy environment where any given person or family page could have 1 or more interpretations. Connections to other person or family pages would have to name both the page and the interpretation at each connection. It might be able to be done - but I wonder how usable it would be. --jrm03063 00:27, 23 December 2012 (EST)

Thinking about this a little more - the above approach might work in the most common cases - but it would probably be impractical for someone like Henry I, where there are different interpretations for a number of potential children. Assuming four children who may (or not) be his - a full page level interpretation would mean 16 interpretations. Five children - 32, etc. Would have to think about whether there's a different way to structure different interpretations, such that you wouldn't get a combinatorial explosion. --jrm03063 00:40, 23 December 2012 (EST)

After a while I figured out you had put up a formal "Suggestion" (page here). This surprised me a bit since it seems like it needs some discussion before a suggestion for software implementation could be formalized. Also, I assume we want a design that editors can start using without waiting the probable very long time before the WeRelate implementors can do anything about it. Do you think the mechanism's needs and variations should be discussed and decided upon there, or here (new topic?), or on some other working/discussion page?

I'm so sorry if my "suggestion" implied that this was in any way ready for decisions to be made. Very far from it I should think! I thought that this might be getting a bit large for to be hosted on the watercooler - and that I wanted to expand it and formalize it enough to show a direction I thought this might go. I'll mark it to indicate that it's still the subject of very active revision and discussion. When the three or four of us who have shown interest start to approach consensus, then perhaps we offer it for consideration as a standard practice/convention. --jrm03063 21:13, 23 December 2012 (EST)

Anyway, plunging ahead: The idea of using an "other" event in "Facts and Events" seems a bit stretched, but investigating it I found that it at least would seem viable. If one adds an "other" event and places the template invocation in the "description" field, then the page displays it reasonably well. For an example of what it would look like for an assertion where we are trying loudly to make uploaders/mergers/browsers aware of the assertion, see this sample page. (Obviously we wouldn't use it in a simple end-of-line situation like the sample; it's just to show how an "other event" would display. The normal event-related date and place fields would not seem to have any use.

For GEDCOM exports, the "other event" generates a line like "1 EVEN {{Parents Unknown|parameters}}" which at least makes moderate sense if we name the templates well. What various programs would do when importing such a GEDCOM event is hard to say, but at worst it probably just gets thrown away.

That's good. I suppose it's also possible that the GEDCOM export could be made smart enough to recognize and expand/transform the templates on export. --jrm03063 21:13, 23 December 2012 (EST)

The use of an event does position it well on the WeRelate page it seems to me, as for at least some of these assertions we want the display high up and visible. I guess the only real alternative to using an event field is to place the template invocation in the general "content" text box, where it might tend to get lost. --Robert.shaw 17:41, 23 December 2012 (EST)

Thanks for your careful consideration/review. Please, feel free to modify/revise/expand the "suggestion" as you see fit. --jrm03063 21:13, 23 December 2012 (EST)

Well, it looks great on the displayed page, but on a merge screen(and probably on a GEDCOM upload - been so long since I've done one I can't say for sure), all you see is the text typed in, i.e., the name of the template. Further, even at face value, my response as a user would be: "You think the parents are unknown? Not me! I know who they are! After all, I found an Ancestry Family Tree that says so!" So it should something like "Please read all notes on this page before changing.", and it probably needs to be supported by the software before it is going to matter.

In your example, the template's invocation {{Parents Unknown|not|Arthur Miller}}, has arguments. But the template itself doesn't seem to take arguments? --Jrich 22:40, 23 December 2012 (EST)

Yeah, the parameters "not|Arthur Miller" are bogus and the template as it was drafted doesn't use any; I just put them there to cover that case for viewing & export and didn't bother with display. You're right that this (or any, I guess) template won't show up well for imports or merges wihtout software support. Just seems to be a fact of life.

The "parents are unknown? I know who they are!" issue is quite real. Because of that, I'm now leaning towards explicit naming of the unproven candidate(s) via parameter. The wording would have to be different. It may be much like "Debunked Parents" in structure, but needs wording more about unsupported, not proven wrong. --Robert.shaw 23:15, 23 December 2012 (EST)

I'll offer a couple things. I don't think the templates need to expand into a box - a standard text item ought to be enough. It might also be helpful if the template expansion included a link to a page describing in greater detail what the assertion templates are meant to do and what any given template implies. Finally, as with other facts - we would like to positively support them with sources and/or a note. To be sure, until there's software support, people can do what they will, but GEDCOM import time is just one moment in the life of the data. I still anticipate consistency checking software that wanders around the database looking for combinations of facts that are mutually exclusive (parents born after children, etc.). This sort of item just becomes another fact combination detected by that process - "parent unknown" with a connected parent page would be flagged as an inconsistency. --jrm03063 10:31, 24 December 2012 (EST)

GEDCOM import is just one moment in the life, but there are others, and all the moments where a page is being changed, be it merging, editing, etc., all you see is the template name, not the template message. Adding a template is really just a negative measure, in my opinion, to stop people re-adding stuff that has been removed. However, I still feel the need is to deal with possibilities, and not just is or isn't, all or nothing. A more positive approach may be to give each fact (including parents) a status of accepted, possible and rejected, for example. Then we don't have to throw away possible data just because it's not provable. It's the same idea that suggests there can be birth dates and alternate birth dates (e.g., Person:Elizabeth Cogswell (8), Person:Rhoda Aldrich (1)), even though we know a person can only be born once. Having multiple variations is a reflection of the state of our knowledge, not of what really happened. --Jrich 11:47, 24 December 2012 (EST)

I had an exchange above w/AndrewRT on a theoretical approach to handling multiple genealogical interpretations. I don't think it can be done in a way that is easy enough for humans to understand, general enough to handle all the situations, and structured enough to make it useful for software analyzing the database. I do think there are a handful of a useful special cases that we could support though. Certainly rejected corresponds to debunked and accepted corresponds to the actual connection structure. We could have another set of templates corresponding to the "Debunked" list, that indicate potential or candidate relationship connections. I'll scratch something in for folks to look at. --jrm03063 12:40, 24 December 2012 (EST)

I have copied the recent comments above which concern templates to a section of WeRelate talk:Suggestions/Assertions. I suggest we continue the template discussion on that page (since it is not directly about handling two contending sets of parents, the original topic here). --Robert.shaw 16:05, 26 December 2012 (EST)

reliable source? [30 December 2012]

I just found an online source for Source:Virkus, Frederick Adams. Abridged Compendium of American Genealogy : First Families of America: A Genealogical Encyclopedia of the United States. I added the URL to the book and created the repository. But I am not familiar with this work. Is it considered reliable data? --janiejac 11:15, 30 December 2012 (EST)

quick scan of its pages reveals no citations or footnotes. quickly scanned its intro as well and saw no reference to sources, but i could have missed. it. Jillaine 12:04, 30 December 2012 (EST)

It's encyclopedic, which is a big strike against it. Not to generalize too much, but these type of works usually have too much breadth to do a good job and usually end up pulling in information from various published sources without any real attempt to verify it, not to mention the limitations of a cramped format. I concur with Jilliane. Would want to verify anything it says with better sources.

There are actually 7 volumes and some indicated as limited seem pretty much full view.

• Full view v.1 (original from University of Michigan)
• Full view v.2 (original from University of Michigan)
• Limited (search only) v.3 (original from University of Michigan)
• Limited (search only) v.4 (original from University of Michigan)
• Limited (search only) v.5 (original from University of Michigan)
• Full view v.6 (original from University of Michigan)
• Limited (search only) v.7 (original from University of Michigan) --Jrich 13:05, 30 December 2012 (EST)

Virkus is not considered a reliable source. He, among others, was discussed in the following excerpted from The American Genealogist, 73:316, October 1998:

"EDITORIAL NOTES AND OBSERVATIONS

COURTESY AMONG GENEALOGISTS; There is a general maxim among scholars that they should treat with courtesy those with whom they disagree. Too often it seems that this maxim is forgotten in the give-and-take of argumentation, but it is one that we try to hold to in TAG. There is a very human tendency to decide that those whose ideas we disagree with must be ignorant or evil or just plain wrongheaded. TAG, of course, is known for its critical articles and reviews, including some in this issue, and for its refusal to accept unproven traditions and legends But that does not mean that there is something wrong with the people who hold the views that we are criticizing. It is ideas and conclusions that must be held up to critical evaluation, not those who support them.

This statement, however, must be qualified. It does not apply to the dead, and we frequently reach conclusions about the quality of work of deceased genealogists. We would be irresponsible if we did not warn readers about such writers as Orra Eugene Monette, John S. Wurts, or Frederick Adams Virkus. Nor does it apply to those who have committed conscious fraud, like Gustave Anjou, Horatio Gates Somerby, and Harriet Bainbridge De Salis. …"

I would add that any of the massive compilations, such those edited by Cutter, should be treated with caution since they were often cut and paste efforts contributed by any number of correspondents other than the editor. These, and works by those mentioned in TAG, may provide useful clues but prudence dictates that they be checked against other sources.--jaques1724 13:57, 30 December 2012 (EST)

I've added a warning quote from Jacobus to the source page. Note the confusing fact that only the first volume of the seven volume set used "Abridged" in the title, and there were several subtitles. WeRelate has four source pages for variants. --Robert.shaw 17:11, 30 December 2012 (EST)

Wow! Thanks to everyone who took the time and effort to answer my question!! I knew you folks would know the answer to my question! --janiejac 18:54, 30 December 2012 (EST)

Attention Wing Nuts! [5 January 2013]

Ok, I wanted to use that topic... :) ! A recent GEDCOM has added a lot of Wing family members with citations mentioning only the Wing Family Directory. I also noticed that there were a couple different Source entries, seemingly, for the same directory. I've consolidated those in Source:Wing Family of America, Inc. Wing Family of America, Inc. Directory. I have also found that the directory content is actually maintained on RootsWeb, so I have created a template to support useful/linkable citations to the Wing database.

I would appreciate it if some folks more familiar with RootsWeb and/or the Wing family would review what I've done. --jrm03063 15:19, 2 January 2013 (EST)

The RootsWeb database for the wing family has proved to be extremely weak, and a note discouraging its use has been accordingly added to Source:Wing Family of America, Inc. Wing Family of America, Inc. Directory. --jrm03063 09:42, 5 January 2013 (EST)

Soldiers from the medieval period [4 January 2013]

This is an interesting site that I found recently.

You can search the 2 Databases, 'Muster' and 'Protection' under various criteria (I have used just the surname option so far) but you will need to be very flexible with the spelling ; these are records from the 1300's and 1400's ! It will accept wildcards, eg. Gr* or We*.

Even if your search is fruitless from a personal family history point of view (although if you do find a possible ancestor the problem is then making the link from the 18th or 19th century !) the information displayed is interesting from a purely historical point of view.

http://www.medievalsoldier.org/search.phpColin Madge 08:19, 4 January 2013 (EST)

Lost someone ? [4 January 2013]

Maybe a blacksheep of the family ?

This may be of interest to anyone, who whilst researching their family tree, have discovered female convicts who were transported to Australia.

The site is from the Female Convicts Research Centre http://www.femaleconvicts.org.au/

They are currently trying to connect the female convicts who were transported to Van Diemen's Land with their birth and marriage families in the UK and their descendants in Australia. They are searching for gaol and trial records and newspaper stories about our women.

All good stuff - Membership of the website is free and once a person joins they have free access to the database. All the work is done by volunteers.--Colin Madge 08:25, 4 January 2013 (EST)

US Immigration site 1830 - 1892 [4 January 2013]

The following website might be useful to those searching for ancestors who emmigrated to the United States. It pre dates the period covered by the Ellis Island website.

http://www.castlegarden.org/Colin Madge 08:37, 4 January 2013 (EST)

Proposed discussion on WeRelate's Person Page age limit [11 January 2013]

There's something I've been thinking about, which I'd like to bring up for discussion. Ever since I began doing research in the newly-released 1940 U.S. census, it strikes me that forbidding pages to be created on WeRelate for possibly still-living persons less than 110 years old is kind of pointless. I understand the issue of personal privacy and the potential for identity theft and all that, and I agree with it -- mostly. But, of course, I'm coming across quite a few children who are 1 or 2 years old in 1940, which means they would be in their mid-70s now, and many will still be alive. (I daresay there are a few regulars on WeRelate who have found themselves in 1940.) And then there are the now-public World War II draft registrations, which include quite a few persons who are still living. The 110-year limit is meant to eliminate all living persons (except for the handful of longevity record-holders worldwide) -- but is this unnecessary overkill? I know several states have gone full retard and have shut down their entire online vital records databases, including back into the early 19th century, which is a stupid bureaucratic over-reaction. And I don't know what the comparable age rule is in the UK for release of their censuses and other data. But if the 72-year limit is good enough for the U.S. Government in balancing privacy with access to public information, shouldn't it be good enough for us? --Mike^Talk 10:30, 4 January 2013 (EST)

There are actually a lot of publicly available records (e.g., Minnesota, Birth Index, 1935-2002 and other familysearch collections) that go quite a bit past 1940, not to mention obituaries that mention various people. So availability of information by itself is a slippery slope (i.e., in the words of Dr. John, if you don't do it, somebody else will). With average life expectancy in the eighties, a limit of 72 doesn't quite seem long enough even if the government does use it. So there seems to be a need for a guiding principle and whatever it is, it will undoubtedly be inconvenient for some situations. --Jrich 10:59, 4 January 2013 (EST)

At the moment, the guiding principle seems to be one of inconsistency, which is what I'm questioning. --Mike^Talk 08:35, 5 January 2013 (EST)

UK census release dates are 100 years after the event. And they are usually late.
Canada has a 92-year rule on censuses and 1921 is expected out late this summer. --goldenoldie 12:01, 4 January 2013 (EST)

I've been frustrated by that too, but if you're sure someone has passed, can't you fill in a "bef. 2012" DOD? Or is this something that you want to control at GEDCOM upload time? --jrm03063 12:40, 4 January 2013 (EST)

Well, yes, and I do that all the time. (Actually, I just put a "Y" in the Death field, which accomplishes the same thing.) But I also transcribe the 1940 census listings and include them on the page for the Head of Family, even when I don't create pages for the young children listed, so the protection supplied is specious. And I'm not willing to exclude the 1940 census, or to censor it by omitting people within the listing, so what does the limitation accomplish in this case? --Mike^Talk 08:35, 5 January 2013 (EST)

I don't think the fact that some organizations have been less strict than others means we have to follow the most permissive. I agree that 72 years is too short, as a large percentage of people born in, at least, the decade before that are still alive. Regarding your last question, having a census transcription in the text, which often has misspelled names and estimated ages, is more opaque to both Google and humans as to who exactly the entry relates to than creating a page would be.--Amelia 10:51, 11 January 2013 (EST)

Handling true aliases and time-resolved name changes [4 January 2013]

I am working on inputting information related to Person:Francis Yockey (1), who was known to use several aliases during his life. It would be very useful to be able to suppress the auto-categorization to 'surname in place' categories for aliases. If you look at the record, you'll see that the aliases are treated exactly like the actual surname. Maybe the solution is to add an additional name-type of "alias" which does not trigger auto-categorization, but does not block manual categorization.

There is the very different matter in re name-in-place which could be time resolved. For instance, a person might be known by a particular name for a particular period of time and that would be valid in a particular place; then later, they would be known by a different name in a different place for a particular period of time. This is a much more complicated issue, which is mostly related to maiden vs. married names and legal name changes (such as transgender- or self-protection related changes).

Much to think about. --ceyockey 20:47, 4 January 2013 (EST)

Supercentenarians [8 January 2013]

I have created a category for supercentenarians. Wikipedia: A supercentenarian (sometimes hyphenated as super-centenarian) is someone who has reached the age of 110 years. Do you have anyone you are working on that would fit in that category? You can add them to the category by adding this to their page: [[Category:Supercentenarians|Last Name, First Name]] --cthrnvl 21:44, 7 January 2013 (EST)

Printable-WeRelate [16 January 2013]

I've added a project page for this little project. It produces printable output from werelate data: a big family tree with just BMD information, and an A4 book with everything (well, basic info, facts, relationships, biographies, and citations; there's more to come, like images, trascriptions, etc.).

The book output is currently looking like this. (There're problems with it, certainly.) I'm currently working on the source citations: getting them formatted, and linked from the correct places. At the moment, it's just putting them in as footnotes to the fact list (and not even formatting them very well). Next will be the inclusion of images.

I'm only mentioning this here as a heads-up, really, and to see if anyone would be interested in being a beta-tester. I can set up a demo from your data. Leave a comment on the talk page if you are.

— Sam Wilson ( Talk • Contribs ) … 19:52, 13 January 2013 (EST)

There doesn't appear to be attribution, as required by http://www.werelate.org//wiki/WeRelate:Terms_of_Use#Information_for_re-users. --Robert.shaw 00:49, 14 January 2013 (EST)

eek, yes, good point! I certainly always meant to add it; I'll do so.  :-) Thanks! — Sam Wilson ( Talk • Contribs ) … 00:51, 14 January 2013 (EST)

I've added a short copyright notice to the tree and book (e.g.). I will be including all contributors' usernames, once I've sorted out the bibtex stuff (which will be used for all citations; rather than the footnotes I've currently got it producing... I think... I'm open to suggestions...). — Sam Wilson ( Talk • Contribs ) … 05:03, 16 January 2013 (EST)

Website/s [18 January 2013]

I'm taking the liberty of moving the content of this discussion to the Source Portal talk page - where the source committee can reflect upon it at their leisure. --jrm03063 10:30, 18 January 2013 (EST)

Templates for marking questionable relationships [23 January 2013]

In an earlier Watercooler discussion ("Handling of parentage contenders?"), there were suggestions that it would be helpful if we had a good way of showing speculative relationships.

The main problem is that sometimes there is a candidate for a relationship (e.g. father) which is not presently adequately supported, yet some people browsing or editing may not realize it. We don't want to link the candidate normally (e.g. as the father) since that implies we know the relationship to be correct. So it was suggested that it would be good to have a standard way of presenting such a speculative relationship, perhaps using templates.

The discussion continued on WeRelate talk:Suggestions/Assertions and has now developed into a prototype system of templates to support this and related needs. These templates support:

• Refuted relationships
• Speculative relationships
• No-accepted-relationship assertions
• Confusion avoidance alerts

(I don't see this as replacing "Disputed Lineages" sections, as those are needed to present detail that these templates cannot.)

This is still a trial mechanism and we would like feedback from the community in order to assure it proceeds in the best direction possible.

You can learn about the template system at Help:Assertions.

Please try it out, and add comments and questions to Help talk:Assertions.

--Robert.shaw 15:41, 23 January 2013 (EST)

Hi Robert, one template some of us have used in the past to identify Person or Family Pages with "problems", such as children born before their parent's marriage date (or the parents for that matter), or other mostly obvious situations is this one:

I'm assuming that the difference between the "Refuted relationships" and "Speculative Relationship" depends whether you agree or disagree with the evidence (of lack thereof) provided, but some researchers have used "disambiguation" to distinguish between contemporaries with the same name or same area during the same time period.

I do like the idea of coming up with some type of "un-proven" relationship indicator, but it may cause some minor disagreements over lineage to become editing wars when the template is placed on a Person or Family Page. We should come up with a specific policy over WHEN and IF they should be used...

Just my $.02.

Best regards,

Jim

I hope the help descriptions of the different templates offer sufficient guidance on when they should be used. I'm also hopeful that some former disputes can be smoothed over, because it's now possible to compromise at "speculative" - taking concrete notice of a possible relationship - without either accepting it or dismissing it completely.

"Refuted" is a little different - as it is meant to provide a way to take concrete notice of things that formerly were accepted or - at least - published - but which the community now agrees are not true. It's meant to help us guard against the re-introduction of errors when innocent contributors work from older reference materials. Of course, if someone isn't really satisfied with a "refutation", then compromising at "speculative" remains a choice.

The notion of "disambiguation" is, I think, carried in the template for "NotToBeConfusedWith". Unless there's disagreement on whether a single name represents one or two people I supposed. --jrm03063 19:15, 23 January 2013 (EST)

Family History (What's Next) [7 February 2013]

I was wondering how future generations will cope with family history.

With more and more people choosing to live with someone , rather than marry.

Children with parents in "families" who have different fathers.

Gay marriage and Civil partnerships.

Hope we are ready and not to confused.

Colin--Colin Madge 08:54, 28 January 2013 (EST)

I have a tentative plan. I mean no disrespect to anyone's choice of partners, but I reserve the "family" object for either

• a conventional heterosexual marriage
• a heterosexual relationship that results in one or more children (even w/o formalities)
• indicate relationships established by adoption, as a 'fact' that is present in both the adopted child's page and the adopted parents family page (assuming the adopted parents are married heterosexuals)
• children of a same-gender relationship will either be adopted by one or both of the parents, and at most, the natural child of only one of the parents. In that case, the child's fact list would include adoption items for both parents, and the parents fact lists would contain items indicating the adoption and the formal relationship with their partner.

Or something like all that...

Alternatively, under the covers, WeRelate is capable of allowing multiple people of the same gender as spouses, but the interface as most people see it generally hides that. It's possible that the interface could be modified to allow a family to be specified as other than a heterosexual relationship - but that would mean software changes. The steps I note above could be accomplished with assertion templates - and no software changes. --jrm03063 11:24, 28 January 2013 (EST)

"It's possible that the interface could be modified to allow a family to be specified as other than a heterosexual relationship" - but then the person in question wouldnt be that person's parents. Whatever you think of homosexuality (and personally I really, really dislike this injection of politics on WR), paternal relationships are a biological fact that can not be argued with or changed. You either are or you are not a couple's child. I dont know what the current policy is with adoptees, but it seems that it is wrong to put adoptive parents as the actual parents of a child, because they are in fact not. Daniel Maxwell

For some years, there seems to have been a strong (and growing) division among family researchers over the definition of "family." Some insist on the "sociological" definition: Anyone raised by a couple is a "child" of that couple, whether adopted or not. The other side (which I subscribe to, personally) takes a genetic approach: A person is a "child" of the couple whose DNA that person carries. The first group tends to be really affronted when the second group tries to explain that adoptees aren't the same as biological offspring, genealogically speaking, and that this is not an attack on adoptees or gay couples or anyone else. It has nothing whatever to do with politics or social agendas. I have plenty of political opinions -- but as a genealogist, I'm interested in documenting someone's physical, generation-by-generation descent from those who lived earlier. And, God knows, my family has its share of "non-birth events" to struggle with, just like everyone else's. --Mike^Talk 09:57, 29 January 2013 (EST)

I agree with you completely. It all boils down to biology. There is no intent to offend anyone. But its just a biological fact that every living human being has a father and a mother, and it cant be any one or anything else. Those adopted kids and illegitimate children do have biological parents, and finding out who they are is the entire purpose of genealogy. To the point though, I would oppose any of the sociological definitions being added to WR. Daniel Maxwell

When I suggested that a family relationship need not be of simple heterosexual form, I didn't take a position on whether such a family is allowed to link children in the ordinary way. My thinking is no - but that's all sort of beside the point. WeRelate is someone limited by the desire to be able to import and export GEDCOMs, and things that you can't sensibly represent in a GEDCOM are problematic. I think a more practical alternative is sketched out here. --jrm03063 10:23, 29 January 2013 (EST)

For me, the original poster is getting at the distinction between genealogy and family history. And do note that they used "family history" in the title, not genealogy, which as others have pointed out is the study of genetic relationships. But I'm sensing that there is an increasing interest in the intersection of these two approaches. And perhaps even a significant target audience as or more interested in history than genes. I know I have a foot in each camp. What the original message says to me is that the software-- whether wiki or elsewhere-- is not really "ready" for such a demand. And it could be that as more and more people want pto document their family history, they will seek tools and communities that will help them do so.

Jillaine 11:21, 29 January 2013 (EST)

I'm thinking that it would be wise if we had a working plan of record for handling this stuff - and it would be neither hard nor require software changes to do something. It would amount to agreement on a set of conventions for fact templates, of the same sort proposed for defining when the evidence for a relationship is questionable - but we still want to be able to objectively indicate the possibility. Is there any interest in such a proposal? --jrm03063 12:07, 29 January 2013 (EST)

I'm with Jillaine on this. And I would guess that family history is what is driving a lot of the interest in genealogy these days. This is one of the reasons WeRelate is my preferred site -- the Text field on each Person and each Family page allows the potential for narrative that can serve as family history and/or as the narrative that is one of the essential requirements of genealogical "proof". If, as Ancestry advertises, "every person has a story to tell", then WeRelate is a place where you can actually tell that story.

As for adoption, it is one of the events listed as an option on the Person page. The adoption wouldn't have to be legal to be added, if you ignore date and place and just fill in the name(s) of adoptive parent(s) or family in the description field (with links, if wanted). Still, I wonder if it would be possible to add an extra field to the Person page: "Adoptive Parent" (with the option of adding more than one); as well as an extra field to the Family Page: "Adoptive Child". For people just learning to use WeRelate, that would probably be the easiest way to deal with adoption and satisfy contributors' need to display both genetic and social relationships. (Templates are important and useful, but they are also a pain to learn/remember and learn to use. Sorry.) That would also reduce at least some of the Duplicate Pages that appear on the Duplicates list.

An input page that helps the user create such data would be better, but templates can let us accomplish what we need in the meantime. Moreover, the internal representation still has to make sense within the restrictions of GEDCOM input/output, so this sort of information would wind up being cast as "other" events anyway. --jrm03063 15:40, 29 January 2013 (EST)

The more interesting -- and probably more difficult -- issue is the one that Mike rather hints at. Documented "non-paternal" or "non-birth" events can be dealt with in narrative, at least. But what about the growing number of well-documented "standard" genealogical relationships that DNA is starting to disprove? This is a genealogical as well as a family history question.--GayelKnott 14:08, 29 January 2013 (EST)

When DNA disproves a long-held lineage - we have to treat it like any other piece of information that refutes previously held facts. --jrm03063 15:40, 29 January 2013 (EST)

I've been peripherally involved in two extended family/surname DNA projects, and in both of them the descent of more than one of the principal lines from the presumed progenitor seems not to be proving out. This has upset a number of people, mostly those who have tended to brag on their descent. (I think there's some karma at work there. . . .) The whole DNA thing is beginning to have a major effect, I think, on the assumptions of family researchers regarding the frequency of non-birth events in even recent history. Probably a good thing. --Mike^Talk 07:29, 3 February 2013 (EST)

Totally agree. My question was: and how are we going to handle this in terms of computer programs that are based on lineage connections? Because the "blood" linkage is what is supposed to be charted, but many of these people probably assumed that the "blood" and social linkages were the same (i.e., they didn't know that their genetic and legal fathers were not identical) and lived their lives accordingly. So do we just throw out everything they knew and thought about their own lives because it doesn't fit the computer program? This, I guess, is where you really have to decide whether you are researching people (who lived lives) or names and dates (and had vital statistics). --GayelKnott 13:37, 7 February 2013 (EST)

If I understand it correctly, DNA (unless you get it for your immediate family) isn't showing anything about immediate ancestry - or any given lineage in particular. I think it makes both soft statements like lineage A->B1->C1->D1->...X1 is consistent/intact with respect to a lineage A->B2->C2->D2->...X2. In special cases (maternal mitochondrial DNA?) I think it can make hard claims (like what we've seen respecting Richard III). But even there, it's only saying that the historically recorded female line from Richard's time to the modern day descendant appears to be intact. It could be that the modern day sample source isn't a descendant of Richard - but they are a descendant of whoever's bones those are - but we accept this as proof because it seems unlikely that two implausible events would line up to still create a consistent result. So other than adding a fact in a descendant indicating that some accepted ancestral lineage has an unknown break - I'm not sure what else we could do.

Only if you know a specific link - that some child is not the genetic child of an accepted parent - would there be anything to do. Then - I suppose - you could drop that child from the family, and indicate them as de-facto adopted. --jrm03063 13:58, 7 February 2013 (EST)

New template to help avoid edit conflicts [17 February 2013]

If you are working on a page for a period of time and would like to avoid an edit conflict, you can add this template to the page to warn other users. There is a parameter to indicate how long you plan to work on the page and add an optional message about the changes you are making. Other users are advised not to edit the page while this template is in place. This is meant for short-term projects and should be removed promptly so that other users may contribute. This template is new, so if you have any questions or comments, just let me know! --Jennifer (JBS66) 11:22, 10 February 2013 (EST)

Many thanks.--GayelKnott 19:08, 13 February 2013 (EST)

This seems like a solution in search of a problem. The first time I experienced an editing conflict I realized why it happened. I learned if I had had an edit open for a significant time I would copy my edit into a wordpad file before saving the edit, then if there was a conflict, I lost nothing.--Scot 22:45, 16 February 2013 (EST)

Browsing templates [14 February 2013]

Is there a way to browse templates? I am sure others have deposited some good stuff, but how can one find it? --goldenoldie 02:56, 14 February 2013 (EST)

You can use the Browse Pages item in the Admin menu. It lets you page through a list of the templates (only shows 10 items at a time). -Moverton 13:24, 14 February 2013 (EST)

You might want to try browsing starting at Category:Templates. It looks like a categorization system was set up just over a year ago, and so you can get an idea of what sorts of templates are available. Of course if a template has not had appropriate Category lines added to it, you wouldn't find it this way. Be aware that some of the templates you find may be abandoned and never or rarely used; at least that's what I recall noticing when I skimmed some templates a couple of months ago. --Robert.shaw 14:41, 14 February 2013 (EST)

There is also this page to scan: http://www.werelate.org/w/index.php?title=Special%3AAllpages&from=&namespace=10 --janiejac 15:40, 14 February 2013 (EST)

Category surname - geographic location [28 February 2013]

Dear friends I have some issues / questions regarding categories and the overall strategy. I start with a component. If this is not the right place, then move my writings.

I spent a lot of energy to create categories, because I think it is important. On 15 February 2013 Klaas made me be aware that in the near future to automatically add a category surname - geographic location will be abolished. I was horrified. I find this auto category of great importance. Klaas motivated that there are now too many geographic locations are automatically added. I disagree.
A common surname contains the category name, a great mountain rice pudding to people with this surname in the earth. (I look at the most by F) It's nice that the people with this surname, through an automatic category a global distribution on this earth get. The states of USA and the countries of the world. 80% of people continue to be listed in one geographic location. (Country or state) In relation to the few people in more than two of these sites occur. (There is more mass when people used more than two surnames have. Again this is only a small percentage)

Advantages of category surname - geographic location.
-When I have a whole family in the Netherlands after 1850 can not be found, the search for a needle in a haystack. When I use the name of the man (or woman) find in eg Belgium / Denmark / Zuid-Afrika/India is an indication in that country further.
-With the advent in the U.S. often change the name. Johannes Mol was Jack Mole. Johannes Mol falls in the Netherlands not there are more than 1000. But the name Johannes Mol in Utah falls though, especially when he's actually just as Jack Mole known.
-Klaas Terpstra emigrated to Chicago, but it seems that 20 years later he married in the Netherlands. With the automatic categories Terpstra family in the U.S. to trace.

One can manually the category name - geographical location capture. The information would get more of the essential data is reduced. But who is going to do that? In a gedcom of 1000 people go to another view 1000 times. That will not happen. The categories thus giving only partial information and are thus less useful. For me there is no more motivation to create them. The chain is only as strong as its weakest link. Better as it goes nothing.

I find this useful Category:Hall surname

Greeting,--Lidewij 08:26, 21 February 2013 (EST)

Beste mensen ik heb een aantal kwesties/vragen ten aanzien van categorieën en de algemene strategie. Ik begin met één onderdeel. Wanneer dit niet de juiste plaats is, verplaats dan mij geschrift.
Ik bestede veel energie aan het maken van categorieën, omdat ik het belangrijk vind. Op 15 Februari 2013 maakte Klaas mij er op attent, dat in de nabije toekomst het automatisch toevoegen van een categorie familienaam – geografische plaats zal worden afgeschaft. Ik schrok vreselijk. Ik vind deze automatische categorie van groot belang. Klaas motiveerde dat er nu te veel geografische locaties automatisch worden toegevoegd. Ik ben het hier niet mee eens.
Een veel voorkomende achternaam bevat in de categorie achternaam, een grote rijstebrijberg aan personen met deze achternaam op de aarde. (bij F kijk ik het meest) Het is prettig dat deze de personen, met deze achternaam, via een automatische categorie een globale verdeling op deze aarde krijgen. De staten van USA en de landen van de wereld. 80% van de personen blijven genoteerd in één geografische locatie. (Land of staat) In verhouding zijn het maar weinig personen die in meer dan twee van die locaties voorkomen.(Er is meer massa wanneer personen meerdere dan twee gebruikte achternamen hebben. Ook dit is maar een klein percentage)

Voordelen van categorie familienaam – geografische plaats.
-Wanneer ik een heel gezin na 1850 in Nederland niet meer kan vinden, is het zoeken naar een speld in een hooiberg. Wanneer ik de achternaam van de man (of vrouw) vind in bv. België / Denemarken /Zuid-Afrika/India is dat een indicatie om in dat land verder te zoeken.
-Bij de binnen komst in de VS verandert men vaak de naam. Johannes Mol werd Jack Mole. Johannes Mol valt in Nederland niet op er zijn er meer dan 1000. Maar de naam Johannes Mol in Utah valt wel op, zeker wanneer hij daar eigenlijk alleen maar als Jack Mole bekend is.
-Klaas Terpstra emigreert naar Chicago, maar het lijkt er op dat hij 20 jaar later in Nederland trouwt. Met de automatische categorieën is familie Terpstra in de VS te traceren.

Men kan zelf handmatig de categorie familienaam – geografische plaats vastleggen. De informatie zou zo meer tot de wezenlijke gegevens gereduceerd. Maar wie gaat dat doen? Bij een gedcom van 1000 personen ga je dat nog eens 1000 maal bekijken. Dat zal dus niet gebeuren. De categorieën geven dus maar gedeeltelijke informatie en zijn op die manier minder zinvol. Voor mij is er dan geen motivatie meer om ze te maken. De ketting is zo sterk als de zwakste schakel. Beter zoals het nu gaat dan helemaal niets.

Ik vind dit zinvol Category:Hall surname

Met vriendelijke groet, Lidewij 08:26, 21 February 2013 (EST)

I had not yet had an opportunity to write the proposal that the Overview Committee spoke about recently. Let me explain the rationale now.

There are automatically created categories that exist at the bottom of most pages. These categories do not appear when you edit a page, only when viewing a page, thus, they cannot be edited. There are some limitations in their scope, their level of user-friendliness, and man power to organize.

Examples

Person & Family pages: Person:John Smith (90) automatic categories are Category:Smith surname and Category:Smith in Massachusetts. These are generated from the Surname and every place listed in the event fields.

Source pages: Source:Zubrinsky, Eugene. Carpenter Sketches automatic categories are listed at the bottom of the page and are generated from the Surname and Place fields.

Place pages: Place:Hatfield, Hampshire, Massachusetts, United States automatic category is one level up from the current page title.

Many times, you will see at the bottom of pages these categories are red-linked. Their hierarchy must be manually created - just adding text to these pages does not "create" them.

Some concerns

• Must be manually created and organized by a person knowledgeable with the hierarchy structure
• Categories are generated only to the Country level, except in the United States where they are generated to the State level
• Confusion between Surname in Place categories such as Category:Schregardus in Netherlands and Surname in Place Articles such as Schregardus in Friesland, Netherlands
• Automatic categories cannot be edited

The thought is the current (or an improved) search feature can better help users find and navigate pages and would not require such a large investment of time from users and administrators to manage. This would allow more specific user-created categories (such as Category:U.S. Presidents) to receive better attention. So, I'd like to ask for input. Do you find the automatically created categories to be useful? Do you use categories such as Category:Surnames, Category:Surnames by country, and Category:Hautes-Pyrénées, France to find a person/family/source/place you are looking for? Feedback and questions are welcomed! --Jennifer (JBS66) 09:13, 21 February 2013 (EST)

Jennifer, the manual creation of the categories can be seen as a disadvantage. The advantage is that you are right some control option. If an incorrect category is usually not the only problem with the pages that belong to that category. Old GEDCOM still need care come this way to the top. There are red link, but there are almost no categories with over 110 topics. And every week, that number down. Automatic categories can not be edited, but it can not be forgotten. And it can not be tampered with.

The Category:Hautes-Pyrénées, France is another story. Groet, --Lidewij 09:55, 21 February 2013 (EST)

I've found the automatic behavior of surname-oriented categories to be a headache for medieval and noble lineages. I offer a proposal of my current practices along with attempting to engage some discussion on the associated talk page. The two lines of thought emerging there (which may not be mutually exclusive) are to simply not use the surname field or to obtain software support that would let us deactivate the automatic behaviors associated with the surname. It was specifically observed that - where patronyms are concerned - the practice of supplying them as a surname may be so deeply embedded that discussions of whether that is or is not a proper/modern surname are somewhat beside the point.

I can't think of anything I have used categories for that doesn't work better with search even under the current system.--Amelia 10:39, 21 February 2013 (EST)

Until recently I avoided using categories. I could not get my head around their usage. Then recently I started working with a family which had been uploaded to WR by someone else who had not provided much more than bmd information, usually without sources. I decided to build up the 19th-century information for a section of this family that lived in Ontario, Canada, and which, much to my surprise, were related to my own family very distantly by marriage. Suddenly I found an automatically-produced category useful.

But I also found a problem. The surname has three or four spelling variations--sometimes invented by census enumerators and local registrars, sometimes passed down the family. Could a group of similar surnames be incorporated into one category manually? --goldenoldie 10:43, 21 February 2013 (EST)

I wonder if you could create category pages as redirects? That's what I'ld try anyway - taking whatever form is least common, then trying to make the category page a redirect to the form that is more common. Alternatively, you could indicate the less common form page as being in the category of the more common form. Then the less common form would show as a sub-category of the common form, but that's probably not what you want. Good luck anyway... --jrm03063 11:09, 21 February 2013 (EST)

Redirecting category pages is not recommended. See WP:Wikipedia:Redirect#Category redirects and WP:Wikipedia:Categories for discussion#Redirecting categories. --Jennifer (JBS66) 12:20, 21 February 2013 (EST)

Surname pages such as Surname:Swart include information on related name variations. The information entered on Surname pages is used to return variant names in searches. There was a large variant names project that was intended to replace the related names section of surname pages. I am not sure what stage this is at in regards to Dallan migrating all the information to the new system. --Jennifer (JBS66) 12:30, 21 February 2013 (EST)

Amelia, if you know exactly what you're looking for, you can use the search system. If too many topics that gives it all a lot less to use. Do not know the correct spelling then gets stuck. Groet,--Lidewij 11:02, 21 February 2013 (EST)

Actually, I think search is much more useful if you *don't* know what you're looking for - it automatically handles spelling variants and gives you additional information in the display, neither of which is true of categories.--Amelia 14:16, 21 February 2013 (EST)

Goldenoldie, you may submit multiple spelling variations use Add alternate name. You can also look at Surname:XXXX, for Related Names. We make this site, maybe you should still fill the other spelling variations. groet, --Lidewij 11:16, 21 February 2013 (EST)

- - - -

I would like to support the comments by Jennifer and Amelia. From when I first joined WeRelate two years ago I have always regarded Categories as awkward and unnecessary. From my background in systems engineering they are nothing but pushing off onto the users the burden of creating and maintaining database search indices - a process which good databases have automated for decades. If we try to (manually or automatically) create and maintain indices for all of the combinations that different users might care about (eg surnames with or without variants combined with location to whatever granularity is deemed appropriate) the entirely predictable result will be the "combinatorial explosion" of categories which the people who steer this site are now backing away from. Ditto for trying to maintain a hierarchy of Categories which is bound to break - history has shown that except for very simple databases hierearchal indices inevitably collapse over time.

Far better to invest the time and energy in a better search interface - more control over which data or combinations or variations "match" the query plus more control over the order in which the large numbers of matches are presented. If we allow users to create and save their own search and sort criteria things will go much better than if we try to anticipate in advance all the combinations of things users might wish to search. Automatically generated Categories can be better served by a small number of canned search or templates. This already exists for simple searches for People, Places, Sources etc and could be extended for combinations of People and Places, etc - and (very important) more control over how the matches are sorted (hierarchal sorting of results trumps hierarchal maintenance of indices). User-defined Categories can be better served by allowing users to create and save their own search templates. Consider adding Searches and MySearches pages, and showing in the Search drop-down a list of the common Searches followed (after a break line) with a list of MySearches. --Jhamstra 13:28, 21 February 2013 (EST)

I generally agree, but this -- "User-defined Categories can be better served by allowing users to create and save their own search templates." -- I don't agree with. By definition, a category should be generally applicable. The equivalents of "X's ancestors" and "Y's Descendants" are not allowed. Thus, any user-defined categories should be created to be useful to the community, both as a marker on pages and as a browsing mechanism. A personal search template doesn't do that.--Amelia 14:16, 21 February 2013 (EST)

My two cents is that I have found little use for categories, personally. If I have a relative that is a US President, it doesn't mean I care about the other 40+ enough to want to link them all together in a category. That seems much more geared towards an encyclopedia than genealogy. But certainly people engage in genealogical projects that involve grouping. But there is some question in my mind about what types of groupings are universal enough, since categories must be shared by all.

As far as automatic categories, due to spelling variations, they are probably useless. A surname article giving overview of branches of its family, and etymology of the name is all useful, but not sure how many people find a category page with 100s of people on it all that useful. Agree searching offers more more focused way to find the related people supposedly being grouped together by automatic categories.

I think a related issue is the use of template banners. I think they are trying to accomplish a function that seems appropriate for categories, and would rather remove the excessive glitz of the banners, as distracting, potentially clashing and intrusive, since many banners only represent groups important to the user that created them, but the banners are visible to all. If there is some overview or navigation common to a bunch of pages, it would seem like it should go on the category page which are easily accessible by link but less obtrusively displayed. --Jrich 14:32, 21 February 2013 (EST)

The private search save, must make sense. Once you found what you were looking for, you usually do not need it anymore. It is a human quality to a good search to start and not everyone has that quality. This search is not an option for someone who occasionally comes along. This Category:Hall surname is clear and inviting.

Everyone has a different way of doing genealogy. When I, in 2007 wikipedia, started contributing I never used the categories. When I am at the moment (10,000 contribs) I find something that usually through the categories. Unknown is unloved.--Lidewij 14:43, 21 February 2013 (EST)

As has been shown over time, different people learn and do research in different ways. What one person finds helpful, another may find cumbersome and vice versa. I, personally, find that categories are helpful in how I do research, because I am able to see at a glance up to 200 uncluttered people that fall under the surname which I am researching. This also gives me a quick, alphabetical snapshot of what research may or may not have been done, what resources someone else may have connected to a specific surname and whether someone else has touched on a family which may be of interest to myself. I understand that the search engine is supposed to be designed to bring the same information forward in one form or another, but I find that I prefer the organization and information of the category pages instead, as long as they are used properly. I admit that the Categories as they currently stand can be cumbersome if they are simply allowed to grow out of proportion, but any useful tool needs maintenance of some type and the Categories are no exception.

It would be unfortunate to lose what I consider a useful tool simply because it isn't used by everyone, unless of course this is actually a space issue (so many categories take up too much hard drive space). If that is the case, then, by all means, do as needs to be done to maintain the overall site, but if it is not, my position would be to keep Categories and find ways to make that tool easier to maintain.

SIDE NOTE: On running various tests of the search engine, I find that I am unable to determine why the individuals of the results given are ordered in the manner that appear on the screen. Anyone else have a handle on this one?--Khaentlahn 20:37, 28 February 2013 (EST)

The barriers are too high! I'm about to give up. [2 March 2013]

I am a mature and intelligent person. I am a seasoned genealogist, Mediawiki administrator-author-editor, and a former computer programmer for a public school system. I have tried placing my genealogy here, but the barriers are just too high.

I agree that uploading GEDCOMs may not be the best way to go for werelate.com. I uploaded some GEDCOMs, but can't find any software to prepare them for the standards expected by werelate.org. Manual data entry is just too time consuming for me to enter data here and maintain my research elsewhere.

I have had little success entering sources. They are the last straw. I do have very good sources, but don't seem able to enter them in a way that is acceptable to the demands of the software. Place names are another problem. I always use "local, regional, state, country." With no standard, things get confusing.

I may give it one more try. I think the basic idea for werelate.org is wonderful, and touches the future of genealogy. I am a septuagenarian anxious to get my work freely available to the public before it is lost. whroll 16:14, 24 February 2013 (EST)

We're trying to strike a balance here - between support of GEDCOM uploads and not letting the site be overwhelmed by content that people load - and then walk away from. I still routinely find myself dealing with content that was uploaded and abandoned from 2007.

Maybe if you pointed at a page or two where you're having difficulty, we could help you? --jrm03063 17:00, 24 February 2013 (EST)

I would be willing to show you some pointers. I will edit some of your pages to give you examples of how to use the sources. Once you realize that many of the sources you will need are actually already on the site, it becomes quite simple. user:DMaxwell

Mr. Roll, you can't give up! Not when I just found you again last night! I am not very computer literate and have found the learning curve very steep. I, too, am entering by hand rather than uploading a GEDCOM. And sources are, I agree, real bears but... you can't quite! You have too much to offer this forum and I really appreciated last night learning that you were here!

If you upload a GEDCOM with sources you can simply leave the sources as MySources. I might be speaking heresy but it is an option.

Jillaine 18:13, 24 February 2013 (EST)

It would be a shame for anyone with high quality data and good sources to give up on WeRelate, but I can sympathize with the difficulty of managing sources and places. I find this the most tedious part of loading GEDCOM files, but tell myself to have patience, grit my teeth and put in the time and effort. It usually takes me an hour or two to match sources, including creating new ones, each time I upload a GEDCOM file with 70-100 sources.

I have found, as DMaxwell says, that sources already exist for many books (although it can be a pain to determine if they refer to the correct edition, since they often include the reprint date instead of the original publication date). I also create new sources for individual journal articles. Maybe if you let us know what types of issues you are having with sources, we could offer more targeted advice.

In terms of place matching, I found when I was loading US data, automated place matching was almost complete and very reliable, but it is less so for other countries. My personal format is similar to WeRelate, but not identical (I usually includes "twp" when appropriate) - and the automated matching still works for places in the US.

As Jillaine says, it is not essential to match sources, and there is a suggestion to enhance WeRelate to make it possible to redirect MySource pages to Source pages, so if you decide to go that route, it should be possible to "fix" the sources relatively easily in the future. If anyone is looking at your data and can't stand that it is using a MySource, they could always change it to point to the correct Source page. It is all part of being a community that shares data.

If you are still finding GEDCOM upload too frustrating, don't deprive WeRelate of your data. At the very least, look for partners to help you load it, or turn it over to someone who is willing to load it. I am still in the process of adding my data to WeRelate, which involves doing more research to improve the quality first, so I'm not ready to take on anyone else's files yet, but I would expect that this is the kind of volunteer work I might do in a few years. As a point of interest, can you give us some idea on the volume of your data (number of people, number of sources and places, countries covered)?--DataAnalyst 19:43, 24 February 2013 (EST)

Volunteer Partners! What a wonderful idea! Is there any hope that this idea could be expanded somewhere? I have not had the time nor skill to break my large database into smaller bits to upload. This would really reinforce the idea of a collaborative site! I would love to have my database on WR but it has become a job too big for me. I haven't even been able to 'clean up' the pages I've already uploaded. --janiejac 11:26, 27 February 2013 (EST)

How large and how intertwined is your database? I have some experience with breaking a database into smaller parts - it is like a puzzle and is a nice occasional break from hunting down source citations. --DataAnalyst 21:29, 27 February 2013 (EST)

Thanks for asking. I wrote the details on your user page. --janiejac 13:05, 28 February 2013 (EST)

The most pertinant comment here is the lack of tools to prepare gedcoms for werelate I,d be interested to hear of peoples experiences in this regard

Your desktop program should have all of the tools you need available. I use PAF which is not as full featured as some other programs but has all of the capability required. 5 years ago I worked out a procedure that should work today. Find it posted on 20 Nov., 2007 at Muti copies of people and/or families? 24 November 2007 I don't know what happened to Ronnie, she used to welcome new users like Amy today--Scot 13:50, 28 February 2013 (EST)

Specifically, tools which could move data from FTM into werelate. FTM now syncs with ancestry and it does much of the source work for you It treats sources in a relational way not the heirarchy approach of gedcoms--Dsrodgers34 21:54, 25 February 2013 (EST)

That would end up being a mess; we definitely do not want to start syncing WR pages to FTM; FTM has fewer options for data and source entries (Ancestry.com is notorious for treating baptismal dates as birth dates, for instance, and burial dates for death dates, not to mention the many garbage 'sources' people use in trees there that would have to be scrubbed), which would screw with the whole site. I can just imagine the headache it would be to go back and fix pages that were 'synced' with someone's tree in FTM. user:DMaxwell

Sorry, you misunderstand me. I'm not talking about syncing just a simple upload. Ancestry, and its partner software, ftm has its problems for sure, but if it is used properly I'd rate it a 7 out of 10 compared to a huge amount of trees going around. Don't werelaters complain that gedcoms come in with a negligible amount of sources ?

What was proposed was discussion about some kind of tools which could be used to prepare gedcoms before upload into werelate. That way some of the common problems could be fixed with search and replace type tools. The alternative is lots and lots of manual rework within werelate, very tedious. I'll try to be clearer next time I contribute.--Dsrodgers34 14:59, 27 February 2013 (EST)

I'd be curious to know what kind of "massaging" of GEDCOM files is needed. I know I do some on mine, but what I do could all be handled by the WeRelate GEDCOM uploader if it were a priority to make the changes to the uploader. All the changes I make to my GEDCOM files are essentially for esthetics - remove DEAT Y, remove _SDATE tags (sort dates), convert months from uppercase to mixed case and "abt" and similar qualifiers from uppercase to lowercase. Additionally, for some reason I have never questioned, the Living fact gets converted to an Other fact by the WeRelate uploader and I have to fix them all in WeRelate. But none of this is earth-shattering or has anything to do with source citations, so it makes me curious what types of problems others are facing. BTW, I use RootsMagic, which I love. Each source is listed only once in each GEDCOM file, with citations for each fact refering to the source - am I right in inferring from the discussion that other genealogy tools don't do that?--DataAnalyst 21:26, 27 February 2013 (EST)

Although I haven't downloaded a gedcom in about 2 years I learned early on to keep them small - 30 to 50 people. I export first to my genealogy software, run my genealogy software potential problems tool on the new file, correct the problems and view and edit, then, if satisfied, create another gedcom and export it to WR. It would not be unusual to go through two cycles before exporting to WR. I abhor encountering duplicates and by keeping the number of people minimal I can do a quick search of WR for potential duplicates.--HLJ411 21:15, 27 February 2013 (EST)

I was going to suggest exactly the same thing. If you break up and load your gedcoms into specific families (obviously the ones that are well-researched and sourced are more preferable), it makes it easier to go through each smaller gedcom in order to 1) make sure it is correctly merged with existing families on WeRelate, and 2) keep the source data in place (which is important to many of us). As has been well-stated above, this is not a "dump and run" genealogy site where marginally researched and documented gedcoms will have to be "fixed" (or deleted) after the submitted leaves.... After you "get the hang of it" with smaller chunks, it gets easier with each one.

Thanks for your understanding and we hope you stick around and help to "raise the bar" on submissions here at WeRelate.

Best regards,

Jim

I definitely agree that the barriers are too high. It's too hard to contribute, either by adding individual entries or by uploading GEDCOMs. As a result, I personally think WeRelate is far too small to be useful as a resource - it needs to cover hundreds of millions of people not a couple of million. At this rate of growth the site is likely to be overtaken and die before it actually makes a significant impact. We don't need to raise the bar - we need to lower it. AndrewRT 17:31, 28 February 2013 (EST)

The entire point of WR is pool the best resources and sources together for the most accurate information. There is a tide of bad genealogy that WR is swimming against. That some people havent figured the quirks of our system is not the fault of the site. Lowering the bar (where, in my opinion, it actually needs to be raised) would turn this under another GEDCOM graveyard of misinformation. Genealogy isnt easy work, and many other sites need to stop giving the impression that it is. Daniel Maxwell

Yes, there is a tide of bad name-collecting genealogy, and WR should work against that, but nevertheless having unnecessary barriers to new users is a fault of the site. There is no need to lower the bar about the quality of additions, but there very much is a need to remove barriers that do not serve to improve the quality of the research presented. Specifically, the interface implies that one must link uploaded places to WR Place pages and sources to WR source pages. This does not improve the quality of the research presented on WR (although it does make WR very slightly more useful). These form barriers to new users, and these barriers tend to keep WR small and therefore less useful and relevant generally, and that situation may lead to its eventual demise. --Robert.shaw 18:08, 1 March 2013 (EST)

I completely disagree. Linking the items to said sources is one of the best features of the site. Now, one could make the case that it should be more automated, but it is not a detraction of the site. On the contrary, it is beneficial. One of the pitfalls of internet genealogy, particularly when moving from paper and pen family trees, is that the sources for the given information get lost. In some cases, even within my own tree, the originals cannot be found (if they are obscure), and we have what appear to be completely unfounded assertions, while they may not be. Other things you mention such as place names conforming to one other improve the neatness of the site. If there were a movement of the users on this site to remove links to sources to make the site easier (and therefore uglier), or to scrub the site of citations, source text, etc I would probably cease contributing completely. Daniel Maxwell

I've been lurking in the background following this discussion. In my opinion, I've made two really good decisions regarding the genealogical data I've collected over the last fifteen years or so. (1) Don't upload the data to the on-line data collections such as rootsweb or the Family Tree Maker site. I've got over 130,000 persons in my database (why so many is another discussion, suffice it to say that I'm very interested in a macro approach to early New England families, not the micro approach to only my own ancestry). Possibly 15-20 percent of those people were taken from questionable sources, rootsweb or the former LDS site. (2) In almost two years on WR, I have not uploaded a gedcom. Making the entries one at a time forces me to go back and evaluate the sources and, often, to discover better sources which I had not been aware of before. Thus, I'm inputting "better" data. I would add that I don't mind the drive-by gedcoms where folks have done a one-time upload and then disappeared. There are often kernels of fact embedded therein which lead to more substantive data.--jaques1724 19:22, 1 March 2013 (EST)

Yes, in fact when I joined here at first I too was confused about sources. Your excellent, neat work (among a couple of others) - which is what caused me to notice WR in the first place, I then used as a model in my work on WR - a model I had been wanting to move to my own personal tree and have since done so. Realizing the problems with GEDCOMs, I have never uploaded one to WR (though I started to) and I agree that it has made me think before I create a page - can I prove the data, or would it be better if I waited till I can prove it? With regard to the drive by uploaders, I guess its mixed to me; when I recently did the complete ancestry of the immigrant Jonas Austen (which took several days) I made all of the people, familes, sources etc by hand. But the result was much neater than if I had dealt with a messy ugly old gedcom upload, but it did take much longer. Daniel Maxwell

I've read the whole of this section with some interest. There seem to be several reasons why some people are thinking of leaving. If you fail to be dissuaded by the convincing-looking responses in this section, please consider or reconsider Familypedia, which is smaller, which does not yet have a recommended GEDCOM upload facility (though several thousand articles were created by a GEDCOM manipulation procedure), which has a very easy form-based system for adding and editing articles about individuals, and which does not have demanding standards about sources or places while it encourages the recording of sources. Familypedia also has Semantic Mediawiki, which is possibly superior to WR in some aspects of display and search results. You do have to put up with a little advertising (but even Rootsweb has that); you see less of it if you register. Robin Patterson 23:34, 1 March 2013 (EST) (another septuagenarian)

Discussions of evidence [26 February 2013]

While I'm here, I have a question concerning where is the best place to put a discussion of the evidence. It seems to me the Person page is best for biographical, narrative type of stuff rather than a down-in-the-weeds discussion of the fine points of comparing differing transcriptions sort of discussion dealing with alternative interpretations of the evidence. The Person Talk page might be better but there is no way to handle sources or quotes from transcriptions without retyping or doing cut and paste. How do others handle such discussions?--Renee Dauven 17:23, 24 February 2013 (EST)

The person talk page is really the best - if you're discussing evidence for that person - since the discussion becomes part of the record for others who follow. --jrm03063 17:53, 24 February 2013 (EST)

The talk page not a good place in theory because these issues are not discussions between two people (i.e, talk), but elaborations on the facts presented on the page, and are often as important to understanding why the fact is there as any source. The talk page is not a good place in practice either, as the indication that there is a talk page is too easy to miss, it stays "lit" even when the talk page was erased and has nothing on it, it often only has nomerges, and the talk page isn't visible during merge or gedcom upload. If the narrative gets too long, centralize these topics in a section with an appropriate header. Since this is not a single user site, there are several issues about dealing with alternative genealogies and uncertainty that there aren't good answers for, and good guidelines haven't been developed. --Jrich 20:38, 24 February 2013 (EST)

It depends on the nature of the comments and whether one is looking for feedback and interaction. If the latter, like you're wondering if fact X is significant to establishing a relationship, then the talk page seems appropriate. On the other hand, if you think there is some subtlety in the data supporting some stated fact about the person, something that people (who care about evidence) should be aware of, then the Person (or Family) page is appropriate. Remember that people will see what's on the Person page, but may not notice the Talk page, and that only the Person page information appears in a GEDCOM download.

It's fine for more than biography to appear on a Person page. Separate "== Sections ==" should be used to make clear what's what. For instance, it's been a common practice to have a "Disputed Lineages" section on a person page under which discussion is included about the evidence supporting alternative relationships (e.g. alternate parents). --Robert.shaw 17:28, 25 February 2013 (EST)

Robert do you know of a page were a disputed lineage section was created that I might look at and maybe use as an example? Thanks all for the suggestions.--Renee Dauven 19:21, 25 February 2013 (EST)

A little search turned some up; here are three using Disputed Lineage sections: Person:Thomas Welles (1), Person:William Marche (2), Person:Samuel Mayo (2). I don't know anything about those people, but in a somewhat similar vein, I added a section (not titled "Disputed Lineage") discussing evidence to Person:Isaac Van Camp (1). --Robert.shaw 03:00, 26 February 2013 (EST)

British nobility [5 March 2013]

There is a lot of public domain information readily available about British nobility, e.g. through the out of copyright editions of Burkes peerage on archive.org. Has anyone else attempted to add this information to werelate? Would anyone get interested in forming a mini-project to do this? Cheers AndrewRT 14:58, 3 March 2013 (EST)

A few people (including myself) have been adding records - I am not sure how complete. Other sources used are The Peerage by Darryl Lundy, who has made extensive use of books on British peers, as well as Medieval Lands by Charles Cawley, who has used many sources and gone back to original sources wherever possible. If there were to be a concerted effort to add records based on Burkes peerage, I would consult these other sources as well, as in some cases, they have more up-to-date research and/or evaluation of research (Cawley, in particular, but I am not as familiar with Lundy). Others have gone through existing records in WeRelate and linked them to Wikipedia articles, where relevant - with the knowledge that the quality in Wikipedia is hit-and-miss. I haven't worked on this for a couple of years, but would be interested in coming back to it in a few years.--DataAnalyst 22:23, 3 March 2013 (EST)

Interesting thanks. I like peerage.com very much but im wary about how database rights would come into play if we replicate a significant portion of his website. Has this been considered at all? AndrewRT 08:48, 4 March 2013 (EST)

I'm always leary about using a large chunk of another person's work (in respect to the work they have put into it), but the fact is that you cannot copyright the facts about another person (e.g., birth date and place, death date and place). It is the conclusions and commentary where we have to be careful, and always make sure to give credit. I haven't quite figured out how to do good quality genealogy without depending on other people's conclusions (e.g., "there were 2 Richard Bronson's in this town at this time and this is how I split the facts between them", or "I don't buy the tradition that so-and-so was the father of this person because of such-and-such"), so I try to make sure that I give credit, and, where feasible, dig into the sources myself and come to my own conclusions. I also try not to use a single source, but to cross-check it with other sources, so at least the new data is not a strict copy of someone else's work (parts of it might be, but not whole trees). I am pretty sure that whatever I do is legal as far as copyright is concerned, and I hope it is considered respectful as well. For British nobility, I would leverage Cawley and sources he points to as well as peerage.com. I think that is the essence of research - building on other people's research, and giving credit. --DataAnalyst 18:57, 4 March 2013 (EST)

Collections of facts DO have intellectual property protection in some non-U.S. jurisdictions (e.g. Europe), thus AndrewRT's reference to "database rights" as opposed to "copyright." I presume WeRelate wants to play on a global scale, so non-U.S. intellectual property laws are as important as U.S. laws. Tfmorris 23:39, 4 March 2013 (EST)

We're presently using Cawley on about 2700 pages, and Lundy on about 5700 (Follow-up of 3/5/13: as of this AM the real champion of DB usage is Wikipedia, on a total of about 20,800 Person pages, many of which are Royals and Nobles). I've exchanged e-mail with both of them and found them helpful and responsive. I've found a handful of duplicates in Lundy's database over the years, and he's always pleased to get any help of that sort. Cawley is much more of a specialist of course (no chance I'll find defects there!) but was very helpful when I asked what the best practice would be for us doing cites of his work, for purposes of link compatibility with future versions.

I'm not particularly interested in duplicating Lundy's content, but I am interested in - some day - being able to run cross-database consistency checks for content that both WeRelate and thepeerage share. I think we may be able to find issues in the content of both sites and to generate potential improvements for both.

I'm more interested in a semi-exhaustive representation of Cawley's work, at least for purposes of people who correspond to HTML anchors in his documents. If we get that far - maybe it would be worth discussing with him whether to add anchors more universally in his work (thereby allowing a systematic database of his content without him needing to change his preferred presentation or method of working). I've also recently started adding cites of Cawley to category pages for relevant houses of nobility, which is sort of slick.

I don't think either Cawley or Lundy are threatened by cites from WeRelate. I would think that we're driving traffic their way and giving them visibility, which is just as I would have it. We don't, and shouldn't, replicate their sources or narrative - so I figure we're legally clean as well as ethically so. --jrm03063 20:55, 4 March 2013 (EST)

---

Thanks for responding - very interesting. Yes it's the highly problematic European concept of "database rights" that I was specifically referring to as a worry. I would hate for us to be very successful and then find in a couple of years time that we had to delete loads of our content following a court case. Wikipedia is not a problem of course, given it is CC-BY-SA licensed like us. Hence my preference for out of copyright books.

Regarding, "replicating their sources or narrative": this sparked a thought - let's say they decided to donated their entire content, which part would not be suitable for use on WeRelate? I think pretty much all of it would be great additions here!

Regarding my mini-project, I've started some thoughts at User:AndrewRT/British_Nobility. The most promising lead I have seen so far relates to a book on "The royal lineage of our noble and gentle families". This sounds a great link to our vision of a pando as it will already link to many people already covered by WeRelate. All feedback welcome on that page or here. AndrewRT 16:33, 5 March 2013 (EST)

Wikipedia hi-jacked? WR agent taken in [5 March 2013]

The most recent upload of details from Wikipedia for the template {{Wp-Mitchell, Ontario-History}} gives the name of the first settler as Asif Patel in 1836. This is a change from a man named William Johnston in the previous upload. Both names are very common in their own cultures and much of Ontario now has residents who came from many lands, but in 1836 Johnson would have been much more expected than Patel.

Having written the above, I went over to Wikipedia to check its sources and found it cited an online book entitled History of Mitchell, Ontario by William Johnston; History of Perth County 1825-1902 Chapter XXV, Stratford 1903. The chapter in the book does not refer to William Johnston.

To top it off. Wikipedia does not list any changes to its article since 2009. The contributors' biographies are far from being those of mature historians. It is my suspicion that we are letting ourselves be duped along with Wikipedia. --goldenoldie 02:48, 5 March 2013 (EST)

{This note also to be found in {{Template talk:Wp-Mitchell, Ontario-History}})--goldenoldie 02:56, 5 March 2013 (EST)

Certainly has the potential to be a case of WP vandalism - would suggest you fix it both in the local WP template and on WP proper. --jrm03063 08:18, 5 March 2013 (EST)

This is a normal situation because WR periodically copies the latest version from Wikipedia, whether it's been vandalized or improved. In this case, it is vandalized, quite possibly by a young Asif Patel. (It's not hijacked, as Wikipedia allows anyone to change most anything, and someone did just that.) By the way the "Asif Patel" change went into Wikipedia on 17 January 2013, so that change is relatively recent.

This is not a great WR policy except if the Wikipedia text has never been inspected by human eyes on WR. Many place pages on WR have never-inspected Wikipedia text, so for them the periodic update is reasonable, since on average the text will have improved despite it sometimes being worse (as in this case). However, if a WR editor has looked over the Wikipedia text, we should somehow mark it so that it thereafter will not be automatically overlaid by a later Wikipedia version. --Robert.shaw 14:45, 5 March 2013 (EST)

I'm not sure I understand the benefit of periodically updating wikipedia text - the changes are as likely to be problematic (as the original requestor has moved on) as improvements. I would suggest we leave them as they are with an option for someone to request an update if required. AndrewRT 16:13, 5 March 2013 (EST)

I don't think so. We just did an update, and there have been many thousands of changes. This is the only one that has been singled out for this sort of problem, and presumably (if it hadn't been seen here) - it would have been fixed in the normal course of events by our next WP update. --jrm03063 16:45, 5 March 2013 (EST)

Family Tree is Live on FamilySearch.org [13 March 2013]

Family Tree is Live on FamilySearch.org for All Users - Wondering what the WR community thinks about this and the possible impact it will have on the future of this site? --Cos1776 16:02, 7 March 2013 (EST)

Already being a registered user of familysearch.org, I logged-on and looked at Family Tree a bit. It is a much simpler interface compared to WeRelate, but not obvious whether one can do some of the more-sophisticated things that WeRelate can do.

That being said, ease-of-use is NOT to be taken lightly and this tends to reinforce a concern that I have previously expressed and that comes up periodically. Whenever someone suggests that WeRelate consider if there might be an easier-to-use method for doing something, there seems to be instinctive push-back from the "Guardians of the Wiki" that we should resist making things "too easy" as this will only encourage carelessness on the part of newcomers. Better to keep the barriers high and discourage all but the most serious contributors. Nevertheless, best systems engineering practices include designing interfaces to encourage "proper" behavior by making it easier to do things the right way (capture sources, check for duplicates, etc) rather than the wrong way. Most of the suggestions to make things easier for WeRelate contributors seem to fall by the wayside - and probably take other potential contributors along with them.

I take the view that competition among genealogy web sites is healthy. Those that best meet the needs of the potential contributors will flourish and those that do not will wither. Demand for change is one of the prices of success of any product or service. Those that evolve to meet the changing needs of their market tend to prosper - those that resist change tend to either go away or survive in narrowly-defined niches. --Jhamstra 16:45, 7 March 2013 (EST)

I did not see a way to import a GEDCOM file. I know that GEDCOMs have been a source of controversy at WeRelate (too easy to add lots of bad data, too hard to use), but for me, it is the only practical way to meet my desire to have my own (quality) database and to share it without introducing a bunch of typos or having to copy source citations (of which I have a lot). Since FamilySearch starts with what appears to be the Ancestral File (which I hope they have cleaned up somewhat), it has the advantage of starting with lots of data, although there may be a lot of junk if they have not cleaned it up significantly.

I think one of the things that will continue to cause WeRelate to struggle is the limited programming resources. Dallan is great, but it is pretty hard to meet everyone's requests for new and improved features with only one developer. When I was in that position once, I had a permanent backlog of at least 100 items that would never become high enough priority to address - and I had a user community of only a dozen people, not hundreds. So, Dallan, we appreciate you, and personally, I appreciate the opportunity to have a say in how the site evolves, even if it is not possible to address everything we would like to see.--DataAnalyst 18:55, 7 March 2013 (EST)

I am probably one of those 'Guardians of the Wiki" you speak of. While I do not want to see it made *too* easy, I have always been happy to support improvements that will make it easier to *properly* contribute to the site without harming the caliber of contributions. But many of the suggestions that have had support either havent gotten added and others havent been commented on (such as moving cemeteries as places to oly the burial location box). This site needs new programming blood, as one man cannot do it all alone. Daniel Maxwell

WeRelate would greatly benefit from assistance across the board! Users who are interested in helping programmatically are encouraged to consider Website features or Bots for page maintenance. Users interested in less technical volunteer opportunities can look over the various patrols at Portal:Maintenance. Leave a message on the talk page of the group that interests you, and we'll let you know how you can help.--Jennifer (JBS66) 10:37, 10 March 2013 (EDT)

I've been using Family Tree for several months now, and while I tend to see it as the "Second Best" on-line site, I think WeRelate is far superior. For one thing, in spite of appearances, many of the changes that need to be made to relationships (parent/child or husband/wife) can be incredibly difficult and frustrating because they are totally counter-intuitive and require way more steps than anything here at WeRelate. And DataAnalyst is right about GEDCOM uploads. Not there. True, as he said, lots of entries already there, but some are old and have major, major problems. There are a lot of other limitations, as well. Positive points: it is a true "Match and Merge" site, it is Source Driven (as much as possible given human nature), and it's likely to be around for a very long time. I still prefer WeRelate and all the extra features it has, and, believe it or not, the fact that it is easier to use. --GayelKnott 20:54, 7 March 2013 (EST)

Please do not misunderstand me - I am NOT ready to jump to Family Tree. It is for some situations a simpler interface but I have not tried to do anything more complex there, nor am I likely to for a variety of reasons. Nevertheless, I find the lack a Source-driven interface for WeRelate to be very cumbersome, especially when trying to apply the same Source to tens or even hundreds of Persons and Families. I am sympathetic to the issue of "Dallan overload" but as with many other software systems where I have provided detailed feedback, it is sometimes difficult to tell the difference between "we think this is actually a bad idea" vs "we don't think we have the resources to do that" vs "we can't be bothered with divergent opinions about how things should be done". --Jhamstra 23:19, 7 March 2013 (EST)

It has always struck me as ironic that the same organization that provides access to the largest set of primary sources available, would also have the worst set of family trees online (i.e., the AFNs and PRFs). So the fact that this is based on AFNs is a huge turnoff to me regardless of how easy it is to use. I just looked up a page I worked on WeRelate, where I corrected some errors imported from AFNs, and yep, the errors are still there on Family Tree, just as ridiculous as when the old system was up (died young but shown with a husband, surname of father differs from maiden name of purported daughter, etc.) I can't say how the system will evolve over time. Perhaps a shared tree will be enough to correct the errors made by those who only copy other people's online family trees, I don't know. My sole criteria for using a site is my belief in its reliability, and years ago I gave up even consulting AFNs as a waste of time. It's not that I don't value ease of use, rather that reliability/accuracy is the only criteria that really matters to me. --Jrich 23:34, 7 March 2013 (EST)

I just checked it out and added a few records, the last of which was mergeable with a record they had. When I completed the merge, it only attached the individual, not the parents connected. That I do NOT understand. Jillaine 08:57, 10 March 2013 (EDT)

Others have said it well - too easy to just add random junk, barrier is too low (Yes Virginia, it shouldnt be too simple). I foresee fights when someone tries to remove a relationship for someone's 'royal pedigree'. I also find their interface ugly; WR is much more presentable and easy to read. Thats part of the problem with some of the other sites - they either make entering data too dang easy (how often will people upload New England colonists, causing the duplicate to rack up - a problem here on the early WR) or too difficult (a couple other genealogy websites allow one person to have ownership over people's pages - imagine the headache that would cause here for those of us that clean up old uploads). WR is the perfect balance, and that is why I only contribute here.--Daniel Maxwell 10:18, 10 March 2013 (EDT)

I've spent some time trying to clean up the Morrows that the Morrow DNA projected sorted out, and it's an odd experience. For context, these are extremely screwed up lines of people all named David, Samuel, and Robert - men are their own father, multiple sets of parents, etc. I can delete relationships at will, leaving unconnected people in my wake, but can't delete people that didn't exist. I am prompted at most points to explain "why I think this is correct" - but not for parentage. And other than those boxes (which don't exist for parentage and aren't always visible), there is no facility to add notes or explanations. There is no ability to use alternate information - you always replace what is there - which is particularly problematic when merging guestimates. Adding sources is also a pain and it's not clear to me that anyone else will ever see them (they are basically "mysources", and I can't find any other records, even ones that should be heavily edited, that display sources), so I have stopped bothering and just paste the source into the "why is this true" notes.

There is a facility to add records from an FS search to a tree entry, but it requires about 6 steps and starting with the search, and doesn't easily display the data that's actually in the record. (There's also no page number or other pin cite information generally - each "source" is designed to be a single record in one place, which will make managing these things on a large scale difficult.) But if this is improved - and has a relation back to the added entry like Ancestry does, it could be pretty slick. (example of an edited record if people are curious, since I haven't found others: [1])

Overall, I think there's value in crowd-sourcing the AF given how common the data is, but between the way display and edits function and the inability to describe or discuss evidence, there are clearly going to be edit wars with no good resolution.--Amelia 11:02, 10 March 2013 (EDT)

I remember reading something by one of FS's site devs some time ago that the feature wasnt intended to be an all inclusive family tree of perfection (like we aspire WR to become :)), but rather so that that alot of the old trees can be cleaned up. There used to be alot of grumbling, even in the 90s, that there was no one way to do this before. Some of these trees in their database date back to ones submitted in the 80s (remember the old Broderbund software on Apple II?), and many havent been changed since then, spreading the same errors, some of which were disproved decades ago. Based on this, I think its an attempt, however futile, to clean out some of that. Daniel Maxwell 11:40, 10 March 2013 (EDT)

I went back and cleaned-up the family tree for a few generations around Maj Ebenezer Wilson (a distant ancestor) https://familysearch.org/tree/?icid=fsGlobalNavFamilyTree#view=tree&person=L85D-9XV. I chose this because I knew from previous searches that there were a number of problems there with duplicate and downright erroneous AFNs and linkages between same (not to mention the confusion caused by four consecutive generations of Ebenezer Wilsons). It appears that Family Tree did a machine merge of all of these AFNs and then left it to the users to clean-up the mess. Well I cleaned-up enough of a few generations of Wilsons and also their relationship with the problematic Newtons (three consecutive generations of Isaacs) - I didn't even try to clean-up the Newtons. In any case it was not a pretty exercise. They have made it easy to enter new data but a real pain to clean-up what they have already loaded. Their Duplicate search is horrendous but I think WeRelate could borrow ideas from their Merge interface. --Jhamstra 00:51, 14 March 2013 (EDT)

Support page [18 March 2013]

I recently answered a question on the Support page and noticed something odd. There used to be numerous users watching the page - now there are only 2 (plus myself which I just re-added). I am not sure how the watchers disappeared, but if you are interested in helping to answer questions from other users - please visit the page and click the Watch link. Thanks, --Jennifer (JBS66) 19:52, 17 March 2013 (EDT)

I recently archived many of the older threads - I wonder if that did it? AndrewRT 16:45, 18 March 2013 (EDT)

Deceasedonline additions for London, England [29 March 2013]

Quoted from the blog "Anglo-Celtic Connections" of 28 Mar 2013

"With the addition of another 160,000 records for the period 25th March 1875 to 15th December 1898 the deceasedonline.com database for Manor Park Cemetery, Newham, East London [England] is now complete. In total 430,000 burial and cremation records are now available.--goldenoldie 08:14, 29 March 2013 (EDT)

inviting others to 'watch' my tree [8 April 2013]

I think I remember several years ago that there was a way to invite new members to 'watch' my tree and when they applied certain steps, they would be watching my whole tree. I cannot remember or find the details on how to do that. Can someone refresh our collective memory of this? I surely didn't imagine this. --janiejac 11:27, 31 March 2013 (EDT)

I've not seen such a thing, but it would certainly be useful. I've been tinkering with a little tool for traversing trees here (actual 'linked' trees, not people's 'defined' trees) and it could easily be extended to permit watching each page traversed. I've always figured it's more useful to actually follow the links in a tree, rather than relying on what's been defined as belonging to the tree, because the latter can sometimes miss branches (or include branches from completely unrelated families!). — Sam Wilson ( Talk • Contribs ) … 20:01, 4 April 2013 (EDT)

There is a way to do this. Go to My Relate>Trees. Then, click the e-mail link on the row of the tree you'd like to share. You can either send the email, or copy/paste the instructions into your own message. --Jennifer (JBS66) 08:54, 6 April 2013 (EDT)

Thank you! That is just what I needed! Sometimes the instructions for these features need to be repeated so that all viewers become aware of this. --janiejac 01:04, 8 April 2013 (EDT)

WeRelate growth [22 April 2013]

I started a discussion previously (see User:AndrewRT/Metrics) about how we could measure the success of WeRelate. Although a very crude measure, I have compliled a graph showing how the total number of pages in the "Person" namespace has expanded which others may find interesting:

AndrewRT 17:45, 6 April 2013 (EDT)

It is interesting. Thanks. --GayelKnott 18:40, 6 April 2013 (EDT)

I too have been keeping track although in a different manner - years to add one million names. For instance, 1 Aug 2012 4.84 years and most recently, 3 Apr 2013 4.90 years.--HLJ411 20:00, 6 April 2013 (EDT)

Both sets of figures indicate a sharp slow down after the "drive by GEDCOMs" were stopped in 2008. Are we happy with the current rate of growth or should we be trying to increase it? If yes, how? AndrewRT 06:54, 7 April 2013 (EDT)

WR did experience a high rate of growth during 2007 - but the quality was horrendous. We've had so many threads here asking Dallan to delete the "junk" imports of various users from that period. It's a common benchmark for users who have been around here for a while - did the user upload their GEDCOM in 2007??? ahhh... that explains the mess... The quality of imports has improved significantly with WR's GEDCOM error detection and Family Match improvements.

One small item that impacts your chart - in March 2010, Dallan adjusted how he tracked the number of pages on the Home Page. He changed from #People and Families to just #People (in this one edit, he reduced the number by 200,000). Another factor is the number of pages people are merging into when they upload their files. The quantity of the pages may not be increasing as sharply as in 2007, but the quality has improved for users to build on. --Jennifer (JBS66) 08:54, 7 April 2013 (EDT)

I don't suggest we go back to the pre-2008 situation (I joined just after those changes were made) given the issues there were. However, I do wonder if there's a way to get the "best of both worlds" - i.e. getting back to those rates of addition but maintaining the quality. I'd also like to develop a metric that incorporated quality (e.g. person pages with at least one date & one source) but that would be hard to back-date. Any thoughts would be appreciated.

Regarding the change from person/family to person - yes I've adjusted for that in my figures. I'll go through the image page and put the full source I've used for each number.

My own experience is that whilst I've found many distant cousins on ancestry.com, which has hundreds of millions of people in their database, I have yet to match a single one on WeRelate. It's different when you're dealing with prominent families (as I've found with my british nobility mini-project, where I regularly match existing pages). I don't believe 2.5m is a big enough number for matching to make a significant different. If you see the rate of increase has actually gone up slightly between 2008 and 2013, despite the site growing by 70%. If matching were a significant factor, it would surely have gone down. AndrewRT 11:00, 7 April 2013 (EDT)

I have to ask - do we really want hundreds of millions of pages? Maintenance is already a problem on WR. To return to the old 'growth' levels, you would have to lower the bar to be similar to Ancestry.com's, who arguably contribute to the problem WR is supposed to solve. But I actually think the turn off for attracting new users is more related to two things (setting aside the learning curve, which should never be lowered) 1) No living people 2) No 'ownership' of pages, with more an emphasis on the first. There was supposed to be a system added to the tree function where living people could be added privately within the program, but not as people on WR itself. I don't think this ever happened. Of course, I never want to see living non-notable pages on WR, but I would like to see the solution that was proposed to happen. The second is a complain I occasionally hear from people who do not want to use WR, but unlike the first I do not sympathize with it - ownership of pages would eventually destroy the site and discourage collaboration. Daniel Maxwell 11:20, 7 April 2013 (EDT)

I have 2 comments to make. First, compiling data of reasonable quality is time-consuming. I only have about 7000 people to contribute to WeRelate, but it is taking me years to validate the info I picked up from a variety of sources. OK - I am also adding citation text as I go, which adds quite a bit of time, but just trying to find reasonable sources (VRs, published books and articles, gravestone inscriptions) to substantiate (and correct) the data that I picked up from other people's personal trees (RootsWeb, Ancestry.com, Pedigree) can take quite some time. It is definitely worth it - I discovered that I picked up quite a bit of garbage along the way, even after I realized that I had to be careful. So, growth based on amateurs like me validating their data before adding it to WeRelate will take time.

Second, I have come across some sizable amateur trees that appear to be quite well-researched. If we could personally invite those authors to submit their trees, or volunteer to submit them on their behalf, it would add a significant number of people. Andrew and I have volunteered to help someone load her tree (about 20,000 individuals). The quality is mixed, and I expect some of the data is incorrect, but it is not a bad starting point for these families. However, the author wanted "clean" place names that match WeRelate place page names, and it is taking me weeks to clean up the approx 7000 place names. So even this can take time (although months, rather than years). After this brief interlude to help load this tree, I want to go back to my own tree, but when I am done with that, I am interested in helping load other higher-quality trees. This type of collaboration in initial loading of data might reduce barriers for those who are overwhelmed with where to start.--DataAnalyst 11:35, 7 April 2013 (EDT)

And by the way, I found that I am distantly related by marriage to the woman whose tree I volunteered to help load (her third cousin 4 times removed married my third cousin 5 times removed)--DataAnalyst 11:40, 7 April 2013 (EDT)

The "best of both worlds" I see nothing good in the old way, just a lot of work.

The quality can not return a millimeter, but up. You can now upload a gedcom with: double persons. Many missing town and missing dates, and above all without sources. It is perhaps time to consider a few things to look seriously. --Lidewij 11:48, 7 April 2013 (EDT)

"do we really want hundreds of millions of pages? Maintenance is already a problem on WR". I certainly don't want unmanageable growth - we need to have growth in a way that is sustainable and maintains quality. But clearly if we had more people contributing information, we would also have more people helping with the maintenance. I do think there are sustantial benefits in having a significantly bigger site. The "pando" model really comes into its own when you have lots of connections between people interested in the same tree. This is simple network theory - the more people who are connected, the more potential connections there can be. I started researching my family tree 20 years ago and after a few years of research had some up with a tree of 250 people. I picked it up again 5 years ago and within a month I was up to 5,000 people, simply by linking into distant cousins who had managed to trace back our common ancestors and had uploaded their data. That happens because ancestry.com has hundreds of millions of people. It doesn't happen to the same extend when you're talking about a site with 2.5m people. AndrewRT 11:53, 7 April 2013 (EDT)

Networking should not be a goal in itself; accurate genealogy should be. Networking will be a natural consequence of growth, even if it may appear slow going. I have already found several just in the course of maintaining New England based pages. Data's point about inviting people with some of the better sourced trees and then helping then import it is a better strategy, as well as my point about fixing the issue with living people, which is BY FAR the biggest complaint people have about WR. Much of what you see on Ancestry.com are duplicates on a massive scale - it is not the best stick to measure WR against. Daniel Maxwell 12:07, 7 April 2013 (EDT)

The topic of helping is a key point in the last few comments. Whether it's helping other users import their GEDCOM, helping with site maintenance, or helping with software development - the community of WeRelate needs help to succeed. Essential to WR's growth is a strong base of organized volunteers, help pages that are streamlined and coherent, and mentors that can help new users. What can we do to increase the number of active volunteers? How can we create a firm foundation upon which increased growth will be solid rather than unstable? --Jennifer (JBS66) 12:40, 7 April 2013 (EDT)

'Evangelization' of WR to other researchers who care about good information is key to this, I think. Data has the right idea. Daniel Maxwell 12:50, 7 April 2013 (EDT)

I've been pondering the idea of going along to one of the genealogy society meetings near me (WAGS), to see if there's anyone else there using WeRelate and whether we mightn't help each other (sometimes more fun in person). How best might I connect with users here who are nearby though? Some additional subcategories to Category:Users? Userboxen, as they have on Wikipedia? — Sam Wilson ( Talk • Contribs ) … 02:25, 8 April 2013 (EDT)

I have a draft article about WeRelate I'm writing for the Orkney FHS - would be great if there was somewhere on here we could share stuff like this and get inspiration from what others have done. AndrewRT 17:37, 8 April 2013 (EDT)

The curve certainly shows what you would expect when you go from a period of zero controls on upload to a more strict regime. It's also positive that the curve doesn't go completely flat in the aftermath. We don't have measurements to tell us that the per-page quality is moving up, but I certainly believe it is.

What I would have expected to see, is evidence of acceleration in the aftermath of the flattening episode. As our data set grows larger, gets better, and turns up on more and more searches (the Alexa data suggest that much at least) - I would expect increasing visibility to turn into increasing participation, new users, more Person pages, etc. Disturbingly, that does not seem to be happening.

The near-linear curve post controls suggests a static size core group - or at least - a static rate of new Person creation. Against a context of more and more people seeing us, that unfortunately means that the percentage of those who eventually choose to join is probably dropping.

Maybe the drop-off in acceptance isn't cause for concern. At some level, it's not the system, it's the data. The database is still free and can never be sold. If thought of as a 2.5M person GEDCOM, it's probably good enough that another effort - with appropriate open licensing - would be able to request (and obtain) the complete set of content as their starting point. If that other system has better usability factors, it will naturally become WeRelate's successor. WeRelate will drift into the sunset - having served its purpose. The data doesn't die, but software does have a life cycle.

I'm a little more optimistic than this might suggest - but we need some fresh ideas.

In the near term - could we start by losing our front-page exciting "News" from August of 2012? Something that tired, sends the wrong message. While the enclosed statement about "time to grow" might now qualify as dark humor, it's probably not a subject you want to lead with. If genuine expectations were behind that remark - well - oh dear.... --jrm03063 21:44, 17 April 2013 (EDT)

ancestry has about 2,500mill persons records at the moment. Theres obviously duplicates and just plain trash. Thre is also a large amount of seriously good genaalogy in there simply because itas so easy to link people to records and have sourcing done for you. When i look for serious connections for people i go to the records where you can see exactly which ancestry users have linked to sources. Their work is by definition more reliable, and less likely to be a copy of someone elses work. I'd love to know the figures of what proportion of census records have been linked for example but i would guess its certainly above half, but probably not more than 80%

Werelate is similar in that its north america europe centric, and most americans have european roots. Werelate excludes living people which means up to 1000 million of all possible records cannot be put in as it stands now. Perhaps the theoretical number of north americans and europeans who have lived, died and had records is somewhere approaching another 1000 million. Certainly not more.

If i had a guess at the number of duplicates in ancestry as 40%, they have 1500 million distinct people records, and 500 million are of good quality.

Therefore ancestry, if it was aiming for pando as good as it could be, they are a quarter of the way there.

But you would be correct to point out that you cant tell which are the good records and which are not--Dsrodgers34 02:03, 18 April 2013 (EDT)

There is good genealogy in lots of places if you are willing to do the work to document it yourself. The difference will hopefully be that someday most of WeRelate will be documented, making it obvious what is good genealogy and what is not. The above estimates of ancestry quality are way too high based on pages I have worked with (colonial era in New England). Reliability, meaning documented, verifiable sources, is what will differentiate WeRelate, since it can never hope to compete on sheer numbers.

There are competing forces that mean any assumption that page add is proportional to users is probably incorrect. Notably, the easy people are already added, and to add a truly new person, fewer generations need to be added to connect him to some other page. In 2008, it was not uncommon to find none of a family entered, and one might need to enter 5 or 6 generations in order to connect a newly added person to an existing page. Now, adding similar pages, it seems rare to have to add more than one or two generations to connect somebody to an existing page.

Of course, that is not to say all people have been added. And even for pages that have been, they are not complete, all correct, nor fully sourced. The importance of this work must not be ignored by only counting page adds.

It would certainly be encouraging to many people to see some progress towards leaving "Beta". --Jrich 11:53, 18 April 2013 (EDT)

Solution : Other languages ! French, german, ... Amicalement - Marc ROUSSEL - --Markus3 12:29, 18 April 2013 (EDT)

I'm not aware that we preclude use of other languages for any purpose, but there's an obvious bias given where the initial world of contributors came from. I wonder if we could do something cute with respect to the 97,000 or so pages we currently source from WP. I wonder if there's a way for a user to specify a preferred language - such that a page inclusion for a person or place - would display in the user's preferred language (assuming that there was a version of that page, written in the user's preferred language)? Likewise a simple internationalization effort on the code, such that any stock label text is chosen from an appropriate language dictionary. I don't think we would want to create different language versions of the entire database - even though the approach is consistent w/WP. --jrm03063 14:44, 18 April 2013 (EDT)

I mean not a specific database for each language ! Only one database for genealogical informations. We need to translate the messages/titles ... Displaying in the user's preferred language is possible with Mediawiki. See this page. Between june 2008 and april 2011, I "worked" on Rodovid ... same tool ! Excuse my very bad english ! Amicalement - Marc ROUSSEL - --Markus3 15:10, 18 April 2013 (EDT)

Duplicating the database would be a bad idea - but that's the way that WP does it - so one does need to take notice. I'm all for internationalization, and certainly for using any support that's built in to accomplish it. Presumably, Special:Allmessages this page will look familiar. --jrm03063 16:35, 18 April 2013 (EDT)

Wikipedias in different languages are not duplicates of one another. Each is composed of either original articles composed in the language or articles which have been manually translated from one language into another. This is why most of the language-pedias have small numbers of articles. It's also worth to note that the content can differ dramatically for an article in one language versus another; there are few controls on the specific content for articles on the same topic across languages. --ceyockey 20:26, 18 April 2013 (EDT)

I get that - "duplicate" was an overbroad term. I understand that the different language-pedias have articles with their own history - sometimes even their own separate conclusions. By duplicate, I mean duplicate software, presumably the same save for internationalization. --jrm03063 22:18, 18 April 2013 (EDT)

Jrich i can accept my guesses are too high. I was more interested in the size of 'pando' for werelate purposes, and used ancestry figures to make a guess. I,d love to see some internal ancestry figures, particualrly the percentage of the various database records which have been linked. Has anyone found these anywhere ?--Dsrodgers34 00:00, 19 April 2013 (EDT)

Just as a matter of interest, has anyone contemplated the task were a group to systematically resolve all major source databases into the mythical 'pando' ?

A bit like we all seem to be doing with our chosen local areas - well some of us anyway--Dsrodgers34 00:03, 19 April 2013 (EDT)

As an example i have been attempting it with three parishes in england which translates to about 20,000 persons with about 45,000 sources so far. Ancestry tels me i still have 17,000 hints unseen ( half of them will be wrong) and im still working my way through the PRs. I have been at it for four years and still seem to be only half way through. I doubt i will add more than a couple of thousand more persons though. Youd have to have some kind of bots to resolve obvious ones and have humans decipher the complicated ones, to speed up the process--Dsrodgers34 00:11, 19 April 2013 (EDT)

Picking out databases to trust could be a problem. It's also an approach more apt to run afoul of copyright restrictions. "Bots" could be useful for identifying possible duplicates - but I don't think you would want automatic resolution. My interest is in trying to bring in various sources - which can then be systematically resolved against our existing database. It makes genealogy more like double-entry book-keeping. --jrm03063 13:42, 19 April 2013 (EDT)

Picking up on what jrm03063 said above about other projects using WeRelate data, I think this is an important step. I don't mean another project taking over, but rather the idea of making it easier to reuse data from here; of WeRelate becoming a central database (the "wikipedia of genealogy websites"; i.e. the go-to place). I absolutely love the idea of WeRelate.org being the central repository, off which can be built any number of things. This could mean that we include more "raw data", e.g. cemetery inscriptions, BMD indicies (intellectual property issues aside), so that the working-out can all be recorded here and sourced properly etc. I quite agree about it not being an automatic process — that's how the other big sites do it, and they get to be full of lots of wrong data.

I've been doing a bit of work on backing up my data from here, and it's not straightforward (the most tricky bit is probably retrieving the list of contributors for any given bit of content). It'll get better as the software here improves.

— Sam Wilson ( Talk • Contribs ) … 20:42, 21 April 2013 (EDT)

GEDCOM upload questions [17 April 2013]

I have a file that is the result of a study done on all the Jacksons in two cemeteries in what is now Nassau County, New York. This file is a bit different from the typical descendants file as many of these Jacksons are not necessarily related. I've capitalized the surnames of those actually buried in the cemetery (as opposed to their descendants found in census records). So will these unrelated-ness issues cause a problem if or when I try to upload a GEDCOM to WeRelate? Will the capitalization stay or be converted to mixed case?

This was started as a hope of connecting some of these folks who were all living in the same general area and all buried in the same cemetery. It was a fun project that overflowed to a second cemetery! By posting this to WR perhaps I'll find more connections. --janiejac 21:40, 16 April 2013 (EDT)

The capitalisation will be preserved, I believe, but long-term should be converted to proper casing. The goal is to be able to determine which of these people are buried in a particular cemetery, isn't it? I'm not sure that there are well-developed guidelines about how to do this (I've not seen anything), but perhaps simply using the category system for this would work? E.g. [[Category:Buried in <Cemetery Name>]] Hmm... although, that is rather double-entering the data isn't it? But without changing the software I don't think it's possible to do this sort of categorisation automatically. — Sam Wilson ( Talk • Contribs ) … 22:51, 16 April 2013 (EDT)

I agree that capitalization is not the right way to maintain this relationship. It's too opaque of a signal - no one else will know that's the reason you've left the names in all caps. If you add a Burial event to each of these people, and link it to the cemetery, then you could go to the "What links here" page for that cemetery, and see everyone buried there (e.g., this page). I agree that a category would also work, but what would be the reason for having a list of people with the same surname buried in the same cemetery? -- Jdfoote1 09:05, 17 April 2013 (EDT)

I realize now that my purpose for capitalizing some names was only for my own reasons and won't be needed at WR because the folks who have burial information will be matched to the cemetery. So I can create a new file with the names mixed case for uploading and that leaves only the question that there are a lot of folks not connected in a line of descent. I think the system can handle that.

--janiejac 14:50, 17 April 2013 (EDT)

Do you have uploads pending ? How much ? When ? [23 April 2013]

In the light of the recent growth discussion I thought it might be useful to take a quick survey to see if people have projects pending which are intended to be uploaded to WeRelate. So if you have do add a few notes

For myself my initial upload was for the parish of Holme in West Yorkshire, england. The original upload was just under 4000 people with about 7500 sources, mainly 1841 to 1901 census. I then realised the parish church served three parishes so when I started resolving parish records ( which are now all on ancestry) i added these parishes, cartworth and austonley, census and all.

Im still a couple of years away from loading into WeRelate, i find it more straight forward to resolve in my ancestry tree, but when i am ready there might be about 22,000 people with 55,000 or so links to sources. Of course 4000 will overlap with the tree i uploaded before, and perhaps other peoples contributions. If its another two years before i do this it will hace taken six years--Dsrodgers34 04:55, 22 April 2013 (EDT)

I have uploaded my own ancestry (largely complete), a surname project around my mother's maiden name (information largely 'built' on ancestry but then uploaded here) and a British nobility mini-project (entered directly here). I'm comfortable adding research directly to werelate as it is built, although do find it easier sometimes to do this on ancestry first, link in their census source information and information from other trees and then transfer it to werelate. Ideally I would like to be able to build a tree directly here - perhaps using information on FreeBMD/FreeREG/FamilySearch. AndrewRT 14:59, 23 April 2013 (EDT)

Idea for a source / transcript [23 April 2013]

Not sure about the rest of the world, but I know that many US States take the time and trouble to create markers for events of historical significance. I've seen a few used here on WeRelate (for example, Ninth Texas Cavalry). Being the work of the state, the narratives can't be subject to private copyright. I presume that they can safely be reproduced verbatim, with only the usual academic requirement of indicating where the quote was found. Perhaps, if you are lucky, your state will even have a site with discrete pages/headers for each marker, providing additional supporting research.

These markers often contain useful information about individuals. For example, the marker above relates to Micajah Bankston, which presumably is the reason that it was added.

If you live in a state, and love it's history, maybe you'ld like to create a complete transcript of the historic markers present in your state? While this is apt to be only supporting secondary-source information for well known people, it seems like it would add some nice color to Person pages that otherwise lack images or context. Grabbing a casual reader and getting them more intrigued or involved can only help us.

Anyway - it's an idea...

--jrm03063 10:53, 22 April 2013 (EDT)

Great idea, I reckon! Have you heard about the Open Plaques project? Perhaps we could integrate with that somehow. Or not, of course; it's not a complicated idea.

Would we create a separate source for each marker? With a separate transcript page and image? Seems the easiest way to then be able to cite individual ones appropriately...

— Sam Wilson ( Talk • Contribs ) … 22:11, 22 April 2013 (EDT)

Actually, I'm afraid I hadn't heard of that one, but the principles would probably be the same. My first thought was markers such as these. Doing the markers for a single state of interest, might be a lot more tractable, than something more extensive. For the case of the NH markers - I would expect to do a single source for the entire state - but I would also expect to create a transcript that had a single page per marker. The source page would get an extract from the WP page above, as well as indicate any State of NH web pages that provide further information. There would also be an entry that pointed to a top-level page for the WeRelate-based page transcripts. Individual transcript pages could be tagged with GIS numbers and/or a map, and indicate the highway markers of NH as their source. By breaking out the markers on a per-page basis, you can look go to referenced Person pages, then hit the "what links here" to get particulars for a cite. Pictures could be added of course, provided that someone felt they could take them or if they're available on fair use terms.

Not sure how brilliant an idea it is - but it's the sort of thing that someone with an interest could add - and that would benefit a group wider than normal. --jrm03063 00:23, 23 April 2013 (EDT)

One more thing - if someone really was interested - perhaps there's a really outstanding project to be done based on [[2]]. They seem to have searchable databases as well as GIS numbers and such. The US National Register also indicates whether a place was added based on a criterion, and criterion "C" is a person. It's a thought... --jrm03063 00:33, 23 April 2013 (EDT)

L O N G Wait [4 May 2013]

Do we really think folks are going to stick around when it takes this long to get a reviewed GEDCOM approved? I really wanted this to work but I feel like the system is broken. I guess I need to find something else to do.--janiejac 23:39, 1 May 2013 (EDT)

Is there something I can do to help? Please let me know... --jrm03063 09:24, 2 May 2013 (EDT)

Late Monday afternoon I finished reviewing the GEDCOM I had uploaded. I hit the import button and received the msg: "An administrator will review your GEDCOM shortly and finalize the import or contact you with any questions." Now it is three days later and the GEDCOM has still not be finalized or accepted. I feel like this is much too long to wait. By then folks, including me, have moved on to something else. If we want folks to stick around and review the new pages their GEDCOM generates, they/we need to be able to do it while the review is fresh in the mind. If there are not enough volunteers available to do this; then the site has a major problem :( --janiejac 11:49, 2 May 2013 (EDT)

I've never participated with that group or in that process. I just went to the appropriate tab, and I find some 18 GEDCOMs (apparently) pending review, but I'm not seeing one owned by you....does it have a name? --jrm03063 15:15, 2 May 2013 (EDT)

Someone apparently heard my plea. The GEDCOM has been finalized by WeRelate agent 13:19, 2 May 2013. I have no idea why it took so long. Thanks for your concern. I wasn't even aware there was a tab to go look at what's waiting. But knowing that wouldn't have helped since I'm not an admin and so couldn't have completed the process. I'm still of the opinion that this type of delay is a major put-off. . . Perhaps others don't mind. --janiejac 16:09, 2 May 2013 (EDT)

I'm not entirely sure you could see it, since it's on the "Admin" options... --jrm03063 17:03, 2 May 2013 (EDT)

Yes, non-sysop/admins can see the list of pending GEDCOms; the "Admin" menu is present for us and the "GEDCOM review" menu item on it does work. --Robert.shaw 14:24, 4 May 2013 (EDT)

Maybe, administrators in charge of GEDCOM approval should let the WeRelate community know that they are on holiday? Or a template message sent to GEDCOM uploaders to say there will be an unforeseen delay? --goldenoldie 16:56, 3 May 2013 (EDT)

An additional follow-up, I tend to agree that GEDCOM upload shouldn't be gated like this. This would be fine if there were lots of people ready to step up and perform the needed reviews, but I only see three admins that have signed up to do this. I've always been a supporter of a scheme where the size of GEDCOM you could upload would be a function of the number of hand edits you've performed. That admin involvement would only be needed if you wanted to upload more than your allowed GEDCOM size - or perhaps - if you wanted to perform an upload in spite if it having more than some threshold level of errors. Small GEDCOMs without many errors should be allowed without assistance. --jrm03063 17:09, 2 May 2013 (EDT)

Speaking of Volunteers [5 May 2013]

Does WeRelate have a policy about or materials that can be used in displays at local genealogy confereneces? I'll be giving a talk at our local conference this fall (with examples of "good genealogy" from WeRelate), but there is also a display hall, and I could ask for a table if there is something I could use to promote WeRelate. --GayelKnott 14:52, 3 May 2013 (EDT)

Hi Gayel, would you mind leaving a message on the Publicity talk page regarding this? Dallan has more information about available materials and we want to keep publicity related discussions in a central place. Thanks! --Jennifer (JBS66) 12:20, 5 May 2013 (EDT)

In Search of Madame Ihrig [7 May 2013]

I wrote a blog post about how I searched for one person - Hattie Chapin AKA Madame Ihrig - it's sort of an anatomy of a genealogy search. I list WeRelate at the bottom as the place I use to organize my information.

In Search of Madame Ihrig

I see that WeRelate has a new publicity project so I think I will try to compile people who are blogging about WeRelate. So let me know if you know about anyone.

Catherine dee Auvil : ) --cthrnvl 16:24, 5 May 2013 (EDT)

Interesting post! :-) I was wondering about Werelate bloggers the other day too. I'd love there to be a 'planet werelate' where they're all aggregated. Is there a page anywhere here for listing these things? (Not to confuse people searching for Blogs of course!) I sometimes blog about WeRelate:Printable-WeRelate and genealogy at http://samwilson.id.au/tag/genealogy/ — usually from a coding perspective. — Sam Wilson ( Talk • Contribs ) … 20:20, 5 May 2013 (EDT)

I will make a special page for bloggers at WeRelate and link to it at the publicity project. Thanks for the positive feedback : ) Catherine --cthrnvl 23:23, 6 May 2013 (EDT)

Maintenance pages' navigation bar? [7 May 2013]

Just wondering about adding a navigation right-side bar to all pages in the Maintenance portal. Something like {{Maintenance navigation}}. (But of course, not adding it to the portal page itself.) — Sam Wilson ( Talk • Contribs ) … 21:58, 5 May 2013 (EDT)

I really like this, nice job! I hadn't realized how much the pages needed navigation until seeing your example. You are more than welcome to add the template to the other Maintenance pages. Thank you for creating this! --Jennifer (JBS66) 07:21, 6 May 2013 (EDT)

Okay, done. :) — Sam Wilson ( Talk • Contribs ) … 00:43, 7 May 2013 (EDT)

Categories [6 mei 2013]

I understand the category name and surname location not match, the bottom of the page, but they are also as hidden category no longer made​​? So a new person Person: Magdalena van Beeck Calkoen (1) is not automatically added to

• Category: Van Beeck Calkoen surname
• Category: Van Beeck Calkoen in Netherlands

When this feature is no longer there, also there will be no more Surname: .... because Surname: Van Beeck Calkoen has no function.
Also Category: Surnames in the Netherlands and Category: Surname in place loses its function A red link was perhaps not beautiful, but it did have all his function and was using.
Search is a tragedy for me and probably not just for me. I often used it, it gave me too many useless / confusing information. (I used the advance continuously in the categories to come) The categories of information brought sorted / arranged together.
In the old search function FamilySearch did not much excess ballast.
Like reaction. --Lidewij 04:11, 6 May 2013 (EDT)

PS.If you want to have surnames in a category you must create them yourself. Now these are not automatically in a category, but over time, the categories created automatically disappeared. --Lidewij 09:04, 6 May 2013 (EDT)

Why have surname categories disappeared? [13 May 2013]

Why have surname categories disappeared from person pages and family pages? I have found them very useful and I have not found any discussion about removing them. What is going on? --Susan Irish 12:10, 6 May 2013 (EDT)

Over the last couple of years, Dallan has suggested removing the automatically-generated Surname and Surname-in-place categories. In February there was also a discussion here on the Watercooler about some of the problems WeRelate has been experiencing with these automatic categories. Some of these issues include: they caused confusion for many users, they were only generated at the Country level outside the United States, they required administrative time for their organization/development/management, they could not be edited, and users have complained about how they were sorted. Overall, Dallan believed their function could be better served by the current (or improved) search features.

The Overview Committee discussed this more in depth and decided the automatic categories should be removed. I did not have the details about exactly when or how that change would take place until yesterday. The first step is that Dallan has removed the automatically-created links on the bottom of pages. The next step will be to remove the links under Category:Surname and Category:Surnames by country. If anyone has specific examples of how the search function can be improved in light of these changes, please do let me know. --Jennifer (JBS66) 13:13, 6 May 2013 (EDT)

Manually create the categories at people costs, I think, much more time than just making the categories. The advantage is that people can now come in the category by first name.

First we thought it was a problem that links were red. Now there are no links, sorry the surname statements are immediately gone. I found that everyone with the same surname, could be found in the categories one of the strong points of this site. Now I want to first rethink whether I want here further.

With search, you should know what you want. The advantage of categories is that surprises you encounter that you were not looking.

Susan, really consultation has not been there, some have expressed their views. A poll I have not seen.

Susan, if you want to capture something you should do that now. The saved pages can then be used to quickly between people clicking. The categories are now only filled with sources and images. --Lidewij 17:37, 6 May 2013 (EDT)

While I am no fan of Categories, I think that Lidewij raises a valid point - there is no convenient way to browse through WeRelate unless you have a fairly good idea what you are looking for. So Jennifer, I will suggest some enhancements to Search criteria and results:

1) Provide a single Search query to return Persons, Families, Sources and Pictures. Provide check-boxes for each of these categories of results.

2) Provide the ability to filter Search results by kinds of fact, dates of facts, surnames, locations, etc.

3) Provide a convenient way to sort and then browse through the results of a Search.

4) There was talk sometime ago about adding a Faceted Search facility. I strongly endorsed that idea then and I think you need to seriously consider it now.

I still maintain that a better interface for searching and browsing would take most of the steam out of the Categories debate. --Jhamstra 20:23, 6 May 2013 (EDT)

In the discussion last February there were people who said they found the surname categories useful, while many objections seemed to be more theoretical than practical. The argument hat they caused confusion for many users as a reason for their removal would suggest that we also remove the place field for events, since this also clearly causes confusion for users who enter such things as birth dates, cause of death, names of family members, etc. in the place field. The problem of demand on Administrators time would seem to be more valid. I know it's hard to get people to volunteer for routine maintenance, but if more did volunteer, would this help?

I agree with both Lidewij and Jhamstra, the Surname in Place Categories did provide a convenient way to browse. I also agree that there does need to be some way to browse, and the current Search function does not serve this purpose. I tried using person search with just a surname and a birth location, which gives pages and pages which have to be read (with eyes slowly blearing) rather than quickly scanned. And, you can search only for birth and death, not marriage or residence. So the Search function does not serve the same purpose. The problems trying to browse or search for Sources using name and place are even worse.--GayelKnott 02:10, 7 May 2013 (EDT)

"The Overview Committee discussed this more in depth and decided the automatic categories should be removed. I did not have the details about exactly when or how that change would take place until yesterday." --Jennifer (JBS66) 13:13, 6 May 2013

And the rest of us ordinary users knew nothing about the change until Lidewij brought it to our attention yesterday. Is there a place where the decisions of the Overview Committee are announced? Do we get email advices about them? ----goldenoldie 02:53, 7 May 2013 (EDT)

I would like to make a suggestion based on the information provided in this post. I embarked on a personal project to attempt to bring pages upon which I landed, whether accidentally or on purpose, closer to the standards which have already been established on this site. The categories at the bottom of the Family and Person pages helped greatly in this endeavor as they glaringly indicated something was not following the standards and would lead to other pages with the same difficulty which could be remedied. I understand the categories are gone, not to return, but I'm afraid using the search engine provided on this site to do as I've been doing is not as intuitive, nor can I determine if there is a way to improve the search function to allow for this project to continue in the same manner.

Therefore, my suggestion is that the Categories page remain entirely intact to help facilitate finding the problem children. Perhaps it could be renamed or reused for this type of endeavor. If this is not possible, are there suggestions from other users which might accomplish this same project in another way to which I am ignorant?--Khaentlahn 07:46, 7 May 2013 (EDT)

I spent a lot of energy to create categories, because I think it is important. The category has a different effect than search. I'm generally ample time warned that there was no assurance that these categories remained.

When I stay active, I took the family, that my interest, add the full categories. Manually entering a category provides better quality. (The categories can I start entering the gedcom) I also use these categories to see what people are newly added. (compare an old store category pages) I also hope, by categories, to connect with people, who at the same surname search

The category indicates the connection of everything associated with that name. Visitors search for people (surname), not on the page of users. When I want to know, what is a family here present, I always look at the category. Only when I encounter in finding people with the same or similar first and surname, I use the search for a wider picture. In the category I see at a glance more than 40 couples a few cm2, always in the same order. Here I find what I'm looking for quickly. Nothing typing, but a single click. Without that I was looking for I see that there are no sources or pictures with a surname. (sometimes a catch of own ‘familie' foto's). In a single click I see the global spread of a surname

Category:Mol surname the family’s in an orderly row

Familie mol Werelate Search What find a visitor, relevance, page titel ??, date last modified ?? The first three are my work. What comes after it is no Mol

Only when entering a surname, the only concrete

Categories will come, even if they are not created automatically. It will take some time before the backlog is cleared.

Categories provide an opportunity for rapid control and bringing together interested parties in the same surname.

In genealogy everyone works in his own way, with its own goals and find that way of working minded alike. The families are now categorized manually will probably be checked for accuracy.

The gedcom that are bad are no longer up. That did happen during the making of the categories.

--Lidewij 08:53, 7 May 2013 (EDT)

Like others, I don't really use the Categories much, and I don't disagree with the decision to get rid of them. However, I think that this is a good time to rethink the way that the Overview Committee works. The fact that none of us knew that this decision was coming is a problem. I have no problem with having a committee of people generous enough to take their time to think about how to improve WeRelate, but I think that their meetings and decisions need to be more transparent, so that we know what they are talking about, and have time and opportunity to comment on decisions before they are implemented. -- Jdfoote1 08:57, 7 May 2013 (EDT)

Regarding the discusssion in February, I made no comment because I did not object to removing the automated category, the red links. However, I do object to the removal of the manually entered surname categories that I and others have worked countless hours on. So if one manually enters the surname category again will that also be removed? My time is too valuable to be wasted.--Beth 09:06, 7 May 2013 (EDT)

Beth, by manually entered surname categories do you mean pages like Category:Coleman in North Carolina? That category will be empty because none of the 17 pages contain the "Coleman in North Carolina" category any longer. If I do a search for Surname=Coleman Place=North Carolina "Exact match only", I get 17 pages, the same exact pages that appear in the category. If I search for Surname=Coleman Keywords=North Carolina instead, I get 54 pages - more because Coleman appears somewhere on the page where an automatic category would not have been generated for it. These searches show all of the namespaces but can be further filtered to show just Person or Family pages. --Jennifer (JBS66) 09:59, 7 May 2013 (EDT)

Coleman in North Carolina is not empty, there are, among other sources.

I get pages - more Coleman, that should not fall into the category of Coleman in North Carolina, what I saw was a pity about the time of the click and watch. --Lidewij 10:47, 7 May 2013 (EDT)

To me you have thrown out the baby with the bathwater, while I only understood that you were throwing out the bathwater. See Person:Absalom Anderson (2). This page now has no category. However this person is still on the category page Category:Anderson in Mississippi but now there is no link. --Beth 10:32, 7 May 2013 (EDT)

What you see is the cache (temporary memory) when you edit the person or touch it disappeared--Lidewij 10:47, 7 May 2013 (EDT)

That is correct, the pages currently do appear in the category. As I mentioned above "The first step is that Dallan has removed the automatically-created links on the bottom of pages. The next step will be to remove the links under Category:Surname and Category:Surnames by country." The links that appear in the categories now are essentially phantom links. Dallan needs to run another process to refresh the categories. Refreshing the categories will clear out pages that no longer "point" to them (meaning since the pages no longer have categories on them, they would not appear in the category).

Beth, your first comment was that you don't object to removing the automated categories (of which many were red-links) but you do object to removing the categories. Then, I mentioned that you can find the same information from a search. I want to understand better how the data from a category was better for you than the same information in a search? --Jennifer (JBS66) 10:54, 7 May 2013 (EDT)

This shows just how hot this topic is. While I was trying to put exactly what I wanted to say on the editing screen, another posting was made, and what I had carefully thought about disappeared.

Would the Overview Committee now look to editing Help:Categories, removing all reference to Categories: Surnames in Places, and making sense of what remains. Over the past year I have read over the topic a number of times and have always come away feeling that I did not understand.

The word "browse" has been used by a number of contributors to this discussion. We want to look around WeRelate and see what others have contributed. Searching is browsing with blinkers on. Can't we look around for morsels of information that might be an arm's length away (or, in genealogical terms, find a part of a family that was hiding on the other side of the nearest hill)? A month ago I suggested that we consider looking at places first, and surnames afterwards. There are all sorts of ways to spell a surname and one part of a family (or the person who wrote down their name) might adopt a different way than the part we have been looking at. Search engines are dependent on alphabetical characters, not on the sounds of names. To look at a variety of surname spellings within one small geographical area of the world may bring out all sorts of interesting considerations. Believe it or not, literacy for the general populace came earlier for the United States than for other parts of the English-speaking world. Families that did not all migrate together could lose touch and never find each other again. ----goldenoldie 10:40, 7 May 2013 (EDT)

@Goldenoldie, When an edit conflict, is at the bottom of your written text. So it was not gone.

Finding variant names via a Search is much better than through the use of categories. Categories did not take into consideration variant name spellings - search does. You said "Search engines are dependent on alphabetical characters, not on the sounds of names." Dallan has already incorporated the WeRelate:Variant names project into search results, so that when I search for Swart, I also get Zwart, Stewart, Schwart, Zwarts, etc. and I can limit that by a location. If I don't want to look through these variant names, I can choose "exact match only". Perhaps having an option to make the display more compact (ie, a checkbox to hide the husband, wife, marriage/birth date, children information) would be helpful? --Jennifer (JBS66) 11:07, 7 May 2013 (EDT)

I cannot explain why I prefer the category to using the search engine but I do. I do not know why we cannot have both options. I have no objection to removing the automation but as I previously stated I had no idea that the Overview Committee intended to delete countless hours of work by many volunteers. The Anderson link was not red. Anyway you have answered my question. There is no use in me manually reentering the category because it will be deleted. Does the Overview Committee plan on deleting all categories?--Beth 11:17, 7 May 2013 (EDT)

There is too much focus on the search. Search is a conscious action. On wikipedia you search. Yet one uses categories. Categories belong to the wiki. To connect topics together there are the categories on these pages you go leaves. These are useful when you are unable to search.

I assume that the categories that were made and to be made, even when some time will be empty, will stay ??? --Lidewij 11:25, 7 May 2013 (EDT)--Lidewij 14:41, 7 May 2013 (EDT)

No, these categories will not stay. It would not be beneficial to keep some of the categories because they too will be empty once the cache is cleared. All of the categories of the type Surname and Surname in Place, that appear underneath Category:Surnames and Category:Surnames by country will be removed. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

---

"Perhaps having an option to make the display more compact (ie, a checkbox to hide the husband, wife, marriage/birth date, children information) would be helpful?" --Jennifer (JBS66) 11:07, 7 May 2013 (EDT)

Compacting the display would help--a default limit of 20 people on a page when there is a possibility of thousands doesn't get one very far very fast. Reducing the number of supplementary facts and placing them to the right would save space as would removing all but the original User. Frankly I did not know that the search engine covered such a wide field. Having started this afternoon putting "Help:Category" in the search box and come up with nothing made me skeptical. ----goldenoldie 11:59, 7 May 2013 (EDT)

"@Goldenoldie, When an edit conflict, is at the bottom of your written text. So it was not gone."

I looked, and didn't find it. ----goldenoldie 11:59, 7 May 2013 (EDT)

I am uncertain what needs to be done with the search function to alleviate the following example, but I bring it to your attention for just that purpose:

Original category that needed some work: Seaver in VT

First individual on the page: Elizabeth Seaver (23)

Initial search for Seaver (using Exact and Close) in Vermont produced 357 people, but I did not find her listed. While there are others in this search that clearly show VT for Vermont, I did not find her. (If that was an oversight on my part, I apologize, but I made a good effort to find her.)

More specific search for Elizabeth Seaver in Vermont produced 21 Elizabeths (or variations thereon) and Elizabeth Seaver (23) was still not listed. I needed to remove Vermont for her name to appear in a list of 385, which included quite a few individuals who were not Elizabeth in any way. Narrowing it by Exact (as opposed to Exact and Close) brought the list down to 70, but then obviously name variants are no longer present. If there is a fairly painless way to repair the original search oversight, that would be fabulous.

Interesting side note, if I attempted to create another page for Elizabeth Seaver with the same basic information, and I used only Vermont as the place of birth, Elizabeth Seaver (23) did not appear, but if I expanded it to Manchester, Bennington, Vermont, United States, she does. I am uncertain why the City/County designation will bring her forward, but not the state. (And, no, I didn't create another page for her. :D) I hope this helps!--Khaentlahn 12:12, 7 May 2013 (EDT)

Addendum: I wish to note that this example is not a singular instance and I'm afraid editing Elizabeth Seaver (23) did not correct a similar issue with other pages which I'm afraid also fail the search engine test. Can we expect the search engine to be modified or will we need to figure out which pages are broken and fix them manually? I'm not vested in either instance, I would simply like to know how to proceed.--Khaentlahn 16:40, 7 May 2013 (EDT)

The reason Elizabeth Seaver (23) could not be found in a search is because the place was not properly formed and was red-linked (the page said Manchester, Bennington County, VT). Since the word Vermont did not appear on the page, you could not find her page by searching for Vermont. You did find her by searching for Manchester, Bennington because those terms did appear on the page. Elizabeth's page has since been edited to correct the place, so you can now find her by searching for Vermont. If the place on her page had been "piped" with an alternate name like Manchester, Bennington, Vermont, United States|Manchester, Bennington County, VT - the place would not be red-linked. In this case, even though VT is shown on the display, Vermont does appear on the page and will be found in search.

The question about how to find red-linked places on pages that need fixing is a good one. I will ask Dallan about ways to accomplish this other than using categories. In the short-term, when cleaning up places like this, I use the What links here page. First, I will see a place that needs fixing (like on this page) and open the red-linked place in another tab. Then, on that incorrect empty place page, I'll click on "What links here". That will display the other pages that refer to that place. I usually fix the Person pages first, refresh the browser view, then fix the remaining Family pages. The reason is that, many times, the error on the Family page will be resolved by fixing the connecting Person page. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

I was aware of this situation prior to posting this example and my addendum question, though I am grateful for your description for those who were not. I realized that I did not phrase my question properly to communicate what I was asking. Can the place names that are not piped by the automated system, the ones that maintain broken places, be included in the basic search or will we need to repair these before they will be seen by specific searches? Though that had been what I was attempting to communicate, my brain shoved it a step further. Can the search be modified so that, as an example, when someone is searching for Vermont, the search also displays VT hits? Since the search brings up surname variants, can it not bring up typical place variants? Also, I am aware of how to find the red linked place names without the Categories, I simply wanted to know whether they will need to be fixed before the search engine will show people where they belong or if the search would be modified.

A minor comment on the order of repairing the broken places on Person pages, I would suggest repairing the Family page first only if the broken place name in question is where the marriage took place. For some reason, if the marriage place on the Family page is repaired after the Person page has been changed, though it will appear changed on the Person page's marriage line, the system still seems to connect the Person page to the broken place until the Person page has been opened and saved a second time.--Khaentlahn 09:28, 10 May 2013 (EDT)

Regarding your Vermont/VT question, I think this already happens for the non-red linked places. If I search for Massachusets in the Place field (listed on the Massachusetts page as a common misspelling), it returns MA and Massachusetts pages. The red-links are a different problem. Since they are not linked to a place page, they don't take advantage of the alt-names for that place. I wonder if a report, generated weekly, for pages that contained red-linked places might be useful. --Jennifer (JBS66) 16:26, 12 May 2013 (EDT)

Simply for clarification, are you referring to Special:Wantedpages, which is generated each week? It does not contain strictly Place red links, but that appears to be the main page type listed on it. Or at least something similar to it?--Khaentlahn 07:46, 13 May 2013 (EDT)

Khaentlahn is making an important point -- things can (or could) be found using the Surname in Place categories that likely aren't going to found any other way. Among other things, I found Henk's Groninger Emigranten/1892 article through the Knot in Netherlands category. I would never have found it, otherwise. Similarly, my Scott DNA Family in Georgia, Maryland, and North Carolina article also appears in Surname in Place categories, which gives it at least a minimally better chance of being found, I would hope. Neither Article will appear in a Person search, nor do images. (Nor do Families.)

And yes, if I search All, with Knot for surname and Netherlands for Place, Henk's Article might show up -- in the 21 pages I would have to read through in order to find it. This, I think is part of the point that Lidewij is making. Not likely that I will read through 21 pages just to see what's there. (And Knot is not a common name in the Netherlands -- I shudder to think of how many pages might show up for a common name using All to search.)

It's clear that several people have put time into working with the Category pages, because they find them useful. Being able to condense the results of a Person search would certainly help, but would still not help with other uses people make of the Surname in Place pages.--GayelKnott 23:46, 7 May 2013 (EDT)

Category:Knot in Netherlands is a relatively small category. As it stands, items are sorted by Namespace first, so you would need to overlook all of the F's and P's to find an article of interest to you. Categories become much more unwieldy as they grow, and the likelihood of being able to stumble upon an interesting article is much less likely. For example, you'd need to click (next 200) 26 times to stumble on the Genghis Khan 1853 Voyage to Australia article in the Brown surname category. A search of Surname=Brown Namespace=Article yields 24 specific results. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

I agree with Beth - they've thrown out the baby with the bath water. Just because some people don't use categories is no reason to eliminate them from the folks that do use them. I have not seen an announcement that would clearly state the reasons for this change, why it would happen and what would be affected by the change. Are ALL categories eliminated or only those generated automatically? What about the categories that we have manually added to each page? Will they go away too? I'm grieving for the future of this site. --janiejac 10:36, 9 May 2013 (EDT)

No, ALL categories will not be eliminated. The automatically-created Surname and Surname in Place links that appeared at the bottom of pages were removed. Often times, these were red-links and category pages had not been created for them yet. Those that had been created (ie the categories that appear under Category:Surname and Category:Surnames by country) will be removed because they will be empty once the pages are "refreshed". Categories such as Category:U.S. Presidents and Category:Founders of Newport, RI will remain. --Jennifer (JBS66) 08:39, 10 May 2013 (EDT)

I have not read through everything in this thread, but I do perceive that most of the people writing are objecting to the change. I have invested heavily in the creation, revision and application of categories over time (if you look at my contributions, you'll see long stretches of edits with the comment "categorized", for instance). However, I am quite willing to accommodate the present change and give it a chance. Any change of this kind is disruptive, but the value of the end product might be greater than the original state. Consider the deficits in the search vs. categorization -- what changes to search or indexing would improve the search (or presentation of results) so that the result would be _more_ useful than categorization. The first thing that comes to mind is faceting based on country; presently search results are not faceted and introducing even the most minimal faceting would be a great improvement. In other words, let's live with the change and seek to suggest (or implement) changes in remaining aspects of the interface which yield a superior product. --ceyockey 20:43, 9 May 2013 (EDT)

I am befuddged by the reasoning or lack thereof behind this! I am not a programmer and so do not understand why categories have to be removed before we can improve the search function!! Why not improve the search FIRST if you think that will eliminate the need for categories?? Now we have neither! Sounds like this was planned by a committee . . . And by the looks of the suggestion page, Dallan doesn't have time to work on suggestions for search anyway. . .:( --janiejac 10:48, 11 May 2013 (EDT)

I've created a suggestions page for assembling ideas to make search more robust and to enhance the display of search results. For those unfamiliar with faceted search, I want to provide an example of this idea in action. Let's say that I'm searching for an area rug for my home and I look at the Kohl's website. On the left, there are filters with numbers in parentheses. I can filter the results in these ways. I want a 4'x6' rug so I click that box and the results are filtered. Then, I can say I want an orange rug, and the results are further refined. Maybe those are not enough options for me, so I can unclick the 4'x6' and just see the orange rugs. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

First we throw overboard the automatically created categories and then we think if we can make a good search system.

Understand an English text through the google translation is a crime, search the genealogy through the furnishing of a house is even worse. --Lidewij 10:44, 10 May 2013 (EDT)

Faceting which is relevant to genealogists (to assuage complaints raised by the home furnishings example): go to http://search.ancestry.com/search/ and do a search. Look at the left hand panel. All those links like "Military" are facets; and under "Military" there is, for instance, "Casualities" - another facet. For the place-oriented categories, replace this with a continent/country/subdivision facet set. We already have some faceting; do a search via the open box on the front page of this site - voila, on the left are facets covering the different page types used here. --ceyockey 17:41, 10 May 2013 (EDT)

Dallan will be implementing a new option for condensed search view tomorrow. There will be a new Search checkbox, next to the results per page drop-down. Selecting this box when running a search will display only page links (with full names as they appear in current search results). Other information such as who is watching the page, when it was modified, birth/death information, etc will not be displayed. Also, the default number of results will be 200 for this condensed view.

Lidewij left a suggestion regarding the use of wildcards. As a side-note to that, I wanted to say that wildcards currently work in the Given name and Surname fields. So, if I search for Jon*, I get pages for Jonathan, Jonas, Jon, etc. The * takes the place of multiple letters and ? takes the place of one letter. There must be at least 3 letters before a wildcard. --Jennifer (JBS66) 18:52, 12 May 2013 (EDT)

Category:Surname and Category:Surnames by country [11 mei 2013]

I assume that the categories that were made and to be made, even when some time will be empty, will stay ??? --Lidewij 11:25, 7 May 2013 (EDT)--Lidewij 14:41, 7 May 2013 (EDT)

No, these categories will not stay. It would not be beneficial to keep some of the categories because they too will be empty once the cache is cleared. All of the categories of the type Surname and Surname in Place, that appear underneath Category:Surnames and Category:Surnames by country will be removed. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

I have the situation since May 7 as viewed.

• Category: Surname XXX will never be empty. This is filled with Surname: XXX, sources Surname: XXX and User: xxx'.
• Most Category: Surnames country are not empty, they are filled with sources, image/photos and user names. Furthermore all kinds of other things that came up users.
  Some category will be empty for a moment but will still be needed within a few years. It would be a big mistake to temporarily remove these handmade categories. --Lidewij 10:30, 10 May 2013 (EDT)

These categories will be empty and thus removed. The Surname and Surname in Place links no longer appear on Source, Image, or User pages so what you are seeing are cached versions. --Jennifer (JBS66) 12:48, 10 May 2013 (EDT)

I had not seen that the sources were also without category. How unhandy can you make? I understand that the images are no longer linked. What a breakdown? Remains user and surname? There is not much left of what I found here good quality for a genealogy site.

Category:Andersson surname Surname:Andersson --Lidewij 13:25, 10 May 2013 (EDT)

Lidewij, I do realize that you are frustrated. There are multiple stages to this process, and I can only assume Dallan has not yet had time to remove the categories from Surname pages. In the event it was an oversight on his part, I will remind him that these too will need to be removed. --Jennifer (JBS66) 13:37, 10 May 2013 (EDT)

Is not productive! Productive I was many, many hours. (>10.000 cats. Now all turns to nothing) I understood that only the categories under the people might not materialize. (That might be better manually, in an additional category) But because these are very useful also for the sources, I see the point. Especially with the sources it is useful to see this at a glance.--Lidewij 14:01, 10 May 2013 (EDT)

Better turned in half, then completely lost.

The categories were removed under the pages because there was not enough interest to make the red link. Yet there are > 20,000 categories created by some people in a year. There are not many red categories with more than 100 items. When there is not enough interest is to make the simple categories, what do you expect for making the places. At the next step, also places no more linked? --Lidewij 16:24, 10 May 2013 (EDT)

When the sources are not categorized by the surname, these rarely or not found / seen /used. --Lidewij 09:54, 11 May 2013 (EDT)

News on the main page of the site - needs an update [15 May 2013]

Hello -- I think that the current news item on the main page should be replaced with a news item related to the elimination of auto-created categories and the availability of a suggestions page for enhancing other features of the site to overcome perceived and actual functionality that this elimination has and will lead to. Thanks for considering this. --ceyockey 20:44, 15 May 2013 (EDT)

Search Update [16 May 2013]

How often does the search update? Basically, when a change is made, roughly how soon before it will show up changed in the search?--Khaentlahn 09:28, 16 May 2013 (EDT)

New Browse Feature [16 May 2013]

Just saw a new "Browse" function under the "Watchers" on one of my pages -- very nice, and many thanks. I'm assuming it will eventually show up on other person and family pages as well. This should serve the needs of those people who like to browse, and looks much nicer than the old Name in Place Categories on the bottom of the page. Again, thanks. --GayelKnott 09:57, 16 May 2013 (EDT)

Did some exploring and found a useful source. Very nice.--GayelKnott 10:31, 16 May 2013 (EDT)

So this new Browse feature is a good idea (if I say so myself 8-). But it is rather flaky in its current form. For example if I go to [3] then I see Browse but if I go to the same Person without the diff [4] after I did a minor edit then the Browse feature evaporates? Also I would place it above Watchers rather than beneath. Still - this is real progress!--Jhamstra 15:55, 16 May 2013 (EDT)

This seems to be a very interesting bug? When first I click on a different page from any URL the Browse feature seems to appear. BUT - whenever I go back to the same page in the same session (via URL, browser Back Arrow, etc) the Browse magically disappears? I have tried this now with several different Person and Family pages with pretty consistent results. Dallan - you might want to look into this? Maybe some inconsistency between the cache and the underlying database? or ? --Jhamstra 16:09, 16 May 2013 (EDT)

I agree, very nice feature. Decidedly faster than invoking the Search page (which is slow on my computer) and using the "compact results" option. A bit frustrating when the Browse tool is not present or disappears from the sidebar. --Robert.shaw 16:30, 16 May 2013 (EDT)