Semantic Web Company

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).

Rolf Sint talks about workflows in wikis on 12seconds.tv

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.

All in all, Peter Kemper’s talk confirmed many of the assumptions which have informed our own KiWi – Knowledge in a Wiki project, the aim of which is to merge the wiki philosophy with knowledge management, enhanced by semantic (web) technologies. Sebastian Schaffert (Salzburg Research) puts it in a nutshell in the video below. Featured in a cameo appearance: the KiWI!

Sebastian Schaffert about KiWi – Knowledge in a Wiki on 12seconds.tv

This second day of TRIPLE-I 2008 was my personal folksonomy day, even though the theme was already set yesterday, with Andreas Hotho’s invited talk about “Extracting Semantics from Folksonomies” which was the opening lecture of the workshop “Knowledge acquisition from the Social Web.”

Andreas Hotho is directing the Bibsonomy project at Kassel University’s Knowledge and Data Engineering resarch group; Bibsonomy is a social bookmark and publication sharing system catering especially for researchers who, next to bookmarkingm also wish to manage publications. Next to other interesting things, Bibsonomy supports the import of bookmarks from del.icio.us, Firefox bookmarks and local BibTex files. Being a project led by a university’s computer science department, Bibsonomy is at the same time the result, the object and a stimulus for research in the area of tagging and folksonomies. Andreas describes this double appeal of folksonomies to both ordinary people and researchers in a 12 seconds vlog post:

Andreas Hotho’s statement about folksonomies and research (see www.bibsonomy.org) on 12seconds.tv

One of the outcomes of the research into folksonomies is FolkRank, a search algorithm that exploits the structure of folksonomies; the name reveals that it was inspired by PageRank, but as the graph of folksonomy structures does not correspond to the web graph, some adaptations had to be made. The specifics of these adaptations can be found in an online article by Andreas and his colleagues: “FolkRank: A Ranking Algorithm for Folksonomies” (PDF, 268 KB).

Andreas Hotho’s talk more specifically addressed the search for methods to identify tags which describe the same concept (or a more specific / a more general concept respectively) within a folksonomy. He suggested two approaches:

1. Applying measures directly to folksonomy statistics, allowing to describe tags as a vector; e.g. co-occurrence frequency and FolkRank could serve as a similarity measure (with these two having a tendency towards high-frequency tags) or a cosine method (which is more likely to produce “siblings”)
2. Looking up tags in an external thesaurus/vocabulary (for instance achieving semantic grounding by mapping a tag and its most similar tags with Wordnet Synsets)

Future areas of interest within folksonomy research Andreas proposed were trend detection, tag recommendation, detecting spam (a major challenge!), logsonomies (i.e. the structure of search engine query log files) and learning synsets, hierarchies, and structures of folksonomies. Andreas Hotho can be contacted via his homepage, if you have any further questions regarding Bibsonomy, FolkRank or this present piece of research.

Another presentation dedicated to folksonomies – and the presentation that won my personal presentation design award – was “Seeding, Weeding, Fertilizing – Different Tag Gardening Activities for Folksonomy Maintenance and Enrichment” by Katrin Weller and Isabella Peters, both from the Dept. of Information Science at Heinrich Heine University in Düsseldorf. The entire presentation was designed to match the CI of Tagcare, a tag gardening tool that is hopefully going to go online soon.

The term “Tag Gardening” was borrowed from James Governor who wrote in a 2006 blogpost:

“Like plants or animals, tags evolve in an emergent fashion, open to hybridisation. Stewardship can help grow and put roots down.

Helping the darwinian process is tag gardening.

Tag gardening is about taking tags in the wild and tending to them, or identifying a wild tag that will do well in your south facing IT

garden. I am talking about domestication here.

Just like there are professional bloggers i am pretty sure some parties will emerge that get paid for their abilities.”

I seriously hope that the latter is going to come true, even though I have the feeling that most providers will continue to consider user input and effort pro bono work!

Katrin Weller’s intro (Isabella Peters had excused herself) focused on the well-known problems with tags and folksonomies, e.g. :

• spelling variants, synonyms, abbreviations, different natural languages
• adhoc or personal functions of tags other than content description (e.g. “toread”, “@Henry”, “nicepic”)
• flatness of tag clouds which allows for browsing by popularity, but not by semantic interrelations

She further distinguished three levels where tag or tag cloud improvement becomes relevant:

• single document vs document collection level
• Single user vs collaborative level
• intra- and cross plattform level (e.g. different tagging conventions, tag separation with comma or blank space, etc)

