User:Jukeboksi/Blog/May2005

29.05.2005

I've been thinking about the Language vs. Area problemacy. I've been plotting a plan in my head that certain companies and products they offer should be arranged by location ie.

[[FI/Tampere/SomeTex-MexRestaurant]]
[[US/California/Santa Cruz/SomeBikeRepairShop]]
[[CA/Ontario/Toronto/China Town/SpicccyChineseRestaurant]]

Thinking how this is not a workable arrangement for transnational corporations to pinpoint them to their HQ...

...but then something almost magical happened... I remembered something that I've been taught in school: There are Goods (tanglible) and Services (intanglible), both of these are products (This is how it is in the course books). The distinction between a service and a good is sometimes difficult to make. This is covered well in the w:Service article.

An example (far fetched):

-Juxo goes to the store to buy bread. Is the store selling me a bread or is it selling me a services (sourcing, logistics, storage and other activities that enable me to consume the service leaving the store knowoing that I won't go hungry for a while now)?

Some people argue strongly that all transactions should be viewed as services. See w:Service economy and/or Service economy on this view point.

I'm currently thinking that companies selling services should be arranged into a tree-like structure so that the companies provoding services would be close to each other in the article hierarchy. And, yes, I know how bad this solution is for performance (I can actually read and write SQL (!)... after all MediaWiki is developed for Wikipedia where the common wiki-way is to avoid sub-articles so it's not at all optimised to traverse up and down subarticle-trees.

Article validation coming to 1.5

Article validation is a hot topic on meta today as m:User:Magnus Manske has once again implemented this feature as described in m:Article validation feature this time it seems to be integrated into MediaWiki in 1.5 tree and you can try it out here.

This new feature is likely the tool we are going to use to decide what gets published as facts and what doesn't.

Those of you who have been with us for a while may remember when we decided that articles about the real world get published when the "default signer" signs a version of an article thus the dreaded sysop doesn't get to make (or have the misery of having to decide) the decision of what goes and what doesn't.

The problem of whose responsibility it is to make these kinds of decisions doesn't evaporate away because someone has to decide who are the decision makers in each case.

26.05.2005

I've got my thinking cap on and I think I'll get a plan for moving to implementation phase soon. Please be patient. I remember when I started this project I was thinking of 10-15 years to implementation... of this only little over 3 years have lapsed. Also emergence of interesting technologies such as NFC and cell phone manufacturers coming out with phones with WLAN and Bluetooth has leaped forward.

22.05.2005

I've been thinking about the non-wikiness and extra hassle that comes if we try to get this thing working using three wikis:

Inevitably that would lead to inconsistencies, wasted working hours and frustration.

I think that it would make sense to drop the third wiki and replace that with non-editable html. I'm not using the word static, because an article or more likely a set of articles from Research Wiki will be merged for publication. This stage would allow the Preferences (that have been at the heart of the whole concept of Consumerium right from the start) to be implemented.

I asked around at #mediawiki on http://freenode.net about wiki -> html conversion since there are hundreds of sites serving Wikipedia content as static html I thought that either all those sites invented the wheel for themselves or there is a freely available tool, and there is one developed within mediawiki development here is the .inc file and here is the .php file (from the 1.5 alpha tree)

The Language vs. Area question on what basis is used to arrange - ie. store and retirieve information - most efficiently organise the information still remains a major blockade stopping us from going on into implemenatation phase.

There are (imho) two approaches to making Consumerium services and features to work:

Pro-Determinism: machine-friendly: heavy use of categories, heavy use of namespaces, Using strictly the same terminology as a business operative would eg. Company, Brand and Product namespaces
Emergent: Laid back, more wikilike. Let's just see if we can make minimum set of rules of what goes where and how will strange attractors or other "order from chaos" emerge.

21.05.2005

Today I got the Consumerium spam blacklist configured and working. I'm not protecting it for now. Please if you notice new clear cut wiki spam cases, add them to the list and blank the page untill a sysop shows up to delete the pages.

17.05.2005

This wiki seriously needs to be categorized, but upcoming Research Wiki avoids using category where ever it can be avoided to keep it simple.

14.05.2005

The wiki was offline for a few hours but the good news is that I managed to upgrade MediaWiki to 1.4.4 (latest stable) after hacking the installation scripts quite a bit.

Other good news is that I managed to get the short URLs to work. If you spot something that's broken due to this upgrade please email me.

Fixed interwiki linking which was lacking wiktionary:kitchen and WikiBooks:Cookbook

09.05.2005

While doing the chores I removed a bunch of hits from a run-amok rogue wget-script so that for a change Statistics are sane and propably even correct.

Sourceforge is experiencing trouble with their mirrors so I could not load the newest stable MediaWiki (1.4.4)

04.05.2005

Finally this Development wiki is up and running again. The cracker had altered the db but I seem to have stiched up a reasonably sane database.