iiRDS – der aktuelle Stand zur tekom-Herbsttagung 2017

Auf der Herbsttagung 2017 stellte die Arbeitsgruppe „Information 4.0“ die Version 0.9 von iiRDS vor (intelligent information Request and Delivery Standard), dem Auslieferungsstandard für Technische Dokumentation im Zeitalter von Industrie 4.0. Für diese Version wurde der Request for Comments, die Kommentierungsphase gestartet. Der RfC soll noch bis Ende 2017 laufen. Nach Einarbeitung der Kommentare soll die erste Version von iiRDS Anfang 2018 veröffentlicht werden und unter einer Creative-Commons-Lizenz zur freien Nutzung verfügbar sein¹.

Sie können den derzeitigen Stand der iiRDS-Spezifikation auf der tekom-Seite einsehen. Nach der Registrierung ist die Spezifikation frei zugänglich. Alle Links auf die Spezifikation in diesem Artikel sind daher nach einer Registrierung erreichbar.

Dieser Artikel gibt eine Einführung in die Datenstrukturen von iiRDS. Eine tiefere Darstellung aller Strukturen sowie der Möglichkeit der Erweiterung würde hier den Rahmen sprengen. Aber wir beantworten gern Ihre Fragen.

Ziele von iiRDS

Die klassische technische Dokumentation entwickelt sich im Zeitalter der Digitalisierung zur smarten Benutzerinformation, auch intelligente Informationen genannt. Intelligent werden Informationen, wenn sie semantisch angereichert und strukturiert sind und von Anwendungen für bestimmte Nutzungsszenarien ausgewertet werden können. Ein Beispiel sind Service-Szenarien, in denen eine Anwendung Informationen zu einem bestimmten Fehlerfall oder für eine geplante Wartung dynamisch zusammenstellt.

Für Industrie 4.0 werden Geräte und Komponenten untereinander vernetzt. Diese Vernetzung wird auch für die Benutzerinformationen notwendig, um für miteinander verbundene Komponenten eine aggregierte Dokumentation anzeigen und auswerten zu können. Wir können jedoch nur Dinge miteinander vernetzen, die dieselbe Sprache sprechen, also ein standardisiertes Vokabular verwenden.

iiRDS will für die Auslieferung von digitalen Benutzerinformationen ein einheitliches Vokabular und ein Paketformat definieren. Das Vokabular definiert Metadaten, mit denen technische Dokumentation angereichert werden kann, und die Beziehungen dieser Metadaten untereinander. Das Paketformat ermöglicht den herstellerübergreifenden Austausch von Dokumentationslieferungen.

Weitere Informationen zu den Zielen von iiRDS finden Sie auch in der Präsentation von Ralf Robers, dem stellvertretenden Vorsitzenden des tekom Deutschland e.V.

Das Metadaten-Modell von iiRDS

iiRDS hat drei Hauptklassen für Metadaten

• InformationUnit: Die Informationseinheit repräsentiert die Metadaten, die einem Stück Inhalt, einem Informationshäppchen, zugewiesen werden. Ein Informationshäppchen kann ein Dokument, ein Topic oder ein Fragment innerhalb eines Topics sein, beispielsweise ein Warnhinweis. Die meisten Relationen zu anderen Metadaten gehen von der InformationUnit aus.
• InformationType: Die Informationsart entspricht der I-Klassifikation aus der PI-Klassifikation von Professor Ziegler, die die theoretische Grundlage von iiRDS bildet.
• DocumentationMetadata: In den Dokumentationsmetadaten befinden sich Klassen für produktbeschreibende Metadaten (P-Klassen der PI-Klassifikation) und funktionale Metadaten wie Ereignisse oder benötigte Werkzeuge.

Die Informationseinheit

