c-rex.net Blog - Konzeption des c-rex.net-Blogs auf Basis von iiRDS und DITA

DITA als Datenbasis

In unserer Redaktion setzen wir auf DITA als zugrundeliegendem XML-Standard. Für die Blogbeiträge haben wir einen eigenen Topictyp Blogpost spezialisiert. Dieser Topictyp implementiert eine Erweiterung für Teaserinformationen und nutzt unsere Standarderweiterungen für Metadaten.

Die Grafik zeigt die Definition eines DITA Subject Schemes in der DITA-Map Ansicht von oXygen. — Definition von kontrollierten Werten in einem Subject Scheme

Über ein DITA subjectScheme, das wir in der DITA-Map referenzieren, definieren wir eine kontrollierte Werteliste für mögliche Metadaten.

Damit lassen sich die möglichen Wert quasi in einer Art Formular auswählen. Das ist benutzerfreundlich und funktioniert in unserem Erstellprogramm oXygen sehr gut. Außerdem hat den schönen Effekt, dass die erfassten Informationen konsistent sind.

Die Grafik zeigt die Auswahl von Metadaten über eine kontrollierte Werteliste auf Basis eines subjectSchemes. — Metadaten und kontrollierte Werte auf Basis eines Subject Schemes

Dokument oder Topic

Dokument oder Topic? Wir fragten uns, ob im c-rex.net-Blog ein Blogbeitrag vom Typ iirds:Document oder vom Typ iirds:Topic sein soll.

Beide leiten von der Basisklasse iirds:InformationUnit ab. Sie haben mit Ausnahme von iirds:has-document-type dieselben Eigenschaften.

Wir haben uns auf iirds:Topic geeinigt, weil ein Blogbeitrag ein in sich abgeschlossenes Thema behandelt.

Ein Dokument hingegen kann mehrere Themen beinhalten, weshalb wir einen Blogbeitrag hier eher nicht zuordnen können. Und diese Definition entspricht dann auch der Spezifikation im iiRDS:

iirds:Document is a collection of information for an audience and a specific purpose.

iirds:Topic is a self-contained piece of information which deals with a single subject. The reader understands a topic without any additional information.

Dennoch haben wir entschieden, dass die geschriebenen Inhalte einen iirds:DocumentType widerspiegeln. Wir haben dafür die Instanzen für News, Artikel und Kundenprojekte definiert und stellen über iirds:is-applicable-for-document-type am iirds:Topic eine Beziehung dazu her.

Eventuell werden wir zukünftig auch eine Kategorie Blogserie einfügen. Diese Blogserie wird dann in einer DITA-Map erfasst, die mittels eines iirds:Document und dem iirds:InformationSubject vom Typ iirds:Collection klassifiziert wird.

<iirds:Document rdf:about="https://www.c-rex.net/ns/iirds/td/cms#MyBlogSeries">
    <iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/collections#BlogPostCollection"/>
</iirds:Document>
<iirds:Collection rdf:about="https://www.c-rex.net/ns/iirds/td/collections#BlogPostCollection">
	<rdfs:label xml:lang="de">Blogserie</rdfs:label>
       <rdfs:label xml:lang="en">Blog series</rdfs:label>
       <iirds:description xml:lang="en"></iirds:description>
	<rdfs:comment xml:lang="en">Indicates that the content represents a collection of information assembled from different blog posts.</rdfs:comment>
</iirds:Collection>

Metadaten identifizieren

Bereits in der DITA-Umgebung haben wir uns Gedanken über das Set an Metadaten gemacht. Dafür haben wir einen ersten Blick in den Standard iiRDS geworfen und uns daran orientiert.

Wieso soll man sich nochmal die Mühe machen und sich etwas eigenes ausdenken, wenn sich viele Experten bereits Gedanken dazu gemacht haben?

Allerdings haben wir uns bei unserer Definition nur um die Informationsquellen gekümmert und den Ausgabeprozess und speziell das iiRDS Format nur am Rande betrachtet.

Wir haben in DITA folgende für uns passende Metadatenkategorien definiert:

Parties

In die Kategorie Parties nehmen wir alle Beteiligten auf, die mit dem Blogbeitrag zur Verfügung stehen. Das sind zum einen AutorenAutorinnenAutoren und AutorinnenAutor:innen, KundenKundinnenKunden und KundinnenKund:innen und ÜbersetzerÜbersetzerinnenÜbersetzer und ÜbersetzerinnenÜbersetzer:innen. Wobei letztere mittlerweile maschinelle Übersetzungssysteme wie DeepL sind.
Components

In unseren Blogbeiträgen dreht sich vieles um die c-rex.net Module. Deshalb müssen wir zu DTS und IDS oder zu beiden eine Beziehung herstellen.
Formats

Des Weiteren schreiben wir einiges zum Umgang mit Daten.

Daten werden in Formaten oder Datendiensten gespeichert. Deshalb gilt es auch hier, Informationen zu erfassen, die eine Beziehung zu unseren Produktfeatures herstellen.

Beispiele aus diesem Bereich wären zum Beispiel iiRDS, DITA oder Word.
Subjects

Subjects nutzen wir um die einzelnen Blogbeiträge zu kategorisieren und sie damit unterscheidbar zu machen. Bislang haben wir als Kategorien Kundenprojekte, Artikel, How-Tos und News identifizieren können.
Td-Processes

Schließlich stehen unsere Blogbeiträge meist mit Prozessen in der Technischen Dokumentation in Beziehung. Angefangen beim Erstellungsprozess über den Übersetzungsprozess, die Verwaltung der Inhalte bis hin zu verschiedenen Ausgabemöglichkeiten.

Weitere Metadaten ergeben sich aus der Struktur des Dokuments und aus den Prozessen.

Erstell- und Änderungsdatum
Veröffentlichungsdatum
Übersetzer

In der Regel übersetzen wir automatisiert. Der Übersetzer ergibt sich deshalb aus dem ausgewählten Übersetzungswerkzeug automatisch. Für den Moment ist das DeepL.
Status des Dokuments

Wenn wir etwas in das Produktivsystem publizieren, ist der Inhalt per Definition freigegeben. Wir pflegen also keinen manuellen Status von Topics.
Typ des Topics

Da wir unsere DITA Topics für die entsprechenden Anwendungszwecke spezialisieren, können wir diese Information automatisiert aus der Struktur des Topic ableiten.

Wir listen also zunächst ganz ausschließlich die Metadaten zu einem bestimmten Inhalt und klassifizieren diese aus Redaktionssicht.

Im nächsten Schritt listen wir die Metadaten, die in Bezug zu externen Ressourcen stehen (wie zum Bespiel AutorenAutorinnenAutoren und AutorinnenAutor:innen, KundenKundinnenKunden und KundinnenKund:innen, ÜbersetzerÜbersetzerinnenÜbersetzer und ÜbersetzerinnenÜbersetzer:innen und Produkte). Und dann machen wir es uns sehr einfach und prüfen, welche Gedanken man sich im iiRDS gemacht hat und mappen diese auf unsere Kategorisierung.

Das DITA Subject Scheme als Basis für den Knowledge Graph

Das DITA Subject Scheme können wir als Konfiguration unserer Redaktionsumgebung betrachten. Ähnliches gibt es in den verschiedenstens Redaktionssystemen; sogenannte Werteliste und Kaskaden, die der Verschlagwortung von Modulen dienen.

Wie man in den Screenshots oben erkennen kann, sind diese Werte sehr spezifisch. Wenn wir nach iiRDS publizieren wollen, müssen wir diese Werte als Basiskonfiguration hinterlegen. Dies können wir tun, indem wir die Beziehungen in Form eines Knowledge Graph manuell definieren oder entsprechende Werkzeuge dafür nutzen. Oder wir nutzen bestehende Systeme, um diese automatisch zu generieren.

