WeRelate talk:Watercooler

From WeRelate

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.

Topics

[add comment] [edit topic]

Active discussions taking place at other pages

[add comment] [edit topic]

Places: Redirect and more... [1 August 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)

How is the place matcher/redirect process coming along now? If/when I do upload my data base, I also have not indicated U.S.A. Also, ALL my counties have Co., after the name. (I hate to see locations and not know if they are talking about the city or the county.) So would my locations get U.S.A added automatically, and would my county locations get directed to your county places dropping the 'Co.'? --Janiejac 20:06, 3 June 2008 (EDT)
Hi Janie,

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)

[add comment] [edit topic]

Merge/redirect and FTE [29 July 2008]

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)

Apparently I'm in a minority on this subject, but I think people should have a reasonable expectation of having their material displayed the way they want them to be displayed. Changes in someone elses lineage should be made collaboratively, not pre-emptively. If you really feel a need to merge, then why not ask the person if its OK with them, ask them to collaborate with you. Ask them in the discussion page, so that there's a public record of having the question put to them. If they are watching, they can respond. If they aren't watching, and don't respond, then I think the presumption is that they don't care, and you'd be free to merge away. If they don't respond you might try contacting them offline, but a public statement that you'd like to change the page, should suffice. No response, change away. Q 21:04, 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)

[add comment] [edit topic]

Discredited Genealogy [29 July 2008]

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)

JRM, perhaps one should write an article and link it to the main page. There are examples of good articles in the NGS quarterly. Because of lack of time for now I have entered a title on the page regarding the discrepancy. See Person:Robert Coker (3) and the topic Lenard Coker & Charlotte Coker in the 1850 household of Robert Coker. This error is found in many of the family trees posted on other sites. I plan to write an article; but may never do it. I have approximately 26 more trees to enter and have not finished the ones that I started. --Beth 20:17, 12 June 2008 (EDT)
I think I prefer the discussion to be on the person or family page. I've been generally dealing with the issue under a heading that's specific to the issue - like one in the beginning called "Origins" (because so often the problem is a faulty line for an immigrant back to England) or I've seen (Ronni I think) have a section on "Possible Children". But a standard section title that calls attention to wrong information is probably useful. I like all JRM's suggested titles, depending on whether the problem is something that's been proven wrong, something that's incompatible with known information but not impossible, or just untrustworthy. I like putting it on the page better because it's more likely to be seen, and because there will often be content to put there (i.e. "Author X disagrees that this man ever sailed on the Mary and John because of X, Y, and Z.") that doesn't really need it's own article (an article which, as Beth points out, may never get written!) --Amelia 20:24, 12 June 2008 (EDT)
What goal are you attempting to accomplish with such labels? Q 20:50, 12 June 2008 (EDT)
They call attention to and acknowledge the bad information, and (hopefully) demonstrate why it is wrong, so that people who don't know better don't get upset at the information being removed and/or try to add it back.--Amelia 20:57, 12 June 2008 (EDT)
Off topic. Has your blessing arrived yet? --Beth 22:26, 12 June 2008 (EDT)
Two weeks ago today...and he sometimes sleeps enough for me to read and type again :-) --Amelia 23:22, 14 June 2008 (EDT)
They are also labels that do not, in my experience, improve the success of a discussion, but different folks have different approaches. Q 21:00, 12 June 2008 (EDT)
In cases where the evidence is unclear and there is room to disagree, you may be right. But there are many cases where information that has been proven to be flat-out wrong is still being circulated, and in that case I think we should call a spade a spade.--Amelia 21:12, 12 June 2008 (EDT)
Red hot pokers are rarely an effective argument. You might "win" with one, but you will rarely change anyone's view. Q 21:15, 12 June 2008 (EDT)
Bill, but you will change someone's view if you have convincing evidence. It should be posted and if a user disagrees they are free to post and document why they disagree. --Beth 22:26, 12 June 2008 (EDT)
I don't think the issue is making a logical argument for or against something. Its labeling someone else's stuff "Discredited", "junk" or what have you. It may in fact be such, but labeling it so implies "I'm right, your wrong". That's not reasoned argumentation. That's argumentation by fiat. If you have to apply a label to enforce your viewpoint, frankly you're argumentation can't be all that good, or people would change their view. Q 22:49, 12 June 2008 (EDT)
Bill, that makes sense. Just title the discussion with reference to what you are disputing. For example, John Doe shown not to be the father of Samuel Doe or evidence disproves that John Doe is the father of Samuel or something.--Beth 00:35, 13 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 a situation on WeRelate. There are 2 different wives shown for the same person. I discussed this with the other user. The user had no objection to me changing the name of the wife; I had direct evidence and the user was not certain where that information came from, possibly a vertical file. So sometimes a discussion with the user eliminates the conflict. --Beth 07:31, 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)

