User talk:MyWikiBiz

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_date, 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)

Update What I'm really describing are 'occupational' infoboxes e.g. actor, author, artist, musician, professor, etc. It should be pretty straightforward to link these infoboxes to the occupational data element within the main infobox_person.

Ditto for industry infoboxes e.g. churches can have a an infobox for their particular NAICS code which links off the primary NPO infobox. Likewise for commercial enterprises within infobox_company, and government types (city, country, district, state, etc) from the primary infobox_govt. Centiare 15:03, 4 December 2006 (PST)

Just so I understand, would this mean that a person would always have an Infobox_Person, but if they also want to indicate they're an actor, they would have an ADDITIONAL Infobox_Actor on the page with just information that's useful for actors (and for which the community could establish guidelines)? Since you can build multiple infoboxes on one page, like this song page, I think that we have the best policy in saying that company, NPO, person, and government are fixed and approved Infoboxes, while anything else should be "addenda" to the fundamental boxes. --MyWikiBiz 06:59, 6 December 2006 (PST)

Yes, we lock in company, NPO, gov't, person, and property with std infoboxes. [I guess we now have person (entity/individual), place & thing.] All other infoboxes will be considered supplemental. Your song example should have a property infobox, then a song infobox.

Sidenote: if a song is in the public domain (eg Oh Sussana), then it it would be (a) placed in the Main space, (b) NOT have an infobox_property, (c) BUT have an infobox_song.

This type of organization will lend itself very well to further granularization for all types of listings eg actors, authors, recording artists, business groupings, etc, etc. Centiare 07:20, 6 December 2006 (PST)

Namespace policy

I put together a brief policy guideline covering when to use either the Directory or Main page namespaces. Please check it out here and let me know what you think. Centiare 09:22, 5 December 2006 (PST)

Updated per your comments regarding property (intellectual/real). Centiare 11:50, 5 December 2006 (PST)

Whom runs this site?

You might want to suggest to them to delete all Wikipedia content from the site. Wikipedia's content is created under a GFDL license, thus, they can't claim copyright over it, as they do now. -- Zanimum 12:30, 7 December 2006 (PST)

See my comments here. Centiare 13:52, 7 December 2006 (PST)

If you put in coordinates for ICR, then we can check the triple-search facility to see if it produces accurate results as the granularity of specific locations is reduced (ie scope out). I'm thinking I may have to reclassify lat/long from strings to integers so that the attributes can be searched as a range of numeric values (like population). Centiare 07:31, 9 December 2006 (PST)

Directory:ICR is updated with geolocation. --MyWikiBiz 08:40, 9 December 2006 (PST)

Looks like lat/long is already working as string values. ICR is 39.8... while MWB is 39.9... Searching on 39.8 produces only ICR, while 39.9 brings up you & MWB. At 39. it brings up all three. I always like it when things work out without having to deal with a new set of technical issues.

Btw, I'll get Google maps working so that they produce specific place markers. Centiare 14:00, 9 December 2006 (PST)

Geographical Categories

The string coordinates also work within an ASK query for ranges. Check out a query example here.