KiWi, the Open Source development platform for building Semantic Social Media Applications, offers features required for Social Media applications such as versioning, (semantic) tagging, rich text editing, easy linking, rating and commenting, as well as advanced “smart” services such as recommendations, rule-based reasoning, information extraction, intelligent search and querying, a sophisticated social reputation system, vocabulary management, and rich visualisation.

Purpose

Poolparty was conceived to facilitate various applications like

• Semantic search engines
• Recommender systems (similarity search)
• Corporate bookmarking
• Annotation- & tag recommender systems
• Autocomplete services and facetted browsing.

These use cases can be either achieved by using PoolParty stand-alone or by integrating it with existing Enterprise Search Engines and Document Management Systems or Enterprise Wikis.

Thesaurus Management

PoolParty is aiming to be easy to use for people without a strong Semantic Web background or special technical skills. The GUI is entirely web-based and utilizes AJAX so the user can e.g. quickly merge two concepts via drag & drop. An overview over the thesaurus can be gained with a tree or a graph view on the concepts.

PoolParty also helps to semi-automatically add concepts to a thesaurus as it can be used to analyse documents (e.g. web pages or PDF files) relevant to a thesaurus’ domain in order to glean candidate terms. This is done by the key-phrase extractor of KEA. The extracted terms can be selected by the user, thereby becoming “free concepts” which later can be integrated into the thesaurus, turning them into “approved concepts”.

Documents can be searched in various ways – either by keyword search in the full text, by searching for their tags or by semantic search and similarity search. The latter takes not only a concept’s preferred label into account, but also its synonyms and the labels of its related concepts are considered in the search. The user might manually remove query terms used in semantic search. Boost values for the various relations considered in semantic search may also be adjusted. In the same way the recommendation mechanism for document similarity calculation works.

PoolParty by default also publishes a Semantic Wiki version of its thesauri, which provides an alternative way to browse and edit concepts. Through this feature anyone can get read access to a thesaurus, and optionally also edit, add or delete labels of concepts. Search and autocomplete functions are available here as well. The Wiki’s XHTML source is also enriched with RDFa, thereby exposing all RDF metadata associated with a concept to be picked up by RDF search engines and crawlers. (See two examples: Cocktail thesaurus &  Standard Thesaurus for Economics)

PoolParty also supports the import of thesauri in SKOS (including several consistency checks) or Zthes format. Those functionalities can also be consumed as stand-alone web services via PoolParty SKOS Services. Additionaly, lists of concepts and their labels can also be imported via CSV files.

Linked (Open) Data

PoolParty not only publishes its thesauri as Linked Open Data (in addition to a SPARQL endpoint), but it also consumes LOD in order to expand thesauri with information from LOD sources.

Concepts in the thesaurus can be linked to e.g. DBpedia  via a service like Georgi Kobilarov‘s DBpedia lookup service, which takes the label of a concept and returns possible matching candidates. The system suggests relevant resources from DBpedia and the user can select the one that matches the concept from his thesaurus, thereby creating a skos:exactMatch relation between the concept URI in PoolParty and the DBpedia URI. The same approach can be used to link to other SKOS thesauri available as Linked Data.

Other triples can also be retrieved from the target data source, e.g. the DBpedia abstract can become a skos:definition and geographical coordinates can be imported and be used to display the location of a concept on the map, where appropriate. The DBpedia category information may also be used to retrieve additional concepts of that category as siblings of the concept in focus, in order to populate the thesaurus.

PoolParty is capable of importing a SKOS thesaurus from a Linked Data server, and may also receive updates to thesauri imported this way. This feature has been implemented in the course of the KiWi  project funded by the European Commission. KiWi also contains SKOS thesauri and exposes them as LOD. Both systems can read a thesaurus via the other’s LOD interfaces and may write it to their own store. This is facilitated by special Linked Data URIs that return e.g. all the top-concepts of a thesaurus, with pointers to the URIs of their narrower concepts, which allow other systems to retrieve a complete thesaurus through iterative dereferencing of concept URIs.

Additionally KiWi and PoolParty publish lists of concepts created, modified, merged or deleted within user specified time-frames. With this information the systems can learn about updates to one of their thesauri in an external system. They then can compare the versions of concepts in both stores and may write according updates to their own store.

This means each system decides autonomously which data it accepts and there is no risk of a system pushing data that might lead to inconsistencies into an external store. Data transfer and communication are achieved using REST/HTTP, no other protocols or middleware are necessary. Also no rights management for each external systems is needed, which otherwise would have to be configured separately for each source.

