Putting information into context

I've got a topic I want to discuss today - providing context to data - but I haven't found the appropriate metaphor for it.  It seems to me that data in the abstract is like a newborn baby - interesting, helpless but full of potential.  It also seems to me that data is like a seed - useless without the soil, water and sunlight to help it sprout.

I was thinking about this when watching two colleagues of mine introduce themselves.  They happened to know each other through one colleague's husband.  So the spouse of the person they both know says "I'm so and so's wife" and the other colleague says "I know so and so through my former boss" and the discussion continued until they put their nascent relationship into context with the people, places and experiences both had had.  What this process does is to help the individuals decide very quickly whether or not the new colleague is trustworthy, reliable and capable. 

We don't take the same approach to data or information, but it's probably even more important to provide context to our data.  About the best most of us do when we create a new document is to try to give the data a descriptive name.  My desktop is loaded with files called "Sales and Marketing projection - February 2005" or something similar.  This is a poor first step towards creating actual context for the data and helping other people find, understand and use the data or information I've created.

It seems to me we should create file storage systems with a lot of context about the data, and the context should not be optional.  When you save a new file, the system should ask you:

- What's the data for?  a temporary analysis or something we'll need long term
- What's the data about?  a marketing project or a term paper for your graduate degree
- Who created the data?  you, a team of people, a vendor or someone else
- How long should we consider this data valid?  a week, a month, forever in the case of the recipe
     for Coke
- Who should have access to this data?
- How should this data be used?
- Is this data fact or conjecture?

This isn't a complete list - I can't define the entire list because to a certain extent each firm should shape how they capture the context of the data they create, because there are unique characteristics about information that may be specific to industries or other segments of businesses. 

Putting our information into context so others can find it and use it means we are leveraging our internal knowledge and corporate assets more completely and are becoming more productive in using and sharing our resources.

Comments

[Bert]

Absolutely! Much of the data that I receive is entitled "End-of-Grade 04-05" and "CRT's 1Q" with no regard to context (Yes, I'm in education administration). Routinely, when I save the file in my computer, I rename the file with relevant contextual key words. The name looks extremely strange "eog 04-05 disaggregated draft confidential..." I standardize the naming structure as much as possible but it still allows me to add context information in addition to the standard keywords. A quick keyword search yields my document and the name provides the contextual information that I need without re-analyzing it. The problem, as you state, is that this is not the case system-wide, therefore, the only one who benefits from this is me.

[T]

Funny you should mention this. My company has been discussing building a product for internal use for months now. However we are not looking to store documents, but code we use in our applications.

We use repositories and document at every stage of development, but we still need a way to store meta-data about our code (whether it be a module, snippet, application) that could be used over. When someone doesn't know how to implement something in PHP but our company has already implemented the functionality in C++, the PHP developer could find the code in C++ and review how to implement the functionality.

Too much time is wasted in researching or recreating information that has already been implemented.