Forum:County Pages Idea

Forums: Index > Watercooler > County Pages Idea

I have not noticed this on this site, but then there is so much here I could have missed it. Perhaps we should have county pages for each county in a state. Have indexes of people and places pages from the county on each county page. Does this sound useful at all? --Will 23:52, 11 April 2007 (UTC)

Robin's first response

Will, that's the plan. But someone has to create them. I expect every county of every country deserves its own page, as soon as there's some material about the county. We should at least have a category for each county that reaches that stage, with subcategories and/or links to the indexes you mention; then a page (listed at the top of the category page) can follow as soon as there's more than a paragraph or so about the county. See Category:Allegan County, Michigan for an example of one of the many existing categories (which, like most, has no separate county page yet). (I don't think it's a good idea to have an individual's page in a county category unless he or she never lived anywhere else; but we'll see how it goes.) If you're writing a page about a city, township, hundred, or other place, please include its county category in that form. Some of the larger units inside a county may get their own categories eventually. Robin Patterson 15:36, 12 April 2007 (UTC)

So, do we have a master location starter? I would imagine a page to select country, when you click on that it has links to states/provinces, when you go to them you can click on counties, etc, etc. If we have a starting point, I could volunteer to start on making the links with basic pages. --Will 17:00, 12 April 2007 (UTC)

The "starting point" is Category:Places. But it's useful only for planning a category structure, whereas the creation of the categories is from the bottom up. I included a sentence (now in bold) above about how that happens. But Zeph has probably already created more than half of the U.S. state and county categories. What would be valuable as the next stage is to create a page about each county so that it can include descriptive material as well as links to related pages that aren't in the county category (such as a genealogical society that covers several counties). That page has its category link with an extra tweak - a pipe and an asterisk - so that it lists at the top of the category, eg [[Category:Allegan County, Michigan|*]]. Robin Patterson 02:05, 14 April 2007 (UTC)

Now see where I have started what may be the first county page: McCormick County, South Carolina. Please copy/improve as much as possible! Robin Patterson 04:54, 14 April 2007 (UTC)

Check out [1]. What we may want to do is a massive import from Wikipedia, cutting out a lot of the detail extraneous to genealogists---such as the FIPS codes. The nice thing about the Wikipedia treatment of this is that some nice person has included state county maps. Very helpful for genealogists. This maybe something that we can get from the Wikipedia management as a single download. Would certainly save a lot of time, especially if they included the state/county images. Bill 13:51, 14 April 2007 (UTC)

Bill's offering of tabular county lists

Not saying how to do this, but this problem was explored a bit previously. I've salvage some of the coding to create a page that displays a tabular list of US states, then a page with a list of counties for one state (Virginia). (Virginia is unusual. It has Independent Cities that have nothing to do with the surrounding counties. In effect, they are separate counties).

U.S. State Data

U.S. Virginia Counties

I would think that within each county you would want a set of data types, e.g., Marriage Records, Census Data, Cemeteries, etc. Before going very far adown the road on this you really need to think through the issues of how all of these pages are to be titled. If implemented this is going to be a very large project. Potentially many many thousands of pages. Getting it half built, and realizing that the name choices aren't the right ones, would create an awful lot of work. Its the carpenters adage: measure twice, cut once. Bill 19:35, 12 April 2007 (UTC)

Zeph's broadening of the subject

I would encourage people to take the "envelope" approach, it is familiar with everyone: start with the smallest and go to the largest:

Individual Name/Person

Street Address

(Township Name, if County is divided into Townships)

County Name

State/Province

Country

NB: For the United States, please use USA not US. "USE" - the United States of Europe - is talked about at least at the broad theory level, as is the United States of Southern Africa.

