The Ten Commandments of Content Management in a Database - Vest Pocket Edition

1. The 10 Commandments

• Content must be stored only once.

• Content must be stored separately from tagging.

• Content granularity must be available at any level.

• Content management capability must be enhanced through the use of metadata and system extensibility.

• Content and publication load, edit, and extract must be independent operations.

• Content objects must have power.

• Content management should be an enterprise solution.

• Content views must support the users' needs.

• Content management should start, not end, with the DTD.

• Content management and workflow integration should be seamless.

1.1. Content must be stored only once

• Eliminating duplicate content allows:

  • Accurate tracking of all uses of a single content element.

  • Separates the content itself from its uses.

  • Accurate version and revision control.

  • Maximizes storage efficiency.

• Points to look for:

  • Is existing content checked for prior existence and reuse?

  • Is a change in content compared to existing content for possible reuse?

  • Can the system immediately notify the user and act upon all current uses of a content element?

  • Can the system show content independently of specific uses of that content?

  • Can the same content be used in different views, hierarchies, and configurations without duplication?

• Other important issues:

  • What size repository do I need?

    • Amount of legacy data.

    • Past growth experience.

    • Projected new needs.

  • How much duplication is acceptable?

    • Is there any real need to duplicate?

    • How does duplication affect version control, re-use, and system performance?

  • Does everything have to be in the Content Management System (CMS ) database?

    • Multimedia files.

    • CAD files.

1.2. Content must be stored separately from tagging

• Various tagging structures can be used throughout:

  • SGML, XML, HTML, PDF, Wireless Markup Language (WML ), XSL, Xlink.

  • Proprietary tagging schemes such as Quark and Microsoft Word formats.

  • Content can be reused with multiple tagging schemes as required.

• Points to look for:

  • Can publications automatically use new standards with existing content, or only with new content?

    • Is conversion a one-time process and expense, or dependant on new standards?

  • Does each new standard require the installation of yet another new release of the system?

• Other important issues:

  • Does it have to be tagged?

    • Should it be SGML, XML, or HTML?

  • Must I make a tagging decision now?

• What is Tag-Neutral-Technology:

  • Open, non-proprietary identification technology for internal CMS database use.

    • Allows multiple media use.

    • Allows immediate implementation of new standards.

    • Assures future value of current knowledge assets.

1.3. Content granularity must be available at any level

• Component size should be dependent on the requirements of the information.

• A content scheme that is not totally flexible in granularity will inevitably become inappropriate for certain situations.

• Points to look for:

  • Support for more than just the literal DTD

  • The DTD should aid system set-up, not be system set-up.

  • Are elements, their requirements, and uses flexible across publications?

• Other important issues:

  • What is granularity?

  • How do I choose a content size?

  • Must I standardize?

1.4. Content management capability must be enhanced through the use of metadata and system extensibility

• More metadata = smarter system.

• The system must allow creation and addition of metadata as required.

• Future requirements are unpredictable.

  • Without extensibility, today's perfect fit becomes tomorrow's organizational nightmare.

• Points to look for:

  • Does the system allow retroactive application of new metadata?

  • How extensive are metadata opportunities without custom programming?

  • Enforceable behavior?

  • Variety of data types?

  • Helper applications?

  • Component independence?

• Other important issues:

  • Just what is metadata?

    • Attributes.

    • Information about information.

    • Descriptions.

  • If I don't have metadata now, why would I want some later?

    • Enhance search and query.

    • Prototype "market specific" publications.

    • Enhance use and re-use abilities and value.

1.5. Content and publication load, edit, and extract must be independent operations

• Business requirements may dictate more than one way to load content.

• Content may require editing in different views.

• Multiple extracts of components may be needed.

• Other important issues:

  • Can I use my current editorial tools and software?

  • What if I want to use Microsoft Word?

  • Must everyone use the same editorial tool?

    • Should they?

  • Should editorial tools be integrated into the CMS ?

  • What about multimedia tools?

    • CAD

  • What about freelance editors or writers?

1.6. Content objects must have power

• There is a difference between a tool that supports object technology and the objects themselves.

• The use of an object tool does not automatically impart power to the object.

• The system must provide capabilities that empower the objects.

• Points to look for:

  • Does changing a DTD make you cringe?

  • Do "spin-off" publications make you nervous?

  • Do you have to add staff to manage new publications or "spin-offs"?

  • What's Component Object Model (COM )?

• Other important issues:

  • Should the underlying database be an object database or a relational database?

    • Can data in a relational database have object behavior and power?

    • Must data in an object database have object behavior and power?

    • Is the tool the important factor?

  • Should the underlying database be proprietary?

    • What other software will utilize the database?

    • Does the database offer the ability to customize its function?

    • How many other programs and systems use this database?

1.7. Content management should be an enterprise solution

• The system should allow:

  • Grouping of sets of related components.

  • Component reuse across different groups.

  • Availability of totally new groupings.

  • Ability to add components and functionality whenever needed.

• Points to look for:

  • Can you mix and match components?

  • Is there support for different types of content?

  • Is there support for multi-site topology?

  • Does support exist for sharing of all corporate knowledge assets?

1.8. Content views must support the users' needs

• Just one content view is not an optimal solution.

• Views, preset and/or pre-defined by a database developer, are likewise not the best solution.

• Points to look for:

  • Do all users of the system edit from the same view of the content?

  • Are users seeing more of the content than their job requires?

  • Is separate editing required for each publication derived from your content?

• Other important issues:

  • Does the system need to have editorial access via the Web?

    • How much functionality is needed via the Web?

  • Will system needs include dynamic population of Web pages?

  • How easy is it to publish content, originally for print, onto the Web?

    • How about CD-ROM?

    • What about wireless transmission?

1.9. Content management should start, not end, with the DTD

• The ability for content evolution must exist.

• The system must allow addition or deletion of components.

• The system must allow the modification of component behavior.

• The system must allow for the addition, modification, or deletion of attributes.

• The system must allow addition, removal, or change to elements in content views.

• The system must allow rules, attributes, metadata, content and validation beyond the DTD.

• The system must allow the creation of new publications as variations.

• Other important issues:

  • Do I need a DTD?

  • Is the DTD enough?

  • Should the system be able to exercise more control over the content than the DTD allows?

  • If one DTD is good, would two be better?

1.10. Content management and workflow integration should be seamless

• The system must allow workflow set-up with the same tools as content set-up.

• The system must allow direct content element access from workflow.

• Workflow objects must have the same power as other system objects.

• Two way triggers must exist between workflow and the content management systems.

• System tools, attributes, and metadata must be available to workflow.

• Content elements must be available to workflow.

• Points to look for:

  • Can an editor directly access the content referred to in a workflow task?

  • Can completion of a workflow task change the status of a content element?

  • Can the inclusion of a content element in a workflow task trigger email notification to an editor?

Design and Development by deepX Ltd.