To push the gardening metaphor even further, Kathrin presented us their ideas of weeding, seeding, fertilizing etc.:

Weeding
The weeds in this case are “bad” tags like spam or misspelled tags (weed: any plant that crowds out cultivated plants)
Aim: enhancing recall and a consistent indexing vocabulary
Achieved by: type-ahead functionality, editing funcionalities, natural language processing, user guidelines for indexing and retrieval, nomination of authorized users as gardeners

Seeding
Seeding in folksonomies means to expand frequently used tags by more specific tags (called “baby tags” or “seedlings” by Katrin Weller; seedling: young plant or tree grown from a seed)

Landscaping
The idea of landscaping here means to create “flower beds” through identifying species of tags, e.g. by similarity.
Aim: enhancing precision and expressiveness

Fertilizing
Fertilizing in this context means to combine folksonomies with other knowledge organization systems (KOS): thesauri, controlled vocabularies, ontologies, etc. (fertilizer: any substance such as manure or a mixture of nitrates used to make soil more fertile). Fertilizing might work both ways, Katrin suggested: a folksonomy might be fertilized with the semantic structure of a KOS, or a KOS enhanced by terms from a folksonomy.

And finally TagCare: The ambitious plan is to have a system that allows to import tag clouds from Flickr, deli.icio.us and Bibsonomy, cleanse out dissimilarities between tags, add hierarchical structure to the tag clouds, allow the user to view tag statistics and probably also to have community features, such calibrating one’s tags with those of the chief gardener or to activate collaborative spam elimination. It is going to be a free service, and if you want to be notified when it goes live, you might want to send an email to Katrin.

This full-service proposal for tag gardening does of course sound brilliant – yet is it going to be feasible, on a technical level? In the post-presentation discussion, somebody mentioned Faviki, which relies on DBpedia concepts to solidify the tag cloud. It didn’t exactly seem as though the TagCare team had already thought along these (semantic web) lines, even though this perfectly corresponded to their ‘Fertilizing’ idea. But if TagCare solely relies on good human gardeners, how long will it take until they have gained a big enough community to stimulate someone’s altruism? The idea of tag gardening of course is beautiful, and I am curious to learn more about the technology it is going to use.

Other folksonomy and tag related presentations that I was unable to attend or am unable to describe now, after the 10th hour of my 2nd day at TRIPLE-I, with a band performing folkore music involving yodeling and probably Schuhplattler right outside of this room:

