|
|
Ontological
Excavation:
|
|
|
|
IntroductionFrom our case studies of ontological excavation, we have observed some distinct characteristics in the recovered ontologies, such as the CD Player’s central cluster of core concepts surrounded by attributes, the Protocol Calculator / Calendar’s multiple subgroups within its ontology, and Notepad’s multiple teleons. We also noticed a possible correlation between these characteristics and the conceptual coherence metrics for their respective applications. These observations suggest that applications may be categorized by their ontological structures. These structures exhibit common forms that likely emerge from design and evolution. We present three hypothetical archetypical ontological structures: We will also discuss the implications of these hypothetical structures for the design of computing applications. The Reef StructureA Reef structure represents a system that implements a tightly related set of concepts, possessing a high conceptual coherence. Many metaphors exist that could express the idea of a unified set of concepts constructed around a central architecture. We chose a biological one to account for the evolutionary behaviors that we have observed in the ontologies of single purpose applications. Coral reefs are ecosystems built on a skeleton of calcium deposits created by tiny creatures called coral. This skeleton provides a habitat for many species that each play a role in maintaining the reef environment. Over time, the reef can grow and develop a very rich and stable biological system. A Reef ontological structure has a central structure that not only supports itself but also a number of other entity types that contribute to the overall system. A Reef-like computing application has an endoskeleton of core services and layers of peripheral services that are supported by the endoskeleton. For example, a spell-checker for a word processor is a peripheral service. Spell checkers could not exist independently of changes for text that has to be spelled correctly. Figure 5 shows an abstract ontology for what we would expect to find in a Reef Structure application – a skeleton of core concepts with some supporting ones on the periphery.
Simply stated, this application does one basic thing. It may have services that aid in the achievement of that central goal but these services could be removed without much loss to the overall application. Arguably, most applications begin as reefs – tools built for a single purpose. Over time, applications with well-defined goals or constrained domains may evolve by acquiring new features but they only tend to acquire those features that can directly support and enhance the existing ones. We believe that examples of Reef workpiece applications include PowerPoint (essentially just a presentation generator), Adobe Photoshop (a bitmap editor), and TurboTax (a financial management tool designed to produce tax documents). Most small applications and games, like CD Players, Solitaire, Calendars, Clocks, and so on are also Reef structures.
The Toolbox StructureA toolbox that you might find in a home is a collection of tools that have different affordances for specialized tasks. Hammers, screwdrivers, and pliers all contribute to different sorts of tasks but one usually does not use every tool in a toolbox to accomplish a task. A Toolbox structure (Figure 6 ) has a collection of conceptually unrelated and lightly related ontologies that have been assembled for reasons of convenience or design under a single morphology.
The tools in a toolbox collectively support a broader category of goals such as resource management, information management, or media playing. Over time, a Toolbox may collect more tools, enhance the capabilities of its existing tools, or begin merging the tools by combining their functions. Examples of Toolbox model workpiece computing applications include RealOne Player (a media player that supports CD playing, CD burning, Internet radio, web browsing, and MP3 management) and Yahoo! Instant Messenger (ostensibly a instant messaging tool that also delivers information such as weather, stocks, auctions, and news). The overall Toolbox structure will have less conceptual coherence by definition but will be structurally coherent within each individual tool. The Urban StructureUrban areas in cities are often divided into large neighborhoods that compete for influence, income, resources, business, and desirable populations of people. Sometimes neighborhoods will fragment into smaller zones. Other times, neighborhoods will subsume other less successful neighborhoods. The collective urban environment may be easy to identify on a map but the subordinate areas within that region may not be.
The Urban Structure (Figure 7 ) results when an application has acquired features that cause its ontology to lose conceptual coherence. Large clusters of features may merge, blurring the boundaries between some services, or fracture, causing others to become more isolated and independent of the computing application. We expect the ontology of an Urban application to contain competing clusters of core concepts (multiple and unrelated teleons that have similar sizes and influences on the ontology). It differs from the Toolbox Structure in that these core concepts are connected to each other. A Toolbox can have large independent clusters of ontologies because, in practice, each cluster represents a tool that is used independently. The Urban Structure can result from a design that had poorly articulated or confused requirements. It also might have begun as a Reef or Toolbox model but over time had evolved by growing in size and functionality to acquire new customers that have different and occasionally conflicting, requirements for this application. Over its lifetime, such an application may be perceived to be more bloated by users who find themselves using smaller and smaller percentages of the overall system with each release. Examples of Urban workpiece computing applications include Microsoft Word and Microsoft Excel. Ontological Structures and Computing ApplicationsWhile still hypothetical, these archetypical ontological structures have interesting implications for aiding designers in designing and enhancing their applications. If this and future research show a correlation between usefulness and conceptual coherence, then one could imagine design heuristics encouraging adoption of the Reef or Toolbox ontological structures as a framework for organizing domain concepts in the ontology of an application prior to developing the software architecture. Bloat could be detected in the ontology by detecting Urban ontological structures in existing applications and in the ontologies of future application versions before proposed features are added. In applications with a close correspondence between its concepts and the underlying software architecture, software maintenance activities could include ontological grafting and pruning; adding teleons to the ontology or removing them to preserve conceptual coherence. For example, if a computing application is found to have an Urban ontological structure, one could preserve the stability and enhance the maintainability of the application by pruning one of the competing clusters of core concepts and creating a separate application that contributes services without sharing morphologies. These potential represent tremendous payoffs in improving software usefulness and in reducing unnecessary effort at the development stage.
|
|
