Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

Modern Data Integration Paradigms by Matthew D. Sarrel, The Bloor Group.

Introduction:

Businesses of all sizes and industries are rapidly transforming to make smarter, data-driven decisions. To accomplish this transformation to digital business , organizations are capturing, storing, and analyzing massive amounts of structured, semi-structured, and unstructured data from a large variety of sources. The rapid explosion in data types and data volume has left many IT and data science/business analyst leaders reeling.

Digital transformation requires a radical shift in how a business marries technology and processes. This isn’t merely improving existing processes, but
rather redesigning them from the ground up and tightly integrating technology. The end result can be a powerful combination of greater efficiency, insight and scale that may even lead to disrupting existing markets. The shift towards reliance on data-driven decisions requires coupling digital information with powerful analytics and business intelligence tools in order to yield well-informed reasoning and business decisions. The greatest value of this data can be realized when it is analyzed rapidly to provide timely business insights. Any process can only be as timely as the underlying technology allows it to be.

Even data produced on a daily basis can exceed the capacity and capabilities of many pre-existing database management systems. This data can be structured or unstructured, static or streaming, and can undergo rapid, often unanticipated, change. It may require real-time or near-real-time transformation to be read into business intelligence (BI) systems. For these reasons, data integration platforms must be flexible and extensible to accommodate business’s types and usage patterns of the data.

There’s the usual homage to the benefits of data integration:

…
IT leaders should therefore try to integrate data across systems in a way that exposes them using standard and commonly implemented technologies such as SQL and REST. Integrating data, exposing it to applications, analytics and reporting improves productivity, simplifies maintenance, and decreases the amount of time and effort required to make data-driven decisions.
…

The paper covers, lightly, Operational Data Store (ODS) / Enterprise Data Hub (EDH), Enterprise Data Warehouse (EDW), Logical Data Warehouse (LDW), and Data Lake as data integration options.

Having found existing systems deficient in one or more ways, the report goes on to recommend replacement with Voracity.

To be fair, as described, all four systems plus Voracity are all deficient in the same way. The hard part of data integration, the rub that lies at the heart of the task, is passed over as ETL.

Efficient and correct ETL performance requires knowledge of what column headers, for instance, identify. For instance, from the Enron spreadsheets, can you specify the transformation of the data in the following columns? “A, B, C, D, E, F…” from andrea_ring_15_IFERCnov.xlsx, or “A, B, C, D, E,…” from andy_zipper__129__Success-TradeLog.xlsx?

With enough effort, no doubt you could go through speadsheets of interest and create a mapping sufficient to transform data of interest, but where are you going to write down the facts you established for each column that underlie your transformation?

In topic maps, we may the mistake of mystifying the facts for each column by claiming to talk about subject identity, which has heavy ontological overtones.

What we should have said was we wanted to talk about where do we write down subject identifications?

Thus:

1. What do you want to talk about?
2. Data in column F in andrea_ring_15_IFERCnov.xlsx
3. Do you want to talk about each entry separately?
4. What subject is each entry? (date written month/day (no year))
5. What calendar system was used for the date?
6. Who created that date entry? (If want to talk about them as well, create a separate topic and an association to the spreadsheet.)
7. The date is the date of … ?
8. Conversion rules for dates in column F, such as supplying year.
9. Merging rules for #2? (date comparison)
10. Do you want relationship between #2 and the other data in each row? (more associations)

With simple questions, we have documented column F of a particular spreadsheet for any present or future ETL operation. No magic, no logical conundrums, no special query language, just asking what an author or ETL specialist knew but didn’t write down.

There are subtlties such as distinguishing between subject identifiers (identifies a subject, like a wiki page) and subject locators (points to the subject we want to talk about, like a particular spreadsheet) but identifying what you want to talk about (subject identifications and where to write them down) is more familiar than our prior obscurities.

Once those identifications are written down, you can search those identifications to discover the same subjects identified differently or with properties in one identification and not another. Think of it as capturing the human knowledge that resides in the brains of your staff and ETL experts.

