THL Toolbox > Reference > Knowledge Maps & Controlled Vocabulary
Knowledge Maps & Controlled Vocabulary Manual
Contributor(s): David Germano
Introduction
Knowledge maps in this context signify hierarchical representations of a phenomena or topic. These thus function as systematic "maps" of a given topic or area of knowledge. Such knowledge maps can be very helpful to present the breadth of a given area, and help people orient themselves as to the full scope of the domain in question. Of course such maps are artificial to a degree, but this is true of all linguistic representations of an area of knowledge. Thus we are building knowledge maps for such areas as literary genres, geographical features, languages, religious sects, animals, and much more. These knowledge maps are not only helpful for readers to visualize the area and understand its various subareas, but we also utilize the knowledge maps to index THL resources. Thus as you look at a knowledge map, you can not only see a short description of each node, but you can also see whatever THL resources pertaining to it might be available - essays, texts, photos, images, audio-video, projects and so forth. In addition, labels for each node can be added in other languages.
For further detail, see:
- Knowledge Maps & Controlled Vocabulary User Manual
- Knowledge Maps & Controlled Vocabulary Editorial Manual
How does it Work?
We use a Ruby on Rails application called the "Knowledge Map Builder" (KMB). This online application allows editors to easily and quickly build and revise such "knowledge maps", including the addition of descriptions of of each level, and translation of level labels into multiple languages. These topical maps can then be imported into other applications as options to select from to fill in a given field. Thus the Place Dictionary calls upon a hierarchy of feature types - a feature thesaurus - created by the KMB in order to specify the type for a given feature. Likewise, in literary cataloging an editor calls upon a hierarchy of literary genres from the KMB to specify what genre belongs the text in question. The hierarchy can then be browsed by end users with the ability to view all the resources thus indexed. In addition, a given node used to catalog a given object will be hyperlinked back to its location in the overall hierarchy.
The KMB is an open-source project hosted on Source Forge under the auspices of the National Digital Library of Bhutan. The source code can found at: 
http://ndlb.svn.sourceforge.net/svnroot/ndlb/portal/ror/topical_map_builder/trunk/
The Basic Knowledge Map
The Knowledge Map Builder builds hierarchies that represent specific areas of knowledge. The result hierarchies are termed knowledge maps because they “map” areas of knowledge through detailing a hierarchy of levels, sub-levels and so on. These hierarchies then are understood to offer a reasonable structural view of the topic in question. Examples of such areas of knowledge include: the relationship of various languages and dialects, the different types of geographical features in an area, literary genres, religions and sects, grammatical function, and so forth. Each node has a unique ID that locates it within a given knowledge map. We are also adding functionality so that a given node can exist in multiple sites in the hierarchy.
Certainly there is an arbitrary character to structurally mapping what is always a complex, fluid and every changing phenomena. In addition, there is no question that there is a great degree of interpretation involved in such mapping, and that as a result, there will be disagreements about the particulars. Despite these issues, such structural maps are of great value in helping people orient themselves to the scope and structure of a given area of knowledge. As long as the presentation is nuanced, and makes clear the somewhat arbitrary and interpretative character of the map in question, as well as its limits, the pitfalls of people getting fixated on the map can be avoided.
Each knowledge map can have each level, or “category”, be described. These descriptions can be multiple, so that different scholars can offer different descriptions. In addition, comments can be appended to descriptions, so that scholars can also choose to just comment on other scholars’ descriptions. In this way, the knowledge maps are not just fixed, static, authoritative structures, but embody a rich dialog that includes disagreement and dispute.
In addition, each node can be given labels in different languages. Thus users can see labels in English, but also understand precisely what the item in question is by referring to another language which may be the original language for this item’s articulation. In addition, if the entire hierarchy is labeled in a given language, speakers of that language can also navigate the hierarchy entirely in their own language.
Finally, nodes can also be keyed to Tibetan dictionary terms when relevant. In this way, readers can then refer to the corresponding Tibetan dictionary term to view more detail about the term in relationship to its usage and history in Tibet. The Knowledge Maps are a useful complement to a dictionary, since they allow for the hierarchical display of how a given set of terms are related to each other. Within the Tibetan Dictionary, it is possible to express relationships between terms in many ways. However, it is not possible to express a complex hierarchy of relationships for a given area.
These knowledge maps are thus of value in and of themselves. They reveal an informed perspective on the structure and scope of a given area of knowledge, and also record scholarly dialog and dispute on the particulars of the analysis. They thus are a useful way to introduce people to a given topic, but also constitute a valuable reference resource even for people quite knowledgeable on the subject.
Use of Knowledge Maps to Index Resources
THL uses these Knowledge Maps to index resources in various repositories. These include: the image collections, audio-video collections, immersive resource collections, bibliography (including THL-published scholarly essays), Tibetan texts and catalog records, Tibetan dictionary entries (terms), and place dictionary entries (features). These involve a number of separate applications: the Media Management System, the Tibetan Dictionary, and the Place Dictionary, in particular.
On the editorial side, we will use the Media Management System and the cataloging of images to give an example to illustrate how it works. When an editor wants to associate a given node within a Knowledge Map with an image, s/he clicks on the relevant field, and it pops open a full display of the relevant knowledge map through a Web Service API. The display has the standard Knowledge Map controls for expanding and collapsing the hierarchy to find the desired node. Because it is being provided dynamically and directly from the Knowledge Map application, the display of the tree and node labels will reflect every change made up until the moment at which it appears. Once the desired node is highlighted, the editor hits the “select” button. This causes the popup to close down, and the ID for that node is inserted into the image cataloging field in question. The application uses that ID to retrieve the corresponding label from the Knowledge Map through the Web Service API, and displays the label.
For end users, the image cataloging record then displays that label for the relevant Knowledge Map field as a hyperlink. If a user clicks on the link, it opens up the corresponding Knowledge Map, and displays the tree expanded to with the label in question highlighted. In this way, users can easily and quickly see what a different label applied to an image means through viewing it within its knowledge map, and reading its corresponding description.
In addition, the Knowledge Map itself can query all repositories utilizing it through Web Service APIs that those repositories provide and determine exactly how many and what type of resources have been indexed by each of its nodes. In this way, the Knowledge Maps can be used to browse these repositories by a variety of subjects. This further enhances the value of Knowledge Maps, since as you explore the subject matter in question, you can not only see its structure and scope, but directly access resources that are relevant to each node. This querying would be difficult to do dynamically each time a Knowledge Map is consulted, since it would create significant speed issues, not to mention draw on the server’s computation resources. Thus we are projecting that it will be done each night at, say, midnight, so that the display of indexed resources will be current for a twenty four hour period.
The actual display will use graphic icons that correspond to each type of resource (images, audio-video, essays, Tibetan terms, Tibetan texts, etc.), and parenthetically indicate how many of each resource has been indexed by the resource in question. As you explore the knowledge map tree on the left, the resources are display on the right hand side at the top above the node’s description(s). When you click on the node or number, it then provide a lightbox popup that allows you view those resources and interact with them.
This process allows editors to rename and shift the structural position of any given node, and yet repositories that have utilized those nodes already for indexing will still work since they have indexed them by ID rather than label or position per se. The application also prevents the deletion of any node that has resources associated with it, and thus requires editors to first remove all such associations. Special Points
In many cases, we know precisely what knowledge map we want to use for indexing resources. However, in other contexts, we want to allow editors to choose any knowledge map and be able to do so as many times as they like. This provides great flexibility to editor. Thus we need a plugin that simply opens up all knowledge maps, and allows an editor to create as many instances of it as s/he desires.
When browsing a Knowledge Map, if your interest is in specific type of resource, or resources in general, you will want see the Knowledge Map with only nodes displayed that actually have content. For example, if you use the “feature thesaurus” to provide a list of feature types that you can display or hide on a map, you certainly don’t want to have to sort through scores of types which have no actual features yet associated with them. Thus the Knowledge Map application needs to be able to offer a view, and a Web service API, which hides nodes that don’t have content associated with them. When a given branch has an active node several layers down, but its parent nodes have no active resources associated with them, the display simply hides the non-active layers, and displays the active node at a higher level. In this way, the entire tree is displayed in a truncated form with only active nodes.
In some cases, an editing application may want to use only a specific branch of a knowledge map, and not want to confuse editors with a cumbersome display of the entire map. Thus the Knowledge Map application must provide a Web Service API that provides only a given branch on down as detached from the larger parent Knowledge Map.
Reservations & Reconciliations with Knowledge Maps
The above depiction may seem persuasive, but there are obvious problems – especially in the highly interpretative and highly contentious climate of academics. The problem basically is that people will not agree on the precise character of how to map out a given area of knowledge. Disagreement will range from arguments about precisely what to label a given node to dispute over where a given node should sit in the hierarchy, all the way up to wide ranging differences on the entire structure of a given map, or even if the topic guiding the knowledge map is a valid one. There is no perfect resolution to such disagreement, but there are strategies for addressing it and achieving a significant degree of reconciliation within a community of scholars. While not perfect, we believe that a robust implementation of these strategies for reconciliation and the value of consensus for a community greatly outweigh the limitations of this system and its drawbacks.
Firstly, the Knowledge Map application allows for a considerable degree of disputation and discussion. Multiple descriptions and comments can both be attached to any given node, such that divergent perspectives can be represented, and dialogs can develop and be archived.
Secondly, each Knowledge Map can be maintained by a team of editors, so the structure resolved upon itself involves community discussion and compromise.
Thirdly, we can allow for a wholly different maps be built that represent quite divergent perspectives – whether from historical sources or contemporary scholars – for a single topical area. However, we can insist that the communally maintained map be the canonical form which gets used broadly for indexing of resources in THL. We can further enable maps to be horizontally connected, so that alternative maps for a given knowledge area can be indexed by the canonical map in that area. In this way, one could use an alternative map to index a given set of resources, but the resultant index will still allow those resources to be found in navigating the canonical version. There would, however, be exceptions – such as when the alternative map had nodes or even whole branches wholly missing in the canonical map.
Fourthly, every community involves embracing common standards that are not agreed upon by all for the sake of the common good. The traffic system, and even human language, are both perfect examples. Of course we could ignore the association of a red light with stopping, and so forth, but the result would be the absence of a well functioning traffic system and all its attendant benefits. Or we could all associate whatever sound we wanted to with objects, but then we would lose the great benefit of a common tongue. Admittedly, these both involve fairly arbitrary associations, and dispute over knowledge maps involves more interpretative issues and disagreements. However, the point stands – we come to consensus and reconciliation because the advantages of community standards often outweigh the advantages of complete individual freedom of choice. We believe the value of the knowledge maps – which allow the public to systematically explore areas of knowledge and directly access a wide variety of associated resources – greatly outweighs the drawbacks. This is particularly so when the system addresses difference and dispute in a variety of ways as outlined above.