Since we're talking about individual articles, how alternative viewpoints are handle is largely up to the individual authors. If someone else wants to have a different view of some genealogical "fact", that's pretty much their prerogative. I don't need to convert them to some other viewpoint. Arguments really only get in the way of doing the genealogy. I probably go out of my way to avoid "hot buttons", simply because its not an argument that I'm trying to achieve. Now, if someone wants to engage in a reasoned discussion of some viewpoint, that's another matter. I always learn from discussions (such as this one). The only thing I learn from an argument is to avoid the person in the future.
So, if "Disputed interpretations" floats your boat, that's better than "Rejected Conclusions" or something of that sort. Personally, I try to avoid hot button words as much as possile, as they do not usually advance a discussion, and sometimes hinder it. The advantage of a phrase like "Alternative Viewpoint" is that its about as non-confrontational as you can get, and still convey the message that there is a subject where differences of opinion are held. Q 08:58, 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)

JRM; I am not all sure that a standard place and name would work for me. It actually would depend on the context within the applicable page. Just checking a few titles for articles in the NGSQ and the NEHGR that pertain to this subject; I found the following titles:
The nature of a wiki is that folks are pretty much going to do as they want. If someone wants to create a "standard" section entitled "Plan Nine from Outerspace", they are going to do that. You aren't going to stop anyone from doing it the way they want, unless you want to establish a policing system---which ain't going to work. Q 09:50, 13 June 2008 (EDT)
Precisely my point Q. One can create a "standard" section; but I may choose not to use it. --Beth 10:06, 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)

If the detective work behind a disputed lineage is significant, it could very well belong in an article by itself. I wouldn't suspect that to be the typical case though, where creating an article "sub-page" would be a heavy handed answer that is, never the less, even more obscure than a "note". I prefer that a brief section exist in plain sight, referring to additional articles if needs be, but not as a general rule. --Jrm03063

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)

Generally, what is being suggested IS the conventional approach. You don't get much more conventional then BCG. Their guidance on this particular point is to include:
Because it:
How you go about doing that is pretty much up to you, but it's their recommendation to resolve such conflicts. Q 08:46, 14 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)