Technology

The software is written in Java and utilizes the SAIL API, so it can be used with various triple stores. The thesaurus management itself (viewing, creating and editing SKOS concepts and their relationships) can be done in an AJAX Frontend based on Yahoo User Interface (YUI). Editing of labels can alternatively be done in a Wiki style HTML frontend. For key-phrase extraction from documents PoolParty uses a modified version of the KEA 5 API, which is extended for the use of controlled vocabularies stored in a SAIL Repository (this module is available under GNU GPL). The analysed documents can be stored and indexed in Lucene/Solr or any other (enterprise) search system along with extracted and semantically related concepts.

During the closing session of ESWC 2009 which was held in Crete, KiWi was awarded as Best Demo of the Year amongst 23 other participants. See the showcase here and let the KiWi consortium know what you think!

If you have just a minute, see what KiWi can do for you and how it can break boundaries, as a system following the Linked (Open) Data principles. Enjoy!

Sebastian Schaffert and his team demonstrated the latest version of this semantic based framework based on wiki principles and built on JBoss Seam.
You can take a look at the online showcase and download the one click installer of the pre-release.
Sebastian emphasised that KiWi will follow Linus Torvald’s maxim of releasing early and releasing often.
In June 2009 KiWi 1.0 should be ready, followed by 1.5 in December 2009, at which time Enabling Technologies and a first implementation of the uses cases will be included in the system.

After hearing talks about the KiWi User experience, data model and transaction management, we learned about the status of reasoning, querying, information extraction and personalisation of the Enabling Technologies groups (online slides forthcoming here).

Peter Reiser presented the Sun use case, in which the focus now is on realising an expert finder mechanism based on the “Community Equity” concept found in Sun Spaces (their highly popular, heavily customized version of Confluence).

In short Community Equity is a system for analysing the social activities in a community and measuring the value of the contributions to the community. Social activities are anything from creating content to simply viewing it. These activities are used to calculate the Community Equity (which is simply a number) of content, tags and people.
Consider this example for a content page: The more people view, download, reuse, comment on or rated the page positively, the higher the page’s Information Equity will be.
In turn the community members acquire Contribution Equity through the content items they create, i. e. the Information Equity of a content item “spills over” to its creator.
The same goes for Tag Equity: Each tag obtains the Equity from all the pages it is applied to. E.g. if there are 3 pages with the tag “JBoss” with Information equity of 10, 5 and 20, then the Tag Equity of JBoss is 35.
These things alone is very helpful for motivating people to contribute to the community and for judging the quality of content and ranking it accordingly.

On top of that, the Equity system allows for a expert finder system. People are related to all the tags that are used on the content items they created. Imagine a contributor has created several documents that were tagged with java and the sum of information equity of those pages is 550, then the person also has
That way a search for “Java” doesn’t only bring documents tagged with java, but also people with expertise in Java.
In KiWi this Community Equity system will be implemented and extended. For one, instead of flat tags KiWi will use concepts coming from SKOS thesauri, which will be managed using PoolParty.
These thesauri act as a shared knowledge model. In this way synonyms, parent/child concept relationships, etc. can be considered for Equity calculation, therby taking personalization, querying and expert finding to a whole new level.
Research will engage with questions like how should the Equity disperse through the graph: Imagine a community member with high Equity in “JBoss”. This means she probably has good expertise in Java too. As this subconcept relationship is expressed in the thesaurus, it is possible to transfer Equity from JBoss to Java, but one has to consider what percentage the equity will be transferred, if Equity only can only spread upwards from subconcept to parent concept or whether other kinds of relationships also warrant the transfer of some Equity.

One of Sun’s further assumptions is that users will migrate to KiWi neither immediately nor completely – and that’s an insight anyone developing yet another social platform should take to their heart. What was true in Field of Dreams – “If you build it, they will come” – does not quite apply here. The network effect works in favour of existing communities, and instead of striving to replace an existing platform, one might be better off with mashable contents and services.

The particular benefit of a semantic wiki is that it allows moving from unstructured to structured information (relatively) easily. For KiWi @ Sun (and in favour of mashed information), this means that what is relevant will be structured, both by people and by machines – a process that is going to extend beyond company boundaries. People will bring in structure by creating links from KiWi documents to external systems as well as by writing new facts (which the KiWi system will represent as triples) about external information. What is not relevant, won’t be structured – and will be forgotten. After all, it’s forgetting that makes you remember the important stuff.

