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. Note that I took out company_name, so you show up as well. This raises an interesting point: while industry portals provide a good entry point, they don't serve pure geo searches regardless of entity type (biz, person, etc).

I'm thinking we may want to create some geo categories where ASK queries can reside, such as country, state, city, & coordinates. It also suggests we may want categories to segregate private vs public companies, commercial enterprises vs NPOs, etc, etc.

Of course, these types of searches could all be done within NAICS, but then it would only be companies classified within a particular NAICS. If one wanted to perform a global search outside the std industry parameters, categories may be the way to go. Thoughts? Centiare 16:42, 9 December 2006 (PST)

Not trying to be flip, but I just had two quick reactions (and I'm really, really tired) -- (A) If you mean traditional "Categories" as on Wikipedia; I thought semantic tagging would liberate us from the mess that categories are? And, (B) aren't these various searches best left to the future Centiare community to ponder and implement? --MyWikiBiz 21:42, 9 December 2006 (PST)

Valid points. I believe (page) relationships are an attempt to address WP's weakness and lack of organization in categories; attributes are more specifically related to actual data values.

As such, some primary reports need a home not only to produce general information, but also to provide pointers & tips to others wishing to develop their own queries. My question was: where do you think we should put some of these queries?

For example, one could put an ASK query listing of all Calif entities under the California main page, a project page called California, or a category called California entities. I think limited use of categories for our purposes may be the way to go. Centiare 07:23, 10 December 2006 (PST)

Okay, then. I think that ASK queries on each of the 50 states would be plenty good to provide an "example" for users wishing to develop queries, plus be mighty interesting for even the users who aren't. I think it should go on the California (Pennsylvania, Florida, Colorado) Main space articles, and that we should try to hold back on resorting to categories yet. Additionally, I agree that an ASK query on each of the Main pages related to public for-profit, private for-profit, non-profit, and people would be very useful and interesting. Of course, as Centiare grows, these queries are going to produce almost TOO many results to be useful, and that will be a lovely problem to have! --MyWikiBiz 15:07, 10 December 2006 (PST)

Today's Featured Article

As you can see from TFA archives, I'm rotating the basic five commercial, NPO, gov't, person & property Directory examples. As you or others complete listings, I'd be happy to put them on the roster. Centiare 08:50, 11 December 2006 (PST)

I don't know if it's really ready for prime time yet, but there is Directory:Zale Corporation. --MyWikiBiz 08:54, 11 December 2006 (PST)

Perfect. At this point, all the TFAs really need are a graphic, starting paragraph and partly completed infobox (with some semantic tags). Btw, you can add TFAs yourself to the archive/staging page.

Note: the convention I'm using is (1) reduce the graphic size; (2) add a link from the first reference; (3) remove external links, templates, etc (they'll render on the front page and mess up the order); and (4) add the ...more. Compare Zales TFA & Zales Directory page.

Btw, for Zales & others, I'd add a space between NAICS: and the first NAICS reference. It was pushed over for IBM to fit all 4 on the same line.

Centiare 09:20, 11 December 2006 (PST)

Resume Listings

Greg, as you can see, I added a few more infobox_Person semantic tags to your personal page. Would you like to create a separate resume section in order to experiment with CV formatting? We now have the following semantic tags for each employment period - please make edits/recommendations as needed:

• naics_code1_title (occupation)
• naics_code1
• job_title1
• employer_name1
• job_period1 (eg 2001-present)
• job_years1
• salary1

I expect there would be lots of searches on occupation & experience (ie job years).

Btw, please feel free to add add'l attributes as needed - 2,3,4... All you have to do is copy the existing attribute page, create a new page in the series, paste & save.

Personal Attributes

OK, made a few more tweaks to the infobox_person and added some more attributes. Please take a look at your listing and think about which items should be moved to either (a) add'l personal info (Infobox_Personal) and (b) detailed job information (Infobox_Resume).

I think most of the info now in your infobox should be moved out - it's starting to look very busy. I think we should have something fairly spare that really pops out at the reader. They can scroll down for add'l info. Centiare 08:03, 14 December 2006 (PST)

Greg, take a look at your directory listing. I broke out some elements from infobox_person and put them into infobox_personal. Next, I'm going to pull out the occupation stuff and put it into a new infobox to be called, 'natch, infobox_resume. I think the infobox_person looks real clean and provides a good snap impression to anyone browsing the site.

One happy realization of the power of both infobox_personal & resume is that registered users can use them on their user pages without having to create directory listings. See mine here (assume I had an ID like eshock). Why is this an advantage? Anonymous listings baby. Think about resume searches and/or MySpace types of personal interest searches. Centiare 11:42, 14 December 2006 (PST)

Specialty Attributes

In your annotation overview, you may wish to explain some of the advantages of using ordinal identifiers (Centiare convention is numbers) to differentiate certain attributes. The two general cases are: (a) when values are variable/non-standard eg job titles vs movie titles (which means one searches on attributes, not attribute values); and (b) when attributes have relations to other attributes eg key person<->job title.

In this way, friends/interests don't require ordinal identifiers, unless at some point there are secondary attribute relations, eg friends<->gender, interests<->summer/winter, etc.

In addition, you may wish to point out that subjects such as interests can also be semantically tagged as relations, since common Directory or Main pages can be interlinked to multiple users via ASK queries (see Skiing, etc). Centiare 10:40, 3 January 2007 (PST)

I added some explanatory notes covering ordinal identifiers in the custom tags help section. Centiare 07:53, 9 January 2007 (PST)