Die InformationUnit ist die zentrale Einheit in iiRDS, sie repräsentiert eine Zusammenstellung von Metadaten für ein Stück Inhalt, z.B. einen Topic. Wenn ein Inhalt in mehreren Informationsprodukten verwendet wird, mit unterschiedlichen Metadaten, dann gibt es dafür auch mehrere InformationUnits, für jede Ausprägung der Metadaten eine. Wenn Sie also denselben Topic einmal für Servicetechniker und einmal für Bediener veröffentlichen, gibt es zwei InformationUnits.

Die InformationUnit definiert die Granularität der Inhalte, denen wir Metadaten zuweisen können: das iiRDS-Paket, Dokumente, Topics, Fragmente.

In der Spezifikation: Subclasses of InformationUnit

Beziehung zur Datei mit dem Inhalt

Der Inhalt, zu dem die Metadaten einer InformationUnit gehören, befindet sich in einer Datei. iiRDS schreibt in der nicht beschränkten Variante keine Inhaltsformate vor. Die Inhalte können zum Beispiel in HTML, PDF oder Word publiziert sein. Möglich sind auch mehrere Inhaltsausprägungen pro InformationUnit, sodass sich die darstellende Anwendung das geeignetste Format raussuchen kann.

Die Beziehung von der InformationUnit zum Inhalt wird über die Rendition-Klasse definiert. Dabei kann sowohl eine komplette Datei als auch ein Bereich in der Datei referenziert werden. So kann man z.B. einem Seitenbereich in einer PDF-Datei oder einer Sequenz in einem Video Metadaten zuweisen.

Informationsarten in InformationType

Die Klasse InformationType enthält Unterklassen für die Beschreibung von Dokumentarten, Topic-Typen und Informationsthemen.

Standardisierte Dokumentarten

Jeder InformationUnit vom Typ Document muss eine der standardisierten Dokumentarten zugewiesen werden. Auch wenn intelligente Informationen wohl nicht als Dokumente ausgeliefert werden, spielen diese in technischer Dokumentation immer noch eine wichtige Rolle, vor allem für die nachträgliche Klassifizierung von Bestandsdokumentation. Die Klasse DocumentType enthält typische Dokumentarten wie z.B. Transportanleitung, Bedienungsanleitung und Wartungsanleitung.

In der Spezifikation: Types of Documents and Topics

Topic-Typen

Topic-Typen, also Informationsarten für Themen, sind wichtig, um bestimmte Arten von Informationen für die Nutzer der Informationen auszuwählen, z.B. Lerninhalte. Die Unterklassen von TopicType stellen typische Themenarten dar, z.B. Aufgabe, Fehlerbehebung oder Lernmaterial.

In der Spezifikation: Types of Documents and Topics

Informationsthemen

Die wohl umfangreichste Klasse in iiRDS sind die Informationsthemen. Hier sind klassische Themen von technischer Dokumentation für verschiedene Branchen gesammelt, z.B. Sicherheitsinformationen, Schaltpläne, Konformitätserklärung, vorhersehbarer Missbrauch usw. Sie ermöglichen den präzisen Zugriff auf spezielle Informationshäppchen für bestimmte Anwender, z.B. wenn ein Servicetechniker den Schaltplan für eine Anlage sucht.

Zur besseren Unterteilung und Erweiterbarkeit durch unternehmensspezifische Themen enthält die Klasse InformationSubject Unterklassen für bestimmte Themenkategorie wie Sicherheit oder technische Übersichten.

In der Spezifikation: Information Subjects

Produktbeschreibende und funktionale Metadaten

Die iiRDS-Klasse DocumentationMetadata sammelt Klassen für produktbeschreibende und funktionale Metadaten.

• Mithilfe produktbeschreibender Metadaten können Anwendungen die Dokumentation zu einer ausgewählten Komponente oder einem Produkt direkt auswählen.
• Funktionale Metadaten unterstützen spezielle Auswertungen und Inhaltszusammenstellungen, z.B. die dynamische Erzeugung von Übersichten zu Serviceintervallen oder Listen mit Werkzeugen für ausgewählte Aufgaben.