This is just going to be messy regardless of what we do. The first issue I have is that I object to having information that is just plain wrong continued to be listed as if it's a legitimate possibility - i.e. labeled "disputed" or "alt." I know that's a line that humans are going to have to discuss, and many times there are good faith alternatives, but there really are many situations where information is just plain wrong. If we continue to present it as a viable alternative, we're doing a disservice and spreading the wrong info - particularly if this "alt" info makes its way into gedcoms downloaded from WeRelate. I would rather have people who get the notification emails generated by the merge keep deleting nonsense than keep the bad information on the page - it's work, but it's the wiki way. It also preserves "alt" as alternatives that could actually be possible. I do feel more strongly about this with regard to relationships (which are harder to clearly label as wrong) than with dates, where we can at least use the note field to explain why something is wrong or disputed.
Another issue - I don't think it makes sense to assume that "later" parent families are the "disputed" ones. The parents are listed in order that they are added to WeRelate, and although in many cases the older page will have been "cleaned" and have the most reliable data (we hope), that won't be true everywhere, and it's not intuitive to change the order to reflect what's the best data. Plus, elevating one set of parents and calling the rest disputed it doesn't cover two common situations 1) the dispute is whether the parents are known or unknown or 2) the dispute is which of two couples is the parents, with both being equally likely.
I would love a way to indicate that parents, spouses or children are disputed, but given the discussion above, that's apparently excessively judgmental of me. A nice alternative would be a way to add a note to a relationship like we can do with events. --Amelia 18:43, 19 June 2008 (EDT)
From past experience I have had in informing someone that their information is wrong; unless they are a professional genealogist, some do not take it very well. My recommendation is to obtain all of the useful information a person probably has before saying outright that they are incorrect. I guess that does not sound very nice but unfortunately sometimes it is necessary. --Beth 20:12, 19 June 2008 (EDT)
Beth, a very good observation.
Almost everyone thinks they are "right" about whatever position they take,
most do not take kindly to being told that they are "wrong",
and some seem mistake honest discussion for personal attack.
Objectivity is rare. Q 20:40, 19 June 2008 (EDT)
Let's don't forget - this is a shared space. The caveats that are expressed on wikipedia apply - if you don't want to see your contribution edited, re-edited, changed around, etc., you should probably find a different place for your work. We're after the community sense of what's correct. We can't be afraid to "fix" things that are broken because we might offend.
I take the view that the person currently working any page has the information that's present there and whatever the best additional information is at that moment. They should make any and all corrections and changes that they believe are appropriate. Nothing is ever really lost, because this is a wiki. Even so, anything that I change because it was incorrect gets a note or (from here on) added to a disputed lineages section. Within that, I place information on the relationship/linkage that I found to be incorrect, along with links to the family and person pages involved (this sort of gives the feature that Amelia wanted, without actually placing such links in the left-hand column).
I avoid situations of A says X and I say Y by adding whatever source information I have. If the discussion is focused on the relative merits of sources, the discussion will probably remain constructive. If two parties reach an impasse, I think the community can be called upon for assistance and the generally accepted/majority view will prevail. If the other side remains unconvinced they can and should write an extensive minority opinion. After all, new information comes to light from time to time, and perspectives change.
Really I am okay with whatever we decide. This is a dynamic site so what we decide now may be changed in the future. The dynamics is one of the many things that I love about this site and a new and updated version of the Think Tank. Although, I am having fun imagining a court of 3 Wiki Judges deciding the outcome of a genealogy impasse. --Beth 21:25, 19 June 2008 (EDT)

It seems that we have two distinct situations here:

  1. There are two dates or relationships, and the contributors are not yet sure which is preferred, or there is some evidence to support both (or more likely, there is no good evidence to support either).
  2. There are two dates or relationships, and the contributors can generally agree that one of them is wrong.

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)

Yes, the Talk page is a better spot. Since we can store multiple occurrences of relationships and events, if both slots are filled we can by default add the other relationship/event as a second opinion rather than overriding it, but I do want to display both pages side-by-side, and there should be a way for the user to say which of the two conflicting relationships/events should be listed first.--Dallan 18:31, 29 July 2008 (EDT)
I love it.--Amelia 13:37, 20 June 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)

[add comment] [edit topic]

GEDCOM size limits for rookies [29 July 2008]

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)

Hi Jrm, I am sorry that you felt scorched in the forum. There is a size limit for gedcoms in place now. I recommended no gedcoms; but one of the attractions of WeRelate is the gedcom feature. It seems we have to take the good with the bad. After the match/merge features is added, perhaps we can reevaluate WeRelate and make a more informed decision.

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 do agree (surprise), but I also wonder if we could accomplish (most of) the goal in other ways. Right now, the upload page has no information on the consequences of one's actions aside from licensing information. It could be a lot clearer that uploading a small file is a much easier way to start. The page could even state it as an official policy that no users should import information from before 1700 (or whenever) without checking if it already exists (although we new search would make this vastly easier) -- the chances of pages already existing go up exponentially for earlier people, and more recent data also tends to be better researched and more reliable.)
Or instead of limiting the upload by number of people, I imagine it could also be limited by date, permitting only pages of people born after 1700, which would get us similar benefits while encouraging more recent info. The problem with any gedcom limit is going to be that many newbies don't know how to create limited gedcoms - it's either everything in their program or nothing. So a simple warning may not work, and a programming limit means some people just won't upload. I can live with that, personally, but it's worth thinking about. --Amelia 16:40, 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)

