WeRelate talk:Watercooler

From WeRelate

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

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

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

Topics

[add comment] [edit topic]

Active discussions taking place at other pages [22 January 2010]

Junk Genealogy
Merging & Down- loading Trees
Sources & Repositories and Source Review
Surname Research Pages
Duplicate Review
Proposal for Managed Pages
Tree Concept in WeRelate
Living People
Naming Conventions
Data Entry Design
New User Support
Categories Project


[add comment] [edit topic]

Technical details? - non-GEDCOM import/export, API, MediaWiki extensions, etc. [3 March 2010]

Is there any place which describes some of the technical underpinnings of the site such as the schema used, how things are modeled, etc?

The FOLG site implies that the code is open sourced (since they're advertising for open source collaborators), but I wasn't able to find where the code repository is located. Is it someplace on werelate.org or on a MediaWiki extensions site or a generic Sourceforge style repository or ...?

Is there an API that can be used to access the site? Where can documentation be found?

Any support (or future plans) for import/export of formats other than GEDCOM?--Tfmorris 05:12, 23 November 2009 (EST)

I am interested in the answer to these questions as well. Anybody? --JoshHansen 23:13, 21 December 2009 (EST)

The best way to see the technical underpinnings is to add "?action=raw" to the url of any page (say a person or family or source page). That will show you the actual contents of the page. You'll see that the data is stored in an XML "island" in the page. The XML schema follows the GEDCOM schema fairly closely.
In four years of advertising for open-source developers I've had only one person express an interest, so the WeRelate source code is not open source. It's simply not worth time it would take.
There isn't an API that you can use to access the site, but the page content is available for download in case you are interested - the same as Wikipedia. Are you interested in helping out?--Dallan 23:01, 12 January 2010 (EST)
Hey Dallan, thanks for your reply and sorry for the delay in responding. I suspect that there have been many people over the years who have wanted to contribute to the development of the site, but that the lack of available code has dissuaded all but the most determined. Though it is true that there are some administrative issues with releasing your code as open source (especially when you start to have other contributors that you have to interact with), at the outset opening your code can be as easy as labeling the files with your chosen license (BSD,GPL,AGPL,Apache...) and then uploading the code to a source repository on SourceForge or somewhere else. In the long run, especially as you get more volunteers implementing features on your rather long to-do list, you could save a lot of time by opening the code. An example of another website that has its source available is pgdp.net, which has a project on SourceForge.
My interest in the code is for purposes of putting WeRelate on the Semantic Web. This seems like a fairly straightforward problem, yet as far as I can tell from the graph at [1] there are no genealogy sites doing this yet, in spite of the potential benefits. I think it would be fine to do something quick-and-dirty where we just get the site to generate RDF to go along with each page. We could add a link tag along the lines of <link rel="alternate" type="application/rdf+xml" href="http://werelate.org/resource/Person:Billy_Bob_Bimbo_(1)" title="RDF/XML Representation" /> to each person and family page, and then generate the rdf conforming to the "genealogy-core" ontology, which is a _very_ simple semantic encoding of genealogical information.
Some links: a guy at the BBC talks about why making their site semantic was beneficial [2]. A helpful tutorial document about how to do the integration [3]. Discussion of URI issues [4].
What would be required from you:
  • Put the WeRelate source up on something like SourceForge or Gitorious -- or host your own source repo.
  • Decision support concerning URI and namespace issues
  • Perhaps implementation of some redirects on the web server
In exchange, WeRelate would become the first genealogy site to join the "Giant Global Graph" and as such its data would become even more useful to the world.--JoshHansen 22:10, 30 January 2010 (EST)

Here's what I've done:

This should be everything you need to generate RDF files from the data.

Unlike the robot framework, which I'm happy to open-source, I don't want to open-source the php code that runs the website, at least not yet, because I don't want a bunch of people creating separate genealogy wiki's that didn't interface/synchronize with WeRelate. In my opinion that would defeat the purpose of a shared genealogy website.--Dallan 12:06, 3 March 2010 (EST)

[add comment] [edit topic]

GEDCOM upload problem? [14 January 2010]

If you look at Family:Edward Converse and Sarah Unknown (1), there are four children: Samuel, Josiah, James and Mary. When I recently uploaded a GEDCOM with this family, the family only ended up with two children and when I noticed, I had to manually connect the other two.

Here's what I think happened. The existing family page was updated with new sources I was uploading. The one lone child originally shown on this page, Samuel, was updated as well. A child Josiah who previously didn't exist in WeRelate at all was added and placed in this family. So far so good.

The remaining two children, James and Mary, both existed in WeRelate with their spouses prior to my upload, but neither one had their parents identified. When uploading, I matched to James and Mary family pages using their spouses. This part worked. But James and Mary did not get added to Edward and Sarah's page as children, even though they were so connected in my GEDCOM.

It happened with one other family in this upload as well. --Jrich 00:53, 23 December 2009 (EST)

Wow you're right - that's a bug. Thank-you for reporting it, and thank-you for the detailed explanation! If you're uploading a person and you match the person with an existing page, and their parent family page with an existing page, and their spouse family with an existing page, and the person in your gedcom is related to both families but the existing person is related to only one family, the system won't add the person to the other family. I'll put fixing this bug high on my todo list.--Dallan 20:25, 14 January 2010 (EST)
[add comment] [edit topic]

Getty Vocabulary [14 January 2010]

Getty placenames from their Thesaurus of Geographical Names (TGN) are used in WeRelate. According to Source:Getty Vocabulary Program, these were added during a research period when WeRelate was being put together. According to http://www.getty.edu/research/conducting_research/vocabularies/tgn/ (and child pages), however, the kind of large-scale use that the vocabulary is being put to here could potentially run afoul of The Getty's copyright on this material. Could WeRelate's Administration speak to this, please? I am sensitized to this issue through contributing to OpenStreetMap, which is very averse to using copyrighted material as the mission is to create resources which can be used with the least copyright overhead possible. Regards, ceyockey 13:54, 27 December 2009 (EST)

I asked Getty about this when I incorporated their material. They said that as long as I wasn't incorporating their entire database they were ok with what I was doing. I only incorporated the populated places and political divisions in their database, which is a small fraction of what they have (their database also includes geographic features like rivers and mountains). Also, I did not incorporate any of their descriptive information about places, which for certain places is fantastic.
The Alexandria Digital Library also has a place database. It looked pretty good and I received a license to use it, but I ended up not using it.
Open Street Map is very cool by the way. It looks like it's come a long way since I saw it last.--Dallan 20:42, 14 January 2010 (EST)
[add comment] [edit topic]

1st Ohio Heavy Artillery project update [6 January 2010]

There are now two companies complete in my 1st Ohio Heavy Artillery project: Company A and Company B (just completed this morning). All of the officers (commissioned and non-comm) for Company C are also online. There are a few men from almost all of the other companies as well. -- Amy 09:18, 31 December 2009 (EST)

Great job, especially the links to individual Soldiers. I have been pondering doing something similar for the regiment my great-great grandfather served in during the American Civil War -- this might give me the inspiration to start working on it again and make it a reality. BTW, I added the Civil War category to those pages.--BobC 09:33, 31 December 2009 (EST)
Yes, Amy, that's becoming a really useful chunk of research as it grows in size. I've thought about doing something similar on the 91st Indiana Inf, the 36th Iowa Inf, the 1st Kentucky Cav (CSA), and/or the 29th Texas Cav, all of which include people from my own family, . . . but I probably have too many irons already in the fire right now. (I tend to get too ambitious with things and over-extend myself.) You know, a project like this -- researching all the members of a specific CW company or regiment -- would also make an interesting methodological seminar lecture -- but you've probably already thought of that! --Mike 10:14, 31 December 2009 (EST)
Thanks for the kind words, both of you! Bob -- thanks for adding the US Civil War category. I had forgotten (if I ever knew <g>) it existed. Anyone thinking about doing a similar project wouldn't have to tackle an entire regiment. They could do a company or two. The only reason I decided to work on the entire 1st OHA is because I've been collecting data on them for so long. If I was starting from scratch, I would probably start with my ancestor's company (D). Mike -- funny you should bring up the idea for a lecture. I'm doing a lecture at the Ohio Genealogical Society's conference in April about the research I did for my senior honors thesis, which was a case study of African American Civil War veterans living in Springfield, Ohio. I don't know if I could do something similar with my 1st OHA work (yet), as so much of the material has been gathered rather happenstance over the years. -- Amy 10:30, 31 December 2009 (EST)
Well, yeah -- I wasn't thinking so much about a whole regiment as about the individual company. Especially in rural areas, as you know, a particular company was generally recruited all in one county or neighborhood, so I'm likely to already know something about many of the members of a company from previous family research. --Mike 14:57, 31 December 2009 (EST)
I too would probably begin with the unit my gr-gr-grandfather served in because most of them were from Berks County, Pennsylvania, whereas the other companies of the regiment were from neighboring counties. Anyone else have ancestral ties to the 88th Pennsylvania Volunteers? Sounds like a good project for 2010. Interesting thought. --BobC 22:39, 31 December 2009 (EST)
[add comment] [edit topic]

Numbering children on family page [14 January 2010]

I'd like to suggest a minor improvement to the display of a family page. Can we get the children numbered? I know it takes up a bit of space, but when there are 12 children in the family and you're trying to compare a WeRelate list it to your own list of children, it makes it a bit quicker to spot discrepancies - at least I have found it useful on other websites.

Obviously, this needs to be a dynamically-numbered list, so that if a new child is inserted, the numbers are updated accordingly.

Not high priority, but please put this on your wish list. Thanks.--DataAnalyst 23:13, 1 January 2010 (EST)

That's an excellent idea. I've got quite a few of those farm families, too. It may not be so much a problem, though, when the pages get redesigned. If it's a family-group-sheet kind of thing, dynamic numbering would be easy. --Mike 23:19, 1 January 2010 (EST)
My 2 cents worth - I'd much rather see the WR ID# beside the children's names! And entering a new child should be no problem if and when the sort order becomes first by birth date, and second by order entered if there is no birth date. Or have some way of manually ordering the children. The lack of WR ID numbers on the family page is a continuing frustration for me. --Janiejac 23:36, 1 January 2010 (EST)
WR ID? When you mouse over a child, doesn't the link for that child page show up in the status bar at the bottom of the window? The link of course, contains what I assume you mean by WR ID#, i.e., 3 in http://www.werelate.org/wiki/Person:John_Doe_(3). Or are you referring to something different? --Jrich 23:49, 1 January 2010 (EST)
Hmmm. I have never noticed that 'status bar' before. And it does have a number in it; but without your telling me I would never have known that

http://www.werelate.org/wiki/Person:Jeremiah_Jackson_%283%29 was Jeremiah Jackson (3). Maybe knowing now how to translate that %283%29 into (3) will help eliminate some frustration, but how hard would it be to just put (3) beside his name? Apparently the WeRelate assigned number is always the number after 28??? --Janiejac 02:29, 2 January 2010 (EST)

%28 is how a left parenthesis is encoded for a URL. Similarly, %29 is a right parenthesis. So %283%29 would translate as (3). If you're curious, you can read more about URL encoding here. -- Amy 07:27, 2 January 2010 (EST)
Thanks for the explanation. That helps. But werelate cannot expect the average uploader to know this. It would be helpful to me to see the assigned number by the name. But wouldn't seeing both the werelate assigned number AND a sequential number be confusing? Perhaps not, because the sequential numbers would be easy to understand. --Janiejac 11:04, 2 January 2010 (EST)
With mouseover, I get floater as well as the usual link reference on the status bar. (I see that with both Firefox and Chrome.) Both of them say "Jeremiah Jackson (3)" -- so I can't imagine why you wouldn't see the parenthesis as a parenthesis. What in the world browser are you using, Janie? --Mike 16:53, 3 January 2010 (EST)
It's not necessary to imply that she's not reporting just what she's seeing, Mike. It works the way she describes in Safari, which is at least as mainstream as Firefox and Chrome.--Amelia 20:50, 3 January 2010 (EST)
I wasn't suggesting that the average WR user would necessarily know that. I was just explaining what it is. I think a lot of this will be covered when the pages are redesigned. --Amy 11:20, 2 January 2010 (EST)
And I appreciate the discussion and explanation. I wouldn't have known and it will be helpful to know those WR numbers. I checked using AOL (paid version), IE and Firefox. Both AOL and IE show the %283%29 while Firefox shows (3). --Janiejac 23:39, 3 January 2010 (EST)

Adding the WR number is a good idea, but I had more in mind adding a sequential number before each child's name. If the family page is being redesigned, please consider this. My reasoning: If I am looking at a family to determine if a) there is more info there than I have in my own database or b) there is invalid info in WeRelate that I might want to clean up, a quick count of the number of children tells me whether it is worth looking more closely. The human brain can easily do this for about 5 entries, but when there are 7 or more, it is very helpful to see the total number of children. Numbering each child is a common way to do that. Then if both WeRelate and my database have 12 children and numbers 4 and 8 are the same, I might not take a closer look. But if WeRelate has 13 children and I have 12, I start looking for a duplicate or misplaced child in WeRelate, or maybe I am missing a child. Having a number beside each child makes it easier to keep track of where I am when I go through the list.

And yes, I suspect it is mostly farm families that are this large, but I find a lot of them in early New England, if one is bothering to list all the siblings of one's own ancestors. Both my husband's and my families trace back there.--DataAnalyst 10:42, 2 January 2010 (EST)

Well, yes, I have improbable numbers of kids in New England colonial families as well -- but they're nearly all farmers. :-) My personal annoyance is that I lose track of the number of kids in the list because I generally have to scroll down a couple of times to view them all. --Mike 16:53, 3 January 2010 (EST)

I would find two sets of numbers confusing. Real estate on the screen is one of the more limited resources and I think its use needs to justified by some functional need.

Dallan is talking about allowing the normal sorting of children by birthdate to be overridden. If this is done with a sequence number, obviously sequence number would be necessary. On the other hand, perhaps he might chose move up/move down type of list to accomplish this. In the latter case, data entry and display of a sequence number may not be necessary, since it can be easily determined by counting. Making a sequence number a data entry field may involve some data management headaches, such as edits by two different people resulting in the same sequence number being assigned to the two different children, etc.

[Second thought re data management headaches: not to mention people misusing (unwittingly or not) the ordering for other purposes, such as moving their ancestor to the top of the list? For this reason, I wonder if it is better to just require people to enter estimated birth dates if they think the order is important. A child every two years following marriage, adjusted for what is actually known, seems to be a pretty standard approach. A will may identify somebody as the second son, but that may not be enough to provide a sequence number since you may not know the relative order with respect to the daughters, but if the first and third son's births are known, you can enter BET. X AND Y.]

Display of the sequence number that is used to distinguish people with the same names (the WeRelate ID) does not really seem necessary. Besides the fact that it can be easily determined in the status bar as discussed, it is rarely needed directly. The list of children are links to their pages and can simply be clicked on (opened either in a separate tab, or in the same window and use the back arrow). In fact, knowing this particular number is of limited use unless you are profficient at entering URLs directly into your browser's navigation bar. --Jrich 11:58, 2 January 2010 (EST)

I second JRich that WR ID is not a widely needed feature (I for one much prefer seeing full names; if you need all the numbers, click edit or use the status bar, which I do think that most people advanced enough to try a wiki and care about WR IDs will understand). I don't really care about ordering numbers either, but I can see the usefulness and I agree that having both types of numbers would be quite cluttered.--Amelia 18:48, 2 January 2010 (EST)

It sounds like allowing people to manually correct the automated sorting by birthdate and displaying a sequence number next to each child is the general consensus. I'll put displaying a sequence number on my todo list. (Manually correcting the sort order is already there.) If anyone wants something other than that, please say so.--Dallan 21:01, 14 January 2010 (EST)

[add comment] [edit topic]

The Generations Project - new program on BYU sponsosred by Roots Magic [7 January 2010]

The series will premiere on Monday, January 4, 2007 at 6:00pm MST on BYU Television with repeats shown throughout the week. New episodes will air every Monday. BYU Television is available on Dish Network channel 9403, DirecTV channel 374, many local cable systems, or online.--Beth 21:40, 4 January 2010 (EST)

Tried to find where I can stream this. Does not appear to be available via on-demand streaming. See [5]. If anyone else finds how to watch this, please post here. Thanks. Jillaine 17:44, 5 January 2010 (EST)

The PBS family history and genealogy television series from 2000, "Ancestors" is also broadcasting this week on BYU TV. I'm DVRing the entire series so I can watch it at my leisure. --BobC 23:00, 6 January 2010 (EST)

Also from BYU, for those interested in Independent Study, BYU now offers free courses (non-credit) in different areas of study. These areas include Family History, Family Life, and Religious Scriptures. Refer to the BYU Independent Study site for more information.--BobC 22:00, 7 January 2010 (EST)
[add comment] [edit topic]

Suggestion for the future = "pre-populate" WeRelate [14 January 2010]

This my get right up the noses of those who hate "Name Collectors" but here goes.

asuming the general aim of weRelate is the Pando thing - oneworldtree by another name - but with genuine quality of information to Wikipedia standards.

In short become the ultimate authority on family History relationships

Is having people submit their own family trees then (hopefully) having some mentor process or volunteer heirarchy which cleans up and enforces standards the most efficient way to achieve that ? The danger is the 'clean-up process' might involve so much work its impossible.

One thought would be to build an interface whicch allows volunteers to pre-populate based on resolving vital records.

Much in the way you can build trees very quickly in ancestry public member trees - with basic sourcing etc etc - obviously the checks an balances need to be there that aren't in such as ancestry at this point in time - each entry to be checked at least once by other volunteers - much the way it is done in transcription projects now.

There would oneed to be lots of detailed policy etc etc. For example ambiguities and bad trancriptions, information would need to be addressed.

But I'm still speaking hypothetically. The work would be methodical and targetted. the 'random' approach would take much longer to reach the "pando" ideal and would have many more errors. (I stress my argument only holds up if "Pando" is the ultimate goal)

I realise I'm talking about a huge amount of work. But wikipedia is a huge amount too, it was accomplished. There are millions of people now working on family history in a basically random faxhion. It just needs the leadership--Dsrodgers34 21:37, 5 January 2010 (EST)

I should add the result would only be a framework. People subsequently coming to weRelate would add more detailed information, or older information etc - its just that the framework would be much more robust--Dsrodgers34 21:41, 5 January 2010 (EST)

Two questions: (a) I wasn't aware that editors were restricted to only upload their own family trees - are you sure? (b) I don't understand what you mean by "resolving vital records" - coudl you give an example? AndrewRT 16:33, 6 January 2010 (EST)

No, people are not restricted to what they can enter there are already already have projects where they comprhehensively cover an location and / or a place in time. I'm suggesting that a more structured approach would get to the 'end game' more quickly than random approaches.

Resolving vital records is family or place reconstitution. Something like my little 'project' in which I have accounted for every census entry for a parish between 1841 and 1911. As time goes on I hope to: 

  1. resolve every record, photo, event or fact I find to a person record in my databese
  2. gradually increase the parishes covered starting with the two adjacent ones and so on.

Its illustrates what I am discussing but obviously the approach would be much more structured and with many people involved (if they could be motivated - but there are benefits for people who are not 'name gatherers" too.

Werelate has already got structure which has been systematically included (sources and places) - A fremework supplied by resolved census recoreds (for example) is just a smilar step (although avery big one)

Project HolmeVillageHome and technique discussion Article:HolmeVillageHome How a reconstitution was done--Dsrodgers34 17:24, 6 January 2010 (EST)

Constructing family trees by linking people found in a comprehensive set of records for a particular geographic area is a really interesting idea. Norway is considering doing this for their entire country. I hope the project gets funded!

I've been thinking lately about a middle-ground approach. This is a long-term idea: What if

  1. when someone uploaded their gedcom it first went into a "private" area,
  2. WeRelate presented possibly-matching records and made it easy for you to attach them to your people, like Ancestry does with their "shaky leaves" but for records that are available on free websites,
  3. WeRelate required that you review the possibly-matching records and attach them as sources before moving your gedcom to the "public" area.

Under this approach at least we'd get more pages with sources being added.

This doesn't include the "check by volunteers" idea that you mention. That's what happens before you publish an academic paper. I'm not sure how feasible it would be in the genealogical community though.--Dallan 21:34, 14 January 2010 (EST)

[add comment] [edit topic]

Shared research vs. Surname in place [17 January 2010]

We have 2 categories that appear to overlap: Category:Shared research pages and Category:Surname in place. The Shared research page says that "Surname in place articles are now referred to as Shared research pages." The help on each of these pages conflict... does anyone know what the most current decision is? I'm asking, because I am trying to make category pages for the automatically created red-links at the bottom of my person pages. Thanks!--Jennifer (JBS66) 12:10, 9 January 2010 (EST)

I don't know 'the most current decision,' but I do hope we keep the Category:Surname in place because I think that is most descriptive. 'Shared research pages' can be anywhere and everywhere, but nailing the info down to a certain place seems to me to be the most helpful. And if the folks migrate on to another place that can be noted. It does seem to me that Surname in place categories should be automatically generated and I thought they were; but I'm not sure now if that has been consistent. --Janiejac 18:07, 9 January 2010 (EST)

I'd also like to see the "Surname in Place" Category survive, it certainly helps "target" a family to a specific area for organization and makes it easy to find. Delijim--Delijim 08:57, 10 January 2010 (EST)

I've been experimenting a bit with some ideas to organize our Surname categories. I believe this is an underused feature here at WeRelate, but one that could be very useful. I began with a popular surname, Smith. This category automatically contains the pages that reference the Smith surname, (families, people, users, etc). I also created a few subcategories that appear at the top (Smith in Massachusetts Smith in Canada, etc).

To further organize these categories, I would like to propose a change. We currently link surname categories to Category:Surnames via pages such as Surname "A" and Surname "B". I believe this is unnecessary. We could eliminate these extra 26 category pages completely, and allow every surname to appear simply under the Surnames category (similar to Wikipedia). For ease of navigation, we could use a table of contents template.

I'm still thinking about Category:Surname in place... It doesn't seem to make sense to link our Surname in place pages to this category. As seen with Smith above, they could be linked to the relevant surname category only.--Jennifer (JBS66) 08:11, 11 January 2010 (EST)

If you look at the history, the Shared Research Pages category was a manually created category by Beth in Feb 2008. If the reason for creation is valid as intended (i.e. "Shared research pages contain information about people having a particular last or surname living in a particular place"), then Jennifer (JBS66) is correct in her observation above; the category seems totally redundant and unnecessary as it would serve the exact same purpose as the Surname in Place category which is a more user-friendly automated function. Additionally, the Shared Research Pages category contains only two linked pages, both of which also link to the Surname in Place category. The Surname in Place category has 54 connected subcategory links and 361 article links, making it far more useful and resourceful.
Rather than moving or redirecting the Surname in Place category links to Shared Research Pages category, I would be in favor of deleting the Shared Research Pages category altogether. It seems to serve no useful function and in my opinion is not a value added category to WR and causes confusion (as proved by Jennifer's initial inquiry). --BobC 09:22, 11 January 2010 (EST)
I generally like Jennifer's idea. I'm a visual person, so need to see this in outline form. Jennifer, if I understand you correctly, the hierarchy categories would be this:
  1. Surnames
    1. Surname (e.g., Smith)
      1. Surname in Place (e.g., Smith in California)

Only downside I see to this is that Jillaine Smith, born in California, would appear (if I were dead) in both the Surname in Place category as well as in the Surname Smith category. Ideally, the system would identify that I was born in California and place me only in Surname in California, and place in Category:Smith only those Smiths who have no birth place listed. Oh wait, am I confusing Surname:Smith with Category:Smith? I think the problem is still the same. I'd appear in both Surname:Smith and Category:Smith in California. How do we deal with that? -- Jillaine 09:44, 11 January 2010 (EST)

I don't see a problem with a name appearing in both the Surname in Place category and the Surname Category -- both serve a very useful purpose for different reasons. For example, if you look at one of my ancestral Surname in Place pages (Schonauer in Berks, Pennsylvania, United States), an auto link to the Surname in Place category was created upon initial entry. I then manually added a link to the Schonauer Surname category in the text block. That's how I dealt with it. --BobC 09:57, 11 January 2010 (EST)
 :I like Jennifer's idea of using that table of contents template!! That would make several categories much easier to navigate. As time goes on those pages that use just the letters of the alphabet will get terribly long and the need for table of contents template will be even greater. I am not programmer enough to know how much trouble it will be to make such a change but better now than a year from now. Anything that will make this site easier to use gets my vote!
If I clicked on 'Surname Smith' the next logical subcategory would be 'Smith in some State'. All the more reason to keep Surname in Place pages and not call them Shared Research pages.
There's a common v. rare surname issue here. I can see how it would be nice to "unclutter" the Smith category by putting the people with associated places in other categories, but if you have a really rare name like, I don't know, Gerlicher, it's nice to see at a glance if there are any such people entered on the site.--Amelia 12:55, 11 January 2010 (EST)

Here is the hierarchy I am thinking of (same as you detailed above Jillaine, just with links)

1 Category:Surnames
2 Category:Smith surname
3 Category:Smith in California

What tends to become confusing, I believe, is there are both Surname in place Categories and surname in place Articles. The categories are automatically generated, the articles are user created. I propose to no longer link Surname in place Category pages (like Category:Smith in California) to Category:Surname in place --Jennifer (JBS66) 10:23, 11 January 2010 (EST)

Not exactly true in all cases, Jennifer, because the Surname Research Links you create in your personal Profile Page creates Article Pages, which in turn automatically link to the Surname in Place categories (both the general category and to the individual surname category) as well as to the Surname Category itself. The category line on the article page looks like this sample Surname in Place page:
Image:Sample Category Link 2.GIF
So, as you see, it is important to know what is a bot function and what is a manual function. --BobC 11:36, 11 January 2010 (EST)

I will admit that I am confused on where to properly direct the surname Articles... I also wonder what will happen when we generate too many surname in place Categories. Say we have a few hundred Smith in place categories - will it become confusing? --Jennifer (JBS66) 10:23, 11 January 2010 (EST)

NOTE: I added the table of contents template to the Category:Surname in place to test it out.--Jennifer (JBS66) 10:36, 11 January 2010 (EST)
Is there a template showing just the 2 digit state designations that would be helpful?
Janie, the pages underneath this category are sorted by page title (in this case, surname). Clicking on a letter in the table of contents jumps you to the first occurrence of that first letter in the page's title.--Jennifer (JBS66) 10:57, 11 January 2010 (EST)
Jennifer, the template is mahvelus, simply mahvelus. Jillaine 11:19, 11 January 2010 (EST)

Well, I am going to be bold... I'll take the first organizing step and start eliminating the Category:Surnames "A"-Category:Surnames "Z". --Jennifer (JBS66) 13:45, 11 January 2010 (EST)

We have a third category named Category:Surname in Place. Capitalization requirements in the wiki are annoying. Who can remember what is capitalized and what is not? --Beth 21:53, 14 January 2010 (EST)

I found the origination and original definition of a Shared Research Page: Within the User Pages Help page the question is posed...

What is the difference between user pages and shared research pages?
  • User Pages are password protected, so that they can only be edited by the original creator
  • Shared Research Pages are community pages that can be edited by any registered WeRelate user

While it looks as if the decision has been made with regard to keeping the Surname in Place pages, I hope this helps refocus what so-called "Shared Research Pages" were meant to entail and encompass at WR. --BobC 14:50, 17 January 2010 (EST)


[add comment] [edit topic]

When use Category vs. Article [15 January 2010]

Above, Jennifer (re)raises the question of when do we use the Category:(Surname) in (Place) and when do we use an Article (Surname) in (Place).

I have preferred to edit the relevant Category page so it's all together. But in some cases, the narrative before the auto-generated list of pages becomes too long. Here are some examples of each:

Category:(Surname) in (Place) (Surname) in (Place) articles
Category:Schlenker_in_Schwenningen Brown in Missouri
Category:Fuller in Massachusetts Townsend in California
Category:Taylor in Massachusetts Taylor in Massachusetts
Category:Barber in Massachusetts Jackson in Queens, New York

I would limit categories to their intended purpose, to provide a visual structure for WeRelate's contents. I would put extended descriptive text, such as that on Category:Taylor in Massachusetts on it's own article page (Taylor in Massachusetts) (which does link back to the category).--Jennifer (JBS66) 11:36, 11 January 2010 (EST)

This part above is KEY to our (and others') understanding of the distinction between category pages and article pages, and because I don't think I've fully appreciated this before, I'm going to repeat it:
I would limit categories to their intended purpose, to provide a visual structure for WeRelate's contents.
Now I'm going to clean up the category pages I've messed up. Thanks Jennifer! Jillaine 12:44, 15 January 2010 (EST)
Jillaine, you didn't "mess up" anything. I suppose in theory I agree that Categories are just for "structure". But three problems here. First, you can't get a visual structure when there are hundreds of entries in a category. That's just a category that exists only for taxonomy structure purposes. Second, these surname in place categories link on EVERY PERSON PAGE. That makes them prime real estate and MUCH more likely to be seen than any articles on the subject. Third, the people as listed in category pages are incomprehensible since they lack dates. I therefore think it's really useful to do things like in the chart above (see also Category:Harrison in Virginia or Category:Arnold in Rhode Island). They aren't full surname in place articles, but I wouldn't have a problem with them being that way.--Amelia 13:55, 15 January 2010 (EST)
I would prefer to see WeRelate adopt a procedure similar to both Wikipedia and Familypedia. They use a template at the top of their category pages, directing users to the appropriate article on that subject. (ie Category:Canada and Smith (surname)). It saves a lot of confusion for users wondering where to put their information - categories or surname pages or an article, etc. --Jennifer (JBS66) 15:37, 15 January 2010 (EST)

While I generally haven't have a problem with enhancing the category page with additional manually added information, I agree with Jennifer (JBS66) that the additional information on the Taylor in Massachusetts category page would be better served on the Taylor in Massachusetts surname in place article page. This category page in particular, probably because the categorized links extend beyond 200 in number (i.e. multiple pages), demonstrates the "problems" that can appear when a lot of manual input is added to a category page with hundreds of linked pages. The manual input shows up at the top of every category page as the user scolls through the pages, and the linked pages, for which the category page is designed to highlight, are at the bottom of each page under the manually inputted material, which is duplicated with each page turn.

Category:(Surname) in (Place) (Surname) in (Place) articles
Category:Taylor in Massachusetts Taylor in Massachusetts


You're a good sport, Jillaine. If you'd like some help combining the manually-inputted information on the Taylor in Massachusetts category page with the Taylor in Massachusetts surname in place article page let me know. --BobC 18:05, 15 January 2010 (EST)

Just in case you have any need to know how confusing this is I offer the following:
Category:Surnames, click & go to SubCategory Surname:"J"

there is NO category for Jackson (surprise to me!) so to see where it would go if it were there, I clicked on Justice and it took me to the Justice Person & Family Pages which is fine.
So to see where the chain to Jackson was broken, I tried to work backwards from that ARTICLE I created 'Jackson in Queens, New York'. The automatic categories assigned were Category:Jackson Surname, and Category:Queens, New York, United States and Category:Jackson in New York. (On the article pg the link is blue!)
A click on the Category:Jackson Surname took me back to that category page with family and person pages AND ALSO had a link to another article page I created named 'Surname Jackson' which was meant to be like an overall research page with links to every Jackson in state article, also links to external Jackson web sites and (coming) a page for Jackson DNA. So I get very confused and probably manage to get others confused also.
So somehow Jackson surname should be listed under "J" and if anyone wants to suggest I do something different to distinguish between articles and categories, I'll listen! I had manually added Category:Surname in Place to the 'Jackson in Queens, New York' article. When I clicked on 'Surname in place' I first thought my article wasn't listed because the first thing you see on that page is subcategories - and no, it wasn't there. But when I scrolled further down on the page, yes, it IS listed among the articles. If we're going to have subcategories at all, shouldn't all articles be listed in subcategories? (Give me A for effort but I get an F in wiki! That's all for now!) --Janiejac 14:14, 11 January 2010 (EST)
Janiejac, the issue here is that Category:Jackson surname didn't have a [[Category:Surnames]] assigned to it, so it didn't show up as a subcategory. I see that Jennifer just added [[Category:Surnames]] to the Category:Jackson surname page so it does show up now. I agree that having to add this category is annoying. Not many people would know to do this. (More about this below.)
Also, subcategories are listed before articles on a category page. It takes awhile to get used to, but I think it's a good idea to separate subcategories from articles in a category.--Dallan 00:07, 15 January 2010 (EST)
[add comment] [edit topic]

Dallan's Poll on Surname Questions [27 January 2010]

I really like where this is going! I have a few questions and ideas.

1. Should we remove Category:Shared research pages? It's not needed anymore, right?

Correct. I vote "yes" REMOVE. Jillaine 12:44, 15 January 2010 (EST)
I also vote YES to remove Category:Shared research pages--Jennifer (JBS66) 12:57, 15 January 2010 (EST)
For the reasons I stated above, YES. --BobC 13:05, 15 January 2010 (EST). I'll amend my original thought to: Yes, remove as a functioning category. I would like to see the term revert to it's original use as stated within the User Pages Help page from Feb 2008 identifying the difference between user pages and shared research pages, where is stated, "Shared Research Pages are community pages that can be edited by any registered WeRelate user," versus "User Pages are password protected, so that they can only be edited by the original creator." --BobC 09:56, 19 January 2010 (EST)
YES --Jrich 10:15, 17 January 2010 (EST)

2. Do we want to have Category:Surname in place? It seems like this category will start to become very large. Would linking the subcategories and articles just to the appropriate surname categories be sufficient?

It seems that the purpose of such a page would be to list all of the "Surname in place" pages? Would such a list be useful? Jillaine 12:44, 15 January 2010 (EST)
Yes, keep the Surname in Place category. Yes, it will become large. I would say to link both to place and name; that way those searching for the name would be able to discriminate by place, and those searching places would be able to see and easily link to names. --BobC 13:05, 15 January 2010 (EST)
YES and YES --Jrich 10:15, 17 January 2010 (EST)

3. To simplify things, I'm thinking that the user pages should link to the surname in place category pages, rather than a surname in place article, and that creating a surname in place article should be the exception rather than the rule, to be done only when there is too much material to comfortably fit on the category page. If we agree on this, I can ask one of my children to cut-and-paste the material from all but the long surname in place articles to the corresponding category pages and to update links to point to the category pages.

At first I agreed with this, until Jennifer posted this reminder about the purpose of Category pages: to provide a visual structure for WeRelate's contents. I'm with her on this unless someone makes a strong case otherwise. Jillaine 12:44, 15 January 2010 (EST)
I feel that we should not be placing extensive text on category pages. Categories are intended as a finding aid, not an article. At Wikipedia, they generally contain only a brief description of the category, along with the automatically generated contents. --Jennifer (JBS66) 12:57, 15 January 2010 (EST)
Not sure which is more effective or preferential. Creation of an article within the User Page also creates the Surname Page (see Beth's inquiry on the Surname Pages and Links topic below). Personally, I like having the multiple linking of categories to articles and surnames in place. Many people don't use that feature though. --BobC 13:05, 15 January 2010 (EST)
NO. "long" is arbitrary, uniformity is simplicity, same rules for everything. Either insist on separate article if any text to be added, or text is always added to category. --Jrich 10:15, 17 January 2010 (EST)
We rely on judgment a lot here, so I'm fine with keeping only "long" "articles." The worst solution would be to insist on articles -- if they aren't linked to the right category page, they would never be found, and how are you going to stop people from editing categories anyway? Having the category links on person pages change to blue when there's content is a great way to clue people in that some possibly interesting content has been added.--Amelia 19:15, 17 January 2010 (EST)
To answer the question, "how are you going to stop people from editing categories" - well, you do that by maintaining the namespace. Just as volunteers monitor recent changes in place pages, image pages, etc... we should be monitoring the categories space for use that does not fit in with its function.
Your comment about links changing to blue when there is content is confusing to me. The links should be blue in a properly maintained wiki, and it is not because they contain content. Referring to a wikipedia article, describing the intent of categories:
  • Categories are a tool for browsing: they function as a table of contents, leading users to the articles on a specific subject.
  • Categories are a means of classifying articles
  • Categories are an index of a subject
  • Categories are a database search
  • Categories are an index of other categories
The TOC, when used properly, helps us to relax any concerns about category pages becoming too long. "In mid 2005 the category table of contents template, {{CategoryTOC}}, was created. With the table of contents it became possible to navigate through very large categories with a few clicks...there is no longer any reason that categories need to be small." Now, with WeRelate's use of the namespace in listing category pages, it makes the TOC nearly useless. This will essentially direct users either to F for Family or P for Person.--Jennifer (JBS66) 08:34, 19 January 2010 (EST)
I think Jennifer has discovered the root of the problem. If we think of a category as the title of the chapter of our book, maybe we wouldn't try to include the whole chapter as part of the title. If we stick to that it should eliminate a lot of the confusion. I'm visual - I'd like to see this laid out somewhere in outline form.
The book has a title, the TOC has names of chapters (categories) which includes 'index'. But the content of the chapter is not included in the TOC. The chapter or section called 'index' would be the Surnames. Surname category pages could talk about the origin of the surname and have links to Places (countries, areas, states). I don't know if we would need a further breakdown or if further info would be the articles themselves. That would probably depend on the intent of the author. Am I missing something? --Janiejac 09:27, 19 January 2010 (EST)
Janiejac, I really like your analogy to books! The example is valid - just as you would not consider listing a book's contents within the index or table of contents, you would not place article contents on category pages. You can list them (by placing a link to the category) to your heart's content... For those of us who are more visual, I have placed a rough outline of WR's current category structure at Categories_project.--Jennifer (JBS66) 10:02, 19 January 2010 (EST)
Thank you for posting that outline! Clicking on some of those links emphasizes the need for some reorganization or cleanup. There is a category:Family Pages that has only 3 articles in it! The is a category:Products that has only 2 subcategories in it: (1) is 'Books' which has a SOURCE in it and (2)is 'Software' which has one article. Oh, there's more, so lets move over to Categories_project to see what should be or can be done. --Janiejac 11:10, 19 January 2010 (EST)
I think we're emphasizing some organizational ideal over actual usability. Wikipedia, frankly, is not the ideal here. They have excessive numbers of categories that do not provide a useful browsing experience. So do we. Right now, we have a system in which 1) red category links means a category with just articles in it; and 2) blue category links means a category that humans have maintained and therefore might have some useful content worth clicking on. I would like to keep that distinction, although I know I'm going to lose. The reason is that I would like to encourage people to CLICK on categories and get something USEFUL out of it. I've done the following things to make these a useful experience, and all would apparently be jettisoned with no good replacement for no good reason under the 'all or nothing' theory.
  1. Putting information on famous or early ancestors in a place (say, Arnold in Rhode Island). I understand that this can be done through articles, but that's an unnecessary step that just hides the content.
  2. Adding Wikipedia templates for content so that other WP templates link to the category instead of WP (like this one. Doing this on an article page would completely defeat the purpose. It has to be a category to provide any usefulness over just going straight off to WP.
  3. Adding information about what the category is for. Like Category:Notable people. This can't be done any other way, and is an approach used by WP.
  4. Adding information about the people in the group in a more useful way than the 'alphabetized by Person' list that's generated automatically (the reason that the Great Migration ships add the template).
Even if I didn't think that it materially degraded the user experience to ban content on categories, I don't think it's a good use of our time to remove this useful content and prevent other people from doing it, and I'm going to be more than a little upset if my efforts are just deleted without more input than just the 2-3 people speaking in this discussion.--Amelia 10:28, 27 January 2010 (EST)
Amelia, I don't mean to speak for Janiejac, Jennifer or anyone else who has piped in on this topic, so I hope they correct me if I'm wrong. From what I've read, I don't think anyone is suggesting that you cannot put an explanation or definition of the category at the top of the category page, such as at the top of Category:U.S. Secretaries of State and Category:Notable people. What doesn't belong on the category page is a lengthy discourse on the category topic. Let's say there's a category for Mayflower passengers. The category page should define what the category includes and excludes, but shouldn't have a treatise on why they sailed, the hardships they endured, etc. That type of material would be better suited to be in a separate article, though you could link to that article from the Mayflower passenger category page. --Amy 10:50, 27 January 2010 (EST)
I did agree with you, which is why I didn't get excited the first time and agreed with a compromise version of Dallan's proposal -- short information at the top is fine, but long articles should go somewhere else. But then this discussion was described here as a proposal to ban manual editing of categories.--Amelia 11:07, 27 January 2010 (EST)
I took that discussion to be referring to the "(surname) in (place)" categories/articles, not to all categories. It appears we need some clarification as to the scope of that proposal. --Amy 11:47, 27 January 2010 (EST)
It is my understanding and belief that, just as Amy stated, a concise definition of the category's contents is appropriate. What I believe we are trying to prevent is anything that resembles an article, such as Category:Taylor surname. While this is great information, it does belong on a separate page. Dallan had another observation regarding extensive text on category pages at the project talk page. He said: "I was on the other side of the fence before (put the content directly on the category page), but after being reminded that it shows up every time you page forward or backward in a category (e.g., Category:Taylor surname), I agree it's better to put it on a separate surname-in-place Article, with an obvious link to the article at the top of the surname-in-place category page." --Jennifer (JBS66) 15:33, 27 January 2010 (EST)
To reference Wikipedia's description of What goes on a category page?: "Category pages exist to be a convenient cross-reference to related articles and other categories. A category page should contain a brief description of the purpose of the category. A prominent link to the most important article in the category is usually a good idea, but please avoid copying large quantities of text or images from an article to a category page." --Jennifer (JBS66) 16:42, 27 January 2010 (EST)

4. Most surname in place category pages have never been created, even though they contain links to pages. The Category:Smith in Minnesota page doesn't exist for example, so it doesn't show up as a subcategory in Category:Smith surname. Should I write a program to automatically create surname and surname in place category pages when they contain a link to a page, and to automatically assign the category pages to the appropriate "parent" categories (to address Janiejac's issue above)?

This would create quite a few more category pages. At one time I worried (and I still do) that doing something like this would have so many automatically-generated category pages that they would drown out the human-created category pages, which are likely to be much more interesting. But not having the links (e.g., a link to Category:Smith in Minnesota from the Category:Smith surname page) makes it seem like we don't have any Smith's in Minnesota, so this doesn't seem right.

I like it as it presently is, but I may be in the minority in trying to make every red link blue. But you may be right in dealing with a volume of unutilized article and category pages created automatically that overwhelms the manually created pages and categories. --BobC 13:12, 15 January 2010 (EST)
YES. If there is a page linked to it, the category page should be there to list that person as a member of the catgeory. Don't create empty pages, but yes on the ones with members. --Jrich 10:15, 17 January 2010 (EST)
Frankly, I'd prefer we didn't start turning category links blue when they have no content, but I've lost that battle with the "A Surnames" stuff. So go for it.--Amelia 19:15, 17 January 2010 (EST)
I vote NO. Leave the red links until the pages are manually edited by a user.--Beth 18:18, 27 January 2010 (EST)

5. What do we want to do about the "place" categories (see Category:Virginia, United States for example)? Do we want them at all? If we keep them I assume we'll want to automatically-generate category pages for place categories as well.

Keep the place categories - absolutely! However, our place categories are currently taking 2 different forms (ie Massachusetts, and Massachusetts, United States see Category:United_States). We need to stick with one, perhaps we should look to follow Wikipedia's lead on this?--Jennifer (JBS66) 12:57, 15 January 2010 (EST)
I think the Virginia page you cited above is a perfect example of why we should keep that category type (e.g. multiple subcategories -- most of them counties -- and almost three dozen articles and one image). I don't see any problem having county placename categories as subcategories to state category pages. It provides multi-level avenues for research and categorizes pages in a logical heirarchy. --BobC 13:12, 15 January 2010 (EST)
YES. Seemed redundant at first, but What Links Here on a Place page is too unfocused. Need some way to say that these pages are important to Virginia, though why Whyte Robert Rumgay's picture is in Category:Virginia or some of the other things are there is beyond me. The stuff that is there should be of use to almost everybody interested in Virginia, not because the linked item is simply in Virginia. Also, Virginia and Virginia, United States are the same thing, the one named plain Virginia should not exist. The names of these should follow the place hierarchies and Virginia, United States should be a subcategory of United States. People placing things in categories should use the smallest one possible (though this may cause problems regarding historical vs WeRelate place names - people may want categories that represent a place in a subset of time?) This needs some organization and some rules to avoid getting out of hand. --Jrich 10:15, 17 January 2010 (EST)
Yes, but as noted above, these should be human-edited to have content of interest to people interested in Virginia. Auto-generating anything is unlikely to go well.--Amelia 19:15, 17 January 2010 (EST)

5a. Do we want to make the "surname in place" categories subcategories of the corresponding "place" categories as well as subcategories of the surname categories?

Oooh. Nice idea. (That's a yes from me.) Jillaine 12:44, 15 January 2010 (EST)
Definitely yes. Will volume be a problem? --BobC 13:12, 15 January 2010 (EST)
YES if possible. Would suggest adding subcategory to the Place called Surnames, and linking surnames in place to that subcategory, not directly the main place category. --Jrich 10:15, 17 January 2010 (EST)
Yes. I like Jrich's suggestion, because volume will be a problem.--Amelia 19:15, 17 January 2010 (EST)

5b. Do we want to add Source, Person, and Family pages to "place" categories?

Please provide an example; having difficulty visualizing this. Jillaine 12:44, 15 January 2010 (EST)
I'm not sure what you mean. Aren't there other routes to make the connection and search for information between those pages? Or are you talking about categorizing family and person statistical events (such as birth, marriage, death) to places? In that case I might see a value. In Wikipedia, a person's birth or death date can be categorized under "1920 births," "2003 deaths," or "People from Seattle, Washington." --BobC 13:12, 15 January 2010 (EST)
NO. That can be done using What Links Here on a Place page. Place categories ought to be used because there is something that is pertinent to/symbolic of/important to that place, not because it is simply there. Somebody would go to a Virginia category to find important pages to view if one is interested in Virginia, like, I don't know, prominent people in history, emigrant families, important books, articles on Virgina history. A list of the millions of people who have ever lived in Virginia would not be useful unless each such category gets automatically created with a subcategory structure to make it easier to manage. --Jrich 10:15, 17 January 2010 (EST)
Only if you can limit it to towns and counties. It would be a mess for states and countries. And it seems if we add the surname in place categories as subcats of place categories that takes care of it. Don't do both.--Amelia 19:15, 17 January 2010 (EST)

6. I'm thinking I'll need to re-work how page links are listed in category pages. It seems like someday we'll want to be able to filter by namespace so that you can display just the Person pages for example. I'm wondering if we also want to display separate alphabetical links for each namespace, so that Person pages get filed under headings like "Person A" and "Person B", or maybe subheadings "A" and "B" under a larger "Person" heading, rather than the current approach of putting all people under "P".

Yes on filtering by namespace. And I think yes on the second part. Jillaine 12:44, 15 January 2010 (EST)
Yes, that filter or additional automated feature could help narrow searches done via category pages for users. That also raises the issue of how more expert users input and edit the category manually to force it into the right place on the category screen by adding the desired alpha character(s) after the category name. But by doing it manually though, some categorized links are alphabetized by user-provided information and most others are automated by page type and then by alpha/numeric designation. I appreciate the flexibility, but it may cause confusion to some. --BobC 23:40, 15 January 2010 (EST)
YES and YES --Jrich 10:15, 17 January 2010 (EST)
YES please. I notice {{Defaultsort}} isn't supported here, but perhaps autopopulating that could accomplish this? And have it be human-editable for special circumstances? Like right now the U.S. Presidents are in date order...--Amelia 19:15, 17 January 2010 (EST)

6a. Do we want to list the person's full name (and maybe birth & death year) instead of their page title in category listings?

Hallelujah! Hallelujah! h...h... hallay looo yuh! (I've wanted page titles to do this for a long time; since we can't have that, it would be MAHvelous to have it this way on the category pages. Jillaine 12:44, 15 January 2010 (EST)
For Person Pages, yes. Not sure about Family Pages. --BobC 13:12, 15 January 2010 (EST)
YES and possibly in more contexts than just Category lists (instead of displaying page title)? --Jrich 10:15, 17 January 2010 (EST)
Yes this would be much more useful --Judy (jlanoux) 11:55, 17 January 2010 (EST)
To quote Jillaine, Hallelujah!--Amelia 19:15, 17 January 2010 (EST)

6b. Do we want to sort person/family pages by surname, then by givenname, then by birth year, then by death year in category listings?

Sure. Will this slow display down too much though? Jillaine 12:44, 15 January 2010 (EST)
On family pages, will that mean there be a separate category sort for both husband and wife? --BobC 13:12, 15 January 2010 (EST)
YES. --Jrich 10:15, 17 January 2010 (EST)
Yes --Judy (jlanoux) 11:55, 17 January 2010 (EST)
Yes. Are you going to have birth and death years for family pages? It seems like marriage date would make more sense.--Amelia 19:15, 17 January 2010 (EST)

--Dallan 00:07, 15 January 2010 (EST)

I'm overwhelmed! Too many suggestions for change at once :-) Can we take this project in smaller steps? Perhaps we could begin with creating a Categories project page. It would allow a centralized place for dicussion, and users could sign up to help create/maintain the category structure. We could then rename just the surname category pages automatically and assign those to the parent Surnames category.

On another note, it appears that image pages that contain surnames with spaces are categorized differently than person/family pages. One example is Image:1753-10-14 Trouw Egidius van Euwick x Elisabetha van Hedel.jpg. The surnames on the image are categorized under both van Hedel and simply Hedel.--Jennifer (JBS66) 12:59, 15 January 2010 (EST)

I agree with Jennifer - when I'm already confused on this subject, all this detail is very overwhelming. I also like very much her comment: "I feel that we should not be placing extensive text on category pages. Categories are intended as a finding aid, not an article." I find articles in categories, even in subcategories. So can we break it down into smaller bites and come up with short definitions of each type of page and whether the pages are automatically generated or user generated? --Janiejac 13:13, 15 January 2010 (EST)
Ok, I created a WeRelate:Categories project page. I just need a bit of help here... how much of this conversation do we move over?--Jennifer (JBS66) 13:44, 15 January 2010 (EST)

I've been thinking about a couple of points regarding this categorization discussion.

  1. Janiejac has brought up a nice point on the Categories project page. Along these same lines, I noticed a number of new surname-in-place category pages that were created last night. These pages link only to the surname in place category and to neither the surname or place they are representing. I suggest that we develop a standard template for our surname-in-place categories, link them to the appropriate surname page, and possibly eliminate the Category:Surname in place altogether.
  2. I have concerns about Dallan automatically creating our surname and surname-in-place category pages. Yes, it would be nice to have this repetitive task handled automatically. However, I think the WR community would benefit from undertaking this project ourselves. It would help us to strengthen our sense of community and develop a stronger knowledge of the workings of this site. Instead of automatically creating incorrect pages like Category:? surname of Category:Moore in NY, we would learn to be cleaning up our messes and properly maintaining the site. There is a daily generated list of wanted categories. Going through this should be a part of regular site maintenance.
  3. In a previous discussion on multi-part surnames, Dallan suggested putting 'dit' names (alternate names common in Quebec) in the surname field. This translates into possible category pages such as Category:Destroismaisons Dit Picard surname. I suggest creating another option in the alternate name pull-down for dit names instead. Then each name would go on a separate line, and two independent categories would be linked.
  4. I am wondering about our automatically generated categories. These are hidden on our pages, and I wonder if that takes away from people learning how categories work. One idea might be to still automatically generate the category, but place the actual [[Category:title]] text within the text box.
  5. In addition to surname-in-place and shared research categories, we also have a Category:Family Exchange and Help:Family Exchange Pages. This seems like another case of overlap that needs to be sorted out.--Jennifer (JBS66) 08:43, 17 January 2010 (EST)
[add comment] [edit topic]

Surname pages and links to person and family pages [17 January 2010]

Are person and family pages supposed to be linked to the applicable surname page? If so person and family pages are not presently linked properly. I checked the Coker surname page and only one person page is linked. I checked the Gay surname page and no person pages are linked. --Beth 21:43, 14 January 2010 (EST)

I see quite a few Coker's listed.--Dallan 00:12, 15 January 2010 (EST)
Yes, under category surname they are listed. Are the person and family pages linked to the category surname page and not to the surname page?--Beth 11:32, 15 January 2010 (EST)
Beth, this is too easy. Please check your User Page. If you notice in the names you are researching on the far left side, all of the names were input by you as surnames you were/are researching. All of the Coker names/links were red because you hadn't linked to the articles they automatically created when you entered the surnname data; the McGuire and McCullough names are in blue because the articles they automatically created you must have changed in some way at some time. To illustrate this, I clicked on the three Coker surnames in Texas, Oklahoma and California. When each article opened all I had to do was edit and save, and this action automatically linked those article pages to your Coker surname page (as can be seen on page 2). I'll let you do the rest of the Coker Surname in Place pages. After you do so I think you'll agree: it's too easy. Right? --BobC 21:02, 15 January 2010 (EST)

Beth is raising a related issue for me. I think we've discussed it elsewhere, but I no longer recall. WHY do we even *have* Surname article pages? They are not linked to from person pages-- those go to the relevant surname *category* page; the bulk of them only list alternative spellings; and they are only linked to from articles when one fills out the Surname field in an article. Wouldn't it be better to have all those alternate spellings as narrative in the upper part of the Category page for said surname and get rid of Surname pages altogether? Jillaine 12:52, 15 January 2010 (EST)

I think we need to look at the purpose of both page types: the Surname Page identifies related (or unrelated) surnames (each having their own surname page and category page) under different spellings. They can be used as an article page (or as a research guide for that name) letting users and contributors add information about that surname; and as indicated by the Surname Portal it can be utilized as a one-name study regardless of known or proven family or ancestral connection. The associated category page is intended as a finding aid within the WeRelate community; while it too can be manually enhanced to include user-contributed data, it's purpose is primarily to group pages of similar content at WeRelate. I see good uses for both and good reasons for keeping both. --BobC 13:59, 15 January 2010 (EST)
The alternate spellings on the pages within the Surname and Givenname namespaces (such as Surname:Smith or Givenname:Jennifer) work along with the search function to return close matches. There are more details at Help:Name pages--Jennifer (JBS66) 14:12, 15 January 2010 (EST)

Bob, your explanation is clear and I do understand the difference in the surname pages and surname category pages. However; I am concerned about the complexity of this site. As I recall, one of the reasons we decided to eliminate the surname in place pages were because the red links that were automatically generated on the user profile page were confusing to users. Users do not know what they are for and do not understand the difference between the surname page and the surname in place pages and/or categories. How many users actually check the categories? What about the categories that the user has to manually enter on the related page to have the page even show up in the list of categories. Somehow we need to simplify this process. I am sure that some users simply give up from exhaustion. I am not recommending that we eliminate the surname in place pages but somehow we need to make it easier for users to differentiate between surname and surname in place pages and the corresponding categories. I believe that most new users would intuitively look for links to people on the surname page and not on the category page . --Beth 19:33, 15 January 2010 (EST)

Hi again, Beth. I'm sure based on your experience level you do understand the difference. I was actually addressing the issue that Jillaine raised in her comment above, and secondarily to other people who may not understand the primary purpose of both page types. Since I only joined WeRelate last year I may not have read the discussion you are referring to about replacing the Surname in Place pages, but I believe the discussion about the subject above clearly indicates concensus otherwise at this point in time. I respectfully disagree with your viewpoint that we need to "dumb down" WeRelate; I think instead we need to educate. --BobC 21:15, 15 January 2010 (EST)
Bob, just in case you overlooked this in my last entry, I stated that I was not recommending the elimination of surname in place pages. I also do not consider simplification to be synonymous with "dumb down". That would depend on the method of simplification implemented. --Beth 09:03, 16 January 2010 (EST)
Actually I didn't overlook it, I disregarded it because it contradicted your previous observation, and I quote, "One of the reasons we decided to eliminate the surname in place pages were because the red links that were automatically generated on the user profile page were confusing to users." You also wrote on the Category talk:Surname in place, "This page needs to be renamed. --Beth 14:50, 22 February 2008 (EST)." I just wanted to correct the record. Hopefully Dallan's response to this question has put this issue to rest and we can now proceed with (or revert back to) the more popular and conceptually accurate Surname in Place usage. Thanks for bringing this issue up for discussion. --BobC 11:34, 16 January 2010 (EST)
By all means proceed with the more popular surname in place usage. Obviously my message was unclear to you, sorry sometimes I have problems selecting the correct words to clarify my meaning. In Feb 2008, I had been an active user of WeRelate for approximately 3 or 4 months, and I did recommend renaming the surname in place pages. That is precisely why I stated in this discussion that I was not recommending the elimination of the surname in places. I changed my mind after reading the support that all of you exhibited for the pages to remain. Trying to to make the record clear.--Beth 09:39, 17 January 2010 (EST)
Bob, if we can't make it simpler to use, folks aren't going to hang around long enough to get educated! If folks stay long enough and struggle through enough to get educated, that is a plus, but it is not the purpose of this site. WeRelate needs eyes on the site for the ad income; if it is easy enough to use, folks will stay and maybe learn from more experienced folks along the way. Someone told me one time, you fish with what the fish like, not with what you like. Our potential users don't want to struggle with complexity. How many have already dropped out??
But it will surely help if we can come up with a clearer definition of pages and then put that in the TOC of help. I like Jennifer's definition of categories as finding aids. My understanding of articles is that they are for discussions, historical or genealogical. But after being here a year, I'm just now figuring this out. I still am unsure when categories are automatically assigned and when they are user generated. --Janiejac 10:09, 16 January 2010 (EST)
Like any program or application, WeRelate has a learning curve. I don't believe it is WeRelate itself that is so difficult to use for most people, it is the wiki framework. When you and I joined WeRelate we didn't know everything about it in a week, we learned the ropes, through Watercooler discussions, through perusing old archived posts, through adding our own GEDCOM data, through editing our FTE file, through becoming involved in Portal additions, and through contributing project work of various sorts. I'm still learning new things and capabilities of WeRelate. The free form of WeRelate is what draws me here. If I wanted the predefined structure of an inflexible template with no ability to make choices or no ability to modify the appearance of my data I would have stuck with Ancestry.com.
I agree with you about coming up with clearer definitions and usages of pages; that is explanation and education, and helps foster consistency. Implementing the WeRelate talk:Support page is a helpful way to answer basic utilization questions; multiple video and text tutorials giver new users a place to learn the basics; multiple help content pages such as Help:Contents are educational tools useful for new users or experienced users branching into new areas. Can we come up with more helpful recommendations for Dallan to simplify the use of WeRelate? Sure we can, and I'm sure he welcomes any and all ideas.
But to go back to some of the areas that are causing people concern, such as red links on a page, just because they don't know what to do with them, should Dallan entertain a motion to eleiminate them? Those red links are there as automated hints for possible expansion of information. People don't have to use them, but they can if they want to. They are an avenue for recording further research. Just because someone is confused about the difference between an article and a category under the same topic heading, do we eliminate one of them so they don't have to make a choice? My thought is we define the overall scope of each and let them use them the way that best suits their needs and abilities.
But this whole discussion of Shared Research Pages vs. Surname in Place articles, Categories vs. Article, and links between Surname Pages and associated Person and Family Pages, are not coming from new users; they are coming from experienced users, saying it would confuse new users. Possibly. So Dallan took the time to put out a series of questions, and to this point only two others besides myself responded to his specific questions. 'Nuff said.
BTW, Janie, I appreciate your fine work with Surname in Place articles, such as on the Jackson line. Now just hit those Surname in Place red links on your user page and the world will be a better place. :) Take care. --BobC 12:13, 16 January 2010 (EST)
Oh! I just learned how easy it is to 'fix' all those red links. I've been leaving them red because I thought I had to add some text to that page. Not so - just click edit and save! Duh! Maybe some more precise automatic wording across the top of the red pages would instruct wiki-challenged folks like me. --Janiejac 04:23, 17 January 2010 (EST)
[add comment] [edit topic]

Mc and Mac and O' surnames [25 January 2010]

In going through the web page Source pages that are family trees (and that have not been linked to by a Person page), I have been adding the web pages themselves as resources on the relevant surname pages (along with a brief descriptive paragraph) before eliminating the not-useful (too narrowly focused, not an actual source) Source page. I note that there are no auto generated surnames that begin with Mc and Mac (or ones that begin with O'). For obvious reasons, these type of surnames could quickly become overwhelming. But there is no explanation that I can find, nor instructions that one should not add Mc or Mac surnames. Can someone give me the background on these surnames? Is there a policy to index them under the name that comes after the prefix? How should one be redirected to the "correct" location to research these names? If there are guidelines I should be following, let me know! I'll go back and fix any errors I may have created inadvertantly...

Thanks,--Brenda (kennebec1) 09:24, 11 January 2010 (EST)

Hi Brenda, you may want to do a little further searching on those Mc and Mac names -- you may find some of them contain a space between the Mc/Mac and the root name, such as "MacNeil" is shown as "Mac Neil" whereas the name "McClure" is categorized as "McClure." Good luck. --BobC 09:42, 11 January 2010 (EST)
Brenda, you also can't generalize about the use of either "Mac" or "O'" names. As an example, "MacIntosh," "McIntosh," "M'Intosh," and "Mac Intosh" (with a space) are all exactly the same name and the variations often appear all in the same nuclear family -- even in letters or documents written by the same individual. Different 19th century publishers in the UK also had different rules when rendering the name in print. (All this history is also why library catalogs file them all together, and why "Mac" names are alphabetized as a separate "letter" before names beginning with "M.") But note that "Intosh" is not going to appear as a surname, so "Mc" cannot be considered a prefix; it's just part of the name. That's the Scots.
The Irish are different. "Mac" names in Ireland usually have Scots origins. (But not always. "McCarthy" is ancient in Ireland.) Names beginning with "O'" are Erse (as opposed to Gaelic) and often lose the prefix with no problem. Hence, in my family, "O'Cronin" of several centuries ago became just "Cronin" by the time the family began emigrating in the 1820s. Some names, like "Sullivan," are never seen with the "O'" prefix, unless someone is being humorously hyper-Irish. So, yes, with Irish surnames you can consider it a prefix. Probably there should be a redirect from "O'Cronin" to "Cronin," or vice versa, just to keep the variations together.
We'll go have coffee sometime and I'll bend your ear about the Welsh and their insane attitude toward surnames, or the lack of them. Onomastics can drive you to drink! --Mike 20:18, 11 January 2010 (EST)
Hi Brenda. The autogenerated names were taken from some English name book. There aren't any auto pages for a lot of names. That doesn't mean they aren't valid, just that you have to create them yourself. Use the surname pages to indicate equivalent spellings so that searches will find pages using any of the varients. As for what is "correct" there's really no such thing. A person's name is whatever he says it is or whatever other people call him. We in these days of birth certificates, driver's licenses tend to overemphasize what is "correct". Even today many people change their names on their journey through life. Also note that many of the equivalents on the surname pages are just plain wrong. What a computer thinks is a similar spelling (which again uses only English rules) doesn't make it the same name. We need to clean these up as we go. --Judy (jlanoux) 21:23, 11 January 2010 (EST)

Thanks everyone for the input. I'm glad to know I wasn't breaking some unknown-to-me rule by adding these surnames... And I have to say, I really look forward to meeting many of you one day. You all are a wealth of specialized and fascinating knowledge, even if what you "know" sometimes contradicts what others here "know"... I will proceed accordingly, (very slowly) working through the web page sources to add them to surname pages if applicable.

By the way, would any of you onomastics experts (I had to look that up...) care to speculate as to origin of the surname Remeschatis/Remeschatus? It's my family's particular surname brick wall (immigrated from Bremen 1871, immigrant born in Neustralitz, and found in one presumed ancestor of immigrant in Neustralitz in the late 1700s... but otherwise apparently now almost extinct except for the remnents of the U.S. immigrants). --Brenda (kennebec1) 12:25, 13 January 2010 (EST)

Brenda, here is an article from U.S. News & World Report about a lady named Linda Remeschatis. Perhaps you could contact her for more information about her ancestry to see if there might be a connection or to see if she knows the origins of her (or her husband's) surname. It seems to be an unusually rare name. Good luck in your search. --BobC 10:51, 19 January 2010 (EST)
I believe (no promises) that schatis/schatus is an earlier common spelling for the German schatz, which means "heart." And schatus probably has a Latin root. I can't make a guess about the origin of the "reme" part, but I suspect the name might have some relation to Roman Catholic history or liturgy. --Mike 16:24, 23 January 2010 (EST)

My guess for the surname Remeschatis (since I can't a proper reference either), is a latinized version of the town Remscheid. By the way, I can find no references to schatz=heart. The German word Schatz means a valuable thing, ie. treasure, darling, money hoard, etc. --Bgwiehle 12:43, 25 January 2010 (EST)

[add comment] [edit topic]

Help Beth in organization [12 January 2010]

I am starting this topic on my user talk page if anyone is interested. First step is deleting and/or reorganizing email messages. I need encouragement and input. If there is a better place for this discussion please advise. I am on Facebook and Twitter. --Beth 20:21, 12 January 2010 (EST)

[add comment] [edit topic]

Please vote [23 January 2010]

Just in case you didn't see it on the homepage: Please cast your vote for the new feature you most want to see added to WeRelate by signing your name next to the feature in the ToDo list. This will help me focus on which features (on a rather large ToDo list) to work on next. Thanks!--Dallan 11:00, 23 January 2010 (EST)

[add comment] [edit topic]

Dit names and German names [4 March 2010]

Recently there have been a couple of comments about dit names and the German practice of using very-common names for the first given name and people going by their middle name as their "primary" name. I'm looking for advice. Should the system have new "alternate name" types for dit names and german common names? If so, what should the types be called? "Dit name" and "Baptismal name"?--Dallan 09:44, 25 January 2010 (EST)

There is already "baptismal name" in the drop down for alternate names; however, I'd rather see that when a GEDCOM is uploaded, the system takes what's in the first name field, adds it to what's in the surname field and creates a page title with the results, so that Maria Magdalena Dressel becomes Person:Maria Magdalena Dressel (#) instead of Person:Maria Dressel (#). (Hyphenating 50-75% of 10,000 names in my GEDCOM is not an option.) Jillaine 10:35, 25 January 2010 (EST)
It's not a German thing, I think it's a continental thing to use double names with the first name being a common one: John, Mary, Joseph...

I've adopted the practice of using the "real" name as the preferred and using baptismal name for the double name. It avoids having twenty pages with the same name. I think if we start making exceptions to the page name rules just for the Germans, it's not going to end there. Everyone is going to want exceptions and you will have pages names with the same junky stuff we get in the name field. That's already a disaster. We need to keep promoting the idea that page names are irrevelant indexes for the system and not "content" and that the primary name field is the important one. Also the places where search is still using page name need to be fixed. The concern that "someone will merge them" won't go away by changing page titles. I can't agree that it is a reason to change the rules. While using names as index was problematical, I think we're stuck with it and need to keep the rule as is. I speak from experience that uploading a non-trivial gedcom requires a LOT of editing. I'm beginning to believe that no time is saved overall.

When baptism names were added to the type, "birth name" went away. That is unfortunate because we really need both choices. Not every family had their children baptised - not all religions baptize infants. Dit names are an especial problem because there is no consistency in their usage. The most usual case I enter as a title suffix as it is usually listed as an alternative to the surname from the days when names were a lot more slippery than they are today. e.g. Jean Caissey dit Roger. Half of the children used Roger as a surname and half Caissey. I don't feel that we need an extra type for dit names. Alt handles that issue as well as many others. But I do think we need Birth and Baptism types because they indicate that the primary name is not the person's "official" or "legal" name.--Judy (jlanoux) 11:41, 25 January 2010 (EST)
When the dit name is entered in the suffix field, it is not found in searches for that possible surname. So if we put Jean (Given) Caissey (Surname) and Roger (Suffix), searches for Jean Roger don't find him. Then, at one point, Dallan had suggested putting Caissey dit Roger in the Surname field. This now poses problems for the automatic surname in place categories. I agree, perhaps just a policy that dit names are entered as an alternate name will suffice. However, having dit as a drop-down option is a nice reminder. --Jennifer (JBS66) 11:47, 25 January 2010 (EST)

To me it is not a continental thing at all as I go by my middle name with first initial L. I find it extremely annoying that people can't understand that. No one seems to remember such folks as F. Scott Fitzgerald, W. Clement Stone, H. Ross Perot and many more. I recently had some government paperwork returned for lack of a "legitimate" name, whatever that means. Invariably, if I enter my full name, Scot will become middle initial S, Arghh. On the other hand I do know a Portuuese family with six daughters, all of whom are named Maria. One goes by Maria and the other 5 by their middle names.--Scot 12:17, 25 January 2010 (EST)

Okay, if the page TITLE is not to be thought of as important as the NAME, then the user interface/display should be changed. Because right now, the *Page* Title is the most prominent thing one sees on the page. So when I see "Maria Dressel (29)" shouting at me from the top of the page, I go a bit nuts because she's really "Maria Magdalena Dressel" and I really don't want to SEE "Maria Dressel" so prominently. It would be far far far better to have the following be the dominantly displayed text on a given page:

etc.

Then relegate the PAGE TITLE display to some smaller, out-of-the-way, but still visible space (for purposes of cut-and-paste). This way, you still have unique page titles, but their often horrendous names do not dominate the page space.

-- Jillaine 12:45, 25 January 2010 (EST)

I agree, I agree. The Name/title area are too obscure. It took me several weeks to realize the name field was there. Maybe I'm unobservant, but it was very disconcerting that the edit view is so different from the display.  :-) --Judy (jlanoux) 13:42, 25 January 2010 (EST)

I'm finally back working on WeRelate after spending the majority of my time for the past few months doing a consulting project for FamilySearch.

--Dallan 14:00, 3 March 2010 (EST)

I'm not at all sure if this is possible here, but in light of recent conversations about "preferred" and "primary" names, I thought I would ask. It appears to me that we often debate about which is a "preferred" name for a person, which spelling should appear as the page title, etc... Doesn't every record in the database have a unique identifying number? Why can't that number be used for the URL? This could eliminate the need to even worry about the page title equaling the URL. Then, each variation of the name could be listed equally. Another wiki genealogy sites employs this number-in-URL technique (Rodovid).

I've thought about that, but here's the issue: one place where you can't use the preferred name is when you link to the page. Now most people don't manually link to pages, but a few do. Would you rather link to [[Person:4832745]] or [[Person:Name-as-it-appears-on-page-title]]. I keep coming back to name-as-it-appears-on-page-title is preferred, although I'm starting to wonder if name-as-it-appears-on-page-title should be the full name, not the first given name. This causes other problems (needing to rename a page when you discover a middle name for someone), but maybe the benefits outweigh the problems.--Dallan 11:11, 4 March 2010 (EST)
Looking at your idea of full-name page title: I have an ancestor, Piebe Lieuwes. In 1811 he chooses the surname Swart, so I rename the page to Piebe Lieuwes Swart. Then I discover that he most often spelled Piebe, Pijbe, so I need to rename the page again as Pijbe Lieuwes Swart. With scenario #1, having the URL be a constant http://www.werelate.org/wiki/Person:4832745, there may be some advantages. I could include the various spellings of his name in the correct form fields and never have to worry about the URL, and never have to rename the page. I, personally, think that one of the most confusing aspects to WeRelate is having to worry about the URL and choosing a "preferred" name and "preferred" spelling. Sure, linking to people and families would require [[Person:4832745]] instead of [[Person:Pijbe Lieuwes Swart]], but do the advantages outweigh that relatively minor disadvantage? --Jennifer (JBS66) 12:03, 4 March 2010 (EST)
I agree with Jennifer. Having names as page ids is a problem and very confusing for most people. Children of a family often get different spellings because different people added them. Then someone decides to rename everyone, etc. etc. etc. When I do manual links, I have to copy and paste because I am never sure of the exact page title. Numbers would be cleaner and wouldn't confuse people with the page title and primary name. (If they survive the transition.)--Judy (jlanoux) 19:00, 4 March 2010 (EST)

Regarding birth names, in my work on Dutch genealogy, the birth name is not always the name that I want as primary, those born prior to 1811 did not have surnames. For these people, I consider their name after they chose a surname in 1811 as their primary name. I think that saying the birth name will always go into the primary name field may be a bit restrictive. --Jennifer (JBS66) 14:36, 3 March 2010 (EST)

Interesting. I wouldn't have expected that. I'll start this as another topic.--Dallan 21:31, 4 March 2010 (EST)

Oh please don't take away Birth Name as a type. Many people are not known by their formal birth name and therefore we don't like to have to use birth name as primary every single time. Also we need Baptismal Name as a separate type because what the priest wrote in his book ofter wasn't what the parents "named" their child. --Judy (jlanoux) 16:52, 3 March 2010 (EST)

Ok, I'll add back birth name as a type. Thank-you for letting me know.--Dallan 11:11, 4 March 2010 (EST)
[add comment] [edit topic]

Need Source Merge [28 January 2010]

Here are two Sources I believe are duplicates. I don't want to try to merge them but I think it should be done.

Source:King, G. H. S. Register of Saint Paul's Parish 1715-1798 : Stafford, County, Virginia 1715-1776, King George County, Virginia 1777-1798

And: Source:King, George Harrison Sanford. Register of St. Paul's Parish 1715-1798

This second source has a talk page attached. Once the source pages are merged the talk page may not be relevant. OK with me to delete my part. --Janiejac 19:51, 26 January 2010 (EST)

I did the merge of the duplicate sources; I left a message on the talk page asking if the PAGE should be renamed to the full title (which could be a problem since I've now deleted the duplicate page that used to have the full title??). For now, tho, there is just one source page with all the repositories combined.--Brenda (kennebec1) 11:56, 28 January 2010 (EST)
[add comment] [edit topic]

United Kingdom Crown Copyright Waiver [3 March 2010]

I have many United Kingdom Birth, Marriage and Death Certificates which I would like to upload as images but which are technically subject to Crown copyright. I have recently discovered that subject to certain conditions, see below, this copyright has been waivered. Can we add a new license type to the image upload page as it is rather tedious having to select other and entering the details in the text box.

Guidance - Copying of Birth, Death, Marriage and Civil Partnership Certificates Date: 27 October 1999 (Revised April 2009)

Introduction

This guidance note sets out the arrangements for the reproduction of official birth, death, marriage and civil partnership certificates (’extracts’ in Scotland). Copyright in the layout of certificates is owned by the Crown. The Crown does not assert any rights of ownership in the contents of the forms.

Reproduction

You are authorised to reproduce the layout of the form in any format including on the web, in films and in print. This authorisation is subject to the following conditions:

--Btomp 11:26, 10 February 2010 (EST)

My view is that each image should be a stand-alone document (or image) rather than a group of documents and should have all pertinent copyright information listed for each image. Users will typically look at images or documents as separate files rather than a group sharing a similar origin or copyright and all pertinent copyright information should be listed, identified, and clearly shown on each file-space. Perhaps you might want to {{template}} the above statement and put on each document image, which to the average user would be indistinguishable from the whole copyright included as part of each file. Perhaps some of the WR Admins would have their own recommendations. --BobC 23:24, 10 February 2010 (EST)

I could add Template:CCW2009 to the MediaWiki:Licenses list of image licenses, but in an effort to keep the list of licenses displayed from growing too long, I think that selecting Other and adding {{CCS2009}} to the text of the page is the better approach.--Dallan 14:00, 3 March 2010 (EST)

[add comment] [edit topic]

Zorched GEDCOM-Merged pages? [3 March 2010]

Hi there... I am now trying the impossible task of merging my sister's MyFamily GEDCOM with my WERELATE GEDCOM in an external program... I downloaded the GEDCOM here and loaded it into the desktop program... and noticed about 2,000 people are missing (!)... I came back here and it looks like (This is my theory at first blush) when trees are merged, they are un-treed... thus (Since I've been a little merge happy), most of my lines past a certain point need to be re-added to my tree... The problem is that you have to click on the individual, click add tree... etc. This could -literally- take days of clicking to restore my tree for GEDCOM retrieval-Especially since I know with merges that there are more than 2,000 related folks that are in the Pando here...

Is there any way to "Autofill" an Add to Tree? Add anybody linked to your tree into your tree? Maybe just ancestors (As opposed to linking EVERYONE in the database)... Maybe this function already exists and I don't know it?

Just wondering... I am trying to find the best way to do this (And get one clean tree out of all of our myriad different trees) without having to repair each and every record...

Aabh 01:19, 13 February 2010 (EST)

You have other options when you click Trees. You can add ancestors of a person (and their children) or descendants. So if you can pick a few key people at the top or bottom you can do most of it in one click. You can check for people missed from the Trees link on MyRelate. It has an option Related pages not in Tree. You can filter this for Person pages and see if you missed anybody. --Judy (jlanoux) 11:32, 13 February 2010 (EST)
Judy has a good suggestion, but merges shouldn't have caused someone to be removed from your tree -- after the merge you should be watching the merged page. I'll double-check this to make sure, but I'd appreciate you giving me an example of someone in a gedcom that you uploaded who is not in your tree.--Dallan 14:00, 3 March 2010 (EST)
[add comment] [edit topic]

compiler to researcher [24 February 2010]

A year or more ago someone posted an interesting piece outlining the path from a family historian to compiler to researcher. Does anyone know where I could find that again? I think it was on a user page but I'm not even sure about that. (I wish I had kept a copy!)--Janiejac 16:40, 24 February 2010 (EST)

[add comment] [edit topic]

Page titles for Person/Family pages [6 March 2010]

A couple of people have suggested that having ids (numbers) would be better than names for Person and Family page titles. So Person:1235432 or Family:345234. Nothing is going to happen right away, but I'd like to talk about it. Replacing names with numbers affects the following areas:

So changing the Person/Family page titles would require some programming work, but maybe it would be worth it in the long term. Note that it goes contrary to Familypedia, which includes not only full names but also birth/death years. What do others think?--Dallan 22:01, 4 March 2010 (EST)


I don't understand the purpose of this (even having read the request above). I understand that names change, but you're talking about altering the entire architecture for a tiny minority, back-programming the rest of the system to have it behave the way it already does now, and adding the additional difficulty of forcing us to use 8-10 digits for page names instead of actual words that human beings are familiar with. What a gigantic waste of precious engineering efforts. Right now, if a page name changes, it gets a redirect. Big deal. No links break. There's a learning curve to figuring out what name to use, but it's almost always not an issue, and it's predictable without looking up every single page. (Not to mention the pre-medieval WP page title rule, which ensures consistency in older pages.) Typos with numbers will be far more common, and far harder to fix--impossible if it's not your own mistake, probably, whereas pretty much anyone can tell that Paul Smitth is probably Paul Smith. In sum, I see no advantage whatsoever, and enormous disadvantages in disruption, wasted effort, and confusion.
Now if you're going to propose having categories, watch lists and other auto-generated page lists show better titles with full names, then I'm all for it. But if I only get that in favor of having to keep track of numbers instead of names, I'd really rather not.--Amelia 23:11, 4 March 2010 (EST)
I agree with Amelia for the most part. I don't see the big gain (i.e. value added) for doing this. Yes, every person would have a unique number assignment, but that would not be a searchable useable feature like the current namespace is now. I think it might cause more headaches for many, especially novices, who would view it as a useless and quite possibly confusing feature. While some genealogy programs used/use the unique reference number for identifying people in its database, it is transparent to most users, but upon GEDCOM download sometime caused problems, such as when downloaded sometimes conflicted with other program's assigned reference numbers when imported. An example I can cite was PAF into EFT (from the early 1990s); when later transferred to FO created two extra unique reference numbers for every original person from the old programs (that showed up on every report asking for data fields) that I spent years trying to get rid of. It was more of a nuisance for me than a benefit.
Personally, I think there are many other greater needs on your "To-Do" list. (Just my opinion.) --BobC 09:10, 5 March 2010 (EST)

I think there are definite benefits to considering using unique reference numbers. To be clear, this number would appear in the URL, like this: http://www.werelate.org/wiki/Person:123456. Searches would remain the same, because that would use the form fields (like full name and birth date). Why did I originally bring up the question? Well, there have been conversations such as German names and how they might import and using birth name vs. primary name. There have been disagreements between users that wanted one type of spelling to be "primary" over another. There are naming rules that are complicated for new users to grasp, such as this one. This really is a usability issue, and I appreciate Dallan considering its implications. When a new person/family is created, users could input all of the data for their ancestor's name, including middle names, alternate spellings, etc. They would not have to consider, which spelling should I list as primary, Boudrot or Boudreau? They would not have to edit or rename pages because their baptismal name of Marie or Joseph was considered primary, instead of their more common name. We wouldn't have users become confused over the use of index numbers following names. I can see where seasoned WR users have become accustomed to the system... but the complaints and confusions are out there! --Jennifer (JBS66) 09:42, 5 March 2010 (EST)

Jennifer, you bring up an interesting point in citing the use and appearance of foreign names as would be recorded in the URL title. An example would be one German ancestral line I research, the Schönauer name which page is identified by URL as <http://www.werelate.org/wiki/Surname:Sch%C3%B6nauer>, which I agree is awkward. But if the URL became <http://www.werelate.org/wiki/Surname:S12345> how would that benefit me or users searching for information on my Schönauer ancestry. Yes, "S12345" may be visually more appealing and easier to type than "Sch%C3%B6nauer," but does it make it any more effective as an identifying feature, address or search element?
Furthermore, I think your line of reasoning between deciding which name (birth, baptismal, stagename, etc.) is primary is not totally applicable or justifiable to make such a programming change, because even with number identifiers in place, it is a decision which will still have to be made regardless of how individuals and families are identified in the database. You certainly cannot list all names throughout all documents, pages, and reports and have it remain a user-friendly application. And then throwing ID numbers into the mix would make it even more intimidating.
Please let me know if I missed or don't grasp your point succinctly. --BobC 10:58, 5 March 2010 (EST)

As Dallan's notes indicate, he would still need to export a readable name to family pages and search results, and therefore this process would still be singling out one version of the name over the others. So I am not sure this is worth it. If this had been done from the beginning, I think it might have resulted in some simplification, since I suspect most genealogy software uses a unique number internally to keep individual records having the same name separate. So I agree that it might present less of a learning curve than the current system. Also, in my opinion, this would be a good way to title source pages.

Perhaps Dallan could comment on whether this change could somehow simplify the ability to use GEDCOMs to iteratively download/upload information, this being a feature some people (not me) have requested. It seems like this naming method might make it possible to establish a more stable link between the person in one's personal database and the page on WeRelate, and enable repeated information transfer?

There are techniques for making the number easier to work with, most obviously chunking, like a license plates or old style phone numbers, where the first three or four characters are letters, followed by a smaller number, etc. --Jrich 10:03, 5 March 2010 (EST)

Taking this one step further, would be also have to change our User Names to User Numbers? Frankly, I prefer User:Delijim to User:12321......  :) I guess Dallan and SQ would be User:0001 and User:0002....

Seriously though, if we come up with some "numbering system" to help identify persons and/or families on WeRelate, it should (in my opinion) operate "behind the scenes" and not replace the normal naming convention that has already been established....

Just my $.02. :)--Delijim 19:54, 5 March 2010 (EST)

[add comment] [edit topic]

NGS conference, Salt Lake City [9 March 2010]

Hello, I'm curious if WeRelate is going to be at the Salt Lake City conference at the end of April this year? Also, is there anywhere on this site to discuss such things? I didn't see a portal. Perhaps that is too much of a social web 2.0 type thing : ) which is fine, I'm not asking for such a place, just curious if it's out there and I don't see it : ) Is there a better place to post such a question? This is only my second national conference, and my first time at Salt Lake, so I'm a bit excited about the whole thing... the mother ship and all... : )

thanks, Amelia J. (88buckaroo)--88buckaroo 14:55, 9 March 2010 (EST)

[add comment] [edit topic]

Givenname/Surname Pages [11 March 2010]

There was talk of re-working the way Givenname and Surname pages work so you only have to maintain one list. Wonder if that is still somewhere on the list? I just added Givenname pages for various spellings of Eleazar (the wikipedia spelling), including Eleazer, Eliezer, Eliazer, Eliezar, Eliazar. At the time I had found actual cases of records using five of the spellings. I added the sixth merely for completeness since I'm sure a search of colonial records could find an example of it being used somewhere, and that means somebody sometime is bound to create a page using it. Six essentially identical pages created. If you want to another spelling variation, you would need to update all six, as I understand the way it works, plus adding the seventh page. Sure would be nice if you could just maintain a list in one place. Can redirects be used here, so you can create one page and then simply redirect all the alternate spellings to the one main page? --Jrich 13:17, 11 March 2010 (EST)

Redirects may not be appropriate, because if the family surname is Eliezer, then the suname for that family is not Eleazar and shouldn't be redirected there. Why not do that in the category namespace? All surname pages are categorized to their surname categories. The parent category for all of those surname category pages could be the "dominant" or "original" surname spelling. I have a few examples of that in my own family tree. --BobC 13:47, 11 March 2010 (EST)
Actually, in this example, Eleazar was a Givenname. Nevertheless, before sometime in the 1800's it is very hard to argue what the proper spelling is. Only recently do people use spelling as marks of individuality. Back when half the people signed contracts by mark, the spelling represented the attorney's, or clerk's, idea of what the spelling was supposed to be, and varied throughout the life of a person. A recent article in NEHGR (163:254) on Gabriel Whelden gave the baptisms of his children, all done at the same church. Despite this continuity of being recorded in a single book, his givenname was spelled Gabriel and Gabrill; and the surname was variously spelled as Whelden, Weelden, Wheeldon, Wildon, Wilden, and Weelding. People tend to use the form they work with, so a descendant of his daughter "Kathren" might be focused on the "Weelden" spelling used in her baptism record. Without some flexibility in spelling they would create what is really a duplicate page, and miss their opportunity to collaborate.
As Jennifer points out, the category won't help the search function either, so if I search for Eleazar, I also want to get Eleazer and Eliezer, etc., which are after all the same name. Same for surnames. If I search for the Skillin spelling my family uses, I also want to get the Skillings, and even Skellin and Skillion spellings that have been used throughout history, and may end up used on a WeRelate page. --Jrich 14:49, 11 March 2010 (EST)

I've been wondering about these name pages myself recently. I don't believe that categories would work, because surname pages serve a specialized purpose for the WR search function. An alternative idea to the 6-7 pages for each name variation is the Dutch Namenthesaurus. If you search for a given name, Pieter, 3 choices are returned: Pieter (male), Pietje (female), Pieters (Patronym). Choosing Pieter (male) gives you the 36 various spellings for that given name. --Jennifer (JBS66) 14:02, 11 March 2010 (EST)

[add comment] [edit topic]

South Carolina - Pre 1800 Districts ? [19 March 2010]

Hello Everyone,

I do not remember a conversation on this topic. There probably was and I just forget it though. Or it was part of a broader discussion. So If you could point out it's location that would be good too. I would like to understand the theory here.

I have found out one of my ancestors had land in the "old Ninety-Six" District of South Carolina. It seems to be a pre County location. I am curious how or why WeRelate does not have the Pre 1800 Districts for South Carolina as a Place. There seem to be about 6 of them. Is there an agreed rule, or did someone not create these page yet? Thanks, Debbie Freeman --DFree 14:06, 19 March 2010 (EDT)

Retrieved from "http://www.werelate.org/wiki/WeRelate_talk:Watercooler"
Menu
Views
Toolbox
Personal tools