In der Spezifikation: Documentation Metadata

Produktbeschreibende Metadaten

Produktbeschreibende Metadaten können nicht standardisiert werden, denn jedes Unternehmen hat seine eigene Struktur von Produkten und Komponenten. Produktkategorien und -merkmale sind zudem in eClass standardisiert.

iiRDS bietet deshalb vorrangig Andockpunkte für eine unternehmensspezifische Produkt- oder Komponententaxonomie. Siehe Product Metadata.

Ein standardisiertes Vokabular gibt es hingegen für die Produktlebenszyklusphasen, die die Dokumentationsinhalte beschreiben. Dafür stellt die Klasse ProductLifeCyclePhase mehrere Unterklassen bereit, sodass die Inhalte den Phasen der Produktentwicklung, der Inbetriebnahme, der Nutzung und der Nachnutzung, zugeordnet werden können. Auf diese Weise können z.B. Servicetechniker leicht nach Inhalten für die Wartung filtern, während Anwender nur Inhalte für den Betrieb finden.

Funktionale Metadaten

Die funktionalen Metadaten unterstützen spezielle Szenarien der Auswertung und Zusammenstellung intelligenter Informationen, z.B. die Erzeugung von Ersatzteil- oder Werkzeuglisten.

Die Klasse FunctionalMetadata enthält verschiedene Unterklassen für diese Art von Metadaten:

• Event: Ereignisse, die vom technischen System gemeldet werden, z.B. Fehlermeldungen oder Warnungen.
• Supplies: Metadaten für Werkzeuge, Betriebsmittel, Verbrauchsmaterialien etc., die für Arbeitsaufgaben erforderlich sind.
• PlanningTime: Metadaten für verschiedene Zeitangaben wie Wartungsintervall, erforderliche Arbeitszeit oder Stillstandzeit.
• Qualification: Enthält Unterklassen für die Rollen oder Qualifikationen, die für eine Aufgabe erforderlich sind.

In der Spezifikation: Functional Metadata

Beziehungen von InformationUnit zu anderen Metadaten 

Damit aus den Nutzungsinformationen tatsächlich ein Netz verknüpfter Informationen wird, das semantisch ausgewertet werden kann, braucht es standardisierte Relationen für die Zuweisung von Metadaten zu InformationUnits.

iiRDS definiert diese Relationen, unter anderem folgende:

• relates-to-event: Dokumentation für ein bestimmtes Event, z.B. zur Fehlerbehebung
• relates-to-product-metadata: Gültigkeit einer InformationUnit für eine bestimmte Produktvariante, ein Produktmerkmal, eine Komponente oder Phase des Produktlebenszyklus
• has-subject: Die InformationUnit beschäftigt sich mit einem bestimmten Thema.
• requires-supply/requires-qualification/requires-time: In der InformationUnit befinden sich Informationen zu benötigten Werkzeugen, Materialien, Zeiten oder Intervallen. Die Arbeiten erfordern eine bestimmte Qualifikation oder Rolle.

In der Spezifikation: Relations of InformationUnits

Domänen für die Metadaten

Einige der oben beschriebenen Metadaten sind nur für den Maschinen- und Anlagenbau, andere nur für die Software-Industrie relevant. Aus diesem Grund verwendet iiRDS das Konzept von Domänen, mit denen bestimmte Datenstrukturen einer spezifischen Domäne zugeordnet werden. So können Anwendungen neben dem Kernvokabular nur die Domänen verwenden, die sie wirklich benötigen.

Derzeit sind folgende Domänen definiert:

• machinery
• software

Derzeit sind vor allem InformationSubjects, ProductLifeCyclePhases und FunctionalMetadata in Domänen unterteilt.

Standardisiertes Paketformat

