REPORT COVER PAGE - Intelligente Lösungen für die ...aabecker/D4.doc · Web viewFigure 7 – Input Form for adding a KM Application/Process to the KM Library ... displays query

WP4 KnowNet Tool Documentation

Know-Net

Project number: EP28928

Project Title: KnowNet

Title of deliverable: Tool Documentation (1st Version)

Availability: Confidential

Number: D4.2

Version: Final Version

Date of delivery: 30th September 1999

Workpackage: WP 04

Nature of document: Report

KNOWNET/D4.2 i PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


Table of Contents

1. DESIGN CONSIDERATIONS AND BASIC CONCEPTS........................1

1.1 Scaleability of the Know-Net Tool.......................................................................11.2. Fundamental Elements of the Know-Net Tool.....................................................21.3. Linking the Framework and Methods to the Tool.................................................31.4. Integrating the Framework, Methods and Tool....................................................4

2. THE KNOW-NET KNOWLEDGE NAVIGATORS.....................................5

2.1. Introduction........................................................................................................5 2.2. Strategic Knowledge Navigator (SKN)................................................................6

2.2.1 KM Strategy link....…………………………………………………………………72.2.2 KM Processes link......................................................................................102.2.3 KM Assets link...........................................................................................152.2.4 KM Structure link........................................................................................222.2.5 KM Systems link........................................................................................242.2.6 KM Networks link.......................................................................................26

2.3. Knowledge Worker Navigator (KWN)................................................................28

2.3.1 One Place..................................................................................................292.3.2 What's New................................................................................................312.3.3 Who's Who................................................................................................332.3.4 Search.......................................................................................................362.3.5 Meetings....................................................................................................802.3.6 Discussions................................................................................................822.3.7 Libraries.....................................................................................................832.3.8 Processes..................................................................................................862.3.8 Projects......................................................................................................872.3.9 Personal....................................................................................................892.3.10 Help..........................................................................................................90

2.4. Knowledge Systems Administrator Navigator (KSAN).......................................91

KNOWNET/D4.2 ii PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


2.4.1 KM Processes/Applications Library.............................................................92

2.4.1.1 KM App's Library……………………………………………………….......…92

2.4.1.2 One Place Forms……………………………………………………….....…94

2.4.2 K Assets....................................................................................................96

2.4.2.1 K Assets Directory...............................................................................962.4.2.2 K.Objects Directory..............................................................................99

2.4.2.3 K.Objects Store.................................................................................101...................................................................................................................................... 2.4.3 K Systems ...................................................................................................102 2.4.4 Ontology Editor........................................................................................103

3. THE KNOWLEDGE MANAGEMENT PROCESSES............................104

3.1. Introduction....................................................................................................1043.2. The Knowledge Management Processes/Applications Library.........................1053.3. Description of the Know-Net KM Processes/Applications................................1063.4. Metadata Management ..................................................................................107

4. THE KNOW-NET KNOWLEDGE SERVER..........................................108

4.1. Why a Knowledge Server?.............................................................................1084.2 Definitions and Basic Concepts/Components..................................................1094.3 The Fusion of the Content-Centric and the Process-Centric Approach...........111 4.4 Knowledge Objects Directory..........................................................................1124.5 Knowledge Objects Store...............................................................................112

5. THE PERSONAL KNOWLEDGE PORTFOLIO TOOL.........................1135.1 Overview........................................................................................................1135.2 MailTack Philosophy.......................................................................................1135.3 E-mail Knowledge Base MailKB......................................................................1135.4 Graphic User Interface....................................................................................1145.5 Creating a MailKB knowledge base.................................................................1145.6 Editing a MailKB knowledge base...................................................................1155.7 Navigating a MailKB knowledge base.............................................................1155.8 Searching a MailKB knowledge base..............................................................1165.9 Other functions...............................................................................................116

5.9.1 Importing any text................................................................................1165.9.2 Writing new E-Mails.............................................................................116

5.9.3 DB Administration.........................................................................................116

KNOWNET/D4.2 iii PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


Know-Net Tool Documentation

KNOWNET/D4.2 iv PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


KNOWNET/D4.2 v PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


1.0 Design considerations and Concepts

1.1 Scaleability

The Know-Net Tool Technology has been designed to be fully scaleable, from supporting and enabling a small team of knowledge workers, as a project and/or pilot – to supporting and enabling a Global Enterprise Wide Knowledge Management System.

Typically, the Know-Net Tool could support and enable the following:

- A virtual team of consultants connected by Intranet, but based in different offices/locations/countries (eg Gooch Webster and Planet)

- A department and/or process (eg The UBS Credit Risk Department)

- A Business Unit and /or Business Function (eg Research & Development)

- A Company/Organisation

- A Global Group of Companies/Organisations

Although the Know-Net Tool documentation has been written for describing the whole Organisation, particularly when discussing and describing the merits and benefits of the Know-Net Knowledge Server, for centralising and managing Knowledge Assets and Knowledge Networks across the Organisation, the principles can be equally and effectively applied at any level. It is certainly strongly recommended to introduce the Know-Net Tool at a pilot level, in the first instance, and then increase the deployment of the Tool to the required level, at the required rate.

Therefore, although words like Organisational KM Vision , KM Strategy, KM Objectives etc are used throughout, they can equally refer to a team KM Vision and Objectives, a departmental KM Vision and Objectives, or a pilot KM Vision and Objectives. Furthermore, reference at the Organisational level to a Chief Knowledge Officer/Director of Knowledge Management may not be appropriate to a team KM initiative, but the principles and responsibilities behind these new KM roles would still apply at any level, albeit to a lesser degree.

The different types of Navigator used in the Know-Net System, described in this documentation for the ‘entire‘ Organisation, could equally be applied for just the team, department, or Business Unit etc.

KNOWNET/D4.2 1 PLANET, KNOWLEDGE ASSOCIATES, INSEAD, DFKI, ICCS, FHBB, UBS, GW


1.2 Fundamental Elements of the Know-Net Tool

The Know-Net Tool has three fundamental elements and associated components, as listed below:

The Know-Net Knowledge Navigators

Strategic Knowledge Navigator (SKN)

Knowledge Worker Navigator (KWN)

Knowledge Systems Administrator Navigator (KSAN)

The Knowledge Management Processes/Applications

The Know-Net Knowledge Server

The KM Processes/Applications Library

The Knowledge Objects Directory

The Knowledge Objects Store

Figure 1 – Fundamental Elements of the Know-Net Tool


S KN KS ANKW N

KM P roc es s / Apps Library

K O bjec ts D irec tory

K O bjec ts S toreKM S ys tem sVoc abulary

Lo tu s D o min o 5 / S a m e t ime S e rv e r

RD BM S

K N av igators

KMP roc es s es / Apps

K S erver


1.3 Linking the Framework and Methods to the Tools The first step in designing the Know-Net Tool was to identify and specify the clear linkages that will occur between the Architectural Framework, the Consulting Methods and Tools, and the Know-Net Technology, according to the Know-Net deliverables.

D1.1 defines the Architectural Framework and Holistic Requirements for Know-NetD2.1 defines the User Requirements SpecificationD3.1 defines the prototype of the Know-Net Tool Specification D6.1 defines the Know-Net Diagnosis (Stage 1 of the Consulting Method)D7.1 defines the Knowledge Transformation to a Knowledge Organization (Stage 2 of the Consulting Method)D8.1 defines the Knowledge Evaluation MethodD9.1 reports on the Awareness Creation at User Companies

This document, D4.2, is the Know-Net Tool Documentation.

Figure 2 below shows the linking between the Architectural Framework, Methods and Tools.

Figure 2 - Linking the framework and methods to the tools


Linking the Framework, Methods and Tools

Arc hitec tural F ram ew orkD 1.1

Know ledgeD iagnos is(S tage 1)

D 6.1

Know N et T oo lD 4.1

Know ledge Evaluation M ethodD 8.1

Know ledgeT rans fo rm ation

(S tage 2)D 7.1


1.4 Integrating the Framework, Method and Tools

In designing the Know-Net Tool Architecture and components, we have been particularly concerned to ensure that the Framework, Methods and Tools are seamlessly developed into 'one integrated KM Solution'.

Figure 3 shows the more detailed linkage between the Architectural Framework, Methods and Know-Net Tool


One integrated KM Solution


Figure 3 - The detailed linkage between framework, methods and tools

2.0 The Know-Net Knowledge Navigators

2.1 Introduction

The first consideration in the design is the appropriateness and suitability of integrating the Architectural and Holistic Framework into the Know-Net Tool.


Integrating the Framework Arc hitec tural F ram ew ork

D 1.1

Know ledgeD iagnos is(S tage 1)

D 6.1

Know ledge Evaluation M ethodD 8.1

Know ledgeT rans form ation

(S tage 2)D 7.1

S KN KS ANKW N

KM P roc es s / Apps Library

K O bjec ts D irec tory

K O bjec ts S toreKM S ys tem sVoc abulary

Lo t u s D o m in o 5 / S a m e t im e S e rv e r

RD BM S

K N avigators

KMP roc es ses / Apps

K S erver


The most appropriate consideration could be as a Navigator.

From a knowledge professional/knowledge workers perspective, in his/her day to day work, this would be too high level and abstract to relate to the practicalities of the day. Instead, a very simple to use, pragmatic and highly practical Navigator is sought here. We have called this navigator the ‘Knowledge Worker Navigator’ (KWN).

From a KM Systems Administrators point of view, the Know-Net Framework is much more relevant, from a technical infrastructure perspective, but not in its entirety. We have developed a technical Navigator the ‘Systems Administrators Knowledge Navigator (SAKN).

However, from a Chief Knowledge Officers (CKO) perspective, or Director of Knowledge Management, and/or a KM Consultants point of view, the Know-Net Framework is highly relevant. Not least, in the design and implementation of a KM Solution. The Know-Net Framework, therefor, has been integrated as part of a ‘Strategic Knowledge Navigator’ (SKN) to the Tool . Furthermore, it will provide the design framework and potential for integrating key aspects of the Method (Stages 1 & 2) directly into the Tool.

There could be merit in having a ‘switchable navigator’ between several or all three Navigators. In the early version of the Know-Net Tool (version 2) we will provide a switchable navigator between all three Navigators, to enable Know-Net Partners for testing and evaluation purposes.

Launching the Know-Net Tool through a browser will, by default, launch into the Knowledge Worker Navigator (KWN). At the top left of this Navigator is a temporary switchable Navigator panel – ‘SKN KWN SAKN’

However, it is important to emphasis here that the final stage of the Know-Net Tool we will have ‘access control’ capabilities built in, to ensure that only appropriate users have access to the appropriate Navigators. This will be managed in the ACL by user name and/or group name and passwords.



2.2 Strategic Knowledge Navigator (SKN)

Figure 4 – Strategic Knowledge Navigator


Strategic Knowledge Navigator


2.2.1 To develop a KM Strategy and Objectives

Section 3.4.1 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 45) defines the Knowledge Management Strategy as follows:

‘The “strategy component of the KMI (Knowledge Management Infrastructure) refers to the company’s values and mission, i.e. the knowledge-related strategic values of the company, the specific knowledge-related business objectives, and the explicit and/or implicit links of knowledge strategy to business strategic objectives/goals. ‘KM strategies begin with strategy, not knowledge’

It defines the KM Vision, Culture, and importance of Strategy as:

‘ Realising the complete vision of an innovative, knowledge-sharing organisation is probably a long-term objective for most companies. Organisations should focus on both obtaining real benefit through ‘quick-win’ projects and the long term vision…It is almost certainly the case that the vision of the perfect knowledge culture is an unachievable ideal. However, it is a worthwhile aspiration and provides strategic direction.’


Step 1. Develop a KM Strategy & Objectives


To assist the CKO and/or KM Consultant in applying the Know-Net Method we have designed a link between ‘Strategy’ in the Framework and the Know-Net Tool.

Clicking on the ‘Strategy’ hotlink or ‘KM Strategy’ on the side Navigator, will launch an application/process to identify and store the KM Vision, Mission, Values, Principles and Objectives, determined by the CKO and/or KM Consultant (this launches knowledger.objectives from Knowledger 2.0 )

Figure 5 below shows a sample listing of the KM Objectives


)


