RSuite User Conference - 10/6/2009

I'm attending the 3rd RSuite users conference in Philly today, by invitation of Really Strategies' Lisa Bos. I've been tracking RSuite since its inception a few years ago - the idea of a decent CMS based on Marklogic always hit me as a good niche product and by all indicators, RSuite is a success, especially in light of how many CMS offerings there are in the world.

I'm here for the technical track - to learn more about how to write customizations for RSuite - I'm a developer afterall. But the Keynote from Howard Ratner (CTO, Nature) is an excellent intro to what comes after CMS.

Nature is using RSuite as an integration tool between various pub tools and the Marklogic content repository. In the Keynote, Howard makes excellent points about the need for content classification, which (of course) is why I'm writing about it! Nature is using a mixture of automated content recognition tools and editorial tools. Also mentioned open search technology - search widgets that create a viral access to the Nature content. One very interesting thing Howard talks about it the "Work Arounds" that are developed because either the content or the technologies don't do the exact job needed. What is the cost of these?

Lisa Bos then gave us a demo of the current version of RSuite. Nice clean and simple to use browser-based GUI. New features include Digital Asset Management, Workflow Configuration, editing (in oXygen and XOpus - one of my fav XML editors). But, IMHO, where's the beef? What does this have that free/open-source solutions (like Alfresco and/or eXist) don't? Or, for that matter, our own Tractare? Other new features - search enhancements, reporting, GUI customizations, better API and the ever needed performance improvements.

Semantic-Content Management

We've been developing a tool set, or framework, or whatever for several years. We call it "Tractare" which is Latin for "to handle, manage, perform". I'm a sucker for that kind of naming.

Anyway, what's it all about? Well, as the Internet becomes more saturated with raw information, keyword search engines really aren't enough to locate that needle in the haystack. We (content providers) need to describe our content in a way that users "get" -- we need to describe the "aboutness" of our content.

An example I like to use when speaking on this subject is this: If you were to use google to search for "retarded", you would get a gazillion hits. But few, if any of those hits would have come up using the politically correct phrase "intellectually challenged". This is because a keyword engine like google depends on the actual presence of the keyword, either as text in the content or as metadata. Now, you could encode both forms of this concept as meta-data on your web-page and it would be found. Now, if you are a psychologist or someone working in mental health, you'd probably be getting the results you want. But if you are a firefighter, the word "retarded" has a whole different meaning. How do we express that? The answer is in several parts of course. But first, we need to capture the meaning of the content; the "aboutness". We need to associate the "firefighter" concept with the content that pertains to fighting fires. This is what Tractare permits us to do.

Tracare is a framework. It's not an off-the-shelf product. It is built on the idea of topic maps -- organizing content around indexes and concepts. It's true power lies in a combination of searching and navigation tools that allow the user to narrow the scope of their work to a set of concepts. We build custom CMS and delivery solutions on top of it.

The CMS systems we build usually include features found in social networking, including folksonomies (as well as traditional taxonomy and classification support) and ranking/commenting. These features allow content providers to apply semantics to content in a number of new and different ways.

The delivery systems we build often include a number of search and navigation interfaces that web users have come to love, including mashups, classification searching, semantic browsing and so on.

Content Management Frameworks -- Tractare and Configuration

There are a large number of Content Management "Frameworks" out there -- http://en.wikipedia.org/wiki/Content_management_framework lists just a few. What is a "Content Management "Framework?" In essence, it is a programmable API for creating customized content management systems. In other words, a programmers way to create (using the framework) a CMS that supports all the stages of content lifecycle: Organization - Workflow - Creation - Repository - Versioning - Publishing - Archives (or some subset thereof). In essence, a CM framework is a foundation on which a custom CMS can be built.

The key features I would expect to see in a CM framework include (http://www.cmsreview.com/Features/Lists.html):

1. a way to acquire both text and non-text content (acquisition, aggregation, authoring)
2. a way to store and retrieve content
   
3. a way to control workflow (roles/permissions, checkin/checkout, messaging/routing)
   
4. a way to control versioning
5. a way to control personalization and localization
6. an interface to administration (reporting, management, etc.)
7. a way to control content delivery (extraction, slicing, publishing, syndication, update)
8. a way to implement business rules
9. and others...

The trick is making this work as a framework. How much needs to be customized by a programmer and how much can be done by a very tech-savy non-programmer.

In our CM Framework (Tractare), we permit most of these features to be customized by scripting. For example, many organizations have IT departments that mandate the use of a particular DBMS (Oracle or SQL Server, for example). So in Tractare, there is a fairly simple configuration setting that allows selection of the database interface driver. But, since Tractare is a CM framework, we also expose the driver interface so that a programmer can create a driver for a database for which we have not supplied one. We make heavy use of configuration files so that non-programmers can customize the CMS.

Another area that we use scripting is in the interface elements (the "view" of the CMS). Internally, Tractare generates most interaction responses as an XML stream. This way, the entire user interface to Tractare can be tailored using XSLT scripts.

Depending on the application however, Tractare could still require an investment in programming. It is written in JAVA and intended to run as a web application (using servlets, etc.). So extending the code is a matter for a JAVA web programmer. But many features can be customized without this level of involvement.