An dieser Stelle entsteht die öffentliche Dokumentation für Epigraf 5. Diese Seite ist noch in Bearbeitung.

Epigraf bildet Dokumente in relationalen Datenbanken ab. Dieses Relational Article Model (RAM) hat sich über mehrere Jahrzehnte aus der Arbeit mit äußerst heterogenen Datenbeständen entwickelt. Es erfüllt  eine Vielzahl an Anforderungen zur flexiblen und gleichzeitig standardisierbaren Erfassung von Forschungsgegenständen:

• Die Struktur aus Artikeln, Abschnitten und Inhalten kann Dokumente abbilden, ohne Annahmen über die Bedeutung der Bestandteile. Ein Abschnitt kann Bilder von Denkmälern, Brieftexte oder Social-Media-Posts  genauso erfassen wie Metadaten zu den betroffenen Zeitpunkten, Orten und Akteuren sowie Metadaten zum Bearbeitungszustand. Die Bedeutung ergibt sich aus der Konfiguration von Beschriftungen und Beziehungen zwischen den Bestandteilen.
• Inhalte werden mit Vokabularen verknüpft und annotiert, die in einer einzigen Tabelle abgelegt werden. Es können dazu sowohl offene als auch kontrollierte Vokabulare eingesetzt werden, die sich auf mehrere Segmente aufteilen und bei Bedarf hierarchisch oder mit Querverweisen organisiert sind. Die Kategorien werden dadurch über heterogene Bestände und lange Zeiträume hinweg konsistent gehalten. Gleichzeitig sind sie fortlaufend erweiterbar. Aus der tabellarischen Struktur ergeben sich einfach nutzbare Filter-, Extraktions und Kombinationsmöglichkeiten für Datenanalysen.
• Die Datenfelder erfassen einfache Datentypen wie Text, Zahlen, Verweise auf Datensätze (bis in die Ebene von annotierten Textstellen) oder Dateinamen. Das Relational Article Model nutzt diese einfachen Datentypen zur Abstraktion von komplexen Gegenständen. Für tiefere Strukturierungen werden Textfelder mit XML oder JSON verwendet, für zusammengesetzte Daten werden mehrere Datensätze kombiniert. Darüber lassen sich beliebige Datentypen mit einem einheitlichen Zugriffsschema organisieren.
• Jeder Datensatz ist über eine IRI nach einem festgelegten Schema identifizierbar. Dadurch können Daten zwischen verschiedenen Datenbanken abgeglichen werden. Zusätzlich können Artikel und Kategorien mit Normdaten versehen werden, um sie mit externen Vokabularen zu verknüpfen.

Relationale Datenbanken und tabellarische Strukturen gehören zu den am weitesten verbreiteten und robustesten Systemen für die Datenhaltung. Sie können einfach auf neue Systeme migriert werden, skalieren gut, weisen eine hohe Integrität auf und sind mit einer Vielzahl an Tools und Packages nutzbar. Aus relationalen Datenbanken können über etablierte Standardtechnologien wie sie in Epigraf implementiert sind Dokumentenformate oder auch Netzwerkdatensätze erzeugt werden. Umgedreht lässt sich eine Vielzahl an dokumentenorientierten Datenformaten verlustfrei im Relational Article Model abbilden.

Datenmodell

Das Relational Article Model (RAM) unterscheidet zwischen Datenmodell und Domänenmodell. Das Datenmodell stellt abstrakte Elemente zur Modellierung von Texten und Objekten bereit. Es zeichnet sich durch eine Anzahl inhaltsleerer Begriffe aus:

