2.3 Dokumentation der Forschungsergebnisse – Administrative Metadaten

2.2 Forschungsdaten – Nutzung von Standards in den Geisteswissenschaften

Im Vergleich zu Standardisierungsaktivitäten im Bereich der beschreibenden Metadaten für geisteswissenschaftliche Daten und Quellen (siehe dazu Abschnitte 3. Daten- und Metadatenformate in den Fachdisziplinen und 4. Beschreibung disziplinübergreifender Objekte), lässt sich gerade bei den administrativen Metadaten ein grundlegender Bedarf erkennen, für den zurzeit in den meisten Codierungsformaten noch keine befriedigende Umsetzungsmöglichkeit geschaffen wurde.

Im Sinne des klassischen Wissensmanagements können administrative Metadaten bzw. Verwaltungsmetadaten folgende ressourcen- oder objektbezogene Informationen enthalten:(¹)

• Herstellung
• Speicherung
• Verwahrung
• Rechtemanagement
• Verwaltung der Zugriffsrechte

Allgemeiner formuliert, können alle Informationen, die für die Administration von Daten benötigt werden, unter diesen Begriff gefasst werden.

Die Beschreibung und Erfassung von geisteswissenschaftlichen Forschungsdaten mit Metadaten geschieht oftmals, sieht man von thematisch ausgerichteten Editionsvorhaben ab, als ein Arbeitsschritt eines individuellen Forschungsprozesses. Dieser Forschungsprozess, der durch ein Erkenntnisinteresse und durch spezielle Forschungsfragen und damit verbundene Methoden und Verfahren strukturiert wird, sollte auch als (Meta-)Information abrufbar sein, damit nachvollziehbar bleibt, wie die entsprechenden Forschungsdaten erhoben, erfasst und aufbereitet wurden, damit also nachnutzende ForscherInnen den "Herstellungsprozess" rekonstruieren können.

Dokumentationsmöglichkeiten von administrativen Metadaten am Beispiel des TEI-Header

Das nachfolgende Beispiel demonstriert den Umgang mit administrativen Metadaten im TEI-Header. Dabei sei aber nochmals darauf hingewiesen, dass TEI (Text Encoding Initiative) einer der wenigen Standards ist, der diese Möglichkeiten überhaupt anbietet. TEI stellt innerhalb des sog. TEI-Header eine mehrstufige, modular erweiterbare Struktur zur Erfassung unterschiedlicher administrativer Metadaten zur Verfügung:

1. \<fileDesc/> 
   Beschreibung der einzelnen elektronischen Ressource (als Computerfile)
2. \<encodingDesc/> 
   Dokumentation der Beziehungen zwischen Quelle(n) und elektronischem File
3. \<profileDesc/> 
   Angaben zum “Text-Profil” (Sprache, Urheber, Klassifikationen usw.)
4. \<revisionDesc/> 
   Beschreibung der Revisionsgeschichte einer Datei

Im engeren Sinne fallen nur die Punkte 2 und 4 in den Bereich der administrativen Metadaten. Sowohl die \<encodingDesc/> als auch die \<revisionDesc/> erlauben Untergliederungen in teils freier, teils stärker strukturierter Weise (letztere empfiehlt sich stets im Hinblick auf die leichtere maschinelle Auswertung von Angaben).

Die File Description (deskriptive Metadaten)

Die \<fileDesc/> bezieht sich rein deskriptiv auf den vorliegenden elektronischen Datensatz mit Angaben zum Titel, zur Art der vorliegenden Datei, zu ihrem Umfang und ihrer Publikation, aber auch zu den dabei benutzten Quellen (zu letzterem Punkt vgl. 4.5 Objektinformationen) und wird daher an dieser Stelle nicht genauer behandelt.

Die  Encoding Description

Im Container-Element \<encodingDesc/> können allgemeine Aspekte zur Art der Codierung eines Objekts untergebracht werden. Die beiden wichtigsten formalisierten Bestandteile einer solchen Beschreibung sind:

• \<projectDesc/>, eine Kurzcharakteristik des digitalen Projekts (Projektbeschreibung)
• \<editorialDecl/>, Erklärungen zu den zugrundeliegenden Editionsprinzipien

