Forum:Births in (location)/Deaths in (Location)

Forums: Index > Watercooler > Births in (location)/Deaths in (Location)

Was just wondering if we want to make categories for births and deaths in certain places? I would suggest just using a state or province. This could aide people looking for certain surnames in states.

Examples : People born in Kentucky, United States of America People born in Lancashire, United Kingdom

etc

Will 03:59, 4 November 2007 (UTC)

I think this is a good idea. Also, I think we can probably automate the creation of these cats, especially if we can get folks to use AMK's person infobox template. As I recall, it explicitly declares birth and death locations. ~ Phlox 06:01, 4 November 2007 (UTC)

I like it too. May need some tweaking of AMK's template, but the idea's great. Some of Will's examples above are longer than necessary: where we have a standard location name, such as "Kentucky" or "Georgia (U.S. state)", it should usually be part of any derived name such as this, so that it can be incorporated and manipulated using "magic words" such as {{PAGENAME}}. See Genealogy:By location category scheme. Robin Patterson 05:04, 7 November 2007 (UTC)

Greene County, Ohio gives an example of how such local cats can be generated automagically, and how they will help plug contributors into the local context and local community of contributors. When we have millions and millions of GEDCOM inputted names, state births will not be enough. At that point, we can flip a switch in the Template:info categories which will generate the county events.

Is there a way you can make your info box wrap around? As it is now we have to scroll horizontally to see everything. Thanks Will 00:34, 11 November 2007 (UTC)

• Looking at the top of the page, the navbox has a row People: Click Births and you will see the category for births in that county. Contributor is plugged into the local context, and has all the resources for researching more about the relative in the navbox. Also contributors can ask questions on the forum for that community.
• For the technically minded, this auto generation works because we have extracted and encoded "|Birth county=Greene" for Catherine Price (1809)/info. The WP categories have normalized naming (at least for CAN and USA, they are always of the form "Category:XXX County, STATE/PROVINCE") which we have leveraged, so we can generate the birth category name via algorithm. I don't expect folks to laboriously encode Birth county, Birth state Birth country, and so a Bot will do this for them. Description of the algorithm is on User:PhloxBot/_Proposals#Auto recognition of Place. Contribute on the talk page if you have opinions, or change the description of the algorithm if you have a better way/ enhancements of the means of extracting these.
• We can roll out this extraction without moving folks over to understanding info pages. The bot would simply extract the dates, create the info page, and place an Template:info categories at the end of the article.

~ Phlox 18:20, 10 November 2007 (UTC)

