Menu
- Home
- Search▼
- List▼
- Add▼
- My Relate▼
- Admin▼
ViewsWatchers |
Genealogy has been a passion of mine for more years than I care to remember, but Wikis, on the other hand, are a fairly recent endeavor. The following information is more for my own benefit than others, but I realized that if I was needing reminders, perhaps others might as well.
RecordsCiting Death Certificates
The order of the information is basically irrelevant, but sticking with a standard makes understanding the information easier. It is also important to differentiate between information culled from the record and information inferred from other sources. Always use brackets for information not directly derived from the death certificate.
Citing U.S. Census RecordsPage creation on WeRelateThis is the standard, copied (with stylistic revisions and additions), which I found on the Source Page Titles help file. [As of 19 Nov 2012] The standard page title style for United States census records is: County name, State name, United States. XXXX U.S. Census Population Schedule (Example:Source: Crawford, Illinois, United States. 1870 U.S. Census Population Schedule)
Citing on individual pagesI want to enter a census record as a source to one of my ancestors. The record is an 1820 U.S. Census for Overton County, Tennessee. Here's my method, which generally follows standards for citing U.S. census records while incorporating WeRelate's census page creation method. I haven't found one actual standard for citing census records. What I have found is that all of the information contained in the various citations is primarily the same, but the order or detail of the record may be different.
At this point, a link can be made to the actual page of the census record if it exists in a format that others can view online. Examples would be an uploaded image of the page or a link to a free website displaying the page. I usually attempt to find the image on Family Search, since it's free, so I can link directly to the image on their site in my sources. So here's the back end of my Text box detail:
Once this is done, clicking on Save Page or Show Preview should have the citation appearing like the following example:
Wallah! Now if you want to enter more details, like a transcription of what was found on the record, have fun and do so. Otherwise, all done! You might be asking, why go to so much effort if I'm linking to the image online? I'm afraid I'd have to answer that question with a question. What if the link to the image breaks? With this method the record is accurate enough that anyone down the road can trace through the census (by hand, if need be) and find the exact page for which they're looking, even if the original image link goes away. Addendum: I have, since the writing of this portion, changed how I enter the citation. Since my main source for census records is Family Search, I have chosen to instead copy the citation they have already generously provided on individual census links under Document Information. I copy the information from FamilySearch to before the NARA portion of the citation. NARA should be included as part of the original census source. The majority, if not entirety, of the information which I gathered and used originally is generally included in this information. Census Enumeration Dates: US FederalEvery US Federal census record has what is called an enumeration date printed on each form. It is the date that census takers were supposed to use as their point of record. It is different than the date written on the records, which is the day they actually acquired the information. The difference between these two dates is simple. The census takers were supposed to write down information as if the date they were recording the information was the enumeration date printed on the form, not as of the date they were recording the information. We as researchers can only make the assumption that the census takers did their job correctly. If we start assuming otherwise, then we are adding another level of possible error onto a source which should be avoided. The official enumeration dates of the United States Federal Census are as follows and are the dates I always enter as the date for those records:
Census Enumeration Dates: US StatesState census records were also restricted by enumeration dates, but these were generally NOT printed on the forms. It is, at times, difficult to determine a State's enumeration date without a bit of digging. Iowa
Kansas
Standards and Standardization: Is it really that important?What's the point? Why does it matter? Is it really that important? It is, quite simply, very important if you want anyone to find your work, help you with your research or you want to make a valid contribution to the core system. Without standardizing the information on WeRelate, there will be 100 different ways to reference Albany County, New York with no one way for anyone to have a clue if someone else is doing research in that area or if there is a reference book that has something to do with that area. Standards are also important for continuity. The more contiguous a site is, the easier it is to navigate and the more likely you will want to be there. Humans are creatures of habit and, in general, we don't like it when we are hit with the big red change sign. When one page shows a date formatted one way (ie, 25 Jun 1950) and another page shows a date formatted completely different (ie, 1950-06-25 or even 25 JUN 1950), it tends to jar our sense of aesthetics and hits us upside the head with unneeded change. Perhaps this isn't a huge irritant for you, which is fabulous and wonderful, but for many people, it is. Don't get me wrong, change can be good for many people, but I have found when reading, it is a bad thing. (past tense/present tense conflicts anyone?) I can't stress this enough, standards are amazingly important, especially with so much information available. It may feel like a pain in the neck sometimes, but a pain now saves on countless headaches in the future. Theory vs Practice...But (Random Name Designated Area Inserted Here) Didn't Exist Before XXXX. Now what?This is one of those areas of Theory vs Practice, where I get it, but I don't. I understand that researchers want to be accurate in how their particular information is displayed (e.g., showing Virginia Colony instead of Virginia, United States). On a theory level, I get it. It would be great if there were webpages that would reflect all of these various iterations of a particular land mass so that researchers could be accurate down to minutiae, but it's not practical in practice, especially on a website. Ultimately though, whether the United States "existed" in 1650 or not is irrelevant. The page United States refers to a specific GPS location. If it referred to a series of GPS locations, all the better... oh wait, those are taken by States, Counties, Cities, etc., so it already does. Therefore, WeRelate already has a Place system that works and connects with a geographical location designated by GPS coordinates. This is the practice side that makes more sense to me. It's clean, it's clear and it's very specific. So then we have the "pipe" system ( | = a pipe ), which, if you're unaware what that means, it's an option that has been used for Place names to allow for "other" names to appear instead of the original GPS referenced name (e.g., Virginia, United States|Virginia Colony). This solves the problem, right? No, not really, because most of the time the "pipes" are used by the back-end of the WeRelate system to catch typographical errors in Place names entered on a particular page, which the researcher input incorrectly. Also, utilizing the "pipes" by manually adding them for personal preferences, regardless of the accuracy of the research, tends to be confusing for most other researchers which come after the initial researcher who chose to use the "pipe". A collaborative website such as this needs to be kept as simple as possible to appeal to and be utilized by average website users, which makes up about 80% of the general population. Here's a separate real world example... Programming. That's okay, if you know nothing about programming, don't run away. This will make sense, I hope. The programming language (or code) that a computer most easily understands is machine code, though it is the furthest thing from a language that is easy for a human to understand. Think binary with all the ones and zeros you may (or may not) have learned about in school. (By the way, if you know someone who programs in machine code, give them a cookie and a pat on the back.) Most programmers today use high-end programming languages like Python, Java, etc. If you were to take an average computer user and teach them how to write the very basic "Hello World" program in Java, it wouldn't be that difficult for them to understand with some explanation, even if they may never use it again in their entire life. Were you to do the same with machine code... uh, no. Not happening. Basically, the average user needs something simple and basic. Now what about other programming languages? Sure, there are other high-end languages that will also work, but in a collaborative system, only one language should be used and agreed upon, otherwise you get what is called spaghetti code (though even with one language this can happen and often does). Now let's connect the dots... Here we have machine code, which equates to GPS coordinates, and the "Hello World" program, which equates to the information that researchers enter into WeRelate. Now we need the programming language between them, which is the structured WeRelate Place name system. All things considered, this is fairly simple and straightforward, but then you get researchers who want to introduce other languages, like the "pipes" or redundant pages with more details. I don't know about you, but as much as I like spaghetti, I prefer it kept away from either programming or webpages. Anything that makes these pages more complex should be avoided. Simplicity is necessary for the website to grow. Also, have you considered researchers outside of your own country when modifying Place names with "pipes" or otherwise? If you came across a page showing Redcliffe Penal Colony, would you know automatically to what it was referencing? If you're from Australia, most likely, but would people from Thailand, the United States or Russia (ignoring language barriers) know that you entered a "pipe" that actually references Redcliffe, Queensland, Australia? Perhaps, eventually, but the unnecessary ambiguity stops the original flow of research. Instead, the most viable solution would be to leave the Place name alone and put the added or modified description in the "Description" column... imagine that. All this to say that while in Theory more specific research places is preferable, in Practice too much detail in the Places column will simply make the whole website cumbersome, difficult to understand, and a challenge to maintain. TemplatesAdministration
Communication
Text
Family ConnectionsUnfortunately, family connections are not always clean for one reason or another...
These are all perfectly valid, so I found a few templates and came up with few templates to help these situations. They all use the same basic format. {{Template name|Person (or Family) name}} used in the Event area of a page with the Other option chosen. More clarity can be found on the actual template pages. When you use one of these templates on a family page, the end result will be shown on both parents individual pages as well as the main family page.
Sources
Errors and SolutionsDealing with Pages Created in ErrorEveryone is going to do it at some point... a page gets created that is later found to already exist, so what do you do with the new page? If it was only created in the past day or so, you can send it to Speedy Delete and only the SD committee is the wiser. If it was created months ago, that could be another kettle of fish. Deleting a PageSending a page to the Speedy Delete committee is the cleanest way to get rid of a recently created page. Here's my solution.
...and Save. Simple and you can go about your work, nothing to see here.
Redirecting a PageSo the page has been around a few months and it's possible someone else linked to it from another website. Great, so now what? It's fairly simple. The duplicate page needs to be redirected to the original page. Follow Steps 1-2 for Deleting a Page, then continue to Step 3.
...and Save. Again, simple, and the world is back in order.
Reverting to a Previous RevisionGoing along my merry way, I made some changes to a couple of pages, which I considered the right thing to do at the time. A few days later (almost a week), I realized I had made a rather huge mistake in my changes. We learn as we go, right? ...and since no one else caught my error, I wanted to figure out how to fix it, but I had no clue. Here's the scenario: I changed the basic information for a census record source, which at the time I assumed was incorrect because it contained a rather specific author. Authors on census records? Not likely... so I changed them thinking something was seriously wrong with the original creator's thinking (arrogance strikes again). Little did I take into consideration that the page was an index that someone else had created OF the original census. Realizing my error later, I knew I had to put all the book citation information back into the source file and change the source file name back to what it was (yes, I changed the source file name too). Here was the response I received when I couldn't figure out the proper way to do it with the least amount of mess.
That thankfully answered my question and the pages are back to normal. *Phew*
General Wiki: Tips and TricksHistory OptionTo the left of just about every WeRelate page is a History menu option, which leads to the Revision History of that page. What is the page all about and how do you use it? This page is for viewing what changes have happened to the page and to help you compare different versions of the page. Viewing the history is the easiest, just click on the History option and the Revision History page opens showing the entire change history from the page's beginning until its most recent version. What if you want to compare changes that have been made to the page? Say someone made four or five changes to a page and you want to see all of those changes in one comparison instead of looking through all of them individually. There are a couple of ways to do this.
You can also use the (cur) and (last) options for quicker viewing.
Inserting External LinksHow to make it look neat and crisp like Example 1 and not awkward like Example 2.
Here's how each example looks on the backend:
Put the name inside the brackets, but don't forget a space between the URL and the name. Inserting References to Sources in Body TextYou've seen the body of a page with so much narrative it would make your head spin and scattered among the narrative are footnote links. How are those done? It is pretty simple. They used the ref tag as follows:
For something so simple, you'd think it would be simple to remember, but if you don't use them very often... well, you get the idea. Wiki TablesSince I seem to return to the help page for this more times than I care to remember, I thought it would be good to put an example here for future reference. How to use a very basic table in wiki format... It's really quite easy, but I always seem to forget one step, that one step that makes it all break.
Wiki Page CreationNew U.S. Cemetery PagesHow to CreateNew cemetery pages can be created in a couple of ways and I will explain both of them here. These examples use cemeteries in the United States, but the creation method works for any country from what I've been able to determine. The first method utilizes the Add feature.
The second method is used when a cemetery is created directly on a person's page or some other page, which basically skips the above steps. Simply type the cemetery into the Burial field of an individual's page (Cemetery Name, City/Township, County, State, Country), save the page, then click on the Cemetery pages' placeholder, which will appear red on the individual's timeline. This will take you directly to the Edit page, which is explained next. This method has the advantage of bringing up the names of cemeteries which may already be entered in the automated drop-down selection box which appears as you type in any place. The drawback is that this list only contains the place names which match what you're typing exactly (or if the Cemetery has that exact name listed in it's "Alternate Names" box, which is not as straight-forward to determine from this list). Basically, if someone entered a cemetery as New Hartford Cemetery and you're entering the same cemetery as Hartford Cemetery, the list may not bring up the other cemetery in the automated dropdown box (unless, the New Hartford Cemetery has Hartford Cemetery listed in the "Alternate Names" box on the cemetery page). In any case, if duplicate cemeteries are entered, at some point these cemeteries should be merged when the duplicates are found, but efforts not to create duplicates are greatly appreciated. What to IncludeFrom here, both methods of creating cemetery pages merge into one, the all-powerful Edit page. The Edit page has a few options and entries that need to be made to create a standard Cemetery page.
Once these are complete, save the page and it's done! Optional Category InclusionsSome cemeteries may be further categorized with the following (including example pages): Ethnic / Religious
GovernmentMiscellaneous  |
