“I have been so long master that I would be master still, or at least that none other should be master of me.” – Bram Stoker, Dracula

In preparation for my presentation, “What’s the Scenario? Defining Boundaries and Intersections for Taxonomies, Reference Data, and Master Data” at Taxonomy Boot Camp on November 16th, I’m going to dive into some of the fundamentals of taxonomies, reference data, and master data management here. Although these concepts are well-defined in the semantic industry, in practice there is often confusion about where data should live, in what form, and who owns it. Can there be more than one source of truth, and, if so, how is this governed in increasingly complex technical architectures?

Let’s start by defining reference data, taxonomies, and master data management and then draw some boundaries between the disciplines and the systems that support them.

Reference Data

Reference data is “data used to classify or categorize other data. Typically, they are static or slowly changing over time” (Wikipedia). Wikipedia goes on to provide examples of reference data, including units of measurement and corporate codes. In my experience, some common reference data needed for classifying content and data are countries and languages, either by full name, by standard ISO codes like 639 and 3166, or a combination of both.

Reference data is typically managed within the organization, but there are many opportunities to source reference data externally, particularly when attempting to make data more interoperable through the reuse of standardized data sets. As already cited, ISO 639 and ISO 3166 offer standardized codes for languages and countries respectively. Rather than invent new lists of country names, language names, and alphanumeric codes to represent them, it saves time and supports interoperability by simply using an existing standard. How and where these standard concepts and codes are stored and implemented will depend on the organization’s use cases. More on that in a bit.

An important characteristic of reference data, as noted in the Wikipedia article, is that it is “static or slowly changing over time.” Characterizing data in this way helps to inform how we handle it and where. Continuing the same example, new or changes to existing languages and countries do occur, but they are not frequent. The last new country was South Sudan, declaring independence in 2011, and the latest country name change was from Nauru; Republic of Nauru to Naoero; Republic of Naoero. Arguably, the most recent language to be recognized as distinct is Light Warlpiri, developing in the 1980s.

Taxonomy

“Taxonomy is a practice and science concerned with classification or categorization. Typically, there are two parts to it: the development of an underlying scheme of classes (a taxonomy) and the allocation of things to the classes (classification)” (Wikipedia). Strictly speaking, taxonomies are hierarchical structures typically organized in parent-child relationships (broader/narrower) based on categories of inclusion based on the “is-ness” of the concept. “Taxonomy” has really come to be a blanket term for lists and thesauri as well, probably because the strict edges between flat lists, taxonomies, thesauri, and ontology functionality are more or less erased in commercial taxonomy and ontology management systems.

By the definition above, many values in taxonomies are reference data because the values are used to classify or categorize other data. There are also values used strictly for navigational values and other use cases, but a significant use case for taxonomies is as metadata applied to content and data.

In the modern organization, taxonomies can be housed in dedicated taxonomy and ontology management systems backed by a triplestore, a purpose-built database based on the RDF standard. These systems are designed to handle hierarchies, attributes on concepts, and the relationships between them. They are flexible, scalable schemas, making them an excellent, standards-based choice for centralized taxonomy management and delivery. Their ability to model and manage semantic models, however, can be problematic for downstream consuming systems which can not always handle semantic formats, or possibly even hierarchies of any number of levels.

Taxonomy management, ideally, is a defined practice in the organization, with taxonomists, a dedicated taxonomy management system, and the ability to build and deliver taxonomies to multiple systems for numerous use cases.

Master Data Management (MDM)

Master data “represents ‘data about the business entities that provide context for business transactions’. The most commonly found categories of master data are parties (individuals and organisations, and their roles, such as customers, suppliers, employees), products, financial structures (such as ledgers and cost centres) and locational concepts” (Wikipedia). Wikipedia goes on to differentiate between master data and reference data in that “both provide context for business transactions, reference data is concerned with classification and categorisation, while master data is concerned with business entities.”

Master data can include concepts which are not useful or easily managed in taxonomies. While it is possible, for example, to define “customer” in a taxonomy, a master data management system allows one to define customer, map it to all of the various occurrences of “customer” in table headings, rows, and columns, and find similar entities as part of the mapping. Additionally, master data can include calculated values like “gross revenue” and other business concepts. Because of the slightly different nature of the data, it is best managed in MDM and not in taxonomies.