• Quality Metrics for Tags of Broad Folksonomies (Celine Van Damme, Martin Hepp, Tanguy, Coenen, University of Brussels, Universität der Bundeswehr München
• Providing Multi Source Tag Recommendations in a Social Resource Sharing Platform (Martin Memmel, Michael Kockler, Rafael Schirru, German Research Centre for Artificial Intelligence DFKI)
• Semantic Tagging and Inference in Online Communities, Yildirim Ahmet, Ãœsküdarli Suzan, BoÄŸaziçi University
• Using Visual Features to Improve Tag Suggestions in Image Sharing Sites (Mathias Lux, Oge Marques, Arthur Pitman, Klagenfurt University)
• Harnessing Wikipedia for Smart Tags Clustering (Maria Grineva, Maxim Grinev, Denis Turdakov, Pavel Velikhov, Russian Academy of Sciences)

Please leave a comment if you think that any of the above needs correction.

EDIT: I got the chance to record another 12 seconds definition (and am thinking of setting up a video glossary for the Semantic Web now): Rolf Sint from Salzburg Research explains what folksonomies are and why folksonomies and ontologies go together well in 12 seconds! Rolf is also involved in the KiWi project, which aims to develop a wiki-based knowledge management system boosted by semantic technologies.

Rolf Sint explains folksonomies and their relation to ontologies on 12seconds.tv

The walls in room 3328, the observation room at Sun Microsystem’s usability lab in Prague, are painted a subdued blue. It swallows all the light, ensuring the testing scenario is not interrupted by curious guests like us, the Kiwi-project team members who were granted the privilege of a tour of the inner sanctum of Sun’s developer den. Through the one-way mirror, we can see a rosy-cheeked developer, talking to himself in Czech, interrupted by little sips from a coke bottle. He does not see us. The fact that very few of us understand Czech gives the situation an even more experimental appeal.

The new usability lab at Sun Microsystems, Prague

Jakub Franc, the cognitive psychologists in charge of the design of the study, explains to us that Sun rely on the Think Aloud method and observation in most of their test cases, rather than analyzing data from biofeedback sensors or eye-tracking devices. “Eye-tracking is good for testing the usability of web sites,” he says, “but for our purposes, the think aloud method, where the test person describes what he does and thinks, has greater benefits to offer.” The authenticity of the tasks to be performed in the study is a key: The developer behind the sound-proof glass wall is currently busy importing his own PHP application into NetBeans, Sun’s open source development environment, while the interaction designers and developers who created the tested module observe. A typical testing scenario lasts about 90 minutes, with the final 20 minutes consisting of an interview. “I always tell the testers that it’s not their fault if they fail to perform a task,” says Jakub. “If they fail, it’s the product’s fault. After all, that’s why we’re testing it.”

Before a software product is tested in its design or redesign phase, the ideal candidates are identified based on the results of questionnaires that are sent out to people in the tester database. The database includes both users of open source software as well as of competitive products, with the ideal test sample consisting of people who represent the whole spectrum of the target group, ranging from expert to newbie – and they must not necessarily be open source enthusiasts: “We offer a relatively high reward of 1000 CZK* as we want testers from all levels and backgrounds and not just the volunteering enthusiasts.”

Until Sun Microsystems moved into their new building in 2006, they collaborated with the Department of Computer Science at Czech Technical University (CTU), where they set up the very first usability lab in the Czech Republic in 2004. The deal was that Sun would supply the equipment and know-how, and CTU would supply the space and construction. Both institutions shared the facility until, after three years, all usage rights and equipment were transferred to CTU. One of the features of the new lab is the one-way mirror – the previous one relied on video observation: “From our experience, despite the fact that some participants feel less comfortable in this set-up, it makes a difference to observers”, writes Jiri Mzourek on his, i.e. one of the many Sun blogs, “they feel more connected to the participants”.

Jakub Franc, cognitive psychologist and usability researcher

Even though there is now an in-house usability lab at Sun, the collaboration between Sun and CTU continues, in particular in research and design projects. Students participate in projects led by Sun that focus on Sun products, learning about research methodology as well as gaining experience in project management in a real business environment. Jakub Franc also gives seminars in cognitive psychology and research methodology to CTU students, and is himself pursuing a PhD in environmental psychology – a relatively new discipline which, according to Jakub, deals with questions such as: “How should buildings be designed so that people are not getting lost in them? What recreational areas help people to recover from daily stress? What kinds of front gardens discourage burglars from invading the place?” In other words: Jakub studies the cognitive parameters of the usability of real objects.

Once the KiWi/Sun usecase enters the evaluation stage, the KiWi team will again be given access to the lab – but this time not as visitors, but as observers, witnessing how usable the KiWi-Wiki system really is to the inclined user. We are looking forward to the experience – and thank the designers of the lab for implementing a sound-proof wall, just in case the KiWis get emotional!

*) worth about 2 monthly passes for the metro in Prague, or 40 beers in a good pub

Semantic technology isn’t about technology: It’s noble concern is to make the life and work of people easier. Yesterday, Marek Schmidt and Petr Knoth, both working on PhD project within Natural Language Processing (NLP) at Brno University, introduced their vision of how Information Extraction could be integrated into the KiWi-System.

First off: What is Information Extraction? In natural language processing, “information extraction (IE) is a type of information retrieval whose goal is to automatically extract structured information, i.e. categorized and contextually and semantically well-defined data from a certain domain, from unstructured machine-readable documents” (Wikipedia). Marek and Petr’s vision for using IE in KiWi is to support the user in the creation of semantic annotations.

The image above illustrates their vision: If a user, for instance, enters the text “Hello, I am the best expert in Java around the Sun” into the content editor, structured information is extracted, analyzed on the fly and returned as suggestions. Through the application of reasoning on existing annotations and on further information that is available on the system – e.g. relevant domain ontologies, but also information about the user himself – the system will be able to infer new statements: E.g. the system will be able to infer that Bill Rodgers has Java programming skills, even though this information has never been explicitly stated in the knowledge base.

In the next session, Rolf Sint gave us insights into his approach to the combination of closed and open data classification mechanisms, which is informed by his findings in his master’s thesis. The probably most widely used retrieval method for digital content is full-text search; Google and Yahoo’s indexing methods, for instance, rely on full-text search. To be able to use this method, words must be contained within the content, leading to obvious problems with synonyms, ambiguities or the different lexical inventory of different languages. Advantages are that full-text search is easy to use, and that no maintenance is required as this responsibility rests with the content providers.