Figure 5 – Sample Listing of KM Objectives

The application will automatically write the following highest level ‘knowledge objects’ to the ‘Knowledge Objects Store’ which is part of the ‘Knowledge Assets’ to be managed.

KM Vision object KM Mission object KM Values object KM Objectives objects (one per Objective)

Knowledge objects and Knowledge Objects Store are defined in more detail below.

These ‘High level knowledge objects’ are written into the hierarchical knowledge store with a ‘level of Knowledge Asset code’ set to 1 (highest level). This can be overwritten, and levels changed by the KM Consultant from within the knowledge objects store.



2.2.2 To identify the KM Processes

Section 3.4.2 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 46) discusses the Knowledge Management Processes.

‘The knowledge management processes of the Know-Net KMI can be classified within the following five groups: acquisition, organisation, dissemination, use and creation….…Before investing heavily in the development of new capabilities, companies should know what knowledge and expertise exist both inside and outside themselves. One way to increase internal knowledge transparency is by creating knowledge maps, which support systematic access to parts of the organisational knowledge base.’

At an even higher strategic level, in the first instance, it is valuable to ‘map the key business processes’ that are critical to the business, and identify the knowledge objects that the key business processes create.

To assist the CKO and/or KM Consultant in applying the Know-Net Method in this regard, we have designed a link between ‘Processes’ in the Framework and the Know-Net Tool. Processes, in this instance, are the key business processes (strategic and operational) that create the key knowledge objects.


Step 2Identify the KM Processes


Clicking on the ‘Processes’ hotlink or ‘KM Processes’ on the side Navigator, will launch an application/process to identify, list, manage and execute the ‘KM Processes/Applications Library determined by the CKO and/or KM Consultant.

The KM Processes/Applications Library is designed to contain a growing suite of KM applications that perform the key business and operational processes. These processes/applications are the prime source to create, amend and delete ‘knowledge objects’.

In other words, the KM Applications contain the Processes that create the knowledge objects.

The application will automatically write the following high level ‘knowledge objects’ to the ‘Knowledge Objects Store’ which is part of the ‘Knowledge Assets’ to be managed.

KM Process object(s) – one per process entered Knowledge objects – as defined by the KM Process/Application and/or KM

Consultant

Knowledge objects and Knowledge Objects Store are defined in more detail below

These ‘High level knowledge objects’ are written into the heirarchical knowledge store with a ‘level of Knowledge Asset code’ set to 2 ( second highest level). This can be overwritten, and levels changed by the KM Consultant from within the knowledge objects store.

The idea behind entering levels, i.e. level 1 – highest level and level 2 – second highest level, is to create a simple and flexible/changeable Organisation Knowledge Asset/object map, showing the hierarchy and relationships.

By clicking, from the SKN, on the ‘KM Processes’ the Processes and applications to support the processes can be viewed and listed as follows:

By KM Application Code - a straight listing of all processes sequenced by a meaningful code to the organisation

By Knowledge Objects Created – for each process entered, it is necessary for the KM Consultant to identify and enter the knowledge objects that the process creates. It is then possible to view and list all the knowledge objects in sequence, and see all the processes/applications that are the sources that produce them.

By Application Category – each process/application can be categorised. It is then possible to view and list all the processes by meaningful category to the organisation.



In other words, the above views enable the CKO/KM Consultant to develop

and maintain simple, but powerful, knowledge process maps and knowledge objects maps.

Figure 6 below shows a listing of KM Applications, sorted by Category

Figure 6 – KM Applications, sorted by Category

It is strongly recommended that, in the absence of a better process categorisation in the Organisation, that the ‘AA Process Classification Scheme’ as detailed in Appendix 5 of the Know-Net Diagnosis Guide, D6.1 be used by the CKO and/or KM Consultant, as the key strategic business processes to include (or strategically plan to include), as summarised below:

1.0 Understand Markets and Customers (Market/Customer Knowledge)

2.0 Develop Vision & Strategy (KM Strategy)

3.0 Design Products & Services (R&D/Innovation)

4.0 Market & Sell

5.0 Produce & deliver products and/or services

6.0 Invoice and service customers



7.0 Develop and Manage Human Resources

8. 0 Information Resources and Technology

9.0 Manage Financial and Physical Resources

10.0 Execute Environmental, Health and Safety Program

11.0 Manage External Relationships

12.0 Manage Improvement and Change

(Note The current Know-Net Tool V2 has been pre-populated with the above categories of process, as a starting template for the Organisation. For each of the above categories, there will be/is below listed, each of the KNAS Knowledger 2.0 Process/Applications that can contribute to or perform the key processes in the business.

The KM Processes/Applications Library has been designed to be able to list all other existing Applications that exist in the Organisation (non Know-Net or Knowledger 2.0) regardless of their type and location (e.g. IBM Mainframe Sales Order Processing System written in COBOL) and categorise them, so that the CKO/KM Consultant can consider the better integration, usage and implementation of all systems across the Organisation. Furthermore, the KM Consultant can also add the knowledge objects descriptions, that the non Know-Net Applications produce, to the knowledge objects directory – to ensure even better Knowledge Asset Management and re-use.

Figure 7 below shows the input form that the KM Consultant must complete to add a new KM Process/Application to the library.



Figure 7 – Input Form for adding a KM Application/Process to the KM Library



2.2.3 To identify the KM Assets

Section 3.3 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 41) discusses the Knowledge Assets.

‘The first step in framing a knowledge management approach is to understand the main characteristics of knowledge assets [see also Day and Wendler (1998)]

Know-Net focuses on three types of knowledge assets which are dynamically interwoven

human knowledge assets, that generate organisational capabilities structural knowledge assets, that generalise the human capabilities market knowledge assets, that gauge the products and services of the

company

Human Knowledge Assets Staff capabilities Staff experience Staff skills Creativity of staff Innovation of staff

Market Knowledge Assets Knowledge about Industry Knowledge about Customers Knowledge about Partners Knowledge about Competitors

Structural Knowledge Assets Patents, Methods Best Practices Administrative systems Training Seminars R&D Material Company standards/processes

A Knowledge Asset can be composed of a ‘knowledge object’ or cluster of knowledge objects, depending on degree of importance to the organisation. Knowledge Assets, therefore, need to be identified and given a hierarchy. At a strategic and operational level, it is critical to ‘ define and map the knowledge assets that are critical to the business, and identify the knowledge object(s) that the knowledge asset contains. To assist the CKO and/or KM Consultant in implementing the Know-Net Method in this regard, we have designed a link between ‘Assets’ in the Framework and the Know-


Step 3Identify the KM Assets


Net Tool.



Clicking on the ‘Assets’ hotlink or ‘KM Assets’ on the side Navigator, will display three sub-menu options:

K Assets Directory K Object Directory K Object Store

As illustrated in Figure 8 below



Figure 8 – KM Assets sub-menu items

To create a new Knowledge Asset, the KM Consultant selects K Assets Directory. A listing of K Assets will appear, as per Figure 9 below.

A further description of the use of the Knowledge Objects Directory and the workings of the Knowledge Objects Store, is given in Section 4 – The Know-Net Knowledge Server.



Figure 9 – Listing of categorised Knowledge Assets

To create a new Knowledge Asset, the KM Consultant selects the ‘Create Primary K. Asset’ button and completes the following input form, as shown in Figure 10 below.



Figure 10 – Input Form to create a primary Knowledge Asset

The create a Knowledge Object the KM Consultant first selects the ‘K Object Directory’ from the sub-menu, and a listing of Knowledge Objects appears, as per Figure 11 below.



Figure 11 – Listing of Categorised Knowledge Objects

To enter a new Knowledge Objects the KM Consultant selects the ‘Create new Primary Knowledge Object’ button and completes the input Form, as illustrated in Figure 12 below.



Figure 12 – Input Form to create a new Primary Knowledge Object



2.2.4 To determine the KM Structure

Section 3.4.3 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 48) discusses the Knowledge Management Structure.

‘The need for an explicit, formal organisational structure that directs, facilitates and supports the knowledge management related activities within a company has been identified and discussed in recent academic as well as business related literature.’

There exist a variety of specialist roles related to knowledge management.

At a strategic level, it is valuable to identify and list the people and roles that are critical to the knowledge management project – the ‘KM Team’.

To assist the CKO and/or KM Consultant in implementing the Know-Net Method in this regard, we have designed a link between ‘Structure’ in the Framework and the Know-Net Tool.

Clicking on the ‘Structure’ hotlink or ‘KM Structure’ on the side Navigator, will launch an application/process to identify, list and manage the ‘KM People, Roles & Responsibilities determined by the CKO and/or KM Consultant, as illustrated in Figure 13 below.


Step 4Determine the KM Structure


Figure 13 – Listing of KM People Roles & Responsibilities

The application will automatically write the following ‘knowledge objects’ to the ‘Knowledge Objects Store’ which is part of the ‘Knowledge Assets’ to be managed.

Person object – one per person entered

Knowledge objects and Knowledge Objects Store are defined in more detail in below.

These level 3 knowledge objects’ are written into the hierarchical knowledge store with a ‘level of Knowledge Asset code’ set to 3 (people objects can then be mapped to process objects, project objects etc. This can be overwritten, and levels changed by the KM Consultant from within the knowledge objects store.

2.2.5 To determine the KM Systems



Section 3.4.4 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 53) discusses the Knowledge Management Systems.

‘The Know-Net partners believe that the role of technology is to enhance human possibility. Systems should free the nodes of knowledge networks (be they individuals, teams or organisations) to realise more fully their values intentions and possibilities. Technological systems should support and facilitate the fundamental issues of knowledge networking and not undermine them in any way. Systems should be in their service and not designed so that they are in its service.

Know-Net confronts the challenge of developing and using technology to serve both the interests of individuals, teams, organisations and of their larger communities. Such challenges will be met successfully only by focusing technology on the increase of knowledge, individually and for the whole’

Therefore, at a strategic level, it is valuable to identify and describe the KM systems that are critical to the knowledge management project.

To assist the CKO and/or KM Consultant in implementing the Know-Net Method in this regard, we have designed a link between ‘Systems’ in the Framework and the Know-Net Tool.

Clicking on the ‘Systems’ hotlink or ‘KM Systems’ on the side Navigator, will


Step 5Determine the KM Systems


launch an application/process to identify, define and list the ‘KM Systems’ determined by the CKO and/or KM Consultant, as illustrated in Figure 14 below.

Figure 14 – Listing of KM Systems

The application will automatically write ‘knowledge objects’ to the ‘Knowledge Objects Store’ which is part of the ‘Knowledge Assets’ to be managed.

Knowledge objects and Knowledge Objects Store are defined in more detail below.

These ‘High level knowledge objects’ are written into the hierarchical knowledge store with a ‘level of Knowledge Asset code’ set to 2. This can be overwritten, and levels changed by the KM Consultant from within the knowledge objects store.



2.2.6 Knowledge Networking LevelsSection 3.5 of the Architectural Framework & Holistic Requirements for Know-Net, D1.1 (page 54) discusses the Knowledge Networking Levels.

To assist the CKO and/or KM Consultant in implementing the Know-Net Method in this regard, we have designed a link between ‘Individual, Team, Organisation and Inter-Organisation’ in the Framework and the Know-Net Tool.

Clicking on the hotlinks or side Navigator, will launch an application/process to identify, define and list the Knowledge Networks determined by the CKO and/or KM Consultant,As illustrated in Figure 15 below.

.


Step 5Determine the KM Systems


Figure 15 – Listing of Key Knowledge Networks



2.3 Knowledge Worker Navigator (KWN)

From a knowledge professional/knowledge workers perspective, in his/her day to day work, the Know-Net Holistic Architectural Framework would be too high level and abstract to relate to the practicalities of the knowledge workers day. A simple to use, pragmatic, highly relevant and highly practical Navigator is sought here. We have called this the ‘Knowledge Worker Navigator’ (KWN), as illustrated in Figure 16 below.

Figure 16 – Knowledge Worker Navigator



2.3.1 One PlaceThe Know-Net User Requirements (D2.1), and the continual research and experience of the Know-Net Partners, in developing the next generation of practical systems for knowledge workers, shows that they are ‘ideally’ looking for a KM System and Navigator that will enable them to perform the following - much faster, much easier and much more intuitively:

