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.
Old topics have been archived at WeRelate talk:Watercooler/Archive 2007 and WeRelate talk:Watercooler/Archive 2008.
I don't know about others, but I just HATE to see places appearing in RED when I upload a gedcom. Since my database contains thousands of places it just is not reasonable to edit all of them within my software... Thus I have for example: Tiffin, Seneca Co., Ohio. This is how I do all my places. I do not have a country for even one place that is in America. As long as my places are in red, my pedimaps don't work.
So all my places are appearing in red, OK, so I thought if I would take for example, Seneca Co., Ohio and put in a redirect to Place:Seneca, Ohio, United States that once I did that all the towns I have listed in that county would then match up and be OK, cause the name of the county and state would be "blue" now. I am not finding that to happen. I just had to redirect the city of Danville to Place:Danville, Knox, Ohio, United States; even though I had previously redirected my Place:Knox Co., Ohio to Place:Knox, Ohio, United States. Is this a bug, or am I doomed to create a whole LOT of redirects?? --Msscarlet1957 00:39, 1 February 2008 (EST)
The place matcher doesn't work very well right now. Improving it is part of re-doing the search function, which is the next thing on the agenda. Once we have the place matcher working better, we'll go through everyone's pages and re-match red places. There are nearly 2 million pages that we need to go through, so the re-match process will take about three weeks. So if you can wait until mid-March, most of your red places should be matched by then. In the meantime you'd need to go through every place and redirect it :-(. (That's why we're working hard to improve the place matcher in the future :-).--Dallan 13:11, 1 February 2008 (EST)
Go check out Q's talk page. We are working on a new concept for a surname exchange page and we could use your input. I beta tested FTM's latest program and was incensed then as you are now because all of my places created error messages in the new program because I used county and did not use USA. After a year or so I have gotten over it and am now prepared to update to the new version of places. (not FTM) I believe that this is actually a function of Google maps so you need to complain to Google. Google maps does not recognize the county. If I recall correctly there is some method on WeRelate to designate city or county when the same name has been appended to the county and city in the same county. At least I believe it is Google maps but may be some other mapping program; but that is why there is now a new format for entering places and I believe that more programs will start using the new format.--Beth 20:57, 3 June 2008 (EDT)
As Beth suggest to me earlier, perhaps the conversation on my talk page should be more public. It threatens to get too long for this space so I'll create a space for it at Talk:Surname Research Pages
I'm working on the new place matcher right now as part of the new search functionality. I'm hoping to have the code finished in a few weeks. It's taken much longer than expected, but I think it will be a big improvement when it's finally ready.
Regarding counties vs. cities, the standard at WeRelate is that counties are listed under the state without the word County, and cities of the same name are listed under the county. So Los Angeles city is Place:Los Angeles, Los Angeles, California, United States. If you see a place "X, State, United States", you can be pretty certain that X is a county. The standard isn't driven so much by Google Maps but by how FamilySearch and some of the other place databases that I reviewed work.
Once we get the new place matcher working we'll go through and re-match everyone's places. The new place matcher won't change the text you entered, but will do a better job of linking your places to existing places in the database by dropping "Co." among other things.--Dallan 13:45, 4 June 2008 (EDT)
Dallan, now two months later, how is is the place matcher working? I am still having to do a lot of redirects to get my places to NOT be red. Another question, when I do a redirect on my "misfit" places do I have to put checkmarks in the boxes beside the trees to add that to? Sometimes I remember to do that and sometimes I don't. What is the reason for the boxes beside the trees when editing places?? --Msscarlet1957 22:46, 30 July 2008 (EDT)
Since the new search functionality was installed we've reviewed thousands of places from various GEDCOM files to make sure that the new place searcher standardizes them correctly. As of two days ago, everything finally seems to be standardizing the way you would expect. During this time the GEDCOM uploader has continued to use the old place matcher. We expect to switch it to the new place matcher this weekend. After that, if you find places that aren't being standardized correctly, please let me know. Also, later this Fall we plan to add quite a few additional non-US places.--Dallan 01:32, 1 August 2008 (EDT)
Have just done my first merge, but there is an interesting side effect. Once the merge is complete (and there are still two entities existing, but one has been edited to redirect) and you have FTE open and you do a search for the individual in question and you click on the individual that has been redirected, the following results:
the proper page comes up (right side frame), but the FTE (left side) has a blank (shaded) box and it shows the clicked-on individual (the one with the redirect) at the top of that frame. If you mouse over the box, it also shows the clicked-on individual (the one with the redirect) in the mouse-over text.
If you want to see, search for People and Families with the values Benjamin and Knowles (my g-grandfather). There are many results. The two for the example are Benjamin Knowles (5) and Benjamin Knowles (6). I have merged these two persons into Benjamin Knowles (6) (which I added to WeRelate). If you click on Benjamin Knowles (5) in the search results, the correct person (Benjamin Knowles (6)) comes up in the right-hand frame, but the behaviour I've described above obtains in the left-side FTE frame.
Also, I would like to make a plea that search results are ordered by Person first, then Family. I get both Benjamin Knowles (6) and Benjamin Knowles (5) on the first page of search results (although they are not at the top). It doesn't seem right that I have to go to the third page of search results to find Benjamin Knowles (2)!
--Slknowles 14:43, 30 April 2008 (EDT)
Yes, merging pages while the FTE is open "confuses" the FTE - that's a known bug that I need to repair.
The new search will have three sort options:
The last option should work for what you want to do.--Dallan 14:05, 3 May 2008 (EDT)
Another merge question: I've found a duplicate family of one I uploaded. My family page is titled 'David Jackson and Jane Carlock'. But the author of the duplicate family has added her married name to the title 'David Jackson and Jane Carlock Jackson'. Looks to me like this author hasn't updated anything for a year. I can't just edit his page to change Jane's name to Jane Carlock. They are both #1. So should I try to redirect his page? This couple has a LOT of children. Do I work from the bottom up or the top down? I'm not sure if I should try to do something with this or just wait until the merge feature is further along. But waiting is my choice! --Janiejac 20:46, 24 July 2008 (EDT)
The value in performing a merge is too great to wait. The result is the union of the contents of the contributing pages and a page that explicitly has the watchers of both contributing pages combined. It's a defacto call for input on the subject of that page because everyone is going to be noticed of the modification by e-mail. Since this is a wiki with history, nothing is ever lost anyway, so discussion can evolve as needed subsequently.
I've performed several thousand page merges. From time to time someone disagrees with the results, takes an interest, and changes the layout - but the result is a refinement of the merged page, which is precisely as it should be. That is also an extremely rare event - figure less than 1%. The only time that we go back to separate pages is in the really rare event that a merge is found to have been incorrect (which again is as it should be).
There's also a practical consideration - who do you wait for and how long? Take a look at the watch lists on any of the Pilgrims - Person:Stephen Hopkins (2) and Person:John Alden (1) for example.
Merge. Always merge. Merge immediately. If you don't want to do the heavy-lifting of merging pages, at least put a very clear notice on both pages that indicates the other as a merge candidate.--Jrm03063 21:42, 24 July 2008 (EDT)
Hopefully I'll have the match and merge functionality for merging Person and Family pages ready in about a week.--Dallan 18:31, 29 July 2008 (EDT)
I'm starting to see folks critically working over some of the genealogy that I've been (more or less) mindlessly merging over the last couple of months. It's actually gratifying to see results that I merged from several contributors critically reviewed edited by others. I have a minor suggestion though.
I've started to think more about the question of how to represent discredited, improbable, and flat out wrong stuff. I've tried to do it up to now using "Note" fields in the appropriate person or family pages, but that may not be sufficient in cases where finding and proving an error is a research effort unto itself. Should we adopt a convention of putting a section, immediately prior to sources, where we'll put such stuff? I'm trying to think of a good name for it, but am not satisfied with anything - "Dubious Genealogy", "Common Errors", "Probable Errors", etc.
Am I out in front of the curve on this? Does anyone want to suggest something?--Jrm03063 18:54, 12 June 2008 (EDT)
Perhaps the approach that could be taken here is to include a section in the article entitled "Alternative Interpretations". There different perspectives on the subject could be discussed, coupled with the evidence for and against whatever the issue was, with out applying a divise label. Q 02:49, 13 June 2008 (EDT)
I had no idea this would be so sensitive! Still, I'm seeing the perspective from both sides. I think most of the information I'm talking about is accepted as discredited, but there's no sense alienating folks either. May I suggest the title "disputed interpretations"--Jrm03063 07:42, 13 June 2008 (EDT)
I'm not particular about what we call it. "Plan Nine from Outer Space" works for me. I just think we need a more or less standard place to indicate relationship connections, generally discredited ones anyway, that don't appear as part of the explicitly connected genealogy.--Jrm03063 09:12, 13 June 2008 (EDT)
Ok, where this started was that I've encountered a number of places where I wanted to document connections that are generally not accepted. The rationale here is that others are going to repeatedly stumble over these issues as information from old GEDCOMs and other databases is recycled. Put differently, if a connection between a person and a family - either as a child of that family or a spouse - is not generally accepted, then:
A) It should not be part of the ordinary explicit family connections
B) It should be explicitly documented within the body of related person and family pages
The only question I'm asking is whether we can make the documentation of these sorts of situations a little more obvious.--Jrm03063 11:25, 13 June 2008 (EDT)
Jrm, how about a heading of "Disputed Lineages", highlighting the contradictions? Most of the disputed lineages occur because of conflicting secondary sources. Some of the disputed lineages are due simply to "old" disputes that have since been solved by a good primary source but the "old" keeps getting passed around from GEDCOM to GEDCOM. The word "disputed" does not have to have a negative connotation to it. Dispute can also simply mean to seek the truth in argument, discussion or debate. So I see nothing wrong about your suggestion. Collaboration is going to involve disputes, plain and simple. Like Amelia said, let's call a spade a spade (I'm sorry, but a father can not be younger than his biological son - that's improbable so let's call it what it is).
Perhaps linking these "disputed lineages" to a category as well would be useful. While the highlights can be brought out on the Family or Person page, maybe eventually these disputed lineages can have articles of their own.
The problem is, as you pointed out, is getting folks to look for something they don't know that they should be looking for. For instance, the family of William Spencer and Agnes Harris *was* a disputed lineage. Agnes was thought to be a Tucker or a Hearne. But Douglas Richardson several years ago found a primary source revealing her name as Harris. The disputed lineage has been solved, but not everyone is aware of it, so GEDCOMs get uploaded with Agnes Tucker and Agnes Hearne. I would assume when Dallan gets the match/merge function that such a case would be flagged as a possible merge, but even still, there needs to be something on the page telling of the dispute or former dispute and why folks should merge their Agnes Tucker into Agnes Harris.
Perhaps a category should be set up in the mean time so we can add these disputed lineages to it as we come across them to "hold" them until a solution is found on how best to present them. --Ronni 11:35, 13 June 2008 (EDT)
We keep coming up with the scenario of Person and Family pages needing "subpages" as it were. Maybe we should start thinking of just plain ol' articles as a type of subpage. Note the disputed lineage on the person or family page and then link it to an article where more information is presented. The article would link back to the Person/Family page. --Ronni 11:44, 13 June 2008 (EDT)
A "Disputed Lineages" section would be fine, I just want to follow a convention that at least a few other folks think is reasonable. In my colonial merging adventures I hit these sorts of things from time to time. I want to leave things in the most probably "correct" state, but I don't want to lose the information on what may or might have been a connection either. I had been adding this material as a "note" entry, but I decided that was a little too obscure. I saw some of Amelia's entries and liked having the material in the body of the person page, but perhaps not as the initial item! I figured a section at the end of the page is a nice compromise and, if a convention could be adopted on the title, there would be a better chance people would see the information when they needed to.
So, as a convention (__NOT__ a requirement), could a few folks chime in on whether "Disputed Lineages" is a catch phrase they would recognize for this purpose?--Jrm03063 11:50, 13 June 2008 (EDT)
I suspect that every problem will have its own specific needs. There's not going to be a one-size fits all solution. In some cases placeing a discussion of the issues directly into the article is going to work, in other cases, the matters involved are going to be too complex for detailed inclusion in a person article. Here's an example of one approach I've taken for a relatively innocuous issue. Go to the Personal data section and read the very brief blurb in the comments section about Dale Carter's Spouse. Relatively straightforward, simply identifying the fact that others have a different interpretation, and pointing to a location that contains a more complete discussion of the issue. I don't think there's much controversy here, as knowledgable researchers have identified the problems; the purpose of the point is simply to provide a more complete explanation of the issues here. If it were a bit less complex I'd have included it directly in the Dale Carter article.
An example of a more complex treate is found Here. This series of articles, still being built, addresses a very contentious problem in the genealogy of the descendants of John Walker I of Wigton Scotland. This is a very complex problem, and ultimately it is probably unresolvable. I have my opinions, others have theirs. the problem is complex and deserves a more complex treatement. It would not be easy to capture something like this within the framework of a simple person article. Q 13:05, 13 June 2008 (EDT)
Something else to keep in mind: One of the BCG's Standards of Proof, is that any contrary views must be adequately addressed. That means including an objective discussion of what others think, coupled with a well reasoned discussion of your own interpretation. Usually, there's an advantage to being objective in such treatments. Q 20:36, 13 June 2008 (EDT)
Just to throw out some different wording for consideration; I have used "Conflicting Data" on my Jackson web site. I figured if I told about the conflicting info and explained how I came to my conclusions, it would give others an insight into how I came to a resolution. I didn't want folks wondering why my data differed from data they found on other sites. Some conflicting data can be explained in a couple of paragraphs, but I have one that took 3 pages. It will need some polishing before I can put that one on WeRelate!
I'd expect to put a couple of paragraphs on the person or family page near the bottom, but maybe with bright color text near the top saying 'See Conflict Resolution Below' or something like that that at the top to catch attention. Anything that takes more than a couple of paragraphs perhaps could be a linked article. --Janiejac 23:28, 13 June 2008 (EDT)
Others may take the view that a generally common or conventional approach will never help, but that is not my experience. I have already tried such an approach and found it convenient to have, and I now want to improve it. Of the ideas put forth, I think "Disputed Lineages" as a final section before "Sources" is least offensive and most on point. I encourage others to adopt the approach if they find it useful (or at least, can think of nothing better).--Jrm03063 23:40, 13 June 2008 (EDT)
I hadn't considered this situation; I'm very grateful for the discussion. I'm going to throw another wrench into the works. For the upcoming merge function, I've been thinking the system would take the events/facts from the newer page and add them to the older page if they don't already appear on the older page. For events like Birth, Christening, Death, Burial, and Marriage that we can have only one of, if different values for those events already appear on the older page, the system would add the events from the newer page as "Alt Birth", "Alt Death", etc. events on the older page. This means that in addition to a text section explaining why a certain event/fact is disputed, it still needs to be stored as an "Alt ..." event/fact. If not, it will be added as an "Alt ..." event/fact every time a page with the disputed event/fact is merged into this page anyway.
We currently don't have anything like "Alt Parent Family", "Alt Spouse Family", "Alt Husband", "Alt Wife" and "Alt Child" to record that certain family relationships are disputed. And we'll need to record the disputed relationships on the page, or every time a page with a disputed relationship is merged into the page, the disputed relationship will be added to the page anyway. I'm thinking that the system can assume that if a Person page is linked to two or more "Parent Families", then the second and later parent family links are disputed. And it can assume that if a Family page links to two or more Husbands or Wives, then the second and later links are disputed. But we'll need to have the user explicitly check a checkbox on the "Spouse Family" link to specify whether this spouse family is a second marriage or is known to be disputed. We'll also want to display a "Disputed" checkbox next to the child links, but we can derive the value for this checkbox based upon whether this family is the second or later "Parent family" on the child's Person page.
By the way, if the resolution of conflicting evidence gets really long, I'd rather have it moved onto an article than to create a subpage. Subpages aren't automatically renamed when you rename a page, and they aren't automatically redirected when you redirect a page. Creating separate articles if necessary just keeps things simpler.
What do people think?--Dallan 18:18, 19 June 2008 (EDT)
It seems that we have two distinct situations here:
I know that we could remove the wrong date/relationship from the page, but having to re-remove it every time someone uploads a new GEDCOM with the incorrect information would be a pain and violates the idea that newly-uploaded GEDCOM's shouldn't be too burdensome to the community. Also, even though they'd be useful, I'd rather not add notes to relationships because most desktop genealogy programs don't support notes on relationships and it would cause problems when we implement GEDCOM re-upload. Having a specific "disputed" flag on the event/fact or relationship, with the reasoning recorded in the big text box, would make it easier for the system to treat disputed information differently from non-disputed information.
How about the following?
--Dallan 12:56, 20 June 2008 (EDT)
Dallan, I am not sure of your approach to match/merge, but the way he PAF utility works, the two pages proposed for merging are displayed side by side. Each data field on the right hand page has a check box beside it. If a field is blank on either page the data from the filled in field is incorporated. If both pages have conflicting data, the values from the left hand page are incorporated unless the box on the right is checked. Then the value is overridden. Any changes made should trigger a dispute flag requiring an explanation, probably on the Talk Page rather than in the big text box. The main issue then becomes source quality.--Scot 15:33, 16 July 2008 (EDT)
Interesting comments Dallan, and I think you're on to something. My concern was that human users would need to see something on the body of the page explaining about known issues/errors that are "out there" in the world knowledge base. I hadn't considered that there might be a way to automatically recognize discredited information on the way in, which is better still (and even if you can only do a few special cases).
My question then, is what of the "alternate birth", "alternate death", etc. events. To my mind, those are by definition disputed or less probable facts. The primary birth/death dates being the generally accepted and/or most likly values, the alternates being other values that have been seen but are probably incorrect. What does it mean then, for an alternate birth to be "disputed"? Does this mean we should drop the "alternate" tag from the various event types and simply allow zero or more births, deaths, or whatevers? The first non-disputed value for birth/death/christening is the value that the page goes by...?
I suppose it would be a drag to change the database so that every "alternate <whatever>" event became simply "<whatever>" with the disputed flag set. On the other hand, ambiguity about the fact items probably isn't a good thing.--Jrm03063 14:01, 20 June 2008 (EDT)
I've been thinking about the "alternate" events as well. It would be pretty easy to change if we displayed them without the "Alternate" word (so just "Birth" for example), but kept using the "Alt birth" tag in the database (which you'd see only when you view a page difference).--Dallan 14:44, 25 June 2008 (EDT)
I don't think we can assume that "alternate" means less likely or disputed. Going back to the first scenario Dallan identified above - there are cases where there's evidence/sources for two different dates and researchers (or at least the page editor) don't know which is the more reliable. That's different than disputed, which means that there is one date that's more likely than others, either because it's the one favored by more careful/better source or because it comports better with other information (including, for example, not belonging to someone else). So whether or not the different fields in the left hand box are marked "alt" or not, I wouldn't want to see all the alt dates/relationships marked disputed or to lose the ability to show more than one piece of information for a field.--Amelia 17:47, 1 July 2008 (EDT)
I think we'd still allow alternate events. Some of those events might be marked as disputed, but they wouldn't have to be. And on the left-hand box we could possibly display them under just the event name rather than the "Alt event" name (e.g., display alternate birth events under "Birth" rather than "Alt birth").--Dallan 16:21, 3 July 2008 (EDT)
So are we saying that an event can be plain, alternative, or disputed? Or are we saying that events can be a combination of alternative and disputed? I suppose you could also add "disproved" as a more definitive form of the negative, but I'm already confused by alternative and disputed, without adding anything else.
We need a couple of variants here, but not so many that folks don't understand what the intention is.
As someone once said, "it's such a fine line between clever and stupid."--Jrm03063 16:37, 3 July 2008 (EDT)
I've been worried about this too. I think we could generally remove the distinction between plain and alternate events, which is why I've suggested that we remove the "Alt" part of the event title, although there will be some places where we have room to display only the first event (the first birth event and the first death event for example). So then we'd just have two types of events: plain and disputed. Coincidentally, New Family Search has a similar structure: plain events and disputed events. They also allow multiple events, although just one of each type of event can be displayed on the summary page.--Dallan 18:35, 3 July 2008 (EDT)
Sorry, I havn't been aware of this discussion before, as I have been busy preparing a presentation for an upcoming convention. To me, the biggest problem with public or commercial sites is that they don't get corrected and/or consolidated. As a result, the discredited stuff is all there uncorrected. The other day, I checked the IGI looking for a particular person born in 1639 +- 10yrs and found 92 separate entries, all of them submitted, none with spouses or parents mentioned and no extracted entries. I suspect that nFS will become the same type of mess in that nothing submitted will ever be deleted so searching for good information will become another case of trying to find a needle in a haystack. There are many lineages that have been discredited through scholarly research. Many people cling to them because they may have once been, but no longer are, accepted by DAR, Mayflower Society, Dames of the Magna Carta, etc. Dozens of colonists have been endowed with royal ancestry by the many genealogical charletons of the 19th century, Gustav Anjou, eg, one of the most notorious, but certainly not the only one, or by just plain wishful thinking. Case in point; JRM and I both worked on a page for Sargent Francis Nichols of Stratford, CT the other day. A persistant myth is that he was the brother of Richard Nichols, the first English governor of New York. Richard's mother was Margaret Bruce, a descendant of Robert the Bruce, King of Scots. This has been the subject of several articles in publications such as TAG by several noted genealogists which have proved it wrong. I noted this on Francis' talk page with the articles cited and deleted the alternate parent as well as a note stating "it is clear there is a close relationship between Francis and Richard." To me, the goal of WeRelate is to reach consensus upon which is the most reliable source and present the single best choice as to what is correct along with documentatin. My understanding was that the talk page was where the dicussions to resolve the conflicts take place. Anyone wishing to reverse an edit must justify it first, not just change it back.--Scot 15:04, 16 July 2008 (EDT)
By the way, I've edited the Help:Wiki etiquette page with a goal to include a link to this page from the welcome message that everyone receives. The comments in this discussion are relevant, so I'd appreciate thoughts/edits that anyone has to offer on that page.--Dallan 18:31, 29 July 2008 (EDT)
It's been a few days since I've been scorched in this forum, so I'm going to offer a suggestion that's bound to be controversial. For "rookie" users of werelate, the total number of pages they can create via GEDCOM upload (a cumulative total over any number of GEDCOM uploads) is limited to some modest number - say, 100 or 200. I would define a rookie as someone who has fewer than some limiting number of contributions made by hand - perhaps a 100 or even 500.
The problem I'm regularly encountering, when searching out stuff to merge, is that it is very easy for a total newbie to upload a very large GEDCOM and then walk away. There has been discussion of the idea of purging unused GEDCOMs after a time, but that approach is not entirely free of disruption, especially if the community has begun to integrate the data. I've suggested writting a warning to encourage users to start small or use the digital library, but warnings like that are typically ignored. There have also been discussions of ideas that try to identify dubious GEDCOMs at or before upload, as well as to merge on the fly. Those are good ideas too, but I'm thinking they may be missing the point. A dedicated user can clean up even an awful GEDCOM. A decent GEDCOM that is abandoned - even if good quality - imposes a real burden on the community.
An initial size limitation would also, I think, discourage upload of materials that are apt to be duplicated (vast harvestings from ancestral file and the like).--Jrm03063 17:04, 18 June 2008 (EDT)
There is an interesting, well I don't know what you call it and I can not find it again; but it is a large colored box with text placed on articles in the Wikia that are unsourced. It says something to the effect that this section has no sources and is subject to deletion. If someone can find this, perhaps we could use the banner on our pages. Also once a user uploads a gedcom or creates a new page; those pages are now part of the community of WeRelate and not really owned by the user. --Beth 10:48, 19 June 2008 (EDT)
I am aware that there is a size limitation, but it's far too big for people who have not determined that they are really going to stick with werelate. I also know that Dallan is working on tools that merge on the fly, but that's never going to be a perfect solution. The real problem is abandoned material - and deleting after the fact isn't a solution, because the rest of us don't stop working while waiting to see if a new user is going to stick around. By the time we realize that someone is gone, it's often (for me anyway) more trouble to get rid of their upload than to just carry on, finish the job, and hope that doesn't happen again too soon.
I don't blame the new users particularly. This is a very different paradigm then traditional genealogy, and there is no reason folks would fundamentally realize they are working in a shared space. Their previous experience with genealogy software is you toss in your GEDCOM and see how you like it. If you don't, you just walk away.
Really, is there any reason that a new user to werelate needs to upload a GEDCOM of more than a couple hundred people? If they are really going to use werelate, they can start small and upload the rest later. If they aren't, let's restrict the damage they can do. Adding "good" information really isn't helpful unless someone is prepared to take responsibility for getting it merged and cleaned up as far as place names so forth.
I would also add that I've done a lot of merging, well over 2500 families and their associated members. It's real work, and it's just not fair to hope/assume that such things are going to magically happen even if voluminous trash is routinely uploaded. I would rather be adding real source material or merging families that wind up increasing the knowledge of the different contributors - not just merging and re-merging, and re-re-merging the same ancestral file content that I've merged numerous times before - and worse - for users who have already given up on werelate. Dallan, please help...--Jrm03063 11:43, 19 June 2008 (EDT)
I took a swing at a warning page in my personal pages area. I'm all for it, but I didn't think it would get the job done. Maybe I don't know how to say what's needed without going on too long, but I was struck that what folks need to know is more than most will take the time to read. I agree that any burden we place on uploads - size, quality, etc. - will result in some uploads not being done.
But I go back to an idea that I mentioned above - what good is a GEDCOM, of whatever quality, if no one is around to take care of the data? We could harvest GEDCOMs if that's what we wanted to do, and toss them all in, but the problem is having folks who will take care of that data. If carving a large GEDCOM into a smaller piece to try out werelate is beyond someone, what are the chances they're going to stick with this learning curve?--Jrm03063 17:17, 19 June 2008 (EDT)
In looking at the GEDCOM's that have been uploaded in the past year, I'm going to drop the size limit to 5MB. Only a few (44) GEDCOM's are larger than that. That amounts to roughly one user per week to have an email conversation with and ask them to consider uploading a smaller GEDCOM, or to evaluate whether they're committed enough to get permission to upload the larger GEDCOM.
I am reluctant to make it smaller than that right now, because I think the main issue we're dealing with is that it's difficult for most people to know up-front whether they will stick around until they see some benefits. They start out by uploading a GEDCOM to see what happens. If nothing happens, they don't come back and their tree is abandoned. But if others start adding onto their tree by merging their trees into it, and they receive a periodic email telling them that "you now share common ancestors with N new users", or "N new people are now reachable from your tree" or something to that effect, then chances are greater that they'll return. And since we don't currently issue these periodic emails because basic functionality that these uploaders would want, like gedcom re-upload without needing to delete their tree first isn't finished yet, most users at present are fairly inactive.
Rather than put things in place up-front to discourage people, I'd prefer to talk about ideas for making uploaded GEDCOM's:
For example, a possible solution to #1 might be to ask people to do their own merging, especially for duplicates within their own GEDCOM. We don't have tree match-merge working yet, but until we do we could do a "poor-man's" matching by reporting the family pages in their upload that have the same husband and wife names as existing family pages and asking them to review and merge them (we'd need to create a simple "Merge" function and write an instruction page). If they don't respond to this request after a week say, then we remove the GEDCOM.
Another thing we could do, and in fact is high on the ToDo list, is to detect when uploaded GEDCOM's are going to cause problems due to a lot of internal duplication or obvious errors (e.g., people being born after they die), and to report the errors prohibit the upload until the errors have been corrected.--Dallan 12:05, 20 June 2008 (EDT)
I'm not clear on how far this goes: "Also once a user uploads a gedcom or creates a new page; those pages are now part of the community of WeRelate and not really owned by the user.[Beth]" I think that should be made clearer, and available to all who join if that is the current belief. I tried to rejoin and ask on the wiki list, but was unable to join, twice. I would not have commented here if I had been able to put it on Beths list.
Jrm03063, I looked at the warning page you have created. The need is for a warning that a person must click through to add anything here. When I joined and added my gedcoms, I saw nothing here that was alarming at all, anywhere. Now I do wish I had not added my gedcoms, and I am not sure if I can completely remove them. The best solution is to remove the ability to add gedcoms. That way the 'junk' is easily taken care of and with warnings people will not add their information without careful thought, and then, one family at a time. Need for this conversation would be eliminated completely. I have been burned in a major way by a researcher and I am careful to retain rights on my research everywhere, so I have been finding the whole discussions on this matter disturbing. I certainly want this made clear soon.
I really liked the wiki format and was more trustful perhaps because of the connection to Allen County Library. I thought the only problem would be someone coming in and putting up false information over my own research. FamilyTwigs- Twigs 12:55, 20 June 2008 (EDT) -
I want to re-ask the question about GEDCOM size limits for rookies in a different way. What is the largest database that any of us can imagine doing a responsible job maintaining? While I'm watching 22K pages, that's only as a side effect of merging - there is no chance I could do quality research on a space that big. My own tree is only slightly over 3000, and I can't see it growing all that much. Doubling perhaps at the outside, but not much more.
When a GEDCOM comes in with over 5000, or even 10000, from someone who isn't a comitted user - why are we allowing that to be uploaded? It's so unlikly that GEDCOMs of that size will be anything more than large dumps of unproofed commercial data bases. Essentially oceans of unsourced names and dates that create a merging burden without adding real information. A dilligtent researcher will still have to go back through any such lineage and try to document it with appropriate reference material before it really becomes useful.
I also think that a file size limit, while convenient to implement, isn't the right answer. It needs to be a content size limit (number of people/families).
I understand not wanting to discourage contributions, but no one should be uploading data they aren't willing or ready to maintain, and it is just beyond reasonable to expect that GEDCOMs with over 10K people are going to be dominated by really useful information. At the same time, it's hugely unfair to expect that a shared-space community is just going to clean up someone else's thinly sourced yet bloated database. In a few minutes a rookie can create months of work for others. Mind you I'm not holding such folks personally responsible - they don't know the implications of what they're doing - so they just have to be reined in.--Jrm03063 15:49, 17 July 2008 (EDT)
I've set the GEDCOM upload threshold to 5,000 people. People can request to upload larger GEDCOM's, in which case I'll review their previous contributions to decide whether to allow it. Less than 10% of our current GEDCOM's are over 5,000 people, so this shouldn't cause difficulty for most uploaders. I've also added some intructions to Special:ImportGedcom based upon instructions User:Jrm03063 has written. Hopefully this will help.
Just a quick note: I'm not sure I would recommend that people go through their pages and make sure that the place names point to Place pages, especially not yet. I've spent some time this week improving the place matcher used for GEDCOM uploads so it's better than before, but we have a list of what looks to be about a million non-US places that need to be added to the place wiki later this year.--Dallan 18:31, 29 July 2008 (EDT)
Hello WeRelaters,
Look at this fantastic site: [1]. Select a state and then you can color code the counties and export the whole shebang as an image.--Beth 09:46, 22 June 2008 (EDT)
Nice find. It certainly is easy to use---much easier than creating such maps manually, or extracting them from the Wikipedia, which is what I've been doing. However, doing a test on this I'm not sure how easy it will be to import these images into WeRelate. The image backgrounds use "transparancies", which either may not import well, or would require some manipulation to import. Will check on it and see. Q 10:08, 22 June 2008 (EDT)
OK, did a check. The program creates gif images and seems to give a decent display. Not sure about the license restrictions on this, if there are any. Need to check terms of use. Q 10:45, 22 June 2008 (EDT)
Bill, I did not find any license or terms of use on the site. Wes Coleman used maps on his pages on Rootsweb and added a note that the maps were available from Texas A&M and gave the link. See Wes' page here [2]. --Beth 10:24, 22 June 2008 (EDT)
Also, on a related matter. Note the modifications to the DIV on the Exchange page. I adjusted this so that it wouldn't overlap the advertising sidebar on the right. Q 10:45, 22 June 2008 (EDT)
I've been working on a functional specification document that describes data consistency testing we could perform in the framework of werelate. While I'm calling it a specification, it's pretty informal. If you are interested in this sort of thing, or have some experience with tools of this sort elsewhere, I would like to hear your thoughts and comments. I think it would give Dallan and others something to work from when they get around to adding features like this to werelate.--Jrm03063 14:32, 28 June 2008 (EDT)
I may have asked this question before, but if so, I don't remember seeing an answer. The article article Settlers of Thompsons Creek, Washington County, VA includes a markup of a map with annotations identifying various reference points in the area. The annotations do not show up on the version of the image in the article, but if you click the image, it takes you to the stored version, and there the annotations do show up. Why do they not show up on the image accompanying the article? or in the version displayed below? Q 19:40, 29 June 2008 (EDT)
A werelate "tree" is really nothing more than a list of pages. Usually they represent a tree of some kind, but this is not a requirement.
Lately, I've started using a tree as a general purpose list of families and people that I need to do further work on, because they represent duplication or are obviously in error. So, I just created a new tree called Errors and Duplicates. If I find an error or duplication that I don't want to resolve at that moment (say I'm in the middle of working on a different family), then I just add the page to my Errors and Duplicates tree.
I used to do this with a personal page, which had the advantage of allowing me to make notes on what the issues were, but this is a lot quicker.--Jrm03063 09:58, 2 July 2008 (EDT)
That's a great idea. Another thing you could consider (if you wanted to edit the pages) is to add them to a category. The long-delayed but upcoming search function will let you search based upon category.--Dallan 16:21, 3 July 2008 (EDT)
Hi, I am trying to help Carol fix her pages. Before I fix this page, just wondering how the page was named before the wife was entered? The page is Family:Dorcas Jones and Issac Standifer (1). Also there are 2 pages for Issac. One under Isaac Standifer and one under Issac Standifer. --Beth 10:53, 2 July 2008 (EDT)
Well, from the history of the page it looks like she has entered the wife's name in the title first and then the husband's, which of course is reversed. Then when WeRelate created the page, it would have had "Dorcas Jones (new)" as the husband's name and "Isaac Standifer (new)" as the wife. It looks like she has taken out "Dorcas Jones (new)" and replaced it with "Isaac Standifer (1)" and then tried an "Isaac Standifer (3)" as the wife, but later took it out and didn't replace it with anything. Thus it looks like a family was created without a wife. --Ronni 11:30, 2 July 2008 (EDT)
This is not addressed in the family pages tutorial, or if it is I missed it.
If the you know the name of the husband but not the wife how do you enter her name? Do you enter unknown unknown or just unknown for the surname or do you enter the married surname for the spouse? I have entered unknown unknown but I am cleaning up data for another user and this user has entered the spouse's surname, before I change it I need to make sure that it matters. --Beth 20:23, 2 July 2008 (EDT)
It doesn't matter all that much whether you Unknown or Unknown Unknown. If you leave the wife's name blank, the system will create a page with just the one "Unknown" for the wife, so a single "Unknown" will be consistent with other pages. What I'd rather not see however is people entering the surname of the husband for the wife's surname, because it will confuse the matching algorithm somewhat (not a big deal, but "Unknown" or even "Unknown Unknown" are better).--Dallan 16:21, 3 July 2008 (EDT)
From Dallan:
I recently received the following link: http://www.familytreemagazine.com/podcast/episode2.asp
In it Family Tree Magazine talks about their new 101 Best Websites list. WeRelate.org made the list again this year. What's especially wonderful is that when their editor Allison Stacy was asked to pick *one* website to talk about in the podcast, she chose WeRelate. The success of WeRelate is due to you.
The part of about WeRelate is toward the very end of the podcast. I believe that Allison is also highlighting WeRelate in the upcoming magazine.
--Beth 12:39, 4 July 2008 (EDT)
Spouse of Family? choose ยป remove
Add new family page Select existing family page
I believe that the layout above leads to confusion with new users. Some are adding the name of a new family page before the spouse is added. We need a redesign of this section.
--Beth 12:47, 4 July 2008 (EDT)
Ditto for spouse. Perhaps "Identify Spouse" would be less confusing? Q 13:22, 4 July 2008 (EDT)
Hello Bill, One day soon I hope to return to our project. Actually I think the line below adds to the confusion more than anything else; it says add new family page or select existing family page. If no family page exists; you should select add new family page. When you select that a screen pops up and you enter the spouse's given name and surname and click okay.
But I belive that some new users interpret the line - add new family page - to mean they are supposed to type in the name; they then end up with a family page with no spouse. That is why I say something needs to be changed to make this clearer. --Beth 14:09, 4 July 2008 (EDT)
Hi Beth. I believe what I was saying was that It works as described and intended, but the way things are labeled is not intuitive. A new user might get the wrong idea, which is what you were pointing to. My observation is simply that there's no redesign needed, just some more intuitive labeling. Q 19:17, 4 July 2008 (EDT)
Well Bill, we agree just a problem with semantics; so we need intuitive labeling. --Beth 19:33, 4 July 2008 (EDT)
Not only does the user type in the name of the new family page; but sometimes it is done in reverse so we have Mary Smith and John Jones as the family page.
Sorry for not responding sooner. How about renaming the labels to:
What do you think about the proposed renaming?
In the very near future I'm planning to get rid of those little dialog boxes that pop up when you add a new family entry. Instead, when you click on the "find/add" link, a new window will open where you'll enter the names of the husband and wife of the family along with their marriage date, and the system will do a search to see if a matching family page already exists and show you possible matches. If the family page already exists, you'll select the matching page and the system will fill in the family field with the title of the selected page. If the family page doesn't exist, you'll click on an "Add" button, the system will create a family page with the information you've entered, and fill in the family field with the title of the newly-created page.
I'm hoping this new approach will reduce the frequency of creating duplicate family pages and mis-titling family pages.--Dallan 17:45, 11 July 2008 (EDT)
I have several questions regarding the format for entering data into the fields. I want to make sure that I follow the correct format in my screen shot for the tutorial.
Regarding the field Volume / page. Should I enter: Part I / 107-109. And how do you enter the data if you only have a page number and no volume number. May I just enter I: 107-109 or is the / important?
What about record name? My source is a book. The name of the article is Rev. Robert M. Cunningham, D. D. which is in the Chapter (not really numbered chapters; just book sections) named Recollections of North Alabama. How about this? Rev. Robert M. Cunningham, D. D. in "Recollections of North Alabama"
Year - I assume that is the year of publication of the book.
Text / transcription location - I probably will not enter anything in the text field; but if one enters text does one follow the text with this / if one has no transcription location.
My article gives source information. I suppose I will enter that in the notes field.--Beth 17:17, 10 July 2008 (EDT)
I personally don't worry too much about the format of the "Volume/Page" or the "Text/transcription location" fields as long as they're reasonably easy for others to interpret. Date is somewhat ambiguous in the GEDCOM standard. I think it's meant to be used for the date you looked up the information, which is useful for online sources. But it also makes sense to use as the date of the particular edition of the book you looked at. I think using the "Record name" field for the Article and chapter makes good sense.--Dallan 17:45, 11 July 2008 (EDT)
On the 13 of April 2007 user:Lynn9932 added a Gedcom to this site. She also added a note on her user's page that would appear to be spam. Would one of the admin's check this please? Q 22:40, 14 July 2008 (EDT)
I agree. Seems to be a case of "link spam." Since this is the first time I've seen this type of spam on WeRelate, I want to get Dallan's opinion. Thanks Q! --Ronni 01:29, 15 July 2008 (EDT)
This isn't the typical "link spam" case that we used to see before people had to confirm their email address in order to edit pages: It's not on a high-visibility page and the user has other contributions. It may be that the user made a mistake and forgot to put in the full URL of their family website. I left them a message about it. In general though I think we should be more lenient about people adding links to their own user pages.--Dallan 03:19, 15 July 2008 (EDT)
Would it be possible or advantageous for there to be a list of projects or features that Dallan has planned and the current status? I know these things are discussed in various places at the watercooler, but I'm hoping for a standard place, easy to find, not buried in many discussions, where this info would be made available. For example, I'd like to know the current status on the match/merge function. And how far down on the to-do list is a feature that will allow line breaks in uploaded notes in GEDCOMs. If there already is such information available, I don't know where to look for it. --Janiejac 12:15, 15 July 2008 (EDT)
and is there a place that tells what has just been done?
I have been away about a week and now when I go to add someone it looks very different. I also cannot find whatever it was that I always used that was a directory of all the pages I have in various trees. I cannot recall the term for this but it doesn't seem to be in the pull down where it used to me. I am feeling very disoriented and if there is somewhere that details the changes I would like to find it?--MizLiv 15:58, 24 July 2008 (EDT)
The new look is from the new search engine that Dallan installed. Dallan is editing the tutorials. You still select My Relate>User Profile. That will show a list of all of your trees and you can view the list from there. Or you can select My Relate>Trees and select to view the tree there. You can also select My Relate_Launch FTE. Do these include the directory that you are looking for? --Beth 17:18, 24 July 2008 (EDT)
thank you!
the list I can't find is not the index within the tree - it was a link that I went two that let me see ALL family pages, individual pages, images etc. no matter what tree they were in. I can't figure out if I am blind or if it has been moved? I thought it was in the MyRelate pull down memory? I have used it a lot so I know I am not imagining it but I COULD be wrong about where it is and suddenly have gone blank!--MizLiv 19:12, 24 July 2008 (EDT)
Well, I am not sure that I ever found the list that you are missing. The dashboard has been moved to the top of the list under My Relate. Sorry that I cannot be of more help. --Beth 19:36, 24 July 2008 (EDT)
Would "Browse" be what you are looking for? Its under Admin in the pull downs. Or at
Q 20:06, 24 July 2008 (EDT)
Sorry for being late responding. In addition to the "Browse" screen, you can also go to the "Search" screen, check the "Watched" checkbox, and press "Search". This gives you a list of all pages in your tree, and unlike the "Browse" screen you can see vital information about the People and Families you are watching. You can even sort them by title or by date modified by checking the "Exact pages only" checkbox. Help:Search has more details. Since it does so much more than Browse does, I removed the Browse menu item from the MyRelate menu (but left it in the Admin menu), but then I didn't tell anyone that I did that :-(. I apologize for the confusion; hopefully you'll really like the new search interface or you can continue to use Browse in the Admin menu.
As for talking about changes that have been made, I'm starting a blog. There's not much there yet, and it looks ugly, but it will improve over time.
As for talking about changes that are going to be made, I'm not going to estimate dates any more, because I'm not a good estimator :-). But I have put a partial list of the things on my ToDo list on the blog (you'll see a link to the ToDo page in the upper right-hand corner).--Dallan 18:31, 29 July 2008 (EDT)
Hello Everyone,
I am trying to figure out what to do about online books (sources) found on the Google Books website.
What is the policy of Werelate, and Google Books about Werelate users citing the book.
Many of these sources are virtually impossible to see in person.
Can they be added as Werelate sources? If so how do we the users list them?
By Title of Book, location Google books?
Thanks for the input on this subject
Debbie Freeman--DFree 12:48, 19 July 2008 (EDT)
On another subject could we add a spell checker to Werelate? I though we had one before.
Here's a link to very interesting beta search engine site.
The specific link above allows you to search the WeRelate site. As an example, type in "Daniel Boone" (include the quotes---otherwise you'll get hits for "Daniel" and for "Boone" as well as "Daniel Boone". You can also use Boolean operators. Not sure if the standard Google symbols (beyond quotes) work here.
When you do that you get a display of links to the site that contain "Daniel Boone". This is fairly neat if what you want to do is search specific to WeRelate, though its advantages will likely be overcome when the update to the WeRelate search engine are in place. Also, I've notice that with some settings links to other websites are also retrieved.
However, the really neat bit with this engine is the "grey" display of connectivity. Near the top of the page there will be a few links that will be in grey, with the form "Daniel Boone (208)" or something of that sort. Click on one of those links and you get a display map showing the links between articles in which "Daniel Boone" appears.
In theory, this would allow you to quickly see other connections to Daniel Boone located on WeRelate---Might be faster to scan the images than to look at the individual links to cull out what's of interest and what's not.
Q 08:57, 20 July 2008 (EDT)
It works for me (maybe it was down earlier). The link graph is cool.--Dallan 18:31, 29 July 2008 (EDT)
We could do something like this based upon the "what links here" links. Probably not anytime soon though. I'll have to mull it over.--Dallan 21:27, 29 July 2008 (EDT)
When edited pages that were submitted by another user; if I have a death date for the living person what is the correct procedure? On the first one I just removed the living person and added the other.--Beth 21:19, 25 July 2008 (EDT)
You could enter the death date, then rename the page to include their given name if you wanted.--Dallan 18:31, 29 July 2008 (EDT)
Hello,
My question is what do I do to ID an accidental duplicate family or person page that I created so it can be fixed later?
As well as help me know it is a duplicate page so I do not add information to that page but to the earlier numbered page. Example John Doe (1) and John Doe (3) person page. I want to make sure I add information to John Doe (1) person page. Debbie Freeman --DFree 16:26, 26 July 2008 (EDT)
Debbie just redirect (3) to (1). If the (3) remains in your tree list after the redirect just remove the page from your tree; do not delete the the page.
To redirect do the following: Redirect the duplicate page to the surviving page by typing # redirecttitle of surviving page on the first line in the text box of the duplicate page.--Beth 18:38, 26 July 2008 (EDT)
Hi Debbie... to clarify Beth's instructions, don't forget to add the brackets. Also, I don't think it works if there's a space between the "#" and "redirect". Here is what your command should look like: #redirect [[Person:Stella Orpha Sumpter (1)]]. --Ronni 21:17, 26 July 2008 (EDT)
I saw your comment and dug through your contributions. I found and fixed at least some of the duplicates you were trying to work through. You'll have to review it anyway. I noticed that you had two problems "#" and "redirect" need to be together. Also, as you already read, the destination of the redirection has to be enclosed in double square brackets.--Jrm03063 22:58, 26 July 2008 (EDT)
The changes made to the Search function are greatly appreciated. I haven't fully explored this yet, but this is a great improvement. A couple of things to consider:
1. If you search for a specific name, e.g., Daniel Boone, you generate a long list of hits. The counter says there are over ten thousand hits. Some of those hits are for "similar to Daniel Boone", and not exact matches. Obviously, you can't examine all of those hits. Fortunately the list is "semi" ordered, so that exact matches for "Daniel Boone" appear near the top---but not necessarily all of them, and not necessarily in order of their "index number". Here's a list from the second page of hits:
Note that the sequence of "Daniel Boone"'s is interrupted by the insertion of "Burwell Boone (1)", and "John Boone (35)". I don't see an obvious reason for that to be a desirable thing if you are searching for "Daniel Boone". What it says is that the list of hits is only roughly ordered. Here the unneeded hits can be easily skipped over. But they are obviously out of order. That makes me wonder if you might get hits for "Daniel Boone" isolated very deep in the list---say at hit 949? You wouldn't be able to find such scattered hits as they would be buried so deeply---and so might miss something helpful
2. The above sequence of hits skips over "Daniel Boone (24)". There is actually a card (sort of) for "Daniel Boone (24)", though the corresponding tree has been deleted, and "Daniel Boone (24)" is just a placeholder for something that once existed but for which there's no information retained---just the fact that sometime someone created a space for "Daniel Boone (24)", and then went away. Is this little bit of real estate (so to speak) up for grabs? Should this "ghost" persist, and could/should others with an interest in Daniel Boone choose to utilize this real estate? Should such "ghosts" be completely purged from the system, and the space set aside for them be reused?
Q 10:38, 28 July 2008 (EDT)
Clicking on "Exact Matches" I get 18 hits for Daniel Boone. If I don't find what I want in there, I would then expand the search. Burwell Boone shows up when doing an "exact match" because his alt name is "Daniel." John Boone shows up because Daniel is his middle name. I find both of them showing up in the hits as a desirable thing, unless you are speaking specifically of where in the order of things they appear. Even so, I *could* have been searching for Burwell, but only know him by the name of Daniel. --Ronni 12:58, 28 July 2008 (EDT)