Bursting Your Filter Bubble

Apr 24, 2013 by Jim Harris

In a previous post about data visualization, I discussed how our expectations can distort the data we visualize a lot more than we may realize, causing us to mistake dashboards for magic mirrors reflecting back our own image of what we want our data to show us.

Do the Eyes Have It?

Feb 27, 2013 by Jim Harris

In my previous post, I looked into the magic mirrors of business leaders, more commonly called dashboards, as one example of how data visualization is used.  In this post, I want to look at what we use to look — our eyes — and how they process whatever data we visualize.

Mirror, Mirror on the Data

Feb 20, 2013 by Jim Harris

As Beth Schultz recently blogged, Data Visualizations Beg Your Attention.  And as Noreen Seebacher recently blogged, A Picture Explains a Lot of Data.

Although I agree with both concepts, and I recommend reading more than just the titles of those posts, I couldn’t help but wonder if what should be begging more of our attention is…

Harmonizing Hard-Coded Metadata

Apr 24, 2012 by David Loshin

I have been exploring the issue of the discrepancy between presumption of logical naming for data elements and their corresponding uses in application code, and the potential dependencies (and eventual data failures) that can erupt when reference data values are hard coded into application code. The problem can’t be solved by globally searching out uses of the data element and changing its name, because the embedded dependencies will still exist.

Hard-Coded Metadata

Apr 17, 2012 by David Loshin

Data attributed that have misleading names are like ticking time bombs awaiting the wrong scenario. While we were considering ideas for mitigating an existing issues related to data attributes with names that did not correctly describe the values the attribute held, one of my colleagues noted that the problem was much more insidious than bad naming. Changing the attributes’ named would not work, since apparently there were numerous applications that had been designed based on those same mistaken assumptions.

Big MetaData

Apr 12, 2012 by Phil Simon

Two years ago, I never even heard of Big Data. These days, it seems like I hear the term every day (although, admittedly, my antennae are now pretty attuned to that very phrase. It’s very much like platforms, but I digress.)

My, how times have changed.

The Impact of Data Element Renaming…

Apr 10, 2012 by David Loshin

In my last post, we came across what is probably a common problem: data attributes have names that don’t accurately reflect what those attributes store. So why can’t we just modify the name of the attribute to something that makes more sense? The gut-reaction answer is that there are multiple impacts that are not immediately known. The data attribute may be used in many different applications. Changing the name of the attribute is going to make all those application fail, so duh, that would not make sense.

Data and the Liar’s Paradox

Apr 04, 2012 by Jim Harris

“This statement is a lie.”

That is an example of what is known in philosophy and logic as the Liar’s Paradox because if “this statement is a lie” is true, then the statement is false, which would in turn mean that it’s actually true, but this would mean that it’s false, and so on in an infinite, and paradoxical, loop of simultaneous truth and falsehood.

The Perils of Bad Names

Apr 03, 2012 by David Loshin

I was recently working on a customer engagement in which a profile of a process’s data set led to the identification of some potential anomalies. These potential issues were related to the use of data values based on the names of the attributes, and what those names presumably meant. However, after some investigation, my direct contact at the customer was made aware that even though the column names implied aspects about how the data values were used, in fact those attributes were not used that way at all, and no one should make any assumptions about the underlying semantics or usage scenarios for the data.