iiRDS – The Current Status

At this year’s tcworld conference in October, the working group "Information 4.0" presented version 0.9 of iiRDS (intelligent information Request and Delivery Standard), the content delivery standard for technical documentation for industry 4.0.

The working group also opened the Request for Comments (RfC). The RfC ended in December 2017. After incorporating the comments, the working group will release the first version of iiRDS at the beginning of 2018 and make it available under a Creative Commons license for free use.

You can view the status of the iiRDS specification on the tekom website. After you have registered, you have free access to the specification. All links to the specification in this article are only accessible after registration.

This article introduces you to the data structures of iiRDS. We won’t dig deeper into all the structures and possible enlargements, but we'll be happy to explain.

Objectives of iiRDS

In today’s Information Age, technical documentation is developing into smart user information, also called intelligent information. Information becomes intelligent when it is structured, semantically enriched, and when applications can evaluate it for specific usage scenarios. Consider an application that can dynamically compile all information associated with a particular error message or scheduled maintenance task.

In an industry 4.0 environment, devices and components are interconnected. This also affects information for users. Not only the components, but also their documentation needs to be interconnected and aggregated in order to support queries and automated processing. But we can only connect things that speak the same language, that is, use a standardized vocabulary.

iiRDS wants to define a standardized vocabulary and package format for delivering digital user information. This vocabulary defines metadata that enriches technical documentation content and the relationships between metadata. The package format makes it possible to exchange documentation deliveries, regardless of the manufacturer.

You find more information on the objectives of iiRDS in the presentation by Ralf Robers, vice-chairman of tekom Germany.

The iiRDS Metadata Model

iiRDS has three main metadata classes:

• InformationUnit: That’s the metadata that is assigned to a piece of content, a chunk of information. A chunk can be a document, a topic, or a fragment within a topic, such as a warning message. Most relationships to other metadata are go out from objects belonging to the InformationUnit class.
• InformationType: Corresponds to the I classes of the PI class model Professor Ziegler, which forms the theoretical basis of iiRDS.
• DocumentationMetadata: Contains classes for metadata that describes the product (P classes of the PI class model) and functional metadata, such as events or required tools.

The InformationUnit Class

InformationUnit is the central class in iiRDS. It represents all the metadata that belongs to a chunk of content, such as a topic. If that chunk is used in several information products with different metadata, then there are several InformationUnits – one for each metadata variant. That means, if you publish the same topic twice – once for a service technician and once for an operator, you will have two according InformationUnits in your iiRDS package.

InformationUnit defines the granularity of the content to which we assign metadata: the iiRDS package, documents, topics, or fragments.

In the specification: Subclasses of InformationUnit

Relation to the Content File

The content that belongs to an InformationUnit is stored in a file. In the unrestricted version, iiRDS does not stipulate any content format. You can publish content as HTML, PDF, Word, or any other format. You can also have multiple content renditions for each InformationUnit and let the publishing application select the most suitable format.

The relation between the InformationUnit and the content is defined by the Rendition class. An InformationUnit may reference a complete file or a range within a file. This way, you can assign metadata to page range in a PDF file or to a sequence in a video.

In the specification: Content References of Information Units

The Class InformationType

The InformationType class has subclasses for describing document types, topic types, and information subjects.

Standardized Document Types

Each InformationUnit of the type Document must be assigned one of the standardized document types. Even if intelligent information might not be published as documents, documents are still important in technical documentation, especially when it comes to classifying legacy documents content.

The DocumentType class includes typical types of documents, such as transport instructions, operating instructions, and maintenance instructions.

In the specification: Types of Documents and Topics

Topic Types

Topic types represent information types for topics. They enable applications and users to select specific kinds of content, e.g. learning material. Subclasses of TopicType are, for example, task, troubleshooting, or eLearning.

In the specification: Types of Documents and Topics

Information Subjects

InformationSubject is one of the most extensive classes in iiRDS. It contains subclasses for typical subjects of technical document from various industries. Examples are safety information, circuit diagrams, declarations of conformity, and foreseeable misuse. Information types enable targeted access to specific pieces of information for specific users. Example: A service technician is looking for the circuit diagram of a plant.

To support company-specific extensions to the iiRDS standard subjects, the InformationSubject class is subdivided into subclasses for different subject categories, such as safety information or technical overviews.

In the specification: Information Subjects

Product-describing and Functional Metadata

The DocumentationMetadata class contains classes for product-describing and functional metadata.