In unserem einfacheren Anwendungsfall ist das DITA Subject Scheme. Wir nutzen es, um zumindest die Rumpf-Informationen der entsprechenden Subjekte zu generieren. Schauen wir uns an, wie das am Beispiel der Party AutorenAutorinnenAutoren und AutorinnenAutor:innen, den Prozessen der Technischen Dokumentation sowie der Zuordnung unserer Produkteigenschaften funktioniert.

Definition der Autoren

Im DITA Subject Scheme definieren wir die Werteliste für Autoren und einen Label.

<subjectdef keys="authors">
    <topicmeta>
        <navtitle>c-rex.net Authors</navtitle>
    </topicmeta>                
    <subjectdef keys="parties.c-rex-maw">
        <topicmeta>
            <navtitle>Markus Wiedenmaier</navtitle>
        </topicmeta>
    </subjectdef>
</subjectdef>

Über ein XSLT können wir daraus die iirds:Party Metadaten generieren.

<iirds:Party rdf:about="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-maw">
  <rdfs:label>Markus Wiedenmaier</rdfs:label>
  <iirds:has-party-role rdf:resource="http://iirds.tekom.de/iirds#Author"/>
  <iirds:relates-to-vcard rdf:resource="https://www.c-rex.net/ns/iirds/td/vcards#parties-c-rex-maw"/>        
</iirds:Party>
<vcard:Individual rdf:about="https://www.c-rex.net/ns/iirds/td/vcards#parties-c-rex-maw">
  <vcard:fn>Markus Wiedenmaier</vcard:fn>
  <vcard:hasPhoto rdf:resource="content/globalimages/parties-c-rex-maw.png"/>
</vcard:Individual>

Anhand der Struktur des DITA Subject Scheme wissen wir, dass Markus Wiedenmaier ein Autor ist und können neben dem Label der Party auch direkt die Rolle iirds:has-party-role zuweisen.

Zudem können wir auch den Rumpf der VCard generieren und regelbasiert ein Foto zuweisen.

Sobald die Schnittstelle zu unserem CRM-System implementiert ist, können wir die VCard auch aus diesen Daten automatisch befüllen. Besonders spannend, wenn wir die Blogbeiträge zu unseren Kundenprojekten betrachten.

Definition der Prozesse

Wenn es um Prozessbeschreibungen geht, bietet iiRDS das spezialisierte iirds:InformationSubject iirds:Process an. Im Standard ist eine Instanz dieser Klasse GenericProcess definiert.

Wir sind hier aber deutlich spezieller unterwegs und definieren jetzt unsere eigenen Instanzen auf Basis der definierten Wertelisten.

<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication">
    <rdfs:label xml:lang="en">Publication</rdfs:label>    
</iirds:Process>
<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-translation" >
    <rdfs:label xml:lang="en">Translation</rdfs:label>    
</iirds:Process>
<iirds:Process rdf:about="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication-industry40" >
  <rdfs:label xml:lang="en">Industry 4.0</rdfs:label>    
</iirds:Process>

Definition von Produkteigenschaften

Auch für iirds:ProductProperty legen wir unsere eigenen Werte fest.

<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds">
    <rdfs:label xml:lang="en">iiRDS</rdfs:label>    
</iirds:ProductProperty>
<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-xliff">
    <rdfs:label xml:lang="en">XLIFF</rdfs:label>    
</iirds:ProductProperty>

Ist das jetzt schon ein Knowledge Graph?

Mit den anderen Metadaten gehen wir analog vor und generieren so die Basiskonfiguration unserer iiRDS Umgebung.

Wir haben jetzt einen Knowledge Graph, der einige Beziehungen hauptsächlich aus Sicht der Dokumentation betrachtet und etwas nach außen blickt. Für unseren derzeit noch überschaubaren Anwendungsfall Blog bilden wir die dafür notwendige Informationen entsprechend in einem Graphen ab.

Für einen Knowledge Graph, der auch unsere Produktstrukturen und Beziehungen außerhalb der Technischen Dokumentation auflöst, fehlt aber doch noch einiges.

Gerade in komplexeren Umgebungen, bei denen Anwendungsfälle im Industrie 4.0- und IoT-Umfeld adressiert werden, sind diese Informationen essentiell.

