In recent debates within the KiWi – Knowledge in a Wiki project, the need arose to further refine and find a common understanding of the type of knowledge that is (ideally) managed and processed using (semantic) wikis. One of the proposals evolved around a conceptualization of knowledge put forward by Gabi Reinmann-Rothmeier, also dubbed the “Munich Modell” (Münchner Modell).
In the Munich Modell, knowledge comes in three states of matter: solid (like ice), liquid (like water) and gas (like water vapor).
“Frozen” knowledge is knowledge in its most tangible, manageable form, for instance the type of verified, expert-endorsed information you would find in an encyclopedia like the Encylopedia Britannica.
“Gaseous” knowledge, on the other hand, is knowledge in its least consolidated form: think for instance of the type of heated debate you might have with folks in a pub, which is arguably the least structured, most uncontrollable, but also the most engaging type of knowledge!
And the “liquid” form of knowledge, eventually, is the common knowledge of day-to-day-life. It’s probably fair to say that it becomes obvious mostly when in the process of changing its state of matter: When it is calibrated against “frozen” or informational knowledge or when it is debated, becomes “gaseous” knowledge that informs action. (If you’d like to know more about the Munich model and are able to read German, you might want to download the original article here – PDF, 365 KB).
When talking about knowledge that is managed, used or, respectively, that evolves online, I think it also makes sense to pay some attention to the type of community that is preferred by particular online tools or environments. The particular flavour of knowledge, in this sense, is simultaneously characterized and shaped by the state of matter of knowledge and the form of the community that applies.
N.B. The following is not an immediate translation of the “Munich model”, but rather a reconceptualization which tries to also consider that different community models (and their implementation through IT) also play a role for the whole spectrum of knowledge management on and with the web (e.g. for online communication and interaction, online publishing and documentation and maintenance of web infrastructures).
Web-Flavour 1: The Blogosphere – gas, gas, gas!
Hmm… sniff it! This is the flavour I like best because it is my flavour. On the blogosphere (and twittersphere), knowledge is exchanged, developed further and evolves almost like in a pub debate… Continue reading →
The IWIS Group at the Dept. of Computer Science, University of Aalborg, Denmark, have just opened up their evaluation of a tag recommender system they are building; the component is to be part of the wiki-based, semantic knowledge management system KiWi (itself based on IkeWiki). Anyone interested in participating, please send an Email to Fred Durão at fred@cs.aau.dk.
Hi,
We are conducting an evaluation of a tag based recommender system with personalization we have developed here at the IWIS group at Aalborg University (http://iwis.cs.aau.dk) and in the context of KIWI project (http://www.kiwi-project.eu). We would be very grateful if you could help us with this task.
The recommendater system is based on a set of algorithms we are evaluating. Later we are planning to plug it into the KIWI system and develop an appropriate user interface for it. Currently, we are evaluating it based on Delicious data (tags and content). The recommendations will be processed by our recommender system based on the tags you placed in Delicious.
As personalization is a crucial aspect to us, we will give you a generated username and password to log onto the Delicious Web site. Therefore please send an e-mail back to us that you would like to participate. You only have to tag a minimum 10 web sites of your preference. Tag as much as you can!
Afterwards we are going to email you a list of recommendations to web sites that you might be interested. These are computed by our recommender system. We will ask you to mark the recommendations by YES if the sites recommended suits your preference or NO if it does not.
The achieved results will be published to all participants after the end of the analysis.
People interested in participate of this evaluation please send an email to fred@cs.aau.dk.
Applications based on semantic technologies offer new ways to discover, browse and explore information – this is an established fact in the SemWeb community. But how can we (as semantic web “insiders”) communicate these potential benefits to a typical end-user who has never heard about “faceted search” before – which doesn’t mean that he or she wouldn’t love intelligent user interfaces if they were in place?
One answer lies in using mockups, which are, on the one hand, an indispensable instrument for prototyping user interfaces, but also valuable when it comes to explaining the workings of an application to an end-user, an audience of interested researchers or a client.
And when it comes to explaining a search engine or search widget, mockups are even more important, as we all and in particular end-users are often unable to think of search interfaces other than in terms of Google.
We have become so googlified that hardly anyone can think of different ways of searching for information than Google has offered for many years now: Put a couple of words in a text box, click a button and scroll through a list of titles and summaries. Repeat until you’re done, or try a new search and repeat. Wow!
Although even Google has started recently to implement a little bit of semantics by offering an auto-complete functionality on google.com (on some local versions like Google Austria this feature is still not available), even the most basic concepts for an intelligent search interface are still not part of common sense thinking.
Admittedly, there are people who get irritated instantly by complex user interfaces like David Huynh´s Freebase Parallax. “This is only for experts!” is their response. But in a corporate setting, complex queries are part of our daily business – they are just not supported by common search engines (only exception being data mining solutions). But that doesn’t mean that we don’t need it.
Where is the way out of this dilemma?
Don’t tell, but SHOW the end-users how semantic technologies can enhance search & browse experiences
Do not use terms like SPARQL or RDF
Create a simple mockup that illustrates the points you want to make
You’re not a designer? Use tools like Balsamiq – Try it now!
Here is an example for a mockup of a semantically enhanced expert finder:
These kind of mockups are essential for any requirements engineering phase in any project where search is a bit more than a text box, a button and a bunch of documents.
Sorry for still writing about last week, but the TRIPLE-I conference had far too many interesting topics to offer for me to be already through with them – promise, this blog post about wikis will be the last TRIPLE-I post.
An interesting use of wikis was introduced with the Moki plugin for Semantic Media Wiki, developed as a side product of the APOSDLE project. APOSDLE (EU-project leaders love their acronyms;-) aims to develop an Advanced Process-Oriented Self-Directed Learning Environment, which in plain language is a platform to support the process of learning at work. In the course of this project, a model of the enterprise knowledge had to be developed that was to be the collaborative result of domain experts within the enterprise and external knowledge engineers. The APOSDLE image video below conveys a sense of the complexity of the knowledge to be represented.
But on to Moki: As wikis are an ideal, readily available tool for collaboration, the simple solution was to build a plugin (Moki) for Semantic Media Wiki that allow to structure and engineer the domain knowledge. Moki is a hierarchy builder that supports drag and drop so that categories and relations can easily be fitted in place – the special benefit of using Semantic Media Wiki was that the structure of the generated knowledge can be exported in Semantic Web compliant formats. Apart from the browser, no further software is required.
The APOSDLE website doesn’t yet offer any information about Moki, but a description can be found in the conference proceedings: Collaborative Knowledge Engineering via Semantic MediaWiki, by Chiara Ghidini, Marco Rospocher (who gave the presentation), Luciano Serafini, Viktoria Pammer, Barbara Kump, Andreas Faatz, Andreas Zinnen, Joanna Guss, Stefanie Lindstaedt.
For those looking for good arguments for setting up a wiki in a global business environment: Peter Kemper‘s keynote was the perfect primer for that. Peter, a Knowledge Management portfolio manager at Shell’s IT-Department, gave some insights into the process of their conversion to wikis. Before there were wikis at Shell, they had global discussion forums, connecting 20,000 people around topics and questions, which were intensively used – the question whether wikis should be adopted or not alone generated 800 responses in these forums.
Instead of going for team wikis, Shell opted for the encyclopedic approach and a wiki that would be accessible to anyone at Shell, and for using MediaWiki – which was, interestingly, the first open source software ever used at Shell. Peter Kemper named scalability and the lean architecture as prime arguments for MediaWiki, and they have indeed not had any technical hiccups so far. It was also an asset that people, being used to Wikipedia, know how to use the MediaWiki interface.
Examples of uses case with which the feasibility of wikis within Shell were tested were: Drilling salt, Geology of the Atlantic Margin, and Production Chemistry. Before that, the main media for maintaining and passing on knowledge had been emails and Powerpoint – not exactly because these were considered appropriate for knowledge management, but because of the effects these media had had on the communication within Shell:
With the advent of email, People wrote less and less memos. Less and less reports were sent to the archive, because people kept powerpoint presentations. If that same information, previously locked in emails and powerpoint, went now into wiki, it would finally be accessible to everyone in the company.
Peter Kemper allowed us a glimpse of the information their wiki held, for instance, about the Atlantic Margin – as geological structures are described, most of the information relies on images. It would be a nightmare to maintain this kind of information in Powerpoint! No offense meant: Powerpoint is good for presentations but not for creating and maintaining a knowledge base. According to Peter, with wikis Shell achieved six times the productivity in comparison to using Powerpoint, in particular due to the linkability of content.
Wikis also turned out to be the superior solution for the integration of curricula from an internal learning environment, as wikis support the modular structure of a learning curriculum. Furthermore, they are also a good means to sustain communication in the time between workshops or team meetings.
At shell, they even use wiki for instance for the translation of contracts into the requirements of day to day procedures – a typical contract in the business that Shell is in has around 400 pages, and it is probably not very likely that a single person is going to read (and immediately understand) the entire contract. In this regard, the wiki also serves as a tool to translate lawyer-readable prose into transparent instructions (and there are probably many more ways in which wikis can be used to support business processes, a statement also put forward by Rolf Sint from Salzburg Research; see his 12 seconds statement below).
A noteworthy detail about the integration of wikis in Shell’s IT architecture: If a user logs onto the wiki for the first time and goes beyond the disclaimer, a new wiki account is automatically created that is identical with his or her windows account – this is not about checking on people, Peter Kemper said, but about creating organisational transparency.
On the one hand, this reveals whether there are organisational units within Shell where the wiki is not as intensively used as elsewhere, meaning that these units probably have specific needs which need to be addressed first. On the other hand, people can (and do) also contact each other via the wiki, e.g. one can contact the person who created an article if one is on need of further information.
About stimulating content production: 60% of Shell’s employees will go into retirement over the next eight years, and with them knowledge that is needed in the company. They even asked and paid former employees to come out of retirement to work on the wiki – that’s what I call commitment to content creation and knowledge preservation.
The Shell wiki already has more than 40,000 registered users (with 150,000 employees in the company, plus contract staff). What is interesting regarding user activation is that the number of active users stays relatively the same, even if the number of users in total increases. Peter Kemper’s account for this was that content comes in waves, meaning that users are activated in those areas where fresh knowledge is generated.
Kemper distinguished three types of users: content owners who create content from scratch; content editors who often just correct syntax or make things ‘look nicer’; and information consumers. Kemper rejected the term ‘lurkers’ for information consumers as looking for information is an activity in itself.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=9725f5b5-19e2-44ed-8cf3-35f3ca89b2f3)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=b15fd2e4-969f-4445-97db-b4de7ee1892d)
For those looking for good arguments for setting up a wiki in a global business environment: ![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7b16d276-2e6b-4abd-bd58-97939cba58d2)