Kategorien

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

IRIs für Artikelinhalte

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.

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.

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_data 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 Name der Datenbank kann gefolgt von einer Tilde in das IRI-Fragment aufgenommen werden, um Konflikte zwischen verschiedenen Datenbanken zu vermeiden. Die Tilde wird auch verwendet, um weitere identifizierende Bestandteile zu erschaffen (siehe oben).

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. 

Kennzeichnung von Datenquellen

Damit die IRI-Fragmente aus verschiedenen Datenbanken nicht in Konflikt geraten, sollte 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.

Kategorien und standardisierte Vokabulare

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 IRI-Feld wird jeweils ein kurzer standardisierter Bezeichner eingetragen, aus dem dann ein IRI-Pfad gebildet werden kann:

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

 

Das IRI-Feld 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 standardisiert werden, das heißt sie können mit Normdaten verbunden werden. Beispiele für solche Normdaten sind Geonames für Standorte oder GND-Nummern für Personen.
  • Eigenschaften können zwischen den Datenbanken der Arbeitsstellen abgeglichen werden.
  • Eigenschaften können aus Exceltabellen (genauer CSV-Dateien) 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.

Externe und interne IRIs

Prinzipiell können IRIs in Epigraf auf zwei verschiedene Weisen verwendet werden: 

  1. Es können 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 erfasst.
  2. Die Referenzdatenbank "public" stellt innerhalb des Epigrafuniversums eine zentrale Sammelstelle für Daten dar. Diese Datenbank dient zum einen der Publikation von Daten nach außen und zum anderen zum Abgleich mit den Datenbanken der Arbeitsstellen. Ein Beispiel für eine IRI der Referenzdatenbank ist "https://epigraf.inschriften.net/epi/public/id/properties/wordseparators/135" (Hinweis: der Link funktioniert noch nicht). Die Nummern entstehen aus datenbankinternen IDs, können aber auch manuell festgelegt werden.

Sollen externe Vokabulare verwendet werden, dann werden deren IRIs im Feld Normdaten erfasst. Es können mehrere IRIs, 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. Ein Namensraum wird in Epigraf dadurch etabliert, dass er in der Strukturtabelle der jeweiligen Datenbank eingetragen wird (dazu an anderer Stelle mehr, aktuell ist diese Möglichkeit noch nicht implementiert).

Namensräume und QNames

Damit IRIs nicht umständlich lang werden, werden sie abgekürzt. Dazu wird ein Namensraum festgelegt, der statt des ersten Teils eines IRIs verwendet wird. Innerhalb von Epigraf steht der Namensraum "epi:" für "https://epigraf.inschriften.net/epi/public/id/". Aus der oben angegebenen IRI in der Referenzdatenbank wird damit "epi:properties/wordseparators/1" (ein sogenannter QName).

Die IRIs der Referenzdatenbank können innerhalb von Epigraf noch weiter eingekürzt werden, denn für jede Art von Eigenschaften - zum Beispiel Worttrenner - ist der erste Teil der IRI implizit durch die Datenbank festgelegt. Im Feld IRI der Worttrenner reicht damit die Angabe "1" aus. Diese wird innerhalb von Epigraf automatisch zu einer vollständigen IRI aufgelöst. Innerhalb der Tabellen für Worttrenner bezeichnet die "1" also die Kurzform "epi:properties/wordseparators/1" bzw. die Langform "https://epigraf.inschriften.net/epi/public/id/properties/wordseparators/1". 

Das IRI-Feld kann wie folgt befüllt werden: 

  • Es darf ein beliebiger alphanumerischer Wert eingetragen werden, bestehend aus den Zeichen a-z und 0-9. Erlaubt ist nur Kleinschreibung. Leerzeichen, Sonderzeichen und Umlaute sind nicht erlaubt.
  • Beispiele für solche Werte wären Zahlen wie "1" oder Wörter in Kleinschreibung wie "kreuz". Es sollten bevorzugt englische Bezeichnungen wie "cross" verwendet werden.
  • Der Wert muss im Epigrafuniversum, das heißt in der Referenzdatenbank, eindeutig sein.
  • Wichtig ist, dass einmal festgelegte Werte möglichst nicht mehr geändert werden. 
  • Auch in den Datenbanken der Arbeitsstellen werden nur IRIs eingegeben, die epigrafweit eindeutig sind und in die Referenzdatenbank übertragen werden können.

Abgleich zwischen Datenbanken

 Anschließend ist ein Abgleich wie folgt möglich:

  1. In der Referenzdatenbank epi_public werden die Eigenschaften angelegt und mit IRIs versehen. Alternativ können Eigenschaften aus einer Projektdatenbank über die Schaltfläche "Transfer" in die Referenzdatenbank übernommen oder über die Schaltfläche "Import" aus einer CSV-Datei importiert werden. Das IRI-Feld sollte in diesem Fall vor dem Import gefüllt werden (es ersetzt den bisherigen Abgleich über die Felder import_db und import_id).
  2. Aus der Referenzdatenbank werden die Eigenschaften mit der Schaltfläche "Transfer" in andere Projektdatenbanken übertragen. 

Die Referenzdatenbank agiert als IRI-Provider. Das bedeutet:

  • Beim Transfer zwischen Referenz- und einer Projektdatenbank werden fehlende IRIs automatisch in beiden Datenbanken angelegt. Empfehlenswert ist aber das manuelle Anlegen in der Quelldatenbank, damit statt Zahlen aussagekräftige, möglichst englische oder lateinische Bezeichner verwendet werden.
  • Beim Transfer zwischen den Datenbanken werden Einträge mit bereits vorhandenen IRIs nicht neu angelegt, sondern überschrieben. So können Lemma, Name und weitere Felder aktualisiert werden.

Ontologien, Thesauri und das Resource Description Framework

In den Eigenschaftslisten gibt es zwei Arten von Einträgen, um beliebige Netzwerkstrukturen (bzw. Knowledge Graphs) abzubilden:

  • Knoten enthalten im Feld Lemma die Bezeichnungen der Eigenschaften und werden über IRIs eindeutig identifiziert. Diese Knoten sind hierarchisch angeordnet, ohne dass (bislang) die Bedeutung der Hierarchie festgelegt ist. Perspektivisch wird innerhalb jedes Eigenschaftstyps in den Strukturdefinitionen der Datenbank festgelegt, welche Bedeutung die Eltern-Kind-Beziehung auf welcher Ebene haben soll (z.B. skos:member, skos:narrower) oder ob die Bedeutung offen bleibt.
  • Kanten sind alle Einträge mit einem Eintrag im Related-Feld. Dadurch wird eine Beziehung zwischen dem  jeweiligen Elternelement und dem Related-Element hergestellt. Im Lemma-Feld sollte diese Beziehung bezeichnet werden, zum Beispiel als "siehe auch". Das IRI-Feld wird perspektivisch dazu eingesetzt, verschiedene Beziehungen mit standardisierten Bezeichnern (z.B. "skos:member, skos:broader, skos:narrower, skos:related) zu differenzieren.

Damit lassen sich Daten in Epigraf im Sinne des Resource Description Framework modellieren. Achtung: Die Terminologie kann leicht verwirren, Eigenschaften in Epigraf sind ein Überbegriff für die Knoten und Kanten, während in RDF nur die Kanten als Eigenschaften bzw. Prädikate bezeichnet werden. Ein verbreitetes Schema zur Standardisierung der Beziehungen ist  das Simple Knowledge Organisation System (SKOS).