• Artikel (articles): Die erfassten Dokumente werden in Epigraf als Artikel bezeichnet. 
• Abschnitte (sections): Jeder Artikel setzt sich aus flexibel kombinierbaren Abschnitten zusammen, in denen der Text und alle relevanten Metadaten sowie zugehörige Dateien enthalten sind.
• Inhalte (items) umfassen Text, Abbildungen und Zuordnungen zu Kategorien.
• Annotationen (links) sind Auszeichnungen und Formatierungen innerhalb von Texten. Sie können mit standardisierten Vokabularen bzw. Kategorien verknüpft werden.
• Fußnoten (footnotes) umfassen Apparate innerhalb von Textfeldern. Ergänzend zu Annotationen sind hier Anmerkungen zu Textstellen erfasst. 
• Kategorien (properties) sind Vokabulare, die zur strukturierten Beschreibung von Inhalten und für die Annotation genutzt werden.
• Projekte (projects) gruppieren mehrere Dokumente.

Domänenmodell

Das Domänenmodell spezifiziert diese Elemente für einen festgelegten inhaltlichen Bereich, etwa um damit Inschriften zu erfassen. Das bedeutet beispielsweise im Fall von Abschnitten in einem Artikel (Datenmodell), dass diese typisiert werden, um konkrete Abschnitte wie Transkriptionen, Abbildungslisten oder Kommentare (Domänenmodell) zu erfassen. Das Domänenmodell wird für jede Datenbank einzeln konfiguriert. In der folgenden Tabelle sind Beispiele aus der Inschriftendomäne angegeben.

Die Abbildung des Datenmodells auf das Domänenmodell wird in der Epigraf-Konfiguration festgelegt.

International Resource Identifiers

Die meisten Datensätze können in Epigraf über IRIs identifiziert werden. Eine IRI ist eine international eindeutige Kennung, die auch stabil bleibt, wenn ein Datensatz in andere Datenbanken kopiert oder exportiert wird. In Epigraf enthalten vollständige IRIs folgenden Daten:

• Domain: Namensraum aller Datensätze, zum Beispiel http://epigraf.inschriften.net/iri/. 
• Tabelle: Der Name der Tabelle in der Datenbank, zum Beispiel items.
• Typ: Jede Tabelle ist in verschiedene Segmente unterteilt, zum Beispiel text oder image.
• Fragment: Das IRI-Fragment ist ein selbst vergebener Bezeichner, der den Datensatz in der Tabelle identifiziert, zum Beispiel di-103-17.

Daraus ergibt sich im Beispiel die IRI: http://epigraf.inschriften.net/iri/items/text/di-103-17 für die Bezeichnung des Textinhalts im Artikel 17 aus dem Band  "Die Deutschen Inschriften Nr. 103". Indem solche IRIs beim Einspielen von Daten in Epigraf verwendet werden, können Daten immer wieder aktualisiert werden.

Das IRI-Fragment ist mitunter komplexer strukturiert. Es kann prinzipiell beliebig gebildet werden, so lange es eindeutig bleibt. Empfehlenswert sind folgende, mit einer Tilde verbundenen Elemente:

• Datenquelle: Eindeutiger Bezeichner einer Datenbank, Datenquelle oder eines Korpus, zum Beispiel di für die Reihe "Die Deutschen Inschriften". Die Datenquelle wird in der Regel weggelassen, wenn der Datensatz in der betroffenen Datenbank geboren wurde. Sie wird notwendig, wenn Datensätze die Ursprungsdatenbank verlassen.
• Artikelsignatur: Eindeutiger Bezeichner eines Artikels, eine Nummer oder eine Bezeichnung in einem Korpus, zum Beispiel di-103-17 für Artikel 17 im Band 103 der Inschriftenreihe.
• Abschnitt: Eindeutiger Bezeichner eines Abschnitts innerhalb eines Artikels, zum Beispiel description. Eine Abschnittsbezeichnung ist immer dann nötig, wenn es mehrere Abschnitte gibt.
• Itemnummer: Mehrere Inhalte innerhalb eines Abschnitts können durchnummeriert werden, zum Beispiel mit 1, 2, 3 und so weiter. Das ist notwendig, wenn ein Artikel oder Abschnitt mehrere Inhalte beherbergt.