One note about the users of KiWi at Sun: Since this use case focuses on knowledge management for software development, it can be taken for granted that users will have an above-average level of web savvyness. Primary users will be software designers (i.e. the people who design for the users of the final product) and developers – learn more about the different roles in a software development project at Sun here.

Consequently, the User Interface (UI) concept Josef introduced also comprises a social networking unit – things such as a ‘My Contacts’, ‘My Pages’ list, but most importantly an activity feed, which will help users to collaborate, participate, discover activities that others are currently working, develop a mental ‘social map’ of the community. Such an activity stream (similar to Facebook’s News Stream) would contain items such as:

• Szaby wrote a blog post
• Josef rated document XUI specs: five stars
• Peter created document ToDoList KiWi-UI
• Stephanie is now a contact of Marek
• Klara shared a document with Sebastian

Considering the target group, it is also planned that the UI will be extensible through widgets that users are able to write themselves.

*coffee break*

Above: The KiWi-Team, hailing (officially) from Austria, the Czech republic, Denmark and Germany

After the break, Andreas Blumauer (Semantic Web Company, Vienna) followed up with a talk entitled “Open Ontology Management & Linked Data” which explored the uses of the Web of Data for the Sun usecase.

His argument was that content and topic-centred, open communities should have mechanisms at their disposal for relating content and activities to particular parts of a shared concept model, e.g. of an ontology. In particular in projects like NetBeans, where contents and related processes evolve over time, different NetBeans groups utilizing the KIWI system should be allowed to maintain and share their own concept models. The combination of bottom-up and top-down approaches would, for instance, come as the combination of free tagging (where people often use different labels to refer to the same, or the same label to refer to different things) and concept tagging.

Free concepts can be turned into controlled ones, too, by being inserted into an existing controlled vocabulary, as either a narrower or related concept of any existing controlled concept. Open Ontology Management done this way is a Learning system: Through the combination of a Free Extraction Model (FEM) and a Controlled Extraction Model (CEM), text extraction improves over time.

Andreas also revealed a first glimpse of a project currently in stealth mode, code name ‘PoolParty’, which is an Open Ontology Management System that can be used to enrich local knowledge with data from the web. PoolParty consumes Linked Data and provides Linked Data; in the context of the current use case, it will be able to communicate with the KiWi System. Please contact Andreas if you would like to be notified about the further development of PoolParty.

Regarding the use case requirements: As Daniel Grolin, a process expert and business architect at Logica (formerly WM Data), pointed out, what is most required at the moment is an application for designing processes, i.e. for designing the ways that people do things. This can be a painful process, in particular if one group of people (consisting of process designers) thinks about the ways that another group of people (e.g. the project managers) are going to do certain things – a collaborative approach should be able to

1) alleviate this challenge
2) generate commitment among the involved parties.

The primary users will be on the one hand the process engineers, and on the other hand the project managers who are the recipients and users of these processes.

In his presentation, Daniel Grolin chose one of four scenarios in which KiWi would ideally be employed: the risk analysis process – which is a vital process for Logica, as the outcomes of this analysis influence the decision whether or not a project will be accepted. From an architectural point of view, KiWi is going to mediate between the process guidance column – which consists of process and workflow features – and the final work product, i.e the result of a process, in this case the report of the risk analysis.

In practice this means that if, for instance, a user has selected the risk analysis process, the Kiwi core system and enabling technologies will provide concepts related to risk analysis, supporting the user in the tagging process. Wiki technology is already being used in the industry, said Daniel, but what is lacking at the moment is the integration of structure, and this is also where he sees the potential of KiWi as a knowledge management tool, and as a means to move easily from unstructured to structured information (by the way, if you are interested in using wikis in the enterprise, I also recommend this article: Wikis for Knowledge Engineering, and in Global Businesses).

Karsten Jahn (Aalborg University) then gave us a preview of a possible user interface (i.e. not of the screen design, but the functionalities) which seeks to address one particular problem: Many companies use many different, sophisticated tools which operate fine on their own, but are not integrated (i.e. there is no communication or exchange of data between them). With KiWi, the aim is to develop a tool that is going to be able to cover all features and processes currently being taken care of by individual tools, to allow for an optimum of data integration.

To conclude, Rolf Sint (Salzburg Research) showed us screens of the current configuration of KiWi for Logica’s needs – the example below is related to the risk analysis process outlined by Daniel Grolin above.