Go to ‘One Place’ only, to enter any new information into the system, with a maximum of two clicks of the mouse to receive the appropriate entry form.

At present, a knowledge worker will typically have to launch a specific Application to then enter Contacts and Organisations; launch another Application to enter Tasks, Project team members, details for a specific Project etc; launch another Application to enter a good idea, or another Application to enter a personal learning, or a Proposal, or write a specific R&D report/White Paper, or enter a timesheet, a diary appointment, a personal to-do list item (as well as a specific project task), a goal, a competence etc.

Our research and experience shows that a typical knowledge worker is continually ‘switching thoughts’ from minute to minute in his/her thinking from say, client/project work - to receiving new telephone calls and new contacts/information. New ideas pop up at the least expected times during the day. Tasks are continually being changed and re-prioritised.

Currently, having to interrupt work and go to a specific application to add a contact or an idea, with current applications, can be slow and is not in line with the way our brain typically works. As a result, much valuable information gathered by the knowledge worker is not added or updated into the KM system ‘because it is too much effort and I simply don’t have the time’.

By first selecting and clicking ‘One Place’ on the Navigator

- a listing appears, in alphabetical sequence – in one central place, of all the input forms from all the Applications that the knowledge worker uses in his/her daily work, as illustrated in Figure 17 below.



Figure 17 – One Place Listing

By clicking once on the selected input form, it appears ready for entering data. The data will then be entered directly into the Application.

The maintenance of the input forms, that appear in this list, is performed by the Knowledge Systems Administrator from the KSA Navigator, described in detail later. It is a simple and quick procedure to add/ amend/delete a form from this list. This facility will also work for any non Know-Net ‘Notes’ Application (as in the case for Gooch Webster) and possibly any non Notes Application (currently being investigated)

The Know-Net Knowledge Worker Navigator will therefore provide one quick input facility of new information into any Application, as it becomes available to the knowledge worker.



2.3.2 What’s New

At present, many knowledge workers have to spend much time ‘trawling’ through databases to see if new items of importance, relevance, and needing attention, have been added to the system, on a daily basis.

By clicking on ‘What’s New’ - going to ‘one place, to see what has been added’ - the knowledge worker can quickly ensure that he/she is fully informed and up to date. This concept is based on the KM ‘Share Model’ where a knowledge worker can go to look for something when he/she wishes, as opposed to the ‘Send Model’ where all new notifications are ‘pushed’ through the e-mail to all users, adding to the e-mail traffic and e-mail overload.

Figure 18 – What’s New

The Know-Net Tool will embrace both models above and

- Email notification of ‘Mandatory Readings’ to the user and insert in the What’s New database

- Insert only into the Whats New database ‘non-essential’ readings



A ‘search agent’ will automatically go through all the underlying (Notes) databases :

- within the designated Know-Net Applications and- within the designated non Know-Net Notes Applications

and provide a list of links to all new documents added/amended/deleted, in date sequence. The user can then, optionally, click on any link and go directly to the new document.

The agent can be set to run by the Knowledge Systems Administrator, at pre-determined times. (Note: The agent is currently set to run once a day at 12 midnight GMT)Details for setting up and maintaining Domino Agents are referenced in the Know-Net Knowledge Server.



2.3.3. Who’s WhoThe above described ‘What’s New’ feature is concerned with assisting the knowledge worker to keep up to date with new explicit ‘content’ added to the KM System. It connects and points ‘people to information’.

However, far more valuable knowledge in the Organisation resides in the ‘heads of the individuals’ the tacit knowledge. This will always be the case, despite increasingly successful initiatives to make tacit knowledge more explicit in more disciplined and codified KM systems. This is because knowledge, at any one point in time in the Organisation, will be in a state of rapid change of form - becoming obsolete, in a state of new creation, and/or renewal. This process of creation, renewal, deletion is first performed in the heads of the knowledge workers and ‘tacit’ knowledge, therefore, will always be the prime source of critical knowledge.

This means that quickly and easily ‘connecting people to people’ who have the knowledge, will be a primary function of a good KM system.

To assist the knowledge worker with this ‘Knowledge Networking’ we have developed in Know-Net a first ‘Who’s Who’ database. This contains key details about people in the organisation, their location, skills, contact information etc. A simple search (described in 2.3.4 below) will enable the knowledge worker to more easily find and connect to the right people and tacit knowledge.

People may be viewed in the ‘Who’s Who’ as follows

By surname and/or first name, if known. By telephone extension number By location By skill type etc – Subject Matter Expert? By photograph By Company

As illustrated in Figures 19 & 20 below



Figures 19 & 20 – Who’s Who listed by Company and by Name



By giving the knowledge worker the responsibility to keep his/her personal details up to date, this will significantly reduce costs in centralised maintenance of a ‘person /skills/telephone directory and databases’ and, the information will be far more up to date.

This Who’s Who Application, commonly referred to by others as the ‘Yellow Pages’ has saved many organisations large amounts of time and money and, as the application is so simple to set up, has provided a ‘Quick Win’ early on in the KM initiative. People have an opportunity to be better known and they can immediately benefit from better knowing ‘who knows what’.



2.3.4. Search

By clicking on ‘Search’ - going to ‘one place, to search across the Know-Net System and beyond’ - the knowledge worker can quickly ensure that he/she can retrieve and list any documents on any item(s) used in the search criteria – key word(s) etc.

By providing a search capability across the entire Know-Net KM System, the knowledge worker is taking the first step to go from ‘if only we knew what we know’ , as an organisation, to ‘knowing what we explicitly know.’

Selecting the ‘Search’ option reveals two sub-menu’s, as shown in Figure 21 below:

Full Text Search Meta Data Search

Figure 21 – Full Text Search and Meta Data Search

The standard ‘Full Text Search’ screen is illustrated in Figure 22. An advanced Full Text Search may be performed, as illustrated in Figure 23.



Figure 22 – Full Text Search

Linking to the Lotus Notes search facilities, which is essentially what we did above, is mainly a preliminary solution until the Know-Net integrated search facilities using metadata, ontology-based indexing, and fulltext search, are fully implemented, stable, and approved by the users. Then, the above described standard search mask will probably be discarded and completely be replaced by the refined Know-Net Advanced Search Interface (KASI). The KM applications and collaboration support described so far and to be described in the remainder of this Section 2, constituting the Know-Net tool version 2.0, with the KASI and the Personal Knowledge Portfolio described in Section 5, altogether form the Know-Net tool version 3.0 which is to be tested in WP5 at the three user sites and is already being used by the Know-Net project team.

The integration of the DFKI KASI and of the FHBB Personal Knowledge Portfolio1 modules into the existing collaboration tools created as a further 1 ... which, at the technical level, can be seen as a particular further development of the ontology-based indexing ideas underlying the KASI. While the latter shall support sharing and reuse of explicit knowledge on the basis of a shared group and company understanding, the Personal Knowledge Portfolio approach rather prefers an approach on the basis of



development of

Figure 23 – Advanced Full Text Search

Knowledge Associates’ KNOWLEDGER product is the central point of fusioning the process-centric approach and the content-centric approach to Knowledge Management which is a core technical goal of the Know-Net tool developement. In Section 4.3, the basic integration idea is elaborated in some more detail.

In the following, we will present the main part of the content-centric approach as a whole, not necessarily following the tool oriented organization of this manual document, but rather following the logical approach which seems to be the most appropriate for the topic. A short review of the underlying ideas will explain why we understand metadata annotation and ontology-based indexing as important for precise-content retrieval.

very specific personal views. Such an approach is appropriate and economic for vaguely structured, complex, but important knowledge contents which are seen in many different ways by different users such that the underlying structuring ideas are still under development during the work with them.



In order to do this, we need some support for creating metadata schemata and indexing ontologies as sketched in the Know-Net transformation method document, deliverable D7.1. This support is given by the Ontology Editor described afterwards (which would belong to the Knowledge Administrator Navigator, but is described here).Having seen the Ontology Editor, we will spend some words on the process of annotating and indexing which is integrated with document creation and input into the system.With these prerequisites, we can describe in detail the KASI. Instead of discussing the several interface elements and services in isolation point for point, we prefer showing the search interface’s functionality in an integrated manner. We will demonstrate the system’s look and feel step by step in a running example with the help of a series of screenshots. This sort of a “How to work with” manual will give a much better idea of what can be done and how, and what can’t, and is thus a better guide for the pilot users. A more formal reference manual will be delivered in workpackage 5 “System refinement” when interface design and underlying functionalities are more stable and complete.



Basics of the Know-Net content-centric approach

Since the several Know-Net navigators and KM applications are especially tailored to support specific collaborative business and knowledge management processes, each of them can, of course, only reflect specific parts and facets of the knowledge and information stored, focussing on certain aspects, taking specific viewpoints, and providing purpose-oriented access and manipulation methods.

The Know-Net architectural approach is based on the idea of a central Knowledge Object Store holding the main constituents of the company’s knowledge ecology. They shall be stored only once, together with the most important relationships and interdependencies between them. However, despite this first step towards an integrated knowledge and information system, there will nevertheless be, at least still for a long time, a fragmentarization of the organizational knowledge base, caused by an extreme heterogeneity of knowledge and information sources to be dealt with.

This heterogeneity partly comes from an incomplete realization, because our Know-Net tool just represents first steps towards a centralized, homogeneous company knowledge infrastructure. Partly, it is inevitable, because it is impossible to anticipate all future uses of knowledge items and documents such that you can only realize one specific storage and access approach and must provide flexible means for defining new views and accessing in new ways in a quick and easy manner. Further, heterogeneity naturally comes into play when legacy systems and other information sources external to the Know-Net tool are to be linked into the system. Manifold aspects of heterogeneity are quite normal in every existing information landscape, like for instance:

Different versions of the same content, evolving over time, are often stored in different files, but should be found altogether for some purposes, e.g., to trace back the development of thoughts and decisions. This is a typical requirement at UBS-CRV.

Multiple storage formats depending on the tool applied, like MS WORD files, Powerpoint presentations, HTML files, Postscript or PDF attachments, Lotus WordPro files – all of them will occur in realistic application scenarios, and often be stored in different systems and different places. Dealing with multiple formats, yet having a uniform information access, was an important requirement of all three users, and is even more obvious in companies formed by a merger, like Gooch Webster or UBS.

A fact a search and retrieval machinery should be able to deal with is that different information sources to be accessed are increasingly often geographically dispersed. Since knowledge networking will more and more involve topic experts working in different offices of one company, or when expanding the networks to the interorganisational level even from different companies, this issue will become more important. This effect is already pronounced at Gooch Webster. A comfortable



knowledge portal should transparently give access to all the information available abstracting away from geographic locations if this is not an explicit requirements to take into account where information stems from. A similar aspect is that of external sources which are not directly under control of the Lotus Notes based Know-Net system, but can be called remotely, like external information providers as required by Gooch Webster, or just old files gathered in the file system which is an important knowledge source for Planet.

Even in one location, working with one information system or even the same instance of the Know-Net tool, it is nevertheless usual that information which belongs together with respect to a specific aspect, is organizationally dispersed. For instance, if we have different departments or project teams of Planet working for the same customer, their individual document collections will reside with them, but in order to get a comprehensive view on this customer it might be appropriate to search across all these documents without going through the separate departments one by one. Thus the knowledge portal must provide some concept to represent the topic in quest (the “customer XY” in the example above).

Though dealing with the same content, documents may be logically dispersed because they are spread over several Know-Net databases depending on their role in different collaborative processes. For instance, the complete information about a new product development might be found partly in idea databases sketching the first rough thoughts, shifting later to discussion spaces, maybe several different discussion groups dealing with technical, marketing, or cost aspects, then lead to decisions documented in library databases, and so on. A comfortable information access would provide a portal offering the topic and simultaneously searching across all different databases. In our Know-Net project server, e.g., information about the Know-Net tool is spread over different workpackage databases dealing with tool requirements, development, and test.

