Yesterday's thinking, Today's Technology and Tomorrow's Problems
I think we're getting really close to a very interesting convergence of two very different forces that's going to be the catalyst for the next big thing.
Force one: Yesterday's thinking is failing to give us the ability to build solutions today that help us solve tomorrow's problems. Need proof? We still don't have a ubiquitous way to relate knowledge with machine processable annotations. Yes, I really do believe there is a relational algebra for knowledge, but I'm not seeing good methods evolving for the machine processing of that. But that's really what we need to cope with the InfoGlut.
What exactly do I mean? Let's take the simplest of business problems: assigning somebody to do a task. Building a database to track that who assigned who to do what is easy. Tracking the status of the task is always easy. Documenting what that task was needed, why it was assigned to one person and why the person that assigned to them is not. However, if you're interested in building systems that aggregate that kind of knowledge -- for whatever reason -- into something as simple as reading a document, you need processable linkage data. Theres just no simple way to build such a thing today.
Force two: XML and its related technologies are spurring creativity. Its been interesting to me to see how XML has grown from being another medium for the transmission of information (either in bulk or as messages) to a serialization of meaning. The first time this really caught my eye was when I started reading Norm Walsh's DocBook book. No, he never says that XML is the perfect format for the serialization of knowledge. It isn't. But its better, I think, than our current alternatives because of communicability and potential semantic richness. DocBook lead to readings on XSL-FO, which beget an interest in using Reporting Services as knowledge analysis tool. A few failed experiences with that taught me what seems like a really valuable lesson: The simpler you make a relation, the more relations you need to make something mesh fully in such a use case. The more relations you have, the less a human can fully process them. That's when you need a query processor and a query language.
That's more or less the whole reason why I think XQuery is important. Its those things. Obviously, though, its not all you need. You need ontologies to translate the “fuzziness“ of human understanding into processable factors. And that's the hard thing to achieve with yesterday's thinking and today's technology. I don't know we have anything in our toolkits for making building effective ontologies possible for “Knowledge Management Morts.“
Still, I get really exciting when I see something like this article on MSDN that talks about transforming Word XML into XSL-FO as pointed out by John Durant. It give me hope that were going the right direction toward that goal.
So what happens when these two forces collide? Big things. Really big things. Need proof? Go listen to James Burke talk about the Knowledge Web.
That's the real Web, and its real future of the browser.
Feel free to discuss.