Ontology vs. Taxonomy

Yesterday I started preparing to archive materials, as I’m coming close to the end of another series of projects. Two years of work has yielded 1gig of data. Granted, there is going to be a lot of redundancy as I typically save major versions of work. If I reduce that down, to a quarter, that is still a significant about a data to sift through and categorize.

During the past two decades I’ve become an ontologist / taxonomist by default. Through the natural course of preforming enterprise architecture for my various employers and clients, I had been guided by necessity into learning various aspects of Ontology and Taxonomy. While my employers and clients don’t pay me to be such, it became apparent I needed to develop those skills to accomplish the goals we agreed to during the start of the projects I’ve worked; more effective usage of information and the creation of knowledge.

It sounds like a simple charter, and many would start with implementing technology solutions such as SharePoint. However, the problem with that approach is often that is where the initiative ends, with yet another technology platform change; resulting in the more tools & data, less information syndrome. This is not to say SharePoint is bad, rather it’s a callout to both business leaders and technologist that SharePoint in isolation is not enough. Consider a previous post of mine and ask yourself; has your SharePoint implementation become nothing more than a Web Frontend to a shared drive or possibly just an electronic routing slip for administrate forms?

The next question is to ask yourself is why? The company either had great ideas to use SharePoint to solve some key information management problems or was piloting to see what it could do. Where in the project plans was the plan on how to manage the information? Did this item get lost in the shuffle of implementing the technology? Had it even been considered?

Often as an Architect the deliverables I create are given a condescending smile by development and business alike. Some of the unkind things I’ve heard are pretty pictures but…we have real stuff to do. Having grown up in the Architecture (houses) and Engineering (Aerospace) industries I find it interesting that still today while many I.T. organizations use the Architecture metaphor my mentor John Zachman defined decades ago “Enterprise Architecture” , few still understand the role of engineering and design (those pretty pictures).

Those nice pictures (aka Systems Engineering Diagrams) keep you in line with the bigger picture when you’re in the weeds. Also those diagrams help you isolate and diagnose where issues are instead of poking around with a share stick. So too, Ontology and Taxonomy assists businesses in understanding the bigger picture of where information is or has been created from and what it is and means.

A simple example I often use harkens back to my days working on an ISO standard. I will not board people hear, retelling the story. I save that for torturing those attend one of my presentations. The net of the story is that terms in taxonomy are important; however, equally important is the understanding of what those terms mean. However, a term’s meaning is contextual though not always represented in taxonomy, thus the need to create ontologies also. This is not a role for an I.T. person (system administrator or programmer) it’s a role that only business owners and leaders can perform with I.T. staff supporting the storage and display of such information.

Original post

Leave a Comment

Leave a comment

Leave a Reply