Spitz geklammert – wie Sie Ihren Inhalten mit XML künstliche Intelligenz verleihen

Teil 4 der BLOGSERIE:

„Vom Verlag zum E-Publisher – wie Redaktionen und Lektorate die digitale Transformation erfolgreich meistern.“

Lesedauer: 8 Min.

XML ist die vorherrschende Datengrundlage und Standard für medienneutrale Inhaltsaufbereitung. Es basiert auf einer DTD oder einem Schema als strukturelles Regelwerk für einen Inhalt. Für Redaktionen und Lektorate von besonderer Bedeutung ist die Behandlung inhaltlicher Elemente innerhalb des Regelwerks. Sie sollten semantisch ausgeformt sein und Funktionalitäten der Endanwendung im Blick haben.

Lesen Sie hier die anderen Beiträge dieser Blogserie:

• Teil 1 „Erfolgreiches E-Publishing: Welche Inhalte Sie digital veröffentlichen sollten“
• Teil 2 „Content-Töpferei: Wie Sie Ihre Inhalte beherrschen und formen“
• Teil 3 „Achtung, Gutenberg-Falle! Wie Sie Autoren im E-Publishing führen“
• Teil 5 „Auf Knopfdruck – wie Sie im E-Publishing den Workflow in Schwung bringen“
• Teil 6 „Such-Potenzial – Wie Sie im E-Publishing Inhalte auffindbar machen“
• Teil 7 „Tür auf, Tür zu – wie Sie im E-Publishing den Zugang zu Ihren Inhalten verwalten“

Was ist XML?

„Das ist doch dieses Spitzklammer-Zeug“, hört man häufig aus Redaktionen und Lektoraten, wenn man sie auf XML anspricht. Was zeigt, dass man sich mit Daten eher weniger gern beschäftigt, XML „ist Technik“. „Na klar arbeiten wir in XML“, verkünden im Brustton die Herstellungsabteilungen, als ob damit alle Probleme im elektronischen Publizieren gelöst wären.

Vorab: Dieser Beitrag ist weder eine Einführung noch gar eine Schulung zur Extensible Markup Language (XML).. Ich möchte hier vielmehr zeigen, wie Sie in Lektorat und Redaktion mit XML umgehen sollten, nämlich vom Inhaltlichen her kommend mit dem Ziel, die Datenbasis Ihrer Inhalte „intelligenter“ zu machen.

Dabei möchte ich Sie hier von Spitzklammern möglichst verschonen. Was ehrgeizig erscheint, wenn man über XML spricht, aber, wie Sie sehen werden – beinahe – gelingt.

Vorausgeschickt werden muss auch, dass die Aufbereitung von Inhalten in XML aufwendig ist, jedenfalls aufwendiger als eine reine Satzerfassung. Für eine einfache E-Book-Version oder eine „Blätteranwendung“ lohnt sich der Aufwand nicht, hier reicht z.B. ein PDF aus. Anders hingegen bei einer Verwendung in Portalen und Rechercheplattformen.

Der Standard

XML ist ganz vorherrschend die Datengrundlage für medientechnisch neutrale Datenaufbereitung und Produktion in Richtung Print und Online. Es ist nicht nur in der praktischen Anwendung ein Standard, sondern vor allem ein vom W3-Konsortium erarbeiteter und empfohlener Standard, also ein „offizieller“, wenn man so will.

Es gibt Stimmen und Ansätze, dass XML in der Praxis viel zu kompliziert wäre und man elektronische Anwendungen besser auf dokumentenorientierte Datenbanken aufsetzen möge, weil die alles an Inhalten ohne weitere Aufbereitung verstünden.

Ich folge dem allenfalls bedingt, weil XML in der Verständlichkeit und der Weiterverarbeitung flexibler und gegenüber Veränderungen weniger anfällig ist. Wenn die Menschen in der Steinzeit XML in die Höhlenwände gemeißelt hätten, könnte man es heute noch verstehen, denn XML ist lesbar und streng logisch.

Regelwerke

Der Standard beruht zunächst darauf, dass für einen Inhalt ein Regelwerk erstellt wird, eine sogenannte document type definition (DTD) oder ein sogenanntes Schema. Innerhalb des Regelwerks werden Elemente definiert, welche die Strukturen des jeweiligen Inhalts benennen und beschreiben. Diese Beschreibungen können innerhalb der Elemente durch Attribute verfeinert werden. Wie eine Zwiebelschale legt das Regelwerk, sich von der größten äußeren zur kleinsten inneren Einheit vorarbeitend fest, in welcher Reihenfolge, Zahl und Logik untereinander die Elemente vorkommen dürfen.

Ob man eine DTD oder ein Schema verwendet, ist fast eine Geschmackssache des Entwicklers. Der wesentliche Unterschied besteht darin, dass ich im Schema ein Element weiter typisieren kann, ob es sich beispielsweise um eine Zahl, ein Datum oder Text handelt, und ich die Häufigkeit des Vorkommens definieren kann. Die Beschreibung wird damit schärfer und die maschinelle Überprüfbarkeit des Inhalts genauer.