Zusammengesetz ergibt sich im Beispiel die IRI http://epigraf.inschriften.net/iri/items/text/di~di-103-1~description~1 zur Bezeichnung eines konkreten Inhalts. Beim Datenabgleich werden in der Regel keine vollständigen IRIs verwendet, es wird auf die Domain verzichtet. Die Kombination von Tabelle, Typ und Fragment wird in Epigraf als IRI-Pfad bezeichnet. Im Beispiel lautet der IRI-Pfad items/text/di~di-103-1~description~1.

Damit die IRI-Fragmente aus verschiedenen Datenbanken nicht in Konflikt geraten, kann der Datenbankname in das IRI-Fragment aufgenommen werden. Die Transferfunktion von Epigraf bildet IRI-Fragmente automatisch, wenn kein Wert angegeben wird. So erhält der Abschnitt mit der ID 18 in der Datenbank epi_nrw das IRI-Fragment "nrw~18". Nimmt man an, dass es sich um einen Abschnitt vom Typ "locations" handelt, lautet die vollständige IRI https://epigraf.inschriften.net/iri/sections/locations/nrw~18 und diese kann nicht mehr mit IRIs aus anderen Datenbanken verwechselt werden.

Beim Importieren aus anderen Quellen als Epigrafdatenbanken, sollte analog zum Datenbanknamen ein eindeutiger Quellenbezeichner sowie ein eindeutiger Dokumentbezeichner aufgenommen werden. Wird zum Beispiel ein Artikel mit der Signatur "ani576mc" aus einem Korpus mit der Bezeichnung "Anima" importiert, dann wäre ein passendes IRI-Fragment anima~ani576mc.

IRI-Schemata

Während Artikel einfach über eine Signatur oder Nummer identifiziert werden können, benötigen die darin enthaltenen Abschnitte und Inhalte etwas komplexere Identifikatoren. Denn es können mehrere gleichartige Abschnitte oder Inhalte in einem Artikel auftreten. Zur Differenzierung werden ausgehend vom IRI-Fragment des Artikels weitere Komponenten mit einer Tilde angehängt.

a) Schema für Artikel

articles/<type>/<datenquelle>~<artikelsignatur>

b) Schema für Abschnitte

sections/<type>/<datenquelle>~<artikelsignatur>~<abschnitt>

Enthält ein Artikel nur einen Abschnitt des Typs, zum Beispiel nur einen einzigen Abschnitt mit Bildern, dann reicht die Artikelsignatur aus. Durch den Typ ist eindeutig erkennbar, um welchen Abschnitt innerhalb des Artikels es sich handelt. 

Kommen in einem Artikel dagegen mehrere Abschnitte vom gleichen Typ vor, müssen diese über ein Postfix differenziert werden. Die Differenzierung ist notwendig, da alle Abschnitte eines Typs mit dem gleichen IRI-Pfad beginnen (z.B. sections/text/). Deshalb wird ein Abschnittsbezeichner mit einer Tilde angehängt . Enthält ein Artikel beispielsweise eine Beschreibung und einen Kommentar jeweils mit dem gleichen Abschnittstyp "text", dann kann wie folgt ein IRI-Fragment für zwei verschiedene Abschnitte innerhalb eines Artikels aus der Datenbank mit der Bezeichnung "anima" gebildet werden: anima~ani576mc~description und anima~ani576mc~comment. 

c) Schema für Inhalte

items/<type>/<datenquelle>~<artikelsignatur>~<abschnitt>~<itemnummer>

Wie bei Abschnitten, reicht die Artikelsignatur aus, wenn in einem Artikel nur ein einziger Eintrag des Typs auftritt, zum Beispiel nur ein einziges Bild. Andernfalls muss der Eintrag über das Postfix eindeutig innerhalb der Datenbank identifiziert werden. 

Ist sichergestellt, dass jeder Abschnitt nur jeweils einen Eintrag enthält, dann reicht auch der Abschnittsbezeichner zur Differenzierung aus, zum Beispiel anima~ani576mc~description und anima~ani576mc~comment. Kommen dagegen mehrere Einträge je Abschnitt vor, so wird getrennt mit einer Tilde durchnummeriert: anima~ani576mc~description~1  und anima~ani576mc~description~2 bezeichnen zwei aufeinander folgende Inhalte im gleichen Abschnitt. 