Having in mind that the Know-Net tool will be further developed during WP5, and, hopefully, also in a commerzialization phase after the project end, the solution to be implemented shoul be open and flexible enough to add further types of relationships between documents later. Up to now, document management tools use to represent only the simple relationship of successorship between several versions of the same document. Domain or application specific solutions sometimes represent more complex document relationships. E.g., the KARAT system for supporting software requirements engineering developed by DFKI (Abecker et al., 1998) represented the concept of follow-up requirements linking together causally dependent requirements, or the concept of composed requirements aggregated from partial documents via a part-of relationship. At least UBS mentioned that it might be useful to express such relationships, e.g. to link together a presentation prepared for some meeting, the minutes of this meeting, the revised presentation changed on the basis of comments made in the meeting, etc. So, a metadata storage and management approach should be open enough to add such features later on.

Another point to be focussed on in later project phases concerns the idea



of presentation ontologies and personal views of the information space recently discussed by DFKI (Abecker et al., 1999) and also essentially underlying he FHBB approach (Bettoni et al., 1998). The main idea here is that different user groups might have such different requirements concerning level of detail, main perspective to look at the shared information space, and vocabulary used, that it can be necessary to have different user interface instances for particular user groups, all of them mapped onto the same internal information model, but all of them representing completely different knowledge portals. This can be achieved by a modular system architecture, clearly separating interface modules, internal knowledge maps, and mapping rules between both layers.

In order to deal with these manifold aspects of heterogeneity, the Know-Net content-centric approach made the following design decisions:

1. The two last requirements, extensibility with respect to document relationships and with respect to individual knowledge portals, are provided for by the agent-based software architecture already sketched in deliverable D2.1 “System requirements” and will be described in more detail in deliverable D5.1, the “Refined system documentation”. Here, we focus more on functional aspects than on the architectural design.

2. The two first requirements, concerning document versioning and multiple storage formats will mainly be addressed by the decision to settle the system upon the Lotus Notes infrastructure which is capable to store and manage the usual document types as attachments, replicate them for offline working, support fulltext search in the attachments, give a URL to each document and enable the basic network services via the Domino server, and host the metadata required without changing the original document. So, we expect that after introducing the Know-Net system in a user company the knowledger workers should shift their way of working as far as possible towards working in the integrated, Notes-based Know-Net tool environment. Only accepting the philosophy of the tool and going over to the collaboration-oriented, networked style of working, in each step settling upon the integrated tool, gives the maximum benefit of the approach.

3. Now, the remaining three “points of dispersion”, concerning the problems of strict, inflexible, single-viewpoint organizations of knowledge are the maint points of application for the Know-Net Advanced Search Interface (KASI). We will describe the approach in more detail in the following:

Basically, the KASI aims at a uniform, homogeneous, ergonomically designed and easy to use knowledge portal harmonizing the heterogeneity of representation and storage. Conventional knowledge portals prefer a browsing-like approach, navigating step by step through the structure of document collections as they are physically organized, i.e., for instance, first selecting the server of office XY in London, then going to the customer database, then asking for customers dealing with business ABC, and finally finding out that the specific information I am searching for is not contained in the customer resumees stored in those customer databases.



Instead, we propose a comprehensive document modelling comprising all dimensions of document metadata relevant to describe a document, including conceptual structures logically organizing the document content. Based upon this document metadata, we offer a mixed browsing-searching approach over the all underlying information repositories are accessible via a uniform search interface and are described as far as possible on the basis of the same metadata schema. What should be contained in such a comprehensive metadata schema?

Standard metadata attributes:- Who is the document author?- When was the document created?- What was the date of the last modification?- ...For Notes DBs, such metadata are mostly contained in the documents themselves. For most other document management systems this information will be available as well, though being accessible by other mechanisms. For some other information sources, like, e.g., company external information providers, these attributes might not be applicable or available.

Contextual factors, i.e., in which process / context has the document been created? In our Know-Net tool, such contextual information will mainly be derivable from the fact in which Know-Net Notes DB (which is created by a certain KM application supporting a specific collaborative process) the document is stored. Consequently, this information should be available at the search interface.

Content of the document, i.e. the topic it deals with. We propose to build formal structures (graphical representations of concept maps) reflecting multiple views and facets of the domain and content of work. These formal structures can be used for conceptual indexing of documents and for graphically specifying search conditions when querying the system. We call these concept maps indexing ontologies because they represent the basic ontological structures underlying the users’ work.

As an example for the idea we refer to (O’Leary, 1999) who identified the ontological structuring principles used by the big international consulting companies to organize their KM systems. For instance, business of the customer, process to be improved, and tools applied, were some of the ontological dimensions used to index best practices there. We propose to use the same indexing ontologies for categorising each explicit knowledge item in the Know-Net system.

Representation of the content, i.e. the textual encoding of the content. To deal with the variations of human language, fulltext search mechanisms are usually employed. Instead of allowing free keywords for document description, we prefer the controlled vocabulary represented in the indexing ontologies, and combine it with the Notes fulltext search



over all metadata attributes plus the document content and attachments.

It must be clarified with the users in WP5, how important free indexing vocabulary, a corporate thesaurus for query expansion, or further developed mechanisms for automatically extracting semantic content of documents, are in daily work. There are already suggestions by UBS / CRV. However, we will wait for first usage experiences with the basic Know-Net system in its current shape before we can assess the possible benefits of further changes / extensions.

Of course, there is no definite answer which metadata should be provided for document description and annotation. There are standardization efforts coming from the Digital Library community (Dublin Core), specific answers tailored for the KM domain (van Heijst et al., ), (Abecker et al., ), and also customer-specific considerations developed in Know-Net (Sonnenberger & Wolf, 1998). Since we do not expect an “ultimate solution”, the Know-Net system is fully configurable in the sense that all metadata to be stored and used for queries can be defined in the Know-Net Ontology Editor described below. The editor also allows to model the indexing ontologies introduced above.

The only restriction in the current version of the system is that each metadata attribute value must be stored somewhere and that, to this end, we relied upon the Notes environment. We extended the Notes-based Know-Net Server Version 2.0 in such a way that in each document input or editing mask the appropriate metadata fields for some basic document description schema (as sketched above) were inserted. The respective extended input masks are shown in the subsequent subsection coming after the editor description.

Practically this means that for each deviation from the metadata schema currently implemented the respective Notes templates must be changed by hand during the tool introduction. For a marketable Know-Net product this would be changed in one of two possible ways. The first one would be to automatically adapt the Notes templates via the application interface whenever the metadata schema is changed. The second one would hold all metadata separated from Notes, e.g., in a relational database the schema of which which could be automatically manipulated as well as the metadata input masks. Both solutions are viable, but were too time-consuming to be realized in Know-Net, up to now. Please note that this restriction only concerns the schema of the metadata attributes. If the complete content description is represented in one attribute (IndexCategories) as it is now in our experimental prototype, we have no real problem of restricted expressiveness, since each ontological dimension can be encoded in the indexing ontology. It should also be expected that the metadata schema is relatively stable for a company while natural evolution of topics and shifts in interest are dealt with in the indexing ontologies.

Having described document description dimensions, and indexed the documents, we come to the query mechanism. The simple basic idea for the design of the user search interface is that, essentially, searching for



information means describing the information need one has as attribute-value-pairs which can be used as search constraints looking for all documents having the specified properties. Such attribute-value-pairs refer to the different dimensions a document can be characterized along which are expressed through the different metadata attribute values.

To this end, the user is provided with an as overseeable as possible graphical interface which allows to browse through the metadata schema and graphically represented metadata attribute values for specifying his/her information needs.

While the user is stepwisely specifying their information needs going through the metadata schema, each interface activity is directly handed over to the underlying search machinery which immediately updates the current result set corresponding to the actual information need description. This incremental update of retrieval results allows to intertwine the direct interaction with the documents considered (which can be opened for reading and editing in separate browser windows while the search goes on in another window) and the further specification of refined (in the case that document metadata or document source inspection of currently retrieved documents shows that the information need must be specified more specifically or in a slightly different way) or other, derived information needs (e.g., when the documents retrieved and read show that there are other topics which should be considered as well).

In the following we will describe the several parts in the order introduced above, first the Know-Net editor for metadata schema and indexing ontologies, then the input mask with indexing extensions, and then the Know-Net Advanced Search Interface.



Functionality of the Know-Net Ontology Editor

The Ontology Editor application is a Java applet communicating with Lotus Notes via the CORBA based application interface. As technical prerequisites one needs a JAVA environment, i.e., JDK 1.7 and Swing.

The Ontology Editor allows the users to model:

the metadata schema describing which attributes are used to annotate and describe documents, and, for some attributes which hold ontology-based indices:

the indexing ontologies describing document content from multiple viewpoints

It offers a graphical representation for the “OCRA” objects,2 so that they are easy to handle, format and change. After defining the ontology it is exported to a file named onto.facts that is used for two purposes:

1. It determines the outfit of the search interface, i.e. which metadata attributes are presented how?

2. It holds the graphical representations of indexing ontologies (concept maps) for document categorisation.

The functionality of the editor is presented on the example of preparing the metadata schema and ontologies used for the Know-Net project team knowledge server which is used to coordinate the project’s team collaboration. We present the several menus available.

It should be noted before that the editor is basically an administrator tool, not to be used by each knowledge worker and not to be used on an everyday basis. It should mainly be employed in the system introduction phase, and, from time to time, for updating the conceptual index structures.

2 The OCRA is the DFKI internal ontology repesentation language, i.e., a formalism for denoting classes, objects, attributes, relationships, etc. Technical details about this language are not relevant for this project, but can be found in ( Abecker et al., 1998 ). Its concrete syntax should be hidden from the user through the graphical representation of the KnowNet Ontology Editor.



Figure 24 - Starting the Know-Net Ontology Editor

Figure 25 - The Edit Menu



The Model Menu (Figure 24) contains two items:

Import Ontology This item imports the current metadata schema and indexing ontologies and reconstructs the graphical representation. After that, the user can modify it renaming nodes, removing nodes and links, or adding any of them.

Export Ontology This item exports the modified metadata schema and indexing ontologies including the created index maps to the appropriate places where they are loaded from by the indexing and retrieval software.

Please note: in order to test the tool or prepare metadata schemata and ontologies independent from a running Know-Net tool installation, there exists (apart from Java applet version) also a Java application. In this application, the import and export functions offer a file browser to load and store ontologies anywhere in the file system.

The Edit Menu (Figure 25) provides different functionalities for defining the metadata schema and indexing ontologies in form of nodes or terms (concepts, database attributes, text, and database values) linked together in a hierarchy. In particular, it contains the following menu items:

Add Node Through this item, the user can add one of the following terms to the current model: concept: an abstract term grouping together

several more specific metadata attributes, or DB values, respectively. An example is the date node grouping together the creation date and the date of last modification (see Figure 26).

dbAttribute: a database attribute, i.e. a specific metadata attribute describing a document. Notice that the each name given here must occur somewhere in the database forms such that the retrieval engine can access to the respective attribute values when searching. Examples are the creation date, or the index categories. For each dbAttribute defined, the possible attribute values to be offered to the user for specifying search conditions must be given, too. This is done either modeling the values as further nodes with one of the three node types below (db value, date, or text), or using one of the EditValueModel, CreateValueList, or LoadAuthors buttons described below. The system distinguishes between single-valued



(e.g., for each document there certainly exists only one creation date) and set-valued attributes (for instance, the author field could be defined set-valued if there are co-authored documents in the knowledge base). This can be chosen for a new to create dbAttribute in a clickbox shown in Figure 27.Later, in the search interface, graphically selecting several attribute values of a single-valued metadata attribute is interpreted as a logical OR (“find documents with one of the marked attribute values”), while selection of several attribute values for a set-valued attribute is interpreted as a logical AND (“find documents having all these value in their vlue set”). The respective meaning is indicated in the header of the query panel (cp. Figure where logical AND is indicated by the – still German - UND). It must be communicated with the users how intuitive and understandable this approach is.

DbValue: is used for explicitly modeling one possible value of a metadata attribute, e.g., the value “draft” of the discrete values set {“draft”, “preliminary”, “final”} used to specify the status of our Know-Net deliverable documents

Date: is used as a placeholder for an attribute value of type date (for instance, to specify that the “modified” and “created” metadata attributes will refer to a date in the metadata store and will be specified by a date restriction menu in the search mask, see Figure 28)

Text: is used as a placeholder for an attribute value of type text like the document name or ShortDescription which are represented in the search interface as text input boxes

