iiRDS – The New Delivery Standard for Technical Documentation

by Ulrike Parson on November 17, 2016

Corresponding service: Smart content and iiRDS

Or: What we can do to standardize the content delivery of intelligent information

At the tcworld conference 2016, the tekom working group „Information 4.0” introduced the first results of the group’s work for defining a new content delivery standard for technical documentation in the age of Industry 4.0: iiRDS. tekom is the German association for technical communication.

Why iiRDS?

iiRDS is short for Intelligent Information Request and Delivery Standard. The tekom group “Information 4.0” explores how technical documentation can be delivered in the age of Industry 4.0 and what features it must provide.

The classic concept of a manual for technical information is no longer viable in the age of increased digitalization, Industry 4.0, and the Internet of Things. Technical documentation is turning into intelligent information, which provides the following:

Dynamically adjusts to the user and the usage context.
Provides target-oriented information for all lifecycle phases, from product specification to maintenance.
Fits the delivered system, even after changes to the configuration and product updates.
Dynamically integrates assistance information, sensor data, and operating parameters.
Supports various search and filter options.
Can be displayed on different devices.
Can be supplemented by the user.
Provides secure communication.
Connects with other intelligent information, for example, from other producers.

iiRDS might sound a little cumbersome. It is crucial though that the name does not only contain the "delivery" of intelligent information but also the "request". Requesting intelligent information is as important as the delivery.

Topics and metadata in connected documentation

Today, we need to access information granularly and in a target-oriented manner. We also want the documentation to dynamically adjust to the users’ needs, the context, and the device. That means that instead of creating document-based documentation, we have to deliver a bulk of single topics. In the old-fashioned manual, we would know from context to which product, target group, or lifecycle phase a section was related to – because we found the section in the service manual for technicians, for example.

If we replace the document manual with single-topic delivery, we need metadata that helps us create this context and also lets us find, in a large amount of topics, the right topic for a particular usage scenario or user. Metadata provides context. Therefore, metadata needs to be part of the delivery, along with the content.

Industry 4.0 and the Internet of Things are based on the idea that plants, devices, and components connect intelligently with each other. In the context of Industry 4.0, various standards are being developed, attempting to harmonize the definition and communication of technical components. Examples are OPC-UA¹, AutomationML², and the general reference-architecture model RAMI 4.0³.

But how can documentation for devices of different producers connect? Suppose, producer A calls a manual “maintenance manual”, but producer B calls it “repair manual”. The person who repairs is either the service technician or the mechanic. How does an application, which is supposed to retrieve the topics for the service technician, control the search and display of information?

We need to standardize the metadata that we deliver together with our documentation and which makes our content semantically accessible. Only this way can documentation content become exchangeable and usable for multiple producers. That’s the fundamental concern of iiRDS.

What can we standardize?

Prof. Ziegler’s⁴ PI classification is a fantastic method for defining metadata for modular content, such as topics. The method classifies content by Product and Information. You can, for example, determine whether content is related to a particular product or component, whether it describes specific functions or is suitable for a particular target group.

Metadata concepts based on the PI classification method are often developed according to company-specific requirements. Each company has a different product structure or uses other variant-determining factors.

Variant-determining factors define the difference between the documentation for different product variants, for example, the various car models of a car brand. How do we standardize that? The answer is simple: We standardize the common metadata that describe the documentation as such and not the product-specific part of the metadata.

Therefore, iiRDS focusses first on the metadata about the information itself. It offers connecting points for product-specific and variant-determining metadata, which are defined by the companies themselves. In order for other metadata classifications to link to the connecting points, iiRDS uses technologies of the semantic Web and defines its taxonomy in RDFS format⁵.

Standardized metadata

A first draft of iiRDS is expected to be issued in March 2017. The basic iiRDS structures, however, have already been introduced at the TC world conference:

The central access point is the InformationUnit. It can either be a documentation package, a document, a topic, or a fragment within a topic. Each information unit can be directly accessed via an IRI (Internationalized_Resource_Identifier).
iiRDS includes pre-defined document types, such as installation guide or maintenance instructions, and topic types, such as Task and Learning.
For each information unit, there is functional metadata and product metadata. Functional metadata includes, for example, required tools, maintenance intervals, events like error messages, or the skills of a target group. Product metadata includes product variants and variant-determining metadata, such as functions or components.

This metadata represents the first standardized vocabulary for technical documentation. iiRDS will initially be available in German and English.

Applications can use iiRDS metadata to request information according to context, for example, instructions for a service technician related to a particular error message:

Standardized package format

We also introduced a first draft of the package format in which iiRDS-compliant data can be delivered. A delivery package with technical documentation will consist of content files (for example, in HTML or XML) and a control file with the RDF metadata.

Not all companies create topic-based documentation. Also, there is a lot of legacy documentation that cannot be converted into new formats like HTML5. Therefore, the tekom group is creating a level concept for the package format:

Level 1: The delivery package includes complete documents, for example, as PDFs, and the corresponding metadata
Level 2: The delivery package includes documentation modules, for example as HTML or XML topics, and the metadata for the modules
Level 3: The delivery package includes documentation modules including the metadata for topics and fragments of topics. This way, single warnings can be addressed within topics, for example.

At the TC world conference, several vendors demonstrated that they can exchange such data packages between their systems and thus proved that standardized metadata and the package format make it possible to deliver intelligent information across multiple systems from different vendors. Among the vendors that participated in these demonstrations were Adobe, Schema Systems GmbH, Empolis Information Management GmbH, FCT AG, Docufy GmbH, Acolada GmbH, and practice innovation.

What iiRDS is not: a standard for authoring documentation

iiRDS wants to facilitate the exchange of technical documentation regardless of producer or device. The basis is a standardized package format and metadata, which standardizes the vocabulary for technical documentation. However, we do not need to write in iiRDS. All we have to do is make sure that with the delivery, the created documentation package conforms with iiRDS. For example, metadata for events could have a different name in your CM system. All that matters is that the event metadata is delivered in iiRDS format. The same goes for information modeled as metadata in iiRDS, but originally created as semantic XML elements during authoring. Example: The technical writer creates information about maintenance intervals or required tools as XML elements. During output generation, the information is additionally transformed into metadata for the corresponding topic.

iiRDS also does not control how content will be displayed. If we want the content of different producers look good, the content needs to be processed by an intelligent rendering application on the server or on the receiving end.

Advantages of iiRDS

Technical communication becomes part of Industry 4.0/smart factory.
Standardized metadatas make exchange and request of data easier.
Content management systems and other information sources can be connected with other content delivery systems - independent of vendors.

Not yet ready

iiRDS is being developed. There is still a lot of work to do. After publishing the first version, which is planned for the end of March 2017, we expect a lot of feedback from the parties that will implement the standard. iiRDS is a joint project of the documentation world and will further grow and change.

iiRDS will be available as open ressource under Creative Commons license.