Zu beachten ist, dass die IRI-Pfade für Einträge unabhängig vom übergeordneten Abschnitt eindeutig sein müssen. Es ist also nicht erlaubt, zwei Abschnitte innerhalb eines Artikels anzulegen und dann innerhalb dieser Abschnitte die Einträge neu beginnend mit 1 durchzunummerieren. Für diesen Fall muss die Nummer über den gesamten Artikel fortlaufen.

d) Schema für Kategorien

Einige der zur Erfassung verwendeten Kategorien sind spezifisch auf die jeweiligen Projekte zugeschnitten, etwa die verwendete Literatur. Andere wiederholen sich zwischen den Projekten, beispielsweise die Worttrenner oder die Überlieferungszustände. Die gleichbleibenden Vokabulare können zwischen den Datenbanken abgeglichen werden. Dazu wird den betroffenen Eigenschaften ein weltweit eindeutiger Bezeichner vergeben. Die Umsetzung ist denkbar einfach: im Feld für das IRI-Fragment wird jeweils ein kurzer standardisierter Bezeichner eingetragen, aus dem dann ein IRI-Pfad gebildet werden kann:

properties/<type>/<datenquelle>~<lemma>

Der IRI wird dazu verwendet, alle Eigenschaften weltweit eindeutig zu identifizieren. Unter Eigenschaften werden in Epigraf entsprechend dem Menüpunkt alle Kategorien verstanden, die in einem Artikel verwendet werden können. Damit sind folgende Dinge möglich: 

• Eigenschaften wie Schriftarten, Worttrenner oder Objekttypen sind eindeutig identifizierbar, auch wenn sich die Beschriftungen ändern. 
• Eigenschaften können zwischen den Datenbanken der Arbeitsstellen abgeglichen werden.
• Eigenschaften können aus externen Datenquellen (CSV, XML) importiert werden. Dabei werden Eigenschaften, die in der Datenbank bereits mit der gleichen IRI existieren, überschrieben und nicht neu angelegt. 
• Einige Eigenschaften, wie zum Beispiel Zustände oder Maßeinheiten, steuern beim Exportieren die Darstellung. Dazu kann in den Stylesheets (=die Skripte, mit denen die Worddateien erzeugt werden) auf die IRIs zugegriffen werden.

Auflösung von IRIs

IRIs sind insbesondere für den Datenabgleich nützlich:

• Kategorien wie Schriftarten, Worttrenner oder Objekttypen sind eindeutig identifizierbar, auch wenn sich die Beschriftungen ändern. 
• Datensätze können beim Importieren aktualisiert werden. Existiert bereits ein Datensatz mit der gleichen IRI, wird er überschrieben und nicht neu angelegt. 
• Datenbestände können zwischen verschiedenen Datenbanken synchronisiert werden.

IRIs sind aufgebaut wie die URLs einer Webseite Ein Beispiel für eine einfache IRI ist https://epigraf.inschriften.net/iri/articles/object/1. Die IRI leitet auf einen Artikel weiter, der ein epigrafisch relevantes Objekt beschreibt. Diese IRI setzt sich aus folgenden Teilen zusammen:

• Der IRI-Endpunkt "https://epigraf.inschriften.net/iri/" sorgt dafür, dass die IRI aufgelöst werden kann. Damit IRIs nicht umständlich lang werden, kann ein Namensraum festgelegt werden, der zum Beispiel in XML-Dokumenten an die Stelle des Endpunkts tritt. Innerhalb von Epigraf steht der Namensraum "epi:" für "https://epigraf.inschriften.net/iri/". Aus der oben angegebenen IRI wird damit die kürzere Form "epi:articles/object/1".
• Der IRI-Pfad "articles/epi-article/1" wird wie oben beschrieben nach dem Schema <table>/<type>/<irifragment> gebildet. Der erste Teil entspricht der Datenbanktabelle (z.B. articles, sections, properties), es folgen der Typ des Datensatzes (z.B. für die properties-Tabelle fonttypes oder locations) und schließlich das IRI-Fragment. 

