This page is for discussing anything you want to discuss unless it relates only to a single page. Let people know what you like and don't like about WeRelate. If you don't want to leave comments on this page, you can email them to dallan@WeRelate.org.
Old topics have been archived at WeRelate talk:Watercooler/Archive 2007 and WeRelate talk:Watercooler/Archive 2008.
I would like to upload a gedcom to an existing tree, but I wish the existing pages in the existing tree to remain in the tree. The new gedcom does not duplicate any pages already in the tree. Is this possible or is it necessary to upload the gedcom to a new tree and then copy the pages to the now existing tree?--Beth 10:11, 24 August 2008 (EDT)
I don't think it's necessary, but there are reasons to prefer an isolated upload. After a GEDCOM upload, I want to go back through all the pages and tidy up place names, remove duplicated sources (or useless sources like "one world tree", etc.). When I'm done with that initial tidying operation on the page, I drop it's membership in the tree I uploaded into and add it to my default tree.
But that said, I'm sure you can upload to an existing tree. Even when you have duplicated person and family pages, you just get a page with an incremented sequence number - you know "Family:John Doe and Mary Smith (2)", etc.--Jrm03063 10:35, 24 August 2008 (EDT)
I have a similar problem. It is too time consuming for me to enter my information into WeRelate directly. Entering into my genealogy software goes 10 times faster, so I upload small gedcoms after I process a family unit.
Can't personally speak to your question, but it sparks a question of my own. What is it about the data entry system on WeRelate that makes it so much slower than your genealogy software? Is this a layout issue? Is it an issue with the basic "Person page-Family page" style of organization? What could be done to make the direct data entry process faster? Personally, I don't make that much use of the data entry system myself, but use my own HTML programming to layout the information. Plus's and minus's with that approach, but "speed" certainly isn't one of its plus's. I personally find the WeRelate data entry system a bit cumbersome to use, but I'm not exactly sure what it is that makes it cumbersome. I think it has something to do with the "Person page-Family page" style of organization. I think this is unique to WeRelate, but its been so long since I explore genealogy programs, maybe its commonplace today. Not saying that it should be different---the WeRelate system is obviously geared toward GedCom downloading, and direct data entry is available for those that need it. But I'm wondering if there's a way to improve direct data entry? Q 10:58, 29 August 2008 (EDT)
I'm making a change in the next month or two that should help: the FTE window will be displayed on every person and family page (you won't run the FTE in a sidebar), and will show the people related to that person/family regardless of whether they're in your tree. So you'll be able to give your relatives a link to a person/family in your tree and they'll be able to navigate around by clicking on the boxes in the FTE window that is displayed on the page. They won't have to launch the FTE.
There's no way to add everyone from one tree to another (and I probably won't be adding one because with this change I'm trying to make it less necessary to worry about what tree(s) a page is in), but if you leave me a message with the names of the trees you want to merge, I can add them for you.--Dallan 13:27, 5 September 2008 (EDT)
It is likely I missed something, but I have watched the get-started video a couple of times, and what it presents is nearly intuitive where I find there are many non-intuitive issues that I wouldn't mind guidelines or rules for.
For example, what is the polite way to dissent with data input by others? Add a topic on the talk page with a explanation of why the data might be wrong, wait a month, and if no response, change the data?
For example, guidelines of what goes in family history and what goes on the talk page? Right now, not many people have talk pages, so one is worried that people don't check here, but this would seem to be the ideal place to explore discredited or alternate evidence.
For example, when using bet., bef. or aft. in dates, it might be reasonable to ask that people always include a source and probably also a note that explains how you arrived at the date. There is a myriad of date issues that could generate such conventions.
There is a hint of the type of rules I am looking for on the screen that describes how to pick Source or MySource. But there are many such decisions where it would help if all users could try to work the same way.
--Jrich 18:24, 26 August 2008 (EDT)
I concur w/Amelia. It's just far too impractical to wait around for folks who might disagree. How do you know who's interested at that moment? Check out Person:John Alden (1), and look at the number of people watching on the left hand side. What would be a quorum?
It's part of the wiki-way to just make the changes. If a dispute arises you deal with it then, but you just can't allow the process to be crippled in the vast majority of cases because once in a very great while someone disagrees. I'm currently watching about 25,000 pages. Over 20,000 of those arise from merging duplicates and tidying up other people's pages. I think I've encountered a disagreement maybe three or four times - and it was never of a severe sort. More of an, are you sure and what do you think sort of thing. Even if it were awful, that's something like 3/20,000. Does that seem worth worrying about?--Jrm03063 22:53, 26 August 2008 (EDT)
Jrich, I applaud your concern with courtesty. I have a similar view, and would not witingly change a page I had not created without at least attempting communication with the author. There is an issue of courtesty with doing work in a wiki type site. WeRelate, despite what some folks think, does not follow the rules of the Wikipedia in several respects. Most importantly, on the Wikipedia there is an overriding emphasis on using published, peer reviewed documents as sources. Use of original research is prohibited. (Good reasons for those rules---without them the Wikipedia would quickly degenerate into into a something quite unreliable.) But if those rules were followed on Werelate, there'd be virtually nothing here---because almost all genealogy involves original research. True, people cite family histories as their sources, but such sources are rarely what could be called "peer reviewed"---perhaps widely read, and some folks think they are the "bible" for their line, but unless something has gone through a formal peer review process, it doesn't meet the wikipedia standards, and you won't be able to get an article based on this accepted long term on the Wikipedia. Try making a change on a wikipedia article based on your original research, and or based on a "family history", and see what happens. Here that's not a problem, but that's because this is not the Wikipedia, and despite what some seem to think, different rules do apply.
Another aspect of the differences between this and the Wikipedia, is that the readership base is much smaller here, than on the Wikipedia. On the Wikipedia you have roughly 40 to 100 Million hits a month. That's a lot of folks reading articles. Not all hits result in an edit, but many do. Here you have at most about 10-20K hits a month, with a corresponding reduction in edits. Half of the users of the Wikipedia are what might be called regulars---folks who habitually go to the Wikipedia to get or add information. On WeRelate most users (about 80%) are just passerbys [1] One look and they are gone. The base of people seriously working the WeRelate wiki is far smaller than that on the Wikipedia. As a result, far fewer folks are going to be paying attention to changes in articles. Some will, but the vast majority will never notice the change---even if they might have felt strongly about the change (one way or the other) they are probably not going to see it, and if they do see a change notice, probably won't invest the time to discuss the point. On the wikipedia, given the larger, more involved user base, you can pretty much guarantee it that if you make a change, its going to be a) noticed, and b) discussed, and maybe c) argued. Not here.
Given the smaller base, I think there's a need to be proactive in contacting folks with whom you disagree about some point of family history. How long you might wait for them to respond is an interesting question. Personally if I were inclined to change an article created by someone else (other than say cosmetic, spelling, etc.), I'd make the change, and then contact them directly by email, asking for their input. That would seriously cramp some peoples style, but I think there is such a thing as courtesty---and this is not the Wikipedia. Q 08:30, 27 August 2008 (EDT)
References:
While I understand the "just change it" philosophy, I am not sure it will scale to high-volume use and mature data. I would hate to see dueling edits flip-flopping data back and forth in one of those numerous cases where the answer cannot be determined and multiple possibilities exist. I would prefer to see a convention for handling this set up now so most people come into WeRelate with it being the norm, and them not getting used to any other way. It is tempting to think we could have a moratorium in its infancy, but I think it should be established and people should start to use it as often as they can bring themselves to...
I was also curious about other issues. There are so many places to put information and it is not clear (perhaps just to me) which is the best for what: embedded in a source, put it in a note, or add it to family history. For example, a one-line statement of historical interest (say, 'Selectman in 1673')probably belongs in the family history section so that all data of a single type is in one location, but it fits so easily in the text section of a source, especially if one wants to attribute that item to that source. A standard set of conventions that most conscientious users follow would result in more readable and understandable pages. I could even see starting every person with a family history section having a standard set of topic headers, or similar framework.
Another issue is the formatting of dates. There are all sorts of practices in the various sources out there, many of which I happen to have an opinion on :-), and I thought the staff genealogist, or other appropriate person could write a quick outline of ideal practices.
Never shy about expressing my opinion, I will outline some of the date issues specifically. George E. Bowman of the Mayflower Descendant sometimes converted dates to new style, which technically meant adding 10 days. So if you saw a date in that magazine of 3 June 1632, you always wondered, is this really 3 June or was it 24 May converted to new style? For that reason, I prefer to leave the date as written in the source, only adding a second year for the months Jan-Mar if necessary, e.g., 24 Feb 1645[/6]. I prefer using brackets to show that I added the second year based on context, or no brackets if the second year format was used by the source, e.g., 24 Feb 1645/6. When quoting numeric dates, I like to quote the date and then give my interpretation in brackets to make it clear I have adjusted for the change in month numbering that occurred in 1753, e.g.: 4 (5) 66 [4 Jul 1666]. When I use aft. or bef. I like to have an explicit note explaining the significance of the date given, such as died bef. such and such a date because that was the date of the inventory. I hate the use of unadorned years which I frequently see, e.g., '1749', except in the sole case where that is all the source gives. If a will is dated 5 Jun 1749 and proved 8 Aug 1749, the death date should be bet. 5 Jun 1749-8 Aug 1749, not 1749. The term Abt. should be used for calculated ages with a 1 or 2 year precisions, e.g., from census entries, depositions, or gravestones, whereas some other term, such as 'Est.' or 'Say' should be used for the swags based on children's ages, date of marriage, etc. Obviously, the basis for all estimates should be explained in a note. I don't want to put words in the mouth of my source, or make it more or less precise than it was, and at the same time, I want to make it very clear what I added so others can check, and if necessary, correct my work. --Jrich 13:19, 29 August 2008 (EDT)
Another issue is the formatting of dates. There are all sorts of practices in the various sources out there, many of which I happen to have an opinion on :-), and I thought the staff genealogist, or other appropriate person could write a quick outline of ideal practices.
Never use an all-digit form (i.e., <yy>-<mm>-
I'd be happy for someone to create a Help:Conventions page and add conventions to it. I don't consider myself enough of an expert to have good opinions here over the basic "don't use all-digits" advice. Currently the software just looks for a 1-2 digit number for the day, an alphabetic word for the month, and a 3-4 digit number for the year. It ignores modifiers like bef, aft, abt, and uses just the first date of a range. (To handle those cases where people use all-digit dates, it checks to see if one of the numbers is between 1-12 and the other is between 1-30, and does the right thing in that case.)
Regarding where to put information, I plan to make a change this Fall that I think will make it more natural to put short explanations on the talk page: I want to list the talk page contents after the contents of the primary page, with an entry box for adding a quick comment to the talk page, like you see in blogs. I'm hoping that this change promotes two behaviors: (1) it will encourage newcomers to leave comments when they have something to say about a page -- filling in a comment entry box at the bottom of the page is a lot less intimidating than editing the page, and (2) it will encourage newcomers to leave their opinions about a page in the comment box rather than editing the page. Then others with more experience can decide whether to incorporate their comments into the primary page. People could be encouraged to leave comments rather than edit well-established pages directly.--Dallan 13:27, 5 September 2008 (EDT)
As one of the benefits of WeRelate should be collaboration, I have been doing the genealogical equivalent of picking a fight: 'fixing' other people's data, and adding controversial individuals, hoping to encourage discussions of these interesting cases. Many of these cases hinge on other people having access to sources I do not, or vice versa.
In making my arguments, I frequently find myself wanting to quote my sources. Sometimes the actual text of a source is important. Having the text certainly seems to add authority in some cases, and shows exactly how limited that authority is in other cases. (A record giving the death date for "Wid. Parks" could easily be applied to the wrong person, but without the text, a reader might assume this is of the same quality as a source that says "Lydia, wife of Benjamin Parks".)
I suspect quoting one vital record with proper attribution would not be regarded as copyright infringement, but after 10 or 15 years of data input, will WeRelate collectively contain 75% of the vital records of towns such as Woburn, Concord, etc.? Would that now be considered copyright infringement?
As a lay person, I am not at all comfortable trying to interpret copyright law. I read some of the fair use links and such, but it might help to have examples of what WeRelate would consider good or ideal usage and improper usage.
Is abstracting a source with attribution always valid? To list a source without some indication of what that source supports could create erroneous appearances if the data gets changed. For example, I enter date-A supported by my source, and later the page is edited to say date-B. If the source is still there, it would now appear that that source is in support of date-B, which is incorrect.
--Jrich 18:48, 26 August 2008 (EDT)
I'm not a lawyer either, but as others have said: facts are not copyrightable and if you put something in your own words you're not violating copyright. Also, I would think that quoting a few sentences verbatim from a copyrighted source along with proper attribution isn't a problem.--Dallan 16:44, 28 August 2008 (EDT)
To see how I have dealt with this issue in the context of obituaries, see for instance MySource:Ceyockey/Obituary for Pearl Eugene Davis. Likewise, for SSN Applications and SSDI entries see MySource:Ceyockey/SSN application for Rebecca D Ashburn and MySource:Ceyockey/SSDI entry for Rebecca D. Ashburn. I think that none of these treatments infringe on relevant copyrights. --Ceyockey 11:54, 5 October 2008 (EDT)
I have noticed that on Family pages, children can be entered in any order and will display sorted by their birth date. This is a great feature. On Person pages, however, when a person has been married multiple times, their marriages are not sorted by date. Is this possible to do other than ordering them correctly on the person’s edit page? Also, is it possible to display a person’s marriage date and location on their Person page?--JBS66 08:50, 27 August 2008 (EDT)
What I plan to do in the near future is display a mini-tree on the right-hand side of each person and family page. In this tree, the marriages and children would be listed in order by date.--Dallan 16:44, 28 August 2008 (EDT)
I have an observation on Place names - not sure if this is the proper place to post this.
My current research involves the Netherlands, specifically the province of Friesland. The Netherlands is divided into provinces and each province is further divided into municipalities. So, I would be inclined to record the town of Fewerd as such: Ferwerd, Ferwerderadeel, Friesland, Netherlands. (town), (municipality), (province), (country). This would be similar to the divisions in France. I noticed that Werelate’s Place pages for France are recorded in this manner (ie: Place:Igé, Orne, Basse-Normandie, France). However, the Place pages for the Netherlands do not include the municipality (ie: Place:Ferwerd, Friesland, Netherlands). It would be helpful to know the municipality in which a town is located for easier searching. I have noticed that websites for Friesland research include municipality information to further limit searches. I wasn't sure if it was possible to make changes to the place pages to add this information.--JBS66 15:49, 27 August 2008 (EDT)
Hello JBS66,
Many of us enter our location names is it was when the event occurred. As I understand it that creates a problem for the mapping system since the mapping is based on present time location names, and it creates issues in Werelate because of that. If I understand correctly you can enter your locations as you wish, and in time those locations will be redirected by Werelate to the present time locations page.
Dallan or others probably understand this much better than I do though. Debbie Freeman--DFree 16:18, 27 August 2008 (EDT)
The short answer is yes! The reason we have only three levels for the Netherlands (and many other European countries) is because the data that we used to construct the Netherlands places (Wikipedia, Getty Thesaurus of Geographic Names, and the Family History Library Catalog) largely had only three levels for most European countries. These countries stay in their current state until someone decides to improve them. For example, User:Scot is currently doing this for Portugal. Others have done it for Sweden, Scotland, Poland, and many other countries (see WeRelate:Place review for information about a large review project last Fall).
If you're interested in working on adding municipalities to the Netherlands, leave a message on my talk page and I'll help you get started. For Europe we tend to title places according to the hierarchy they were in around 1900-1930, and earlier/later hierarchies are listed as also-located-in places. The Netherlands seems to have been relatively stable for the past 100 years, so this won't be an issue for Netherlands.
One final thing: I'm starting a process to automatically edit 750,000 Source pages for the sources in the Family History Library Catalog. During the next few days while this is running, I'd rather not have a lot of place reorganization underway, but you could start around the end of next week if you're interested.--Dallan 16:44, 28 August 2008 (EDT)
I was wondering how I can export data from weRelate to a gedcom. It's a feature that we can see in the future ? The only way that I can see to backup my tree is to use a web crawler / spider and make an offline copy (is a really bad idea, but it's the only that I can imagine now).--fbarriga 22:39, 27 August 2008 (EDT)
There's supposed to be a GEDCOM download one of these days, but we're waiting on Dallan on that one. It's somewhere on his dance card.
I want it for the same reason you do. Also, since there really aren't plans for werelate to offer anything in the way of report generation, it would allow you to dump a section of data to the report-generating facility of your choice.--Jrm03063 10:18, 28 August 2008 (EDT)
I should have mentioned previously, there is an ongoing discussion at werelate talk:Merging and downloading trees.--Jrm03063 14:44, 28 August 2008 (EDT)
I'm the bottleneck on this one unfortunately. I expect by the end of the year we'll have GEDCOM export ready. Need to get matching+merging working first.--Dallan 16:44, 28 August 2008 (EDT)
In Chile and others countries, the wife don't loose their family names and we all have two family names. Example: I'm "Felipe Barriga Richards", son of "Arturo Barriga Apparcel" and "Heidi Richards Staab". At this time, I was using the two family names, but I don't know if there is a convention to deal with that.--fbarriga 22:43, 27 August 2008 (EDT)
Local and contemporary custom is most important. I'm not aware of any customs on this particular issue, but if I understand it correctly, you're saying:
<given name> <parent surname 1> <parent surname 2>
Where the "effective" surname is "<parent surname 1> <parent surname 2>". I think that you would simply put the two parts of the effective surname in the surname field, because that's what they are. My children have their Mother's surname as their middle name, but that's not what you describe. I'm familiar with other customs as well, where children take a hyphenated version of their parents surnames - <parent surname 1>-<parent surname 2>. I suppose this latter situation is most like the one you describe, but apparently use of the "-" character isn't a typical custom where you are? Do folks sometimes put the parent surnames together with a "-" so that they will not be mistaken for a middle then a last name?--Jrm03063 23:18, 27 August 2008 (EDT)
I agree with User:Jrm03063. Put both surnames in the surname field; you can hyphenate them or not. The surnames will be individually-searchable, so if a person's surname field is "Barriga Apparcel" and someone searches on Barriga or on Apparcel, that person will be returned.--Dallan 16:44, 28 August 2008 (EDT)
The new browser from Google is great for merging pages. You can actually have two or more windows open at the same time. Check it out. --Beth 19:48, 5 September 2008 (EDT)
Son said that the Safari windows version has issues; but don't know if that is still the case. Yes, Bill you have been having a good time and didn't let us know. <g> I have been opening WeRelate in my laptop and desktop to merge pages. --Beth 20:44, 5 September 2008 (EDT)
Tabs are definitely awesome. Firefox and IE7 also have them. I just downloaded Google Chrome to check it out.--Dallan 00:45, 7 September 2008 (EDT)
My hubby says the "buzz" on the net is that Google created this "Chrome" without any collaboration with other "browser makers" and thus it is full of security leaks and other problems, which other established browsers have already "fixed" in their versions. Just an FYI --Msscarlet1957 23:14, 15 September 2008 (EDT)
My major interest in WeRelate is in developing a feeling for how our ancestors lived, particularly on the Virginia Frontier in the late 18th Century. The Southwest Virginia Project is part of how I'm attempting to do this. One of the things that I think helps are images that help create a sense of the context of our ancestors lives. My wife and I recently attended an "18th Century Trade Faire", at Fort Loudon, Vonore, TN. Fort Loudon was the site of an ill-fated British Fort that came into existence during the French and Indian War. Each September the Fort Loudon Association puts on the Trade Faire. You can read about it here.
I took a number of photographs, and placed a few of them in a temporary starter article. Some of these photos will probably make their way into illustrations for the Southwest Virginia Project Q 00:18, 7 September 2008 (EDT)
These are some terrific pictures!--Dallan 00:45, 7 September 2008 (EDT)
Dallan
Is there code that can be used in an article page that will transfer the content of edit input boxes (e.g, date of birth input box) into text placed in the article? Q 13:47, 7 September 2008 (EDT)
Many of the sources found in the Source namespace are FHL microfilms or ancestry.com databases. But they are merely reproductions of real books which may also be found in libraries.
When you use find/add to locate a source, the list presents the title only with no hint about the edition (except those where ancestry.com or FHL film number gets stuck in the title).
I have been using these reproductions and the underlying sources interchangeably, since I assume if the data is the same, others will just want to know the most convenient form for themselves. I.e., if I can find the book in a nearby library, why rent a microfilm at a Family History Center which takes at least 2 weeks to arrive? For some I have taken the time to add in the author and original dates of publication, even though the source is nominally referring to a FHL microfilm, to provide more descriptive information about the source.
Recently an "automated update" changed one of these entries to enter the date of filming, overwriting the publication date of the underlying book I had entered. It also undid my edit which had moved the subtitle to the subtitle field and instead put everything back in the title field so that the title is once again long and impossible to input except by cutting and pasting.
First, I would argue that in terms of assessing the quality and type of data, the date of filming is useless. It depends on the publication date of the underlying material.
Second, most of these entries abuse the title field, and clearly combine both the title and subtitle into the title field instead of properly using the subtitle field. This makes it very difficult to type the source names by any manner than cutting and pasting when you want to add a [[Source:xxx]] type link to your notes.
Not only are the FHLC titles long, but adding place and/or author before the title makes them too long. Most place oriented items have the place name in their title anyway so it becomes redundant when you add it in front. And adding the FHLC number to make each title unique instead of listing all the filmings in the text of a single page also screws up the title. I expect the title to be the title. Is this just compensating because the listing of titles after you do a search on the find/add screen doesn't specify the author, etc? I haven't memorized the FHLC film numbers so I still have to follow the FHL link to read the description to find out what the different versions of the same title are. --Jrich 21:42, 8 September 2008 (EDT)
But, that said, there are times when editions become an important issue, as in when things get updated or there is an error in one edition. But is there a need to treat each different edition on each different media as a different item in the Source namespace?
If so, it seems that the process to select from the list of known sources needs to change. Perhaps the first step is to pick the title/author and then a second step would be to identify the edition/format.
I guess this touches on my earlier question about conventions. Different people might think different organizations are more optimal than others. But the one thing that won't work is to have everybody each do their own thing. What is the best way to deal with this?
--Jrich 09:14, 8 September 2008 (EDT)
Your point about not citing specific editions is an excellent one. That is something that should always be done, where it applies, and usually the distinction between editions is based on the date of publication. Works published in different years oft contain different information---sometimes contradictory---so knowing which edition you are using can be very important, and needs to be included in the citation. In theory, the citation format preferred here includes that information, though not as part of the article title. Unfortuantely, I've seen sources here where the date of publication was not specified---apparently whoever wrote the article felt the title alone was sufficient. In most cases it is, but not in all, and good form should always include the date I think.
Here's and example Source:Marriages by Rev. George Wack If you read this work you see that it was created by a 'bot', and that the date is not included. If you open the page up for editing, you'll note that there is an input box for "issue date" (really that should be publication date in most cases, but perhaps "issue" fits a more global interpretation. (ie, something that was never "published", just printed up on a certain date.)
So if "Marriages..." was first released in 1890, and then reissued in 1895 (perhaps with corrections or with additional marriages), just citing "Marriages by Rev. George Wack" would be quite inadequate. The date the specific document examined should have been included in the bibliographic citation. Personally, I think it should be included in the articles title, but that's personal preference. In anycase, the date should be in the pages data.
But suppose "Marriages by Rev. George Wack" was indeed released in 1890 and 1895. How would you direct someone to one version or the other---even if you figured out a way to include both dates in the description, just calling out the articles title [[Source:Marriages by Rev. George Wack]] would not allow you to point to the specific edition. Perhaps you could fiddle with the article title itself "Marriages by Rev. George Wack, first edition" or "Marriages by Rev. George Wack, second edition". Citing "Wack, 1890" seems easier, but that's just me perhaps.
On consistency, One can expend an awful lot of effort in making things consistent.there are circumstances where consistency is important and needs to be achieved. There are other circumstances where it accomplishes little, and simply drains time and effort. Depends on the goals. in anycase:
There are five major citation styles in use in the United States. Here's a summary of examples for each Style, as given on World Cat, for a specific work.
Citation Styles for "Annals of southwest Virginia, 1769-1800,"
| Style | Example |
| APA | Summers, L. P., Bickley, G. W. L., & Coale, C. B. (1929). Annals of southwest Virginia, 1769-1800. Abingdon, Va: L.P. Summers. |
| Chicago (Author-Date) | Summers, Lewis Preston, George W. L. Bickley, and Charles B. Coale. 1929. Annals of southwest Virginia, 1769-1800. Abingdon, Va: L.P. Summers. |
| Harvard | SUMMERS, L. P., BICKLEY, G. W. L., & COALE, C. B. (1929). Annals of southwest Virginia, 1769-1800. Abingdon, Va, L.P. Summers. |
| MLA | Summers, Lewis Preston, George W. L. Bickley, and Charles B. Coale. Annals of Southwest Virginia, 1769-1800. Abingdon, Va: L.P. Summers, 1929. |
| Turabian | Summers, Lewis Preston, George W. L. Bickley, and Charles B. Coale. Annals of Southwest Virginia, 1769-1800. Abingdon, Va: L.P. Summers, 1929. |
For the most part, there's not a whit worth of real difference between these styles---all provide the same basic information. None specify edition, but all specify date of publication---just in different places, and in different "styles". What's preferred on WeRelate (not my personal preference, by the way) is MLA or Turabian. (It doesn't appear here, but the difference between MLA and Turabian is that in Turabian, the title is underlined.)
These different styles exist, I presume, because they meet specific needs. These styles are preferred and used by different groups of writers. In part, what they use is simply a matter of convention. Someone "liked it" early on, and that like turned into a standard within that group. It is likely, however, that some of the styles developed in response to specific needs of specific groups---because the style emphasized things that were important to that group. APA and Chicago, for example, are used in the Sciences, Harvard in law, and MLA, and Turabian are probably encountered more in the arts (including English, which is significant because that's the style most folks are going to be familiar with. The distinction between Science and the Arts in terms of citation style probably reflects what these groups want to emphasize. Ignoring content, for Science, the important thing is not what you call your document, but who wrote it and when. Priority of discovery is based on precedence, and who said it first, and when, is what is important to science authors. In the arts, what's important is who made it and what they called it.: No one refers to "Shakespeare, 1589", instead they refer to "Shakespeare's Hamlet". Among scientists, on the otherhand, when writing technically would prefer "Darwin, 1859", over "Darwin, Origin of the Species"---though they might use the latter form in more casual reference, simply because Origin of the species has become iconic.
If there is a standard in genealogy, its probably MLA and Turabian. The NEHGS prefers something similar to MLA, but its not quite the same. Other journals use, I believe, different source formats, but they are probably most similar to MLA or Turabian.
Does it really matter which format is used? That depends on the purpose. Obviously, if you want to create a bibliography for your work, you'd prefer to be consistent within that work. That doesn't mean you have to be consistent BETWEEN works, just within that one work. After all, purposes and objectives might change, and different format serve different purposes. But in the broad scheme of things, it doesn't really matter which of several formats you choose---what's important is that the needed information is present. That way, if a bibliography needs to be developed necessary to support an article in a particular journal (say NEGHS), then you'd have all the information needed to support that article. One day there may even be a Bibliography Tool here to do that for you. You could specify the format (MLA, for instance), give it a list of articles, and it would punch out the bibliography according to the needed specifications. Send it to a different Journal (say one that prefers Harvard), you could get a bibliography in that format. That would be a very cool tool to have, even if you weren't into publication, and it wouldn't make much difference if the format's of the original source articles differed---as long as the data was there. Q 12:38, 8 September 2008 (EDT)
Is there a badge we can add to our blogs that would link back either to the WeRelate homepage or to our profile page? More and more sites are offering that feature to their members/users. I think it would be a neat way to drum up a little more traffic for the site (and it would look cool on our blogs ;-) --Ajcrow 08:45, 11 September 2008 (EDT)
Good idea! How about <a href="http://www.werelate.org/wiki/User:Dallan"><img src="http://www.werelate.org/w/skins/common/images/badge.png"></a> ? You probably want to replace my user page with your own :-)--Dallan 11:39, 17 September 2008 (EDT)
I'm preparing to merge my individuals where duplicates exist with other users. I came across a user that uploaded a Gedcom with over 11,000 individuals. They have not made any contributions since, and their work contains duplicates. Should I go through the effort to merge into their work or can we consider deleting this tree as suggested for another user on User talk:Jrm03063?--JBS66 17:23, 13 September 2008 (EDT)
As you've noted, there has been much discussion on this issue and the reason I would say for a lack of response here is we are at a stand-still on the topic. I don't recall that a decision was ever made on what to do about such GEDCOMs. We'll have to wait for Dallan to chime I believe. :)
I wonder though if instead of deleting the entire GEDCOM (which some people oppose for fear of losing some crucial data yet undiscovered) if the pages couldn't be moved to a ... graveyard of some sort? Gone but not forgotten? --Ronni 08:20, 15 September 2008 (EDT)
I think we treat abandoned GEDCOMs like abandoned property. Make some reasonable attempts to contact the person who did the upload to see what their intentions are. If we don't hear anything, then it belongs to the community and we can do what we want. If anyone in particular has worked with the materials in question, then I think Dallan will generally respect that person's opinion on whether the material is worth retaining or not.
I've covered a lot of ground on stuff like this - could you please advise what user/tree you're looking at? Thanks...--Jrm03063 10:38, 15 September 2008 (EDT)
The user I keep coming across is User:Rrhoule.
I've been trying out some merging this morning thanks to the great tips on User talk:Jrm03063 and User talk:Scot. 1/5 of the Gedcom families that I uploaded have potential duplicates. I'm glad I only uploaded a portion of my data!
What happens with families that have been deleted such as Family:Charles Cloutier and Louise Morin (1). Actually, this family is indexed under (1)-(12), 10 of which have been deleted. Can the lower index numbered pages be reused? So, can I redirect my [Family:Charles Cloutier and Louise Morin (12)] to [Family:Charles Cloutier and Louise Morin (1)] to keep the index numbers low?
It seems so easy to upload a Gedcom, and so incredibly time consuming to clean up the results. I look at why I uploaded a Gedcom instead of entering by hand. I thought entering by hand would take too long, and I wasn't sure how much of my data was common to WeRelate's. I only uploaded names/basic dates/marriages and planned to go back and add in sources. Perhaps there could be some sort of happy medium. I could upload my Gedcom, but if the program notices the family currently being uploaded shares a title, it will put that into a log file instead of creating new pages. Then, I would be responsible for checking the log file to see what I needed to enter by hand. It would be a whole lot easier to enter in a few pieces of missing data on a page then to match/merge multiple pages. Just a thought... I do have to say that I love the concept of WeRelate. It's great to have a site where work can be done collaboratively on unique pages.--JBS66 12:22, 15 September 2008 (EDT)
I definitely try to keep the index numbers low. If index "1" was previously deleted however, you'll need to recreate it before you redirect to it. That's easy enough of course, because when you try to go to the deleted address location you'll get a chance to create the page anew.--Jrm03063 12:54, 15 September 2008 (EDT)
So, how do we go about deleting this tree? This user holds the coveted (1) page on many of my merges, so I'll hold off on merging those until that tree is deleted.
This might be a silly question but I came across a few cases like Family:Marin Banne and Isabeau Boire (2) where there are no other duplicates but the Family:Marin Banne and Isabeau Boire (1) spot was deleted. Would you suggest redirecting to the (1) page, even though this family is not duplicated, just to have the (1) spot? It would make it easier to see that it wasn't a duplicate, but would it create a needless redirect page?
Thank you!--JBS66 07:02, 16 September 2008 (EDT)
I'm sorry for not chiming in earlier; the last few days have been overflowing with various things that had to be done.
I'll contact User:Rrhoule and let them know that I'm deleting their tree. I'm working right now on tools that will make merging easier, and in the future part of the GEDCOM upload process will be to merge into existing pages before the new pages get created. Until those tools are in place, the policy is that GEDCOM's that are going to cause a lot of merge work that are uploaded by people who are no longer active, are deleted upon request.
We keep every GEDCOM that's been uploaded, but a lot of the GEDCOM's contain information on living people to I'm reluctant to automatically put existing GEDCOM's into the digital library. Sometime next year though I plan to add an option to the GEDCOM import where people can say explicitly that they want their GEDCOM to be added to the digital library, and I'll make a "gedcom viewer" available (similar to the FTE) so that people can view the GEDCOM files online.
As for renaming/redirecting pages to (1) indexes, you're free to do that, although I agree with Jrich that ultimately a (1) index often won't have any special meaning.--Dallan 11:39, 17 September 2008 (EDT)
Is there a button link I can use to link werelate to my blog? I already have a text link but buttons are better because they stand out. --Brannon 18:21, 15 September 2008 (EDT)
Brannon, I don't think Dallan has a specific button link, but could you use the little WeRelate icon that appears in the upper left corner of this page? Just embed a link in it and put it on your website? --Ronni 12:32, 16 September 2008 (EDT)
Try <a href="http://www.werelate.org/wiki/User:Dallan"><img src="http://www.werelate.org/w/skins/common/images/badge.png"></a> . I just created it this morning using this website.--Dallan 11:39, 17 September 2008 (EDT)
How should Chinese surnames be handled? The Chinese surname 伍 has the pinyin Wu, but most natives of this surname originate from Guangdong and go by Ng or Eng in western countries. And Wu is used by other surnames, see http://en.wikipedia.org/wiki/Wu_(surname).--Ronengyoung 21:51, 17 September 2008 (EDT)
Here are two possible suggestions:
I am not able to see any of the Google Maps. Is it my browser? or is it a problem at Google? or some problem here at WeRelate? --Msscarlet1957 10:29, 18 September 2008 (EDT)
not working for me most of the time but does work once in a while along with several other features. i think the problem is in the werelate program. i am using vista & internet explorer. --Jimlatimer 13:46, 22 September 2008 (EDT)
Google maps is working fine for me. I use Firefox, Google Chrome, and also tried it out on MS Internet Explorer.--JBS66 13:58, 22 September 2008 (EDT)
I'm able to repeat the problem with IE7 on XP, but I haven't found out what's causing it yet. I'll look at it more tonight.--Dallan 18:20, 22 September 2008 (EDT)
still not working -- i did control-F5 and nothing changed, i did control-refresh and nothing changed, i turned off protected mode and nothing changed. i am not sure what you mean by turn off web filter. i do not have parental control turned on.--Jimlatimer 11:57, 23 September 2008 (EDT)
Google maps (on WeRelate) is now not working for me. Tried it on Firefox, Chrome, and IE. On IE last night, an error box that said "Maps Loaded" came up. Your example site, Google Maps, and Acme Mapper all do work.--JBS66 12:53, 23 September 2008 (EDT)
I'm sorry. How embarrassing -- I ended up breaking maps completely last night and didn't realize it until tonight. Maps should be working finally now.--Dallan 00:23, 24 September 2008 (EDT)
What's the protocol for pages that have been created for famous living people? Example: Person:George Bush (3). There's also a page for Prince Charles around that does actually have data. One one hand, yes, we say no living people. On the other hand, George Bush's vitals are available in approximately a zillion places already, and the ability to hook into a famous person's ancestry is probably a perk of our system.--Amelia 13:56, 21 September 2008 (EDT)
There's a lot to be said for the absolute nature of living/dead. If you decide on fame, then you have to decide on a metric that is relatively objective. My choice would be whether or not they have a wikipedia page, but again, I don't have a strong preference.--Jrm03063 16:50, 21 September 2008 (EDT)
Let's go with what User:Jrm03063 suggests -- this lets us rely upon Wikipedia's metric rather than create one of our own.--Dallan 18:20, 22 September 2008 (EDT)
I don't think that I have posted information about this program on the Watercooler before. The program is very useful; especially for me since I am spoiled by the clipboard features available in Legacy.
The program is free. Access the download here.
Description:
Ditto is an extension to the standard windows clipboard. It saves each item placed on the clipboard allowing you access to any of those items at a later time. Ditto allows you to save any type of information that can be put on the clipboard, text, images, html, custom formats, .....--Beth 23:11, 22 September 2008 (EDT)
I am so excited as finally I have two cousins who have joined WeRelate, AND have adopted the appropriate tree I have online, AND they are collaborating. It is a dream come true! OK, so now I have this "new" problem.
As I find more information, Say.. John Doe had NO wife or kids entered when my cousins adopted the tree. Now I find more info and add the wife and kids. I find that the wife and kids are now "not" being watched by the two cousins, so they don't know anything when I even find more and add a second generation to the original John Doe. So I have write to them and have them go in and manually open each of the new kids and click edit in FTE and click on "add this person to the tree." Is it unreasonable to somehow have new people pages within an adopted tree, added to the my collaborating cousin's watchlist automatically? --Msscarlet1957 20:11, 23 September 2008 (EDT)
I think though if your cousins are watching John Doe and then you add a spouse to him, your cousins should get a message that changes were made to the John Doe page. When they look at what has changed, they should see something like Propagating changes to a family member and then they can see the newly added page and choose to "watch" it. I think this is how it works. I don't have my preferences set to receive email when changes are made so I'm not sure about notification, but when I look at my Watchlist, I see this kind of change all the time.
And btw, congrats on the new collaboration! :)
--Ronni 20:34, 23 September 2008 (EDT)
I agree with Ronni's comment -- your cousins should get an email about the Family page being changed, and when they view the changed page they can decide if they want to watch the newly-added pages. Having them use your user name and password could also work, but then they wouldn't get email notifications since the emails would all go to you.
The issue with their needing to also add the pages to their adopted tree is a pain I agree. For reasons like this I want to get rid of the notion of "trees" later this year and instead display the FTE window on every Person and Family page. I think this will make things simpler. I could also provide an option to "watch every page that user X watches", but that's lower in priority for now.--Dallan 00:23, 24 September 2008 (EDT)
Both cousins already have their own user name and password. and the whole idea of collaboration is for us to get emails when any of us makes changes. so having them use my password would mute the whole collaboration concept for me.
The option to "watch every page that user X watches" would not be good, in my humble opinion, as I am watching all pages from my other trees, which have no connection what so ever to the folks in the tree which the two cousins are collaborating on, thus that action would add a bunch of pages they don't need to be getting emails about when updated.
Let me ask, if they just go to the page and click "watch" in the upper right hand corner, does that do the same thing as when you go up to "edit" and then select "add this page to tree"? I did not think it did, I was thinking that only makes them watch the page, but these newly watched pages would "not" show up in the FTE window. I was thinking that when you go up to "edit" and then select "add this page to tree" -that cause you to watch the page AND to have it added to the adopted tree, thus the new children and spouses will now show up in the FTE window. Do I have that correct? I am attempting to "guide" my cousins, I don't want to get them discouraged, now that I finally have someone willing to Collaborate!! --Msscarlet1957 09:41, 24 September 2008 (EDT)
What you want to ask them to do is click on "Tree +" in the upper right corner. This is the same as clicking on "Edit" and then "Add this page to tree". If they do this the page will be added to their tree so it will show up in the FTE, and it will also be added to their watchlist, so they'll get notified about changes. (And I agree it's confusing right now - hopefully it will get streamlined before the end of the year. And congrats on your collaboration!--Dallan 15:05, 24 September 2008 (EDT)
You can now search sources by subject and availability. Just click on Search in the main menu, then on WeRelate, then click "Sources" on the left-hand side. Try entering a place and clicking on Search. All of the sources that cover that place are listed, and you get a list of the number of sources for each subject along with a list of the number of sources that are online websites, microfilms viewable at a family history center, etc. on the left. And thanks to the people who are reviewing the online sources, we should have a lot more websites categorized by early next year, which should make this source search engine a very useful function!--Dallan 15:05, 24 September 2008 (EDT)
There is a new "Find duplicates" menu option under the "More" menu in the uper right corner of Person and Family pages. This is the first half of the upcoming Merge function. Even though the actual "Merge" part is not yet implemented, I thought that this "compare" part might be useful for those who are trying to find duplicate person and family pages. If you're interested, please check it out. Here's an example family page that has a duplicate family: Family:Daniel Phillips and Ella Grey (1).--Dallan 15:05, 24 September 2008 (EDT)
This is great! This is so much easier than having multiple browser pages open side-by-side and trying to compare. I also like the colors to help differentiate the fields that are identical and those that differ. The option of being able to merge family and children all at once will save a lot of time. Can't wait!--JBS66 15:43, 24 September 2008 (EDT)
Is there a particular convention when creating a title for person pages for someone with a surname such as de la Croix? I have seen it filed under Croix (de la), LaCroix (de), La Croix (de), Delacroix, and de la Croix. It may also make a difference that these person pages are for individuals from 1600-1700 France where their surname was associated with the location they lived in. I know that I could put just part of the surname (such as Croix) into the title, and then add the (de la) into the surname field after the page is named.--JBS66 15:22, 24 September 2008 (EDT)
I don't know what the genealogical convention would be, but if you were to write it as "Delacroix" or "de la croix" in the surname field, then it would be found in searches for "delacroix" or "de la croix" or even "de lacroix" (the variations are interchangable). Whatever you decide, I'd keep the page title and the main surname the same. You could put variations if you wanted as alternate surnames.
So, can I add additional info/names into the other fields (given, title prefix/suffix) of the primary name line, or does that first name line need to remain identical to the title? Regarding dit names such as Ballard dit Latour - should the dit name be put into the Title suffix field?--JBS66 14:15, 26 September 2008 (EDT)
One additional comment: if you write it as "de la croix", then it currently won't be found by searches for the surname "croix", since "de la croix" gets indexed as a single word "delacroix". I did this so that names like "Mc Williams" did not get returned for searches on "Williams". I could possibly change this behavior though.--Dallan 00:06, 25 September 2008 (EDT)
I've seen names like this written both ways, so when indexing surnames the system combines words less than four characters long together (so for example "Mc Williams" becomes "McWilliams", "de la Croix" becomes "Delacroix", "O'Hara" becomes "Ohara", and "Van Den Berg" becomes "VanDenBerg". This seemed like the most straightforward way to handle them.--Dallan 14:27, 25 September 2008 (EDT)
I went to Wikipedia, and wanted to see what a search for de la Hoya would look like. I could pull up Oscar de la Hoya with searches for de la Hoya, la Hoya, or just Hoya. My opinion - I would think that WeRelate searches could benefit from this same approach. I can't, however, speak for how it would effect people with surnames of other origins such as Scottish, Germanic...--JBS66 14:15, 26 September 2008 (EDT)
Yes, but you can't find "De la hoya" in Wikipedia if you search for "De LaHoya" or "Delahoya". That's the problem I was trying to solve, since it seemed to me that the more common problem is for certain surnames to be written sometimes with embedded spaces or apostrophes and sometimes not. I could possibly add returning "De la hoya" also on searches for "Hoya" (I don't know how important this is - comments?), but searches for "Hoya" still wouldn't find "Delahoya".--Dallan 18:22, 26 September 2008 (EDT)
The "dit" names bug has been fixed; i.e., the surname "Brien dit Desrochers" is indexed as three separate words and can be found by searching "Brien", "Desrochers" or "Brien dit Desrochers". Newly-added/edited pages are being indexed correctly, but existing pages need to be re-indexed, which should be complete in 2-3 days. Unfortunately this means that "dit" names will not be searchable during the next 2-3 days until they get reindexed.--Dallan 13:05, 29 September 2008 (EDT)
The above thread on Multi-part surnames brings up additional naming questions. What about names such as Jean Baptiste or Marie Madeleine? It was a common custom in Quebec to name boys/girls Joseph/Marie in addition to another first name. For me, it would be helpful to distinguish exactly which Marie we're talking about in a family. PRDH states "It is difficult to distinguish true double first names – those written with a hyphen – from juxtaposed first names, which could be used separately. In the PRDH, we circumvented this problem by separating all first names into their elements. Thus, the PRDH treats the name Jean-Baptiste as two names, Jean and Baptiste, and name searches in the data base can be made according to either one." [3]. So, following the convention in the above thread, if a page is titled Marie Madeleine, will it not be found by searches for Madeleine?
Next thought, what about names such as Francois or Etienne? I'm not well versed in French, but from what I can see in source documents, it is more accurate that these names be spelled François and Étienne. How does this affect searches/merging functions and is there a proper convention?--JBS66 07:58, 25 September 2008 (EDT)
I also noticed that when searching and sorting by title, Étienne appears at the end - after the names that begin with Z. Also, a search for Francois does not bring up any François entries. I guess either the program would have to recognize that c and ç are interchangeable, or that it wouldn't allow titles with those characters (automatically changing É to E and c to ç). --JBS66 08:20, 25 September 2008 (EDT)
Hyphenated given names are indexed separately. So a name "Jean-Baptiste" should match a search for "Jean-Baptiste", "Jean Baptiste", "Jean" or "Baptiste". The only time the system combines name words is in surnames if the word is less than four characters long. All other name words can be searched individually.
Accented characters are supposed to be treated the same as unaccented characters in searches, but it looks like they're not. I'll have to fix that. Thank-you for pointing that out!--Dallan 14:27, 25 September 2008 (EDT)
Two questions: 1. Do multiple first names then have to be hyphenated in the First Name field? So, I should be entering Jean-Baptiste as such? In names such as Marie Madeleine, I'm leaning toward including both names in the title instead of just Marie. 2. Does it create a computing problem if there is a page titled François Bourdon (1) and another titled Francois Bourdon (1)?--JBS66 13:03, 26 September 2008 (EDT)
1. No, multiple first names don't have to be hyphenated in the first name field. If you enter "Jean-Baptiste" or "Jean Baptiste" it's indexed the same and returned for searches on "Jean", "Baptiste", or "Jean Baptiste".
2. No, there's not a computing problem. The system treats the titles as different titles. The real problem is getting the system to treat accented characters similar to unaccented ones - so that searches for Francois return people named François. (I thought I had done this, but unfortunately not. I have to fix this and re-index the pages next week.)--Dallan 18:22, 26 September 2008 (EDT)
The accented characters bug has been fixed; i.e., the name Étienne can be found in searches for Etienne (and vice-versa, the name Etienne can be found in searches for Étienne). Newly-added/edited pages are being indexed correctly, but existing pages need to be re-indexed, which should be complete in 2-3 days. Unfortunately this means that names with accented characters will not be searchable during the next 2-3 days until they get reindexed.
At present, when you choose to sort search results alphabetically by title I'm still sorting Étienne after Z at the end of th