Playing Devil's advocate for a moment, let me throw this in. I suspect that a fair number of people will upload their GEDCOMs with no intention of sticking with the learning curve. They want to publish their tree in the hope that someone researching some of the same people will contact them. They don't necessarily want to go in "whole hog," so to speak. But does that invalidate their contribution? And would we be doing a disservice to the rest of the WR users who might want (or need) the info in that person's GEDCOM if we discourage that upload? --Ajcrow 17:48, 19 June 2008 (EDT)
That's a legitimate purpose, but this is a place for actively working your data in cooperation with others - at least to a basic level of correctness and completeness. Of course nothing is ever really "done", but walking away without a basic pass through your data after upload - no attempt to clean up your own duplicates, merge with other werelate data as appropriate, standardize and correct place names - amounts to burdening the active members of the community without their agreement. We could provide a help page that instructs people on where to get GEDCOM split utilities so they can readily break their stuff up into a piece for upload now and another for upload later, if they remain interested.

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:

  1. not burdensome to the community, and
  2. not disruptive if we decide later to remove them.

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.

Hi, I have subscribed you to my mailing list; sorry but I don't know what caused the problem. --Beth 13:52, 20 June 2008 (EDT)

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) -

FamilyTwigs -- could you explain more particularly what it is that you're finding alarming that you didn't understand before? The one thing that is repeated often here is the terms of the license that permit "your" work to be edited, downloaded, and redistributed, so if that's what's concerning you and didn't get through, that's an additional problem.--Amelia 13:35, 20 June 2008 (EDT)
FamilyTwigs -- something else to keep in mind is that whenever someone makes a change to a page, you can always change it back. In fact, each page has a link to "History," which shows all of the revisions made. --Ajcrow 13:52, 20 June 2008 (EDT)
One good indication of whether a new user intends to work their data, is whether or not they create a user page. If they don't even bother to do that, then we can assume they won't do more. I am not so sure about removing unsourced data, as over the years, I have collected a lot of such data which has later been validated by source information I have found, although it should not be allowed to supercede sourced data. BTW any data that claims AF, IGI, Ancestry.com, wfT and such as a source should be considered unsourced.--Scot 18:39, 16 July 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 may easily be one of those who could/would upload a large GEDCOM without realizing the implications of the work involved. We are used to uploading to sites that don't require further input; so perhaps it needs to be spelled out in more detail up front just what would be expected of someone who wants to upload a GEDCOM. I've been holding back my main data base until match/merge but maybe I need to learn more of what's expected. --Janiejac 16:16, 17 July 2008 (EDT)
I would think that if you upload XYZ pages, that you'll go through each of them sanitizing place names to make sure they point to something in the place database. Further, when you find family names that have an index greater than 1, you'll check to see if there's a duplicate of the family already here. When you find duplicates (and you will, especially if you have any colonial genealogy), merge them or get help merging them with the pages that are already here. There's been talk that Dallan may be able to automate some aspects of that process on the upload side, but I don't see how that would ever be a perfect/complete solution. You'll still need to visit your own pages and tidy them up. Maybe others disagree, but that's how I see it. --Jrm03063

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)

[add comment] [edit topic]

Color-Coded State Maps [7 July 2008]

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)

Image:TestImage.gif


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)

Beth, I also checked, and no terms of use. So I sent an email to determine if there's a problem in using the images. I'm sure there's not, otherwise they'd not have the thing out there for people to use. But its always good to check.
Bill, did you receive an answer regarding the usage of the map images? --Beth 12:26, 7 July 2008 (EDT)
Nope! But its a collegiate site, and the responsible party may not be around during the summer. I'll ask again in the fall.

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)

[add comment] [edit topic]

Data Consistency in Werelate [2 July 2008]

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)

