Mare Nostrum

Knowledge and forgiveness

David Weinberger at KMWorld makes an excellent point about knowledge in a recent column:

Knowing is not something apart from forgiveness. Forgiveness is not merely something we do, external to knowledge. The knowing that matters requires forgiveness as its condition, just as it requires language and other people. This most obvious of facts sounds odd because we have so thoroughly demeaned knowledge by considering it to be mere content. But if it were only content, how could we distinguish the content that is knowledge and the content that is, say, propaganda or a joke? Knowledge is knowledge because it is embedded in a social system. Social systems are composed of humans. Humans are fallible, even when we happen to be right.

Therefore, there is no knowledge without forgiveness.

That might sound like a paragraph from a book on the philosopy of science, but Weinberger has a point that's important for collaboration, basic content services, and enterprise content management--in other words, the entire spectrum of activity around content, from the informal to the formal, from the free-form to the regulated. Every day, we're caught between the two poles of life that Max Weber (pictured to the right) described in "Politics As A Vocation" and "Science As A Vocation." At times, we have to get things done (politics). However, we also have to understand what we're doing, and share that understanding with others (science).

We face obstacles when we move along both paths. Not everyone wants to participate in a project, or think it's a good idea. Politically, we have to win them over. We also have to convince them that our understanding of the pertinent facts (how well our marketing program is working, what are the obstacles in getting our product manufactured at a lower cost, etc.). That step may require an admission that they were wrong in their cherished beliefs. What Weber says about teachers therefore applies to pretty much everyone in this position:

The primary task of a useful teacher is to teach his students to recognize 'inconvenient' facts--I mean facts that are inconvenient for their party opinions. And for every party opinion there are facts that are extremely inconvenient, for my own opinion no less than for others. I believe the teacher accomplishes more than a mere intellectual task if he compels his audience to accustom itself to the existence of such facts. I would be so immodest as even to apply the expression 'moral achievement,' though perhaps this may sound too grandiose for something that should go without saying.

We have to admit what when we're wrong, too. That principle applies whether we're preparing for an important presentation (collaboration) or preparing pharmaceuticals for clinical trials (enterprise content management). A shorter way of saying the same thing is, That's life. The tools you use can make your life easier, or harder. I hope that the ones we build make both politics and science easier.

The metadata-driven view

Mike Straus, product manager extraordinaire, just published his new project (code sample plus documentation) about a metadata-driven view of content in our system. Why is this interesting?

• It exposes the metadata entered for document classes (our term for categories) in a way that's immediately useful. Anyone looking for a particular piece of content, or interested in what's available generally, can benefit from this view.
• It provides a reason for entering the metadata in the first place. If you don't enter the metadata, your work won't appear in this view. If you do a lousy job of entering it
• Customers and partners have already built views like this one. For example, Time Warner built a much more sophisticated version of this view, but the point is essentially the same: let people browse by the metadata.
• The folder structure is increasingly less important than other views on the content. Everyone knows how to navigate files and folders, but this view of the content doesn't fulfill everyone's needs. Looking at a folder full of documents, I don't know who is their intended audience, what there topics might be (other than what the file name suggests), and whether they're really in good enough shape to use. To answer these questions, you need something like the metadata-driven view.
• Customer use cases often demand a metadata-driven view. That's effectively what the institutional repository solution provides, a metadata-driven way of browsing and searching library content. You can take Mike's code as a starting point for exploring the third option discussed in the institutional repository white paper (building this view of our system, instead of integrating us with a separate institutional repository application).
• We're building metadata-driven views for future versions of our product. We're not necessarily building something that functions in exactly the same way that Mike's project does, but there are plenty of other ways to use metadata (and other types of metadata). For example, you might use a metadata-filtering view, in which you click particular standard or custom metadata to narrow the list of files and folders that fit that profile. (Think of the way iTunes lets you filter music by genre, artist, etc.).

Take a look at Mike's project, and let us know what you think.

The big, fuzzy picture

Can someone explain the usefulness of this "Big Picture" view of C|Net content? I always want to know about related stories, but the whole "knowledge map" view seems even harder to figure out than just a list of links. I looked at their example, but the crazy-quilt of graphical connections doesn't seem more useful than just a link that says, "Click me to read more stories about Apple."

The What's Hot view seems slightly more useful. On the down side, it's not relevant to what I'm reading now, and it seems like a self-fulfilling prophecy. I'm sure that the headline, "Cyberbullies scare schoolgirls into stripping online," feeds on itself. (Plus, need I say it? Ewwww...)

Sticky ideas

I often think that the IT business needs to look beyond its borders. There are all kinds of debates in content management and collaboration circles that boil down to relatively simple questions, often asked and answered by people outside our field. For example, IT professionals often worry that important bits of information aren't getting the attention they deserve. For example, Mike Gotta of the Burton Group recently posted on his blog a set of questions about "event stream processing." He does a nice job of linking it to some real-world use cases in the US government around "need to know" versus "right to know." Here's the kind of puzzle that gets under his skin:

Specifically, I'm looking at how attention data and "post" activities act as informal, loosely-coupled signaling methods that, when streamed in a public manner, can be combined with sensor/filter/relay mechanisms to intelligently pull messages and information to other people or situate the information to the right place (e.g., a "my space" created as a honey pot of sorts to house interesting/relevant items).

Meanwhile, elsewhere on the Internet, a recent Scientific American podcast featured an interview with one of the authors of Made To Stick, which tries to explain why certain scientific discoveries get attention, and others don't. We assume that, as soon as someone makes a discovery, it instantly leaps into practice. However, it often takes years, or even decades, for the implications of a discovery to sink in, or for someone to realize its practical implications. For example, the first steam engine wasn't invented by Thomas Newcomen. That honor goes to Hero of Alexandria, an ancient Greek who documented how to drive the rotation of a sphere through the expulsion of steam. More modern inventors toyed with steam engines before Newcomen and Watt convinced people that they were worth putting into mass application.

And that's just one interesting book on the subject of how "to intelligently pull messages and information to other people" that historians of science, psychologists, sociologists, and other researchers have discovered. Maybe it's time for IT to incorporate as more social science into its work?

ECM DOA

Today, I'm at the Gartner Portals, Content, and Collaboration Summit. (Say that three times fast.) Two Gartner analysts, Toby Bell and Kennet Chin, have made a bold statement: ECM is dead.

What does that mean? Well, it's not that there isn't a place for tools to run big, complex web sites, or high-end DM tools. However, enterprise content management has never been able to expand to either involve or control everyone in the organization. In that sense, enterprise content management--CM by and for the enterprise--hasn't succeeded. In fact, it hasn't really ever gotten off the ground.

Well, heck, who am I to argue with that? Basic content services--content management for the masses--doesn't move from the complex to the simple. It moves fromthe very simple to the somewhat more complex. In other words, it's tough for ECM vendors to prine their technology down to become basic content services tools. On the other hand, it's possible to build from the simpler tools--file management, e-mail, chat, etc.--to more complex rules and processes.

I've often half-jokingly called this process "The Stairway to Heaven." (Yes, I am a Zep fan.) The first step is what people do for themselves, or to work easily with their most immediate collaborators. Once you've made people happy with those tools and processes, you can start adding new functionality, restrictions, content, you name it--as long as you don't stray immediately from what people already know and embrace. In other words, you can't go from 0 MPH to ISO 17799 compliance in 6.0 seconds.

There will always be a role for ECM. As a BCS vendor, we still need to co-exist with ECM systems already deployed. However, ECM today looks a lot like ECM several years ago--and that picture isn't likely to change. People still need to manage content--which is why organizations will invest in BCS.

I used to have a pair of model tanks on my desk to make this point. Both were used in WWII; each represented a different design philosophy. The American M4 Sherman was simple and reliable. The German Panzerkampfwagen VI ("Tiger") was powerful, but prone to breakdown, and consumed fuel and spare parts at a furious rate. Which tank would you buy? For most jobs, the Sherman. For a few jobs, the Tiger. That distinction is a lot like the dividing line between BCS and ECM today. (And who won the war?)

Institutional repositories and Xythos

The institutional repository white paper is finally here. (Actually, it's right here.) It's designed to answer the following questions:

• What options exist for using the Xythos server (whatever flavor) and desktop technology in an institutional repository?
• What are the pros and cons of each option?
• Which Xythos features are important for these options?
• Which version of the server--Enterprise Document Manager, Digital Locker, or WebFile Server--best fits each scenario?
• How much customization, if any, might be necessary?

The white paper makes special reference to DSpace, which probably the most popular institutional repository tool. As always, your feedback is cordially invited.

KM 2.0 and Web 2.0

David Weinberger has an interesting article in KMWorld about how knowledge management is following a similar path as the Web:

That's why, in my opinion, KM 2.0 is both a useful phrase and fundamentally different from Web 2.0. KM 2.0 points to Web 2.0-ish phenomena gaining prominence in the KM space: bottom-up, participatory, rapid innovation, more mixing up and mashing up of information. These are all good things, or at least good things to try. But they are truly discontinuous from the paradigmatic versions of KM 1.0, which were all about managing and controlling information environments.

Wow, I couldn't agree more. Blogs, Wikis, photo upload sites, other Web 2.0-ish tools made web publication easier than using some big honkin' web content management system. The same tools, plus a few more, like search, have made made more institutional knowledge available, without making it less manageable.

Shameless self-promotion corner

I recently published this article in Business Integration Journal. It's a good example of why we Xythinians talk so much about "basic content services." Whatever ECM projects might look good on paper, they still have to face IT realities, such as integration requirements. Since you can easily fill up your to-do list with the integration tasks, you're often compelled to scale back your ambitions to something far less ambitious--which, in the long run, might serve your users' needs better.