Zusätzlich zu den strukturierten Metadaten definiert iiRDS einen Liefercontainer für die intelligenten Informationen. Das kann z.B. ein ZIP-Archiv sein.

Das standardisierte Lieferformat ermöglicht die herstellerübergreifende Auslieferung von intelligenten Informationen – jede iiRDS-kompatible Anwendung muss in der Lage sein, iiRDS-Container zu verstehen.

In der Spezifikation: iiRDS-Container

Verzeichnisstrukturen

In jedem iiRDS-Container muss es auf oberster Ebene ein Verzeichnis namens META-INF geben. Hier liegt die RDF-Datei mit den Metadaten zu den Dokumentationsinhalten. Die Inhalte selbst befinden sich in beliebigen Ordnern unterhalb des Wurzelverzeichnisses.

Inhaltsformate

Die Dokumentationsinhalte können in verschiedenen Formaten vorliegen, z.B. PDF oder HTML. Grundsätzlich unterscheidet iiRDS hinsichtlich der Inhaltsformate zwischen zwei Paket-Varianten:

Eingeschränktes iiRDS/A-Format

Das iiRDS/A-Format erlaubt nur eine bestimmte Untermenge von HTML5, verschiedenen Medienformaten und PDF/A-3 als Inhaltsformate. Das eingeschränkte Format muss von allen iiRDS-kompatiblen Anwendungen problemlos darstellbar sein.

In der Spezifikation: iiRDS/A Media Formats

Unbeschränktes iiRDS-Format

Es gibt keine Einschränkungen bei den Inhaltsformaten.

Was iiRDS nicht ist: Ein Erfassungsstandard

iiRDS soll die Austauschbarkeit von technischer Dokumentation über Hersteller- und Gerätegrenzen hinweg ermöglichen. Dazu dienen ein einheitliches Paketformat und Metadaten, die das Vokabular für technische Dokumentation standardisieren. Deswegen müssen wir aber nicht in diesem Standard schreiben. Vielmehr muss bei der Erzeugung der Ausgabeformate sichergestellt werden, dass die erzeugten Dokumentationspakete dem iiRDS-Standard entsprechen. Das Metadatum für Ereignisse z.B. kann also in Ihrem Redaktionssystem ganz anders heißen, wichtig ist nur, dass die Ausgabemechanismen das als iiRDS-Metadatum ausliefern. Analog können Informationen, die in iiRDS als Metadaten modelliert werden, beim Schreiben jedoch als semantische XML-Elemente erfasst werden, bei der Erzeugung der Ausgabe umgesetzt werden. Beispiele hierfür sind Informationen zu Wartungsintervallen oder benötigten Werkzeugen, die vom Technischen Redakteur in XML-Elementen erfasst werden, bei der Ausgabe aber zusätzlich als Metadatum des entsprechenden Topics angelegt werden.

iiRDS regelt auch nicht die Darstellung der Inhalte. Damit die Inhalte verschiedener Hersteller gleich gut aussehen, bedarf es noch einer Verarbeitung auf dem Server oder der Empfängerseite, also einer intelligenten Anwendung zum Rendering.

Brauchen Sie zum Erzeugen von iiRDS-Paketen ein Redaktionssystem? Eigentlich nicht, aber Sie sollten strukturiert schreiben und die Möglichkeit haben, den Dokumentationsinhalten Metadaten zuzuweisen. Das funktioniert prinzipiell auch ohne Redaktionssystem, z.B. in einer DITA-Autorenumgebung. Ein Redaktionssystem mit integrierter iiRDS-Unterstützung bietet natürlich viele Vorteile, da dort Inhalte und Metadaten sowieso meist getrennt verarbeitet werden.

Weitere Schritte in der iiRDS-Entwicklung

Nach der Veröffentlichung der Version 1.0 von iiRDS wird die Entwicklung weitergehen. Die tekom richtet dazu ein Konsortium ein, das die Arbeit in Arbeitsgruppen fortführen soll.