On the other end of the spectrum, within open data classification mechanisms, we have social tagging. Tagging (in general) means that a user asigns labels to content items. The advantage here is that content is immediately classified; as such, tagging is an easy way to provide metadata for content, in particular as the user does not to have think about (arbitrary, system-dictated) structures. However, this leads to problems if singulars and plurals are used simultaneously, if synonyms are used, spelling mistakes occur etc etc. With tags, the exact same spelling has to be used if items are to be assigned to the same group. But if done collectively (and that is what social tagging is about), the wisdom of crowds can improve the signal to noise ratio significantly – see the miracle of the tag cloud.

What Rolf proposed in his thesis was to combine the two approaches. In his design, he used an extended thesaurus as an instrument to achieve vocabulary control – we’re looking at an extended thesaurus here, because it’s not simply built around a taxonomy, but expanded by tags that were assigned by users and integrated using a vocabulary management tool.

This extended thesaurus can be applied in multiple ways. (more…)

Yesterday we dealt with reports, user interaction and interface questions, today is usage data model day (or morning) in the KiWi РKnowledge in a Wiki - Project. Usage data model means that it is concerned with an abstract conceptualization of the data as perceived by the user (and not by the developer/implementer) Рat the same time, it is not immmediately concerned with the visualization of data on screen. Fran̤ois Bry gave us an overview of the proposed core concepts and objects which are currently: content item, tag (and tagging), link, rule, user, and access right.

There is no need for me to repeat his full presentation, as François had already in advance made his presentation available on the KiWi-project wiki. Nonetheless, I’d like to highlight a few aspects:

A content item is to be understood as a slight generalisation of a wiki page: Every wiki page is a content item, but not every content item is a wikipage, and content items that are no wiki pages are part of a wiki page. This could include, for instance, media content such as pictures, diagrams or tables. This modularization (content items within pages) meets the demands of the proposal that Kiwi-pages must be composable.

Consequently, not only wiki pages but content items too must be taggable (which takes us to: tagging). Furthermore, it was proposed to make a distinction between atomic tags (short; consisting of a tag name and an associated content item instead of a description) and structured tags (that are made up of atomic tags), as well as between explicit tags (that are applied by users) and implicit tags (that are generated on the basis of rules that have been defined by users).

To illustrate this distinction, I’ll paste in a few illustrating explanations from François’ wiki report:

The tags assigned to the content item of an atomic tag T can be seen as tags assigned to the atomic tag T itself. Tagging of tags in this way can serve, for example, to distinguish between the atomic “hotel” in English and the same atomic tag “hotel” in French or to group or classify tags. [...] A structured tag is build up from atomic tags. [...] Examples of structured tags are as follows:

hotel(3stars downtown)
hotel(location(downtwon))
hotel(comfortable)

A heated debated ensued (which I quite like, because that is the point where our own, yet unchallenged assumptions are exposed), in particular with regard to the implementation of structured tags: Wouldn’t that mean to raise the cognitive barrier too high if users were required to enter complicated tags?

Much was clarified with the agreement that users may use structured tags, but that this wouldn’t be a requirement. Using complex tags (e.g. a structured tag that includes dates or deadlines) might make sense to a particular set of users (e.g. project managers in the Logica use case) – and whether a software feature is going to be used (successfully) or not is primarily depending upon the question whether the user sees a benefit in it or not. Also: The concept of structured tags within the data model does not yet say anything about the way they will be represented on screen – in most cases, users won’t see a hotel(location(downtwon)) spelled out.

On to the coffee break!

[Image: Physical tagging on a tree, by Jean Etienne Poirrier]

Josef Holy’s report this morning about the status quo in the KiWi usecase conducted in collaboration with Sun microsystem presented us with an interesting contrast. While the point of departure in the Logica usecase was a conceptual model of knowledge that is shaped by CMMI, Josef made the point that software development in an open source project follows quite different rules: “The lack of formal processes IS the process”, said Josef, characterizing the collaboration in the NetBeans development environment which (as reported earlier) has about 200 Sun developers working on it, in addition to thousands of external contributors and hundreds of thousands of active users. Correcting his own presentation regarding the development process from May ‘08 he said: “We shouldn’t think of a production pipeline here, but of a graph.”

