Standards in der geisteswissenschaftlichen Textdatenverarbeitung

Standards in der geisteswissenschaftlichen Textdatenverarbeitung Über die Zukunftssicherung von Sprachdaten Vortrag beim Workshop der Union der deutschen Wissenschaftsakademien Mannheim, den 6. Oktober 2008 C. M. Sperberg-McQueen

Einleitung

Standards in the humanities? Surely you're joking.

Die Überschrift dieses Vortrags lautet: Standards in der geisteswissenschaftlichen Textdatenverarbeitung. Es wäre verst&ae;ndlich, würde man verbl&ue;fft auf diese Überschrift gucken und sich fragen Standards? Normierung? In den Geisteswissenschaften? Kann das als Witz gemeint sein?F&ue;r ihre Hilfe bei der deutschen Formulierung dieser Gedanken habe ich Herrn Prof. Dr. Kurt G&ae;rtner und Herrn Dr. Felix Sasaki herzlich zu danken. Der Zuh&oe;rer ahnt gar nicht, wie viel er ihnen schuldet.

The humanities (Dilthey) are about meaning, not regularity. Meaning inheres particularly in the unusual, in the irregular, in the exception the rule. Humanists are habitually interested especially in the marked case. (And when we are interested in the unmarked case, our way of studying it is Verfremdung, to make it into the marked case and something we can focus upon.)

Denn Normieren heißt, regelkonform machen. Und Dilthey hat uns ja gelehrt, daß die Geisteswissenschaften sich mit dem Verstehen, nicht mit den Regelmäßigkeiten, der Dinge befassen. Und das Verstehen richtet sein Augenmerk zum großen Teil auf die Eigenart der Sache, auf die Unregelmäßigkeit, auf den Verstoß gegen die Regel. Die Geisteswissenschaft interessiert sich naturgemäß für den merkmalhaften Fall. (Und wenn man gelegentlich ausgerechnet das Merkmallose untersuchen will, pflegt man, es durch eine Art Verfremdung zum Merkmalhaften zu machen, um es schärfer sehen zu können.)

Humanists attend to the significant particularities of the text; how can that be standardized?

Jocelyn Penny Small: the database system wants you (or so the documentation will suggest) to clean up the mess that is your data. Don't clean up the mess. Preserve the mess.

Die Kunsthistorikerin Jocelyn Penny Small hat einmal bemerkt, wer ein Datenbanksystem einrichtet, kommt in Versuchung, kommt ja gerade unter Druck, die Daten schön regelmäßig einzugeben, alles klar, alles sauber, alles aufgeputzt. So läuft man aber Gefahr, die Daten leicht oder schwerwiegend zu verfälschen, denn est ist sehr leicht, beim Normalisieren die Eigenart der Daten fahren zu lassen. Man kommt sich als Geisteswissenschaftler angesichts der kalten Logik des Datenbanksystems mit seinen Schemata und seinen streng rechteckigen Datentabellen so unordentlich, so desorganisiert, vor, man möchte anläßlich der Digitalisierung aber das wilde Durcheinander in den Daten doch ein bißchen aufräumen.

Aber, wie Small uns ganz zurecht mahnt, est ist gar nicht unsere Sache, die Unordnung der geschichtlichen Überlieferung und der geisteswissenschaftlichen Daten allgemein zu zähmen. Unsre Sache ist es, mittels der kalten Logik der Datenbanksysteme die wirbelnde Unordnung des faktisch Gegebenen möglichst detailliert und wirklichkeitstreu nachzubilden, und das Durcheinander somit zu bewahren. Preserve the mess, schreibt Small.

Wie kann man das, wenn man nach Normen und Standards, und nicht nach den Eigenarten der Daten arbeiten muß?

Some have argued that humanities is so special in its requirements that we are misguided even to try to use the tools of standard information technology in the first place; what we need, according to Manfred Thaller, is an entire new discipline of historical (or: humanistic) informatics.

Manche behaupten sogar, das für die geisteswisssenschaftliche Datenverarbeitung Notwendige sei der gängigen kommerziell ausgerichteten Praxis der Informationstechnologie (und der real existierenden Normenorganisationen [standards development organizations]) so fremd, daß wir als Geisteswissenschaftler mehr Schaden als Nutzen daraus ziehen. Manfred Thaller, der als exponierter Befürworter dieses Gedankenganges gelten darf, hat sich dann konsequenterweise schon vor Jahrzehnten angeschickt, eine neue rein geisteswissenschaftliche historische Informatik zu begründen, die mit der herkömmlichen Informatik und Datenbanksystemen kaum etwas mehr als den Namen Informatik gemeinsam haben soll.

So is my title a sort of mythical beast? Could the talk just as easily have been called "Applications of unicorn hair in the semiconductor industry?"

Bezeichnet also der Titel des Vortrags also eine Art mythisches Ungeheuer? Hätte er genausogut Anwendungen des Einhornhaares in der Halbleiteranfertigung heißen k&oe;nnen?

[Pause]

You know perfectly well, of course, what my answer will be. The genre of an evening public lecture in an institution of scholarship does not really allow for a talk which is only three minutes in length. So none of you, trained as most of you are in appreciating the force of genre and its influence on the act of communication, will be terribly surprised to hear me say that no, on the contrary, standards have everything to do with humanities scholarship and the objects of our research.

Sie wissen schon genau, daß dem nicht so ist.

Zum einen läßt die Gattung des Abendvortrags in einer wissenschaftlichen Institution wie dem Institut für deutsche Sprache eigentlich keine Dreiminutenvorträge zu. Kein Mensch wird erwartet haben, daß der Vortag etwa so laute:

Standards in der geisteswissenschaftlichen Textverarbeitung?

Es gibt keine.

Das wärs. Tschüß, Ihr Lieben!

Allein die Tatsache, daß der Empfang nachher noch nicht fertig vorbereitet ist, würde das unmöglich machen.

In the first place, exceptions cannot be exceptions without the rule. Marked features are marked in contrast to other features which are, necessarily, unmarked.

Three reasons you won';t be surprised to hear me wsay ... strength of genre expectations no exception without rule -- every humanist continually seeks the rule against which to interpret the exceptions ... n.b. some think otherwise [think willard here]. they think that conceiving of a standard eans conceiving of and enunciating and meaning the demand that everyone conform to the standard. But in reality, standards are just a means of classification: conforming, non-conforming. Commercial interests may assign further meaning, but to us, that can be nebesächlich. because of who you are and wha you do, you may be particularly well placed to understand / appreciate the role (and the limits) of standards in hum. t.p.

Den Zuhörern, die die Macht der gattungsbedingten Erwartungen schon gut kennen, wird es also keine Überraschung bereiten, wenn ich sage, Nein, das ist kein Witz. Die Standards haben alles mit der Aufgabe und den Möglichkeiten der geisteswisseschsaftlichen Textverarbeitung zu tun. Aber das Verh&ae;ltnis bedarf der weiteren Er&oe;rterung.

Die Geisteswissenschaften interessieren sich wie gesagt besonders für die Ausnahme, für den merkmalhaften Fall. Aber die Ausnahme kann erst in Hinblick auf eine Regel als Ausnahme erkannt werden. Das Merkmalhafte eines jeden Phänomens wird erst im Gegensatz zu anderen notwendigerweise merkmallose Eigenschaften der Sache überhaupt deutlich. Die Regelmäßigkeit — der Standard — ist der Eigenart der Sache und damit ihrem Verstehen untrennbar verbunden.

Es wäre ein Irrtum, anzunehmen, der einzige Sinn und Zweck der Standards sei, genau vorzuschreiben, wie ein Text, ein Wörterbucheintrag, ein Lexikonartikel auszusehen habe, und daß die Standards Ausdruck der Forderung seien, alles müsse gleichgeschaltet werden. Genau genommen sind alle Standards und Normen nur Hilfsmittel zur Klassifikation der Sachen: es sind eben Definitionen. Sie erlauben es uns, die Sachen als der Norm konform oder nicht konform zu beschreiben. In den meisten kommerziellen Anwendungen verlangt man in der Tat, daß ein Gerät, oder ein Datenstrom, der jeweiligen Norm konform sei; diese Bewertung liegt aber in der Natur der Anwendung, nicht im Wesen der Standards selbst.

Talk both about stds and about their limitations. About need to handle unusual cases. About need for nuance. Perhaps talk about optimizing for common cases. Perhaps talk about McGann.

Longevity = message to future.

Ich möchte heute abend zuerst die besonderen Anforderungen erwähnen, die man an Standards stellen muß, wenn sie für geisteswissenschaftliche Anwendungen taugen sollen. Dann möchte ich einige Anforderungen und Schwierigkeiten beschreiben, die aus dem Bestreben geisteswissenschaftlicher Projekte erwachsen, um Lexika, Wörterbücher, digitalisierte Textausgaben, Korpora, und andere Grundlagenwerke, die wir erstellen, der Nachwelt nutzbar zu machen. Denn was man für die Nachwelt baut, ist eine Art Botschaft oder Nachricht an die Zukunft. Botschaften und Nachrichten kommen aber nicht immer bei dem Empfänger an. Was können und müssen wir machen, um die Wahrscheinlichkeit des Erfolgs zu vergr&oe;&ss;ern? Zwischendurch werde ich einzelne Standards erwähnen, die besonders relevant sind für die geisteswissenschaftliche Arbeit.

Anforderungen an Standards f&ue;r geisteswissenchaftliche Arbeit

Die geisteswissenschaftliche Arbeit stellt eine Reihe von Anforderungen an Standards, und wenn man für die eigene Arbeit sich einen Standard auswählen muß — eine der schönsten Attribute der heutigen Standards, ist die Tatsache, daß es derer so viele gibt, man hat eine reiche Wahl und darf bzw. muß sich eine eigene Palette davon zusammenstellen — wenn man einen Standard wählen muß, wie beurteilt man, ob er für die geisteswissenschaftliche Arbeit geeignet sei?

Es spielt dabei die Tatsache ein Rolle, daß normiert wird, was man schon gut versteht. Das heißt, das Gel&ae;ufige wird zuerst standardisiert, das Ungew&oe;hnliche erst sp&ae;ter oder gar nicht. Die Gegenstände geisteswissenschaftlicher Aufmerksamkeit widerstreben oft die Normierung. Wir untersuchen sie ja eben deshelb, weil man sie nicht vollkommen versteht. Es kann schwierig sein, geeignete Standards zu finden. Was verlangen wir als Geisteswissenschaftler von den Standards?

Breite / Vollständigkeit

- support a broader range of data than just the commercially important (e.g. in character sets, but not only there)

Erstens, die Vollst&ae;ndigkeit, oder wenigstens die Breite.

Der Standard soll f&ue;r das betreffende Gebiet so vollst&ae;ndig sein, wie m&oe;glich. Das gilt f&ue;r jede Ebene der Datenrepr&ae;sentation, vom Zeichensatz bis hin zur Text- bzw. Datenstruktur und zur semantischen Ebene: jede Ebene der Datenrepr&ae;sentation mu&ss; eine bestimmte Vielfalt an Daten darstellen k&oe;nnen.