In the first presentation today, Sebastian Schaffert from Salzburg Research gave us a tour of two different configurations of the KiWi system. The KiWi core system is oriented towards content versatility, meaning that content items can be displayed and used in various contexts and configurations. As a service to the user, KiWi uses Javascript-based WYSIWYG Editor TinyMCE enhanced with a few home-grown plug-ins which, for instance, make it easier to set links to other wiki pages. Memorizing wiki shorthand is sometimes a challenge, so this feature helps getting things done.

Using a different skin and interface, KiWi can take various forms and shapes – even shapes where you might not spot the wiki in it at first glance. TagIT is such an example of an adaptation of the KiWi core system: a geotagging platform targeting youth in Salzburg who can locate, tag and comment on places that matter to them.

Vice versa, KiWi in its wiki incarnation displays a little map, provided a content item is enhanced with geoinformation; technically, the map on the wiki page is an interpretation of a georelated tag (learn more about complex, structured tags proposed by the KiWi Enabling Technologies Work Package in this article: Usage Data Model Day in the KiWi Project).

Take a look at the screenshots below:

It is the same article that is being displayed, in the first example using the classic KiWi interface, in the second example using the TagIT interface with the article appearing as an info page.

This afternoon, we expect to see another configuration of the system, in a presentation about how the system is specifically tailored to the needs of Logica’s “Knowledge Management for Project Management” usecase.

N.B. The system is not yet publicly available, if you have questions, please contact Sebastian Schaffert.

Related articles by Zemanta

• KiWi Joint Work Package Meeting in Prague
• KiWi: Knowledge in a Wiki
• Usage Data Model Day in the KiWi Project
• Not a pipeline, but a graph: software development in the KiWi/Sun usecase

People unable to attend physically, Christoph wrote, might consider participating in the Semantic Wiki Mini-Series Launch Event via ONTOLOG (= Open, International, Virtual Community of Practice on Ontology, Ontological Engineering and Semantic Technology), to take place online on Thursday, October 23, 2008, 10:30 AM PDT / 1:30 PM EDT / 7:30pm CEST / 17:30 UTC (click here for more details, time zones, registration procedures for first-time participants).

Here are some of the topics that have already been put on the wish-list for the Semantic Wiki Mini-Series (source):

• usability vs expressivity
• community building
• uncovering more implementations
• HCI: navigation of large, high-dimensional knowledge spaces
• e-science (especially pharma research & biomedicine)
• semantic wikis and mashups
• recommendation and personalization in semantic wikis,
• knowledge representation (expresivity vs. simplicity)
• how to make business subject matter experts able to enter, review and validate
  meaningful information without them having to learn new words
• what dialect of OWL supported
• integration of semantic resources (Protege / OOR / MW / …)
• content quality
• integration of external data
• a semantic wiki & OOR session
• experiences with distributed collaboration
• server-side infrastructure to support semantic wikis
• survey of semantic wikis for vertical domains (e.g. HCLS)
• integration with other tools / linking wiki content to other apps

If you ask me, there are more than enough topics not for a mini, but for a grand series of conferences on Semantic Wikis:) For updates, bookmark the homepage of the series.

Related articles by Zemanta

• Knowledge Representation in the Legal Domain
• KiWi: Knowledge in a Wiki
• Social Semantic Web events
• Educational uses of wikis

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… it does have the extra advantage though that you can add links, cite resources and that you get to keep your blog posts (or tweets or equivalents thereof) for later reference or debate. Different people approach blogging differently – the approach I would favour in the context of this definition is a form of blogging that invites dialog in that it allows others to comment and react, and where contributors aren’t anonymous, distant institutions, but are addressable using their personas/identities on the web. As such, contributions are often marked or tinted by the views and personality of that real-life person behind a persona/identity. As a short cut, think of this flavour as the flavour of the social media tag cloud.

Web-Flavour 2: Wikipedia – evolving slowly with the flow

