2159 lines
116 KiB
Plaintext
2159 lines
116 KiB
Plaintext
\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}
|