In 2002, Ann Rockley, Pamela Kostur, and Steve Manning published Managing Enterprise Content: A Unified Content Strategy (New Riders). I served as technical editor. Ann and I were also working with a multinational life sciences company at the time. We were helping the company adopt information science-backed methods and techniques to meet its business goals. A major part of that work involved us helping it adopt semantic structured content and component content management.
The goal was a sustainable, scalable approach that would reduce the amount of time required to prepare and submit New Drug Applications to the US Food and Drug Administration (FDA).
I recently reread The Architecture of Content Reuse, a short paper Ann and Steve derived from the book for a panel at the 2002 annual meeting of the American Society for Information Science and Technology (ASIST). Reading it 24 years later reminded me how far their ambitions extended beyond cheaper publishing. Reuse is the paper’s subject, but it also describes information models that identify content elements, what those elements mean, and how they are reused.
How Rockley Classified Reuse
Most organizations, the authors observed, reused content by copying and pasting it. That works until the content changes and someone has to find every copy. Miss one, and the result is an error.
They distinguished opportunistic reuse, in which an author chooses to reuse an existing component, from systematic reuse, in which reuse is planned and software inserts components at designated locations. Reused content takes one of three forms. Locked content stays unchanged wherever it appears. Derivative content is adapted from a parent component and stays linked to it, so its author is notified when the parent changes. Nested content holds several reusable elements inside one element, and different information products use different subsets.
A warning that needs identical and approved wording across all products is a perfect candidate locked reuse (where a content component is reused unchanged). A maintenance procedure that is mostly shared but has one configuration-specific step calls for derivative or nested reuse.
Derivative reuse occurs when a reusable content component is edited, that component becomes a derivative [or a “child”] of the original “parent” element. According to Rockley, a derivative content component “continues to be related to the original, such that if the original (parent) changes, the author of the derivative (child) element is notified of the change and can decide whether or not to incorporate the change.”
Nested reuse occurs when content contains a number of reusable content components contained within another content component. According to Rcokely, “nested reusable information provides authors with the ability to create content for all the outputs at the same time, thereby providing context and frequently speeding up the authoring process.”
The paper’s information models specify elements, attributes, metadata, and the relationships among content elements. Semantic tags describe what an element is and what it’s about. Architectural information records where content is reused and how. DTDs, authoring forms, and structural templates enforce a consistent structure. That consistency makes automated processing possible, but it doesn’t establish that every necessary fact was captured in the content.
From Unified Content Strategy To Intelligent Content
Rockley didn’t invent structured authoring, single source publishing, or content reuse. She was one of several people at the leading edge of content strategy thinking about them, and with Kostur and Manning she assembled those ideas into a framework technical documentation teams could implement. Its principles became standard practice among teams that went on to adopt the Darwin Information Typing Architecture (DITA) XML, component content management systems (CCMSs), and automated publishing. And these practices are the foundation upon which many documentation publishing pipelines are built.
In 2011, Ann and Joe Gollner wrote about intelligent content strategy in a special section of the Bulletin of the American Society for Information Science and Technology that Seth Earley and I edited. On automation, they wrote,
“Content must be consciously designed to support it.”
Ann and I ran the Intelligent Content Conference together and sold it to the Content Marketing Institute in 2014. The following year, Ann, Charles Cooper, and I published Intelligent Content: A Primer.
Chapter 1 includes Ann’s definition:
Intelligent content is designed to be modular, structured, reusable, format free, and semantically rich and, as a consequence, discoverable, reconfigurable, and adaptable.
None of this was new in 2015. Mark Lewis, author of DITA Metrics 101, opened his endorsement of the primer with that point:
“You may be new to intelligent content, but intelligent content is not new.”
Note: Intelligent content is also known as kinetic information.
What Bob Glushko Wrote In The Foreword
Robert J. Glushko, a friend and mentor under whom I lectured at the University of California, Berkeley, School of Information, wrote the primer’s foreword. He described two dimensions of a digital format’s adaptability:
how far it separates semantic information (what something means) from presentation (how it looks), and
how much structure and organization its semantics contain
He placed scanned print documents low on both, HTML as highly structured but usually not semantic, and XML or database content high on both, especially when it conforms to standards for a domain’s content types. He also credited Ann with persuading skeptics, back when the work involved using Standard Generalized Markup Language (SGML), that single-source publishing was more than a cost-saving tactic.
Built For The Business Case
Tech docs teams adopted structured content practices to solve specific business problems. Teams concerned about translation costs, for example, build content reuse and conditional processing capabilities to save money on translation. Teams aiming to publish faster typically invested in workflow and output automation capabilities to increase publishing efficiency and speed time-to-market. Many of those investments met their stated goals.
Problems show up when the same content has to do a job nobody planned for, such as supplying an AI answer engine. Teams add metadata when a capability requires it. Team that published only PDFs and a help system for the past few years had no business-critical reason to tag each procedure with the product versions it covers, so its content model has no element or attribute for them.
Valid XML, Missing Applicability
AI answer engines may retrieve a passage from our docs without retrieving the surrounding topic content or its metadata. A hypothetical maintenance procedure illustrates the problem.
Its DITA topic has structured steps, a labeled warning, and metadata naming the product family. The topic validates and publishes correctly. The procedure applies only to certain versions, but the retrieved passage carries no version restriction. If the customer’s product is one of the excluded versions, the answer engine delivers instructions that don’t apply.
Either nobody recorded which versions the procedure covers, or that information got lost before it reached the answer engine. Either way, the answer engine has the steps but can’t tell whether they apply to the customer’s product.
XML validation, the kind of DTD check Rockley and Manning described, confirms that content conforms to its declared rules. It doesn’t establish that those rules required the facts a particular answer depends on, and it doesn’t guarantee that a retrieval pipeline preserved the relevant metadata.
I’ve been developing a method for identifying where documentation leaves important conditions or relationships implicit, including cases where the individual facts appear but their connection is unstated by the person or machine that created the docs. I’m working with academic researchers to test whether greater explicitness measurably reduces AI answer errors. A content review can identify the omissions in your docs without waiting for that research.
Where To Look First
Rockley and Gollner wrote that information modeling forces teams to consider all their information requirements and assess what information is available to fulfill them. For documentation that AI systems now consume, that means inspecting both the source docs and the documentation content that reaches the answer engine.
Check where your product versions, configurations, and prerequisites are recorded. Then check whether your publishing, indexing, and retrieval pipelines preserve them. Missing source information calls for changes to the content model or authoring practice. Information lost after authoring calls for changes to the processing pipeline.
Rockley and Manning’s model tracked one relationship explicitly: a derivative stayed linked to its parent, and its author learned when the parent changed.
Applicability is a different relationship, between a procedure and the products it fits, but it needs the same respect. It has to be recorded in the source and preserved to ensure access is provided to whatever systems need to read it.
The question is how much of that work our source content does, and how much it leaves the answer engine to infer. 🤠