Taxonomy Mapping Engine in Use

Our team is in Annual Trends Report Mode. Yesterday we published our first of seven Trends Reports tracking Mergers & Acquisitions in the Media and Software Sectors. This report is for the media space. One part of the report is to collect the deals that for this space. We use an auto-population algorithm that fills the lists many times a day. We then use an Industry Map and rules set that maps the categorized deals into a simple flat taxonomy just used for this report. We can then compare sub-segments of the Sector to see which segments are performing better or worse. Note we do this for 7 different reports each with its own Industry Map and rules set. We never have to categorize a deal more than one time. The mapping engine puts the deals into the appropriate bins for that report. Check it out here.

The Pecking Order - Rules Sets for Mapping

Continuing from the last post, let us look at how mapping from one taxonomy to another can be used. I had used the analogy of mapping rules sets as a camera where the rules sets will collapse the multi-dimension taxonomy to a single dimension taxonomy just as a camera takes a three dimensional space and collapses it to a two dimensional image. I also mentioned the the mapping rules in the rules set are prioritized. Going back to our camera, we know the objects in front will block objects in the back of our image. So with our taxonomy camera, mapping rules at the top of the order will override or block rules lower in the order. Now let us look around at how our businesses are run. Most businesses have a sales team. At our business, the sales team are managing directors and they do much more than just sales. Sales teams are given jurisdictions so as to keep them from stepping on each others toes. Depending on what a businesses product is, a business can define these sales jurisdictions by geography or by specialty based on domain knowledge. Taxonomies will not help define geographic sales territories, but if your business defines sales jurisdictions based on what the clients are (as opposed to where they are), you can use Mapping Rules Sets. Our team has defined a simplified taxonomy which describes the different practice groups, and then a mapping rules set that maps from our multi-dimensional taxonomy onto the simplified taxonomy. As anyone might know, the agreed upon rules for defining sales territories can be quite intricate and often contested, and using prioritized rules sets will help to define as broadly or narrowly any businesses sales territories. This pecking order of rules can be used to allocate leads to our sales teams in a consistent and efficient manner.

A One Way Street to Clarity and Simplicity - More on Mapping a taxonomy to a taxonomy

In my last post, I did not elaborate too much on rules sets that contain the logic to map from one space to another. These rules sets are interesting in that usually when you map from a complex multi-dimensional taxonomy space to a simpler domain specific taxonomy space it is a one way mapping. A good way to think of it is to think about how photography works. A camera has a lens that focuses an image of a three dimensional space onto a two dimensional piece of film. Needless to say, there is a loss of information when the camera takes a picture because the resulting image is just a single view of a three dimensional image. Can we recreate the three dimensional space from our two dimensional photo? Not really, though I have seen some software that guess. Nevertheless, we still love photography. I was just looking at my wedding pictures last night, and in a way photography gives us a clearer vision of our shared reality from an authorial viewpoint.Great portraits or landscapes captures a moment and gives it clarity.

Let's get back to our idea of rules sets (our taxonomy camera), and how they map from from a complex multi-dimensional taxonomy space to a simpler domain specific taxonomy space. We develop the simpler taxonomy to give us a perspective of a domain which gives us vision of clarity and simplicity. We use it to give an authorial view of certain business sectors in a way that our more general purpose taxonomy can not do.

For those with a mathematical bent, I can say that our rules sets are prioritized rules and the fact that we have rules with greater priority than other rules makes these rules sets one way, and collapse the information to a simpler view. If we ran our rules sets on companies classified using the complex taxonomy to get the simpler classification, and then ran the rules sets in reverse on the simple taxonomy to get the categorizations in the complex taxonomy, the original complex classification will not be the same as the derived categorizations.

Mapping a taxonomy to a taxonomy

In my last post, I talked about "meta-terms" which mapped a commonly used expressions to nodes in multiple trees. This concept could be taken much further. When our team built our four dimensional taxonomy, our goal was to be able to classify any business, and to find similarities between companies even though traditionally they  would be considered to be operating in different arenas. My favorite example is to look at Intuit which creates financial software for the consumer, and compare it to H.R. Block which provides a financial services for consumers. In the tax arena, they both provide help to people doing their taxes, and compete directly. Our taxonomy categorizes Intuit as a consumer software company for taxes, while H.R. Block is a consumer service company for taxes. As you see these companies overlap on what they do, and who they do it for, but not on how they do it. Interestingly enough, Intuit started offering a professional help service and H.R. Block started offer a software package.

What this brings up is that our taxonomy is complicated. Our team produces reports on Merger and Acquisition activity in a variety of segments (http://mandasoft.com), and each of these business segments like to break down using their own taxonomies specific to their domain. How do we reconcile the need for a taxonomy with nodes that can be used cross multiple domains, while needing to have easy to understand domain specific terms in a given domain?  The way I like to see this problem is that we have a vocabulary that works great when looking at the business world at the 50,000 foot level, but when we get down into trenches, the terms start to look vague and confusing at the lower altitudes. The way we solved this was by building a system to create 50 ft level simple taxonomies for specific domains (e.g. healthcare media and software). We then categorize each business using the 50,000 foot level taxonomy, and we then have rules sets that map from 50,000 ft level taxonomy to the 50 ft level taxonomy. The utility is especially noted when we create multiple domains with their own rules sets  (e.g. healthcare media and software, and  Cloud Computing) and a business which may reside in both domains, only needs to be categorized once at the 50,000 ft level taxonomy. We can create as many domains as we need and not have to reclassify companies as our domain views evolve!