Data currency is monetary value assigned to data to identify its
financial significance to an organization. Once the monetary value of data assets is identified, it may be used as the unit of exchange in a transaction, either as the sole payment or in combination with money.
Direct financial models of data monetization include:
• Identifying the cost of replacing data in the event of its loss.
• Identifying the amount that data contributes to an organization’s revenue.
• Identifying what the data could generate if sold.
For Attribute data, Data Currency and Data Consistency are very
important concepts. When you’ve finished reading this post you’ll
understand that you can’t just pick up an old dataset and blindly
believe that it will meet your needs.
Out-of-date data might be pivotal to your project if you’re interested
in analysing something from a long time ago. It can also be a major
problem for your GIS project.
Let’s think for a moment about Google Maps because data currency is
particularly important to it. Do you think people would want to use
Google maps to find businesses and places if the information that
google returned was out-of-date?
For example, if a restaurant search returned a business that had
closed 4 or 5 years ago, or a menu that was equally out of date. Data
currency is critical to Google Maps. Although some of their
information is incorrect, google does a pretty good job of trying to
keep the information current.
Data Currency also relates to common GIS tasks such as Land Use
mapping. An out-of-date map might show a cadastral block as being in
an industrial zone, where in fact, in the last few years, the zone may
have changed to be residential. It’s sometimes important to know
whether a residential area was once industrial, what sort of
industries were there, and previous ownership – especially where
environmental contamination issues are at stake.
Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof.
Many government databases are in poor standing because they’ve not
resolved the data consistency issue. The idea behind data consistency
is that you need to describe your data in a consistent way. For
example, I was dealing with a Swimming Pool project for my state
government some years back. The database I was using was from the
Building Inspector’s department. A database search for “Pool” produced
dwellings with “Swimming Pools”, “Pools”, “Pool Fences”, “Pool
Tables”, and a number of other variations. The Department had no
consistent way of describing anything in their database, meaning that
it was near-useless for the project purpose.
Another example would be a search in a restaurant database for a
Cantonese restaurant. Unless somebody is going to specifically be
searching for a Cantonese Restaurant, its probably better to have it
described as a Chinese Restaurant. Another mistake that’s commonly
made in restaurant databases is to call a “restaurant” a “café”, to
mis-spell it to be a “restrant”, or to abbreviate it somehow. If you
have a consistent way of spelling and representing the same sort of
thing in your database, that database is going to be far more powerful
than it otherwise would have been.
Information Brought To You By Biovolt Corporation.