"USA" is a noun (which I don't mind seeing used wherever appropriate); for the adjective, please always use "U.S." - see the Central Wikia standards. Robin Patterson 02:29, 14 April 2007 (UTC)

Therefore, it would be:

Census Data for Willis County, Virginia, USA (this page can have = = subheadings for years = = )

Census pages are discussed at Forum:Census pages - no need to discuss them in detail here because they will be linked in a number of ways irrespective of what the page names are. Robin Patterson 02:38, 14 April 2007 (UTC)

Counties in Virginia, USA or List of Counties in Virginia, USA

or Townships and Counties in Virginia, USA (if Virginia has Townships)

Caution - unless they have compact pretty tables such as Bill displays below, these may be no better than the category listings. Robin Patterson 02:38, 14 April 2007 (UTC)

After further investigation, noting for example that Georgia has 169 counties, I think Bill's idea may have distinct value. We don't want 169 county pages (several starting with "C") cluttering a state page that is trying to list census and cemeteries under "C", for example. I'm going to follow the Wikipedia categories even more closely. Robin Patterson 04:54, 14 April 2007 (UTC)

Marriage Records from Robinson County, Wellington Province, New Zealand

Death Certificates filed in Cook County, Illinois, USA

See also: Cemeteries in Michigan

Respectfully, Zephyrinus 01:54, 13 April 2007 (UTC)

I wrote several paragraphs in reply but my ISP cut me off and I hit the wrong "refresh" sequence and lost the lot. See you tomorrow. Robin Patterson 13:42, 13 April 2007 (UTC)

Cautions from Bill

This is not a trivial problem. To solve the problem someone needs to understand more than anything else, how the dataset is going to be used by the majority of end users. That's the majority of end users---not how you personally would use it, because your needs may be different. No scheme is going to be efficient for every user, and no scheme is going to be efficient for every search conducted by any given user. The objective is to make the scheme match the most common needs of the largest number of potential users. Hard problem.

Usually, what you want to do in setting up an access scheme is to find the item that most folks are going to key on first when they start looking for information, and place that item first---sort of the largest common denominator that will help people with the least amount of information to drill down to the actual information that they need. If you pick the right scheme most people are going to be able to drill down quickly to the information they want. If you pick the wrong scheme, you end up with a lot of frustrated people. And you don't want frustrated end users---because they soon stop being end users. Bill 16:17, 13 April 2007 (UTC)

"Search" may be the "key" word, so to speak. If the search box function is working properly, the precise form of the page names is not important for searchers, as long as the page name reasonably describes the contents and therefore allows the searcher to choose the right hit and probably not need to "drill down" at all. For example, a page called "1840 census" may contain very little actual information but it may be the best-looking hit in someone's list and must therefore have links that help the reader find most or all of the other pages on the subject of "1840 census". Robin Patterson 02:58, 14 April 2007 (UTC)

Where page name consistency scores highly is where a searcher is browsing categories or lists. If the word order is consistent, the searcher will soon work it out and know which part of the list or which subcategory to jump to. But if it's a jumble, like the pages in the "WeRelate" category list I referred to at Forum:Census pages, the whole list has to be browsed, which is OK if it's half a screenful but not OK if it's many screenfuls. Robin Patterson 02:58, 14 April 2007 (UTC)

Where to use complete names, not abbreviations

Sounds like this is out of my hands. But it does lead me to another question. When we enter place names in our genealogy pages, should we be typing out the words completly. As an example:

Polk Township, Atchison County, Missouri

instead of

Polk Twp., Atchison Co., MO

--Will 19:33, 13 April 2007 (UTC)

Elrondlair---I don't know about that. Seems like this is a user driven site, and its a group kind of thing. We just happen to be touching on a significant issue. I've concluded that I don't personally want to spend the time working collateral developments. Developing this site as a data base could be a fairly heavy duty task, and would need many folks working on it. YOur thoughts on this are good, so are Zephyr's, and of course, Robin's. I don't know what the right answer is. But at the moment, I'm not in a position to think it through. So I've just made some observations. I suspect that Zephyr's Cemetery page is going to pave the way for people interested in other aspects of the problem. And I really don't want to put a damper on anyone's contributions in this area. So perhaps I should just shut up. If I'm not willing to cook, perhaps I shouldn't comment on the cooking.

On your final question, I'm fairly sure Robin would go for the full spelling. I personally am not consistent. Bill 19:49, 13 April 2007 (UTC)

Yes, full spellings for anything that could end up as a link to another page. Our place pages and categories should match the Wikipedia page names wherever practicable so as to minimise the amount of changing we do when copying from WP. But second and subsequent references within the text need not be in full. (They can still be links, though, if you use a pipe, eg: [[Polk Township, Atchison County, Missouri|Polk Twp]]). Robin Patterson 03:07, 14 April 2007 (UTC)

Back to state and category pages and nesting

Well I could make state pages, but I am not on how to make things a category page. If it can be made a category page later maybe I can help. As for spelling thing out, I think personally I will start spelling out everything, before I get too many pages on here to change. --Will 19:52, 13 April 2007 (UTC)

See above (my second response). Robin Patterson 02:05, 14 April 2007 (UTC)

I've probably succeeded in confusing things. There are two (perhaps more) separate problems here. What I was really thinking of was the way that you nest article sets. What others are talking about (and I probably inadvertently slipped up and started talking about as well), is the name of the article itself. For the article name, its not that critical, but generally I think Zephyr's envelope idea has real merit. Its also easy to remember since it follows the style of a mailing address: eg., Cemetery Name:County:State:Nation. For a hierarchy of articles, each set of articles placed in separate "folders", you probably want it the other way around to facilitate accesses: Nation:State:County:Cemetery Name. There the start I pointed to

U.S. State Data

USA Virginia Counties

Works well---but incorporate Zephyr's point about U.S., versus USA. But then, where do you put the Data Type? is that a series of subsets under counties (ie, all cemeteries in the county, all marriage records for the counties, all....? If you do it that way, then when some one is looking up data for a person born in Rockbridge co, then they have it all together in one folder. But maybe you want the data type to occupy the highest level of the hierarchy, e.g,

[[USA Cemetery Transcriptions}}

USA State Cemetery Transcription

USA Virgnia County Cemetery Transcriptions

Bill 23:00, 13 April 2007 (UTC)

---