• Using product-describing metadata, applications can directly select documentation for a particular component or product.
• Functional metadata supports content retrieval, processing and content compilations, for example, the dynamic generation of maintenance tables from service intervals or the generation of tool lists for selected tasks.

In the specification: Documentation Metadata

Product-describing Metadata

Because all organizations have their own product and component structures, iiRDS cannot standardize the product-describing metadata. Also, there are already international standards focusing on product categories and properties, such as eClass.

For this reason, iiRDS simply offers docking points for a company-specific product or component taxonomy, see Product Metadata.

There is a standardized vocabulary for the product life-cycle phases, however. The ProductLifeCyclePhase class has several subclasses so that we can assign content to the phases of the product lifecycle, such as design and development, commissioning, and use. This way, service technicians could easily search for maintenance information while other users only see general operating instructions, for example.

Functional Metadata

Functional metadata supports applications in the evaluation, retrieval, and compilation of intelligent information, for example, in the generation of spare part or tool lists.

The FunctionalMetadata class has different subclasses for the following types of metadata:

• Event: Events that are reported by the system, such as error messages or warnings.
• Supplies: Metadata for tools, equipment, and supplies that are required for work tasks.
• PlanningTime: Metadata for various time periods and intervals, such as maintenance interval, required working time, or downtime.
• Qualification: Contains subclasses for the roles or qualifications that are required for a task.

In the specification: Functional Metadata

Relations Between InformationUnit and Other Metadata

To create a semantic network for the user information that can be semantically evaluated, we need to standardize the relations that are used to assign metadata to information units.

iiRDS defines these relations, including the following:

• relates-to-event: Describes a relation to a specific event, for example, for troubleshooting.
• relates-to-product-metadata: Describes the relation to a specific product, component, product life-cycle phase, or product feature.
• has-subject: Describes the subject of the InformationUnit.
• requires-supply/requires-qualification/requires-time: Describe relations to required tools, supplies, time periods, and intervals, as well as to the qualification or role required for a task.

In the specification: Relations of InformationUnits

Metadata Domains

Some of the metadata we described above is only important for mechanical and plant engineering; other only for the software industry. For this reason, iiRDS applies the concept of domains and assigns some of the iiRDS data structures to specific domains. That means that, in addition to the core vocabulary, applications can only use the domains they really need.

The following domains have been defined so far:

• machinery
• software

Currently, mainly InformationSubjects, ProductLifeCyclePhases and FunctionalMetadata are divided into domains.

Standardized Packet Format

In addition to the structured metadata, iiRDS defines a delivery container for intelligent information. The container format may be a ZIP archive, for example.

The standardized delivery format enables the exchange and delivery of intelligent information across manufacturers. Each IIRDS-compatible application must be able to unpack and parse iiRDS containers.

In the specification: iiRDS Container

Directory Structures

Each iiRDS container must have a top-level directory named META-INF. It contains the RDF files with the metadata for the documentation content. The content itself is located in an arbitrary folder structure below the root directory.

Content formats

The documentation content itself may have various formats, such as PDF or HTML. With respect to content format, iiRDS distinguishes between two formats: Restricted iiRDS/A format: The iiRDS/A format only allows a certain subset of HTML5, different media formats, and PDF/A-3 as content formats. All IIRDS-compatible applications must be able to render this format. In the specificaiton: iiRDS/A Media Formats Unrestricted iiRDS format: There are no restrictions on content formats. What iiRDS is not: An authoring standard iiRDS wants to facilitate the exchange of technical documentation across manufacturer and device boundaries by providing a standardized package format and a standardized vocabulary for the metadata. That does not mean, however, that you have to write in the iiRDS format. You only have to make sure that your delivered documentation packages comply with the standard. That means, for example, that the metadata for events can have a different name in your CMS. All that matters is that the output mechanisms deliver the metadata as iiRDS metadata. Also, you may author information that iiRDS represents as metadata as semantic XML elements in your authoring environment. You may, for example, use semantic elements for maintenance intervals or tools when you write your topics. After conversion to the output format, however, this information also needs to be represented in the metadata to make it iiRDS-compliant.

Also, iiRDS does not control how content is rendered. In order for the content of different manufacturers to look equally good, you will need some processing on the server or the receiver side, that is, an intelligent rendering application.

Do you need a CMS to create iiRDS packages? Not really. But you should author structured content and be able to assign metadata to your content. This can be done without a CSM, for example, in a DITA authoring environment. However, a CMS with integrated iiRDS support offers many advantages because content and metadata are managed separately in such systems.

Further Steps

After the release of version 1.0 of iiRDS, the iiRDS consortium will continue to develop the standard.