But in my opinion, the quality of the data must always be defined with respect to a context. I have seen applications that were designed to do specific things when a country code field had a given value, say ’33′ instead of ‘FR’. If we wanted to use the good value ‘FR’. The application could not work correctly anymore.
In this very particular case, a good data quality was not usable. Bad data was mandatory !!

I agree that for this case, the application should have been changed, but the impacts were so important that they renounced to do it.

Of course, a good data here is ‘FR’ as it is a well defined standard ISO code, but data are used by applications and when the applications are not well designed, the meaning of data quality must take into account the context of the application.

I have a fundamental problem with definitions of data quality which move the quality measurement away from the data itself (in this case, to its intended use) and away from the fact that data has inherent quality, regardless of what it is intended for.

Imagine, I call a company to order some goods, and they take my details. The intended use of the data is to send me the goods (and that they arrive). When the goods arrive, my name is spelt wrong, the street name is incorrect, the city name has a typo, the postal code is incorrectly formatted. In fact, it was only delivered because the house number was correct and the postal code was legible.

As the goods were delivered, the conclusion must be that the data has quality.

I disagree.

Clearly data fulfils use(s), but it has, or fails to have, inherent quality, regardless of those uses.