"How would you store thirty years'-worth of experience in a database?"
[quote from a senior research scientist at one of our clients]
Knowledge is more than informationThat sounds obvious, perhaps, but the implications aren't - especially where knowledge-management is concerned. One of our regular clients has a significant knowledge-management issue: they're an aircraft-engineering research group, and much of their knowledge-base has a data-life of fifty years or more. That may not seem that long a time - given that the products of some civil-engineering projects may have to last for centuries - but it's actually almost as long as the entire history of commercial computing. And there've been a few changes in that time...
In practice, the knowledge-base needs to be stored, expanded, protected and retrieved over a period which is longer than any of the usual measures:
This isn't a computing issue as such: a common mistake! (In fact most of their legacy data was on paper: a lot easier to maintain than computer-stored information, though much, much harder to search...) Current knowledge-management systems obviously depend in part on database technology to provide storage, search and cross-reference, access-control, and usage and performance metrics. But knowledge-management depends just as much on:
At xio we believe that knowledge-management works best as an extension of the organisation's quality-system:
For knowledge-sharing to happen within an organisation, knowledge acquired in each team's work needs to be linked with the organisational knowledge-management system - which often doesn't exist! So knowledge-management is a fundamental systems-level issue, relying on the human aspects of the system as much as on technical matters.
Data-contentAll of these depend on understanding of the overall data-content - an understanding of what knowledge actually is. In practice, the data-content of knowledge may be partitioned into three categories:
Conventionally, only objective data is maintained in databases - partly because it is the easiest type of data to manage. In recent times there's been an increasing awareness, in the scientific community and elsewhere, of the importance of maintaining metadata, particularly for traceability and quality-management; but at present there still appears to be only a poor awareness of the importance or value of maintaining subjective data - particularly subjective associations between data-items. Although objective data are often strongly emphasised in scientific and commercial knowledge-management, and are often mistakenly considered to be the only valid part of the overall data, in essence they only provide source-material for subjective interpretation of meaning:
objective data are meaningless without metadata to provide context, and without subjective data to provide interpretation.
This is especially true in long-term knowledge-management, where dependence on human memory to 'fill in the gaps' becomes increasingly unreliable over time, and by definition unavailable for the kind of data-lifetimes required by this client of ours - and many others.
A real knowledge-management system needs to be able to provide appropriate support for all three data-categories, and maintain appropriate distinctions and separations between data-categories whilst also maintaining the contextual links between them. None of the commercial 'knowledge-management systems' we've seen as yet actually manage to do this - especially the proper long-term management of connections. But it should happen fairly soon: the technology already exists in XML/XLL (eXtensible Markup Language/Link Language), for example. What's often harder is finding the commitment - especially in senior management - to actually doing it...!
Data-safetyShort-term data-safety is mainly concerned with keeping appropriate control over users' access to functionality - ensuring that records can't be created or changed inadvertently or inappropriately, for example. Data-safety over longer periods - for the full required data-lifetime - depends less on control of access to function, and more on appropriate design and management of data structure:
Appropriate standards for data-content and structure (at least in transfer forms for data-sharing and data-migration) include the Australian National Library and Dublin Core standards on metadata, and the NCSA and XML standards for data-structure and formatting of transferred data content. In this sense, an XML file would be close to fully 'self-describing', especially if it contained (rather than referenced) the respective Document Type Description (DTD).
Data-migrationOver the full required data-lifetime, physical and logical systems will inevitably need replacement. Appropriate plans and procedures - the human side of systems - need to be in place to support migration of data from older systems to their replacements. This includes:
The importance of clear requirementsThe general experience is that trying to implement a knowledge-management system in one go is a bad idea:
So in practice, implementation of a full knowledge-management should always be iterative - often over several years. And at xio we advise our clients that before trying to implement any of the system, it's essential to be clear about what the system is expected to achieve, both overall and at each iteration. Clearly-defined requirements provide a means to measure progress; and prioritised requirements maximise leverage and 'return on investment' at each stage. Requirements which are relevant to knowledge-sharing would include:
Data-sharingIn planning for knowledge-sharing, it's useful to ask:
A kind of conclusion...So to come back to that question with which we started this item in the toolkit: how could we store thirty years of experience in a database, in a way that others could use?
- by making it easy to do so, for everyone, every day.
- by providing secure database support not just for data, but also for metadata and connections;
- by providing facilities for organisation-wide cross-reference and search.
- by acknowledging our responsibility to the future as well as to the present!
No particular suggestions for resources on this one: one of the most useful that we've found was a set of White Papers by Dataware Corporation, sadly no longer available since their takeover by LiveQuest Corporation.