Aber diese Erweiterungen, die zukünftig auch bei uns relevant werden und teilweise schon sind, folgen demselben Prinzip.

Folgendes ist uns wichtig:

Wir nutzen Informationen aus unseren bestehenden Systemen.
Wir leiten daraus den Knowledge Graph wenn irgendwie möglich automatisch ab.
Wir können dabei die Basis des Systems jederzeit reproduzierbar aktualisieren.

Viele Informationen sind in zentralen Systemen eines Unternehmens (ERP, PIM, CRM, PLM, …) vorhanden.

Wenn Informationen fehlen, sollten sie auch dort in der Quelle hinterlegt und gepflegt werden, denn sie sind auch außerhalb der Informationsbereitstellung in einer horizontalen Organisationsstruktur relevant.

Die externe Modellierung kann deshalb nur ein temporäres Provisorium sein, das nach und nach entfallen und aus dem Bestand heraus generiert werden sollte.

In unserem Fall müssen wir zum Beispiel eine Beziehung zwischen unseren Produkten und den Produkteigenschaften und -funktionen herstellen.

Diese Informationen liegen uns in der Technischen Dokumentation nicht oder nur sehr bedingt vor. Denn sie werden in externen Systemen und ggf. auch von anderen Abteilungen gepflegt.

Können wir zum Beispiel Informationen aus einem PIM-System anzapfen, können wir die Beziehung unseres Produkts c-rex.net DTS mit den Eigenschaften und Funktionen automatisch in Beziehung setzen:

<iirds:ProductVariant rdf:about="https://www.c-rex.net/ns/iirds/td/products#c-rex-net-services-c-rex-net-dts">
  <rdfs:label xml:lang="en">c-rex.net DTS</rdfs:label>
  <iirds:has-identity>
    <iirds:Identity>
      <iirds:identifier>CREXDTS-0001</iirds:identifier>
        <iirds:has-identity-domain rdf:resource="https://www.c-rex.net/ns/iirds/pim/product
     </iirds:Identity>
  </iirds:has-identity>
  <iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-net-gmbh"/>
  <rdfs:seeAlso rdf:resource="https://www.c-rex.net/ns/iirds/pim/products-external#c-rex-net-services-c-rex-net-dts"/>
</iirds:ProductVariant>
<iirds:ProductProperty rdf:about="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds">
    <rdfs:label xml:lang="en">iiRDS</rdfs:label>    
    <rdfs:seeAlso rdf:resource="https://www.c-rex.net/ns/iirds/pim/products-external#formats-tekom-iirds"/>
</iirds:ProductProperty>

Aus dem PIM-System werden damit Metadaten und Beziehungen extrahiert und mit unserer Rumpfstruktur verknüpft. Über das Prädikat rdfs:seeAlso hat iiRDS sogenannte Extension Points, um externe Ontologien an den Klassen iirds:ProductVariant, iirds:Component und iirds:ProductProperty anzubinden.

Wenn dies alles entsprechend definiert und nach Möglichkeit automatisiert aus Bestandsdaten generiert ist, hat man einen Knowledge Graph, der die Produkt-, Anlagenstrukturen abbildet und für konkrete Anwendungsfälle ein Abbild der Realität schafft. Damit hätten wir also den wesentlichen Teil eines Digitalen Zwillings.

Verknüpfung der Informationseinheiten

Nachdem wir die für unseren Anwendungsfall notwendigen Basisbeziehungen und Endpunkte definiert haben, wird es nun deutlich einfacher, zumindest aus Systemsicht.

Wir generieren nun die Metadaten für einen Blogpost und stellen Beziehungen zu anderen Objekten her.

Das setzt natürlich redaktionelle Disziplin voraus. Bei der Inhaltserstellung müssen bereits entsprechende Informationen zu einem Topic erfasst werden, die (noch) nicht automatisiert ableitbar sind.

Für den Blogbeitrag Nie wieder Probleme mit Daten im falschen Format generieren wir die Metadaten für unser DITA Topic und stellen Beziehungen zur im Vorfeld definierten Basiskonfiguration her.

