CommentThe Know-Net-Papers are fixed on a deliverable point, but we develope our Documentation further, while we develope our tools. |
KnowPort (KNOWLEDGE PORTFOLIO) is a subproject of the EU esprit project KnowNet (KNOWLEDGE MANAGEMENT WITH INTRANET TECHNOLOGIES) for the development of information technologies to support and improve the learning abilities and learning efficiency of individuals, teams and organisations.
KnowPort investigates the tier of INDIVIDUAL knowledge management with the aim to develop a tool "KnowPort" (SW tool and means) that allows knowledge workers to manage knowledge (Knowledge Portfolio) so that learning and knowledge sharing be supported and improved.
KnowPort consists of 4 subprojects MailTack, FileTack, TaskTack, WordTack), each with own user requirements specifications. Therefore only general considerations are made here. Our general requirements (non tool-specific) are very near at the requirements of our partner UBS, the essential difference concerns the hierarchy of access which is in a bank of essential importance, but is of course not relevant at individual level.
We understand our project as individual or personal knowledge management
Since we understand our project as individual knowledge management, we can ask us, which requirements we ourselves make on our product. In this case, we give up to be representative, however we win a lot more specific and more thorough knowledge than with surveys of course. Particularly, in this procedure the so-called hidden or tacit knowledge becomes available to us. In addition, we can regularly update our requirements, if that is suggested by new insights.
Since we develop tools and techniques, we can understand the resulting knowledge as technology. In this sense, we perform the development of the knowledge tools in order to develop our understanding of knowledge. This methodology has an autopoietic character in that the very results of developing (the software tools) are used as means for doing that same developing work. A consequence of this selfreferentiality consists in one basic requirement to the tools we develop: that they should serve us during our progress in the process of developing them as well as in the process of understanding what we mean by "knowledge". When we start we imply to know what knowledge is. Then the tools and their use make explicit, what we mean by knowledge.
What ever knowledge is, at least partially it appears in form of data, which may act as external memories. We distinguish different data related actions as speaking, making a phone call, writing, sending e-mails, and so forth. However here we are concerned primarily with data-related operations, which lead to electronically written texts, i.e.to texts that can be processed on computers (Inter- and Intranet).
2.1. The holistic engineering process.
At the beginning we speak about what we construct, that is which one of our activities we intend to systematise and realise as tools and how we plan to do this. We collect ideas in form of tools and texts, that seem useful to us. In order to keep survey we arrange the texts, we manage them. We reflect on how to do that best (best practice). We specify a wish list, whichsays what we would like to have and therefore want to construct.
We document what we collect:
Everything, what we collect from the viewpoint of the development of knowledge, can be understood as "Artefact". A partial set of the artefacts we are interested in, are texts.
A task - one the we unconsciously already perform everytime - is ordering these artefacts, bringing them into relations and so forth. Therefore, we can observe, what we do with that artefacts. We manage the texts on a server which can be accessed by all of usl. We associate the texts via links and build a structure.
Our tools and means must support us in this. More precise requirements are explained in the subprojects.
Typically knowledge is stored in an encyclopedia. However, the encyclopedia is necessarily context neutral and contains no knowledge about current cases. So no encyclopedia says for example what the stock trader recommended yesterday to me at phone or which conditions were linked to a specific offer which I received about four weeks ago. In practice however we want very frequently to look up such context binded, current knowledge.
In order to solve this problem we will pursue an action oriented approach in the KnowPort project which is based on our Trace-your-Tack-Principle: Trace your knowledge in action (on tack), in order to sail on the right tack in the knowledge ocean! KnowPort therefore, will be used for recording knowledge relevant events during the application of personal knowledge in the context of a current activity.
We therefore concentrate on the input side of the document administration in order to reduce retrieval complexity. We want to support the process in which information is linked into the knowledge base. Automatable processes will be automated. Interactive processes will be supported by visualisation.
3.1.1. Hardware and software platform
Our tool shall be usable on the usual computers/operating systems, first of all on Personal Computers and workstation with Windows and Internet browsers.
Safety and reliability are defined in the field of the available hardware/software. The personal Knowledge management does not specify additional requirements.
Knowledge management contains many different fields as information retrieval, document management, workflow management, time and project management. Therefore a smooth collaboration between the used tools and sources is really important.
Our tools should not force specific organisational structures. It is important that the tool allows the reorganisation of the data and knowledge base. This includes the definition of new (sub-)categories, renaming and deleting of categories, moving documents to new places, etc. Such activities should be possible at any time, also for running applications.
The integration of existing documents is a relevant goal. In particular it should be possible to import HTML documents with their links. Updating local files after processing them on external platforms should be supported like in MS Windows. Integration of printed documents (from scanning and OCR readers) should be supported.
All the most common document types and formats should be supported, in particular the formats of the most used text and graphics software packages (Word, Exel, Adobe, Corel and so forth)
The documents should be visible as objects with qualities like author, date, version and so forth.
Contributions to discussions which are stored in various places should easily be brought into sequences.
As the automatic derivation of content descriptions is still experimental, a mixed mode with short, rather general, manually assigned content descriptions in addition to automatically derived ones is possibly the best solution. The classification of document contents best works with a formal conceptual model of the domain in form of a thesaurus or an ontology. Such conceptual models have to be built up first and then to be maintained continuously. Both tasks require manual work but could be supported by text mining techniques.
Pattern recognition is usable on different tiers. It can be used in order to enlarge
domain-specific thesauruses. In this way the automatic derivation of contents descriptions
could be improved. More refined analysis tools can recognise and support typical
Tools should help the knowledge manager to find dangling links, outdated documents (i.e. that were not modified after a certain date), cyclic links, etc.
One should be able feature the documents for particular search machines, to make sure, they are really found, if they correspond to the search inquiry.
The tools should be adjusted to the most used GUIs so that the users do not have to change their habits, where this is not combined with massive advantages. The tools shall give clear feedbacks and avoid asking cryptic questions.