Coming along nicely. (We don't need millions of names before dropping to county level!) --Robin Patterson 23:54, 10 November 2007 (UTC)

I hope that county categories for births and deaths will be in addition to the state ones and not replace it. Some families spread out a little, and it would be easier looking up a surname in an entire state than each individual county. Will 00:34, 11 November 2007 (UTC)

I agree with Will there. Another reason is that a birthplace derived from a census may specify only a state, not a county. Robin Patterson 01:30, 11 November 2007 (UTC)

I agree with Will before he said it. That's why you will see the example character, Catherine Price (1809) was already Cat'd that way.

Births in or Born in?

I prefer "Born" -

1. a birth was a birth in a place but a person was born in it
2. two characters fewer

If Wikipedia has an equivalent of either, I'd adopt it. Robin Patterson 01:30, 11 November 2007 (UTC)

Born or Birth is a question of whether noun form or verb form. Our precedent is Births, eg Category:1991 births. So what kind of consistency is that? Births one place, but Born in elsewhere? Before you start to frown Robin, I'll spoil the suspense by telling you that I'm going to agree with your POV, but I want to give a fair survey the arguments on either side here....

Multilingual Commons, English and French WP make noun form dominant. But consider de:category:Geboren. It's verb form for German (eg. Geboren), Spanish (Nacidos) and Russian. There are Cats for lots of "stuff" by "time period": Births, Deaths, Crimes, Musicals, Actors, Comics- all by year, decade, century. From a literary perspective, active verbal forms enliven a domain- so Born in Ohio, Died in Ohio, Married in Las Vegas... is much less stale than Ohio Births Ohio Deaths, etc. We have a kind of dusty domain here, so anything we can do to breath life into it is a plus. So I agree with Robin's instincts on this- I vote for Verb form wherever possible.

A quick look didn't show any events by location pattern on Wikipedia. The pattern of course for events by time is ("Date" "event"), and I think some folks were following the symmetry of that by catting as "Ohio Births".

This falls into the Placename category scheme, but just to recap:

Pros/Cons:

• "Placename" "Event"
  • Pro:
    • Symmetry with "Time(Century/Decade/Year)" "Event" eg Category:1991 births
    • Species-Genus order for events. Puts the differentiator up front easing visual scans for particulars.
  • Cons:
    • Symmetry is only with the non standard en-wp time scheme. All other Euro- French, German, Norwegian, Russian- you name it- even Arabic (though right left) all do the Event - date form.
    • Will produce some awkward category names France Deaths seems ok, but France Actors does not.
    • Temptation to use the adjective form if placename is found in this position.

• "Event" "Placename"
  • Pros
    • Can be applied uniformly: Deaths/Died in France "Actors"/Acting in France
    • Is Genus/Species- the more traditional style of ontologies (although the main advantage of this is now obsolete- that this form is convenient for manual lookup and classification systems eg card catalogs/ library shelves that are irrelevant to the internet).
  • Cons
    • Assymetrical with Time schemes "Time" "stuff" order.
    • Creates long names- requiring prepositions in European languages
    • Less convenient for online use, since it is Genus/Species order: the differentiator is buried, making visual scans for the distinguishing feature more difficult.
    • Sometimes preposition choice is not clear- Museums of Russia, but Paintings from Russia.

So this is very longwinded- sorry but we are making some huge ontology decisions here, and I just want to make people aware of that.

Conclusions:

• My opinion is "Born in". "Died in" "Married in".
• For consistency, everything should be Event first order, should be Born in 1991 as much as it is Born in Ohio.
  • PhloxBot should move all the time categories to the same form. Born in 1991, following the Arabic/German/Spanish/French/greek/Russian/netherlands/norwegian/portugese WP standard.

We are going to have to do a Cat move though- because I don't think I was the only one making the error of using the Placename Births (Ohio births) form. ~ Phlox 07:19, 11 November 2007 (UTC)

Thank you for all the detail. I'd add the following points:

1. "Will produce some awkward category names France Deaths seems ok, but..." - part of the "but" is that "Zillah, Yakima County, Washington deaths" is fairly unnatural whereas "Deaths in Zillah, Yakima County, Washington" is an OK pagename, as is "Died in Zillah, Yakima County, Washington".
2. Changing the "1991 births" back to "Births in 1991" or to "Born in 1991" may muck up several related templates such as the ones that calculate navigation to nearby years and decades; do templates all take kindly to redirects? (I changed a couple to go with "Brths in ...." but saw how undesirable it might be to go on with that indefinitely; that was part of what made me turn towards the WP standard.
3. Consistency is not a be-all and end-all but is good as long as it does not make phrases too unnatural or hard to remember

Robin Patterson 09:30, 11 November 2007 (UTC)

Consistency means predictability for newcomers. Predictability means they can find stuff faster, get frustrated less often. If it was just anal retentiveness, I could care less.

I can deal with the template situation- if you list them for me I will have new versions ready to go when we do the switchover. Cat redirects as you may know don't work like page redirects, so it is a more complicated transition, but for a bot it is not a big deal.

Again- that's what makes this sort of decision less painful. Instead of the worry that we may be making a mistake that will saddle this wikia with problems for decades to come, we can know that folks can decide differently in the future. We can just do this, try it on for size and if it doesn't fit, we just try something else. Much better to do it when we have a handful of contributors per day rather than thousands per day. ~ Phlox 16:32, 11 November 2007 (UTC)

Are we agreed on the proposal that the time cats should be moved? If so, I can run the bot to put warning template on all the cats in violation of the Thing of (place/time) scheme, and refer any interested parties to this thread. How does that sound? ~ Phlox 17:01, 11 November 2007 (UTC)

I have not been the best one for putting categories on my pages that I do, but lately I have been trying to be more proactive. I used to have Births in 1968, started to change things to 1968 births when I saw people were doing that. Honestly I don't care which way it is, I just wish a choice would be made on the correct way to do it. I am already getting confused by which of my pages I have updated or not. I say this with smile in case anyone reads this more harshly than I mean. Will 19:35, 11 November 2007 (UTC)

Not to worry Will. The bot will change any that need changing to whatever format is decided on. As for cat'ing the places or the dates, don't worry about that either for the time being. The bot should be able to pick out most dates and places, just so long as you are using a template that makes it clear what the dates and places relate to. I know the AMK's infobox template makes this clear, but I haven't really studied the others. I'll be doing some tests over the next few days to see how good autocatting can work. It won't be 100%, but it may get us a long way towards where we want to be in upgrading our data. ~ Phlox 22:55, 11 November 2007 (UTC)

I looked at some of your articles Will. I am a little more concerned about them, because the way the template was set up (grumble), it is free form text. This means it is more ambiguous for a bot to figure out what is what. Fortunately, your style seems fairly uniform, so I should be able to program it to pick up the locations and dates from your articles. However, I would like to put in a word for going to something like AMK's infobox style of article. It would be possible to convert this style over to Infobox style via bot, but of course only if you don't mind a format change. ~ Phlox 07:50, 12 November 2007 (UTC)

Hehe, sorry you don't like my template. No offense to AMK but I kinda like mine better just for looks. I don't mind changing my categories as I go along now that is seems you guys have decided the format. Will 03:20, 13 November 2007 (UTC)

It's not the looks, but the fact it doesn't use fields. Your template could look exactly the same but be much more reliably scannable if it were encoded that way. But whatever- if you are upgrading your own then it doesn't matter because I don't have to write any code to extract the data. That's fine with me. I like less work. ~ Phlox 04:37, 13 November 2007 (UTC)

Well I do like a challenge. If I were to make a template loosely based on William Allen Shade (1968- ) would this work for your bots? I probably should have made a more generic starter page, but I was just doodling around. Thanks Will 05:51, 13 November 2007 (UTC)

Sure thing. By far the most perfect thing is if the fields (parameters) are named the same as the infobox persondata thing. If there are more field names you need that aren't on that template, you will find a fuller list in here. It's not complete- I have some notes on fields needed for nobility, and some things like residences and occupation lists that Gedcom 6 has. ~ Phlox 08:56, 13 November 2007 (UTC)

Ok just wanted to see what you thought of this page - Genealogy:Person Infobox Template Will 02:34, 14 November 2007 (UTC)

There is something funky about the table because with Firefox it wipes out the right hand bar. On IE it coversthe adverts on the right which is a big no no. As far as the structure- I suppose it is better than before because at least in a table folks probably aren't going to mess around with changing the row names. But they could, unlike if they were stored in parameters. But anyway- from the bot scanning perspective- your new template is easier to scan than free form text where folks are tempted to change everything.

Forum:Talk about Greene County, Ohio

That's right. Forum naming will conform to the placename scheme.

Part of the rationale is technical. The way Forums work, the name of the forum also creates a category- which in turn is used to generate the messages list. Since it is a category, the forums will have to be named accordingly. It used to be '(county name) queries" Now it shall be "Talk about (countyname)"

"Talk about" has a tone more inviting for anyone wandering by to get chatty. The former name eg "Greene County, Ohio queries" was self limitting- even "Messages on Greene County, Ohio" was dead sounding. Verbal form seemed get us closer, if anyone has a suggestion for improvement, please chime in. This will affect 3300 forum names for the US, and it is going to be a global pattern affecting many more. Forum:Talk about Greene County, Ohio ~ Phlox 07:50, 12 November 2007 (UTC)

Sorry I missed noticing this one. I do like the "Talk about" idea, and I'm pleased to see it now in effect. Robin Patterson 00:55, 6 March 2008 (UTC)