Rename Node Enables the user to change the name of a node. This menu point is active when there is a term node selected. Selecting a node is done clicking with the right mouse button on the node. Selected nodes are marked blue. Deselection is done by clicking again on a selected node.

Please note: each rename action on nodes representing metadata attribute values is stored by the system in a special log file. At the next startup time of the retrieval machinery, an agent is started which propagates the model changes to all documents in the Lotus Notes environment which are indexed with one of the changed attribute values.

Note for WP5: change propagation is easy at the



moment for all documents under the control of Lotus Notes. If there are other document sources linked into the system in some user site installation, it must be clarified whether and how such changes can be done, or whether they must be forbidden for specific cases. It might also be appropriate to change the design of the metadata storage towards an isolated metadata store independent from the concrete documents accessing them only via the URL. Then, changes would only be propagated to this metadata store.

Figure 26 – Adding an Ontology term



Figure 27 – Adding a set valued database attribute



Remove Node To remove a certain term from the ontology, use the right mouse button to select the node to be removed, then, the remove item on the Edit Menu will be active. The system will interact with the user to acknowledge this procedure.

Note for WP5: up to now, we would remove a node (especially, a DB value node) from the model without propagating any changes to the documents. This means that the indexing with this term remains existent, but the value is not anymore offered in the search mask to specify a search condition. It has to be communicated with the users what removal of a node has as consequences and whether such an action should be allowed, or should enforce propagation to the documents, or should be combined with a check whether the respective index term is still in use for some document.

Create Values List

When there is a dbAttribute the values of which should be specified by hand as a number of dbValues, this can be eased using this menu item. It will open a box to type in a number of dbValue terms, separated by <return>, and after closing the box and comitting the action, automatically create the respective nodes to represent these dbValues (see Figures 29, 30, 31).This is used in the same way as adding a dbValue, but allow the user to add a set of values at once.

Load Authors This is a specific case of input support for a particular dbAttribute. Please remember that each dbValue to be offered for selection in the search interface for specifying search conditions over some dbAttribute must be explicitly modeled in the Know-Net Ontology editor. Since we can expect that each metadata schema will contain the Authors dbAttribute, and that on the other side at least Lotus Notes knows the name of all authors occuring as creators or modifiers of Notes documents, this button establishes a connection to Notes and automatically pumps all names of Notes document authors as dbValues for the authors attribut into Ontology editor for the Know-Net metadata handling (see Figure 32).

Note for WP5: it should be clarified whether a general mechanism for establishing a connection between specific Notes attribute ranges and the metadata and ontology editor makes sense. It might



also be necessary to expand the scope of this approach to information sources not under the control of Notes.

Figure 28 – Adding a “date valued” attribute value term



Figure 29 – Lists of DB values can be specified at once



Figure 30 – Editing a list of DB values



Figure 31 – Respective value nodes are created automatically

Edit Values Model

This menu item is used to define the domains of metadata attributes which should be presented graphically for indexing and search, instead of simple lists, text fields, or date menus. This idea of graphically specifying multiple concept maps to describe several views (multicriteria classification) on document content is a main characteristics of our Know-Net “product-view” approach. The respective metadata attribute (dbAttribute) must be selected (using the right mouse button) to activate the menu item in the pull-down menu.To edit the values model of the selected attribute, a second editor will be opened where the user can graphically model this structure (see Figure 33, 34). When closing this value model editor, the attribute values are exported (see Figure ) which means the values are saved within the corresponding attribut node and an associated HTML and a clickable GIF file are generated to be used later fo indexing and retrieval. The Edit Menu of the values model editor contains only two types of terms, concept and dbValue, for modeling conceptual maps. The concepts represent abstract terms which are used for structuring the model but cannot be used themselves as indexes in documents, and are thus not clickable during search.

Note for WP5: when there is some experience with graphically categorising documents, it should be discussed with the users what the most appropriate way would be to use abstract concepts in categorisation models. Technically, it is no problem to use all nodes in values models a indexes, since it might be possible that, e.g., one document is dealing with “Information Technology” in general while another one is about “Client-Server systems” in particular which is a subfield of the former. On the other hand, it is also no problem technically, to allow only the most specific terms in the modeled structures as indices, and implement a simple search heuristics in the retrieval mechanism: when there is a query for an abstract term, automatically expand it to a search over all specific terms below. This might also make sense. However, having both ideas simultaneously, abstract concepts as topics of themselves, and abstract concepts as containers for the more specific ones, this might lead to confusion with the users.

Note for WP5: another point coming from UBS / CRV addresses the required (and useable) complexity of models. It was suggested to replace / extend the graphical



editor which relies upon the user’s ability to deal with visual pattern and allows arbitrary graphs to represent value models, by a tree editor which relies on the user’s familiarity with folder structures to organize content. Such a solution would be much easier to use when designing the models and – if the models can also easily be folded / unfolded during indexing and search just like the metadata schema – could be easier to oversee when models become large.

Figure 32 – Loading authors from Notes



Figure 33 – The domain of a metadata attribute can be specified by a graphical concept map



Add & Remove Link

Links determine the hierarchical structure of metadata attributes which lead to the organization of the user interface for indexing and search described below. Links are added in the following way: keep the left mouse button pressed while dragging the mouse from the origin to the destination node. When releasing the mouse button, a link will be added between the two nodes. To remove such a link, just select the two nodes using the right mouse button, choose “remove link” in the pull-down menu and confirm the action in the pop-up dialog (see Figure 35).

Figure 34 – Creating a concept map for describing the “Know-Net Products”



Figure 35 – Removing links

We shortly summarize how to edit models with the Know-Net Ontology Editor:

Marking regions: holding the right mouse button and marking a rectangular area selects all nodes within this area (selected nodes are marked blue). For a selected region, the following actions are possible:

- “Remove node” removes all marked nodes.- “Remove link” removes all links between nodes in the marked

region (after a confirmation dialog for each link).- Moving one node of a selected region causes that all other nodes

will be moved accordingly such that the original geometric relaionships between the marked nodes are kept.

Moving nodes: hold the left mouse button on the node and drag it. Selecting & Deselecting nodes: press the right mouse button. Selected

nodes are marked blue. Selecting a node ativates the respective, node-specific menu items in the pull-down menu. Selecting two nodes activates the “remove link” menu item.

Note for WP5: Please note that a term (node) name should be used only once in the ontology. In the next version this will be checked automatically.

The Help Menu will show the content of this document online.



Indexing documents

Since the main aim of our tool development approach is to seamlessly integrate the process-view and the product-view to KM support, and we don’t want to disturb the usual flow of the user’s work, the content oriented indexing is directly integrated into the Knowledger / Know-Net server V2.0 input forms. Specifically, this means that each document input form of a discussion or a library database as shown in Figure 35 below not only contains the standard metadata input fields, e.g., for a short document description, but also additional fields for the metadata attributes holding graphically denoted index categories. In the current example, we have only one such metadata attribute, namely the IndexCategories field. For each such attribute which has been provided with a concept map during ontology editing, to the left of the input field, a link has been added called “choose”. In Figure 12, for instance, you can see this link. Clicking on this choose link will open the appropriate concept map as a clickable GIF image as shown in the Figure 35 below.

Figure 35 – Document indexing using concept maps



Clicking left on a concept in the map automatically inserts the respective index conept into the attribute field, deselecting a concept by clicking again removes it from the index list.

Although many requirements elicidations show that users are not willing to spend any extra effort for indexing, we nevertheless decided to test this graphical access to a controlled vocabulary to ensure high-quality indexes. This is in contrast to many commercial KM solutions the main value-added of which is to use (mainly neural-net based) innovative approaches for automatically acquiring semantic content of documents. We are not very convinced from the quality achievable by such approaches. Nevertheless, they could be integrated as third-party software into the system both as an additional search module (in the same way as the Notes fulltext search, see below) and as automatic indexers.

Note for WP5: one further step into the above mentioned direction, but still a bit more depending on initial user input could be to integrate a learning text categorisaion system. In (Tschaitschian et al., 1997), (Junker, 2000) we describe such a system and its integration in a similar scenario as the one here. A learning text categroisation system takes as input preclassified examples for a number of classes to classify texts or text fragments into. From these manually classified examples, the system tries to automatically extract patterns and decision rules which would allow an automatic classification after the training phase. Such a system could be used for suggesting indexing decisions to ease user interaction, or to automatically index legacy document collections. However, it must be clarified in WP5 with th users whether there would be enough preclassified input data, how well such an automatic classification would be accepted by the users, and whether the classes (index categories) to be considered would promise clear enough class indicators to allow automatic learning.

Figures 36 and 37 below show the indexing ontologies extracted by hand from the Know-Net project server. They could partly be found in the originally installed KNOWLEDGER discussion and library databases, partly evolved as Lotus Notes categories in use, and partly were not explicitly mentioned before, but come logically from the project plan and the way it is enacted. The indexing ontologies contain, for instance, the structure of all material and immaterial artifacts to be produced in Know-Net (the framework, the tool including documentation, the pilot installations, etc), the structure of work organization, or the type of documents produced.



Figure 36 - Index dimensions found in the Know-Net project server



Figure 37 - Further index dimensions in the Know-Net server



The Know-Net Advanced Search Interface (KASI)

When you enter the KASI from any other navigator via the “Search” button, you will reach a screen as shown in Figure 38. Basically, the screen is divided into three main areas: The upper part (region 1) contains control elements. The middle part (region 2 and 3) allows the uer to graphically specify

their information needs. The lower part (region 4) displays query results and other output streams

if wished.

Figure 38 - Starting Screen of the Know-Net Advanced Search Interface


1

2

3

4


As already pointed out the Know-Net tool is freely configurable concerning the question which metadata schema will be employed. DFKI’s previous work showed that, at least if one incorporates legacy information systems, it is often the case that the metadata schema structuring the underlying information space become large and difficult to handle for occasional users (Abecker et al., 1999). Also UBS’s investigations into the specific requirements at the Credit Risk Valuation group (Sonnenberger & Wolf, 1999) show that for several types of documents several sets of metadata might be appropriate which makes an overall query interface complex and uncomfortable to use. In order to ease these problems three main ideas are underlying the KASI search approach:

1. The metadata schema itself is browsable.2. Attribute value models can be denoted for indexing and for querying in a

graphical manner which shall exploit the human’s exellent ability to remember and deal with visual structures.

3. Each user action gives an immediate feedback in the result panel thus supporting sort of an “iterative refinement” search.

The cognitive / ergonomic adequacy for dealing with large conceptual and metadata schemata as well as the retrieval efficiency when dealing with large document collections shall be challenged in the WP 5 trial phase at the three user sites. The above three design decisions are reflected in the KASI as follows (please refer to Figure 38):

1. In the interface region (2) the metadata schema is presented in a folder-like manner which can be folded and unfolded to come to the metadata attribute the user wants to use for expressing his information need.Figure 39 and Figure 40 show how the very small metadata schema currently used for our internal Know-Net project server is unfolded in two steps until we have only concrete attributes which are directly reflected in document description attributes embedded in the respective Notes documents. If there is a large, difficult to oversee metadata schema which is uncomfortable to navigate stepwisely, or the user doesn’t know exactly in which part of the metadata she has to go into detail, the three buttons at the left of the navigation bar (1) can be used to unfold or fold together, respectively, the whole folder tree level by level, or to unfold it completely with one click. To repeat:

Closes the subtree of the selected node in the metadata schema.

Opens the next level of the subtree of the selected node in the metadata schema.

Opens the whole subtree of the selected node in the metadata schema.

2. Another help for navigating in the metadata schema is the textsearch field included in the control and navigation bar (1). Here, the user can



type in an arbitrary string and if there is a metadata attribute or any possible value of some attribute containing this string, the metadata schema tree is opened up to this attribute, and the range of values of this attribute are shown on the right hand side (3).Having found the appropriate metadata attribute in the schema, it can be marked either by clicking to select, or clicking again to deselect, or using one of the following buttons in the control bar (1):

Changes the state of the actual selected node to “selected”. This node will be included in the query. Thus only entries of the database that have values different from NULL will be delivered.

Changes the state of the actually selected node to “deselected”. This node will be included in the query. Thus only entries in the database that have a value of NULL will be delivered.