Jede Norm f&ue;r Zeichens&ae;tze z.B. stellt einen gewissen Vorrat an Zeichen bereit. Braucht man f&ue;r die Arbeit nur eine Untermenge dieses Vorrats, so ist die Norm f&ue;r diesen Gebrauch vollst&ae;ndig genug.

In dieser Hinsicht mu&ss; der sogenannte Universalzeichensatz (UCS, Universal character set) erw&ae;hnt werden. Dieser Universalzeichensatz wird von zwei parallel entwickelten Normen definiert: Unicode (von dem Unicode-Consortium verabschiedet) und der internationalen Norm ISO 10646. Schon die erste Version von diesen Standards hatte einen Zeichensatz f&ue;r praktisch alle standardisierten Schriftsysteme der Welt bereitgestellt. Inzwischen sind durch weitere Forschung und durch die gro&ss;e Verdienste von vieler Philologen, darunter des Thesaurus Linguae Latinae und des Thesaurus Linguae Graecae, tausende von neuen Zeichen aufgenommen worden, die in historischen Schriftsystemen, und in Dutzenden von Minderheitsschriften, gebraucht werden. Die historische Formen der griechischen und lateinischen Schriften sind inzwischen einigermassen gut vertreten, und in der n&ae;chsten Version von Unicode erwartet man, da&ss; auch die notwendigen papyrologischen Zeichen aufgenommen werden.

F&ue;r viele Projekte darf die Zeichensatzmisere, an die viele fr&ue;here Unternehmen der geisteswissenschaftlichen Datenverarbeitung gelitten haben, und die mancher hier noch gut in Erinnerung hat, als historisches Kuriosum gelten. Man wird abends nach einem Glas Wein vielleicht alte Geschichten erz&ae;hlen, wie man den Gro&ss;rechner des Rechenzentrums ausgetrickst hat, um die notwendigen Zeichenformen auszudrucken, aber f&ue;r viele von uns geh&oe;ren solche Bem&ue;hungen nicht mehr zur Tagesarbeit. Daf&ue;r k&oe;nnen wir den Philologen dankbar sein, die es m&oe;glich gemacht haben, den Universalzeichensatz so zu erweitern.

&Ae;hnlich bietet uns jede Anwendung von SGML oder XML (jeder XML-Auszeichnungssprache, oder XML-Wortschatz wie man in Anlehnung an das Englische XML vocabulary sagen k&oe;nnte) eine bestimmte Anzahl von Terminis an, mit denen man eine bestimmte Anzahl der Textstrukturen oder Textph&ae;nomene unterscheiden und auszeichnen kann. Wenn alle Textstrukturen, f&ue;r die man sich interessiert, mit diesen Terminis ausgezeichnet werden k&oe;nnen, so ist die Auszeichnungssprache vollst&ae;ndig genug.

Wer z.B. technische Handb&ue;cher mittels DocBook auszeichnen will, wird meistens alles in Docbook finden, was er braucht. Gedichtsammlungen gegen&ue;ber weist aber Docbook peinliche L&ue;cken auf: f&ue;r diesen Zweck kann Docbook nicht als vollst&ae;ndig gelten.

Erweiterbarkeit / Extensibilität

- allow extension

Zweitens, die Erweiterbarkeit.

Bezeichnend f&ue;r die geisteswissenschaftliche Arbeit ist, da&ss; die absolute Vollst&ae;ndigkeit ein Chim&ae;re ist, manchmal aus rein praktischen Gr&ue;nden, aber oft auch aus theoretischen.

Das sogenannte Universal Character Set (UCS), der universeller Zeichensatz von ISO 10646 und Unicode nimmt sich vor, einen Zeichenvorrat f&ue;r alle Schriftsysteme aller Sprachen bereitzustellen, einschlie&ss;lich der archaischen Zeichen alter Schriftsysteme. Und wie schon gesagt hat man hier viel geleistet. Es ist aber leicht einzusehen, da&ss; dies als Zielsetzung bewundernswert, als Beschreibung eines real existierenden und jetzt auf immer geschlossenen Zeichensatzes aber fast undenkbar ist. Denn wir k&oe;nnen jederzeit neue Schriftsysteme entdecken oder entschl&ue;sseln. Es ist ja nicht so lange her, da&ss; man durch die Entschl&ue;sseling der Schrift Linear B jede Menge neuer Einsichten in die antike Kultur gewonnen hat.

Und es gibt in der Tat eine Reihe von Schriften, die auch in der n&ae;chsten Version von Unicode voraussichtlich nicht ber&ue;cksichtigt werden.

Es gibt auch Zeichen, die man gelegentlich als Zeichen braucht, die aber kaum in einen Standard with Unicode oder ISO 10646 passen. Wilhelm Schlegel (oder was es Friedrich?) benutzt in seinen Tagebüchern oft ein Zeichen, das wie eine Parabol (oder die H&ae;lfte einer Hyperbol) aussieht, mit einem P&ue;nktchen am Fokus. Das Zeichen bezeichnet offensichtlich die Unendlichkeit, oder das Unendliche. Es w&ae;re praktisch undenkbar, Schlegels Tageb&ue;cher ohne dieses Zeichen herauszugeben oder zu digitalisieren. Aber es w&ae;re ebenso undenkbar, dieses Zeichen in das Universal Character Set eingliedern zu wollen: es geh&oe;rt nicht dahin, denn es ist nicht Teil eines kulturell getragenen Schriftsystems, sondern ist eine rein private Abk&ue;rzung.

Oder man denke an die Abk&ue;rzungen der antiken und mittelalterlichen Handschriften. Wer Handschriften mit pal&ae;ographischer Genauigkeit nachschreibt, wie etwa in den Handschriftenausgaben der arnamagnaeanischen Institute in Kopenhagen und Reykjavík, wird bestimmen m&ue;ssen, welche handschriftlichen Unterschiede hier als graphematisch anzusehen sind, und welche als blo&ss; graphetische Unterschiede nicht in die Transkription geh&oe;ren. Dazu braucht man einen gro&ss;en Vorrat an Sonderzeichen. Aber will man jede Schreibart mit in Unicode aufnehmen, die in Capellis Katalog der Handschriftenabkürzungen vorkommt?

Es ist also wichtig, da&ss; man den Standard erweitern kann, wenn es unbedingt n&oe;tig ist. Ich h&ae;tte mich zum Beispiel geweigert, den Universalzeichensatz des Unicodes und der ISO 10646 als den einzigen zul&ae;ssigen Zeichensatz von XML-Dokumenten zu akzeptieren, wenn den beiden Standards nicht die sogenannte Private Use Area eingegliedert w&ae;re, mittels derer man den Standardzeichensatz erweitern kann.

Die Zeichen der Private Use Area sind nicht standardisiert, und bed&ue;rfen der Dokumentation und der Sonderbehandlung, d&ue;rfen also nur dann benutzt werden, wenn es dringend notwendig ist. Aber es ist eben manchmal dringend notwendig, einen Standard zu erweitern. Es ist gut, wenn der Standard diese M&oe;glichkeit von vornherein anerkennt und daf&ue;r Regel anbietet.

In der Praxis kann man oft die Lücken eines Standards wenigstens zum Teil auf h&oe;heren Ebenen wieder f&ue;llen. Wenn man z.B. wie manche Sachkundige wom&oe;glich vermeiden will, Zeichen im Private Use Area von Unicode direkt zu benutzen, kann man die notwendigen Zeichen des Textes durch Auszeichnungen in einer Auszeichnungssprache darstellen, etwa mit einem XML-element namens Zeichen oder char, wie es in der Auszeichnungssprache MathML oder in den Richtlinien der Text Encoding Initiative beschrieben wird. Diese Ausweichm&oe;glichkeit, die Flucht auf die h&oe;here Ebene, hat ihre Nachteile (die unterschiedliche Darstellung der Zeichen sticht z.B. ins Auge), darf aber nicht vernachl&ae;ssigt werden.

Bei der Auszeichnung der Textstruktur st&oe;&ss;t man etwas schneller an die Grenzen der vorhandenen Standards, die XML-basierte Auszeichnungssprachen definieren. Die Richtlinien der TEI behandeln eine reiche Vielfalt an Textstrukturen, die man in anderen &oe;ffentlich zug&ae;nglichen Auszeichnungssprachen (wie etwa Docbook oder HTML) vermi&ss;t. Ihr Ziel war es ja, die Auszeichnung von Texten zu erm&oe;glichen, die f&ue;r die geisteswissenschaftliche Forschung interessant sein k&oe;nnten. Das hei&ss;t aber, da&ss; sie beliebige Texte, beliebige Gattungen, in beliebiger Sprache, f&ue;r beliebige wissenschaftliche Interessen, behandeln m&ue;ssen. Manches ist da verh&ae;ltnism&ae;&ss;ig gut ausgebaut, aber L&ue;cken gibt es da genug.

Es ist daher Grundprinzip der TEI-Guidelines, da&ss; man die Auszeichnungssprache erweitern und umdefinieren kann, ohne deswegen den Richtlinien nichtkonform zu sein. Viele Elemente k&oe;nnen mit Hilfe des Attributs type ohne gro&ss;en Aufwand spezialisiert werden. Neue Elemente k&oe;nnen der Sprache hinzugef&ue;gt werden. Fast alle vordefinierte Elemente der Auszeichnungssprache d&ue;rfen weggelassen werden. Die Grundstruktur existierender Elemente darf ge&ae;ndert werden. Mit diesen Mitteln, versucht man in der TEI die Ausnahmefreundlichkeit der Richtlinien und die Toleranz für Spezialfälle zu erh&oe;hen.

Man kann nat&ue;rlich noch mehr machen.

Der Sinn des Namens Extensible Markup Language (erweiterbare Auszeichnungssprache) besteht darin, da&ss; man mit XML beliebige Textstrukturen auszeichnen kann, eben weil man eigene XML-Tags, und damit ganze eigene Auszeichnungssprachen, definieren kann.

Bei der Entwicklung von XML und vordem von SGML hat man die Erweiterbarkeit der Auszeichnungssprache dadurch garantiert, da&ss; man gar keine Auszeichnungssprache definiert hat (der Name ist historisch begr&ue;ndet, ist aber irref&ue;hrend), sondern nur eine Metasprache zur Definition von Auszeichnungssprachen definiert hat. Hier sieht man eine wichtige Methode der Erweiterbarkeit, die ich die Flucht in die Metasprache, oder die Flucht in die Abstraktion nenne. Eben weil man &ue;ber die richtige Auszeichnungssprache uneinig ist, einigt man sich darauf, da&ss; ein jeder eine eigene Auszeichnungssprache mu&ss; definieren k&oe;nnen.

Toleranz für unvollständigkeit

- support partial information

