WikiVote! Foresight wiki

SMWCon Fall 2012
Semantic MediaWiki for strategic foresight creation
Talk details
Description:	The description of the interesting use case of SMW in strategic planning
Speaker(s):	Yury Kaktov
Slides:	see here
Type:
Audience:	Everyone
Event start:	25 Oct 2012 16:20
Event finish:	25 Oct 2012 16:40
Length:	30 minutes
Video:	click here
Keywords:
Give feedback

WikiVote! Foresight wiki is an installation of WikiVoteWiki platform that was used during the Foresight trip on August 13-19 from Moscow through the most beautiful Russian cities and back again. It will be also used as a platform for support a variety of foresight methodologies. The wiki uses the power of SMW to dynamically slice and dice the foresight data, it has custom design, semantically-enabled user profiles and flexible voting system. Moreover, some of the business logic were implemented with the help of inferencing and semantic queries.

Terminology and problem domain

Foresighting is the study of strategic planning the very distant future. Foresighting lays between planning and forecasting. One of the main documents that people create during the foresight is the roadmap - graphicaly represented set of trends, possible events etc., their key characteristics (possible years of happening, probability, importance, etc) and the relationships between all of these entities. Foresight approach are now used in Europe, Russia and Japan for effective strategic planning.

Who is using Foresight wiki

The wiki were deployed in the boat's intranet and were accessible by WiFi. There were about 300 participants that were engaged in creation of foresights. During the trip participants were having methodologically organized offline brainstorming sessions. Afterwards they could think more deeply on the ideas born in the brainstorming and improve the foresight articles online.

After the trip the wiki was made accessible on the Web.

Overview of Semantic MediaWiki usage

Data storage

In Foresight Trip Wiki we tried to use semantic properties for all sorts of data so that the wiki has a common data model. This enabled the possibility to use #ask-queries for all sort of things. The semantic properties are used for the following data:

• foresight objects such as trends, future technologies, laws etc.
• user profiles,
• voting data,
• information about page authorship.

All the data is entered via Semantic Forms. We have developed several new Semantic Forms Inputs and merged them into SFI extension:

• Two listboxes input as user-friendly alternative to existing inputs like checkboxes and select. Two listboxes allows users to enter a list of values and has all the functions of traditional select.
• Spinbox input is a common way to enter numerical values in the desktop applications. We believe that the spinbox is more preferrable since it doesn't allow to enter non-numeric values and gives user unambiguous hint about the data type.
• URL input is used for enter either names of the wiki pages or external URLs.
• Semantic Maps input was improved in two important aspects. Many of the users were confused by two separate inputs: the address box and the address finder on the map. We decided to both save the address and use the address box as a finder. The second improvement is that we've added Yandex maps support to Maps and Semantic Maps extensions. Yandex maps is very popular in former Soviet Union; it also has more detailed maps of Russian cities and villages.

Data representation

We have used #ask-queries very intensively both on integration pages with summaries and infographics, but also in templates, skin and our own extensions.

One of the greatest features of SMW-QL language that is used in #ask-queries is its immense flexibility. We've made the system for foresight creation before. Not long before the trip we suddenly realized that there will be a dozen or more foresight sessions organized on a trip! However after a short period of panic we found the way to organize the content with categories and make our summaries and statistics distinct from each other. For that we only needed to add Category restrictions in our queries and write a small extension to make sidebar navigation more pleasant and dynamic.

Business logic

We've been already convinced that Semantic MediaWiki is an ideal choice if you want to create very dynamic websites. However we have tried to do more than many other SMW wikis namely we used SMW queries, parser functions and variables to implement parts of the logic of the system.

TODO: ADD DESCRIPTIONS OF THE TRICKS WE USE

Voting

Voting is the essential part of offline foresight sessions and much effort has been put to make voting system as good and flexible as possible. First we have used Article Feedback which is really great extension from MediaWiki team. Since it was pretty easy to semantize the average votes the Semantic Article Feedback extension was born.