Changes the state of the actual selected node to "don't care" (not selected).

3. The interface region (3) on the right hand side displays the possible values allowed for the attribute selected on the left hand side. Having selected an attribute in the schema in panel (2) as interesting for characterizing the actual information need, the specific search condition can be formulated here. Up to now, three types of metadata attributes are available:- Date: here, the usual search conditions over dates can be expressed

via several pulldown menus- Value lists: attributes which have been declared as lists of values are

presented as lists with clickboxes (see below, the Author attribute)- Index maps: some attributes can be graphically displayed by

clickable maps if they have been defined so during ontology building (see below, the IndexCategories attribute)The use of all three kinds of metadata attributes will be demonstrated below using Figure 41, 44, and 46.

4. The actual answer set resulting from the current query is always displayed in panel (3), in the lower part of the system interface.

In this part of the KASI, the user has also some possibilities for inspecting the system behaviour.

The “query” button shows an SQL like textual description of the query currently considered resulting from the several user interactions at the GUI (see Figure 43 and Figure 45).

The “explanation” facility is not yet implemented but could be worthful in later projects. It should be available for explaining complex search processes over difficult to oversee indexing structures, maybe using search heuristics or other kinds of background knowledge as envisioned



in the paradigm of ontology-based information retrieval (cp. (Abecker et al., 1999)).

The “agents” button shows the messages exchanged between the several parts of the agent-based retrieval machinery. This is implemented, but very interesting for a normal user, rather useful for debugging purposes. It might make sense to remove the explanation and the agents button from the final user interface of the Know-Net tool.



Figure 39: Unfolding the metadata schema



Figure 40 - Further unfolding leads to concrete metadata attributes

To come back to our running example: assume the user has inspected the metadata available and decides to specify first a search condition using the author field. Having selected the author attribute, the system offers all authors occuring in the document collections available as shown in Figure 41.



Figure 11 - The system offers possible attribute values



Figure 42 - After each value selection the answer set is displayed

So having specified that she is interested in documents written by Dimitris Apostolou the user is shown in the lower part of the interface all documents retrieved. Each document is represented by a row in a table giving all known metadata attribute values, including the documents URL.



Figure 43 - The underlying retrieval machinery can be inspected as well

Inspecting the queries sent to the retrieval machinery allows to control the actual set of search conditions graphically specified and shows the number of the currently retrieved documents.



Figure 44 - Additional search conditions narrow down the answer set

Assume the user is searching for a specific discussion contribution which came recently from Dimitris Apostolou. He is not aware of the exact creation date but knows that the document was sent somewhen after mid April. He enters the additional search condition, older documents are immediately filtered out, and the result panel is updated instantly.



Figure 45 - The refined query produces five documents less

In the current implementation, all specified search conditions are considered conjunctive which can be seen inspecting the queries launched. The query log shows that the date restriction filtered out five older documents. If some search condition done prior is considered obsolete and shall be discarded later, the “deselect” button can be applied to the respective attribute (cp. Figure 50).



Figure 46 - Index dimensions can be graphically displayed

Coming to a metadata attribute which has been specified by a graphical image, selecting this attribute lets a clickable map pop up. Here, all concepts marked yellow are indexes used for describing documents. Clicking on such a concept means searching for documents indexed with this index term. Currently we allow to use both abstract concepts (upper level of a tree) and instance concepts (leaves of a tree) to be used for indexing. It can be specified at ontology design time which kind of node a concept shall be.

Note for WP5: it will be examined how user friendly such concept maps really are. We have already the suggestion from UBS to replace the arbitrary maps by simple folder representations of concept trees thus giving a still more simple and more uniform user handling. It shall be investigated how comfortable and intuitive the maps are for the test users and whether more complex index structures than trees will be used.

Note for WP5: if users wish and the resources are available, we think about the possibility of clicking on a general concept (like “Know-Net method” above) in order to search for all documents indexed with some subconcept (“Diagnosis method”, “Transformation method”, “Evaluation method” above). This simple kind of exploiting semantics of index ontologies might make sense, but it must be discussed with test users whether such a service will be understood and wished. Moreover, to our understanding, it should



not be confused with the possibility to directly use such a general concept as a document index such that only one possibility should be allowed in the system.



Figure 47- Clicking on index terms marks interesting concepts

In our example, the user might be interested in “Discussion entries” written by Dimitris Apostolou ...



Figure 48 - Several index dimensions can be combined for multicriteria search

... dealing with the “Transformation method” to be developed in Know-Net. Finally, having specified all search constraints, the system comes up with two documents found.

Note for WP5: currently, all selections in concept maps are considered as conjunctive search conditions. It is easy to configure the system such that the selections are considered disjunctively if users wish. In order to allow for a multicriteria classification, a conjunctive understanding of selections in different index dimensions must be applied, anyway. Extending this idea by a disjunctive selection within one indexing dimension might make sense, however, we expect this will cause understanding problems for “normal users.”



Figure 49 - A document can be directly accessed via its URL

Since the metadata entries contain the URL for each retrieved document, the original source text including all attachments can directly be accessed for inspection or editing.



Figure 50 - Metadata attributes can be marked as “don’t care”

Now assume the reader had a look into Dimitris’ document on the Know-Net transformation method and would decide to go further into this topic. He might be interested in other documents on the topic, maybe written by other people than Dimitris. So, he marks the author field as “don’t care” and gets an updated document list which contains also comments by, e.g., Gregory Mentzas or Ron Young.



Figure 51 - Negative search conditions can also be specified

Now, if the user would remember a specific thread of discussion Dimitris was not directly involved in and would like to trace the respective discussion contributions back, she could filter out all documents written by Dimitris clicking again on his name which marks it as a negative selection. The semantics of a negative selection is that only documents definitely not containing this name in the author field can be presented. Negative selections for index models represented as a graphical map are done in the same way as it is the case in attributes with simple lists representing the value range like the author field: one click selects a concept which is marked green then, the second click changes the selection into a negative one which is marked red then, another click again changes the concept back into “not selected”.

Let us further assume that the specific discussion I was interested in was a dialog between Gregoris Mentzas and Ron Young which I remember when seeing the “Short Description” of the first document delivered. Let us further assume that the system woudl return not only four documents as shown in our small example above, but, say two hundred documents, many of them written by Ron Young such that restricting the author field would be no very useful way for guiding search. But having noticed that Gregoris Mentzas’ document title referred to “Ron Young’s feedback on the transformation method”, the user guesses that the other document she is searching also contains the word “feedback” somewhere in title, short description, or text body. ...



Figure 52 - The Notes fulltext search is linked into the system

... So, she uses the fulltext search which directly calls the Lotus Notes fulltext search machinery coming back with a set of documents which is, before presentation, intersected with the answer set found so far, considering the metadata values.

Note for WP5: Fulltext search over manifold document formats (Powerpoint presentations, WORD files, etc.) was considered very important by all three users. It was technically relatively easy (whereas not yet stable, up to now), to incorporate the Lotus Notes fulltext search, so having access to all documents under the control of Notes. It must be clarified at the user sites how realistic it is to have everything to be dealt with by fulltext search uploaded into a Notes document. But this would certainly be the best solution. It brings also, on the fly, a uniform metadata handling at no additional implementation cost. If this cannot be guaranteed for many documents, it must be decided which technical or organisational means would be appropriate for dealing with this user requirement. The agent-based search architecture is designed open enough to link in arbitrary other



fulltext search mechanisms (if there is some third-party software available with reasonable interfaces) but this can probably not be done within the limited timeframe and budget of Know-Net. However, such activities, obviously development

Figure 53 - Fulltext search plus metadata combines precision and free associations

rather than research, can easily be postponed into a post-project exploitation phase for commercialization of the Know-Net product.

A look into the communication with the underlying retrieval machinery shows that metadata search together with remotely calling the Notes search as an external agent narrowed down the result set to a handable size.



A short review of the KASI interface icons

Changes the state of the actual node to “selected”. This node will be included in the query. Thus only entries of the database that have values different from NULL will be delivered.

Changes the state of the actually selected node to “deselected”. This node will be included in the query. Thus only entries in the database

that have a value of NULL will be delivered.

Opens the original document in the database when the user selects a certain URL in the result table (see figure 1).

Changes the state of the actual selected node to "don't care" (not selected).



2.3.5. Meeting Space

Knowledge Networking is also about connecting ‘people to people’ in new and more powerful ways and forms. A primary function of Knowledge Networking, performed in the daily work of the knowledge worker in the increasingly global knowledge based economy, is to communicate and collaborate through ‘virtual meetings’. Know-Net is committed to the Intranet and Extranets as the primary medium for communicating and collaborating. Virtual Meetings, ‘same time – different place’, via the Internet will become increasingly common and important.

The idea is to click on ‘Meeting Space’, which then links directly to the Sametime Server ‘Meeting Space’. This lists, executes and manages all the scheduled real-time virtual meetings through the Internet. Within a virtual real-time meeting, using the Sametime Server the knowledge worker can

Real – Time chat, person to person and in groups Real – Time threaded discussion, for more focused, facilitated and

contextual virtual meetings Use Electronic White-boarding Share Applications over the Internet

Figure 54 – Lotus Sametime Meeting Center



Figure 55 – Lotus Sametime Client

Figure 55 illustrates the Lotus Sametime Client which shows who is ‘on-line’ on the Internet/IntraNet within the team. It is then possible to immediately perform the ‘sametime’ virtual meeting functions over the Web.



2.3.5 Discussions SpaceSection 2.3.5 above describes the increasing importance of ‘real-time meeting spaces ‘, supported by real time technologies, for enhanced knowledge networking and knowledge working.

To complement this, the Know-Net Tool has identified and integrated the equally important dimension of ‘different time – different place’ virtual meetings, forums, discussions etc.

By clicking on ‘Discussions’, the knowledge worker is presented with a list of all the discussions taking place in

- Alphabetical order of discussion ‘description’- In user defined ‘categories’


(Note – non Know-Net Notes Discussions can be included in this space for better enterprise wide discussion management)

Figure 56 – Listing of Categorised Discussions



Figure 57 below illustrates the input form to create and categorise an immediate discussion.

Figure 57 – Creating an immediate discussion



2.3.6 Libraries Space By clicking on ‘Libraries’, the knowledge worker is presented with a list of all the libraries of documents in Know-Net listed in

Alphabetical order of library ‘description’ In user defined ‘categories’


(Note – non Know-Net Notes Libraries can be included in this space for better enterprise wide document management)

Figure 58 – Listing of Categorised Document Libraries



Figure 59 – Input Form for creating and categorising a new Document Library



2.3.7. Processes/Applications

Section 2.3.1. ‘One Place’ describes how the knowledge worker can quickly enter only, new information into the Know-Net Tool - ‘ as it occurs spontaneously’.

The ‘Processes/Applications’ space is entered by the knowledge worker, when more substantial work is to be performed e.g.

Launching a Client Tracking Application to view all the latest visit meeting reports

Launching a Best Practices Application to examine how best to serve a client

Launching a Competencies Management Application to view overall status on personal competence development and examine personal development plans

Launching a Innovation Management Application to have a discussion about some good ideas and potential new products

Launching a Bid Management Application to examine competitor strengths and weaknesses

In other words, this is the space the knowledge worker enters to execute the application and perform the process(es) that represent and/or support his/her daily work

By clicking on ‘Processes’, the KM Processes/Applications library is listed. This can be viewed in many ways e.g.

By KM Application code By KM Process/Application category

Clicking on the ‘Enter DB’ icon, to the right of the Process/Application description will automatically launch the application directly.

Clicking on the ‘description’ of the Process/Application, will display details about the Process/Application.

The KM Processes/Applications Library has been discussed and illustrated in Figure 6 in Section 2.2.2 above.



2.3.8. Projects Section 2.3.1. ‘One Place’ describes how the knowledge worker can quickly enter only, new information into the Know-Net Tool - ‘ as it occurs spontaneously’. Therefore project information could be entered though ‘One Place’ as it occurs.

However, the ‘Projects’ space is entered by the knowledge worker, when working in more detail on a specific project(s), as opposed to just entering information.

A Project is a process, and one could argue that projects could be listed, launched and entered from the ‘Process’ space. Key Business and Operational Processes tend to be long lived and rather stable in character. Projects can be both long and short lived and more changeable and dynamic in nature.