Damit können wir in unser System basierend auf c-rex.net IDS beliebige Abfragen implementieren, um unsere AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen schnell und mit wenigen Klicks zu den für sie relevanten Informationen zu führen.

<iirds:Topic rdf:about="https://www.c-rex.net/ns/iirds/td/cms/c-rex-dts_001_de-DE">
    <iirds:has-topic-type rdf:resource="https://www.c-rex.net/iirds/td#Blogpost"/>
    <iirds:is-part-of-package rdf:resource="urn:uuid:17f7aa78-bb05-4b8a-b9de-0323e8f32657"/>
    <iirds:title xml:lang="de-DE">Nie wieder Probleme mit Daten im falschen Format</iirds:title>
    <iirds:has-abstract xml:lang="de-DE">Nie wieder Probleme mit Formatvielfalt, .....</iirds:has-abstract>
    <iirds:language>de-DE</iirds:language>
    <iirds:revision>001</iirds:revision>
    <iirds:dateOfCreation>2021-10-05</iirds:dateOfCreation>
    <iirds:dateOfLastModification>2021-10-05</iirds:dateOfLastModification>
    <iirds:is-version-of>
        <iirds:InformationObject rdf:about="https://www.c-rex.net/ns/iirds/td/cms#c-rex-dts"/>
    </iirds:is-version-of>
    <iirds:has-content-lifecycle-status>
        <iirds:ContentLifeCycleStatus>
            <iirds:dateOfStatus>2021-10-23T19:08:08.569+02:00</iirds:dateOfStatus>
            <iirds:has-content-lifecycle-status-value rdf:resource="https://www.c-rex.net/ns/iirds/td/status#Published"/>
        </iirds:ContentLifeCycleStatus>
    </iirds:has-content-lifecycle-status>
    <iirds:is-applicable-for-document-type rdf:resource="https://www.c-rex.net/ns/iirds/td/subjects#subjects-article"/>
    <iirds:relates-to-component rdf:resource="https://www.c-rex.net/ns/iirds/td/components#c-rex-net-services-c-rex-net-dts"/>
    <iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-microsoft-word"/>
    <iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-custom-xml"/>
    <iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-ditaxml"/>
    <iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-xliff"/>
    <iirds:relates-to-product-feature rdf:resource="https://www.c-rex.net/ns/iirds/td/formats#formats-tekom-iirds"/>
    <iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-creation"/>
    <iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-translation"/>
    <iirds:has-subject rdf:resource="https://www.c-rex.net/ns/iirds/td/tdprocesses#td-processes-publication"/>
    <iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-net-gmbh"/>
    <iirds:relates-to-party rdf:resource="https://www.c-rex.net/ns/iirds/td/parties#parties-c-rex-rc"/>
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/xhtml+xml</iirds:format>
            <iirds:source>content/html5/de-DE/posts/c-rex_dts.xhtml</iirds:source>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

Fazit

Mit diesem Blogbeitrag haben wir in einem überschaubaren Rahmen die Vorgehensweise auf dem Weg in die Digitalisierung aufgezeigt.

Im ersten Schritt geht es darum, für einen konkreten Usecase die relevanten Metadaten und Beziehungen zu identifizieren. Wir betrachten nur sehr begrenzt den Rest der Welt und was alles sonst noch relevant sein könnte.

Dennoch ist es wichtig, stets das Große und Ganze im Blick zu haben. Und dabei hilft uns der Standard iiRDS, der weit über einen konkreten Anwendungsfall hinaus definiert ist.

Wir können also loslegen, so wie wir es bei HOMAG bereits für einen ganz anderen Anwendungsfall umgesetzt haben. Auch hier haben wir klein angefangen wohl wissend, dass das implementierte System ausbaufähig ist und um weitere Anwendungsfälle wie Predictive Maintenance jederzeit erweitert werden kann.

Wenn Sie sich gerade mit den Themen Content Delivery, Industrie 4.0 und IoT sowie der Verknüpfung von modularisierter technischer Dokumentation beschäftigen, legen Sie los: Think big and start small.