Final Edits

Greg, please take a look at your Directory listing. We need to do a few things: (a) finalize person, resume & personal infoboxes; and (b) finalize your info. I guess there are two primary questions: (1) are we picking up all information we need? (If not, what needs to be added?), and (2) where should it be placed?

Please note that we don't need to spend too much time formatting the infoboxes. As long as the (complete list of) data elements are being captured, the infoboxes can always be edited/reformatted as part of an ongoing process.

PS I messed up your coordinates - I copied your church's over for placeholder values. Centiare 18:10, 14 December 2006 (PST)

Special Characters

MW doesn't like & in article titles, so your Family&Workplace Connection listing couldn't be loaded. See headings. I changed the title to Family Workplace Connection for now. Perhaps you could put 'and' in instead of the & until I get David to make the appropriate Apache fix. Centiare 02:24, 15 December 2006 (PST)

Fixed it myself. See The Family & Workplace Connection and Karl Nagel & Co. for examples. Centiare 16:41, 19 December 2006 (PST)

Internal Links

I finished putting together a little table that summarizes whatever internal links someone wishes to summarize. The same feature could be generated automatically by categories, but that would require users clicking through to another page rather than seeing a nice summary on the entry page. Likewise, the same report could be generated by ASK if we had something like a page_author attribute tagged on each page.

Right now the template is limited to 5 entries, so I'll have to go back and modify it so that it's open ended. However, it should work quite nicely for now for people wishing to summarize key entries. Centiare 12:36, 19 December 2006 (PST)

Semantic tags

Considering the (apparent) positive impact on Google SEO, I would recommend that you build into your various directory pages:

1. Intra-Centiare wiki-links
2. Semantic tags (even the State of Georgia "belongs" to Country:USA, you know?)

Keep having fun, OMG. --MyWikiBiz 09:52, 9 January 2007 (PST)

Question

Still not understanding how to create semantic tags outside of an info box. --OmniMediaGroup 10:29, 9 January 2007 (PST)

Just type

[[city:=San Francisco]]

to create the attribute San Francisco or

[[Personal Interest::Skiing]]

to get the relation Skiing.

As an added plus, you can add more information to attributes so that they record not only the actual value, but wikilink back to a main or directory page. Example:

[[city:=San Francisco|[[Directory:San Francisco|The City]]]]

produces [[city:=San Francisco|The City]].

Notice how traditional wikilink pipes work as usual? For more information, you can check this page as well. Centiare 10:49, 9 January 2007 (PST)

And Karl beats me to it

You can just "do" them, within the text, inline. For example, if I were to mention Van Doren Oil, I could also just as easily mention [[Legal_Name:=Van Doren Oil Company|Van Doren Oil Legal Semantics]] and sneakily squeeze in a Legal_Name attribute, or mention [[Web:=www.vandorenoil.com|Van Doren Oil Website Semantics]] and sneak in a Web attribute.

Or, you can just create a sematic "field" in an out-of-the-way place at the end of the article, like this:

Semantic attributes

• Year started -- [[Year_Started:=1939|1939]]
• Primary NAICS code -- 45431

Either way, it should automatically create the RDF "lookup table" at the bottom of your page (it's not doing it here, I guess, because they are set not to render on Discussion pages?), and that's (I think) what starts the Google SEO algorithm a-buzzing. --MyWikiBiz 10:57, 9 January 2007 (PST)

Upper or lower case

I've noticed that some tags are all lower case, some all upper case, and some are mixed. Does this matter when tagging? --OmniMediaGroup 11:04, 9 January 2007 (PST)

The official attribute style is all uppercase. We're just getting started on relations, which is why some are upper and others are upper/lower. When referenced within text/infoboxes, they follow existing wiki convention ie first word converts to upper case, while remaining need to be of the same case (upper or lower). Centiare 11:21, 9 January 2007 (PST)

Year_started

Hi, the starting year of an activity is marked as required - but I don't have that information for many businesses where I have the basic data to be put online. Also many companies here in town would probably like to be in the directory, but for now don't have e-mail and website. How to deal with these? Thanks! --SabineCretella 03:54, 13 January 2007 (PST)

In cases where you have allowed for a semantic attribute for which you have no data, you have two simple choices:

1. You can leave the data field blank, and the attribute will not render in the page. (Probably your best choice, if you anticipate that one day you will have the data, and you'll come back and complete it.)
2. You can remove the attribute altogether. It won't hurt any infobox to remove an attribute element. (Probably a good choice, if you believe that the attribute is irrelevant and/or that you'll never obtain that data point.)

I hope that this helps answer your question! --MyWikiBiz 06:26, 13 January 2007 (PST)

Sabine is referring to the template itself where 'founded' is a required element. As you say, one can still choose whether or not to use a semantic attribute within any of the templates/infoboxes. In this case, founded is required because potential customers typically want to be able to determine the number of years an entity has been in business. I would suggest that Sabine use a general date if a specific date is not available at this time. Centiare 07:14, 13 January 2007 (PST)

Whoops, I forgot that in some Infoboxes, certain elements are required, or rather, even in their absence of data the field label will still show up. Yes, it seems that either "living with" the empty appearance of the label, or filling in an estimated date, are the only solutions (other than Centiare modifying the template to not require this field). --MyWikiBiz 07:44, 13 January 2007 (PST)

I reviewed the infobox trying to recall why founded was a required field. I initially considered changing it to variable, but then remembered that we definitely want a consistent record of the number of years in business for all listed entities. Centiare 08:07, 13 January 2007 (PST)