Daneben beinhalten DTD und Schema noch eine Vielzahl anderer Informationen wie z.B. verwendete Zeichensätze, womit wir uns an dieser Stelle aber nicht weiter beschäftigen. Es wird nämlich in Lektorat und Redaktion nie Ihre Aufgabe sein, ein solches Regelwerk zu schreiben. Je nach Inhalt kann dieses außerordentlich komplex werden und man überlässt seinen Aufbau tunlichst den Datenspezialisten in der Technik.

XML-Elemente sind Inhalt

Was diese Datenspezialisten aber in aller Regel nicht können, ist die Zerlegung von Inhalten in typologische Bestandteile und die entsprechende Definition eines Elements. Hier bewegen wir uns im inhaltlichen Bereich, das ist Ihr Metier und hier benötigt der Datenspezialist Ihr Wissen und Ihre Hilfe. Wir wollen deshalb im Folgenden „mit den Elementen spielen“ und dabei möglichst vereinfachte Beispiele wählen.

Wichtiger als das Verstehen einer DTD bzw. des Schemas insgesamt ist für Sie das Erkennen inhaltlicher Elemente und deren Verwendung in einer XML-Datei, als die Ihr Inhalt irgendwann vorliegt. Wenn im Regelwerk z.B. die Elemente Vorname und Nachname definiert wurden, steht im XML-Datenstrom irgendwo

                        <Vorname>Hermann</Vorname>

<Nachname>Ruckdeschel</Nachnahme>

D.h., der Klartext des Inhalts wird in sogenannte Tags, nämlich Start- und Ende-Tags gehüllt, das Element wird „befüllt“.

Grenzen des Standards

Und hier kommt XML an die Grenzen des Standards. Standard sind nämlich nur die Form des Regelwerks und die Nomenklatur als solche, nicht aber die Bezeichnung und Verwendung der Elemente. Deshalb sagt „wir erfassen in XML“ überhaupt nichts, sondern es kommt elementar darauf an, wie das Regelwerk aufgebaut wurde und wie die Elemente befüllt werden.

Hätte ein rein technisch und nicht redaktionell denkender Entwickler nicht die Elemente Vorname und Nachname definiert, sondern stattdessen E1 für Element 1 und E2 für Element 2, stünde im XML

                        <E1>Hermann</E1>

                        <E2>Ruckdeschel</E2>

Das würde technisch in einer programmierten Umsetzung genauso funktionieren, ist aber nicht mehr sprechend und deutlich fehleranfälliger. Ein Mensch, der sich über DTD und XML-Datei beugt, bräuchte einige Zeit, bis er erkennt, dass hinter <E1> immer ein Vorname steht und dann <E2> wohl immer der zugehörige Nachname ist.

Prüfprogramme, sogenannte Parser, können XML-Dateien auf die Einhaltung des Regelwerks überprüfen. Hätte die Erfassungskraft aus Unkenntnis oder Verwechslung getaggt

                        <E1>Ruckdeschel</E1>

                        <E2>Hermann</E2>

würde der Parser den Fehler nicht bemerken, denn die Elemente sind definiert, stehen an der richtigen Stelle und sind befüllt. Inhaltlich falsch wäre das XML trotzdem. Ein sprechendes Tagging hätte die Erfassungskraft hoffentlich stutzen lassen.

Semantik, Semantik, Semantik!

Deshalb ist von außerordentlicher Wichtigkeit für Qualität, Verständlichkeit und weitere Verarbeitung, dass der Aufbau der Regelwerke und der darauf basierenden XML-Dateien so semantisch wie irgend möglich erfolgt.

Dies ist ein Punkt, an dem Redaktion und Lektorat entscheidend einwirken können. Nur Sie können darüber befinden, in welche semantischen Bestandteile ein Inhalt sinnvoll zerlegt werden kann und wie ein sprechendes Element sinnvoll heißen soll. Bei der Benennung können insbesondere auch Begriffe der jeweiligen Fachsprache Verwendung finden.

Bei der Bildung von Elementen muss ganz stark von der ins Auge gefassten Fachanwendung und ihren Funktionalitäten her gedacht werden; auch das kann die technische Abteilung nur bedingt.

Beispiele

Ein Lernmodul in multiple-choice-Form wird wohl die Elemente Frage und Antwort benötigen, letzteres mit dem Attribut richtig oder falsch.

Frage und Antwort wird es auch innerhalb eines Elements Interview geben, wenn ich will, dass diese in der Anwendung wechselweise eingeblendet werden.

In Fachtexten kann es Sinn machen, Definitionen als <definition> zu taggen, um diese in einem eigenen Bereich navigierbar zu machen oder ein Glossar zu erzeugen. Beispiele, Praxistipps, Zitate, Mustertexte, Berechnungen sind es wert, als eigenständige Elemente definiert und datentechnisch behandelt zu werden. Ein Personen- oder Autorenverzeichnis wird aus den Elementen Vorname, Name, Titel, akademischer Grad, Funktion bestehen.

