Tag Archives: Metadata
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.
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.
Feb 20, 2013 by Jim Harris
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…
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.
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.
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.
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.
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.