Webinar on MarkLogic Coming Up

In case you weren't able to attend the Webinar, I'll summarize it here. The speaker started by saying that there are three things that any Knowledge Management (KM) system must provide:

1. The ability to capture information,
2. The capability to analyze that captured information, and
3. A way to share the resulting, synthesized information in a collaborate way.

Customers who need a KM system face a lot of challenges in attaining one that satisfies their needs. The first is deciding whether or not they should build their own or buy one from a third-party. In making this decision, they find themselves in a marketplace that doesn't provide them with the technologies they need to successfully insure that the resulting system is useful, timely, relevant, flexible and able to facilitate collaboration and data enrichment.

The primary reason the landscape of KM systems is lacking, according to the MarkLogic presenter, is because today's technology doesn't optimally allow users of these systems to do the one thing they need them for: to get answers to their questions. In order to provide users with the answers they seek, most modern KM systems use one of two approaches:

1. Crawl relevant data sources using a search engine or
2. Store the information from various sources in a relational database.

The problem with the search engine approach are threefold:

1. Search engines are geared toward finding the location of information and are not usually able to find the exact piece of datum that addresses the user's search;
2. Crawlers are not always able to index all relevant data sources; and
3. There may be a time before the information has been indexed by the crawler during which information can't be located.

The problem with using RDBM systems (or KM products based on them) is that they are often too rigid. They require a static schema that doesn't allow for the level of flexibility that is being demanded. Plus, systems that use an RDBMS often require a search engine as well to search and aggregate data sources in external documents. This combination is often inflexible and slow (e.g., in the case of the Congressional Quarterly which worked around this limitation by moving to MarkLogic's native XML database).

The proposed solution to overcome these technological shortcomings is to buy or build a KM system that uses a native XML database, like MarkLogic Server, at its core. The reason that such a technology can help in coping with the challenges mentioned above is because XML inherently supports a wide arrange of schemas. Knowledge comes in many formats including user manuals, emails, documents, reports, Web pages, images, diagrams, tables, etc. A KM system is better able to support all of these documents types with their different content formatting if it uses a native XML database under the covers, the speaker asserted. Furthermore, an XML-based approach allows metadata, format, structure, semantic information, analytic capabilities (e.g., relationships and facts), annotations (i.e., interactively), and visualization of information in ways not possible with alternative technologies. Thus, the information is augmented and enriched, leading to enhanced navigation, simpler searches, and other benefits including:

• Increased agility;
• Centralized knowledge store; and
• Helps pin point content at various levels in the source document (e.g., chapter-, paragraph-, section-level).

Another primary benefit of using a MarkLogic Server is that it provides the capability to quickly expose information stored within it via Web services. It does this by exposing XQuery applications over HTTP that perform CRUD operations on the information with the server's content store. The result is a very simple and easy way to create RESTful Web services that exchange POX, RSS, Atom, etc.

I'm not sure what it would take to send/receive SOAP messages and whether or not MarkLogic provides capabilities to help developers create Web services using this protocol and the WS-* stack. I intend to find out, however, and will update this blog with more details when I have them.