The following terms are important for the discussion and will appear in several places below. They are listed here for the sake of clarity.
Let S be a set of concepts, and let C be a concept in S. A context in S that contains C is called a contextual neighborhood of C in S. The contextual topology on S is the set of all contextual neighborhoods (in S) of concepts of S. If a concept C has no contextual neighborhood involving other concepts from S, then C is called an isolated concept in S. Let us add the following terms to our dictionary:
Presenting informational content requires some form of containing structure - or context - for the information that is to be presented. A traditional dictionary, for example, uses lexicographic ordering of the labels representing the content to create the structure of the presentational context. This lexicographic context has the advantage of making the content easily accessible through the corresponding label, but at the same time it has the drawback of not showing any conceptual relationships between the different pieces of content.
Therefore, a dictionary creates a totally disconnected (= discrete) contextual topology on the set of the corresponding components - with each separate component corresponding to an isolated concept.
A textbook, on the other hand, normally makes use of some form of taxonomy (= classification scheme) in order to create a suitable context for the presented information. For example, if the textbook is about animals, they might be presented as a taxonomic type-hierarchy of insects, fish, reptiles, birds, marsupials and placentals on the first sublevel. Each of these types would then in turn be appropriately subtyped according to the level of presentation and targeted reader profiles. The chosen classification scheme creates a context that gives a relational structure to the informational content, and this context reflects the corresponding taxonomic connections between the various information components. In this way a textbook creates what could be called a taxonomically connected contextual topology on the set of content components.
Of course, the components of a book are frozen into a single context by the order in which they are presented in relation to each other. In the case of a hyperlinked multimediated system - such as e.g. the WWW - the situation is very different. Here there are in general many different contexts for the components, and both their number and their form are constantly changing by the addition and removal of pages and links.
For example, a web-browser maintains a dynamic contextual relationship between the page that is viewed now (= this page) and the page that was viewed the moment before (= the previous page). The corresponding dynamic contextual neighbourhood is traversed by using the browser buttons 'back' respectively 'forward'. Another (larger) example of a dynamic contextual neighbourhood is given by the browser's history list.
In fact, each web-page functions both as a container of its content and as a context for the contents that are reachable (by a mouse-click) from it. Consider a typical web-page Q. Each web-page P from which Q is reachable forms a context for Q. If Q contains a link to another web page R, then Q forms a context for R, and if R contains a link to Q, then the relationship is reversed and R forms a context for Q.
In this way the underlying link structure leads to an inextricable mixture of content and context - creating what could be termed a reachability-connected contextual topology on the set of components. Since these connections only have "1-step-forward visibility", this tends to make each web-page more self-contained, and could be expected to favour a contextual design that focuses more on various forms of eye-catching techniques rather than on illuminating the conceptual relationships of the content. Of course, when designing a conceptual presentation system - as in fact when designing any kind of system - the overall aim is to use visual techniques in order to support the underlying conceptual context, and not as a substitute for this context.
The contextual topologies that were discussed above are extreme in terms of their relationship between content and context. Books are totally (= linearly) ordered and do not allow reuse of components in different contexts. The overall context of a book is fixed, and so is the relationship betweeen its context and its content. The WWW, on the other hand, presents a totally fluid and dynamic relationship between context and content, which makes it hard to get an overview of the context within which the content is presented. This results in the all too well-known web-surfing-sickness that could be summarized as "Within what context am I viewing this, and how did I get here?"
Multitudes of different knowledge management tools have been proposed in order to deal with the problems mentioned above. Although we make no attempt to survey this field, we mention Mondeca , OntoBroker , OntoLingua , Protegé  and Tadzebao . They usually display the connections of the different content components in terms of text-based trees or labeled connectivity maps - such as concept maps ,  or Topic Maps  - and they all attempt to highlight the conceptual relationships in different ways in order to support the overview of the information landscape. However, since none of them is based on contextual topologies, the capability of contextual navigation (by traversing contextual neighborhoods) is not supported by any of these systems. Neither is the capability of context-dependent aspect filtering of content components, which is discussed below.
A concept browser is a knowledge management tool that conforms to the eight major design principles listed below:
The principle of separation between context and content is a design feature that is applied with varying degree of rigor by different knowledge management, including the ones mentioned above. The strict adherence to this principle introduces two different modes of the conceptual browsing process that are termed surfing respectively viewing. You surf the contexts (= context maps) and view their respective content (= resources). Note that this usage of the term 'surfing' is consistent with standard web terminology. When you surf the web in the normal mode, you have direct access only to the next level of forward links, a process that could be termed surfing with forward-single-depth link visibility. In contrast, when you surf/view the web according to the principles of conceptual browsing, you have direct access to the content of all the concepts and concept relations without losing the overview of the context. This could be described as conceptual browsing with multiple-depth link visibility.
A context map with visually defined semantics breaks up the linear order of any verbal presentation of the depicted conceptual relations. It shows them all at the same time, as opposed to a verbal presentation that is forced to describe them in a certain order by creating a journey (= navigated path) between the different concepts on the map. In terms of supporting the contextual overview, a context map has a fundamental advantage in comparison to a verbal presentation. The reason behind this advantage lies in the fact that our capacity to visually survey conceptual relationships in different directions is considerably greater than our capacity to change the directions of the corresponding verbal descriptions. Hence, it is much easier to cognitively integrate the contextual information visually than verbally. In fact, this is the very reason why we use the term 'overview' (instead of something like 'overwords') for the description of such a contextual survey.
Since its introduction in 1997, the Unified Modeling Language has emerged as "the Esperanto of object-oriented modeling". Over the last decade, Ambjörn Naeve has developed a more concept-oriented modeling technique , , which is designed to visually depict how we speak about things. This technique has been adapted to UML under the name of Unified Language Modeling (ULM), the basis of which is depicted in this figure:
Making use of ULM for the graphical representation of each context introduces clearly defined (and verbally coherent) visual semantics for the concept relations, which makes it easy to visually convey the meaning of the underlying contextual model. This standardized overview support is a crucial advantage in comparison with other contextual representation techniques, such as concept maps or the related topic maps, which rely on verbally defined semantics in order to convey their contextual models.
This feature enables contextual navigation in a way that naturally corresponds to the underlying contextual topology of the presented information. As a concrete example, if we think of the context maps as an atlas, and consider e.g. the concept of Paris, then we can easily switch between all the different maps in the atlas where Paris appears.
Contextual navigation by "neighborhood switching" is one of the characteristics of a concept browser, which (to the author's knowledge) distinguishes it from any other knowledge management tool that is available today. A concept browser is fundamentally important for the construction, exploration and presentation of information that is structured in the form of a Knowledge Manifold, which is a learner-centric educational architecture that supports customizable forms of inquiry-based learning. For more information see , .
Both the concepts as well as the relationships of a context map can be assigned a multitude of different content components. These components can then be displayed in different ways, e.g. through an ordinary web browser, in a way that is controlled by the concept browser. Highlighting a concept and simultaneously displaying both its content and its present context provides an effective cure for the "web surfing sickness" mentioned above.
This principle allows for a third mode of concept browsing, called inspecting, which is a "metadata mode" that enables the study of the labeling of the resource components, or the automated search for such components based on their respective labels. These labels include such information as author, coverage, description, granularity, interactivity level, platform requirements, pedagogy, use rights, use support etc. - all of which are part of the IMS metadata scheme , .
Since a concept browser should support the reuse of concepts and concept relations in different contexts, some of these concepts and concept relations will eventually become associated with very large sets of content components. This suggests a variety of filtering and sorting features, where filtering means hiding inappropriate content components, and sorting means arranging the displayed components in some form of structure (e.g. a tree of maps). In order to support a context-dependent presentation of content, each combination of a concept and a context (or a concept-relation and a context) should allow the definition of its own separate filtering and sorting layer, which can narrow the scope of the presentation of all content components of this concept (or concept-relation) in the corresponding context. The presentational structure (sorted order) can be thought of as different aspects , which need not be exclusive. In a longer perspective, users may have locally defined filters working as a part of their own personal profiles. Since the filtering and the sorting should be based on metadata only, the content components themselves should not affected. This is a novel (and very powerful) kind of information interface technique.
No information presentation system can claim an absolute distinction between content and context. As we have seen above in the case of a hyper-linked information system, the content of a concept may well form the context of a set of other concepts. Hence it is important for the flexibility of a concept browser to allow a content component to be a context map in itself. However, it is of fundamental importance to maintain the separation between context and content. Therefore, when a context map appears in the form of conceptual content, it should not at the same time be treatable as a context. In order to be able to treat it in this way, we should first contextualize it, which transforms the content component into a context map and displays it in the context window of the browser, where it can be treated exactly as any other context map.
The importance of lateral thinking to web browser use in not fully recognized. Often people do not follow a logical path when browsing. They start with one concept in mind, follow that for a couple of links, then spot something that is peripheral but interesting. What is needed is a "concept graph" that allows people to identify sets of resources that they have visited that were related to a particular concept. For example, if a user visits three resources about Topic Maps, then the concept bookmarker will add Topic Maps to her list of recently browsed concepts. If she then goes off and reads a series of resources that contain critiques of Wittgenstein, then he should get added to the concept bookmark list.
Often we do not know what we want. We start somewhere in the hope of getting to some unarticulated goal. What we need is a record of how we got there so we can find other matching patterns. For example, say a user looks at a web site on mathematics to find out something about lattices and comes across a particular person who has produced an important theorem on the subject. What the user then wants to do is to look for other sites where there are resources that reference the same theorem, but only if they are linked to other resources that are about lattices and related to mathematics, rather than the use of lattices in computer applications. In this case it is the context that is important, and which needs to be reused, not the single concept. Such context-based searching will be made possible by the Edutella system  discussed elsewhere on this website. These "contextual queries" will be phrased in a graphical query-language based on the ULM technique mentioned above.
A first prototype of a concept browser, called Conzilla  has been developed during the past 3 years within the KMR group at CID . Conzilla is written in Java and uses XML as the underlying format for exchanging information. Since the program is carefully designed  with a clear object-oriented structure that separates the underlying logic from the presentational graphics, it can easily be adapted to different presentational styles and cognitive profiles. Conzilla is presently being developed as an open source project at SourceForge. Several Conzilla-based knowledge manifolds are presently under construction at CID, e.g. within the fields of mathematics , IT standardization and interoperability between different systems for e-commerce .