The ETL assumed by Bloor Group should be written: ETLD – Extract, Transform, Load, Dump (knowledge). That seems remarkably inefficient and costly to me. You?

This isn’t a new idea, but it occurred to me that introducing readers to “dimensions of subject identification” might be an easier on ramp for topic maps. It enables us to dodge the sticky issues of “identity,” in favor of asking what do you want to talk about? and how many do you want/need to identify it?

To start with a classic example, if we only have one dimension and the string “Paris,” ambiguity is destined to follow.

If we add a country dimension, now having two dimensions, “Paris” + “France” can be distinguished from all other uses of “Paris” with the string + country dimension.

The string + country dimension fares less well for “Paris” + country = “United States:”

• Paris, Arkansas, a city
• Paris, Idaho, a city
• Paris, Illinois, a city
• Paris, Indiana, an unincorporated community
• Paris, Iowa, an unincorporated community
• Paris, Kentucky, a city
• Paris, Maine, a town
• Paris, an unincorporated community in Green Charter Township, Michigan
• Paris, Mississippi, an unincorporated community
• Paris, Missouri, a city
• Paris, New Hampshire, an unincorporated community
• Paris, New York, a town
• Paris, Portage County, Ohio, an unincorporated community
• Paris, Stark County, Ohio, an unincorporated community
• Paris, Oregon, an unincorporated community
• Paris, Pennsylvania, a census-designated place
• Paris, Tennessee, a city
• Paris, Texas, a city
• Paris, Virginia, an unincorporated community
• Paris, Wisconsin (disambiguation), several Wisconsin localities
• Paris Township (disambiguation), several US localities
• Beresford, South Dakota, a city formerly called Paris
• Loraine, California, an unincorporated community formerly called Paris
• Paris Mountain, South Carolina – see Paris Mountain State Park
• Paris Mountain, Virginia

For the United States you need “Paris” + country + state dimensions, at a minimum, but that leaves you with two instances of Paris in Ohio.

One advantage of speaking of “dimensions of subject identification” is that we can order systems of subject identification by the number of dimensions they offer. Not to mention examining the consequences of the choices of dimensions.

One dimensional systems, that is a solitary string, "Paris," as we said above, leave users with no means to distinguish one use from another. They are useful and common in CSV files or database tables, but risk ambiguity and being difficult to communicate accurately to others.

Two dimensional systems, that is city = "Paris," enables users to distinguish usages other than for city, but as you can see from the Paris example in the U.S., that may not be sufficient.

Moreover, city itself may be a subject identified by multiple dimensions, as different governmental bodies define “city” differently.

Just as some information systems only use one dimensional strings for headers, other information systems may use one dimensional strings for the subject city in city = "Paris." But all systems can capture multiple dimensions of identification for any subjects, separate from those systems.

Perhaps the most useful aspect of dimensions of identification is enabling user to ask their information architects what dimensions and their values serve to identify subjects in information systems.

Such as the headers in database tables or spreadsheets. 😉

I mentioned yesterday that creating a public interchangeable identifier isn’t as easy as identifying identifier and documenting them publicly. Recognizing an Interchangeable Identifier

What if I identified (by some means) “Patrick” as an identifier and posted it to my website (public documentation).

Is that now a “public interchangeable identifier?”

No. Why?

First, there has to be some agreed upon means to declare an identifier to be an identifier. When I say agreed upon, it need not be something as formal as a standard but it has to be recognized by a community of users.

Second, it is important to know in what context this is an identifier? Akin to what we talk about as “scope” in topic maps. But with the recognition that the notion of “unconstrained” scope is a pernicious fiction. Scope may be unspecified but it is never unconstrained.

I would argue that no identifier exists without some defined scope. It may not be known or specified but the essence of an identifier, that it identifies some subject, exists only within some scope.

More on means to declare identifiers and their context anon.