\documentclass[ngerman,a4paper,]{report}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
\else % if luatex or xelatex
  \ifxetex
    \usepackage{mathspec}
  \else
    \usepackage{fontspec}
  \fi
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\usepackage[breaklinks=true,unicode=true]{hyperref}
\hypersetup{
            pdftitle={Konzeption und Implementierung eines kollaborativen Annotationssystems für TEI-Editionen},
            pdfauthor={Christian Kremitzl},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[shorthands=off,main=ngerman]{babel}
\else
  \usepackage[ngerman]{babel}
\fi
% \usepackage{breakurl}
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
% Add ',fontsize=\small' for more characters per line
\newenvironment{Shaded}{}{}
\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{{#1}}}}
\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{{#1}}}
\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{{#1}}}
\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{{#1}}}
\newcommand{\ImportTok}[1]{{#1}}
\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{{#1}}}}
\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{{#1}}}}
\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{{#1}}}
\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{{#1}}}
\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{{#1}}}
\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{{#1}}}}
\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{{#1}}}
\newcommand{\BuiltInTok}[1]{{#1}}
\newcommand{\ExtensionTok}[1]{{#1}}
\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{{#1}}}
\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{{#1}}}
\newcommand{\RegionMarkerTok}[1]{{#1}}
\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{{#1}}}}
\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{{#1}}}}
\newcommand{\NormalTok}[1]{{#1}}
\usepackage{longtable,booktabs}
\usepackage{multirow}
\usepackage{makecell}
\usepackage{diagbox}
\usepackage{tocloft}
\usepackage{relsize}
% \newcommand{\acro}[1]{\textsmaller{#1}}
\newcommand{\acro}[1]{\textsmaller{\addfontfeature{LetterSpace=3.0}#1}}
\newcommand{\annoteitor}{Anno\textsc{\addfontfeature{LetterSpace=3.0}tei}tor}
\newcommand{\TEI}{\acro{TEI}}
\newcommand{\KoDiKE}{\acro{K}o\acro{D}i\acro{KE}+}
% Fix footnotes in tables (requires footnote package)
\IfFileExists{footnote.sty}{\usepackage{footnote}\makesavenoteenv{long table}}{}
\usepackage{graphicx,grffile}
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
\makeatother
% Scale images if necessary, so that they will not overflow the page
% margins by default, and it is still possible to overwrite the defaults
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{2}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{amssymb} \usepackage{algorithm} \usepackage{algorithmic}
\usepackage{hanging}
\usepackage{todonotes} \floatplacement{figure}{tp}
\usepackage{subfig}
\AtBeginDocument{%
\renewcommand*\figurename{Abbildung}
\renewcommand*\tablename{Tabelle}
}
\AtBeginDocument{%
\renewcommand*\listfigurename{List of Figures}
\renewcommand*\listtablename{List of Tables}
}
\usepackage{float}
\floatstyle{ruled}
\makeatletter
\@ifundefined{c@chapter}{\newfloat{codelisting}{h}{lop}}{\newfloat{codelisting}{h}{lop}[chapter]}
\makeatother
\floatname{codelisting}{Listing}
\newcommand*\listoflistings{\listof{codelisting}{List of Listings}}
\usepackage{cleveref}
\crefname{figure}{Abb.}{Abb.}
\crefname{table}{Tab.}{Tab.}
\crefname{equation}{eq.}{eqns.}
\crefname{listing}{lst.}{lsts.}
\crefname{section}{Abschnitt}{Abschnitte}
\Crefname{figure}{Abb.}{Abb.}
\Crefname{table}{Tab.}{Tab.}
\Crefname{equation}{Eq.}{Eqns.}
\Crefname{listing}{Lst.}{Lsts.}
\Crefname{section}{Abschnitt}{Abschnitte}
\newcommand{\ok}{\checkmark}
\makeatletter
\crefname{codelisting}{\cref@listing@name}{\cref@listing@name@plural}
\Crefname{codelisting}{\Cref@listing@name}{\Cref@listing@name@plural}
\makeatother

\title{Konzeption und Implementierung eines kollaborativen Annotationssystems
für \TEI{}-Editionen}
\author{Christian Kremitzl}
\date{\today}

\begin{document}
\input{LaTeX/Titel}

{
\setlength{\cftbeforechapskip}{0.9em}
\setcounter{tocdepth}{2}
\tableofcontents
}

\setmainfont[Ligatures=TeX,SmallCapsFont={* Caps},Scale=MatchLowercase,Numbers={OldStyle}]{Latin Modern Roman}

\chapter{Einleitung}\label{sec:einleitung}

Editionen sind ein zentrales Werkzeug der Geisteswissenschaften. Sie
erschließen historische Dokumente oder andere Objekte der
Kulturgeschichte, reichern sie mit kritischem Wissen an und werden als
Grundlage für weitere geisteswissenschaftliche Forschungen
veröffentlicht (Jannidis, Kohle und Rehbein 2017). Eine wichtige
Methode dabei ist die Annotation. Mit der zunehmenden Digitalisierung
der Geisteswissenschaften werden daher auch Systeme wichtiger, die beim
digitalen Annotieren und Edieren unterstützen. Da die Prozesse von
Projekt zu Projekt sehr unterschiedlich sein können, werden ebenso
unterschiedliche Anforderungen an Annotationssysteme gestellt.

Die vorliegende Abschlussarbeit beschäftigt sich mit dem Entwurf und der
Implementierung eines solchen Annotationssystems am Beispiel eines
konkreten Anwendungsszenarios: der kollaborativen Annotation einer
\TEI{}-Edition im Rahmen des latinistischen Forschungsprojekts \KoDiKE{} an
der Universität \mbox{Bamberg.}

Im folgenden \cref{sec:hintergrund} werden zunächst die fachlichen
Hintergründe erläutert, die zu diesem Anwendungsszenario führen: die
wissenschaftlichen Methoden des Edierens und Annotierens sowie \TEI{} als
technische Lösung dafür. Anschließend stellt \cref{sec:problemstellung}
das Forschungsprojekt genauer vor, leitet daraus die Anforderungen an
das Annotationssystem ab und umreißt die technische Problemstellung.
\cref{sec:sota} gibt einen Überblick über den Stand der Technik bei
Annotationssystemen für das Web im Allgemeinen und für \TEI{} im
Speziellen. \cref{sec:luxf6sungsansatz} stellt den Lösungsansatz vor,
\cref{sec:umsetzung} beschreibt die genaue Implementierung. In
\cref{sec:evaluierung} wird die Lösung evaluiert, abschließend werden in \cref{sec:diskussion} die Ergebnisse diskutiert.

\chapter{Hintergrund}\label{sec:hintergrund}

Editionen sind eine Grundlage geisteswissenschaftlicher Forschung.
Durch sie werden historische Dokumente oder andere kulturgeschichtliche
Objekte für einen größeren Nutzerkreis reproduziert und zugänglich
gemacht. Im Fall von Dokumenten kann es dabei sowohl um den abstrakten
Text als auch um das materielle Objekt gehen (Jannidis, Kohle und
Rehbein 2017).

Je nachdem welchem Zweck eine Edition dient und wie stark der
Herausgeber eingreift, werden Editionsparadigmen unterschieden:
Faksimile-Editionen \mbox{stellen} das edierte Objekt möglichst originalgetreu
dar. Über ultradiplomatische, diplomatische und semidiplomatische
Editionen steigt der Grad des Eingriffs durch den Editor bis zur Leseedition an, die
Eigenheiten des Dokuments zugunsten einer besseren Lesbarkeit
vernachlässigt. Interpretative und kritische Editionen enthalten
zusätzliche Kommentare (Pierazzo 2014; Pierazzo 2015; Pierazzo 2016).

Inzwischen wird zwar vermehrt digital ediert, dabei orientieren sich die
Herausgeber aber noch sehr an traditionellen Prinzipien und lassen das
Potenzial digitaler Editionen weitgehend ungenutzt (Pierazzo 2016): Die
Seitenfokussiertheit gedruckter Medien ist nicht mehr nötig, auch
multimediale Elemente können gezeigt werden. Da der Platzverbrauch keine
Rolle spielt, können digitale Editionen mehr Kontext darstellen. Auch
mehrfache Textwiedergaben bis hin zu multiparadigmatischen Editionen
sind möglich (Jannidis, Kohle und Rehbein 2017). So können etwa sowohl
die Besonderheiten eines bestimmten Skriptoriums als auch korrigierte
Schreibungen für eine bessere Lesbarkeit in einer einzigen Edition
kodiert werden. Genauso können unterschiedliche wissenschaftliche
Herangehensweisen gemeinsam ediert werden. Der Nutzer kann dann
interaktiv zwischen den Varianten wechseln und sie vergleichen (Pierazzo
2016). Nicht zuletzt können digitale Editionen laufend aktualisiert
werden und so den aktuellen Arbeitsfortschritt zeigen, statt einen
willkürlich festgelegten Endzustand abzubilden (Jannidis, Kohle und
Rehbein 2017).

Digitale Editionen bieten aber nicht nur mehr Möglichkeiten, sondern sie
stellen auch andere Anforderungen an Arbeitsabläufe und Werkzeuge
(Pierazzo 2015). Herausgeber müssen mehr und anders markieren und
kommentieren als bei gedruckten Editionen, die Anzeigeprogramme müssen
damit umgehen können und beispielsweise die Möglichkeit bieten, zwischen
verschiedenen Ansichten umzuschalten (Pierazzo 2016). Darüber hinaus
altern digitale Dokumente schneller und sind wartungsaufwändiger als
gedruckte (Pierazzo 2015).

Es muss zwischen dem Datenmodell und der formatierten Publikation
unterschieden werden (Pierazzo 2016). Publiziert wird eine digitale
Edition meist als Webanwendung, der informationsangereicherte Textdaten
zugrunde liegen. Diese werden fast immer als \acro{XML} gespeichert,
üblicherweise als \TEI{} (Jannidis, Kohle und Rehbein 2017).

\section{\TEI{}}\label{sec:tei}

Zum Kodieren eines digitalen Textes gehört auch die Kodierung von
Struktur\-elementen, textsortenspezifischen Merkmalen, Anmerkungen und
Kommentaren, damit der Text interpretierbar bleibt (Kurz 2015). Im Laufe
der Jahre wurden zu diesem Zweck unterschiedliche Methoden entwickelt, die untereinander inkompatibel waren
(Ide und Sperberg-McQueen 1995). Damit Texte langfristig nachvollziehbar
bleiben, ist ein unabhängiges, portables und offenes Datenformat nötig
(Kurz 2015).

Im November 1987 wurde auf einer Konferenz der Association for Computers
and the Humanities (\acro{ACH}) vereinbart, dass ein neues Kodierungsformat
geschaffen werden sollte, das Syntaxempfehlungen und Konventionen für
verschiedene Forschungsdisziplinen anbieten würde (Ide und
Sperberg-McQueen 1995; Kurz 2015). Daten sollten unabhängig vom
konkreten Analyseziel und der wissenschaftlichen Disziplin
wiederverwertbar aufbereitet werden können (Jannidis, Kohle und Rehbein
2017; Burnard 2013). Zusammen mit der Association for Literary and
Linguistic Computing und der Association for Computer Linguistics (Ide
und Sperberg-McQueen 1995) gründete die \acro{ACH} die Text Encoding\footnote{Im
  Gegensatz zu informatischen Definitionen wird hier unter Encoding bzw.
  Kodierung verstanden, dass Codes oder Tags in einen Text eingefügt
  werden, um bestimmte Eigenschaften des Textes explizit zu machen und
  damit die computergestützte Verarbeitung zu ermöglichen.} Initiative,
kurz: \TEI{} (Jannidis, Kohle und Rehbein 2017; Pierazzo 2016). Das erste
Ergebnis waren die Poughkeepsie Principles:\footnote{\href{http://www.tei-c.org/Vault/ED/edp01.htm}{http://www.tei-c.org/Vault/\acro{ED}/edp01.htm}}
Empfehlungen, wie ein universelles Textkodierungsschema erreicht werden
könnte (Burnard 2013).

Von 1990 bis 1994 erschienen mit \acro{P}1, \acro{P}2 und \acro{P}3\footnote{Das P steht für
  Proposal.} die ersten drei Versionen der \emph{Guidelines for the
Encoding and Interchange of Machine-Readable Texts} (Burnard 2013; Kurz
2015). Die Guidelines basierten auf \acro{SGML}\footnote{\href{https://www.w3.org/MarkUp/SGML/}{https://www.w3.org/MarkUp/\acro{SGML}/}}
(Burnard 2013) und stellten Einschränkungen und Empfehlungen für dessen
Einsatz in geisteswissenschaftlichen Texten auf. Um die Akzeptanz zu
erhöhen, entschied sich die \TEI{} statt einem Standard für Richtlinien und
Konventionen, die freiwillig eingehalten und beliebig erweitert werden
können (Ide und Sperberg-McQueen 1995). Zum Ende des zwanzigsten
Jahrhunderts kümmerte sich keine Organisation mehr aktiv um die
\TEI{}-Richtlinien (Burnard 2013), sodass sie dem \TEI{}-Konsortium (\TEI{}-\acro{C})
übertragen wurden, einer Non-Profit-Organisation (Burnard 2013; Kurz
2015), die seitdem für die Weiterentwicklung und Wartung zuständig ist
(Pierazzo 2016). Nachdem \acro{XML}\footnote{\href{https://www.w3.org/TR/xml/}{https://www.w3.org/\acro{TR}/xml/}}
eingeführt wurde -- woran auch \TEI{}-Mitglieder mitgewirkt hatten (C.
Sperberg-McQueen und Burnard 2017)~--, löste es 2002 mit Version \acro{P}4 auch
in den \TEI{}-Guidelines \acro{SGML} ab (Burnard 2013; Pierazzo 2016). 2007
erschien die aktuelle Version \acro{P}5 (Burnard 2013; Jannidis, Kohle und
Rehbein 2017). Seit 2011 veröffentlicht das \TEI{}-\acro{C} das peer-reviewte und
frei zugängliche \emph{Journal of the Text Encoding
Initiative.}\footnote{\url{https://journal.tei-c.org/journal/index}}

Die \TEI{} wird zu den großen Erfolgsgeschichten der Digital Humanities
gezählt (Jannidis, Kohle und Rehbein 2017). Nachdem sie als
akademisches Forschungsprojekt mit zentralisierter Struktur begonnen
hatte, hat sie sich bis \acro{P}4 zu einem verteilten Open-Source-Projekt
gewandelt, dessen weitere Entwicklung von der Community gelenkt und
vorangetrieben wird (Burnard 2013). Sie ist international etabliert und
spielt eine wichtige Rolle für zukünftige Entwicklungen, die das Tagging
von digitalen Texten betreffen (Ide und Sperberg-McQueen 1995).
Die \TEI{}-Richtlinien stellen einen De-Facto-Standard in den
Geistes\-wissenschaften dar (Kurz 2015; Pierazzo 2016).

\emph{\TEI{}} steht nicht nur für die Initiative, sondern auch für das von
ihr geschaffene Textauszeichnungssystem. Die aktuelle Version \acro{P}5 basiert
auf \acro{XML} und bietet über 500 Elemente zur Auszeichnung von texttragenden
Objekten, Textsorten, Textphänomenen, wissenschaftlichen Anwendungen und
textanalytischen Zwecken (Jannidis, Kohle und Rehbein 2017). Damit
stellt \TEI{} eine Ontologie dar, die über Länder- und Fächergrenzen hinausreicht und Kompromisse zwischen verfälschender Abstraktion und
austauscherschwerender Präzision vermeidet (Pierazzo 2016, 308).
\TEI{}-konforme Dokumente lassen sich mit jedem Text-Editor schreiben,
spezielle \acro{XML}-Editoren machen es komfortabler (Kurz~2015).

\TEI{} ist modular aufgebaut. Zusätzlich zu den vollständigen Guidelines
gibt es die reduzierte Variante \TEI{} Lite. Die volle Variante besteht aus
21 Modulen, von denen für jedes Projekt diejenigen ausgewählt werden
können, die benötigte Elemente und Attribute enthalten. Das Modul
\emph{core} muss immer eingebunden werden (Kurz 2015, dort ist auch eine
Liste aller Module zu finden). \TEI{} deckt technische, bibliografische,
strukturelle und semantische Metadaten ab. Es liefert sowohl generische
Elemente, etwa für Absätze, Zeichenkodierung und Entitäten, als auch
gattungs- und genrespezifische Tagsets. Es beschäftigt sich
hauptsächlich mit Text, kann aber auch grafische Phänomene wie
Text\-topo\-grafie, Layout und Bilder beschreiben. Auch Text, der nur als
Bilddaten vorliegt, kann beschrieben werden (Jannidis, Kohle und
Rehbein 2017).

Die folgenden Absätze geben einen kurzen Überblick über den Aufbau einer
typischen \TEI{}-Datei. Eine deutlich ausführlichere Darstellung bietet
Kurz~(2015).

Eine \TEI{}-Datei kann entweder nur eine \TEI{}-Instanz -- ein Dokument --
oder ein Korpus aus mehreren Instanzen enthalten (Kurz 2015). Jede
Instanz steht in einem \texttt{\textless{}TEI\textgreater{}}-Tag, das in
\texttt{\textless{}teiHeader\textgreater{}} mit dokumentbeschreibenden
Metadaten und \texttt{\textless{}text\textgreater{}} mit dem
eigentlichen Text (oder inhaltlich entsprechende Alternativen)
unterteilt ist (Kurz 2015; Jannidis, Kohle und Rehbein 2017).

Der Header beschreibt die \TEI{}-Instanz möglichst genau,
mit Titel, Dateigröße, Erklärungen zur Edition u.\,ä. Außerdem kann
er die Kodierung (etwa verwendete Tags), nichtbibliografische Merkmale
des Textes und die genaue Textrevision beschreiben (Kurz 2015).

Das \texttt{\textless{}text\textgreater{}}-Element bildet den
eigentlichen Inhalt des edierten Objekts ab. Es enthält einen optionalen
Vorspann \texttt{\textless{}front\textgreater{}} mit Titelseiten,
Klappentexten, Prologen etc., einen Hauptteil
\texttt{\textless{}body\textgreater{}} (oder eine
\texttt{\textless{}group\textgreater{}}, wiederum mit
\texttt{\textless{}text\textgreater{}}-Elementen) und einen Nachspann
\texttt{\textless{}back\textgreater{}} (Kurz 2015).

Zur weiteren Strukturierung von Texten bietet \TEI{}-Core sowohl generische
Elemente wie Absätze (\texttt{\textless{}p\textgreater{}}) und
Abschnitte (\texttt{\textless{}div\textgreater{}}) als auch eine
Vielzahl spezieller Elemente zur typografischen oder semantischen
Auszeichnung und für analytische Inhalte. Jedes Element unterstützt die
globalen Attribute \texttt{xml:id}, \texttt{n} (zur Benennung),
\texttt{rend} (für Formatierungsangaben) und \texttt{xml:lang} (Kurz
2015; Jannidis, Kohle und Rehbein 2017).

\TEI{} versucht zwar, alle möglichen Szenarien abzudecken -- etwa
technische, bibliografische, strukturelle und semantische Metadaten --
und seine Grundstruktur ist für fast alle Anwendungsbereiche geeignet.
Für viele Forschungsfragen werden aber trotzdem zusätzliche
Annotationskategorien benötigt. Daher können Elemente ausgewählt oder in
ihren Verwendungsregeln modifiziert und eigene Elemente hinzugefügt
werden (Jannidis, Kohle und Rehbein 2017; Kurz 2015). Der genaue
Prozess der Erweiterung wird von Kurz (2015) erklärt.

\section{Annotation}\label{sec:annotation}

Das Annotieren von Dokumenten und Texten ist eine der ältesten
wissenschaftlichen Pratiken und so grundlegend, dass es als
\emph{scholarly primitive} bezeichnet wird (Jannidis, Kohle und Rehbein
2017; Lordick et~al. 2016).

Beim Annotieren werden zusätzliche Informationen an ein
Informationsstück oder Dokument angefügt, ohne dass das Original
modifiziert wird (Hunter 2009). Annotationen sind also Assoziationen
zwischen verschiedenen In\-for\-mations\-stücken (Sanderson, Ciccarese und
Young 2017). Von Metadaten unterscheiden sie sich dadurch, dass sie
nicht das gesamte Objekt beschreiben, sondern nur einzelne Teile
(Jannidis, Kohle und Rehbein 2017).

Annotationen treten in den unterschiedlichsten Formen auf: von einfachen
Hervorhebungen im Text über Querverweise und Korrekturen bis zu
komplexen Kommentaren, beispielsweise als Marginalien (Hunter 2009;
Jannidis, Kohle und Rehbein 2017). Sie können informell oder formell
sein, ontologiebasiert ermöglichen sie Reasoning (Hunter 2009).
Inhaltlich kann es sich um generische technische oder um fachspezifische
Informationen handeln (Jannidis, Kohle und Rehbein 2017). Meistens
beziehen sich Annotationen auf Text, der beispielsweise strukturell,
grammatisch oder semantisch ausgezeichnet wird (Jannidis, Kohle und
Rehbein 2017; Lordick et~al. 2016). Aber auch Bilder, Audio- oder
Videodaten können annotiert werden, etwa mit der Transkription
gesprochener Sprache (Jannidis, Kohle und Rehbein 2017).

In der Linguistik geht es beim Annotieren darum, Beschreibungen oder
Analysen an Sprache anzubringen (Hunter 2009), indem Texte segmentiert
und die einzelnen Einheiten beschrieben werden, beispielsweise Wortarten
beim Part-of-Speech-Tagging. Dabei sollen nach Möglichkeit bestehende
Standards wie die Gemeinsame Normdatei\footnote{\href{http://www.dnb.de/DE/Standardisierung/GND/gnd_node.html}{http://www.dnb.de/\acro{DE}/Standardisierung/\acro{GND}/gnd\_node.html}}
eingehalten werden (Jannidis, Kohle und Rehbein~2017).

Mit digitalen Annotationen wird die analoge Praxis weitergeführt und
"~entwickelt: Zuvor implizite Informationen können explizit kodiert und
formalisiert werden (Jannidis, Kohle und Rehbein 2017), die
Annotationen selbst werden zu einem eigenständigen Forschungsdesiderat
und können als Mikro- oder Nanopublikationen veröffentlicht werden
(Lordick et~al. 2016; Jannidis, Kohle und Rehbein 2017; Grassi et~al.
2012).

\section{Bedarf an Annotationssystemen für \TEI{}}\label{sec:bedarf}

Annotationssysteme sind Werkzeuge, die bei der Erstellung von
Annotationen zu bestehenden Informationsstücken unterstützen. Schon die
Vielzahl solcher Systeme, die für das Web existiert (vgl.
\cref{sec:werkzeuge}), lässt vermuten, dass ein gewisser allgemeiner
Bedarf besteht. Speziell im Kontext von \TEI{} gibt es konkrete
Bedürfnisse:

Nach Pierazzo (2016) bringt \TEI{} drei große Problembereiche mit sich:
überlappende Hierarchien, mangelnden Zugang und seine hohe Flexibilität. Das
erste Problem erbt \TEI{} von \acro{XML}: Da \acro{XML}-Dokumente streng hierarchisch
aufgebaut sind, ist es nicht möglich, mehrere unabhängige Hierarchien zu
kodieren -- etwa um gleichzeitig Seiten- und Satzstrukturen abzubilden.
Es gibt zwar verschiedene Workarounds dafür (vgl.
\cref{sec:annotationen-in-tei}), doch nicht jeder Workaround ist für
jede Situation geeignet und allein die Tatsache, dass sie nötig sind,
ist für manche ein Grund, \TEI{} für gescheitert zu halten (Pierazzo 2016).
Die anderen beiden Probleme sind eng verbunden: Der mangelnde Zugang
rührt daher, dass Herausgeber ihre \TEI{}-Dokumente weitgehend von Hand
schreiben müssen, weil es keine hinreichende Unterstützung durch
Software gibt. Dazu kommt, dass \TEI{} nur für die Datenschicht zuständig
ist, zur Veröffentlichung sind daher Kenntnisse weiterer Sprachen und
zusätzlicher Software nötig. Die mangelnde Unterstützung durch Software
liegt wiederum darin begründet, dass \TEI{} sehr flexibel und
ausdrucksmächtig ist, was die Entwicklung generischer Werkzeuge
erschwert. Stattdessen müssen Werkzeuge speziell für bestimmte
Anwendungsszenarien entwickelt werden (Pierazzo 2016).

\chapter{Problemstellung}\label{sec:problemstellung}

In diesem Kapitel wird zunächst das Forschungsprojekt \emph{\KoDiKE{}}
vorgestellt, für das im Rahmen dieser Arbeit ein kollaboratives
\TEI{}-Annotationssystem entwickelt werden soll. In
\cref{sec:anforderungen} werden daraus konkrete Anforderungen
abgeleitet. \cref{sec:zu-luxf6sen} fasst zusammen, welche
technischen Probleme dafür zu lösen sind.

\section{\KoDiKE{}}\label{sec:kodike}

\emph{Kollaborative Digitale Korpusedition plus. Eine neue Art des
Edierens am Beispiel neulateinischer Grammatiken} -- kurz:
\emph{\KoDiKE{}} -- ist der Titel eines Forschungsprojekts am Lehrstuhl
für Klassische Philologie\footnote{\url{https://www.uni-bamberg.de/klassphil/}}
mit Schwerpunkt Latinistik der Universität Bamberg in Kooperation mit
dem Lehrstuhl für Angewandte Informatik in den Kultur-, Geschichts- und
Geowissenschaften.\footnote{\url{https://www.uni-bamberg.de/kinf/}}
Es beschäftigt sich mit der Edition von lateinischen Schulgrammatiken
aus der Zeit des Rennaisance-Humanismus, die mittelalterliche Methoden
durch neue sprachdidaktische Ansätze ablösten. Drei repräsentative
Grammatiken sollen als Korpus kritisch ediert werden, angereichert mit
dem Fachwissen eines interdisziplinären Forscherteams, und auch für
Nutzer aus angrenzenden Disziplinen zugänglich.

Dafür werden zunächst die Manuskripte in Bamberg transkribiert und als
historisch-kritische Basisedition in \TEI{} ausgezeichnet. Es folgt eine
themenübergreifende Schwerpunktkommentierung: Das \TEI{}-Dokument wird an
Experten verschiedener Fächer (Grammatikographie, Grammatiktheorie,
Bildungs\-geschichte, Kulturinformatik) gegeben, die jeweils unabhängig
fachliche Besonderheiten annotieren und damit ihre eigene Perspektive
auf das Transkript abbilden. Zwischenergebnisse werden über eine
Kollaborationsplattform diskutiert. Die Annotationen werden abschließend
wieder in Bamberg zusammengeführt und dann in einem
Forschungsdatenrepositorium und als Website veröffentlicht.

Ein neues Annotationssystem soll den kollaborativen Annotationsprozess
ermöglichen und die Zusammenführung der Annotationen durch eine
gemeinsame Visualisierung aller Annotationen im \TEI{}-Dokument
unterstützen.

\section{Anforderungen}\label{sec:anforderungen}

Schon die in \cref{sec:bedarf} erwähnte Vielfalt an Annotationssytemen
deutet darauf hin, dass es je nach Nutzungsszenario sehr
unterschiedliche Anforderungen gibt. Allgemeinere Beispiele sind die
Möglichkeit, kollaborativ zu arbeiten, und die Nutzbarkeit mit möglichst
wenig technischem Vorwissen (Lordick et~al. 2016). Bei wissenschaftlichen
Anwendungsfällen kann eine ganze Reihe zusätzlicher Anforderungen
relevant werden. Es muss beispielsweise sichergestellt werden
können, dass die Urheber aller Annotationen sicher identifizierbar sind,
dass einzelne Annotationen dauerhaft referenziert werden können, oder
dass bestimmte Normen eingehalten werden (Lordick et~al. 2016). Im
Folgenden werden aus dem Anwendungsszenario in \cref{sec:kodike} die
Anforderungen für diese Arbeit abgeleitet.

\subsubsection{Anforderungen an
\TEI{}-Dokumente}\label{sec:anforderungen-an-tei}

Zunächst muss eine Anforderung an die zu annotierenden \TEI{}-Dokumente
bzw. den damit verbundenen Workflow gestellt werden, um den
Implementierungsaufwand in einem machbaren Rahmen zu halten:
\TEI{}-Dokumente sollen aus Sicht des Annotationssystems unveränderlich
sein, ihr Inhalt wird also nach der Integration in das System nicht mehr
verändert -- weder durch das System noch durch Zugriffe von außen.
Außerdem müssen \TEI{}-Dokumente, falls das System beim Navigieren im
Dokument jeweils die passende Manuskriptseite zeigen soll, Informationen
darüber enthalten, welcher Text auf welcher Seite steht.

\subsubsection{Anforderungen an das
Datenmodell}\label{sec:anforderungen-an-datenmodell}

Im Rahmen dieser Arbeit ist eine \textbf{Annotation} eine schriftliche
Notiz zu einer bestimmten Textstelle eines bestimmten \TEI{}-Dokuments.
Eine weitere Formalisierung der \textbf{Notiz} selbst ist für \KoDiKE{}
weder möglich noch nötig. Eine \textbf{Textstelle} ist im Normalfall
eine zusammenhängende Zeichenfolge von einer bestimmten Startposition
bis zu einer bestimmten Endposition im Dokument, kann aber auch aus
mehreren solcher Zeichenfolgen bestehen, die sich gegenseitig nicht
überlappen. Einzelne Textstellen sind weder an \TEI{}-Elementgrenzen noch
an Textstellen anderer Annotationen gebunden, sie können in beliebiger
Granularität und völlig unabhängig von der Granularität der bestehenden
Auszeichnungen erfolgen. Eine Versionierung der Annotationen ist nicht
nötig; wichtig ist aber, dass der jeweilige Urheber bekannt ist.
Formaler ist eine Annotation also ein Tupel
\[(Notiz, Dokument, Textstelle, Urheber),\] wobei \(Notiz\) eine
beliebige Zeichenkette ist, \(Dokument\) eine eindeutige Referenz auf
ein \TEI{}-Dokument und \(Urheber\) eine eindeutige Referenz auf den
Ersteller der Annotation. \(Textstelle\) ist eine Menge disjunkter
konvexer Mengen zeichengenauer Positionen im Dokument.

Da das \TEI{}-Dokument nicht verändert werden soll, müssen die Annotationen
außerhalb des Dokuments gespeichert werden.

\subsubsection{Anforderungen an die
Nutzeroberfläche}\label{sec:anforderungen-an-oberfluxe4che}

Die Nutzeroberfläche des Annotationssystems muss im Wesentlichen zwei
Bereiche unterstützen: Das Darstellen einer Edition, ggf. mit
Visualisierung bestehender Annotationen, und das Erstellen und
Bearbeiten von Annotationen.

Zur Darstellung der Edition muss das jeweilige \TEI{}-Dokument so
aufbereitet werden, dass es ohne \TEI{}-Kenntnisse genutzt und annotiert
werden kann. Es soll kein \acro{XML}-Code angezeigt oder eingegeben werden
(vgl. Price 2016; Pierazzo 2016). Parallel zum \TEI{}-Dokument soll, falls
vorhanden, das Faksimile der Handschrift dargestellt werden (vgl.
Pierazzo 2014).

Falls es zum geöffneten \TEI{}-Dokument bereits Annotationen gibt, sollen
die dazugehörigen Textstellen geeignet visualisiert werden und das
Anzeigen der jeweiligen Notiz möglich sein. Nutzer außerhalb des
Bamberger Projektteams sollen dabei nur die Annotationen sehen, die sie
selbst erstellt haben; das Projekt\-team soll dagegen alle Annotationen
sehen und bei Bedarf annotatorenweise ein- und ausblenden können.

Das Erstellen von Annotationen bleibt angemeldeten Nutzern vorbehalten.
Sie können Textstellen markieren und Notizen anfügen.
Mehrere Annotatoren sollen auch gleichzeitig dasselbe Dokument
annotieren können.

\section{Technische Problemstellung}\label{sec:zu-luxf6sen}

Für ein neues \TEI{}-Annotationssystem, das die genannten Anforderungen
erfüllt, sind im Wesentlichen drei Aspekte zu lösen:

Erstens muss ein geeignetes Datenmodell entworfen werden, das
Annotationen in der in \cref{sec:anforderungen-an-datenmodell}
vorgestellten Form mit ihren Beziehungen zu Textstellen in
\TEI{}-Dokumenten abbilden kann, ohne dass diese verändert werden müssen.
Das Datenmodell kann sich an bestehenden Modellen und Standards
orientieren, die in \cref{sec:annotationen-im-web} vorgestellt werden.

Zweitens muss eine Benutzeroberfläche entwickelt werden, die
\TEI{}-Dokumente mit allen bestehenden Annotationen geeignet visualisiert
und das Erstellen und Bearbeiten von Annotationen ohne \TEI{}-Kenntnisse
ermöglicht. Für die Annotationen können gängige Metaphern genutzt
werden, wobei auch überlappende Annotationen klar interpretierbar sein
müssen. Außerdem ist eine Lösung für die Darstellung von \TEI{}-Dokumenten
ohne Tags zu entwickeln.

Drittens muss ein geeigneter Ablauf entworfen und implementiert werden,
um Annotationen aus dem Datenmodell in darstellbare Textstellen für die
Benutzeroberfläche zu übertragen und umgekehrt über die
Benutzeroberfläche neu angelegte Annotationen in das Datenmodell zu
überführen.

\chapter{Stand der Technik}\label{sec:sota}

Da es wenig Literatur zu Annotationssystemen für \TEI{} gibt, aber vieles
unabhängig vom annotierten Format gilt, erweitert der erste Abschnitt
dieses Kapitels den Kontext auf die Annotationspraxis im Web. Der darauf
folgende Abschnitt beschäftigt sich dann mit den theoretischen
Möglichkeiten in Bezug auf~\TEI{}.

\section{Annotationen im Web}\label{sec:annotationen-im-web}

Die ganze Bandbreite der in \cref{sec:annotation} aufgeführten
Annotationsformen lässt sich auch in Webtools finden: begonnen mit
einfachen grafischen Markierungswerkzeugen (wie sie in Mozilla
Firefox\footnote{\url{https://www.mozilla.org/de/firefox/}} angeboten
werden) über die Möglichkeit, Text zu markieren und mit zusätzlichem
Text zu kommentieren (beispielsweise in Microsoft Edge\footnote{\url{https://www.microsoft.com/de-de/windows/microsoft-edge}})
bis hin zu komplexen semantischen Annotationen. Typisch für letztere
ist, dass sie Informationseinheiten anhand einer globalen \acro{ID}
referenzieren, typisieren und mit anderen Informationen verknüpfen.
Außerdem erhalten sie selbst eine \acro{ID} und können wiederum von anderen
Annotationen referenziert werden.

Ein gängiger Standard dafür ist das Resource Description Framework
(\acro{RDF}).\footnote{\href{https://www.w3.org/2001/sw/wiki/RDF}{https://www.w3.org/2001/sw/wiki/\acro{RDF}}} Es wird auch
in linguistischen Forschungsprojekten verwendet, beispielsweise in
\emph{Open Data for Linguistics} (Chiarcos et~al. 2012), in \emph{\acro{ASI}t}
(Buccio, Nunzio und Silvello 2013), und zur Annotation digitaler
Editionen in \emph{Sharing Ancient Wisdoms} (Jordanous et~al. 2012) und
\emph{SemLib} (Barbera et~al. 2013).

Während \acro{RDF} ein generischer Standard für den Datenaustausch im Web ist,
gibt es auch Ansätze speziell für Annotationen, die in den folgenden
Unterabschnitten vorgestellt werden sollen. Zunächst werden abstrakte
Architektur\-modelle betrachtet, in \cref{sec:standards} Standards und in
\cref{sec:werkzeuge} eine Reihe bestehender Werkzeuge, die sich
teilweise daran orientieren.

\subsection{Architekturmodelle}\label{sec:architekturmodelle}

Die meisten Annotationssysteme beinhalten eine Nutzeroberfläche zum
Erzeugen der Annotationen und zur Suche nach Annotationen sowie eine
Komponente, die für Speicherung und Indexierung zuständig ist (Hunter
2009). Agosti et~al. (2006; vgl. auch Hunter 2009) beschreiben ein
dreischichtiges Architektur\-modell für solche Systeme: In der obersten
Schicht liegt das Nutzerinterface, mit dem Annotationen gesucht,
erzeugt, betrachtet, geändert und gelöscht werden können. Dabei kann es
nötig sein, unterschiedlichen Nutzern je nach Aufgabe unterschiedliche
Interfaces zur Verfügung zu stellen. Die mittlere Schicht ist eine \acro{API}
zur Kommunikation mit dem Server. Die untere Schicht ist auf dem Server
für die Speicherung der Annotationen in einer Datenbank oder einem
Tripelspeicher zuständig. Die drei Schichten kommunizieren über \acro{HTTP}.

Das wichtigste Unterscheidungsmerkmal von Annotationssystemen aus
Datenhaltungsperspektive ist die Ablageart: Die Annotationen können
entweder im annotierten Dokument oder separat gespeichert werden (Hunter
2009; Lordick et~al. 2016). Eine separate Speicherung ist aufwändiger,
wenn an nur einem Dokument gearbeitet wird; sie erhöht außerdem die
Gefahr toter Links. Wenn jedoch verschiedene Dokumente annotiert werden
oder Dokumente unabhängig mehrfach annotiert werden, ist sie flexibler
und schneller (Hunter 2009).

Ein häufig zitiertes Architekturmodell für Annotationssyteme, das auf
separate Speicherung und \acro{W}3\acro{C}-Standards setzt, ist \emph{Annotea}\footnote{\url{https://www.w3.org/2001/Annotea/}}
(Kahan et~al. 2002). Es legt Aussagen anderer Autoren über ein
Webdokument als externe Annotationen ab. Annotea ist als
Client-Server-Modell konzipiert. In der Referenz\-implementierung wird
Apache\footnote{\url{https://httpd.apache.org/}} als Webserver und der
Browser Amaya\footnote{\url{https://www.w3.org/Amaya/}} als Client
eingesetzt. Annotationen werden in einer \acro{RDF}-Datenbank auf dem Server
gespeichert und über \acro{CRUD}-\acro{HTTP}-Methoden zur Verfügung gestellt (Kahan
et~al. 2002). Sie bestehen aus einer eigenen \acro{URI}, einem Link zum
annotierten Dokument, einem \acro{XP}ointer, der die annotierte Stelle in
diesem Dokument definiert, einem Body mit dem Inhalt der Annotation,
einem Link zum Verfasser und ggf. weiteren Metadaten (Kahan et~al. 2002;
Hunter 2009). Über die \acro{URI} können Annotationen typisiert und
untereinander verknüpft werden (Kahan et~al. 2002). Auch wenn die
Referenzimplementierung in der Praxis nicht mehr nutzbar ist, weil Amaya
eingestellt wurde und ein entsprechendes Firefox-Addon\footnote{Annozilla,
  \url{http://annozilla.mozdev.org/}} nicht mehr mit aktuellen
Firefox-Versionen kompatibel ist (siehe \cref{sec:werkzeuge}), ist das
Modell weit verbreitet (Hunter 2009) und wird beispielsweise für
Europeana\footnote{\url{https://www.europeana.eu/}} eingesetzt (Grassi
et~al. 2012; Haslhofer et~al.~2010).

\subsection{Standards}\label{sec:standards}

Damit Webannotationen wissenschaftlich nutzbar bleiben, müssen sie trotz
engen fachspezifischen Nischen untereinander kompatibel sein. Dabei
hilft es, Formate und Vokabularien zu standardisieren und Normdaten
einzuführen (Lordick et~al. 2016). Standards für die semantische
Verknüpfung sind \acro{RDF}\footnote{\href{https://www.w3.org/2001/sw/wiki/RDF}{https://www.w3.org/2001/sw/wiki/\acro{RDF}}}
und die Web Ontology Language (\acro{OWL})\footnote{\href{https://www.w3.org/2001/sw/wiki/OWL}{https://www.w3.org/2001/sw/wiki/\acro{OWL}}}
(Lordick et~al. 2016), im linguistischen Kontext beispielsweise die
\emph{General Ontology for Linguistic Description} (\acro{GOLD})\footnote{\url{http://linguistics-ontology.org/}}
(Farrar und Langendoen 2003). Auch Mikroformate\footnote{\url{http://microformats.org/wiki/browsers}}
und \acro{GRDDL}\footnote{Gleaning Resource Descriptions from Dialects of
  Languages, \href{https://www.w3.org/TR/2007/REC-grddl-20070911/}{https://www.w3.org/""\acro{TR}/""2007/""\acro{REC}-grddl-20070911/}}
werden genannt (Hunter 2009). Deutlich präsenter sind im
Webannotationskontext aber das Web Annotation Data Model und das Open
Annotation Model, die hier näher vorgestellt werden sollen.

Das Web Annotation Data Model\footnote{\href{https://www.w3.org/TR/annotation-model/}{https://www.w3.org/\acro{TR}/annotation-model/}}
(Sanderson, Ciccarese und Young 2017) ist eine \acro{W}3\acro{C}-Empfehlung für die
Struktur und das Austauschformat von Web\-anno\-ta\-tionen. Eine Annotation
ist ein gerichteter Graph, der Beziehungen zwischen Ressourcen abbildet.
Die zwei Haupttypen von Ressourcen sind Bodies (der Inhalt der
Annotation) und Targets (das annotierte Objekt). Beides kann auch nur
ein Segment eines vollständigen Objekts sein. Jede Annotation hat
mindestens ein Target, eine beliebige Anzahl Bodies und beliebige
weitere Relationen. Das Web Annotation Data Model ist
protokollunabhängig (Sanderson, Ciccarese und Young 2017).

Das Open Annotation (\acro{OA}) Model (Haslhofer et~al. 2011) ist als
Kollaboration mehrerer Universitäten aus der Zusammenführung von Open
Annotation Collaboration (\acro{OAC})\footnote{\url{http://openannotation.org/}}
Ontology und Annotation Ontology (\acro{AO}) hervorgegangen. Ziel war ein
Framework zur Interoperation wissenschaftlicher Annotationen auf
digitalen Ressourcen. Das Modell basiert unter anderem auf \acro{RDF} und
Annotea (Hunter und Gerber 2012). Hunter und Gerber (2012) evaluieren \acro{OA}
für verschiedene Anwendungsszenarien und kommen zum Ergebnis, dass es
zwar sehr flexibel, aber für die meisten Szenarien auch zu komplex ist.

\subsection{Werkzeuge}\label{sec:werkzeuge}

Es gibt eine Vielzahl von Annotationssystemen. Hunter (2009)
klassifiziert sie unter anderem nach Spannweite: von
Standalone-Programmen für persönliche Sammlungen über Systeme für
digitale Bibliotheken bis hin zu webbasierten Systemen. Einige weitere
Unterscheidungsmerkmale nach Hunter (2009) sind die unterstützten
Medientypen (Webseiten, Bilder, \ldots{}), die unterstützte Granularität
(ganze Ressourcen vs.~Ausschnitte), die Struktur und Komplexität der
Annotationen (von einfachem Tagging bis zu komplexen, vernetzten
Annotationen), ob Annotationen eingebettet oder separat abgelegt werden,
und ob eigene oder fremde Inhalte annotiert werden. Im Folgenden werden
ohne besondere Ordnung einige Webannotationssyteme aufgelistet. Die
Auswahl ist durch die ursprüngliche Absicht motiviert, Systeme zu
finden, die sich potenziell für \TEI{} eignen, was jedoch auf die wenigsten
zutrifft. Weitere Systeme und Klassifikationen sind bei Hunter (2009),
Andrews, Zaihrayeu und Pane (2011) sowie Uren et~al. (2006) zu finden.

Zunächst soll auch an dieser Stelle noch einmal auf
Annotea\footnote{\url{https://www.w3.org/2001/Annotea/}}
verwiesen werden, das bereits in \cref{sec:architekturmodelle}
vorgestellt wurde. Annotea wurde im Browser \emph{Amaya}\footnote{\url{https://www.w3.org/Amaya/}}
implementiert (Hunter 2009; Kahan et~al. 2002), der jedoch nicht mehr
weiterentwickelt wird und daher nicht mehr produktiv eingesetzt werden
kann.\footnote{Die neueste Version von Amaya ist vom Januar 2012 und
  setzt das veraltete \texttt{libssl0.9.8} voraus.} Dasselbe gilt für das Addon
\emph{Annozilla,}\footnote{Annozilla, \url{http://annozilla.mozdev.org/}}
das Firefox Annotea-kompatibel machen sollte, aber nicht mehr mit
aktuellen Firefox-Versionen kompatibel ist.\footnote{Annozilla ist nicht
  signiert und ließ sich deshalb schon seit Firefox-Version 42 nicht
  mehr ohne weiteres installieren. Spätestens seit Firefox mit Version
  57 auf Webextensions umgestellt wurde, sind ältere Addons vollständig
  inkompatibel.}

Der \emph{\acro{SHOE} Knowledge Annotator}\footnote{\href{https://www.cs.umd.edu/projects/plus/SHOE/KnowledgeAnnotator.html}{https://www.cs.umd.edu/projects/plus/\acro{SHOE}/KnowledgeAnnotator.html}}
ist ein Java-Programm zur grafischen Annotation von Webseiten mit \acro{SHOE}
(Simple \acro{HTML} Ontology Extensions) oder \acro{RDF}. Der \emph{Semantic Markup,
Ontology, and \acro{RDF} Editor} (\acro{SMORE}) vom selben Entwickler unterstützt \acro{OWL}
(Hunter 2009). Beide sind aber relativ alt und scheinen nicht mehr
weiterentwickelt zu werden.\footnote{Die letzte Version vom \acro{SHOE}
  Knowledge Annotator ist von 2000. \acro{SMORE} ist als Programm nicht mehr
  auffindbar, das letzte auffindbare Paper über \acro{SMORE} ist Kalyanpur
  et~al. (2006).}

\emph{WebAnno}\footnote{\url{https://webanno.github.io/webanno/}} ist
ein webbasiertes kollaboratives Annotationstool für Text (Lordick et~al.
2016). Es ist Open Source, wird aktiv gepflegt und unterstützt \TEI{}, ist
aber relativ komplex.

\emph{Pundit}\footnote{\url{http://thepund.it/}, vorgestellt von Grassi
  et~al. (2012)} wurde im Kontext des Projekts \emph{SemLib}\footnote{Das Projekt wird vorgestellt
  von Morbidoni et~al. (2011). Die Projektwebsite
  \url{http://www.semlibproject.eu} war am 1.8.2018 nicht zugreifbar.}
entwickelt (Morbidoni et~al. 2011; Grassi et~al. 2012), basiert auf dem
Open Annotation Model und macht Webseiten durch eingebettetes JavaScript
annotierbar (Lordick et~al. 2016). Dabei werden strukturierte, semantisch
typisierte Annotationen als \acro{RDF}-Tripel erzeugt. Für Metadaten wird die
\acro{OAC}-Ontologie genutzt, die eigentlichen Annotationsdaten können
beliebige Ontologien verwenden (Grassi et~al. 2012).

\emph{Annotator.js}\footnote{\url{http://annotatorjs.org/}} (früher
\emph{Annotator}, vgl. Barbera et~al. 2013) ist eine generische
Annotationsbibliothek, die von der Open Knowledge Foundation un\-abhängig
von speziellen Anforderungen entwickelt wird und Webseiten durch
eingebettetes JavaScript annotierbar macht. Sie ist schlank, gut
dokumentiert und in der Digital-Humanities-Community etabliert -- so
wird sie zum Beispiel von der \emph{\acro{DARIAH}-\acro{DE} Annotation
Sandbox}\footnote{\url{https://annotation.de.dariah.eu/}} genutzt, um
Daten zu annotieren, die im \emph{TextGrid}-Repositorium\footnote{\url{https://de.dariah.eu/textgrid}}
veröffentlicht wurden (Lordick et~al. 2016). \emph{Neonion}\footnote{\url{http://neonion.org/}}
ist eine Open-Source-Webanwendung, die auf Annotator.js basiert (Lordick
et~al. 2016). \emph{Hypothes.is}\footnote{\url{https://web.hypothes.is/}}
ist ein Annotationsdienst, der ursprünglich auf Annotator.js aufbaute,
aber inzwischen davon unabhängig ist.\footnote{Vgl.
\href{https://web.hypothes.is/help/what-is-the-difference-between-hypothesis-and-annotatorjs/}{web.hypothes.is/help/what-is-the-difference-between-hypothesis-and-annotatorjs/}}
Er macht Webseiten ebenfalls durch eingebettetes JavaScript annotierbar
(Lordick et~al.~2016).

Zwei weitere kollaborative Online-Annotationsplattformen sind
\emph{A.nnotate}\footnote{\url{http://www.a.nnotate.com/}} (Barbera
et~al. 2013) und \emph{\acro{CATCH}}\footnote{\href{https://osc.hul.harvard.edu/liblab/projects/catch-common-annotation-tagging-and-citation-harvard}{https://osc.hul.harvard.edu/liblab/projects/catch-common-annotation-tagging-and-citation-harvard}}
(Lordick et~al. 2016). Weitere Beispiele für desktopbasierte Anwendungen
sind \emph{TextGridLab}\footnote{\url{https://textgrid.de/download}}
(Lordick et~al. 2016), das \emph{Wagsoft \acro{UAM} Corpus Tool}\footnote{\url{http://corpustool.com/}}
(O'Donnell 2008; Lordick et~al. 2016) und der semantische Desktop
\emph{Nepomuk}\footnote{\url{http://nepomuk.semanticdesktop.org/},
  \url{https://userbase.kde.org/Nepomuk}} (Hunter 2009).

Zusammenfassend lässt sich sagen, dass es eine große Auswahl an
Web\-annotations\-systemen mit teilweise sehr unterschiedlichen Zielen und
Eigenschaften gibt. Über das gesamte Spektrum hinweg treten jedoch zwei
Probleme auf, die für diese Arbeit relevant sind: Die meisten Systeme,
die auch andere Formate als \acro{HTML} annotieren, wurden als möglichst
generische Werkzeuge entwickelt. Wenn \TEI{} unterstützt wird, dann meist
nur so rudimentär, dass die Benutzung nicht ohne \TEI{}-Kenntnisse möglich
ist. Das zweite Problem ist, dass viele Werkzeuge als wissenschaftliche
Prototypen enstanden sind und schon nach verhältnis\-mäßig kurzer Zeit
nicht mehr gepflegt wurden. Nur wenige werden kontinuierlich
weiterentwickelt. Beides zeigt, dass der in \cref{sec:bedarf} genannte
Vorwurf der mangelnden Softwareunterstützung bei \TEI{} nach
Pierazzo (2016) nicht unbegründet ist.

\section{Annotationen in \TEI{}}\label{sec:annotationen-in-tei}

Ein weiterer Problembereich nach Pierazzo (2016) ist die hierarchische
Struktur von \acro{XML} (und damit auch von \TEI{}): Elemente müssen korrekt
verschachtelt werden; wenn ein Element innerhalb eines anderen beginnt,
muss es auch innerhalb des anderen enden. Überlappungen sind nicht möglich.
Annotationen dürfen dagegen nicht an bestehende Auszeichnungen gebunden
sein und müssen auch voneinander unabhängig sein (vgl.
\cref{sec:anforderungen-an-datenmodell}).

In der Literatur werden unterschiedliche Möglichkeiten beschrieben,
diese Anforderung trotz der hierarchischen Struktur von \acro{XML} zu erfüllen.
Besonders intensiv beschäftigt sich damit Bański (2010). Die
verschiedenen Methoden lassen nach dem Grad ihrer Unabhängigkeit vom
\TEI{}-Code in drei Gruppen einteilen: \TEI{}-Standard-Markup,
\TEI{}-integrierte Standoff-Annotationen und externe Standoff-Annotationen.

\newcommand{\vhead}[2]{\hspace{-1mm}\rlap{\rotatebox{90}{\makecell[tl]{#1\\\quad\,#2}}}~~~~~}

\hypertarget{tbl:muxf6glichkeiten}{}
\begin{table}[tb]
    \centering
    \caption{\label{tbl:muxf6glichkeiten}Annotationsmöglichkeiten und jeweils erfüllte Kriterien}
    \begin{tabular}{@{}lllllll@{}}
        \toprule
        & \multicolumn{6}{c}{\TEI{}-integriert $\leftrightarrow$ \TEI{}-unabhängig}\tabularnewline
        \\
        & \vhead{a) \TEI{}-Standard-Markup}{}
        & \vhead{b) Leere oder verkettete}{\TEI{}-Elemente}
        & \vhead{c) \TEI{}-integrierte Standoff-}{Annotationen in \texttt{<text>}}
        & \vhead{d) \TEI{}-integrierte Standoff-}{Annotationen in \texttt{<standOff>}}
        & \vhead{e) Externe Standoff-Annotationen}{und \TEI{}-Markup}
        & \vhead{f) Externe Standoff-Annotationen}{ohne \TEI{}-Markup}
        \tabularnewline
        \midrule
        Annotationen & \ok & \ok & \ok & \ok & \ok & \ok\tabularnewline
        unabhängige Annotationen & -- & \ok & \ok & \ok & \ok &
        \ok\tabularnewline
        Trennung Struktur / Kommentar & -- & -- & \ok & \ok & \ok &
        \ok\tabularnewline
        \texttt{\textless{}text\textgreater{}} muss nicht verändert werden & --
        & -- & -- & \ok & \ok & \ok\tabularnewline
        \TEI{}-Datei muss nicht verändert werden & -- & -- & -- & -- & \ok &
        \ok\tabularnewline
        Keine \TEI{}-Kenntnisse erforderlich & \ok & -- & -- & -- & \ok &
        \ok\tabularnewline
        \bottomrule
    \end{tabular}
\end{table}

\subsection{\TEI{}-Standard-Markup}\label{sec:standard-markup}

Jannidis, Kohle und Rehbein (2017) beschreiben \TEI{} als »ein
\acro{XML}-konformes Textauszeichnungssystem, mit dem Textwissenschaftler für
sie relevante Informationen in Texten annotieren können«. Das macht
deutlich, dass \TEI{}-""Auszeich\-nungen bereits Annotationen \emph{sind}
(\cref{tbl:muxf6glichkeiten}\,​a). Doch auch wenn zwischen Auszeichnungen
mit rein strukturierender Funktion und Annotationen mit ergänzender
Funktion unterschieden werden soll, bietet \TEI{} Möglichkeiten: Zum einen
wird eine große Zahl an Elementen mitgeliefert (Jannidis, Kohle und
Rehbein 2017; Pierazzo 2016), darunter auch solche für Notizen, die über
die Textstruktur hinausgehen (Lordick et~al. 2016). Zum anderen ist \TEI{}
erweiterbar, sodass eigene Elemente mit neuer Semantik definiert werden
können (Ide und Sperberg-McQueen 1995; Jannidis, Kohle und Rehbein
2017; Kurz 2015).

Damit ist es beispielsweise auch möglich, getrennte
Auszeichnungssegmente zu verketten und ihnen eine gemeinsame Annotation
zuzuweisen (\cref{tbl:muxf6glichkeiten}\,​b). Auf diese Weise können sich
Annotationen durchaus auf Passagen beziehen, die über bestehende
Elementgrenzen hinweg laufen. Einen ähnlichen Ansatz nutzt
beispielsweise das \emph{Online Froissart Project}\footnote{\url{https://www.dhi.ac.uk/onlinefroissart/}}
(Croenen und Romanova 2010): Dort wird je ein leeres Element für Beginn
und Ende einer Markierung genutzt; die Zusammengehörigkeit wird dann
über gleiche Attributwerte gekennzeichnet (ebenfalls
\cref{tbl:muxf6glichkeiten}​\,b).

Problematisch an diesen Lösungen ist erstens, dass es keine
Annotationswerkzeuge gibt, die solche Semantiken für die Benutzer
transparent umsetzen könnten (vgl. Bański 2010); sie setzen also gute
\TEI{}-Kenntnisse voraus. Zweitens wird die Trennung zwischen struktureller
Auszeichnung und ergänzendem Kommentar aufgehoben, die von
Geisteswissenschaftlern vielfach gewünscht wird (vgl. Bański 2010),
schon weil das Ausgangsdokument beim Annotieren unverändert bleiben soll
(vgl. \cref{sec:anforderungen-an-tei} und Hunter 2009).

\subsection{\TEI{}-integrierte Standoff-Annotationen}\label{sec:tei-integrierte-standoff-annotationen}

Standoff-Annotationen bewahren diese Trennung, indem das Markup im
\TEI{}-Dokument unberührt bleibt und die Annotationen stattdessen von einer
anderen Stelle aus die annotierte Textstelle referenzieren,
beispielsweise über \acro{XP}ointer\footnote{\href{https://www.w3.org/TR/xptr-xpointer/}{https://www.w3.org/\acro{TR}/xptr-xpointer/}}
(Bański 2010; Pierazzo 2016). Dadurch können beliebige Passagen
annotiert werden, unabhängig von Elementgrenzen und anderen
Annotationen.

Bei \TEI{}-integrierten Standoff-Annotationen werden die Annotationsdaten
in derselben Datei gespeichert wie das ursprüngliche Markup. Nach
\TEI{}-Standard werden sie innerhalb des
\texttt{\textless{}text\textgreater{}}-Elements abgelegt
(​\cref{tbl:muxf6glichkeiten}​\,c). Bański (2010) hält das nicht für
sinnvoll und schlägt vor, ein neues Element
\texttt{\textless{}standOff\textgreater{}} einzuführen, das parallel zu
den Elementen \texttt{\textless{}teiHeader\textgreater{}} und
\texttt{\textless{}text\textgreater{}} eingefügt wird und ausschließlich
Annotationsdaten enthält (​\cref{tbl:muxf6glichkeiten}\,​d).

Doch auch diese Lösung erfordert gute \TEI{}-Kenntnisse, solange es keine
Softwareunterstützung dafür gibt. Nicht nur müssen beim Annotieren
mehrere Stellen gleichzeitig betrachtet und \acro{XP}ointer o. ä. geschrieben
werden, sondern zusätzlich müssen Text und Annotationen zur Anzeige
wieder zusammengebracht werden (Bański 2010). Gleichzeitig bleiben die
Nachteile einer unvollständigen Trennung von Text und Annotationen
bestehen: Das Originaldokument wird auch hier modifiziert und
kollaboratives Arbeiten erschwert (Hunter 2009; Bański 2010).

\subsection{Externe
Standoff-Annotationen}\label{sec:externe-standoff-annotationen}

Erst bei externen Standoff-Annotationen wird dieses Problem umgangen,
indem die Annotationen in separaten Dateien oder Datenbanken abgelegt
werden (​\cref{tbl:muxf6glichkeiten}​\,e). Das Originaldokument wird dafür
nicht verändert: Es bleibt so neutral wie möglich, während Annotationen
unabhängige Sichten darauf abbilden (Bański 2010). Noch extremer ist der
Ansatz, im Originaldokument auf jegliches Markup zu verzichten
(​\cref{tbl:muxf6glichkeiten}\,​f), da auch strukturelle Auszeichnungen
strittig sein könnten (Pierazzo 2016). In jedem Fall können extern
abgelegte Annotationen als eigenes Forschungsdesiderat behandelt und
beispielsweise auch als Mikropublikationen veröffentlicht werden
(Lordick et~al. 2016; Jannidis, Kohle und Rehbein 2017)

Auch bei diesem Ansatz bleibt das Annotieren kompliziert und erfordert
Softwareunterstützung, die aber nicht \TEI{}-spezifisch sein muss. Die
Trennung von Text und Annotationen ist gegeben, auch kollaboratives
Arbeiten wird begünstigt, weil mehrere Annotatoren nicht in dieselbe
Datei schreiben müssen.

\chapter{Lösungsansatz}\label{sec:luxf6sungsansatz}

Im Folgenden werden Lösungsansätze für zwei der drei Aspekte aus
\cref{sec:zu-luxf6sen} vorgestellt: in \cref{sec:datenmodell} für das
Datenmodell und in \cref{sec:normalisierung-realisierung} für die
Überführung vom Datenmodell zur Benutzeroberfläche und umgekehrt. Die
Oberfläche selbst wird erst in \cref{sec:oberfluxe4che} behandelt, weil
sie stark von der für die Umsetzung verwendeten Plattform
(\cref{sec:plattform}) abhängt.

\section{Datenmodell}\label{sec:datenmodell}

In \cref{sec:annotationen-in-tei} wurden drei grundlegende Möglichkeiten
vorgestellt, \TEI{}-Dokumente zu annotieren. Die ersten beiden --
\TEI{}-Standard-Markup und \TEI{}-""integrierte Standoff-Annotationen -- sind
für diese Arbeit nicht geeignet, weil sie das \TEI{}-Dokument verändern,
was die Anforderungen nicht zulassen (vgl.
\cref{sec:anforderungen-an-tei}). Es bleibt also nur die Möglichkeit
externer Standoff-Annotationen: Sämtliche Annotationsdaten müssen
getrennt vom \TEI{}-Dokument gespeichert werden. Das hier vorgeschlagene
Datenmodell lässt sich bei Bedarf auch auf das in \cref{sec:standards}
vorgestellte Web Annotation Data Model abbilden.

Für Annotationen kann die Definition aus
\cref{sec:anforderungen-an-datenmodell} verwendet werden. In veränderter
Reihenfolge, mit etwas anderen Bezeichnungen und zusätzlich einer
eindeutigen \acro{ID} zur Unterscheidung ansonsten gleicher Annotationen ergibt
sich ein Tupel
\[Annotation = (ID, Dokument, Textstelle, Annotationstext, Annotator).\]
\(Dokument\) ist die \acro{URI} eines \TEI{}-Dokuments. Somit können nicht nur
Dokumente annotiert werden, die innerhalb des Annotatationssystems
abgelegt werden, sondern auch beliebige Dokumente im Web. \(Textstelle\)
ist eine Menge disjunkter konvexer Mengen zeichengenauer Textpositionen,
kann also als Liste von Passagen abgebildet werden, die wiederum durch
Start- und Endposition im Text definiert sind:
\[Passage = (Startposition, Endposition)\] Sowohl \(Startposition\) als
auch \(Endposition\) sind Textpositionen, die jeweils durch einen
eindeutigen \acro{XP}ath und den in Zeichen gemessenen Versatz vom Beginn des
durch den \acro{XP}ath angegebenen Elements definiert werden:
\[Textposition = (XPath, Offset)\] Damit der \acro{XP}ath immer eindeutig, aber
trotzdem möglichst robust gegenüber Veränderungen des Dokuments ist,
sollte er immer relativ zum nächsthöheren Element mit \acro{ID} sein, falls ein
solches vorhanden ist, und für jede Stufe eine Ordnungszahl enthalten.
Die genaue Definition des Offsets wird in \cref{sec:offset} behandelt.

Da die einzelnen Annotationen voneinander unabhängig gespeichert werden,
stellen Überlappungen im Datenmodell noch kein Problem dar. Anders sieht
das beim Überführen in die Benutzeroberfläche aus.

\section[Normalisierung und Realisierung von
Annotationen]{Normalisierung und Realisierung\\von
Annotationen}\label{sec:normalisierung-realisierung}

Für den Lösungsansatz wird angenommen, dass die Editionen in der
Be\-nutzer\-ober\-fläche durch eine Browser-Engine dargestellt werden und
deshalb mit einem \acro{DOM} (Document Object Model) gearbeitet werden muss,
während der \acro{XML}-Quelltext nicht zugreifbar ist. Sowohl die
Visualisierung von Annotationen als auch das Erzeugen neuer Annotationen
muss daher über die \acro{DOM}-\acro{API} erfolgen: das Erzeugen, indem auf
Textselektion reagiert wird, und das Visualisieren, indem die
annotierten Passagen im \acro{DOM} ausgezeichnet werden.

Im Datenmodell sind die einzelnen Annotationen völlig unabhängig
voneinander, sie können sich auch auf überlappende Textstellen beziehen.
Im \TEI{}-Dokument müssen sie sich aber immer der Baumstruktur des \acro{DOM}s
unterwerfen, die keine Überlappungen zulässt, und können sich auch
ansonsten gegenseitig beeinflussen.

Bevor die konkreten Problemfälle und jeweiligen Lösungsvorschläge
vorgestellt werden, sollten für etwas mehr Klarheit zunächst einige
Begriffe voneinander abgegrenzt werden. Diese Arbeit verwendet die
folgenden Bezeichnungen (vgl. auch \cref{fig:begriffe}):

\begin{description}
\tightlist
\item[Passage]
ist die maximale zusammenhängende Textpassage, auf die sich eine
Annotation bezieht. Eine Annotation kann sich auch auf mehrere Passagen
beziehen, wenn unzusammenhängende Textpassagen beschrieben werden
sollen.
\item[Elementgrenze]
ist der Anfang oder das Ende eines \TEI{}-Elementes, durch ein öffnendes
oder schließendes Tag gekennzeichnet.
\item[Segment]
ist ein Teil einer Annotationspassage, der nicht über Elementgrenzen
hinweg läuft und durch eigene Tags begrenzt ist. Annotationspassagen
können aus nur einem Segment bestehen, wenn sie nicht durch andere
Elementgrenzen unterbrochen werden.
\item[Start- und Endpositionen]
sind die zeichengenauen Positionen im Dokument, an denen eine Passage
oder ein Segment beginnt bzw. endet und entsprechende Tags eingefügt
werden müssen. Sie werden durch einen Bezugsknoten und einen Offset
definiert.
\item[Offset]
ist der in Zeichen gemessene Abstand einer Start- oder Endposition vom
Beginn des Inhalts des Bezugselements/-textknotens (\cref{sec:offset}).
\item[Normalisierung]
ist die Umrechnung einer Start- oder Endposition, die einen Textknoten
als Bezugselement verwendet, in eine entsprechende
markierungsunabhängige Position, die ein \TEI{}-Element als Bezugselement
verwendet und im Datenmodell gespeichert werden kann
(\cref{sec:normalisierung}).
\item[Realisierung]
ist die Umrechnung einer markierungsunabhängigen Start- oder
Endposition, die ein \TEI{}-Element als Bezugselement verwendet, in eine
entsprechende Position, die sich auf einen Textknoten im aktuellen \acro{DOM}
bezieht und an der ein Markierungstag eingefügt werden kann
(\cref{sec:realisierung}).
\end{description}

\begin{figure}
\centering
\bigskip
\includegraphics[width=0.8000\textwidth]{Bilder/begriffe.pdf}
\medskip
\caption{Illustration in dieser Arbeit verwendeter
Begriffe}\label{fig:begriffe}
\bigskip
\end{figure}

Grundsätzlich müssen Annotationspassagen, die über Grenzen anderer
\TEI{}-Elemente hinweg laufen, an diesen in einzelne Segmente unterteilt
werden, um die hierarchische Struktur zu wahren. Wesentlich komplexere
Auswirkungen haben aber die Verschiebungen, die durch das Einfügen,
Entfernen und Verändern bestehender Tags auftreten.

\cref{sec:offset} beschreibt diese Auswirkungen und schlägt eine
Strategie zum Umgang mit ihnen vor, die in \cref{sec:normalisierung} zur
Normalisierung und \cref{sec:realisierung} zur Realisierung gebraucht
wird.

\subsection{Offset}\label{sec:offset}

Das Ende jedes Segments verschiebt sich um die Länge des öffnenden Tags
nach hinten (\cref{fig:offset1}). Bei mehreren Annotationssegmenten
innerhalb eines gemeinsamen Elternelements entstehen zusätzliche
Abhängigkeiten: Wenn zwei Segmente aufeinander folgen (unabhängig davon,
ob sie direkt aneinander angrenzen oder ob weiterer Text dazwischensteht), wird das zweite um die Länge der Tags des ersten verschoben
(\cref{fig:offset2}). Wenn ein Segment innerhalb eines anderen beginnt
und endet, wird es um die Länge des öffnenden Tags des äußeren Segments
verschoben. Gleichzeitig wird das schließende Tag des äußeren Segments
um die Länge der beiden Tags des inneren verschoben
(\cref{fig:offset3}).

\begin{figure}

\centering
\subfloat[Ein einzelnes
Segment]{\includegraphics[width=0.70000\textwidth]{Bilder/offset1.pdf}\label{fig:offset1}}

\subfloat[Zwei aufeinander folgende
Segmente]{\includegraphics[width=0.70000\textwidth]{Bilder/offset2.pdf}\label{fig:offset2}}

\subfloat[Zwei verschachtelte
Segmente]{\includegraphics[width=0.70000\textwidth]{Bilder/offset3.pdf}\label{fig:offset3}}

\caption{Verschiebungen durch Einfügen von Segment-Tags}

\label{fig:offset}

\end{figure}

All diese Abhängigkeiten müssen jeweils nach dem Erzeugen einer
Anno\-ta\-tion im Dokument zur Speicherung eliminiert
(\emph{Normalisierung,} \cref{sec:normalisierung}) und beim Laden zur
Darstellung wieder rekonstruiert werden (\emph{Realisierung,}
\cref{sec:realisierung}). Das genaue Vorgehen dabei hängt davon ab, wie
der Offset gemessen wird. Eine intuitive Zählungsmethode ist folgende:

\begin{enumerate}
\def\labelenumi{(\arabic{enumi})}
\tightlist
\item
  Vom Bezugspunkt aus werden alle Zeichen des Quelltextes bis zur
  gesuchten Textposition gezählt.
\end{enumerate}

\noindent Diese Methode berücksichtigt aber nicht, dass zwischen
Bezugspunkt und gesuchter Position die Tags anderer Markierungselemente
eingefügt oder entfernt werden könnten, und ist somit ungeeignet.
Stattdessen müssen beim Zählen die Tags aller Markierungselemente
übersprungen werden:

\begin{enumerate}
\def\labelenumi{(\arabic{enumi})}
\setcounter{enumi}{1}
\tightlist
\item
  Vom Bezugspunkt aus werden alle Zeichen des Quelltextes bis zur
  gesuchten Textposition gezählt,
  \texttt{\textless{}mark\textgreater{}}-Tags ausgenommen.
\end{enumerate}

\noindent Damit können beliebige Markierungselemente hinzugefügt oder
entfernt werden, ohne dass sich der Offset einer Textposition ändern.

Es gibt aber einen weiteren Unsicherheitsfaktor durch
\acro{DOM}-Implemen\-tie\-run\-gen: Was eine \acro{DOM}-\acro{API} als Inhalt eines Elements
zurückgibt -- und worin gezählt wird --, ist nicht notwenigerweise das,
was im Quelltext steht. Während der Umsetzung dieser Arbeit konnte
beispielsweise beobachtet werden, dass Elemente im \acro{DOM} zusätzliche
xmlns-Attribute enthielten oder leere Elemente, die im Quelltext die
Kurzform \texttt{\textless{}tag/\textgreater{}} hatten, im \acro{DOM} zu
\texttt{\textless{}tag\textgreater{}\textless{}/tag\textgreater{}}
expandiert wurden. Geschehen solche Änderungen innerhalb des
Bezugselements und vor der gesuchten Position, verschiebt sich der
Offset ebenfalls. Da die \acro{DOM}-\acro{API} keine Möglichkeit bietet, auf den
unveränderten Quelltext zuzugreifen, ist kein Abgleich möglich, der
dieses Verhalten feststellen und geeignet behan\mbox{deln könnte}.
Es müssen daher beim Zählen von vornherein auch alle anderen Tags
übersprungen werden. Die Zählung kann sich somit auf Textknoten
beschränken:

\begin{enumerate}
\def\labelenumi{(\arabic{enumi})}
\setcounter{enumi}{2}
\tightlist
\item
  Vom Bezugspunkt aus werden alle in Textknoten enthaltenen Zeichen bis
  zur gesuchten Textposition gezählt.
\end{enumerate}

\noindent Grundsätzlich könnten auch konsekutive Steuerzeichen
übersprungen werden:

\begin{enumerate}
\def\labelenumi{(\arabic{enumi})}
\setcounter{enumi}{3}
\tightlist
\item
  Vom Bezugspunkt aus werden alle in Textknoten enthaltenen Zeichen bis
  zur gesuchten Textposition gezählt, wobei mehrere Steuerzeichen in
  Folge als ein einzelnes Zeichen gezählt werden.
\end{enumerate}

\noindent Das hätte den Vorteil, dass der Offset etwa gegenüber
veränderten Zeileneinrückungen stabil bliebe.

Da sich das \TEI{}-Dokument aber laut Anforderungen nicht verändert, im \acro{DOM}
während dieser Arbeit keine derartigen Veränderungen festgestellt werden
konnten und das Entfernen von Steuerzeichen verhältnismäßig
fehlerträchtig ist, weil unterschiedliche Vorgehensweisen denkbar wären,
wird in dieser Arbeit darauf verzichtet. Im Folgenden wird daher davon
ausgegangen, dass der Offset nach Methode 3 berechnet wird.

\subsection{Normalisierung}\label{sec:normalisierung}

Die Normalisierung von Zeichenpositionen ist immer dann nötig, wenn eine
im Dokument neu angelegte oder veränderte Annotation ins Datenmodell
übertragen werden soll. Dafür muss die Abhängigkeit von anderen
Annotationen eliminiert werden. Ausgangspunkt ist eine vom Nutzer
gewählte Annotationspassage in Form eines vom \acro{DOM} bereitgestellten
\texttt{Selection}-Objekts mit der jeweiligen Start- und Endposition.
Die beiden Positionen werden jeweils durch einen \acro{DOM}-Knoten und einen
Offset definiert und unabhängig voneinander normalisiert
(\cref{alg:normalisierung}).

Hierzu wird zunächst von der jeweiligen Position im \acro{DOM} nach oben
gelaufen, bis ein \TEI{}-Element gefunden wird, das selbst kein
Annotationssegment darstellt. Falls sich unterwegs andere
Annotationssegmente finden, die die gesuchte Position einhüllen, wird
deren Position in ihrem Elternelement zum bisherigen Offset addiert, da
sie in diesem Moment das Bezugselement waren.

\begin{algorithm}
    \floatname{algorithm}{Algorithmus}
    \caption{Normalisierung}
    \label{alg:normalisierung}
    \begin{algorithmic}
        \REQUIRE Textnode $t$ contains the wanted position $pos$ at offset $o.$
        \ENSURE \acro{XP}ath $x$ refers to a \TEI{} element containing $pos$ at offset $o.$
        \STATE $p, d \leftarrow$ parent element and distance of $t$
        \WHILE{$p$ is a mark}
            \STATE $q, e \leftarrow$ parent element and distance of $p$
            \STATE $p \leftarrow q$
            \STATE $d \leftarrow d + e$
        \ENDWHILE
        \STATE $o \leftarrow o + d$
        \STATE $x \leftarrow$ unambiguous \acro{XP}ath for $p$
        \RETURN $x, o$
    \end{algorithmic}
\end{algorithm}

Der Schritt nach oben \emph{(parent element and distance of)} gibt das
nächsthöhere Element im \acro{DOM} sowie den Offset des gegebenen Knotens in
diesem Element zurück. Wie in \cref{sec:offset} erläutert, werden dabei
keine Tags mitgezählt (Methode 3).

Der Normalisierungsalgorithmus gibt einen \acro{XP}ath für das neue
Bezugs\-element sowie den Offset der gesuchten Position in diesem Element
zurück. Da Anfangs- und Endposition unabhängig voneinander betrachtet
werden, funktioniert das Verfahren auch, wenn eine Annotationspassage
über Elementgrenzen hinweg läuft.

\subsection{Realisierung}\label{sec:realisierung}

Der umgekehrte Weg ist nötig, wenn Annotationen aus dem Datenmodell im
\TEI{}-Dokument dargestellt werden sollen. Für eine normalisierte Position,
definiert durch einen \acro{XP}ath und einen Offset, wird mit
\cref{alg:realisierung} die reale Position in einem Textnode des
Dokuments ermittelt.

Dazu wird vom entsprechenden \TEI{}-Element ausgehend jeweils zum in
Präorder-Reihenfolge nächsten Knoten gesprungen. Handelt es sich bei
diesem um einen Textknoten, der lang genug ist, dass er den aktuellen
Offset enthält, dann ist der gesuchte Knoten erreicht, die Schleife wird
abgebrochen und Knoten und Offset werden zurückgegeben. Handelt es sich
um einen Textknoten, der zu kurz für den aktuellen Offset ist, wird
seine Länge vom Offset abgezogen und zum nächsten Knoten gesprungen. Ist
der aktuelle Knoten ein Markierungselement, wird zu seinem ersten
Kindknoten gesprungen (ohne den Offset zu verändern, da die Tags nicht
mitgezählt werden dürfen). Falls der aktuelle Knoten ein anderes
\TEI{}-Element als eine Markierung ist, wird seine Länge abzüglich
enthaltener Tags vom Offset subtrahiert und zum nächsten
Geschwisterknoten gesprungen.\footnote{Das Element selbst darf die
  gesuchte Position nicht enthalten, da die Vorbedingung den \acro{XP}ath des
  innerstmöglichen Elements fordert. Aus demselben Grund und weil
  Textknoten keine und Markierungen keine anderen Elemente enthalten,
  muss sich das Element auf der obersten zu durchsuchenden \acro{DOM}-Ebene
  befinden. Da die gesuchte Position noch kommen muss, muss es also
  mindestens einen nächsten Geschwisterknoten geben.}

\begin{algorithm}
    \floatname{algorithm}{Algorithmus}
    \caption{Realisierung}
    \label{alg:realisierung}
    \begin{algorithmic}
        \REQUIRE \acro{XP}ath $x$ unambiguously refers to the innermost \TEI{} element that is not a mark element and contains the wanted position $pos$ at offset $o.$
        \ENSURE Textnode $n$ contains $pos$ at offset $o.$
        \STATE $n \leftarrow$ first child node of the element described by $x$
        \LOOP
            \IF{$n$ is a textnode with $\left|n\right| \geq o$}
                \STATE break
            \ELSIF{$n$ is a textnode (with $\left|n\right| < o$)}
                \STATE $o \leftarrow o - \left|n\right|$
                \STATE $n \leftarrow$ next node from $n$ in pre-order
            \ELSIF{$n$ is a mark element}
                \STATE $n \leftarrow$ first child of $n$
            \ELSE
                \STATE $o \leftarrow o - \left|n\mathrm{~without~any~ tags}\right|$
                \STATE $n \leftarrow$ next sibling of $n$
            \ENDIF
        \ENDLOOP
        \RETURN $n, o$
    \end{algorithmic}
\end{algorithm}

Sobald für eine Annotationspassage die Anfangs- und die Endposition im
Dokument bekannt sind, kann der Text dazwischen ausgezeichnet werden. Da
sich Elemente in \TEI{} nicht überlappen dürfen, müssen zunächst alle
Passagen, die sich über Elementgrenzen hinweg erstrecken, an diesen
Grenzen in Segmente zerlegt werden. Die Segmente werden dann unabhängig
voneinander dargestellt, indem die betreffenden Zeichen in
Annotationselemente gehüllt weden.

Da bei der Realisierung nicht zwischen Anfangs- und Endpositionen
unter\-schieden wird, kommt es bei direkt aufeinander folgenden
Markierungen zu zeichenlosen Überlappungen, also leeren
Markierungselementen innerhalb der jeweils anderen Markierung:

\hypertarget{test}{\label{test}}
\begin{Shaded}
\begin{Highlighting}[]
\KeywordTok{<mark>}\NormalTok{Markierung 1}\KeywordTok{<mark></mark></mark><mark>}\NormalTok{Markierung 2}\KeywordTok{</mark>}
\end{Highlighting}
\end{Shaded}

\noindent Das ist zwar grundsätzlich kein Problem, es erschwert aber die
Übersicht und lässt sich leicht verhindern, indem auf das Einhüllen von
Segmenten verzichtet wird, deren Anfangs- und Endposition identisch
sind.

Optional kann auch bei Segmenten, die nur aus Steuerzeichen bestehen,
auf die Hervorhebung verzichtet werden. Das verhindert, dass zwischen
mehreren in einer Annotationspassage enthaltenen Blockelementen einzelne
Leerzeichen oder Ähnliches markiert werden. Es kann aber gleichzeitig
auch das Problem verursachen, dass bei sich überlappenden
Annotationspassagen unter Umständen zusammengehörige Zeichenfolgen nicht
korrekt ausgezeichnet werden, weil dazwischen Leerzeichen fehlen.

\chapter{Umsetzung}\label{sec:umsetzung}

Dieses Kapitel stellt das \TEI{}-Annotationssystem \annoteitor{} vor, eine
prototypische Implementierung des Lösungsansatzes aus
\cref{sec:luxf6sungsansatz}. Nachdem \cref{sec:plattform} zunächst auf
die zugrunde liegende Plattform und \cref{sec:poc} auf einen ersten
Proof of Concept eingeht, beschreiben die
\cref{sec:architektur,sec:server,sec:client} die Architektur, den Server
und den Client des vollständigen Prototypen.

\section{Plattform}\label{sec:plattform}

Der \annoteitor{} wurde als Webanwendung entwickelt. Das hat eine Reihe von
Vorteilen: Eine Webanwendung ist im Projektumfeld schnell einsetzbar, da
die einzelnen Teilnehmer nichts installieren müssen. Kollaboratives
Arbeiten ist einfach machbar, wenn alle Daten auf einem zentralen Server
gespeichert werden und somit sofort für das gesamte Projektteam
verfügbar sind. Besondere Locking\-mechanismen sind dabei nicht
erforderlich, weil jeder Benutzer nur auf die eigenen Annotationen
schreibend zugreift. Außerdem kenne ich mich mit Webtechnologien besser
aus als mit nativen Frameworks, was eine effizientere Entwicklung
versprach.

Letzteres ist auch der entscheidende Grund, für die serverseitige
Implementierung Ruby on Rails\footnote{\url{https://rubyonrails.org/}}
zu verwenden, das für Rapid Prototyping besonders gut geeignet ist.
Damit der Client ohne zusätzliche Addons im Browser läuft, beschränken
sich die clientseitigen Technologien auf \acro{XML}, \acro{HTML}, \acro{CSS} und JavaScript.
Da es sich nur um einen Prototypen für einen sehr engen Benutzerkreis
handelt, werden für einen geringeren Implementierungsaufwand die jeweils
aktuellen Versionen \acro{HTML}5 und \acro{CSS}3 vorausgesetzt. Die Skripte wurden
zwar in \acro{ES}6 implementiert, werden aber vom Server mithilfe von Sprockets
\acro{ES}6\footnote{\url{https://github.com/TannerRogalsky/sprockets-es6}} und
Babel\footnote{\url{https://babeljs.io/}} in \acro{ES}5 transpiliert, bevor sie
ausgeliefert werden.

\section{Proof of Concept}\label{sec:poc}

Um zu prüfen, welchen Anteil der benötigten Funktionalität bereits die
Browser anbieten und was clientseitig zusätzlich implementiert werden
muss, wurde zunächst ein serverloser Proof of Concept ohne
Persistenzfähigkeiten entwickelt. Er beschränkte sich darauf, auf
Textselektionen im Browser zu reagieren, Annotationen zu erzeugen und
darzustellen, sowie eine Normalisierung der markierten Textstellen
durchzuführen und das Ergebnis anzuzeigen. Der dafür geschriebene Code
wurde anschließend in den Client des vollständigen Prototypen
übernommen, der in den verbleibenden Abschnitten dieses Kapitels
beschrieben wird.

\section{Architektur}\label{sec:architektur}

Der \annoteitor{} ist als Client-Server-System konzipiert. Der Server ist
dafür zuständig, sämtliche Daten zu verwalten (\cref{sec:server-datenmodell}),
die \TEI{}-Dokumente zusammen mit dem Client auszuliefern und anschließend
\acro{AJAX}-Anfragen des Clients zu beantworten (\cref{sec:api}), ohne
unautorisierte Zugriffe zuzulassen (\cref{sec:authentifikation}). Der
Client (\cref{sec:client}) stellt Annotationen vom Server sowie neue
Annotationen dar und übermittelt neue oder geänderte Annotationen an den
Server. Außerdem muss er die nötigen Interaktionsmöglichkeiten für den
Benutzer anbieten.

Damit ähnelt die Architektur zwangsläufig Annotea\footnote{\url{https://www.w3.org/2001/Annotea/}}
(Kahan et~al. 2002): Auch dort wird ein Client-Server-Modell mit
\acro{HTTP}-Methoden für \acro{CRUD}-Operationen verwendet, Annotationen werden
außerhalb des annotierten Dokuments gespeichert und enthalten eine
Referenz zu diesem, eine Angabe der genauen Textstelle, einen
Annotationstext und eine Referenz auf den Verfasser. Unterschiede
bestehen in den zugrunde liegenden Technologien: Während Annotea die
Annotationen in einer \acro{RDF}-Datenbank verwaltet, verwendet der \annoteitor{}
eine relationale Datenbank. Außerdem basiert er nicht wie der
Annotea-Prototyp auf Apache als Server und Amaya als Browser, sondern
setzt nur einen JavaScript-fähigen Browser und einen Server voraus, der
Rails-Applikationen ausführen kann.

\section{Server}\label{sec:server}

Da alle clientseitigen Operationen von der \acro{API} des Servers abhängig
sind, wird zunächst der Server beschrieben.

\subsection{Datenmodell}\label{sec:server-datenmodell}

Für die eigentlichen Annotationsdaten sind in der relationalen Datenbank
drei Tabellen nötig (\cref{fig:datenmodell}): Eine Annotationstabelle
speichert die \acro{ID}, eine Referenz auf das annotierte Dokument, die \acro{ID} des
Verfassers und den Annotationstext. Eine zusätzliche Markierungstabelle
verwaltet die Annotationspassagen, bestehend aus der \acro{ID} der Annotation,
einer Start- und einer Endposition. Die dritte Tabelle verwaltet die
Benutzer.

Die \TEI{}-Editionen müssen nicht in die Datenbank geschrieben werden. Sie
werden stattdessen als \acro{XML}-Dokumente im öffentlichen Verzeichnis des
Servers abgelegt und können anschließend über eine aus dem Dateinamen
abgeleitete \acro{ID} referenziert werden. Denkbar wäre auch, die \acro{XML}-Dokumente
über ihre \acro{URL}s zu referenzieren -- so könnten auch Editionen annotiert
werden, die auf anderen Servern veröffentlicht wurden.

\begin{figure}
\centering
\includegraphics{Bilder/datenmodell.pdf}
\caption{Serverseitiges Datenmodell}\label{fig:datenmodell}
\end{figure}

Voraussetzung für die korrekte Darstellung ist lediglich, dass das
\acro{XML}-Dokument eine ebenfalls öffentlich zugängliche \acro{CSS}-Datei
referenziert -- andernfalls würde der Browser den \acro{XML}-Code anzeigen.
Optional können in einem separaten Verzeichnis nach der Editions-\acro{ID}
benannte Unterordner mit Bilddateien angelegt werden. Diese werden dann
in alphabetischer Reihenfolge als Faksimileseiten behandelt.

\subsection{\acro{REST}-\acro{API}}\label{sec:api}

Alle nötigen Daten sind über eine \acro{REST}-\acro{API} abrufbar. So kann der Client
auf Editionen zugreifen sowie Benutzer, Annotationen und Markierungen
anlegen, abrufen, ändern und löschen.

\subsection{Authentifikation und
Autorisierung}\label{sec:authentifikation}

Fremde Annotationen sollen laut Anforderungen nur vom Projektteam
eingesehen werden können. Daraus folgt, dass Annotatoren authentifiziert
werden müssen, bevor sie bestehende eigene Annotationen sehen können.
Ausschließlich gerade erzeugte Annotationen zu sehen, wäre nicht
zielführend, also kann das gesamte Projekt auf angemeldete Benutzer
beschränkt werden. Je nach Rolle (externe Fachexperten oder zentrales
Projektteam) sind dann außer den reinen Editionen nur die eigenen
Annotationen oder alle Annotationen und Benutzer sichtbar.

Um den Verwaltungsaufwand im Projekt so niedrig wie möglich zu halten,
bekommt ein Benutzer, der sich neu registriert, automatisch die
erweiterten Rechte, falls (und \emph{nur} falls) sie noch niemand sonst
hat. Jeder Benutzer mit erweiterten Rechten kann sie auch anderen
Benutzern zuteilen.

Für die Umsetzung der Authentifikation und Autorisierung wird das
Rails-Gem Devise\footnote{\url{https://github.com/plataformatec/devise}}
verwendet, das die komplette benötigte Funktionalität mitbringt und
lediglich passend konfiguriert werden muss.

\section{Client}\label{sec:client}

Basierend auf den Informationen zum Server kann nun auch der Client
vorgestellt werden. \cref{sec:oberfluxe4che} beschreibt zunächst die
Benutzeroberfläche, \cref{sec:implementierung} behandelt im Anschluss
die Implementierung.

\subsection{Weboberfläche}\label{sec:oberfluxe4che}

Als Startseite (nach erfolgreicher Anmeldung) dient eine Übersicht über
die Editionen (\cref{fig:editionsuxfcbersicht}). Von hier können alle
bestehenden Editionen geöffnet werden. Außerdem können über die
Navigationsleiste am oberen Bildschirmrand das eigene Profil oder -- je
nach aktuellen Rechten -- die Liste aller Benutzer verwaltet und die
aktuelle Sitzung beendet werden. Die Option, neue Editionen hochzuladen,
wurde aus Zeitgründen noch nicht implementiert. Über den Link in der
oberen linken Ecke kommt man von allen anderen Seiten zur
Editionsübersicht~zurück.

\begin{figure}
\centering
\includegraphics{Bilder/screenshot_editions2.png}
\caption{Editionsübersicht}\label{fig:editionsuxfcbersicht}
\end{figure}

Öffnet der Benutzer eine der Editionen, wird diese in einem dreiteiligen
Fenster dargestellt (\cref{fig:edition}): Im linken Bereich wird, falls
vorhanden, das Faksimile angezeigt. Der mittlere Bereich zeigt das
\TEI{}-Dokument an, der rechte -- wenn er gerade aktiv ist -- den
Annotationseditor.

\begin{figure}
\centering
\includegraphics{Bilder/screenshot_edition_anonymisiert.png}
\caption{Edition mit Annotationen (Mail-Adresse unkenntlich
gemacht)}\label{fig:edition}
\end{figure}

Zur Einbindung des \TEI{}-Dokuments wurden unterschiedliche Möglichkeiten
geprüft: Ein \texttt{\textless{}object\textgreater{}}-Element mit
\texttt{data}-Attribut ist nicht geeignet, weil Java\-Script nicht von
außen auf das eingebettete Objekt zugreifen kann. Um den Inhalt direkt
in das \texttt{\textless{}object\textgreater{}} einzubetten,
müsste er aus gültigem \acro{HTML} bestehen. Ein
\texttt{\textless{}embed\textgreater{}}-Element würde ein geeignetes
Plugin zur Darstellung des Inhalts voraussetzen. Ein
\texttt{\textless{}iframe\textgreater{}} kann dagegen beliebigen
Quelltext enthalten, der zum Rendern vom Browser interpretiert wird und
für JavaScript zugreifbar ist, solange er von derselben Domain stammt
wie die umgebende Seite.

Im eingebetteten \TEI{}-Dokument werden alle Passagen markiert, die zu
Annotationen gehören, die für den Benutzer zugänglich sind. Im \acro{DOM}
erfolgt diese Markierung an \acro{HTML} angelehnt durch ein
\texttt{\textless{}mark\textgreater{}}-Element. Die visuelle
Formatierung muss verhältnismäßig salient sein, aber auch bei
verschachtelten oder überlappenden Markierungen erkennen lassen, welche
Markierung wo beginnt und endet. Am eindeutigsten wären zu diesem Zweck
Rahmen; sie müssten aber elementübergreifend funktionieren, was per \acro{CSS}
bei hinreichend komplexen Verschachtelungen ähnlich schwierig zu
handhaben ist wie bei Zeilenumbrüchen innerhalb von Markierungen. Daher
verwendet der \annoteitor{} stattdessen Hinterlegungen in einer Farbe, die
dem jeweiligen Annotator zugeordnet wurde.

Damit auch Überlappungen und Verschachtelungen sichtbar bleiben, haben
diese Hinterlegungen eine geringe Opazität und lassen darunter liegende
Markierungen durchscheinen. Erst wenn der Benutzer mit der Maus über
eine Annotationspassage fährt, werden diese und alle weiteren Passagen
derselben Annotation voll-opak hinterlegt, damit ihre
Zusammengehörigkeit erkennbar wird und sie besser von anderen Passagen
abgegrenzt werden.

Nach einem Klick auf eine Annotationspassage öffnet sich im rechten
Fensterbereich der Annotationseditor mit dem bearbeitbaren Annotationstext
und die \acro{ID} der Annotation wird in die \acro{URL} integriert. So können auch
einzelne Annotationen im Kontext der Edition verlinkt werden. Wird ein
solcher Link geöffnet, öffnet der \annoteitor{} die Annotation im Editor
und scrollt automatisch zur ersten zugehörigen Annotationspassage.
Sobald eine andere Passage angeklickt oder der Editor durch einen Klick
auf eine nicht markierte Fläche geschlossen wird, wird die aktuelle \acro{URL}
entsprechend angepasst, damit sie jederzeit den aktuellen Zustand
widerspiegelt.

Selektiert der Benutzer Text in einer Edition, wird automatisch eine
neue Annotationspassage erzeugt und der Annotationseditor geöffnet. Je
nachdem, ob vorher bereits eine Annotation aktiv war, wird die neue
Passage mit der bestehenden oder einer neuen Annotation verknüpft. Eine
bisher nicht umgesetzte Alternative wäre, dieses Verhalten über einen
Button oder die Tastatur zu steuern. Das Löschen von Annotationen
erfolgt über einen Button im Annotationseditor. Alternativ könnten
Annotationen dann gelöscht werden, wenn die letzte zugehörige Passage
entfernt wurde. Auch diese Alternative konnte nicht umgesetzt werden, da
das Entfernen einzelner Passagen (oder auch einzelner Zeichen aus
Passagen, was analog zum Hinzufügen von Passagen über die Tastatur
gesteuert werden könnte) noch nicht implementiert ist.

Neben den beiden bisher beschriebenen Seiten existieren hauptsächlich zu
Debugging-Zwecken weitere Seiten, die bestimmte Datenbankinhalte
auflisten, etwa globale Übersichten über alle Annotationen und
Annotationspassagen. Genauso wie die Seiten zur Benutzerverwaltung sind
sie noch nicht angemessen in die Webanwendung integriert, können aber
bei Bedarf endnutzertauglich ausgearbeitet werden.

\subsection{Implementierung}\label{sec:implementierung}

Die Implementierung der clientseitigen Abläufe ist multiparadigmatisch
umgesetzt: Die Nutzerinteraktion wird ereignisorientiert behandelt, die
Datenverwaltung erfolgt objektorientiert, Normalisierung und
Realisierung orientieren sich an funktionalen Prinzipien.\footnote{Sie
  sind nicht rein funktional umgesetzt, weil intern Zugriffe auf die
  \acro{DOM}-\acro{API} stattfinden.} Die Funktionalität ist auf mehrere Skripte
aufgeteilt. Die Konfiguration des Clients erfolgt über einen
Key-Value-Store. Dort lässt sich unter anderem einstellen, ob
Annotationssegmente markiert werden sollen, die nur Steuerzeichen
enthalten (vgl. letzter Absatz von \cref{sec:realisierung}).

Es gibt unterschiedliche Ereignisse, mit denen der Nutzer entsprechende
Aktionen auslöst:

\begin{itemize}
\tightlist
\item
  Wenn eine Edition geöffnet wird, werden die zugehörigen Annotationen
  und Markierungen (ggf. nach Zugriffsrechten gefiltert) vom Server
  geladen und dargestellt.
\item
  Wenn Text markiert wird, wird eine Annotationspassage dafür erzeugt.
\item
  Wenn ein Annotationssegment mit der Maus überfahren oder verlassen
  wird, werden alle zur selben Annotation gehörigen Segmente
  hervorgehoben bzw. die Hervorhebung entfernt.
\item
  Wenn eine Annotation angeklickt oder ihre \acro{URL} aufgerufen wird, wird
  sie hervorgehoben und im Annotationseditor geöffnet.
\item
  Wenn in einen leeren Bereich geklickt wird oder bevor eine andere
  Annotation geöffnet wird, werden Änderungen an der vorherigen
  gespeichert und der Annotationseditor geschlossen.
\end{itemize}

\noindent Diese Aktionen greifen auf die Annotationen und Markierungen
zurück, die lokal objektorientiert verwaltet werden.

Die lokalen Datenstrukturen sind nötig, weil die Informationen für
einzelne Datensätze an unterschiedlichen Stellen entstehen. Die \acro{ID}s
kommen -- um Kollisionen zu vermeiden -- aus der serverseitigen
Datenbank; die übrigen Informationen stammen vom Client. Würden die
Annotationen zuerst auf dem Server angelegt, würde das visuelle Feedback
für den Benutzer stark verzögert, weil erst eine \acro{AJAX}-Anfrage gestellt
und beantwortet werden müsste. Stattdessen werden die Annotationen erst
lokal ohne \acro{ID} angelegt, sofort angezeigt und erst danach an den Server
geschickt und vervollständigt wieder geholt, um die lokale Datenstruktur
aktualisieren zu können. Dabei auftretende Netzwerkfehler werden derzeit
noch nicht behandelt.\footnote{Wenn Requests nach einer Änderung nicht
  beantwortet werden, gehen die Änderungen verloren. Für produktive
  Einsetzbarkeit müsste hier zumindest eine Fehlermeldung erfolgen.}

Bei jeder Änderung von Annotationen werden alle zugehörigen Markierungen
mit zum Server übertragen, dort alle bestehenden gelöscht und durch die
neuen ersetzt. Dadurch wäre es einfach möglich,\footnote{Der Client
  macht davon noch keinen Gebrauch, diese Funktionalität lässt sich aber jederzeit ohne
  Änderungen am Server implementieren.} die Markierungen clientseitig
als Mengen zu behandeln und beispielsweise Zeichen aus der Mitte einer
Markierung zu entfernen (was dazu führt, dass zwei getrennte, kürzere
Markierungen entstehen), ohne dass der Server das Resultat den
vorherigen Markierungen zuordnen können muss.

Das gesamte Datenmodell verwendet normalisierte Textpositionen. Beim
Erzeugen neuer Passagen ist daher der erste Schritt die Normalisierung.
Für alle weiteren Verarbeitungsschritte bleiben die Textpositionen
normalisiert; nur zur Darstellung im \acro{DOM} findet eine Realisierung statt.
Bei der Berechnung des Offsets müssen eventuell enthaltene Tags
übersprungen werden (vgl. \cref{sec:offset}, Methode 3). In der
aktuellen Implementierung geschieht das, indem vom \texttt{innerHTML}
des Bezugsknotens ausgegangen wird und alle enthaltenen Tags über einen
sehr einfachen regulären Ausdruck entfernt werden, bevor die Länge
abgefragt wird. Das führt potenziell zu Fehlern, wenn der reguläre
Ausdruck etwas anderes als Tags oder nicht die vollständigen Tags
erfasst, beispielsweise weil im Text eine öffnende spitze Klammer
verwendet wird (was in wohlgeformten Dokumenten nicht vorkommen darf)
oder weil in einem Attributwert eine schließende spitze Klammer
vorkommt. Letzteres ließe sich zwar auch durch eine Erweiterung des regulären
Ausdrucks lösen, eine robustere Alternative wäre aber, in Präorder durch
die \acro{DOM}-Knoten zu iterieren und bei der Längensummierung nur Textknoten
zu erfassen, wodurch die Verantwortung auf den Browser überginge. Dies
konnte aber aus zeitlichen Gründen nicht mehr umgesetzt werden.

\chapter{Evaluierung}\label{sec:evaluierung}

Zur Evaluierung des Prototypen wurden zwei unterschiedliche Verfahren
eingesetzt. Zum einen wurde systematisch überprüft, ob die Anforderungen
aus \cref{sec:anforderungen} erfüllt sind. Vorgehen und Ergebnisse
dieser theoretischen Evaluation werden in
\cref{sec:theoretische-evaluation} beschrieben. Außerdem wurde der
Prototyp durch einen Fachexperten des Projektteams auf
Praxistauglichkeit geprüft. Diesen Teil der Evaluation behandelt
\cref{sec:praktische-evaluation}.

Der Prototyp ist grundsätzlich browserunabhängig implementiert, setzt
aber moderne \acro{CSS}-Features voraus. Für beide Evaluierungen wurde Mozilla
Firefox\footnote{\url{https://www.mozilla.org/de/firefox/}} in Version
62.0 unter Ubuntu\footnote{\url{https://www.ubuntu.com/}} 16.04.5 \acro{LTS}
verwendet.\footnote{In einem kurzen Versuch mit Chromium 68.0.3440.106
  (\url{https://www.chromium.org/}; ebenfalls unter Ubuntu 16.04.5)
  zeigte sich, dass zwar das JavaScript funktionierte, aber Probleme mit
  einem neueren \acro{CSS}-Feature auftraten.}

\section{Theoretische Evaluation}\label{sec:theoretische-evaluation}

Das Ziel der theoretischen Evaluierung war, systematisch zu prüfen, ob
der Prototyp alle Anforderungen aus \cref{sec:anforderungen} erfüllt.

Die meisten Anforderungen können durch einfaches Ausprobieren oder
Nachsehen getestet werden. Die dafür verwendete Liste von Anforderungen
und zugehörigen Testkriterien ist in \cref{tbl:weich} dargestellt.
Deutlich aufwändiger zu prüfen ist nur die Unabhängigkeit einzelner
annotierter Textstellen von anderen Textstellen sowie von den übrigen
\TEI{}-Elementen. Hierfür müssen möglichst umfassend verschiedene
Konfigurationen von Markierungen getestet werden.

\begin{table}[htpb]
    \caption{\label{tbl:weich}Anforderungen, Tests und Ergebnisse}
    \begin{longtable*}[]{@{}p{0.8cm}@{}p{11cm}l@{}}
        \toprule
        \#  & Anforderung / Test & \quad\llap{\quad Ergebnis} \tabularnewline
        \midrule
            & \textbf{\TEI{}-Dokument}\smallskip & \tabularnewline
        1   & \TEI{}-Dokumente werden nicht verändert. & \checkmark \tabularnewline
        \midrule
            & \textbf{Datenmodell}\smallskip & \tabularnewline
        2   & Annotationen sind schriftliche Notizen zu Textstellen.\smallskip & \tabularnewline
        2.1 & Eine Textstelle kann markiert und mit einer schriftlichen Notiz versehen werden, die sich nach erneutem Laden der Edition wieder aufrufen lässt.\smallskip & \checkmark \tabularnewline
        3   & Textstellen können aus einer oder mehreren (nicht überlappenden) zusammenhängenden Zeichenfolgen bestehen. \smallskip & \tabularnewline
        3.1 & Eine Annotation zu einer einzelnen Zeichenfolge kann angelegt und wieder aufgerufen werden.\smallskip & \checkmark \tabularnewline
        3.2 & Weitere Zeichenfolgen können zu einer bestehenden Annotation hinzugefügt werden. Alle Zeichenfolgen werden als zugehörig gekennzeichnet.\smallskip & \checkmark \tabularnewline
        4   & Textstellen verschiedener Annotationen sind voneinander und von \TEI{}-Elementgrenzen unabhängig.\smallskip & \tabularnewline
        4.1 & Innerhalb eines kinderlosen \TEI{}-Elements können nacheinander zwei Textstellen \(a\) und \(b\) annotiert werden, wobei \ldots{} \emph{(siehe \cref{tbl:hart})}\smallskip & \checkmark \tabularnewline
        4.2 & Innerhalb einer \TEI{}-Struktur mit zwei aufeinander folgenden Elementen, die jeweils ein Kindelement haben, können nacheinander zwei Textstellen \(a\) und \(b\) so annotiert werden, dass jedes der Kindelemente mit mindestens einer Textstelle eine nicht-leere Schnittmenge hat und \ldots{} \emph{(siehe \cref{tbl:hart})}\smallskip & \checkmark \tabularnewline
        5   & Annotationen können ihren Autoren zugeordnet werden.\smallskip & \tabularnewline
        5.1 & Wenn eine Annotation eines anderen Autoren von einem Administrator geöffnet wird, wird der Autor angezeigt. & \checkmark \tabularnewline
        \midrule
            & \textbf{Nutzeroberfläche}\smallskip & \tabularnewline
        6   & Editionen werden dargestellt, ohne dass \acro{XML}-Code sichtbar ist, ggf. mit Faksimile.\smallskip & \tabularnewline
        6.1 & Wenn eine Edition geöffnet wird, wird sie gerendert, ohne dass \acro{XML}-Code zu sehen ist.\smallskip & \checkmark \tabularnewline
        6.2 & Wenn zu einer Edition ein Faksimile existiert, wird es neben der Edition dargestellt.\smallskip & \checkmark \tabularnewline
        7   & Annotationen werden dargestellt, wenn der Nutzer die entsprechenden Berechtigungen hat.\smallskip & \tabularnewline
        7.1 & Wenn zu einer Edition Annotationen mehrerer Autoren existieren und ein Administrator diese Edition öffnet, werden sämtliche Annotationen mit allen Markierungen dargetellt und können geöffnet werden, um den Annotationstext zu sehen.\smallskip & \checkmark \tabularnewline
        7.2 & Wenn zu einer Edition Annotationen mehrerer Autoren existieren und einer der Autoren, der kein Administrator ist, diese Edition öffnet, werden alle seine Annotationen mit allen Markierungen dargestellt und können geöffnet werden, es erscheinen aber keine fremden Annotationen. & \checkmark \tabularnewline
        \bottomrule
    \end{longtable*}
\end{table}

Das Problem dabei ist, dass die Kombinationsmöglichkeiten mit der Zahl
der \TEI{}-Elemente und markierten Textstellen exponentiell wachsen. Lässt
man den absoluten Abstand zwischen einzelnen Textpositionen außer Acht,
können Annotationspassagen als Intervalle verstanden werden und ihre
qualitativen Relationen zueinander mithilfe der Intervallalgebra nach
Allen (1983) beschrieben werden. Danach gibt es 13 mögliche Relationen
zwischen zwei Intervallen. Allein für zwei \TEI{}-Elemente und zwei
Annotationspassagen ergäbe das \(\mathcal O(13^6)\) denkbare
Konfigurationen. Davon würde zwar ein großer Teil wegfallen, weil
erstens nicht alle Relationen für \TEI{}-Elemente zulässig\footnote{\TEI{}-Elemente
  müssen sich der hierarchischen Struktur von \acro{XML} unterwerfen, damit
  sind keine Überlappungen möglich.} und zweitens viele Konfigurationen
widersprüchlich sind.\footnote{Beispielsweise kann für drei Intervalle
  \(a, b, c\) nicht gelten: \(a < b < c < a\).} Dennoch bleiben zu viele
Konfigurationen übrig, um sie alle von Hand zu testen.

Stattdessen wurden nur die 13 möglichen Relationen zweier
Annotationspassagen in jeweils zwei unterschiedlichen Umgebungen
getestet: innerhalb eines gemeinsamen \TEI{}-Elements sowie in einer
komplexeren Struktur aus zwei aufeinander folgenden \TEI{}-Elementen mit
jeweils einem Kindelement, das eine nicht-leere Schnittmenge mit
mindestens einer der beiden Annotationspassagen hat. Die resultierenden
26 Konfigurationen sind in \cref{tbl:hart} aufgelistet.

\begin{table}[tb]
    \caption{\label{tbl:hart}Unabhängigkeitstests}
    \begin{longtable*}{@{}lcc@{}}
        \toprule
        Konfigurationen für Test 4.1 und 4.2 aus \cref{tbl:weich} & 4.1 &
        4.2\tabularnewline
        \midrule
        \endhead
        \ldots{} sich \(b\) mit Abstand hinter \(a\) befindet. & \ok &
        \ok\tabularnewline
        \ldots{} sich \(b\) mit Abstand vor \(a\) befindet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) an derselben Position beginnt, an der \(a\) endet. & \ok
        & \ok\tabularnewline
        \ldots{} \(b\) an derselben Position endet, an der \(a\) beginnt. & \ok
        & \ok\tabularnewline
        \ldots{} \(b\) innerhalb von \(a\) beginnt und danach endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) vor \(a\) beginnt und innerhalb endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) an derselben Position beginnt wie \(a,\) aber vorher
        endet. & \ok & \ok\tabularnewline
        \ldots{} \(b\) an derselben Position beginnt wie \(a,\) aber später
        endet. & \ok & \ok\tabularnewline
        \ldots{} \(b\) innerhalb von \(a\) beginnt und endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) vor \(a\) beginnt und danach endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) innerhalb von \(a\) beginnt und mit \(a\) endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) vor \(a\) beginnt und mit \(a\) endet. & \ok &
        \ok\tabularnewline
        \ldots{} \(b\) mit \(a\) beginnt und endet. & \ok & \ok\tabularnewline
        \bottomrule
    \end{longtable*}
\end{table}

Zusätzlich wurden stichprobenartig einige deutlich komplexere
Konfigurationen getestet. Dieser Schritt war auch Teil der praktischen
Evaluation.

Das Ergebnis der theoretischen Evaluation ist durchweg positiv: Alle
Tests verliefen erfolgreich (vgl. \cref{tbl:weich,tbl:hart}). Mit einer
früheren Version des Realisierungsalgorithmus (bei der nach
Offset-Methode 2 nur \texttt{\textless{}mark\textgreater{}}-Tags vom
Offset abgezogen wurden, vgl. \cref{sec:offset}) traten bei der
strichprobenartigen Überprüfung komplexerer Szenarien Fehler auf, die
sich alle darauf zurückführen ließen, dass die Angaben, die der Browser
über die \acro{DOM}-\acro{API} anbot, nicht mit dem \TEI{}-Quelltext übereinstimmten. Mit
der in \cref{sec:normalisierung} vorgestellten Version (Offset-Methode
3) traten diese Fehler nicht mehr auf.

\section{Praktische Evaluation}\label{sec:praktische-evaluation}

Bei der praktischen Evaluation sollte ein Experteninterview zeigen, ob
ein Fachexperte realistische Annotationen umsetzen kann, und welche
Probleme und Wünsche sich dabei ergeben.

Hierzu habe ich mich mit Oliver Siegl, einem Mitglied des Projektteams,
getroffen und ihm zunächst den aktuellen Stand des Prototypen
vorgestellt.\footnote{Der Prototyp basierte zu diesem Zeitpunkt noch auf
  der vorher beschriebenen fehlerhaften Version des
  Normalisierungsalgorithmus (siehe Ende von
  \cref{sec:theoretische-evaluation}). Der Experte wurde vor dem Beginn
  der Evaluation darüber in Kenntnis gesetzt und hatte später noch
  einmal die Gelegenheit, die korrigierte Variante zu testen. Dabei
  traten keine Fehler mehr auf. Die Annotationen in
  \cref{fig:evaluation} sind mit der korrigierten Variante entstanden.}
Anschließend testete er frei praxisrelevante Szenarien
(\cref{fig:evaluation}), machte Anmerkungen zu Problemen und äußerte über den aktuellen Stand hinausgehende Wünsche.

\begin{figure}
\centering
\includegraphics{Bilder/screenshot_evaluation_anonymisiert.png}
\caption{Oliver Siegls Annotationen (blau) aus der praktischen
Evaluation (E-Mail-Adresse unkenntlich gemacht)}\label{fig:evaluation}
\end{figure}

Insgesamt zeigte sich der Experte sehr zufrieden damit, dass alle zu
Beginn besprochenen Anforderungen umgesetzt waren. Explizit erwähnte er
dabei die Möglichkeit, Annotationen zu überlappenden Textstellen sowie
zu mehreren Passagen erstellen zu können. Letzteres wird ihm zufolge
unter anderem für die gemeinsame Annotation ähnlicher Textstellen sowie
für die spaltenweise Annotation von Tabellen benötigt -- beides wurde
getestet. Positiv hervorgehoben wurde außerdem die Adressierbarkeit
einzelner Annotationen über eigene \acro{URI}s (vgl. \cref{sec:oberfluxe4che}).

Der Experte wies auf zwei Probleme der Benutzeroberfläche hin: Zum einen
störte, dass bei einer aktiven Annotation neu angelegte Passagen
automatisch der bestehenden Annotation zugeordnet werden. Da die
Mehrfachzuordnung in der Praxis eher selten gebraucht werde, sollte sie
nur stattfinden, wenn sie beispielsweise über einen Button oder eine
Tastenkombination explizit aufgerufen wird. Ansonsten sollten neue
Passagen jeweils einer neuen Annotation zugeordnet werden. Zum anderen
kam es vor, dass Passagen nicht mehr angeklickt und damit die
entsprechende Annotation nicht geöffnet werden konnte, wenn später erzeugte
% kam es vor, dass Passagen nicht mehr angeklickt und damit die
% entsprechende Annotation geöffnet werden konnte, wenn später erzeugte
Passagen sie vollständig beinhalteten. Als Lösung für dieses Problem
schlug der Experte vor, für jede Annotation zusätzlich zur Markierung
ein Symbol am Seitenrand anzuzeigen, über das sie ebenfalls aufgerufen
werden kann.

Der Experte regte darüber hinaus mehrere neue Features an, die in
Zukunft umgesetzt werden könnten. Die bereits bestehende Möglichkeit,
Annotationen zu referenzieren, legt nahe, das Datenmodell dahingehend zu
verändern, dass Annotationstexte davon Gebrauch machen und auf andere
Annotationen verlinken können. Auch ein thread-artiges Kommentieren von
Annotationen wäre wünschenswert. Alle Annotatoren -- auch externe --
sollten die Möglichkeit haben, die bestehenden fremden Annotationen zu
sehen,\footnote{Laut \cref{sec:anforderungen} gab es die Anforderung,
  dass nur die Projektmitglieder fremde Annotationen sehen dürfen, alle
  anderen nur ihre eigenen. Im Gespräch stellte sich jedoch heraus, dass
  diese Anforderung auf der nicht zutreffenden Annahme beruhte, dass
  sonst kein gleichzeitiges unabhängiges Arbeiten möglich wäre. Sie kann
  daher verworfen werden.} sie sollten das aber selbst umschalten
können, um weiterhin auch ablenkungsfrei arbeiten zu können. Sobald auch
fremde Annotationen angezeigt werden, sollte eine Legende deutlich
machen, welche Markierungsfarbe für welchen Verfasser steht. Für die
fernere Zukunft wird außerdem gewünscht, dass der Client nach einmaliger
Übertragung vom Server auch offline benutzbar ist und bei späterer
Verbindung zum Server alle Änderungen synchronisiert, auch wenn der
Browser zwischenzeitlich geschlossen war.

\chapter{Diskussion}\label{sec:diskussion}

Diese Arbeit beschäftigte sich mit dem Entwurf und der Umsetzung von
\mbox{\annoteitor{},} einem kollaborativen Annotationssystem für \TEI{}-Editionen.
In diesem Kapitel wird diskutiert, was der Kern des Problems war, welcher Anteil
zufriedenstellend gelöst ist, was noch zu tun wäre, um den Lösungsansatz
praxistauglich zu machen, und inwiefern er sich für das vorgestellte
Forschungsprojekt und ähnliche Szenarien eignet.

Das Problem war dreiteilig: Zu finden waren ein geeignetes Datenmodell
für die Annotationen, eine Benutzeroberfläche, die Annotationen
visualisiert und ohne \TEI{}-Quelltext auskommt, und Verfahren für die
Überführung von Annotationen aus dem Datenmodell in die Oberfläche und
umgekehrt. Am schwierigsten gestaltete sich die Überführung. Besonders
problematisch war dabei die Umsetzung mit JavaScript und \acro{DOM}-\acro{API}, da an
mehreren Stellen Zugriffsbeschränkungen die Implementierung erschwerten:
Die mitgelieferten \acro{XP}ath-Funktionen können nicht auf Iframes zugreifen,
von geklonten \acro{DOM}-Knoten aus gibt es keine Möglichkeit, zum
Originalknoten zu gelangen, und das \acro{DOM} unterscheidet sich an einigen
Stellen vom Quelltext, ermöglicht aber keinen Zugriff auf diesen.

Das auf Standoff-Annotationen basierende Datenmodell und die
Weboberfläche erfüllen die gegebenen Anforderungen. Sie lassen sich auch
mit geringem Aufwand an neue Wünsche wie die im Experteninterview
(\cref{sec:praktische-evaluation}) geäußerten anpassen. Die Überführung
ist durch die vorgeschlagenen Verfahren für Normalisierung
(\cref{sec:normalisierung}) und Realisierung (\cref{sec:realisierung})
gelöst. Insbesondere können sie mit mehrteiligen, verschachtelten und
überlappenden Textstellen umgehen.

Damit der \annoteitor{} produktiv eingesetzt werden kann, muss er auch in
anderen Browsern getestet und bei Bedarf angepasst werden. Bei
Netzwerkfehlern muss zumindest der Benutzer informiert werden, statt
dass Änderungen ohne jedes Feedback verloren gehen. Besser wäre, sie
zwischenzuspeichern und bei Gelegenheit erneut zu senden. Außerdem muss
die Benutzeroberfläche stärker an den Bedürfnissen der Endnutzer
ausgerichtet werden. Dafür müssen mindestens die im Experteninterview
(\cref{sec:praktische-evaluation}) beschriebenen Probleme behoben
werden, etwa die Steuerung der Zuordnung von neuen Annotationspassagen
und die Erreichbarkeit von Annotationen, deren Passagen vollständig von
anderen überdeckt werden. Auch Netzwerkprobleme müssen geeignet
behandelt werden.

Darüber hinaus können auch die weiteren Vorschläge aus dem
Experten\-interview umgesetzt werden: Eine Verlinkung von Annotationen aus
An\-no\-ta\-tions\-texten heraus setzt im einfachsten Fall eine entsprechende
Linksyntax und deren Ersetzung bei der Darstellung des Annotationstextes
voraus. Die Kommentierung von Annotationstexten erfordert dagegen eine
leichte Erweiterung des Datenmodells. Eine Annotatorenlegende lässt sich
ohne Weiteres in die Benutzeroberfläche integrieren. Die gewünschte
Offlinefähigkeit würde dagegen einen erheblichen Implementierungsaufwand
mit sich bringen, wäre aber ebenfalls umsetzbar.

Der Lösungsansatz und die Implementierung erfüllen nicht nur die
Anforderungen von \KoDiKE{}, sondern sind auch für andere vergleichbare
Anwendungsfälle geeignet. Sie sind auch nicht auf \TEI{} festgelegt,
sondern können mit beliebigen \acro{XML}- und \acro{HTML}-Dokumenten umgehen.

\chapter*{Literatur}\label{literatur}
\addcontentsline{toc}{chapter}{Literatur}

\hangparas{24pt}{1}
\sloppy

\hypertarget{refs}{}
\hypertarget{ref-AFF+06}{}
Agosti, Maristella, Nicola Ferro, Ingo Frommholz, Emanuele Panizzi,
Wolfgang Putz und Ulrich Thiel. 2006. „Integration of the \acro{D}i\acro{LAS}
annotation service into digital library infrastructures``. In
\emph{Workshop on Digital Libraries in the Context of Users' Broader
Activities}. Chapel Hill, \acro{USA}.
\href{http://www.dei.unipd.it/~agosti/papers/2006/DLCUBA2006.pdf}{http://www.""dei.unipd.it/\textasciitilde{}agosti/papers/2006/\acro{DLCUBA}2006.pdf}.

\hypertarget{ref-All83}{}
Allen, James F. 1983. „Maintaining Knowledge about Temporal Intervals``.
\emph{Communications of the \acro{ACM}} 26 (11): 832--43.
\href{http://cse.unl.edu/~choueiry/Documents/Allen-CACM1983.pdf}{http://""cse.""unl.""edu/""\textasciitilde{}choueiry/Documents/Allen-\acro{CACM}1983.pdf}.

\hypertarget{ref-AZP11}{}
Andrews, Pierre, Ilya Zaihrayeu und Juan Pane. 2011. „A Classification
of Semantic Annotation Systems``. \emph{Semantic Web Journal}, 1--27.
\href{http://www.semantic-web-journal.net/content/classification-semantic-annotation-systems}{http://www.semantic-web-journal.net/content/classification-se""man""tic-annotation-systems}.

\hypertarget{ref-Ban10}{}
Bański, Piotr. 2010. „Why \TEI{} stand-off annotation doesn't quite work:
and why you might want to use it nevertheless``. In \emph{Proceedings of
Balisage: The Markup Conference 2010}. Bd.\,5. Balisage Series on Markup
Technologies. Montréal, Canada: Mulberry Technologies, Inc.
doi:\href{https://doi.org/10.4242/balisagevol5.banski01}{10.4242/balisagevol5.banski01}.

\hypertarget{ref-BMMT13}{}
Barbera, Michele, Federico Meschini, Christian Morbidoni und Francesca
Tomasi. 2013. „Annotating Digital Libraries and Electronic Editions in a
Collaborative and Semantic Perspective``. In \emph{Digital Libraries and
Archives: 8th Italian Research Conference, \acro{IRCDL} 2012, Bari, Italy,
February 9-10, 2012, Revised Selected Papers}, herausgegeben von
Maristella Agosti, Floriana Esposito, Stefano Ferilli und Nicola Ferro,
45--56. Communications in Computer and Information Science. Berlin
Heidelberg: Springer.
doi:\href{https://doi.org/10.1007/978-3-642-35834-0_7}{10.1007/978-3-642-35834-0\_7}.

\hypertarget{ref-BNS13}{}
Buccio, Emanuele Di, Giorgio Maria Di Nunzio und Gianmaria Silvello.
2013. „A Curated and Evolving Linguistic Linked Dataset``.
\emph{Semantic Web Journal} 4 (3): 265--70.
doi:\href{https://doi.org/10.3233/SW-2012-0083}{10.3233/\acro{SW}-2012-0083}.

\hypertarget{ref-Bur13}{}
Burnard, Lou. 2013. „The Evolution of the Text Encoding Initiative: From
Research Project to Research Infrastructure``. \emph{Journal of the Text
Encoding Initiative}, Nr. 5 (Juni).
doi:\href{https://doi.org/10.4000/jtei.811}{10.4000/jtei.811}.

\hypertarget{ref-CMCF12}{}
Chiarcos, Christian, John McCrae, Philipp Cimiano und Christiane
Fellbaum. 2012. „Towards Open Data for Linguistics: Linguistic Linked
Data``. In \emph{New Trends of Research in Ontologies and Lexical
Resources}, 7--25. Springer Berlin Heidelberg.
doi:\href{https://doi.org/10.1007/978-3-642-31782-8_2}{10.1007/978-3-642-31782-8\_2}.

\hypertarget{ref-CR10}{}
Croenen, Godfried und Natasha Romanova. 2010. \emph{The Online
Froissart Project. Manual for transcription and markup}. Version 1.2.
\acro{AHRC} / University of Sheffield / University of Liverpool.
\url{http://pcwww.liv.ac.uk/~gcroenen/Guidelines.pdf}.

\hypertarget{ref-FL03}{}
Farrar, Scott und Terry Langendoen. 2003. „A linguistic ontology for
the semantic web``. \emph{\acro{GLOT} international} 7 (3): 91--100.
\href{http://emeld.net/documents/GLOT-LinguisticOntology.pdf}{http://""emeld.""net/""\mbox{documents}/\acro{GLOT}-LinguisticOntology.pdf}.

\hypertarget{ref-GMN+12}{}
Grassi, Marco, Christian Morbidoni, Michele Nucci, Simone Fonda und
Giovanni Ledda. 2012. „Pundit: Semantically Structured Annotations for
Web Contents and Digital Libraries``. In \emph{Proceedings of the 2nd
International Workshop on Semantic Digital Archives}, herausgegeben von
Annett Mitschick, Fernando Loizides, Livia Predoiu, Andreas Nürnberger,
und Seamus Ross, 912:49--60. \acro{CEUR} Workshop Proceedings. Paphos, Cyprus.
\url{http://ceur-ws.org/Vol-912/}.

\hypertarget{ref-HMGS10}{}
Haslhofer, Bernhard, Elaheh Momeni, Manuel Gay und Rainer Simon. 2010.
„Augmenting Europeana content with linked data resources``. In
\emph{Proceedings of the 6th International Conference on Semantic
Systems, \acro{I}-\acro{SEMANTICS} 2010}. Graz.
doi:\href{https://doi.org/10.1145/1839707.1839757}{10.1145/1839707.1839757}.

\hypertarget{ref-HSSvdS11}{}
Haslhofer, Bernhard, Rainer Simon, Robert Sanderson und Herbert van de
Sompel. 2011. „The Open Annotation Collaboration (\acro{OAC}) Model``. In
\emph{2011 Workshop on Multimedia on the Web}. \acro{IEEE}.
doi:\href{https://doi.org/10.1109/mmweb.2011.21}{10.1109/mmweb.2011.21}.

\hypertarget{ref-Hun09}{}
Hunter, Jane. 2009. „Collaborative semantic tagging and annotation
systems``. \emph{Annual Review of Information Science and Technology} 43
(1). Wiley-Blackwell: 1--84.
doi:\href{https://doi.org/10.1002/aris.2009.1440430111}{10.1002/aris.2009.1440430111}.

\hypertarget{ref-HG12}{}
Hunter, Jane und Anna Gerber. 2012. „Towards Annotopia---Enabling the
Semantic Interoperability of Web-Based Annotations``. \emph{Future
Internet} 4 (4). \acro{MDPI} \acro{AG}: 788--806.
doi:\href{https://doi.org/10.3390/fi4030788}{10.3390/fi4030788}.

\hypertarget{ref-IS95}{}
Ide, Nancy M. und C. M. Sperberg-McQueen. 1995. „The \TEI{}: History,
Goals, and Future``. In \emph{Text Encoding Initiative}, 5--15. Springer
Netherlands.
doi:\href{https://doi.org/10.1007/978-94-011-0325-1_2}{10.1007/978-94-011-0325-1\_2}.

\hypertarget{ref-JKR17}{}
Jannidis, Fotis, Hubertus Kohle und Malte Rehbein, Hrsg. 2017.
\emph{Digital Humanities}. Stuttgart: J.\,B. Metzler.
doi:\href{https://doi.org/10.1007/978-3-476-05446-3}{10.1007/978-3-476-05446-3}.

\hypertarget{ref-JLHT12}{}
Jordanous, Anna, K. Faith Lawrence, Mark Hedges und Charlotte Tupman.
2012. „Exploring manuscripts``. In \emph{Proceedings of the 2nd
International Conference on Web Intelligence, Mining and Semantics --
\acro{WIMS} 12}. \acro{ACM} Press.
doi:\href{https://doi.org/10.1145/2254129.2254184}{10.1145/2254129.2254184}.

\hypertarget{ref-KKPS02}{}
Kahan, J., M.-R. Koivunen, E. Prud'Hommeaux und R.R. Swick. 2002.
„Annotea: an open \acro{RDF} infrastructure for shared Web annotations``.
\emph{Computer Networks} 39 (5). Elsevier \acro{BV}: 589--608.
doi:\href{https://doi.org/10.1016/s1389-1286(02)00220-7}{10.1016/s1389-1286""(02)""00220-7}.

\hypertarget{ref-KHPG06}{}
Kalyanpur, Aditya, James Hendler, Bijan Parsia und Jennifer Golbeck.
2006. „\acro{SMORE} -- Semantic Markup, Ontology, and \acro{RDF} Editor``.
Technischer Bericht. Maryland University College Park Dept of Computer
Science. \href{http://www.dtic.mil/docs/citations/ADA447989}{http://www.dtic.mil/docs/citations/\acro{ADA}447989}.

\hypertarget{ref-Kur15}{}
Kurz, Susanne. 2015. \emph{Digital Humanities}. Wiesbaden: Springer
Fachmedien Wiesbaden.
doi:\href{https://doi.org/10.1007/978-3-658-05793-0}{10.1007/978-3-658-05793-0}.

\hypertarget{ref-LBB+16}{}
Lordick, Harald, Rainer Becker, Michael Bender, Luise Borek, Canan
Hastik, Thomas Kollatz, Beata Mache, Andrea Rapp, Ruth Reiche und
Niels-Oliver Walkowski. 2016. „Digitale Annotationen in der
geisteswissenschaftlichen Praxis``. \emph{Bibliothek Forschung und
Praxis} 40 (2). Walter de Gruyter GmbH: 186--99.
doi:\href{https://doi.org/10.1515/bfp-2016-0042}{10.1515/bfp-2016-0042}.

\hypertarget{ref-MGN+11}{}
Morbidoni, Christian, Marco Grassi, Michele Nucci, Simone Fonda und
Giovanni Ledda. 2011. „Introducing the Semlib project: semantic web
tools for digital libraries``. In \emph{Proceedings of the 1st
International Workshop on Semantic Digital Archives (\acro{SDA} 2011)},
herausgegeben von Livia Predoiu, Steffen Hennicke, Andreas Nürnberger,
Annett Mitschick und Seamus Ross, 801:97--108. Berlin: \acro{CEUR} Workshop
Proceedings.
\url{https://pdfs.semanticscholar.org/c313/476a041ee84eb81e5eaa1adcc46cdbd389e5.pdf}.

\hypertarget{ref-OD08}{}
O'Donnell, Michael. 2008. „The \acro{UAM} CorpusTool: Software for corpus
annotation and exploration``. In \emph{Proceedings of the \acro{XXVI} Congreso
de \acro{AESLA}}. Almeria, Spain.
\href{https://www.uam.es/proyectosinv/woslac/DOCUMENTS/Presentations\%20and\%20articles/ODonnellAESLA08.pdf}{https://www.uam.es/proyectosinv/woslac/\acro{DOCUMENTS}/""Presentations\%20and\%20articles/ODonnell\acro{AESLA}08.pdf}.

\hypertarget{ref-Pie14}{}
Pierazzo, Elena. 2014. „Digital Documentary Editions and the Others``.
\emph{Scholarly Editing: The Annual of the Association for Documentary
Editing} 35: 1--23.
\url{http://scholarlyediting.org/2014/essays/essay.pierazzo.html}.

\hypertarget{ref-Pie15}{}
---------. 2015. \emph{Digital Scholarly Editing}. Taylor \& Francis
Ltd.
\href{http://www.ebook.de/de/product/25652918/dr_elena_pierazzo_digital_scholarly_editing.html}{http://""www.""ebook.de/de/product/25652918/dr\_elena\_pierazzo\_digital\_scholarly\_""editing.html}.

\hypertarget{ref-Pie16}{}
---------. 2016. „Textual Scholarship and Text Encoding``. In \emph{A
new com\-pan\-ion to Digital Humanities}, herausgegeben von Susan
Schreibman, Ray Siemens und John Unsworth, 93:307--21. Blackwell
Companions to Literature and Culture. West Sussex: John Wiley \& Sons
Inc.
\url{http://www.ebook.de/de/product/24654348/susan_schreibman_ray_siemens_john_unsworth_a_new_companion_to_digital_humanities.html}.

\hypertarget{ref-Pri16}{}
Price, Kenneth M. 2016. „Social Scholarly Editing``. In \emph{A new
com\-pan\-ion to Digital Humanities}, herausgegeben von Susan Schreibman,
Ray Siemens und John Unsworth, 93:137--49. Blackwell Companions to
Literature and Culture. West Sussex: John Wiley \& Sons Inc.
\url{http://www.ebook.de/de/product/24654348/susan_schreibman_ray_siemens_john_unsworth_a_new_companion_to_digital_humanities.html}.

\hypertarget{ref-SCY17}{}
Sanderson, Robert, Paolo Ciccarese und Benjamin Young. 2017. \emph{Web
Annotation Data Model.\acro{W}3\acro{C} Recommendation 23 February 2017}.
Technischer Bericht. \acro{W}3\acro{C}; \acro{W}3\acro{C}.
\href{https://www.w3.org/TR/2017/REC-annotation-model-20170223/}{https://www.w3.org/\acro{TR}/2017/\acro{REC}-annotation-model-20170223/}.

\hypertarget{ref-SB17}{}
Sperberg-McQueen, C.M. und Lou Burnard. 2017. \emph{\TEI{} \acro{P}5: Guidelines
for Electronic Text Encoding and Interchange}. Version 3.2.0, Revision
0fcf651. \TEI{} Consortium.
\url{http://www.tei-c.org/release/doc/tei-p5-doc/en/Guidelines.pdf}.

\hypertarget{ref-UCI+06}{}
Uren, Victoria, Philipp Cimiano, José Iria, Siegfried Handschuh, Maria
Vargas-Vera, Enrico Motta und Fabio Ciravegna. 2006. „Semantic
annotation for knowledge management: Requirements and a survey of the
state of the art``. \emph{Web Semantics: Science, Services and Agents on
the World Wide Web} 4 (1): 14--28.
doi:\href{https://doi.org/https://doi.org/10.1016/j.websem.2005.10.002}{https://doi.org/10.1016/j.websem.2005.10.002}.

\clearpage
\thispagestyle{empty}
~ \vfill

\noindent Ich erkläre hiermit gemäß §\,17~Abs.\,2~\acro{APO}, dass ich die vorstehende Master"-arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

\vspace{2cm}
\noindent\textsc{datum\hspace{2cm}unterschrift}
\vspace{2cm}

\end{document}
