At this year’s Taxonomy Boot Camp conference, I was invited to present on the panel giving 5-minute “Pecha Kucha” lightning talks, for which this year’s theme was ontology. Just as there are different understandings and usages of “taxonomy,” so are there different understandings and usages of “ontology.” You can come to if from different angles. If you come to ontologies from the experience of taxonomies and the field of information management, then, most simply, an ontology is a more complex type of taxonomy that contains richer information.
In my brief presentation, “From Accidental Taxonomist to Accidental Ontologist,” I summed up the differences between taxonomies and ontologies as follows:
- Relationships: Taxonomies have hierarchical and sometimes a simple “related term” associative, but ontologies have semantic relationships, which are custom-created.
- Term Attributes: Taxonomies generally don’t have term attributes, but ontologies do.
- Term Classes: Taxonomies generally don’t have classes for terms, unless you consider facets as classes, but ontologies do.
- Guidelines/Standards: Taxonomies should follow the ANSI/NISO Z39.19 (2005) or ISO 25964, whereas ontologies are expected to follow the Web Ontology Language (OWL) guidelines and make use of the Resource Description Framework (RDF).
- Purposes: Taxonomies support indexing/tagging, categorization, and/or classification of content, and in turn information findability and retrieval. The primary purpose of an ontology is to describe a domain of knowledge, and support of indexing/tagging, categorization, classification, findability, and retrieval can be secondary.
- Tools: Some software supports the creation of only taxonomies, some software is for ontologies, and some software can do both quite well. Additionally, some taxonomy/thesaurus software can support most, if not all, features of ontologies.
Coming at ontologies from taxonomies, the biggest distinguishing feature of ontologies is the semantic nature of the relationships.
In a taxonomy or thesaurus, you may have generic relationships, such as:
Automobile industry RT (related term) Cars, and
Cars RT (related term) Automobile industry
Ford Motor Company NT (narrower term) Lincoln Division, and
Lincoln Division BT (broader term) Ford Motor Company
In an ontology, you may have customized, semantic relationships, such as:
Automobile industry MAN (manufactures) Cars, and
Cars IND (manufactured by the industry) Automobile industry
Ford Motor Company SUB (has subsidiary or division) Lincoln Division, and
Lincoln Division PAR (has parent) Ford Motor Company
If you can customize the relationships, does this change a taxonomy into a ontology? No. Customized relationships are just one feature of an ontology, although perhaps the most important feature. In my online course on taxonomies, although I don’t teach how to create ontologies, I do provide a lesson on customized/semantic relationships. It is often desirable to create a more complex taxonomy without necessarily meeting all the requirements of an ontology.
Furthermore, a customized relationship might not be fully semantic. In the example above, the second set of relationships are customized, because they are designated by the ontologist for the particular case. The relationships are also “semantic” because they contain specific meaning. (Semantic means “has meaning.”) It is possible to customize relationships while still not making them fully semantic. You may decide to simply rename the standard relationships for your particular application and audience. For example, you might rename broader term (BT)/narrower term (NT) as “parent/child,” or rename Related Term as “see also.” If your taxonomy/thesaurus software is more sophisticated, it will allow you to specify any number of customized relationships, and thus you can add more nuances of meaning.
A key component of truly semantic relationships as expected in ontologies is the ability to create directional relationships that are distinct in each direction, with reciprocity. Most of these semantic relationships will be variants of “related term” (RT), rather than variants of the hierarchical relationship. The generic RT relationship, however, is singularly bidirectional. If you simply customized it by renaming it, it would have to be the same in both directions, such has “has partner.” To create a semantic relationship pair, such as MAN (manufactures) and IND (manufactured by the industry), you need a tool that supports ontological relationships and not just “customized” relationships.
If your tool supports customized relationships but not the ability to create distinct pairs of directional relationships that are associative rather than hierarchical, the results cans still be very useful. You may have a “near ontology” if not a strictly defined ontology. For example, you could rename the singular “related term” (RT) as “Manufacturer-Product” with an abbreviation such as MAN-PRO (Credit to Alice Redmond-Neal of Access Innovations, Inc. for the example). Thus, the relationship is the same in either direction:
Automobile industry MAN-PRO Cars, and
Cars MAN-PRO Automobile industry
It is not completely semantic, with the directional details missing, but this may be good enough for your purposes. After all, it should be obvious which is the manufacturer and which is the product. Therefore, taxonomy/thesaurus software that provides most, if not all, features of an ontology may be sufficient, too.
What matters is serving your needs. Rather than calling it an “ontology” when it does not meet all the definitions of an ontology (and causing confusion or disagreement), it may be safer to say your sophisticated taxonomy “has features of an ontology.”
I think this is a great description and exactly on point from the experience of taxonomies and the field of information management. I also come from the experience of taxonomies and the field of information management so can relate very easily to what you’ve described in your blog post.
I’ve also come across another perspective that I’ve found very interesting. This perspective is really my view, though, through the eyes of professionals whose focus is on implementing ontologies in semantic applications. It is then a perspective once removed, so to speak. So, I welcome comments from anyone, reading your blog, who is doing that type of work directly.
What I’ve found, then, is that from that perspective an ontology seems to be anything that is instantiated in the Web Ontology Language (OWL). While I’m still learning about all the capabilities of OWL, I think the ability to create those customized relationships that your article describes comes through the OWL capability.
I find this perspective intriguing because when I start to look at the world of ontologies from that viewpoint, I begin to see a wide variety of “things” that could be considered ontologies by people from perspectives outside of my own foundational perspective.
OWL can express what looks to me like data models, also Knowledge Organization Structures (KOS) as you describe, as well as a variety of descriptions of knowledge domains for the ability to reason and infer additional knowledge.
Some examples of these that I’ve come across in my “travels” are:
1. VIVO ontology (http://vivoweb.org/) looks more like a “data model”
2. The work that is represented here http://www.w3.org/2001/sw/wiki/SKOS/Datasets as Knowledge Organization Structures that mainly use SKOS as its foundation (From the information management perspective, I’m most familiar with this type of work)
3. And, there is also the work at NCBO Bioportal http://bioportal.bioontology.org/ that seem to have as its focus the ability to create structures for reasoning and inferring of additional knowledge
I think this is just a taste of the possibilities for creation of “things” that could be considered ontologies. While I see where this perspective once-removed that I’ve described can exacerbate any confusion that may exist as to what exactly is an ontology, I am intrigued with looking at ontologies from this perspective because it also open the door to (what I’d call) the “cross-pollination” of ideas from different “worlds” which I think germinates and develops into great possibilities. So, I’d say… Let the fun continue!
-Paula Markes
Speaking as a professional ontologist, a few things to keep in mind about building ontologies, versus building other sorts of data repositories:
Ontologies are MUCH more focused on what happens when you extract the data than how you enter it. Strictly speaking, you can enter whatever sort of semantic relationships you want into your triple store — so long as the RDF is valid, the ontology wouldn't much care, which is a very big difference from your typical relational database system, where data entry is strongly checked for valid forms and content.
Instead, an ontology describes what can be looked at, what connections can be made when you query the data stored inside, in terms of if-then logical connections. "If you've extracted a person, you'll find an associated birthday." You can specify as elaborate a framework of logical connections as you want, and the more elaborate, the more varied the inferences your system will be able to make based on the data you put in that conforms to your ontology's properties.
Additionally, OWL and ontological modeling can be thought of as "object-oriented semantic webs", I find. Your basic semantic relationship is "Subject – property – object", and RDF allows you to put whatever subjects, properties and objects you want in that three-part syntax that you like.
What ontologies try to do is create classes of things — if X is of a given type of subject, it will have these given properties in relation to those given objects. I'd highly recommend anyone interested in working as an ontologist to check out a book or two on declarative logic as a primer for this sort of thinking.
One beef (or quibble, depending on your perspective): In distinguishing players in the MAN-PRO relationship, you say " it should be obvious which is the manufacturer and which is the product." Obvious to who? This one is only obvious if you already have a lot of a priori knowledge. Imagine the same problem for a more obscure field or in a situation where the entities are similar (e.g. corporation_A ACQUIRES / IS_ACQUIRED_BY corporation_B versus corporation_A MERGES_WITH corporation_B). More to the point, try asking a computer! The point of ontology is often to allow a computer to infer, validate, or classify some information. With only symmetrical relations, inference is severely limited.