Voraussetzung für eine IRI ist somit die Angabe des IRI-Fragments, das bei jedem Datensatz im Feld norm_iri erfasst wird. Alle anderen Angaben - Endpunkt, Tabelle, Typ - ergeben sich automatisch. In diesem Feld gelten folgenden Konventionen:

• Es darf ein beliebiger alphanumerischer Wert eingetragen werden, bestehend aus den Zeichen a-z, 0-9, - und _. Erlaubt ist nur Kleinschreibung. Weitere Leerzeichen, Sonderzeichen und Umlaute sind nicht erlaubt. Eine Ausnahme ist die Tilde zur Kennzeichnung von Datenquellen und Datensatzteilen, siehe unten)
• Beispiele für solche Werte wären Zahlen wie "1" oder Wörter in Kleinschreibung wie "kreuz". Es sollten bevorzugt englische Bezeichnungen wie "cross" oder an standardisierte Vokabulare angelehnte Bezeichner wie "deu" (ISO-639-3-Code für die deutsche Sprache) verwendet werden.
• Wichtig ist, dass einmal festgelegte Werte möglichst nicht mehr geändert werden.
• Der Wert muss im Epigraf-Universum eindeutig sein.
• Der Name der Datenbank kann gefolgt von einer Tilde in das IRI-Fragment aufgenommen werden, um Konflikte zwischen verschiedenen Datenbanken zu vermeiden. .

Jede IRI muss im Epigrafuniversum eindeutig sein, das heißt auch datenbankübergreifend eindeutig, damit Datenbestände abgeglichen werden können. Der IRI-Endpunkt selbst löst lediglich zur Referenzdatenbank epi_public auf. Sollen Datensätze über eine IRI erreichbar sein, dann muss der Datensatz in diese Referenzdatenbank übertragen werden. 

Externe IRIs

Neben den IRIs des Relational Article Model können in Epigraf IRIs aus externen Vokabularen verwendet werden. Ein Beispiel dafür ist der IRI "https://sws.geonames.org/2917788/", mit dem die Stadt Greifswald identifiziert wird. Diese IRIs werden im Feld Normdaten von Artikeln und Kategorien erfasst. Kategorien können also über die Eingabe von Normdaten standardisiert werden. Beispiele für solche Normdaten sind Geonames für Standorte oder GND-Nummern für Personen.

Mehrere IRIs werden getrennt durch Zeilenumbruch, eingegeben werden. Hier muss entweder der volle IRI oder ein IRI mit einem in Epigraf etablierten Namensraum wie "geonames:2917788" eingetragen werden. Damit IRIs nicht umständlich lang werden, werden sie abgekürzt. Dazu werden in der Konfiguration der jeweiligen Datenbank Namensräume festgelegt, die statt des ersten Teils eines IRIs verwendet werden. Innerhalb von Epigraf steht der Namensraum "epi:" für "https://epigraf.inschriften.net/epi/public/id/". Aus einer IRI in der Referenzdatenbank wird damit "epi:properties/wordseparators/1" (ein sogenannter QName).

Datenfelder

Die Datensätze werden innerhalb der Anwendung als miteinander verknüpfte Objekte repräsentiert. Jedes Objekt verfügt über:

• Echte Datenfelder: Inhalte aus der Datenbank. Die Felder sind in der Entwicklungsdokumentation aufgeführt und erfassen unter anderem Namen, annotierte Texte, Datierungen, Positionen oder Verweise auf Kategorien. Zum Beispiel enthält ein Artikelobjekt das Datenfeld signature.
• Virtuelle Datenfelder: Einige Objekte verfügen über Eigenschaften, in denen Inhalte aus der Datenbank aufbereitet werden. Zum Beispiel enthält ein Artikelobjekt das virtuelle Datenfeld iri_path, obwohl es dieses Feld in der Datenbank nicht gibt. Der Wert setzt sich in diesem Fall aus Tabellenname, Artikeltyp und IRI-Fragment zusammen.
• Untergeordnete Relationen: Beziehungen zu anderen Objekten. Es können zwei Arten von Beziehungen auftreten. Eine belongsTo-Beziehung verweist auf ein einzelnes anderes Objekt. Zum Beispiel enthält ein Artikelobjekt die Beziehung project, darin ist das Projektobjekt enthalten. Dagegen enthalten hasMany-Beziehungen eine Liste mit Objekten. Zum Beispiel enthält eine Artikelobjekt die Liste der Abschnitte in der Beziehung sections.
• Übergeordnete Relationen: Artikel enthalten Abschnitte, welche wiederum Inhalte enthalten, die auf Kategorien verweisen können. Der Artikel ist für alle diese Objekte das root-Objekt und kann über die root-Eigenschaft erreicht werden. Das jeweils übergeordnete Objekt kann über die container-Eigenschaft erreicht werden. In hierarchischen Tabellen wie den Abschnitten, ist ein übergeordneter Abschnitt über die parent-Eigenschaft erreichbar.

Für die Konfiguration der Oberfläche, die Auswahl von Spalten in Tabellen und beim Exportieren werden Daten aus diesen Objekten extrahiert. Dazu werden drei verschiedene Arten von Extraktionsschlüssels verwendet:

• Pfadschlüssel tauchen in ein Objekt ein, indem die Felder mit Punkt getrennt aneinander gekettet werden.
  • Ein einfacher Pfadschlüssel enthält den Namen des Datenfeldes oder der Relation. Beispiel: signature.
  • Ein zusammengesetzter Pfadschlüssel kann in Objekte eintauchen, indem der Pfad mit einem Punkt getrennt angegeben wird. Beispiel ausgehend von einem Artikelobjekt: project.signature.
  • Ein zusammengesetzer Pfadschlüssel kann auch übergeordnete Objekte erreichen, etwa ausgehend von einem Inhalt die Artikel-IRI: root.iri.
  • Der Pfad kann ein Asterisk * als Platzhalter enthalten, um mehrere Objekte zu adressieren. So können Werte aus hasMany-Relationen extrahiert werden. Beispiel: items.*.content.
  • Zusätzlich kann bei der Verwendung von Platzhaltern gefiltert werden. Dazu wird in eckigen Klammern eine Bedingung angegeben. Beispiel: items.*[itemtype=images].file_name.
• Aggregationsschlüssel: Sollen die Werte weiterverarbeitet werden, können an einen Pfadschlüssel mehrere  Verarbeitungschritte mit einer Pipe | angehängt werden. Die Parameter der Funktion werden nach einem Doppelpunkt angegeben, mehrere Parameter mit Komma getrennt. Beispiel: items.*[itemtype=images].file_name|collapse:;  
  
  Aktuell stehen folgende Pfadfunktionen zur Verfügung:
  • collapse: Verbindet mehrere Werte zu einer Zeichenkette
  • first: Gibt das erste Element einer Liste zurück
  • min: Gibt das kleinste Element einer Liste zurück
  • max: Gibt das größte Element einer Liste zurück
  • count: Gibt die Anzahl der Elemente in einer Liste zurück
• Platzhalterschlüssel sind Zeichenketten, die Aggregationsschlüssel in geschweiften Klammern enthalten. So können komplexe Werte zusammengesetzt werden. Beispiel: Quelle {project.description.source} - {article.created|date:deut}. Mehrere Aggregationsschlüssel können mit Komma getrennt in eckige Klammern gesetzt werden. In diesem Fall wird der erste Wert zurückgegeben, der nicht leer ist. Beispiel: {[project.name,project.signature]}.
• Benannte Schlüssel beginnen mit einer Bezeichnung gefolgt von einem Gleichheitszeichen. Auf diese Weise können etwa Spalten in einer Tabelle benannt werden: Signatur=article.signature