Es ist auch wichtig, da&ss; der Standard es dem Wissenschaftler freil&ae;&ss;t, Informationen unvollst&ae;ndig anzugeben, denn manchmal wei&ss; man eben nicht alles &ue;ber die Gegenst&ae;nde der Untersuchung.

Dies kann eine heikle Sache werden, denn die automatische Nachpr&ue;fung der Daten um Vollst&ae;ndigkeit ist ein wichtiger Hilfsmittel, um Fehler bei der Dateneingabe und bei der Verarbeitung und Wiederspeicherung der Daten zu entdecken.

Botschaften an die Zukunft

But some of the biggest challenges for hum. computing come from the fact that in the nature of things, our goals include the preservation of information from and about the past, to ensure its accessibility in the future.

Soweit zu den Anforderungen, die wir als Geisteswissenschaftler an die Standards stellen m&ue;ssen.

Es gibt auch einige Anforderungen, die an die geisteswissenschaftlichen Projekte gestellt werden, eben weil unsere Projekte als Ziel haben, Werkzeuge f&ue;r die Nachwelt vorzubereiten.

Lebensdauer der Technik und der Daten

Computer hardware comes and goes. You may plan for a two- or three-year replacement cycle, or you may try to keep laptops or other machines for five years. Five-year old machines, however, have an alarming tendency to break down without warning. You're not likely to have any computer equipment on a twenty- or thirty-year, or even a ten-year replacement cycle.

Die Computertechnik entwickelt sich nach wie vor im rasenden Tempo. Viele Organisationen rechnen damit, da&ss; alle Hardwares jede zwei bis drei Jahre ersetzt werden; manche versuchen, die Maschinen im Durchschnitt f&ue;nf Jahre lange in Betrieb zu halten — Maschinen im Alter von f&ue;nf Jahren neigen aber zu unerwarteten und katastrophalen Pannen. Wer denkt schon daran, Rechner im Drei&ss;ig- oder Zwanzigjahrenzyklus, oder selbst im Zehnjahrenzyklus, zu erneuern?

Software often lasts somewhat longer. Individual versions of software come and go, but a given brand may be available, or even remain dominant, for a decade or more.

Die Softwares bleiben oft etwas l&ae;nger leistungsf&ae;hig. Die verschiedenen Versionen einer Software ersetzen sich vielleicht regelm&ae;&ss;ig, aber es gibt durchaus Softwares, die jahrzehntelang zug&ae;nglich sind, oder sogar jahrzehntelang den Markt beherrschen. Jahrzehntelang, aber man kann noch nicht sagen: &ue;ber viele Jahrzehnte hinweg. (Tustep, jetzt bald im Alter von drei&ss;ig Jahren, ist ja in der Softwarewelt ein Greis.)

But the data we work with and care about often has a much longer life. Our contract with the telephone company may run for five, or ten, or fifty years. Health records may — ought, ideally — to last our lifetimes or longer. Information about parents' and grandparents' medical histories may be crucial to a physician trying to make a diagnosis. Buildings may have a thirty-year depreciation schedule for tax purposes, but in reality they may last much longer than that.

Aber die Daten, um die wir uns k&ue;mmern, leben viel l&ae;nger. Selbst kommerzielle Daten bleibe viel l&ae;nger aktuell, als Hardware und Software. Der Vertrag mit dem Telefondienst l&ae;uft f&ue;nf, oder zehn, oder f&ue;nfzig Jahre. Die &ae;rztlichen Unterlagen sollten idealerweise uns das ganze Leben lang zugreifbar bleiben, oder noch l&ae;nger, denn die [medical history] unserer Eltern k&oe;nnen durchaus bei der Diagnose von Belang sein. F&ue;r Steuerzwecke haben oft Immobilien eine Abschreibungsdauer von etwa drei&ss;ig Jahren, werden aber viel l&ae;nger in Stand gehalten.

Und das sind nur die einfachsten rein kommerziellen Beispiele. Wer die menschlichen Sprachen, Literaturen, und Kulturen als Forschungsgegenstand hat, pflegt, Daten im Alter von f&ue;nf bis zwanzig Jahrhunderte zu verarbeiten. Selbst die Vorbereitung eines W&oe;rterbuches nimmt in manchen F&ae;llen mehr Zeit in Anspruch, als die Geschichte der elektronischen Rechentechnik aufzuweisen hat.

If we have to re-create all the data we care about, every time we change hardware or software, the cost will often be prohibitive. If we have to tranform all our data, by importing it into the new system, the cost will still be high. If the import process is lossy, the cost will be higher.

Wenn wir bei jeder neuen Maschine, bei jeder Aneignung einer neuen Software, alle Daten wieder neu erstellen m&ue;&ss;ten, so k&ae;men wir nie &ue;ber die Anfangsstadien unserer Projekte hinaus.

It is much better to have our data in a form that can remain unchanged for a data lifteime, that can be used as a long-term archival format, and that allows easy transformation into application-specific formats. How do we do it? How do we future-proof our data?

Wenn wir unsere Daten und Forschungsresultate, und die Werkzeuge, die wir uns bauen — Korpora, Ausgaben, W&oe;rterb&ue;cher, Lexika — nicht nur f&ue; den eigenen Gebrauch erhalten wollen, aber noch &ue;ber das eigene Leben hinaus der Nachwelt zur Verf&ue;gung stellen wollen, sollten wir uns ernsthaft dar&ue;ber Gedanken machen, wie wir die Daten in einer dauerhaften und nachhaltbaren Form [Format?] speichern k&oe;nnen, aus der wir wenns notwendig ist auch anwendungsspezifischen Formen ableiten k&oe;nnen. Wie macht man das? Wie sichert man die Daten f&ue;r die Zukunft?

The remainder of this paper offers a partial answer to these questions. Section 2 applies a general model of communication to the problem and identifies several possible points of failure, which can be avoided with the right practices. Section 3 discusses one particular problem at greater length: how to preserve the semantics of the data.

Man kann diese Fragen vielleicht am besten beantworten, wenn man hier die Botschaften an die Zukunft im Licht eines allgemeinen Kommunikationsmodells betrachtet, das vom dem gro&ss;en Strukturalisten Roman Jakobson 1960 vorgeschlagen wurde.

Erfolg und Fehlschlag

As we will use the term, to future-proof our data means to ensure (or at least improve the chances) that the data we invest in today will be usable in the future. Structurally, this is analogous to the problem of exchanging data with other people or organizations: the future is another country; they do things differently there. There are some twists. The recipient we have in mind is likely to be us, or our successor, or our organization, in the future — but in many essential ways we do not know who the recipient is: we do not know what we will have learned between now and then, our organization may have changed or taken over or been taken over by other organizations, with resulting changes to culture, goals, and needs. The situation may have changed dramatically. (This is not at all unusual when new data or software is provided: long before the original plan is completed, the delivery of the first installments may reach critical mass and change the situation dramatically — one reason to plan to review your plan periodically.) And even if the goals of the recipient are substantially what we foresee, we do not know what the technical environment will be, what hardware or software will be used to exploit it. We don't know and cannot ask, because communications with the future are one-way only, at least until time travel becomes reliable and prices come down to something we can fit onto our project budget. So the recipient cannot receive our message, inspect it, and then write us back saying "Message not understood; please re-transmit." When you send messages to the future, you get no feedback. It's a little bit like sending messages in a bottle, or to a spies so deep undercover that they cannot send any acknowledgements to your messages.