Within Sun (or any software development project), one can draw a distinction between three groups of people working on a software project, depending upon the intensity of interaction and impact they have on the project: First of all, you have the planners, designers, developers and testers who interact intensely and whose work strongly affects the actual product. Secondly, you have people like the documentation writers who describe a software, but who do not shape it. And thirdly, there are people who translate the work of the second level to different markets or target groups, e.g. people working in localization.

A first important decision to be made was: Who to involve in the KiWi usecase? As the KiWi approach is decisively informed by the wiki philosophy, it only made sense that the designers, rather than the developers, should participate. Designers need to have access to various repositories of information, for instance user interface specifications, requirements descriptions, usability reports, marketing intelligence data, etc. And, to a much greater extent than is the case with developers, their work relies primarily on the written word, in the form of definition and documentation. And that makes them ideal candidates in the KiWi-Wiki usecase.

P.S: Yes, we all know that documentation is also a crucial part of the work of developers – yet we also know that the world has seen a lot of software developments that went undocumented;-)

Peter Axel Nielsen, a researcher from Aalborg University who is working on the Logica usecase, started his report by giving us an overview of CMMI, a process improvement approach that is being used by Logica and that is thus going to be of eminent importance for the KiWi/Logica usecase.

CMMI stands for Capability Maturity Model® Integration, and, according to its inventors, “helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.” CMMI was created by the Carnegie Mellon Software Engineering Institute, and has been adopted worldwide.

CMMI provides a framework for a 5-step path towards maturity in software process improvement – a path that can be expected to take years and which demands a company’s full commitment. Peter drew our attention to a volume, fresh from the printing press, which he edited together with Karlheinz Kautz: Software Process & Knowledge. Beyond Conventional Software Process Improvement.*) The volume contains an interesting CMMI case study, “The Road to High Maturity. How the first Danish company reached CMMI level 5 in 100 months,” in which the authors emphasize that software process improvement, in essence, is “an organizational change process, that is, the processes in an organization, and the behaviour and interaction of people, groups, projects and, in fact, the whole organization.” Some of the benefits reported by the participants in the case study were: reduction of overtime, increased satisfaction of employees, increased opportunities to delegate as a result of formal definitions of roles and greater ease to move between projects.

Switching to CMMI brings with it the benefits of a well-defined, ready to use conceptual model of knowledge – this is, of course, an invaluable asset when it comes to defining the requirements of the KiWi system, which is going to be used as a wiki-based, semantically enhanced knowledge management system for IT project management in the Logica usecase.

*) Peter Axel Nielsen, Karlheinz Kautz (eds.): Software Process & Knowledge. Beyond Conventional Software Process Improvement. Software Innovation Publisher. Aalborg. 2008. ISBN 978-87-992586-0-4 See also: website of the symposium on Software Process & Knowledge that preceeded the publication.

So here we go again, the KiWi and me: Today, tomorrow and Friday I am in Prague with my colleagues Andreas Blumauer and Matthias Samwald, attending the first Joint Workpackage Meeting in the EU-funded project KiWi – Knowledge in a Wiki. The present meeting is hosted by Sun Microsystems - Josef Holy and Inka Havlova gave us a very warm welcome, but thankfully the Sun offices are the direct opposite, namely perfectly chilled on this hot June day:-)

The day started with Sebastian Schaffert, project coordinator from Salzburg Research, giving us an overview of the actitivies of the first quarter in the project and a primer on the objectives of the meeting. The overall concern of this full meeting, in order to align core developments of the project early on, is to develop a common understanding of the functionalities and behaviour of the KiWi system, to define a core data model and to develop an outline for the upcoming dissemination plan.

An IT project is like herding cats, they say – in our case, we’ll be herding kiwis, and if we can enjoy it only half as much as these guys, I’ll be fine:-)

The first session is coming up: Peter Axel Nielsen’s report from Work Package 5, i.e. the usecase developed by Logica and Aalborg University. More updates coming up soon!

“Communion must be symmetric”, well-known painter Salvador Dalí once said about Leonardo’s masterpiece “The Last Supper“. I could not help feeling reminded of this phrase when I made this snapshot at the European Semantic Web Conference 2008 in Tenerife. I took this picture at the panel discussion entitled “Does the Semantic Web Need Web Science?”. The central position of Stefan Decker, director of DERI Galway, might have some meaning: his institute had by far the most representatives and published papers at the conference, according to the nice ESWC2008 linked data browser (powered by RDF and the Exhibit data exploration tool).

Oh, and I really do think that the Semantic Web needs web science.