However efficient and well-designed Article Feedback could be, it was still not enough. Sometimes we needed just yes/no votes, sometimes we though about the 0..100 scale like in W4G_Rating_Bar, sometimes the customers needed several criteria of evaluation so the voting bar needed to look more like questionnaire. What was even more important is that different kinds of objects have to be handled differently in terms of voting and evaluation. After a while we decided to write our own voting extension that can support all the functions we need.

The newly-baked WikiVote Voting extension includes the following features:

• the administrator can construct the voting bar for category or for namespace with any number of evaluation criteria,
• very flexible system of access control so that the administrator can define what groups of users can vote and what user will see the voting results,
• the system supports yes\no votes, slider scales (1..100, 0..5, etc), discrete scales (scales like "very bad, bad, normal, good, very good")
• the average votes are already available in the semantic form so we can use the votes as a sorting criteria or create the visualizations and infographics that can neatly and nicely show the current situation.
• support a variety of algorithms for voting and several strategies for dealing with user ratings (the weight of the user vote is depends of her computed expertise in this particular area of knowledge), plus some tricks for dealing with ever-changing nature of the wikipage

In the future projects we want to enable the users to vote for the sections of the text, make some visualizations related to the dynamics of the votes

User management

Many wiki-engines don't care very much about the user data. MediaWiki provides the User page which unstructured (it's hard to use the data from this page) and requires to know wiki markup. This is clearly very careless approach since the wiki is always a social system. First we tried Social Profile extension to manage user data and created Semantic Social Profile to make its fields accessible to #ask-queries. Before long we realized that Social Profile is not very flexible, have many important limitations and is written mostly to make your wiki look like social network. What's more important is that the profile's fields weren't typed so it was difficult to semantize them. We've been trying to improve Social Profile by adding access control to its field, making them restricted, improving its user interface but have eventually given up and started to find another solution.

We found a great way to manage user profiles by using Semantic Signup and Semantic Forms. It was simple, it was elegant and it was semantic out-of-the-box. The only thing we miss about the old Social Profile is the access control: in the real world you need to be very careful with the user data

Technical details on user privacy

it's still theoretically possible to make some of the fields of the user profiles invisible. Yet before you can tell that the wiki users can store their credit card number you need to think about so many things:

• don't show the user data in the normal, rendered mode,
• never show the wiki-markup,
• be sure that it never turns into semantic property, so it can never be visible with #ask, #show, Special:Ask, SMW API and Factbox,
• restrict access via MediaWiki API,
• don't forget the printable
• what about wiki diff?
• hehe, and also ?action=oldid, ?action=history Special:ExportRDF, Special:Export,
• probably much more.

When you think about making some fields of the Semantic Forms private to the users and administrators, the following quote comes inevitably to mind:

The technology involved in making anything invisible is so infinitely complex that nine hundred and ninety-nine thousand million, nine hundred and ninety-nine million, nine hundred and ninety-nine thousand, nine hundred and ninety-nine times out of a billion it is much simpler and more effective just to take the thing away and do without it.

Douglas Adams, Restaurant at the End of the Universe

Appearance

One of the goals of the creators was to make wiki look and feel very unlike Wikipedia but still make it easy for user to recognize that every article can be edited and voted for. This goal define Foresight Wiki design specificity:

1. it has custom skin with less buttons, toolboxes and settings
2. the user never sees the wiki markup: even the diff is visual

History

The foresight methodology requires to always know which version of the object description had been discussed offline. Because of that we modified MediaWiki history and add so called milestones to it.

TODO: ADD DESCRIPTION OF THE WIKIVOTE HISTORY

Bots and cyborgs

There are several kinds of bots live on a Foresight wiki and doing repetitive tasks. I remind that the whole process has taken place on a boat trip where the wasn't much Internet access for 300 people. Because of that we wanted to create all the users beforehand using the information they gave during the registration.

Since the offline brainstorming sessions were the essential part of the trip, we also needed to import the results of such sessions in the wiki. For this task we used special bot coupled with Excel template for foresight note taking, that restricted and validated the values entered in the spreadsheet.

Cyborgs