Let’s talk about knowledge. Let’s talk about knowledge as it relates to a traditional K-12 curriculum. About twelve years ago I designed a curriculum management software application. As I began it’s development I decided that “it all begins with content areas”. In other words the frameworks of content in our traditional formal educational systems for instruction are top down in nature. Every school district develops courses within content areas. They might be, mathematics, social science, language arts, science, foreign language, art, music, family & consumer science, technology, business, etc. This domain of content areas is meant to represent the scope of knowledge to be addressed in the k-12 curriculum of that district. For each element of that domain there exists an implicit or explicit content taxonomy.
Taxonomy
A taxonomy is just a classification of things. They are usually hierarchical. They do two things: give exact names for everything you’re dealing with (your ‘domain’) and show which things are parts of other things (sometimes called parent-child relationships, sometimes called broader-narrower). In our case someone develops what I call major content strands. For the domain music, they might be: The elements of music; Musical history & style; Listening to music; Performing music; Creating music; The role of music in society and valuing and evaluating music. For each of these major strands there would appropriate sub strands, perhaps three or for levels deep. Assuming the same thing is done for all other content areas in the domain, we would have a set of taxonomies as a framework for instruction. This would represent the scope of instruction. The assumption would be that every course objective in every course in any content area could be mapped into the content area taxonomy. If this were done then we could define the sequence of learning and the degree of articulation of the instruction.
I mentioned earlier that content taxonomies are implicit or explicit. In almost all cases, these taxonomies are not explicitly designed or used as guides for curriculum development. Instead decisions about content are made primarily by textbook authors. As an algebra teacher, my focus and thus the focus of the learners is on the table of contents of my textbook. I assume that in other courses in the k-12 mathematics curriculum the rest of the “domain of content in mathematics” is being well addressed.
Ontology
An ontology is like a taxonomy in that it is going to contain all the entities in your domain (for one reason or another–probably its roots in philosophy–people often seem to use the term “universe” when talking about the domain of an ontology), and show the relationships they have to each other. However, it does more: it has strict, formal rules (a “grammar”) about those relationships that let you make meaningful, precise statements about your entities/relationships.
An ontology is a formal representation of a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to define the domain.
An ontology as a formal representation of reality as seen by it’s creator at the time it is created.
A Simple Knowledge Engineering System
As we said earlier, there is no one “correct” way or methodology for developing ontologies. Here we discuss general issues to consider and offer one possible process for developing an ontology. We describe an iterative approach to ontology development: we start with a rough first pass at the ontology. We then revise and refine the evolving ontology and fill in the details. Along the way, we discuss the modeling decisions that a designer needs to make, as well as the pros, cons, and implications of different solutions.
First, we would like to emphasize some fundamental rules in ontology design. These rules may seem rather dogmatic. They can help, however, to make design decisions in many cases.
1) There is no one correct way to model a domain— there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.
2) Ontology development is necessarily an iterative process.
3) Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.
That is, deciding what we are going to use the ontology for, and how detailed or general the ontology is going to be will guide many of the modeling decisions down the road. Among several viable alternatives, we will need to determine which one would work better for the projected task, be more intuitive, more extensible, and more maintainable. We also need to remember that an ontology is a model of reality of the world and the concepts in the ontology must reflect this reality. After we define an initial version of the ontology, we can evaluate and debug it by using it in applications or problem-solving methods or by discussing it with experts in the field, or both. As a result, we will almost certainly need to revise the initial ontology. This process of iterative design will likely continue through the entire life cycle of the ontology.
Folksonomy
Folksonomy is a new term — I mean, literally, it came about in the last couple of years. It’s essentially what you see on del.icio.us or flickr by way of the use of tags. It’s in many ways the exact opposite of a taxonomy in that:
a. Folksonomies are flat (that is, they have no hierarchy, and show no parent-child relationships)
b. Folksonomies are completely uncontrolled (part of making a taxonomy is deciding what the names of your entities are, but in a folksonomy, there can be a thousand different words for the same thing)
Any relationships you see in a folksonomy have to be derived mathematically (statistical clustering).
However, a folksonomy is like a taxonomy in that they share the same purpose: classification. A lot of debate is going on right now about which is better, though of course the answer is that you use them for different purposes. It’s nice to have both.
• The core property of a taxonomy is that it possesses a hierarchical structure.
• A taxonomy classifies according to properties internal to the data, a classification can be made
according to external criteria.
• Taxonomies tend to mix with simple ontologies. Using more specific terms than just “ontology”
(like “ontology with inheritance hierarchy”) helps to give more clarity.
• Once a lot of properties and relationships are added to a hierarchical structure, the term “ontology”
is better suited than “taxonomy”.
• A classification tells you in which box your piece of data is, an ontology tells you what your data is.
Grass-roots categorization, by its very nature, is idiosyncratic rather than systematic. That sacrifices taxonomic perfection but lowers the barrier to entry. Nobody needs a degree in library science to participate.
It comes down ultimately to a question of philosophy. Does the world make sense or do we make sense of the world? If you believe the world makes sense, then anyone who tries to make sense of the world differently than you is presenting you with a situation that needs to be reconciled formally, because if you get it wrong, you’re getting it wrong about the real world.
If, on the other hand, you believe that we make sense of the world, if we are, from a bunch of different points of view, applying some kind of sense to the world, then you don’t privilege one top level of sense-making over the other. What you do instead is you try to find ways that the individual sense-making can roll up to something which is of value in aggregate, but you do it without an ontological goal. You do it without a goal of explicitly getting to or even closely matching some theoretically perfect view of the world.
Critically, the semantics here are in the users, not in the system. This is not a way to get computers to understand things. When del.icio.us is recommending tags to me, the system is not saying, “I know that OSX is an operating system. Therefore, I can use predicate logic to come up with recommendations — users run software, software runs on operating systems, OSX is a type of operating system — and then say ‘Here Mr. User, you may like these links.’”
It’s all dependent on human context. This is what we’re starting to see with del.icio.us, with Flickr, with systems that are allowing for and aggregating tags. The signal benefit of these systems is that they don’t recreate the structured, hierarchical categorization so often forced onto us by our physical systems. Instead, we’re dealing with a significant break — by letting users tag URLs and then aggregating those tags, we’re going to be able to build alternate organizational systems, systems that, like the Web itself, do a better job of letting individuals create value for one another, often without realizing it.
IWhy do we examine taxonomies, ontologies and folksonomies? What part can they play in our quest to leverage learning with web tools?