Sind XML-Daten intelligent?

Daten an sich besitzen keine Intelligenz. Eine XML-Datei tut nichts, ist kein ausführbarer Programmcode. Im schlechtesten Fall ist eine unsemantische XML-Struktur so aufgebaut, dass sie lediglich visuelle Satzformatierungen unterstützt und abbildet.

Aber ein XML-Konstrukt kann intelligent angelegt sein. Und eine elektronische Anwendung kann dann auf die semantischen Informationen in den Daten zugreifen und die Inhalte intelligent durchsuchbar machen und präsentieren. Gutes XML ist also die Vorstufe für eine intelligente Anwendung.

Ist XML „Künstliche Intelligenz“?

Nein – insofern müsste man die „Künstliche Intelligenz“ im Titel dieses Beitrags in Gänsefüßchen setzen, was ich hiermit nachträglich tue.

KI (auch artificial intelligence – AI) ist ein Buzzword, das allen Menschen derzeit ständig begegnet. Sie soll Autos lenken, Ereignisse vorhersagen und sich irgendwann selbst weiterentwickeln. Vor allen Dingen verspricht Sie aber Unternehmen eine Steigerung ihrer Effizienz und ihrerwirtschaftlichen Erfolge. Dass dieser Trend nun auch die Medienwelt erreicht hat, wurde auf der diesjährigen Frankfurter Buchmesse deutlich, die das Thema in mehreren Vorträgen behandelte.

Auch wenn XML an sich nicht über Intelligenz verfügt, hat es sehr wohl mit Intelligenz zu tun. Mit natürlicher, menschlicher, wie sie derzeit noch stets in der Programmierung von Anwendungen steckt. Was in den Daten nicht drinsteckt, kann in Anwendungen nicht zutage treten. Und deshalb ist es abhängig von der Intelligenz der Redaktionen und Lektorate, im XML-Regelwerk die richtigen Elemente anzulegen, die z.B. Meta-Informationen enthalten, Klassifizierungen zuweisen, Erschließung verbessern. Und das ist durchaus eine Kunst.

Das richtige Regelwerk

Die Behandlung von DTDs und Schemata und der Umgang mit ihnen sind so vielfältig wie die Verlagslandschaft. Dabei gab und gibt es immer wieder sehr groß angelegte, ganze Sparten in den Griff nehmende Ansätze wie eine Medizin-DTD, eine Jura-DTD oder themen- und werkübergreifende Verlags-DTDs.

Aktuell hat auf der diesjährigen Frankfurter Buchmesse ein technischer Dienstleister eine verlagsübergreifende XML-Struktur angekündigt und als open source bereitgestellt. In der Präsentation wurde der Anwenderkreis dann schon auf Publikumsverlage eingeschränkt. Wenn man sich das XML-Schema anschaut, kann man sagen: gut gemacht, passt auf manches, aber nicht umsonst wurden die Fachverlage ausgeschlossen. Fachinhalte haben eben sehr eigene, heterogene Strukturen.

Das andere Extrem besteht darin, jedem einzelnen Inhalt sein eigenes Regelwerk zu verpassen, was letztlich einen nicht zu unterschätzenden Aufwand für Erstellung und Pflege bedeutet.

Mittelweg

Ich halte vom zu Großen wie vom zu Kleinen wenig. Zunächst müssen jeder Inhalt und jedes Werk für sich betrachtet werden. Und brauchen dann vielleicht tatsächlich ihre ganz eigene Struktur, weil sie mit der anderer Inhalte partout nicht zusammenpasst.

Darüber hinaus ist es aber möglich und sinnvoll, Werkgattungen mit einer endlichen Zahl von Strukturausformungen zu definieren und unter einem Regelwerk zusammenzufassen, so für Kommentarwerke, bestimmte Handbücher, Reihen und Klassen von Fachzeitschriften. Hier muss jede Fachsparte und jeder Fachverlag auf die eigenen Werkformen und die Bildung von Gattungen schauen.

Soweit Teilinhalte wie z.B. Gerichtsentscheidungen in mehreren Regelwerken vorkommen, sollten sie dort nach einer einheitlichen Unterstruktur abgebildet werden. Wie überhaupt darauf zu achten ist, XML-Regelwerke modular und „baukastentauglich“ anzulegen.

Wenn Werke unterschiedliche Ausformungen besitzen, aber semantisch gleich oder ähnlich gelagerte Inhalte aufweisen, kann es gelingen, eine gröbere Metastruktur über alle diese Werke aufzuspannen.

Wenn Sie einen neuen Inhalt auf den Tisch bekommen, der elektronisch oder in mehreren Medienformen publiziert werden soll, können Sie nach der folgenden Checkliste vorgehen.

Checkliste: Wie gehen Sie vor?

Ein verletzungsfreies Handling mit den spitzen Klammern wünscht

7. Datenkontrolle

Ihr

Hermann Ruckdeschel