WeRelate talk:Watercooler/Archive 2009

Watchers

Topics


Archived single-topic discussions ending in 2009



Update on merge statistics [28 July 2009]

Just a quick update on merging: as of last night, nearly 15,000 merges have taken place since October 14th (in addition to several hundred before then), resulting in roughly 18,000 families and 40,000 people being merged.

Approximately 100 people have performed at least one merge and 19 have performed over 100 merges. Of those, 6 people have performed 500-1000 merges: Amelia.Gerlicher (665), CTfrog (568), Jillaine (694), LSnellgrove (540), Scot (523), and Susan Irish (883), and 3 people have performed over 1000 merges: Bergsmit (1719), JBS66 (1532), and Jrm03063 (4546 merges).

Great job everyone!

I'm busily working on the new GEDCOM upload process with merge-during-upload. I expect to have it ready around the end of next week.--Dallan 10:23, 28 January 2009 (EST)


Cool! Thanks for posting these. Wow! I want to join the 1k+ club. How close am I? (And can I determine this myself?) Thanks! jillaine 11:39, 28 January 2009 (EST)
You're close :-). I just added counts next to everyone's names in the list above. There's no way to find out for yourself the total number of merges you have done, but if you want to see how many merges you have done since January 16th, select Logs from the Admin menu, then set the "Logs" drop-down to Merge log, enter your user name, and click Go. By the way, Msscarlet1957 (352), Jeffhomes (451), and Bevbh (464) are all pretty close to making it into the 500+ merges club :-). I'll update the total stats periodically.--Dallan 14:36, 28 January 2009 (EST)

13 February update

As of right now, approximately 18,500 merges have taken place. Twenty-one people have now performed over 100 merges. Of those, 5 people have performed 500-1000 merges: Amelia.Gerlicher (665+35=700), CTfrog (568+35=603), Jillaine (694+31=725), LSnellgrove (540+156=696), Scot (523), and 4 people have now performed over 1000 merges: Bergsmit (1719+1434=3153), JBS66 (1532+62=1594), Jrm03063 (4546+539=5085), and Susan Irish (883+452=1335).

Thank you everyone!


8 April update [8 April 2009]

Here's an (overdue) update: Approximately 26,400 merges have taken place since Oct 14 last year, resulting in nearly 80,000 people being merged! 147 people have performed at least one merge, with 25 people performing over 100. Of those, 6 people have performed 500-1000 merges: Amelia.Gerlicher (988), CTfrog (617), [[User:Delijim|Delijim] (919) welcome to the list! Jillaine (839), LSnellgrove (706), Scot (523), and 4 people have performed over 1000 merges: Bergsmit (5658), JBS66 (2636), Jrm03063 (5864), and Susan Irish (2207).

Great job everyone!

BergSmit and Jrm03063 are going to town!!! whoo hooo!! That's great. And... Dang. I'm still short of the 1k club. Dallan, how recent are these stats? I've been spending the last couple of hours merging. This is great incentive. (C'mon Amelia and Delijim!!! you're almost there!!!) (See? What I tell ya elsewhere about sharing data? ;-) jillaine 14:18, 8 April 2009 (EDT)
They're from a few hours ago. Let's see - you're at 896 now :-)--Dallan 16:36, 8 April 2009 (EDT)

27 May update [27 May 2009]

Here's another update: Approximately 33,000 merges have taken place since Oct 14 last year, resulting in over 100,000 people being merged! 159 people have performed at least one merge, with 25 people performing over 100. Of those, 3 people have performed 500-1000 merges:

and 9 people have now performed over 1000 merges:

Thank you everyone! The number of duplicate families has dropped by 33% since April 8th, from 21,000 to 14,000!


28 July update [28 July 2009]

Nearly 5,000 additional merges have taken place in the past two months, resulting in approximately 15,000 people being merged! 17 more people have performed at least one merge (not counting the merging during gedcom uploads that is taking place), and 5 more people have performed over 100 merges:

The number of duplicate families has dropped by over 20% since May 27th, from 14,000 to 11,000! THANK YOU to everyone participating in this project! --Dallan 11:34, 28 July 2009 (EDT)

Question: If so many folks have been merging dups the past two months, why are almost none of the above names on the volunteer log? Did the IRS say we don't have to do that anymore? --Mike (mksmith) 18:03, 28 July 2009 (EDT)
"Have to do it" or "would like us to do it"? I used to keep track but I lost interest in worrying about that. I'm sure I average 100+ hours a month, but who's paying attention? --Jrm03063 18:09, 28 July 2009 (EDT)
"Would like us to do it" is correct. Please update the volunteer log with the time you've put in (even a rough estimate) as you think about it. Thanks! :-) --Dallan 00:55, 31 July 2009 (EDT)


Blank Page on Merge Candidate [1 January 2009]

On my list of potential duplicates, I have this link:

http://www.werelate.org/w/index.php?title=Special:Compare&ns=Family&compare=Johann_Bohnenberger_and_Elisabetha_Bohnenberger_%281%29%7CJohann_Bohnenberger_and_Elisabetha_Bohnenberger_%282%29

When *I* pull it up, I get a blank page. Help, please. jillaine 12:20, 21 December 2008 (EST)

For this one, you have a do not merge instruction on Johann Bohnenberger and Elisabetha Bohnenberger. I didn't check the others, so perhaps that's the problem. --Ronni 13:45, 21 December 2008 (EST)

Here's another one that does the same thing. Both are from the same family tree (whereas my other dupes that are working are from a different family tree/gedcom).

http://www.werelate.org/w/index.php?title=Special:Compare&ns=Family&compare=Male_Unknown_and_Agnesa_Unknown_%281%29%7CMarx_Schneckenburger_and_Agnesa_Unknown_%281%29

jillaine 12:38, 21 December 2008 (EST)


And a third. Also from the same gedcom.

http://www.werelate.org/w/index.php?title=Special:Compare&ns=Family&compare=Marx_Schneckenburger_and_Agnesa_Unknown_%281%29%7CMale_Unknown_and_Agnesa_Unknown_%281%29

THis makes me think that there's something wrong with my GEDCOM. This is the Family Tree of Jillaine Smith (vs. the Family Tree of Philip Bogdonoff, which is also mine).
jillaine 12:40, 21 December 2008 (EST)

Something is wrong with the compare screen I think. I'll fix this when I return on Thursday.

This bug is fixed now.--Dallan 16:43, 1 January 2009 (EST)

Adding pages to my Watchlist [24 February 2009]

I recently linked my family line to an established line on WeRelate. I had been Watching my line, but when I linked to the established line I am not automatically watching the new ancestors. The same problem happens with my trees (new lines are not added to my tree), but I'm not worrying about that too much since I know trees are probably going to be replaced. Is there a method I'm missing about how to add this new line of ancestry to my watch list, or do I need to add each page manually?--Jennifer (JBS66) 11:44, 29 December 2008 (EST)

This is one of the problems with the "tree" concept that Dallan is wanting to change. His current proposal is to use "tags" instead. See Is it broke? where the last paragraph summarizes Dallan's thoughts. In the meantime, I don't know of any way of adding the pages other than doing it manually. --Ronni 12:57, 29 December 2008 (EST)

There's no way to do it right now. I'm working on a couple of approaches for the future. One is a way for you to at least see which Person/Family pages you are watching link to Person/Family pages you are not watching. Another is to include an option when you add a Person/Family to your watchlist to add all direct-line ancestors as well. I'm not sure the direct-line ancestors option would be sufficient. I could also add option to include the children of direct-line ancestors. However, this quickly becomes a slippery-slope with more and more complex options: also include the spouses of those children, and maybe also the direct-line ancestors of the spouses.

My question is, if you had an option to include all direct-line ancestors of a person, what other options along these lines (if any) would you want)?--Dallan 14:54, 29 December 2008 (EST)


I just finished a new special page that should help: Select "Trees" from the "MyRelate" menu, and then click on "related pages". This will show you a list of pages not in your tree that pages in your tree link to. Choose a namespace of Person or Family to see just people or families. You can then decide which of these pages to add to your tree.


I noticed that I had failed to respond to the above question. I would like to be able to tag/tree all direct-line ancestors of a person. By this, I mean all of the people that would appear on a pedigree chart. I know that I can add them individually through FTE, but I want to be able to take an entire line from a certain point and then send that line to a relative for them to watch. I am less interested in including children or other spouses of ancestors. Currently, I have relative that may be interested in participating with WeRelate, but I have no clear-cut way to provide them with a tree that begins from their vantage point.--Jennifer (JBS66) 08:31, 24 February 2009 (EST)


Request for Brick Wall "code" [3 January 2008]

Yesterday, I started drafting a "brick wall" template for separate pages that people could use to post and share "brick wall" challenges. Then I slept on it and woke up with a better idea:

What about a {{brickwall}} code that you can use to tag certain pages (people or otherwise), that then generates a Special:Brickwalls page that is available for all people to peruse. Once the brick wall is solved, then you simply remove the {{brickwall}} code from said page.

I suppose an alternative would be to use a Category:Brickwall. Would that accomplish the same thing?

jillaine 08:02, 30 December 2008 (EST)


I read your comment but I was a little confused. What problem are you trying to solve?

Are you trying to create a list where people can advertise their brick walls? Is a user expected to browse this page listing potentially thousands of various brick walls, and from the summary listed, pick one and work on them to help other people?

Personally, I don't suspect such a list will accomplish much. If a user knows something, they probably uploaded it in their GEDCOM and you got notified. If they don't known anything, knowing that person represents one of your brick walls is not all that interesting to them. So the only situation this appears to address is the user who has the information, but is disinclined to input it. I would guess that this person may also be disinclined to scan the list.

I think one can accomplish just as much by adding a simple comment to the Talk page or Personal History section about what is known, what dead ends have been pursued, etc. A person sharing a research interest in a person will scan the page and see the comment. It will be much more obvious in this situation whether they can help, and this is likely to be the type of person that will actually get involved. --Jrich 11:07, 30 December 2008 (EST)


Once we had a "Help Needed" category. The idea was that people could add pages to this category if they needed help. We eventually removed it due to lack of use, both from people putting pages into the category but more-so from a lack of people browsing the category. I think a comment in the personal history section of the page is a better idea.--Dallan 19:53, 3 January 2009 (EST)


How to merge pages not in list? [31 December 2008]

Hello All,

I am back again. I am trying to locate my duplicates. I found two pages that I need to merge. They are not in the new list though. I tried to look for the current instructions on how to merge these pages. No luck. They are the same person. So how do I now merge Person page: Fanny Williams (21) to Fanny Williams (19)?

Thanks DFree --DFree 21:08, 30 December 2008 (EST)


Hello All,

Sorry! I think I figured it out. You can disregard this message.

Thanks DFree--DFree 21:16, 30 December 2008 (EST)


Status of the Digital Library? [16 January 2009]

What is the status of the digital library? I keep seeing references to it, and I managed to find it, but

a) it had a title that made it look like it was not part of werelate, but part of an African project or organization

b) when I attempted to login, it did not recognize me. It told me to use my werelate pwd, which I did, and it would only bounce me to the werelate.org login screen no matter how many times I tried. I could get into werelate just fine, but not the DL.

made me think it's not ready for prime time yet.

THnks. jillaine 13:26, 2 January 2009 (EST)


I havn't added anything to it for a while, but I did put a couple of PDFs in when it rolled out. They are each associated with werelate source pages and I just looked them up successfully. You can take a look at Epsom New Hampshire Cemetery Book, and transit the link to the copy in the digital library. You'll see a page that indicates that you're in the Low-Country Africana project digital library (which may not be correct), but you'll also see a link for the PDF file. I just hit it and saw the content as I would have hoped.--Jrm03063 13:36, 2 January 2009 (EST)


I created the digital library last Summer for Africana Heritage. I plan at some point to integrate it into WeRelate, but other things have had higher priority. Realistically, integrating it into WeRelate probably won't happen for maybe another year. Long-term, the goal of the digital library is to be a place where genealogical societies can host their materials on-line for free. Each society would be able to provide their own colors and logo. Currently it doesn't have the capability to give every society different colors and logos, but Africana Heritage is the only society using the website so we just went with their colors and logo for the entire site.

Earlier I had also thought about the digital library being a place where people could upload source documents and images, but recently I've been thinking that it might instead be simpler to extend the wiki software to allow this: have MySource pages link to the images or documents involved.--Dallan 19:53, 3 January 2009 (EST)

I've been making extensive use of the Digital Library, and find it well suited for my purposes (apparantly the only one doing so, other than Africana Heritage. One of the advantages here is that you can store source materials as transcribed without concern that someone might choose to modify a transcription so that it corresponds with what they believe it should say. (Yes, people do that. They KNOW the right answer, so if something conflicts they do what they see as the helpful thing and amend an original record just to help out other "less knowledgable genealogists. I have, for example, an revolutionary war era bible record where someone didn't agree with a particular DOB---so they changed it from 1731 to 1737---this has circulated for years in photocopies, and the amendation is obvious---but it looks as though it was made by the original recordist---when you see the original its obvious this was done by a later hand, because the amendation was made in blue ball point pen---something rather uncommon in a Revolutionary War era document.)
In any case, the Digital Library is something that I think has considerable utility for my own work. I rarely make use of the MySource pages anymore---(mostly because I've still no clear idea what constitutes a "MySource"). By having the transcription or image housed in the Digital Library I can refer people to it in an article in a way that's more secure than if it were on a "MySource" page. Effectively, this removes it from the category of "ephemeral source", so that others can see exactly what I was referring to, without concern that some later author might have adjusted it for either good or bad reasons. Q 11:35, 10 January 2009 (EST)
I think for people that don't mind going to the effort of learning a new tool, the digital library should work fine. I'll continue to make it available to individuals who want to use it.--Dallan 11:33, 16 January 2009 (EST)

I had a couple of PDF files that I uploaded and linked to corresponding werelate sources. There is some question however, as to whether there's value in having different ways/places to archive stuff. From the site's perspective, disk is disk so who cares? I do wonder though, whether key reference material needs more protection than a wiki would directly offer. I sort of figured that the digital library existed to provide that. On the other hand, that's a pretty narrow reason to continue to support the software for a whole site. I guess whatever is easiest/cheapest to maintain.--Jrm03063 12:39, 16 January 2009 (EST)


I plan to continue to run the digital library for genealogical societies who want to upload material, so it's not going to be just for individuals who want to use it. What the library has going for it that the wiki does not is the ability to grant various types of access to specific indidivuals for specific collections. So a genealogical society could specify who could upload to their collections, who monitors uploaded items and reject/approve them before they're published, who gets to view their collections, etc. It would be difficult to modify the wiki to fill that need. But it wouldn't be difficult to modify the wiki to say that only the owner of the MySource page could edit it, or only the original image uploader could upload a new version, or to add the ability to upload PDF's. So lately I've been thinking that for most people, rather than asking them to learn a new system (the digital library), it may be easier for them if I made a few tweaks to the wiki. I don't know for sure; I'm still thinking about this. But the digital library will certainly be there.--Dallan 13:36, 16 January 2009 (EST)


We should discuss Rev. Carter (page naming) [19 January 2009]

One of the pages in my Watchlist got its name changed to Person:Rev. Thomas Carter of Woburn (1). The justification was that there were several Thomas Carters in colonial times that were confused. On one hand, this makes this Thomas readily identifiable and it has a nice appealing user-friendly quality. We also already have non-conventional page titles for royalty and others with no last name (the Wikipedia title rule). But on the other hand, this rather drastically changes the rules for "normal" people and substitutes a judgement call for a hard and fast rule. The point of the (1) behind the name in the first place is to distinguish between people of the same name (making the (1) here redundant). And this change could be applied to many people for many reasons. Person:Steven Cleveland (1) should be renamed Person:President Grover Cleveland, for instance. And while this might even be fairly easy to decide for most men, what do we do with people not famous by their birth name (like many women)? A genealogy site really should not start referring to women by their married names, but that would be the name by which many famous women are most readily identifiable. So rather than have people doing this under the radar, I thought such a drastic change should at least appear here for discussion.--Amelia 14:13, 2 January 2009 (EST)


Great question, Amelia. I'm the renaming culprit and did it for the reasons you said. I also placed more information about the four contemporary Thomas Carters here: Carters in Massachusetts, which will also show how I renamed the other three-- for the same reasons. My apologies if this was against protocol. I figured that the clarity of distinctions was more important. And in looking at this, I see I used parentheses inconsistently, but before I change anything further, I'd like to hear more discussion about this topic you've raised.
One option is that we keep the page title simple (Thomas Carter (1), etc.) but use the Prefix and Suffix fields for the Reverend and (of Woburn);
Another option is that we keep the page title simple, not use suffix at all (for this purpose), but place a link to the Carters in Massachusetts page prominently on the top of each Thomas Carter page, so people can see a page that distinguishes them.
I just think it's important to distinguish them clearly in some way.
jillaine 14:55, 2 January 2009 (EST)

An interesting question. Definitely understand the need to be able to associate a particular article with a specific individual in a way that others can immediately see whose being discussed. "By names" (of which honorifics like "Rev." are an example) are a great way to do this, but can lead to problems. I've seen them used on other genealogy wiki's, but don't think the experiment worked very well---made it hard for search engines, and the like to locate articles, etc. And since by their nature "bynames" are often arbitrary, they don't provide that much of a cue except to those already well versed in the family history. My since is that they basically end up cluttering up the title with minimal advantage---better a simple title than a complex one.

Part of the problem might be alleviated in other ways---in particular, I can think of some improvements to the search function that would help resolve this. The recent improvements to this function were very very helpful, but there's still some room for improvement. For example, currently, if you are searching for a particular name (e.g., "Hugh Linn") you'll get a list that's ordered by a criteria that's not (I think) optimum. In the Hugh Linn example, what you get are entries for

Hugh Linn (1)
Hugh Linn (2)

followed by

Hugh MacLean (1)
Hugh Morrow (3)
Hugh Percy (1)...

What you don't get is

H. Linn (1)

Or what I should say is, you get it buried deep down in the 3000+ list of entries. What's happening is that the search engine is prioritizing on "Hugh", and only secondarily looking at "Linn". Needs to be the otherway around, perhaps.

No arrangement is going to be fully satisfactory. There are always going to be combinations where useful results get buried deeply. The hazards of a search engine. But I suspect that focusing on the surname as the first priority will be of more use to more people. (Interesting enough, the current version also pulls up first "Hugh Linn (1)" even if you search on the "Lynn" spelling---but the actual spelling sought ("Lynn") is buried deeply in the sort list.

I believe this would help solve the problem at hand by simply making it easier to find matches for specific names.

Something else that might help is to have a more compact display of search results. as it stands a search yields a substantial amount of information (good), but the information is displayed across multiple lines. For example

Person:Hugh MacLean (1)
Name: Dr. Hugh MacLean
Birth: 30 Jan 1878, Glasgow, Scotland
Death: 1 Jan 1958, La Jolla, San Diego, California, United States
Parents: Archibald McLean and Margaret Nairn (1)
Spouse: Hugh MacLean and Susan Weir (1)

If you are lucky that your target comes up early on in the listing (by no means assured, unless you are explicitly searching for "Hugh MacLean"), but if you search on something a bit away from that (e.g., "Hugh McLean")---and "Hugh MacLean" would be buried deep. What would help here is if the information was arrayed on a single line. Then you would get many more entries on a single page, making scanning those entries much easier. Would not fully eliminate the problem, but would simplify things a bit.

Also, if the data for each entry were ordered left to right (rather than vertically), then you could more quickly compare different entries to see which was the best fit. Hard to get all of that into a single line. Ancestry solves that problem by giving you fewer data elements to work with. Even so, I htink their approach works fairly well.

Q 12:18, 10 January 2009 (EST)



There is a field for adding a title already, and "of Woburn" can be somewhat arbitrary. Some people commonly referred to as "of xxx" sometimes were neither born nor died there. Thus I think this kind of title is a mistake. If people don't already know enough about Rev. Thomas Carter of Woburn to recognize them by birth and death, perhaps Rev. of Woburn won't help much either. Also when do you stop? For those individuals that are differentiated by their spouse or father, do we start saying, "Abigail Smith, spouse of John Adams", etc.? Or see the excerpt from Source:The Libby family in America, 1602-1881 about the trouble identifying all the John Libbys in Maine. At some point, you have to break down and read the page, and trying to ensure that the title provides a complete identification is probably not an acheivable goal. --Jrich 14:54, 2 January 2009 (EST)

JR, Well, I wasn't familiar with Thomas Carter, Rev. of Woburn, but I do have Thomas Carter of Charlestown in my tree-- direct-line ancestor of my husband. While I was cleaning up my own data, I checked for dupes and came across all these contemporary men. I realized I needed to learn more about each of them to distinguish them. And I figured-- as I frequently do-- that I'm probably not alone in needing to understand these distinctions. Hence the results you see.
But as I said earlier (above), if we can find a way to help people distinguish them without using the naming model I used, fine by me. jillaine 15:03, 2 January 2009 (EST)
I thought of another reason to use Page Titles like this-- at least while we're merging madly. It could be very easy to merge at least three of these four men if there wasn't something to easily distinguish them. jillaine 15:05, 2 January 2009 (EST)

While I hate the convention, I've seen wikipedia use forms like <name> (born <year>), <name> (died <year>), and <name> (<year>-<year>). I've also observed the practice, for "wikipedia" people, of naming the werelate page as it appears in wikipedia. My thinking is that the werelate page (and preferred name) should go by the name most commonly used in the available research (wikipedia being pretty common). We can fall back to general conventions when there aren't existing or line-specific naming conventions for folks.

For example, a line I've worked on has three men named John Tuttle, the first being father of the second and the second being father of the third. For whatever reason, they did not refer to themselves as Sr, Jr., and II in their time (at least not in any consistent way), so applying it after the fact isn't quite right. No one even knows the name of the first John Tuttle's parents, so who knows if it would be proper to call him Sr.? In the genealogical references published subsequently, some disambiguating short-hand terms have come into common use. "John Tuttle", or "Shipwreck John" for the first (ironically, even though there is only a family tradition - and no proof - that the first John Tuttle was a survivor of the Angel Gabriel wreck). "Judge John" for the second, and "Ensign John" for the third (even though Judge John Tuttle was once an ensign and was referred to by that title in some contemporary documents). In any case, folks with any familiarity with the research on this line are clear on what is meant by "Shipwreck John", "Judge John" and "Ensign John".

Not sure whether either of these will help in this situation, but I'm a strong believer in collective good faith best judgement, so don't worry if what you do at least makes sense to you!--Jrm03063 15:41, 2 January 2009 (EST)


Here are a few additional thoughts:

  • We need to depart from the usual page titling standard for people without surnames. Adopting the Wikipedia title in these cases seems like as good a practise as any.
  • Women need to be titled according to their maiden name.
  • Titling pages according to a name that only a few people know about seems like a bad practice. I don't think we'd want to see "Person:Shipwreck John" as a page title if only a few people knew that the first John went by that name.
  • You can certainly add alternate names for these alternatives. So "Shipwreck John" could be an alternate name for the first John.
  • You could also create redirects. So you could create a "Person:Shipwreck John" (without an index number) that redirected to the correct John Tuttle page if you wanted.
  • There's nothing in the system that requires pages to follow the standard anymore. (It helps in a few odd cases, but they're pretty rare.) Following a common convention is simply something to help the people using the system.
  • One idea I'm a believer in is the "principle of least surprise," which says that you should adopt convensions that at least don't take people by surprise. For that reason continuing with the usual convention coupled with redirects and/or alternate names may be a good idea.

--Dallan 19:53, 3 January 2009 (EST)

On redirects: how would this be used? Pages that are redirected don't show up in search or categories (for very good reasons), so I'm wondering if there's some other feature of the system I'm missing that would make this useful?--Amelia 17:04, 4 January 2009 (EST)
If you wanted, you could use the redirect in a link when referring to the individual. I agree the use is limited.--Dallan 14:26, 5 January 2009 (EST)

Upon further discussion, line specific names may not be a great choice after all. If a name isn't unique enough to stand on it's own as a wikipedia page, then it probably doesn't rate as a special name in werelate. If, on the other hand, there is a special name recognized for the person in wikipedia, we don't have to discuss the issue further because we want to follow that convention rather than introduce another.

I've spent so much time lately with medieval nobility, it's starting to feel like everybody is the earl or duke of something....or maybe, the duke of earl!--Jrm03063 21:03, 3 January 2009 (EST)

"If a name isn't unique enough to stand on its own as a wikipedia page, then it probably doesn't rate as a special name in werelate."
But werelate is not wikipedia. We're not likely to see all four contemporary Thomas Carters in wikipedia (although the Rev. of Woburn is there). For people doing research into genealogy/family history, werelate goes much farther than wikipedia. And naming here, in the context of family research, is far more important than over at wikipedia (imho). jillaine 21:36, 4 January 2009 (EST)
Would adding Rev. Thomas Carter of Woburn as an alternate name, or adding "Reverend" and "of Woburn" as a name prefix and suffix respectively to the primary name, address the problem?--Dallan 14:26, 5 January 2009 (EST)
That would probably be a decent compromise, but does not really address my concern that when people are searching and/or merging, they won't be able to easily distinguish the different (in this case) Thomas Carters. But I could live with this solution. jillaine 23:16, 8 January 2009 (EST)

Okay, I think it's possible that my newbieness may have been at fault/play here.

So understanding how certain things work would help me figure out how best to address my concern.

We have

  1. The name of the page -- in this case "Person: Thomas Carter (N)" - this appears at the top of the main body of the page and also in the "blue bar" of the browser.
  2. The name of the person, which is a combo of given+surname - this appears at the top of the left-hand column on the person page.

I think I had assumed that #1 = #2 by default.

And I think this is still the case when the page is first created: the page title (#1) uses the information in #2.

But later you can go back and "rename" a page which will change #1 without changing #2.

This was not exactly clear to me for awhile.

So what I need to know is when are each of #1 and #2 used?

  • Which is searched when typing things into the search engine? (I think it's #2)
  • Which is displayed in search results? (I think it's page name #1)
  • which is displayed in merge activities? (I think it's page name)

What else do I need to understand about the distinction between #1 and #2 in terms of how used on WeRelate?

And having revisited all this again after a week or more "off", I'm still really liking having the distinctions between the early Thomas Carters of Massachusetts clearly visible at the top of the page.

Just sayin'...

-- jillaine 17:51, 10 January 2009 (EST)

I suppose, if that's important for you (and I can see why that would be the case), you could always insert a bit of code in the article space--say something like
<font color=red size=3>Dr. Thomas Carter</font>
and get a nice header for the article
Dr. Thomas Carter
Q 19:04, 10 January 2009 (EST)

But I want the distinctions displayed in search results. So when I search for Thomas Carter and the results come up, I can see the distinctions there. Otherwise, I risk spending a long time clicking through, reading, editing and possibly even merging the wrong people. And I'm still waiting for answers to my bulleted questions above. Thanks. jillaine 08:59, 14 January 2009 (EST)
I suspect that would not work very well. By-names are arbitrary conventions, that may be applied or may not be applied. Different people could easily decide to use different by-names. For example, in the simplest cases such as you point to, someone could use "Dr. Thomas Carter", or "Rev. Thomas Carter", or even "Thomas Carter, LLD". Don't know if those specific bynames apply in this particular case, but they might very well. There is virtually an infinite number of by-names that COULD be applied to any given individual--only some of them are actually used (if used at all) but the large number of variations would, I think, make this more difficult to do than the benefits warrant. There might, I suppose, be a way to do this, but I'd personally prefer that Dallan spend his efforts on some of the larger issues concerning search engines.
I suspect that Dallan is the one who needs to answer your specifics about how the search engine works. To that end you might want to extract your question and place it into a separate topic. Q 11:29, 14 January 2009 (EST)

I just wanted to add a couple of observations. In doing my husband's Dutch genealogy, there are no official surnames before 1811. They followed the system of patronymics, taking their father's name as their last name. So, I can have many people with the same name, within the same generation, and along ancestral lines. Let me provide an example: Halbe Halbesma (in this case, they did have a surname).

  • Which is displayed in search results?
    • Exact Match Search for Person Halbe Halbesma - returns 3 people. Under Name, the full given name that I entered on the first line of names (not alternate names) is displayed. So, if you wanted to add clarifying info to that line (like Jr. Rev...), this is where it shows up a on search. I would have to test to make sure items in the Title prefix and Title suffix fields are also displayed.
  • which is displayed in merge activities?
    • Compare pages prior to a merge
    • Here, the given name, along with the various alternate names are displayed under Given Name and Surname. Again, I would have to test to make sure items in the Title prefix and Title suffix fields are also displayed.--Jennifer (JBS66) 12:06, 14 January 2009 (EST)

Well, I did start a separate topic here about the Search engine, but the more I get into this, reading all your responses, as well as the discussion started by Q about his disambiguation tables, the more I realize that we should come to agreement about the purposes of the various fields. Because I think we're all working from different definitions and expectations of how that field is used. Coming to a shared agreement (if possible) about the purpose of these fields, could answer the question (I think) about the Reverend Thomas Carters of werelate.

Let's start with PERSON pages.

1. Page Title, which until someone tells me otherwise, initially draws from Given Name + Surname. (Does it also add Prefix and Suffix if they are filled out?). One can then go back to the page, and change the Page Title to something separate and unique from the Given/Surname set of fields.

But what is the PURPOSE of the Page Title field? If its primary purpose is to describe the PAGE, then it makes sense to me that it could be edited as appropriate to describe the person of this page. Under this understanding, "Rev. Thomas Carter (of Woburn)" could be appropriate. What is your sense of the purpose of the Page Title field?

2. Surname Field.

3. Given name field.

In my mind, the above two fields (Surname and Given name) are used purely to record the documented name(s) of the person in question. Alternates would be used when documentation exists that includes a different name. In these fields we would keep away from "(of Woburn)" etc. in these fields.
It also seems like these fields should drive the search engine search results/display, but that may be a separate topic that I started earlier.

4. Prefix

5. Suffix

These last two contain documented(?) titles (Reverend, Jr., III, etc.) (I bet they're not consistently used this way.)

I look forward to discussing this with you all. jillaine 14:26, 14 January 2009 (EST)

Possibly this is semantics, but sometimes semantics are important. Page title Field?. I'm not sure there is such a field at least not one accessible to us. The edit page does have places for Surname, Given Name, Prefix, Suffix inputs , which could be described as a "fields", (technically, they are "input boxes"). I suspect that what appears at the top of the page is created on-the fly when the page is created. There may be a difference in how this is created depending on the manner in which the page is triggered.
Yes, Page title Field. And we *do* have access to it. It appears to be initially created by adding Given and Surname fields together as someone later describes. And after this creation, we have direct access to it through the RENAME PAGE command. jillaine 20:47, 14 January 2009 (EST)
I believe there's a misunderstanding there. Access to a "field" is usually something that can be modified. The only thing that we can modify is the information in the text boxes and input boxes. I supposed there's a database somewhere on the server that contains this particular information; but in anycase we can't access it. We can see what's presented on the page, but not the field itself. Its conceivable that its on the fly, reassembled on demand from the information in the input boxes---but that does not appear to be the case---as you can change the content of say the surname input box, and the page title remains unchanged. But in anycase, technically, no we don't have access to the field; we may be able to see it on the page, but we can't change it directly, except by renaming the page. In anycase, when you point to something called the "title field" there's nothing on the page to tell someone what you are referring to. I'm guessing its the persons name in the left hand sidebar, but I don't know that. Q 21:01, 14 January 2009 (EST)
  • If you go through the "Add" function, you get a page with input boxes for given name and surname. no Prefix or suffix, let alone middle name or by-name.
  • If you go through the old standby of creating a link to a non-existent page (ie, by putting the page title between square brackets, and adding the namespace, and an approrate index number) it seems to parse the input more or less correctly, and create a page with the Surname in the surname input box, and given name in the given name input box. If you include something else in the title the system does other things---which I've observed but have not explored in detail.
For example, I created a page to test this for "John Jacob Smith". The system parsed that by putting "John" the given name input box. The Surname input box got "Jacob Smith".

Interestingly enough, when I used the "Add" function and gave "John Jacob" as the first name, and Smith as the surname, the page came out "John Smith (801). [I will not be doing a disambiguation page for "John Smith"]. The middle name got completely lost in the page TITLE, but under the left hand sidebar, under "person Information" his name appeared correctly, as "John Jacob Smith".

Seems like I've seen this "middle name" problem discussed.

In anycase, how the search engine would handle these two creations of "John Jacob Smith" has its interesting features. If you search "John Jacob Smith", with "unwatched" checked, and "exact match" not require you get a listing of 20K worth of hits John Smith's---I assume that Jacob is in there someplace very deep, but I'm not going to go through 30K entries to check that.

If you search for "John Smith" with "unwatched" checked---you get a listing that looks similar to the one for "John Jacob smith"---but with about 23K worth of hist.

If I do those searches with "watched" checked you get a shorter listing of 29, but John Jacob Smith in any form doesn't appear. Possibly there's a lag time before new pages appear in the indexing system. Q 17:01, 14 January 2009 (EST)

The search engine behavior is interesting, but may we please keep this focused on my recent set of questions which is about the purpose of the various fields? Thanks. jillaine 20:47, 14 January 2009 (EST)

Here are the purposes of the various fields as I see them:

  • Page title: every wiki page has to have a unique title. For most people (people with surnames or who use patronymics), I'd prefer the page title to be simply First-givenname Surname (index-number). The more we include in the title the more people will want to rename it when they disagree on whether Sr should be part of the title, or when they find a middle name, or when they change a birth year, etc. And an overabundance of redirects can cause problems in certain areas. If we leave these extra pieces of information out of the title, the fields can be changed on the page without needing to rename the page title. Automatically renaming the title when a first givenname or surname changes is on my todo list, just not very high.
  • Given name field: is used to store the given name and middle names of the person.
  • Surname field: is used to store the surname or patronymic name.
  • Title prefix and suffix fields: is used to store things like Dr., Rev., Sr., etc.

In searches, the given name and surname fields are searched, for both the primary as well as alternate names. The title prefix and suffix fields are not searched, although I could add searching the title prefix field for searches on givenname, and add searching the title suffix field for searches on surname, so a search of

Given name: Reverend John
Surname: Carter Sr.

would sort the John Carter with a title-prefix of Reverend and a title-suffix of Sr to the top. Let me know if this would help you.

In addition, pages with the searched-for given name and surname in the title are sorted higher than those without. This is to handle the case where you're searching for say Ann Smith and you'd like people with a given name of Ann to sort before people with a middle name of Ann. (This was a request last year.) Since the page title is supposed to contain just the person's first givenname, pages with Ann in the title sort higher.

This also explains why "H. Lynn (1)" sorted so low. If this page were renamed to "Hugh Lynn (##)" it would sort higher in searches for Hugh.

In case the name you're searching for is spelled slightly differently, unless you've specified to return exact matches only, pages with similar names also appear in search results, although they're sorted lower than pages whose names match exactly. Similar is defined as related names that appear on the Givenname or Surname wiki page for common names, or names that are spelled similarly for uncommon names (using double-metaphone, which is similar to soundex). So people named "Jonathan" or "Jahn" are returned in searches on "John".

Search results display both the title (in big letters) and the primary name (in smaller letters underneath the title). The primary name includes the title prefix, given name field (which can include the first given as well as middle names), surname field, and title suffix. I have thought about displaying the primary name in big letters in place of the title for people. This would be inconsistent with how other pages are displayed (pages in other namespaces display the title in big letters) so I haven't done it. I could though.

The issue with displaying search results in a row-and-column format is it doesn't work very well when results come from different namespaces. Articles for example don't have birthdates. Also, if you include keywords in your search then you'd like to see the context of matching keywords in the page text, which doesn't fit well in a narrow column. Replacing the title with the person's full name would allow more search results to fit in the same vertical space. If we display the person's primary name in big letters instead of the title for Person pages, we could also display the person's birth and death dates in big letters after the name, which would make those two fields easier to see, but give a slightly more cluttered results page. Let me know if you would like to see those two fields after the name in big letters in place of the page title.

There is a lag of about an hour between the time that you create/edit a page and the time that it will appear in the search results screen. If the page is listed in the list of your recent edits on the left, it hasn't been indexed yet. Once it disappears from that list, it's been indexed.

The primary name (title prefix, given names, surname, and title suffix) appears at the upper-left corner of the Person page.

When you're comparing people for merging, both the page title and the primary name and the alternate names are displayed. The page title is displayed as a link at the top of the column; the given and surnames are displayed below. Title prefixes and suffixes are displayed on the merge screen, but are not displayed on the compare screen. That's a bug; I'll add title prefixes and suffixes to the compare screen.

I hope this answers all of the questions posed above. If not, please let me know.--Dallan 13:36, 16 January 2009 (EST)


Thank you, Dallan, for all the answers. Much appreciated. You've written some great text that should be added to the help pages (somewhere). (After I am done with my travels, I'll take a crack at finding and editing such pages if someone else doesn't get to it before me.)

While my concern is not wholly addressed, I will bow to the more experienced wikians among you. You've all clearly done so much work to make this a phenomenal resource. My apologies for muddying the waters for awhile. (Knowing me, this won't be the last time.) ;-)

Until then, jillaine 16:34, 16 January 2009 (EST)


Thank-you for offering to update the help pages with this information when you get back from your travels. If you have any other questions, feel free to bring them up. (I might have missed them in reading through all of the comments). Also, everyone please weigh in on whether you'd like to see any of the possible changes I suggested above. I probably won't get to them until Spring, but we can add them to the list.--Dallan 16:40, 16 January 2009 (EST)

All of the renamed Thomas Carters are now un-renamed. I am still searching for the best place to incorporate your descriptions. And because this topic is so darn long (and convoluted), I'm creating a new section immediately below for Dallan's suggested changes for us to review and comment upon. jillaine 08:49, 19 January 2009 (EST)

Dallan seeks feedback on proposed search results display changes [26 January 2009]

1. In searches, the given name and surname fields are searched, for both the primary as well as alternate names. The title prefix and suffix fields are not searched, although I could add searching the title prefix field for searches on givenname, and add searching the title suffix field for searches on surname, so a search of

Given name: Reverend John
Surname: Carter Sr.

would sort the John Carter with a title-prefix of Reverend and a title-suffix of Sr to the top. Let me know if this would help you.

2. Search results display both the title (in big letters) and the primary name (in smaller letters underneath the title). The primary name includes the title prefix, given name field (which can include the first given as well as middle names), surname field, and title suffix. I have thought about displaying the primary name in big letters in place of the title for people. This would be inconsistent with how other pages are displayed (pages in other namespaces display the title in big letters) so I haven't done it. I could though.

3. If we display the person's primary name in big letters instead of the title for Person pages, we could also display the person's birth and death dates in big letters after the name, which would make those two fields easier to see, but give a slightly more cluttered results page. Let me know if you would like to see those two fields after the name in big letters in place of the page title.

Any thoughts on this? If it's not a high priority, we can back-burner it for now and address it later this year.--Dallan 16:35, 26 January 2009 (EST)

Three new special pages for trees [5 January 2009]

I've added three new special pages for trees:

  • Special:TreeRelated - Shows pages that are not in the tree that are linked to by pages in the tree, so you can see pages that you may want to add to your tree.
  • Special:TreeCountWatchers - Shows the number of people watching each page in a tree, so you can tell which pages in your tree are being watched by others and which are watched only by you.
  • Special:TreeDeletionImpact - Shows pages that link to pages that would be deleted if the tree were deleted, so you can see the impact of deleting your tree. These pages would lose their links if your tree were deleted.

Links to these new special pages can be found by clicking on "Trees" in the MyRelate menu.--Dallan 12:54, 5 January 2009 (EST)


Wikipedia refresh complete [7 January 2009]

Roughly 75,000 pages at WeRelate (mostly Place pages, but now more than a thousand Person pages as well) copy some text from Wikipedia. Until last week these texts hadn't been updated in over a year. They have now been updated with the latest available version of the Wikipedia text, and hopefully with the updated refresh code I'll be able to keep them more up-to-date in the future.--Dallan 14:45, 5 January 2009 (EST)


Many thanks!--Jrm03063 15:34, 5 January 2009 (EST)


Hmmm. Something does not compute. I was under the impression that there was considerably more pages on WeRelate than this. And I certainly thought there were more than 1000 person articles. Doing a check with the search engine in the "Person" name space, and a "blank" in the information field, yields 1,624,864 articles. Possibly some of those are redundant, given the vagarities of a search engine, but there's got to be more than 1000 person articles out there. Seems like the total number of articles must be well over 2M. Q 17:06, 6 January 2009 (EST)


There are 1.6M+ people, the 1000 people are pages with body content sourced directly from wikipedia. And the number is more like 1200, with about another 100 or so pending beyond that.--Jrm03063 19:41, 6 January 2009 (EST)


Are you sure? [10 January 2009]

A recent change in the way edits are handle seems to be a response to someone's concern about loosing edits because they hadn't saved. Now you get warned when you navigate away from a page opened for editing, that if you haven't saved, you'll loose your edits.

That's not a bad idea; on occassion I've had that happen as well. However, for me personally this is more annoying than useful. Since the site has been cooking along for sometime without this cue, I suspect most people don't run into this problem more than a few times; perhaps the pain of having to retype something because the save button wasn't hit, is an effective way to get folks to save after editing. As it is, there's now an extra step in every edit session that I think serves the needs of a relatively few people.

Also, if you use the back button to get back to a given place, you'll also get this warning everytime you hit an "opened page for editing". So what used to be a fairly simply process becomes much more cumbersome.

If this change is really needed, perhaps it could be set up so that the user's preferences allow the warning to be turned off. Q 16:56, 6 January 2009 (EST)
I agree with Q.--Beth 19:28, 6 January 2009 (EST)

I thought this warning that suddenly showed up was a problem with my computer. Actually, with all the editing I am doing I find this warning rather annoying. --Susan Irish 23:31, 6 January 2009 (EST)



I don't usually make this error so this is not a major lifesaver for me, but every once in a while it is/would be a great help. And the back button does not get everything back. A lot of the place names come up blank in this situation. When I am inputting data I usually have multiple browser windows going, checking facts, etc., and it is easy to loose track and close the wrong window, especially if it is hidden under another window. So I like it all in all. Perhaps explicitly pressing the Cancel button doesn't need this extra step, but I think it is very consistent with most computer programs (Dallan's principle of least surprise), and should stay. --Jrich 17:56, 6 January 2009 (EST)

Perhaps not executing the "Are you sure" routine when an explicit save is in fact made, is the change needed. Q 19:33, 6 January 2009 (EST)



I like this feature in cases when I've actually made an edit to a page. Oftentimes, however, I go to a page edit just to copy some text to paste elsewhere. I will also go in to edit to view how I coded something. In these cases, the dialog box is slightly annoying. Is it possible to code the box to only appear if the page has been modified?--Jennifer (JBS66) 08:52, 7 January 2009 (EST)


That's a good idea (only prompt if you have actually changed something). I'll fix it later today or tomorrow.--Dallan 15:28, 8 January 2009 (EST)

You're now prompted only if you have changed the page or if you've clicked on the "Show preview" or "Show changes" button.--Dallan 20:11, 8 January 2009 (EST)

Thanks Dallan for making this change. I think I'm the person who initiated the request for this 'are you sure' warning. I'm a pretty typical potential user, that is, wiki-challenged genealogist. It makes the program frustrating to try to use when carefully typed info is so easily lost. The goal is 'let's don't frustrate the newbies'! At the same time you don't want to annoy or frustrate the experts!--Janiejac 21:04, 10 January 2009 (EST)


UK - Census - Suggestions [16 January 2009]

Hello All,

Hope I am using the correct page for this question.

What is the Werelate naming theory about the UK census, 1841, 1851, etc. Source pages?

I have used both Ancestry and FHL microfilm.

There does not seem to be a main naming pattern for this.

Unlike the United States Census which has "United States. Year U.S. Census Population Schedule".

I found one page "Register of Great Britain Census, 1841" which mentions the FHL catalog.

Suggestions?

Thank You Debbie Freeman --DFree 19:16, 7 January 2009 (EST)

Hi Debbie, I was supposed to fix the source pages for the censuses in Scotland; but haven't had the time. I planned to use the following: "Scotland, Aberdeenshire, Glenbuchat. 1841 Census of Scotland". Perhaps something similar with the UK census. I am not familiar with the UK census data; I would title the country the same as in the census, I think.--Beth 20:03, 7 January 2009 (EST)


This is a good question!

It appears there are 6 pages that cover the censuses 1841-1891 currently titled as Source:Census returns of England and Wales, 1841, Source:Census returns of England and Wales, 1851, etc. These cover the whole of England and Wales and would be akin to the Source:United States. 1900 U.S. Census Population Schedule pages.

There are also pages for each county, like Source:1851 census of England and Wales (transcription and indexes) : Norfolk, akin to the Source:United States. Texas. Taylor. 1900 U.S. census, population schedule pages for the U.S.

I also noticed that in the FHLC film notes, a county will be called Buckingham, but at Ancestry it will be called Buckinghamshire. In this case, our place page is also titled Buckinghamshire. I would suppose that we would want to title the census pages to be consistent with our place page naming (as far as the county goes).

What about something like:

  • Country level: England and Wales. XXXX Census Returns of England and Wales
  • County level: England and Wales, county name. XXXX Census Returns of England and Wales
    • In the "Places covered by the record group" field, enter: county name, Country Name (For example: Buckinghamshire, England.)
    • In the "Title" field, enter: XXXX Census Returns of England and Wales

Whatever naming scheme we decide upon, I would suggest adding that info. to the Help:Source page titles page.--Jennifer (JBS66) 06:48, 8 January 2009 (EST)


Most of the current Source pages don't conform to the new Source page title conventions because the pages were created prior to the conventions. I will at some point (this Spring) write a program to rename them. I know it's an unfortunate situation that you can't use existing Source pages to see what the titles should look like, but working on merging (and unmerging) and gedcom export takes priority right now.

I agree with what User:JBS66 said with a slight modification: that if you create a county level census source that you name it according to the particular country the county was in, either "England, county name. ..." or "Wales, county name. ...". I know the county Place:Monmouthshire, Wales is considered by some to have been in England at various points in time. If you create a source for a Monmouthshire census, how about titling it under Wales so we're consistent with the Place title for Monmouthshire. You could also create a "England, Monmouthshire. ..." page that redirects to the Wales one if you want.

And the suggestion to modify the help page is a great one. In general, if anyone learns something by asking questions on the watercooler or elsewhere, it would be a huge help if you would add that information to a help page. Thanks!--Dallan 15:28, 8 January 2009 (EST)


Hello,

I think I see what you are suggesting.

I will start to change DFree Mysource English census to Title only "England and Wales. Year Census Returns of England and Wales" for now.

That will work.

Thanks, DFree --DFree 16:29, 8 January 2009 (EST)


What I can do then, is add the following to the Help:Source page titles page. I can also change the 6 Country Level pages, and also find/edit/create a page for the 1901 census. I will leave the county level pages untouched, but the instructions will be on the help page for those wishing to undertake this project.

  • Country level: England and Wales. XXXX Census Returns of England and Wales
  • County level (England): England, county name. XXXX Census Returns of England and Wales
    • In the "Places covered by the record group" field, enter: county name, England (For example: Buckinghamshire, England.)
    • In the "Title" field, enter: XXXX Census Returns of England and Wales
  • County level (Wales): Wales, county name. XXXX Census Returns of England and Wales
    • In the "Places covered by the record group" field, enter: county name, Wales (For example: Breconshire, Wales.)
    • In the "Title" field, enter: XXXX Census Returns of England and Wales.--Jennifer (JBS66) 06:34, 9 January 2009 (EST)

I do want to add a note that it is difficult to locate the country census pages through WeRelate's search feature alone. If I Search for Place:United States, Title:census 1900, Subject:Census Records, and choose Exact Matches only, 446 pages are returned. The majority of these are pages for counties. Is there a way to sort the results by place so that Source:United States. 1900 U.S. Census Population Schedule would be returned before any of the state pages, and before any of the county pages?--Jennifer (JBS66) 08:06, 9 January 2009 (EST)


There should be. I'll add this as a high-priority item to the todo list.--Dallan 13:49, 16 January 2009 (EST)


Bugs fixed [8 January 2009]

I just fixed a couple of bugs in propagation -- the code that generates "back-links" between Person and Family pages so that if you add a link from a Person page to a Family page, a link back to the Person is automatically added to the Family page. I've tested it and I'm fairly certain it's working correctly, but please let me know if you notice anything broken.

Just FYI, the two problems were:

  • If you edit a Family page and switch one of the family members from a spouse to a child (or vice-versa), the back-link from the Person page to the Family page could be lost. Similarly, if you edit a Person page and switch a family link from a parent-family to a child-family, the back-link from the Family page back to the Person page could be lost. This shouldn't happen in the future, we've identified the (roughly 50) pages that it has affected, and we're about halfway through correcting them.
  • If when merging a family you added birth or death information to one of the family members, that updated birth/death information would not be propagated to the newly-merged family page. This shouldn't happen in the future, but a fair number of pages have been affected. I'll write a program to update them in the next 2-3 months unless people really want to see them updated sooner.--Dallan 20:11, 8 January 2009 (EST)

Same father, 2 different mothers [10 January 2009]

I have a man in my tree who married a woman. She died after having a child. The man married another woman & had 3 more children. Here's my problem. How do I get the one child linked to the first marriage? Right now it's linking to the 2nd marriage. It shows Dean Swearingen and Living Behrens (1) with Nathalie Tucker as an "Alternate Wife". I've been trying to link Dean & Nathalie's son to them (and list their marriage date), but can't find a way to do it. Do I just create another family page? Will that mess up what I already have? Thanks for any help.--Lkm02196 22:40, 9 January 2009 (EST)

  1. Go to the family page where the first child is incorrectly linked. Edit the page. You should see the first-marriage child listed (incorrectly) on this page. Click on the REMOVE button, to remove this person's page from this family page. SAVE.
  2. Go the family page of the father and first mother. Edit. Add child. Using the search, find your first child person page. Add. Save.
that should do it. jillaine 08:00, 10 January 2009 (EST)

Great Feature of Jennifer Stewart's Work [11 January 2009]

I love the new feature of Jennifer's work. I like this idea of featuring the work of a particular contributor. It accomplishes several things:

  • It provides an example of how someone can take on a piece of WeRelate and go to town on it (implicitly suggesting that others do the same)
  • It provides some good examples of project-like pages (ditto)
  • It acknowledges a volunteer for her contributions to the wiki

Lastly, it's inspired me to select a few of my near-ready-for-prime-time pages and really clean them up.

I would like to see more features like this-- especially now-- in order to encourage people to do comparable work and provide ideas for how to do it.

Nice work, Jennifer!

-- jillaine 08:07, 10 January 2009 (EST)


Jillaine,
Thank you for the kind words. I do want to note that a monthly feature of users has been occurring for the past 6 months or so. If you would like to see the past featured users, you can go to WeRelate:Featured pages.--Jennifer (JBS66) 11:24, 11 January 2009 (EST)


Merge Weirdness [16 January 2009]

I just attempted to do a merge of multiples familes-- specifically what became this:

Family:John_Thayer_and_Joan_Lawrence_(2)

When I was merging, on that first merge page, I noticed that the children had also been duplicated, so I selected the Merge 11 with 1, Merge 12 with 2, etc.

BUT on the subsequent page, none of those children came up, and as you'll see from the link above, they were not merged. Why did that fail?

Thanks. jillaine 00:17, 11 January 2009 (EST)


UGH! There is clearly something wrong with the merging of families when you merge children in a family. UGH! Sorry, but it took me QUITE awhile to merge five or more families into one, including the children who were listed in/duped across at least three of them. This time, all the dupe kids made it onto the second merge screen, and I carefully merged them. But when I completed the process, the Family:Johanes Tawier and Mary Roberts (1) page still has them all as dupes. UGH. jillaine 18:33, 11 January 2009 (EST)

I imagine what you're seeing is that the kids you're merging into are not children in the "first" (furthest right) family, correct? If true, you can't merge into those children. Why that is true, I don't know, but that's been the way it's worked since the beginning. The easiest way around it is to merge the one with the kids into the correctly named page, then merge the rest of the families into that one.--Amelia 19:36, 11 January 2009 (EST)
Amelia, thanks for trying to help me. So you're saying that if the furthest right column does not contain children, but the other columns DO, you can't merge into those other columns? For example, let's say that the right column is empty, but the one to its left has children, and the one to the left of THAT also has children, but further down and not aligned horizontally with the children in the column to its right. Are you saying that I cannot merge children from column 3 (from the right) into column 2 (from the right)-- but only into children who must be dupes in column 1 (far right)? I missed that part of the user's manual, obviously.
I actually thought that there WERE children in the far right column but now I'm not so sure. UGH. Okay. I'll go see if I can clean up that mess. BLECH. jillaine 20:54, 11 January 2009 (EST)

I've definitely seen cases where, when merging a family, only some of the merges occur. The family page always works, but sometimes spouses don't merge as expected. Also, sometimes children don't merge as expected. You can later effect the individual overlooked merges, but it is strange. One situation where I think this occurs, is if you have a two family pages with children. One of the family pages already has a particular child duplicated (so there are three instances of the child, even though there are two families being merged). Even though you may be able to specify the correct merge for the child, you won't be presented with the three children horizontally in the final step of the merge.--Jrm03063 21:56, 11 January 2009 (EST)


You should be able to merge children together even if one of the children isn't in the right-most column. You have to set both children's "Merge with" drop-down to the same child number. I just tried this and it seems to work ok for me. The point of confusion may be that you have to set the "Merge with" drop-down on both children, not just one. I'll change this so that by default, the "Merge with" value is set to itself for every child.

This trick should work for merging multiple children from the same family together as well: Set the "Merge with" value for all children to the same child number. This worked for me when I just tried it. It doesn't work for children in the right-most family because they don't have "Merge with" drop-downs, but I can add "Merge-with" drop-downs to the right-most family as well.

If you come across a situation where people you're trying to merge don't get merged, would you please leave a message on my talk page? I just looked at Family:Johanes Tawier and Mary Roberts (1) and I can see the duplicate children. (You can merge them if you want by clicking on "Find duplicates" in the "More" menu for each of the duplicate children and merging them.) The problem is I can't figure out by looking at this page what might have gone wrong. I recently reworked some parts of the merge process, and maybe that's why things are working now, but it seems not very likely. I'd like to track down any problems with merge that people are seeing, so if it happens again, would you please leave me a message including as many details of what you did as you can remember? I'll try to repeat it and if I can, I'll be able to find the problem and fix it. I'll also add some logging to merge to help me better understand what's going on at the back-end.

Thank-you! And sorry for the trouble.--Dallan 14:58, 16 January 2009 (EST)


[13 January 2009]


Incorrect Change [16 January 2009]

As part of the effort to eliminate duplicate entries for the same person, someone scrubbed the family trees containing "Samuel Porter". I'm sure there were many duplicates for this particular individual. As it happens I created a disambiguation page for this name, mostly because there were so many entries on WeRelate. Some of those entries were for entirely different persons who happened to have the same name. Others were duplicate entries created by different contributors when they added their family tree's. Yet others were duplicate entries created by the same contributor either doing "false starts", or perhaps adding new data, and somehow managed to duplicate old entries.

I occassionally create such disambiguation pages to help me sort out the information found here on WeRelate. I've tried different formats, and have not yet reached a conclusion on the most useful format for my purposes. Sometimes one thing works, sometimes another. In anycase, the particular format used for the Samuel Porter disambiguation page identified the the persons parents, DOB-DOD, Spouse, and author.

Here are selected entries in the table.

PersonParentsDOB-DODSpouseAuthor
person:Samuel Porter (1)Samuel Porter and Sula Cannon (1)1888-1979Rkoelz
Person:Samuel Porter (2)John Porter and Anna White (1)1632-1632Hncamp
Person:Samuel Porter (3)John Porter and Anna White (1)1635-1689Hncamp
Person:Samuel Porter (4)
Person:Samuel Porter (21)Unknown and Elizabeth Duncan (2)1780-1806Philipkcraig
Person:Samuel Porter (22) Joseph Porter and Elizabeth Wyman (1)-1819-y Inator
Person:Samuel Porter (23) Joseph Porter and Elizabeth Wyman (1)-1819-y Inator
Person:Samuel Porter (24)redirected to Person:Samuel Porter (3)
Person:Samuel Porter (25)redirected to Person:Samuel Porter (2)

Note in particular the last two rows, second cell, which indicate that the content there was redirected toward a different location. Apparently, what has happened is that in the scrubbing processing someone eliminated the original pages for these individuals, and as a helpful act, attempted to correct this table.

That's all very well and good, and I appreciate the thought. Unfortunately, the changes made to this table were handled incorrectly. The cells that were changed are in the column marked "Parents". That column was intended to help sort out specific individuals, so that I could see what different persons were saying were the parents of this particular individual. The original link was to the parent card for this person. Now the link is to the person himself with the helpful, yet unhelpful note "redirected to".

In truth, no change should have been needed (assuming the original scrubbing had been done correctly). Clicking the link that was there should have taken the reader to the correct couple even if the index number was wrong.

Q 18:34, 13 January 2009 (EST)

As the person who did that change, I will explain. It is not true that there are 25 different Samuel Porters on WeRelate numbered 1-25. There are maybe 16 or 10, or something. I thought it would be much easier to look at the list and know that you can ignore the ones that have been merged than it is to look and try to remember by the time you are at level 24 or 25 if you have seen those parents before. I was thinking these tables were for general use and was trying to make them easier to use, but if you prefer them to be for your own personal use, then I won't touch again. That's what the revert button is for.--Amelia 20:43, 13 January 2009 (EST)
This table was carefully set up to serve a specific purpose. Even the empty fields, and links in red, have significance for that purpose. The table includes 125 entries, though most are still in red---indicating the corresponding person article has not yet been created. The way the table is set up any new additions (through about Samuel Porter (125) or so, will automatically reveal themselves, though most of the fields will be blank. So, yes, of course, there are not as yet 125 Samuel Porter entries---as yet---but those blanks still serve a purpose. Specifically, they tell me the article has not yet been created.
Of course, every page (other than perhaps the user page) is available for general use. If someone finds this particular page helpful, then that's fine; in fact, I always appreciate help. So if someone wants to add information to it, that's great. However, it may be unwise to make changes in a table whose structure and intent is not understood. Q 21:11, 13 January 2009 (EST)

What is unwise is putting something on WeRelate that you want to control and not putting a big warning all over in big red print. WeRelate by design and common usage does not belong to anybody. Get the idea of owning resources out of your head. --Jrich 22:09, 13 January 2009 (EST)

To repeat:
Of course, every page (other than perhaps the user page) is available for general use. However, it may be unwise to make changes in a table whose structure and intent is not understood.
I was not concerned that changes had been made on the page. Only that changes had been made without understanding what the table was doing. Q 22:26, 13 January 2009 (EST)

The merge that was made appears to me to be correct, and the justification for changing your table was stated and it seems to me that it makes sense. After all, as I understand it, those numbers can't be reused, so they will never point to some new page freshly entered, so why not just label them as redirected - the parents are now the parents it was redirected to, find the parents there. So the message that came across is that you didn't like somebody changing your page, to which: see my previous remarks. Jrich 22:36, 13 January 2009 (EST)

The issue is not with the merging, but with the changes made to the table. Those changes were erroneous. The information presented might have been valid information---the index numbers presumably pointed to the proper Samuel Porter. However, the space in the table into which that information was inserted was for the parents, not the individual, and not for parenthetical commentary. The problem arose because someone (very helpfully) wanted to point out the redirect, but did not understand what the table was about, and so placed the information in the wrong cell of the table, thereby reducing its utility for the original purpose.
I don't really have a stake in this. But it just seems that your statement that the table was changed incorrectly assumes that it is obvious how to use the table. There are no instructions, or links to instructions on Disambiguation:Samuel Porter. If I had done the merge, and had been aware of the table, I probably would have completely deleted the two rows, as my choice for the most appropriate way to handle that situation. But Amelia took a different approach, probably a friendlier one. Sure, obviously the column was for parents, but that information sort of seems unnecessary after the page is redirected, since the parents are necessarily the same as the page it was redirected to. Without instructions, there is no way to guess that it wasn't the intent to keep the information updated to reflect the current state of WeRelate, that you apparently wanted a snapshot of the data as it existed at some point in time of your choosing. I don't think you can assume all, most, or even many people trying to help out by updating the table would have responded to this situation in the manner you believe is "correct". If you want to create a page following a certain paradigm and have others stay consistent with that, I think you need instructions. If you want only yourself to update it to be sure it done in a certain manner, I think you need to add a prominent warning to others not to change it without checking with you. --Jrich 17:29, 14 January 2009 (EST)
I would assume that how to read a table would be a basic capability, not something that needs an explanation here. Since you are clearly able to correctly interpret the table, how to use it would seem to be obvious at least to you. The table itself required no correction since (at least in theory) the redirects would resolve any problem. In truth the change made was purely gratuitous. However, in anycase, you misunderstand the issue. The concern did not lay with making the change, but with making a change where there was clearly no understanding of the implication of the change. It was not neccessary to contact me before making the change. However, had I been contacted I probably could have explained the misunderstanding on their part. Q 18:26, 14 January 2009 (EST)
At first, I thought you were going to suggest your disambiguation page as an alternate mechanism to mangling the titles of pages to say Rev. Thomas Carter of Watertown, per this person's preference for identifying someone, or that person's preference for identifying him. That would be a more interesting idea to discuss. --Jrich 22:36, 13 January 2009 (EST)
While there was a reason for pointing out this change, that wasn't it. Had it been I'd probably have put it under Jilliane's question. However, yes, of course, a disambiguation page could be used for solving Jilliane's problem. Whether the specific format I was using for Samuel Porter would be the best way to handle it, I don't know...but it or something like it could be used for that purpose.
I actually created a type of "disambiguation" page for the Thomas Carters on the "Carters of Massachusetts" category page. jillaine 20:50, 14 January 2009 (EST)
Speaking as someone who routinely uses by-names to distinguish between different sets of data for individuals that may or may not be the same person, even though they share the same name, I find by-names very effective in sorting out problems. The problem with a by-name, though, is that they are not really the proper genealogical name to use for a person....only a shorthand note to help folks keep straight the identity of similarly named individuals. This is a tried and true convention---even our ancestors used it; when looking at tax records I often find where the tax collector has distinguished between similarly named, but distinct persons. The use of "Jr." and "Sr.", or "Rev." is a case in point, but sometimes they went further. In the specific case of Samuel Porter in Castle's Woods (SW VA), there were at the same time two separate Samuel Porters, unrelated (as far as we know). One was the son of Patrick Porter who lived on Fall Creek (and happened to be the tax collector), the other Samuel lived in Castle's Woods itself, in an area then known as "Temple Hill". In his records Patrick the tax collector distinguished between the two by adding the by-name "Temple Hill" or "Castle's Woods", to his records for the Samuel Porter who was not his son.
IN other locations I've experimented with using By-names in the title. It has not worked well for me, and is something I wouldn't recommend. The problem with this for genealogists is that "Samuel Porter of Temple Hill" not really the gentleman's name, but something that's been applied to help keep records straight. For the modern day genealogist its helpful to use the by-name when you speak of one Samuel Porter---but for that to make sense you'd need to understand a fair bit about the history. Someone with a knowledge of the Castle's Woods area and the family history might (or might not) recognize the significance of the by name. For other's it probably wouldn't be helpful---especially since differnt people might focus on different features of the persons life when it came to selecting the by-name. For example, one could just as easily refer to "Samuel of Temple Hill", as "Samuel the Tory", emphasizing (probably inaccurately) a different aspect of his life.
A disambiguation page that incorporated by-names, or alternative bynames, might be useful for some folks. It might be useful for Jilliane. I wouldn't recommend adding yet another namespace (we've enough of those already). I also don't know that a standard structure for such pages would be that useful---sometimes different needs can be met with the same approach---but that doesn't necessarily mean that every disamgiguation page would have to be organized in the same way. Q 11:14, 14 January 2009 (EST)



That seems like a page that Dallan could generate "on the fly" (no saved backing page) if it's all that useful.--Jrm03063 21:40, 13 January 2009 (EST)
Yes, it could be. Or if there were "tags" that could be used, we could create it ourselves automatically. I've experimented with the format a fair bit, trying different approaches. Sometimes one thing works well for the immediate purposes, sometimes another. While this is useful to me, I don't know if others would find it useful. I believe the general organization of the table as shown above is probably a good one that could be used in the search engine results display---one line per entry. That way you could examine more entries at a time. Unfortunately, the idiosyncracies of the search engine (though its much much improved) limit this particular application--results are not sufficiently regularized to make this approach effective. Q 21:54, 13 January 2009 (EST)

In the future, can discussions about incorrect changes to specific pages be held on those pages' talk pages? The watercooler is already long... (I admit that I just skimmed this topic after the first few paragraphs.)

Also, in the future, if someone makes a change to a page that is incorrect, please just fix it. It probably takes less time to back out the change and perhaps add some clarifying instructions so a similar change isn't made in the future, than to bring it up here. I know I've made changes that weren't correct. I imagine we all have. In fact I just received an email about an incorrect merge that I did - It was a little embarrassing, but they were right!

Thank-you!--Dallan 16:06, 16 January 2009 (EST)


How the Search Engine Works [16 January 2009]

If this has been discussed elsewhere, please point me in the right direction and accept my apologies for duplication of topic discussion.

The whole "Thomas Carters of Massachusetts" discussion (above) is having me learn more about how the search engine works. As I've said in that topic, I would like the search engine results to help me distinguish the various Thomas Carters (as an example). The search results DISPLAY the Page Title in the results. Hence a contributing reason to my changing the Page Titles of said pages to include the distinctions of "of Woburn" and "of Salisbury" etc etc.

Unfortunately, the search engine also appears to be using the Page Title to SORT the results; as a result, my "of Salisbury" and "of Woburn" Thomases end up at the END of a long list of other Thomas Carters, rather defeating my intention to using search engine results to help distinguish between these folks.

  1. How exactly does the search engine work-- both in displaying and sorting results?
  2. What is the logic behind the current way the search engine searches and displays results?
  3. Once we know the answers to 1-2: What are the pros and cons of different ways of sorting the results of a search?

Thanks!

jillaine 09:16, 14 January 2009 (EST)


See Help_talk:Search for a related question (which remains unanswered as well). Thanks. jillaine 09:17, 14 January 2009 (EST)

Titles are used to sort results only if you click on "Exact matches only", and then on "Sort by title." By default, pages are sorted by best-match first. The more criteria you enter about the person you're looking for, the better chance you'll have of having that person show up at the top of the list. Title suffixes and prefixes aren't currently searched, but this would be easy to add.

More information in answer to this question is listed earlier, under the other topic where the question appears.--Dallan 15:47, 16 January 2009 (EST)


New feature for reviewing merges [26 January 2009]

I'm happy to announce that you can now review merges to see what the pages involved in the merge looked like just before the merge. Essentially, you can see what the person doing the merge saw when they were comparing the pages before the merge. Links to this new "Review merge" screen are available from the "Recent changes" screen and from the page histories of any page involved in a merge. This currently applies only to merges made within the past few hours and going forward, but eventually you will be able review and undo any merge made during the past 2-3 months.

The "Recent changes" screen has been modified in two ways:

  • In order to make recent changes less cluttered, a single recent change entry with a link to the "Review merge" screen replaces the list of pages that were changed in the merge. You can still see all of the pages that were changed in the merge by clicking on the "Show bots" link.
  • You can see just the merges that have taken place, along with deletions, renames, and image uploads, by setting the "namespace" drop-down to "Logs".

A quick roadmap for the next few weeks:

  • Soon - hopefully tomorrow, probably Monday, I'll add the ability to "undo" a merge from the "Review merge" screen.
  • After that, I plan to go through the old page versions and construct review entries for merges that have already taken place, so that people can review and undo those merges as well.
By the way, both of these steps are done now. You can review and undo practically any of the nearly 15,000 merges that have taken place since October 14th.--Dallan 19:59, 26 January 2009 (EST)
  • Once this is done, I will implement my part of the merge-during-upload process (User:Npowell is already working on his part).
  • Then it's on to GEDCOM export.
  • Then I need to take several weeks to upgrade the website to the most-recent version of the MediaWiki (wikipedia) software. I've made quite a few tweaks to their software over the past two years and I've been putting off upgrading, since it will take awhile. But they have implemented some really cool new features that I think we want, including the ability to undo just the changes made in a specific revision of a page if the page was edited later. This ability will make undoing old merges easier.
  • About the same time User:Npowell will work on the ability to upload an updated version of a GEDCOM file without having to delete your tree first.

--Dallan 16:38, 16 January 2009 (EST)


Notice of talk changes [26 January 2009]

I was wondering if there would be value in making the presence of a talk page a little more obvious. I would hope it will become the focus of much more activity, maybe even most of the activity as time goes on.

Ideally a talk page should be where discussions of "disputed lineages" or the plausibility of alternates, ongoing research, etc., so the Personal History section can be more of a narrative of the person and their life. But if people don't pay attention to talk pages, then such discussions will naturally move to where they are more obvious...

When you add a message to talk page, it is not very obvious. One almost has to train yourself to look for the "View the talk page". It has its own history page, so when you inspect the history of the main page, and it does not show that the talk page was changed. Could the message be red, or say "new talk message added 5 days ago" or flash when something has been added to the talk page since you last visited it, or something similar?

Another item is that if you erase your remark, because you answer your own question, or whatever reason, it still says "View the talk page" even though the talk page is now empty. Of course the history is not empty... I guess I should delete it?

--Jrich 20:12, 17 January 2009 (EST)


I'm not really happy with the "View the talk page" message either, but for a different reason: if the page you're looking at is the result of a redirect, you don't get the "redirected from ..." message because the "View the talk page" message replaces it. Similarly, if you're looking at an older version in the history, you don't get the previous/next version links. So I don't like where the message appears. I've been thinking about re-doing how person and family pages are displayed in the future (March/April timeframe). What would you (and others) think about putting a little icon (e.g., a little yellow star) next to the word "Talk" in the page menu at the upper-right corner of the screen if you've never visited the talk page or the talk page is a later version than the one you've seen, and getting rid of the "View the talk page" message?

Regarding the empty page dilemma, if nobody else is watching a person or family talk page you can delete it, but if someone else is watching it, I think we're stuck with having an empty talk page. Maybe leave a "answered my own question" comment on the page?--Dallan 19:59, 26 January 2009 (EST)


Disambiguation Pages [26 January 2009]

The recent discussion about using page titles to help distinguish (i.e., to disambiguate) multiple people with the same name introduced me to "Disambiguation Pages". Quolla then later made reference to this page:

Disambiguation:Samuel_Porter

I then went searching Help for more information about Disambiguation pages on werelate only to find one such reference on

Help:Special_pages

where it reads: "Disambiguation pages - we don't have any disambiguation pages yet"

This last appears to be wrong given the existence of Samuel Porter's disambiguation page. Yet, it is partially correct in that no namespace "Disambiguation" appears on the search screen.

Further research over at wikipedia finds this:

Disambiguation templates

which as a newbie I can hardly make sense of.

So I'm wondering: what's up with Disambiguation pages at werelate? What should I know about them to help me use werelate effectively (both as a researcher and as a volunteer helping others and editing pages, etc.)?

Thanks!

Writing from 78-degree Southern California,

jillaine 09:08, 19 January 2009 (EST)


I'm all for creation and use of "disambiguation" pages, but I don't think it's practical to maintain them by hand. Rather, I think that they should be "special" pages, created on-the-fly by the site. To my mind, the most useful thing would be for family and person pages to have an icon to the right of the page name. The icon wouldn't appear, or would be grey, if there are no other pages that share the same base name (redirects don't count). If there are other identically named pages, the icon would be active. Perhaps the icon could simply be an integer indicating the number of like named pages. When active, clicking on it would yield a machine generated page that presented a tabular summary of the different pages sharing that name.--Jrm03063 11:55, 19 January 2009 (EST)

Cool idea JRM03063. Is that what happens at wikipedia? Or is that template they use done so manually?
In the meantime, I've started using the category pages (since there are links to them on the bottom of most / all People pages) to serve this purposes in cases where there are multiples in the same state:
And now I suppose someone is going to tell me I'm muddying the waters again.
Cooler today, but I'm still going to hit the beach! jillaine 14:07, 19 January 2009 (EST)

Wikipedia disambiguation pages are done manually, e.g. Pi (disambiguation) --JoshHansen 15:24, 19 January 2009 (EST)


The situation of wikipedia is such that it probably couldn't create useful disambiguation pages manually. Werelate however, deals with a narrow set of page types and has a lot of information about what will be found on any given page. Decent disambiguation pages should be able to be created automatically.
Beyond having the site automatically generate such pages as needed, it would be nice if there was a way to designate a single "Note" field entry (on pages being disambiguated) as being associated with the disambiguation page. That way, a user-defined string could be associated with entries in the machine generated disambiguation page-table.--Jrm03063 16:14, 19 January 2009 (EST)

Using category pages is one way to disambiguate, especially because you could include additional information, similar to the note that User:Jrm03063 mentions, to each person. For example, the link [[Category:Carter in Massachusetts|Carter, John: 1860 - 1925]] would display John Carter's birth and death years after his name in the category page. Or [[Category:John Carter|1860 in St Paul, Ramsey, Minnesota, United States]] would display John's birth year and place in a category page for all people named John Carter. We could decide which fields from the Person page should appear in the category link. Category links could be added automatically whenever there was more than one person in the category. Obviously category pages don't work this way currently, but it wouldn't be too hard to change them to work this way.

Another approach would be to use search result pages, where the person's given and surname were searched for with the exact-match-only box checked. Instead of automatically-generated categories, we could have links like "More Carters in Massachusetts" and "More John Carters" appear at the bottom of the page that would take you to search result pages. As opposed to the category approach, it would not be feasible to add these "More like this.." links only when multiple people had the criteria, but search results pages show a lot more information, and you could add additional search criteria to further narrow the list.

I'm currently thinking about the latter approach because I think having too many automatically-generated category pages dilutes the value of the ones that people create: the human-created ones don't stand out in search results. However, I could be talked into the former, or some combination of the two.--Dallan 19:59, 26 January 2009 (EST) (writing from MN, where it got up to a whopping 6 degrees today - how did people ever live here 100 years ago?)


Image Formats [26 January 2009]

moved question from Talk:Main Page
Image Formats [22 January 2009]

Most of my image files are in PDF format, any a number of others in TIF format. The IMAGE features in WeRelate does not accept either. Please assist. --BobC--BobC 11:42, 22 January 2009 (EST)

--Jennifer (JBS66) 09:50, 23 January 2009 (EST)


I don't know if anyone answered your question or not. There is a free program that you go and download called Irfanview that can make copies in the .jpg format to upload here. Irfanview You should keep a copy as .tiff at least for storage. I always scan in .tiff and make copies of the ones I want to use online in the .jpg format. I hope this is of some use.--Twigs 10:35, 25 January 2009 (EST)


I second Irfanview. Another terrific program is GIMP, which has a lot of wonderful image-editing features but is also harder to use.--Dallan 19:59, 26 January 2009 (EST)


Incorrect and annoying error message [26 January 2009]

I just tried to merge a family that has two dup parents and five dup children. I get "Unable to merge. Too many pages to merge. Sorry - you can merge only up to five families at one time. If you need to merge more, please divide them into groups of five, merge the pages in each group, then merge the groups." First, I'm not trying to merge five families. Second, please don't tell me that I can't merge more than five people or children, because there's no easy way to merge kids right now, so this limitation would be really annoying -- and I've done it before numerous times, so I know it can technically be done. I can get it to work eventually my having no more than four people in the merge.

"Fixing" it brings up another error. In changing the syntax below each child (i.e. the choices are "merge with" or just a child number) there's now no option not to merge that child if the system has already made a match. --Amelia 15:30, 24 January 2009 (EST)


I got this message, too. I was only trying to merge one family and it said I could not merge more than 4. ??? I had to go through and merge each of the 9 children separately, and then I was able to merge the Family page. This seems like a bug, since this is not how it used to work, and it makes it much harder to merge duplicate families! --Jrich 17:38, 25 January 2009 (EST)


Sorry - I was counting the number of rows in the table (the total number of merge targets) instead of the maximum number of columns (the number of pages being merged together into one page). I'll fix it so that it's counting the right thing, and I'll also increase the limit to 10. I'll also put the do not merge option back in. I'll make all of these changes first thing in the morning. Sorry about that.--Dallan 22:18, 26 January 2009 (EST)


Family Tree Formats [27 January 2009]

Looking through Wikipedia I see a few different family tree and ancestry chart formats. Two of those links are shown below. I tried carrying over a couple edit formats to my pages on WeRelate, but was unable to get to work. Let me know if these functions do not work on this wiki application or if I'm doing something wrong. Thanks.

- "Ahnentafel5" function is an excellent example of what I'm looking at producing.
- Wikipedia: Family Trees showing a simple Ahnentafel listing, two Ancestry charts (left to right and top to bottom), ASCII art, Tables, and Template Tree.

--BobC 23:38, 25 January 2009 (EST)


Thanks for the links to the chart template pages, I had been looking for something similar. I copied the template from Wikipedia over here. On the template, I cited where I obtained it from - I believe this is ok under GNU, but if I've erred - please let me know!
Anyway, here is the template, and here is a sample I worked up User:JBS66/Sandbox. You can edit the colors, and the box heights when you call the template (see the code behind the sample at User:JBS66/Sandbox, you can edit the font-size, line-height, padding, and background-color). Just cut & paste the code from my Sandbox onto your page and edit the Person Page links. Good Luck!--Jennifer (JBS66) 07:44, 26 January 2009 (EST)


Oh, one more thing... Dallan, you may want to look at the style codes in the template. I think it's trying to call CSS, but I'm not experienced enough with this to know if it's a problem. Thanks.--Jennifer (JBS66) 07:46, 26 January 2009 (EST)


This template is really cool - thank you for setting it up! I looked at the style codes and they look fine. Setting your own styles, like this template does, isn't a problem.--Dallan 22:18, 26 January 2009 (EST)

BTW, in case you hadn't noticed it, you can get something similar to this (less work, not as many generations), by clicking on "Pedi-Maps" in the "More" menu).

Oh, perfect. Very nice and very needed. Thanks!--Twigs 11:36, 27 January 2009 (EST)


Images and thumbnails [28 February 2009]

I've been trying to add thumbnails to the Add Image on person and family pages. I've seen some pages with a nice neat table of thumbs at the bottom. I know how to add it to the page. But you can't add |thumb| to the Add Image. How do you create the neat thumbs at the bottom using the Add Image feature? Here is what I am talking about on the bottom of one of my family pages,: http://www.werelate.org/wiki/Family:Rufus_Brock_and_Bizzie_Beard_(4)

I want the photos to be small on the page, but clickable to a full size. The Bible snippet resized itself on the page without my help. Have I made sense?--Twigs 12:20, 15 January 2009 (EST)


Is this what you want to do by any chance? Help:Images_tutorial#Including_an_Image_Gallery_on_your_page--Jennifer (JBS66) 12:33, 15 January 2009 (EST)


So it can't be done through the 'Images' feature. I have two photos that made themselves into thumbs automatically. I don't understand how that happened unless it automatically does it if the image is over a certain size? If I want a gallery set up then I have to make and upload the thumbs and the reg. size photos and put it on the 'Family History' area.

Thank you for responding.--Twigs 12:43, 15 January 2009 (EST)


You shouldn't have to resize them yourself. If you put
<gallery>
Image:xxxxx.jpg|your caption
Image:xxxxx.jpg|your caption
</gallery>

into the Family History Section, it will automatically resize them for you (as small thumbnails). You can test it by going to your family page and copying a couple of the image filenames from your Images Section to the above code. Add it to the Family History Section, then click preview.--Jennifer (JBS66) 12:53, 15 January 2009 (EST)


Thank you! It turned out just as I wanted it to be. I'd have never found out how without your help.

Thanks!--Twigs 15:56, 15 January 2009 (EST)


You're welcome! I'm glad it worked out. Nice job with your family page by the way!--Jennifer (JBS66) 16:16, 15 January 2009 (EST)


I ought to draw the images in the "Images" section using the gallery tag. That's a nice idea for the future - thanks!--Dallan 15:52, 16 January 2009 (EST)


One problem with the gallery is that the page no longer shows up on the what links here of the images page.--Btomp 19:02, 16 January 2009 (EST)


Thank-you for letting me know. Whatever solution I come up with I'll make sure that the what-links-here feature works.--Dallan 16:36, 26 January 2009 (EST)


(This isn't exactly the same topic, but it has to do with thumbnails....) I've uploaded several parish register images from the Danish state archives (for example, I1 at Person:Kirstine Pedersen (3) and I2 at Person:Katinka Kristiansen (1)). Images come from the archives site as monochrome TIFF files, which I then convert to monochrome PNG for upload to WeRelate. The problem is that the thumbnailer seems to have trouble with these high-resolution files (6532×4704 pixels for one of them) and no thumbnail is generated. My question is whether the thumbnailer can be made to accomodate these images. As far as actual file size they are not very large, perhaps 600kb, and I am reluctant to reduce the resolution because, at least for my untrained eye, the large resolution compensates somewhat for the monochrome-ness and improves readability. Any thoughts? --JoshHansen 15:48, 28 February 2009 (EST)


I can't speak whether or not the thumnailer can be adapted, but here is a possible workaround. What if you put this: [[Image:IMAGE TITLE|100x150px|thumbnail|center|IMAGE CAPTION]] in the Personal History Section? The image won't appear with the rest of the images, but it does display a thumbnail version of your picture.--Jennifer (JBS66) 16:09, 28 February 2009 (EST)


Genealogy Codicil for Your Will [30 January 2009]

Although many of us reading this page and using WeRelate are interested in applying modern computer technology to our interest in genealogy and family history, if you are like me this is only a secondary method of collecting and compiling your genealogical material. Most of it is probably in binders, boxes, files and reference books. So, after your death, do you know what will happen to that collection? Have you ever given thought to who will care for the collection and continue the hard work you put into it? If you have not thought about it or have not done anything about it, now may be the time. You may want to consider a Genealogy Codicil for Your Will. Although WeRelate is an excellent method for sharing the basics of your genealogical data, for many of us it will hardly replace the collection of family history material we have accumulated in our own personal libraries in our homes. Using an idea as presented in the Genealogy Friends of Plano Library newsletter (June 2004 edition) I have prepared a Genealogy Codicil Template you may be able to use when you evaluate the disposition of your genealogical records and family history collection upon your death.
--BobC 14:12, 29 January 2009 (EST)


Article Assessment Effort? [29 January 2009]

Genealogy Wikia appears to be implementing a variation of Wikipedia's "article assessment" protocol. See:

[1]

Is this something we might want to do here? jillaine 20:43, 29 January 2009 (EST)


Namespace Portals? [7 February 2009]

There is so much information and discussion on WeRelate, sometimes it can be difficult to locate the basics for creating various pages. I was mulling around the idea of Namespace Portals - sort of a homepage for each Namespace.
One example is a Source Portal. It could contain boxes of pertinent information such as:

  • Tips on creating and using sources
  • Link to Searching sources
  • Browse Sources by Category (another future idea?)
  • Add a Source
  • Help on Sources
  • Naming conventions
  • Current Source Projects

Perhaps, along with (or instead of?) the Search and Add links on the blue menu bar, we could have links to various Namespace homepages. From here, we could link to search, add, and help, and also provide at-a-glance tips and how-to's.
Here's an inspiration page from wikipedia.[2] Any thoughts??--Jennifer (JBS66) 13:43, 1 February 2009 (EST)

Here is a link to Wikipedia's main Portal page--Jennifer (JBS66) 06:04, 4 February 2009 (EST)


Jennifer, is this along the lines of what you had in mind? jillaine 22:37, 3 February 2009 (EST)

Doesn't WeRelate already have the feature of a Namespace concept in the use of categorized surnames? With my limited use here, I notice that for each new surname and location I enter creates it's own link to a page that can be used by anyone using similar criteria. I think that page then can be expanded and formatted to create the type of document you are looking for -- and then those could be combined into and connected by a disambiguation page.
--BobC 09:44, 4 February 2009 (EST)


Topical Portals [7 February 2009]

Jennifer,

I like your idea; I've been thinking along similar lines at least in the sense that the wiki is so extensive that we need ways to help navigate it; portals as you suggest may go a long way towards this.

In addition to space name portals, we might also want to have topicals portals such as:

  • Colonial New England/Great Migration
  • German Palatine Emigration of the 1700s
  • German Emigration Wave 1845-1865
  • French Huguenot Emigration of the 17th Century

There are probably a lot of great articles already started that could "feed" such portals. I'd be willing to work on the first one above.

jillaine 18:00, 3 February 2009 (EST)


I notice that this too may already be in use here at WeRelate, such as the Southwest Virginia Project, which is a very organized and well-coordinated effort concentrating on a topical area. Here's an example of a categorical index that someone here at WeRelate might be able to duplicate for what you are talking about.
Each one of those areas of research you show above would be worthwhile projects, and I would be willing to lend a hand on the German/Palatine emigration topic, as I have at least a couple groups of immigrant families in this category and have done a lot of research in that area.
--BobC 10:10, 4 February 2009 (EST)

I've redirected the link above away from my UserPage where I initially implemented the Portal while I was testing it. The link now points to the main portal in "article space".
Wikipedia has a very well developed Portal system, but I found it easier to create my own structure than to try an implement their system of templates for portal construction. That may have been just my limitations when I first started working in a wiki environment, but any portal I might create would be pretty much one of a kind anyway, so the template approach has less value to me for this particular purpose.
A thought that has occurred to me many times, was that one way to organize information on WeRelate would be through a series of regionalized portals (like the SWVP), This cuts across narrow, and largely artificial boundaries of County or State. Ideas for Portals that have occurred to me include ones focused on the Cumberland Gap, and major settlement areas like Borden's Grant and Beverly's Manor. Jillaine's "Great Migration" project, would obviously fit in with this. The trick, though, is finding other folks with a similar interest set AND the genealogical and computer skills needed to create, maintain, and expand, such portals. That is not as easy as you might think. Many have the interest, few have the skill sets needed. Q 19:45, 7 February 2009 (EST)

I recommend a browse feature in WeRelate. The first page could lead to project, geographical, and topical pages. Additional pages could narrow things further. The search may be fine for a person's name, but it does not make finding project pages easy. ---Parsa 19:09, 7 February 2009 (EST)

I really like this idea! Perhaps we could create a "master portal" that would link to the other portals, and link to the master portal from the main page, perhaps in place of the current "Explore" link?--Dallan 14:20, 9 February 2009 (EST)


Guidelines for use of wikipedia [2 February 2009]

I have written a proposal for a set of guidelines on inclusion of wikipedia content within werelate. I would very much appreciate comment and criticism, such that an evolved version might be adopted as a guide by the community.

You will find the document in Proposed Guidelines for use of Wikipedia.

The document includes information and examples on what is proposed, as well as the reasons why.--Jrm03063 19:57, 1 February 2009 (EST)


Place names automatically categorized appropriately? [4 February 2009]

I just love learning more about how this wiki works...

When one creates an article, there is a box (or field) where one can enter a Surname. Let's say MARSH. This automatically creates a category for this article, such that if one goes to the Category:Marsh_surname, one will automatically find the article listed there under the appropriate space name.

Similarly, there is a box/field where one can enter a Place. Let's say "Warwick, Franklin, Massachusetts, United States." Now THAT is a town or city. There are no Categories at the CITY level. If I change the place name to only the county level-- Franklin, Massachusetts, United States, then the article IS automatically coded to include the category for that county and if I go to the Category page for that county, I will find the article listed in its index under the appropriate space name.

What would be totally cool is if the place pages (not category pages, but pages like Place:Warwick, Franklin, Massachusetts, United States) had an automatically created section called "Articles" wherein were listed any articles on werelate.org that had the place name filled in to match the place page.

That way my article on Spiritual Wife-ism would automatically be listed on the Warwick place page (as long as I'd listed Warwick, Franklin, Massachusetts, United States in the appropriate place field).

Is that possible? Desirable, generally?

-- jillaine 19:39, 3 February 2009 (EST)


Not sure if this is what you mean but...
If you go to the Place:Warwick, Franklin, Massachusetts, United States page, click on more, then click on What links here you can see everything that links to that place (person pages, family pages, other place pages, and your article...)--Jennifer (JBS66) 19:55, 3 February 2009 (EST)


Jennifer may have been saying the same thing using a different route, but you may already have what you are suggesting -- kind of anyway. Look at the uncreated category (in red) at the bottom of your Spiritual Wife-ism page for Warwick ("Warwick, Franklin, Massachusetts, United States"). Click on it, and it lists the category page with two index-style links: the vital records of Warick and your Spiritual Wife-ism page.
--BobC

Sheesh. I didn't "see" it because it was RED. I don't think of clicking on red links because I expect them to be empty. Yes, you're right; between what both of you shared, I'm getting what I want. I appreciate your patience as I continue to learn the ropes. jillaine 21:03, 4 February 2009 (EST)

Advice for converting User pages to Articles [12 February 2009]

I have a couple of questions I could use some help with.

Because I probably didn't know better at the time, I've created some User pages (only editable by me) that should probably be Articles (editable by the community). But I can't quite figure out where to put them.

Related to where to put the above, I'm really trying to understand when and how to use subdirectories. If there's some text about this somewhere, please point me in the right direction. I've attempted to find advice through Search and Help, but can't find it.

Also related (and I know this was talked about recently; I just can't find it-- does Search search the watercooler archives?): I've transcribed a number of documents, such as wills, probates, other old items from colonial New England times. (See above.) I recall a recommendation that these be put in my User space because they are "personal" documents. But given that these are documents pertaining to people in colonial new england with a significant number of descendants, it occurs to me that they aren't really "personal" to MY family. And they should go somewhere else. But where? I recall being told NOT to place this text in the text box of the Source.

Should it go in a subdirectory of the relevant Person page? Please advise.

Thanks!

jillaine 20:13, 3 February 2009 (EST)


Regarding "subdirectories" I see you've already incorporated my suggestion to create your own index page, such as User:Jillaine/Transcriptions. So you may be looking for something less obvious and/or more automatic. Hope someone shares that.
Regarding the search for archived Watercooler items, on the page that appears on the WeRelate:Search WeRelate Page, enter your search criteria and select "WeRelate" under the "Namespace" block. The search results will find what you are looking for if it is available. It works for both the current Watercooler page as well as archived Watercooler pages.
For article of general interest, just "ADD" your own article without the "User:Jillaine" tag. It should be created as a publicly accessible and editable page.
--BobC

Bob, thanks for the response. I figure that inside of User:Jillaine, I can create subdirectories to my heart's content. It's "My" space, right? But I'm thinking about how (if at all) to use subdirectories in the "Article" space-- or rather in the non-User space; ie., the community-editable space.
I started looking around to see how others are organizing the wikispace, and I'm only more confused than I was before. I looked at the articles in the "Main" space and I can't help but wonder why they're there at what I would call the "Root" level of a directory. For example, there are all those south-east Virginia pages just hanging out there. Why don't they have their own subdirectory? Are there guidelines somewhere for organizing the wikispace of WeRelate? I get that there are "name spaces" (Article, Person, Family, User, etc.), but I'm talking about within each of those.
And semi-related, but perhaps more related to Jennifer's proposal above about portals, is there anything to prevent or discourage users from creating, for example: WeRelate:Portal and emulating the wikipedia Portal concept here? Jennifer's made a proposal and asked for feedback. So far, only I've responded. Is there some approval process that needs to happen or can Jennifer or anyone else just START such a set of portals?
Elsewhere, I've seen Dallan and others encourage users to create and edit help pages. And certainly we're encouraged to create and maintain articles, etc. *I* would read that as a culture that would respond to Jennifer (or Jillaine, who's all ready to start working on it) with "Go for it!" But I also know that I've "gone for it" in the past (about renaming pages) and had to backtrack because I went against protocol. I'm fine with how all that came down, but it all makes me a bit confused about what we are and are not encouraged to do in this space.
-- jillaine 21:14, 4 February 2009 (EST)

Subpages (subdirectories) have a couple of downsides:

  • A page can be a subpage of just one "primary" page.
  • If the "primary" page is renamed, subpages are not automatically renamed.
Dallan, I see that you're intentionally conflating subpages with subdirectories. I KINDA see that, but I still see a workaround. Couldn't you have:
just to serve as a "directory" -- not a PAGE (even though yes, I get that it's technically a page). Then that way you could have:
or

UGH... Disregard the second bullet of each of the above; I only just this mornign realized that there is no "Article" namespace like there are other namespaces. the "Article" namespace is actually the "root" directory or what others call the "Main" space. But my question still stands: couldn't we create subdirectories off the main "root" directory? jillaine 08:59, 12 February 2009 (EST)
The thing is we don't have subdirectories. It's just like Wikipedia, where there are 2M articles all at the "root". We sub-pages, but they have limited use. The most-common use of subpages is associated with User pages, since User pages are not likely to be renamed.

In general I would use Categories instead of subpages, unless you're pretty sure there won't be a need to rename the primary page in the future, and the subpage is tightly-related only to one primary page (e.g., it's a chapter in a book, and the primary page represents the book). On the other hand, an article can be in multiple categories, and you don't have to worry about doing anything special if the article is renamed. Categories are how articles at Wikipedia are organized.

Please say more; I have no idea how I would use Categories in the case of these transcriptions. I'll go look and see if I can find a Category tutorial...
You could put a [[Category:Transcriptions]] or even a [[Category:Jillaine Transcriptions]] at the bottom of each transcription page. This causes a "red" link to the category to appear at the bottom of each page you add the category to. If you click on this link, you'll see a list of all pages that the category has been added to. You can even edit this Category page with some general information about the category.
People at Wikipedia even create category hierarchies (like directory hierarchies) by assigning category pages to higher-level categories. So for example, you could assign your transcriptions to [[Category:Jillaine Transcriptions]], someone else could assign their transcriptions to [[Category:their-name Transcriptions]], and then you and they could both make your transcription categories sub-categories of a higher-level Transcriptions category by adding [[Category:Transcriptions]] to the bottom of your "user-name Transcriptions" Category pages. The best way to learn about categories right now is to pull up a page in Wikipedia and look at the categories that page is in. Try editing the page or the category page to see how the categories are assigned.

As for which namespace your pages belong in, the "Spiritual wife-ism" and "Tracking" pages could be moved to the article namespace if you wanted others to edit them as well.

Got it; at least this one's handled. ;-)

We've had a difficult time figuring out the best thing to do with transcriptions. I think making each transcription a separate article (or even a subpage) would clutter up the "article" namespace quite a bit.

Wouldn't you agree, then, that the "root" space is BADLY cluttered? Seems like a lot of what's in there should be in some other namespace, right? I find the root space horribly cluttered. But is this just part of wiki-land that I'm just not used to?
Yes, the root space has general articles all at the same level, just like Wikipedia. I agree it would be nice if someone were to organize those articles by assigning them to various categories (which is how Wikipedia organizes their articles), and listing the major categories in our brand new Article portal.

You could leave them where they are and let people add comments to the talk pages if they want something corrected. Or you could create MySource pages for them (e.g., MySource:Jillaine/Daniel-Denison-Autobiography1672). MySource pages are editable by others, and MySource pages are intended for this sort of thing - sources that don't apply to enough people to qualify as community sources. In fact, I've been thinking about adding "Source title" as a new field to MySource pages, so that you could say which community Source page your MySource page (transcription) is a part of.

Well, this is the first I've heard that MySource pages could be edited by others. Interesting. While I'm willing to take a closer look at using MySource in this way, I resist this because my "MySource" is so cluttered with GEDCOM-uploaded Sources that really should be Community Sources.

I hope that we can maintain a culture of "go for it!" Some ideas don't catch on (we do seem to be picky about how pages are titled), but I think most ideas do. I'd start by creating an example and requesting feedback, as Jennifer has done. Even if the consensus is it's not a good idea, it's hopefully not too difficult to undo. As for the portal idea, it seems like a great idea personally. I was working on the upcoming merge-during-upload last week and let responding to the watercooler slide or I would have responded sooner. We do have difficulty helping people navigate to the more interesting areas of the site, and portals seem like a great solution to that problem. --Dallan 16:16, 9 February 2009 (EST)

inline comments by jillaine 23:01, 9 February 2009 (EST)
reponses by Dallan 13:44, 12 February 2009 (EST)

Current v. historical place names [17 February 2009]

I noted that the the agent has created Place pages that have more historical rather than modern names. Furthermore things seem to be inconsistent. The problem especially arised with the patchwork quilt of free cities, baronies, duchies, ecclesiastical principalities, etc. that existed in southern Germany during the long decline of the Holy Roman Empire. During the time when many immigrants came to America in the 18th century, there were many Germans, but there was no Germany. Consider this map of one period in the history of southern Germany during the 18th century: MAP. My question is, should we use the historical names or the modern administrative names? For an example, my Varner ancestors came from Massenbach. The agent gives this as Place:Massenbach, Württemberg, Germany. During the 18th century, Massenbach was a free town (barony) with a Freiherr (baron: "free lord"). The land was not under fief of any other lord except the emperor. It would not be part of Württemberg until after 1806 (and I'm not even sure about then). This area changed constantly due to numerous wars and invasions. The modern administrative designation would probably be: Massenbach, Schwaigern, Heilbronn, Stuttgart, Baden-Württemberg, Germany. To illustrate the inconsistency, the Heilbronn district ("Kreis") seems correct: Place:Heilbronn, Stuttgart, Baden-Württemberg, Germany, but the city itself has an older style name: Place:Heilbronn, Württemberg, Germany. The latter is funny since it's not modern, but there was no "Germany" when Württemberg was a Duchy and Kingdom. ---Parsa 16:04, 7 February 2009 (EST)


The Place pages for this area of the world are definitely in need of some help! Generally here at WeRelate, the general goal is to name locations as they were around the year 1900. That being said, your are right, the pages are inconsistent. They were gathered from a variety of sources, some more modern like Wikipedia, and some more historic like FHLC. We also have the problem of there being multiple pages for one town. I had started to put together some basic ideas here. The ultimate goal would be for there to be one place page for one town, and each alternate location would be listed within that page, like I've been doing for the Netherlands Place:Baard, Baarderadeel, Friesland, Netherlands. I also think the Wikipedia template on the page can be misleading, since it always contains the modern town location.--Jennifer (JBS66) 16:32, 7 February 2009 (EST)


What's the reasoning behind the 1900 date? I can see setting a reference year. They do that for star positions on star charts. However, politics is much more chaotic, and most people's knowledge of exact geography in 1900 may be pretty weak. Does the date mean we have to list towns in Alaska as being part of an unorganized territory? A lot of nations did not even exist in 1900. If a person's ancestor came from a particular area in Germany, the political structure could change wildly between 1600 and 1945. My suggestion would be to list the modern location, then have users add geopolitical and historical information and dates for the town or region. The problem also arises in the USA in regards to counties. While towns are relatively constant, counties have changed, increased in number, and been eliminated over the years. My ancestors in the Piedmont area of North Carolina could stay on one farm, yet be living in several different counties over a 50 year period. ---Parsa 18:56, 7 February 2009 (EST)

What we're seeing here is where documentation of genealogy conflicts with the notion of an encyclopedia. Good documentation in genealogy, I've been taught, requires that you use the name of the place as it was at the time of the event. Therefore, for events prior to 1776, Massachusetts was a colony of the British Empire. After, it was Massachusetts, a state of the United States. In the case of "Germany" it would be as described above, different for each specific time period. But such documentation would be more accurate than calling the place by its 1900 name or current name or ANY one name from a given period. An online ___pedia "insists" on a single page for a given place. But this is not consistent with proper genealogical documentation. jillaine 20:22, 7 February 2009 (EST)

Thanks Jillaine for describing the dilemma concerning places on this site. I think this is one of my main stumbling blocks to uploading my info. I tried just a small chart and [the results] concerning places were not good. This may be one area where this wiki needs to separate itself from the online _____pedia method. I am not active enough on this site to carry any weight to have this changed, but if you can have influence to change it, the rest of us wiki-challenged genealogists will thank you. --Janiejac 23:26, 7 February 2009 (EST)


I don't know what "correct" genealogical practice might be, but I think the most useful thing to do is use the present day location that most correctly specifies the actual geography/place being specified. Put differently, I want the location that has the closest GIS values to the actual location of the events being specified.

Consider the problem for genealogical-map making - if names have to be cross-referenced with dates to figure out what is really meant - the problem becomes impossible.

There is something you can do to improve things though - if you know the location of an event to the level of GIS specificity, you can put a google maps reference in the description for the event. Dallan has specifically rigged the map-making function to look for google map references in the description field for events, so you can refine a location to any level of detail you may want. Take a look at my Grandfather's page for some examples. You'll also see that you can use the same method to create picture captions that nail locations where pictures were taken...--Jrm03063 00:00, 8 February 2009 (EST)


I have to agree with the statements above. A place is a locality where people live. It has a geographic location and an historical and cultural background that doesn't change with political boundaries. Genealogists list women by their maiden name, not by every married name they have. I've noted a great many errors on web sites in regards to political names of places. A town in North Carolina may have been in a half dozen different counties in addition to being part of the Carolina Colony, the North Carolina Colony, and the State of North Carolina (North Carolina Formation Maps). In order to avoid having dozens or even hundreds of names for the same locality, it makes sense to me to create a page for a geographic location using the latest political designation. Then a list can be placed on the locality page giving changes in political boundaries for different dates. The principle is similar to giving dates for various noble titles for rulers (such as those of Rudolph II, Holy Roman Emperor given on the bottom of the page here). ---Parsa 01:41, 8 February 2009 (EST)



The use of non-political coordinates such as longitude and latitude offer the hope of having a stable designation that can be mapped, for those that are tracing the migration of their family, etc. It lacks a little in intuitiveness. Using the current political name is more intuitive, but it may not be so ten years from now. Further it may not match the names seen in documentation (Monomoit versus Chatham, MA). Some of this can be addressed by redirects unless having dual names creates conflicts. Finally, one would like to have a clue where to look for research materials. The name of Northfield, Mass. used to include parts of Vermont and New Hampshire until 1740, then was part of Hampton County, Mass. until 1811, and now is part of Franklin County, Mass. So when looking for vital records and probates, one may need to try multiple administrative units to be thorough.

It is a difficult problem, but it is just part of the fun of genealogy. Until Dallan can provide an input mechanism based on picking a name off of a historically adjusted map, which he then stores in a neutral form, and displays to each viewer according to their preferences (current, colloquial, or historical administrative), or some such complex system scheduled for completion in 2050 probably, I suspect choosing what seems most intuitive to the thousands of viewers, is probably the best approach. --Jrich 10:21, 8 February 2009 (EST)


As Parsa noted, those with German ancestry know well the problems associated with place names. All of my maternal ancestors originated within the old Kingdom of Prussia (or Preußen, as it is commonly seen on old documents), most of them from the area where the Polish nation had originated, which was known as the Province of Posen after the forced partitions of Poland by Prussia in the late 1700s. The Polish place names of today bear little resemblance to the same geographic German place names while under Prussian and German rule. I'm not so sure the suggestion to use the current place name (which would probably be abhorant to my German ancestors of the 19th century who may have looked upon the Polish culture, language and people with disdain) and use the redirect function for the old German place is the answer (versus the use of the 1900 place name).
For example, relating to the Province of Posen, prior to Prussian occupation, the area was part of the larger Polish-Lithuanian Commonwealth. The German place name (Provinz Posen) was used from the late 1700s through the end of WWII, identified more specifically as the Duchy of Warsaw during the years of the Napoleonic Wars of the early 1800s, and the Grand Duchy of Posen (or Großherzogtum Posen in German, Wielkie Księstwo Poznańskie in Polish) after that time up through World War I. Since World War II, the current Polish place name Prowincja Poznańska has been used.
I’ve seen gazettes and place name charts identifying the different versions of the same German-Polish place names, and will include links to them if I can find them at a later time. Something like that could be incorporated (along with GPS/longitude and latitude) into a cross-referenced redirect function such as Jrm03063 & Jrich suggest.--BobC 11:44, 8 February 2009 (EST)

One solution is to place the currently named location into the default Place field, and use the Alternate Place for the place as documented on the documentation of the event. (Or vice versa.) Another solution is to use the current name in the Place field and place the historically accurate place name in the citation of the source. jillaine 13:41, 8 February 2009 (EST)

Yes, that's true. Also what could be done is to continue to allow pages to be created for historical place names, but have them created (somehow) as a sub-page of the current designation. The main page could have brief descriptions for each period, with a link to the main article for the historical town information. Additionally the sub-pages would of course have a "back" link at the top to the main designation as they always do. ---Parsa 14:20, 8 February 2009 (EST)

Whatever solution is proposed as far as titling Place pages, there will be members of the WeRelate population for whom it doesn't work. Some feel strongly about modern titles, others about historical titles. However, these titles are essentially just pointers to a page. Say your ancestor was born in Town, County A, State, United States and died in Town, County B, State, United States (without ever leaving the farm). I agree with Jillaine that it is appropriate to indicate the location as it was when the event took place. However, we have this unique Place page title to deal with. The workaround for this is to place the following on your Person/Family page: WeRelate Place Page Title|your own title. When you then look at your Person/Family page, what will show up is your own title. This way, we are keeping the pointer to the correct place page (the WeRelate Place Page Title), while documenting how the town was at the time the event occurred (your own title). Then, when you click on this link, it will bring you to the correct Place page.

Example: Place:Holwerd, Westdongeradeel, Friesland, Netherlands. Holwerd used to be in Wesdongeradeel, and is now in Dongeradeel. Since I put Dongeradeel as an Also-located in place on the Holwerd page, I can choose to type Holwerd, Dongeradeel, Friesland, Netherlands into a place field and a link Holwerd, Dongeradeel, Friesland, Netherlands is automatically created.

I would like to see a definitive decision made, and guidelines put into place. Then, the gusto that is currently focused on the discussion of titles could instead be directed to merging the say 4 versions of the same town into one page and adding all the variant information within.--Jennifer (JBS66) 14:35, 8 February 2009 (EST)


1900 was chosen as the reference year for Germany simply because this was the reference generally used by the Family History Library Catalog (FHLC), and more places were imported from the FHLC than the other two sources, so keeping the FHLC reference year was the simplest path. Interestingly, the FHLC chose different years for different countries (France is much later for example, and the US uses generally modern jurisdictions), but in general they chose years around 1900 for most European countries. The reference period we use for a particular country is listed on the country homepage (e.g., Place:Germany or Place:France) for most European countries. Also, I'm not sure why but the FHLC included places in Thüringen, Germany even though it wasn't created until 1919, so we have some German places listed under Thüringen. Even though we've spent many hours cleaning up Germany, it could use additional work. The same goes for Poland and the other Eastern European countries.

So what to do about places that change their jurisdiction over time? We have four options at our disposal:

(1) As Jennifer says, you can use the | notation to give any place whatever title you want in your Person and Family pages. When you upload a GEDCOM, whatever you've entered for the place appears after the | automatically, so that your uploaded page shows the place as you entered it, but links to the place that the place matcher matched it with. The upcoming update to the GEDCOM upload process will allow you to review and correct the Place pages that the place matcher matched your places to before the wiki pages get created.

(2) You can edit the Place page and add the earlier or modern jurisdiction as an "also located in" place, and the earlier or modern name as an "alternate name". You could even describe the history of the place's jurisdictions in the description field. A few hours after doing this:

  • The place matcher can match places listed using the alternate jurisdiction and name to this place.
  • Searches on the alternate name and jurisdiction will find people/families with events listed in the 1900 place and vice-versa.
  • If you enter the place with the alternate name and jurisdiction, the drop-down list will show the 1900 place (according to its 1900 title).

(3) In addition to option 2, you could create a new place page, title it according to the earlier or modern jurisdiction, and "redirect" it to the existing Place page (with the 1900 title). A few hours after doing this:

  • The drop-down list of places will list the new place that you created and show that it redirects to the 1900 place (in addition to listing the 1900 place title).
  • When you select the redirected place in the drop-down list, your Person/Family page shows the title of the redirected place with the alternate jurisdiction and name, but links to the 1900 Place page.

(4) You could create a new place page, title it according to the earlier or modern jurisdiction, and list the place with the 1900 title as a "see also" place. This does not affect either the place matcher or the drop-down list.

In most cases when the regions of a country are re-organized, I think options 2 and maybe also including 3 are ideal because they provide cross-search capability: when you search for a place in an also-located-in jurisdiction you find events in the main jurisdiction and vice-versa. A number of places have their modern jurisdictions listed as "also located in" places for example. Once the "also located in" relationships were established, the redirects of option 3 could even be created automatically if desired. But it takes time to set up these relationships. That's why Jennifer is proposing the User:JBS66/Eastern European Place Renaming. I hope that people will get involved with this!

As places move between countries, it may be more useful to go with option 4 instead of options 2 and 3. You'd lose the cross-search capability, but it may be more intuitive for people looking up Polish ancestry to link to Place pages in Poland that contain see-also links to their German/Russian counterparts. I'm open to this.

I'd love to get feedback on this, especially if you're interested in helping to reorganize places. You'll notice for example that places in Place:Scotland are pretty well organized due to the efforts of people like User:TomChatt and User:LSnellgrove. (Places in several other European countries also owe their current organization to specific individuals.)

I hope I haven't missed any of the questions above. Please let me know if I forgot something.--Dallan 16:16, 9 February 2009 (EST)


Just to be clear, I don't suggest GIS coordinates instead of a place name. I do strongly suggest use of GIS coordinates if a location is known to that level of precision, since a town or village location leaves out a lot of nice-to-have information. GIS numbers are probably more handy than a street address, and certainly longer-lasting. Another for example - how much easier would it be to find a grave site (even in a smallish cemetery) with a set of GIS numbers for the plot?

I guess that I was trying to say that having GIS data obviates the problem of picking "the right" town/community name.--Jrm03063 16:36, 9 February 2009 (EST)


Just to give you someone else's take on this issue, I've copied this exchange from the AncestralQuest Users group as someone was asking how to replace all her historical place names with place names to coordinate with nFS (I guess that is New Family Search). A response was given and I hoped if this would be helpful in discussing this issue:
Re: Editing places
Posted by: "Stewart Millar" sm999@tiscali.co.uk sm99923
Mon Feb 16, 2009 9:06 am (PST)
Selecting to use the "Standardised Place Names" is not "correcting" your place names; the nFS standardised place names do not provide a "more" correct place name, merely one that is "standardised" to fit a modern map location.

nFS actually holds both the "original" entered place name-as befitting the location at the time of the event and an associated "standard" place name which the system will use for mapping and indexing/searching. It is the "original" entered place name that is displayed in nFS; but on the Details screen, hovering the cursor over the place name will cause the associated "standard" place name to be displayed.

There is a corresponding "original" and "standardised" feature with dates, except that in this case it is the "standard" date that is displayed and the "original" that can be seen by similarly hovering the cursor over the date.

Please don't be fooled into thinking that it is necessary to use the "standardised" place name as a "better" alternative to what you might already have; there are good reasons for having both.

We (in the UK) have a very particular problem with standardised place names, as to fit with a modern gazetteer and map they use "United Kingdom" as the "country" designation and provide multiple choices of "counties" incorporating the historic counties and the modern overlapping government areas known as "Unitary Authorities" - whereas the standard genealogical definition of place name in the combined "United Kingdom" is to use the originating host nations of England, Scotland, Wales and Ireland as the country designations and then to use the historic counties.

One further note on this issue; if you ever use an ecclesiastical parish as part of the place name, parish names are not included in the standardised place names - but the entered "original" place name containing the parish name will (usually) identify a match with a standardised place name which you can select to associate with your entered place name.

Give it some more thought.

Regards, Stewart Millar


We're similar to nFS: we hold both the original place name, which is the name that is displayed, and the "standard" place name, which is the matching place we found in the wiki and which is used (like nFS) for search. In the wiki pages that are generated, the standard place name appears before the bar and the original name appears after the bar. We don't include "United Kingdom" but use the original 4 countries as the highest level for the UK.--Dallan 16:03, 8 April 2009 (EDT)


African American - Slave People Pages [15 February 2009]

Hello,

I am hoping for suggestions. I am finding the names of slaves on the will of the Owner. I would like to create People Pages for these African Americans. So far I only have first names. Is there a tutorial, or agreed to system on how to create these People Pages? How are other Werelate Users handling this situation?

Debbie Freeman --DFree 20:56, 8 February 2009 (EST)


Hello! Didn't a lot of African Americans gain a last name either by becoming part of a "white" family or through some kind of association with another family? If so, many of these people may be lacking a last name (Especially if they died before being freed)... This is a very perplexing question... but it's all-encompasing, Roman and Greek slaves will be in the same boat (If anyone can trace into Rome or Greek slaves). Chinese immagrants especially in California might be in similar situations. Should we have some kind of pattern for slaves? I hate to say this (Because it sounds really awful), should we have an "Owned by" option? (In the interest of scientific history, not because we condone owning people, of course) Which would connect the slave to a family (Which might be the only connection they ever have) Who knows? Someday a family might link up with that slave and connect through a tree that way. ---Guy Aabh 20:08, 12 February 2009 (EST)


The people at Lowcountry Africana seem to organize slave records by plantation. What about using the plantation name as the surname; e.g., "of Drayton Plantation"? This is of course similar to the idea of using the slave owner, but it seems like using the location they were from (plantation name) is more in keeping with what we do with medieval people. Just a thought.--Dallan 22:16, 14 February 2009 (EST)


Hello Aabh & Dallan,

Thank You for the input and suggestions.

I will try to locate a name of a plantation, but highly doubt that in these cases there is a plantation. It is a few to maybe a dozen slaves in total.

Most are slave owners from Kentucky or Tennessee that migrated to Missouri before 1850. Some of the owners siblings stayed in Kentucky and or Tennessee. So I assume there is a good chance that the MO slave are related to the KY and TN slaves.

Debbie Freeman --DFree 22:37, 14 February 2009 (EST)


Merge during upload in progress [13 February 2009]

I said earlier that merge-during-upload would be ready this week, but unfortunately, it's not ready quite yet. If you've been aching to see what it will look like, you can go to http://beta.werelate.org/gedcom/gedcom.html

beta.werelate.org is a website that I use for testing. It's not guaranteed to be up and running, and it has a very old version of the wiki database, so don't expect the content to be the same as on the main WeRelate website. Feel free to use it as a sandbox if you want. If you've been a member of WeRelate since Aug 2007, you can sign in with your old username and password. Otherwise feel free to create a new account. (You'll need an account in order to look at the gedcom upload tool.)

In the future, after a user has uploaded their GEDCOM, but before the wiki pages have been created, the user will get a message on their talk page directing them to review their gedcom and prepare it for upload using this tool.

You can't do any merging yet, but you can review the people, families, sources, and places in your GEDCOM. I'm working on matching sources, places, families, and people (in that order).--Dallan 16:16, 9 February 2009 (EST)

This is wonderful! I really like the tabbed layout, it's all very intuitive. This will be a great additional WeRelate feature. --Jennifer (JBS66) 08:08, 13 February 2009 (EST)


Notes and footnotes [16 February 2009]

I have not been able to find anything specific in the help pages or in Watercooler on the appropriate time to use notes versus footnotes. Notes of the type: N1, N2, ..., are generated when Gedcoms are uploaded, and can also be created using the Note boxes on the edit pages. Footnotes are also generally the same sort of notes, but are created using the "ref" tags. I've looked at several Person pages, and within the text section, some people have used footnotes, while some have added a target to a Note, such as [[#N1|N1]]. Is there a preferred way to do in-text notation? When would it be more appropriate to use the Notes or wiki-style footnotes? -- Parsa 14:22, 11 February 2009 (EST)


The current documentation state is more "how to do stuff" than it is focused on "how you should do stuff". Still, I think your question probably contains the elements of your answer. Ultimately, werelate content is supposed to be able to download to form nice GEDCOM material. Presumably there are some generally accepted practices on when and how to use notes in GEDCOMs, which would therefore be the approach to take here.--Jrm03063 14:44, 11 February 2009 (EST)

There is some overlap between notes and sources as well. Here is a rough description of how I find myself differentiating between them, for what it is worth.

  • If I want to reference a source to "prove" a fact, I create a source and tag the fact or facts it applies to. The source is a place somebody can go and verify that the information claimed is there.
  • When I want to add historical notes or narrative that should be more or less permanent and apply to the subject of the page, I use the history section, embedding [[Source:name of source]] references as needed.
  • When I want to add more of a personal comment or explanation, especially in the situation where it might want to disappear in the future, I use a note. For example if I am commenting on a discrepancy between sources and explaining why I chose one over the other, or explaining how I estimated a date, etc. Ideally, when all information is fully known, the notes would no longer be necessary, but they explain some assumption or some logic that fills in a gap in my knowledge of the facts.

A better source doesn't mean that the replaced source disappears. It may be useful for the incorrect source to stay and continue to testify to its own incorrectness. However, it is likely that a better source will remove the need for a note. A note explaining that the marriage date is estimated based on the birth of the eldest child would be silly once the marriage record is found. Since notes are easy to "remove", this seemed to be a good use of this feature. --Jrich 18:23, 11 February 2009 (EST)


But when do you use the <REF>...</REF> tags? jillaine 09:01, 12 February 2009 (EST)

Notes are described as being intended to hold information that doesn't fit anywhere else. They may be attached to facts, or sources, or dangling. There is no button at the top of the text window for referencing a note in the text section. Is there a way to do that? I suppose this is the [[#N1]] mentioned above.

Footnotes <REF>...</REF> appear to be the supported method for annotating text in the historical narrative. One wiki construct creates the reference to the footnote and the footnote itself, and all the data is in one place which makes future editing easier. This would seem to be the preferred way of referring to a source, or adding a parenthetical comment, or supporting information to your narrative when you don't want it inline.

Notes seems to have only a few good uses. For one thing, it is displayed way at the bottom of the page, possibly separated from the text section by images and sources so not necessarily in a place where people will look if the page happens to have lots of data on it. I think they could be one way to document disputed lineages rather than spending the whole history section for an individual talking about other people who he is not, which seems somewhat demeaning to his importance. Also, as I mentioned, they seem a good way to provide assumptions, and deductive logic, that may go away in the future.

Of course if you have written a note, and want to reference your note without duplicating it, or adding a footnote that says "see note 1", you could do the above, but otherwise, I suspect footnotes will be a better way.

But this is just my opinion. Clearly a consensus needs to be reached and guidelines added. --Jrich 10:38, 12 February 2009 (EST)


GEDCOM's support notes, but not footnote references. When we support GEDCOM export, the contents of the big text box will be put in a single note attached to the individual or family. So when someone exports a page with ref tags and views it in their desktop genealogy program, they're going to see the page source containing the ref tags (without the generated footnotes section).

Having said this, I personally don't like GEDCOM notes. In the desktop genealogy programs that I've used it's not obvious when a note has been attached to a particular person or event. And you can't see all of the notes attached to any event for an individual together. Ref's are more convenient to work with when you're use footnotes in inline text.

So I think the question is whether you're writing primarily for online display or for GEDCOM export. If you're writing for online display I'd go with ref tags.--Dallan 14:22, 12 February 2009 (EST)


Ick! There must be ways to avoid a choice of this sort...--Jrm03063 18:27, 12 February 2009 (EST)

On one Person page I'm working on, I added footnotes to an historical account in order to explain some terms (such as what "Regulators" and "route agents" were in the Mid-West). There are also notes referring to research for death location, etc.

It seems as if a computer program can turn a Gedcom note into an html target tag and note, that a program could also interpret a reference tag and its contents and convert it to a Gedcom note. -- Parsa 22:00, 12 February 2009 (EST)


Yes, the GEDCOM export could certainly turn a ref tag into a note, but here's another problem: many desktop genealogy programs can only handle one note per individual or event (I don't know about all of them, but I just checked Family Tree Maker, PAF, and RootsMagic and they all behave this way). Multiple notes attached to the same individual or event get combined into a single note. PAF doesn't allow attaching any notes to events as far as I can tell. So if the GEDCOM export were to export each ref as a separate note, they'd all get combined together into a single note when the GEDCOM was read into the desktop genealogy program, which defeats the whole purpose.

What's really needed I think is a desktop genealogy program that can display formatted wiki text. I hope we'll have something along those lines eventually. Until then I'd still use the ref tags instead of notes.--Dallan 22:36, 14 February 2009 (EST)



Person Naming Revisited [15 February 2009]

Okay, after all that above about Thomas Carter, I thought I'd figured it out. But then someone just renamed a page and a primary name of a woman to her married name. That said, she was born prior to 1500, so maybe an exception? And also, wikipedia uses her married name, and we're using content FROM that wikipedia page. But we KNOW her maiden name. What to do? What to do?

Person:Katherine_Swynford_(13)

Does her name have to match that on wikipedia when pulling in content from wikipedia?

I have a personal fondness for this woman. (Read a book about her when I was a youngun') So I'm feelin' rather attached to her having her maiden name as her primary. (Just thought I'd warn ya!)  :-)

-- jillaine 14:56, 13 February 2009 (EST)


And btw, I posted this HERE vs on her person page, because i want to make sure we're all on the same page about this. It's not specific to her, but to anyone like her. k? jillaine 15:01, 13 February 2009 (EST)

Presumably, I'm the one doing the renaming, so I'll explain why I do it. There is no werelate "functional" reason that matching up with the wikipedia name is required. Referencing the wikipedia download "Wp-<name>" template takes care of creating the association so that other wikipedia pages, referencing that person and extracted for use in werelate, get turned into werelate links to the correct werelate page. The real issue is the process of working through the enormous mess that is our space for European nobility. When pages are named according to the wikipedia convention, then second attempts to create the same name wind up getting flagged with a larger sequence number. --Jrm03063


are you Bergsmit? That's who's doing the renaming of my dear Kat. Okay, then is the policy that an exception exists for European nobility (including their ancestors)such that we should use the name that history most closely associates with the person-- and that's the name wikipedia uses?
I keep forgetting that she falls into this category because it was her descendants who became noble while she went down in history as John of Gaunt's paramour...
-- jillaine 17:46, 13 February 2009 (EST)

It seems to me as an uninterested person that a genealogy website should follow the genealogical convention of using the maiden name. As far as the goal to catch future merges, who's to say merges won't come along with the maiden name? What about an alternate name? In the check for duplicates, if the spouse or parents match, name variants still show up near the top of the list. I would guess a matching alternate name with these additional criteria would be sufficient to tag it as a likely merge in a GEDCOM update??? --Jrich 18:06, 13 February 2009 (EST)


I'm not Bergsmit, but he is following the conventions that I generally observe, which means naming such pages consistently with wikipedia when possible. This really helps create connections and merges that I wasn't even looking for.

Let's remember - we're talking about the page name only. You can still attach any number of alternative names on the page.--Jrm03063 19:42, 13 February 2009 (EST)


Actually in this case I'm referring to both the page name and the primary name fields. Both were changed. -- jillaine 19:57, 13 February 2009 (EST)

I thought that the policy about using Wikipedia names was intended only to apply to people who don't have last names. Otherwise, there's little reason why any woman whose maiden name is unknown shouldn't be listed as her married name. This is a genealogy site. We should use the maiden name where possible. In this case, it ends up very strange for usability purposes to have "Katherine Swynford" listed as a child with parents of a different name, or with family pages using her maiden name. This a far cry from using "Queen Victoria" or whatever. JRM is going to have to be more specific about how this is helpful in any case except when someone is not following genealogical naming conventions, which is not a good reason to change our practices.--Amelia 20:38, 13 February 2009 (EST)


I'll try to explain myself one more time. I need this as I'm working through trying to both merge the medieval space and get as many pages as possible boot-strapped with wikipedia content. To give you an idea of the scale of the problem, there are presently 49 redirects on Charlemagne (1) alone.

The way this works, is that the "wikipedia" people become landmarks in the medieval space. As I work through the space, I try to associate as many pages as possible with a backing/shadowing wikipedia page, working outward from any known point (wikipedia associated). If I rename a page to it's backing wikipedia name, and I hit a sequence number greater than 1, I know I'm looking at a duplication that I need to merge. If I find the wikipedia page references people that are not already added to a family, I add them under the wikipedia name and often discover that the person was already added as a result of their membership in some other family. Do all that while merging spouses, merging parents, etc.

Names in this space present some major challenges - besides the problem of no common first/middle/surname feature, you have names that have been applied by genealogists after the fact for purposes of distinguishing people. You also have multiple forms of the same name due to scrambling of the name components by various software. Another layer of fun, you get various titles of nobility mixed in Duke, Earl, Marquis, Elector, Knight, Poobah, etc. Finally, you get to see all of this in various states of English, German, Dutch, Spanish, French.

A well-mannered name is an aberration in this space, and so it isn't as helpful as you might think.

Using the approaches I've described, I've associated something like 1900 werelate people with backing/shadowing wikipedia pages. Except for a few dozen folks, that's all in the medieval/renaissance era. Since there are probably two non-wikipedia backed pages adjacent to every wikipedia backed page in the space, that takes the number of person pages up to 5000 or so. If you then look at the pages I share in common with bergsmit, you'll see that it's typical to have ten or more people watching a page (as a result of merging their common people). So, very roughly speaking, I've been able to do a reduction of something like 50000 down to 5000.

I've made a lot of progress, but it's not done.--Jrm03063 21:54, 13 February 2009 (EST)


Interesting strategy: renaming a page and the primary name fields in order to find appropriate merge candidates. And if the numbers you cite are accurate, an impressive result in terms of merges (and Dallan's numbers indicate that you and Bergsmit are up at the top. So, here's a possible solution: once you've completed the merges, change the names back to the genealogically-appropriate convention. -- jillaine 07:25, 14 February 2009 (EST)

I completely agree with your suggestion. I just think we'll want to think about the problem of names in the medieval and nobility spaces more comprehensively, instead of just taking a name or two that happen to be well behaved, and then apply the modern convention.

My numbers are all estimates of course, and Dallan is probably in a better position to comment. I'm not averse to showing my work on the estimate though! I arrived at it thusly:

  • Search on person pages containing the "wikipedia-notice" template. That turns up something over 1700.
  • There are another 100+ pointed at by the "wikipedia-source" template, which will run again this weekend.
  • Maybe 100 of them are "modern" (presidents and immediate family, FDR, etc.)
  • Assume two adjacent non-wikipedia people for each one found

(1800 - 100) * (2 + 1) = 5100

I randomly probed around to see how many people are "watching" (which is a good quick indicator of how many were merged to get there). My guess was that 10 was typical, but perhaps that's over-optimistic. Whatever number you think is the overall "average" reduction, multiply that by 5100 and that's where we started in the space.--Jrm03063 08:03, 14 February 2009 (EST)

While I'll certainly defer to the consensus, especially after things settle in the nobility spaces, I don't understand the passionate desire to insist that the page name always follows the rules for birth name. I would think it should follow the name that would most immediately be recognized for the person (to my mind, the "primary" name) so that it would be easier to spot in a web search.
I also don't understand the insistance on the primary name being the birth name. This point seems particularly odd, since there is a separate name tag allowing specification of the birth name. That birth name tag would be essentially useless except for wikipedia-named pages. A page for Mark Twain would have Mark Twain listed as an alternate name, but plainly it was the name by which he was most commonly known in life and subsequently. Hal Holbrook doesn't do "Samuel Clemens Tonight". Archibald Leach instead of Cary Grant? George Kelly instead of Machine Gun Kelly?
I also recall that one of the reasons given for making the primary name be the birth name, is how that string looks when it appears in the originating family. If that is really a problem, I am sure that Dallan could modify things such that family pages would display "birth name", in preference (or addition) to the "preferred name".--Jrm03063 15:52, 14 February 2009 (EST)

If this site was wikipedia, then your argument might apply, but this is a genealogy wiki. And the bulk of its content is supplied by GEDCOMs, derived from people using genealogy software, who hopefully had at least some basic genealogy training somewhere, which would ground them in using birth names for the primary names. My understanding is that we are following genealogy standards here, and it really has nothing to do with "passionate desire". ;-) -- jillaine 16:22, 14 February 2009 (EST)

I agree. It is nice not to duplicate wikipedia, but given following genealogy rules on a genealogy website, or following wikipedia, I would vote genealogy without a second thought. There is a reason why the websites are separate. If a page doesn't naturally agree in name with wikipedia, add the name as an alternate.

I bet most people who happen to have Cary Grant in their family trees do so under Archibald Leach, so it matches his parents and his siblings, and not under his stage name. That he is Cary Grant is probably added as an alternate name or in the notes. --Jrich 16:44, 14 February 2009 (EST)


So why are there separate "primary" and "birth" names?

I'm not against this as a general rule and/or general practice. I just think there are going to be exceptional circumstances, and we ought to trust the judgement of the people working those pages to - now and again - depart from (primary == birth) convention. Stage names are one such example.

Maybe what you want is to have the "primary name" label changed to indicate "birth" name, and the primary name is dropped as an alternative sort of name?--Jrm03063 17:11, 14 February 2009 (EST)


Do you mean "preferred" name when you refer to a "primary" name? That's the label I see on the Person pages for the main name when I try to add an alternate name. I suspect the "birth" type of alternate name is intended for things like adoption where the person legally took the name of the adopting parents, or possibly legal changes of name. I do not believe it was intended to suggest that a stage name like Cary Grant should be a preferred name.

Because this is a cooperative site designed to ease collaboration, I believe there are conventions that should be followed even when it increases effort a little. I believe the convention of using maiden name is pretty well universal in genealogy. I think stage names, while familiar, are not genealogically useful, as possibly significant parts of the person's life will not be recorded under than name, and that such aliases should take the secondary position to the birth name, i.e. the birth name is the preferred name.

I think you are using your specific interest to justify going against convention. To me, it is shortsighted to do this. However many WeRelate people there may be in wikipedia, many more times that number are not. Further, I still haven't heard that putting the stage name, etc., in an alternate name wouldn't be sufficient to avoid problems with future GEDCOMs which, near as I can tell, is the only real reason given for doing this. I know it be sufficient from a search perspective. --Jrich 19:59, 14 February 2009 (EST)


So let's move the remainder of this discussion to Help talk:Naming conventions.--Dallan 14:22, 15 February 2009 (EST)


Naming Conventions Help Page Drafted [14 February 2009]

As I promised Dallan last month, and to support the current conversation about naming conventions, I drafted Help:Naming_conventions. Not sure that's where it should stay, but that's where I have it now. -- jillaine 14:41, 14 February 2009 (EST)


I offered a simple rule for the family name, which sort of pushes the issue off on the names of the people. --Jrm03063 15:52, 14 February 2009 (EST)

(moved rest of JRM's comments to Page Naming topic) jillaine 16:22, 14 February 2009 (EST)


unknown fathers [18 February 2009]

Can someone advise me?

I am working on a project tracking a number of families in a small area of Yorkshire England in the late 18th century/early 19th century. The birth rate at this time and place for children born out of wedlock is very high. The parish registers I am working from simply give the mother when she is unmarried. I have hopes that I will be able to identify some fathers from court records but for the time being I need to keep track of these children and their mothers with limited information at present.

The only way I know to do this is entering these children with the mother and father Unknown Unknown. Is this really the only thing I can do or is there a better way that creates less Unknown Unknowns in the world?

thank you! Anne--MizLiv 20:41, 14 February 2009 (EST)


Here's what I suggest. Create the family page with the father portion of the name as "Unknown" and the Mother as you know it. Then, just don't create a page for the father - I mean, you don't know anything that would go on the page, so why bother?--Jrm03063 20:45, 14 February 2009 (EST)

I've got an identical situation in 19th century Denmark. See Family:Unknown and Johanne Jensen (1).--JoshHansen 17:31, 18 February 2009 (EST)

Chat feature? [21 February 2009]

Periodically, I see that I'm working online at the same time as someone else, and I'd like the ability to "chat" with them, to possibly coordinate efforts. Any possibility of adding a "who's online" / chat feature? Or has that been discussed and tossed? -- jillaine 21:07, 14 February 2009 (EST)


I don't think it's been discussed before. There are several options. Most of them require that I upgrade to a newer version of the Wikipedia software, so they can't be implemented right away, but here are some things to think about:

  • It's possible to get a list of users who are currently online. Would people be comfortable with this?
  • We could create a way for you to open a chat window with someone. This would notify them that you wanted to chat. They would receive this notification the next time they read a page from the server, just like you are notified now that someone has left a message on your talk page. Clicking on the notification link would open a chat window where you two could chat.
  • Alternatively, we could let people enter their existing Instant-Message user names as part of their user profile and include those names in the list of users who are currently online, and you could use your existing Instant-Message client to communicate with them. (If we did this, I would only want registered users to be able to view this information.)
  • Alternatively, we could create a multi-user chat room, which anyone could visit and chat with other people who had also decided to visit the chat room. We've done this in the past, but very few people visited so we stopped.

--Dallan 23:40, 14 February 2009 (EST)


thank you (both of you!) I will do as you suggest. I am working through various records hoping that I will get fathers for some of them but this will help until (or if) I do.

Anne--MizLiv 15:42, 21 February 2009 (EST)


Tracking Articles [17 February 2009]

I've taken Dallan up on the challenge of "categorizing" the Article namespace. First I'm just getting familiar with what's currently there, creating and "index" of sorts of what I find. But I see that WeRelate does not "remember" where I've been very well. As long as the search results don't change their order (I search for all pages in the "Article" name space with no search criteria other than the name space), I can get buy by keeping track of which search-results page I'm on. But a) I'm not 100% confident that the search results are always in the same order, and b) I'd REALLY like to be notified any time that a new article is added to the "Article" namespace. Or at least be able to easily identify such. Is there some fancy way to use the Search engine that I haven't figured out to get this? Or some other way? Thanks! -- jillaine 19:27, 16 February 2009 (EST)


By the way, what IS the order that search results are given in when no search criteria are entered (other than namespace)? Thanks. jillaine 21:13, 16 February 2009 (EST)
When no search criteria are entered other than namespace and you're not doing an exact search, the order is pretty random.--Dallan 17:19, 8 April 2009 (EDT)

If you search the article namespace, and choose Exact matches only, a couple of options become available. You can sort by title or by date modified. I think sort by title will help you to remember where you've been. The sort by date modified can help you to discover new articles (newly modified that is).

The other option is the Title index on the left side of the search page. After a search, you can choose a letter, and break up your project that way.

--Jennifer (JBS66) 04:23, 17 February 2009 (EST)


Date Conventions [20 February 2009]

Motivated by Help:Naming conventions, I attempted to start a page on dates (Help:Date Conventions). On the surface, it looks like I am trying to legitimatize my opinions :-), but sincerely, I am just interested in reaching a consensus so everybody is speaking the same language. Please express your opinion, as unexpressed opinions will not be taken into account! --Jrich 12:43, 20 February 2009 (EST)


I attempted to write a guideline for nicer person and family events, but I didn't get far so I never submitted the work for review. Part of that was spent thinking about date formats. The most useful things I came up with were:
Wikipedia has an extensive manual of style, with specific guidance on representing dates of birth and death. Included there is guidance on how to represent approximate dates, date ranges, and more. Werelate adopts this guide with caveats:
  • absolute genealogical preference for day-before-month forms.
  • always abbreviate month names to their three-letter form. Never use a numeric.
  • years before 1000 should include a leading 0.
  • days of the month before 10 should not include a leading zero.--Jrm03063 13:28, 20 February 2009 (EST)

It's a good summary, but I need two points cleared up: why do we need a period after such terms as bef, aft, est and all the rest? And I've been using btw for between; should it be bet? The other point concerns Quaker dating. I thought it was more than just the year being different. Isn't there a 3 month difference? As when the Quaker records say he was born 12d 2m 1730, I have been using 12d 2m (Apr) 1730. I've always heard we should leave the date as we found it but can indicate a more modern conversion. Maybe I've misunderstood.--Janiejac 13:43, 20 February 2009 (EST)


I responded on Help Talk:Date Conventions. --Jrich 14:54, 20 February 2009 (EST)


Person Pages - middle names question [27 February 2009]

Hello,

I need opinions.

When I uploaded my GEDCOM the ancestors names had the middle names in it. So far I do not have middle names in the surname section. Should I wait and rename these pages, or just leave it alone? So far it has not been a problem.

Thanks --DFree 17:32, 26 February 2009 (EST)


Do you mean like your Person:John Robbins (37) page where the title is John Robbins (37), but his name was John Marion Robbins? WeRelate's naming convention is to use only the First name and Last name when titling. All other information (such as middle names, suffixes, etc) can be added when you edit the page. See Portal:Person or the help page for more details. What do you mean when you say "middle names in the surname section"? Only surnames should go in the surname field so searches work properly. When you edit a page, the middle name would go in the Given name field.--Jennifer (JBS66) 18:44, 26 February 2009 (EST)


Hello,

Thanks for responding.

I do try to locate the answer on Werelate before asking. Sometimes that only makes me more confused.

If I understand you the People page title does not have the middle name in it. So I am worrying about nothing?

I guess I asked do I leave it alone, or try to fix these pages? Take out the middle names and use it in a AKA.

--DFree 18:32, 26 February 2009 (EST)


I looked at a sampling of your Person pages, and it looks to me that the vast majority are titled correctly: Firsname Lastname. I came across two (there may be more) that have middle names in the title, Person:Stella Orpha Sumpter (1) and Person:Shirley Benjamin Robbins (1). I certainly don't think it's worth worrying over! As you come across Person pages with middle names, you can rename them at that point. Renaming is really easy to do - on the person page just click Rename and give it a new title. Don't hesitate to ask further questions!--Jennifer (JBS66) 18:44, 26 February 2009 (EST)


Hello Jennifer,

Thanks. I think you are right. Once again I was trying to make it more complicated than I needed to.

--DFree 19:33, 26 February 2009 (EST)



Online Books [8 April 2009]

I'm wondering if there is a better way to emphasize when online fully viewable versions of genealogical texts are available. There are tons of books online! If I look at a current source page Source:Whitmore, William Henry. A brief genealogy of the Usher family of New England, I notice:

  • the Repositories info. is pretty far down on the page
  • Google Books lists as a Free Website
  • Unless you are familiar with Heritage Quest, you might not know you can view these books online.

One of my ideas was using Categories, but I thought there might be other ideas out there....--Jennifer (JBS66) 15:29, 28 January 2009 (EST)


I'm open to suggestions. Would moving the repositories up on the page help?--Dallan 01:38, 1 February 2009 (EST)


I do think it would help to move the repositories section up. Especially as we start adding more surnames to the source pages, the repositories get kind of lost down there. My gut still says that it would be handy to emphasize when a book is available online - like with a banner, or icon. Essentially, we all know that we can get these books, but to know that I can read & search it on the computer - that's even better.
I'm still trying to figure a way to organize things a bit with categories - but that's another story.--Jennifer (JBS66) 14:28, 3 February 2009 (EST)


One other thing that might help is adding a field to the source search. We are adding online books from sources such as Google Books as Type:Books Availability:Free Website. However, I can't then limit my search by source type (book). The other option would be to add another option to the Availability field.--Jennifer (JBS66) 07:41, 9 February 2009 (EST)


You could also enter "google" into the keywords field to search for sources on google books.--Dallan 14:02, 8 April 2009 (EDT)


Type vs Subject [8 April 2009]

I could add Type as a search option. This raises a question about something I've been thinking about lately: Should we get rid of Type and just have Subject (and if so, what additional subjects should we add)? The Type field was added to sources mainly so the system could automatically construct Source page titles (based upon the type), and so the system would know which fields to display on Source pages. Lately I've been thinking that if we were to add "Census" as an additional option to Type when someone is creating a new source, we could ask for the kind of census, etc. and have the system title the Source page according to our new standard for titling census sources. And I wonder if it would make sense to add other options to Type when we come up with other subject-specific standards for titling Source pages. But this would make Type and Subject overlap quite a bit, so I'm wondering if long-term we should drop Type and just use Subject.

So I can put adding Type as a search option onto my ToDo list, but I would like to get people's feedback on the thought about replacing Type with Subject and adding additional Subject options.--Dallan 12:41, 12 February 2009 (EST)


I see Type and Subject as distinct entities. To me, Type might be more properly called Format. Book, Article, Microfiche, Newspaper, Map, etc would fall into this field. (If you go to WorldCat Search, you can see a list of their formats).

Subject provides the detail: what is this source generally about?--Jennifer (JBS66) 13:06, 12 February 2009 (EST)


We could change Type to Format, but there are two problems: Many sources are in both microfilm and book formats, so you couldn't assign a single Format to Source pages, and for the purpose of titling the Source page it doesn't matter whether the book is in paper, microfilm, or electronic format; the title for all three is the same. Maybe it would be better to keep Type and add Subject to the "Add Source" screen so that we could better generate Source page titles, and index Type.--Dallan 14:44, 12 February 2009 (EST)

____

What information are you trying to convey? Are you interested in describing

  1. the physical format of the work (Microfishe, Book, Journal, PDF file, etc), or
  2. the type of content it contains? (e.g., will, marriage records, census record, family history, regional history, etc.), or
  3. something else altogether?
Q 15:50, 12 February 2009 (EST)

I think that as we push to merge duplicate sources, WR's source screen doesn't fully serve that purpose. In regards to the Type field, optimally, we would have multiple types within each source page. What I'm thinking is a structure such that each reprint or version of a source (I'm specifically thinking about books), would have its own fill-in section, with its own publisher, date, repositories... (similar to the Edit Person page screen's Source Citation section). Then, the type field would be ill-suited to creating page titles. I think the idea of the subject field serving that purpose probably works and is more expandable. I like the idea of the system automatically suggesting a title. Would that then enable you to create code that would search for a potential duplicate before adding a new source?--Jennifer (JBS66) 17:25, 12 February 2009 (EST)


I could see eventually having repeating "publication information" field(s).

Thinking about it, I can't see combining "Type" into "Subject" because books about New England marriages need to have a subject of "vital records", not "book". So maybe the best thing to do is add "Online book" as another "Availability" option after all. I'll add this to the todo list if there are no objections.--Dallan 21:36, 14 February 2009 (EST)


I find that source type is mostly an annoyance. Every time I am doing a find/add of a source, there is this extra screen that requires a type in order to know what fields to prompt for. Give me all the fields and I will fill out the ones that apply. Most of the time I am entering only a few prominent words of the title, perhaps an author's last name, seldom more. Could the type even be put on the find/add screen, causing its layout to change dynamically? Then it would remove one screen/delay in the process. If you are simply searching, it doesn't seem to make much difference what type you use, your results will be anything matching the criteria you want. I often select Miscellaneous because it only prompts for a title, even when I know I am looking for a book. Any distinction between book and vital records seems pretty unimportant in practice.

Regarding the auto-completion/popup list of sources, it would be nice if it could be case insensitive. I can never remember which parts of the title are capitalized, since most of the titles have very non-traditional capitalization. I know there was a comment about fixing this, but until that happens auto-completion is of not much use. Let's see, was it Vital Records of Sudbury? No, it is Vital records of Sudbury. If you want to get really fancy you could ignore punctuation and compress spacing where possible, and also ignore any leading 'the' or 'a' or 'an'.

--Jrich 13:27, 6 March 2009 (EST)


I concur with jrich about the annoying extra screen when searching for Sources. It REALLY bugs me. And I like the suggestion of showing all fields, and letting me pick out the ones I want. -- jillaine 13:39, 6 March 2009 (EST)

Regarding capitalization, you shouldn't have to worry about it. When you add a source using the "Add Source" page, it capitalizes the source correctly for you regardless of what you enter. (Correctly meaning that every word is captitalized except for 'the', 'a', etc.)

Asking people to choose a type on the "Add source" page is mainly to help new users know what to enter when adding new sources. The type is on the "Add Source" page; when you fill in the type the other fields become visible, so the layout does change dynamically. Type isn't listed on the search screen. Are we talking about different things?--Dallan 14:02, 8 April 2009 (EDT)


I wasn't asking about the Add Source function, I was referring to creating a source citation pointing to an existing source item.

The complaint about capitalization had to do with the auto-completion of the source field. If I type 'Vital records of Sudbury' and wait a pause, WeRelate will fill in the rest of the source title without me having to remember the rest of the title with its state (Massachusetts or Mass.?), its ending year (to 1849 or 1850?), the exact punctuation (was there a comma after the state?) and the exact capitalization necessary to create a valid link. It is a good way to make sure I am creating a valid link. But if I type 'Vital Records of Sudbury' it will not auto-complete, because capitalizing the R means it does not match the stored Source.

Given that auto-completion must match the beginning of a source is not too onerous but the current capitalization in the WeRelate source records is mostly not standard (closer to Sentence case than Title case) and this is easily fixed by doing the search in a case-insensitive manner.

Going further on auto-completion, sometimes auto-completion gets messed up because the punctuation is '<space><comma><space>' instead of '<comma><space>' but this is a rarity and I can live with it. It would be nice if the search used here was more of a general keyword search, so I could just type 'Savage Dictionary' or 'First Settlers Dictionary' and get a small popup of a fairly focused set of choices from which is it easy to pick 'Savage, James. A Genealogical Dictionary of the First Settlers of New England', but I can live with typing in a prefix of the title. Usually when I work on one family, I cite the same source over and over and quickly learn the shortest string I need enter to type in to get auto-completion to work.

Ok, currently the auto-complete works by reading an alphabetical list of the page titles. This means it's both punctuation and case sensitive. I can address this in one of two ways:
  • First, the system could automatically capitalize your input in the same way that source titles are capitalized. We'd probably have to wait to do this until after the sources were renamed to have the correct capitalization. And this wouldn't address punctuation sensitivity.
  • Alternatively auto-complete for sources could work by doing keyword search on the page titles. This would make it not punctuation or case-sensitive, and you could enter words appearing anywhere in the title, which could be really helpful. But, entering say "United States. 1850 U.S. Census" would return all of the sources containing those words in the title, which would include all of the county sources for the 1850 census. I could sort the results so that shorter titles appeared at the top of the list, but would this be acceptable? Also, sources added within the last hour wouldn't be included in the drop-down list.

Going through the full find/add process (to add a source citation to a fact) also asks for a type. That is the only field on the screen. Then you only get to a screen asking for your search criteria. If you select book, it only controls the fields presented. The results of the search bring back magazines, articles, or any type of source that matches your criteria. (And it is not clear if Vital Records of Sudbury is a book, or Government Records?) When I select find/add I would like to see all the search criteria displayed. If I set the type, dynamically change the screen, but skip the extra screen that asks for nothing but the type. In other words, make this work like the Search->WeRelate function when you search for a Source. I don't even need to specify the type of source there and I get what I want.

I see what you mean now. You'd like to avoid having to select a type and just be able to enter the author, place, title fields on the "Find/Add Source" page, and have that take you directly to the search results page. I think we could avoid having people enter "type" on that page.

While I am on this topic, can a press of <ENTER> while focus is on a source title field NOT trigger the Save function. I would expect ENTER pressed here to either act like tab, or better still, to activate find/add. So if I type 'Savage Dictionary' into the source name field and hit ENTER, and up pops the search criteria screen with 'Savage Dictionary' preloaded into the title field.

Actually this comment on ENTER applies to all the text fields. I accidentally trigger the SAVE function all the time by hitting ENTER when I should hit tab, because many applications treat ENTER and tab the same. My fault, obviously, but I would think it would be safer to require a user to explicitly select Save to trigger that action, since it has so many side-effects.

Let me see what I can do about that. The default behavior of Enter is to submit the form, but there may be a way to disable it.
--Dallan 16:36, 8 April 2009 (EDT)

--Jrich 15:16, 8 April 2009 (EDT)


Displaying summary information better [8 April 2009]

The problem with the left hand side bar is that its designed to hold much more information than can be conveniently displayed. The space is far too cramped to make the display effective---at least for instances where a lot of the text boxes have been completed. As a workaround I place a link in the body of the article itself under the header "electronic sources". I usually place that right after another header I use "Bibliographic Citation". (That latter item is useful because the current set up in the side bar does not give you a useful bibliographic citation. When it comes time to create a list of references, this facilititates the process.) I then add in whatever commentary I think appropriate for the work. In anycase, by having the "Bibliographic Citation" followed by "Electronic Source", the two most important (arguably) bits of information are presented immediately after opening the page. I rarely even look at the left hand side bar. As an example see Source:Addington, R.M. History of Scott County, Virginia Q 10:59, 9 February 2009 (EST)

As an alternative approach, one thing that might be useful would be to combine the data elements in the edit text boxes to form a bibliographic citation. Then display only the bilbiographic citation in the left hand side bar. Links to online versions could then be placed immediately under that. Then supress the display of the information in the side edit text boxes. Even so, the sidebar would be a little cramped for displaying a long bibliographic citation. So maybe kill the sidebar altogether, and place the bibliographic citation in the main article space as I'm doing now. Q 11:18, 9 February 2009 (EST)


When would a book whose availability said "Free website" not be available for reading online? "Free website" for other types of sources (e.g., cemetery records) generally means that you can read the records online. Maybe we need to create another availability for books that are not available online (e.g., in Google books), and reserve "Free website" for those books that are?

Yes, Google Books (and other similar repositories) are a "Free Website". My difficulty is that they're not distinguished from other Free Websites. So, say I want to find all books about the Mayflower that are viewable online. As the search is currently, I cannot filter to display only books let alone those viewable online. I think Free Websites works, as long as you can also filter by type (book).--Jennifer (JBS66) 15:56, 9 February 2009 (EST)
Something that might be helpful and fill a real need for many folks, would be a search engine that was specific to the major electronic book sources---e.g., Google, Ancestry, Project Gutenberg, etc. I usually pick those up hit and miss with a Google Search, but having an onsite search engine specific to that need would be very helpful. (Not that I think this the most pressing problem on Dallan's "to Do: list. Just something that would be helpful. Might even be sufficiently helpful as to attract additional users. Q 16:19, 9 February 2009 (EST)
Presumably if its a substantive website the material would always be available (ignoring minor management downtime.) If its not normally available long-term, free or otherwise, then its probably best not to link to it if it can be avoided. An example might be a personal website where someone was so enthused with a particular work that they scanned it in themselves and made it available for free---good, but the problem is, it will be available only as long as they choose to pay to have the site maintained. So, in a few years, when they loose interest, or otherwise pass from the scene, the very valuable contribution they made will be lost. It might still be free, just not available. --Q

I think the issue of the sidebar containing too much information applies to Person and Family pages as well. It does seem like a lot of this information should be moved into a wider section just under the page title. I'd probably keep the coverage information (places, surnames, date range?) in the sidebar. But I agree - the information in the side-bar needs to be divided into a box that goes across the top of the page with the more-important information, and the sidebar with the less-important information.--Dallan 14:20, 9 February 2009 (EST)

A reasonable approach, though that might create some formating problems for people trying to do substantive articles. As a cautionary note, restructuring that's gone on in the Genealogy Wiki, has made some articles virtually unreadable. (They've gone to these very wide advertsiement boxes in the right hand sidebar, so that the space available for the article itself is sometimes less than a third of the page. Great idea from an advertising point of view, but not very good idea from an end-user point of view. Very short sighted, I think.)
One Genealogy Wiki idea that's useful is the "Vita Box" (kind of awkward name, but it has the advantage of being pretty self explanatory). This gives a concise statement of basic vita data. I use something akin to it, though in my case I've added fields for identifying the source of information/commentary on how something was figured out. (Its actually pretty rare to have a specific source that you can point to to prove something is true). Adding a Vita Box (please come up with a better name!), would be a good idea. But its implementation would have its problems.
Something that might be helpful here would be to allow the end users to choose the placement of the "vita Box". Perhaps a template that would dictate the content of the box, and what went where within the box, but allow the user to choose where it appeared on the page. Q 15:44, 9 February 2009 (EST)
A compact way to display key data for a family article:

Personal Data
Vita Husband Spouse
Name John Paul Margaret Smith
DOB 1942 1954
POB Morgntown, WV Islip, NY
DOD 1990 5 Aug 2007
POD Morgantown, WV Morgantown, WV
Marriage
DOM 5 Aug 2007
POM 1990

















Gee! You mean like a traditional family registry page? What a concept. I think I proposed this during my first foray at WeRelate (or it may have been over at the Genealogy Wiki) what? two years ago. I like this idea because it's something that people doing genealogy are familiar seeing. I'd love to see something like this here. -- jillaine 21:34, 27 February 2009 (EST)
The point was this was a way to condense information now located in the sidebar, where it basically gets lost if there's lots of information. Dallan was speaking of a banner across the top of the page as a way around that. This is another approach, and could be inserted automatically near the top of the narrative space. This approach was adopted by Genealogy wiki (several years ago)---Everything there is done manually, so this appears only if someone wants to insert it. It is comparable in style to the info boxes used on Wikipedia. This particular version would work as is for a family page. Something else would be needed for a husband or wife page.
The above is a "wikiTable" layout, which is less familiar than the more common standard HTML layout. I believe the Wikitable gives a better appearance, though my experience with the HTML format may simply reflect my personal limitations. In anycase, the WikiTable format above is fairly inadequate for my own purposes, but might work well for others. Q 08:23, 28 February 2009 (EST)

The plan is to change the format for Person and Family pages later this year, with a table across the top containing the basic information. When I say table across the top, I mean a table under the title, to the right of the sidebar, and above the narrative. I think we're talking about the same thing.--Dallan 14:02, 8 April 2009 (EDT)


What do we do with Adam and Eve? [8 April 2009]

In contributing time for merging, I have stumbled across Adam and Eve. Um. What do I do with them? Has this been discussed elsewhere? Please advise.

jillaine 17:03, 31 January 2009 (EST)


It is a documented genealogy. Have you uncovered who Enoch's mother is yet? --Jrich 17:18, 31 January 2009 (EST)


Is the material being maintained by an active user? If not, we can remove it on that basis.
Beyond that, I generally think that faith is wonderful, worthy, and honorable. It isn't genealogical evidence though.--Jrm03063 17:32, 31 January 2009 (EST)

I think a good argument could be made that the family tree of Adam and Eve is documented, historical and valid. I believe the debate should center on the source's validity and reliability; whether the Bible, the Torah, the Qur'an, and the Tawrat should be considered as primary, secondary, questionable, or unreliable sources. Wikipedia's Genealogies of Genesis and Genealogy of Jesus both show well-documented, well-discussed, and well-presented reasons for considering the presentation and inclusion of the genealogy of Adam and Eve as a valid entry for WeRelate. I wish my own family tree was half as well documented and preserved.
--BobC 22:12, 31 January 2009 (EST)


If Wikipedia has captured the descendancy of Adam & Eve, then shouldn't we just use or reference Wikipedia?
What I'm more concerned about is the "genealogies" that claim to link current lines back to these biblical references.
jillaine 00:57, 1 February 2009 (EST)

I was preparing my response at the same time that User:Jillaine wrote hers, and it's along the same lines: If we delete them we would have to give a reason, and I'm not sure what that reason would be. The people and their relationships are documented well enough to have wikipedia pages (see Wikipedia:Category:Bible genealogy). I imagine we're talking about only a few dozen to a hundred people. I'd be ok with keeping them, and referencing the wikipedia pages. By the way, thinking about my response got me to read an interesting article with an overview of attempts to trace modern lineages back to Roman times and earlier. If someone tries to tie into a biblical genealogy, I hope we can do them a service and set them straight.--Dallan 01:38, 1 February 2009 (EST)


I agree with Dallan.--Beth 09:32, 1 February 2009 (EST)


In my previous response I was trying to address the "faith" versus "evidence" issue (or as I read it, the validity of source) in Jrm03063's comment.
Although I cannot completely disregard these links to biblical genealogies, I am pretty skeptical of these lists of names without sources noted (or only the sources of other family histories identified). You guys have to determine if pages such as these are "value added" to this WeRelate audience. Seeing a page with "Person:Adam" or "Family:Adam Unknown and Eve Unknown" with no other reference, no citations, no narrative, does nothing for me. As Jullaine stated, links to these biblical genealogies should be referred back to Wikipedia or private webpages; or use of the wiki disambiguation and redirect functions.
Doing a WeRelate search on "Adam and Eve" produced three pages, each of which references their own websites on Rootsweb and Geocities, which I think is appropriate. Checking into these showed that they were basically long lists of names, citing none of their sources (which they may or may not have in their private records). The concern I have is that someone who may link into their family line will use that genealogy page as a source for their own link back to Adam and Eve. Whether valid or not, to me that is "junk genealogy."
--BobC

While mythical and faith-oriented genealogies may be present and documented on wikipedia, I doubt that you will find an unchallenged representation that they link to a modern or traceable genealogy. As werelate has developed, I think we're trying to create a maximally unique, documented, and connected genealogy. Pretty much by definition, faith-oriented genealogies can never connect with all that.

The genealogies of faith and myth are important, meaningful, and perfectly valid in their own context. But I think that context is quite different than werelate. I would encourage people working on that stuff to work on either the appropriate wikipedia pages or to launch a custom wiki for the purpose.--Jrm03063 09:22, 1 February 2009 (EST)


I'm reminded of a lesson my dear mother taught me as a child, "It's not polite to discuss politics or religion upon meeting someone." So without getting too much deeper into an impolite on-line thread, discounting biblical genealogies as solely mythical disregards the historical record as provided in non-spiritually-based texts, such as the works of Josephus, a jewish Roman citizen and respected historian of the first century AD. As Dallan pointed out above, a new research method called prosopography is attempting to balance, analyze and validate those DFA (descent from antiquity) claims in an historical, biographical and genealogical context.
While it's true any genealogy should be open to challenge, my argument is that the challenge should be based on evidence and the quality (or reliability) of the source. You don't need to be a Christian to accept the history contained in the Bible as generally credible. The decision of whether that related genealogical record should be placed here on WeRelate should be based on its relevance, reliability and usefulness.
Final thought: Don't let your own bias cloud the historical (or genealogical) relevance of any particular document.
--BobC

I think the pages themselves are harmless. If someone connects to them with poor sources, then it is like any other genealogy page: prove them wrong with better sources. If some of the previous references are right, a person so inspired could make it a crusade to detach all such trees, using good sources, and ironically show that, instead of everybody being related to Adam and Eve, nobody is. If you haven't got a better answer, I think the various sources mentioned in this discussion means you should leave it. There are plenty of other, more recent pages here with little or poor justification and we don't complain about them (at least not specifically). If you delete them, you know somebody will recreate them at some point. How is it different than somebody showing they are related to this famous person or that? --Jrich 10:48, 1 February 2009 (EST)

Are any of the users associated with such pages active and working on them? Or is this just more abandoned upload?--Jrm03063 10:52, 2 February 2009 (EST)


Here's the Adam and Eve page (thanks BobC for merging them all together!) You might want to check out User:Socrtwo, whose user page states "Hi. I'm trying to make family trees of all the Myth Systems of the World as listed in Wikipedia on this page: [3]."--Jennifer (JBS66) 10:59, 2 February 2009 (EST)


I just checked the last contribution from User:Socrtwo, it was 22 November 2007, a day after his last GEDCOM upload. Swell...--Jrm03063 11:31, 2 February 2009 (EST)


I don't feel that strongly about it. Whether the Biblical genealogies are valid or not is a matter of faith, but I think everyone is in agreement that links from modern genealogies to Biblical genealogies are invalid. I just don't want to spend a lot of time on it, and I worry that enforcing a policy of removing these pages (and justifying it, especially when we don't remove unsourced modern material) will be more trouble than it's worth.

Having said this, I just looked at User:Socrtwo. I don't think we need trees from someone who's primary objective is to upload trees of Biblical and mythical genealogies. We'll email this user about deleting their trees.--Dallan 14:20, 9 February 2009 (EST)


I just came across some more of this sort of stuff. A shaky scandinavian line turned into Odin, which then went through a long list of names though Troy and thence to the biblical space. While I generally believe that it's best to come to a debate with source material that refutes an existing claim, sometimes claims are so weak, it seems an unreasonable burden to expect them to be able to be explciitly disproved.

For example, would it be reasonable to say that representations about people born more than 500 years ago, without supporting sources, are liable for delete without further justification? I would offer the generic short-hand phrase, "ancient and unsubstantiated" as a generic rationale in such cases.

I guess I would further add, that even if an ancient person page turns out to be true/real/etc., re-creating an empty page isn't much of a burden when someone is coming back through with source content.--Jrm03063 12:48, 10 February 2009 (EST)


Why 500 years? Can't we agree that pretty much anything beyond 100 years is hearsay, passed down by word of mouth without personal knowledge of the facts? Then you still have the question of what constitutes a valid source. So I think your criteria is unworkable. Instead I would argue if you don't care enough to explicitly refute it, leave it. If there aren't enough serious genealogists such that sooner or later one will refute these with arguments, then my estimates of the value of WeRelate, and the intelligence of people in general, are too optimistic... It doesn't have to be you: my advice is to be patient and tolerant and focus on the parts you know.--Jrich 13:31, 10 February 2009 (EST)


I'm looking for something that will help those of us working in the ancient spaces right now. We're trying to clean away stuff that is often abandoned junk, but not always, so wholesale delete of entire trees isn't really what we want to do. I also think there's a problem with letting someone start with a claim based on zero evidence, and then requiring those of us doing the cleaning to try to perform detailed analysis that explicitly disproves the assertion.

What if I'm looking at a person, for whom the wikipedia page says nothing is known with certainty about their ancestry. If I then find a lineage in werelate (devoid of sources), is that sufficient justification to delete the lineage leading past the wikipedia-backed page?

My thinking is that 500 years is pretty much beyond the extent of any accuracy in an oral tradition, and the space that I'm looking at is generally older than 1500. I would think we would want a shorter window eventually.--Jrm03063 13:54, 10 February 2009 (EST)


What if we had a policy that for people with pages in Wikipedia, we take what Wikipedia says as the best source of information that we have available, and if pages are created for them with information that is contrary to what's on Wikipedia, then those pages are subject to being edited to bring them in line with the Wikipedia page. The reason for editing would be "contradicts Wikipedia" and the contributor would be invited to edit the Wikipedia page if they felt they were correct. By doing this we place the burden of determining whether the information is properly substantiated on Wikipedia, which has a much broader community of people interested in "famous" people.

Has anyone come across pages for people born more than 500 years ago that do not have a page on Wikipedia? I don't mind setting 1500 as a cut-off date for unsubstantiated information -- the LDS Church used 1500-1550 as their cut-off for submissions because they believed that the only surviving genealogical records for Europe before 1500 were already well known and that individual contributors weren't likely to come up with anything new -- but I think I'd rather have a policy of going with Wikipedia information for people on Wikipedia, including for more recent people like presidents.--Dallan 13:15, 12 February 2009 (EST)


I just noticed that one of my new lines from an attached tree puts me as an ancestor of a Norse god... or at least a mythological hero figure of some sort... (I haven:t had time to read all of it, yet)

I guess I'm not trying to make light of this, the point I:m making is that a lot of cultures put king lines as "direct descendents of the Gods" and they sort of wipe out the real history and connect King so-and-so as the son of the God of Something (A great example of this is the Japanese royal throne, which has an unbroken lineage all the way back to the Goddess of the Sun... and it:s fact... to the Japanese). I went on ahead and added that lineage to my tree because we would have to go against 1500 years of culture to find who was the REAL ancestor out there in that great white wasteland... so this is all we have... As I go along, I'll probably find that I:m related to Adam, Eve, Norse Gods, King Arthur, Celtic what-nots and maybe even a few banshees... There is a fuzzy line where fact becomes fiction and it:s going to be there no matter what we do (For now). If Adam and Eve are the best we:ve got from that era, I say let:s use them... Someone will have to clean up our trees later... but I don:t think they are going to be too keen on having to repair the guy who was 500 feet tall and made it snow, either... Aabh 01:38, 13 February 2009 (EST)


I just deleted a number of trees that contained nothing but norse gods, etc. What do people think about the idea I mentioned above of deferring to Wikipedia for people with pages on Wikipedia? If nobody objects or has another idea, I'd like to make that a standard policy.--Dallan 21:40, 14 February 2009 (EST)

Dallan, although I'm opposed, if you've set your mind on doing it, I'll put in my recommendation that you accomplish it in two phases:
(1) notify owners of pre-1500 genealogies, people or families whose genealogy has no recorded connection to themselves or current-day folks (i.e post-1950 people) that their genealogies will be deferred to Wikipedia; and then
(2) after this is absorbed, about 90 days later notify authors of pre-1500 genealogies who have not added to or maintained them during the past year that their genealogies will be deleted and references deferred to Wikipedia.
I really think if a genealogy GEDCOM file, family or person is being maintained on WR, then it should be allowed to remain as an active site and not referred elsewhere. I just happen to be on a trip to Ft Lauderdale, Florida and I visited the main city library there and perused a number of genealogy-related books (such as Old World Heraldry, English sub-royalty, Welsh surname history, etc.) that show a trememdous amount of very valid and legitimately referenced genealogies that record pre-1500 names that may (or more likely may not) be included in Wikipedia.
--BobC 00:42, 15 February 2009 (EST)
Dallan, I too am opposed. Mostly because someday I'm hoping we'll have a Gedcom download from here... if that ever occurs, the link to Wikipedia will drop off... thus our Gedcoms will be truncated... in combination with the "Living" issues that I'm still struggling with, it would pretty much reduce my Gedcom to just the middle part... I'm not sure the Norse Gods should be removed, either... We don't know who preceeded Emperor Jimmu on the Chrysanthemum Throne (Japan) He is said to have been the son of the Goddess Amaterasu... but if you have Jimmu in your list... he MIGHT be legandary... or might not... where do you draw the line? Emperor Jingu (The last one that is questionable)? Trimming to 1500 would bring your lineage all the way up to Emperor Go-Kashiwabara and when you downloaded your Gedcom you'd lose 2000 years of linage, about 80% of the line. Aabh 10:19, 16 February 2009 (EST)

Well, I've previously suggested a way that all this could be done, but I'll also point out again: it flies in the face - literally - of our name: "werelate". I intend no disrespect to anything from the worlds of faith, myth - even fiction. The problem is that when you're looking at a different context, then by definition, folks don't relate (at least, not by standards that will be uniformly accepted). We already have an ocean of material that we're trying to manage and improve. Deciding on what the rules are based on what sort of page you're looking at seems like a burden we shouldn't take on - the scope is already large enough.

With respect to wikipedia - nothing is "lost" when it becomes a GEDCOM. The convention is that the body is usally taken from the article preamble and a source citing the article appears on the source list. I think Dallan's proposal is that such body content would, initially, be replaced with a specification of where in wikipedia it came from. So a person would typically have two references to the wikipedia page. How is that losing anything? Keeping the link lets you get whatever the up-to-date content is. I do think that an ability to download a GEDCOM containing wikipedia data in snap-shot form would be helpful too though, so reports and such could be created. Generally though, I wouldn't think you would want to make a copy of material which will become dated, when you can just point at the place where it should be able to be found in its most up-to-date form.

With respect to "hosting your gedcom", that's not quite true. Your GEDCOM is read to produce the pages, and those pages are added to your default "tree", but your GEDCOM doesn't continue to exist in any particular form. As your pages are merged with duplicates for those people and families, your "tree" points at the new page material. We're also talking about adopting rules that may require certain levels of evidence for pages associated with people born before a threshold date. If "your tree" contains stuff that doesn't pass that filter, then sections of it are likly to be edited off the site anyway.--Jrm03063 10:51, 16 February 2009 (EST)


Just to be clear, when I say that we defer to wikipedia for medieval people, I don't mean that we remove pages for those people from WeRelate, but that the pages for them on WeRelate agree with the data at Wikipedia. So the GEDCOM export would still include them.

What I'm suggesting is that if a GEDCOM is uploaded containing parents for a medieval person named X, and wikipedia says that X's parents are unknown, that when this discrepancy is discovered the page will be edited and the parents removed.

As an alternative, what JRM has suggested is that the parents remain, but that they be categorized as such-and-such legend or misconception or whatever.

I believe that we should use JRM's suggestion as an exception, rather than the rule. The rule should be that pages for people at WeRelate who have pages at Wikipedia agree with the information at Wikipedia. For example, Wikipedia includes all of the emperors of Japan but lists the first 14 as legendary, so we could include pages for them as well with links to the Wikipedia pages which note that the first 14 are legendary.

If someone uploads a page for a person who has a wikipedia page, containing parentage information that is not listed on wikipedia, then if the parentage appears to be a widely-held belief we can invoke JRM's exception and include those parents but categorize them as a legend or misconception. However, I hope that we would apply this exception very sparingly because these parentages will appear just like normal parentages on pedigree charts, and this will likely cause frustration for people who don't want them to appear on pedigree charts.

With this clarification, are people still opposed to the idea?--Dallan 13:02, 16 February 2009 (EST)

Whops! Yep, I totally misunderstood somehow. I thought we were proposing to 'cut' the trees at 1500AD... Thanks for the clerification! Okay, now that said (And now I will comment in a less I:m-losing-my-GedCom-panicked-way and instead be in a much more academic, happy-discussion way :D) Who is to say that the researchers here aren't further along than the researchers on Wikipedia? I've noticed some confusion in the later Stewarts (Kings of Scotland) area where Wikipedia isn:t quite in line with my Gedcom or sometimes even the Scottish Peerage sites (I:m willing to accept that I might be wrong, but I start to worry when the Peerage is involved)... which means that if we use Wikipedia as the definitive source, we might be changing or altering family trees simply so we have to change them back when a newer researcher updates Wikipedia... It:s okay to have Wikipedia be referred to... but to just trim because it doesn:t match Wikipedia only concerns me a bit. Let:s go in the reverse; I discover that King So-and-so:s mother is Queen so-and-so. I have a verified, clean source for this information (English Peerage, for example), but, of course, Wikipedia says the parents are unknown. The Peerage goes back 20 generations or something awful (So as to make this example complicated because updating Wikipedia AND Werelate would suddenly be a massive project). Er...all of this rambling by me and I haven:t really gotten to my concerns (Sorry about that... I:m a rambler) Um, so; 1) What exactly will happen to people and families that go beyond Wikipedia? 2) What will happen when those families differ from Wikipedia (I have found that the Parents of King George were Bob and Nancy Smith, Wiki says it was Tim and Sarah Smith)? 3) What happens to extra information: (Family Researcher Tim Smith found in a 1722 Family Bible that King Tim of Florin had a Cocker Spaniel named "Spot") or more importantly (Family Researcher Tim Smith found in a 1722 Family Bible that King Tim of Florin had an affair with Princess Annabelle of Gilder which produced one illigitamate child; "Spot Smith").
Typical of me, I:m only really concerned with capturing as much data as possible, as accurately as possible on each of my ancestors. Little things make them real (the dog Spot) and I think differing them to Wikipedia is just fine (I have no objection) as long as we don:t lose any extra information (Or worse, lose complete records or tree branches). Aabh 19:44, 16 February 2009 (EST)

In answer the the observation, "what if werelate researchers are further along", I would reply that the appropriate thing to do is to host the research on wikipedia FIRST. There are not enough researchers on werelate to competently referee material of extreme antiquity. If someone legitimately has information that is both ancient (pre-1500, or whatever) and reasonably sourced, then it should pass muster on wikipedia. If the stuff survives on wikipedia, then it can be referenced here at WR.

Also, while I do a lot of work here at WR, I wouldn't limit myself by saying I'm a WR-only person. Indeed, I think wikipedia should be viewed as a more general-purpose name space than PERSON, FAMILY, ARTICLE, etc. Unless documented ancestry before 1500 is being kicked off wikipedia on relevance/notoriety grounds, I don't see the problem with requiring things to clear that hurdle.

If "1500" seems too recent, it could be an earlier cut-off and the procedure above would still apply.

To my mind, the point of ancient lineages on werelate, is to allow people who have valid connections in modern genealogy to reference the ancient stuff without attempting to reproduce it themselves. I don't think, presently anyway, you could claim that werelate is a great place to originate/publish ancient material.--Jrm03063 16:45, 19 February 2009 (EST)


I (personally) would not normally be concerned about pre-1500 lineages, so this discussion is not likely to affect me directly. Nonetheless, I can see some very specific reasons for NOT deferring to Wikipedia. Wikipedia relies on (requires use of) published authoritative sources. Information gleaned from original research is explicitly excluded. And there are good and sufficient reasons for making that one of their rules---if the case was otherwise, every cracked-pot with a novel idea about whatever hobby horse they liked to ride, could write up their "original research", and "publish" it on Wikipedia. And that's why genealogies are not allowed on Wikipedia---because almost all genealogies are based on, unpublished "original research". (And a "published" family history is not going to fair much better.) It doesn't matter whether the facts they present are right or wrong---unless those "facts" are documented in an authoritative source, they will be excluded (at least in theory). While the truth is that most genealogies are not well done, some are very well done indeed, and probably contain information not available in a Wikipedia article. Adopting a rule of deferring to Wikipedia on an article (even if the field of view is pre 1500), would automatically exclude those data. Q 18:50, 19 February 2009 (EST)


I've seen plenty of genealogy on wikipedia. Perhaps not pages that represent a genealogy unto themselves, but thousands of pages that give family ancestry and descendancy information. How about Alfred the Great? Baldwin II, Count of Flanders? Bernard I, Duke of Saxony? So the 99% case - people rifliing through archane texts in various libraries - is resolved by requesting that they start on wikipedia, then bring it to werelate by reference.

What about the 1% case - a true primary researcher in the pre-1500s space? I havn't met one yet, but I think they need to go through the steps of getting published in a peer-reviewed forum. NEHGR or similar. From there they can write a nice wikipedia summary and we'll be thrilled to reference the content.

We have to have some basic rules that let a small number of amateurs can sift through the vast and abandoned ancient space content without being experts on just everything, ever.--Jrm03063 19:44, 19 February 2009 (EST)


I hesitate to enter this subject again, but I don't think we finished it. And now that the new GEDCOM upload is being tested at the sandbox site I'm trying to tie up loose ends.

Regarding pre-1500 research, I'm ok with allowing WeRelate to differ from Wikipedia, but I think it should be the exception rather than the rule. In general, the articles at Wikipedia are much better sourced than those at WeRelate. But if someone comes up with a really good source that isn't acceptable to Wikipedia (I think this would be rare), I'm ok with making an exception. And we can certainly have additional information about people here if additional information can be found about them that wouldn't make sense to post on Wikipedia.

Regarding people in religious or mythological or legendary lineages, this is a difficult question. It has caused a few problems already and I can believe it will continue to be an issue no matter what we decide.

After reading the above discussion, I think we should discourage people from posting these lineages because tracking ancient lineages is outside the scope of WeRelate. But I don't want to spend time searching them out and deleting them. I think the time is better spent on other things. I just tried to create a new Family page for Adam Unknown and Eve Unknown and got an index number of 4, so we haven't had that many instances of this. There are a lot more instances of medieval people who need to be cleaned up and merged. I'm ok with marking the pages for people in these lineages as "religious, mythological, or legendary" if someone wants to take the time, but I think most people are aware of that already. I'm more concerned with disabusing people of the notion that they can actually link to these people. I hope that if we find people born prior to 1500 with lineages that disagree with Wikipedia, that we "fix" those pages to conform to Wikipedia and add a wikipedia link. If the contributor has a source that disagrees with Wikipedia, we can consider that on a case by case basis.

And further thoughts on this?--Dallan 14:02, 8 April 2009 (EDT)


Can we at least preclude GEDCOM upload of material older than, say, 1000 C.E.? I don't know whether we could just curtail the upload and do it partially, or whether it would make more sense to decline the GEDCOM if it contains dates before some point. I think that such a limitation, if it could be imposed, would filter a lot of highly questionable stuff that seems to continue to be around.--Jrm03063 14:28, 8 April 2009 (EDT)


Dallan, I liked JRM's suggestion WeRelate_talk:Watercooler#Non-traditional_Genealogy_-_Adam_.26_Eve_Part_II_.5B15_February_2009.5D here

-- jillaine 14:34, 8 April 2009 (EDT)


If we were to have a protection system in place for pages that either have more than 5 active watchers and/or have a backing Wikipedia template, could the system just not add that GEDCOM data to the page? I have to say, on another note, that saying Wikipedia is "much better" than us in any way worries me. We're only in the Beta stage, isn't this setting ourselves short? One could also say that Wikipedia has much better place pages. I would hope that because we are a genealogical Wiki, that we would strive to become the go-to resource, rather than deferring that to Wikipedia. --Jennifer (JBS66) 15:00, 8 April 2009 (EDT)


Precluding old material from GEDCOM upload seems like a good idea. I think I'd make the year 700 so people can link to Charlemagne though. I'm under the impression that most of the people born before 1500 either currently have or soon will have wikipedia stubs, so people won't be able to edit those pages, but if we allow them to match the people in their GEDCOM to the wikipedia people, then the Wikipedia people will be added to their tree, which ought to satisfy them.

We're already planning on a policy that GEDCOM's containing pre-1500 data will be flagged for admin review to make sure they were matched appropriately, so I think having another policy that you can't upload anyone born before 700, regardless of whether or not they were matched, seems reasonable. For ease of programming, let's start by asking admins to make sure people born before 700 are excluded when they review the warnings in the GEDCOM. I'll have the system flag each of them with a warning, so they should be easy for an admin to exclude. If it turns out that we get a lot of GEDCOM's like this, then I'll make the exclusion automatic.

Regarding Wikipedia, the reason I would like to defer to wikipedia for pre-1500 people is I believe medieval research requires a different set of skills and interests than modern research. And I think that more people with those skills and interests frequent wikipedia than WR. Maybe someday the tables will be turned (that would sure be interesting!) but until then I think basing our pre-1500 pages on Wikipedia makes sense. Post 1500, I do expect that we'll become the "go to" site soon!

And yes, I like Jrm's suggestion below as well.--Dallan 17:19, 8 April 2009 (EDT)


Recycling a redirected name [8 April 2009]

During the merge process, it often and unfortunately occurs, that the preferred form of a page name becomes redirected to some less than desireable form. Say, "Fred Flintstone and Wilma (1)" gets redirected to "Unknown Fred and Wilma Flintstone (48)". Of course, you can rename "Unknown Fred and Wilma Flintstone (48)", but you'll get "Fred Flintstone and Wilma (2)", which is a lot less satisfying.

One way to get back to the original name is to look at the "what links here" list for the page, and find the preferred name as a redirection. Open a window to edit that page, removing the redirect line and saving back the page as empty. Then, go to the "Admin" pull down and select, compare pages. Put the old icky name and the preferred name into the appropriate list for comparison. Trigger the comparison, and then follow it through with a merge from the icky name to the newly recovered name.

If you're like me, and have the retention span of a goldfish, this is the only way to go.--Jrm03063 17:37, 2 February 2009 (EST)


Another thing you can do, if you happen to notice it during the merge, is to change the "merge target" (the little circle just underneath the page title) to the page that has the title you want.--Dallan 14:20, 9 February 2009 (EST)


I think this is an interesting strategy, and have begun using it when the desired page is deleted instead of redirected. I am confused about one thing. Say the (1) page is redirected to another page, can you really just delete the redirect link? What happens to the User that was watching the original (1) page, and, by virtue of a redirect, is now watching the redirected-to page? Wouldn't that User then be watching your new (1) page?--Jennifer (JBS66) 17:51, 16 February 2009 (EST)


I'm a little confused by the question; if a user was watching the original page, after the redirect they'll be watching both pages. So if you delete the original page they'll still be watching the redirected-to page. Ah, I think I see the problem: you can't delete the original page (which is now a redirect) if someone else is watching it. That's true unfortunately. I suppose you could mark it for speedy delete.--Dallan 16:03, 8 April 2009 (EDT)


Non-traditional Genealogy - Adam & Eve Part II [8 April 2009]

I was originally against accepting on werelate, any genealogy that either wasn't, or had no immediate hope, of being documentable in the strict sense. The consensus that biblical and other genealogies are, never the less appropriate, gave me pause. Like it or don't, there are a lot of GEDCOMs out there that contain such stuff, either improperly linked to modern genealogies or not. There are also plenty of GEDCOMs circulating out there with data from 19th century hoaxes and other sources. More insidiously, there are "hypothetical" people, that were added to justify and create links to Mayflower and other ancestry of interest. If we delete this stuff whenever it comes in, we'll be forever on a treadmill of removing stuff, without any explicit documentation of these issues.

What if, instead of deleting such non-traditional genealoty, we embrace them. This way, the merge-on-upload feature has some hope of matching such stuff and not re-recreating it yet again.

I'm not suggesting that we represent this stuff as classically "accurate" genealogy, but rather, as accurate within it's context. A person that is accurate as a representation of some aspect of a Norse myth, for example. Likewise, a person that is part of a known hoax lineage or known hoax link. Such a person can be "accurate" and documented in that sense.

What if we do this, by establishing a guideline that non-traditional genealogies:

  • Are uniformly marked with some standard template banner as "non traditional", and are labelled with a context/tradition.
  • Person/Family pages of one context, should not link (via spouse/child references) to pages of another context. They may refer to such pages in their body, but not as probable or documented ancestry.
  • The tradition/context would have some supporting descriptive page, indicating what this is all about.
  • Contexts/traditions can be rolled up by users, examples might be "Norse Myth", "Hellenistic Myth", "Native American Myth", "Descent from Adam Fabrication", "Christian Old Testament", "such and such a hoax", "fabricated link to mayflower ancestry", etc.

Thoughts?--Jrm03063 12:06, 13 February 2009 (EST)


I like it. -- jillaine 14:58, 13 February 2009 (EST)

Funny you should bring this up. I've been thinking the past couple of days (after I deleted the trees with mythological beings) that maybe we ought to have a policy that people who cannot be connected to modern people (which would include mythological beings and biblical people) shouldn't have pages on WeRelate. This policy would allow us to focus on helping people connect with their own genealogy, which is the main purpose of this site, and side-steps the impossible argument of whether or not biblical people are well-documented. What do you think about this?--Dallan 22:51, 14 February 2009 (EST)


While I am behind the spirit of your suggestion, Dallan, it seems like this might exclude the perfectly good work of historians who have documented the heck out of, say, the lines of Welsh nobility from 300 AD to 1500, and have put it online. Are you saying we exclude such work because it may not be linked to a current line?-- jillaine 23:27, 14 February 2009 (EST)

No, just people that cannot be linked to modern lines. This includes biblical people (according to Wikipedia:Descent from antiquity there are no known lines right now that extend back to the bible), mythological people, fictional characters, etc. So Welsh nobility would be ok, but Abraham's genealogy would be excluded until someone showed how to link from Abraham to someone born in medieval times.

I'm not against Jrm's suggestion either.--Dallan 21:27, 15 February 2009 (EST)


I've been on both sides of this thing. Since there seemed to be a developing consensus that we needed to allow all sorts of things, I was trying to find a way that they could all coexist in the same space. So I proposed the multiple-context idea, where folks would define their context and then be required to indicate that something was non-traditional and it's context, in order for it to be allowed to persist. Still, that is literally against the notion of "werelate", since, well, other contexts can't relate! It also wasn't, and really isn't my preference. We don't have solid documentation and practices in ordinary spaces as yet - we shouldn't start going afield.

It would probably be a better thing, if someone were devoted to biblical genealogy (for example) to start a clone of werelate with it's own standards. Likewise other cultural or faith-oriented contexts.

I think one aspect of my proposal above should survive though - the idea about explicit representation of hoax people and fabricated link people. I would think that having such people in the werelate database will make it more likely that uploaded GEDCOMs, containing such defects, will be discovered as such early - and not wind up recreating problems sorted out and documented by other folks. Of course, such "people" would need a very visible up-front template, indicating that this comes from a persistent defect/fraud/hoax that needs to be explicitly known.--Jrm03063 21:50, 15 February 2009 (EST)


I just commented on the earlier Adam and Eve topic (I forgot about this one). I'm fine with someone identifying pages of this sort with a "Norse myth" etc. template if anyone wants to take the time to do this. I don't know how important it is, because these Old Testament / Norse myth pages are generally fairly obvious. But I really like your other idea: explicitly identifying hoax and fabricated link people, because those people aren't often very obvious. If someone's interested, please be bold and create these templates and leave a message here and in a help page on how to use them. Thanks!--Dallan 16:03, 8 April 2009 (EDT)


Someday: Show how we relate [8 April 2009]

In the course of some of the category work I've been doing, I've been thinking it would be nice to have a feature that could show how two people were related. For example, this couple are the ancestors of both Gerald Ford and Barack Obama. But I don't know of any way on here to pull that specific 8-10 generation descent out to figure out how the line goes or how the two are related to each other. Also, people love descendant societies... it would be really interesting to be able to tag a person "Mayflower descendant" and have the ability to pop up their line back to the appropriate passenger(s). And then you have a new user find Great-Grandpa, and find out he's descended from some Mayflower folks, a president or two, and Charlemagne, which I've got to think would be great fun. I have no idea whether the wiki or other software could be harnessed to do this, and I'm sure there are all sorts of complications I haven't thought of, but given the name of the site, after all, I thought I'd throw it out there. --Amelia 16:28, 16 February 2009 (EST)


That would definitely be a nice feature. If I recall, the PAF application has something like that, where you can pick two persons out of a file and ask how they're related, and it comes back and says "X and Y are 4th cousins, twice removed", and shows you the connection. The data's definitely there to be able to do it. From a software algorithm point of view, the problem is to determine whether X and Y have any common ancestor.

The latter part of your comment is a slightly different problem. That is, does person X have any ancestors with category tag C? That would be even easier, software algorithm-wise. Though I'm not sure whether WeRelate currently has all of the categories set up that would be interesting for that purpose. Do we have categories for "Revolutionary War vet", "Mayflower passenger", "European royalty", and such? --TomChatt 04:16, 22 February 2009 (EST)

Some of those categories exist (Category:Mayflower Passengers, Category:U.K._Monarchs, Category:U.S. Presidents), but some categories would be useful mainly for this feature, because they otherwise would be overwhelmingly large (like Revolutionary War vet).--Amelia 11:44, 22 February 2009 (EST)

Funny, I've been thinking about this as well. I hadn't thought about using categories; I'd thought about using wikipedia-linked pages to tell you who the "famous" people a person was linked to were. But I like the idea of using category tags also. It's definitely do-able, and I think it's a cool idea. Realistically it's a feature for next year though.--Dallan 16:03, 8 April 2009 (EDT)


NGS Family History Conference (May 13-16) [8 April 2009]

The 2009 National Genealogical Society Family History Conference will be held May 13-16, 2009 at the new Raleigh Convention Center in Raleigh, North Carolina.

I live near Raleigh and am planning on attending the conference. I would like to take this opportunity to open a collaborative discussion among WeRelate users and those interested in going to the conference or with those that might want information from the conference after-the-fact from those who attended. The impressive program (about 230 individual sessions) will have one presentation on "Blogs, Wikis, & Flickr" by Jordan Jones on May 14th at 2:30 pm.

If the discussion and interest here warrants, maybe we can set up a separate Article page or Talk page to contain and organize the expanded discussion better than the Watercooler page.
--BobC 12:55, 21 February 2009 (EST)


Please do! I wish I were going to the conference. We cut back this year due to the economy. I'd love to hear how it goes.

I'm planning to go to FGS in September (giving two talks along with a booth). Anyone else going?--Dallan 17:19, 8 April 2009 (EDT)


The lectures I signed up for are listed below. It was difficult to choose, because I was interested in so many; I want to go to at least two topics for every timeslot for which I've had to pick just one -- they've planned for 10 tracks each day, with new lectures in each track every 90 minutes. Seems very well planned.

  • Wed, 8:00 - Opening Session: "The Past is Behind It All," Ira David Wood
  • Wed, 9:30 - Genealogical Exhibits and Vendors
  • Wed, 11:00 - "Tracking Pennsylvania Ancestors: Keys to Successful Research," Kay Haviland Freilich (State track)
  • Wed, 2:30 - "Making Yourself "Priceless" in a Faux Market: A Guide for Professional Researchers," J. Mark Lowe (Working with Records track)
  • Wed, 4:00 - "FamilySearch's Family Tree: Facilitating Collaboration and Research," Timothy Cross (GenTech track)
  • Wed, 7:00 - "Melungeon Voices," Film by Julie Williams Dixon and Warren Gentry
  • Thu, 8:00 - "North Carolina's Cemetery Survey and Stewardship Program," Mary Hollis Barnes (Carolinas track)
  • Thu, 9:30 - "Using the Master Genealogist," Bob Velke (GenTech track)
  • Thu, 11:00 - "Newspapers: Dailies, Weeklies and Beyond," Paula Stuart-Warren (BCG Skillbuilding track)
  • Thu, 2:30 - "The Reality of Researching Your Indian Ancestry," Carolyn Earle Billingsley (Ethnic track)
  • Thu, 4:00 - "What's New in RootsMagic 4," Bruce Buzbee (GenTech track)
  • Fri, 8:00 - "Show Your Stuff! Tips for preparing a Successful TCAPGen Application," Ruth Ellen mannes (ICAPGen track)
  • Fri, 9:30 - "Ancestral Atlas - The Social Networking Site for Dead People!," Nick Francis & Adrian Strahan (GenTech track)
  • Fri, 11:00 - "Death: One Event, Many Records," Ann Carter Fleming (Working With Records track)
  • Fri, 2:30 - "ARC & AAD: Online NAPA Resources," Lynn Goodsell & Rebecca Warlow (National Archives track)
  • Fri, 4:00 - "Scottish Military Records," Craig Roberts Scott (Ethnic track)
  • Sat, 8:00 - "Make 'Em Want to Read It," Jeanie Croasmun (GenTech track)
  • Sat, 9:30 - "FamilySearch's Records Access: Bringing the World's Archives to Your Home," Ransom Love (GenTech track)
  • Sat, 11:00 - "A DNA Surname Project and Its Results," Robert D. McLaren (GenTech track)
  • Sat, 12:15 - "FamilySearch Needs You: Offer to Help Wiki and Indexing," Paul Smart (GenTech track)
  • Sat, 2:30 - "Trail of Tears: Cherokee Migration from North Carolina, Tennessee and Georgia," Wendy Bebout Elliott (Migration track)
  • Sat, 4:00 - "Tracing Central European Ancestors through Military Records," Richard Camaur (Ethnic track)
    --BobC 22:32, 8 April 2009 (EDT)

Marriage Dates? [8 April 2009]

It would be very nice if marriage dates showed up on Person pages. I don't know if that would cause problems. I remember there was some talk some time back awhile about ordering marriages automatically the way children are, too?

I like the way the Christening date gets used if there is no birth date for a person, when that person is shown on Family pages. (And burial for death.) I think it would nice if Marriage Banns were used in a similar way when there is no known marriage date? --Jrich 19:53, 22 February 2009 (EST)


I'm planning on doing this soon (next few months). The plan is to list a person's spouse, children, marriage, parents, etc. in a little 'mini-FTE' window on the page. You'll also be able to use this window to add a new spouse, child, parents, etc.--Dallan 17:19, 8 April 2009 (EDT)


I so do NOT get how to do the "wikipedia" thang [8 April 2009]

Could someone please take a look at Puritans? I put all three "templates" that I could find about pulling in wikipedia text, and I made a "puritan" wikipedia template, but frankly I find the whole thing confusing and don't know what the heck I'm doing. Please advise. Thanks.

-- jillaine 21:38, 25 February 2009 (EST)

What is it that you want to do with the article---simply copy the Wikipedia entry? Or do something more specific to genealogy? And what do you mean by a "Puritan" template?

Templates are normally used when the same thing needs to be used in multiple articles. I don't see that being the objective here, unless what you want is a very brief "standard definition" that could be plugged into an article. (If you had that as a need you'd only need to change the underlying template, if something needed to be added. Otherwise, you have to change your stanard blurb everyplace you used it. Templates can be real timesavers as well as "Consistency makers", but I suspect that's not the need here. Q 16:56, 2 March 2009 (EST)


I think what Jillaine is referring to is from Proposed Guidelines for use of Wikipedia and creating the WP templates to grab Wikipedia content. The page looks like it refreshed on 1 Mar. To me, it seems you added the correct code. Does it look like you intended Jillaine?--Jennifer (JBS66) 17:11, 2 March 2009 (EST)


I never closed this out. It's now looking the way I want it; I only needed two of the three original templates. But I still gotta say that I remain confused about how to do it. The instructions are confusing to me. And I fear that the next time I need to do it, I'll be back here wondering if I did it right. jillaine 14:41, 8 April 2009 (EDT)


The easiest approach is to add {{source-wikipedia|<wikipedia_page_name>}} to the top of your article and wait for the weekend. Over the weekend the introductory section (before the first heading) of the wikipedia article will be copied onto your page. You can also have other sections of the article copied onto your page, but it's more involved.

I haven't checked Proposed Guidelines for use of Wikipedia recently to see how clear it is there, but in any case, the proposal has been accepted and this information should be moved onto a Help page. (You'd need to create a new Help page, copy the content onto that page, and manually redirect the article to the Help page since we can't redirect across namespaces.) Would someone be willing to do that?--Dallan 18:31, 8 April 2009 (EDT)


Putting our heads together [1 March 2009]

So... I have been using the wonderful (And it really is :D) option of merging family trees and I have come to a point where I need to really get some straightening going... The Child is the same in all 5 mergable records (Not only is he the same, but the data is very extensive "10th Thane, Sir Whatzit Whozit, born on March 1st 1256 and died... etc"... the parents, however, are all over the place (Including one record which says the mother was named "John")... I reall have no idea where to go from here, but I think we all (Those of us that tie in here) need to put our heads together, search our GedComs, look in the family Bibles, hit up Wikipedia... whatever to straighten this record set out... I'd like to start a "Group Discussion" on this where anyone can help (Heck, even if they aren't in your family but you like a good puzzle!)... But I have no idea what to do about it... Should I start a discussion on the Talk page? Which talk page should I discuss it on? The Mutual child page? If I do that, will anyone actually see it? How do I call for help on a real snarl? I'm sure I'm not the only person who has run into a tangled part of the tree and thought "Two heads have to be better than mine" :)... so, what is the procedure for a public "Hey, anyone want to help?" sort of thing? Do we have one? Do we 'want' one?

Aabh 09:02, 27 February 2009 (EST)


Seems like there should be a "Medieval" portal or some other article page for purposes of this sort. It would be great to see those of you working in the medieval space working collaboratively. (And no, I'm not going near this space; I'm busy enough as it is in Colonial New England... which reminds me, if there's anyone else interested in working collaboratively on Colonial New England, I've started a "Puritan Great Migration" portal (currently at User:jillaine/Sandbox3 but about to be moved to real portal space. Would love some additional collaborators.) -- jillaine 10:15, 27 February 2009 (EST)

I think this is a great idea - not that I'm going to touch this one either! But... here are a couple of pages that might help somebody (friendly hint) wishing to undertake this project.
Portal:Basic Layout with Instructions and Help:Portal are both still in draft mode but will soon be added to the Community Portal.--Jennifer (JBS66) 11:14, 27 February 2009 (EST)

Hmmm... the portal is great! :D And I shall build a new portal... (no idea what to call it :D) But I also think I want to try to contact the folks directly involved in this tangle... I think what I'm thinking of is so wierd that I can't actually form a solid thought as to what exactly it is that I want :D Maybe I should just go to all the different pages, and add a "Hey! There's a problem here!" note to all the user:pages for everyone watching those pages... Maybe (Not like there isn't enough on Dallan's plate already... sorry about that) There would be a way to "Flag" a record which would put an alert on the page of everyone watching it. A resercher could put a note on the flag: "One record(s) have been flagged by User:Aabh: Hey guys, I found this part of the tree where it says that Joe Smith was really a dog and born from a litter of puppies... Does anyone have a clean record on him? (Link to Joe Smith) (Link to Joe Smith's Talk Page)" Maybe it could pop up like the "You have new messages" alert. I just think with so many records and so many people doing great work in so many diverse pages... we might be able to concentrate forces on one or two problem spots when they are found and maybe with all of us working together, Might really be able to clean up a record set.

Aabh 22:03, 27 February 2009 (EST)


Ah... a "Brick Wall" portal? We've got a graphic image for you. -- jillaine 07:57, 28 February 2009 (EST)
Jillaine, I hope you mean this graphic image :~)--Jennifer (JBS66) 09:08, 28 February 2009 (EST)

Aabh, back to your original question of "Should I start a discussion on the Talk page? Which talk page should I discuss it on... will anyone actually see it?" I did a little sleuthing, and I think I know the Person page you are referencing. In this case, most of the Users watching are of the type that uploaded their GEDCOM and never returned. However, User:Jrm03063 is also watching the page. Jrm is an active user and will hear your call! My suggestion would be to post a comment on the child's talk page.

One way to tell if you have active users watching your page is to click on their name, which brings you to their userpage. Then, click on More, Contributions. Here, you will be able to see what they've contributed to WeRelate. If it just shows a bunch of GEDCOM uploads and nothing else - well - their probably not listening!--Jennifer (JBS66) 09:05, 28 February 2009 (EST)


Thank you! :D The Brick Wall Portal... Hmm... actually (All horsing around aside) It is kinda cute. I like it! :D Maybe it's not a bad idea to have something a little... obscure as a name, "Oooo! That IS a puzzle, why don't you put it up on the Wall and see if anyone else can help?" It might be kinda neat :D Since it isn't really a "Medieval portal" or a "King portal" or anything of the sort...
Jennifer: I managed to untangle that mess by spending all day (I started at 10AM and kept going until midnight) on it... I kinda got all carried away :D (You know how it is, I fixed one little thing, then I went on and fixed another... and I was having so much fun that I just kept on keeping on...) But, even though there are a lot of folks whom aren't still around anymore, I got a lot of data from their trees, which pushed Jrm's and my tree quite a way further back... So it was worth it :D I managed to merge (And clean up) what looks like 8 trees together. I wonder how many things could benefit with having someone put that much effort in an area? Especially if the person whom puts it on "The Wall" put it up with a note: "Hey, Jennifer, this looks like it's in your tree!" or something of the sort :D Aabh 21:38, 28 February 2009 (EST)

New Portal for Medieval - Middle Ages Research [2 March 2009]

I couldn't help myself. I got you started so you have something to edit it. I did not call it "Medieval" but "Middle Ages" because um that's what Wikipedia calls it. ;-)

Portal:Middle_Ages

Check it out and go to it!

Have fun!

-- jillaine 22:49, 28 February 2009 (EST)


Middle-Aged Portal :D I love it! :D I hope it doesn't buy a Farrarri... :D Okay, I'll start tinkering with it! Thanks! :D Aabh 19:13, 1 March 2009 (EST)


New GEDCOM import function and a new Sandbox site [24 April 2009]

I'm sorry I haven't been responding lately to the watercooler. I really want to stem the tide of new duplicate people and family pages flowing into the system and I've been spending all of my time on the new GEDCOM import.

The new GEDCOM import is finally available for testing on our new Sandbox site. The sandbox contains a copy of the main WeRelate.org website. Anyone can use it to try out ideas and test things (anything, not just uploading GEDCOMs). You can find out more about the new Sandbox by visiting the Sandbox main page.

I hope that people will test the new GEDCOM import function on the sandbox and give me feedback. If you find bugs or suggestions for enhancement, please leave them on my sandbox talk page. If all goes well I'd like to move the import function to the main website by the end of this week.

To test the new GEDCOM import function, sign into the sandbox using your existing WeRelate.org user name and password if you signed up for WeRelate.org prior to February 21, or create a new sandbox account. Then select "Import GEDCOM" from the "Add" menu like you normally would. Within a few minutes you should receive a message on your talk page telling you that your GEDCOM is ready for review. Click on the link in the message to review your GEDCOM. There is a "Help" tab with instructions.

During this test period, wiki pages will be generated for all GEDCOMs after the review is complete. When we move this to the main website, pages will be generated only for GEDCOMs under a certain size with less than a certain number of warnings and non-matches. Other GEDCOMs will need to be reviewed by an administrator before the pages are generated. To facilitate this, there is a new "Gedcom Review" option under the "Admin" menu so that administrators can see which GEDCOMs need review.

It's taken a long time, but I think we're almost there.--Dallan 11:51, 1 March 2009 (EST)

I and two friends have been working together on one chart and have been desperate for some way to collaborate or get our charts in sync. I've been watching WeRelate for some time but am still wiki challenged; my friends will be completely new to wiki and this site. We want to upload each of our charts, one at a time, and I'll try to do the merging to get the info all connected. We have sources, but I'm sure they won't meet WeRelate conventions!! There will be less than 200-300 persons in each GEDCOM we upload, but a lot will be duplicates that I'll need to merge. I'm thinking between the 3 of us, we will have 4 GEDCOM files to upload. Do you recommend we upload to WeRelate directly or to the sandbox? --Janiejac 21:02, 2 March 2009 (EST)

Do you have any idea how soon the new import function will be brought over from the sandbox? --Janiejac 20:43, 27 March 2009 (EDT)


The new GEDCOM upload function is ready for final testing at the sandbox website. It's taken a long time, much longer than I thought, to implement everyone's suggestions, but I believe the result is a much better product, so THANK YOU to everyone who offered suggestions! I'd like to add the new import function to the main website later this week, so I invite everyone to test it once more on the sandbox and to let me know if you notice any problems. Thank you again!

--Dallan 10:05, 6 April 2009 (EDT) who is finally crawling out of his cave now that GEDCOM import is almost ready!


Did I break it? I've been testing the GEDCOM review, in Places, and um, now I can't pull up any page in the sandbox! -- jillaine 15:33, 8 April 2009 (EDT)

It's back. What was THAT? jillaine 15:35, 8 April 2009 (EDT)

Um, that was probably me rebooting the server. Sorry about that. :-)--Dallan 18:31, 8 April 2009 (EDT)


Has there been a change? Up until now I have imported small add-on trees to my tree without any problems. Today the message was that I had to name a new tree! I don't want a bunch of trees to confuse me. If I create a new tree can I merge it with my base tree?--HLJ411 14:04, 15 April 2009 (EDT)


Please see the new section "GEDCOM re-uploads" at the bottom of the page.


Watching merged pages question [8 April 2009]

Currently, when you merge pages you end up watching the merged page only if you were watching one of the pages involved in the merge. In the sandbox, I've changed this so that you always watch the merge targets. But I'm thinking perhaps I should change it back. There are three possible options:

  • only watch merge targets if you were watching one of the merge sources
  • always watch merge targets
  • watch merge targets if "Add pages I edit to my watchlist" in the "Editing" tab of your preferences (available from the MyRelate menu) is checked. This preference is checked by default, so this option would normally function the same as the second option unless you had changed your preferences.

What do people think?--Dallan 12:15, 1 March 2009 (EST)

I kind of like the third option, since it allows some choice. If I'm merging in an area where I'd like to preserve the outcome, keeping me watching prevents holes if gedcoms are later deleted. On the other hand, I do merge a lot of stuff I never want to see again, so if I had a way to turn it off occasionally, that might be useful.
I'll go with this option then.--Dallan 18:31, 8 April 2009 (EDT)

Chronologically Dated - Editing sources by date [6 March 2009]

Hello,

Is there a way (quick trick) to organize the sources chronologically exist?

Or could it be a easy thing to do by Dallan or someone else more experienced with computer code?

Right now I am manually doing this.

My thought was when you edit the page, added or change the citation date after the volume page section, it would automatically organize the sources by date?

Just asking, Thank You. --DFree 15:58, 1 March 2009 (EST)


If we could just get sources that would be good. From what I have seen, most source citations do not have dates entered. Personally I seldom bother unless it is the only way I have of identifying the issue of a magazine, and if it is a book, I assume the source has the publication date. So I am not sure there will be much there to sort by.--Jrich 17:34, 1 March 2009 (EST)--Jrich 17:36, 1 March 2009 (EST)

My preference is to have my sources organized by the event dates, which may or may not be the same as the source dates.--Beth 20:26, 1 March 2009 (EST)
Agree with Beth. I do not think I have ever constructed a page where the date of the source is relevant to anything (if I ever use it), and I would hate to have that be the default sort.--Amelia 23:05, 1 March 2009 (EST)

Creating an easier way to manually sort sources is something that is on Dallan's to-do list. Right now, you have to cut-and-paste all of the data into new Source fields in order to move them. Having a way to move the sources around to manually sort them would be nice!--Jennifer (JBS66) 16:06, 2 March 2009 (EST)


Contrary to some of the statements made here, citing the date of publication for the specific work being cited is important. Many publications occur in more than one edition, and the work is often revised for subsequent printings. Even when the work is a reprint, additional information may be added by a publisher, or the author, in the form of commentary, editorial analysis, or other matters considered relevant. The differences between reprints are usually trivial, but the differences between new editions is often substantive. If the date of publication is not cited, then its not possible to tell which particular edition was used, and it becomes difficult to verify what is being said. This is why every standard bibliographic citation format includes the date somewhere in the citation. Q 16:34, 2 March 2009 (EST)

In recognition of the appreciated deletion of your last comment, I'll rewrite mine. For the purpose of clarification, I was talking about WeRelate pages, which do not often require a full citation because all the relevant information is (or should be) on the source page (multiple editions excepted). --Amelia 16:58, 2 March 2009 (EST)

I was also thinking it would be great to have a Move function for sources. When I found a new census record, the census dates were out of order. It's not a big deal, but it would be nice if they were chronological. I also had a set of pension documents for one individual. I ordered them physically before creating the image and source pages, then after they were all added, I listed them in chronological order in the Talk page for the person. I opened the page for the person in a new tab, and added the sources one at a time. - Parsa 12:20, 6 March 2009 (EST)


Personal History need to be place on proper pages [2 March 2009]

Personal History  about an individual should be on that Person's individual page in the Personal History section...so that it is more easily understood...Personal History on a family pages should only be on the couple themselves, and the Personal History on their children should be on the child's page of whom they are about, same for Parents, & Sibling,...when one post notes we should add our signature at the end of each note, then if someone who has a question concerning the notes knows who to discuss a point with and also instead of using "I" am kin to this person put your name because "I or me" could be any one because we are all "I or me", we need to remember that this is viewed by people all over the world and hopefully for many generations to come, and on one page several different ones may add Personal History to the person's page... --Dlbradley1 16:51, 1 March 2009 (EST)

Unfortunately the note box does not support the --~~~~ construct. --Jrich 17:35, 1 March 2009 (EST) --- Sorry I meant the Personal History section not the note section...--Dlbradley1 19:53, 1 March 2009 (EST)

You could suggest this in the help files; I would not make this mandatory.--Beth 20:30, 1 March 2009 (EST)
I agree that personal history should only include information on the individual, but you should not sign anything you do on the person page. You should attempt to create a unified narrative with the text that is there. The history function keeps track of who does what if someone wants to question it. If your personal opinion is relevant, the Talk page allows you to attribute your thoughts to your name.--Amelia 23:03, 1 March 2009 (EST)

This again goes back to the discussion on sources...when you put a source sometime it looks as if it is the source of all the History on the page that is why I said we need to sign what we put on the page some do not know to go to the history page or will not take the time...some of the pages have up to 200 years of history on a person's history page some of it correct and some that is questionable and If you have a source down it may be taken that all this is the work of the one listed on the source.--Dlbradley1 23:41, 1 March 2009 (EST)

Now I don't understand what problem it is you're trying to solve. But I stand by the comment that teaching people to use the wiki software with the history and talk pages is preferable to actively discouraging the creation of coherent narrative pages. --Amelia 00:09, 2 March 2009 (EST)

I am not dicouraging the creation of coherent narrative pages..and I am just learnig Wiki as I go and want to learn all I can.....what I am talking about for example: several pages of my upline someone uploaded on the family or person page several generations of downline[(over 200 years in some cases).... in the History section of that page] in some cases I do not agree with it, and I use a very well verse member of the family for Source a lot...his work is well backed up and highly respected in the genealogy field (he gave me personal permission to use on this site for it is all copyrighted)..then the source come up at the bottom of the page with his name on it, and it looks as if he was the source of all the information on the page..when he is not...when I use a source I want it to show what information the source cover...I love the fact that we can put our work out and it be examined by other and fine errors that we can correct...this is the great part of this program but the information should be put on the proper pages..that is why we have A Person Page for each person and a Family Page for each Family...to my understanding it is set up to cover one generation not 5 and 6 generations.....--Dlbradley1 13:53, 2 March 2009 (EST)


dlbradley,

could you link us to the page in question?

Generally sources at the bottom of the page are linked to a specific fact. But without seeing what you're talking about, it's difficult to assist you more specifically.

Thanks.

-- jillaine 13:58, 2 March 2009 (EST)


Ah...you want to delete all the nonsense that shouldn't be there, and you want to attribute specific information in the notes to a specific source? Edit the page, delete what should be deleted, and after the section(s) that you want to source do one of two things: 1) add <sup>[[#S1|S1]]</sup> (where S1 is the source you're citing; make it S2 or S3 if necessary). This gives you a footnote linked to the source. or 2) add <ref>Source description here</ref> after the text, and <references/> to the end of the page. This gives you a footnote with a number linked to the text that you put between the 'ref' tags. It's useful if the citation isn't a source already, needs additional information, or you're afraid the sources will be altered later. (If you're talking about a source for a fact in the left hand column, we need a page to look at as Jillaine suggests.)--Amelia 14:02, 2 March 2009 (EST)

Sorting order for sources at National Archives [6 April 2009]

I was impressed with this explanation of sorting order and wondered if it would be helpful. The following was copied from http://arcweb.archives.gov/help/usingarc.htm#sort_auth Perhaps this is common knowledge; but I hadn't seen it before.

Not having read more than you provided here, this is not a conventional sort, and is being explained, apparently, exactly because they use a customized sort. Almost all text-based sorting is done character by character where archive21 sorts to after archive2 and before archive3. That is why so often you see leading zeroes added, e.g., archive02. Sorting is done character by character, based on the code used to represent the character being sorted. If two strings are tied when the end of one is reached ('dad' and 'daddy') the shorter one will go first: the absence of a character sorting before any character. The codes were originally selected to make the characters sort in a more or less intuitive manner in English. [4] will give you an idea of the ordering. Some changes have come along to allow sorts to be ordered according to the language being used, but it is still essentially character by character. Dallan can correct me, but I'd be surprised if WeRelate, based on encyclopedia software, uses a different system. --Jrich 17:05, 6 March 2009 (EST)

People and Organizations Searches

As with the Archival Descriptions Search, the default search results of a keyword People or Organizations Search are ordered by the most relevant first. (Relevancy is based upon the number of times a keyword appears in an authority record, as well as its placement in the authority record.) Results of a browse People or Organizations Search are presented in alphabetical order. You cannot re-sort the search results for either a keyword or browse search.

In general, sorting is on a character-by-character basis and is not case sensitive. Numbers, potentially consisting of more than one numeral are the exception. These are sorted by arithmetical value. For example, ‘7’ comes before ‘17’, even though a character-by-character comparison would order ‘17’ first.

The general order of characters is defined as: Commas, Spaces, Symbols (other than numerals, letters and punctuation marks), Numerals (0-9), Letters (A-Z). Articles such as 'A', 'An', and 'The' are ignored when sorting Organization names.

Examples

Sorting is not case sensitive. So in Organizations searches for example, acronyms are not separated from other text:

NAACP
National Archives and Records Administration
NATO
Northern Energy Corporation
NRA
Nuclear Data Group

In People searching, by ordering commas before everything, similar last names are grouped together:

Dinh, Phuc Nguyen-
Dinh, Q. C. (Quang Chi)
Dinh, Quang Chi
Dinh Duc Dao, Giovanni
Dinh Lê, 1963-

Spaces are ordered before Letters/Numerals. Even though the periods are ignored, the space after the initial “J” and “K” allows these names to be ordered before first names that are spelt out:

Oppenheimer, J. Robert
Oppenheimer, James N.
Oppenheimer, K. T.
Oppenheimer, Kevin S.

Headings with qualifiers or explanatory notes are arranged as if those qualifiers are just other words in the heading:

U.S. Circuit Court for the Eastern District of Pennsylvania.
U.S. Circuit Court for the Eastern (Keokuk) Division of the Southern District of Iowa.
U.S. Circuit Court for the Eastern (Spokane) Division of the District of Washington.
U.S. Circuit Court for the Eastern (St. Louis) Division of the Eastern District of Missouri.

Abbreviations are sorted alphabetically exactly as they are written, and not as though they were spelled out:

Cmdr. Smith
Commander Brown
Doctor Zhivago
Dr. Jekyll and Mr. Hyde

Numbers are arranged in arithmetical order:

5th Dimension (Musical group)
101st Airborne Division Association
200 Voice Festival Choir & Orchestra
707 (Musical group)
Periods within numbers are treated as decimal points.

Letters modified by diacritics are sorted as their nearest basic equivalent letters in the English alphabet. For example, ‘ä’ is treated as ‘a’.--Janiejac 15:48, 6 March 2009 (EST)


I know that's the ideal, but it takes extra work to make it happen that way. Perhaps someday...--Dallan 18:31, 8 April 2009 (EDT)


Non-scientific/Fictional/Biblical Trees [7 March 2009]

Everyone, what do you think about allowing fictional, non-scientific, or Biblical genealogy in the database?

I personally think it would open up possibilities for some really educational stuff (think about a genealogy of the Old Testament), but we'd have to require both a) a warning at the top of each page warning of this, and b) no links to normal genealogy pages.

What do you think?--Joeljkp 20:40, 6 March 2009 (EST)


For example: Template:BiblicalRecord-Christianity --Joeljkp 20:45, 6 March 2009 (EST)


See topic 31 on this page. Not sure if there was a final consensus, but you can certainly find out what everyone thinks about it. --Jrich 21:32, 6 March 2009 (EST)


At current there are a number of tree lineages that end in legend. A lot of time history is "Changed" so a king will become "Descended from the Gods themselves". When I run into this, I try to rename the suffix of the individual to "Legendary Hero of ***** History", which helps some... there has been some argument as to whether to include legendary people (Adam and Eve have been brought up before), the problem is; where does the real lineage end and legend begin? Being a person whom believes strongly that once data is destroyed, it is lost and can't be recovered, I personally believe we should have all of the legendary ends to all of the Peerage trees (Including the Kings of Judea), and like any good Science, we will call that "correct" until someone comes up with proof otherwise. I do agree, though, that there should be some kind of comment about "Legendary" persons. Who is Legendary in the Kings of Judea? I'd say anyone with a lifespan longer than about 100 years is probably Legendary and should be marked as such. With the Norse, I've been going to "Legendary" status as soon as they "Made the snow" or "Walked for 300 years" or something of that sort. :) Aabh 09:54, 7 March 2009 (EST)


What happens to pages nobody is watching? [8 April 2009]

Sometimes when I am bored, I will scan the Duplicate Review page for names that are familiar. If I know something about one, I might do a merge.

So today I merged a family with a very familiar name, but the family wasn't one I am following. After merging two copies together, each with a single, different child, I now had a family watched by two people, but having only 2 children out of several. So I added some of the missing children that I knew about. After doing this, I took them off my watchlist, not having any personal interest in this family.

So now there are 3 children, with a source pointed to their birth record, and nobody is watching them. They are valid. Will they remain, or will they get flushed at some point? I don't really need more people in my watchlist, but I will if I have to. --Jrich 15:59, 8 March 2009 (EDT)


This is a good point;

I have been merging pages as well, and I have been snagging new record data from trees that are out there (Not being really maintained), but have very useful data... I:m "Buttoning" those records as I have time (Going through each record on the matching trees and merging the parents, then the kids, then spouses, etc)... but it:s time consuming (Not HALF as time consuming as before the merge function was put in... Just though I:d make another compliment to Dallan for that :D), but it is taking time, I have 3,500 people on my tree, and I:m wandering all over it to connect as fast as possible...

Would it be okay to wait 6 months or so before you unleash the `bots on those unviewed trees? Long enough for me to mine the information sources? (I mean, if they are going to put the data up here and leave, at least I can put it to good use, right? :D) Aabh 20:52, 8 March 2009 (EDT)


If the person's page has sources, documentary evidence for their relationships and life, there's no reason not to have them on the site. Theoretically someone could make pages for people who have similar surnames, but who are not related, in order to avoid confusion. You never know how this could help someone in the future. Charles Messier, the French astronomer, cataloged over one hundred fuzzy objects in the heavens so he wouldn't confuse them with the comets he was hunting. Now we know these objects are galaxies and nebulae much more important astronomically than the comets. They still go by the same names he gave them.--Parsa 22:31, 13 March 2009 (EDT)

A few comments:

  • By popular demand, we're not planning to automatically delete anyone's trees, even if they are no longer active on the site and the tree contains duplicates with others' trees, so you don't need to worry about the pages going away because a robot has deleted them.
  • In a few hours I'll post an idea for a new approach for when someone deletes their tree - what pages will and won't get deleted. I think we should be more restrictive about deleting pages than we are now to avoid creating holes in others' trees.
  • Pages that nobody's watching can be manually deleted by anyone. All they have to do is watch the page and then delete it. I'm not sure what to do about this or how much of a problem it is. I could possibly say that you can't delete a page unless you're the only watcher and you're the original contributor. Or that only admins can delete pages for people born before a certain date or with wikipedia links, but these two restrictions would be simple to circumvent by editing the page first. Or I could allow anyone to undelete a page that was deleted.

Any thoughts on this?--Dallan 18:56, 8 April 2009 (EDT)


Deleting Duplicate Pages [14 March 2009]

I've been working on deleting sources that are prefaced with Ancestry.com that are duplicates of sources that already exist on WeRelate. Most times, deleting the duplicate source is not a problem, as there is nothing that links to the page, and nobody is watching. Occasionally, however, there are pages linking to the source. In that case, I could redirect the page, but this causes an annoying problem. The source title that people should not use is still listed in the drop-down box - which is terribly confusing - even for more seasoned WeRelate users! Any thoughts or tricks I may not have thought of?--Jennifer (JBS66) 15:11, 9 March 2009 (EDT)

I usually just fix the cites on the relevant pages -- there are rarely many. (And I assume you're adding the Ancestry.com link to the existing page?)--Amelia 22:32, 9 March 2009 (EDT)
Thank you for the suggestion. And yes, I am adding the Ancestry.com link.--Jennifer (JBS66) 13:46, 10 March 2009 (EDT)
So if I see a source like this: Source:Ancestry.com_-_Search_Indiana_Marriage_Collection,_1800-1941, I should move it or redirect it to: Source:United_States,_Indiana._Marriage_Collection,_1800-1941, correct? - Parsa 11:42, 14 March 2009 (EDT)
Here's what I do when I find ancestry.com sources:
  1. Look at More: What Links Here and make sure that nothing does. If nothing does (and so far, all of the ones I've found haven't had anything linked to it), continue:
  2. Copy the URL for the ancestry.com link
  3. Edit the page, and add {{speedy delete}} into the text box, followed by "dupe; nothing links here" on the next line.
  4. Save the page.
  5. Go to the non-ancestry.com version of the source.
  6. Add a repository entry: Ancestry.com and paste the URL into the longer box, and select "Paid site" from the drop down menu.
  7. save this page.
C'est tous.
-- jillaine 11:47, 14 March 2009 (EDT)

miscellaneous suggestions [9 April 2009]

Just some things I noticed, that I happened to write down before they were forgotten:

1) Sex is not shown when comparing children inside the merge families function: this can be useful when children are named Unknown and similar vague names since discrepant gender is fatal to a merge.

Good point - I'll add gender.

2) 2-part place names (page name and alias) could be useful, but mostly get misused. For example, Recently I encountered “Barnstable, Barnstable, Massachusetts, United States|Barnstable, Barnstable, Massachusetts, England”. The editing field is too small to display all this so it appears correct, so these type of errors are hard to spot while editing, leading to multiple edits. I also believe shortcuts like “Barnstable, Barnstable, Massachusetts, United States|Barnstable, MA” engenders US-centric naming which is bad.

I've been thinking that the solution is to have events take two lines in the form so we can make the place field longer.
If you're thinking about this issue, might I add source titles and renaming titles to the list of fields that really need to be longer!--Amelia 00:44, 10 April 2009 (EDT)

2-part naming is a good feature for allowing some flexibility in naming when importing GED. Naming is a hard problem, and there is a constant struggle between current and historical names, and who knows what each genealogist may favor. But this flexibility allows all sorts of naming conventions to be displayed on pages with no consistency. Overall, it may be better to have some robot program go through and resolve all the aliases to the formal place name, and remove the alias. Leave it to the family/person history to discuss historical place names if needed. That way, you can handle the wide variety of imported names, but gradually make them match a standard.

I wouldn't dare change the place names that people enter :-) I do plan to write a robot to match them better someday though; early versions of the place matcher was easily confused and left a lot of "red links" that the current place matcher can now link to the correct place.

--Jrich 13:41, 10 March 2009 (EDT)

--Dallan 13:10, 9 April 2009 (EDT)

I am one of those who has been putting shortcuts like “Barnstable, Barnstable, Massachusetts, United States|Barnstable, MA”. The benefit I see is readability. With the really long names, the info in the left-hand margin can get pretty cluttered, and using shortcuts can help make it more concise. I don't see it as necessarily US-centric, so much as "local-centric" to the person and family in question. If I'm working on a particular line who lived in Barnstable, I know what county and country that's in, and don't need to see it repeated over and over again. On the other hand, if I come across an unfamiliar shortcut place name, I can easily click into the place page, or merely hover my mouse to view what it links to, in order to determine the full name.

Also, there are cases where a specific source gives a place name in a specific way, and that should be represented as it appeared in the source. For example, if the source said "Greenwhich" for "Greenwich", or "beer Eylant" for "Barren Island", I would link to the full proper place name, while giving the source's exact version in the alias. The name|altname notation is useful for that. It would be a grave disservice to have some robot go and strip out all the aliases.

--TomChatt 03:02, 17 March 2009 (EDT)


I have a different problem with these multi-part, hyper-comma-ed place names, which I first ran into while poking around on Ancestry. Leaving out "Township" and "County" as part of the name is misleading, especially to novices, and I personally refuse to do it. If you see a listing for "Albia, Monroe, Iowa", is "Albia" the name of a town? Or a township? It makes a difference. I have ancestors in the town of Albia, which is in Jackson Township -- but others who are farmers out in Jackson Township itself, with no connection to the town of Albia. Nearby is Linn County, which has a Monroe Township, . . . and a town therein (now vanished) named "Jackson". This problem is especially egregious in unsourced GEDCOMS. It also doesn't account for cases like Norfolk, Virginia, which is an "independent city," no township involved. Likewise, I object to anachronistic place names at Ancestry and elsewhere, like "Prussia, Germany" in the 17th century. There's no such place, "Germany" being only a linguistic region, not a country, until the 19th century.

So I believe in being as explicit and historically accurate as possible with placenames -- though I also have to confess to U.S.-centrism (or whatever) in that I believe "North Carolina" or "Louisiana" is enough to indicate that the place is a U.S. location by default. --mksmith 13:31, 5 April 2009 (EDT)


I agree with you on the lack of the word 'county'! I don't know how much time I've lost just trying to decide if where an author meant was a county or city. I leave the word county in my places and so far the program has taken it very well. I hope they have dropped the idea of having a robot 'clean up' our places! The problem seems to be when the categories are automatically assigned to our pages. I still don't understand how the categories are assigned and/or how to change a category to one I think more appropriate. I can add a category, but I don't know how to remove the one it should replace. I've tried rewording the page, but that doesn't seem to help.--Janiejac 14:56, 5 April 2009 (EDT)


I understand your comment, but I think the problem is unsolvable, and probably the best thing to do is go with the flow.

First, I think people are trying to communicate at least two different things with the place name: where an event happened physically, and where it happened in terms of governmental/administrative unit to understand the recording and laws associated with that event. We have already had extensive discussions about towns versus parishes, for example.

Second, I think the Place: namespace has no way to represent time, so it creates inherent ambiguities, which genealogists see in books all the time, often expressed as "that part of Salem now known as Beverly", etc. I believe I have read that this problem was addressed by asking people to use the name of the place in 1900, following FHL conventions, which if done accurately (I bet most people use the modern name), would remove the time dimension from the issue.

Third, there is the sometimes conflicting viewpoints of the knowledgable researcher, and the potentially naive searcher. As a researcher, you may want to put Prussia, but what will the person searching to find your data enter as the location? Germany, perhaps? Perhaps they don't know the exact year the birth/marriage/death/event happened, and perhaps just a year or two difference makes a difference in what the place was called.

If the location of the event was the goal, we could just put in approx. longitude and latitude by selecting a point on a chronologically accurate map. I suspect few people bother to locate the old homestead to such precision, and this type of data would probably end up appearing more precise than it really was.

There are some features to mollify your dissatisfaction. You can always create historically named places and redirect them to the name used by WeRelate conventions, or you can use the two part naming, i.e., [[Place:Chatham, Barnstable, Massachusetts, United States|Monomoit]] to display the historical name Monomoit but still link to Chatham. --Jrich 14:48, 5 April 2009 (EDT)

Something that doesn't take much time and would be very beneficial is to edit the Place page and add alternate names and older/newer jurisdictions (located-in) places for the Place. This helps the matcher match the place when it is listed under the alternate name or older/newer jurisdiction in GEDCOM uploads. It also helps researchers learn about the place history. It's a good idea to do this even if you've also created a redirect.--Dallan 13:10, 9 April 2009 (EDT)

The added comment above has confused me. I am not entirely sure I do understand the comment about missing counties. Yes this is a genealogy problem, but it is not really a problem in WeRelate since to name a valid Place:page you either link to or directly name a fully qualified name.

The issue of townships wasn't real clear. Was there another Albia such that Albia, Monroe, Iowa, United States isn't unique? I believe each comma only means "contained in". If there is really a place that cannot be unambiguously named with a 4-level name, why not add a 5-level Place page? 5-level names are already in use for cemeteries, for example: Place:East View Cemetery, Rome, Floyd, Georgia, United States. There is also the description field where additional information such as parishes, church names, townships, longitude/latitude, etc. could be added.

Regarding an unincorporated area in Jackson Township in Monroe county, you can add a page for the township, if specifying simply the county isn't good enough. (One can always go overboard on being precise. For example, should one insist on creating a place for a named ranch, or can that better be communicated in a different way?) The instructions for adding a place say

  1. The title of a place page is the name of the place, followed by the names of the containing jurisdictions; e.g., Cook, Illinois, United States.
   * The number of containing jurisdictions varies from country to country. The U.S. and Canada generally have 4 levels -- inhabited place, county/district, state/province, and country. Most other countries have 3 levels.
  1. Omit "type" words like County or District from the title. But it's ok to use type words in parentheses if needed to distinguish the place from an existing place with the same name; e.g., Thornton (township), Cook, Illinois, United States.

There are already lots of pages for townships. For example, Place:Ashland Township, Indiana which redirects to a page with the full formal name Place:Ashland, Morgan, Indiana, United States. The page has a type of "Township". As the instructions say, this could have been named Ashland (Township), Morgan, Indiana, United States, if necessary. And of course, there are pages for counties, since many farms wouldn't be in a town.

The other issue I saw addressed was the use of modern versus historic names, about which I already used more than my share of space.

--Jrich 09:35, 6 April 2009 (EDT)


How to add and ancestor? [11 March 2009]

I have the name of a great grandfather to add. It seems that my only options are to add him as a second spouse to my grandfather or to make him a child of my grandfather. There is no apparent way to make him the great grandfather that he is. I just don't understand. Help!--Sharrow 08:09, 11 March 2009 (EDT)


Hello, can you please post the title of your grandfather's page on your talk page User talk:Sharrow. Then, I can assist you a bit better. Thank you!--Jennifer (JBS66) 08:16, 11 March 2009 (EDT)


OK, I've added his name to my page.--Sharrow 08:26, 11 March 2009 (EDT)


I messed up; can somebody fix it or tell me how to fix it? [18 May 2009]

Would someone please search for Vashti Unknown (2) and tell me why I'm not watching that page. The menu at the top of the page gives me the option to unwatch it but my name is not at the bottom as a watcher. This page is a redirect from Vashti Unknown (3). Somehow I've messed this up. I clicked on the review/redo button but that was a mistake. I wanted to review what I had done, but didn't want to redo it. I guess I should have reviewed it by looking at history - but the button said review. (How long can I keep claiming to be a newbie? <grin>) --Janiejac 18:33, 11 March 2009 (EDT)


It looks to me like you are watching it. Sometimes I have seen things like this. I think there is a caching issue. I rely on the Watch/Unwatch to be the most accurate indicator of whether I am watching a page. --Jrich 18:54, 11 March 2009 (EDT)


I've got two categories that should be merged but I don't know how to do that.

  1. Category:Jackson in Fauquier, Virginia
  2. Category:Jackson in Fauquier County, Virginia

My entries seem to be the only links on both of these pages. --Janiejac 16:37, 27 March 2009 (EDT)


One of MySources contained an email address. That was fine for my personal file, but I should have removed it before uploading. I renamed the source but that didn't change all the person or family pages that show that source. It still shows with the email address. Horrors! Renaming really doesn't edit the source!! Now it seeems I have to go to every page using that source to fix it! That is enough to discourage anyone.

I can understand not editing a WeRelate Source that other folks might be using. But seems like there should be a way to edit my own source. Later when I want to clean up MySources and find that I could have used a WeRelate Source, I guess I will still have to change every page?? No way, that will be done. --Janiejac 07:34, 31 March 2009 (EDT)


Today you can edit your MySource page and put a #redirect [[Source:title of the source page]] at the top of the big text box to redirect the MySource to a Source page, so that when you click on the MySource link in your Person and Family pages you'll be taken to the Source page. Starting next week the new GEDCOM uploader that will hopefully be installed this weekend will let you review the MySource pages that will be created from your GEDCOM and allow you to match them to Source pages before your GEDCOM is imported.--Dallan 13:49, 9 April 2009 (EDT)


I'm glad y'all are patient with newbies. I wanted to add a table, so went to help/formatting/tables which sent me to wikipedia which offered a spreadsheet converter. I thought that was great but the results are NOT great. Instead of erasing the mess and giving up, I left it hoping someone could tell me if it can be salvaged; if not, what else can I try? What I pasted there not only moved all the Google ads to the left, it shows all the code, and if you scroll down beyond the code, you see the table results which are not spaced right at all. I've got this info in both rtf format and in excel. I don't want to have to type it all over again into werelate. I obviously don't know how to do a decent table in wiki and if I did, I'd have to retype it again. Ugh! I'm going to be disappointed if there is no good way to keep this kind of info here. Here's the page: [Jackson in Clark, Indiana] --Janiejac 01:20, 18 May 2009 (EDT)

Janiejac, there was a tiny piece of code that was messing the whole thing up! I removed it and your table looks great! The code btw was {{table}}. That template, which works on Wikipedia, does not work here on WR until the MediaWiki software is updated. What this means is that you will need to add the code {| border="1" cellpadding="4" manually. I did this for you on your Jackson page. The border="1" defines the thickness of the border, if you change the 1 to a 0, the table can have no border. The cellpadding="4" adds a bit of space around your text so that it isn't right up against the border. Both of these numbers can be adjusted if you want. --Jennifer (JBS66) 07:16, 18 May 2009 (EDT)


Seeking those knowledgeable about St. Albans, Hertfordshire [14 March 2009]

Anyone here familiar with the records of or research about St. Albans, Hertfordshire? (Cooley researchers, early Springfield settlers, etc.) I'm trying to make sense of the different Sources related to this parish. Please see Person talk:Benjamin Cooley (1) where I list all the variations-- some of which are obvious; three of which are not. Before I delve into each and every film note about these (there are a lot), I thought I might try to track down someone already familiar with this set of records. Thanks. jillaine 10:08, 14 March 2009 (EDT)


A Crazy Idea to Improve Our Cemetery Pages [20 March 2009]

There are lots of great cemetery transcriptions out there on the web. How much more useful would they be if integrated into this site? Quite a bit more, I think, given the ability to link to the individuals listed in the transcription and to provide richer information about the cemetery itself. Unfortunately, we can't very well go and just copy the transcriptions available on other sites. But I have an idea for a system to go about legitimately getting as many transcriptions as we can.

It goes like this: create a script that generates a list of all the cemeteries on Interment.net, including the email address of the person who submitted each transcription. For each cemetery in the list, find out if there is a corresponding Place on WeRelate. If not, create the appropriate page. At the end of this process we will have a list including the name of a cemetery, the email address of the transcriber, and the name of the corresponding WeRelate page.

Next, for each of these cemeteries we send a polite email to the transcriber telling them a little bit about WeRelate, giving a link to an example Place page that gives an idea of what the end result would be like, and asking if they would be willing to contribute their transcription. We can tell them they can either go through the extremely easy process of creating an account and then adding their transcription to the relevant page, or they can simply mail a small statement authorizing us to post it to WeRelate under GFDL. Then we wait and see how they respond.

My hope is that we could slowly yet systematically go through the existing cemeteries on Interment.net getting transcriptions from whoever is willing to submit their work. Once that is done, we can monitor the Interment.net New Cemeteries RSS feed to request transcriptions from anyone submitting new ones to Interment. Over time I hope that we'd become enough of a cemetery resource that we could establish a cemetery portal and start getting new transcriptions submitted to us directly.

Thoughts? Oh yeah, and this process can be adapted to pretty much any transcription site. Interment.net is just an example. --JoshHansen 16:48, 14 March 2009 (EDT)

By the way, I think Place:Lizemores Cemetery, Lizemores, Clay, West Virginia, United States is a good example of what can be done with cemetery transcriptions on WeRelate. --JoshHansen 17:06, 14 March 2009 (EDT)

Funny... I was just looking at a bunch of cemetery transcriptions and thinking the same thing. There are a few sites making an effort, but they are not working together. Here are a few;

If they were all working together, there would be a lot more information out there for people. I agree that having cemetery transcriptions here is a great idea. There may be a lot more that can be done on WeRelate than a surname-ordered transcription. Cemeteries listed by location with a name index are much better I find. Location often shows relationships not evident with surnames only. We have the ability to include GPS coordinates into this site. There's no reason why you could not build a complete virtual cemetery with photos tagged to exact geographic spots in the cemetery. If you look at my own Virtual Road Trips on the photo page of my AmericanRoads.us web site, you'll see what can be done with geotagging images. I don't even need to stop and record the GPS location. I just make sure the GPS receiver and digital camera are time synchronized before I begin. Software easily does the rest. I use free JetPhoto Studio for this. If events can be shown on a map on WeRelate's map page, graves could also be shown on an aerial photo of the cemetery. Even if the detail is not great enough on a map, the coordinates would let visitors find the graves much more easily using a GPS.--Parsa 17:49, 14 March 2009 (EDT)


USGenWeb is no longer with RootsWeb. Some county sites remain there only because the County Coordinator has chosen to use the free space. You will find the majority of the transcriptions are at the county level, and the responsibility of the County Coordinator. --Twigs 12:13, 16 March 2009 (EDT)


While we're talking crazy, it would be great to be able then to incorporate the decreased person's obituary into the site as a cross-reference also.

Some present obituary sites include...

Many other sites out there -- not sure how to link them all and it would take a concerted effort.--BobC 15:50, 15 March 2009 (EDT)

Nice idea but I don't believe we have the time or volunteers to do this.--Beth 20:39, 15 March 2009 (EDT)

I think we have at least a few people interested in this sort of thing. The question is not whether we can do _all_ of the stuff we've been talking about, but whether we can set up a process that people can work at a little at a time (sort of like they do for merging duplicates) that will eventually yield an increase in the usefulness of this site. As for the cemetery transcriptions, almost the whole thing could be automated. Of course, we'd want to do it slowly so that any recruited contributors would be able to ask questions and get a useful response from a contact. --JoshHansen 21:24, 15 March 2009 (EDT)


Mmmm... As an interim measure, I see some sort of cemetery portal in these ideas... jillaine 08:06, 16 March 2009 (EDT)


I think you are riding a very thin line. As a GenWeb county coordinator I know how this works. We spend a huge amount of our time doing what you are trying to politely take. When we are sent a cemetery we take it with the promise that the information is the submitters and can be pulled when they choose to do so. They hold the copyright completely. I assume it is the same anywhere that takes submissions. I did briefly consider trying to find a way to put up the cemeteries I have done, but could not find an example or information on how and where to put it, with it not being connected to my tree.

I know at my state level, counties have had so much trouble with Find-A-Grave. Some people take the photos and information and post under their name making their submission numbers climb to ridiculous totals, all stolen. FAG does remove them if requested, and it is always requested if found. It is our job to keep the submissions safe from this kind of activity.

If you begin this practice, how do you make certain that the same does not happen here? Also, how do you justify taking from sites who volunteer and ask others to volunteer this work for sites that are geared to offer just such information? --Twigs 12:02, 16 March 2009 (EDT)

Twigs, what is it about the above proposals that is "taking"? As Josh pointed out, we would be *asking* transcribers to contribute, not *taking* anything. Please clarify your concern. Thanks. -- jillaine 13:31, 16 March 2009 (EDT)
I agree with Jillaine. Even in my comments above about tying in obituaries, I'm not proposing we steal those existing cemetery and obituary records, but primarily linking the cemetery data and obituary data together, wherever they occur, and creating a template or portal for original research and a method for tying in existing work.
But talking about copyrighted data, I believe the information itself is not copyrighted, just the presentation of it, or whatever original work was put into it; for example, the words on the headstone are not protected copyrighted material, but the art work, photograph of the headstone, drawing of the cemetery, or commentary on the subject and burial site may be. And unless the newspaper obituary is a published article, I think the obit itself becomes public domain and is not a protected work and can be copied or transcribed for use elsewhere (as is commonly done by the obit collection links above). Maybe one of our folks with legal expertise may be able to assist in this question and confirm the specifics of copyright law.
--BobC 14:59, 16 March 2009 (EDT)



I'm not saying you are going to 'steal'. I am saying that is where it will most likely go, not by you but by someone wanting to add a lot of data (hence the FAG reference). But first, if you go to a cemetery and create a list (index) of the graves there, you do indeed hold a copyright on the list/index that you created. You know you can't go and scan or copy a list created by a society and put it up without their express permission. I can assure you they most likely won't allow you to and will come after you if you do. If you transcribe the cemetery (physically go there) you can post them anywhere you want. I said I had thought about posting my own work here so I don't have objections other than the ability to pull material off if it is found to be 'taken' from somewhere else. I don't believe the search would be easy if you were searching for a specific cemetery here, either.

All photos are obviously copyrighted. As far as obits are concerned, there is still a question about them. I don't believe they are copyrighted but have been told they are. I post them, but if asked to remove one, I do so immediately.

If you think about it, cemetery transcriptions are going to be created as time passes in a natural and LEGAL fashion by the addition of each family member of each person working to create this huge database. The "transciption contributions" are not what this is about. At least, not as I understood it. Perhaps someone can clarify the purpose for me if I have it wrong. --Twigs 16:34, 16 March 2009 (EDT)


Hello,

Might I suggest we think a little out of the box here.

I have not seen many cemetery pages organized by their religious, or ethnic background.

We could also have a system were we could add the sources to these cemeteries.

Right now the on line internet community seems more a system of geography, etc.

There are hidden in many books, obits, etc mentions of churches, and cemeteries of old.

I think organizing the Werelate cemetery pages by religious groups, ethnic groups could be a solution.

That way we could avoid the copyright issue since we would not be a "clone" to other cemetery pages.

Suggestions, opinions?

Debbie Freeman ------DFree 17:59, 16 March 2009 (EDT)


I guess my view of genealogical records is different than some people. If I were an artist, professional photographer, author, or musician, I would want protection for my work. I would not put anything online except for lo-res stuff as examples. However, all the work I do in genealogy is really for my descendants and other relatives out there. If I went to a local cemetery, recorded the names, dates, took photos, recorded positions, etc. I suppose I "own" this information. I could sell CDs of the data on ebay. However, if I put it online for all the world to see, I basically feel that it's there for whoever needs it. An article I write with a byline might be a different matter. I think of that as needing a bibliographic citation and acknowledgment of the source author. Photos may be listed as copyrighted and requiring permission, but laws regarding online content are pretty open, and most stuff on the internet is pretty much fair game. This site however is a GFDL site, and it's expected that the material posted is public.
One web site I created had world language lists for each continent. A US government site actually copied the pages for its own use. C'est la vie.
The situation in regards to professional genealogists is of course different, but they probably are not posting all their resources and work online. Some genealogical societies collect data, scans, and photos and sell them on CDs to whoever needs them. That's a way of raising funds. I have no problem with that. - Parsa 14:24, 20 March 2009 (EDT)

I'm am not sure I understand all the ins and outs of this discussion, but the last comment seemed to have some worrisome tones.

I put data on WeRelate and personally I don't care if somebody copies it. Actually, I want them to, since I hope it's good data, and in most cases, I think that means there's one less person copying bad data, one less website propagating incorrect genealogy. However, that said, I think some of the comments about copying data are wrong. The data does belong to me, I have a copyright, and although I could never prove it, that doesn't change the fact that somebody copying it and presenting without attribution (at least to WeRelate since they aren't likely to go through the logs and figure which piece came from where), is still plagi arism. It still happens, so yes, c'est la vie, but condoning it means you don't care about rules, and pretty soon nothing is honored. And the people doing so are showing a total lack of courtesy, and are not sufficiently honoring the people who have paved the way for them to discover their own genealogy. If somebody wants to donate their cemetery transcriptions, that is fine, but to take their work, especially without attribution, is not a good collaborative practice.

All that said, I am not sure I understand the whole concept being discussed here. What would seem useful to me, since WeRelate is organized by Person, would be to find the transcriptions on the Person page it applies to, or if more appropriate, a link to Find A Grave or other site leading you to their transcription. To collect transcriptions en masse by cemetery, duplicating the function of many other websites around the Internet, seems to be somewhat a waste of time and loss of focus. I could see creating a Category for each cemetery, giving directions, visiting hours, etc., and then adding the pages for people buried there to that Category. Then the what links here should allow you to go backwards. Beyond that I think this is going beyond the purpose of WeRelate. --Jrich 15:28, 20 March 2009 (EDT)


Thanks to everybody for being willing to discuss what we ought to do with regard to cemeteries. Here are some thoughts:


Err on the Safe Side of Copyright [4 April 2009]

Jrich is correct that copying and redistributing his WeRelate work without crediting him (or, as he says, at least crediting WeRelate) is a violation of the GFDL license. As for going the other direction: in the United States, creative works are in essence copyrighted by default, if I understand the system correctly. No need for text saying "(C) 2009. by Josh Hansen" or whatever. So, while an argument could be made that people who make their work, such as cemetery transcriptions, publicly available on the web have in essence waived their copyright, I don't know if this is legally the case. (I seem to remember hearing about a lawsuit related to that notion, but I have no clue when/where it was.) So I would only be comfortable putting interment.net or find a grave data on WeRelate if we got the explicit permission of the original author.

I find myself a bit bemused by this discussion on cemeteries. I've been doing genealogy a long time, and I'm also a librarian of 30+ years' experience. And in retirement, I've become heavily involved in editing and publishing. So perhaps I have a wider perspective. The first point to remember is, you can't copyright facts, only their presentation. The information -- the facts -- on the headstones in a cemetery are "public." More than that, the courts have ruled multiple times that "general" cemeteries (i.e., not small family plots on private land) are public places. If you take a photo of a marker and post it online, you have no problem; such an image is not capable of being copyrighted and no one can stop you from doing it. If you publish a book of cemetery transcriptions, that's another matter. You can certainly copyright the book, and that includes the way the transcriptions are arranged, etc. But again, you can't copyright the actual content of the words on the markers. That's not what "copyright" means. Copyright protects your own, personal contribution (writing the book, arranging the material in it) -- and you did not "create" the names and dates on the grave markers. Those are merely facts. Now, copying and posting material from someone's published book of family history is a completely different matter (whether the copyright on the book was registered or not), but that's not what applies here. --mksmith 17:04, 4 April 2009 (EDT)

Two quick observations. I am not competent to get in a detailed conversation about copyright law. However, many cemetery sites add extra information beyond the gravestone transcription, which could be copyrightable. So some sort of mining the Internet for cemetery data may very likely pull in more than just the public domain transcription. (Of course, an interesting question, what if they transcribe the gravestone incorrectly, and you copy it. You are no longer copying a fact, you are copying the transcription.) And I question the comment about not being able to copyright a picture of a gravestone. Several for-pay services have copyright notices on their images of otherwise public domain records, and I would think there could always be some question of photo composition, lighting, etc. that allows one to say they added value and hence there is a copyrightable aspect to a photo. So while one may be able to quote the transcription shown based on a picture, copying the picture may be copyright infringement? --Jrich 17:20, 4 April 2009 (EDT)


Why We Should Bother [20 March 2009]

As for whether we _should_ do this, my view is that WeRelate should be whatever makes it the most useful freely-available, openly-licensed genealogy collaboration site on the Web. Duplication of effort is not a very good criterion in this circumstance; after all, the vast majority of the data on WeRelate is available elsewhere. The thing is that information on sites like interment.net is not available under the GFDL license, nor can it be tightly integrated with other information using wiki-style linking. What if interment.net disappears off the face of the web tomorrow? Then we're left to dig around in old copies on archive.org and to wonder "What now?" Having that data in at least one other live source seems like a practical thing. Plus WeRelate offers an experience that noone else can match. Think of going to your ancestor's Person page, seeing that they were buried in such-and-such cemetery, clicking on the cemetery's Place page, and then not only seeing a list of everyone buried there, but also being able to learn about those people who shared the same space and time as your ancestor. To me that's cool -- really cool! -- and seeing that experience replicated over and over again for different people would make the whole effort worthwhile. But that's just me....


I am not saying this is a bad idea, just in a world of perpetually limited resources, it may not be the best way to make WeRelate more useful. There are plenty of families still not represented in WeRelate and lots of connections not yet made or documented.

Actually, speaking of connections, there is something on WeRelate that is relatively rare on the Internet, and it is what sets WeRelate apart: it uses a shared tree, and actually connects the people into a single consensus of the truth as we know it. As you can tell from its name, that is its purpose. Its name is not GenealogyWarehouse. :-) --Jrich 16:27, 20 March 2009 (EDT)


Summary, and A New Place for This Discussion

So the objective is: increase the quality and quantity of cemetery resources on WeRelate showing full respect for the right of others to not have their work on this site without their permission.

By the way, I created Portal:Cemetery to make a central point for collaboration and discussion regarding this issue. I suggest we move this thread over to the portal talk page. --JoshHansen 16:02, 20 March 2009 (EDT)


Search Results to an editable Page [9 April 2009]

Here's a feature I think I need. Or at least, could use. Have a way to drop the complete results of a search (not ten hits at a time - all of them) into an editable page. I would like to be able to generate a check-list, that I could then use to systematically work through larger domains of pages. Of course, there's a poor man's version of this now - just collect the results page by page with clip-board operations, then edit the results into a form that you find useful. The scale of my problem however - several thousand pages - is well beyond such a drag and drop exercise (I formerly used the "watchlist" as a source of this kind of material, but mine is around 45000 and won't display any more). It would also be highly useful if a couple of different report forms were available (not too many - only enough to facilitate work on the site - not a real "reporting" solution). My preferred initial form would simply be a wiki-ready one-line per found page form (with an appropriate hyperlink to the page in question) with page title and up to 50+/- characters of summary info.

My specific desire is to be able to grab a linear report of my work in the medieval space. I then want to work through that content page by page, performing various checking, validating, and enhancement exercises. Particular searches can be repeated of course, but the results order changes as pages are modified and changed. It's also impractical to try to remember that you're 42 results pages into the search - or to leave a browser window open to a search on a very long-term basis.--Jrm03063 10:49, 16 March 2009 (EDT)


I just made it possible to do this - to list search results in a wiki list format - but it's a little technical so I will send you the details in an email. I can also send it to others if there is interest.--Dallan 13:49, 9 April 2009 (EDT)


Dallan, I would love more info on this! Thank you,--Jennifer (JBS66) 13:51, 9 April 2009 (EDT)


Requested feature for GEDCOM upload [14 April 2009]

Recent conversations about multiple trees, upcoming inability to upload gedcoms into existing trees and tracking all the various things one does, has raised (for me) the idea of having an option at the time of upload to add a category to every page of one's uploaded tree. Something like:

y / n -- Append Category to each generated page?

If yes -- Category to be appended? "Family Tree of Jillaine Smith"

I haven't thought through all the +/- of this, but I'm sure someone will think of something ;-)

-- jillaine 08:51, 17 March 2009 (EDT)

If we do something like that, such a category needs to be hidden from browsers. It would not be useful and probably detrimental to the browsing experience to see dozens of "family tree of X" categories at the bottom of a page.--Amelia 13:46, 22 March 2009 (EDT)
The net result of the discussion about trees awhile ago is that I'm going to try to make trees behave more like categories later this year. Trees won't be added to the page, but you'll be able to browse trees more easily, etc.--Dallan 13:49, 9 April 2009 (EDT)
I would like to see some user category or tag implemented to allow some sort of a personal grouping that FTE can use. Especially with an imported Gedcom, I need a list of all pages created so I can work through it for cleanup. As I'm done with a page I would remove it from the tree/category/tag whatever we call it. I periodically have other needs (less pressing) to have a way to create a list of pages for my purposes that would have no use to the general user. --Jlanoux 10:13, 10 April 2009 (EDT)
That's a good point. I'll try to keep it in mind as I think about the new tree "categories".--Dallan 22:29, 14 April 2009 (EDT)

Help in renaming image [18 March 2009]

Hello,

I made a small mistake. Help would be very appreciated.

Could someone tell me how to contact the person reviewing the uploaded images. Or tell me how to rename the image title? I tried to locate that on the image page, like you can on other pages. It does not seem to exist. I titled the image "correct version of Miles Prigmore Letter 1" for page 1. I meant to title it "Olson, Leta. Correct version of Miles Prigmore Letter 1"

Thank You, Debbie Freeman


DFree 21:05, 17 March 2009 (EDT)

Hi Debbie, There is no available option to rename an image. You may delete the image and reupload; then give the image the correct name.--Beth 08:50, 18 March 2009 (EDT)


Do we have this sort of help page? [9 April 2009]

Is there a place on this site where I can go to read a concise definition and difference between 'articles', categories', 'shared research pages' 'name in place pages' etc and also have links to one example of each type of page? We already have how-to create these pages, but I still don't have a good understanding of when to use what. I'd like to see examples and definitions all in one spot for easy comparison. --Janiejac 09:16, 18 March 2009 (EDT)

I found it here: Help:Page_titles#Titles_of_specific_types_of_pages --Janiejac 22:23, 22 March 2009 (EDT)
Janie, you may also want to look at a little help page I wrote for myself here: User:Jillaine/Understanding WeRelate. jillaine 10:30, 8 April 2009 (EDT)
And remember that if you figure something out that's not obvious in the help pages, please be bold and fix them! :-) Thank you--Dallan 13:49, 9 April 2009 (EDT)

Wiki page for a Genealogy Organization? [9 April 2009]

What would be the best type of wiki page for a genealogy organization? I'd like to create a wiki page for the Gudbrandsdal Laget. Should that be a portal or maybe an "other" page of some sort?--Romsaas 22:20, 25 March 2009 (EDT)
Maybe I've answered my own question by searching and finding the "Other articles" category. "Other articles -- enter a descriptive title: anything you wish related to family"--Romsaas 22:25, 25 March 2009 (EDT) history.


We strongly encourage other non-profit genealogy organizations to create pages for themselves and their resources here! Over time I hope we can figure out WeRelate can be used as one way to help genealogy organizations to connect with their members and potential members.--Dallan 13:49, 9 April 2009 (EDT)


Drop Down Place Function Frustration [9 April 2009]

I'm new to WeRelate and have become quite frustrated with the drop down place function. It is supposed to work as follows - Type the name of the town or village and then type a comma (,). A drop down menu will appear listing all of the cities with this name, worldwide, along with the county, state (province), and country of each. Click on the place where your ancestor was born. I find that sometimes the drop down menu won't appear when it should or if it does and I select my location nothing happens or if the menu is too long to be all seen if I try to scroll down it disappears. Now I just type in everything to avoid the frustration.--HLJ411 17:10, 27 March 2009 (EDT)--Beth 20:06, 27 March 2009 (EDT)


I concur with the new user's frustration with the drop down menu. I've figured out a work-around, but it *is* annoying that it doesn't work right. It might be a PC vs. Mac problem. When the drop-down menu does appear, I expect it to work as follows:
  • I use my arrow keys (or my mouse) to move down to the place of choice.
  • I hit RETURN or double-click to select it
  • The full selection fills out the field
  • I can then click on the next field or press TAB to the next field
Instead, hitting RETURN or double-click on selected place does NOT fill out the field; RETURN saves the page without the field being filled in; double-click does nothing.
What I have found that works is using the arrow keys til the selection is highlighted, then pressing TAB to go to the next field. It's not at all intuitive (and I forget to do it a lot), but it does work.
I'm on a mac. I use firefox.
-- jillaine 07:56, 28 March 2009 (EDT)

The auto-complete has some problems; I'll move it up higher in the priority list.--Dallan 14:43, 9 April 2009 (EDT)


Notes taken while editing new upload RE small frustrations [14 April 2009]

I took notes of areas that either didn't work as I expected or could use some fine tuning. Perhaps some of these could find their way to Dallan's to-do list:

  1. When saving a page, I would hope the default check mark on the first listed tree can be removed. I sometimes forget to remove it.
  2. When I'm editing a family page and want to add a child, I see the window to fill in and do so, then click on find/add. It goes to another find/add page window where I have to retype in the same info again but adding more detail and click on find/add again. It seems like it should remember what I typed in the first window when going to that second 'details' window to eliminate retyping. (I finally learned not to type in the first window but let's eliminate the confusion!)
  3. When looking at family page, the children are not identified by ID#. I've found I need that info and have to go to each separate child's person page to find their ID#. Should be easy to list it beside their names on the family page.
  4. The list of children without birth dates look like they are in correct order as input when first seen, but they don't stay in that order once you begin clicking on the children and editing their pages. They get rearranged but shouldn't since I didn't add birth dates.
  5. Why aren't the search results for MySources in alpha order? Without some order, it makes scrolling thru the many sources more difficult.
  6. I would like some way to add a category to everyone in one of my trees. Seems like I saw some comment about this earlier this this would cause a problem, but it sure would be helpful if it could be done.

Goal is 'drop-dead easy'! Not quite there yet, but on our way.--Janiejac 11:22, 30 March 2009 (EDT)


  1. I'll add not checking the default tree but prompting if none of the trees are checked to the todo list
  2. The plan is to make adding children easier.
  3. You can "hover" your mouse over the child link to see the ID number
  4. Sorting children better is on the todo list
  5. You can put search results in alpha order by clicking on the "Exact match" checkbox.

Still a ways to go, but we're getting there a little bit a a time. :-) --Dallan 14:43, 9 April 2009 (EDT)


I have a question on the default tree item. Is is possible to add a field in preferences that asks which tree you want to be default, with none also being an option? I find that I go through times when I am working exclusively on one tree, and it would be really handy not to have to remember to click on that tree's checkbox each time. --Jennifer (JBS66) 14:49, 9 April 2009 (EDT)


Oh, please don't add a prompt if there's no tree chosen!! That would drive me (and anyone else editing for the community rather than for one's self) far far crazier than having the default checked.--Amelia 00:11, 10 April 2009 (EDT)


Ok, we'll go with a preference for the default tree, with none being an option (and no prompting).--Dallan 22:31, 14 April 2009 (EDT)


Frustrations with attempting to create subpages [4 April 2009]

I'm in the middle of creating a page (by hand, not via GEDCOM) for William H. Smith. I have a lot of material, so I want to put some of it on linked subpages, especially a couple of "brick wall" problems that involve extended discussion. At Wikipedia, creating a subpage is easy: You go to the "parent" page, type a slash and the desired subpage name in your browser's title bar, click it and go. You're there! But in WeRelate's implementation of the wiki software, there appears to be a complication. When I type "/Problem of William H. Smith" in the browser title bar following the address for the parent page, the new, empty page appears -- but when I've typed in a bunch of text and try to save the page, I get a message, "The page title does not have an ID; please create a page with an ID using Add page." And I'm not allowed to save the subpage.

But the message is inaccurate. I'm not creating a new Person page, only a subpage. The address in the browser title bar is <http://www.werelate.org/wiki/Person:William_Smith_(640)/Problem_of_William_H._Smith>, and the ID number is in there for the person on the parent page. And why does the message only appear when I've edited the subpage -- but not when I first created it? And if I use the "Add page" link, what I'm trying to create won't be a subpage, it will be an entirely separate, unconnected page -- and it's not meant to be a "Person" page in any case.

The whole ID number thing seems uncommonly awkward (though I certainly understand why it's necessary, or some mechanism like it), and I wonder if there's a design conflict that wasn't resolved? --mksmith 16:40, 4 April 2009 (EDT)

MKS, while it is possible to create subpages for pages in the article names space, and perhaps other namespaces (such as user namespace where I know you can do this), the system is set such that this can not be done for pages in the person namespace. I suspect the reason for that is because there's a requirement for every page in namespace to have an index number. That apparently includes subpages---which is why you get the warnings you do. I suspect that even if you try to invent an index number, it won't recognize it. I seem to recall some discussion of that, but I don't know that this is going to be changed anytime soon. I'd recommend simply creating an appropriately titled page in article namespace, and linking to it. I think that amounts to the same thing, just not a "subpage" per se.
There are probably many things that different people find cumbersome. Perhaps the numbered indexing system is one of them. I'll admit I think that things are going to get rather interesting when we start having index numbers such as "John Walker (43560)" and the like. (Currently there are 204 John Walkers, though some are probably duplicates.) However, even though this site is still in Beta development, I suspect that changing the index system would not be practical at this late date. Its much too embedded in the process. And you do need some system for telling apart different people by the same name. Other sites use a date convention (e.g., "John Walker (1705-1783)" The problem with that convention is that it doesn't give you a unique ID. Theoretically, there could be more than one John Walkers with the same DOB-DOD pair. Q 17:02, 4 April 2009 (EDT)
Quolla6 and I had a bit of an "edit conflict" - trying to save our response at the same time!
It's my understanding that subpages cannot be created for Person or Family pages (which I see is counter to this help page, which errs in describing how to "create subpages of my person and family pages") Another talk page here states: "Person pages can't have subpages because they'd be difficult to move around as a Person page gets renamed/merged". To my knowledge, Articles are the only pages that allow subpages.
My suggestion would be that MySources may suit your needs well. Then, you can add the links to your MySource into your Person or Family page.--Jennifer (JBS66) 17:10, 4 April 2009 (EDT)
Thanks very much, guys! I had wondered about casting this little essay as an "article," but I guess I was interpreting that term to mean topics of general interest -- methodology and the like. Anyway, I've created the thing as The Problem of William H. Smith, so take a look and see if you think it fits there all right.
Had that same hesitation once myself. But speaking as someone who does this quite a bit, that seems to be a tacitly approved use of Article space. Just be sure you have a good way to keep track of articles you create, either using links or Categories. Otherwise you may find that you can't get back to that article again, because you don't quite remember what you called it. Or even end up writing it twice because you don't remember you wrote it the first time. (Really! Do enough work here and you'll find how easy it is to forget something you wrote two weeks ago.) For myself, I do this by using a series of "master Maps", that organize my input. One being on my users page---not pretty but functional. I also use categories, but not very consistent about that, except where its built into a template I use routinely. easier to create a page of links to key articles. What I like to think is a good example of this is found here though its probably a bit more elaborate than you'd problably like to bother with. Q 19:20, 4 April 2009 (EDT).
Yes, I ran into the forgetfulness problem a few years ago on Wikipedia. I've done around thirty articles there from scratch (or from a pathetic stub), and have materially added to maybe three times that many. I finally put a list of "completed articles" on my User page so I could remember what I had finished with and what was still being worked on. I like your project page, . . . though I'm pretty much a text person, being artistically challenged. But I shall have to keep an eye on your Southwest Virginia activities, since my family runneth over with Hatfield, Gastineau, and Ashcraft lines from those parts. --mksmith 20:48, 4 April 2009 (EDT)
Jennifer, my understanding was that MySources are like any other "sources," except that they aren't generally available or accessible, and probably not of much interest to others. For instance, my late grandmother left me a large stack of manuscript notes she made back in the 1930s and '40s, the result of an apparently huge amount of correspondence she carried on with often distant family members. I don't have have her actual correspondence -- just the notes that resulted -- so I can't really do a proper citation, except to "Cordelia's notes." That's what I was thinking of as a classic MySource.
I personally think that's the highest and best use of "MySource"---a repository of things that can't be readily consulted during verification and validation---that is, they are not published sources that can be revisited---things like your grandmothers notes. Dallan tends to view them as something more closely akin to family bible records. You might want to check the Portal Page for MySource (Portal:MySource) and see how it views them. Q 21:17, 4 April 2009 (EDT)
I don't object to the use of ID numbers, you understand. You have to have some sort of distinguishing point in the name, I know that. And I'll be curious to see what happens (in terms of "precedence") when merging of Person pages becomes common. I can imagine sitting down to do some work on "John Smith (999)" and discovering it no longer exists -- not knowing it's been merged with "John Smith (567)"! There will need to be a bread-crumb trail or something left behind so the new location of the merged information can be found, I think. --mksmith 17:55, 4 April 2009 (EDT)
There will be breadcrumbs. The old pages are never destroyed, but contain a pointer to the new page. If you try to go to John Smith (999) you will be redirected to John Smith (567). It's pretty painless. --Jrich 18:21, 4 April 2009 (EDT)

Seeking feedback on Categories for Organizing ARTICLE namespace [6 April 2009]

Inspired by a past comment by Dallan as well as the new Portals, I set out to see what it might take to Categorize the pages that are in the "ARTICLE" namespace. My idea for how to do this includes the following steps:

  1. Review what's already in the Article namespace
  2. Based on what's found there, identify some major categories. I've started this so far and gotten through about 430 pages (out of over 1700).
  3. Create an index of Categories for these articles. This I've begun here.
  4. Ask "power users" to review #3 and provide feedback. This is the purpose of THIS post. Please review what I've started so far and provide feedback on the category names through the Article Project Talk page.
  5. As we approach consensus (or something close to it, if that's at all possible), convert the Article Project page to something that enables volunteers to take on particular sections and work their way through it.
  6. Draft help language for Help:Article to help people apply categories as they're creating/editing them.
  7. Establish a volunteer "maintenance" project that checks newly added Article pages and categorizes them.

Your help and feedback is appreciated. See you over at the Talk page of the Article Project.

Thanks.

-- jillaine 22:56, 4 April 2009 (EDT)|Jillaine

I've posted a lengthy series of thoughts on the talk page there about your list. Possibly too lengthy for a newbie on WeRelate. . . . --mksmith 14:00, 5 April 2009 (EDT)

I should not have included the phrase "power users" (although mksmith, I'd consider you one given your experience at wikipedia). I'll take comments from anyone. Thanks. jillaine 08:08, 6 April 2009 (EDT)


New Surname Namespace [14 April 2009]

I've just "discovered" the new Surname space. I note that when surnames are added to an article page, they now link not to the category page for that surname but to a Surname PAGE for that surname... which is empty.

As someone who had started to use more intentionally the category pages, I find this change a bit abrupt and not sure what to do with it.

Please advise:

  1. What is the intended use of this new namespace and surname pages?
  2. How, if at all, will the surname categories relate to/be connected with these surname pages?

Thanks.

jillaine 09:57, 7 April 2009 (EDT)


Ironically I found the same thing the other day. Because I added surname information of a general nature unrelated to my family on the category page, should I now move it to the surname page?--BobC 10:04, 7 April 2009 (EDT)


This isn't new. Articles and sources that have a Surname(s) covered field link back to the Surname space. Automatic categories are still there - at the bottom for articles. What is really handy about the surname space is going to what links here. From that page you can see all sources and articles where that surname has been specifically referenced. This particular feature, however, is relatively new. I noticed that it doesn't seem to take effect in sources until the source page is opened and then saved again.

I think the Surname space also acts as a programming help for identifying similar sounding/spelled names in searches. Dallan might have to correct me on this one! --Jennifer (JBS66) 10:09, 7 April 2009 (EDT)


Ugh. Is this yet another case of semi-newbie not paying close attention? You mean these links have ALWAYS gone to a surname article page? I could have sworn they used to go to the Category page for that surname. Excuse me if you can't understand my speaking; my foot is crammed down my throat.
I don't find the "What links here" to be particularly helpful because there are so many pages. It would be far more useful if I had a drop down menu to filter the kinds of pages (namespaces) that link to a given page.
Frankly, I'd find it far more helpful if the surnames went to the category page. A surname page seems duplicative to me. When would you edit the Surname page vs the Category page?
jillaine 11:09, 7 April 2009 (EDT)

Asking Dallan's input: Where should we as users add generic surname information not directly related (or not yet proven to show connection) to our family lines -- in the Category page or the Surname page?
For example, if I have a general collection of surname data on the Marquez name that I can't fit into the family I am researching, should I add it to the Surname:Marquez page or to the Category:Marquez surname page? What is your preference?
--BobC 13:39, 7 April 2009 (EDT)

As Jennifer says, Surname pages are used by the search engine to provide lists of similarly-spelled names it should include in searches. When we started the website I thought that people would use them to post family information and add additional related names. But it was one of those ideas that didn't really "stick". Most people have been using categories or creating articles. I'd recommend putting your information on the category page if there's not a lot of it, or creating an article for it.--Dallan 14:43, 9 April 2009 (EDT)


Dallan,

If you recommend the category page over the surname namespace page then wouldn't it therefore follow that the surname links on article pages should go to the category pages?

-- jillaine 15:52, 10 April 2009 (EDT)

Good point. I'll add that to my todo list.--Dallan 22:59, 14 April 2009 (EDT)

Proposed change to how tree deletions are handled [18 April 2009]

Now that we're merging trees together, if someone deletes their tree, it can create holes in others' trees unless the other users are diligent about watching the new pages they're now connected to. I like the idea of allowing people to remove their contributions in case they decide to leave, but having creating holes in others' trees seems to go against the goal of WeRelate.

Here is a proposal for changing what pages get deleted when you delete your tree: people in your tree that others are watching will not be removed (as usual). In addition, spouses, children, and ancestors of those people, as well as spouses and children of the ancestors, also will not be removed.

In addition, deleted pages may be restored at the request of another user. Or perhaps we should allow any user to restore deleted pages.

Comments?--Dallan 22:25, 8 April 2009 (EDT)


You many want to look at the discussion at User_talk:Seymour_t pertaining to loss of some of my Cherokee ancestral lines that I thought were deleted by Seymour_t. Not really sure if that was in fact the case or if was a programming fault.--BobC 22:46, 8 April 2009 (EDT)

The discussion you reference is exactly type of thing that the above proposal is trying to address. (And yes, it appears that Seymore_t deleted their tree. It's not a programming fault.) So please think about the situation you experienced and whether keeping spouses, children, and ancestors (along with ancestors' spouses and children) of your watched pages would satisfy your needs. Alternatively we could say that you can't delete your tree once you upload it, but I think that's going too far. I'm open to other suggestions though.--Dallan 13:10, 9 April 2009 (EDT)

Dallan, it was my understanding that once you upload a contribution, it's no longer "yours." It now belongs to the WeRelate community. Since you've made the contribution in the (presumed) knowledge that it was being offered for everyone's use, you ought not to be allowed to take your ball and go home. If you decide to opt out of WeRelate, any uploads that you brought to the party, remain at the party. --mksmith 14:38, 9 April 2009 (EDT)

Thank you for addressing it again, Dallan. I'll break down my recommendation into separate groups below:
  • Individuals & Families on Watch List: Yes, I agree that people in someone else's tree that I am watching should not be removed. The removal action they perform should only remove their User-name from that person or family if they are being watched by me or someone else.
  • Immediate family not on my Watch List: Additionally, the immediate family (spouses, children, parents and siblings of those people) should not be removed automatically, even if I am not watching them.
  • Ancestors & Collateral Relatives not on my Watch List: I would suggest, if possible program-wise, that a warning be delivered to me for other ancestors of those individuals, as well as spouses and children of the ancestors, that they will be removed/deleted within a certain time-period (say, ten days) if no action is taken by me to add them to my Watchlist. Many times these collateral relatives are related to my Watch List line by marriage, and that process would give me an option of whether of not I want to save and watch the spouse's immediate family or watch their extended family as well.
  • Restoration of Deleted Pages: Deleted pages should be able to be restored at the request of any other user if they are willing to add the person or family to their Watch List.
Does that make sense?--BobC 14:05, 9 April 2009 (EDT)

Dallan, you may want to consider having an "update/revise tree" option, when someone wants to include additional lines/people to their tree by updating an overlapping, but revised gedcom. Currently, when you try to upload a gedcom with additional lines, people, etc., you get an "apparent duplicate merge" message in most circumstances, but since you've got the new gedcom review process in place, why not allow duplicate merge gedcoms, allow the duplicates to be merged in the review process? I had a couple of families that I entered small gencoms, and tried to upload more complete versions, but since I got the "apparent duplicate merge" message, I had to delete the tree and re-import the updated gedcom, which also creates an additional problem of re-numbering the people that were deleted in the original tree (for instance, the deleted John Lackey(1), becomes John Lackey(2)). Allowing the "revision/updating" of trees by importing an enlarged gedcom would resolve this situation. You could also make these types of gedcom updating situations mandatory for a second review by an admin, to make sure that the families were merged correctly.--Delijim 13:36, 18 April 2009 (EDT)


Could you comment on the new GEDCOM Re-uploads section I just added to the bottom of this page? I want the upcoming gedcom re-upload process to handle the "update/revise tree" idea that you mention, with the additional feature that the system will match people in your new gedcom to the wiki pages assigned to the people in the previously-uploaded gedcom that you're replacing. It sounds like you're saying that you'd want a new gedcom to replace possibly multiple previous gedcom's?--Dallan 14:46, 24 April 2009 (EDT)


Edit menu [20 April 2009]

When you bring up a page to edit, an "edit menu bar" appears above the edit text box. The edit bar is "iconized", with a large "B" indicating "add bold format", and an italicized capital "I", indicating "add italics formating" etc. The third element is an "underlined "Ab", which usually means "Underline". Instead, what you get is square brackets around the contained text---which creates a link to an "article namespace" article, rather than underline. This may be intentional, but since it flies in the face of the expected "underline", it may not be the best choice for this function---especially coming after the "B" and "I" which do follow the usual formating convention. If the intent is to insert square brackets, perhaps [[]] would be a better choice. If the intent is to provide a quick underlining format, it doesn't do that. Q 10:52, 9 April 2009 (EDT)

I think the clue the original designer expected you to notice is that the two letters and the underline are all in blue, . . . like an unvisited hyperlink. I agree, it was a bad design decision. But Dallan obviously took the edit bar from Wikipedia -- or else it comes with the wiki software these days, I don't know. When I first started writing stuff at Wikipedia, there was no edit bar; you just had to remember all the coding. And the bar you'll find at Wikipedia now is about three times as long as this one, with superscript, subscript, and various tools for mathematics formatting. You're pretty good at graphics design (I've poked around your user page . . .), so you might consider designing some WeRelate-specific buttons you think would be useful. --mksmith 14:52, 9 April 2009 (EDT)
Ok, total escaped me. As you say, probably not a good design decision. Not difficult to create an alternative---as . Getting the colors right (to match the existing) would be relatively easy. Getting it to match the size and square format might be a bit more difficult. That's probably why they went the way the did---space considerations.

Here's an improved version: . The "fade" in the background is not quite right, doubt that the letters can be inserted. Don't know that its worth fixing though.---either this example, or replacing the current icon. What I really was looking for was a quick way to insert underlining---handy for setting hierarchical text labels, without having to clutter up the TOC with third and fourth order headings.

Well, that part's easy. Since wiki can accept most HTML tags, just use <u> and </u> for underlining. But your double-square-bracket button would be good for "wikify text." --mksmith 22:33, 9 April 2009 (EDT)
I was basically trying to make better use of the existing tools. I don't routinely use underlying, so when I found a use for it, thought I'd try the existing tools rather than look up the html. As you point out, its easy enough to do manually, and all the edit button would do (if it did what I thought it would) would be to insert the HTML code. Since relatively few folks are working on narrative text on these pages (at least on the person pages) its probably not a need that needs to be met. Eventually Dallan will upgrade the wikimedia, and this will probably come along with the upgrade. Q 08:50, 10 April 2009 (EDT)

Now that I think of it, is there anyway to suppress third and fourth order headings so that they still appear in the text, but not in the TOC? Q 18:32, 9 April 2009 (EDT)

You can supress the entire TOC with __NOTOC__, but I don't know how to suppress the third and fourth order headings.

The Ab icon means "internal link". It's probably not an ideal picture; it's standard on wikipedia-based wiki's though.--Dallan 14:43, 9 April 2009 (EDT)


A long time ago, there was some discussion about making this internal link button more full-featured rather than requiring that one remember the exact page title they want to link to, with all the ins and outs of punctuation and capitalization that can redden an otherwise valid link. I was wondering is this is still on the list somewhere?

Ideally, it would do something along the lines of this: when you press the button, you would get a search window where you select a namespace and enter your criteria. The search results works just like a typical search. When you "select" the desired object, the fully completed link is inserted for you into the text.

I'd also find that very handy. I'm constantly inserting links to existing person articles, and have to open up another window, navigate to the search function, find the person, then copy the article title, and pass it back to the original page. It would be nice if the search could be done from the edit menu, and the page title automatically be inserted. Q 13:48, 10 April 2009 (EDT)

I agree the icon is misleading. Even moving it away from the bold and italic in the list would help, since normally the B, I, and U are such a tightly coupled triplet in editing. It is natural to assume it means underline when it immediately follows B and I. But given a vote, I, too, would prefer to see a better icon used. --Jrich 09:01, 10 April 2009 (EDT)

Thanks! I've updated the link icon (you'll probably need to force-refresh the page in your browser to see the new icon). Also, here is a blank that you can use in case you want to modify any of the other button icons.
As for having the link icon open a search window, I could have it open a search window, or I could have it open a little pop-up autocomplete window. I agree it would be handy. Any thoughts on which approach (search vs. autocomplete) would be preferable?--Dallan 12:17, 15 April 2009 (EDT)

New Portal - Analyzing Sources [17 April 2009]

Hello,

I have a suggestion.

I would like to suggest we create a new Portal or new section on Werelate called "Analyzing Sources".

I had thought It existed as a Portal, or WeRelate Section already.

If I have missed it could someone point it out to me.

There seem to be scattered throughout Werelate already exiting material and many discussions which could be used for this new portal.

My number one complaint with the new "internet based" genealogy is a person has access to the sources, but many times that person does not have the classroom, or group instruction, or years of experience on how, on why to use the source they access.

Examples could be "Why not use Jane Doe GEDCOM as a source?" or "Why we use the 1880 or 1850 census" or "why use land records" etc. i.e what is important about these sources, compared to other sources.

WeRelate could fill in a badly needed missing educational section bridging the gap.

Thought, Suggestions?

Debbie Freeman


See: Portal:Source

--DFree 14:49, 15 April 2009 (EDT)


Hello Quolla6,

Thank You for the suggestion. I had already looked on WeRelate and the Source Portal. It does not exist. I guess I am not making much sense right now (sick, and on medication does that to you). I will create an Article for the WeRelate Source portal later next week so I can give an example.

Debbie Freeman --DFree 16:38, 15 April 2009 (EDT)


Hello,

I created the article. I could not put it in the Source Portal. It looks like you cannot put in articles in the Source Portal. I believe it is listed under the Article section of WeRelate.

Thoughts, Suggestions, corrections, etc Gratefully accepted.

Debbie Freeman --DFree 22:58, 15 April 2009 (EDT)

I'm confused. DFree, please provide the link to your article. Can you not utilize Portal:Source and identify a link to your related FAQs article in it? --BobC 8:13, 16 April 2009 (EDT)

I appears that the Source and Image portals are still protected pages, editable only by administrators. This was likely an oversight. I will unprotect them for the time being. I know there was some previous discussion about all of the Portal pages being protected, don't know the status of that, however. Debbie, can you possible post the link to your article here, first, then we can decide the best place for it? Thank you!--Volunteer Admin - Jennifer (JBS66) 08:21, 16 April 2009 (EDT)


http://www.werelate.org/wiki/Analyzing_your_Genealogical_Sources

Debbie Freeman --DFree 12:32, 16 April 2009 (EDT)


I've reviewed your article and made some suggestions on the article's talk page.--BobC 07:25, 17 April 2009 (EDT)

Thank You BobC for reviewing the article. I really appreciate it.--DFree 12:25, 17 April 2009 (EDT) ---


Ancestycom mailing list on Rootsweb [22 April 2009]

For any of you that are interested in joining, I have added a new mailiing list on Rootsweb to discuss topics relating to the subscription service, Ancestry.com. If you would like to subscribe follow the instructions in this link: [5]. Thanks. --Beth 23:02, 16 April 2009 (EDT)

Unfortunately Ancestry has decided to remove this list from Rootsweb. This message was posted today on the Ancestrycom mailing list:


Dear Ancestrycom List Members,

We wanted to let you know that in the next coming days the recently created Ancestrycom mailing list will be removed from the site. We definitely don't want to discourage discussion about the Ancestry.com website, but currently there are two very active message boards dedicated to the discussion of Ancestry.com. One is called Ancestry Site Comments (mainly used for general comments about the site) and the other is called Ancestry Improvements (mainly used to submit suggested improvements and site feedback).


Ancestry Site Comments

On Ancestry.com - http://boards.ancestry.com/topics.ancestry.ancsite/mb.ashx

On RootsWeb.com - http://boards.rootsweb.com/topics.ancestry.ancsite/mb.ashx


Ancestry Improvements

On Ancestry.com - http://boards.ancestry.com/topics.ancestry.ancimprovements/mb.ashx

On RootsWeb.com - http://boards.rootsweb.com/topics.ancestry.ancimprovements/mb.ashx


Our Product Managers and other Ancestry.com staff are active on these message boards and try to visit them regularly to read the recent posts. We are worried that with an additional outlet for discussion about Ancestry.com we may not have enough staff to stay on top of things and may miss some of the comments that would have been made to the message boards. We want to make sure that we can understand everyone's feedback about the site and can offer our comments when it is helpful and keeping it focused on these two message boards will help with that.


Thanks in advance for your understanding as we try to use these messages boards instead of this new mailing list. We understand that some of you prefer to use mailing lists rather than the message boards and hope that this doesn't inconvenience you too much.

Sincerely,

Anna

Anna Fechter Community Operations Manager The Generations Network

A 360 W 4800 N Provo, UT 84604 ancestry.com | genealogy.com | myfamily.com | rootsweb.com | family tree maker

--Beth 20:32, 20 April 2009 (EDT)


Beth

There are many other hosting venues for email lists. I've found "Google Groups" to be general effective, though like all mailing list hosts (Including Rootsweb), not without its problems. Q 20:39, 20 April 2009 (EDT)


Thanks Bill, I will wait an analyze the fallout and then decide. I am familiar with Rootsweb but not with the administration of lists on other sites. --Beth 20:45, 20 April 2009 (EDT)


Let me know if I can help. I'm familiar with Google Groups, and have helped others start mailing lists in that venue. Q 21:40, 20 April 2009 (EDT)


I have created a new Ancestry group: [6]--Beth 12:09, 21 April 2009 (EDT)


Out of curiosity, why the separate list? What *is* the purpose of this alternative discussion group about Ancestry.com? jillaine 16:28, 21 April 2009 (EDT)
Not to "not answer" your question, but in 24 hours the list had over 40 members. Would appear there is a need being met. While my Ancstry subscriptioin is an important resource for me, I will observe that Ancestry does not have the best track record in dealing with end user dis-satisfaction. The experience Beth had in trying to set this up through a Rootsweb mailing list is simply another instance of a rather ham-fisted approach on the part of Ancestry management. Its why I pesonally won't create another mailing list that passes through Ancestry. Q 19:45, 21 April 2009 (EDT)

Jillaine, I wished to have a mailing list for questions regarding Ancestry. There was no mailing list before; there are message boards. Message boards and mailing ilsts are different.--Beth 10:49, 22 April 2009 (EDT)


GEDCOM Re-uploads [2 May 2009]

In preparation for the ability to re-upload a GEDCOM without deleting it first, which will hopefully be in place sometime next month, the system currently requires that every gedcom be uploaded into a new tree. The issue is that during gedcom re-upload the system needs to compare your current gedcom to a previously-uploaded gedcom so that it can assign the same wiki pages to the people in your new gedcom as were assigned to the people in your previous gedcom. The easiest way to approach this is to require that each tree contain only a single gedcom, and that a new gedcom upload replace the previous gedcom for the tree. That way the system only has to read the most-recent previous gedcom uploaded for the tree to assign wiki pages to the people in the newly-uploaded gedcom.

Another feature of the proposed GEDCOM re-upload feature is to compare people in your newly-uploaded GEDCOM with the people in the previously-uploaded GEDCOM being replaced. Anyone that differs will be listed in the "Updates" tab in the GEDCOM Review program, so that you'll know which wiki pages you might want to update. You'll then be able to update the wiki pages just like you update matching families today.

I've noticed that a few people have uploaded multiple gedcoms into the same trees in the past, but I thought that I would start with the simple approach - require that each tree contain just one gedcom - and see if anyone said anything. So now I'm looking for suggestions by people who want to upload multiple gedcom's into the same tree; how we can best meet your needs?

Here's one idea: we could allow you to upload multiple gedcom's into the same tree, but you would have to specify whether

  • the newly-uploaded gedcom replaced one of the previously-uploaded gedcoms, in which case we would read the gedcom being replaced to assign wiki pages to the people in the newly-uploaded gedcom,
  • or if it was an add-on gedcom that did not replace any of the previously-uploaded gedcoms, in which case we would treat it like a gedcom loaded into a brand new tree -- new wiki pages would generally be created for people in the gedcom.

Would this idea meet everyone's needs? Is there something else that would be better?--Dallan 14:25, 24 April 2009 (EDT)

Given that we strongly encourage (both overtly and through the intentionally burdensome process) the upload of small gedcoms, I think it's a usability disaster to have any expectation that someone will want to update with a gedcom that is identical (in the people it covers) to a previous one. I just uploaded one line last week, and I already really don't remember what ancestor I picked and how many generations down it went. I don't know what "replace" means in the context you're using it, but it sounds suspiciously like the system is going to drop from the tree or delete anyone not in the second upload, which is not going to be desirable. I would envision a process that works almost exactly like the current upload process, except that the merges are perhaps a little more automated, and it matches your mysources. That's independent of the contents of any particular tree/gedcom. But if you can drop the one gedcom per tree rule, I'd much appreciate it. My "trees" are getting increasingly meaningless. --Amelia 12:26, 25 April 2009 (EDT)
My first thought was similar to yours, Amelia. No way am I going to upload a massive GEDCOM which would then take me forever to tidy up. I'm doing this in small, bite-sized chunks, partly because I expected it to be a learning process (which it has been). The upload I'm currently working on goes back a limited number of generations, and I had anticipated uploading a bunch of the earlier generations later on and attaching to the current group. These are the same family, so I would expect them to be part of the same "tree." Requiring that the later group be labeled as being a different tree is doable, I guess, but it would also be awkward -- even though I understand Dallan's technical concerns.
Confession: I have trouble thinking of the "tree" label as equivalent to a tree in the usual genealogical sense -- as a lineage. The use of "tree" on WeRelate is more what I would call a "focus group," since it can include pages from any namespace -- not just people, but places and sources and anything else you care to include in it. And certain individuals logically belong to more than one tree. I have a large number of FRAKES people, and a larger number of HATFIELDs, and the FRAKES girl and the HATFIELD guy who married are naturally members of both trees.
Which suggests that it would be useful to be able to mass-rename members of a tree after the upload/import process is completed. If I upload another couple hundred people who are members of my FRAKES family (and all their associates and in-laws), and they are required to be members of a differently-named tree during the import for technical reasons, it would be nice -- once I have them all ready for prime time on WeRelate -- to be able to go back and say: "Move this person and all his/her ancestors [and maybe all their spouses and children] from the 'Temporary Upload' tree to the FRAKES tree." Actually, it would be nice to be able to do that, or something similar, even if it didn't involve a GEDCOM upload. --Mike (mksmith) 10:32, 27 April 2009 (EDT)
When I first came to WeRelate I uploaded a small tree just for the experience and to learn how it worked. Over time I have edited that tree and would like to upload the edits. I want to put them in the same tree, not a new tree. I would hope an upload to an existing tree would be able to determine the dif between what is now on WeRelate and what is in my tree and let me have the option to include only the differences I indicate as acceptable. Similar to the merge process where I check mark what I want merged and leave unchecked those items that are identical. I don't want to upload identical persons because I don't want to have to reformat the notes. (But will the program know if I have ADDED to the notes and should check the edited note for upload?)
You spoke of a new upload 'replacing' an old tree. That would create problems if other folks have added to or edited some of the pages on the tree that I'm planning to upload into. So I'm hoping you didn't mean the old tree would be replaced. I just need to merge the new info into it. Is this going to be possible?
We've been encouraged to upload only small segments of our trees and I would expect to be able to add onto those trees; not get a new tree everytime I add another branch or even an edit to an old branch. I already have too many small trees to remember! And I added a few folks manually and they got somehow accidently added to the wrong tree! In the pando sense, it doesn't really matter what 'tree' they are in, does it! But in searching through one of 'my trees', I was surprised to find them there.
But I hope to upload some folks that aren't my line at all, and in that case, I would expect to put them in a new tree - so not everything I upload goes into the same tree. --Janiejac 15:10, 27 April 2009 (EDT)
I have a sinus headache and maybe that is contributing to my confusion regarding the gedcom upload. The way I envisioned the gedcom upload to work is that I would upload a gedcom and WeRelate would recognize the trees that had matched pages and ask me which tree I preferred. I would select the tree. By merge I mean that I may have duplicate pages in the gedcom, but the page on WeRelate may already be Wikinized, so I expected to have the ability to compare the pages similar to the duplicate pages merge process. I certainly would not want to replace pages and have to edit the pages again, creating hyperlinks, converting MySources to Sources etc. It is not possible for me to know which pages are most current, the ones on WeRelate or the ones in my database for one of my trees without comparing the pages one by one. On my personal family tree I thought that I would upload a gedcom containing the name of one person who is already in my tree and that way WeRelate would choose the correct tree and I could then add his descendants, but this is just a small section of the tree. Replacing the entire tree will not work for me. I don't even remember but I think that I may have uploaded one gedcom. Most of my trees were hand entered. Ha, now I have even confused myself. Not sure that the gedcom upload should have anything to do with trees other than which tree you match; then your pages are added to that tree. If your gedcom doesn't match any pages then WeRelate can ask you to name the new tree or select an existing one. --Beth 18:33, 27 April 2009 (EDT)

I began in early March with a tiny tree and then added 10 small gedcoms to it. The plan was to slowly and carefully build up the tree. Then I found that the system changed and every gedcom would be a new tree! I don't want to dump everything on WeRelate all at once with all its warts, nor do I want to create lots of tiny trees. Meanwhile I am on hold. I tried a large gedcom of my paternal grandmother's family and got lots of warnings so I withdrew it. I have questions about that also but they can wait.--HLJ411 21:10, 29 April 2009 (EDT)

Many of the warnings are too strict and a few have bugs. The fellow who wrote the warnings code is in the process of changing jobs and moving to another state unfortunately, so I haven't heard from him in the last week. But next week the warnings are going to be fixed one way or another.--Dallan 12:49, 2 May 2009 (EDT)

Clarification [2 May 2009]

Sorry for the confusion. Let me start over. There are two things that I want the system to do automatically when you upload a GEDCOM that contains people that you have uploaded before:

  • Match people in the new GEDCOM to the wiki pages created or matched for these people in a previous upload. I want the system to match them automatically because a new GEDCOM may contain hundreds/thousands of people included in previous GEDCOM's, and I don't want people to have to match them by hand.
  • If the information on the person has changed between the previous GEDCOM and the current one, list the person in the "Update" tab so that you can compare the information in your current GEDCOM to the current version of the wiki page and possibly update the wiki page. Note that whether the wiki page has changed since the previous upload it doesn't matter. The "Update" tab will only list people who differ between your previous GEDCOM and your new GEDCOM, since these are the wiki pages you probably want to consider updating.

Initially, my idea for implementing this was to compare your new GEDCOM to your previously-uploaded GEDCOM, look for people who are identical in both GEDCOM's and automatically match the people in the new GEDCOM to the wiki pages created/matched for the people in the previous GEDCOM. Then use these identical pairs of people (one from the old, one from the new) as "landmarks" when trying to match additional people in your new GEDCOM to your old GEDCOM. So if we have a pair of people who are identical, and the parents of the pair are similar, then match the parents in the new GEDCOM to parents in the old GEDCOM and add them to the list of people in the "Update" tab. Try to match as many people in the new GEDCOM to people in the old GEDCOM as you can. People in the new GEDCOM who can't be matched will be treated as if this were a first-time upload, and they'll go through the normal match process to see which pages on the wiki they might match with.

The idea of replacing a previous GEDCOM wasn't meant to affect your tree, just reduce the number of previously-uploaded GEDCOM's the system needed to compare the new GEDCOM with. The idea that you can upload possibly many GEDCOM's that overlap a bit with previously-uploaded GEDCOMs, but that each GEDCOM might contain different people complicates the above approach, because instead of comparing the new GEDCOM to the single most-recently uploaded GEDCOM, we need to compare it to all of your previously-uploaded GEDCOM's. And when determining whether the information for a person in the newly-uploaded GEDCOM has changed, we should look at only the most-recently uploaded GEDCOM containing this person. But I think I'm convinced that we need to implement this more complex approach, especially since the new GEDCOM upload process encourages uploading many small GEDCOM's into the same tree.

So I'll put back the option to upload a GEDCOM into an existing tree later today, and once we support GEDCOM re-upload, when you upload a new GEDCOM (whether into the same tree or not), we will compare your current GEDCOM to each of your previously-uploaded GEDCOM's. Then you won't have to specify whether or not your new GEDCOM is replacing an existing GEDCOM. The system will match the pages in your new GEDCOM to pages in any of your previously-uploaded GEDCOM's, and determine whether they differ between the new and previous GEDCOM.

Thoughts on this approach?--Dallan 12:49, 2 May 2009 (EDT)

That sounds like it addresses my concerns (and it sounds like great functionality).--Amelia 12:56, 2 May 2009 (EDT)
Also, copying pages from one tree to another, even from another user's tree, is on the todo list.--Dallan 12:57, 2 May 2009 (EDT)
Thanks for the clarification. I can specify the name of the tree that I am updating if that is helpful.--Beth 13:09, 2 May 2009 (EDT)

Excluding living people from new GEDCOM uploads [4 May 2009]

Of the 1.7M Person pages on WeRelate, 150K of them (nearly 10%) are for living people. Pages for living people are nearly devoid of content, containing only a surname, gender, and the families to which the person belongs. We originally created these living pages because that's what RootsWeb and other sites did. But now I'm wondering if this is a mistake. What if we were to exclude pages for living people by default? You could use the GEDCOM review program to include pages that you really wanted to include (they'd still be nearly devoid of content, as they are today). Also, we'd probably want to create a page for the "Root" of the tree and their ancestors if the root was living. But the vast majority of living pages would no longer be created. How would people feel about this?--Dallan 14:57, 24 April 2009 (EDT)

Is there any problem caused by having the living people pages? A LOT of my 'living' people may not be living at all, but I don't know when they died. If their pages are available, maybe someone else knows when they died and can add that info. Or maybe you could exclude living folks born after some arbitrary date just to eliminate living children. I guess as time goes on, even that could be a problem later. OK, so maybe best after all to just not upload living folks. If someone knows when my living folks died, they also know enough about them to add them to the family, so you don't need my living folks. Hows that for quick change of mind! --Janiejac 16:24, 24 April 2009 (EDT)
Hmmm. I assume ya'll are aware that most genealogical publications go by the "Hundred Year Rule"? You don't include anyone in a published lineage who was born within the last hundred years. Or sometimes it's 70 years, which parallels the rule for release of the U.S. Census. I edit a statewide journal and our rule (at the moment) is "no one born after World War I." It's a matter of privacy. Consider that if you upload information on your deceased parents, even, that's going to potentially lead someone to you (or to your siblings) -- only a single generation away.
I understand that a century is probably too strict for the people on this website -- but I would definitely draw the line at anyone who is alive, or who is thought to be alive, or who is reasonably likely to be alive. And not just you and your parents, either. If you post information on your living 1st cousins, what is their reaction going to be? All four of my grandparents were born in the 19th century and have been dead for some time now, and that's as close as I'm willing to come to the present in my published research; my parents are both deceased, too, but I'm not uploading anything anywhere on them. (The detailed Ahnentafeln on my own website begin with my great-grandparents.)
Having said all that, how is it useful to upload an empty page? "Unknown Living m. Unknown Living" and had an unstated number of Unknown Living children. C'mon. I would automatically exclude the upload of any person lacking an explicit death date who was born less than, say, 100 years ago. If the uploader knows the person is deceased, but not exactly when, they can always say something like "Died bef 2009." If the uploader doesn't know whether the person actually is dead or not, they shouldn't be uploading them.
One other thing: Why is it so important to upload the root person of a GEDCOM? What function is that supposed to serve? First of all, the root person certainly doesn't have to be identical with the uploader. In fact, that's the sort of knee-jerk, nondiscriminating uploading pattern we're trying to get away from, right? The root person of my first, experimental GEDCOM is my grandmother. But WeRelate, being a wiki, doesn't focus on tree-shaped lineages. It's more of an amorphous cloud of inter-related people, none of whom is the "root." The whole point of a collaborative project like this, I would think, is that no one is more important, more "primary," than anyone else. That's one of the things I like most about the concept. --Mike (mksmith) 20:49, 24 April 2009 (EDT)
I don't see any benefit in having hundreds of empty pages cluttering the system. People seem to think there is some benefit, but do they realize that the pages have been stripped of all useful information? Is someone really going to do a search for "Living Smith(3624)"?
The harm is that we live and work in the "real" world and "Stuff happens". If we accept information on living people, we can't guarantee that it won't accidently get out. The news is full of reports of corporations and government agencies that have had their "oops" moments. We need to reject information that is personal to living people. We just have no business loading it.
--Judy (jlanoux) 21:04, 24 April 2009 (EDT)
I'm fully in favor of having no "Living Surname" pages on the site.--Amelia 12:27, 25 April 2009 (EDT)

Based upon the above discussion (thank you to the contributors!), I'm going to change the GEDCOM upload tool to by default mark living people excluded, except for the root and the root's direct ancestors.

  • People with early birth/marriage dates, or people without any dates at all who aren't directly related to people with recent dates, will continue to be marked dead by default. Only people with recent birth/marriage dates and no death dates, or people without any dates who are directly related to people with recent birth/marriage dates will be marked living by default. During the review process you'll be able to review the people who have been marked living and mark them dead and include them if you know that they're dead.
  • I want to continue to include the root and direct ancestors even if they're living because in the past a lot of people have said that they'd like to see their tree in the Family Tree Explorer starting with them as the root. I have an idea for addressing this desire without needing to to create pages for living roots and their ancestors, but I haven't implemented it yet. Once this other approach is implemented the system will mark living roots as excluded by default during GEDCOM uploads as well.
  • I'll make the change to the GEDCOM upload process this week, but deleting the 150K pages for living people is a lower priority, and probably won't happen for awhile.

--Dallan 14:19, 4 May 2009 (EDT)


Cemeteries as place pages [4 May 2009]

One of the things I've noticed while reviewing gedcom's the past two weeks is that all kinds of things are listed at the last level of a place, including schools, hospitals, and cemeteries. These places usually result in "red links" because we don't typically have them in our place wiki. The presence of the red link encourages people to create Place wiki pages for these places. But we don't want to clutter the place wiki with lots of pages for schools and hospitals, so we take them out when we see them. Next week I plan to change place matching so that schools and hospitals in gedcoms get matched to the next-higher-level wiki place. For example, Northwestern University, Chicago, Cook, Illinois, United States would link to Chicago. The place would show as Northwestern University, Chicago, Cook, Illinois, United States but if you clicked on it you would be taken to the Chicago Place page.

The question is, what about cemeteries? In the past I've thought that we should create Place pages for cemeteries because they're listed so often as places in gedcoms. But there are a lot of possible cemeteries, and if Place pages were created for even half of them it would certainly clutter up the place wiki. On the other hand, we have some beautiful Place pages for cemeteries, complete with pictures, so I'm not sure if we should say that you can't create Place pages for cemeteries. Or maybe we should say that you can't create Place pages for cemeteries and these existing cemeter pages should become articles that are linked-to from the enclosing town/township?

If we decide to allow people continue to create Place pages for cemeteries, I'm wondering if when a cemetery is listed in a gedcom and we don't already have a Place page for the cemetery, if we should match it to the next-higher-level wiki place, like I'm proposing to do for schools and hospitals? Then people wouldn't feel the need to create a Place page for a cemetery just to turn a red link blue. They could still create Place pages for cemeteries through the "Add" menu.

Thoughts?--Dallan 15:12, 24 April 2009 (EDT)

Cemeteries can be great sources of information, linking families together through burial and plot records. I think place pages for cemeteries could be great resources for providing information on how to contact the cemetery, whether records are available from the cemetery or other locations and at what cost, and what the overall condition of the cemetery is. --Lauren 15:31, 24 April 2009 (EDT)
Mmm... why NOT have cemeteries, schools, hospitals and (you didn't mention) churches be Place pages? Especially for the marriage place field, I bet there are a LOT of churches in the marriage place field. Having a red link would be an opportunity for someone to create a page for that church, cemetery, school, hospital-- although frankly the last couple, especially hospital, is of less interest to me. A church page could have information on it about whether or not the LDS microfilmed its records and how to obtain them, etc.
So what if the Place space is "cluttered"?
Another alternative: is there a way that a church, cemetery, hospital, school could be a subdirectory off the appropriate Place? Or am I going off-wiki again? ;-)
-- jillaine 15:41, 24 April 2009 (EDT)
Question 1) Do we want to allow place pages below county level?
Cemeteries do have a special place in the heart of a genealogist. I remember when DeLorme was testing their first map CD. We genealogists clamored for cemeteries to be added. (They're in there!)
My question is: Does having a lot of extra place pages for cemeteries do any harm? (We cheerfully created thousands of empty pages for living people)
I can see that they are helpful. With small rural cemeteries, a place page could make them findable by more people. In large, urban areas it would help to have information on reaching the office and maybe a section map. I guess in the past week working in WeRelate I've talked myself into thinking that cemetery pages are a good thing and am planning to add a few.
With respect to the other type places, where would you draw a line? I just hope that we don't have users forgetting to add People to the database because they are so busy adding places. It's the people count that attract traffic.
Red Links...Are these so bad? I think the compulsion to force a place match may come from a subtle tone in the help and talk discussions that is is immoral to have red links. (Sorry I don't have an example, but that is definitely the message I picked up in my three short weeks here and thus I spend a lot of time working place links.)
Question 2) If a place is not matched, do we want the gedcom routine to drop the lowest field and try to match it at the larger level?
I am in favor of this having watched some new users struggle to get through the import. A giant list of match errors is pretty discouraging. We say it is optional, but one still gets the idea they have done something wrong. When trying to work the place list, I noticed that what I was doing was dropping the cemetery, church, whatever and matching on the city or county. Why not let the computer do that? This is assuming you will still display the original entry "behind the pipe".
With this solution we could allow, but not require place pages at the lower level.
--Judy (jlanoux) 20:54, 24 April 2009 (EDT)
[...edit conflict, mutter, mutter, mutter...] I don't have any strong feelings one way or the other about schools or hospitals. No one in my family, that I'm aware of, ever lived in a school.   :)   And only the last two generations of my family were even born in hospitals, not to mention not dying in them. Cemeteries are different, though. I tend to think of a cemetery itself as a "source" -- or at least a repository, the same way a courthouse is a repository. Also, cemeteries have a great deal more meaning for family researchers, I think, than do schools or hospitals. If the concern is "cluttering" in the Place namespace, there are a lot of tiny "inhabited places" that I'm sure aren't being used, either. I've been creating some cemetery Place pages myself in the process of tidying up my GEDCOM -- but only (so far) those that I've personally visited, and therefore have something useful to say about them. I'm also trying to include geo-coordinates for all of them (Google Earth is great for that), especially the smaller ones that are easy to miss. Several of them are also important to certain families because half a dozen generations of an entire clan might have been buried there. (I'm thinking Hatfields in Indiana.) --Mike (mksmith) 21:07, 24 April 2009 (EDT)
So, here's perhaps an extreme view: we should have Place pages for cemeteries, hospitals, schools, churches, etc., etc. because otherwise we have to throw away a significant collection of information. Throwing away data is bad! Besides, think of the sort of uses for that sort of data: find out who else was being born or dieing in the hospital when your grandfather died there. Look for patterns: do a large number of deaths connected with such-and-such hospital have a certain cause of death? Perhaps because the hospital lacked equipment to treat that condition? You could find out who were classmates and contemporaries of your relative.
Once again, I also think having a Cemetery namespace might be a good idea. As for cluttering up the Place namespace, let's remember that places include a "Type", which we could filter by. Place types seem to be fairly consistent, although there are too many "unknown"s, I think. --JoshHansen 23:59, 24 April 2009 (EDT)

I feel that we should encourage pages for sites (I call them sites to differentiate them from places). Just a couple of examples: there is a building down the street from me that used to be an orphanage - not even many locals know this. It would be nice to be able to have a page that could collect photos, stories, etc. about this site. Another example: my great-grandfather passed away in a hospital in the Bronx that is no longer there. Again, it would be nice to have a page that detailed where it was, photos, etc. I don't understand why we would worry about cluttering up the place wiki. I think the cluttering issue here is more about the drop-down boxes. Church pages! Yes, that would be very nice to have. The wiki allows for endless possibilities and creativity, we should embrace that.--Jennifer (JBS66) 07:32, 25 April 2009 (EDT)


Another type of "place" that hasn't been mentioned is the large number of once-upon-a-time military installations in this country. I've been making Place pages for a few of them, as I think of them. Jefferson Barracks, just south of St. Louis, was the training camp for tens of thousands of Civil War soldiers from the Midwest; it was established in 1826 and was an active post until 1946. My folks were married in the chapel at Camp Grant, Illinois, which also was closed in 1946 and is now under Rockford International Airport. An army post is closer in type to a town or village, but it's created by government order and often ceases to exist the same way, so its history is finite. --Mike (mksmith) 11:14, 25 April 2009 (EDT)


I've been assuming that Cemeteries are places for quite a while. For example: Eastman Cemetery in Bartlett Memorial Forest, Nottingham, Rockingham, New Hampshire, United States. You can also create a place reference using lat/long. For example, {{googlemap|42.46900|-71.35062|Concord Bridge|Concord+Bridge|14|h}}. I use http://mapper.acme.com to zero in on a location and pick up the detailed coordinates.--Jrm03063 22:10, 1 May 2009 (EDT)


Ok, it sounds like the consensus is to allow people to create Place pages for schools, hospitals, churches, cemeteries, etc.

To simplify matching these places during the GEDCOM import process, I'll add a Match place at next higher level menu option to the GEDCOM review program.--Dallan 14:55, 4 May 2009 (EDT)


New Search [4 May 2009]

I forget where we were talking about the confusion about searching page title v. book title. Not a fan of all the clutter created by separating them out, but I understand the usability reasons. What I don't understand is why the changes to search are somehow getting me church records when I search for census. I assume it's because I have to (for no reason whatsoever as far as I can tell) pick a "type" before I search, and I pick government/church. So I get things like "Church census records, 1914-1960", displayed under Book title as "Church census records, 1914-1960". Huh? Yes, that technically has census in it, but the bolding doesn't. And the next few records are church records from totally different parts of the country than I asked for. It appears likely that there's not actually any census records for the county I searched for (Newton, MS), but the search order is now so wacky I can't tell. I should at least be getting CENSUS records, but I'm not.--Amelia 21:39, 27 April 2009 (EDT)

There was a too long conversation on User Talk:Dallan about searching for geographical sources. See especially Dallan's comment about things you can do with the keyword field. --Jrich 22:36, 27 April 2009 (EDT)
That was the conversation I was referring to (which I followed but didn't participate). But it doesn't answer the problem of "church" all of a sudden apparently being a search term. That's even worse than before! If I search for Newton, MS census, I expect 1) Newton, MS census records; 2) MS census records; 3) census records. That's it (and overkill of course, but this is non-exact match, since that animal doesn't work for sources that aren't named yet).--Amelia 23:48, 27 April 2009 (EDT)
Hmmm, something seems wrong. I can't even get results I was getting before. As soon as I put a place and check exact match, I seem to find nothing even though there should be sources for that place. I got rid of church by selecting Subject as Census records, but this did not help find the census record. --Jrich 09:34, 28 April 2009 (EDT)

For a specific example, searched for place=louisiana, united states; page title=census; subject=census. Exact match=Nothing(!). Normal: the top 10 includes about 3 actual Louisiana records, 3 records that mistakenly have Louisiana as a place, and about 4 records like Portage Co, Ohio census and the 1810 Tennessee census. #13 is also in Louisiana, nothing else in the top 30 is. Put "+Louisiana +census" in the keyword field, and I get 174 matches, nearly all of which are actually from Louisiana. But no matter how hard I try, I can't get Source:United States, Louisiana, Union. 1850 U.S. Census Population Schedule to show up. It's not in the first 10 pages of the 174 (bored) and I get no matches if I add +union to the search terms.--Amelia 00:50, 30 April 2009 (EDT)


Happiness and joy. Much, much better this morning.--Amelia 13:47, 3 May 2009 (EDT)


Thanks :-) It was a bug that I introduced last week when I added the new "source title" field on the search form. I also made a few improvements to searching sources in general. And for anyone who hasn't tried adding a source lately, you no longer have to enter the source "type". Just fill in author (if there is one), place (if the source covers a particular place), and title, and search for matching sources. If you can't find a matching source and decide to create a new page, the Source page title will be Author. Title if author is filled in, Place. Title if the place is filled in, or just Title if neither author nor place are filled in. Hopefully that provides a simple description of how Source pages are titled, and it agrees pretty well with our current title standard. I've listed some examples for when you would fill in each field on the Add Source page. Is everyone ok with this change? Finally, I've changed the field label for the source title from "Book/Collection title" to just "Title" -- I'm hoping that it will be obvious from the context that we're talking about the source title and not the Source page title.

Would someone mind updating the help pages with this information? Thanks!--Dallan 13:36, 4 May 2009 (EDT)


Categorizing Images [4 May 2009]

It struck me it might be a good idea to encourage people to put dates and places on images, even vaguely (eg c1900 or virginia) and also asking to categorise them (eg 1880 Census, school group photograph, Portrait, church)

This would provide secondary value for example (once the collection has grown) when people are dating photographs. They could seach for Wedding, virginia, 1900 and get some examples of the type of photo, fashions common in that place in that era--Dsrodgers34 18:20, 1 May 2009 (EDT)


We currently have a field for place on the images; I could add one for (approximate) year if people want. I could also add a category field if people would come up with a list of categories they wanted.--Dallan 13:53, 4 May 2009 (EDT)


Thats what I meant. Of course it would only be useful if people embraced it - It'd be interesting to see what others think

Dale


BCG Certification Video online [1 May 2009]

The BCG now has a video of a BCG certification seminar online at [7]. I recommend at least viewing the portion that addresses Requirement 7.--Beth 19:56, 1 May 2009 (EDT)


Another change to searching sources [6 May 2009]

A few weeks ago I changed the way that searching sources worked: if you entered a place and checked "Exact matches only," you would only get sources that covered the entire place you searched for, and not ones that covered lower-level jurisdictions. So for example if you entered "United States" into the place field and checked "Exact matches only," you would not see county-level sources.

The more I think about this the less I like it. It's a different behavior than you get when you search people or families, where if you enter "United States" and check "Exact matches only," you'll get people with the event located anywhere within the US. So I've just changed it back so that searching sources behaves the same as for searching people or families: if you enter a place and check "Exact matches only," you'll also get sources for lower-level jurisdictions. If this causes a problem for anyone, please let me know and I'll revert it back to only returning sources covering the entire place you searched for. Note that none of this affects searching sources without the "Exact matches only" box checked. In that case sources covering the entire place you search for appear above sources covering smaller jurisdictions.

In about two weeks I plan to implement another sort option for exact-match searches: sort by Popularity. This will be the default sort option (you'll still be able to switch back to sorting by title or last-modification-date). Popularity will be based upon the number of people watching the page and the number of other pages linking to it. I'm hoping that this will generally cause higher-level sources, like US Census sources, to appear above lower-level sources in exact-match searches. Popularity will also be taken into account when sorting results for non-exact (regular) searches.--Dallan 23:31, 6 May 2009 (EDT)


proposed acknowledgements [28 May 2009]

Image:Feature article medal ribbon.jpg for featured "person articles"

Image:Genealogy Well Done Ribbon.jpg For Genealogy-Well-Done articles, including in particular good use of primary sources

Image:Genealogy Well Done Ribbon 0.jpg For well done articles, lacking sources, but making good use of narrative


Q 10:48, 13 May 2009 (EDT)


I think if people want to use these to highlight pages they come across, I think that would be great. I really like the idea of highlighting well-done pages. Q, could you add these images to a help page so they don't get lost? It might even be better to create three templates: one for each type of award that includes the corresponding image.--Dallan 20:11, 27 May 2009 (EDT)

Happy to. Q 21:44, 27 May 2009 (EDT)

Used the triple curly brackets to create two templates, whose use can be seen at Person:Leonard Coker (1).


Method needed to make it easier for users to locate pages that need assistance [27 May 2009]

We need some method to identify pages that need assistance. I don't see any easy way for a user to identify such pages presently. Users would probably work on the pages if they were marked somehow. Maybe by category. For example, we have many pages that were uploaded via gedcom but have not been cleaned up after the gedcom upload. Users could delete the duplicate sources, enter place names so that they are included in the place name links, etc. --Beth 20:30, 16 May 2009 (EDT)


Do you think we could do this with something along the lines of a template that assigns the page to a Help needed category? Would it be useful to have different types of templates to point out different types of problems, like {{incorrect-dates}} if the page has obviously-incorrect dates? Feel free to create one or more help-needed style templates and add this to the help pages.--Dallan 20:11, 27 May 2009 (EDT)


little check box in Merge - moving ? [18 May 2009]

Hello,

Is it my imagination, or has anyone today noticed this? The little check box when you choose what to merge is moving when you try to check it? Debbie Freeman --DFree 00:00, 17 May 2009 (EDT)

Using IE7, the check box is not moving. --Beth 08:09, 17 May 2009 (EDT)

On this topic I did merges but it wasn't immediately apparent , when merging, that you were merging a page which was originally contributed by someone else. I'd prefer a strong notification before I made a change to another persons page so that I could take more care etc--Dsrodgers34 00:15, 18 May 2009 (EDT)


Collaborating within a "Tree" [27 May 2009]

I have a tree which is of anyone who was in a particular village/parish as referenced in PRs/census. A 'one place study' rather than a family tree if you like.

I hope to encourage people to contribute within my tree rather than upload a tree then merge. Its taking some time to find and then get others interested but I have one lady who's happy for me to take the Photographs she has contributed to Ancestry and put them in my 'site'.

I'd like to add her as a watcher so she gets notification when I make changes to pages which interest her. Is it possible for me to add her to my pages as a watcher ? I don't think she is keen on uploading gedcoms etc and this would be the best way to encourage her valuabe input

Or would she get the same effect by 'watching' my tree page ?

Regards,

Dale--Dsrodgers34 00:13, 18 May 2009 (EDT)

My thought would be to encourage her to "Edit" your page, ensure the "Watch this page" button was checked, then "Save Page." --BobC 13:09, 18 May 2009 (EDT)

Or she could click on the "Watch" link at the top of the page. The idea of watching a tree, so that you automatically watch any new pages added to the tree, is on my todo list for later this year. Then she could just watch your tree and get notified when new pages are added and automatically watch those pages.--Dallan 20:11, 27 May 2009 (EDT)


Transclusion from Wikipedia [27 May 2009]

In the process of "polishing" the format for Place:Russell, Virginia, United States I noticed that the transclusion of the county summary from Wikipedia, does not work. In checking back to the earlier versions of this page, it appears that it never worked. The code for the transclusion

{{wp-Russell County, Virginia}}

produces only a broken link:

{{wp-Russell County, Virginia}}

I see nothing obvious that would cause the problem.

The similar code

{{wp-Washington County, Virginia}}

does exactly what its supposed to, though its for a different county page.

{{wp-Washington County, Virginia}}

Any suggestions on how to correct this? (other than just copying the text over and ignoring the transclusion)?

Q 09:13, 25 May 2009 (EDT)--Q 09:22, 25 May 2009 (EDT)


I'm not sure what happened (why the template never got created), but I changed the {{wp-Russell County, Virginia}}<nowiki> to <nowiki>{{source-wikipedia|Russell County, Virginia}}. This will direct the wikipedia-update program, which usually runs each weekend, to create the {{wp-Russell County, Virginia}} template and to reference it in the Place page (changing {{source-wikipedia|Russell County, Virginia}} back to {{wp-Russell County, Virginia}} once that template has been created).--Dallan 20:11, 27 May 2009 (EDT)


Questionable category and template added [27 May 2009]

I have added this template: {{questionable|template for pages with questionable or incorrect data}}. See Person:Solomon Casey (2).--Beth 08:16, 26 May 2009 (EDT)

Works for me, particularly since you include the specific concern with this specific page, rather than a generic statement. The statement of the issue is very objective or "position neutral" in wiki terms---just a statement of fact. As such it should not be problematic. I see that the person watching this page continue's to edit their initial input, so a flag of one sort or another has a reasonable chance of illiciting a response. Clever use of the alias to indicate the specifics; I'll try that with Speedy delete, which has a similar problem. Length of template display is a bit long, as it pushes into the advertising area. If you had a really long comment it would end up being partially obscured. You might consider useing a somewhat more subdued shade of yellow for the template. I've been using the to flag the specific data elements of concern, with a similar explanation, and have inserted such a flag one the target page to illustrate an alternative approach. This specific type of error could be searched globally by the system and inserted, which could be good if the specific problem could still be identified by the machines. Conflicts like this should not be too difficult for the machines to identify the specifics. Jut need an appropriate rule. Q 15:07, 26 May 2009 (EDT)

This big yellow banner strikes me as a little overbearing in appearance.

I believe the way to address some of this would be to enhance the value of the Talk page, but making it more obvious when there is new talk material (as I have suggested elsewhere).

In the example case, not only is the father born only 5 years before his son, he is about 40-50 years younger than his wife. So it looks like a typo or a mixup of namesakes, resulting in an incorrect birthdate for the father.

If I was interested in the person, I would try to get a more reasonable date and replace it, giving a source, possibly adding a discussion on the talk page. I am not sure such a banner is all that useful for an interested person since they should be motivated to find a better answer and replace the bad data.

If I wasn't interested, i.e., didn't know or want to find a reasonable alternative, just alert people that the data was bogus, I would probably try to pin down the likely single mistake, if possible, recording its existence on the talk page, giving a brief explanation of why it is most unlikely, and then remove it from the page, so it does not mislead future searches, etc. If somebody is watching the page they will be notified by the change to the talk page, and can respond via discussion if needed.

Errors like the example are so obvious that anybody should catch them. And so not surprisingly, it turns out the parent's page with the 46 year age discrepancy was uploaded by GEDCOM and nobody has edited it yet. This will be much less likely to take so long to be noticed when WeRelate goes into high volume production.

The example note with the red flag is better, and notes can be removed easily when the problem is fixed, but leaving the data unchanged still means searches and stuff will reflect the obvious mistake.

--Jrich 19:10, 26 May 2009 (EDT)

I must give credit to Dallan Quass for the template. I implemented the template that he suggested during a conversation regarding the difference in opinions of removing the person from the existing page. I have adjusted the color and length of the banner. My preference is to place this on the page; newer users may not even be aware of the talk page. One has the option to not use the template or use the template on either the page or talk page. The red flag and note is certainly another option; I would add the Category:Questionable on the page when you use the red flag. This allows users to easily access pages with questionable data and elect to improve upon the pages. --Beth 19:50, 26 May 2009 (EDT)


I agree that the banner is a bit overbearing, but that's now fixed. The length still needs to be shortened. When I just checked its now pushing the ads to the far right, and off the screen. Now I can live with not seeing the ads! but that's what funds the site, so this probably needs to be fixed. Something to keep in mind is that there are differences in display capabilities between different machines. It may look OK to you, but to someone else with a different system, it may look really bizarre.
I personally like the flags, and Beth suggestion of inserting a Category tag is a good one. But the Banner approach has its advantages---especially in this position neutral format. Much of this is a matter of style, and how much people want to get involved in fixing things that aren't in their own line. The banner would be easier to implement by machine, I suspect. All you'd need to do would be to compare DOBs of the child and of the parents---anything with a difference of less than X gets a banner---Whether the original submitter fixes the problem, or someone later on does it, matters not. But by flaging the problem (with a flag OR a banner), then its easily noticed that there's a discrepancy which says "Somebody Please Fix This". Eventually someone will. Q 20:02, 26 May 2009 (EDT)

To keep the banner from interferring with the right hand side bar I reduced the width down to 600px. Many would not notice the problem, because it only shows up when are using certain monitors, with certain screen settings. The way its now set if I expand my window to the full extent of the screen, it looks fine.

Perhaps Dallan can advise us if there's a certain rule of thumb about the maximum image width that's advisable to use.

Q 20:32, 26 May 2009 (EDT)


There is a problem with this and all banners. A person that knows little about this family is making a judgment about what is wrong. There is a census entry for Randolph Casey in KY in 1820 and he has one son under 10 and one between 10-16. I would guess that the Randolph Casey Jr. is the male listed as 10-16, i.e., b. 1805, and was mistakenly linked into the father's spot. It doesn't appear to be the case here, but this is an error that could easily happen due to aggressive merging. The real problem appears to be with the Randolph entry and you are putting what is (to me) a distracting, so-loud-that-it-makes-it-hard-to-think, banner on Solomon's page, when Solomon may very well be accurate, as much as is given. So given that someday, some body corrects Randolph and never sees Solomon's banner, what then?

If Dallan wants to write a check program that uses certain rules and adds little markers next to unsourced facts that seem out of whack, and re-run the check every night so fixed flags get removed, I would have no problem with that. He could even collect all these pages onto a Questionable Review project just like the Duplicate Review project if people would volunteer time to clean up bad data. Presumably there would be a noquestionable template like the nomerge one so when one knows a 80 year old man marries a 24 year old woman, one could flag it as not questionable.

Using a small little flag in a note is questionable because it suffers from the same problem described above, i.e., somebody that doesn't know the family judging the validity of the data, but at least it doesn't dominate the whole page. This banner is bordering on rude (IMHO). --Jrich 23:56, 26 May 2009 (EDT)

I disagree; the banner is not rude; it simply points out that there is questionable data on the page and gives the reason and also alerts other users to the category to identify pages that need addressing.--Beth 00:44, 27 May 2009 (EDT)

The reasons why it strikes me as rude (which is probably a stronger word than I mean) is that

  • it is so prominent even if you don't look at the data, you will notice the banner. It screams!
  • the person using it is not starting a discussion but making a statement
  • the person using it is willing to pass judgment but not willing to look for the correct data.

All this indicates you are not watching the page, so don't care about the page, but are just punishing somebody for making a mistake, or equally possible, a simple typo. If the data is so obvious that you can spot questionable data without needing any sources, others will spot it too without the banner being needed, or just a small, discrete one. You are far more likely to use this banner in error than to accomplish any good with it. --Jrich 01:31, 27 May 2009 (EDT)

Overall, toning down the color makes the banner less in your face. I probably take it a bit further, say using a simple border similar to Wikipedia, and no color, or grey. But in anycase, as it is at the moment, its prominent, but not overly so. I will probably continue to use flags, as they are a bit more surgical and discrete, but convey the message that a fix is needed. As for the wording of the banner, its pretty much position neutral. If an editor working on this family objects to it, it would not be because the statement is argumentative, etc., but because they disliked having a common, but rather unintelligent error, being pointed out. One might argue that you if you are going to spend the time to point something like this out, you should spend the time to fix it. Perhaps so, but then why does Wikipedia do this? Mostly because things like this are a work in progress, and having issues pointed out is the first step in getting them fixed. Eventually, someone will fix them. Doesn't have to be today. And if the original author of the item is not happy because someone identified a problem, then I suspect working in a wiki environment is not for them. As to misidentifying a problem, I'm sure that kind of error will happen to. But this particular instance is fairly obvious. Irrespective of what the wrong datum is (the childs DOB or the fathers DOB), the page is in error. When someone sees something like this, pointing it out is a good thing, even if you choose not to pursue the matter and fix it yourself. Errors of this sort mostly occur because the information involved is being added independently from each other---and its not immediately obvious to the submitter that an inconsistency has crept in---mostly because they are focusing only on certain elements. Its a very easy mistake to make, and its very very common. Having a system that catches things like this, and flags them, would be very useful to most genealogists. And more to the point, would be very helpful in making the tree a better and more useful database. In general, I see nothing rude about this approach. Its fairly discrete (could be more so), definitely within the realm of "position neutral", should not offend, and I think helps foster the objectives of WeRelate. Q 08:56, 27 May 2009 (EDT)

Banner color changed again per request. --Beth 10:27, 27 May 2009 (EDT)

Not sure, based on the content of the discussion here, if this is meant as a self-help device, for individuals watching a page to add their own flag to a page they are working on (such as an HTML "Under Construction" image) or as a visual reminder; or if it is meant as an editorial comment by readers and users; or if it is is meant as a method to critique of the validity of the information on a page by volunteer screeners.
If this idea is meant as a screening option and is adopted within WeRelate, my vote is for using the to flag specific questionable data elements rather than the yellow or purple banner on the page (or whatever color it turns out to be). The colored banner would infer the entire page is questionable, unsubstantiated or unreliable. That to me is overkill.
The use of such flagging highlighter, in whatever form used, would not be needed at all if the data was properly sourced. The reliability factor assigned to each source of data should give readers and users that information and there would be no need for such a highlight. Therefore if imposed by someone other than people watching the page, it should only be done when data is not sourced, much the same as in Wikipedia when requesting more sources on a subject.
Use of the Talk page on any particular article or page might be a more appropriate place to comment on a reader or screener's opinion of the validity of the facts presented. For those concerned about the use, type and validity of sources, you might want to review Wikipedia's Reliable sources policy page and Citing Sources for their policies on the subject. I'm sure there are articles on the subject here within the WeRelate comunity as well.
--BobC 12:27, 27 May 2009 (EDT)
I think all of the above is true. The flag-its, and banner-its serve similar purposes. They are specifically intended to mark a problem in passing for correction. Who does the correction is not especially important. The audience is anyone who reads the page. Note that on Wikipedia, similar banners go directly on the article page. That's so that they won't be ignored---which is what would happen if it went on the talk page. Q 13:31, 27 May 2009 (EDT)

For the past month I've been reviewing the new GEDCOM uploads. The new GEDCOM upload process includes a list of warnings where it finds suspect dates in the GEDCOM. Nearly all of the uploaded GEDCOM's have warnings on some of the pages. I've come to the opinion that it's quite difficult even for conscientious people to get everything right - things get overlooked. Several people have asked me to allow them to print the warnings list since it's not feasible to fix all of the warnings during the GEDCOM upload process. Eventually I want to do this, and more importantly, to run a warnings check periodically over all pages in the wiki and identify pages with probable issues. But that's months away. In the meantime, the banner seems like a good way to point out pages with potential problems, which most people probably aren't aware of and I think most of the time would be grateful for the notice. Wikipedia uses banners similar to this. If one of the authors can clear up the issue, then it's pretty easy to remove the banner. And I think we do searchers a favor by pointing out pages that need help so they don't blithely copy the data into their personal trees. If we get feedback that the banner is too in-your-face, we can reduce the size, but I think that a banner of some sort is a good way to go.

As for width, I don't think we'd want it any wider than it is now. It could even be 100 pixels narrower to fit a bit better on 1024x768 monitors. But 600px is fine.

I just changed the color to grey and the size to 500px to see what that would look like; feel free to change it back if people like the other look better.--Dallan 20:11, 27 May 2009 (EDT)



Brick Wall Icon [1 July 2009]

user:Delijim has an interesting icon that he's added to his user page, which I thought I'd pass along. I believe somewhere that someone suggested a "Brickwall" page or something along those lines. This could be used to indicate problems of that sort.

Image:Wallbash red.gif

Q 18:24, 26 May 2009 (EDT)

it might also be useful as an emoticon in some of our more "intense" discussions. Q 21:45, 27 May 2009 (EDT)


I love this one FAR better than the brickwall template created many months ago. OMG, this is great. And conveys some MUCH needed humor. jillaine 09:57, 9 June 2009 (EDT)
nodding (and laughing) in agreement with Jillaine --ceyockey 21:35, 1 July 2009 (EDT)

Need template for the NGSQ system for numbering [26 May 2009]

Is there available a template for the NGSQ system for numbering family members? --Beth 21:31, 26 May 2009 (EDT)


Speedy Delete [31 May 2009]

I've just used Dallan's pointer about the triple brackets to modify the Speedy Delete template so that the reason for the proposed deletion is embedded within the field, rather than appearing separately below the box. To use this function you need to insert the reason for the deletion following a "pipe" inserted just before the final double bracket of the template. As in

{{Speedy Delete 2|Insert reason for proposed deletion here}}

Note that the call for this version is "Speedy Delete 2" in curly brackets. The old Speedy Delete remains as it was, and can be called as before.--Q 10:58, 28 May 2009 (EDT)


I was wondering about how "speedy delete" works. Are pages automatically deleted after some prescribed period of time, or are all such pages removed when the "speedy delete job" gets run....???--Jrm03063 15:10, 29 May 2009 (EDT)


Including the reason as a parameter is a great idea. I've copied Template:Speedy Delete 2 to Template:Speedy Delete so that it works this way and updated the FAQ. If you add the template without a parameter but with the reason below the template as before, it will still display ok.

Pages on speedy delete are removed manually. An administrator reviews the page and the reason before deleting it.--Dallan 10:34, 31 May 2009 (EDT)


GEDCOM export available in the Sandbox [7 June 2009]

A first cut at GEDCOM export is available on the Sandbox! I'd love to get your feedback on how well it works (or doesn't work) before it goes out on the main website. Hopefully we can post it to the main website by the end of this week.

To export a tree, select Trees from the MyRelate menu and click on the export link next to the tree you want to export. A message will appear on your talk page in 10-20 minutes with a link where you can download the GEDCOM file.--Dallan 10:39, 31 May 2009 (EDT)

The link generated to download the exported GEDCOM is wonky. This is what I got: http://localhost/w/index.php?title=Special:Trees&action=downloadExport&user=gewurztraminer&name=crt --dayna 21:28, 31 May 2009 (EDT)
Thank-you for letting me know. I found the problem. I just exported another GEDCOM and it works ok for me now. Could you please try it again and let me know if it's still giving you the bad link?--Dallan 23:04, 31 May 2009 (EDT)
Works great now! --dayna 23:42, 31 May 2009 (EDT)

Hey, I just found that I can download your GEDCOM from your talk page. Is this supposed to work for everyone, meaning that you can download everybody's GEDCOM by spying on their talk page? (reposted from Dallan's talk page on the sandbox) --Enno 16:23, 31 May 2009 (CDT)

It's all public information from the website; I didn't think there would be a need to add security, and I thought that some people might want to email the link to their friends. What do people think? Should we make it so that only you can download your exported tree?--Dallan 23:04, 31 May 2009 (EDT)
Absolutely not; this would go against the entire philosophy of a Wiki. The trees are part of one community, WeRelate and are communal trees. --Beth 19:29, 1 June 2009 (EDT)
I basically agree, but I foresee a problem, too. We already have a problem with "drive-by" GEDCOM-ers dumping stuff here and disappearing. Does anyone not think there's the potential for some of these "genealogists" grabbing up GEDCOMs from this site, going elsewhere, and dumping them there? Do we really want to contribute to the growth of the garbage heap? The Person & Family Pages are "public," certainly, but maybe GEDCOMs ought not to be, for purely strategic reasons. --Mike (mksmith) 22:50, 1 June 2009 (EDT)
I can go either way on this. Later this week I hope to implement adding an entire family line in one step to your tree, so it will be much easier for people to extend their trees once they've become linked with others' trees. The concern about GEDCOM harvesting has come up in the past as well. One thing: every person in the GEDCOM has a source citation that contains a link to the WeRelate page they came from. So if people do harvest GEDCOM's, at least they'll contain links back to the (editable) source.--Dallan 00:46, 2 June 2009 (EDT)
OK, I first brought it up, because it looked like a security issue, but it's not if exported GEDCOM's don't show the details of living people that were there when I uploaded my GEDCOM. Anyway I think that harvesting is against wiki philosophy, because it may drive away users when they find out that their whole GEDCOM is being copied by people they don't know, and it may also drive away visitors, because it makes this site less unique. In other words, I agree with Mike on those strategic reasons. Please note that when taken literally, the Share Alike part of the Creative Commons license used here forces harvesters to disribute their downloads under the same license as we use here.--Enno 16:19, 2 June 2009 (EDT)
As a general observation, whether its proper or not, I suspect any site that publishes peoples Family trees via GedCom's, and makes them available for downloading, does so with the idea that they will be copied promiscuosly into other peoples family tree. Just about any search of the Ancestry family tree's will turn up numerous instances of cards for specific persons having exactly the same information contained in the "notes", but on different persons trees---I mean long passages in the notes, including copies of emails, and more personalized discussions, repeated from tree to tree. Usually there's no indication of where the information came from. One could say its at best, flagarant plagerism, and at worst copyright infringement. Either way, this doesn't seem to trouble many folks. I guess my point is that if someone puts their family tree up on a site, they probably better assume that people are going to incorporate it whole cloth---their personal "creative" notes (in the copyright sense of "creative") and all. if they do so on a wiki, then they should understand the nature of a wiki ---where its a given (with some exceptions) that what you put up is under the GDFL/Creative Commons, or whatever. If they put it up on a site like Ancestry all I can say is that it may as well be GDFL, as its going to be plagerized, appropriated, reused, usually with out the slightest hint of an acknowledgement. If Ancestry announced that you couldn't use Gedcom's on their site in this way, then they'd probably have to take most of them down---because most of those tree's have been "grown" by promiscuous copying of GedCom's. Q 19:04, 2 June 2009 (EDT)
If WeRelate is truly a Wiki then this question should be moot. Dallan once proposed eliminating the tree concept but changed his opinion. I was opposed to eliminating the tree concept; but now have changed my mind. When one creates pages on a Wiki, whether by gedcom or from scratch; they become part of the Wiki and are everyone's pages. Restricting gedcom export violates the principles of the Wiki in my opinion. --Beth 20:23, 2 June 2009 (EDT)

Problem reported by one user with the new gedcom export so don't use it yet.--Beth 19:33, 1 June 2009 (EDT)

Every person in the GEDCOM is seperate. no family groups. So parents, spouses ect are diconnected. [Reported to the administrators' group on Yahoo.]


Oops - this is fixed now. I was so focused on names and events that I forgot to look closely at family relationships. They should be working now.--Dallan 22:20, 1 June 2009 (EDT)


Here's an issue I hope to get people's comments on:

PAF doesn't accept multiple names for an individual; it throws the alternate names away. It does show you a list during import of alternate names that it's throwing away, but that's it. It has fields for a "Married name" and a "Nickname", but you only get one of each, and you can't attach notes or source citations, so I decided not to use those fields but to store multiple names in the GEDCOM instead.

RootsMagic and I expect TMG and other programs on the other hand handle multiple names for individuals just fine.

TMG has always had a philosophy of "include everything," since the first beta version a dozen years ago. Actually, GEDCOM export in TMG allows you to include all alternates or to include only primary versions of tags, and GEDCOM import does the same thing in the other direction. No problem there. --Mike (mksmith) 09:54, 2 June 2009 (EDT)

I'm not sure how well the various desktop genealogy programs handle alternate information: multiple names, birth dates, sets of parents, etc., which we tend to have here as a result of merges. The question is how best to represent this alternate information when it is exported as a GEDCOM file.

  1. I could target lower-level programs like PAF and just store the alternate information in notes, instead of trying to store it in structured fields that programs like PAF will probably just throw away anyway.
Speaking as a non-programmer, . . . I would think almost anything you're unsure of could be stored as a "note" (the old FTM fall-back) -- in the expectation that the person downloading the GEDCOM is going to go back and tidy up. Everyone does that, . . . right? --Mike (mksmith) 09:54, 2 June 2009 (EDT)
  1. I could target higher-level programs like RootsMagic that handle multiple facts and relationships and put the alternate information in the structured fields, which is what I'm doing now.
  2. I could allow people to specify the program they want to import their GEDCOM into: PAF, RootsMagic, TMG, etc. and try to target that program specifically. This third alternative would be the most work to implement (and I'd need help because I don't have access to most desktop genealogy programs), so it wouldn't be my first choice, but maybe we have to go this route.

As you play around with exporting GEDCOM's, would you please think about this question?--Dallan 00:36, 2 June 2009 (EDT)

I've been thinking about this. It seems to come up with every development project.

My take is that those who persist in using programs that can't properly store data have made their choice - they just don't care (and probably wouldn't notice what was missing). Other people have gone to great lengths to insist on a program that can handle the needs of a research project - they care a great deal. I can't condone crippling program output to cater to the least common denominator. It is the responsibility of an importing program to store the data they receive. It they don't have a place for it, then the import should put it in a note themselves. --Judy (jlanoux) 10:44, 7 June 2009 (EDT)


I don't know how hard it is to cater to the different desktop programs out there. I never really found one I liked and I stopped looking after I got going with werelate. Still, I do want to have a few GEDCOMs for backup purposes. I think the goal is to be symmetric - make sure that we can correctly read anything that we generate.--Jrm03063 14:59, 7 June 2009 (EDT)


I'll continue to target higher-level programs then. Right now we should be able to read anything we generate (once I get the export fixed). But I do need to remove the automatically-generated WeRelate source citations on a re-import.--Dallan 19:48, 7 June 2009 (EDT)


Info pages on Familypedia [1 June 2009]

Take a look at the info pages on Familypedia. I believe the pages are setup so your data is updated on the info page when you add data to another related page. Is this correct? If so this would be a great feature on WeRelate. Note that the pros and cons are discussed and there is no requirement that one uses the info page. Link to information about the info page: [ http://genealogy.wikia.com/wiki/Genealogy:Info_pages] --Beth 19:23, 1 June 2009 (EDT)

As far as I can tell, if I edit an /info page at Familypedia and add a wife to someone, I then have to edit the wife's page to add the husband as her spouse. This is in contrast to what already happens at WeRelate: when you edit a Family page and add a child, the child's page is automatically updated with a link to the Family page.--Dallan 22:23, 1 June 2009 (EDT)
I have not tried it Dallan; just trying to interpret it. But I was thinking it might work the other way around; you don't edit the info page first; you edit the wife's page to add the husband as her spouse and maybe the info is automatically updated on the info page but not sure. --Beth 22:40, 1 June 2009 (EDT)
I just edited an info page and removed a spouse. The spouse's info page was not automatically edited.--Dallan 00:37, 2 June 2009 (EDT)

Gedcom uploads and duplicates [7 June 2009]

Hi Dallan, a recent gedcom upload created 2 possible duplicates on the A page. Family George Alden and Jane Unknown are semi-protected pages. Family Dominico Attino and Francesca Urgola seemed to have slipped through the gedcom warnings. --Beth 08:24, 4 June 2009 (EDT)

There's so little information on George and Jane it's difficult (for me at least) to tell whether they are the same family. Dominico and Francesca are definitely the same family though. I'll merge them, but before I do I want to figure out how they slipped through. Thanks for pointing this out!--Dallan 01:05, 5 June 2009 (EDT)

Ok, I checked into this. The issue was that the uploaded GEDCOM file contained two family records for Dominico and Francesca. This happens every once in awhile. When it does happen, it's actually simpler to merge the two families after the upload. I think when I reviewed this GEDCOM I didn't notice the warning about the duplicate families and so didn't leave a message on the uploader's talk page about merging the duplicates after upload. Your message is a good reminder that I need to watch for that warning in the GEDCOM review process and to leave a message for the uploader asking them to merge the duplicates after upload. Thanks!--Dallan 19:57, 7 June 2009 (EDT)


Copyright? [8 June 2009]

Am I right in thinking that anything I publish on WeRelate is available for anyone to copy or change without my permission? I want to make absolutely sure that I understand the GNU license. I will not publish anything here, if that is the case. I don't mind sharing my research, but I don't like the idea of anyone changing my writing.

I also am not sure about the changes made to some of my family files, either. It bothers me when I can't find sources for the changes. Thanks. Ellen Rowan Taylor--Ellen 15:16, 4 June 2009 (EDT)

When you say you "can't find sources for the changes," do you mean that you can't find who made the changes or that a new piece of information on the page does not have a source associated with it? --Ajcrow 15:32, 4 June 2009 (EDT)

I can find who made the changes, without any problem. I just have not found credible sources for the changes. I'm not saying that my information is always correct, but I would not want to change anyone else's information without knowing that what I changed was documented.--Ellen 16:24, 4 June 2009 (EDT)


I am responding to my own question-my son assures me that the licensing relates to software, but he also assures me that anything I put on WeRelate is public domain and accessible to anyone without my permission. That is also my understanding. So, I will probably not submit anything else. I love the format. It is easy to use, and seems to work well, but it's not for me.--Ellen 18:03, 4 June 2009 (EDT)


If you feel that way, you are probably making the right decision. This website is about collaborating to find the most accurate genealogy. Not all of us have access to all the sources as an individual researcher. Nor are we all equally skilled at interpreting ancient documents. So each adds their own value to this website.

Of course, all your additions are recorded as yours in the logs. But, it is true that somebody could easily download this data, post it elsewhere, and make it appear like their own work. Or they could edit the data and add some fact that you think is false. Is this about you, or about your ancestors?

There are plenty of websites where only the submitter of the data can change it, and that is apparently, to you, an attraction. But to me, that is the weakness of those websites, as it limits the reliability of the data posted to a single person's opinion as opposed to the consensus of the community with all its diversity of interests. I recognize that I can make mistakes and I put my data here specifically so others can correct it when it is wrong. The result is something better than I can do alone. --Jrich 23:04, 4 June 2009 (EDT)


The GNU Free Documentation License is similar in purpose to but different from the GNU software license. The license allows others to use the information without charge given that they obey two conditions:

  1. They must give attribution to the authors of the information. This is typically interpreted to mean that they have to provide a link back to the "History" page, which shows the authors of the page.
  2. If they create a "derivative work" based upon the information, then the derivative work must also be made available under the GFDL.

The upcoming GEDCOM export feature adds source citations to every element of the download that link to the "History" pages in order to satisfy the first requirement. Someone could remove those citations or copy the information without giving attribution, but that would be a violation of the license.

As long as we're talking about licenses, it's interesting to note that Wikipedia recently voted to switch from the GFDL to the Creative Commons CC-BY-SA license. They'll be making the switch officially later this month. The CC-BY-SA license is similar to the GFDL, but it's easier to understand and doesn't require that the entire text of the license appear in exported GEDCOM files or other extracts of the information - just a link to the license webpage. Some of our content is dual-licensed under GFDL and CC-BY-SA currently, but not all of it. Once Wikipedia officially makes the switch, I'd like us to vote also on whether we want to switch everything over to the CC-BY-SA license.--Dallan 01:05, 5 June 2009 (EDT)


Ellen, if you have useful information on your ancestors that can be helpful to other fellow ancestors, I believe you are obligated to share it with others, whether here or on other genealogical sites, especially if it is information that helps clear up any conflicting information, adds additional generations or helps resolve "mis-understandings" among researchers. By "keeping this information to yourself" you are doing a huge dis-service to the genealogical community, in general. I have much of my research that has been "borrowed" by others on many of my key families, unfortunately, much of it without attribution or citation, but that is the reality of the internet. Since none of us have "exclusive ownership" over our ancestors, we all share them equally, and hopefully with increased information and research contributed by others (like yourself), our children and future generations will have a BETTER base of information to conduct their own research, hopefully built on the foundation of information that we are now building. If we all selfishly decide to "take our family information to the grave" without sharing it, then future generations will have no benefit from our life's work of research. I for one, hope you'll reconsider your decision not to share your work. Just my $.02.--Delijim 13:39, 8 June 2009 (EDT)


How to Watch pages that are automatically generated [7 June 2009]

Is there a way to be notified when a page that is automatically generated/updated changes? For example, I've marked several Cemetery Category pages, such as [[Category:Cemeteries of Perry, Ohio, United States]] to "Watch." Since the content of that page is generated by other pages being marked with Category:Cemeteries of Perry, Ohio, United States, the notification doesn't get sent out when a new cemetery appears on that page. Is there a way that a notification can be sent?--Ajcrow 21:45, 5 June 2009 (EDT)

Sorry, there isn't. It's a good idea though. This is on the todo list.--Dallan 20:05, 7 June 2009 (EDT)

Text size-Why so tiny? [7 June 2009]

My text size suddenly changed sometimes tonight. Now I need a telescope to read what I am typing. I did not change any settings. I am using IE8. --Beth 00:49, 6 June 2009 (EDT)

You mean on your home system or on WeRelate pages, on any page you navigated to? Q 07:32, 6 June 2009 (EDT)

The text in this box that I am typing now is the primary problem; I can hardly read what I am typing. All of the info boxes on WeRelate and Ancestry seem much smaller. I can adjust the page text to largest on WeRelate and the overall page text is larger. Adjusting the page text on Ancestry has no effect and switching to the compatibility mode on Ancestry does not seem to help much. I will try Mozilla and compare. Thanks. --Beth 21:39, 6 June 2009 (EDT)

Then the problem is with your system. Presumably just your browser, unless you are having the same problem with things other than your browser. I presume you have a PC since you said you were using IE8. If you are using a Mac you need to change out of IE, as its no longer supported on Mac's. Q 21:45, 6 June 2009 (EDT)
IE 8 has an option to reset all settings to their default values. It's in the Internet options dialog in the Extra menu, at the bottom of the Advanced tab. The actual names of these things may differ from what I mention here, since I'm using a Dutch IE 8 as a reference. --Enno 09:21, 7 June 2009 (EDT)
Thanks, I fnally figured out how to enlarge this text; although I did not make any changes to the IE8 settings when the small text problem occurred. If you Select Page>Zoom>Zoom in that fixes the problem.--Beth 09:49, 7 June 2009 (EDT)
Right. Page Zoom 100 % should work too. --Enno 09:54, 7 June 2009 (EDT)

New Categories [7 June 2009]

It would be helpful if users were notified of new categories. --Beth 20:33, 7 June 2009 (EDT)


Using GEDCOMs as sources [3 July 2009]

Help on merging says "Do not keep MySources that reference gedcom, .ftw, etc. files."

I am wondering if we aren't going a little overboard on removing GEDCOM-type sources.

I think citing an imported GEDCOM or FTW, etc., is bad genealogy. If that is where one's data comes from and one wants to cite it to give proper credit, one still ought to be able to explain in the abstract why it is credible, e.g., what sources the GEDCOM itself cites. If it is not posted on the Internet where anybody can access it, then it should be a MySource, and the abstract should give enough information so that others, without access to it, can know what it says. But, that said...

Is it better to know that the data is based on an imported GEDCOM, or to have no source at all cited? They may have the same credibility, but in the GEDCOM's case, it would appear to be at least two people's opinion. If it is listed as a MySource, one could always contact the User who created it and ask if there is more information available. So I am not sure much good is being done by removing these citations.

Perhaps removing these sources is making a statement that weak sources are not wanted. But this statement is only visible in the History, and will not be noticed by future viewers of that page. Instead someone else will come along and fix the absence of sources by citing a different GEDCOM.

Sources that are posted on the Internet do not fall in quite so despicable category in my opinion. One World Tree and worldconnect trees sometimes do have sources listed. Plus they are available on the Internet for others to view/review on their own, so deleting these references merely remove a pointer that could help somebody. These types of sources should ideally not be removed unless at a minimum the remover takes the time to check and verify that they give no sources, and provide no email address that may be contacted for more information.

I wonder about the need to remove source citations on pages that the remover has no intention of watching or contributing to, which is typical in merging. I prefer to think the better way to remove such junk genealogy is to crowd it out with real evidence, either refuting the junk genealogy, or providing real sources and only then removing the junk sources. There is a certain unfairness about putting oneself in the position of vetoing other people's sources and yet not being willing to provide better ones yourself. --Jrich 16:28, 8 June 2009 (EDT)

Yea!! Well said. I often have family members send me a GEDCOM. I know their work well enough to use their data but I don't like to put their email address as part of my source. So all I have as a source is Research of ... or GEDCOM of ... without any way for a viewer to also see what I see. That doesn't make it bad data. So when I see a chart with this kind of 'source' I know that somebody feels this is correct and I can try to find corrobative info.--Janiejac 17:22, 8 June 2009 (EDT)
There's a lot to be said for the Jrich's perspective on this. Professional genealogists will always say you should cite the specific source YOU got the information from. ---which in many cases these days is going to be a Gedcom or some other ephemeral source. I personally don't think they are useful, and would not cite them as such. But for some there is merit in citing them. If nothing else, a citation to a GedCom tells you something about the genealogical sophistication of the person citing it. I also agree that There is a certain unfairness about putting oneself in the position of vetoing other people's sources and yet not being willing to provide better ones yourself.
While I'd probably keep identifying Gedcom's as "MySource", killing GedCom's as sources makes it (more) clear that a proper source is still needed for a specific datum. if there's something in the blank---even if that something is a GedCom---then its got a source, so the perception is that there's less need to attach a proper source to it. Sort of a human nature thing. Empty spaces demand to be filled, but spaces filled with not so good stuff are much less demanding of attention.
There are advantages and disadvantages both ways. They aren't of much use to me, but for the original submitter they may have value. Apart from offending some sensibilities, they don't do a great deal of harm (some harm, but in the grand scheme of things, not much). I certainly wouldn't recommend going on a search-and-destroy mission against GedCom Citations. Some battles simply should not be fought (at least directly). Q 17:24, 8 June 2009 (EDT)
I've seen a suggestion that folks insert the template {{cn}} {{cn}} meaning "Citation Needed" and that may serve a good purpose but I wouldn't want to substitute that for a source named "GEDCOM of so-and-so" because then I would lose the info of who I got the info from. Perhaps both could be used and then removed when better sourcing is available.
I see this as another indication of the tension that exists between professional genealogists and hobby or family genealogists. It's good to want the site to be the best possible, but a condesending attitude toward unsophiticated genealogists (when setting up the 'rules') will keep a lot of folks at arms length. I've learned a lot from just lurking around the watercooler and will continue to learn as long as my somewhat amatuerish attempts are encouraged and accepted. Dallan said one time that the site would need all the eyes it could get. So I'd recommend we not tell anyone their sources are unacceptable by removing them without replacing them by something better. Just my 2 cents worth. --Janiejac 22:00, 8 June 2009 (EDT)
I'm certainly not a professional genealogist. I also strongly believe that werelate needs to make effective use of folks from all over the spectrum. Still, I think I would draw the line at sources that are only useful to one person. I don't think it's too much to ask that sources provide enough information that a dedicated researcher could find and review the information themselves - whether that requires going to a far-away library, web-site, film vault, or whatever. A "gedcom so and so" source leaves a follow-on researcher no where to go.
That said, I only remove those things when I encounter them on pages I'm cleaning up or improving generally. I don't touch a page just to get rid of such sources. If I do touch the page though, I won't be preserving them either. Not because they're offensive - they're just not useful. --Jrm03063 23:25, 8 June 2009 (EDT)
Agree with JRM. Sources that are useful only to one person are equally as useless as no source at all. In my experience, the vast majority of people that cite gedcoms don't have any further information, and if they do, you can usually tell from the citation itself. The junk asdfas.ftw (I exaggerate not) sources that proliferate need to be removed because they set a bad example, they look horrible, and they obscure any useful information on the page.
I agree that GEDCOMs are not the best source. However, I think we need to be careful of the "the data must be junk if the source is a GEDCOM" mindset. I have had instances in my own research where I've seen something on World Connect that had another GEDCOM as a source and it got me thinking, "Hey, I never looked for that marriage in that county." I didn't take the marriage fact on World Connect as being accurate, but I certainly used it as a clue -- and then found the marriage record in a book of published marriage records for that county. My point simply is this -- when you see a "fact" whose source is a GEDCOM, don't assume it's true, but don't assume it's junk, either. Use it as a clue. --Ajcrow 08:41, 11 June 2009 (EDT)

Let's also please distinguish what we mean by imported GEDCOMs. At least some of the more popular genealogy programs (e.g., FTM), automatically create a "source" citation for each piece of data that comes from an imported GEDCOM. So if you import a GEDCOM, FTM creates a "source" with the name of that GEDCOM file, and adds a citation to every single piece of information that comes with that GEDCOM. I *believe* that FTM has created an option for turning this off in newer versions-- I no longer use the program-- but I think the default is still the above behavior. When I used this software, and helped others who were using it, I recommended that we edit the master source list and change, for example, SMITH.GED, to something like "Personal research of Jillaine Smith, Bethesda, MD (email address)" or something like that. When so changed "SMITH.GED" becomes far more useful information. But without that, the name of the imported GEDCOM file means NOTHING. It's not really a "source". And frankly, FTM's default setting for this (and any other program that does the same) does a disservice to genealogy work by not encouraging people to rename this source upon importation. So I throw my vote behind those who say, get rid of this "clutter" (SMITH.GED).

I'm not familiar with what happens when someone imports a GEDCOM from Ancestry. I've never done that (shudder). But I'd use the same criteria. If the resulting source citation makes it clear exactly where the information came from (i.e., I can find it independently), then keep it, but if it only says "GEDCOM from Ancestry.com", toss it.

jillaine 08:32, 11 June 2009 (EDT)


Points well taken. While its difficult to do, I have been able to track down information obtained from GedCom's to the original source. Usually not worth the effort, so I do that only when I have something especially interesting. Still, it can be done, which is to say, these sources are not without value. Given the pervasiveness of their appearance on Werelate, its not really a useful effort to search and destroy them. If it needed to be done, its something best left to the machines. Ultimately, Dallan will either do something systematically with sources like this, or he'll allow them to persist. Q 09:18, 11 June 2009 (EDT)


It is clear nobody likes GEDCOMs, and when there is a better source available that is based on primary evidence like town records, wills, deeds and the like, then I agree, delete the GEDCOM source. But many published genealogies are hardly better than GEDCOMS when the author does not take the time to explain where their data comes from or the primary sources it is based on.

Like Ajcrow, I believe the existence of a GEDCOM is better than nothing. And a GEDCOM is not entirely useful to only one person, as there is the possibility of contacting the WeRelate user that cited the GEDCOM and getting them to provide additional information, like a copy of the GEDCOM, or notes that accompanied it, etc. I have individuals I have researched pretty thoroughly over many years where the only source of certain data still remains an AFN without sources. Because the data is consistent with everything else I know, and assuming there is some basis for giving the precise date shown, I accept it probationally until I find a better source. I recognize that such a source is not proof, and so it does not represent an endpoint, but to ignore this, I would have to think the author was simply making up data.

One point I don't see discussed specifically is what is meant by a GEDCOM. Jillaine's comment would seem to agree with one point I proposed at the beginning, namely, for One World Tree and WorldConnect trees, one should look at it first and determine its quality before removing the citation. If it is one of those that has sources, deleting the pointer to it is bad. I think websites also fall into this category. Some websites are very good about providing sources, the Pane-Joyce website comes to mind, the Carew-Lundstedt world connect also.

--Jrich 09:36, 11 June 2009 (EDT)


I'd like to re-raise this topic. I think a poor-quality source is better than no source at all. I hadn't thought about it before, but I can see that even a GEDCOM filename may be useful to help prompt a contributor to remember more information about where they got some information from. And I think GEDCOM files that include the name of the original contributor and One World Tree or World Connect references have some value, especially if no other sources are listed. Also, I hope that even newbies feel comfortable at WeRelate.

Having said this, half a dozen filename-only GEDCOM citations are unnecessary and make the page look cluttered. How can we achieve both goals: keeping GEDCOM sources that might have some value and making newbies feel included, but not keeping so many that pages end up getting cluttered?

One thing I could do is exclude filename-only GEDCOM sources by default during the GEDCOM import process, and in the upload instructions explain that filename-only GEDCOM's aren't very useful in a community website so they're excluded by default, but if they wanted to rename their source to list the website (even a facebook page) of the originator they're welcome to do so and include the source. Excluding filename-only GEDCOM sources as part of the upload process seems less "harsh" than having them omitted after-the-fact when the pages are merged.

If we do this, what do we do about the existing filename-only GEDCOM sources? Should we recommend to remove filename-only GEDCOM citations only when there are better sources on the page? Alternatively, there are less than 1000 MySources with the letters ged or ftw in the title, and they come from just a few dozen people. Maybe we should contact these people directly and explain that we're trying to clean things up a bit and remove filename-only GEDCOM sources?

More thoughts?--Dallan 19:36, 22 June 2009 (EDT)

One reason you find so few ftw sources may be that they are in notes rather than in the source fields. I don't know which programs do what with stuffing info into gedcoms, but the most useless pages that I encountered in duplicate cleanup have nothing on them but five or six different notes with a .ftw filename in each. Merge a few of these guys and you have a page full of nothing but filenames. So I can understand why someone would have suggested we clean them up. But I do think we can go a little too far with this. When I find MySources for gedcoms on pages that contain useful information, I'm inclined to leave them there. The same for emails except that I'm uncomfortable leaving someone's email address on a web page.--Judy (jlanoux) 21:06, 30 June 2009 (EDT)
I stand by removing them completely. In 10 years on WorldConnect, I have never seen a gedcom filename source that was any use for anything. If the poster cared where it came from, there are other notes included about the person who sent it (which are also rarely helpful, but sometimes I can see it happening). I am also completely fine with discouraging users who think that is useful sourcing. If removing what they should know to be useless--doing it for them even!-- discourages them from further participation, then I'm okay with that -- because it should prompt them to understand that they have not been properly sourcing their material and start to fix it, not get them righteous and pissy. Also, I've removed a number of file name only gedcoms from pages of the worst offenders (this was useful mindless work when feeding at 4am), and I've never gotten the least response, I would be shocked if they protest a widespread removal.--Amelia 21:18, 30 June 2009 (EDT)

I'm with Amelia and reiterate what I said above.

If the "source" is SMITH.GED or AncestryFile or PublicTree or OneWorldTree without any additional identifier, then TOSS it. A valid source enables another person to find and review the information themselves.

If the source information enables you to find it, then keep it. E.g.:

-- jillaine 21:50, 30 June 2009 (EDT)

As a pretty new user, who imported data from Ancestry, I'd like to say a few words about gedcoms...

First, I've learned ALOT in my few weeks on werelate about the work involved and the value in documenting sources. I can't tell you how many times I've scratched my head trying to remember how I learned some particular fact regarding a person... and now have to retrace my steps and try to find it again, and DOCUMENT it this time.

And, I am absolutely clear, after just a few weeks at werelate, that Ancesty made me very lazy as a genealogist. It is easy to add lots and lots of names to a tree, with the best intentions of researching them "someday," and where the only legitimacy these names have is that somebody, somewhere, wrote it down and thus I can copy it.

But it's also true that when I first began doing genealogy, GEDCOMs and OWT, etc. were invaluable in helping me make connections and possibly find other sources for my family names, and to tie my family names to a larger context. It was really exciting to go far enough back in my Slocum line, for example, that I hit upon the Slocum names in the WeRelate database and could connect up my line with others.

Often it is sibling lines that produce a source that (in passing) confirms a fact for my particular ancestor. And GEDCOMS, even One World Tree, can give you some clues to who these siblings might be, or who they might have married.

Of course, GEDCOMs should be added selectively and reviewed carefully. For example, I always decline to add completely undocumented (no birth or death date) children to a family in Ancestry, figuring I can always add them later if other "real" sources confirm the children. And I check dates, to make sure the children are born while their mother is alive... In some (admittedly rare) cases, there are good (and well documented) facts in a GEDCOM. In my area, some of the best information available on genealogy in a neighboring town is on One World Tree (thank you Martha Croasman!!), and it's been an invaluable resource for me.

I realize that for a genealogy wiki, like WeRelate, GEDCOMs are often useless because it isn't a source that can be easily shared. But a new user is likely to come to WeRelate with a certain amount of GEDCOMs in their data. Some are going to be decent data with sources, some will list (without sources) a bunch of facts that can be sourced in other ways, and some will be completely useless (and erroneous) data.

I like Dallan's suggestion of excluding filename only GEDCOM during the data merge, and I especially like the idea of renaming them/keeping them as a MySource if they happen to be the rare Martha Croasman-quality GEDCOM source. I wish I had been able to do these things during my imports, as it would have saved me a lot of ruthless cutting out of these sources once I had uploaded data. What I was left with after I cut as many One World Tree and Ancestry Tree references I could find, however, was a bunch of facts that I now had to go out and try to find the real sources for. This will probably keep me busy for the rest of the year(!), but I don't object to that (insert wry grin here).

But I do think that rather than focusing on the symptom -i.e. GEDCOMs-we should focus on the underlying problem: the need to document sources for the facts we acquire. GEDCOMs aren't so much a problem (they are just clutter) if they are an extra citation for a fact that is otherwise sourced. The problem really is the number of facts/persons/families that don't have any sources, or no sources except an unspecified GEDCOM. I was astounded (and a bit overwhelmed) at how many of these I have even in the very limited family trees I have added to WeRelate so far. I'd like to spend some time writing some help for "The Ancestry User at WeRelate" (for example), to try to help other users like me find the real sources that support the facts/names/families we are importing. Sorry to go on and on... I'm a writer and not yet concise enough for the web, apparently... Brenda--kennebec1 23:04, 30 June 2009 (EDT)


Brenda, I agree with your sentiment entirely.

And I want to try and make a specific distinction between viewable and non-viewable "GEDCOMs". By the former, I am thinking specifically of One World Tree and worldconnect. Jillaine, your worldconnect citation is the same as a OWT source in that you have to go to the website to see if it has sources. Many do not, and your citation could be thrown out through guilt by association as easily as OWT. Heck, many WeRelate pages have no sources, so maybe we throw them all out too.

If it is a website, then you have the capability of going to the website to see if it has sources or not before you nuke them. A filename-type GEDCOM that exists only on some unknown person's computer may be something you can never inspect, so I am not talking about them, but verifying OWT and wc.rootsweb is just a matter of applying yourself. Many public libraries and many Family History Centers can probably provide free access to ancestry.com to view OWT. If it is not important enough to you to visit a local library and check it out, I would suggest it is not important enough to you to delete, so leave it alone.

As I have gotten deeper into certain families, I have even discovered that submitters of certain Ancestral Files are known to me as early computer-age family experts, so I hesitate to treat even all those the same either. Unless there are better sources, or conflicting sources, I think it is dangerous to just paint them all with one brush. If it is somebody you or I are researching, you or I are probably capable of making that judgment and provide better sources, but in the general case, you could just be denying another researcher a clue that they have the interest to pursue until they find the underlying evidence that spawned that poor source citation. Then WeRelate loses because they do not replace the bad source citation with a better one. --Jrich 23:51, 30 June 2009 (EDT)


Brenda,

Thank you for your thoughts -- that's a great example of the best benefits of WeRelate. But I should clarify that we're not talking about removing data sourced by gedcoms. Only the ugly and 99.9% useless filenames used as sources. Those sources tell you just as much about the data as nothing does -- "I found this somewhere." That's good, and it may be helpful to the person who uploaded it. But the chances of it being useful to any other wiki user are so slim that it does not outweigh the damage: the impression that such sources are appropriate. And if the gedcom name really does hold some hidden meaning obvious to people familiar with the page, then the deletion will hopefully prompt the interested people to make the meaning not so obscure. (This is why I don't include "Research of so-and-so" when I'm deleting gedcom files -- that person might be a family expert to those researching the family.)--Amelia 11:52, 1 July 2009 (EDT)


It doesn't matter how you cut it, data that simply cites a GEDCOM, WFT, AF, IGI or any other website as a source is not sourced. If the website cites a source, use that, otherwise the source reference is useless. If you don't delete it because you have no better source, the process of improvement is impacted. I'd rather see citation needed than a URL or e-mail address for a dubious source. I'm not saying to delete the data, if it makes sense, oftentimes it is correct and the source may be found eventually. but there is an awful lot of bad data out there too, from "The name's the same so it must be him", or "if it's in a book somewhere it must be correct" to outright fraud perpetrated by charleton genealogists. If 5 GEDCOM collectors copy it and post it at WFT or AF that does not provide any more credibility to it. Ideally all source citations would reference primary contemporary documents, but we don't live in an ideal world. There are, in fact many responsible secondary sources such as the Barbour Collection, Savage, Torrey, Jacobus, Virkus, The great migration series, the Mayflower 5 generation series, TAG, NEGR etc. In my experience, a great deal of information that I have found which was lacking source documentation has proved to have its origin in legitimate source documents. If the source is dubious, the citation should be deleted but unless the information is refuted, the information should be retained. Hopefully over time if the data is wrong it will be corrected or if it is correct, a proper source will be found and cited. As more and more material is digitized and made available on the internet (Google Books, FHL digitizing of their collection etc) and with improved search engines, we as a community will be able to find and document source citations with increasing authority.--Scot 16:03, 1 July 2009 (EDT)

Some IGI records are actually transcripts made of primary records by volunteers from FHL films, so are pretty good sources. Others are simply member-submitted records and on a par with AFNs. You have to look at the source to tell which is which. I get a little sentimental about a few select AFNs because I have spent years trying and haven't found anything better, and found confirming sources enough to say the dates they give are within say a year, but in general I agree that GEDCOMs, WFT, almost all AFNs, member submitted IGIs are not useful. I was trying to make a distinction with web-based sources where you can go see if they have sources like world-connect and OWT. Oh, and I don't pay much attention to family tradition either, having seen first hand multiple times how unreliable it is even after one or two generations. --Jrich 20:55, 1 July 2009 (EDT)
While I agree with just about everything said above re GedCom, WFT etc., the suggestion "If the website cites a source, use that" is problematical. If you want to cite a source that you haven't actually seen, the best way that I've found is to identify the ultimate source as well as can be done, but add the word "fide" (faith, taken on faith, etc) and the intermediate source where you found the information. Even if no one can ever get back to that specific source, you've announced that you took it from a specific location, and that the information needs to be verified in the original source---to which you've provided a citation by which it can be pursued at a later date. To just cite the ultimate source implies you've seen it, and verified it, and vouch for the accuracy of the statement. If you have seen it, etc. then by all means cite it. But if all you've got is an intermediate source, you need to indicate that you haven't actually seen it, but are taking this on faith until time permits verification. Q 18:09, 1 July 2009 (EDT)

All well and good, but if one restricts editing to that which is directly available to him or her, very little will get done. Perhaps we need a source field for confirmation by someone who has seen it, at least we have told them where to look. How many views does it take to vet a source. If you say you have seen it can I believe you or must I see for my self? if we both see it can others believe us etc.? Ultimately it must be taken on faith. The point of the wiki, as I see it, is the power of the community to gather the best knowledge available to each of us. As none of us has ready access to all available sources. Make it a 2 step process, citation needed, source confirmed. If a GEDCOM has an invalid citation, returning there does you no good.--Scot 19:05, 1 July 2009 (EDT)


Citing sources: If I locate a webpage or gedcom that has documented information then I cite the webpage or gedcom and also cite the source referred to on the webpage or the gedcom making it clear that I have not viewed the source. Obtaining a copy of the source is then added to my to do list; so yes I must see it myself eventually. It may be 5 years from the initial references. For example, on some of my pages you will find marriage records cited from Ancestry. Some of them I have already replaced with the actual marriage record and uploaded the image of same. So if someone has a copy of the source, I expect the user to also upload the image of the document. This enables one to evaluate the source and conclusions drawn from the evidence from the particular source. --Beth 20:19, 1 July 2009 (EDT)

I routinely scavenge things like Ancestry lineages, particular where the author includes notes, because there are often bits of information contained therein that prove quite useful. If the source I'm looking at provides a citation to where they got their information from, then I usually record both the intermediate and original source until such a time as I can get to the original. Often I can get to the "original" fairly easily---especially if its not the actual original document, but a compendium of information such as Chalkley's. If the material I'm using provides no sourceing, about the only time I'd bother citeing them is if they had an especially nice writeup---well thought out, information rich, just lacking in sources. Then its worth crediting them for their understanding. But usually, information that's not backed up by sourcing information is, I agree, not worth crediting. Its just data that is probably right, but needs to be recovered from its original context. But if you cite the original source, with no indication that you didn't actually see that source, you're doing yourself a severe disservice. You are assuming that the person has things exactly right, and that its an accurate transcription, or an accurate interpretation. So if there's an error in it, and you don't explain where you actually got the information from, then the error is yours, and yours alone. And yes, it takes time to document properly. That said, would I cite a GedCom? Probably not, because its probably not revisitable in the first place. Q 21:39, 1 July 2009 (EDT)

Q is right, but as to what you do on WeRelate: if you haven't seen the source you should mark it as such when you enter it on a page (i.e. cited on WorldConnect, or just cited elsewhere, etc.). If someone else comes along and has seen that source, then they remove that notation, and hopefully can provide a snippet or image. If they remove the notation and it turns out wrong, it should eventually be fixed when someone who has seen the source can rebut it. Ultimately, through collaboration, we have a page that reliably relates that a particular source says a given thing. But in your personal research, you should still mark it as "cited on WeRelate" until you've seen it yourself. Hopefully, in time, "cited on WeRelate" will be considered more reliable (because of the power of many) than "cited by Joe Blow", but that doesn't change what you ultimately should do.--Amelia 00:21, 2 July 2009 (EDT)
The term for what Amelia is describing is "reference verification"---the art of making sure that "Smith, 1639" says "the moon is made of green cheese". The other part of this is "reference validation"---the art of making sure that Smith's observation about the moon and green cheese is in fact correct. In genealogy its not at all uncommon to find that a source doesn't actually say what someone says its says. Usually, any discrepancy is innocent, but I know of instances where there were deliberate falsifications. There was a certain New England "professional" genealogist, I'm told, that like to add a few extra details into his transcriptions, so that he could "prove" the connection needed to satisfy his clients desires to be descended from Charlemagne, Louis the IVth, or whoever. None of his clients ever checked to see if the documents said what he said, so he ran a very profitable business for many years, with many pleased clients. Its only when his work started to be disseminated, and used by others that people started finding discrepancies between what he said was in certain documents, and the actual content. But this deliberate falsification is rare, I think. In most cases its just information misunderstood, transcription problems, and other innocent mistakes.
In the past, when I've thought about this in the context of WeRelate, I came to the same conclusion as Amelia---that there was a really good opportunity here to systematically verify data, and record their findings. They might say something like "I checked the LDS microfilm XYZ for this document on 1 July 2009, and this is an accurate quotation of whats in the microfilm." Or better yet "I checked the original document that was microfilmed by the LDS, and verified that this is an accurate quote." That's a fair bit of trouble, and I don't think we're ready to do anything like that, at least systematically, but eventually, that's what's going to start taking place. Q 11:49, 2 July 2009 (EDT)

After reading the above I'll propose that we:

  • Exclude filename-only gedcom sources during gedcom import by default. We instruct the uploader that if they can add a way for people to contact the author (website? facebook page?) then they can include the source and it will get imported as a mysource. But filename-only sources that others can't reference aren't useful to a community website.
  • It's ok to remove filename-only gedcom sources during merges as well.
  • Regarding online tree sources: OWT, AF, etc., these are ok but can be replaced as pages "mature" and better sources are found.

Would someone mind adding this information to the help? If anyone disagrees strongly, please say so.--Dallan 00:29, 4 July 2009 (EDT)

Someday, "An Ancestry user at WeRelate" would be a nice help page. :-)

Also, I fully agree that the real issue here is that we need to make citing proper sources easier. As more sources go online, especially onto free websites, we need to make it easy for people to cite them.--Dallan 00:29, 4 July 2009 (EDT)


Updating Sources & My Sources [1 July 2009]

I'm a new user, and I uploaded a gedcom from FTM. I admit it... I have some lines that I haven't spent as much time on, and are essentially "placeholders" for presumed data (often reference OWT or Ancestry Gedcoms). But I'm working on cleaning up my sources and my data on the wiki; it will just take some time.

So I have two questions relating to this:

  • Is it appropriate to make a note on these pages that are unsourced or that are only sourced with OWT that I *know* there is a problem, I believe there are sources, but I haven't gotten back to them yet? Alternatives would be to delete all such individuals/families from my tree and from the wiki, which seems not that useful, as someone else may know something I don't. This is a good example where a category such as "needs sources" or "needs help" would be good, if only because I could then search for the pages in my trees that I need to do work on when I have a few moments to travel down another line...
All genealogy is a work in progress. If a data element is shown as unsourced, I think the presumption is that we're waiting to find an original source that supports that particular data element. Blank sources represent unfilled needs. Eventually, those needs should be met, either with original (aka primary or secondary (aka derivitive) sources. In the meantime, blanks are simply needs to be met. Whoever happens to be working on a page might meet those needs if they can. Sometimes people insert the template {{cn}} {{cn}} meaning "Citation Needed" Q 19:56, 8 June 2009 (EDT)
Hi, Brenda. I was a new user not that many months ago, though I've been around wikis for years, and around genealogy for decades. We all upload or create pages that need sources, or that need non-laughable sources. In fact, creating such a page and putting it out in public is a good way to embarrass yourself into doing the necessary work.    :)    The method for keeping track of this that I came up with was to create a tree called "Need Sources," which functions as a "to-do" list. After I import a GEDCOM, I go through the list of pages, cleaning up each one, and I add the unsourced ones to that tree. Now I'm spending a certain amount of my time working my way through that tree and searching for sources to back up assertions from other researchers, from family mythology, or whatever. Easy to use because you always have access to your trees. --Mike (mksmith) 09:02, 10 June 2009 (EDT)
  • 2nd question/request: Is there a way to show all the person or family (or other) pages that use a certain source? I would like to update some of my imported MySources to regular sources (i.e. Census records, vital records). But I sometimes need to know which person used that source so I can correctly link to or create the Source. A good example is the 1790 Census, which imported as just the U.S. 1790 Census. Without knowing which person I imported with that reference, I can't tell what the specific census location was so as to correctly title a new Source page, or search for an existing Source page, or even update the MySource page to be more useful. I think a function like the "contains" for geography (or contained within) might work? --Brenda--Kennebec1 17:45, 8 June 2009 (EDT)
Hi Brenda, welcome to WeRelate. It is not necessary to delete your pages that are essentially "placeholders". You may use this category Category:Source citations needed. Type the category, as written here, but omit the colon before the word Category in the edit section of your page.
Regarding the second question, your mysource citation for the 1790 census should be on the relevant pages. I believe you must change each MySource individually. Also you may perform a search for your pages. Use the search feature on the blue menu bar. Select Search WERelate>watched pages>MySources>and enter the source name. That should work. --Beth 18:14, 8 June 2009 (EDT)

Thanks Beth and Q - I like the template and the category and will use them. I think I have figured out how to use your suggestion, Beth, to find watched pages that reference a specific source, but I still think it would be helpful if a MySource page had links for the specific people/families that reference that MySource.

When you import a GEDCOM with its attendant mix of quality in the sources and duplicate sources, the good news is (for We Relate) that all sources become MySources and don't "mess up" the Sources used by everyone. So what I want to do as a new user is go back and assess my sources (i.e. all of kennebec1's MySource pages), correcting references, deleting duplicates, and manually transferring some MySource references to a common Source reference when applicable, so that I'm sharing the common language and sources of WeRelate (and anyone, not just another Ancestry user, can find my sources, which is one of the primary reasons I'm going through all this trouble to translate my Ancestry files!).

I think if I could (more directly) tell which pages referenced a MySource page, or even how many person/family pages reference a MySource page, it might ease the process of updating the (relevent) MySources to Sources. It would definitely help me prioritize which MySource pages I wanted to update and correct first. But maybe I'm just having an obsessive moment. Anyway thanks very much for the quick help with using WeRelate. -Brenda


Most pages, not just MySources, have an item "What Links Here" in the More menu at the top. Click it and you get a list of pages that refer to that page. So visit your MySource page, click on "What Links Here" and you should have a nice list of all the Persons and Families that cite that source. --Jrich 09:10, 9 June 2009 (EDT)
Brenda, as they said, "What Links Here" works fine for what you want. The larger question, though, is which MySources you want to be in a hurry to convert to "real" sources. I've been creating Source pages for published books and articles and such as I go along (because there's a canonical form for published materials), and I've made up many dozens of new census pages (which is easy because the format used here has been more or less decided by consensus). But when I search for a primary source ("Perry County, Indiana, marriage record books," etc), I usually find a wide variety of previously-created sources that match . . . more or less. And many of them are badly formed. And Dallan has been talking about revising/redesigning the whole source-related section of the code for the site. As a result, I've left my original sources as MySources for the time being. When everything shakes down and decisions are made, then I'll go back and turn all those MySources into real sources. And that's what I would suggest you consider, too. --Mike (mksmith) 09:02, 10 June 2009 (EDT)

Hmm. That is a good point, Mike. As you note, many of the MySources I am interested in converting are Census locations that are not currently in the WeRelate Sources, and I'm using the current rules (I think) to create new pages, i.e. United States, State, County. XXXX U.S. Census Population Schedule. I suppose that for as long as I continue to be the only one working in this locality, it really doesn't matter if I keep MySources or add new Sources.

Most of my 19th century ancestors are in either Indiana or Iowa, so I've been creating numerous census source pages with every GEDCOM I upload. Just to keep track of what I'm doing (and because I'm almost a pathological list-maker . . .), I've kept a list of all the census pages I've created in a text file, and a similar list of all the book and other sources (including MySources) in another file. I keep those two files open in NotePad in the background when I'm working on adding material to pages or expanding what's listed in the source notes, so I can just copy/paste the correct form into the proper field. Much quicker than tying out a full census source title, too. It also alerts me to census source pages I haven't created yet, if I don't find them when I search. And having a full list of all my MySources, I can at least try to make them follow a reasonable and consistent pattern. --Mike (mksmith) 19:05, 11 June 2009 (EDT)
I'm glad to see people creating standard census sources... a couple things 1) know that many if not most counties pre 1880 have entries in the system already that just need to be edited/renamed; 2) please add the relevant template ({{XXXXCensus}}; and 3) the relevant category ([[Category:XXXX State census]] - lower case 'c'). This puts some useful links to that year's census information on the page, and populates the category hierarchy (currently helps tracking, can later help browsing). Thanks!--Amelia 19:13, 11 June 2009 (EDT)

Or they are, as you describe, published titles or vital records where the search for sources turns up multiple versions, most of which are not in the "correct" format. I've been selecting the "most correct" of these options, adding updated information on alternate repositories (such as Google books), and generally trying to update the sources I've used.

On the one hand, I hate to do all that work if we're going to change the rules... On the other hand, one of the reasons I'm attracted to WeRelate is that I really like the idea that we can all share sources (and share access to sources, when possible). So it makes me feel "helpful" if I can update information on a Source that is used by others. But I can see that figuring out what the guidelines should be for sources isn't easy, and isn't yet complete.

As a newbie, as best I can tell, I've tried to avoid the controversial topics (such as what the Page Title should be) and instead just updated info on the source and repositories. But I do still find I'm not at all sure what is "supposed" to go in various fields. A good example is when adding a repository to a source - should the link be to the generic page for that repository (Google Books, Ancestry.com) or to a specific location on the site where that source can be found (what appears in my browser when I go to the Google Book or Ancestry page)? - Brenda

I have to confess, I don't worry too much about repositories any more-- simply because there are so many these days. I mean, the "repository" for a grave marker is the cemetery, and that's unlikely to change. But what do I care whether I've read the original census page on Ancestry, or on microfilm at my old library in Dallas, or on film at my library in Baton Rouge? It's exactly the same image. Ditto for published books -- as long as it's the same edition, or a photoreproduction, so the page numbers match. I've downloaded a number of 19th century county histories from Google Books for quick consultation, and those are exactly identical to the hardcopy books I may have consulted at Dallas or the Filson Club or the Iowa Gen Soc library, or wherever. It simply doesn't matter. If someone posts a scan of a Civil War pension record on their personal website, or GenWeb, or Ancestry, I can save a copy of that scan to my computer and cite it as an original document source -- because it is. But what's the repository, and why does it matter? Yes, the original is in the National Archives, but not the copy I actually use. Genealogy -- heck, research in general -- has changed enormously even since I retired a decade ago, much less since I began doing this stuff in the late '60s. --Mike (mksmith) 19:05, 11 June 2009 (EDT)
I'm with you, Mike, on the repository for census records and military records. I think the most useful application for "repository" is for rare/small-run books. True, we can always look things up on WorldCat, but (1) not every repository is on WorldCat and (2) even those that are on WorldCat have their entire collection listed. --Ajcrow 19:18, 11 June 2009 (EDT)

I am wondering if it hurts anything to just put your sources in the notes field?

I must confess to being the only one at we relate whose brains dribble out her ears when she reads the source field instructions. I feel overwhelmed by them and as they become more and more formal it makes me afraid to add anything to anyone else's pages or work with anyone because I have source field anxiety. Last week I had a lovely document I thought a WeRelate person would like (scanned primary document) but didn't put it on her page because I was afraid that if I just wrote "Davis County Iowa Deed Book 4 p. 32" in the notes field I might annoy them for not understanding the art of the source field.

Does it HURT anything for me to move my sources to the notes field so they don't become anyone's problem if they are not formatted properly or I never do comprehend those source field instructions? Anne--MizLiv 17:16, 1 July 2009 (EDT)

Well, that's some evidence that we've crumped up the fields (which are currently under redesign discussion). But at any rate, gosh no, never feel bad about adding new information, even if you don't know how to format it. Plain text in the notes field is just fine! If someone else watching or happening along feels one way or the other about it, they'll fix it. It's a group effort!--Amelia 17:23, 1 July 2009 (EDT)
Anne - Any time you have a primary document, please get it onto the page anyway you can. Someone, someday is going to be very grateful to you. The beauty of having a wiki is that the 'prettifying' folks can come along and fix it up if they feel like it. Sometimes when my brain isn't into heavy lifting, I just visit a few pages and tidy things up a little. But, I confess, getting the information out there is my primary goal.
As Amelia mentions, we are into design discussions and one of the concerns is making the edit pages easier to use. Any comments on what gives you difficulty would be very useful. --Judy (jlanoux) 18:32, 1 July 2009 (EDT)

POB and POD conventions [28 July 2009]

I believe I saw some discussion recently about how to list place of death, place of marriage, place of birth during periods when the county boundaries were changing. That is, someone was born in what was then Washington County Virginia, but where they were born is now in Russell County, because Russell was not created untill after their birth. Was a convention arrived at as to whether to list the POB according to the area as it was known at the time of birth, or as it later became know. Or is it catch as catch can, user beware? Q 13:59, 16 June 2009 (EDT)

And from the discussion below, I'd say its quite clear that the answer is "catch as catch can". S'all right with me. As someone pointed out there's no substitute for knowing your geography. Just wanted to check to see if a convention was actually adopted. There wasn't, or at least there seems to be no concensus of opinion. Though I do like Mksmith's rule that you follow what the documentation says---assuming your looking at primary sources. And anachronisms also drive me crazy. Q 21:59, 20 June 2009 (EDT)
I run into this a lot with West Virginia counties, and also with southwest Pennsylvania, where the state sometimes changed as well as the county. The rule is to record what the original source says. If it's Yohogania County, Virginia, then that's what you record -- regardless of the fact that the location is now in Fayette County, Pennsylvania. It's up to the reader to be aware of history. Personally, I hate it when someone's page says an ancestor was born in Harrison County, "West Virginia" in 1810. I see this a lot with European locations, too -- someone recording that an event took place in "Belgium" in the 17th century. Maybe it's my history background, but this sort of anachronism drives me crazy. . . . --Mike (mksmith) 09:32, 18 June 2009 (EDT)
I've read opinions here on both sides of the argument: that the most commonly used and best known named location should be used as well as opinions that the actual historical recorded name should be used. Regardless of which placename used as the primary location on your page, I would suggest that the other geographical reference should be tied into the placename used on your page by use of a "redirect," either through the use of "Alernate Names" or within the commentary itself. I get that a lot with my Cherokee ancestors born in the Cherokee Nation in the region of what is now Tennessee and North Carolina before the formation of those areas as states. (See the Cherokee Chota settlement as an example.) Being that some of those specific areas are now nonexistant as locations, a redirect gives a pinpoint reference to a known location (either past or present) -- or as close as can be determined. I also see that in many areas of what what known as Prussia (especially in the conquered Polish kingdom) when it was occupied by the Germans in the 18th & 19th centuries, where the Prussian authorities moved and settled Germans in those regions and used Germanic place names, and then Poland exiled and forcibly removed many of them after retaining control of those regions again in the early 20th century and renamed the communities by their Polish place name. --BobC 11:14 am, 18 June 2009 (EDT)

Don't forget - if you know a location with near GPS/GIS accuracy, the google map link/idiom can be put in the description field. Besides providing a clickable link, when the event is mapped Dallan's code will use that information instead of the place GPS as the map flag location. An example: Person:James Mason (13).--Jrm03063 12:19, 18 June 2009 (EDT)


When you say the rule is "The rule is to record what the original source says." are you referring to a WeRelate rule? (It is not the rule that I am aware of, as this seems counter to what I have read on various Help pages.) Also, this implies you are buying into your source's credibility without much circumspection. Not all sources are contemporaneous, it is not clear which single source should have the most authority, and even when all that is clear, some contemporaneous sources used colloquial names not well known that have become the cause of many research headaches (examples on request).

No, that's the "rule" in genealogy, and always has been. You reproduce exactly what the source says -- even if you know it's incorrect, or even if it doesn't follow some standardized convention. Nor does this imply that you're accepting the validity of the information. You can comment and interpret all you like -- after you quote what the source actually says. This principle applies to the spelling of names, identification of geographical places, whatever. Reproduce what the source says. --Mike (mksmith) 19:20, 18 June 2009 (EDT)
Right, so the rule applies to the text in the source citation and does not apply to the location field in the events themselves, which after all represent a summary of the totality of the sources, and hence no single source. --Jrich 20:39, 18 June 2009 (EDT)
No, actually, that's not what I said and it's not what I meant to imply. If the sources (whatever they might be) give you three different places of death, then you have three possibilities to deal with. You don't average them out, or summarize them into a "totality." You don't just pick one to put in the location field. You investigate the three sources until one of them turns out to be correct -- or probably correct, because you may never be sure. Until then, you record the three possibilities, and you present the three possibilities as possibilities. In fact, that's been my major gripe for years with software like Family Tree Maker: They don't properly allow for alternatives in dates, places, parentage, or anything else. Alternative possibilities remain just that, pending additional evidence that allows you to make a case one way or another. --Mike (mksmith) 07:08, 26 June 2009 (EDT)

What a source says belongs in the text of the source citation, if it is significant. What goes in the place field is the name of a Place page to link to. There can be many source citations each giving different locations, but a birth event may only link to a single Place page. The Place page will then describe the place and gives its history including alternate and historical names. It is my understanding that the basic Place pages follow the LDS convention of naming things as they were in 1900, so it seems to me, by default, one should should name things as they were named in 1900. There are plenty of alternate ways to add detail when you think that Place page name is misleading or incomplete. One is to create a new place that redirects to the 1900 name. Or use the description field. Or add a note. Or put comments in the text of your source citation. --Jrich 13:56, 18 June 2009 (EDT)

I'm aware of the 1900 convention, though I think it's pretty silly and entirely non-historical. However, this issue has been thrashed out before and I believe Dallan is planning to handle it by having "paired" source fields -- one for a standardized geographical name, so he can work his magic with GIS and so on, and one with whatever name the page's creator or editor thinks the reader ought to see, with consideration of time period, context, and all that. I assume this will be "piped," like page titles. --Mike (mksmith) 19:20, 18 June 2009 (EDT)
Arbitrary might be a better word. I don't necessarily think silly is appropriate because it solves the problem. After all, you could convert the 1900 locations into GPS coordinates pretty unambiguously. (Unambiguous in the sense that you know what the name means, which is what matters here. There is an inherent ambiguity when you attempt to convert an area name into a single point, that no naming convention will fix because the appropriate precision was never recorded.) With the 1900 scheme, if you could manage to develop a way to add the time-based information, it should be possible to translate the names to the chronologically correct name.
The GPS/GIS coordinates seem like a good way from the standpoint of being chronologically neutral. But I don't know if people will be able to deal with the preciseness appropriately. Many records where only designed to determine in which town, or which county, events happened, so attempts to bleed more precision out of them will introduce falsities. For each record that names the house where something occurred, or a battlefield, there are thousands where it is just assumed to be the subject's residence when they could have fallen dead working their fields 2 miles outside of town. Or they could have journeyed across town to their sister's house to have a baby. Even locating houses from colonial deeds that describe properties in terms of this tree or that tree could be hard. Also, working with the coordinates is an expertise most people don't have. It will be interesting. --Jrich 20:39, 18 June 2009 (EDT)
Mmmmmm. . . . I think all that is mostly a red herring. Knowing the location of some event to a tenth of a second of latitude and longitude is usually unnecessarily precise. In fact, it's immaterial. What we care about, mostly, is in what jurisdiction something occurred. It's useful to know that my grandmother died in her sleep at home and that my grandfather died in the naval hospital, because that tells me where to look for the associated records -- San Diego County in one case and the Dept. of the Navy in the other. But I don't care which tree at Shiloh a soldier died under. Likewise, the fact that one of my ancestors lived in Nelson County, Kentucky, in 1790 is what's important -- not the fact that his neighborhood was later carved off into Meade County. It was Nelson County when he lived there, and it's the Nelson County courthouse I want to go to to hunt for deeds -- not the Meade County courthouse. Saying they somehow lived in "Meade County" (merely because that's its current name) is not only historically inaccurate, it's misleading. They lived there then, not now.
The 1900 convention "solves the problem," you say, but I have to confess -- I don't see a problem. I have no difficulty calling a place by the name by which it was known to the people who lived there at the time I'm interested in. I mean, historians do this without thinking about it. I think we're going to have to agree to disagree on this. --Mike (mksmith) 16:41, 19 June 2009 (EDT)

I don't entirely disagree with everything you say, but I don't think there is one simple answer. In practice, I probably do what you are talking about most of the time anyway. If I find something in VR Salem MA, I use Salem, and for all I know, in 1900 it could have been that part of Salem that became Beverly, or Wenham, and so technically, I may have used the wrong location. Maybe someday, some researcher will figure out some of these locations precisely enough to tell, but given the information I have I don't know the actual location.

There is no substitute for learning the geography and history of a region. If you are in a research situation where multiple place names are involved, like Cambridge Farms and Lexington, you need to know this or you could miss a clue that is staring you right in the face. The more challenging the research you are doing, the more this is true. So anybody, except a newbie, can probably deal with either name, and will know where to look for sources, and will know what jurisdiction is involved, or will at least how to figure this out because they've had to figure it out for other places before. So fundamentally, either Beverly or Salem should be helpful, and if it is important for some reason, I suspect somebody will change it appropriately. You used the word immaterial, and in this sense I agree. I believe it incumbent on a serious genealogist to be prepared deal with all the possible variations.

Basically, place is overloaded. People may be trying to communicate one or several things using place names: where an event happened, where it was recorded, what the jurisdiction was, where the record is found. This is in addition to the issue of historical versus current names. But properly, I think the place should represent where the event happened. Where a record is found may be documented in the source citation, so that is not really what place is for, and a good genealogist should be able to figure out the jurisdiction from the actual event location, but not necessarily the other way around.

Nor do I think it is necessary for the Place fields in WeRelate to be historic. Now, in attributing data to sources, it is respectful and most accurate to transmit places names as they are given in the source citations. On one page you may easily have one source that names a place the way it was at the time, and another source that uses a modern name. In that case, the two source citations would each use different names for the same place. You could add clarifying notes. But the Place fields used in WeRelate are summaries, representing the final conclusion of what the location was after distilling all the sources, and they do not have any obligation to preserve the name used in any single source. Their purpose is to communicate the result in the clearest manner.

Some problems with using historical names to communicate are

  • they are not well-known (Cambridge Farms and Monomoit in Massachusetts, Number 5 in Worcester County of Masschusetts, Black Point and Blue Point in Maine, Oyster River in New Hampshire)
  • they may seem to imply migration when there was none (b. in Salem, d. in Beverly, yet all on the same homestead
  • they require a date to be specified exactly

These are the problems I think the 1900 convention was trying to solve. I find it awkward as you do, but I think, if used correctly, it would solve those problems.

You're right: giving the county that didn't exist in 1790 can be misleading, but trying to locate places on a current map using the historical name doesn't work so well either. A WeRelate page offers plenty of opportunities to add all sorts of useful information about a place ("the part of Plymouth Colony that became Plympton and later Carver", etc.) that can clarify these situations.

In 1790 you might specify Nelson County, but in 1793 perhaps you would be specifying Hardin County, and after 1825 Meade County would be correct. Or perhaps in 1790 you mean that part of Nelson County that in 1800 became Breckinridge County, and then after 1825 became Meade County. So even for a Revolutionary soldier, maybe he lived long enough that you have to check all three, or maybe all four, places? And since Meade County in 1900 is smaller than Nelson County in 1790, it actually is a more precise specification of location. --Jrich 15:54, 20 June 2009 (EDT)

Actually there is a consensus which is posted on the help page. Below is a copy of the information on the help page for places.


====How do I title places with jurisdictional changes?====

Suppose you have a place that used to be located in one place but is now located in another. For instance, Ravenswood, Mason, Virginia is now Place:Ravenswood, Jackson, West Virginia, United States. In this instance, Jackson County has now been cut out of the early Mason County and after 1863 that area of Virginia became part of the new West Virginia.

We recommend that you list the place as "Ravenswood, Mason, Virginia, United States" since that's where the event took place, but that you link to Place:Ravenswood, Jackson, West Virginia, United States since that's the current name of the place. In addition, it would be nice if you edit the Place pages involved to tell others about the place movement:

If you do this, then future GEDCOM uploads will automatically link "Ravenswood, Mason, Virginia" to Place:Ravenswood, Jackson, West Virginia, United States. --Beth 22:46, 20 June 2009 (EDT)


Another thing you could do in in addition to the above would be to create a Place:Ravenswood, Mason, Virginia, United States page that redirected to Place:Ravenswood, Jackson, West Virginia, United States. You would do this by entering

#redirect [[Place:Ravenswood, Jackson, West Virginia, United States]]

as the only line in the big text box for the Ravenswood Virginia Place page. Then links using the historical name that appear anywhere in text will automatically forward to the current (1900) place.--Dallan 19:36, 22 June 2009 (EDT)

I'm jumping in a few days late just to say that am I right that Dallan's approach would make the Mason County entry show up in the place dropdown? Am I the only one who uses that? Because it's very high on my pet peeve list to have junk show up in that list. If I'm trying to pick the right entry for "Ravenswood, Virginia", I'd rather not have two or three different counties show up. If there's a way to specify the "real" page, that would be okay, but otherwise it's making things more inconsistent instead of less (the purpose of the dropdown in the first place.--Amelia 00:44, 26 June 2009 (EDT)
If you created a "Ravenswood, Mason, Virginia, United States" redirect page, it would show up in the drop-down list (and would show that it redirected to West Virginia). I agree that many (most) of the current place redirect pages need to be removed, but in the case of the Virginia/West Virginia split, you don't think that a redirect would be appropriate in that case?--Dallan 12:51, 29 June 2009 (EDT)

I have to agree with Mike, in that it bothers me to see anachronistic information. The nineteen hundred convention renders every event in colonial America ocurring in the United State an anachronism. I have a man born in Brunswick County, Virginia in 1728, married in Lunenburg County in 1748 and died in Halifax County in 1780 yet he never moved. The place page for Halifax County states that it was formed from Lunenburg Co. in 1752, the Lunenburg County page says it was formed from Brunswick in 1746 and Brunswick's page says it was formed in 1720 from Prince George County and In 1732 the county received more land from parts of Surry and Isle of Wight counties. I don't see how redirects could possibly handle this. To determine what county his farm was in in 1900 is probably not possible. However the importance of the place name is to determine where to look for records and that would be determined by what the place name was at the time of the event. There are a host of similar issues involving naming. Did your ancestor come from España or Spain? Was his name Jóse or Joseph? It all depends. What was his Baptismal name? what name did he use? and so on.--Scot 12:35, 2 July 2009 (EDT)

Just to be clear, the problem with the man in Brunswick, Lunenburg, and Halifax Counties is caused by the historically accurate names. If it was one place, it had exactly one name in 1900, and all three references should name it the same way, according to the 1900 convention. Then a person would click on the Place and go to a place page that hopefully tells him how the county was formed and changed over the years so he can figure out where to look for records. --Jrich 13:06, 2 July 2009 (EDT)
Jrich, I think I'm misunderstanding you. Are you saying that the man in Brunswick, Lunenburg, and Halifax Counties should be listed under only 1 county? --Ajcrow 19:10, 2 July 2009 (EDT)
As I understand how the 1900 convention is supposed to work, yes. As Scot pointed out, the man never moved but it looks like he did. Whereas, if the convention was followed, all the events would be listed in the same location. Hopefully, the source citations might show that the information was found in different counties because different entities had administrative control handled record-keeping at different times. But for the casual reader of the page, showing all the events with one location would communicate the story better than with 3 different locations. A casual reader is much less likely to understand the history of the county than a researcher looking for source. But either way, the county history can usually be easily found (wikipedia is often good for this, or county genwebs). --Jrich 20:12, 2 July 2009 (EDT)
But listing the location per the 1900 convention would confuse the casual reader, especially if they have (1) any knowledge of the area or (2) any curiosity to pursue the matter further. Using a different location as an example, let's say that a friend of mine was born and raised in Perry County, Ohio and knows that her county was formed in 1818. If she sees the location for an 1803 birth as Perry County, she's going to wonder if the person who entered the info knew what the heck he was doing. Using an artificial construct like the 1900 convention does nothing but add confusion. Let's say that the "casual reader" wants to follow up on something like finding a marriage record. The 1900 convention could put them in completely the wrong courthouse. Putting aside the historical inaccuracy of it, how do you know which location is correct per 1900? Take Washington County, Ohio as an example. It was one of Ohio's original counties. Which of the daughter (or granddaughter or great-granddaughter) counties do you list per the 1900 convention? --Ajcrow 20:26, 2 July 2009 (EDT)
Well I have a hard time defining a casual reader as someone who knows the history of their county that well. Also, this strikes me as a poor source citation if it doesn't provide a clarification, since whoever located the source must have known, and they aren't helping much by not alerting the reader. And as I pointed out many, many posts ago, I probably use the historical approach most of the time simply because I don't know if a vital record in Salem, MA refers to a spot in Salem, Beverly, Wenham or any of the other offspring towns, so I can only say what I know, i.e., Salem. Only if some source tells me that a person was born and died in the old homestead and their death is in Beverly, but their birth is in Salem, could I even deduce something like that. There are a very small handful of such locations out of many thousands that I have recorded in my research, that I can pinpoint well enough to be do that. --Jrich 21:17, 2 July 2009 (EDT)

I'm planning to split the event place field into two separate fields: the place as entered by the researcher (which should reflect the place of the event as it was when the event occurred), and the title of a Place page (which the system uses mainly for plotting events on maps). The first field will be displayed on pages and will link to the Place page. Based upon what you enter into the first field, the system will try its best to fill in the title of a reasonable Place page. You can override what the system fills in. This approach represents the simplest thing I can think of for handling historical place names. We don't want multiple Place pages representing the same place over various points in time, so the 1900 rule is one way to maintain just one page per place. But we want to allow the researcher to record the name of the place on the record. Does this sound ok?--Dallan 00:44, 4 July 2009 (EDT)

So, this solution would help resolve the "how to title a place with jurisdictional changes," correct? i.e. if something is entered into the researcher's place name page and the system doesn't come up with the right place, if I correct the Place page reference, will I be prompted to update the Place page to show the connection (meaning the time frame of this also known as place name, for example)? I'm afraid my language here might not be right, but hopefully you understand what I'm asking.-Brenda--kennebec1 08:18, 4 July 2009 (EDT)
You're not prompted to edit the place page, but if you edit it you'll see a box where you can enter other jurisdictions in which the place has been located over time, and you can enter year ranges for those jurisdictions.
I sort of knew (from Judy) that this was being planned as a solution to the place-name issue, and it sounds good to me. I'm not a techie (really) but I'm aware of the necessities that arise at the programming end of things. As long as the "real" place/time location is identified to whoever might be reading the page, I have no problem whatever with what the system creates for its own internal use. And if the page editor can override the "assigned" place name when the programming gets the matching-up wrong, it should work fine. --Mike (mksmith) 11:39, 4 July 2009 (EDT)
Yes, you can always override the assigned place.--Dallan 11:06, 28 July 2009 (EDT)

After thinking about this question a bit more, I realize I have an approach that I use routinely that may be of some help. In Southwest Virginia (as defined for the Southwest Virginia Project) there's a "cascade" of parent counties, with the area once described as "Washington County" becoming gradually broken up into smaller and smaller units, until today it is comprised of a half dozen or so counties. So, when someone was born in 1770 in an area now known as Russell County, it was at the time known as Washington County. My approach for capturing this disconnect is to describe this birth as occurring in "Old Washington County" or "Old Washington County now Russell County", or variations on this theme. In truth I usually use terms like "Old Washington County" more in discussions than in annotating things like POB. But the concept could be used by those troubled by the disconnects and anachronisms involved. Q 10:11, 4 July 2009 (EDT)

I might also add that my personal pet anachronism is when someone says that the person was born in an area that was not settled at the time of birth. For example "John Smith was born in 1735 in Washington County Virginia"; not only did Washington County not exist in 1735, neither did its immediate precursor counties. Unless the parents were Native Americans (or perhaps an escapee from the Don Pardo expedition), they were not living in the area in 1735. Q 10:11, 4 July 2009 (EDT)

This is exactly the situation in my area of Maine. First there is York county, then Lincoln County is broken off in 1760, then Lincoln is broken up into numerous smaller counties by the end of the 1800s. How does "Old Washington County" exist in the Place names database? Does it redirect to different counties depending on where the underlying towns ended up? I also have a town that subdivides into several smaller towns over a 100 year period. Today, the location might be Phippsburg, but in 1790, Phippsburg was part of Georgetown.
When I find a record for Georgetown in 1790, I may or may not know (or be able to deduce) that the record concerns an event in present-day Phippsburg. If I know or think I know it is in present day Phippsburg, in Dallan's proposal, I put Georgetown, Lincoln County in the Researcher's Place Name, and select Phippsburg, Sagadahoc County in the Place Page (geographic place) drop down box of options, correct? If I don't know the present day town, I'll just leave it in (presumed) present-day Georgetown, Sagadahoc county until evidence shows otherwise.
I have to agree with an earlier comment that despite my numerous reading of the Place Page directions, I am still not sure how to show on a place page that Phippsburg used to be Georgetown, or that Phippsburg was Lincoln county, or that x event took place in present day Phippsburg, but was then Georgetown in York County.
If I put in the date range of an "also known as" name, does the system know to pull up that name if I enter in an event dated in that time period?
The "also known as" and "also located in" fields on Place pages are used by the search and place-matching functions to identify places. Using Place:Phippsburg, Sagadahoc, Maine, United States as an example, if someone enters "Phipsburg, Lincoln, Maine" (note the single p in the middle) into a search box or in a place field, the system will match that with Place:Phippsburg, Sagadahoc, Maine, United States because Phipsburg is listed as an alternate name, and Lincoln is listed as an also-located-in place. The system will still display what the user entered, but will link it to the Phippsburg place page.
The system isn't smart enough to take date ranges into account. If you enter "Phippsburg, Sagadahoc, Maine" for an event occurring in 1840 when Phippsburg was part of Lincoln county, it's not going to change what you entered. But if you read the place page for Phippsburg you can tell that you ought to change the county you entered to Lincoln.
You can also enter see-also relationships and additional information into the text box of a place page. This information isn't used by the system (it might use the see-also places someday), but could be helpful to a researcher trying to learn more about the place. Place:Phippsburg, Sagadahoc, Maine, United States has a see-also place for Georgetown.--Dallan 11:06, 28 July 2009 (EDT)

Help for User MinnRay [17 June 2009]

User:MinnRay wrote on his User Page this message. Could someone help him? Thanks --DFree 12:28, 17 June 2009 (EDT)

I'm not sure if this is where I should ask this question or not.

I added successfully the Marszalkiewicz Focus Group.

I have just added the Borowiak Focus Group and I am reviewing it.

John Marshall, person No. 116 in the Marszalkiewicz Focus Group is the husband of Mary Burke in the Borowiak Focus Group.

When I created John Marshall's family, I made him the husband of Mary Chorzewska Borowiak Burke, married 24 January 1904.

How do I merge Mary Burke with Mary Chorzewska Borowiak Burke so I can tie the Marszalkiewicz and Borowiak families together? I will be needing to do this for all of my families.

Or should I go back to the beginning and make one master "focus group" with all my families together in one group. Can that be done with a GEDCOM file? It would save me a lot of work.

Now that I am thinking about it, I suppose if I start with me and work backwards, it would work? Is that what people do?

But would that GEDCOM contain all the siblings of my ancestors?

Thanks in advance for your help.


Ray Marshall--MinnRay 20:04, 16 June 2009 (EDT)


Handling Ambiguous Spouses After a Merge [25 June 2009]

When merging up through one or more common representations of the same ancestry, it often happens that you reach a point where there are multiple candidates for the husband or wife of a family, but the information available for the candidates doesn't make a convincing argument that the candidates are really the same person. Moreover, there isn't enough evidence present (nor easily available) to resolve the ambiguity. So how to represent the situation until evidence appears that resolves the matter?

In evaluating the different approaches, I'm concerned about:

  • What is the most explicit/obvious way to present the uncertainty?
  • Is the result incorrectly recognized/detected as a duplicate by the detection/reporting mechanism? Can that be prevented somehow?
  • What would a GEDCOM dump of the affected person/family pages look like? Would the ambiguous situation be apt to be retained or lost in transition from WR to another application? (The other application might be WR, as a result of an upload of off-line work).

Approaches to this situation would seem to include:

  1. Just allow the different names to continue to appear as alternative spouses.
  2. Create a separate person page representing the "abstract" spouse, connect that as the single spouse of the family, and document the abstract person page is possibly being one and the same as several alternatives, noted in the body of the relevant pages.
  3. Just delete the questionable pages. They can be recreated if/when substantive information becomes available.

At different times, and for different purposes, I've used all these approaches. I wondered if there's any consensus of thought building up, on what to do and when. ???--Jrm03063 15:33, 19 June 2009 (EDT)

TMG handles this sort of thing by allowing for a "candidate" spouse or parent. You can have as many of those as you like, depending on what information you have. Candidature implies that you're awaiting, or searching for, additional evidence. Would it be useful to have a relationship box available on each page (or a drop-down, or whatever) where you could, when necessary, designate a candidate for a relationship? I think this would be more useful than simply deleting the page because you can't come to a good conclusion about something. I doubt that any flavor of GEDCOM would know what to do with it, but that's why so much info gets stuffed in "Notes" anyway. --Mike (mksmith) 15:42, 20 June 2009 (EDT)

Deleting a page is not my usual choice! Only when they are devoid of helpful content and were contributed via GEDCOM by a subsequently inactive user. My thinking of such pages is that they are trivial to re-create if someone comes along with something substantive. Put differently, such lame pages actually create confusion without adding info - so to delete them is to make an overall improvement.--Jrm03063 19:01, 19 June 2009 (EDT)

FWIW, if a family has multiple husbands or wives, the multiple individuals appear on the watchers' ShowDuplicates lists. So if you leave them alone they'll be a bit more conspicuous and may get cleaned up more quickly.--Dallan 19:36, 22 June 2009 (EDT)


I've had the same problem when working on merges. One writer may speculate that John's wife could possibly be Mary Jones. Instantly dozens of FTM files add Mary Jones as wife. The "possibly" instantly becomes "is". Then it is downloaded, copied, reuploaded dozens of times. To the innocent newbie, "Everybody says so, must be true". I think we have a responsibility to stop the chain. Like you, I have used different approaches at different times depending on the circumstances.

when it is clear that a person has done some work as come to a rational conclusion, I tend to let it be.
when it's clear that someone downloaded six gedcoms and then uploaded them here without ever reading them and has never been back, I am less hesitant and make the changes that seem needed to avoid misleading other people
in all cases my strong preference is not to link a specific person as a spouse if I feel it is wrong. Otherwise it will get downloaded and the merry-go-round starts all over again. Thus wife "Unknown" should be the only one linked. If there are real people who are candidates, I leave their pages so that more facts can be collected and use a link to the person in the text box as a possible candidate for the wife. That way the information on "possibles" will be there but it won't erroneously be downloaded as a wife.
on rare occasions, the muddle is so great that one must simply resort to slash and burn. It's way more work to try to fix the mess than to clean it out when there's nothing of value on the page. So sometimes I feel a delete is justified. But really hesitate to do it.
If you haven't tried working on merging some of these early gedcoms, you can't understand how much of a mess it is. I have had to spend three days on just one family (mom, pop, and kids). I could have gone to the library, looked up the sources and written a new, correct page much quicker.
so to answer the original question, your instincts seem good. There can't be a hard and fast rule that applies to all circumstances.--Judy (jlanoux) 16:34, 23 June 2009 (EDT)
Another approach might be to insert a note of some sort that something has gone agley. That way others when they come upon this page, will benefit by knowing that something seems questionable. You don't have to find the solution to every problem you encounter, but its good for others to realize that something is amiss. I personally favor inserting an appropriately sized Image:Red Flag.jpg (30px works well in many cases) to mark such, then add whatever note that the problem merits and you have time for. Every problem need not be solved immediately. Just calling attention to an issue is beneficial. Q 16:23, 25 June 2009 (EDT)
Would someone please summarize and add this information to Help:Merging pages so it doesn't get forgotten? Thank-you.--Dallan 14:04, 25 June 2009 (EDT)

I'm not so sure that the content above is ready for anything like prime-time. So I've tried to tidy it up a bit and create the beginnings of a page that could land on help someday. Please contribute and/or revise: Proposed Guidelines for Ambiguous Spouses resulting from a Merge.--Jrm03063 16:44, 25 June 2009 (EDT)


Proposed "Sources needed" template [26 June 2009]

I come across pages -- lots and lots of pages -- that have zero source citations. Mostly, these appear to be the offspring of abandoned GEDCOMs, but some are even "hand-made." This is not a Good Thing.

I'll even admit up front that I have created a bunch of pages myself that lack source citations; these include data taken from family trees at Ancestry -- data that is so precise, I have to think it's probably correct, but which has no source attached. I'm averse to citing "Ancestry" as a good source (it isn't), so I've included no source at all on those pages. I have, however, put them on a to-do list and I've managed to ferret out decent sources for several dozen of those bare pages already (at least one or two per person or family page), so I look upon it as a work-in-progress and try not to lose sleep over it.

However, the point is, I want to flag those pages that have no sources whatever. I want to call attention to them, partly to encourage us and others to work on them, and partly to get them listed in a category ("Category:Sources needed") which can function as a to-do list. (I'm aware that I may be partially duplicating other people's work here. . . .)

This is what I came up with:

{{Sources needed}}

An example of its use is at Person:Mary Tindal (1).

I started out with something much brighter (lots of red and yellow and exclamation marks), more assertive, . . . and probably off-putting to some. So I toned it down. This version is an attempt at maintaining dignity while still calling attention to the work that needs to be done. I shall have no hesitation in attaching this template to a number of "my" pages, those I created sans sources. (Maybe someone will come up with a source I haven't found.)

My notion is to put this at the top of the text box on any entirely unsourced page I come across. Then, when one (whoever) finds and adds a decent source, one may feel justified in removing the template. This is not, by the way, meant to replace the "{{cn}}" or any other more specific template. Nor is it meant to brand any page as "junk." Comments? --Mike (mksmith) 15:46, 20 June 2009 (EDT)

I like how it asks for help rather than saying "Hey, this is awful!" --Ajcrow 07:58, 21 June 2009 (EDT)
Wikipedia has a very large array of banners of this kind, in all sorts of flavors. But they all try to be encouraging rather than critical or condemnatory. That's a good model to follow when you're asking for help.   :)    --Mike (mksmith) 10:07, 21 June 2009 (EDT)
That would work well, especially with the position neutral POV. However, keep in mind that if there's narrative, the sources may be in the narrative. Not everyone uses the "source" space in the left hand sidebar. In my particular case, sources that I consider acceptable, are often difficult to comeby, and values for DOB's DOD's, DOM's, as well as POB, POD, and POM's are often supported by inferential analysis---which is (or will go eventually) into the narrative. (ie, first child born 1771, so DOM probably c1770; they were then living in Washington County, so POB probably Washington County, etc. Though after seeing some well done sourcing by User:Beth and others, I'm warming to the use of the lefthand sidebar for sources. Q 10:25, 21 June 2009 (EDT)
I haven't been crazy, either, about the way all the key data is squeezed over into the left-hand column -- but I gather Dallan is rethinking some of that, so no problem. I'm trying to remember to create "Events" when I hand-build pages, and then I create Sources attached to the events. However, I put the transcriptions of sources almost entirely in the text box, where there's room to read them. Then I use the {{cite|Sx}} template to refer back to the source. (Screws up the GEDCOM export, but I don't expect to be doing much, if any, of that from WeRelate.) But it's not the inferential dates that pain me. I do those, too, usually in the form "Married 1828?", based on age of the mother and age of first child, or whatever. No, it's assertions like "Born 25 Feb 1798 Brownsville, Fayette, Pennsylvania." And nary a citation in sight. As I said, when something is that specific, I tend to assume there's an actual source behind it -- a family bible or something. I just want people to tell me what it is! I'm a bit embarrassed to admit I do actually grab names and dates from the family trees at Ancestry, but only as useful leads -- and then I go looking for real sources. --Mike (mksmith) 11:39, 21 June 2009 (EDT)

I like the template. Is there a way for me to get a list of all of my unsourced pages or do I have to examine all of my pages to determine which pages are presently unsourced? --Beth 12:39, 21 June 2009 (EDT)

As I mentioned a while back in a discussion (somewhere . . .) on the various uses of the FTE, I've created a tree for myself called "Sources Needed." Then, when I create a page, or when I tidy up a page that got here via a GEDCOM import (I always tidy up), if it needs source citations to justify its space, I add it to that tree. When I want to spend some time doing some of this source-hunting, I can just pop up that tree and work my way through it. When I find something useful in the way of a source for a page, I can de-tree that page. At the moment, there's around 180 pages, I think, on my "Sources Needed" tree. Whether there's a way to search systematically for unsourced pages, I don't know. I kinda suspect not. Though Dallan may know a way to run an "If-then" script or something, searching for "null sources." (Sorry, my few programming skills were learned on a TRS-80 with line-numbered Basic.) --Mike (mksmith) 13:46, 21 June 2009 (EDT)
Here's an idea for looking for unsourced pages: Click on MyRelate, then Trees, then the View link next to the tree you're interested in, then add
-Source -MySource

to the end of the keywords line. This will return everyone in your tree without the word Source or MySource.--Dallan 19:36, 22 June 2009 (EDT)

I tried a slightly different approach:

{{Help Wanted}}

Most of the people I run across have good information, but they're not into computer stuff. I need to make it easy for them to get in touch. I'm hoping that if a message is left on Talk for a person I'm watching that I will get an email. Is that true?--Judy (jlanoux) 12:45, 21 June 2009 (EDT)

Yes, although it doesn't hurt to check your Watchlist on the MyRelate menu and click on Show all pages changed since last visited every once in awhile.--Dallan 19:36, 22 June 2009 (EDT)
I like both of those banners. But one thing to consider when creating them is the width of the banner. I used Beth's 'questionable information found' banner on a page I merged that had doubtful info. The original banner was wider than the space between the left side and the advertisements on the right. So it fell lower on the page beneath the ads. Then when the screen was opened in AOL and not maximized, the page looked empty and a viewer would see no reason to scroll down the 'empty' page. So Beth tweaked the template just a little to make it narrower and it works perfectly now. Right at the top of the page where it can be readily seen. --Janiejac 15:36, 21 June 2009 (EDT)
Beth's original version of the banner (at about 800px I think) also behaved the way Janiejac describes. We cut it down in stages to 500px and it seemed to work fine, at least on myscreen. Then Janijac found it wouldn't work for her in her set up, so Beth cut it down to 400px. Which seems to work fine. A little realized aspect of web page design is that even a carefully designed page will appear differently on different systems. Most of this has to do with your personal preferences settings. Some of it has to do with different browsers being used. And some of it probably has to do with different systems (Mac-PC) being used. Usually web page designers keep two or three different sytems around just to view differences in the way the page appears on these systems. But no one can have everything covered. I thought the 500px would cover most bases, but Janiejac shows us that 400px may be a better choice. At some point in this kind of exercise you have to decide whether the "needs of the few outweigh the needs of the many". In anycase, its really really really good, when you see something that looks funky, to let the person know about it. It probably looks fine to them, and will appreciate knowing that it looks a tad off to you. Q 17:10, 21 June 2009 (EDT)
Am I correct that you made your banner fixed-width? I didn't do that, and for that very reason. (I don't believe Judy did, either.) If the screen space is too narrow, the text in the banner will wrap -- which looks a bit ugly, I admit -- but it stays at the top. --Mike (mksmith) 10:04, 22 June 2009 (EDT)
For some reason unknown to me, the banner was set with a fixed width when I got involved. Believe Dallan actually dropped it down to 400px. Perhaps the better solution would be to let the width float. Q 10:12, 22 June 2009 (EDT)
Banner was set at fixed width originally by Dallan. I dropped it to 400px. Please change it to floating width if that is preferred. I don't know how. --Beth 10:36, 22 June 2009 (EDT)
Just hack out that "|400px". I believe in the case of your banner, setting it to fixed width does no harm at 400px. Anyone with settings so restrictive that 400px is going to be a problem, are going to have much more severe problems than that. This, however, brings forward a potential future issue. When, if, proposals to insert a register in the "narrative" area are implemented, Banners like this may become a definite problem for display. For that reason, if the register idea is implemented, I'd prefer it to be done as a "tab" or drop down type of display, leaving the existing Narrative area intact. Q 12:02, 22 June 2009 (EDT)
OK, tried that. Doesn't work. If you hack out the fixed width, it lets the the banner float pushes it across the page so it underlay's the right hand sidebar. I think the problem is with the "div". In this style I presume, you need to use a fixed width to avoid that problem. 400px should be adequate. It would be good to how this could be solved with floating the width in combination with a Div. Q 09:02, 26 June 2009 (EDT)

I like Judy's banner for its very gentle and non-directed tone (appears to be addressed equally as much to a general reader as well as the author), but it does not say anything about no sources. Perhaps clicking on the banner could take one to a help page explaining the reasons why the banner is there and how people can improve the page and remove the need for the banner. Given that people add pages with no sources, I suspect it must be assumed that they don't see a lack of sources as a problem, and an explanation of what is wrong probably needs to be explicit.

Unlike making the judgment that this source is OK or that source is not, flagging a complete lack of sources seems like it can be done very objectively and impartially. It would seem that this would be fairly simple to automate this process, making it much more effective. So I would like to see Dallan's thoughts.

Personally I think time will solve much of this even without the banners, but judging from the number of posts here, plus previous threads on this topic, there seems to be at least a general consensus that something along these lines should be done. --Jrich 11:33, 22 June 2009 (EDT)


Once this is settled, would someone please update the help pages? I love the banners. Maybe add the words "Help wanted" to the beginning of the first line of the Sources needed template? Someday I'll automate displaying these kinds of banners when the computer can figure out that they apply to a page, but that's a ways away, and in the meantime I think manually adding the banners will be helpful.--Dallan 19:36, 22 June 2009 (EDT)


Time needed for Administrative Approval [22 June 2009]

I uploaded a GEDCOM and reviewed it, matching the families, about one o'clock this morning. It is still awaiting administrative approval. Is there something I failed to do or is this a normal amount of wait time? --Janiejac 11:54, 22 June 2009 (EDT)

I'm usually asleep at 1am! :-) Solveig and I are still the main people reviewing GEDCOM's; we need to get the other administrators involved. Things have been going pretty smoothly lately so I think it's time.--Dallan 19:36, 22 June 2009 (EDT)

Volunteer for Community Portal for Genealogical Research Education [22 June 2009]

Seeking a volunteer to create a community portal for research education. There are several free courses on the web. --Beth 22:17, 22 June 2009 (EDT)


News updates [22 June 2009]

For those who don't visit the main page often (many followers of this page do not), there are two news items to report:

  • GEDCOM export is available by clicking on Trees in the My Relate menu, then clicking on the export link next to the tree you want to export. Many thanks to the people who helped test it: DFree, Gewurztraminer, Janiejac, Jrich and especially Jlanoux. (If I inadvertently omitted anyone, please let me know.)
  • In case you're wondering how bug fixes and new feature development are coming along, you can get (almost) daily updates at Twitter.

--Dallan 23:07, 22 June 2009 (EDT)


Place pages and adding history - what do with supporting documents [29 June 2009]

I updated Lafayette, Alabama; I added information about a fire in 1899. I sourced the information, but don't intend to keep my copy of the referenced newspaper article. Should I upload the image; if so to what location? --Beth 18:10, 26 June 2009 (EDT)

I think I would put it into the digital library, at least until Dallan adds the "Document" source type. The DL will accept a wide variety of formats, including pdf's, images, Word Files, etc. You can also save them as HTML, or as simple TXT files. PDF's and Images are good choices, since most folks can read them. Word files etc., require that the person recovering the item have MS Word. Q 22:01, 26 June 2009 (EDT)
Well, I was afraid that would be the response. Since it has been forever since I have even been to the digital library is there a tutorial for this? Exactly under what do I enter the image and how is this image linked to the place page?
Probably no tutorial as yet, as I don't think this is going to come out of Beta for sometime.
  • Go to Digital Library
  • Click "Start New Submission"
  • Select the Collection you want it in (presumably your own)
  • Go through the steps as the system guides you. There are a number of data entry pages. Somethings you have to enter, something you should, and somethings (most) can be ignored.
In the end you'll get an item added to your collection, relatively quickly, but not instantaneously. You';ll get a notification that includes a link to the item. You can click on that and it will take you to a view of the item. Then you can copy the URL and place it where-ever you want as a link. Or just use the URL from the notification. There are a couple of shortcuts to this last step, but they are a bit tricky. (At various stages you'll see an URL displayed for you. You can use those, but they sort of link to an intermediate storage product. Better to wait I think, and use the formal URL the system gives you.) Q 22:57, 26 June 2009 (EDT)
Okay I uploaded the item but unsure about the link; I thought it might automatically link it to the page. How do I now find the link that I am supposed to place on the place page? Okay I received the email but the link did not work initially but now does so all is well and many thanks. --Beth 00:54, 27 June 2009 (EDT)


Just as an after note; I find it a huge problem on WeRelate to add data; it is more trouble than the potential worth.

Also since I am a resident of Alabama I find it rather annoying the place page for Lafayette is La Fayette. Unless someone has documents to the contrary to prove such this city was never La Fayette. --Beth 22:35, 26 June 2009 (EDT)

Seems like that would be easy to change with rename. Q 22:57, 26 June 2009 (EDT)
It is but I am reluctant to change from the naming conventions on Wikipedia when the data from Wikipedia is a part of the place on WeRelate. --Beth 00:14, 27 June 2009 (EDT)
Then change Wikipedia. I'd recommend placing a comment on the article's talk page, explain what you think should be done, provide some documentary support for the spelling, etc. Q 08:21, 27 June 2009 (EDT)

The digital library has several advantages (being able to control who can submit to and view items in a collection), but simplicity is not one of them. After using the library for awhile, it's looking like adding simplicity will be a fair amount of work. It's a different model than the wiki. I'm thinking that in the long run it will be easier to add the ability to upload external documents (HTML, PDF, Word, etc.) to the wiki and migrate the current digital library items over to the wiki (once we get a Document namespace added to the wiki).

You're welcome to upload the image to the Image namespace. That's the simplest approach.

As for renaming the place, go ahead. That's the whole point of a wiki. My guess is that Wikipedia got their information from the same underlying data sources that I did, and those data sources are known to have a few errors. Changing Wikipedia as Q suggests would also be a good idea if you're so inclined.--Dallan 12:51, 29 June 2009 (EDT)


Summer Wikepedia Project? [3 July 2009]

Is there some sort of summer internship program happening where volunteers have been assigned to go find wikipedia content for anyone on WeRelate and copy the WP template over to such WR pages?


Both Edmund Rice and Ureli C. Hill's pages have been so modified recently by someone not watching the page (in this case Skater). I believe Skater is doing such work on other pages as well. Yes, see:

Skater's Contributions to Person Pages


Does someone know what's going on?

The reason I ask is that there appears not to be a great deal of discernment happening. In the case of Edmund and Ureli, above, the content that was already on the page (pre-WP template) was/is better than what's on WP. At best, we end up with a bunch of duplication.

Can we take a breath and discuss this please? Thanks!

-- Jillaine jillaine 17:32, 29 June 2009 (EDT)

Jillaine, IMO particularly on "your" pages you need to have a discussion with User Skater. I am positive that the two of you can sort it all out. WP content should only be added if the content improves the page. --Beth 19:38, 29 June 2009 (EDT)
Another point regarding WP content inclusion. We really ALWAYS want the inclusion template, it's just a case of whether the content is:
  • The entire body of the person page
  • A section in an otherwise ordinary page
  • Stowed below the WP source citation
The reason being, the WP template has the extremely helpful side-effect of telling the WR agent that a particular WR page corresponds to a particular WP page. This means that when other WP content is included, that happens to contain WP hyperlinks to WR<->WP associated pages, we automatically get a translation of the WP hyperlink to a WR hyperlink.--Jrm03063 21:00, 29 June 2009 (EDT)

I initially did post a query on the Edmund Rice talk page. Turns out Skater is not watching either of the two pages. Another watcher expressed related concern about the WP content inclusion. I then posted a question on Skater's Talk page, but the more I look around the more it appears that this is a system-wide project. That's why I'm asking the question here. jillaine 19:44, 29 June 2009 (EDT)

I understand your concerns Jillaine; but I have no knowledge of any such project. Looks like User Skater is contributing by adding the WP content. From reading Skater's user page, I assume that this user is receptive to positive recommendations. --Beth 20:12, 29 June 2009 (EDT)

I think there is an informal project being conducted by Dallan's kids. Whoever "skater" is, I spoke w/them on a talk page, and they are receptive, so there shouldn't be a problem.
Dropping existing content on a page isn't a requirement, in order to attach WP content. The WP content can be added as a section of a conventionally created page. The WP template reference (after being created) can also be placed within the body of the WP source entry as well. It can't start life there, since the agent has problems finding the {{source-wikipedia|WP_PAGE_NAME}} syntax for replacement other than in the body of a page.
My general approach to existing body content, is that I drop it if it's obviously not being maintained and/or is an untended upload. I retain existing sources as best I can, as well as any facts that are not refuted by WP. I'm very careful to retain body content that was created by an active WR user.
I have no doubt that "skater" and others, will gladly follow the above principles - or any others that are generally agreed to regarding this sort of stuff. We just need to gently educate them....--Jrm03063 20:46, 29 June 2009 (EDT)

"My general approach to existing body content, is that I drop it if it's obviously not being maintained and/or is an untended upload. I retain existing sources as best I can, as well as any facts that are not refuted by WP."

How do you determine if it is being maintained? If there is no new evidence, there would be no reason for it to change. About the only reasonable way to assess if something is being maintained is to look at the date of the person's last contribution and if no watcher of the page has made any contribution to WeRelate in, say, a year, two years, maybe you could argue a page is not being maintained. If they are still active on WeRelate and watching a page, I don't see how you can say it is not being maintained.

Jillaine gave two examples of pages where she thinks WP is not entirely right, I gave a different example the other day, as well as a WP page that was cited that itself was without a single source other than two webpages containing no source (awfully reminiscent of citing GEDCOMs as sources). I don't see how any of these examples suggest that we can regard WP as sufficient authority to remove other material based on what is in WP, and what is not in WP.

Wikipedia is a secondary source, if properly documented, and worse if not. --Jrich 21:19, 29 June 2009 (EDT)

I'll try to deal with your complaints in order Jrich, though I doubt you'll be all that satisfied. I really think you're missing the point.
How do I determine if a page is being maintained? Indeed, I look at the history and try to read the tea leaves. If there are specific source citations, I carefully save them - even when they are undecipherable by me, in index code forms, and even in foreign languages. If I can figure out how to salvage the body content, I do, but I won't strain myself if the WP body content "seems better". Also - if the WR content seems active or adds something not present in the WP page - I can maintain both. The WP stuff can be included in it's own section w/o removing WR content you wish to save.
The subjective call about saving the body content of a page or not, variously revising it and so on, is always on the table, whether a particular page has a WP shadow or not. If someone is watching a page and doesn't like what I do, they can change it back and engage a discussion. That's the way it's all designed to work - change first, speak up if you disagree.
I accept as completely true that there are WP pages that are "not entirely right". And the reason you're not fixing them would be...??? The WP pages that is. One of the key principles of WR is to end duplication of effort, and to bring together researchers working in common areas (like it or not). Arguing about whether the WR copy of a page is better or worse than a WP copy of a page is nonsensical - the real question, is why not engage the WP-based research community on such shared pages? I mean, do you believe in your own content assertions or not?
So labeling WP as a "secondary" or somehow a less worthy source "sometimes" is as much beside the point as it is incorrect. We call it a source because we have to call it something, but the real issue is associating disparate research and researchers - thus maximizing peer review. The reason that WP gets a "primary like" level of deference isn't because the content is primary quality, but because WP is the much more heavily reviewed research forum. We can readily go over to WP and improve pages and engage discussions there. It isn't (yet) realistic to expect the reverse.
Wait a minute. Can you (or someone) tell me why it's such a great idea to have the content of a Wikipedia page completely duplicated on a WeRelate page in the first place? I've been an active editor on Wikipedia for a number of years now -- since there were only about 100K pages there, in fact -- and I have a pretty clear idea of what Wikipedia is, and what it is not. It's a encyclopedia, nothing more, nothing less. Encyclopedias are great for quick reference. Librarians (like me) use them heavily for just that purpose. Wikipedia is a modern version of Funk & Wagnalls, and that's great. But no encyclopedia is a "scholarly source," and none that I know of make any claim to being that. The staff writers for any encyclopedia are just English Majors drawing a paycheck. They're not world-recognized experts in a given subject with Ph.D.'s and awards. This is perhaps even more true for Wikipedia. (A number of articles I've written in the past have been run roughshod over by those with grossly insufficient information.)
WeRelate is therefore a rather different sort of animal. If you want information on the families living in colonial southwest Virginia and how they interrelate, you would go to someone like Quolla -- not to the Encyclopedia Americana and not to Wikipedia. If you want similar information on Old Red River County, Texas, you'd likewise be better off asking me. I know the subject backwards and forwards and in great detail -- far more so than a contributor to a general encyclopedia. This being the case, active contributors to WeRelate are far more likely to be knowledgeable and accurate about their own fields of interest than what might have found its way onto a related page on Wikipedia. (I say "active" because I'm excluding the name-collectors and those who commit drive-by GEDCOMS. They're not genealogists in my book.) For this reason, while I have no problem with a link to a page at Wikipedia, which is no different than a link to any other external site, I object to whatever mechanism it is that auto-imports an entire WP page into WeRelate. Most of what's on the page for, say, Zachary Taylor, has nothing whatever to do with his family history, which means that -- for WeRelate -- it's irrelevant. You say the goal is to minimize "duplication of effort," but it seems to me you're creating a duplication in effort by auto-copying the WP page to this site. Now we have to review what others -- non-genealogists -- have posted to Wikipedia in articles that get copied here. Well, I'm not going to invest the time to go edit the article on Louisa Alcott or whoever at Wikipedia. That's just not my "job." --Mike (mksmith) 13:36, 30 June 2009 (EDT)

Oh silly me for bringing up a topic that raises the old issue of Wikipedia and its relationship with WeRelate. There is clearly NOT consensus on this issue and there is clearly diversity in how individuals using WeRelate use (or not) Wikipedia. Personally, I don't think that active (or even semi-active) WR users should be required to maintain pages at multiple sites. I have no interest in maintaining a WP page about Edmund Rice; I focus my limited time on WR. We've discussed this before (to death), and in my mind (and I think others, too), WR and WP are two different beasts. The information about Edmund Rice at WP might be perfectly fine *for WP*. But it's not necessarily genealogically framed. It *is* another source of information-- good or bad. I have no trouble pointing people to WP for more information about a person or a period of time. And I also don't have a problem with using WP content when there is no other content to be used for a WR person page. But a number of us have recently been working on Edmund Rice-- in fact, I was just saying what a great example of collaboration this page has become because a few of us were going back and forth, cleaning up after each other, clarifying, formatting, and making the page look dang nice. And I'd just done a bunch of cleaning up on Ureli C. Hill as well. Then along comes the WP agent and -- in my view -- uglifies the page and at best duplicates what was already there.

Let me be clear: this is not a complaint against Skater. As far as I can tell, Skater's working on a system-wide project and is not personally involved with the pages Skater is editing (otherwise, I assume, Skater would be Watching said pages). And frankly, if there's a WeRelate project to copy over WP content for pages here that have no content, totally cool. It gives us something to start with. But I do not think that WP content should be copied over here when there is perfectly fine information already here, nor should WP be the default god-of-content for WR.

-- jillaine 00:00, 30 June 2009 (EDT)


For background on the project, see WeRelate talk:Famous categories. Yes, this is an effort to flag existing pages that have WP pages, both for the categories, and because, as JRM indicates, it gives us lots of nice cross-references. I've been asked by Dallan what the procedure should be when there is existing content on pages I've worked on. To which I said, if there is substantive content, please leave it and use the source template in the source citation if appropriate. Where it is not appropriate (such as where it is many duplicative paragraphs long), there is an alternative template that says something along the lines of "For more information, see <link to wikipedia page>." (i.e., Person:Reginald Denny (1)) That would have been a better approach on Edmund Rice, probably. If these templates don't provide value, then they shouldn't be used/should be deleted. You can gain the same advantages by hand editing, it's just more work.--Amelia 00:15, 30 June 2009 (EDT)


I would think the link to Wikipedia, and citing it as a source, is always more appropriate than including the text, or even portions of it, verbatim. How hard is it to follow a link? People know what Wikipedia is, and can choose to read it or not depending on what they know and what they are interested in. But as a link it would not crowd out WeRelate specific data entry. I think that would be fine, and wouldn't even have a problem if the Wikipedia page turned out to be wrong because the link doesn't imply unquestioning acceptance the way blindly copying the text by automated agent seems to. A link would still be making access to a good source easier, which is a good thing.

I joined WeRelate to contribute to a community tree, not to maintain Wikipedia. I have no desire to spend time fixing Wikipedia pages when they can't bother to read Thomas Prence's will to find out that his wife when he died was named Mary. They are not interested in wasting time discussing whether he had 2 or 4 wives, and that is one of the chief things I want to discuss. There are thousands of people I am interesting in learning about that they have no interest in. But, by simply linking the pages, they can focus on what they think is important, and their material is easily accessible, but the WeRelate community can still focus on what is important to them as genealogists. --Jrich 01:27, 30 June 2009 (EDT)

The advantage of the WP inclusion is that when WP is updated, so is WeRelate. This is very very good in some circumstances, and not so good in others. For example, its very helpful to have Place articles drawing from WP by inclusion, because when the data gets updated, so is the WR article. Ditto articles about really well known persons are often dealt with in more detail on WP then here, and certainly have more "eyeballs-on" than here. havig a link to them is probably good. Articles on lesser known individuals. But I'm not so sure about articles on WP that get a paragraph of treatment or less. There are fewer persons looking at them, there's less intense scrutiny of the product, and the people doing the work may or may not be well qualified to evaluate genealogical information. A good article on WeRelate for such folks is probably better than on what's on WP. A so so article on WP is probably better than NO article on WR. Q 13:02, 30 June 2009 (EDT)

Wikipedia is certainly a fine resource for gathering information about persons of historical interest. I've occassionally used their content as a shortcut in creating an article. And while some articles do contain useful genealogical content, its a good idea to keep in mind that the people writing those articles are not, as a rule, well versed genealogists. One of the central requirements on Wikipedia is that information be documented. If article writers can point to something like a family history that supports whatever they want to say, then they've met the requirement. Unfortunately, family histories are not necessarily accurate. Detecting inaccuracies in such sources requires experience with genealogy that the Wikipedia writers often lack. Q 07:51, 30 June 2009 (EDT)


I'm another person who was very dismayed to see Wikipedia content being blindly copied into Person pages. I really can't think of any valid reason for doing it except "because we can". [See my comment above about updating Q 13:02, 30 June 2009 (EDT)] A source reference to a Wikipedia is adequate and appropriate. Pasting a WP article into the text box where it assumes dominance over the carefully researched sources is just plain bad. And I agree that it 'uglifies' the pages as well as introducing material that is potentially inappropriate. It's not our job to police WP yet you are trying to make it so. Last I looked (it's been a while) there was a "no genealogy" rule on WP. --Judy (jlanoux) 10:25, 30 June 2009 (EDT)

Actually, a good example of "uglification" using Wikipedia articles is the very place where it makes the most sense to use them---place articles. Its good that those articles are updated (assuming that there's value for WR users in knowing who the current city manager is of some location, or last census demographics), but it certainly does not make a pretty article. Q 13:02, 30 June 2009 (EDT)

If you don't like WP links on the pages you're working on, delete them. This is a wiki after all. You can obviously make things better whenever you want. However, let me explain a couple benefits. We have pages here for a lot of people about whom much is known, but nothing has been added to WR. Take Abraham Van Buren, whom I was just working on. He was the son of President Van Buren and a military officer. No one has bothered to write any notes for him. By dropping in the Wikipedia link, we get the bio, and links to a lot of people in his life that are also on here -- his parents, his classmate Jefferson Davis, his wife the first lady, and Dolly Madison, who introduced the two of them. And those links show up without anyone having to know that they are on WR and find them. Similar logic for someone like George Washington, where it's just silly really for someone here to write a biography. The WP link pulls in just the intro, which is a summary, shorter section of the whole article, which also doesn't need duplicating here. Yes, someone could do this work by hand, but they haven't, and this is significantly easier. So if you want to edit your own research interests to include these links and the categories that are appropriate, by all means, do that and delete the WP template. There's no requirement that there be WP links. But for people that you don't care about, they give you a great bang for the buck. --Amelia 11:02, 30 June 2009 (EDT)

I agree with that also. There are places where inclusion of WP articles serve a useful purpose. There are also places where it would be better not to include them. Q 13:02, 30 June 2009 (EDT)
Amelia, I went and had a look at the George Washington page you use as an example. I see exactly one-half of a line (at the very end) that deals with his family. How does that justify copying the entire article into WeRelate's space? The purpose would be far better served by including on the WeRelate page a short bibliography of books and articles on the Washington family -- and there's a bunch of them out there -- and then including a note: "Follow this link to the George Washington article at Wikipedia." Also, I have no objection whatever about doing a WeRelate page "by hand." I'm more interested in quality than quantity. Genealogy has always been a time-intensive avocation. --Mike (mksmith) 14:15, 30 June 2009 (EDT)
That's exactly my point. Nobody has cared enough to add any content about George Washington (except me) and it's ridiculous to start from scratch to summarize his career or the sources available about him. If you want to, you may absolutely do so. But in the meantime, we have content on that page because of Wikipedia and for no other reason. That one line (which is not from Wikipedia -- I added it based on information on... George W.P. Custis's Wikipedia page) does not "justify" copying anything -- the fact that there's nothing there on the rather significant nature of who the man was does (And it's not the entire article, which is much, much, much longer). --Amelia 14:41, 30 June 2009 (EDT)

User:Skater is my daughter. User:Taylor (my son) has been doing the same thing, but not as much. They've been adding templates to WeRelate pages that have a Wikipedia article. This is in preparation for an upcoming feature later this year where you'll be able to see which "famous people" you share common ancestors with. (See WeRelate talk:Famous categories as has been mentioned previously.) The Wikipedia links will give us a starting point for determining which WeRelate people are "famous" and what famous category(ies) to assign to them. She hasn't been watching the pages because she doesn't have a long-term interest in them, but she has been responding to messages on her talk page.

To my knowledge, she isn't deleting any existing content or changing any existing facts/events (except in a few cases where the text we had was simply a cut-and-paste from the wikipedia article - in those cases she replaced the text we had with the wikipedia template so that the text would get updated periodically). She's been adding one of two templates to the pages: either Template:Source-wikipedia, which at the end of the week is turned into another template that includes the opening text from the Wikipedia page onto the WeRelate page, or Template:Moreinfo wikipedia, which just links to the Wikipedia page and doesn't copy over any content.

She's supposed to be using the "Source-wikipedia" template only when the page's text content is empty or has just one or two sentences, and use the "Moreinfo" template when the page already has text on it. From the examples given it doesn't look like she's been doing that, and I apologize. I'll have her go through her contributions and remove the wikipedia template from pages that already have text content on them and replace it with the "Moreinfo" template. Most pages that I've seen her edit don't have any text content though. For pages without any text content or with just one or two sentences, I think it's nice to include text from Wikipedia. We've done this for Place pages for example and I think the place pages with wikipedia content look better than the ones without anything at all. I think the same goes for Person pages -- Wikipedia content is better than no content at all.

The policy always has been if you have something better to say than what Wikipedia has, feel free to replace the Wikipedia content with your own content. In my opinion it's doubtful that we'll have anything better to say than what Wikipedia has for people who lived before 1500. But I know there are instances where we have more genealogically-relevant things to say about people born later. In those cases feel free to replace the Wikipedia content with something better. If you do replace the Wikipedia template with your own content, please add the Template:Moreinfo wikipedia template to the end of the page. (I'm going to use the moreinfo template to automatically convert links found in other copied Wikipedia content from linking to Wikipedia pages to linking to the corresponding WeRelate pages.)

Does this sound ok?--Dallan 13:18, 30 June 2009 (EDT)


Thanks, Dallan, for providing the context. It helps to know what was behind this recent round of WP-related edits. And thanks for asking your daughter to review what she's done so far.

In the meantime, I also reviewed the text that JRM initially drafted about WP guidelines the can now be found here: Help:Guidelines_for_use_of_Wikipedia. JRM put a lot of effort into that document and it helps explain how to do it when you want to do it, but what I noticed as missing is WHEN and WHY to do it. I started drafting such language here:

Help_talk:Guidelines_for_use_of_Wikipedia

(It doesn't include the Place example, which I think is a good one. I hope someone will add that.)

It doesn't look like we will ever reach consensus about how much to rely on WP for WR content. Clearly there is a spectrum of opinions about this. But hopefully the above drafted language (second link) is a start at something to help people think through when and why it might be a good idea, and then the rest of the Guidelines say how.

And as others have said: if you don't like it, edit it.

Dallan, if there was a better way for me to have raised this issue (I did post to Skater's Talk page, but without response) other than creating a storm over here at the Watercooler, please advise.

jillaine 15:15, 30 June 2009 (EDT)


I would like to think we could agree that:

  • If there is a WP page for a person, then the corresponding WR page must define the association in a way that the WR agent can recognize. That means either content inclusion or use of the "for more info see" template. Note: the guideline document was written before the "for more info" template was created. Therefore, it was assumed that inclusion was REQUIRED in order to create the WP<->WR page association. That document should probably be fixed to indicate such intent.
  • If you think that a corresponding/shadowing WP page is flawed in some non-cosmetic way, you need to do one of the following:
    • Fix it on WP
    • Create an explicit WR source for the WP page, and tag the source with a note describing the flaws.--Jrm03063 16:08, 30 June 2009 (EDT)

JRM, I think we may be able to all agree on your first bullet. I'm perfectly fine with there being a "for more info" link on the said pages (Edmund and Ureli, for example). But I think we may get stuck on your second point and its sub points. It's not that the WP pages on Edmund Rice or Ureli C. Hill are flawed. They're just not framed in a genealogical way. And as I and others have said, we do not see our role here as working on WP pages. As for creating an explicit WR source for the WP page, it may not always be appropriate for WR to be a *source* but rather an external link. I.e., "for genealogical information related to Edmund Rice, see URL..." jillaine 18:31, 30 June 2009 (EDT)

My second item notes, "in some non-cosmetic way". I'm talking about factual inconsistency. WP says X, but a WR page is being written that says (not X). The sort of discrepancy I want to consider is what Jrich refers to when he says, "... when they can't bother to read Thomas Prence's will to find out that his wife when he died was named Mary...." I never claimed anyone should address issues on WP if they don't like format, or focus, or cosmetics of any sort.
You don't have to love WP, use it's content, or even like it, to recognize that it's ubiquitous, many folks are going to use it, and if you're not going to engage a prevalent misconception there - it is going to tend to find its way back to WR again, and again, and again. I mean, doesn't academic diligence require an explicit notice in this kind of situation?
Putting this in a less W-sensitive framework, assume that there's a common resource for some particular family. Further assume that it is pretty good mostly, but has a few defects that are discovered by later research. I'm saying that completeness requires you to explicitly address the flawed resource and note the flaw - if for no other reason than to protect your work from being damaged by the less well informed.
--Jrm03063 20:22, 30 June 2009 (EDT)

BTW, User:Skater has reviewed the pages she edited and has made the necessary corrections. I'm glad someone pointed out the issue before she got too far down the list :-). Let me know if you find anything else amiss.

Regarding the use of Wikipedia content, I've added a few thoughts to Help_talk:Guidelines_for_use_of_Wikipedia.--Dallan 00:57, 4 July 2009 (EDT)



Success stories needed! [28 July 2009]

Howard Wolinsky from Ancestry Magazine would like to do a story on WeRelate. He wants to include concrete examples of people who have been able to extend their lines, add or correct information, and collaborate with others on WeRelate. If you have a story to share (please do!) would you email it to dallan@werelate.org? Thank you!--Dallan 13:27, 30 June 2009 (EDT)


How soon are these needed? Is there a deadline or target?--Judy (jlanoux) 14:16, 30 June 2009 (EDT)


I sent him several that people emailed to me a couple of days ago, but if anyone has others, please continue to email them. Not only are they wonderful to read! :-), but even if they're too late for this article, this experience has made me realize that we need to have a set of "success stories" that we can point to.--Dallan 01:01, 4 July 2009 (EDT)


Dallan, I'll be happy to create such a space-- perhaps off the Community portal?-- if you want to send them my way, I'll compile them. jillaine 09:50, 13 July 2009 (EDT)
Thank you! I'll send them your way.

One more thing, if there's going to be an article about WeRelate published, we can expect a flurry of new contributors. All the more reason to have some good language ready for them to read before they do some willy-nilly uploading of GEDCOMs.... jillaine 09:51, 13 July 2009 (EDT)
Right. He said that he would wait until later this year, so we have some time to improve things before then.--Dallan 11:06, 28 July 2009 (EDT)

Surname page Usage [18 July 2009]

The Help for Surname pages is devilishly hard to locate but I have read it several times and still don't understand how I should be interacting with them. Help seems to tell me "how to" when I want to know "when to". Please help me understand any conventions in place for the use of these pages.

1) Are pages supposed to be created automatically for each surname?
This doesn't seem to be happening consistently. If I'm supposed to create the surname page, how can I get a list of people/surnames with missing surname pages?
2) Should there be a separate page for each spelling variation? or should all variations be on a single page?
It seems that the research content would be most effective if there is a single page, but then would merges be required if there are already multiple pages. And do we really expect to look here for research content?
3) Sources are asked for on alternate spellings. I know we like sources, but it seems impractical to find a cite for what is really a collective observation. One can observe spelling evolving over time in the same family and know that the surname is intended to be the same. Likewise one can observe common misspellings and want searches to include the variations. I'm inclined to use "spelling variant" or "common misspelling" where it says source. Is this acceptable usage?
4) The 'WR similar spelling' algorithm is not working very well for non-English names. The choices are nowhere near the same name, so I need to do some editing. Is any fallout created by removing obviously different names?
5) Are any alternates automatically recognized? or must every one be listed on the page? Example: Leblanc; LeBlanc; Le Blanc; le Blanc
6) How important is it that these pages be maintained? i.e. What bad stuff will happen if a surname is not contained on any surname page?

Some guidance would be appreciated. It appears that the surnames pages are what determines matches on searches so I definitely don't want to break anything. But I'm finding that some of my surnames don't seem to appear on any surname pages and alternate spellings are not on them. So it appears action is needed on my part. --Judy (jlanoux) 20:49, 30 June 2009 (EDT)


Surname pages is one of those ideas that was, say, not great :-). WeRelate started its life as a search engine for genealogical information on the Web. (The Web item in the Search menu is the vestiage of that beginning.) The Surname pages were intended to be places where people could write general histories about a surname or leave tips for researching a surname. They were also used to store "related" names for the search engine: if you searched on "Smith", the search engine would include all the variants of Smith listed on the Surname page.

We found that what people did on the surname pages was write about specific ancestors. So we added Person and Family pages and the surname pages have gotten very little use since then. The search engine for WeRelate still uses them:

  • If you search for a surname that has a surname page, the search engine includes the variants listed on the page. The 100K most-common surnames have pages created for them.
  • If you search for a surname that does not have a surname but appears as a related name on other surname pages, the search engine includes the primary names (names in the titles) of the pages on which it appears. I think roughly couple hundred thousand surnames appear on one or more surname pages.
  • "Rare" surnames that do not appear in any of the surname pages are picked up in searches by soundex (double-metaphone actually, which is similar to soundex).

In the long run I'm not sure that a set of surname wiki pages is the best approach to manage a set of related names for searching. We may get rid of the Surname pages someday and migrate the related name information to something more appropriate. In the meantime though, editing the Surname pages is how you modify what related names get included in searches at WeRelate.

To answer your questions.

1) There are millions of possible surnames. Too many to create pages for each one.
2) You don't have to create a surname page. If a surname doesn't have a page, it will use as its set of related names the titles of all of the surname pages on which it appears. (Search for the name as a keyword in the Surname namespace to get a list of the pages it appears on.) And no, I no longer expect that Surname pages will hold research content. It was a bad idea.
3) I agree.
4) Just that those names won't be included as related names in searches for the primary (title) name. But if they're nowhere near the same name, then please remove them.
5) Names are case and space-insensitive. Leblanc, LeBlanc, Le Blanc, and le Blanc are all the same to the search engine.
6) No, it just means that searches for that name will return other names with the same soundex code.

--Dallan 01:36, 4 July 2009 (EDT)

THANK YOU for taking the time to explain - especially the history. This clears up a lot of confusion.
I have names that may have 10 - 20 variations and do need them recognized as being the same. We don't want long lists of alternate names on the Person page so it makes sense to have an equivalence table of some sort. I will work on the pages for the ones I am concerned about.
I was hoping that one page could take care of all the alternates, but I'm afraid the second * above says "not so". If I search on a name that is listed as an alternate, it will match any instances of the primary name but not any of the other alternates? <bummer> Well something to think about for a future rewrite. I think creating two or three primaries will take care of most cases.
That's right. I'm not really wild about that either. It really should look up all of the alternatives on all pages. I need to fix that.--Dallan 11:06, 28 July 2009 (EDT)
Does anyone mind if I take the references to using the page for research content out of the help? It tends to confuse people when we also have categories and shared research pages. --Judy (jlanoux) 21:47, 7 July 2009 (EDT)
I don't have any objection. I cannot locate the help page anyway.--Beth 21:59, 7 July 2009 (EDT)
I said it was hard to find.<g> Help:Name pages --Judy (jlanoux) 22:39, 7 July 2009 (EDT)
Well, I believe I added a surname or two when I first started using WeRelate; but I don't remember ever viewing the given name pages. Not sure I knew they existed. --Beth 22:58, 7 July 2009 (EDT)

I have tried to move Dallan's notes on searching to Help:Name pages and remove indications that the pages are for discussing names. Please fix or notify me if you see a problem. Is there a better place to add the notes on how searching works? --Judy (jlanoux) 15:26, 18 July 2009 (EDT)

Help:Search?--Dallan 11:06, 28 July 2009 (EDT)

Bookmarks Feature... [28 July 2009]

Is there a way I can bookmark pages for future ease of reference? I thought perhaps I could set up a mock tree in FTE to save pages I want to be able to find easily, but I don't seem to be able to save templates to a tree.

What I'm looking for is a place to store the pages I go to all the time, from the templates I've created to the help pages I use alot (formatting, titling pages), to even some of my favorite sources. I suppose I could use the Bookmarks in my browser... but I thought I'd ask to see if there is something I'm not able to find. Thanks, Brenda--kennebec1 22:21, 1 July 2009 (EDT)

I've started a user page with a Cheat Sheet for the things I want to have handy, including templates. You might consider this method. You can also try your browser's bookmark feature. You can create a user page from the add menu. --Judy (jlanoux) 23:28, 1 July 2009 (EDT)
If you spend much time on Werelate, having someway to get back to what you were doing last month is a good idea. I find that I forget quickly what was being worked on, (even as early as this morning!) and so some sort of navigation tool is helpful. I use my user page for exactly this purpose. (User:Quolla6). The page itself isn't particularly neat, since I use it as a work desk---a messy workdesk at that--- but the main table provides a set of links to various pages that I've a need to get to (and remember) from time to time. Some links take you to other tables that do essentially the same thing. In effect, these are hierarchical navigation tables so I don't have to remember things. There's some crude organization to the main table in that its divided into four columns, with more or less with distinctly different items in each column. Items that I use more frequently are cluster toward the top. Possibly the most frequently used link is the one to "Contributions", which brings up the "special page" that gives my recent contributions to the site. (I could use the link in the main menu for that, but having all of my navigation tools in one place means one less distinct pathway to remember.) Q 09:07, 2 July 2009 (EDT)

Every once in awhile I think about adding a bookmarks feature but I always talk myself out of it because of services like http://del.icio.us that do a terrific job of managing bookmarks - much better than I could come up with. But if there's a general desire I could add it to the todo list.--Dallan 01:36, 4 July 2009 (EDT)

I hadn't even thought about Delicious, . . . even though I have a large bookmark collection there myself. The thing is, though, that's an outside tool, and if you want to maintain a current work-list of WeRelate pages there, you'd be constantly adding and deleting them. And since they're of no particular interest to other Delicious users, you would probably want to mark them "Private" as well. I think what people are suggesting here is a quick page-marking tool, like the bookmark feature in FTE. Something you can easily add and delete, maybe even more than once a day, as you change the place you're presently working. Personally, it hasn't been an issue with me, since I tend to move slowly through a tree, working on a sub-group of people or families, getting it finished, and then moving on, so I don't usually forget where I am. And I keep a WeRelate section in my brower's bookmark list for Special pages and such that I go back to regularly. --Mike (mksmith) 12:02, 4 July 2009 (EDT)
Over vacation I've had some time to think about this. I agree with the above. My current plan is to add three buttons to a new UI that will open pop-up windows for quick navigation: bookmarks, recent edits, and watched pages.--Dallan 11:06, 28 July 2009 (EDT)

Regimental page(s) [5 July 2009]

Over the past several years, I've been collecting information on the 1st Ohio Heavy Artillery (Civil War). I've decided to start adding the data to WeRelate. A few days ago, I uploaded the first of what I hope will be several GEDCOMs of the men from the 1st OHA; so far, the members of Company A all of have pages. My vision is to have a page with the unit's history, a bibliography of sources and suggested readings, and links to rosters of all the companies. Those rosters, in turn, will have links to the soldiers' Person pages. The beginning of the main page can be found at 1st Ohio Heavy Artillery. At the bottom of the page is a link to 1st Ohio Heavy Artillery, Company A, with its roster and links to some of the members of that company. I would really appreciate feedback on the pages (both the regimental/company pages and the individual Person pages). Some of the Person pages will be more robust than others, as I have photos of gravestones, GAR records, etc for some. One thing I would like to add on the Person pages is the source for the muster in and muster out info. I remember seeing somewhere that somebody figured out a way to have footnotes within the text. Could someone point me toward that code? Thanks in advance for any feedback you might give. --Ajcrow 23:07, 4 July 2009 (EDT)


After posting my message last night, I thought of a better way to present the data on the Person page. Instead of just lines of text with line breaks afterwards, I'm making them unordered lists. Person:Robert Cooke (8) is an example of the new way I'm trying it. --Ajcrow 09:05, 5 July 2009 (EDT)


Template:Cite may be what you were looking for. It lets you insert a link to a source in the text. That sounds like a nice project.--Judy (jlanoux) 10:33, 5 July 2009 (EDT)

Thanks, Judy. That's what I was thinking of. As I've been playing around with formatting the info on the Person pages, I think I prefer the format for Person:Stephen Crabtree (1). It doesn't use a footnote, but it is very clear where the info came from. --Ajcrow 10:47, 5 July 2009 (EDT)

Gay Marriage [28 July 2009]

Now, how do I enter that? I keep getting up with mixtures like 'alternate husband" and such. It is rather common in our country, you know {proud to say}. So, tell me how . Tnx. Leo - Europa.--Leo Bijl 03:02, 5 July 2009 (EDT)


I've been contemplating this. I don't think there's an approach that is directly supported by the structure of werelate, but I do think there are good approaches that maintain the information while respecting the parties to such relationships.
The model I would propose is like that I use for an adoption in my near family. I don't put the child in as literally the child of the adoptive parents - because in my case, I know who both sets of parents were and need to record all that information. I reserve the family relationship for biological parentage - whether it was really much of a family or not. I record the adoptive relationship within the body of the pages for all the parties concerned, along with appropriate hyperlinks. Also, for werelate purposes, if a child is shown as having two sets of parents, we generally understand that to mean that there is question about who the parents of this child really were.
Barring a medical break-through, gay marriage will not be producing biological children, so I wouldn't seek to force a "family page" to serve in that role. Also, the family page is structured along gender lines and you would wind up with duplicate mothers or fathers - which around here we generally understand to mean there is a question about who the real spouse was - not that there are literally two of a kind (see the problem above).
I would propose that such relationships be described either within the body of the page and/or as additional facts for the people involved (say, an "other" fact) with a description that there is a life-partner/same-sex spouse, and a link that jumps to that person's page.
Seems like a new set of guidelines is in the offing. Someone else want to paint a bulls-eye on their back?--Jrm03063 09:41, 5 July 2009 (EDT)

I don't see a problem. I just went to sandbox and created a family page with two male partners without a hitch. Most properly designed software can accomodate alternate situations. You are, however, stuck with the terms "Husband and Wife" just as your are with other situations such as where the partners were not married. That's a minor cosmetic thing - part of the scenery, and doesn't affect the utility of the program. I tolerate some variance with labels as they are useful in helping guide beginners. They are easy to ignore. It's hard to find a label that's going to be accurate 100% of the time when you let users decide how to use the program.
So if you want a family page you can do it. If you would prefer not, you can just note the partnership and link to the other partner in the text box. --Judy (jlanoux) 10:53, 5 July 2009 (EDT)

Ah, yes, I'm afraid you do have a bulls-eye... (said with a smile!) Gay partnerships quite often produce children, and many of these children are biological. In most cases, the child is biologically related to only one partner, but there are several scenarios in which two women (or actually two men as well) can both be biologically related to their children. More to the point, these relationships (whether called marriage or not) ARE the family unit for the children and adults involved (meaning there is not necessarily an other "biological" person to put into the missing father or mother slot).

Just as is true throughout history, not all children of a marriage are always biologically connected to both parents. Sometimes, as genealogists, we know about the the details behind this, and can make note of the difference between biological and adoptive parents (I have one family story where I have done this). Other times, we may know there was an adoption, but may never know who the biological parents were (I have another family story where this is the case). In most cases, we don't know one way or the other, and just go along assuming that just because two people are married, their children are biologically related to both parties. We're probably wrong about one parent (usually the father, for obvious reasons), a small, albeit significant, portion of the time.

For WeRelate today, lesbian or gay couples with children won't be too much of an issue, because we can't put in information about living people, and most open gay and lesbian families with children are within the last twenty-five to fifty years (with the shorter time frame reflecting the dramatic rise in the use of various reproductive technogies by both heterosexual and homosexual families). Someday, future genealogists will have to wrestle more significantly with this dilemma - documenting both biological and social lineages, because certainly being brought up by a particular parent, even without direct biological ties, has an effect on who a person becomes.

As a never-married single parent, I've chafed under the limitations of "husband" and "wife" in most genealogical software as the only means to describe the relatiionship between two people that results in a child. But I'm still alive, so my child's particular genealogical burdens aren't yet a big problem for WeRelate.

Still, it would be good to begin planning for these changes in definitions and relationships. Why not have the "husband" and "wife" labels be modifiable? Does it matter to the software or to the wiki whether Party A is called a Spouse, a Partner, or a Husband? or party B is a Spouse, a Partner or a Wife? I understand there are conventions (important to detecting duplicates) that put one name first, or on the left in a tree, generally the male, and so if a relationship involves two men or two women, someone has to decide who goes first... But Spouse allows inclusion of same-gender couples, and Partner provides a way of defining a relationship that produces a child, but is not necessarily marriage.

This would be a good way to document the relationships between people as part of a life story. I suspect the relationships between parents and children really should probably be a second selection box (i.e. in Family Tree Maker, one selects a Spouse, and then chooses the Gender of that person, and then in a separate location selects whether each spouse is natural, adopted, step, foster, related, guardian, etc. to a particular child).

Just some possibilities... - Brenda--kennebec1 21:12, 5 July 2009 (EDT)


I'm certainly not making a value judgement on one relationship type or another, but I should think that the correct answer as to how this is all represented lies in the root word of the discipline: GENE. When we designate a father and mother, we're asking who contributed the genetics. We're not saying that either parent had value beyond being a contributor of relevant proteins. I think we all know plenty of examples of biological parents who are unworthy of the title "parent", but we're stuck with it.

When we look at relationships that are profoundly important - but not genetics based - then we're talking about family history. Critical to be sure, and part of telling a full story, but not genetics.

In the case of two women, where one contributes the egg and the other contributes the reproductive tract, I think we still have to fall back to the genetic definition of mother.

In the case of two men, I suppose you could mix their contribution so that the actual father remains unknown. Fair enough, then we have two potential candidates as we might in other - ehem - less planned out - circumstances.

As much as I value and respect the relationships of the "parents as a matter of practice", it is a separate question than that of "parents as a matter of genetics". When data is available, we need to represent all of the critical relationships for a person - but the "family" page really has to be left as the "genetic family" page.--Jrm03063 22:32, 5 July 2009 (EDT)

As a follow up on my own remarks above, we really want to leave the biological family page alone partly so that the presence of multiple spouses of a common gender can be recognized as a potential data error. Likewise, having a child appear as the biological child of multiple families, this too is recognized as a possible data error. If folks want a "top level" way to handle this (not simply noting it as a family fact or in the body of the page), then it might be better for Dallan to define a new sort of "family" page, that is not constrained by genetics.

--Jrm03063 22:41, 5 July 2009 (EDT)

I don't disagree with you regarding the *point* of GENEalogy. But I'll note again that we are wrong about one side of genetic lineage in a certain number of historic cases, and that reproductive technology (anonymous male or female donors of genetic material) will erase access to one half of the lineage equation for certain number of folks in the future. For both men and women couples, I was also thinking of scenarios in which one partner is biological parent and the other a biological uncle or aunt, or where both parents are biological parents of different children, although raised together as siblings from birth. These are fairly uncommon scenarios, and actually possible to document more or less in the context of genealogy as it is set up today.
Well, I've got a "primary/personal" genealogical space of a couple thousand. Within that there are several adoptions, and a couple of cases of teen girls - giving birth out of wedlock - having their children raised as if they were younger siblings (and the birth certificates were written to support the fiction!). The exceptional cases are probably a lot more common than we give them credit for. --Jrm03063 08:37, 6 July 2009 (EDT)
I can see that Family pages as they are today are SIMPLE and straightforward, and that is a great benefit. As Judy pointed out, they have the capacity today to hold a couple of any gender, so there is no urgent need to change. Still, the ability to set these relationship and family units in a more flexible way will almost certainly become necessary in the future, so it is good to start thinking about how to build that.
If we agree that Family pages are, at their core, about documenting genetic parentage, the use of the Husband and Wife label for those known (assumed) contributors of genetic material may well have worked 200 or even 100 years ago. However, they are becoming increasingly incomplete today. And, in the past one could assume that the contributors of genetic material and "social upbringing" were more or less likely to be the same people. But that is MUCH less likely to be true in the last 50-75 years, so the next generation of family researchers are going to have to wrestle with these questions more and more often. As the contribution of genetic material and the contribution of social upbringing increasingly have the potential (likelihood) to separate, due to divorce, remarriage, reproductive technology, etc., it is going to become more and more of a research challenge to find ways to document both aspects of a person's history.
Husband and wife are indeed troublesome labels. We routinely ignore them in the royalty space with regard to mistresses, where there is no good way - presently - to indicate the lack of a (so-called) "proper" marriage.--Jrm03063 08:37, 6 July 2009 (EDT)
So, why can't Family pages serve both needs? Absolutely, the core data piece for genealogy is to document biological relationships when known. But since many genealogy researchers are also interested in the family history, and since not all biological relationships are known, isn't it better for us to have a way to specify for any given child+parent pair what is or is not known/assumed about the relationship with that parent? To me, that covers all the bases, and separates the adult-adult relationship from the adult-child relationship (which can vary widely within modern blended families).
I guess when I call it a separate page, I'm talking about it from a software design point of view. The rules for a biological family narrow what the contents of the family can be. Those rules give us ways to validate the data base and find our way to possible defects quickly. In large data sets, any help you can get along those lines is not to be ignored. A non-biology defined family page is fine too - and if users want to wrap themselves around the term "family", well, it can certainly be labeled as anything you want. You just need - at least internally - to have objectively different things for the software to deal with. --Jrm03063 08:37, 6 July 2009 (EDT)
So, if the relationship between child and parent(s) is defined as "natural," or "genetic" then the data is eligible to be validated by the rules of the biological family, right? And then maybe some variation in the validation rules can be applied to other family scenarios. One example of this is the whole question of the linear order of spouses. Obviously, if Jane Doe is John Smith's first wife, she can't be "related" (as stepmother) to his later children. So if the software learns to arrange spouses in date order, at least one additional set of validation criteria can be applied.
It seems to me keeping family units intact in some way (even when they are not genetic units) does serve other research conveniences (in part because that is how much data will be found, such as the census). But it does complicate the basic simplicity of WeRelate, because it means that any given person can be connected (correctly) to more than one set of parents, depending on the circumstances, even tho only ONE set of parents will be the biological parents (although who those parents are might be a matter of dispute, as they are today in our family pages).
Another aspect: we may increasingly need a way to distinguish between disputed genetic parentage (child of couple A+B or child of couple A+C? being the most common we see in the database today), and legitimate alternate parents (adoptive parents, step parents, or even primary parents of the same gender. You sound like you understand more than I do how the software works -- does that make sense? Again, I don't think this is the most urgent question facing WeRelate, but we will definitely have to deal with the variation in family defination when new users import data that may not reliably stick to the "Husband + Wife = genetic parents" understanding. -Brenda--kennebec1 09:55, 6 July 2009 (EDT)
Another way to think about Family pages is as Father and Mother pages (vs. Husband and Wife). Define the Family page as "Biological Parents," but then document other relationships on the person page (i.e. adoptive parents, step parents, etc.) and allow different definitions of how the Father and Mother might relate to each other (meaning they may or may not be married, and one party may well not be known in the future).
Sure, I think this is the direction we're talking about. We could even jettison Father and Mother in favor of "XX" and "XY" if we really want to go vanilla... !--Jrm03063 08:37, 6 July 2009 (EDT)
I'm really not necessarily proposing a specific change; I don't think I know enough yet about how WeRelate works. I just think this is a really interesting question to try to wrap our (collective) minds around, in terms of how genealogy and family history studies will change as a result of the changes in the world over the last fifty years or so. --Brenda--kennebec1 00:02, 6 July 2009 (EDT)

I'm joining this interesting conversation late, but I have to say I'm a bit surprised at the insistence that a "family" record should be strictly limited to genetic families. To my mind, adoptive families are every bit as important (and in some cases even more so) than genetic parentage. Even our surnames don't necessarily follow genetic lines. Omitting non-biological families would seem to me to be a significant gap for research. But maybe that means I'm doing "family history" as opposed to "GENEalogy". :-)

To look beyond my own opinion, I note that in the GEDCOM standard, it is explicitly provided for that an individual can have multiple links to families, where the "child_to_family_link" has an attribute that specifies whether the link is adoption, birth, foster, or sealing. And the Personal Ancestry File software supports multiple child-family linkage, prompting you to specify the linkage type. I had thought WeRelate did the same, but I just tried in the sandbox, and I didn't see any place to put an attribute on the child-family link. Adding a second parent family just shows up as "alternate parents". It probably would not be hard to add an attribute to that relationship, and to show "adopted" or "foster" in the place where it currently shows "alternate". In the mean time, I would think it perfectly appropriate to link children to both their adoptive and biological parents when known, with appropriate explanations in the text.

Going back to Leo Bijl's original question, it appears that WeRelate will let you construct a family with a male "wife" or a female "husband" (I note that other software, such as PAF, won't even let you do that), so that's probably the best you can do for a same-sex marriage, and live with the inappropriate role names until the software gets more flexible. But I agree that that's probably not high on the priority list for WeRelate, especially, as someone else pointed out, same-sex marriage is still quite new, and most of us same-sex married couples are still among the living thus not yet topics for family history. :-)

--TomChatt 02:26, 9 July 2009 (EDT)


I'd recommend User:TomChatt|TomChatt]]'s approach: create a family with a male wife or female husband, or create one with two husbands/wives. You can certainly store multiple sets of parents for an individual, and I do have plans to allow people to track the parent-child relationship (adopted, biological, etc.). Eventually it wouldn't be too difficult to modify the tags, but as has been said, I have some time before it becomes a widespread issue.--Dallan 11:58, 28 July 2009 (EDT)


proposal to amend WeRelate licensing [28 July 2009]

I'm posting this here in case people don't see it on the homepage.

The board of directors of the Foundation for On-Line Genealogy invite the WeRelate community to vote on a proposal to to license WeRelate material so it is available under the Creative Commons Attribution-ShareAlike license (CC-BY-SA), while retaining dual licensing with the GNU Free Documentation License (GFDL). Voting ends July 27. Read more...

--Dallan 13:13, 6 July 2009 (EDT)


The voting has been unanimous to amend the WeRelate license . I will make the amendment later today or tomorrow. Thank you to those who voted!--Dallan 12:00, 28 July 2009 (EDT)


Add: Source - fields not saved [13 July 2009]

Could someone familiar with how ADD: SOURCE works please visit:

Help_talk:Source_pages#Add:_Source_-_fields_not_saved_.5B7_July_2009.5D

and answer my question there? Thanks!

jillaine 12:57, 8 July 2009 (EDT)

There isn't a special trick to adding a source, I've done it. But I have had cases where all of the data disappeared from an edit on several different occasions. I have been assuming it is a glitch in the web connection. I have learned to save more often. --Judy (jlanoux) 13:16, 8 July 2009 (EDT)


This problem was resolved. See link for the answer. jillaine 09:54, 13 July 2009 (EDT)

Is a Wiki really for you? [28 July 2009]

Ask yourself this question. Why did you join WeRelate? I joined because I plan to leave my research here for future researchers to expand upon, rather than having to reinvent the wheel, so to speak. I was also excited about the prospect of collaboration. I also believed that I could edit pages without being attacked. What happened to the idea that one could simply revert to the previous version? We already have semi-protected pages on WeRelate. Some of them are worthy and some are not; this is reflective of the determining factor; the number of watchers on the page.

I have agreed to remain on WeRelate until the duplicate merge review is finished. After that it depends on how I view the level of civility on WeRelate.--Beth 22:40, 8 July 2009 (EDT)


Why did I join WeRelate? I joined because I had imagined the great potential of wiki technology for genealogy, and had been thinking of doing it myself when I discovered -- to my great delight -- that Dallan had already done it, and had done it with all the features I had hoped for and then some. I've been working here on and off since I joined in Dec 2006, including some "project work" (Scotland place pages), and have had only good experiences. I haven't had the experience yet of actively working on the same lines as someone else, but I have crossed paths with folks working in the same towns and times and had useful research exchanges, and I have also had "passive linkage", where I've connected into other folks' GEDCOM uploads. I've also had a chance to do some merging, and to clean up some perpetuated mythology and perform some needed disambiguation, tasks where a wiki is a particularly good tool.

I'm very sorry to hear that Beth has had what sound like some negative experiences, being attacked, I surmise, for making changes to pages that somebody thought "belonged" to them. I haven't experienced that myself, but with a wiki, it's probably just a matter of time. The openness of wiki collaboration is both its strength and its weakness. On the Internet, you run into all kinds of characters, some of them with no manners at all, and sometimes, as Kipling says, you just have to keep your head when all those around you are losing theirs. I hope those kind of experiences remain the exception rather than the rule here on WeRelate. --TomChatt 02:51, 9 July 2009 (EDT)


I too think a wiki is the ideal medium for genealogy. I have hopes of eventually emptying my file cabinet here so that all of my research can benefit someone else. Now that we have WeRelate, I find that when researching I tend to enlarge my scope to allied families and research a few generations of them so that it can benefit more people. I have never in 20 years online found a site where it is possible to post without what you call "attacks". I do note that possibly some people do not realize how sharp their posts come across when questioning an action or how strident we may seem when stating our opinions. But, it is hardly something that makes me want to "take my ancestors and go home". The regulars at WeRelate are an enormously dedicated group and I marvel at how helpful everyone is to me as a wiki beginner. We can all help make WeRelate a nicer place in two ways: 1) take an extra minute to reread before posting to make sure that our posts have the tone we intended and 2) avoid overreacting when questioned. The gedcom and merge processes will cause us to unintentionally stray into pages that someone has slaved over. I try to review the results, but sometimes miss one because a merge can affect so many things at once. But keep in mind that even the one who posts a comment that you object to needs a chance to learn the wiki way. --Judy (jlanoux) 09:19, 9 July 2009 (EDT)


I've been around wikis for awhile now, which perhaps is why I've taught myself to be patient and calm in a wiki environment. (Surprise: I'm not always so patient and calm in the real world.) At Wikipedia, for example, anyone who becomes strident on a Talk page because "their" contribution has been rewritten, is quickly sat on (sometimes pretty hard) by the regulars who understand the wiki philosophy. Go through that once or twice, and you either get your feelings hurt and go home, or you learn how things work and become part of the productive mass. Some people just aren't wiki-friendly, it's true, just as there are some you would not want to share an office cubicle or an airplane seat with, but most people adapt -- especially most genealogists, because they learned to cooperate with other researchers long ago.

I'd like to suggest, by the way, that the gist of the posts in this section (and the others I hope will be added here) be reworked and added to the "Welcome to WeRelate" section on the home page. --Mike (mksmith) 13:28, 9 July 2009 (EDT)


As a comment from someone wo recently did merges on my uploaded gedcom for the first time - I found the merge process quite straightforward but I feel there should have been a notifier when I was to merge with a page in someone elses tree, If there had been (or if I had seen it) I would have proceeded more cautiously.

Indeed as WeRelare matures an hopefully covers a considerable part of the geneological space, this will happen more and more, and hopefully the pages already there are quite complete. Perhaps an alternative to a "merge" would be a to opt to link to and then the new person could add information to pages in a more WIKI type approach (as when we make additions to Watercooler, we dont overwrite)

In fact if weRelate is really successful, further down the track people new to weRelate might identify a near ancestor, then find 90% of the genealogy and local history here anyway removing half the fun I suppose) then might pursue in a different way, maybe just adding "I'm Related" type messages in social media type fashion. What I'm saying is the most popular functionality will change over time, as weRelate matures


I do really think that if someone is prepared to take responsibility for a person, family or place, (Tending the grave) then they should be respected as such and encouraged to accept additions rather than changes thrust upon them. Others may be more skilled as genealogists or historians, but if they aren't prepared to tend the page in an ongoing basis then they shouldn't frustrate someone who is, or drive them away.

One driver for someone to pur their research in here is the "who will maintain my genealogy when I'm gone" If your work is in here, and it becomes the defacto repository, there is more chance that will happen. However. if you have put all your hard work on here, but then realise it will quickly change beyond recognition, then the motivation is diminished somewhat.

To sum up - Warn people when they are to merge with 'anothers' page - Allow people to opt to link to rather than merge - Encourage people to take respnsibility for pages - Take a long long term view of WeReleate (eg in 50 plus years time)--Dsrodgers34 22:27, 9 July 2009 (EDT)

Well, that brings up a usability issue - there is an option in the gedcom upload process to just declare your pages a "match" - which means that you don't merge, and your information on those pages isn't uploaded. Your pages on their children/parents will just link to existing pages. If that's what you're looking for, apparently it's not especially clear. Perhaps there's also room to explain what it means to merge: by definition, it means you are merging with pages that someone else has added data to, but there is no such thing as "another's" page.--Amelia 22:32, 9 July 2009 (EDT)

My circumstance might be slightly different from most peoples. I uploaded a small GEDCOM to try WeRelate out then after I had improved my GEDCOM, loaded the full version (nearly 4000 people - residents of an english village during the census years.

I was using the show duplicates to remove duplicates within my 'tree' but after doing that, realised I had merged with people pages in other trees without even knowing it.

I havent tried a gedcom upload since it has had the merge function. Perhps it is more clear.

I'm stating the obvious by saying that in WIKI terms, allowing GEDCOM upload is just like making a total WeRelate novice a super administrator. Its OK while these trees remain relatively unconnected, but if WeRelate becomes successful and grows to have the coverage like some of the big sites, this will happen more and more. The discussion in here shows everyone knows that. I am just saying my experience as a novice suggests the warnings of what someone might actually do might need to be more obvious.

People will learn from their mistakes and get better at it , but could cause quite a bit of work for others in the meantime.--Dsrodgers34 23:21, 12 July 2009 (EDT)

I'm not entirely clear as to the problem that you encountered. You ended up merging your target people with lineages already on WeRelate? Were they merged with people that they should not have been merged? Or were you simply trying to keep the lines that you uploaded from being merged with the main tree (Pando)? If its the former then, yes, mistakes will happen I suppose. I'm not personally doing anything more than a very surgical merge when I come across multiple cards for a person in one of the lines I'm working on, but from what I've seen, even very experienced mergers sometimes error. If its the later problem you encountered, then I would guess that eventually the lineages you are uploading will be merged anyway.

It was a successful merge and the pages from other trees were not more complete than mine. Indeed I would like to have more such merge candidates but I don't think WeRelate is big in terms of UK based trees (yet) My comment was just that If someone comes in, fairly new to WeRelate, and a merge candidate is already a very complete page in WeRelate - is it possible a person might accidentally stuff up someone elses work ? Is the notification for Newbies obvious enough ? Compared to Wikipedia where someone trampling over other work is doin it intentioanlly, her a well intentioned person might do it accidentally.--Dsrodgers34 23:31, 13 July 2009 (EDT)

It's possible that a new person might accidentally mess up someone else's work. I think it's more difficult with the new GEDCOM upload because by default none of the GEDCOM data elements are added but all of the existing data elements are kept, so you would have to manually uncheck an existing data element to remove it. In the end though, people are going to make mistakes - no way around it. I'll be notified that someone has changed a page that I've worked on and I'll see that it's been changed for the worse. Hopefully I'll be courteous and understanding, and others will be courteous toward me when I make mistakes (which I'm glad to say they have been).
A counter-example to WeRelate is New FamilySearch. (The website is available only to LDS Church members.) In that website you're not allowed to change other people's opinions of names, dates, and places, just add new opinions of your own. There are many people on the site with dozens and even hundreds of different opinions. After 8 years of development and 2 years of operation, Ancestry Insider reports that the next version of FamilySearch, which they hope to start developing next year, will use an open-edit model like WeRelate.
I believe that courtesy is very important to the success of WeRelate. I like the comments that have been stated here. We have a Help:Wiki etiquette page, but it's not linked to prominently. Could someone please add the comments here to that page? I'll link to that page from the Portal:Community and feature it more prominently on Help:Contents.--Dallan 12:53, 28 July 2009 (EDT)

Urban Legend Needs to Die - No genealogy on Wikipedia [9 July 2009]

I've seen this in a couple of different people's reactions to WP content inclusion and/or interaction with WP. I've looked at a lot of WP biographical articles at this point, and I see no reason to believe this.

What I believe IS TRUE, is that articles about people of only genealogical note are frowned upon. Also, articles that represent reports of genealogy, for groups of people of only genealogical note, are also frowned upon. There exist many biographical articles containing significant genealogy (just search WR person pages for "wikipedia-notice" for thousands of examples). There also exist articles that are nothing but genealogy, but at least some of the subjects of such an article are of more than genealogical note.

So it is true that you can't generally "do genealogy" on wikipedia (unless your family is uncommonly famous). That does not mean there is not a lot of genealogical information to be had, reviewed, extracted, etc., on wikipedia - the individuals or families involved simply have to clear the standard of "notability". --Jrm03063 08:32, 9 July 2009 (EDT)


WP to WR External Links [10 July 2009]

I would like to hear from anyone who has a person page, for which a WP biography page exists, where the WR page significantly extends upon, clarifies, or otherwise improves the overall information on the WP page. I want to systematically put in WP-based links to WR articles, when we actually have something to add.

I've already been able to do this for a couple of pages, but would certainly like to do it for a whole lot more. Can anyone recommend specific pages?

--Thanks--Jrm03063 12:16, 10 July 2009 (EDT)

You mean inserting links at Wikipedia that take the reader back to WeRelate? That'll teach 'em. :) --Mike (mksmith) 12:26, 10 July 2009 (EDT)

That's the idea.--Jrm03063 13:11, 10 July 2009 (EDT)

2 Person or 2 Family Merges [12 July 2009]

I don't know if this topic has already been addressed; I was just doing some duplicate merges, and it seems like it would make sense to not have the merge checkboxes at the top of the comparison page when you're only comparing two people or two families, because you're already making your merge or not merge choice at the bottom with the two buttons.--Nathan 19:27, 12 July 2009 (EDT)

Also, when we click on "Not a Match", it would be nice to have a link back to the duplicates list, just like after we finish merging a person. --Nathan 19:49, 12 July 2009 (EDT)


I see your point. I suppose requiring the choice does add a little more certainty to the process though, and keep the steps symmetric with situations where more than two people or families are being merged. Still, I have thought that, until you have made some appropriate choices at the top, the merge/not a match buttons should be grayed out (though I'm not sure if that level of UI control is easy to get with a browser page).
But now that you mention it, I have a few related/nearby UI design concerns that I've never taken the time to note on the record. I'm not sure I like that lack of symmetry between the merge and not a match operations. Since the merge operation has a second step, where you get to nail down the details of how the merge is done (and implicitly, confirm what is going to be done) it seems like the "not a match" process should have a confirmatory step. There's also another little detail that I've never taken the time to groan about - when merging families, if more than one family contains the SAME person page as a child, the merge process presents them on the screen as if there are two identical pages. Of course there aren't, but it's not as clean as it might be.
But since I've know about these and said nothing for months - I'm not sure how big a deal they are...
--Jrm03063 19:55, 12 July 2009 (EDT)

Can WeRelate become a genealogy giant ? [27 July 2009]

I note the WeRelate home page suggests WeRelate is still in beta and also comments that the intention is to be the largest geneaolgy WIKI. I understand it is anyway.

I wondered if it will ever achieve the kind of critical mass close to that of Ancestry public pages ? (but still maintain high quality) This poses quite a few questions:

  • What sort of promotion would be needed to grow exponentially ?
  • How could high standards be maintained while achieving that growth ?
  • Could it still be administered on a voluntary basis (Wikipedia suggest it might)
  • Would that success prompt sites such as ancestry to adopt WIKI type functionality thus removing the need for people to move to something like WeRelate ?

I should say I use ancestry because I find its online tools for extracting its census information into a GEDCOM is perfect for my "one place" study. having cleaned up the GEDCOM I extracted from ancestry, I moved it here to do some REAL 'one place' work I can post a page about a place, a picture, an event - then link it to the people involved - There are many more relationships in peoples lives than genealogical ones - these get missed in 'traditional' family history HolmeVillageHome

If anyone else is a WeRelate "One placer" I'd appreciate any advice or comment--Dsrodgers34 23:42, 12 July 2009 (EDT)


DSRodgers,
Glad to see your comments here. Here and above, you raise some good questions and reflect experience of newcomers to WeRelate that we all definitely need to consider as WeRelate continues to mature. (BTW, I'm only slightly less-new than you are.)
I distinguish the purposes of Ancestry and WeRelate (for myself) this way (and this also answers the above question about Why I'm on WeRelate):
  • Ancestry is a research tool for working on "my" tree. It also supports my ability to share "my" work-- whether through private family-only trees, public trees or through Rootsweb's WorldConnect. (I prefer the latter)
  • WeRelate is a place for me to contribute what I've done to a larger community effort, relinquishing, if you will, the "my" of it, although the contribution does contain results of "my" work. While I will continue to work on "my" tree, I do that in my offline version (or my Ancestry version if I had one). Despite the creation of the ability to download a tree from WeRelate, I am not likely to use that feature-- at least right off-- because I want greater control over "my" work, which I will maintain myself. The work I do here on WeRelate is aimed at building a single community tree (I think Dallan calls it Pando or something), of which "my" work is a part.
Ancestry attempted to do something alone the lines of the latter through its OneWorldTree. They abandoned this effort because the culture they'd set up was focused on the notion of "my" not "we" and many people were really annoyed that "their" info was being mixed up with that of others. Ancestry would do well to keep their focus/niche on being a research tool for individual researchers, and stay away from "wiki-ness".
HERE, the intention going in (although your comments make me think WeRelate hasn't communicated this effectively enough) is that you are contributing to a "we". Therefore, as you found out, your merging of duplicates included not only duplicates within your own GEDCOM but with duplicates that were already here before you contributed your GEDCOM. And in *my* mind (grin), WeRelate would do well to keep its niche/focus on collaboration, and NOT as a research tool, even though the site will have that benefit for most of us. Just not in the same way as Ancestry does.
So those are my two cents.
Oh, one more thing. In answer to your one-place question. I have such a project underway. I am focused on a German town called Schwenningen. I started it over at Rootsweb's free web pages, and I intend to move it over here by the end of the year. My GEDCOM for this town is now over 10,000 people, and includes many lines-- in some cases to the present-- of those who emigrated from the town to the U.S. (mostly). I perused your Holmes pages, and the difference I see between our efforts is that mine is currently more focused on the lines and the people, not so much the town. My goal with it is to help people here in the states (mostly) find their link to their appropriate branch(es) in Schwenningen, and to connect us with each other.
-- jillaine 08:13, 13 July 2009 (EDT)

There are a number of similar focused projects---where information is being collected about a specific group of people, either united by a common location, or some other factor. The Southwest Virginia Project would be one example, but there are other's under development.

{{Regional Project List}}

In addition there's at least one similar project related to a military unit 1st Ohio Heavy Artillery There's also a regional surname project: Coleman Family Exchange Collecting data on all things Coleman

I expect in the course of time there will be more of these projects, simply because its a natural in the context of WeRelate. Usually such projects are too large for anyone person to do alone, and in a Wiki many hands can (and will) work on a project.

As it happens, I've been involved to some extent with each of the above, sometimes more directly (SWVP, Old Chester which is just starting up), sometimes just lending a helping hand. As we go along with these we learn more about what works and what doesn't. I've tried a lot of different approaches, and seen others use different approaches, to solve various problems. Some solutions are more successful than others. I've backed out of a fair number of things because they were simply too cumbersome to work. (Using the Talk page to collect data was, I found, a particularly misbegotten approach. Good for discussion, but to small space to work for heavy duty data representation.)

From my experience here I can make a couple of suggestions about features that I think are very important for a project.

1. Banners and Badges. You will eventually find that you have many hundreds, if not thousands of pages housed within your project. Its a good idea to make sure that those pages can be easily distinguished as being part of a specific project. That way, when people visit a particular page they can quickly see that the page has an overall context within which it fits. There are some technical reasons for doing this (see below), but the main reason is to give pages with in the project a consistent look and feel. It basically gives people "hooks" to help their understanding, and to aid in project recognition.

I think this can be accomplished by using "Banners" and "Badges", usually displayed across the top of the page. It gives instant recognition that a page is part of a particular project.

2. Navigation tools. You need a way to allow folks to navigate from one part of your project to another. The basic navigation system on WeRelate works very well indeed for navigating "up and down stream" along a lineage. But the problem in a project is that you have many unconnected lineages within its boundaries---getting from one to another is not easy. So there's a need for a supplementary navigation system that allows you to move "laterally" across the project. There are probably many approaches to this, and I'm always looking for new ideas about how to do it. But a common denominator across the existng projects, and one that I think works well, is to incorporate a navigation device within the Banner or Badge. For example

{{template:SWVP Banner}}

includes a link back to the project's main page. There the user gets an immediate overview of the project content, and can navigate to different components. As you can tell I like to use icons to identify links to different components. While I'm not entirely consistent about this, you'll often find that the icons shown on the main page often also appear on the target page ---just to reinforce the user's "sense of place" within the project. I personally like to use a lot of graphic elements on a page; my thinking is that a) it makes the page a bit less bland, and b) provides hooks on which help people absorb information quickly. (The less they have to think about how to get around the more they can concentrate on what they came here for. Good graphic elements make that easier to accomplish.)

Because the link back to the main page is contained within the banner (learn to use templates!), it appears on every page that has the banner, and allows the user to quickly return to the main page when they need to look at something different.

One of the things that I've started to include in the template for the banner (in addition to the iconic banner itself, and a link to the main page), are a smaller set of icons blow the banner that allow the user to navigate to specific parts of the project. I've not done this yet with SWVP (and may not: too many pages to retrofit, unless I fiddle with the banner template.) But I've started to add this as a contribution to some of the other projects, particularly with User:Delijim's Old Augusta project. This includes a series of five icons that take you to various subject areas. I reuse the same icons for these areas in different projects, so that it minimizes the time the user needs to orient themselves to the local navigation system. For most of the projects that have been started this would work well, because they have a common relationship---early pioneer settlers in PA and VIrginia during the Colonial period through the Revolutionary War. So, for the part of the SWVP dealing with people that are considered in the project, a common icon (based on a painting of early settlers passing through the Cumberland Gap) works well

---nicely conveys a sense of people settling a new land. But this wouldn't work at all for User:ajcrow's recent initiative for the First Ohio Heavy Artillery project.


Many thanks for your feedback, which I will peruse soon.

It did strike me that if enough people approached WeRelate in terms of "projects" it might soon take critical mass and become a first point of contact for collaborators. I'd love others to get into my project. I have tried to inerest those on ancestry who overlap my area. They come and look, but do not stay. One person is happy for me to take her protographs and data from Ancestry and place them here.

It struck mme that local FH soceities ,who in the past did transcriptions and indexes (maybe even gainingsome funds from the se activities)now find that increasingly being done by such as ancestry (not as accurately, but with critical mass which means thy become a first point of contact) If those soceities and groups did something like 'Projects' on something like werelate they could establich the GEDCOM 'framework' for a place quite quickly form ancestry and then add the 'niche' stuff which sites such as ancestry cannot do. I talk of photographs, events, workplaces, stories etc completely linked to the participants.

On ancetry itself - I agree they wouldnt revisit the 'one world' tree - but if they had place, event pages which were independent of their person page that might take off. Where they cannot compete in my mind is it terms of quality and correctness - they are clearly not too concerned with that.--Dsrodgers34 23:43, 13 July 2009 (EDT)


Re Dsrodgers question – Can WeRelate become a genealogy giant? At the moment, my opinion is no. I belong to a genealogy group of about 35, mostly seniors. They are keen about their family history and seem to do excellent research. When I try to imagine them using wiki genealogy I come up with only 1 or 2 that might try. That would leave about 95% uninvolved.

I would like to talk to the group about WeRelate but I don’t know how I can keep it simple enough such that most would at want to download a gedcom without concerns about the techniques of wiki enhancements. What I/we need is some sort of – “WeRelate for Dummies”. I don’t see any need for immediate perfection of someone’s wiki genealogy as there will be many future years or decades for others to make improvements which, of course, is one of the attributes of wiki. The following situation where simple instructions would have been useful occurred recently. A lady with about 15 years of family research was just told she had terminal cancer and was desperate to find a location where her research would benefit others. I suggested wiki genealogy to the hobby genealogist who was telling me the story and I could see my comment meant nothing to her. I tried to explain but gave up. Had the individual’s gedcom been downloaded it is obvious that she would have had little or no opportunity to follow up.

Please note that I am not criticizing the admirable work done by WeRelate contributors and I believe wiki genealogy will be very important in the future. It’s just that somewhere, somehow, there has to be an entry point for those who simply want to submit their family tree.--HLJ411 15:47, 16 July 2009 (EDT)

Your points are well taken.
There's considerable discussion going on along the lines of making WeRelate easier to use by the average hobby genealogist. The goal, I think, has always been, and I believe, continues to be, to make it "drop dead easy". But that's a surprisingly difficult goal to achieve. The problems that have to be solved to "wikify" genealogy, are much more complex than might be thought at first. In its current state of development WeRelate works best for genealogists with better than average genealogical skills, and very good computer skills. This has proven true on virtually every implementation of "wiki genealogy" that I've examined. The fact that you can upload a GedCom is wik-unique to WeRelate, and allows even a novice user or genealogist to at least upload and save their work to this site. What happens after that gets a bit more complex---and in part that's because of Pando. All other no wiki genealogy websites allow you to upload your data and you can expect that that data will remain "yours"---basically an extension of your desktop program, that allows others to see what you have, but not to edit. Here, once the data is uploaded, it belongs to the community as a whole--it is, after all, a wiki. And because the intent with WeRelate is to create a single, monolithic one-person one card family tree, there are a lot of different things that have to be worked out and gotten used to. One of the main differences is that sites like Ancestry allow you to create your very own alternative reality of your family history. As a result, when you examine the lineages on these sites, you can find dozens' of different versions of someone's lineage---different DOBs different DODs different spouses different parents. Here, in theory, there can be only one. A consequence of this is that there is great emphasis placed on sources, and documenting "how we know what we know". You can get by with shoddy documentation on Ancestry, because it only affects you personally. Here, everyone interested in a line, has to come to agreement on what the right data is---and the only way to do that is to be able to provide the necessary source underpinnings to show why a DOB of 1703 is correct, and 1704 is wrong. This might not seem like a big deal, but in truth, its a very difficult problem. And a problem being attempted on this scale nowhere else that I know of.
So yes, WeRelate does have some problems in making things easier to use. But fortunately, site administration is very very responsive to input and alternative ideas, and is constantly "pushing the envelope" as to what works and what doesn't. I've been working here for about not quite two years, and have seen enormous strides in "workability" as different problems get ironed out. Problems remain, to be sure, but since the site remains in Beta mode, this shouldn't be seen as a problem, but as an opportunity to help get it right.
Which brings me to another point. Many of the genealogists using WeRelate are very skilled at what they do. But genealogy is only part of their skill set. Those who continue to work WeRelate on a daily basis (as opposed to those who just dump their GedCom) have, by and large, an additional skill set. They are sufficiently computer savy to find workarounds for whatever problems they encounter. That's a benefit for Werelate, because their work becomes an example of what can be done. It also has its drawbacks---namely, they often don't see the problems the less skilled user is likely to encounter. We all have a blindspot when it comes to understanding what is likely to give a new user trouble. When you have considerable computer skill, solving problems is second nature, and you often don't see the problem at all---you just solve it, and go on. But the novice user doesn't usually have that capability. What for some is a simple problem that doesn't even rise to the level of being recognized as a problem, is for the novice a complete and total roadblock. Skilled users don't see those things, and so don't recognize what gets in the novice user's way. And if you can't see a problem, you can't fix it.
Which is why postings like yours are particularly useful---yes, we know there are "usability issues", but what are they? What is it that you found that you think are stumbling block? What makes it hard for folks to use the site? That kind of insight would really help make the site sing for a wider audience. Q 16:38, 16 July 2009 (EDT)

I'm with Howard (HLJ411). And I'm glad he said it. There's been a lot of talk about "abandoned" GEDCOMs here and elsewhere on the wiki. That somehow if someone uploads a gedcom and then walks off (or in this case, dies of terminal cancer), that such gedcoms shouldn't be allowed.
Horse snot! A wiki is a much better place for such gedcoms than something like WorldConnect. I've seen some gedcoms on WC where it's been added "Contributor is Deceased..." Hopefully in those situations, at least their GEDCOM is downloadable (the default at WC). But how much better if it had been put up at WeRelate where others could work on it, and continue the fine work that someone else started.
I can *easily* imagine at some point feeling like I'm "done" with a particular branch of work. Where I want to stop spending time on it--with or without the presence of a terminal illness or accidental death. When that happens, it makes complete sense to me to upload such work to a wiki where others can-- should they feel so moved-- continue the work.
So I really wish we'd stop talking about "abandoned" GEDCOMs. I completely understand and have witnessed recently some really BAD GEDCOMs. But frankly, if someone uploads a really well-sourced, excellent GEDCOM and we never see them again, I'll still stay Thanks for making it available!
jillaine 16:07, 16 July 2009 (EDT)

There already are plenty of sites to upload your GEDCOM and have it sit there available for other people to copy.

As has been pointed out elsewhere, WeRelate is trying to do some things that are not commonly done, one of which is force everybody into a single tree. This brings a different process, which is sufficient to cause some people to recoil in fear of the unfamiliar. Well, if things are just done the same, you will get the same result. Since there already are places like that, if WeRelate was happy with that result, I suspect the developers never would have started this project.

My viewpoint is that, while I want lots of people cooperating, the cooperation part is far more important than the lots parts. And I imagine some people will find this whole experience is not their cup of tea. They may not like being told they are wrong. They may not like extra steps to make their data useful to others. Well, so be it, IMHO. I would rather see committed users buying into this idea (figuratively) for an extended period of time than to be attractive to every person that ever compiled a collection of Ancestral Files into a family tree. A person that doesn't have the patience to learn what to do is probably not one of those committed users. --Jrich 16:10, 16 July 2009 (EDT)


jrich, the example Howard raised is not about people dumping kaka gedcoms here. It's about serious researchers who have invested quite a bit of time etc into their work, who want to see it live on, and-- in the case of Howard's example-- are about to die. Such contributions should be actively welcomed here. We want quality, not quantity, but if we only get quality without ongoing participation, I say "so be it!" jillaine 16:20, 16 July 2009 (EDT)

When you can guarantee that only quality comes in, then I'm with you. But until then, it's about both situations, and there are far more "kaka gedcoms" than "quality data". And we don't actually know which camp the lady in question is in. That said, one of my frustrations when I find a good post on, say genforum, is how seldom I can actually contact the person to ask questions and compare notes, so it would be nice if people would stick around and actually be interested in two-way cooperation rather than just one-way.
I think it is fine to ask for this to be easier, but the process exists for a reason. If you bypass matching, you get duplicates. If you don't convert MySources, you get poor, often useless source citations. If you don't convert places, then you have non-standard, ambiguous place names. How do you propose to make it easier? It used to be easier and I don't think the results were all that impressive, with a gazillion duplicates and such being created, and most of them abandoned.
I think Howard has overstated the difficulty of this process to start with. Anybody that can create a GEDCOM has some computer saavy. They have gotten used to looking at genealogical data on familysearch.org or ancestry.com, if not actually reading authentic documents. They have probably input data into a genealogy package of some sort. No, WeRelate doesn't work like their home system. But then, their home system isn't trying to allow thousands or millions of people to input data into one Pando either. If they aren't committed enough to learn to make the small (in my opinion) adjustment, how committed were they to their research?
Do the tutorials probably need improvement? Sure, but it's only Beta and still changing. Should we make it difficult on purpose? Of course not. Should we make it easier? A qualified yes: only if it doesn't mean sacrificing quality. GEDCOMs are not the factor that means success for WeRelate. There will come a time, and not far off, when most GEDCOMs will simply be duplicates anyway, except for maybe one or two recent generations. People will come to WeRelate, like they go to wikipedia or the Great Migration Begins, when they feel they will find answers they can count on. You have to figure out how to open the screen door to let the dog in without getting a million bugs at the same time. --Jrich 18:18, 16 July 2009 (EDT)
If anything, Howard understated the problems. Perhaps you don't see the problems because you, and experienced person on WeRelate, know how to work around them. The novice user can not contribute beyond a GedCom upload simply because the mechanics of data entry are much too difficult at the moment. Understand that its all well and good to say "if they can't hack it here, go somewhere else.". The problem is, they will go somewhere else. And that means this site will remain utilized by the very few. And that means this site will not survive, at least as a free site. The data entry problems must be fixed for WeRelate to thrive. If it doesn't thrive, it won't be here. Q 18:51, 16 July 2009 (EDT)



Thanks for the comments.

Being an older IT person (not very versed in building web applications) I have a bit of a grasp of the stages of IT maturity. Many people do 'start-ups' and this stage many contributors to unearth all the possible solutions to an issue or market segment. as time goes on, one or two approaches, or products, become dominant. Once the other competitors stop operating, the dominant players aquire the best parts of those. This could be through market failure or aquisition. It is suggested that because of the GEDCOM upload, WeRalate is already well in front of most Gen WIKIS, even if this puts the quality issue as a risk. Lets say WeRelate continues this. There would become a point where a geneologist could come here and stand a very good chance of finding relevant information. There would be enough people, places and events pages to make this the case. Hopefully they are of good quality and seen as having authority (like wikipedia)It will beseen as the best place for such information, ie a good combination of quantity and quality. Once this occurs I believe the usability as a repository for newcers will be less significant. Most people will just be 'watchers'or one time viewers, or make minor additions if they have extra information. This position of 'authority' will make it more attractive for people wh want to post lots of information, much as with Wikipedia. They will make themselves learn WIKI in order for their information to get as wide an audience as possible. We would also need other countries data to be as well represented as that of north america. Ancestry is US based but it does have other 'portals' for UK and Aus for example. Once WeRelate gains this critical mass, the issues become like that of Wikipedia, maintenence and control. The question is how to get there. I joined WeRelate because it has 90% of the functionality I would have in a website were I to have the time to construct my own. In HolmeValleyHome have in my tree of most of the census information for one parish in england, resolved to people. I am trying to encourage people to come to my 'project and add information not construct the genealogical 'web'. So far I have not been able to get anyone to contribute (similar to others experience) but one person has allowed me to take their photos from ancestry and put them on. It took me hours and hours, even using ancestry tools to create the gedcom. a village of 400 people ends up with 4000 people (6000 sources)when you include everyone who lived there 1841-1911, their descendants and close relatives of those who moved there. It did strike me that 80% of that effort - 'ancestry' mining could be done by a 'bot' with a human coming in and resolving the discrepancies. whether Ancestry would approve of such wholesale mining Im not sure (probably not) but they do actually provide the tools to do it FTM9 can do it so the APIs must be there. To sum up- I believe 'Projects' is the way for WeRelate to gain critical mass.--Dsrodgers34 18:00, 16 July 2009 (EDT)


I hate to hear stories about people who choose not to upload their data because of technology/effort entry barriers. Somebody out there has exactly the information I've been waiting for 35 years to find. And I don't really care if they are a fellow techie. I'll gladly hold their hand and walk them through the process. I've been thinking about the "new abandoned gedcoms". Those that were uploaded in the past few weeks that may get deleted because the uploaded has not returned to process it through the gedcom review. I wonder if maybe we could have volunteers review those to see if any are worth processing before they are discarded. I certainly would volunteer some time to help get that lady's gedcom imported so her work is preserved in a way that it can be built on and expanded. We spend a lot of time talking about quality and sources, but we do also need the linkages. If we get casual visitors browsing as a result of a magazine article, I hope they find something. Otherwise, they'll tell their friends "I tried WeRelate but there's nothing there". So we do need to put some emphasis on quantity as well as quality. A web site thrives on traffic. I think we need to work on getting the word out that a gedcom uploaded here becomes part of a growing entitity and is integrated into a larger whole. It's not just a tomb where the data is dumped to molder and never see the light of day. I think that concept would have a lot of appeal if we could just get it across. It might make the extra work see worthwhile. I am amazed at how popular Find-a-Grave has become. There are obviously a lot of people out there willing to post things on the chance it would help someone else. And they are putting in a fair amount of work. We need to channel some of that enthusiasm.--Judy (jlanoux) 18:46, 16 July 2009 (EDT)

Personally, I also see great value in even the crudest of lineages. If there are data sets being added, that turn into free electrons because the user did not return to finish the process, then that right there points to a serious problem. Personally, I'd favor a "no delete" rule on Gedcom's, but there are probably counter-incentives to preventing that---ie, people not trying the system out because they can't be assured that if they don't like it, they can take their data back. In anycase, if there's a way to keep some of this stuff from being converted into free electrons, by all means lets find a way to keep the stuff. Is there a list of such Gedcom's ready for the fire for want of attention? Q 20:03, 16 July 2009 (EDT)
Since Solveig is on vacation, I don't think any are being deleted this week. Perhaps we could petition for a "pound" where stray gedcoms can be held pending adoption. After an extended period if no one wanted to save them, they could be deleted. I admit that there are some I am working on merging duplicates with that I wish had never been uploaded. The new review process would have helped.--Judy (jlanoux) 21:17, 16 July 2009 (EDT)

I guess one way to keep so called "Junk Genealogy" in case someone at some point in the future is prepared to remediate it, would be to revisit the quality accreditation thing again. If the unrenovated stuff is allowed to stay, but the cared for or well documented stuff has some obvious quality rating (which shows up in searches as well as on the page itself).

The first problem I see with t hat is the sheer work involved in accrediting work individually. Might it be possible to accredit pages within certain 'trees' if they are generally of good quality ? This would be a quicker way to establish a quality accreditation system.

If every document has some field or template which can show the level of quality, either awarder individually to a document or to a tree as a while, and this is prominently displayed on the document, or when searching or merging, would that work.

I suggest a WeRelater might upload a tree, work on it to get it up to scratch, then submit it for peer review. If that determines the tree as a whole is of sound quality, Then every document within should display something along the lines "Accredited to be from a contributor who maintains high standards" even though some of the pages might not be that good quality wise. I suppose that means additions need to have high standards applied, and problem pages addressed asap. If the person wishes to add significant amounts of data (in my case adding a parish) then this should be in a separate tree and accreditation not requested until the trees contents are brought up to scratch.

In thios way the less accredited stuff could remain, but not be given the tick of approval

PS if I were to approach renovating a gedcom left by someone - It would probably be quicker to download the gedcom, run it agains Ancestry and add census sources using hints etc, using search/replace to eliminate duplicates etc, then reload onto WeRelate--Dsrodgers34 23:32, 16 July 2009 (EDT)

I'm opposed to any scheme that involves rating other people's work. There's no quicker way to make people feel unwelcome. From reading the comments here over the past few months, I'd say that we don't even have a common language, much less a common idea of quality. And quality is a very slippery concept. The same source can be excellent quality to document one fact and yet very poor for another fact. It's very hard to computerize. Once has to use one's experience to judge each case.
For most people our research and thus the tree tends to spread in all directions. While you may have good documentation on the core (or trunk) people there will always be those on the fringe that are thinly documented. This is where we work. After about 35 years, I have a lot of fringe. In fact, fractal theory tells me I have a lot more fringe than core. (It was rather a shock to learn this) One of the strengths of this site is the power of collaboration. The tale told by someone's great-aunt Martha may have the key to a major breakthrough. It would be sad if someone felt that Aunt Martha's story wasn't good enough to upload. --Judy (jlanoux) 02:45, 17 July 2009 (EDT)


Ultimately, sources are the key for evaluating quality. Use of primary/original sources means (typically) good quality, use of secondary sources means OK quality, use of tertiary sources (GedCom's) probably means bad quality. I'm not sure if "No sources" is better or worse than citing GedCom's as a source. I suppose there are other factors involved as well. Ignoring sources, if the data shows frequent inconsistencies (Person born 1639, died 1968, ---actual example, and this was NOT simply a typo) then its probably not good quality. But usually good sourcing will eliminate such inconsistencies. (if you've got a good source for each of two bits of data that are inconsistent with each other, then you probably have a confusion of one sort or another, and recognizing that will lead to correction. Having NO sources for either data element just leaves you wondering which is right. having a good source for one inconsistent data element, and not the other, probably means the "other" should be jettisoned.) As far as being welcoming is concerned, usually a position neutral tone avoids offense. One of the things that is NOT welcoming, is the use of "hot button words". Calling something "crap" or "horse-snot", does not usually encourage a quality exchange of information. It's certainly not welcoming. Possibly emotionally satisfying, but not welcoming. Q 07:30, 17 July 2009 (EDT)


I'm joining this conversation a bit late, so please excuse the jumbled nature of my comments.

First, I agree with the user who is opposed to quality ratings. I don't even use them for the source citations in my desktop genealogy program. Quality ratings of sources and GEDCOMs are subjective and, IMHO, pointless. They serve only to give either a possibly false sense of security or a possibly false sense of exclusion. Something might not be the best source (or the best cited GEDCOM), but I would much rather see someone's work and have it give me a clue than to not see that person's work.

Which brings me to my second point: Abandoned GEDCOMs and non-documented GEDCOMS are not the enemy. What is wrong with a GEDCOM (even a non-documented one) being uploaded and then never touched again by the person who uploaded it? In a wiki environment, anyone can modify and improve it. That's the point of a wiki. There have been times when I've done a search on a county where a lot of my ancestors are from and have come across familiar names -- not my ancestors, but people in the same townships. I've added some marriage and burial information from books I have. In some cases, the user who uploaded the GEDCOM never created a user page (a sign to me that he or she is not an "active" WR user). But does that mean that his information wasn't useful or that my modification of those pages was pointless? I maintain that each of us -- by his initial upload and my modification -- contributed positively to WR.

While abandoned and non-sourced GEDCOMs are not the enemy, GEDCOMs that are never uploaded to WR are. Genealogists like to find their ancestors. That statement probably seems pedestrian, it has major implications in online endeavors. People don't regularly revisit sites where they don't find their ancestors. For WeRelate to become a true "you have to go there" site, it must reach a critical mass of data. Otherwise, people visit, not find anything, and write it off. (And, as someone else mentioned, they'll tell their friends that there isn't anything here.) That is one reason why I started the 1st Ohio Heavy Artillery project. Not only did I want a place to share what I have and collaborate with others, I wanted to contribute to building the critical mass.

WeRelate is all about collaboration. However, it is hard to collaborate when there is no starting point. An uploaded GEDCOM -- even one that is "abandoned" by its original uploader or doesn't have great citations -- provides a starting point. --Ajcrow 07:41, 17 July 2009 (EDT)

I'll agree with that. I personally have no need to "rate" the quality of others work. But if its going to be done then you need criteria, and source type is an objective way to set criteria. Objective approaches are usually position neutral, and should not give offense. I think some of the banners that have been recently implemented flagging specific articles for attention are useful, as long as a) they are not overly intrusive, b) they adopt position neutral language. ie, "Please help WeRelate improve this article by adding additional sources." As opposed to the pithy "This article stinks". Q 08:12, 17 July 2009 (EDT)


I know this topic has transformed into at least a couple multi-dimensional subjects (as many Watercooler topics do here), but the subject of "Project Work" within WeRelate has compelled me add my project to the mix. After reviewing the comments, suggestions, criticisms and examples of existing projects above, I took the plunge and decided to more formally organize my work on Cherokee Indians. With the hopes of garnering interest in the subject and in attracting additional readers and contributors to the project, I've created the Cherokee Heritage Project, designed to record, collect, preserve and share the origins, history, politics, social and spiritual life, culture, art, achivements, and genealogy of peoples of Cherokee ancestry. Although still in the formative stage (i.e. under construction), I hope the project will soon be considered a community-owned resource rather than just my pet project.

Regarding banners, as stated by a couple writers above, I can understand the subtle intimidation factor with banner pages, especially to novice WeRelate users (as I was a couple months ago). So, to help alleviate some of that perception and to avoid the "take-over factor" by brandishing a banner atop all new or existing related pages, I will only include the large banner at the top of the Project Page and on the associated Category Page. All other related pages (such as for people, families, sources, etc) will only show the Project Badge (below) at the bottom of the page for reference and linkage purposes.

Comments are invited, here or at the project page itself. --BobC 16:18, 27 July 2009 (EDT)

{{Template:Cherokee Heritage Project Badge}}



Repository page titles [28 July 2009]

What is the preferred format for repository title pages? I have searched all over WeRelate and have not been able to find this information. I find that the Alabama Archives is titled Repository:United States, Alabama. Alabama Department of Archives and History and the Texas Archives is titled Repository:Texas State Library and Archives Commission. I know that I created the Texas one and most likely created the Alabama one as well, but they are not consistent. Some of the repository pages evolved from source pages.

What is the preferred method? --Beth 21:01, 13 July 2009 (EDT)

I think you answered your own question. :) The repository issue obviously hasn't shaken itself out yet. I believe a lot of folks here don't regard it as a pressing issue, compared to citation of actual sources. I mean, I don't think it really matters whether I read the census at the library in Dallas 20 years ago, or at the library in Baton Rouge 10 years ago, or online at Ancestry yesterday. One-of-a-kind sources are different, obviously, but even that's changing. A lot of state libraries and archives -- plus federal agencies, of course -- are putting their most consulted document collections online these days. Do you consider the online collection to be identical to the physical building? Personally, I would have no problem structuring state agencies (or federal agencies) on the same top-down geographical pattern that we seem to have agreed on for direct government publications, but I'm not sure there's actually a consensus on that yet. As they say at Wikipedia: "Be bold!" At least the question of cemeteries as repositories seems to have been settled to everyone's satisfaction, so there's some progress. --Mike (mksmith) 10:32, 14 July 2009 (EDT)
Mike, I will just leave the titles as they are until this issue is resolved. I am working on my to do list; User:Beth/To Do List. I decided to make one general to do list that pertains to all of my trees and will contains links to the repositories and person or family pages. Page is presently under construction as are most of my pages. --Beth 11:17, 14 July 2009 (EDT)
I have been creating some repositories as I go. I have a strong preference for using the name by which the Repository calls itself. Why would we presume to change it? The best use for them is to note where rare or limited availability items can be found. While everyone uses the "microfilm of the census" example, there are family genealogies, local typescripts, etc. that are not of general availability. It is a service to other researchers to note a repository where such a material is available. Like so many of our little projects, this is a long term effort. If everyone cooperates and leaves a few breadcrumbs, future researchers will have an easier time finding these items. It also helps to note repositories that have useful collections. --Judy (jlanoux) 21:11, 16 July 2009 (EDT)

I agree: a repository is a repository, not just another place, so I see no reason to follow the place-name convention. The actual repository name should be used. While visiting Chicago on a trip this past week I visited the main library there, and in annotating and updating some of the resources I found there I discovered the library itself was not listed as a repository on WR, so I added it as Harold Washington Library Center (Chicago), not as United States, Illinois, Cook, Chicago, Harold Washington Library.--BobC 12:20, 21 July 2009 (EDT)

Repository is a relatively new namespace and has almost no conventions or help associated with it. I second Mike's suggestion to be bold and propose some conventions on say Help:Repository pages and add this page to the help contents page.--Dallan 13:34, 28 July 2009 (EDT)


Vandalism from Wikipedia [28 July 2009]

This article, Horseheads, Chemung, New York, contains vandalism that was pulled via template from the corresponding Wikipedia article. The Wikipedia article has already been corrected. Will the article here at WeRelate eventually correct itself or does something need to be done manually to force a refresh of the page? --dayna 12:01, 17 July 2009 (EDT)


All WP templates are refreshed at some interval based, I think, on a complete extract that Dallan gets from time to time (maybe once or twice a year). Refreshing again from that snap shot won't help though - since the snap shot is what contains a copy of the damage.
This is a pretty rare event. If this occurs and you aren't willing to just wait the six or so months for a refresh, you can go to the WP template and edit it yourself (as I just did). --Jrm03063 13:39, 17 July 2009 (EDT)

Thanks. --dayna 11:43, 19 July 2009 (EDT)

Coincidentally, I started running another refresh from Wikipedia today. I run it 2-3 times a year, more often if people request it :-).--Dallan 13:42, 28 July 2009 (EDT)


Fraudulent Lineages and WeRelate [19 July 2009]

One of the well-known creators of fraudulent lineages was Gustav Anjou. (Citing 1)[8], 2) Genealogical Journal, Volume 19, Numbers 1 & 2, 1991, "We Wuz Robbed! The modus operandi of Gustave Anjou," by Robert Charles Anderson, CG, FASG, 3) Genealogical Journal, Volume 19, Numbers 1 & 2, 1991, "Gustave, We Hardly Knew Ye," by Gordon L. Remington.

On WeRelate, Gustav Anjou was automatically cited as an author for several sources through the Family History Library through a bot capture of the FHL Catalog. It is my understanding that the FHL films designating Gustave Anjou as the author are no longer available for rental. One may only view them in Salt Lake City, Utah.

What should WeRelate do regarding these sources?

There were other fraudulent lineages created by other researchers, but I am hesitant to mention them without the sources for the allegation. I suggest one read the recently archived messages entitled Genealogy Frauds as Case Studies on the APG mailing list on Rootsweb to check to see if you may have relied on one of these researchers for your lineage. --Beth 19:17, 18 July 2009 (EDT)


This is an area where werelate should be able to shine. Since we can indicate any number of things about a source, we can certainly indicate whether a source is known to contain fraud.
Presumably, any fradulent lineage that gains traction must start out with enough correct lineage to get things going. I should think that there would be a person or persons, where the facts represented by such a lineage transition from reality to fiction. On those pages, the fradulent source should DEFINITELY be noted as a source, and then figure prominently in a section entitled, "Fradulent Genealogy" (or some such).
Likewise, fraudulent lineages can work their way back the other way - from historical notables to ordinary folks. The sons of Person:Peter Browne (1) may be such - so our page on Peter should probably contain explicit notes on known examples of that.
I'm not so sure about literally fraudulent people. Perhaps in those cases it might be better to create an article page, describing the fraud, noting the elements of the fraud - along with the elements of truth that were rolled into the fraud.
--Jrm03063 19:58, 18 July 2009 (EDT)

Note that there is at least one Gustav Anjou source that appears on WeRelate: Source:Parson family records. Anjou is one of the reasons (more a cautionary tale) why intermediate sources actually used, should be cited, (as opposed to the original sources they cite). If Anjou is the source of information, then there's a good possibility that the source he's pointed to does not contain the information stated. A collection of "Anjou" crafted documents would be of some use. They might be entered as sources but "flagged" to indicate his history, and the possiblity of being fraudulent. perhap's a nice "skull and crossbones" icon? Q 20:41, 18 July 2009 (EDT)


This strikes me as one of the primary uses of having editable source pages. By all means, keep them and explain on the pages as much as possible as is known about what isn't trustworthy. No flags or icons necessary.--Amelia 20:46, 18 July 2009 (EDT)


I think it's important to differentiate between "fradulent" and "incorrect" lineages. There are several publications that have published incorrect lineages that have been cited and propagated mistakes in many families. Perhaps we need to come up a "disproven source" icon? This would be able to be used for both fradulent and incorrect lineages. Agree though that Anjou deserves "special status" for his obviously error-ridden work. Delijim 19 July 2009-

Yes, two different species. I suppose the would work well enough for things of this sort. I usually apply it on issues where there are differences of opinion, and alternative views, but I occassionally use it to highlight something that is fundamentally disproven, but has not yet reached wide acceptance. Perhaps an overly fine distinction. As most know by now, I like using non-verbal cues, such as icons, to convey a message. The majority of people respond better to something like that than to extended explanations. You still need the explanation, but the icon often conveys the message faster. Not all view it this way, but by and large we remain a visually oriented species. That's one why roadside markers favor the use of incons rather than text. And of course, they also transcend language barriers. Q 12:17, 19 July 2009 (EDT)


I don't actually think we do need to distinguish, at a policy level, between bad/incorrect and bad/fraudulent sources, or to decide on some standard for a "completely" unworthy source. This is an area of a lot of nuance and gradations, and thus I think it's best left to the text on any given page to describe the problem. Anjou has special status in the sense that the very fact that he is the author of a book is enough to merit the assumption that it contains fraud, but he's really just notable because he committed fraud on purpose repeatedly. But since (as I understand it) he started with correct lines and ended with correct lines, and connected them in the middle with something invented, his works themselves are not that much worse than hundreds of other works that misstate the immigrant connection to the mother country. They should all be evaluated on their own merits. For those doubted just because of Anjou's authorship, we should link to a substantive discussion of what he did.--Amelia 12:02, 19 July 2009 (EDT)

Except in this case, it's not just a "possibility" of fraud. It's the "poison fruit of the poison tree." Joining two "correct" lines with a paste-up of false, invented data creates a new, fraudulent lineage. Deliberate fraud, perpetrated with the motive of criminal financial gain -- which is exactly what anjou spent his entire career doing -- is not at all the same as mistaken interpretations of data or misstatements -- as a couple of hours of merging some truly ludicrous duplicates makes very clear. Perhaps unfortunately, anything Anjou ever touched is completely and permanently suspect and therefore unusable. If you cite him for any data you present yourself -- even if you think you've managed to sort out the true from the false in some instance -- it will result in your own work being labeled untrustworthy. Better to just stay the hell away from his "work" entirely. Gustav Anjou is anathema. --Mike (mksmith) 12:42, 19 July 2009 (EDT)

Research question - land records [21 July 2009]

This question was left today on my small Jackson yahoo group and I don't have an answer. I thought maybe someone here might give some advice or pointers.

"The migration from England to New England was so different from the migration to the Chesapeake that it is hard to imagine that the two Jackson lines that we are researching could be related to each other. Each migration was from a different area of England, different social economic groups, and different religious groups. How do we fit in?

Since the Hempstead (Queens, NY) related Jacksons in Virginia had land they were not indenture servants and it appears that the only records that we have to provide source information for our research on these Jacksons is going to be deeds, patents, and grants or other land records. I have searched for deed mapping research to see if anything has been done on the Northern Neck Counties but have found nothing that would help us. Is there anyone in this (yahoo) group that has any experience or knowledge of how to go about this type of research?"

Any advice will be appreciated! This is clear out of my field (and not the usual topic for the watercooler). DNA has proved these Northern Neck Virginians are somehow related to the Queens Co., NY Jacksons. I would love to make our research a project on WeRelate but none of the others are familiar with wiki and I haven't been able to convince them to learn. I've uploaded one of the Samuel Jacksons that we've been working on here: Person:Samuel Jackson (49) of Prince William Co, Virginia. We've found 4 other Samuel Jacksons in the same area during the same time period and it's become an interesting challenge. --Janiejac 23:16, 20 July 2009 (EDT)


Have you looked at the catalog for the family history library? Place Search put in the county, part of Virginia and check the land records category. Click on film notes. Usually there is a film containing an alphabetical index for the county, maybe one for grantors and one for grantees even. So usually you order this film first, and find all entries for the person you are interested in. This will help you decide which film(s) you need to order to get the recorded version of the actual deeds. (Some counties may have hundred of films to hold all the deeds.) The charge is about $5.95 per film, and each order takes 2-3 weeks to get there but could take longer. The film is yours to use about 1 month, but it cannot leave the local family history library. A thorough search can take a while between waiting for films, finding time in your schedule when the local FHL is open, and deciphering hard to read copies.

The list of resources for the county shown in the catalog may also have probate records as well, and church records, and other resources that may come in handy. Of course, you need to go by the county that the area was part of at the time in question, or you may need to search through multiple counties.

Is that the type of help you were looking for?

--Jrich 01:18, 21 July 2009 (EDT)


Janie, this sounds like a great question for either the APG or Transitional Genealogy listserv. (Beth, which one do you think would be better for her?) jillaine 08:30, 21 July 2009 (EDT)


The counties considered in the Northern Neck of Virginia are Lancaster, Northumberland, Richmond, Westmoreland, and some people include Prince George County; so are these the counties of interest or are you actually interested in Prince William County? There are several people working on Prince William land records and I believe there is at least one listed for Richmond and Westmoreland. See this list. [9] You should also review the Deed Data Pool. You may view the data files with your word processor and view the details of the deeds but you need Deedmapper to view the actual plats. Link to pool [10] Does this answer your question, Janie? --Beth 09:44, 21 July 2009 (EDT)


Thank you, Thank you to all who have responded with ideas and links! Yes, this is the kind of help I needed! I'm sharing what you have given with my research buddies and hopefully, between us we can come up with the info we need. These links are all new to me so I'm eager to check them out! --Janiejac 13:58, 21 July 2009 (EDT)


Category for the Confederate States of America [28 July 2009]

I need some help on how to organize this category. I want to add a category to recognize people who served in the military for the CSA.

I looked at Wikipedia for guidelines and Wikipedia seems to have a separate category for the Confederate States of America; I assume because they were not part of the United States. So I created the category on WeRelate Category:Confederate States of America. However the subcategories on Wikipedia for the CSA military seem to be all over the map and I don't wish to recreate that here.

Need suggestions on the subcategories; we already have some CSA related categories under the states; I believe that I can create a subcategory that links back to more than one parent category, but anyway help and advice please.

As an example I have 2 people who served in Company K, Seventeenth Alabama Infantry. How do I categorize Company K, which was created in Butler County, Alabama, also known as the Butler True Blues.--Beth 23:32, 20 July 2009 (EDT)


Oh my, I wouldn't encourage categories based on regimental affiliations. That would lead to thousands of categories.
I think the way this really wants to be done is via facts, where the military service is described by unit. For army service, I would think this best done by attaching a WP link to the appropriate regimental history. For examples: Person:Omri Eastman (2) and Person:Uriah Leach (2). If it was your intention to compose a roster, I would think you would want to do that directly with an article noting all the members of the unit. --Jrm03063 01:03, 21 July 2009 (EDT)
First, believe it or not everything is not on Wikipedia. <g> There is no link for this regiment other than a red one; there are a few CSA links but the majority of them are red. Wikipedia has numerous subcategories, but I believe that creating one subcategory named Military of the Confederate States of America should do it. Then I can just use the pipe symbol to further subdivide the category.

Yes, I do have the muster roll for Company K, but don't plan to take the time to create an article this week. --Beth 10:13, 21 July 2009 (EDT)


I've started a project on the 1st Ohio Heavy Artillery and debated the use of categories. Other than having a way to automatically generate the roster of the various companies, what purpose does a category serve? The page for 1st Ohio Heavy Artillery, Company A was created by copying and pasting the roster. I'm going back and adding the links to the specific Person pages. I realize that a category could automatically generate the list, but since I have to go back and edit each of the Person pages anyhow (add the project's template, etc), it doesn't seem like adding a category link would really save me anything. Just curious if I'm on or off in my thinking. --Ajcrow 10:59, 21 July 2009 (EDT)


You have a great project. I guess my vision of categories is somewhat different. Let's say for example that a researcher decides to create a project on Company K. They could check out the category on WeRelate and easily find members of the Company with bios already available. I believe if WeRelate continues to evolve that historians and sociologists and other researchers could find a number of our categories beneficial. --Beth 12:17, 21 July 2009 (EDT)
I don't know that our "projects" are so different. I'm just starting out with more data. Still trying to decide if I should be using categories, beyond adding 1st Ohio Heavy Artillery and its associated roster pages to the Category:Military units. Decisions, decisions... --Ajcrow (Amy) 12:29, 21 July 2009 (EDT)
I use categories for three purposes: 1) the group is fairly small, and seeing who else is in it might be interesting (Category:Mayflower Passengers); 2) as a label (i.e. Category:1630s Immigrants); or 3) what's really both 1 and 2, but will have a later purpose as well, as part of the notable people hierarchy that will call out notable descendants (i.e. Category:U.S. Presidents). I also use templates liberally to help with navigation between people in a category, which I suppose technically eliminates the need for the category, but it's still a handy catchall, particularly before I get around to building a template. I also generally follow Wikipedia style where I can -- use categories liberally, and put the related templates (which all follow a similar style) at the bottom of the page, since there might be several that apply to any given person.--Amelia 11:10, 21 July 2009 (EDT)
And now I'm wondering about categories as well. Today I started an Article listing people entered into WeRelate who are United States Patent Holders. The first idea I had was to do this via categories, but I wasn't able to determine if categories are used as liberally here as they are on Wikipedia. So this morning I started the list as a user page; I quickly realized that it would be helpful if others could add to the list as well. I moved it to Article space, hoping that was an acceptable place for it.
Should I go back and use categories? Or is the idea of a list of people who had the initiative to patent their ideas/inventions only interesting to me (which I don't doubt at all!)? --dayna 12:01, 21 July 2009 (EDT)
Use both. The category labels the person, and allows one to navigate from the person to the list (on the category page - which can have your fully formatted list either on it or linked to it as well) and back again. It also lets you add things like sources or images to the category. And, it's a visual cue to other users that these types of categories exist, which prompts them to explore them. I've done several categories this way (Mayflower, Windsor Founders, most of the Great Migration ships) because it's useful to have the full list of people somewhere to account for the people who don't have WR pages yet. In your case, it doesn't look like you want to include a list of the entire universe of patent holders, but you do want to include the invention, which is a reason for keeping the formatted article page. And I think this is a great idea - it's not just interesting to you!--Amelia 12:08, 21 July 2009 (EDT)

Are you suggesting that categories could be used as a sort of bottom-up way to get unit rosters? That's sort of cool. As I think about this, there has to be a smart way to take advantage of the WP taxonomy of unit histories to sanely organize WR-based individual genealogy. For example, if we're careful to create a unit roster page with a name that follows the WP unit organization naming conventions, we can legitimately and systematically hook it in as an external link for the WP page on the unit. Maybe another element of WR corresponding page is to have a standard form that contains roster-specific information (scans perhaps?) as well as a link that takes you to the corresponding unit category. Of course, the WR page would standardly have a back-link to the corresponding WP article.
It's not so much that I'm a WP zealot, as I am a wiki-zealot, and I want to see both WP and WR each used to their best advantage. I started the WP article stub on your unit, and will flesh it out a little more this evening. --Jrm03063 11:15, 21 July 2009 (EDT)
Thank you for starting the page; but I was not planning to start a project on any regiment or Company. Your article has 17th in the title and 18th in the body. I simply want a method to show all of the people on WeRelate who served in the CSA and I still believe the category system is the best method.
I fixed those "18"s. I'm not looking for another project either. I'm also not against categories, though I had my doubts. Maybe categories can be a way to allow ancestors to just automatically accumulate into a roster for a particular unit. If the categories and/or sub-categories line up with the unit history taxonomy on WP, then maybe there's a very handy and mechanical way to associate WR ancestry with WP unit histories. --Jrm03063 14:11, 21 July 2009 (EDT)

Is there a valid reason to limit the number of categories? --Beth 12:17, 21 July 2009 (EDT)

Not really. Probably. But categories at WP, for instance, have a tendency to get out of hand -- occasionally, way out of hand. I don't think I would consider creating a category unless I had already identified a problem or a need, and then found that a category was the best way to solve the problem or fill the need. Creating a category should be a means to a definable end, not something you do just because you can. --Mike (mksmith) 22:19, 21 July 2009 (EDT)

How you handle something like this depends a bit on the reason you want to create categories. Presumably, its a finding aid for individuals. IE, you want to create a list of everyone who served in XYZ unit. Then you could use that list as a look up register for people who both served in the unit, and have articles on WeRelate.

The category process works by placing the page title in a list. The list is in alphabetical order. Which would be handy if the page titles were set up "last name, first name", but they are not. So what you get is a list ordered by first name. Andrew Able, followed by Andrew Deavers, followed by Andrew Zybigsky, etc. Actaully, its worse than that, as since every person page is proceeded by "Person"", you end up with a list of pages all grouped under "P". Here's an example of where I tried something early on, and found it wasn't especially useful. Category:Early_Settlers_of_Southwest_Virginia. (I used a template to add the category page automatically along with other information to the page. When I realized it wasn't going to work, I changed to a new template, without the category. The list still persists because the new template had a new title.)

If you don't have many people in the list, then you're okay because its easy to scan the list and find the right person. If you have a few hundred, or a few thousand people, its more of a problem. Perhaps there's a way to invert the name order. Seems like that's a common enough problem that there would be a way to do that. Haven't looked. If not, how useful is a list of people ordered by first names? or by Namespace? I still use categories on occassion for limited short term purposes. Q 07:55, 22 July 2009 (EDT)

You can alphabetize by last name by using |. (It won't display that way, but it will sort alphabetically.) That's what we've done in the Cemeteries category. To get the cemeteries to sort by name and not have them all appear under "P - Place:...", we add the cemetery name after the |. So [[Category:Cemeteries of Columbiana, Ohio, United States|Hope]] allows Hope Cemetery to be listed under H instead of P. I haven't tried it with a Person namespace, but I would think it would behave the same way. I just wish there were a way to get something else to display on the category page (eg, "Hope Cemetery," instead of "Place:Hope Cemetery." -- Ajcrow (Amy)

08:21, 22 July 2009 (EDT)

That's good to know. I would have thought the pipe would have jettisoned the name space, but perhaps that's a manual addition, rather than simply inserting the pipe and letting the system do it. Guess it would have to be manual to just get "Hope" to show, and not the full page title. But if so then you have to manually change every category entry to get this to work.
Some of the other Gen Wiki's utilize categories more heavily than here. That's probably because their search engines are not so elaborate as what's available on WeRelate.

OK, I going to jump in here, playing devil's advocate a little. I am not trying to complain about anything that has been done or discussed, but using current examples, and carrying them to extremes, I think there is some danger here, Mr. Robinson. Dallan has said, "If we were to allow everyone to add categories during GEDCOM upload, we could end up with some pages having a lot of categories, so I'm reluctant to do this."

So I believe there needs to be some guidelines on the use of categories. Probably Dallan needs to provide lots of guidance in terms of the load they place on the system and performance, etc., or whatever his other concerns might be. People need to provide input on what they want to do with categories, but keeping in mind whatever they are allowed to do, potentially so will millions of other worldwide contributors be someday.

So to start the discussion, here are some questions:

What is a necessary requirement to create a category? Keeping in mind that this is community data, that person pages are shared, is it better to mark a person with a category, or to simply note the membership in some group as part of the text in the narrative? If you want some way to find all the pertinent people, would it be better to simply write an article and list the pertinent people in the article, but do nothing on the person page? ("What links here" would show that the article references them, if people were trained to look there, and expected to find there, what groups a person belonged to.) Or, more visibly, but possibly worse than a listing of categories at the bottom of the page, a link to the article could be included in the narrative.

What criteria can be developed so there aren't categories like "Founders of now defunct town", "Ancestor of Michael Jackson", or "Past Presidents of the Model Train Club"? At what count do the number of categories become an impediment and distraction and who is to judge that one person's category is more important than another's?

Do project banners stamp pages with too much ownership, branding them if you will, so others may be afraid to contribute because they think there is a different protocol than for regular pages? Which project banner gets the coveted top spot when there are more than one? (How many banners can fit on one page, should they go at the bottom, should there be a size limit, do they slow page loading if there are multiple banners?) Why is a category, or whatever is decided above, not sufficient for marking pages in a project? --Jrich 11:49, 22 July 2009 (EDT)


Jrich, I guess I'll jump in on your last paragraph and respond on behalf of myself, Quolla and a few of us that have spent much time on "branding projects" (your words), such as Q's Southwest Virginia Project and my Early Settlers of Augusta County, Virginia Project. These projects add much additional information to those ancestors that otherwise probably wouldn't have been added without the many hours (or days and weeks) of additional research necessary to complete these projects. Rather that an "ownership brand", these projects add a wealth of information (in many cases collaboration between several researchers), and serve as a "baseline" to group ancestors together, based on their location (in Q and my Project's case). Since many of the families in these projects intermarried (because of their obvious proximity), this is an obvious plus to those researchers that are seeking information on related families by looking at those included under the project "banners". Although I don't personally feel that I have "branded or claimed ownership" those ancestors, these projects do show that a certain amount of effort has been done in the process, that will benefit future researchers. I believe Dallan has been very appreciative of those involved in these projects that have separated WeRelate from any other genealogical sites to date. If WeRelate brings additional projects that add a wealth of information to this site (and the increase of collaboration, etc.), then (in my opinion), so much the better! --Delijim 22 July 2009

Well said, to which I have only a little to add. Yes, its highly likely that some individuals could be "claimed" under multiple projects. It doesn't much matter which project, if any, uses attaches a particular banner to a particular article. If you are working in the area you are pretty well going to expect that your ancestor was here at a certain time, but previous to that were somewhere else. The point of the banner is that it provides a cohesive way to link many different articles (not just people articles together) and provide common navigation tools to take you to different parts of the project. This makes it easy to recognize that a particular individual was located within a certain area at a certain time. It also serves to focus peoples attention on other elements that may be of interest to them, and not just the family relationships.

IF, ---and this seems to me to be a highly theoretical point that seems to have caused no problem so far---but IF there was a conflict in some way between two projects wishing to identify a particular article with a particular project, then the answer is you shift from a "single banner" to multiple "badges", each badge pointing to a different project, with exactly the same effect---except that now you have two areas that you can associate the person with, and two separate lines of information display and collection that may benefit you. And you aren't even limited to two badges; I believe there's space for a fair number of such "mini banners", each leading you off into another project. There are some examples of such badges on the present page. I don't believe we've started incorporating them into "person articles' but some pages are being linked to multiple project, at least on the main enterance page. 13:54, 22 July 2009 (EDT)

If an ancestor has earned "multiple banners" (as you've suggested), I believe that they should probably be placed in chronological sequence, with the earlier banner at the top. For instance, one of my ancestors, James Kerr is a key "Early Augusta County Settler", and will also most likely be included in Quolla's "Chester County, PA Project". Since his family migrated to Chester County, PA before their migration to Augusta County, I'd suggest that the Chester County banner be listed first......--Delijim 22 July 2009

Makes sense to me. I know some instances where we have "backflushing" which would complicate that approach (Samuel Porter of Temple Hill) for example, but those are really rare cases. For the most part its a one-way street pointing west and south, and a chonological ordering makes the most sense.---if there's a need. Q 14:05, 22 July 2009 (EDT)

By the way, I've started adding in maps derivitive of the Hildeband maps, based on your scanned images. I've included one of those in the Old Augusta Project---specific to identifying the waterways depicted by Hildebrand on his Borden's Grant map. Waterways are overlain as a distinct color against the tract maps. I've removed Hildebrands labeling of individual tracts (mostly for clarity). I need to do some stream labeling. Right now it just shows the North and South (St. Mary's) Rivers as labeled features. labeling the smaller streams is a bit problematic. I'll be adding other maps based on similar approach (e.g., Great Road, principle places, etc), plus something that can be used to highlight specific tracts. Q 14:14, 22 July 2009 (EDT)


I'm not complaining about your projects and I value the work you do. I think genealogy is immensely helped by people who take a wider interest than just their own ancestors. Look how often Savage's Dictionary on pre-1692 colonists gets used. Not that ancestor-focus is bad, either, since the collaborative nature of WeRelate is what can take this limited scope and combine it with others to come up with a broad result executed with focus.

I think WeRelate wants to allow you to pursue your projects. I am just questioning how it needs to be done. Some book I worked with once started the entry on each person with a list of lists the person belonged to. You turned to the appendix and there was each list, about 30 in all if I remember correctly, maybe more: charter member of this church, tax list of 1762 (or whatever year), etc. Each of those lists could be somebody's pet project. As mentioned earlier, each military unit. Important to them. Don't want to discourage them pursuing that. That kind of diversity is good. So I am not attacking the idea of projects, just asking how it is most appropriate to mark the Person and Family pages, if at all.

Is your project meaningful to all researchers of an individual? Is your project meaningful or of interest to the general public? To somebody outside the US? Perhaps we don't care, since they probably won't look at the page.

I have a hard time finding a definition of exactly what is the scope of some of these projects. Is your project defined by some natural boundaries, like pre-Revolutionary, pre-incorporation, or are the criteria arbitrary? What if somebody wants to add somebody to the project you don't think qualifies? Wrong range of years? Outside the area? Who decides? Assuming they don't qualify, does the other researcher have to create a whole new project to get a feeling of inclusion?

Is your project defined by your source? Should every genealogy work get its own project? Savage's Dictionary? Early Settlers of Any County? Founders of such and such a town? Do we need a big banner for each? A gallery for thumbnail banners? A list of categories at the bottom of the page?

What if somebody researching one of your people dislikes the banner on the page because they don't think it is all that pertinent (maybe they only resided there a year or two), or it distracts from other information there? What if they want to make a change that makes the page look different than other pages in the project (add their own pet formatting), perhaps add different sections, or rearrange them to add some extra information?

You want people to know there is more information available to provide a broader scope to their research? Can't a category do that? You want to have a way to tie together pages being worked on by a group? Can't a category do that?

The banner has nothing to do with the person, it has to do with an arbitrary project that somebody is using as a research focus. It goes great on the articles which address the project's main theses. But does it belong on individual Person and Family pages?

Articles always seem a little less of community creations. While I realize anybody can add to them, I would hesitate to do so without checking with the author, especially if the article was in somebody else's user space. But Person and Family pages seem different. They don't belong to anybody. I realize that most of the banners are put there with the best of intentions, and actually improve the overall appearance. Regardless, I also think to the inexperienced user, or in certain situations where disagreements arise, they communicate an ownership that may not have been intended. Or they may encourage a feeling of ownership that is not proper.

So I wonder why simply creating a category isn't good enough? --Jrich 14:35, 22 July 2009 (EDT)

I don't believe I said anything about categories not being a useful tool. I pointed out one of their limitations. Ajcrow pointed out a useful workaround that partially solves the main problem, but requires a fair bit of work to implement. Since this wiki (uniquely) has better functionalities for dealing with the problems categories were designed to solve, I personally found that they were a wrinkle I didn't often need. But if you think that categories would help your research, then by all means make use of them. We'll look forward to seeing what you produce. Q 16:14, 22 July 2009 (EDT)

Jrich expresses a concern I've had for a while. While I'm very impressed with the Virginia work, I'm not a fan of the big banners at the top of the pages. It's not so much that it's those banners, it's the scalability of it all. I realize, however, that I am at least as guilty of spreading a particular style on many pages (which is why I copied WP so much -- I'm trying to stay under the radar). I prefer the bottom of the page information because it's out of the way while being more overt than just a category (which, until we get rid of the automatic surname categories, are often overlooked in the mess). The info templates are also a handy way to replace common information that used to be repeated in the narrative (e.g. "The Mayflower was the first ship to settle in New England..."), something you can't do with a category without requiring the user to click away.

Anyway, at some point, when there's more than just a handful of us doing this, I think we should develop common style templates for these types of projects so that other users just think of them as community add-on's, and not any particular person/group's pet project.--Amelia 00:16, 24 July 2009 (EDT)


As far as Banners on a page, I feel they add to the look of the page, I have worked with Bill and Jim and several others on the Southwest Virginia Project...I have never felt it was a pet project...Bill asked me if he could use some of my work when he started it...and it has been a great help to me, it has not been the work of one but all whose family was from that area...the banner has been place on several of my family pages and I am proud of it...we have corrected many mistake by joining in and working together...this project only covers a time period and a small area...some of my family was a part of that time period and I have learn a lot from the project....the banner fits the work and I see no reason for it ever to be changed..anyone can add to the pages that is what the group is all about....if the information fit the area and the time and has sources to back it up....I am sure it will be welcomed by all who has worked so hard on the project...if it does not fit the time and area then it should be place were it does fit...I feel this project will be of great value to many researchers....and to me it has been a great honor to work with Bill(who I have the up most respect for) and the other on this project...I would like to see more projects on different area done and a distinct banner at the head of each this would tell us when we pull up a page what it is tied to, and it belong at the top of the page in my book....-,-Dlbradley1 19:26, 24 July 2009 (EDT)


Thanks Amelia for bringing this up. Great points. And I'm about to create a new project-- have started really, but it's not very far along yet ("Our Schwenningen Ancestors"). I think it might be appropriate to put the header on the main page of the "project" but perhaps at the bottom of subsequent pages like you do your "Founders of ___, CT" template. I'll watch this conversation with great curiosity. jillaine 16:41, 24 July 2009 (EDT)


With all due respect to everyone's opinions; I believe that we have room on WeRelate for templates, banners, and categories. I am not sure that I wish to have specific rules in respect to categorizing pages. That could possibly preclude a new innovative approach by a new user. I happen to like Q's banner, Jillaine's banner, and Amelia's template. Y'all already know that I am fan of categories. If a user complains specifically about a banner, template, or category; I recommend that we address the specific user's complaint. --Beth 20:18, 24 July 2009 (EDT)


I don't want to come across as discouraging categories. My experience with categories that were created "just because we could" (i.e., the surname categories) is that they're next to worthless. Search results do just as good of a job. But the categories I've seen that people are actively maintaining look terrific. So I'd second what's been said above about creating categories whenever you have people you want to display in a group, just don't create a bunch of mostly-empty categories and expect others to fill them.


Banners, badges, and categories [29 July 2009]

Regarding banners, badges, and categories, what about what BobC said under a different topic on this page:

Regarding banners, as stated by a couple writers above, I can understand the subtle intimidation factor with banner pages, especially to novice WeRelate users (as I was a couple months ago). So, to help alleviate some of that perception and to avoid the "take-over factor" by brandishing a banner atop all new or existing related pages, I will only include the large banner at the top of the Project Page and on the associated Category Page. All other related pages (such as for people, families, sources, etc) will only show the Project Badge (below) at the bottom of the page for reference and linkage purposes.

You can see the results at Cherokee Heritage Project and Person:Attakullakulla Raven (1). I think banners at the top of project and category pages is perfectly appropriate. A reduced-size banner like BobC uses or a navigational template (example) like Amelia.Gerlicher uses might "scale" better in case a person is involved in multiple projects and may help encourage non-project members to contribute.

I'm not suggesting that Q and Delijim and others need to go through and change their existing pages - that would take a lot of time. I bring this up for going-forward purposes.

What do others think?--Dallan 14:24, 28 July 2009 (EDT)


I like (and will follow) the model of the Cherokee project. (And what a cool project!) jillaine 08:33, 29 July 2009 (EDT)


Research Guides vs. Place pages [23 July 2009]

Oh me and my undiagnosed ADD... Gotta tell ya, WeRelate is a haven for such folks (like me)...

Okay, I'm on a couple of listservs that have EXCELLENT resources, and I start thinking about compiling them. Well, why not here? They're genealogy-related.

So I went in search of existing research guides, and finally found them.

I added a few more.

And then I thought I'd organize the Category:Research guides page.

AFTER (!) I organize the geographical research guides (all the blue ones of which existed prior to my current attention), I ask myself:

Now wait a sec! Why wouldn't we place research guidance on the appropriate PLACE page?

Anyone want to explain this to me, please? Thanks!

-- jillaine 13:02, 22 July 2009 (EDT)|Jillaine

I'll agree that it would seem that the best place for a research guide concerning a PLACE, would be either on that places' page or on a page linked to that place. I can easily see where a place specific research guide could easily overwhelm a place page, and could stand on its own quite satisfactorily. On the other hand, if it doesn't contain a great deal of information, then perhaps its best suited for the place page.

Ditto other forms of research guides---e.g., surname guides, event guides (e.g., Revolutionary War era genealogy), etc. Q 14:00, 22 July 2009 (EDT)


There is so much to learn about WeRelate! I, like many others, start using it without knowing much. I didn't know there was a page that listed 'research guides'. But I did put some helpful links I knew about on the West Virginia state place page. I didn't like the section title 'Research tips' so I created a new one called 'Links to West Virginia Genealogy and Historical Web Sites' and put the info in that section. I see now these links could have been put in a 'Research Guide' but my instinct was to put them on the place page. Place:West_Virginia,_United_States

Or maybe there wasn't a page that listed all the research guides together until you started organizing them. I like that! It does make an easy way to find the guides. Why not rename the 'Research tips' section on the Place page to 'Research Guides' and show a link to the Research Guide for that locality. To put all the external links and comments on the place page may make some pages too long, but there surely could be a link in the page (not a category link) to the Research Guide page. I would see the link under the section heading a lot quicker than looking at the bottom of the page for a category. (Somehow Research Guides needs to be more to the forefront so they can be noticed! How did I miss them?) --Janiejac 14:24, 22 July 2009 (EDT)

"Research tips" seems to have been a standard element created by the bot when these pages were created. There's probably a need for a more complex page structure. I personally find most of the Wikipedia information that's imported to be of limited interest for genealogy. I'm sorry, I don't really care about the current structure of the city council.), But some of the information is quite useful (County history etc.) I don't do this systematically, but in counties that I'm working on I often import the Wikipedia County map, puting it somewhere near the top of the page. That's useful to have on the place page, (usually more informative than the GoogleMap in the sidebar, and having the image available allows you to insert same on a person article when you want to show where you're talking about. Using the place page is a natural repository for the map, so you can go back and quickly see whether one has been imported or not, get its proper title, and then place it where a copy is now needed. Very handy. As I come across other information I'll add it here as well (for example a county level bibliography, or links to marriage data for the county, etc. Its a good place to keep information like that because its highly focused, and easily found. The name "Research tips" is a bit clunky, but serves the purpose. I image one day people will get together and decide what the page should really look like, contain, and upgrade these pages. Q 16:30, 22 July 2009 (EDT)

I've been reminded that there was a short discussion about this topic already-- well about research guides. I'm reviving it here. Please participate if it's of interest to you. jillaine 10:13, 23 July 2009 (EDT)


Problem viewing Watch List [28 July 2009]

I am no longer able to view my watch list. When I open it (view entire list) Firefox seems to go catatonic. If I go get a cup of tea it will eventually bring the screen back, but then as soon as I touch a scroll bar or something, the screen goes white again. This worries me because my watch list is about 3800 items and I've only uploaded about a quarter of my people so it could get a lot bigger.
I'm getting suspicious that it may have something to do with the recent Firefox releases as I didn't have this problem before. I just checked and IE works fine. So maybe suspicion is confirmed? Are there any settings that I need to change? I've browsed the FF menus but don't find inspiration. Wishlist: It would be nice if I could filter by namespace. It's tedious having to scroll through all those listings even when it's not broken. --Judy (jlanoux) 21:27, 22 July 2009 (EDT)


Judy, I have Firefox (on a Mac) also, and my watchlist is acting just fine. Also, I have a pull-down menu on my watchlist that enables me to select a namespace filter. jillaine 08:36, 23 July 2009 (EDT)

I have firefox on a pc, my watchlist is of similar length, and sometimes it takes a long time (a minute, up to about 3) to load the watchlist. Once I looked at it the first time, it seemed faster the next time (I go to this screen a lot). And it did just start behaving this way recently (maybe two weeks?). I was afraid I crossed some threshhold... Not this morning, though. --Jrich 09:18, 23 July 2009 (EDT)

Apologies; I misunderstood. You're speaking about when you click on "View all and edit watchlist". I've never used that before. FYI, I just tried it. It did take a little while. But no more than about 20 seconds. I have over 11,000 pages on my list. And yes, it *would* be nice to have a filter-by-namespace on this page. jillaine 10:03, 23 July 2009 (EDT)

Good point. I need to rewrite the watchlist page to allow filter-by-namespace paging so it doesn't try to load your entire watchlist at once. I'll try to get that done by the end of this year.--Dallan 14:31, 28 July 2009 (EDT)


Usability issues and the novice user [5 August 2009]

Quote from 'Q': "yes, we know there are "usability issues", but what are they? What is it that you found that you think are stumbling block? What makes it hard for folks to use the site? That kind of insight would really help make the site sing for a wider audience."

Let me say right off I've watched WeRelate for over a year and still consider myself a 'novice user'. I work until I get frustrated and leave for a bit. But I'm continually drawn back because I love the concept and want to make this work. I often want to tell someone where I have a problem or find an area that is not intuitive enough. I do that and my comments are scattered about the community.

What would everybody think about having a page just dedicated to newbie/novice reporting their problems? Wouldn't it be helpful to the developers to have this all in one spot? I'm not talking about a page to vent frustrations; I'm thinking of a page where novice users could tell specifically what doesn't work for them. I wouldn't want to put this necessarily on the watercooler because experienced folks don't need to wade through this. But I agree that the experienced person doesn't always see a problem where others stumble. And I don't want folks leaving because of having no vehicle to helpfully point out something that needs improvement. I'd like for something like this to be in a forum, but that will be awhile coming; so in the meantime, perhaps a 'Report a Problem' page for newbies could be considered. Directions could be given to ask a person to be very specific about what problem they encountered. And if it's a real bug or something that can be fixed, remove the report when the problem is resolved to keep the page manageable.

I know it makes me feel like I've tried to help, instead of just venting, when I'm able to tell someone what I see as a problem. I often don't know where to post my comments.--Janiejac 23:15, 16 July 2009 (EDT)


I do wonder if a lot of people are more comfortable with a Blog or Forum type interface as in rootschat.com (one of the more popular UK centred ones). Lots of useful requests and assistance happening there. As I see it they 'solve' lots of genealogy bu it is never stored centrally for re-use.


Might we get more interest if we had this type of portal to WeRelate as well ? Geographically centered discussions with the moderators for each board then encouraging people to put there findings in the WIKI ? People might find this less intimidating than a talk page.

perhaps a step in this direction is for those in 'projects' to consistenly provide a discussion area, which could then be aggregated into a portal. even if we dedicate a 'article' page for discussion.

I suppose there's a possibility it might be even more confusing--Dsrodgers34 00:51, 17 July 2009 (EDT)


I think there are a LOT of things that can be done to improve the experience of new users, and which therefor would result in higher retention of new users. A newbie corner might well be one of those things. Possibly a mailing list targeted to helping new users. One of the benefits of WeRelate is the free flow of information on talk pages, but that's also a problem. Have you noticed how difficult it is to add something to a long ongoing discussion--especially if its not right at the end, but somewhere in the middle. I have difficulty finding where to insert a comment; I'm sure newbies wouldn't even try. So mailling lists where conversations have a more formalized structure (you send a message, I reply to it) might be a useful approach. Perhaps such a mailing list might be pointed to in welcoming message, as a place to go to get help. Q 08:02, 17 July 2009 (EDT)


I agree, these discussions are very difficult to follow as comments get scattered all over, here and at random talk pages. If the talk pages were structured to thread topics instead of allowing posting anywhere all you would need to do is add discussions of interest to your watchlist.--Scot 13:07, 17 July 2009 (EDT)


Could we start a UK portal ? Often UK people see a collaborative site and see it dominated by US content, and move on.

My suggestion for now would be to add pointers to active UK - centric researchers home page and place or other pages' talk pages. Once it was of a useful standard we could start publicising it to suitable people in order to garner some interest. By suitable I mean some leader type people who are active in such as rootschat.com. they doe really good work but the work isnt then put into a meaningful structure/context for re-use.

Incidentally, are there ny UK centric people who would be interested ?--Dsrodgers34 01:46, 18 July 2009 (EDT)


I think a UK portal is a great idea. A template is provided at Portal:Basic Layout with Instructions and a help page at Help:Portal.
You can create a new portal page by going to Add, Other Page, and choose Portal from the Namespace drop-down box. Enter a title like United Kingdom and copy/paste the source text from the Basic Layout page. If you need any help getting things set up, just let me know. Volunteer admin--Jennifer (JBS66) 07:19, 18 July 2009 (EDT)

A newbie corner seems like a good idea. I have some idea of the problems people face and am slowly working on fixes for them (my goal is to get some of the worst ones solved before FGS in September), but maybe a Portal-style page for newbies would be helpful? Would someone be interested in taking this project on?--Dallan 13:40, 28 July 2009 (EDT)

I think a portal assumes a new user will 1) find it; 2) read it; and 3) find their question there. Building such a thing would be a helpful exercise in answering frequently asked questions (although, hopefully, duplicative of help pages already written). Given the difficulties of this free-flow format, however, I would recommend a standard message board that either had notifications to 'watchers' or gateways to a mailing list, for new (or old) users to ask their questions that they don't find answers to. Reunion software does this to great success with ReunionTalk. Much of what goes on at WaterCooler could be there too, but we could also have boards explicitly labeled as being a place to ask newbie questions.--Amelia 12:24, 31 July 2009 (EDT)

One thing I have noticed is that WeRelate is about the only place that doesn't have a "who are you looking for?" box on the front page. Yes, there is search, but could you get anything useful out of it on your first try? It would be nice to have a more welcoming front page. A name search box and a link to the proposed newbie portal would both be helpful to draw people in rather than turn them away. --Judy (jlanoux) 17:00, 31 July 2009 (EDT)

Both good suggestions. I've been thinking about how best to incorporate a more standard forum, or if a talk-page forum would work alright. Let me see what I can do later this Fall.--Dallan 01:14, 5 August 2009 (EDT)



User-specific page markings [5 August 2009]

I've used this site extensively to add and edit Person and Family pages for people both directly and indirectly (and sometimes not at all) related to me. I watch a lot of these pages, and sometimes it's hard for me to immediately tell who I'm getting updates about and how they're related to me. Here's what I'm proposing:

  1. A way to mark a page as related to you in a certain way. Maybe by making a Living page and marking it as "this is me", or marking any page as "this is my [blank] (mother, father, grandmother, etc.)".
  2. An automatic label on any other page that tells you at a glance how this person is related to you, if at all. So I could visit a random page and it would have a badge at the top saying "this is your 10th great grandmother" or "this is a cousin, twice removed".

I'm not sure how tough this would be to implement, but it seems as if all the pieces are in place, once we are able to mark known relations. I do think that it would make this an extremely interesting and magical place for people looking for distant relatives, and help those of us that can't keep track tell who we're looking at. --Joeljkp 22:39, 26 July 2009 (EDT)


WeRelate meets facebook ?

Seriously though, this could give some broad appeal to WR - the appeal of genesreunited without the mountains of dross. People who are not confident might register for updates even if they dont want to contribute (hopefully in time they won't need to - it will be close to complete (bar the arguing over 'speculation' or 'ambiguity')

It would be harder to code but if the viewer could also get notifications about changes direct ancestors of their 'anchor' person, or even any page linked to them - (they can do this now with a tree but aren't trees under discussion ?). or even when a new page links ?--Dsrodgers34 22:59, 26 July 2009 (EDT)

I recently implemented being able to add multiple generations of ancestors or descendants of a person to a tree at once. Despite previous discussion, trees are here to stay. Rather than replace them with something else, I'm going to try to improve them over time.--Dallan 15:34, 28 July 2009 (EDT)

I'm not sure how we might pull that off. I don't think we would want to clutter pages with user-specific information. It's not exactly the point around here, after all. Indeed, I usually remove notes to the affect of "John Doe's 82nd grandfather". Even if that information was somehow hidden in the form of an XML comment or some sort of non-printing tag, I don't think we would want that sort of thing to build up (I could be wrong of course, just my take on it).
It's almost like what you want here, is a page with links to your family members of interest, with each person tagged according to your personal relationship. Then, you would like to have a special-purpose search that cross references the links from your page with changes on your watch list. I think...
In a universe of limitless compute resources, maybe we could ask the page-generation engine to emit relationship information on changed members of the watch list, where you would seed that process with a key individual (then WR could try to figure out how any given person is related to your key individual). Something like that would indeed be slick, but also - I should think - too costly for normal use.--Jrm03063 08:49, 27 July 2009 (EDT)
That's what I thought the request was, but I think it's actually more like the relationships shown when you're on Facebook, or better, LinkedIn. You're looking at someone's profile, and there's a box that shows how you are connected to that person ("You -> Bill -> Susie") It changes for each user for each page. Now given the size of genealogy networks, it seems like there might well be a load issue, but perhaps no worse than the tree already proposed (maybe have one or the other?)--Amelia 09:53, 27 July 2009 (EDT)
I'm no expert on the computing side of it, but what I think such a feature adds is a balance between the individual and the group goals for werelate.
I would suspect that many new users, like me, come to werelate from other genealogical websites and software programs where the emphasis is on "My" Tree. Sooner or later, a person realizes that the tree I've created has either grown too large, or has places where I've gotten stuck and I can't find the next layer. Or perhaps I realize that I've got a lot of info that would be useful to others, but that there's no good place for in my tree. Or that I want to collaborate with specific other family members, and I need a place where I can do that. (All of these reasons are why I was searching for something like werelate.)
Anyway, once I'm here, at least at first, I need a way to keep connected with and tied to "my" tree (i.e. the Family Tree Explorer) as well as ways to explore all the other persons and families that are here. In my personal family tree software (FTM), there is a "define relationship" script that labels every person in a tree with their relationship to the "home" person (who is not necessarily me). At Ancestry, I had to use CAPITALS to show who was related to my home person directly. Since we don't want to clutter up werelate (where all pages are shared) with cryptic codes and CAPITALS, I think it would vastly increase usability and user excitement (which leads to retention) to find a way to track relationships...Brenda--kennebec1 09:14, 1 August 2009 (EDT)

This has intrigued me somewhat for a while.... Some WeRelate contributors have added "cryptic" codes on some of their ancestors, many of which don't seem to make much sense. Some appear to be LDS or AFN numbers, others are probably just a code to agree with their own genealogical file. I usually opt to delete codes or dates that don't seem to directly relate to a genealogical relationship for an ancestor. I have not seen anything in the WeRelate documentation as far as a stance on this type of coding, whether LDS or otherwise.... Also, I'd like to know what the stance on LDS "baptism or admittance" dates is. On the surface, I don't think they have a "genealogical reason" to be included, but perhaps someone could weigh-in with their thinking....--Delijim 13:12, 27 July 2009 (EDT)


when I see such marks, I remove them. I have found where an x or asterisk precedes or is appended to a given name, apparently to indicate which sibling is the submitters ancestor. I view this as clutter. When I receive notice that a page on my watch list has been edited, the first thing I do is search my desktop program for the person or family to determine the relationship. I check the page to see if I have anything to add and either add or delete it from my watchlist depending on my level of interest. If you need to, add the relationship on your desktop page not on the WR page. admittedly navigating down from an ancestor is harder than moving up. instead of using FTE for navigation, I usually use pedimap as you can searchup 5generationsat a time. Also, I don't believe temple work is relevant here. The data base maintained by the LDS church should be an adequate repository. UID's, RIN's and such have no value here. AFN's are controversial, but do indicate the quality of the source, or lack of same.--Scot 14:21, 27 July 2009 (EDT)

I agree -- AFN numbers should be kept because they can be used to reference AF (I know, not a great database, but it's often the source of the information). Personal codes and LDS events can be removed since they're not relevant to the community as a whole.--Dallan 15:34, 28 July 2009 (EDT)

I should have clarified - I was thinking out loud its not something high on my wish list. I am setting up a tree for someone else whos interested in my project so I can get by with that--Dsrodgers34 18:20, 27 July 2009 (EDT)


Right, to all who have replied, I wasn't talking about permanent user-specific markings in the page content, but an automatic "badge" put there by the system automatically for logged-in users. It would be like how the system knows a certain person is in your Tree and adds a link to the top toolbar.

The algorithm would be something like: is person logged in? --> has person marked a page with a known relationship to them? --> what is the relationship of the person being viewed to that person? --> display "This is your 10th great-grandmother!" marking. --Joeljkp 23:11, 27 July 2009 (EDT)


Since you are not supposed to put in page for living people, how would the system know how you fit into the tree to calculate your relationship? You would have to mark some page with your relationship to it, but that person doesn't pertain to just you, so is this appropriate? Is this not something you can do on your system at home? --Jrich 00:26, 28 July 2009 (EDT)

Showing how you're related to people in your tree is an interesting idea. Once we get the bookmarking feature in place, you could specify how you are related to the person being bookmarked when you add the bookmark. The system could calculate further relationships based upon the bookmarks and store the relationships in the family-tree database records (that track which people are in which trees) so they wouldn't clutter up the Person pages. Like you say, probably not a high priority, but worth keeping in mind.--Dallan 15:34, 28 July 2009 (EDT)


I would like to encourage this innovation in some way. Even in my own Tree, once I get back several generations I can't always remember or tell which child is my direct relation, or which spouse leads to my lineage. So sometimes I get lost while browsing my very own Tree, never mind People pages in general or my watchlist! So something that would help in navigation and decision making would be really helpful and I think a plus for new user usability. Also, at least as described by Joeljkp, isn't this concept tied to the "who are my famous relatives" feature I read about as a future idea?

Would it be interesting or too much information to also know, for example, if there are other relatives of a person you are looking at who are logged on or who are members of werelate?

The system tell you if there are other people "watching" a page you watch. If we had a bookmark system such as you are describing, would the system be able to essentially suggest pages to you to either watch or add to your tree as relatives (Opt in)? Or suggest to a user that these 5 other users are also related to the person in your tree, and you can contact them via their "talk" page or even a "relatives" page?

I'm mostly brainstorming here about ways to develop conversations among werelate users, a factor I think potentially adds to new user connection/retention.

Brenda--kennebec1 08:51, 1 August 2009 (EDT)


I'll put labeling relationships higher up on my priority list.

There are a couple of features that might already handle the watcher situation you mention:

  • The "related pages" link on the "Trees" page (in the MyRelate menu) lists people not in your tree who are related to people in your tree.
  • "Network" (in the MyRelate menu) lists other users who are watching the same pages as you, along with a list of pages that you are watching in common.

Having the system tell you how you're related to these other users also seems like a good idea.--Dallan 01:14, 5 August 2009 (EDT)


Promoting WeRelate in Australia [28 July 2009]

As a member of the Society of Australian Genealogists I have emailed the editor of the Societies electronic newsletter "SAG-E" about using WeRelate and had positive responses from both the Editor and the Executive Officer. Can you suggest how I could promote WeRelate to the other SAG members?--burgjoh 23:31, 26 July 2009 (EDT)


I left a note on your user page Cheers!--Dsrodgers34 04:55, 27 July 2009 (EDT)


editing person page [27 July 2009]

This evening I edited the birth location of several folks, example Lucetta Jackson (1) from Fauquier, Virginia to Prince William, Virginia. This shows on the edit page but doesn't change on the person page. Why not? I tried leaving WeRelate and logging back on; I tried using the refresh button, but still the page says born in Fauquier, Virginia. --Janiejac 21:57, 27 July 2009 (EDT)

I went into the Lucetta Jackson (1) page and found that the place field actually read Prince William, Virginia, United States|Fauquier Co., Va. I deleted the pipe symbol and everything after it and it displays correctly now. --Ajcrow 22:03, 27 July 2009 (EDT)

Promoting WeRelate in Louisiana [28 July 2009]

I haven't been around much for a few days because I've been getting the Summer issue of the Louisiana Genealogical Register ready for the printer. I've been doing this for ten years now, and I swear this is my last year. One of the perks of editing a journal is that you can talk about almost anything on the Editor's Page -- or at least I do. This issue, the Editor's Page was given over to explaining what exactly WeRelate is, why it is, and how the readership could best make use of it. We'll see what happens. I expect to see a lot of Louisiana genealogists at FGS in Little Rock in a couple of months, too. --Mike (mksmith) 14:30, 28 July 2009 (EDT)


Tre Lag Stevne and FGS [18 August 2009]

Just a quick note: I'll be at Tre Lag Stevne in Minneapolis and FGS in Little Rock. If anyone else is planning to attend it would be great to get together. (Mike, I look forward to meeting you! :-).--Dallan 15:41, 28 July 2009 (EDT)

I saw that you'll be in booth 605 at FGS. I hope to see you there! --Ajcrow 18:20, 18 August 2009 (EDT)

GEDCOM export offline? [30 July 2009]

I've been waiting on a GEDCOM export since early this morning. Is it backed up? Turned off? Do I need to bribe someone with chocolate? --dayna 18:54, 28 July 2009 (EDT)

Sorry about that. There was a bug that kept gedcom's from being exported for awhile. The bug was fixed later that day (no chocolate needed :-) --Dallan 00:55, 31 July 2009 (EDT)

sending a tree to a new person [5 August 2009]

I saw this 'email' from the tree page and I thought it would be a good way to invite someone in.

Unfortunately the message seems a bit basic for a new user - I created a new login to test it but It wasnt obvious either.

Can I get slightly more complete instructions to send Quote Once you register you can save this tree as your own and we'll both be able to add information to the pages online. We can add new families and individuals, upload pictures, view maps of our ancestors' events, and more. I'll be notified of changes that you make, and you'll be notified of changes that I make.-- end quote Dsrodgers34 05:56, 29 July 2009 (EDT)

Here are more-specific instructions (I'll add them to the email template tomorrow):

  1. Create an account on WeRelate
  2. Click on the link in the email to launch the Family Tree Explorer
  3. In the File menu of the Family Tree Explorer, select Copy tree and give the tree the name you want. By doing this, you will be notified whenever a change is made to any of the pages in the tree. Likewise, I will be notified of changes that you make.
  4. In the future, you can launch the Family Tree Explorer on this tree by selecting Trees from the MyRelate menu and clicking on the launch FTE link next to the tree you just copied.

Please let me know what else (if anything) needs to be clarified. Thanks.--Dallan 00:55, 31 July 2009 (EDT)


Many thanks. you sound busy.

I'm hoping to attract some quality researchers in to boost the effort.

I was thinking this could be a bit like the old 'pyramid selling' without the rip-offs.

If you attract in quality researchers and they get busy,and you are linked in, the research just comes rolling in ! - And hopefully its for the 'common good' too of course !

PS I noticed Ancestry public trees has recently added in a feature whereby you can essentially 'watch' a page and be notified of changes. Trouble is in there, if someone has the same person as you, they more than likely 'imported' it from you anyway - its like pyramid in reverse !

Have a great weekend--Dsrodgers34 03:35, 31 July 2009 (EDT)


Great observation from Dsrodgers34 about the problems with Ancestry family trees. It was also the potential issue I predicted might happen when Dallan created the GEDCOM export here -- that WR researchers would find their own data listed elsewhere (possibly on a fee-based service) without attribution or credit in a couple months or a couple years with additional user-supplied data, and not know whether or not it was someone else's original research or their own recycled genealogy. After experiencing that repeatedly with my LDS Ancestry File submission in the early 1990s (which was submitted in full at the time -- and for which I can't even change my address for contact purposes from four addresses ago) and my RootsWeb WorldConnect Project submission in the late 1990s (which I submitted an abbreviated predigree only, thankfully), that is why I made my own family tree 'private' on Ancestry.com when I subscribed to it two years ago. Now I am in the difficult and slow process of weaning myself away from Ancestry and the extensive family tree I created there. It is a great place to find scanned historical records and genealogical information, but, in my personal opinion, a less than adequate place to keep my family tree.--BobC 10:59, 31 July 2009 (EDT)

Just as an FYI, I plan to improve the tree sharing feature later this year. Currently, if you make a copy of someone's tree and they add a page to their tree later on, you would need to add that page to your tree as well if you want it to be part of your tree. I want to figure out a way to avoid needing to add the page to both trees.

Regarding attribution, each person in an exported GEDCOM contains a source citation with a link to the page here that it came from. It would be possible for someone to remove the source citations, but it would be in violation of the license under which they exported the tree. I'm expecting that most people will leave the citations in, if only because it's extra work to remove them.--Dallan 11:23, 31 July 2009 (EDT)

That's great news. Tree sharing along with the new "build a tree" functionality will help greatly in enlisting collaborators as new users. Since installing an email tree link puts everything on your watch list, I am grateful for the build a tree to let me create a tree specifically targeted to the interest of the person I am inviting. "Sharing" would let us all grow the same tree. Can you have it automatically add new people to everyone's watch list and get an email when a new person is added to the tree? --Judy (jlanoux) 16:54, 31 July 2009 (EDT)

That's the plan. I'm thinking that if someone watched a "tree" that they would be notified when a page was added to the tree and whenever a page in the tree was modified.--Dallan 01:14, 5 August 2009 (EDT)

FHC v. FHL [14 August 2009]

We have pages for repositories for both Repository:Family_History_Center and Repository:Family_History_Library. I think that the Library is the building in Salt Lake City, and a Center is a regional library. That being said, what is the proper term for the repository for items that are in the catalog and available for you to order by microfilm? The system has defaulted to making FHL the link and FHC the type, which is kind of odd. Do we need pages for both? And can someone with knowledge please edit those pages to make it clear which one we should use in case we forget? --Amelia 14:26, 2 August 2009 (EDT)

Hello Amelia, This is just my opinion. I would prefer that we keep both please. There is a small amount of sources that are available in the FHL (Salt Lake Library), but are not available to be sent to you thru the FHC's.
I frequently see people (not on WeRelate, of course . . .) confusing FHCs (of which there are hundreds, maybe several thousand, I don't know) with the FHL (of which there is only ONE). A local FHC may have a few books on its shelf that local users have donated, which might be thought of as a "permanent collection" -- but basically, an FHC is just a "depot," a delivery point for microfilms sent to them from Salt Lake. In which case, you can think of all the FHCs as just minor branches of the FHL system. So I wouldn't refer to a neighborhood FHC as a "source" (sorry, "repository"), only the Family History Library (Salt Lake). --Mike (mksmith) 10:47, 3 August 2009 (EDT)
It also brings up the question do we keep the NARA (Washington DC) and NARA Regionals as separate too since that is also true of the NARA system. The Civil War pensions are only available thru DC, not the Regionals. Also different NARA Regionals many times have their NARA Regional records, and the other NARA Regionals may not have a copy of those records. Thanks, Debbie Freeman --DFree 16:06, 2 August 2009 (EDT)
This is a similar issue, I think. When people (librarians and archivists especially) talk about the "National Archives," they mean the nationwide system. The regional facilities are just branches, like the neighborhood branches of your local public library. The key point is this: The regional branches have no independent existence as repositories. And what a regional branch happens to have available to you might very well change tomorrow, as a result of decisions made at the main office in D.C. They function as parts of a whole. Plus, some heavily-used materials are available both in D.C. and in all the regional branches, just for convenience. I don't think there's any problem with interpreting "NARA" to refer to the entire archives system. --Mike (mksmith) 10:47, 3 August 2009 (EDT)
Record Type 85 Chinese Exclusion documents, which Chinese Americans use to verify immigration and emigration exist only as originals and are found at the NARA regional branch associated with the port of last entry/exit, e.g. Angel Island at San Bruno and Ellis Island at Varick St. Without designating the regional facility, the document would not be found. (There is also usually a file box and file folder number, e.g., 1234/567 for the file folder for each immigrant.) --Ronengyoung 23:27, 3 August 2009 (EDT)
. . . and it's still housed at the "U.S. National Archives." --Mike (mksmith) 09:11, 4 August 2009 (EDT)

And aren't all these not Sources at all, but repositories? jillaine 22:43, 3 August 2009 (EDT)

Yes (read Mike's last line to say repository instead). And I'm not proposing that we drop either, only that we use only one of them to mean "that catalog based in SLC that will probably let you check out this book".--Amelia 22:48, 3 August 2009 (EDT)
Maybe we need, for these special cases, a way to have a "contained within" or "See also" reference. In each of these examples, the FHCs work as "branches" of the FHL, and the Regional Archives work as "branches" of the National Archives. But each FHC and each branch also has (or may have) unique collections specific to that location. Perhaps Repository pages for an FHC or a Regional Archive should have template language explaining that this is a branch of the larger Repository (with link) and how the regional locations function. Then also provide guidance to users/editors suggesting that any additional info on this page should be specific to THIS particular location's unique collections; otherwise, please cite the FHL or National Archives Repository.
This approach would seem to serve both needs - to record with some specificity unique resources available only in a particular Archive or FHC Repository, and connecting users to the larger (actual corporate) entitity that holds a set of collections. -Brenda--kennebec1 09:58, 4 August 2009 (EDT)

One would assume that most of the type of repositories under discussion have catalogues that would indicate limitations of availability, etc. I know FHL/FHC does. You can quickly determine which ones you cannot order. I see some value in making an entry for FHL and another entry representing all FHCs, but no necessity. Carried to an extreme, this idea adds too much complexity to WeRelate based on the organization of an external organization. So if all the items are listed in one catalogue, I think one repository would be reasonable, and then assume most people have some ability to using whatever finding aids are available to help them navigate that repository's collection. For really unique cases, I also expect there is the possibility of adding a comment to the source citation. --Jrich 11:00, 4 August 2009 (EDT)


I think as a general matter it looks like the FHL and FHC pages serve slightly different purposes, and that while technically each FHC might be it's own page, that would get pretty crazy. So to offer a concrete question, how should FHL catalog materials appear?

  1. Repository FHL, type FHC (default, in which case we should have some content on the FHL page)
  2. Repository FHC, type FHC
  3. Repository FHL Catalog (or some similar name), a page that describes the network
  4. Any of the above, change the type name.

Any but 1 would need some mass intervention, but since they were put in that way, I'm assuming that's not an issue.--Amelia 00:06, 5 August 2009 (EDT)


It looks like we had a bug from when we automatically-updated the sources last Summer. What should have happened is that items available only at the FHL (there are over 200,000) should have been given a repository of FHL and an availability type of "Other", while items that could be ordered and sent to an FHC should have been given a repository of FHC and an availability type of FHC. What did happen is that items available only at the FHL were usually given a repository of FHC instead of FHL, but the availability type was correctly set to "Other". I'll change the repository on these pages (where the availability type is Other but the repository is listed as FHC) to FHL when I update the sources in the next month or two. Thank-you for pointing out the problem.

I'm not as familiar with NARA. Maybe it makes sense to have a NARA "system" repository for general use, and region-specific repositories for cases where items are permanently available at a specific regional repository? --Dallan 11:22, 5 August 2009 (EDT)

Well, as I said up above there, somewhere, the regional branches are to the main archives complex in Washington (and in Suitland, MD, for that matter) pretty much as your neighborhood branch library is to the big main library downtown. In both cases, the various units are all part of a system. And the system is what matters, believe me. The Dallas Public Library (which I know pretty well) now has 30+ branches, but the repository you would cite is still simply "Dallas Public Library."
The regional branches of NARA are merely offices of the U.S. National Archives, sharing a catalog, an administration, curatorial & conservatorial support facilities, and so on. They have zero independent existence. At present, each regional branch has certain collections of original documents that were transported there (usually) from D.C. or Suitland. This was done, actually, because of a lack of storage space back east combined with an attempt at marketing, by making each branch seem "special."
But that's just how things are "this week," frankly. There's absolutely no reason the United States Archivist couldn't issue an order that all one-of-a-kind collections of original documents should be sent back to D.C. tout suite. (There's been a lot of storage expansion constructed in Maryland the past couple of decades.) Those collections don't "belong" to the regional branches. The branches simply have current custody of them. And, in fact, various materials do get moved from one unit of NARA to another, depending on need, all the time. So there's nothing "permanent" about the arrangement. Therefore, if you cite the repository by the all-inclusive term "U.S. National Archives," there's no problem. Anything moved from D.C. to a branch, or from one branch to another, hasn't left the system, only moved within it. And you can always note the current geographical whereabouts of a set of documents within the "citation detail" of the NARA repository listing, if it's useful to do so. --Mike (mksmith) 21:02, 5 August 2009 (EDT)
NARA did attempt a few years ago to move all of the Chinese Exclusion Records to their bunker in Kansas, but there was an apparently successful large campaign of protest as Chinese Americans view this as an effective denial of access, as the Chinese Exclusion Records now for the most part reside in the regional branch closest to the community of settlement, e.g., San Bruno with San Francisco Chinatown. You will make a lot of enemies if you give the current United States Archivist ideas to reopen the issue.--Ronengyoung 06:23, 14 August 2009 (EDT)
I agree with Mike on NARA. The WeRelate user may cite the regional office in the citation.--Beth 22:05, 5 August 2009 (EDT)
Thanks, Mike, for the lesson in NARA. That makes a lot of sense to me, too. Despite what I said above, it makes sense to me to combine the NARA repositories, though I'd add to the NARA page a version of Mike's explanation and Beth's suggestion (in user guidance).
And, I found Dallan's explanation of the FHL/FHC issue quite illuminating. I suspect I have changed some of the "Other" availabilities to "FHC" availability, because I didn't understand. Thus, it would be helpful if the Type name changed, perhaps to "FHL only" or "Utah" or even "non-circulating" (which is too long) with an explanation on the FHL page. Also, can the Repository selection on a source page have a "Find/add" link? I'm often uncertain about what the correct name is for a repository.
Given the MANY FHC centers, I could also live with having just the FHL repository, or possibly two Repositories for FHL (a way to get around the limits of the type field) 1) FHL circulating materials , or FHL Catalog? and 2) FHL non-circulating materials available only in one location (either the FHL in Utah or a specific FHC's internal collection, specified in the Source citation. detail.-Brenda --kennebec1 08:10, 6 August 2009 (EDT)
I'll add having a "Find/Add" link for the repository on a Source page to my todo list. Currently we use Repository:Family History Library for non-circulating materials and Repository:Family History Center for circulating materials. I'll edit those repository pages to explain better what they mean.--Dallan 00:55, 8 August 2009 (EDT)
Well, I've certainly screwed up more than a few before I realized there might be method to the madness. Can you tell us how to tell from from the catalog whether something is "circulating"? Is it just if it has a film number?--Amelia 16:22, 8 August 2009 (EDT)
I wouldn't worry about it too much. Books don't circulate, and microfilms that say something like "don't circulate to family history centers" on the "Film notes" page don't circulate. (I found all this out when crawling the FHLC 5 years ago.)--Dallan 22:33, 8 August 2009 (EDT)

Notification emails not sent [5 August 2009]

Notification emails of changes to pages made from Aug 2 (Sunday) noon to Aug 3 (Monday) noon EDT were not sent. The problem has been fixed, and you can click here to see a list of all pages on your watchlist that have changed since you last visited them. I apologize for the inconvenience.--Dallan 01:14, 5 August 2009 (EDT)


Citation Template in Citation Source Fields [12 August 2009]

I could have sworn that we used to be able to place the {{cn}} template into the Citation ID field on a given page. However, it appears that this is now being stripped upon saving the page. Was there a change recently? If so, why? Or is early stage dimentia rearing its ugly head? jillaine 10:41, 11 August 2009 (EDT)

I've also note that other templates seem to be stripped as well. Q 11:09, 11 August 2009 (EDT)
I usually put it in the description field for an event. It seems to stay there. I think your problem may be that the citation id field is expecting a valid source id.--Judy (jlanoux) 17:09, 11 August 2009 (EDT)
I haven't changed anything recently, but putting templates in the description field is a good idea. It will keep the software simpler if we have only citation ids in the citation field.--Dallan 00:22, 13 August 2009 (EDT)

Large public-domain transcriptions [19 August 2009]

When using public domain sources, I've made a habit of freely transcribing large sections of those works, and then using ordinary hyperlinks to give old narratives real life (see, for examples: Person:John Tuttle (11) and Family:John Gilman and Elizabeth Trueworthy (1)). My working approach to these has often been to create a large transcription with links, then distributing source-attached sections to various person and family pages as appropriate.

I'm starting to be concerned however, that I'm losing something of the effort when I break up such larger transcriptions. It seems like having a larger contiguous transcription of a source is a valuable thing - even if it isn't a complete transcription.

One approach might be to create such transcriptions as wiki article pages, linking back to the original source. The original source would also contain links to the werelate transcriptions.

Ideas anyone? --Jrm03063 12:13, 11 August 2009 (EDT)


I find long transcriptions somewhat annoying, especially those that seem to focus more on the parents and grandparents than the subject of the page, presumably trying to give some context, but annoying to someone interested in the subject themselves. Therefore, the idea of pushing longer transcriptions off to a separate article is good. If I am interested, I will usually try to find the original anyway, but if I am not interested, then it is simply time-consuming to have a long transcript to read through only to find it tells me nothing I don't already know.

In almost all cases, I value a short abstract right there on the page, with a link, to tell me if I want to leave this page and read the full text, be it an article within WeRelate, or a link to an outside website, or a book in a library.

I think there are multiple audiences: people just trying to determine if the Person/Family being viewed are pertinent to them, and people interesting in learning everything that is known about those people. The first audience just wants the basics plus some quick indication of how credible the information is, while the second probably wants to know everything there is to know about the subject. Their answers to this question may be different. --Jrich 23:23, 11 August 2009 (EDT)


I think your method of sourcing the information (or transcript) is appropriate, but appears awkward without personal notes and text under the individual subject's name; the person entry includes only the lengthy source citations. One method might be to create a MySource entry with the extracted transcribed information from the primary source, and then reference the MySource entry at the person page. It would still provide a path to the transribed source and let you include only the information you need on the person page to substantiate the entry or fact you are using in your personal details. Just a thought...--BobC 12:55, 12 August 2009 (EDT)


I'm thinking of moving the longer transcriptions off to separate article(s) attached to the relevant sources. I like the ability to create such pages, as they become a way to jump back and forth between twisted genealogical narrative and (so bloody many begats...) and the actual pages themselves. When the source says something like, Eunice was the daughter of Joe and Rose, it's slick to be able to jump from the linked source to the person and family pages - verifying that things are just as the source represents. Sort of links as a confirmation/validation tool.

I've always been reluctant to paraphrase a source. I throught that "note" flags on the source were a better way to introduce the researchers take on the source. I also like the source body to consist of, at least, a sufficient quote so that a follow-on researcher can know with absolute precision what part of the source text I'm referring to. I suppose they can get the context if they want to go look it up themselves. So maybe cutting back isn't a bad idea, especially if I'm going to put longer transcription pages somewhere else.

Source people? Could you weigh in on the idea of having partial/fragmentary transcriptions, on separate article pages, pointed at somehow by a source page? --Jrm03063 16:57, 12 August 2009 (EDT)

I have been doing a lot of these lately and have the same problem. I now begin to think I understand what Dallan meant when he talked of a possible "document" source type with a container for transcripts. For now, I see three possibilities: 1)put them in the source text on the person page where one or two might relieve the page of it's naked look, but more are overwhelming. 2) use a MySource. I favor this one because it looks and works like a source and can contain a transcript. I just dislike the personal connotation when it's a shared item. 3) use an article and link to it. The third is the one I am least likely to use unless it truly is not directly relevant to the documentation. It feels more loosely tied to the person. I just love that we have a way to post transcripts and try not to worry about the perfect vehicle.--Judy (jlanoux) 21:03, 12 August 2009 (EDT)


My take: John Tuttle is impressive. What would be more impressive is a fully footnoted and linked narrative that wove all those sources together. In that case, I think the long sections on the person page sources become duplicative, and they should be on the source page itself (can we do subpages maybe?) or an article page. The only thing that really needs quoting on the ideal page would be the best event sources (in the source info box), wills, any similarly important (and reasonably short) documents, and perhaps short bits of particularly interesting writings from other historians. But, we don't live in an ideal world (yet!) In which case, I don't mind seeing longer transcriptions on the person page if they're about the person. Extended family bits should go somewhere else. I don't think I MySource page is appropriate, really, but the source page, an article, a category page ("Tuttle in Connecticut"?) if applicable, or a subpage or talk page of one of those all seem to make equal sense to me at this point.--Amelia 00:07, 13 August 2009 (EDT)


Eventually maybe the best thing would be to have a separate "Document" namespace for transcriptions, but in the meantime I'd suggest moving the texts to MySource pages or articles and optionally leaving short excerpts on John's page. Creating source subpages is an interesting idea, but I'm not sure I want to encourage that right now because I don't know how it would fit into searching sources or the source drop-down list.--Dallan 00:22, 13 August 2009 (EDT)


Well, I asked for comments! Great, thanks to all.

I appreciate what folks are saying about writing a narrative that brings the sources together, but what if I just want to get all the sources together and try to back up the genealogical facts list? I'm also not all that sure I have real new narrative to contribute on the subject.

Here's what I'm thinking. I understand the idea of using a "MySource", but the personal connotation of a MySource item, along with the tradition that it's a holding pen for just uploaded sources bums me out a bit.

How about this -

  • Create transcripts or transcript fragments as ordinary articles
  • Give the page a name that is a combination of the source name, an identifier that the page is a transcript, and some indication of where (in the overall source) the transcript came from (I'll make a proposal on this form shortly).
  • On the source page, we create a section called "Transcripts", which is simply a table of contents of transcripts from that source.

--Jrm03063 10:04, 13 August 2009 (EDT)


I wanted to create an example of what I'm suggesting, for everyone to browse. For the Person:John Tuttle (11) page, there is a source Source:Tuttle, Charles W. The Tuttle Family of New Hampshire. This was formerly a very long section on the person page, but I've trimmed it. Also, after the volume and page in NEHGR, I note that there is a WeRelate Transcript page. The transcript page indicates the source page, and the Source:Tuttle, Charles W. The Tuttle Family of New Hampshire page notes the transcript.

This practice generally seems to follow what I believe has been suggested for family bibles and the like - a specific source page that is just the source reference, with a companion page that contains the transcript (if there is one).

One of the things I would like to tidy up, is to have the source record transcript link point to the right place in the transcript, instead of just to the top. I assume there's a nice way to do that without creating artificial headings in the transcript. Other cosmetic suggestions would be appreciated...

--Jrm03063 16:46, 13 August 2009 (EDT)


I thought that when we have a citation to a periodical article that we are supposed to cite the periodical, not make a new source page for the article. --Ajcrow 07:16, 16 August 2009 (EDT)

I agree. There is already a source page for the periodical. The iss