Consistency checks are something that I'd like to implement in the future, so I encourage anyone who is interested to get involved. User:Jrm03063, could you perhaps create a "WeRelate:" page from the contents of this page? You have to be an administrator to edit someone else's user page, so making this a "WeRelate:" page would allow others to edit it. Thanks!--Dallan 16:30, 1 July 2008 (EDT)
Done, find it at WeRelate:Functional Specification for Data Consistency Verification --Jrm03063 20:07, 1 July 2008 (EDT)
[add comment] [edit topic]

Image Markup [1 July 2008]

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)

Image:Thompson's Creek Settlers Markup.jpg

It's a known deficiency that's on my todo list. The technical reason is that the annotations aren't part of the image itself; they're actually stored in the text of the Image page. When you include the image on another page you're including just the picture. What needs to be done is I have to read the annotations from the text of the Image page and add them to the image when the image is included on another page.--Dallan
[add comment] [edit topic]

Trees as a notepad or checklist [3 July 2008]

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)

[add comment] [edit topic]

How is a Family Page named before the wife is added? [2 July 2008]

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)

[add comment] [edit topic]

Family page and named spouse and unknown spouse [3 July 2008]

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)

[add comment] [edit topic]

Happy 4th and WeRelate once again in the top 101 [4 July 2008]

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)

[add comment] [edit topic]

Person page - adding spouse of Family [14 July 2008]

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)

Hi beth. I don't know that it needs to be redesigned. Seems like it works they way a reasonable person would expect it to. What might help would be a different label. "Spouse of Family" and "Child of Family" might be a bit confusing, and lead people to putting in the wrong information. I remember the first time I looked at this entry system I had to pause a moment to figure out what was meant. ie, "Does this mean I should put in the children of this person" or does it mean "identify the parents for this person". Intuitive is always better, and this isn't what I'd call intuitive--reaonable, rational, but not intuitive. The fact that this is set up to describe a "Family" as a basic card type is I suspect novel, and could use a little more immediate description of what is intended. What's there now is probably the most precise and concise way of saying what's needed, but it's not the terminology people expect. Would "Identify parents" work better? I'm not sure, as I don't routinely use this aspect of we relate.

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)

This is causing all kinds of family page problems with one new user. Hopefully this is just isolated case; but if we have an influx of new people making the same kinds of mistakes the administrators are going to be hard pressed to fix all of the pages.

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.

Also if you are creating a new family page; why would you need to select an existing family page? --Beth 08:44, 5 July 2008 (EDT)
Not being one who uses this approach, I'm probably not the best person to answer, but I'll take a shot at it anyway. I think the short answer is that there are a number of ways you might have arrived at this point. Depending on the past choices that have been made you might or might not have already created a family card for a husband and wife pair---but you haven't actually created the person cards for them as yet. So, when you create the person cards, you need an option to attach them to the already existing family card.
On the otherhand, you might be starting from scratch on this family, and have previously created the husband or wife, but not the family card. In this case you need an option to create a family card from scratch.
On of the fun things programmers get to do is account for every dad-gum possibility that someone might encounter when using the system. That means they have to think of everything, including ways of interacting with the program that are different from the way many users would approach it. Different is not bad, just different, and the programmers have to accomodate those differences. This is an example of that. Q 09:36, 5 July 2008 (EDT)
Okay Bill, first I am going to attempt to improve upon the tutorial by uploading images of screen shots and see if that helps. --Beth 10:19, 5 July 2008 (EDT)

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)

Dallan, I would prefer to have under add spouse; add new person or add existing person. Although I realize that we cannot currently add an existing person without entering the person and their index number. --Beth 21:12, 11 July 2008 (EDT)
We could keep the "add new family" link.--Dallan 03:19, 15 July 2008 (EDT)
[add comment] [edit topic]

Source Citation Details [10 July 2008]

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)

[add comment] [edit topic]

Spam? [15 July 2008]

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)

[add comment] [edit topic]

Current status of various projects [29 July 2008]

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

Special:Browse

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)

[add comment] [edit topic]

Google Books - Sources [24 July 2008]

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.

