Difference between revisions of "User talk:OmniMediaGroup"

MyWikiBiz, Author Your Legacy — Friday November 15, 2024
Jump to navigationJump to search
Line 41: Line 41:
  
 
::::Thanks for all the new Attributes and Relations. The ASK query at state level is pretty slick!--[[User:OmniMediaGroup|OmniMediaGroup]] 14:05, 12 January 2007 (PST)
 
::::Thanks for all the new Attributes and Relations. The ASK query at state level is pretty slick!--[[User:OmniMediaGroup|OmniMediaGroup]] 14:05, 12 January 2007 (PST)
 +
 +
===Attributes & Relations===
 +
Karen, I'm in the process of writing up [[Centiare:Semantic_tagging|guidelines]] for creating custom attributes & relations. Since I haven't completed it yet, I'll step in here real quick to provide a brief overview.
 +
 +
One thing I'm going to emphasize is the decision one must make between creating an attribute or relation for non-numeric values. That is, the logic is pretty clear about creating attributes for values like population, revenues, etc.
 +
 +
Where it can get a little fuzzy is if the value '''''could be''''' a relation (ie target page in which to create a relationship between articles). In this case, you can still choose to use an attribute, like CEO for a job title, BA for degree, etc, rather than a relation to main space articles that define/explain the meaning of those terms.
 +
 +
In the case of recipe_name, you start moving down the path closer to creating a relationship, especially if you anticipate creating stand-alone recipe pages in the future. Situations where relationships already work really well can be seen with the city->county->state->country roll-ups, etc.
 +
 +
Finally, there's the issue of ''ordinal'' identification ie situations where there may be multiple values '''OR''' associations between values, such as degree(s)<->year(s). Right now, relationships don't handle either very well (typically, they need an additional category identifier), but attributes are just the ticket. So even if something was logically a relationship, if you're going to have a complex data set, you may decide to use attributes instead. [[User:Centiare|Centiare]] 09:11, 13 January 2007 (PST)

Revision as of 17:11, 13 January 2007

Karen, Greg mentioned that you may be interested in some other MediaWiki extensions. Feel free to forward any recommendations/suggestions you may have.

What I'm particularly interested in is adding both Craigslist type classified advertising & eBay like auction marketing to Directory listings, along with the youTube extension.

You probably know where we're going with this - if you come across anything, could you let me know? Otherwise, I may have to cobble something together myself from scratch. Centiare 13:41, 11 December 2006 (PST)

Subsidiary listings

Karen, I've been talking to Greg about an easy way for you to create separate listings for your various blog properties, and then summarizing them at your primary Directory listing. You can see an example schedule at MyWikiBiz. We can go over a slightly more automated approach if you're interested. Centiare 13:38, 19 December 2006 (PST)

ASK

Example of others that have listed OMG as a friend:

<ask> OmniMediaGroup </ask>

This is exactly how one would create a query to list all subsidiaries of a given company, properties/websites/blogs controlled by an individual, papers/presentations given by an academic, etc.

Family on Centiare

Based on a conversation I had with Dad this morning, I think we're mere hours away from him opening an account on Centiare. Pretty amazing when a new Internet space utilizing the cutting edge in semantic technology can draw in a 73-year-old man whose most recent programming tasks were probably in COBOL. --Gkohs 08:58, 30 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)
Karen, I went ahead and created the following four relations for the state listings. You can link through to each one, as well as the relation definition itself, which has a summary ASK query:
I've updated your North Carolina listing for these 4 tags. I also created Attribute:Year Admitted as a replacement for Year Started. If you want, I can create four more attributes along the lines of city of, has city, has county, & county member of. Let me know. Centiare 12:26, 12 January 2007 (PST)
I went ahead and created Relation:County Of, Relation:Has County, Relation:City Of & Relation:Has City. Note that cities only have to be listed under counties - an ASK query at the state level will list counties & their respective cities. See Directory:California for an example. Centiare 13:57, 12 January 2007 (PST)
Thanks for all the new Attributes and Relations. The ASK query at state level is pretty slick!--OmniMediaGroup 14:05, 12 January 2007 (PST)

Attributes & Relations

Karen, I'm in the process of writing up guidelines for creating custom attributes & relations. Since I haven't completed it yet, I'll step in here real quick to provide a brief overview.

One thing I'm going to emphasize is the decision one must make between creating an attribute or relation for non-numeric values. That is, the logic is pretty clear about creating attributes for values like population, revenues, etc.

Where it can get a little fuzzy is if the value could be a relation (ie target page in which to create a relationship between articles). In this case, you can still choose to use an attribute, like CEO for a job title, BA for degree, etc, rather than a relation to main space articles that define/explain the meaning of those terms.

In the case of recipe_name, you start moving down the path closer to creating a relationship, especially if you anticipate creating stand-alone recipe pages in the future. Situations where relationships already work really well can be seen with the city->county->state->country roll-ups, etc.

Finally, there's the issue of ordinal identification ie situations where there may be multiple values OR associations between values, such as degree(s)<->year(s). Right now, relationships don't handle either very well (typically, they need an additional category identifier), but attributes are just the ticket. So even if something was logically a relationship, if you're going to have a complex data set, you may decide to use attributes instead. Centiare 09:11, 13 January 2007 (PST)