One area the two can overlap and agree on where appropriate is the definitions of common terms. Some concepts that are managed as master data, especially those that are in the business glossary, will likely wind up in taxonomies and vice versa. Ensuring that the concept form and its definition are the same in both systems can aid in business agreement.

Mixing and Matching

Reference data often becomes a part of the master data for several reasons. First, not every organization practices taxonomy management as part of a taxonomy program and taxonomies are not always housed in dedicated taxonomy management systems. Therefore, reference data resides in master data systems with other important data. Second, not every downstream consuming system can take in triplestore data in its native graph format. Taxonomies and ontologies then are ingested into MDM systems to become relational tables for consumption. These taxonomy data products may be shared in whole or in part and their canonical values mapped to other data in the MDM. Finally, the kinds of business rules used to govern data as part of a larger data governance program may only live in the MDM system. As part of the larger data ecosystem, taxonomies are also part of the governed data living in the MDM.

With the potential for overlap, who owns which data and where is it managed? Taxonomies are a natural location for reference data since they are primarily used to classify and categorize other data and content. That said, the ability to mix and match taxonomy data with other types of stored entities and data, like customer sales data, is an important business function. It is possible to use some governing principles which can help determine where data should live and who owns it.

Taxonomies (and ontologies) are the right choice for

• Reference data that can include preferred labels, alternative labels, and property attributes,
• Concepts that can be associated or mapped by relationships with other concepts in triples,
• Concepts that don’t change frequently, and
• Data that does not need high levels of security, like personally identifiable information about customers or employees.

Master data management systems are the right choice for

• Sensitive and personally identifiable information (PII) (or at least the business entities that refer to this data living elsewhere),
• Product data,
• Customer and vendor data, including names and addresses,
• Employee data,
• Location data, and
• Mapping core business entities across systems.

Some of these, like some product data and location data, could feasibly live in either system, so how do you decide which lives where so important reference data like geographical names are not duplicated? It’s not always a matter of what kind of data it is, but the use case the data is being used to solve. Taxonomy management systems typically include ontology management functionality, allowing standards-based SKOS taxonomies to include custom relationships and properties and map preferred labels to alternative labels (synonyms, acronyms, localized variants, etc.) Therefore, creating rich semantic models linking products to geographical locations to content types to organizational team names is a prime use case. While these mappings can also be done in MDM, standards-based semantic models are flexible and scalable, so modeling is typically more resilient to change.

As mentioned above, not every system can easily ingest triples and properties, so much of the semantic richness of a robust knowledge model is lost. Translating these values into relational tables in an MDM system can make the data more accessible to downstream systems. Of course, using a taxonomy management system and an MDM in tandem requires strong governance policies so that the systems can stay synchronized as sources of truth with no variance.

Governing Source(s) of Truth

If a taxonomy management system is a source of truth for taxonomy values, including preferred labels, alternative labels, properties (attributes), and the defined relationships between them, then what happens when this source of truth data is essentially duplicated in a master data management system?

Taxonomies can be ingested into MDM systems and their preferred labels, alternative labels, URIs (unique identifiers), and, if needed, definitions and scope notes can be stored as relational tables. Because URIs are immutable, they will always identify the concept and its alternative labels no matter what changes happen to those labels in the taxonomy management system. Thus, any changes or mappings in the MDM will always be traceable back to the original concept. Whether downstream systems connect directly to the taxonomy management system or the MDM for canonical taxonomy values, the concepts are resolvable through their URIs.

Taxonomy and MDM as fully realized programs as part of a larger data governance practice should work closely and in tandem to deliver clean, canonical source of truth data for use in systems across the organization, including data warehouses and data lakes. Values can be added to taxonomies and MDM systems through carefully managed governance processes including change requests and communications between system owners.

While different in definition and scope, taxonomies, reference data, and MDM all have a place in the organization and should work together to manage and deliver clean datasets for all kinds of use cases, particularly in a world of artificial intelligence requiring well-defined source of truth data.