Wouldn’t you agree that Wikipedia is like a sea of knowledge? It is fed by brooks and rivers (in this analogy: for instance the article and contributions that are invited on the Wikipeda Community portal) that make it rise and swell like tidal waves would, but mostly by millions, billions and trillions of tiny drops that trickle in on a daily basis. In comparison to the blogosphere, the world inside wikipedia is a rather neat and orderly one: Titles of pages are unique, and were they aren’t, there are disambiguation pages (like this one) in place. Even though articles are written by real humans (I assume), there is no visible author attached to an article (unless you start developing an interest for Discussion Pages, e.g. this one; most people don’t). Wikipedia is the sea of knowledge we bathe in on a day-to-day-basis without even noticing – just try to remember how many and which Wikipedia pages you have looked at today or this week – can you? Most probably not. It’s the result of a community effort, but it’s not about views and opinions of individuals, but about what we all know together or would know together if we could wire our brains to one another (tired of the Wikipedia examples? Check out Factolex instead, a collaborative, micro-content encyclopedia that allows you to extract and conceptualize bite-sized pieces of knowledge as you go).

This is the flavour I like to have around me every day, because it makes things easier without asking for a huge effort. It’s also the flavour of thesauri and metadata schemata.

Web-Flavour 3: The unfinished structure of ontologies

Flavor three is NOT (as one might expect) the flavour of the Encyclopedia Britannica Online (which is one huge data silo and therefore not relevant for my scope of interests) … instead, I would argue that it’s the flavour of the web’s infrastructures and of knowledge infrastructures like ontologies. Think of the geometry of snow flakes: they all follow rules but none of them is like another. The open world assumption of ontologies also applies to snow flakes – just because you haven’t seen a particular shape doesn’t mean it doesn’t exist! Nobody has the patent for building snowflakes – Wilson Bentley in his famous snowflake shots just captured an expression of rules that are out there, in the world, belonging to the world. Ontologies capture the structure of what, to the best of knowledge and belief, can be said about the world. Anyone can build an ontology, but we prefer to have experts do that job: members of the scientific community which has its own ranking and weeding mechanisms in place.

Flavour three is the flavour of things we wish to be able to rely on on the web, and where we can invest a trust that is much greater than the trust we invest in people. More like the trust we invest in, say, the laws of nature.

So what is the flavour of a Semantic Wiki?

A good mix of flavour two and three, I would argue. A Semantic Wiki is a vessel for the sea of relevant knowledge (relevant for instance for the members of a particular team), but enhances it with the structure of the domain knowledge that applies.

Having said that: A semantic wiki would be much spicier if it also had a bit of the flavour of the blogosphere and social media (i.e. flavour one), as there are tasks where a bit of a debate, a bit of a controversial exchange and the ability to respond to people directly is highly valuable! Just as water, knowledge goes through a cycle of different states of matter, and knowledge is not processed by segregated individuals, but in communities and through networks of people.

Before publishing this, I wanted to get some feedback in particular from KiWi members working on enabling technologies – here is Peter Dolog‘s take; Peter is an Associate Professor in the Information Systems Unit at the Dept. of Computer Science Aalborg University:

I like the distinction and comparison of knowledge to some natural elements like gas, liquids, solids or snowflakes. These give a good metaphor for understanding when talking about different flavours of knowledge. It is also fascinating to see how humans move between these three categories by participating in different social processes or simply by studying these things.

It is, however, a bit more difficult to see how this can be done or supported in the most suitable form on the web or in the intranets of companies. At the same time it seems to me, from the discussions we have had in the KiWi project, that semantic wiki platforms could indeed facilitate this. Wikis naturally provide the social contexts for contributions. Semantic wikis with tags and ontology management seem to be a first step towards a flexible knowledge consolidation infrastructure where one can move easily between these categories; and other technologies such as natural language processing and automated reasoning can help further. Personalization can further provide and adjust views on the knowledge according to preferences.

I am happy that we can study these phenomena in the KiWi project at least to a certain extent and perhaps contribute to this as well. I am confident that this is relevant also for the industry and especially for large distributed companies where externalization of knowledge is a must.

So there is a lesson to be had: When building a knowledge management system using the web, think of the three states of knowledge, but most importantly, also think of the form of community and community processes that are required or preferable to allow future users to really put that knowledge to work – melt it, share it, heat it, debate it, freeze it, keep it, let it evolve!

Image sources on Wikicommons:
Water vapour by Markus Schweiss
Wake at Boelge Stor by Malene Thyssen
Ice Crystals by Petr Dlouhý

Author: Jana Herwig

Related articles by Zemanta

• Quality Assurance in an Open Project
• Social media is changing the shape of scientific debat
• Wikipedia – 25 things you should know
• How Wikipedia’s model can impact on the world of education
• Best Wiki-moments

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.

Best regards,

Fred Durão and Peter Dolog

Here is link to the FAQ.