Google Books is a repository. If a book (which is a source) can be found there, the link to the book should be listed in the repository listing (e.g. here).--Amelia 18:12, 19 July 2008 (EDT)
Debbie, the browser Firefox has a spell checker. You can download from here [3]. --Beth 19:07, 24 July 2008 (EDT)
[add comment] [edit topic]

Cluuz [29 July 2008]

Here's a link to very interesting beta search engine site.

Cluuz

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)

Q, is this working? I tried this using Firefox and I did not get any results. I don't mean zero matches; there were no results displayed. By the way Dallan's new search engine is installed. --Beth 19:28, 24 July 2008 (EDT)

It works for me (maybe it was down earlier). The link graph is cool.--Dallan 18:31, 29 July 2008 (EDT)

As I recall from my PERL programming days, there's a canned routine for generating such displays. I've not seen it implemented previousy (assume this is probably a redo using PHP). The item seems neat, but you need a large data rich site to get any use out of it. WeRelate would qualify as "data rich". Some County web pages (e.g., Russell County GenWeb) are also extremely data rich, and this works effectively on that site. Sites like Ancestry are compartmentalized, and much of the data is only served up on demand, so it doesn't work well there. But on data rich sites, it could be very useful. Q 18:40, 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)

As elegant as this is, there are many other things I think would be needful, and I would, I think, deserve higher priority. In the meantime, the CLUUZ site itself seems sufficient unto the need. And as I said, I'm not entirely sure how useful this will prove. Q 22:38, 29 July 2008 (EDT)
[add comment] [edit topic]

Living Coker (12) replacing with actual person [29 July 2008]

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)

Wouldn't it depend on why they had a) a "death date" and b) a notation that this card was for a living person? This, and variants is a frequently seen error on Ancestry family trees. Sometimes you;ll see folks with the notation "living" but DOB's in the 1500's etc. Obvious no longer amongst us, but still with the notation "living person". I suspect from that that this is due to a preference being set to ALWAYS assume the person is living, unless noted otherwise. Then they forget to note otherwise as they are adding hundreds and thousands of cards to their family tree via GEDCOM dumps. To me, this is simply a symptom of not thinking about what they are doing, but just harvesting names for their tree. I believe that for those showing this and other symptoms, the actual data about the person is of only secondary interest---its adding as many connection that you can find that's important. Q 08:00, 28 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)

[add comment] [edit topic]

Best way to ID accidental duplicate pages for later fix [27 July 2008]

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)

[add comment] [edit topic]

New Search Functionality [29 July 2008]

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:

Person:Daniel Boone (23)
Person:Daniel Boone (25)
Person:Daniel Boone (26)
Person:Burwell Boone (1)
Person:Daniel Boone (27)
Person:Daniel Boone (28)
Person:John Boone (35)
Person:Daniel Boone (29)

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)

Hi Q, I have reused some of these "ghosts"; when helping others rename their pages. --Beth 11:59, 28 July 2008 (EDT)
Yes, I think you and I have discussed this before. I think you're re-use of the real estate is the best choice, but there might be reasons for keeping them that we don't know about. Just putting the question, so to speak to Dallan. Q 12:04, 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)

Hi Ronni, I could be wrong, but I'd think you'd want the priority to be given to persons whose card reads as stated, then persons who have as an AKA the same name. Names not actually being searched, but which for various reasons give you a match, should, I think, appear a lower depth in the search. Yes, the instance you cite would make things harder, but the instance you cite would be much less common than someone simply looking for Daniel Boone. The priority should, I think, go to what serves the greatest number.
Also, the problem you point out would be largely eliminated by using any of the additional fields (e.g., parents, spouse, DOB, DOD, whatever) provided to narrow a search.
With a common name you could expect to get a hundred hits or more. In the future, as the database builds, this will become much more problematical. Right now you get about 120 hits for a common name like "John Walker". Some day I expect you'll get literally thousands of hits for that name. At that point, there's a substantial penalty to be paid for retrieving names that don't match a search exactly. From my perspective, what's needed is a system that
a) gives a well ordered list for what's being searched. If the search is for "John Walker" than hits for John Walker should appear beforehits for John Alexander Walker; John Walker before Alexander Walker,,etc, and hits should be in proper "human" numerical sequence