Damit ist lediglich ein Minimal-Set an Informationen abgedeckt, die zudem meist knapp gehalten sind, weil sie in der Regel nicht spezifisch für ein einzelnes File, sondern für ganze Sammlungen sind, so dass man mit einem Verweis auf separat abgelegte ausführlichere Daten (etwa separate Editionsrichtlinien) auskommt.

<?xml version="1.0" encoding="UTF-8"?>
<teiHeader>
   <!--- andere Teile des teiHeader -->
   <encodingDesc>
      <projectDesc>
         <p>Carl-Maria-von-Weber-Gesamtausgabe, Sämtliche Briefe, Digitale Edition</p>
      </projectDesc>
      <editorialDecl>
         <p>Die Übertragung und Texteinrichtung folgt den Editionsrichtlinien der
            WeGA, vgl. http://www.weber-gesamtausgabe.de/de/Editionsrichtlinien</p>
         <p>Der Text des vorliegenden Files folgt ausnahmsweise dem späteren
            Druck D-2, da dieser möglicherweise auf das Original zurückgeht.</p>
      </editorialDecl>
   </encodingDesc>
</teiHeader>

Beispiel einer \<encodingDesc/> der Carl-Maria-von-Weber-Gesamtausgabe

Es ist jedoch – speziell bei einem umfangreichen Einzeltext – möglich, auch umfangreichere Angaben zu bestimmten Aspekten des editorischen Vorgehens strukturiert abzulegen. Das betrifft etwa Angaben zu Korrekturen (\<correction/>), zum Grad der Normalisierung von Orthographie (\<normalization/>), zum Umgang mit Silbentrennungen (\<hyphenation/>), zur Kennzeichnung zitierter Abschnitte (\<citation/>) u.v.a.m.

Mit einer Reihe weiterer Deklarationen lassen sich auch forschungsmethodische Details festhalten:(²)

• Angaben zu den Leitlinien bei der Anlage eines Korpus oder einer Kollektion von Texten (\<samplingDecl/>)
• Erklärung zu der Verwendung der Markup-tags (also der Elemente) im Dokument (\<tagsDecl/>)
• Erklärung zur Struktur von Verweisen im Dokument (\<refsDecl/>)
• Verwendete Taxonomien im Text (\<classDecl/>)

In der Regel werden diese Angaben frei innerhalb eines \<p/>-tags formuliert.

Die Profile Description (Angaben zum Textprofil)

Die umfangreichen Möglichkeiten zur Angabe von Aspekten des “Textprofils” in der \<profileDesc/> gehören zur inhaltlich erschließenden Beschreibung eines Files – also nicht im engeren Sinne zu den administrativen Metadaten (vgl. hierzu auch die Getty-Klassifikation bzw. den Abschnitt 4.5 Objektinformationen). Die fakultative \<profileDesc/> beschreibt den jeweils in der Datei wiedergegebenen Text als historisch, z.B. mit Angaben zu seiner Entstehung, zur verwendeten Sprache, Textsorte usw.

Die Revision Description (Beschreibung der Revisionsgeschichte einer Datei)

Innerhalb der \<revisionDesc/> des TEI-Headers besteht die Möglichkeit, alle Veränderungen an einer vorliegenden Datei zu protokollieren (die Ausführlichkeit der Einträge hängt dabei selbstverständlich von den jeweiligen Bedürfnissen in einem kollaborativen Arbeitsumfeld ab). Jede Änderung (\<change/>) wird datiert und einem Verantwortlichen zugewiesen (vgl. die Attribute @when und @who im folgenden Beispiel). Die Granularität der Beschreibung der Eingriffe sollte dabei in einem Projekt mit zahlreichen Mitarbeitern feiner sein als in leicht überschaubaren Kontexten.

Die beispielhafte Revisionshistorie innerhalb eines Briefdokuments, wie sie innerhalb der digitalen Carl-Maria-von-Weber-Gesamtausgabe im \<teiHeader/> angelegt wird, zeigt das folgende Codebeispiel:

<?xml version="1.0" encoding="UTF-8"?>
<teiHeader>
   <!-- andere Teile des teiHeader -->
   <revisionDesc status="candidate">
      <change when="2012-06-19" who="#AS">alte ID's in den @keys ersetzt</change>
      <change when="2012-04-18" who="#JV">Personen ausgezeichnet, Korrekturlesung Haupttext</change>
      <change when="2011-04-03" who="#PS">Text erstmals eingerichtet, Kommentare eingearbeitet</change>
   </revisionDesc>
</teiHeader>

Beispiel für eine \<revisionDesc/> innerhalb eines Briefdokuments

Das generell bestehende Defizit an maschinenlesbar hinterlegten Metadaten, die sowohl die Herstellung als auch spätere Änderungen an digitalen Ressourcen dokumentieren, wird in dieser Codierungsform sichtbar: Die einzelnen Herstellungs- und Änderungsprozesse sind lediglich innerhalb des Elements \<change/> als Fließtext ausgezeichnet und können dadurch nicht maschinell ausgewertet werden. Dies ist hier ausschliesslich für die angegebenen Attribute der Zeit (when=“ ”) und Person (who= “ ”) möglich.

Um einen (idealisierten) Workflow maschinell erfassbar zu machen, müssten die bisher im Fließtext ausformulierten Beschreibungen stärker formalisiert werden. Das kann einerseits in einfachster Weise durch ein kontrolliertes Vokabular erfolgen, das nur festgelegte Werte bzw. das Vorkommen von Standardbegriffen in den eingetragenen Texten erlaubt. Denkbar ist z.B., für ein bestimmtes Textkorpus festzulegen, dass folgende Begriffe in einer Revisionshistorie auftauchen dürfen:

• initiale Transformation
• formale Auszeichnung
• semantische Auszeichnung (ggf. differenziert: Auszeichnung Personen/Werke)
• Erstkorrektur
• Kommentierung
• Endkorrektur

In diesem Falle könnte dann gezielt nach bestimmten Stufen der Veränderung gesucht werden.

Eine weitere Möglichkeit ist die Überführung einer solchen Begrifflichkeit in Attributwerte. Neben den bislang in TEI im Element \<change/> vorwiegend verwendeten Attributen @when, @who und @n (letzteres für eine ggf. vorzunehmende Nummerierung oder Vergabe auslesbarer Zahlenwerte) kann auch das Attribut @type für die Kennzeichnung und spätere Ausgabe definierter Werte genutzt werden (etwa type=“initTrans”, d.h. initiale Transformation).

Beispiel für eine entsprechend individuell angepasste, stärker formalisierte Revisionsbeschreibung:

<teiHeader>
   <!-- andere Teile des teiHeader -->
   <revisionDesc>
      <change type="rel01Cor" when="2011-04-08" who="#PS">Abschließende Korrektur für 
         Release 1</change>
      <change type="semMarkup" when="2011-04-03" who="#PS">Veranstaltungsorte ausgezeichnet</change>
      <change type="semMarkup" when="2012-05-03" who="#PS">Ortsnamen ausgezeichnet</change>
      <change type="formalMarkup" when="2012-04-18" who="#JV">Lateinschreibung und 
         Konsonantengemination ausgezeichnet</change>
      <change type="semMarkup" when="2012-03-03" who="#PS">Personen und Werke ausgezeichnet</change>
      <change type="initCorr" when="2011-06-20" who="AS">Korrekturgelesen bis Ende Kapitel 5</change>
      <change type="initCorr" when="2011-06-19" who="#AS">Korrekturgelesen bis Ende Kapitel 2</change>
      <change type="initTrans" when="2011-01-01" who="#KO">Initiale Transformation, 
         grobe Fehler beseitigt</change>
   </revisionDesc>
</teiHeader>

Modifizierte \<revisionDesc/> innerhalb eines Briefdokuments (TEI P5)

Alle vorstehenden Beispiele bleiben jedoch bei eher formalen Beschreibungen des Arbeitsprozesses und den Voraussetzungen, auf denen TEI beruht, stehen – sie demonstrieren daher die Notwendigkeit einer detaillierteren Berücksichtigung des Forschungskontexts auch im dafür bereits am besten geeigneten TEI-Schema.

3. Daten- und Metadatenformate in den Fachdisziplinen