Old comment

Looks like you've successfully ported over an infobox for Mr. Sagan. If you figure out the ASK parser to handle subqueries, you're going to soon become armed and dangerous. PS Hopefully, we'll have file upload working tomorrow to start building out graphics. I'm really interested in uploading Adobe/MS Office type docs - it could become invaluable for catalog info, ad runs, coupons, presentations, etc. --Centiare 21:18, 16 November 2006 (PST)

BTW

I've been posting comments under your Directory_talk:Gregory J. Kohs listing. Centiare 08:52, 3 December 2006 (PST)

I've moved those comments here. --MyWikiBiz 18:42, 3 December 2006 (PST)
Your Directory listing looks good. You might want to double check some of your data elements - it looks like you have some company type attributes. People have add'l info tags eg birth city along with city (residence), person_first_name instead of person_name, etc. Centiare 07:53, 4 December 2006 (PST)

Copy from Gregory J. Kohs discussion

The residence link in the infobox_person was missing - the template wasn't as well constructed as infobox_company. I went through the template and tuned it up + made a few modifications. Let me know what you think.

If you'd like, feel free to create new attributes for birth_date, birth_place, death_death and death_place. Centiare 08:32, 3 December 2006 (PST)

I ended up creating these attributes for Carl Sagan. Feel free to update your site using the respective attributes.
Note: the first birthday/deathday reference includes month/day -> we want that reference style so that days are sub-pages of months (for almanac reports eg births, deaths, etc). However, to search specific attributes, month & day have to be treated separately. That's why the last category 'reference' is used as a placeholder to record specific values. Centiare 12:30, 3 December 2006 (PST)
We will probably have to discuss this "month/day" format, or I will have to spend some time thinking about it. I just don't understand it yet; but as a layman, it just seems awfully odd when we get these pages like "December/20". But, you're saying that the Wikipedia method of "December_20" would not work well within semantic search? I guess I get it -- people may want to search for either December, or December 20, but if the label is "December_20", that won't work for the "just any December" searches. --MyWikiBiz 18:47, 3 December 2006 (PST)
Exactly. December_20 & December/20 aren't really that different from a straight text reference perspective. Actually, I think Centiare's method is better, since day dates are natural sub-pages of months. Either way, once a reader is on the Dec 20 page, ASK can run queries on that specific date eg births, deaths, etc. That is, as long as the semantic tags record the individual data elements as to month, day & year. Centiare 07:57, 4 December 2006 (PST)

Edit notes

You'll notice that the Template:Country data US is placed after locations in infobox_person (instead of before as in _company). That's because birth location is below birth date - the flag looked weird hanging out in the open. Play around with the placement if you'd like. Centiare 08:39, 3 December 2006 (PST)

Legal notes

Note that persons within Directory listings using infobox_person should provide contact & reference information. That because even if they're dead, by definition, if they're within the Directory namespace, that means they have commercial value; ergo there should be contact info + reference information.

For example, Carl Sagan has a link to his estate that generates licensing revenue from his name/works/image. OTOH, Newton is public domain, so he shouldn't be listed under Directory - rather, he should be included within Main page articles.

I guess we (interested?) could create another infobox_person for Main page entries - ie no longer any commercial rights. There's a lot of stuff in infobox_person that could be cleaned up/removed to create a new version for non-commercial public figures. Centiare 12:30, 3 December 2006 (PST)

Occupational Codes

Should we use NAICS as occupational codes or go full bore and incorporate official occ codes? I think I already know the answer you're going to give me. If that's the case, should Portals be NAICS or a level above that branch to NAICS & OCC?

Off the cuff, I'd rather just add a link to Individuals (ie occ codes) from the main portal entry - sort of like a special sub-portal. Centiare 09:29, 4 December 2006 (PST)

Just moved this section to the bottom. That's the wiki "policy" -- new threads always go to the bottom of Discussion pages.
Assuuming that by OCC, you mean the Census classified index of occupations? Or, perhaps you mean the BLS's Standard Occupational Codes? Either way, if you look at those links, I don't see any granularity between a Board Chairman, a CEO, a CFO, a CIO, or a Railroad Commissioner, for that matter.
If I'm understanding you correctly, then I would agree that a link to Individuals (with the wide array of different occupational codes, so that we can accomodate a chiropractor, we can. However, wouldn't the chiropractor more simply just align himself (sorry for the pun) with the appropriate NAICS code of 62131? I'm unsure at this time, but currently I'm dubious of Centiare encouraging individuals to identify themselves more by their occupational role than by the NAICS Industry they serve. --MyWikiBiz 09:51, 4 December 2006 (PST)
Greg, these are the types of answers I like. KISS would suggest using NAICS, but OTOH, one doesn't want to take shortcuts that miss picking up crucial data. (That is, if OCC added add'l granularity; but, as your example points out, NAICS really does define what an entity does, whether it's a company or individual.)
If we stick with NAICS, then not only do the Portals remain as they are, but ASK queries can then produce listings based on either person_names and/or company_names. Even better, since I know you're wondering, we could search for people within companies. Like I've said before, the sky really is the limit once individual data elements are captured. Centiare 10:00, 4 December 2006 (PST)

Infobox Proliferation

I was experimenting with infobox_actor for Marilyn Monroe when I realized that these types of individual infoboxes are all just derivative templates from the primary infobox_person. That is, they shared 90% of the same info such as birthday, occupation, etc. with the only differences being that actor had some data elements for movies, etc.

However, there is a BIG problem at WP as far as consistency that we really want to avoid. To be more specific, infobox_person uses birth_day, while actor was birthday. Not only is this bad for templates, but it's really compounded with semantic tags.

The solution is to create a very firm policy covering 4 or so primary infoboxes that should always be used as baselines: company, NPO, person & government. Actors could then use a specialty infobox_actor to cover items specific to that biz (IMDB could provide a good data schema), while churches could have their own in addition to the std NPO.

Let me know what you think. Check out Marilyn Monroe for a good example. Centiare 13:56, 4 December 2006 (PST)