Als Zukunftsicherung der Daten bezeichne ich das Bem&ue;hen, sicherzustellen (oder wenigstens die Wahrscheinlichkeit zu erh&oe;hen, da&ss; die Daten, die wir m&ue;hevoll und teuer erstellen, f&ue;r die Nachwelt nutzbar seien. Im Grunde genommen gleicht dies dem Problem des Datenaustausches mit anderen Projekten oder Organisationen: Die Zunkunft ist ein fremdes Land, man macht dort vieles anders. In mancher Hinsicht unterscheiden sich diese zwei Probleme: der Empfänger der Daten z.B. sollen wir oft selbst sein, und nicht andere, aber im wesentlich kennen wir auch dann den Empf&ae;nger auf eine sehr unvollkomme Weise. Wir werden bis dahin einiges gelernt, oder vergessen, unsere Institutionen werden vielleicht neue Richtungen eingeschlagen haben. Die Lage kann sich drastisch ge&ae;ndert haben. (Das kommt nicht ganz selten vor, wenn man neue oder neuartige Daten und Softwares bereitstellt: lange, bevor man den Originalplan zu Ende gef&ue;rht hat, k&oe;nnen die ersten Teillieferungen die Lage grundliegend &ae;ndern.)

Und selbst wenn der Empf&ae;nger die selbe Ziele hat, die wir erwarten, kennen wir doch nicht die technische Umgebung, in der er arbeitet, wir wissen nicht, was f&ue;r Hardware und Software zur Verf&ue;gung stehen wird, unsere Daten auszunutzen. Wir wissen es nicht und k&oe;nnen es nicht erfahren, denn die Kommunikation mit der Nachwelt ist eine Art Einbahnstra&ss;e, ein Write-Only Datentr&ae;ger. Der Empf&ae;nger kann nicht unsere Botschaft empfangen und inspizieren, und dann uns eine R&ue;ckmeldung schicken Botschaft nicht verstanden. Bitte nochmals senden. Wer Botschaften an die Zukunft sendet, bekommt keine R&ue;ckmeldungen. Es ist eine Art Flaschenpost, oder als ob man Botschaften an Spionen senden w&ue;rde, die so geheim arbeiten m&ue;ssen da&ss; sie sich keine R&ue;ckmeldung leisten k&oe;nnen.

So it behooves us to anticipate as fully as possible all the ways our messages can fail, to try to forestall them. We propose to do this by considering a model of communication originally proposed by the linguist Roman Jakobson in 1960 [Jakobson 1960].

In dieser Lage m&ue;ssen wir alle Fehlerm&oe;glichkeiten des Vorgangs voraussehen und vermeiden. Alle Bruchstellen der Verbindung zwischen Sender und Empf&ae;nger m&ue;ssen untersucht werden, um m&oe;gliche Pannen zu vermeiden. Dazu diene uns das Kommunikationsmodell von Roman Jakobson.

A message, Jakobson pointed out, obviously has a speaker (or sender) and a hearer (or receiver).

Ein Mitteilung, so Jakobson, hat offensichtlich einen Sender, und einen Empf&ae;nger

The message may tell us primarily about the sender (this Jakobson calls the expressive function of language), or it may tell the receiver to do something (the conative function). But the message is usually about something else; it refers to things in the real world. The message has a referent:

Die Mitteilung kann vor allem dazu bestimmt sein, &ue;ber den Sender Auskunft zu geben. Jakobson schreibt demgem&ae;&ss; eine Ausdrucksfunktion oder emotive Funktion der Sprache und der Mitteilung zu. Oder sie kann dem Empf&ae;nger einen Auftrag oder einen Befehl geben: das ist die Aufforderungsfunktion oder die konative Funktion.

Meistens aber handelt es sich um eine Mitteilung, die sich auf eine Sachlage in der Welt (oder im Kontext) bezieht; eine so ausgerichte Mitteilung &ue;bt die referentielle Funktion der Sprache aus.

Communication takes place, however, only if the sender and receiver are in contact through some channel. The message must actually pass from the sender to the receiver. For spoken communication, this means we have to be close enough that you can hear me, or else I need a bullhorn, or I need a radio transmitter and you need a receiver, or I need to be sending a podcast and you need a player, and so on. For written works, the distance between us must be traversed by some piece of paper, or a series of papers; works written in antiquity or the Middle Ages can be read today only if at least one manuscript has, over the centuries, outwitted the enemies of information by surviving. Even in modern times, plenty of written works have disappeared, victimes of war, state censorship, or the fireplaces of surviving relatives. Language is sometimes used just to confirm that the channel is functioning correctly (Jakobson calls this the phatic function of language.) If we add the channel, Jakobson's diagram looks like this:

Die Kommunikation findet aber nur dann statt, wenn der Sender und der Empf&ae;nger k&oe;rperlich in Kontakt stehen. Die Mitteilung mu&ss; ja physikalisch vom Sender zum Empf&ae;nger kommen. Im Fall von gesprochenen Mitteilungen hei&ss;t das, da&ss; der Sprecher (der Sender) und der H&oe;rer (der Empf&ae;nger) in unmittelbarer N&ae;he zueinander sind, es sei denn, Lautsprecher oder Funkger&ae;te kommen ins Spiel. Im schriftlichen Fall mu&ss; der Schrifttr&ae;ger vom Sender zum Empf&ae;nger kommen, entweder direkt oder durch eine Art Staffellauf, wo mehrere Abschriften einen Teil der Strecke zur&ue;cklegen k&oe;nnen. Werke der Antike oder des Mittelalters kann man heute nur dann lesen, wenn wenigstens eine Hs die Feinde der Information &ue;berwunden hat und bis in unsere Zeit &ue;berlebt hat. Selbst in der Neuzeit sind viele Werke dem Krieg, der Zensur, oder den Kaminen &ue;berlebender Verwandter des Autors zum Opfer gefallen. Eine Mitteilung oder Botschaft kann auch als Zweck haben, einfach sicherzustellen, da&ss; dieser Kontakt richtig funktioniert. (Hallo? Hallo? H&oe;ren Sie? Funktioniert diese Lautsprecheranlage?) Das ist die phatische Funktion der Sprache. Wenn wir den Kontaktweg hinzuf&ue;gen, sieht die Zeichnung so aus:

Contact alone, however, is not enough. Communication only happens if the sender and receiver speak a common language, share a common code. The metalinguistic function of language is used to establish or repair the commonality of the code:

Der Kontakt aber gen&ue;gt nicht. Die Kommunikation findet nur dann statt, wenn der Sender und der Empf&ae;nger beide das selbe sprachliche System (denselben Code) beherrschen. Die metalinguistische Function der Sprache dient dazu, die Gemeinsamkeit des sprachlichen Systems herzustellen oder wieder in Gleichgewicht zu bringen.

Jakobson was interested in elucidating different functions performed by human language, but we can use his model to help us systematically about points of failure in our endeavor to send messages to the future.

Jakobson wollte die Funktionen der Sprache erl&ae;utern, aber sein Modell kann uns dazu dienen, die verschieden Ausfallarten der Kommunikation zu verstehen.

Ausfall beim Sender

The first failure point is you. You could decide to throw the data away instead of preserving and reusing it. You could delete it. That's not necessarily a bad idea. But presumably, if you're reading a paper about future-proofing your data, you have some data you've decided not to throw away.

Die erste m&oe;gliche Bruchstelle in der Verbindung von Sender und Empf&ae;nger liegt beim Sender. Wenn wir Botschaften an die Zukunft senden, dann sind wir das. Wir k&oe;nnen aus Absicht oder Versehen die Daten &ue;berhaupt nicht senden; wir k&oe;nnten sie verlieren oder l&oe;schen, statt sie aufzubewahren und wiederzubenutzen.

A second failure of the sender is failure to say what you mean. In XML terms, this means succumbing to the temptation to tag abuse, poor modeling, and other semantic ills. We'll discuss semantics in more detail below. For now, suffice it to say that you wish to be able to reuse certain information in the future, it's important to have a clear idea of what, exactly, the information you care about really is. In a document, this will lead you to want to say of one phrase that it is a programming-language keyword, of that other phrase that it is a technical term, of a third that it is a foreign word; it will lead you not to say that your current house style decrees that they are (to be) printed in italics. When (not if) your house style changes, those phrases may not all still be in italics, but the first will still be a programming language keyword, the second a technical term, the third a foreign word. If you focus on the salient information, you reduce unnecessary churn.

Oder, und das ist eine zweite Ausfallart, es k&oe;nnte vorkommen, da&ss; wir nicht sagen, was wir meinen. Im Bereich XML hei&ss;t das, wir k&oe;nnten dem Tagmi&ss;brauch, dem schlechten Modellieren, oder anderen semantischen Übeln unterliegen. Die Semantik soll sp&ae;ter diskutiert werden. Im Moment gen&ue;gt es, zu sagen: wenn mann bestimmte Informationen in Zukunft wiederbenutzen will, so ist es wichtig, im Klaren &ue;ber die Natur dieser Information zu sein. In einem literarischen Werk wird dieses Anliegen dazu f&ue;hren, da&ss; man am liebsten die eine Stelle as Personennamen, die andere als terminus technicus, die dritte als Fremdwort, auszeichnet, auch wenn in der Stilvorlage alle drei in der gleichen Schriftart (etwa: schr&ae;g) gesetzt werden sollen. Wenn man mal die Stilvorlage &ae;ndert (und das kommt doch vor), wird sich die Schriftart der einen oder der anderen Stelle &ae;ndern, doch nicht die Tatsache, da&ss; es um Personnenname, terminus technicus, oder Fremdwort handelt. Wenn man sich auf die sachliche Auszeichnung konzentriert, so vermeidet man viele unn&oe;tige &Ae;nderungen.

In a data-oriented application, the effort to say what you mean will lead you to do your modeling carefully, distinguishing constraints imposed by yhour implementation choices from constraints imposed by policy decisions from constraints imposed by the nature (as you understand it) of the things you are modeling.

The ability to say what you mean, instead of having to fit your utterance to some predefined scheme of semantic primitives is one of the most liberating aspects of SGML and XML vis a vis other methods of document representation. The responsibility for deciding what you mean and for saying it clearly is one of the most sobering aspects. With freedom comes responsibility.

Die F&ae;higkeit, das zu sagen was man sagen will, statt die Aussage einem vordefinierten Schema von semantischen Primitivfunktionen anzupassen, l&ae;&ss;t den Gebrauch von SGML und XML fast wie eine Befreiung erscheinen, wenn man an andere Methoden der Textdarstellung gewohnt ist.

Damit verbunden ist ein ern&ue;chternde Verantwortung, denn wenn man genau das sagen kann, was man sagen will, so mu&ss; man sich eben entscheiden, was man eigentlich sagen will.

Ausfall beim Empf&ae;nger

A second point of failure is the receiver. The future could decide not to listen to your message. There's not much we can do about that, except perhaps to make sure it's easy for them to know what's in the message so they don't discard it through misunderstanding what it is.

Eine zweite Bruchstelle stellt der Empf&ae;nger dar. Es kann sein, da&ss; der zukunftiger Empf&ae;nger unserer Botschaft gar nicht auf diese Botschaft achtet, nicht zuh&oe;rt, f&ae;ngt damit nichts an. Dagegen kann man nicht viel unternehmen, au&ss;er da&ss; wir es dem Empf&ae;nger leicht machen, zu wissen, worum es sich bei dieser Botschaft dreht. So kann man vielleicht verhindern, da&ss; unsere Arbeit aus Versehen weggeschmissen wird, weil der Empf&ae;nger (und hier bitte die Erinnerung daran wach halten, da&ss; es sich hier sehr oft um uns selbst handelt) nicht mehr die Bedeutung oder den Ursprung der Daten durchschaut.

A more subtle failure is also related to the receiver. Remember — appearances to the contrary notwithstanding, when you send messages to the future you do not know who the receiver is. You do not know what their capabilities are. It follows that in the bottles we send to the future it rarely makes sense to include messages with an imperative semantics. Declarative semantics are much more likely to remain relevant after the passage of time, just as declarative semantics are key to making data reusable, device independence, and application independence today.

Eine zweite Ausfallart beim Empf&ae;nger besteht darin, da&ss; wir vergessen, da&ss; wir nicht wissen, wer der Empf&ae;nger ist. Wir wissen vor allem nicht, was der Empf&ae;nger kann, was seine F&ae;higkeiten sind. Es ist folglich meistens sinnlos, ihm per Flaschenpost zu bestimmten T&ae;tigkeiten anzuregen, ihm Befehle zu erteilen, ihm eine Botschaft mit imperativer Semantik zukommen zu lassen. Eine deklarative Semantik hat viel gr&oe;&ss;ere Chancen, auch in zuk&ue;nftiger Zeit relevant zu bleiben, genauso wie die deklarative Semantik heute eine Schl&ue;sselposition hat, wenn man die Wiederverwendbarkeit, die Ger&ae;teunabh&ae;ngigkeit, und die Anwendungsunabh&ae;ngigkeit der Daten gew&ae;hrleisten will.

Ausfall beim Kontakt

A third point of failure is the loss of contact.

Die dritte m&oe;gliche Bruchstelle liegt darin, da&ss; man den Kontakt zwischen Sender und Empf&ae;nger verliert.

Diese Ausfallart tritt dann ein, wenn der Datentr&ae;ger verloren geht, aus internen Gr&ue;nden nicht mehr zu lesen ist, oder mit neu erworbenen Maschinen nicht mehr zu lesen ist. In den 80er Jahre haben gewissenhafte Benutzer ihre Dateien regelm&ae;&ss;ig auf Disketten gespeichert, um sie zu archivieren. Jetzt sitzen dies Benutzer auf einem gro&ss;en Haufen Disketten in der Gr&oe;&ss;e von 5 Zoll, die keine Maschine mehr lesen kann. Wenn man noch 3-Zoll Disketten hat, soll man sie schnell auf neue Datentr&ae;ger &ue;berspielen, bevor die letzte zug&ae;ngliche Maschine im Haus, die ein Diskettentreibwerk noch hat, spurlos verschwindet.

The media containing the message may be lost or go bad; they may become unreadable on new hardware. In the 1980s conscientious users will have religiously made archival copies of data they cared about, so today those users are saddled with large boxes of 5 1/4" floppy disks that cannot be read by any device they still possess. If they were foresighted, they copied them onto 3 1/2" disks when the time came. And the time has now come to copy them again onto some other medium, before the last floppy drive in their establishment goes the way of all flesh.

Many large organizations, including libraries, address this problem (or try to) by means of digital-library software which manages the copying of data and its metadata. But precisely because they are designed to deal with large volumes of material, these systems can resemble sausage grinders. There is a risk that nuances, subtlety — anything not written down — will be lost in the process. So write things down.

Manche Bibliotheke und Rechenzentren versuchen, diese Ausfallart dadurch auszuweichen, indem sie alle Datentr&ae;ger regelm&ae;&ss;ig kopieren. Viele setzen daf&ue;r Softwares f&ue;r die Verwaltung von digitalen Bibliotheken ein, die das Kopieren der Daten und der dazugeh&oe;rigen Metadaten bewerkstelligen. Solche Softwares sind dazu konzipiert, sehr gro&ss;e Datenmassen zu bew&ae;ltigen, aber die Verbindung zu dem urspr&ue;nglichen Kontext geht in solche Massensystem leicht verloren. Es r&ae;t sich, dabei m&oe;glichst alles aufzuschreiben, was der zuk&ue;nftiger Empf&ae;nger vielleicht wissen mu&ss;, wenn er die Daten innerhalb dieser Digitalbibliothekssoftware eines Tages herumliegen findet.

Ausfall im Code

One of the most obvious possible points of failure, at least to those who moved data among unlike systems in the 1980s and earlier, is the possibility that the recipient won't understand the coded character set (or character encoding) used in the message. Precisely because it is no important and ubiquitous, character encoding can easily become invisible to users and developers alike. It goes without saying, surely, that all data "we" produce uses the character set built into our hardware and software, whether that is the Radio Shack extension to ASCII; or the Hewlett-Packard International Character Set (so documents can be printed conveniently on the HP LaserJet down the hall), or the code page built into the IBM PC (later dubbed IBM CP 437), or IBM CP 850, or whichever of the literally hundreds of character sets IBM documented as being in use on its systems, or the one used by DECs running VMS, or a transliteration system invented by the user because the system character set turned out not to support Icelandic characters. Since the character encoding goes without saying, it is not surprising to find that messages from such systems frequently fail to document the character encoding.

Eine Ausfallart, die in der Vergangenheit den geisteswissenschaftlichen Projekten gro&ss;e Schwierigkeiten bereitet hat, ist die M&oe;glichkeit, da&ss; der Sender und der Empf&ae;nger verschieden Zeichens&ae;tze benutzen. Eben weil der Zeichensatz von so grundlegender Bedeutung f&ue;r die Textdatenverarbeitung ist, und von allen Teilsystemen unterst&ue;tzt werden mu&ss;, wird die Wahl des Systemzeichensatzes vielen Benutzern v&oe;llig unsichtbar. Stillschweigend setzen alle Softwares im System den gleichen Zeichensatz voraus. Wer nicht gegen diesen Systemzeichensatz wegen seiner Unvollst&ae;ndigkeit st&ae;ndig k&ae;mpfen mu&ss;, fragt sich gar nicht, wie der Zeichensatz des Systems &ue;berhaupt hei&ss;t, bis es beim Datenaustausch mit einem fremden System zu einer Panne kommt.

Hier hat die Entwicklung vom Universalzeichensatz unheimlich viel geholfen. Auch wenn man auf die Private Use Area zur&ue;ckgreifen mu&ss;, um Sonderzeichen zu kodieren, hat man mit dem Universalsatz einen gemeinsamen Anhaltspunkt.

The development of the Universal Character Set used by ISO 10646 and by the Unicode Consortium is a large step forward in this connection, because the inclusiveness of the character set ensures that for many or most users, all of the characters they will need are present in the character set, so that it becomes unnecessary to switch between coded character sets, to extend them, to invent new coded character sets, or to use specialized transliteration schemes. XML's use of Unicode as the underlying character repertoire means that XML data can always use Unicode — every conforming XML processor is required to understand both UTF-8 and UTF-16 — which helps avoid this failure point.

As always, however, there is a downside. Precisely because Unicode covers so many needs out of the box, it may make life even harder for you when you do need to extend it. When you need a character not included in the current version of Unicode, you will not have to look long or far to find people to tell you that you don't really need that character, because Unicode is universal: if Unicode does not have the character you need, it must not really exist. Others will tell you to file an application to the Unicode Technical Committee asking them to add the character in question, and await their answer. In a year or two, or perhaps in a few months if things go swiftly, it will be added and you can use it normally. In the meantime, they will tell you, you should wait. This may be inconvenient if you were in the middle of transcribing an important older manuscript with an unusual character in it, or if you were trying to get out the technical documentation for a new product due to ship in a few weeks.

In reality, while a finite, fixed set of characters can suffice to enumerate all the characters used in standard or widely used non-standard writing systems for known languages, it is not feasible to make a fixed, finite list incuding every character ever used or ever to be used in human writing. Some scribes or authors invent private symbols of their own; they behave like characters and it is inconvenient not to treat them as such, but if they appear only in an unpublished manuscript of C. S. Peirce or Wilhelm Schlegel and have never seen the light of day in a published book, it is hard to believe they really belong in a Universal Character Set. The correct way to handle those characters, if they really are characters and you cannot wait for the ISO/IEC JTC 1 SC 2 and the Unicode Technical Committee to add them to the Universal Character Set, or do not belong there, is to use the Private Use Area of Unicode, or some other appropriate extension mechanism, to represent them. This involves a certain amount of work: you have to teach all of your software about them, if that software knows about characters in the first place. And a certain amount of Unicode-aware software is wholly unprepared for the notion that anyone might actually need to use the Private Use Area (as are many Unicode experts, who will controvert what we say here). But more important for the topic of this paper you have to document your use of the Private Use Area carefully and thoroughly. Your goal should be to document your private usage as completely and well as the ISO 10646 and Unicode standards document the characters in the UCS. And you will need to make sure that the recipients of your messages can find the documentation. Success here may be very elusive, but you can improve the chances by having multiple copies of your character-set documentation (at the cost of introducing redundancy in your system — so make sure you and everyone else involved knows which one is the master copy and how to automate the process of replicating any updates to all of the duplicate copies), by linking to your character-set documentation from the documents that use your extensions (remembering that linking systems may change and the servers you now use may have been decommissioned when the recipient reads your message), and by inlining at least some of the essential documentation in the documents that need it.

Once the character encoding is understood by the receiver, the difficult work of understanding the data format can start. There are no limits save those of human ingenuity on the rules that can apply to data formats used on computers, and human ingenuity has been exercised energetically in the invention of formats.

Wenn der Empf&ae;nger einmal die Zeichenkodierung verstanden hat, beginnt die schwierige Arbeit, das Datenformat zu verstehen. Es sind dem menschlichen Geist beim Erstellen von Datenformaten praktisch keine Grenzen gesetzt, und der menschliche Geist hat sich dankbar auf diesem Gebiet energisch und reichlich entfaltet.

In sending messages to the future, you have three broad classes of formats to consider.

You can use a proprietary format. You can devise your own format to suit your data. You can use a publicly documented non-proprietary format.

Wer eine Botschaft an die Zukunft senden will, hat drei Arten von Datenformatten zu erw&ae;gen:

propriet&ae;re (geschlossene) Formate eigene, selbstdefinierte Formatte, den eigenen Daten und dem eigenen Bedarf nach Belieben angepast &oe;ffentlich zug&ae;ngliche, &oe;ffentlich dokumentierte Formatte

Proprietary formats are convenient when the commercial software supporting it is or will be available to both sender and receiver. They are often used for exchange of data across organizational and geographic boundaries. For data exchange with the future, however, the sometimes short lifetime of proprietary formats tells heavily against them. Neither of the authors have ever found a commercial backup program for personal computers which could read backups made by previous versions of the same program. And while commercial word processors frequently have the capability of importing files written in the format of the previous version of the program, they do not always handle earlier formats, so that if you skip a version you risk not being able to read your existing documents.

Propriet&ae;re Formate bieten sich an und sind sehr bequem, solange die dazugeh&oe;rige Software weit verbreitet ist und sowohl dem Sender wie auch dem Empf&ae;nger zug&ae;nglich ist. F&ue;r den Datenaustauch &ue;ber geographischen und organisatorischen Grenzen hinweg werden propriet&ae;re Formate oft mit Erfolg eingesetzt. Aber das meist recht kurze Leben solcher Formate macht sie f&ue;r eine Botschaft an die Zukunft eher untauglich.

For sending messages to the future, this makes proprietary formats very unwise.

Self-designed formats are always tempting, since they can easily be fitted to the specifics of the data to make them compact and convenient. But unless you are prepared to document them well enough to allow the receiver of the data to construct software to read the format, they can be very dangerous. Fewer than thirty years had passed when the scientific data from NASA's Viking Mars lander (launched 1975, landed 1976) were re-examined to see if after all they indicated signs of life on Mars. But the tape format was undocumented (or possibly the documentation existed but was not found by those who needed it), the programmers responsible for it had left NASA, and in the end the data were rekeyed from paper printouts instead of being read from tapes.

Selbstgemachte Formate sind oft eine gute Wahl, weil sie so gut der Eigenart der Daten und den Bed&ue;rfnissen des Senders angepa&ss;t werden k&oe;nnen. Aber wer ein solches Eigenformat definiert, mu&ss; damit rechnen, da&ss; er das Format auch gr&ue;ndlich dokumentieren mu&ss;. Denn ohne Dokumentation wird der Empf&ae;nger wenig mit den Daten anzufangen wissen. Es waren keine drei&ss;ig Jahre seit der Marslandung von Viking (1975 gelauncht, 1976 gelandet), als man die Me&ss;daten des Landers durchsuchen wollte, um m&oe;gliche Zeichen von Leben auf Mars zu finden. Das Magnetbandformat aber, in dem die Daten elektronisch erhalten sind, wurde leider nie dokumentiert, bzw. es wurde die Dokumentation nicht gefunden, und alle Daten wurden neu von Papierausdrucken mit der Hand eingegeben.

Open formats like XML thus appear to be the best bet for a message to the future: the format is publicly documented in many places, so knowledge of it is unlikely to disappear entirely; it is highly redundant, which helps make it resistant to minor data corruption and lost bits; and if XML goes so thoroughly out of fashion that the future receiver of the data cannot find any off-the-shelf XML parsers, the format is still simple enough to make it easy to construct a parser for it. In what follows, we will assume that messages to the future are to be sent in XML form.

F&ue;r eine Botschaft an die Zukunft scheinen aus solchen Gr&ue;nden sich die offene Formate wie XML besonders gut (oder wenigstens weniger schlecht) zu eignen. Solche Formate sind gut dokumentiert, die Dokumentation l&ae;&ss;t sich ohne gro&ss;e M&ue;he finden (wenigstens heute - wir wollen hoffen, das sei auch in Zukunft der Fall), und es scheint unwahrscheinlich, da&ss; das Wissen um XML und andere offene Formate jemals g&ae;nzlich aus der Welt verschwindet. Das XMLformat weist viel Redundanz auf, so da&ss; es Datenverfall verh&ae;ltnism&ae;&ss;ig gut widersteht — wenigstens wird es weniger Wahrscheinlich, da&ss; die Daten korrumpiert werden, ohne da&ss; man es merkt. Auch wenn XML so aus der Mode fiele, da&ss; es keine XML-softwares mehr g&ae;be, ist das Format im Grunde so einfach, da&ss; man selbst einen Parser daf&ue;r schreiben k&oe;nnte, um die Umformatierung in ein neues Format zu erleichtern.

In sum: failures of channel and code each have well understood workable solutions, for anyone willing to use them. Lack of clarity about what information you really wish to transmit, or lack of clarity about its larger implications, are unavoidable in some cases. But failures of channel and code can be avoided with high reliability by the disciplined replacement of media and the disciplined use of well documented public data formats.

Zusammenfassend kann man sagen, da&ss; gegen Ausf&ae;lle beim Kontakt und beim Code es brauchbare technische Mittel gibt, wenn man diese Mittel konsequent und diszipliniert einsetzt. Probleme beim Sender unde beim Empf&ae;nger dagegen, verlangen nicht technische sondern institutionelle L&oe;sungen.

Ausfall in der Semantik

The final locus of failure is perhaps more challenging.

Die letzte Ausfallart ist die der Semantik.

Communication can fail spectacularly even if the sender wants to talk, the receiver wants to listen, and the message is transmitted over a satisfactory channel in a code common to sender and receiver. Three distinct failure modes may be associated with the referent of the message, all involving problems grasping the meaning of the message.

Die Kommunikation kann selbst dann spektakul&ae;r versagen, wenn der Sender etwas mitteilen will, der Empf&ae;nger zuh&oe;ren will, und die in dem gemeinsamen Code verfa&ss;te Mitteilung erfolgreich beim Empf&ae;nger ankommt. Drei verschiedene Ausfallarten gibt es hier, die alle mit der Erfassung der Bedeutung der Botschaft zu tun haben.

The first appears to be hopeless: the receiver may receive, decode, and understand the message only to discover that it conveys no information the receiver finds interesting or useful. The receiver, it may be, was interested in lightning; the message, when deciphered, proved to contain data about lightning bugs. Close, but not close enough. There is little one can do to prevent this failure mode, except to try to ensure that the actual topic of the message is made clear with as little work from the receiver as feasible.

Die erste Ausfallart scheint ein hoffnungsloser Fall zu sein. Der Empf&ae;nger empf&ae;ngt, entschl&ue;sselt, und versteht die Botschaft, und entdeckt dann erst, da&ss; die Botschaft f&ue;r den Empf&ae;nger weder interessant noch n&ue;tzlich ist. Der Empf&ae;nger will vielleicht etwas &ue;ber die Weissagung in der Antike erfahren, und schaut sich die Daten an, weil sie angeblich u.a. auch von Orakeln handeln. Er findet darin aber nur Information zu einem gewissen Datenbanksystem, das ihn leider nicht interessiert. Ganz verhindern kann man wohl diese Art des Ausfalls nicht, aber wir k&oe;nnen und sollen es dem Empf&ae;nger so leicht wie m&oe;glich machen, zu sehen, welches Oracle wir eigentlich meinen.

The second failure mode occurs when the recipient succeeds in decoding the message, correctly parsing the data values, and associating them successfully with the appropriate objects in the application domain, but nevertheless fails to grasp the full import of the message. This failure mode, too, is almost completely out of the sender's control. Failure to grasp the full import of a communication is in some sense not so much a failure of communication as it is just a fact of life. Do the monthly sales figures in this XML database show that a particular product line has reached the end of its useful life and should be phased out? Or do they reflect regular seasonal variation? Or trends in the national economy? It would certainly be good to know, but the problem is related more to the understanding of science and cognition than to that of communication or data preservation.

Die zweite Ausfallart besteht darin, da&ss; der Empf&ae;nger die Botschaft erfolgreich entziffert, alle Daten richtig den betreffenden Objekten in der Anwendungsdom&ae;ne zuweist, begreift die volle Bedeutung der Botschaft aber nicht. Dagegen ist auch kein Kraut gewachsen: da&ss; man gelegentlich die volle Bedeutung einer Tatsachenmenge nicht begreift, geh&oe;rt weniger zu der Problematik der Kommunikation, als zu der Problematik des Lebens.

The third failure mode related to the referent consists in the receiver of the message failing to understand what information the elements and attributes of the XML document are to convey. This is perhaps the most widespread and difficult problem in the interchange of XML documents today, but it is avoidable, at least in part, but the methods for doing so are less routine than those for avoiding the other pitfalls we have identified. They are discussed in the next section.

Die dritte semantische Ausfallart ist ganz einfach. Man bekommt ein XMLdokument, versteht also m&ue;helos die Elementstruktur der Daten, kennt aber die vorliegende Auszeichnungssprache nicht, versteht also nicht, welche Bedeutung den Elementen und Attributen des Dokuments zuzuweisen ist. Diese Ausfallart d&ue;rfte eine der am &oe;ftesten auftretenden sein, wenn es um den Austausch von XMLdokumenten geht. Sie kann wenigsteins teilweise vermieden werden, aber nicht ohne Arbeit.

Zu diesem Thema gibt es viel zu sagen — zuviel, vielleicht, denn ich vermute, der Empfang ist inzwischen doch fertig vorbereitet, und Sie haben vielleicht schon Durst. Ich versuche mich also kurz zu fassen.

Nachhaltige Semantik

Many of the points of failure described so far have reasonably well understood, almost mechanical solutions, or else are currently well beyond any reliable solution (there is, for example, no systematic method to ensure that the future receiver of your data will beinterested in it). The preservation of semantics is less well understood and involves human understanding and intelligent human intervention at virtually every stage. This may be unavoidable: the term semantics tends to be used only for things we do not know how to manage formally or mechanically; as we learn to deal with particular problems by automatic means, they often disappear as topics from discussions of semantics and move into discussions of syntax or other concepts carefully distinguished from semantics.

A great deal of current research and development work is focused on improving our grasp of the semantics of data, sometimes by trying to make them machine-processable and sometimes by encouraging better human-readable documentation. Some progress has been made — different people, including the two present authors, have different estimates of just how much progress - - but the state of the art is currently far from making what we now call the meaning of markup completely (or even in significant part) machine-processable for current applications of markup languages. For the foreseeable future, the careful drafting of human-readable documentation remains indispensable.

Worrying about documenting markup vocabularies for XML data may strike some as unnecessary or frivolous. Do we not hear frequently that XML> is "self-documenting"? Surely if it's self-documenting, the provision of external documentation is a waste of time, a form of gilding the lily. The logic is impeccable, but the premise is false: XML is not self-documenting in any serious sense of the term. It is true that XML's relatively high redundancy and its use of explicit delimiters for all elements and all markup (start-tags, end-tags, attribute values, comments, and declarations) mean that the XML data stream indicates explicitly the beginning and ending of each element and attribute value, without requiring anything that a specialist in formal language would regard as meriting the term parsing. But the delimiters are explicit and clear only to a reader (human or machine) instructed in the rules laid down in the XML specification. It is only from documentation that we learn clearly the agreed upon structure of the information and the usage and meaning of all elements and attributes.

Given the need for human intelligence to be applied, it's difficult to provide mechanically checkable or enforceable rules for the preservation of semantics. But some general advice can be given, and the reader can be pointed to current work that suggests trends for the future. What follows are our advice on good practice for future-proofing your data by preserving the semantics of your markup and your data.

Die eigene Auszeichnungssprach dem Empf&ae;nger verst&ae;ndlich zu machen, erfordert eine gewisse menschliche Intelligenz, und es ist schwierig, daf&ue;r ein Regelwerk zu erstellen, das objektiv oder intersubjektiv nachpr&ue;fbar w&ae;re, und das uns den Erfolg garantieren w&ue;rde. Einige allgemeine Ratschl&ae;ge kann man allerdings geben.

Rule 1: think about what you wish to say.

Regel 1: Man denke dar&ue;ber systematisch nach, was man sagen will.

Man braucht nicht unbedingt, eine formale Ontologie mit Definitionen in der Web Ontology Language (OWL) oder mit Topics in Topic-map-format zu formulieren, aber es lohnt sich zu fragen: wor&ue;ber, &ue;ber welche Arten von Wesen, wollen wir Aussagen machen? W&oe;rter? Sprachen? Texten? Werken? Belegstellen? Wenn man eine formal definierte Ontologie erstellen w&ue;rde, was f&ue;r Dinge w&ue;rde man voraussetzen? Welche Eigenschaften w&ue;rde man ihnen zuweisen? Zu den Methoden f&ue;r solche systematische Überlegungen gibt es eine kleine, weit verstreute Literatur, die die Modellierung und die Erstellung von Auszeichnungssprachen behandelt. Ich empfehle allen u.a. das Buch von Eve Maler und Jeanne El Andaloussi, Developing SGML DTDs: From Text to model to markup.

The crucial first step is to think about the information to be captured in the message and make explicit decisions about the information structure, the properties of each thing (entity, in philosophical jargon), and how the things interrelate. In the case where the vocabulary is intended to capture the relevant semantics of an existing set of documents or messages, this involves a careful analysis of existing documents. In other cases, where there is no existing data, it will involve careful application design with active participation from the users of the system and domain experts. Techniques for document analysis and joint application design are well known, although not universally practiced. (Perhaps the best and fullest published account, not outdated in essentials by the development of XML, is still Maler and El Andaloussi [Maler/ElAndaloussi 1996].)

There are many ways to achieve clarity; one that often works very well is to ask explicitly which objects exist in the application domain and what their salient properties are, or at least which objects and properties are relevant for understanding the messages to be constructed. Consensus on the answers to these questions is not always possible, but it is always worthwhile if it can be achieved. An explicit list of the objects and properties involved in a particular idealization of the application domain makes it dramatically easier to describe (on the part of the sender) and understand (on the part of the receiver) a set of messages which reflect that idealization. (We intentionally omit processes from this list of basic notions, since thinking about meaning in terms of processes to be performed presents the average sender with a strong temptation to devise an imperative rather than a declarative semantics for messages. Imperative semantics are much less likely to allow reuse of the data. The development of SGML and XML were driven in part by the need for a notation to which a purely declarative semantics could be ascribed, precisely because declarative semantics are more effective for ensuring the reusability and long life of data.)

It is not obvious that all meaning can be reduced successfully to assertions about the properties of specific objects or classes of objects. But if there is meaning which cannot be captured this way, then it also eludes treatment in formal logic, for first order predicate calculus postulates individuals and allows us to express propositions regarding their existence, non-existence, and properties. An object-and-property model may be incomplete, but like symbolic logic it covers enough ground to be useful. If we know what objects our messages are to be about and what properties our messages will ascribe to them, then we have a chance of being able to be confident that our messages say what we mean. And it will be feasible to describe that meaning clearly, both in prose and at least in part by symbolic means, in first-order predicate calculus or in Prolog or in the notation of the Resource Description Framework (RDF) either using only terms of our own devising or using terms introduced by lanuages like the Web Ontology Language (OWL).

Equally important, clarity about the meanings to be conveyed makes it much easier to develop a clear and useful markup vocabulary in which to convey them.

Which brings us to the second rule:

Rule 2: design the vocabulary carefully, with a view to making document instances easy to understand.

Regel 2: die Auszeichnungssprache sorgf&ae;ltig entwerfen, mit dem Ziel, da&ss; die Einzeldokumente, die mit dieser Sprache ausgezeichnet werden, so gemeinverst&ae;ndlich wie nur m&oe;glich sein sollen.

Rein mechanisch produzierten Auszeichnungssprachen k&oe;nnen beliebig schwerverst&ae;ndlich werden.

Many people have observed that some XML vocabularies produce documents that are easy to read and understand correctly, while others are hard to decipher and thus error-prone both when documents are created and when software is developed to process them. There is no satisfactory mechanical rule for telling the difference between them; the best accounts of the difference now available stress the use of well chosen natural-language words or phrases to name elements and attributes [Maler/El Andaloussi 1996, p. 246; Wrightson 2005]. When elements and attributes have well chosen natural-language names, human readers can, if they are speakers of the natural language in question, use their language skills to interpret the markup in roughly the same way that they use it to interpret prose sentences. This explains why there is no mechanical rule for distinguishing well chosen names from ill chosen names; until we have mechanical devices for understanding unrestricted natural-language utterances, we cannot have such a rule. Choose the names carefully. Use them to give clues to help your receiver correctly identify the universe of discourse or context within which to understand the message. In the context of a bibliographic reference, a name like date may obviously refer to the date of publication (since that is the date most carefully provided in standard bibliographic citation practice). In the context of a matchmaking system, date may refer to a calendar date or to a social outing involving people who are or may become romantically attracted to each other.

Rule 3: document the vocabulary and your usage.

Regel 3: die Auszeichnungssprache, und Ihren Gebrauch dieser Sprache, dokumentieren!

Gro&ss;e Bibliotheke haben oft ein Hauptexemplar des bibliothekarischen Regelwerks, nach dem sie B&ue;cher katalogisieren. Dieses Hauptexemplar wird oft mit unbeschriebenem Papier durchschossen, damit die lokal adoptierten Zusatzregeln, die lokale Auslegung schwieriger F&ae;lle, usw. festgehalten werden k&oe;nnen. Manche geisteswissenschaftliche Projekte pflegen auch eine solche lokale Erweiterung ihres Regelwerks. Bei einer allgemein gehaltenen Auszeichnungssprache wie den Richtlinien der TEI sind solche lokale Erweiterungen durchaus notwending, und m&ue;ssen dokumentiert werden, wenn die Daten dem Empf&ae;nger verst&ae;ndlich sein sollen.

In sum, the markup vocabulary (or more generally the data format used) in any data intended to have a long life should be documented in several different ways:

Zusamenfassend sollte das Markup Vokabular (oder genereller gesagt das verwendete Datenformat) in allen für Langlebigkeit angelegten Daten auf verschiedene Arten dokumentiert werden:

general high-level documentation reference information for each element and attribute local usage notes, when local usage constitutes a consistent dialect of a public vocabulary in wider use descriptions of the meaning of the markup by giving translations of markup constructs into one or more formal notations: first-order predicate calculus, RDF, Prolog, etc. Generelle Dokumentation auf hoher Ebene Referenzinformationen für jedes Element und Attribut Anmerkungen zu lokaler Anwendung, wenn die lokale Anwendung eine konsistente Variante eines weit verbreiteten Vokabulars ausmacht. Beschreibungen der Bedeutung des Markups mittels einer 'Übersetzung der Bedeutung des Markups oder von Markup-Konstrukten in eine oder mehrere formale Notationen: Prädikatenlogik erster Stufe, RDF, Prolog etc.

Rule 4. Avoid tag abuse.

Regel 4. den Tagmi&ss;brauch vermeiden!

Tag abuse damages the utility of documentation, because when tag abuse is committed, the language described in the documentation is no longer the language in which the data are expressed. When elements or attributes in a vocabulary are used without proper regard to their defined semantics, the data become less easily reusable, because they cannot be processed so reliably.

Der Tagmi&ss;brauch (engl. Tag abuse) schadet der Nutzbarkeit von Dokumentation, denn wenn Tagmi&ss;brauch begangen wird, dann beschreibt die Dokumentation nicht mehr die Sprache, in der die Daten ausgedrückt werden. Wenn Elemente oder Attribute nicht angemessen hinsichtlich ihrer definierten Semantik benutzt werden, sind die Daten weniger einfach wiederverwendbar, weil sie nicht so verlässlich verarbeitet werden können.

Because it is defined in terms of a mismatch between the intended semantics and the actual usage, tag abuse is difficult to detect by purely automatic methods. But there are methods of making the necessary human intervention easier and more efficient. False-color proofs can be prepared, marking in striking colors the specific passages a human should check (e.g. everything tagged as the name of a person in red, or all part numbers on a blue background). The semantics of the markup may be translated into English prose so that it can be read and checked for inconsistencies or irrelevancies. See [Marcoux 2006] for further discussion.

Der Tagmi&ss;brauch definiert man als Unverträglichkeit zwischen der beabsichtigten Semantik und der tatsächlichen Verwendung eines Tags Es ist schwer, ihn mit automatischen Methoden aufzusp&ue;ren. Aber es gibt Methoden, welche das notwendige menschliche Eingreifen einfacher und effizienter machen. So genannte false-color Fassungen von Dokumenten können vorbereitet werden. Sie stellen in auffälligen Farben Markierungen von spezifischen Passagen bereit, welche ein Mensch überprüfen sollte (z.B. alles in Rot was als ein Personenname ausgezeichnet ist, oder alle Ortnamen mit blauem Hintergrund). Die Semantik des Markups kann in natursprachige S&ae;tze übersetzt werden, so daß sie hinsichtlich Inkonsistenzen und Irrelevanz überprüft werden kann. Vergleiche [Marcoux 2006] für weitere Diskussionen.

Rule 5. Provide and document ancillary documents.

Regel 5. Ergänzende Dokumente sollen bereitgestellt und dokumentiert sein.

Fifth, transmit as much relevant context as possible. Important metadata unique to a particular document should probably be recorded internally within the document, rather than externally, so that it has fewer chances to get lost. Metadata shared by many documents, however important, will typically be stored separately in order to reduce redundancy. It is helpful to have explicit links to such metadata from the documents, or at least from some sort of contents-list showing the things that belong together. As [Wrightson 2006] observes, the availability of such ancillary materials can go far toward making the proper context of interpretation for the data clear, and thus help prevent misunderstanding or incomprehension of the data.

Soviel relevanter Kontext wie möglich mu&ss; man an den Empf&ae;nger weiterleiten. Wichtige Metadaten, die spezifisch sind für ein bestimmtes Dokument, sollten wahrscheinlich eher innerhalb des Dokuments gespeichert werden als extern, so daß es weniger wahrscheinlich wird, da&ss; sie verloren gehen. Die Verfügbarkeit solchen zusätzlichen Materials kann weitreichend zum Verständnis des angemessenen Kontextes für die Interpretation der Daten beitragen, und hilft somit Mißverständnisse oder ein Unverständnis der Daten zu verhindern.

Rule 6. Validate and verify early and often.

Regel 6. Fr&ue;h und oft validieren und verifizieren!

Sixth, perform routine validation and verification. In the general case, semantics of formal languages are well defined only for well formed utterances. Invalid documents do not necessarily have any fixed interpretation. So validate early and often.

Man kann viele Problem dadurch verhindern, indem man regelmäßige Validierung und Verifikation durchf&ue;rht. Im allgemeinen Fall ist die Semantik formaler Sprachen nur für wohlgeformte Äußerungen wohldefiniert. Nicht valide Dokumente haben nicht notwendigerweise eine feste Interpretation. Es mu&ss; deshalb früh und oft validiert werden.

The same goes for semantic validation and verification procedures. (The reader should be aware that researchers and practitioners active in the field of program verification treat verification as denoting a mechanical process, and validation as denoting a related non-mechanical process. The markup community follows the tradition of formal logic in regarding validity as a mechanically checkable property; not infrequently, the term verification is used to denote the related non-mechanical process. When you talk to someone interested in the subject, make sure you understand which terminology they are using.)

Das selbe trifft für semantische Validierungs- und Verifikationsprozeduren zu. (Der Leser sollte sich bewu&ss;t sein daß Forscher und Praktiker aus dem Bereich der Programmverifikation Verifikation als mechanischen Proze&ss; bezeichnen, und Validierung als zugehörigen nicht mechanischen Proze&ss;. Die Markup Community folgt der Tradition der formalen Logik, indem sie den Ausdruck Validität als mechanisch überprüfbare Eigenschaft auffa&ss;t; nicht selten wird der Ausdruck Verifikation benutzt um einen zugehörigen nicht mechanischen Proze&ss; zu bezeichnen. Wer sich mit Anderen unterh&ae;lt, die Interesse an dem Thema haben, tut gut, sicherzustellen, daß man man sich u.U. die Terminologie sich gegenseitig erkl&ae;rt.)

To summarize:

Know what you wish to say. Choose your generic identifiers (element names), attribute names, and nesting structure carefully. Document the vocabulary, preferably in several ways:high-level prose documentationdetailed element by element and attribute by attribute descriptiondocumentation on local interpretations and usagedescription (in prose and executable code) of how to express (at least part of) the meaning of a document instance in a radically different notation such as first order logic or RDF Avoid tag abuse. Make ancillary documents (documentation, schemas, stylesheets, etc.) available to the receiver. Validate both the syntax and the semantics of your documents systematically.

Zusammenfassend:

Überlegen, was Sie &ue;berhaupt sagen wollen! Die Auszeichnungssprache mit Sorgfalt entwerfen, und die Elementnamen, die Attributnamen, und die Verschachtelungsstruktur mit Bedacht w&ae;hlen! Die Ausz.spr. dokumentieren, vorzugsweise auf verschiedene Arten: Dokumentation in Prosa auf hoher Ebene detaillierte Beschreibung jedes Elements und jedes Attributes Dokumentation zur lokalen Interpretationen und Verwendung Beschreibung, in Prosa und als ausführbarer Programmcode, zumindest eines Teils der Bedeutung einer Dokumentinstanz in einer radikal anderen Notation wie Prädikatenlogik erster Stufe oder RDF. Den Tagmi&ss;brauch vermeiden! Zusätzliche Dokumente (Dokumentation, Schemata, Stylesheets etc.) für den Empfänger bereitstellen! Sowohl die Syntax als auch die Semantik der Dokumente systematisch validieren!

Schlu&ss;wort

The data we work with and care about often has a much longer life than the applications and tools used to create it. If we have to re-create all the data we care about, every time we change hardware or software, the cost will often be prohibitive. If we have to tranform all our data, by importing it into the new system, often in a lossy process, the cost will still be high. It is much better to have our data in a form that can remain unchanged for a data lifteime, that can be used as a long-term archival format, and that allows easy transformation into application-specific formats. The outline presented here is an initial attempt to help explore the context for an answer.

Die Daten, mit denen wir arbeiten und die die für uns wichtig sind, sind oft beständiger als die Anwendungen und Werkzeuge, mit denen sie erzeugt werden. Die Kosten w&ue;rden unerschwinglich sein, wenn wir alle für uns wichtigen Daten jedesmal neu erzeugen müssten, wenn wir Hardware oder Software auswechseln. Die Kosten werden immer noch hoch sein, wenn wir unsere Daten transformieren müssen, indem wir sie in einem oft verlustbehafteten Proze&ss; in ein neues System importieren. Es ist viel besser, unsere Daten in einer Form zu haben, die unverändert bleiben kann, so lange die Daten bestehen, die als Format zur Langzeitarchivierung verwendet werden kann, und die eine einfache Transformation in anwendungsspezifische Formate erlaubt. Der hier präsentierte Entwurf ist ein erster Versuch, den Kontext einer Antwort für dieses Problem zu erkunden.

Ein abschließender Gedanke.

As already noted - we can standardize only what we understand.

Wie bereits bemerkt — standardisiert werden kann nur das, was man versteht.

So we will, as a society, have standards that do justice to the complexity, variability, and nuance of human cultures and our cultural heritage only if those with the requisite knowledge and experience participate actively in the development of appropriate standards.

Wir werden als Gesellschaft Standards, die der Komplexität, Variabilität und Vielfältigkeit menschlicher Kultur und unseres kulturellen Erbes gerecht werden, nur dann erzeugen, wenn Personen mit dem notwendigen Wissen und der notwendigen Erfahrung aktiv an der Entwicklung der Standards teilnehmen.

From the side of standards development organizations, this goal can be achieved only if adequate provision is made for public participation. In the case of the W3C, which I know best, several features of our organization and process have been designed with this in mind. W3C membership dues for non-profit organizations are deeply discounted. When appropriate, W3C working groups may include experts to participate in the work even though their organization is not a member of W3C. My own involvement with W3C began as an invited expert in the Working Group which produced the XML specification. So even if your organization does not join W3C, you may when appropriate be able to participate in a WG as an invited expert. Every W3C Recommendation is published at least three times, and most specs many more than three times, for public review: as a Last Call WD, as a Candidate Recommendation, and as a Proposed Recommendation. At each stage, the responsible WG has an absoloute obligation to attempt to resolve comments and objectsion to the satisfaction of the commenter, whether they represent a W3C member or not. From experience I can affirm that the comments of non-members are treated as seriously, and can occasion just as much rework, as those of members. So even if your organization does not join W3C, and even if you are not serving as an invited expert, you have the opportunity to comment, and the WG has the obligation to engage seriously with your contributions. (Earlier is better, of course. Don't wait till PR and expect massive changes.)

Aus der Sicht von Standardisierungsorganisationen ist dieses Ziel nur erreichbar, wenn ausreichende Vorraussetzungen für die öffentliche Teilnahme gegeben sind. Im Falle des W3C, welches ich am besten kenne, wurden mit diesem Umstand im Hinterkopf verschiedene Eigenschaften der Organisation und des W3C-Proze&ss;es definiert. Die W3C-Mitgliedsgebühren für gemeinnützige Organisationen sind gegenüber denjenigen für die Vollmitgliedschaft stark reduziert. Unter geeigneten Umständen dürfen im W3C Sachkundige an der Arbeit von Arbeitsgruppen teilnehmen, auch wenn deren Organisation kein Mitglied des W3C ist. Meine eigene Teilnahme beim W3C begann als invited expert in der Arbeitsgruppe, in der die XML-Spezifikation erstellt wurde. Selbst wenn man also nicht bei einer Organisation arbeitet, die dem W3C beitritt, kann man möglicherweise in einer Arbeitsgruppe als invited expert mitarbeiten. Jede W3C Empfehlung (Recommendation) wird mindestens drei Mal für öffentliche Kommentare veröffentlicht, und manche Spezifikation noch öfter: als Last Call Working Draft, als Candidate Recommendation, und als Proposed Recommendation. In jeder Phase hat die verantwortliche Arbeitsgruppe die absolute Verpflichtung zu versuchen, allen Kommentaren und Einwänden gerecht zu werden und den Kommentierer zufrieden zu stellen, unabhängig davon, ob er ein W3C-Mitglied vertritt, oder nicht. Aus meiner eigenen Erfahrung kann ich bestätigen, daß die Komentare von Nicht-Mitgliedern genauso ernst genommen werden und genauso viele Umarbeitungen der Spezifikation hervorrufen können, wie die Kommentare von Mitgliedern. Das heißt, selbt wenn eine Organisation nicht dem W3C beitritt und selbst wenn man kein invited expert ist, hat man die Möglichkeit, Kommentare abzugeben, und die Arbeitsgruppe hat die Verpflichtung sich ernsthaft mit diesen Kommentaren zu beschäftigen. (Natürlich kommen Kommentare je frührer desto besser an. Wenn man erst in der Schlu&ss;phase massenhafte Abänderungen vorschlägt, ist kaum zu erwarten, da&ss; die Arbeitsgruppe die Vorschläge freudig annimmt.)

But much can also be undertaken from the side of organizations concerned with the study and the preservation of human cultural heritage. There are far too few member organizations of W3C which represent scholarship and users, in proportion to those which represent softwawre vendors. Boeing does a great deal to represent users of the Web, but they can only do so much!

Viel kann aber auch unternommen werden von Seite der Organisationen, welche sich mit der Studie und dem Erhalt des menschlichen kulturellen Erbes beschäftigen. Es gibt im Verhältnis zu Softwareherstellern viel zu wenig W3C-Mitgliedsorganisationen, die die Forschung und die Nutzer von Standards repräsentieren. Die Boeing Company z.B. vertritt im W3C auf hervorragende Weise die Interessen der Benutzer des Webs, aber auch ihr sind als Einzelmitglied Grenzen gesetzt!

The work of W3C, and thus the Web as a whole, would benefit from more participation by universities and other culutral institutions. Is hyour institution a member of W3C? I have reviewed our membership list, and I am sorry to say: no.

Die Arbeit des W3C, und des W3C als ganzes, würde sehr von der Teilnahme von Universitäten und anderen kulturellen Institutionen profitieren. Sind die Einrichtungen, die hier im Workshop vertreten sind, Mitglieder des W3C? Ich habe mir die Liste unserer Mitglieder angeschaut und muß leider sagen: nein.

Please join! If you can't join, please participate in other ways, by commenting on the specs and engaging with the WGs! And similarly at other standards organizations which provide for public comment.

Bitte treten Sie dem W3C bei! Wenn Sie das nicht können, dann nehmen Sie bitte auf andere Weise teil, indem Sie Spezifikationen kommentieren und sich mit der Arbeit des W3C vertraut machen! Und tun Sie auch Ähnliches bei anderen Standardisierungsorganisationen, die öffentliche Kommentare erlauben.

So können wir erreichen, daß die Standards, die vom W3C oder andere Normierungsorganisationsen verabschiedet werden, und die wissenschaftlicher Projekte, wie sie hier vertreten sind, sich durch ihren Erfahrungsaustausch gegenseitig bereichern können.

[Pause]

Und jetzt kann ich im Ernst sagen: Das wär's. Ich danke für die Aufmerksamkeit.

Berners-Lee, Tim, Dan Connolly, and Ralph R. Swick. 1999. Web Architecture: Describing and Exchanging Data, W3C Note 7 June 1999. [Cambridge, Sophia-Antipolis, and Tokyo]: World Wide Web Consortium. On the Web at http://www.w3.org/1999/04/WebData Capelli, Adriano. 1899. Dizionari di Abbreviature latine ed italiane usate nelle carte e codici specialment del medio-evo Milano: Ulrico Hoepli. [Und viele spätere Ausgaben.] Hazaël-Massieux, Dominique, and Dan Connolly. 2005. Gleaning Resource Descriptions from Dialects of Languages (GRDDL), W3C Team Submission 16 May 2005. [Cambridge, Sophia-Antipolis, and Tokyo]: World Wide Web Consortium. On the Web at http://www.w3.org/TeamSubmission/2005/SUBM-grddl-20050516/ Jakobson, Roman. 1960. "Closing Statement: Linguistics and Poetics", in Style In Language, ed. Thomas A. Sebeok (Cambridge: MIT Press, 1960), pp. 350-377. [LOCKSS Project.] 2006. LOCKSS: Lots of Copies Keep Stuff Safe. Project home page at http://www.lockss.org/lockss/Home. Marcoux, Yves. 2006. "A natural-language approach to modeling (extended draft) Why is some XML so difficult to write?" Extreme Markup Languages 2006 (forthcoming). Maler, Eve, and Jeanne El Andaloussi. 1996. Developing SGML DTDs: From text to model to markup. Upper Saddle River, NJ: Prentice Hall PTR, 1996. xxiv, 532 pp; index. Small, Jocelyn Penny. Retrieving Images Verbally: No More Key Words and Other Heresies. Library Hi Tech 9.1 (1991): 51-60. Sperberg-McQueen, C. M., Claus Huitfeldt, and Allen Renear. “Meaning and interpretation of markup.” Markup Languages: Theory & Practice 2.3 (2001): 215-234. On the Web at http://www.w3.org/People/cmsmcq/2000/mim.html Sperberg-McQueen, C. M., and Eric Miller. 2004. On mapping from colloquial XML to RDF using XSLT, Extreme Markup Languages 2004. On the Web at http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Sperberg-McQueen01/EML2004Sperberg-McQueen01.html Vorthmann, Scott, Jonathan Robie, and Lee Buck. 2000. “Schema adjunct framework”. Draft Specification 30 November 2000. [Chapel Hill]: Extensibility. http://www.extensibility.com/saf/spec/ (no longer available?) http://xml.coverpages.org/SchemaAdjunctFramework200011.html Vorthmann, Scott, and Jonathan Robie. 2001. “Beyond schemas: Schema adjuncts and the outside world”. Markup Languages: Theory & Practice 2.3 (2001): 281-294. Wrightson, Ann. 2001. "Some Semantics for Structured Documents, Topic Maps and Topic Map Queries." Extreme Markup Languages 2001. On the Web at http://www.mulberrytech.com/Extreme/Proceedings/html/2001/Wrightson01/EML2001Wrightson01.html Wrightson, Ann. 2005. "Semantics of Well Formed XML as a Human and Machine Readable Language." Extreme Markup Languages 2005. On the Web at http://www.mulberrytech.com/Extreme/Proceedings/html/2005/Wrightson01/EML2005Wrightson01.html Wrightson, Ann. 2006. "Conveying Meaning through Space and Time using XML." Extreme Markup Languages 2006. Forthcoming.