But because Projects are a key work area for most knowledge workers, it is considered more practical to have a separate ‘Projects’ space from a ‘Processes’ space.

By clicking on the ‘Projects’ space an application is launched which displays your ‘personal ‘ project desktop, and manages the key aspects of project management. (This launches knowledger.projects from Knowledger 2.0) e.g.

Project Mission and Objectives Reports on project status Team members Project definition and scope management Exception reporting Action Plans and task management

In other words, this is the space the knowledge worker enters to work in detail on a project(s) that represent and/or support his/her daily work

Figure 60 below illustrates the ‘Project Desktop’



Figure 60 – The Project Desktop



2.3.9. PersonalThis is a placeholder at the moment, pending further thought and feedback.The idea is to enable the knowledge worker to be able to easily enter into his/her personal applications without having to leave the Know-Net knowledge space.

For example, automatically launching the email, word processing, web browser etc.

Furthermore, this is a future placeholder for FHBB to add the Personal Knowledge Portfolio. Clicking on a sub menu here will launch the appropriate applications.

When WP5 brings the first experiences of the pilot users with metadata and ontology-based search, the personal space will be populated with personal information agents actively delivering knowledge and information on behalf of their owners. To this end, we will implement sort of a “scripting interface” for defining an active service from an example query. This interface will look as follows:

The user marks the begin of a search script or starts with a standard query from a library of commonly used search agents.

In the case that the user decided to define a search script of his own, he manually performs a search using the interactive query interface. When all query conditions are specified, he stops the scripting mechanism.

The user specifies a timing expression similar to the usual possibilities one has for active delivery services in document management systems. She can say, for instance, “perform this search once a day”, or “perform this service every 2 hours”, or “perform this search each Monday between 9 and 12 a.m.”.

The user chooses the delivery mode which can be either “deliver by e-mail”, or “deliver by putting search results in a personal “what’s new” page”.

After having defined a search agent the user may allow to offer this agent also to other users by inserting it into the agent library.

The personal “what’s new” page will also contain search results brought up by mandatory readings agents which are under the control of the system administrator.

Additional active delivery modes, e.g., for directly launching a result notice on the user’s desktop might be useful, but go beyond the scope of this project. There are already very good solutions for this problem in the market, e.g., the products by Livelink. We will review competing products in the exploitation workpackage.



2.3.10. HelpA facility will be provided for the knowledge worker to click ‘Help’ and link to an on-line copy of this Know-Net Tool documentation, when finalised.

We are also very conscious of the enormous value to be gained from being able to easily obtain from the knowledge worker ‘Feedback’. To obtain this, it must be simple procedure and easy for the knowledge worker to perform ‘as it occurs spontaneously’

We have, at least, design a simple feedback form and inserted it in the ‘One Place’ under ‘Feedback’ – to attempt to capture as much feedback as possible.

Feedback from knowledge workers, and our ability to rapidly respond, are critical to success.



2.3 Systems Administrator Knowledge Navigator (SAKN)

From a KM Systems Administrators point of view, the Know-Net Framework is much more relevant, from a technical infrastructure perspective, but not in its entirety. We have developed a technical Navigator the ‘Systems Administrators Knowledge Navigator (SAKN), illustrated in Figure 61 below.

Figure 61 – The Systems Administrator Knowledge Navigator



2.4.1 KM Processes/Applications LibraryClicking on this option reveals two sub-options, as illustrated in Figure 62 below

- KM Applications Library - One Place Forms

Figure 62 – Sun-Menu options for Processes/Apps

KM Applications Library

This is where the Systems Administrator can set up and link new software applicationsTo the Know-Net Navigator. Clicking on the button ‘Create KM Application’ will provide the following form to be entered, as illustrated in Figure 63 below.



Figure 63 – Linking KM Processes/Applications to Know-Net



One Place Form

This is where the Systems Administrator can set up and link input forms from applications to the ‘One Place’ Navigator in the Knowledge Worker Navigator (KWN).Clicking on the button ‘Create Application Form’ will provide the following form to be entered as illustrated in Figure 64 below:

Figure 64 – Listing of One Place Input Forms



Figure 65 – Input Form to link Input Forms from Applications into One Place



2.4.2 KM Assets Clicking on this option reveals three sub-options

- K Assets Directory - K Objects Directory - K Objects Store

K Assets Directory

This is where the Systems Administrator can view and maintain the list of Knowledge Assets that have been created. See Method Stages 1 & 2 for more details. Clicking on the button ‘Create K Asset’ will provide the following form:

This has been previously described in Section 2.2.3, Figures 8 – 10 above.



Figure 67 – Listing of Knowledge Assets (also Figure 9 above)



Figure 68 – Input Form for new Knowledge Assets (also Figure 10 above)



Figure 69 – Listing of Knowledge Objects

K Objects Directory

This is where the Systems Administrator can view and maintain the list of Knowledge Objects that have been created. See Method Stages 1 & 2 for more details. Clicking on the button ‘Create K Object’ will provide the following form as illustrated in Figure 70 below :



Figure 70 – Input Form to create a new Primary Knowledge Object



K Objects Store

The Knowledge Objects are written into a Knowledge Objects Store, in a Relational Database (RDBMS) described in Section 4.



2.4.3 KM SystemsThis is an overview listing of the components of technology in the KM System, as initially defined by the KM Consultant in the Method Stages 1 and 2, for the Systems Administrator to view and maintain.



2.4.4 Ontology Editor

As mentioned before, the Know-Net metadata schema and indexing ontology editor is a Knowledge Administrator tool and can be opened clicking on the respective KSAN link. Nevertheless, we preferred to describe the editor’s functionality above, together with the indexing and search approach, in Section 2.3.4. Concerning further administration requirements, please note that Lotus Notes has inbuilt functionality to perform the necessary storage administration, archiving and import / export of documents as required for the Know-Net Knowledge Server.



3. The Knowledge Management Processes

3.1. Introduction

Underpinning every Business Organisation / Enterprise, is a set of processes to perform the business. The key business processes, for example, are typically the

Sales and Marketing Processes The Manufacturing and Distribution Processes The Human Development Processes The Product/Service Research and Development Processes The Business Planning and Review Processes The Financial, Legal and Administrative Processes

Each of these business processes are typically automated, and many computer software applications perform these processes e.g SAP, PeopleSoft. Much knowledge about how to perform the process and how to manage the information the process requires is embedded in the software application itself.

A Business Process is, therefore, a Key Knowledge Asset to be managed.

Business Processes not only contain the knowledge of performing the process, but also contain the knowledge to manage the information and knowledge content. The process manages and generates ‘knowledge objects’. Therefore, the better the quality of business process design and automation - the better the quality of knowledge asset and knowledge objects generated.

Know-Net recognises the importance of identifying and managing the Knowledge Assets and Knowledge Objects of an Organisation through high quality and innovative Process design and execution.

Secondly, we have recognised the Knowledge Management process itself. The Knowledge Management process has, broadly, the following steps:

Perform a task/activity and learn from the experience Review the learnings and document them (capture and make explicit) Develop new learnings into improved codified ‘Best Practices’ and share

them Develop from ‘specific’ cases of Best Practices the Best Knowledge ,

‘generally’ applicable

This KM process is illustrated in Figure 71 below.



Figure 71 – The KM Process

The Know-Net Tool will allow the KM Process to be embedded into the Organisation in two ways:

At a high level learnings may be captured and entered into Best Practice Databases contained within the ‘Libraries of Documents’.

The KM process could be embedded within each business process application. That is to say, for example, that a normal Bid Management Process could also become a Bid Knowledge Management Process A Sales Automation process could also become a Sales Knowledge Management system, and so on.

3.2. The Knowledge Management Processes/Applications Library

One of the ideas behind the Know-Net Process Applications Library is to be able to gradually define and build a library of business processes, define them as Knowledge Assets, define the Knowledge Objects they create by


Kn o wled g e M a n a g e m en t Pro cess

Adapted f rom Know ledge As s oc iatesExec u tive Brief ing on Know ledge M anagem ent, 1999

T as k / Ac tiv ity

Review Learn ings

D evelop'G enerally Applic able'

Bes t Know ledge

D evelop'S pec if ic '

Bes t P rac tic es


executing the processes, and define measurements for both the Knowledge Assets and Knowledge Objects.



3.3. Description of the Know-Net KM Processes/Applications

Knowledger 2.0 developed by Knowledge Associates, is provided to the Know-Net Tool as an optional set of business process applications developed to execute through web-browsers. Knowledge Associates have also modified their applications to write the knowledge objects directly into the Know-Net Knowledge Object Store and utilise the Knowledge Objects directly from the Know-Net Knowledge Objects Store.

Over a period of time, other business process applications will be created and/or modified to likewise write the knowledge objects directly into the Know-Net Knowledge Object Store and utilise the Knowledge Objects directly from the Know-Net Knowledge Objects Store.

It is envisaged that a Know-Net API (Application Programming Interface) toolkit could be developed at a later stage beyond the Know-Net project and provided to third party development companies that wish to integrate the Know-Net tool into their KM Solutions.

Below is an initial list of the Knowledger 2.0 Applications available as ‘plug-in modules’ to Know-Net

1) Knowledger.objectives – This application performs a process to capture, maintain and share the Organisations Values, Vision, Mission and Objectives (Part of the Business Planning and Review Process)

2) Knowledger.contacts – This application performa a Sales Automation process, including client relationship tracking, proposals repository, presentations repository and sales focused discussions

3) Knowledger.bidmanagement – This application embeds the KM process into an automated Bid Management Process

4) Knowledger.project – This application embeds the KM process into an automated project management system

5) Knowledger.pdp – This application embeds the KM process into an automated personal learnings and competence management system

6) Knowledger.innovation This application embeds the KM process into an automated creativity and innovation system

7) Knowledger.bestpractices – This application embeds the KM process into the Best Practices process. It also integrates with the Knowledger.pdp application

8) Knowledger.bestknowledge – This application embeds the KM process into the Best Knowledge process

9) Knowledger.capital – This application captures performance and intellectual capital measures, in a simple form, and analyses them into human capital, structural capital and customer capital reports.

10)Knowledger.who’swho – a simple Who’s Who directory in the organisation

11)Knowledger.discussion – a modified discussion template to allow dynamic creation and listing of multiple discussions

12)Knowledger.libraries – a modified document libraries template to allow dynamic creation and listing of multiple libraries of documents



Furthermore, Know-Net can link any other Notes based application to its Navigators, including for example, Lotus Team Room and Lotus Learning Space.



3.4 Metadata Management

To enable the indexing, management and searching on Metadata, the Know-Net Tool requires the following metadata fields added to each document in the business process applications:

Document title

Authors

Creation date

Date of last modification

Document short description

Status of the document

Lifetime of the document

Index Categories

Please keep in mind the preliminary status of this list as explained in Section 2.3.4. on search. The Know-Net system is fully configurable with respect to the metadata schema applied. It should be defined individually for each user.



4. The Know-Net knowledge server

4.1. Why a Knowledge Server?

The Know-Net Tool is designed to support and enable a scaleable Knowledge Management System, from a small team, an SME, or a large Global Enterprise wide KM initiative.

To truly create, retain, leverage, reuse, measure and optimise the use of the knowledge assets of the entire organisation requires a design of a centralised Knowledge Server that will manage the ‘content’ to:

Receive explicit knowledge objects from all the business processes performed in the organisation into a knowledge object store

Maintain and develop explicit knowledge objects in one central place, avoiding duplication and fragmentation of knowledge

Allow for enterprise wide navigation, searching, filtering and dissemination of explicit knowledge objects

Furthermore, to truly create, retain, leverage, reuse, measure and optimise the use of the knowledge assets of the entire organisation requires a design of a centralised Knowledge Server that will manage the ‘processes’ to:

Identify and generate knowledge assets Manage and leverage knowledge assets Measure knowledge assets Disseminate knowledge assets

Furthermore, to truly create, retain, leverage, reuse, measure and optimise the use of the knowledge assets of the entire organisation requires a design of a centralised Knowledge Server that will manage the ‘networks’ to:

Manage better communications between knowledge workers in ‘virtual spaces’

Manage better collaboration between knowledge workers in ‘virtual spaces’

