Data reuse in S1000D – the good, the bad and the reality

Data reuse in S1000D – the good, the bad and the reality!

Often I am asked to explain what is meant by data reuse, specifically when it comes to S1000D. Confusion exists as this is a common buzzword thrown around when being ‘sold’ S1000D. We will often hear S1000D is all about ‘data reuse’, ‘writing once, using many’ are all phrases we have heard. Unfortunately, this sales pitch does not work at all levels in the information supply chain. It often causes a distinct anti-S1000D sentiment deeper in the supply chain.

When we look at S1000D, we have to accept that the specification focuses on the platform support information. The Model Identification Code approach makes this blatantly clear and is core to the code and linking system in S1000D.

The specification makes no excuse for concentrating on a specific product, variant or type and ties information to a unique code. All suppliers, producers, and contributors will focus on uniquely identified technical content creation for the product.

Traditional monolithic technical publication production methods have now changed to one of a modular approach. Modular techniques deconstruct the monolithic publication into reusable modules and supporting illustrations. The modular process is the concept that S1000D embraces and is the first example of data reuse at its most fundamental level. The ‘write once and use many’ description works well here. Projects can structure required outputs by reusing modules at needed locations.

A simple example is a panel removal task that a maintainer may need to perform during multiple other maintenance tasks. In this simple example, we write one procedure for the panel removal and refer to this single module from all other maintenance tasks. Giving support to the ‘write once, use many’ sales pitch.

In S1000D and other modular approaches, we can use repositories that act as libraries for our technical content creation. These [S1000D] Common Information Repositories (CIRs) act as subset databases containing content ‘snippets’ reused and repurposed across various modules and manuals. This data reuse method is much more granular but provides both a centralised and shared library and efficiency gains for our technical authors.

Warnings and cautions that may be common across a product, system or sub-system are good examples of this information snippet. Authors may call a standard warning and use it (as defined by the project) inside the authored module.

The problem of data reuse is a problem more profound in the supply chain. An excellent and real-world example is a standard system or component manufacturer supplying various customers and a variety of platforms. In the ideal world, all customers would be using the same issue of S1000D, standard Business Rules and have no special requirements.

We all know that this is not the reality, especially if you are in the supply chain. Most of our customers require modern technical publications in their own and unique way. The consequence of all of these special requirements forces many in the supply chain to manage multiple versions of off-the-shelf technical publications.

Working against the ‘write once, use many’ philosophy of data reuse is a consequence of how S1000D works at the highest and product-focused level, especially for those deeper in the supply chain.

Watch the full YouTube video explaining more around the CIRs and how S1000D supports and works against data reuse.

Want more from TDW? Why not join the growing family of subscribers?