Manage better tacit knowledge creation and sharing between knowledge workers in ‘virtual spaces’



4.2 Definitions and Basic Concepts/Components

Stage 1 of the Know-Net Method identifies at the highest level the Key Knowledge Assets that need to be better managed in the Organisation. At this stage some basic ideas are captured into the Know-Net Tool about how the Knowledge Assets are to be defined and measured.

Stage 2 of the Know-Net method identifies and defines at the deeper level the Key Knowledge Assets that need to be better managed in the Organisation. At this stage, detailed specifications are captured into the Know-Net Tool about how the Knowledge Assets are to be defined and measured.

Stage 2 also identifies the Knowledge Objects that are created by the Knowledge Assets an how they are to be defined and measured .

The Knowledge Objects that are created by the Knowledge Assets, through Key Processes are then automatically written directly into a Knowledge Objects Store which is based on a Relational Database management System (RDBMS).

Whenever Knowledge Objects are created, edited/modified/developed or deleted in the Key Processes, they are automatically created, edited/modified/developed or deleted in the Knowledge Objects Store in the RDBMS. In other words, the Knowledge objects are both embedded in the Processes/Applications documents and written to a relational engine.

This mirroring and dynamic updating of Knowledge objects is achieved by using the ‘LEC’s or Lotus Enterprise Connectors software between Lotus Notes Databases and Relational Databases,As shown on the following page in Figure 72:



Figure 72 – Mirroring and Dynamic Updating on the Knowledge Object Store

Stage 3 of the Know-Net Method has the potential to be further developed to integrate knowledge objects directly into the Know-Net Intellectual Capital Performance and Measurement System

It is interesting to observe that the same architecture applies from the personal portfolio level to the enterprise wide level.


Know ledgeO bjec ts

Know ledgeO bjec ts

Know ledgeO bjec ts

Know ledgeO bjec ts

Know ledgeO bjec ts

Know ledge O b jec ts

Lotus Enterpris eConnec tors (LEC 's )

KM Proc es s es

Lo tu s No te s D a ta b a se s Re la tio n a l D a ta b a se(s)


4.3 The Fusion of the ‘content’ centric approach with the ‘process’ centric approach

In designing the conceptual and technical architecture for fusing both the content centric KM approach with the process centric KM approach, we examined the common characteristics and properties that Knowledge Objects contain in both approaches.

1. A Knowledge object is created and maintained by a KM process2. A Knowledge object is used to search, organise and disseminate

knowledge content

Therefore, we concluded that the Knowledge Object is the common unifier and lowest common denominator of a holistic KM system incorporating and integrating process and content.

Figure 73 – The Fusion of the ‘content’ centric approach with the ‘process’ centric approach.


KM P roc ess

Know ledgeO bjec t

Content Centricapproach to

Knowledge M anagem ent

P rocess Centricapproach to

Knowledge M anagement

S earc h

Index O rgan is eD is s em inate


4.4 The Knowledge Objects Directory

This is described in detail in earlier sections – more to follow in Work Package 5 by 31/12/99

4.5 The Knowledge Objects Store

This is described in earlier sections – more to follow in Work Package 5 by 31/12/99



5.0 The Personal Knowledge Portfolio Tool

5.1 Overview

This tool documentation describes MailTack a comprehensive development and exploitation environment for creating and exploring E-Mail Knowledge-Bases (MailKB); MailTack thus focuses on personal knowledge in communication tasks and contributes to a personal knowledge portfolio management as a component of the broader KnowPort system already described elsewhere (WP 2 and WP3).

MailTack is designed especially for e-mail users at all levels who would like to harness the power of state-of-the-art tools to construct a personal knowledge portfolio based on segmented e-mails (text). Aided by a sophisticated graphical user interface and an easy-to-learn set of MailTack commands, even a newcomer can create a MailKB quickly with MailTack. MailTack consists of a list of tools for creating and deploying MailKB's. A brief tour of these tools follows after an introduction to the MailTack philosophy.

5.2 MailTack Philosophy

MailTack assists users in exploiting the hidden potential of e-mail communication: doing different-time conversations (discussions, negotiations, argumentations, decisions, consulting, ask-answer sequences, complex know-how interactions, etc.) with many partners spread over different locations. You use MailTack for keeping constant track of a lot of different topics that develop independently over time and with contributions by many persons exchanging e-mail messages.MailTack makes e-mail conversation as easy and powerful as face to face conversa-tions eliminating the need for same-time and same-place meetings and adding the advantages of concentration on one medium, real-time overview and traceability.

5.3 E-mail Knowledge Base MailKB

The functionality provided by MailTack is based on the new concept of an E-Mail knowledge base called MailKB. Think of a MailKB as a network of connected e-mail conversations organized according to the following knowledge model:

expression: elementary conversation unit.

segment: connection of adjacent expressions in a text.



category: concept (keyword, expression) for designating the thematical views.

stream: connection of segments from one text or from different texts into a sequence (argumentation thread).

constellation: association of categories with other categories into a flat network (non-hierarchical).

categorization: association of segments with categories of a constellation.

According to this model, the user who wants to work with MailTack must organize the network of her E-mail conversations as follows: unite message sentences into segments, define categories and connect them into constellations, associate segments with categories and connect segments into conversation streams.Segments and categories are the building bricks of a MailKB. Segments are created from given e-mail messages and categories are (mainly) created from existing categories. Through connections and associations every segment and every category is directly or indirectly related to every other segment or category. MailTack lets you create a kind of knowledge base that is highly interconnected, quite like knowledge in your mind. A MailKB organizes e-mail messages into a highly personal conceptual space. By organizing your MailKB by your subject matters in associated areas, when you are thinking about a particular subject or idea MailTack will present you segments that contain that subject or idea with their context. You will then be able to contribute more efficiently and more effectively new ideas to an ongoing e-mail conversation.

5.4 Graphic User Interface

MailTack has two Main Windows, namely GraphTools and Text Tools. In the Graph Tools Window the user can see and handle the organisation of the knowledge base objects, i.e. mainly the streams, the constellations and the categorizations of his E-Mail texts. For different views the user can split up and arrange the window in different Desktops, select among different graph layout styles (like circular, symmetric and hierarchical), zoom to fit everything in one window or to see a portion of the graph and finally scroll through parts of the graph by means of an overview of the entire graph (symbolic scrolling).In the Text Tools Window the user can see and handle sorted lists of text descriptions (header entries, categories, categorizations) and the contents of the texts as well as access the database administration.GraphTools and Text Tools are tightly related: what the user chooses in one window is representated also in the other. For instance, if he is looking on a list in the lower Text Tools Window he can see the content of the list also in the upper Graph Tools Window in different graphs. Or if he klicks in the Graph Tools Window on a segment node he will immediately see the related text in the Text Tools Window.

5.5 Creating a MailKB knowledge base

In order to allow a user to create his own E-Mail Knowledge Base MailKB the following



functionality has been implemented:

Module "Import“ in the Text Tools Window allows to automatically import header and body of a message into a MailKB (automatic parsing of header informations). The current implementation requires that the user previously exports sent and received E-Mails from his E-Mail tool to *.txt format.

Module „Define“ in the Text Tools Window is dedicated to the definition of segments from the display of the E-Mail message text; it allows to connect adjacent sentences into thematical units - thus defining the segments - by simply selecting with the mouse a peace of text and then clicking a button.

Function „Define Streams“ has been realized at the Graph Tools level: the user can very easily connect segment nodes into sequences dealing with the same idea by simply selecting two nodes in the graph and a menu item.

Function „Create Category“ allows to add a new concept for designating a new subject matter or idea found in E-Mail messages. Two possibilities have been implemented: the user can either add an isolated category (for instance when a new constellation should be created) or create it from an existing category, in which case the new category becomes an extension of an existing constellation.

Function „Categorize Segment“ has also been implemented at the Graph Tool level: it allows to attach a segment to a constellation by associating it with one or more categories. The user can do this by simply selecting a segment and a category in the respective graphs and then clicking a menu item.

5.6 Editing a MailKB knowledge base

A set of functions intimately connected with the creation of the knowledge base are those which allow to modify it. This set includes:

disconnecting segments from a stream

deleting an association between two categories

deleting an association between a category and a segment

deleting a category

renaming a category

All deleting operations are subject to consistency checks which require that consistency conditions be fulfilled before executing the requested operation and disply warning and help messages when execution is denied.

5.7 Navigating a MailKB knowledge base

A MailKB is a network of connected segements and categories. As the user creates



categories and assigns segments to them, he will be navigating through the structure of his MailKB. Because a developed MailKB is too large to be viewed in its entirety, MailTack works with a visible area called the ‚focus‘, a graph of a set of segments or concepts closely related. There are two graph areas displayed in the default setting, a left focus graph an a right focus graph. At the center of a graph is the ‚active element‘ (active category‘ or ‚active segment‘), the element that the user has most recently selected. It is the element of immediate interest. Elements closely related to the active element are displayed on a circle around it. Any element is made active by clicking it when it is visible in the focus graph or by selecting it from lists. When an element becomes active, the focus graph is reorganized by placing the new active element in the center and showing its closest elements around it.

5.8 Searching a MailKB knowledge base

Besides navigating from focus to focus, finding a specific segment or mail in the MailKB is also supported by search functions that scan the database for segments and categories that match certain types or keys. Types are for instance ‚All segments', ‚All categories', ‚All mails', ‚Annotated segments', ‚Annotated categories', etc. Keys include header informations like ‚From', ‚To', ‚Subject', ‚Date From', Date To' and a list of categories. The user that for instance would like to view all segments sent by person P on subject S and associated with category C1 and C2 can enter these items in a search form, then activate the search and finally view lists of matching segments either limited to P or including P and S or including P, S and C1 or finally including all the keys.

5.9 Other functions

5.9.1 Importing any textThe "Import" module of the Text Tools allows the user to import E-Mails manually, i.e. without relying on the automatic parsing of header informations. These header informations must be there in automatic import but can be missing in manual import. Thus, this function allows also to import texts that have some special E-Mail header or more generally any kind of text.

5.9.2 Writing new E-MailsA natural consequence of having a clear overview of one's E-Mail discussions is the need of using this overview also in composing new contributions to a discussion. This is supported in MailTack by the "Write" module (Text Tools) which gives access to a standard multiple document interface (MDI). Besides writing and reading text files, the MDI is directly connected with the streams graph: clicking on any segment node allows the user to append the related segment text within the currently selected MDI document.

5.9.3 DB AdministrationBy means of this module the user has a direct access to the database records underlying his MailKB knowledge base and can modify them for instance by deleting E-



Mails or their segments, deleting or renaming categories, changing the DB-tables paths, viewing creation date, modification date and other parameters.



REFERENCES

Abecker, A., Bernardi, A., Hinkelmann, K., Kühn, O. and Sintek, M. (1998). Techniques for Organizational Memory Information Systems. DFKI Document D-98-02, DFKI GmbH, Kaiserslautern., Germany.

Bettoni, M., Ottiger, R., Todesco, R. and Zwimpfer, K. (1998). KnowPort: A Personal Knowledge Portfolio Tool. In REIMER, U. (ed.), PAKM 98, Practical Aspects of Knowledge Management.

Junker, M. (2000). Symbolisches Regellernen für die Textkategorisierung. PhD Thesis, University of Kaiserslautern and DFKI GmbH Kaiserslautern. In German. To appear.

Sonnenberger, G. and Wolf, M. (1999). User requirements of UBS / CRV: metadata fpr document management. Internal document of the Know-Net project, UBS AG, Zürich, Switzerland.

Tschaitschian, B., Abecker, A. and Schmalhofer, F. (1997). Information Tuning with KARAT: Capitalizing on Existing Documents. In: PLAZA, E. and BENJAMINS, R. (eds), 10th European Workshop on Knowledge Acquisition, Modeling, and Management (EKAW-97), Sant Feliu de Guíxols, Catalonia, Spain. Springer Verlag, LNAI 1319.

Tschaitschian, B., Sintek, M., Abecker, A., Hackstein, J., and Bernardi, A. (1999). Using Ontologies for Advanced Information Access. September 1999. Internal document of the KonArc project. DFKI GmbH, Kaiserslautern, Germany.

2.5.1 K

2.5.2
