Auszeichnungssprachen

Christof Schöch
(Trier University, Germany)

Modul Grundlagen der Digital Humanities
Master Digital Humanties
Trier University

22 Oct 2024

Sitzung 1 (22.10):
Organisatorisches und Überblick

Sitzungsablauf

• Organisatorisches
• Vorstellungsrunde: Name, Bachelor, Erwartungen
• Seminarplan: Überblick über die Themen
• Empfehlung: Digital Humanities: Eine Einführung
  (Jannidis, Kohle, and Rehbein 2017).

Datenformate im Überblick

Sitzung 2 (29.10.):
Auszeichnungssprachen und Datenformate

(1) Ihre Kontakte mit HTML

• Genau, alle Webseiten nutzen HTML!
• Ansonsten
  • Im Kurs “Programmieren 1: Textprozessieren”
  • In der Schule im Fach Informatik
  • Im Bachelor Computerlinguistik
  • Kurs zum Digital Media Management und SEO
  • Um Daten zu sichern, als Server offline ging
• Achtung!
  • Word/PowerPoint nutzt nicht HTML, sondern DOCX/PPTX
  • Webseiten mit HTML erstellen haben nur wenige gemacht

(2) Ihre Fragen zu Datenformaten

• Wie kann man mit HTML eine Seite erstellen? => Übung
• Wie funktioniert CSS und wie bettet man es in HTML ein? => separate Session
• Wie funktioniert SVG? Animationen in SVG, PNG vs. SVG => separate Sitzung
• Wie kann man Bilder, Stempel, Embleme taggen? => mit TEI (separate Sitzung)
• CSV/TSV: Wofür wird das in den DH genutzt? Was sind die Unterschiede?
  
• Welche Zeichenkodierungen gibt es neben UTF-8 (siehe unten)
• Wofür kann man Mediawiki Syntax nutzen außer in Wikipedia? (siehe unten)
• Unterschied zwischen Markup und anderen Formaten (siehe unten)

CSV/TSV: Unterschiede / Nutzung in den DH

• CSV/TSV
  • Kein Unterschied zwischen CSV/TSV (außer dem Trennzeichen)
  • Auch beliebige andere Trennzeichen sind denkbar
  • Zellen, die das Trennzeichen enthalten, müssen “ge-quoted” werden
• Nutzung in den DH
  • Das wichtigste tabellarische Datenformat; sehr verbreitet
  • Immer, wenn man für viele Items viele Einzelinformationen festhalten möchte
  • Und wenn keine hierarchische Struktur notwendig ist
  • Und wenn die Informationen nicht kommentiert / qualifiziert werden müssen
  • Bspw.: DOAJ-Dump; Dokument-Term-Matrix; Metadaten-Tabelle; uvm.

Markup vs. andere Formate

• Unterschied 1: Wie werden die “Daten selbst” von den Meta-Informationen getrennt?
  • Markup (HTML, XML): Markup wird durch spezielle Zeichen abgetrennt (<...>)
  • CSV/TSV: Spaltentitel vs. Zelleninhalte
  • JSON: besondere Struktur von "Label" : "Werte"
  • Markdown: Meta-Informationen haben spezielle Syntax: # oder ![]()
• Unterschied 2: Wie ist das Format organisiert?
  • Markup (HTML, XML) und JSON: hierarchisch
  • CSV/TSV: Tabellarisch / als Matrix
  • Markdown (und Mediawiki): String mit speziellen Markierungen

Wofür kann man Mediawiki Syntax nutzen außer in Wikipedia?

• In allen Sprachfassungen der Wikipedia wird Mediawiki verwendet
• Auch auf Wikidata/Wikibase, Wikisource und anderen Projekten der Wikimedia Foundation
• Es gibt auch sehr viele unabhängige Seiten, die Mediawiki verwenden, bspw. https://wikitravel.org/
• Es gibt aber auch viele alternative Wiki-Syntaxen: Dokuwiki, Confluence, Zim-Wiki, Markdown

Welche Zeichenkodierungen gibt es neben UTF-8

• Zeichenkodierung
  • Mapping zwischen einem Buchstaben (Anzeige) und einem “code point” (einer numerischen Angabe);
  • dieses Mapping ist die Zeichenkodierung (auch “Zeichensatz” oder “charset”)
• Es gibt eine große Zahl von Zeichenkodierungen
  • ASCII: 1963, 7 bit, 128 Zeichen, davon 95 anzeigbar (Rest freie Codes)
  • ISO-8859-1: 1998, auch “Latin-1”, 8 bit, 191 Zeichen (Rest freie Codes)
  • ISO 8859-15: “Latin-9”
  • UTF-8: 1992, 8 bit (aber 1-4 Bytes); Kodierung für UNICODE-Zeichen; sehr weit verbreitet; für alle UNICODE-Zeichen geeignet
• UNICODE (UNIversell, aber zwei Schritte)
  • Keine Zeichenkodierung, sondern eine Definition von 154,998 Zeichen
  • Jedes Zeichen hat einen numerischen Identifier, hexadezimal: U+00DF
  • Diese Zahl wird dann wiederum bspw. in UTF-8 kodiert

Sitzung 3 (5.11):
HTML und CSS

CSS: Pro Auszeichnungssprache

• Es geht um die Formatierung, Layout, Darstellung von Text (Farbe, Fonts)
• Deklarativ (X ist Y: “h1” = “grün”), wie Elemente in HTML/XML
  
• Es werden Attribut-Wert-Paare definiert und bei Passung angewandt
• CSS funktioniert so ähnlich wie eine Formatvorlage in Word
• CSS ist auf eine recht spezifische Aufgabe spezialisiert
• Cascading / Vererbung: Wichtiger Mechanismus mit eigener Logik, aber statisch

CSS: Contra Programmiersprache

• Keine Kontrollstrukturen für Abläufe: Bedingungen, Schleifen
• Keine Operationen: Berechnungen, logischen Operatoren
• Keine Variablen (im Normalfall)
• Keine Funktionen (außer calc() für einfache Berechnungen)
• Keine komplexeren Datenstrukturen
• Nicht imperativ (über Anweisungen organisiert)
• Man kann mit CSS keinen Algorithmus oder Software implementieren
• Keine direkte Interaktion mit Benutzenden-Eingaben

Folgefrage zu CSS

• Frage: Wenn CSS eher wie eine Auszeichnungssprache funktioniert, inwiefern ist es dann aber dennoch anders als HTML oder XML-TEI?
• …
• XML-TEI: Elemente beschreiben nur, was etwas ist
• CSS: Definiert nur, wie etwas dargestellt wird; eine Art zweite, auf einer abstrakteren Ebene liegende, darstellungsbezogene Schicht der Auszeichnung
• HTML: Mischform, weil es Default-Werte für die Darstellung gibt

HTML + CSS im Kontext von CMS

• CMS = Content Management System, bspw. Wordpress, Drupal, Typo3
• CMS funktionieren mit Templates: komplexe CSS-Konstrukte für die Darstellung der Seiten
• Mit CSS kann man in die Templates eingreifen und Modifikationen vornehmen

Frage: Nochmal mehr zum Boxmodell?

• Zunächst mal: inline-Elemente (bspw. hi) vs. Block-Elemente
• Block-Elemente sind für Seitenstruktur (bspw. header) und Textstruktur (bspw. h1) gedacht
• Block-Elemente sind als Box gedacht mit:
  • Position
  • height und width
  • padding (innen), border (Linie mit border-width) und margin (außen)

Boxmodell (Bühler, S. 66)

Flexbox

• Weil fixe Boxen nachteilig sind, gibt es als Alternative auch Lösungen wie die Flexbox
• Mehrere Inhaltsblöcke innerhalb einer Box können verteilt werden
• flex container (außen) und flex items (innerhalb)
• Position Reihenfolge der items können abstrakt vorgegeben werden
• Reagieren “responsiv” auf Bildschirmgröße und -format: konkrete Größe und Position passen sich an
• Mehr: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Unterschiede HTML / HTML5

• HTML5 ist eine Weiterentwicklung des ursprünglichen HTML
• Neue Funktionen und Verbesserungen
  • Neue semantische Elemente: <header>, <footer>, <article>, <section>, <aside> und <nav>: bessere Strukturierung
  • Audio und Video direkt einbetten mit <audio> und <video> Elementen
  • <canvas>-Element und bessere Unterstützung für SVG: Grafiken und Animationen ohne Plugins
  • Neue Formularfunktionen: HTML5 bietet neue Eingabetypen wie date, time, email, url und number
  • Technische Verbesserungen für schnellere Client/Server-Kommunuikation, Offline-Funktionalitäten, uvm.

Pseudoklassen und Pseude-Elemente in CSS

• Pseudoklassen und Pseudoelemente: besondere Selektoren, die auf bestimmte Zustände oder Teile eines Elements zugreifen, ohne dass zusätzliche HTML-Klassen oder -Elemente nötig sind.
• Pseudoklassen
  • beschreiben einen besonderen Zustand eines Elements, wie z. B. das erste Kind eines Elements (strukturell) oder ein Element, wenn es von der Maus berührt wird (Benutzeraktion).
  • Beispiele strukturell: :first-child, :last-child, :nth-child
  • Beispiele interaktiv: :focus, :active, :visited
    
• Pseudoelemente
  • Erstellen virtuelle Unterelemente, mit denen spezifische Teile eines Elements angesprochen werden können
  • Beispiele: ::first-line, ::first-letter

Beispiele

• Hier wird die erste Zeile jedes Absatzes (

  ) fett dargestellt:

p::first-line {
    font-weight: bold;
}

• Hier wird vor jedem Absatz der Text „Hinweis: “ eingefügt:

p::before {
    content: "Hinweis: ";
    font-weight: bold;
}

Sitzung 4 (12. Nov.)
Textkodierung

Insights (speziell TEI)

• Sehr praktische / pragmatische Motivation für TEI: Auszeichnung von Dokumenten, vor allem aber Austausch von Daten und Standardisierung.
• TEI wollte vor allem flexibel sein und Forschenden nichts vorschreiben, sondern unterschiedliche Lösungen ermöglichen (Grund für den Erfolg?)
• Wie “revolutionär” es für die TEI eigentlich war, auf deskriptiven statt prozeduralen Markup zu setzen, und wie einflussreich auch für die allgemeine Textverarbeitung.

Insights (Textkodierung allgemein)

• Textkodierung ab 1949 schon mit Lochkarten!
• Die lange Geschichte der Markup-Sprachen.
• Textauszeichnung stößt in den DH auch theoretische Debatten an, setzt Theorie von Text um.
• Vorteil des deskriptiven Ansatzes für die “portability”.
  
• Ursprung des Wortes Markup (als Anweisungen an den Setzer)
• Das OHCO-Modell

Frage 1: Kodierung von Materialität in TEI

• Ein Ansatz dafür ist das Modul 12 “Representation of Primary Sources”
• Sie Kapitel 12 in den TEI-Guidelines
• Es enthält u.a. die Elemente facsimile, surface, zone.
• Grundlegender Ansatz
  • Kodierung der materiellen Seite (Buch als Objekt mit Flächen)
  • Kodierung der textuellen Seite (Buch als Text mit Textstrukturen)
  • Verknüpfung der beiden Repräsentationen durch gegenseitiges Verlinken

Frage 2: Beispiel für überlappende Hierarchien

• Siehe Kapitel 21 zu “Non-Hierarchical Structures” in den TEI Guidelines
• Quellen von Konflikten:
  • Physische Struktur (bspw. Seiten) vs. intellektuelle Struktur (Absätze)
  • Versstruktur vs. syntaktische Struktur (in der Lyrik)
  • Versstruktur vs. Grenzen der direkte Rede (im Drama)
  • Verschiedene analytische Perspektiven
• Lösungsansätze
  • Leere Elemente (“milestone elements”), die Grenzpunkte markieren
  • Aufsplitten eines Elements in mehrere Teile
  • Stand-off Markup (separate Datei / separater Bereich)
• Siehe Beispiel-Dateien

Sonstiges

• DGSSL: nur für SGML, jetzt XSL für XML
• Beziehungen zwischen SGML, HTML, XML
  • SGML und HTML parallel entwickelt
  • HTML4 ist SGML-kompatibel
  • HTML5 nicht mehr
  • XHTML ist XML

Alternative zu XML für TEI?

• Große Einigkeit:
  • JSON oder JSON-LD wären geeignet
  • Markdown und CSV (und HTML) nicht
• Argumente pro JSON
  • Auch hierarchisch, wie XML/OHCO
  • Einfach, weit verbreitet, anpassungsfähig: beliebige Keys
  • JSON-LD: unterstützt zudem semantische Beziehungen (context verbindet Keys mit RDF-Vokabular)
• Einschränkungen
  • Bei komplexen Strukturen etwas unübersichtlich (?)
  • keine expliziten Tags (?)
  • Attribute zu einem Key müssten als Unterstuktur gesetzt werden
  • keine Validierung (sehr wichtig)

Sitzung 5 - Ariadne Baresch

Sitzung 6
XPath

Kurzer Nachtrag: TEI in JSON-LD

• Aktuelle Diskussion auf der TEI-Mailingliste, siehe Archiv:
  https://lists.psu.edu/cgi-bin/wa?A2=2411&L=TEI-L&D=0&P=23010454

Fragen zu XPath (1): XQuery vs. XPath vs. XSLT

Eigenschaft	XPath	XQuery	XSLT
Ziel	Zugriff auf Knoten	Auswahl, Transformation und Generierung von XML	Transformation von XML in andere Formate, bspw. HTML
Anwendung	Datenabfrage / Navigation (auch in XQuery und XSLT)	Datenabfrage, -aggregation, -manipulation	Layout- und Formattransformierungen.
Sprachtyp	Expression Language	Query Language	Templating-Sprache
Syntax	Pfadausdrücke	SQL-ähnliche Syntax	XML-basierte Syntax mit Templates
Komplexität	Relativ einfach	Mittel	Komplexer

Nachfragen zu XPath (2): XPath in Python

• Hauptsächlich bezogen auf die Frage, wie XPath “in the real world” dann eingesetzt wird, bspw. in Python.
• Hier wird die Library lxml genutzt
• Siehe hierzu Code-Beispiel mit bibliographischen Daten in XML/RDF.
  • Anzahl verschiedener Publikationstypen
  • Wichtigste Sprachen pro Publikationstyp
  • Anzahl der Autor:innen pro Beitrag, pro Publikationstyp
  • Anzahl von Beiträgen mit bestimmter Anzahl von Autor:innen

Was sind Reguläre Ausdrücke?

• Worin liegen die Stärken von Regulären Ausdrücken (Regular Expressions)?
• Worin liegen im Vergleich zu XPath bestimmte Nachteile?
• Siehe auch Beispiel mit XML/RDF

Sitzung 7 (3. Dez.):
X-Technologien – XSLT

Überblick

• Fragen zu XSLT

Anwendungsbeispiel XML zu HTML (u.a. auch: CSS)

https://side17.i-d-e.de/index.html

Überblick über den Prozess

Setup für Transformationen

• Tools
  • Texteditor, bspw. Geany oder VSC / Codium
  • Java JRE / OpenJDK (requirement)
  • Saxon HE 12 für Java
• Bausteine (Beispiel-Transformation)
  • XML-Dokument: source/records.xml
  • XSL-Transformation: transform/records-to-csv.xsl
  • Output-Datei: output/records.csv
  • Java-Befehl: java -jar saxon-he-12.jar -s:source/records.xml -xsl:transform/records-to-csv.xsl -o:output/records.csv

Anwendungsbeispiel XML zu CSV (Konstrukte)

• Konstrukte (nach denen teils gefragt wurde, teils nicht)
  • <xsl:for-each select="">: Loop über alle bestimmten Elemente
  • <xsl:sort select="">: Sortierung nach einem bestimmten Kriterium (Umstrukturierung!)
  • <xsl:if test="">: If-Bedingung (siehe XSLT als Programmiersprache)
  • <xsl:value-of select="">: Wähle den Element-Inhalt
  • <xsl:text>: Füge plain text / String ein

Anwendungsbeispiel XML zu CSV (Code)

Beispiel: https://programminghistorian.org/en/lessons/transforming-xml-with-xsl

Anwendungsbeispiel XML zu SVG (Konstrukte)

• Frage: Beispiel zur Umwandlung eines XML-Dokuments in eine SVG-Datei
• Antwort: Erneut aus dem vorigen Datensatz; Beispielsweise: Wir könnten die Anzahl der “records” pro Stadt (oder pro Jahr) zählen und dann einen Barchart anlegen, der diese Anzahl visualisiert
• Es kommen wieder mehrere XSL-Konstrukten zum Einsatz (nach denen teils gefragt wurde):
  • <xsl:call-template name="generateBarChart"/>: Um das Ergebnis eines Templates in den HTML-Kontext einzubauen
  • <xsl:for-each select="">: Um über alle Treffer für ein Element zu iterieren
  • <xsl:variable name="" select="."/>: Variable anlegen, die dann nach und nach befüllt / modifiziert werden kann (Variable!)
  • Die Variablen cityName, cityCount und barHeight werden angelegt, befüllt / berechnet und genutzt
• Knackpunkt
  • <xsl:for-each select="//city[not(. = preceding::city)]">
  • Sorgt dafür, dass ein neuer Eintrag nur begonnen wird für Städte, die noch nicht vorkamen
  • Vom aktuellen Knoten aus (.) gesehen, wird eine neue Stadt nur angelegt, wenn sie keiner (not) der preceding-siblings “city” (preceding::city) entspricht

Anwendungsbeispiel XML zu SVG (Code)

Frage: Ist XSLT eine Programmiersprache?

• XSLT hat einige Merkmale einer Programmiersprache:
  • Es gibt Schleifen und Bedingungen (also eine Ablauflogik)
  • Es gibt Variablen, die angelegt, befüllt, verändert werden können
  • Ein Input wird verarbeitet und ein Output generiert
  • Man kann templates definieren und später aufrufen (wie Funktionen)
  • Es gibt einfache eingebaute Funktionen / Methoden (wie count)
• Es gibt aber auch Gegenargumente
  • XSLT ist deklarativ (beschreibt Ergebnis), aber nicht imperativ/prozedural (definiert Prozess)
  • XSLT ist auf XML spezialisiert und nicht so vielfältig einsetzbar wie Python, Java oder C++

Sitzung 8 (10. Dez. 2024):
TEI

Überblick

• Rückfragen zu TEI
• Grenzfälle der TEI-Kodierung

Visualisierung und Analyse von TEI-Daten

• Frage: Welche Programme können TEI-Daten gut visualisieren und analysieren? Wie integriert man TEI-Daten in gängige Workflows, z. B. für die Datenanalyse?
  
• Antwort
  • Es gibt keine Programme speziell für die Auswertung von TEI-Dateien
  • Man liest typischerweise erst mit XPath Informationen aus und speichert sie als CSV/JSON
  • Diese Daten kann man dann bspw. mit Python (pandas, numpy, seaborn) analysieren und visualisieren
  • Ausnahme: die DraCor-Plattform, die direkt für die Anzeige und einige Auswertungen gedacht ist

Alternativen zu TEI

• Frage: Gibt es Alternativen zur Textkodierung mit TEI? Bieten sie irgendwelche Möglichkeiten, die TEI nicht hat?
• Antwort
  • Es gibt sehr viele Alternativen, aber eigentlich keine Konkurrenz für wissenschaftliche digitale Editionen
  • Mediawiki (Wikipedia)
  • Markdown (allgemein einsetzbar)
  • LaTeX (wiss. Texte)
  • HTML (Webseiten)
  • JATS (wiss. Zeitschriften)

TEI und Bilder

• Frage: Wie kann man visuelle oder grafische Inhalte (wie Diagramme oder Karten) in TEI-Dokumente integrieren?
• Antwort
  • Siehe Kapitel 15 der Guidelines zu Tables, Formulae, Graphics and Notated Music
  • Grundsätzlich kann man sagen, dass solche Informationen nicht kodiert, aber einbebettet werden können
  • Ausnahme: Tabellen, für die es <table>, <row>, <cell> gibt
  • Für die anderen Medien gibt es jeweils externe Standards, mit denen sie kodiert werden können
  • Formeln bspw. mit LaTex: <formula notation="TeX">$e=mc^2$</formula> (Alternative: MathML)
  • Musik bspw. mit MEI: <notatedMusic><ptr target="chanson.xml"/></notatedMusic>
  • Abbildungen: in <figure> und <graphic>
  • Siehe auch: Kapitel 5 Characters, Glyphs and Writing Modes

Beispiel für Musik

<notatedMusic>
  <ptr target="/data/music/bar1.xml" mimeType="application/vnd.recordare.musicxml"/>
  <desc>First bar of Chopin's Scherzo No.3 Op.39. Encoded in MusicXML.</desc>
</notatedMusic>

Beispiel für Abbildung

<figure>
 <graphic url="Fig1.png"/>
 <head>The View from the Bridge.</head>
 <figDesc>A Whistleresque view showing four or five sailing boats in
   the foreground, and a series of buoys strung out between
   them.</figDesc>
</figure>

Validierung

• Frage: Kann man / muss man die Validität von TEI Dokumenten prüfen?
• Antwort:
  • Ja, auf jeden Fall!
  • Die allgemeinen Schema-Sprachen (vgl. Sitzung im Nov.) für XML sind auch für TEI einsetzbar
  • Diese kann man dann einsetzen, um die Validität von TEI-Dokumenten zu prüfen

Grenzfälle der Kodierung mit TEI

• Songs (Text und Musik als Noten oder Melodie)
• Digitale Kunstwerke (interaktive, dynamische Inhalte)
• Multimedia (siehe oben, bspw. Bilder oder Musiknotation)
  
• 3D-Museumsobjekte (Schwert, Gemälde)
• Digitale Filme (Text/Skript, visuelle Elemente)
• *Grafik Novel / grafischer Roman (Text und Bild, vgl. CBML)
• interaktive Installation
• *Manuskripte (Handschrift + Zeichnungen oder Skizzen)
• 3D-Artefakte
• Musikdateien
• Animationen oder Videos
• *mündliche Erzählungen (siehe Kapitel 8 Transcriptions of Speech)

Sitzung 9 (17. Dez. 2024):
Dictionaries mit TEI

Überblick

• Allgemeine Fragen: Zu welchen Aspekten der Kodierung von Wörterbuch-Einträgen mit TEI möchten Sie noch mehr Informationen oder ein Beispiel hören?
• TEI und Lex-0: Welche Gründe könnte es dafürgeben, dass die TEI nicht grundsätzlich dem ja eigentlich einleuchtetenden Prinzip von TEI Lex-0 folgt, die Kodierung von Quellen stärker als bisher zu formalisieren und zu standardisieren?

Aspekte der Kodierung von Wörterbucheinträgen

• Wie kann man historische und heutige Bedeutungen eines Wortes zeitlich differenzieren?
• Wie kann man in TEI die Etymologie und Geschichte von Wörtern kodieren?
• Wie kodiert man Mehrdeutigkeiten, Polysemie und Homonyme, auch mit Belegstellen?
  
• Welche TEI-Elemente gibt es, mit denen man diakritische Zeichen oder die Schreibweise von Wörtern in alten Schriftformen richtig kodieren kann?
• Wie geht man mit Wörterbüchern um, die unterschiedliche Schriftzeichen verwenden, z.B. Deutsch - Russisch oder Deutsch - Chinesisch?
• Wie sieht das bei zweisprachigen Wörterbüchern aus?
• Wie unterscheiden sich und ?
• Wie können Zitate oder Beispiele aus verschiedenen Quellen einheitlich referenziert werden?
• Zitate: Wie organisiert man Zitate mit verschiedenen Typen (wie „Beispiel“ oder „Übersetzung“) und mit Referenzen?

Zeitliche Einordnung von Bedeutungen

• Bedeutungen: Mehrere <sense>-Elemente mit Kind-Elementen <def> und <cit>
• Zeitliche Einordnung: mit Kind-Element <usg> und Attribut @type
• Standard-Werte für @type: “temporal”, “geographic”, “domain”, etc.
• Der Element-Inhalt von <usg> kann dann Zeitangaben beinhalten

<sense n="2">
  <usg type="temporal">Vx.</usg>
  <def>Vaillance, bravoure (spécial., au combat)</def>
  <cit type="example"> 
  <!--- -->
</sense>

Angabe von etymolologischen Informationen

• Siehe Artikel “TEI Lex-0 Etym” in JTEI.
• Deckt “etymons” (Sprachstufen, zeitlich) und “cognates” (verwandte Sprachen, räumlich) ab
• Mit dem Element <etym> (innerhalb von <entry> oder <sense>)
• Darin: <cit> mit den Attributen @type (“etymon” | “cognate”) sowie Elementen <lang> und <form>

<entry xml:id="Eingang" xml:lang="de">
  <form type="lemma"><orth>Eingang</orth></form>
  <gramGrp><gram type="gen">m.</gram></gramGrp>
  <etym>
    <cit type="etymon" xml:lang="gmh">
      <lang expand="Mittelhochdeutsch" norm="gmh">mhd.</lang>
      <form><orth>īnganc</orth></form>
    </cit>
    <cit type="cognate" xml:lang="nl">
      <lang expand="Neuniederländisch" norm="nl">nnl.</lang>
      <form><orth>ingang</orth></form>
    </cit>
    <cit type="cognate" xml:lang="da">
      <lang expand="Dänisch" norm="da">dän.</lang>
      <form><orth>indgang</orth></form>
    </cit>
    <cit type="cognate" xml:lang="sv">
      <lang expand="Schwedisch" norm="sv">schwed.</lang>
      <form><orth>ingång</orth></form>
    </cit>
    <lbl>Lehnübersetzung des</lbl>
    <cit type="etymon" xml:lang="la">
      <lang expand="Latein" norm="la">lat.</lang>
      <form><orth>introitus</orth></form>
    </cit>
    <note>Aus dem ‘Hineingehen’ als Handlung ist 
      die ‘Stelle, an der man ins Haus, in den Saal geht’ 
      geworden, neuerdings auch die ‘Gesamtheit der 
      eingegangenen Geschäftssachen, Mannschaften’ 
      usw. Vgl. <xr type="related"> <ref type="entry">Zugang</ref>. 
        <ref type="bibl">(Kluge, 1975) p. 159</ref></xr></note>
  </etym>
</entry>

Schreibweisen von Wörtern in alten Schriftsystemen

• Grundsätzlich ist das Element <orth> innerhalb von <form> für Schreibweisen gedacht
• (Für die Aussprache ist <pron> innerhalb von <form> vorgesehen
• Man kann das Attribut @type verwenden, um Schreibvarianten anzugeben
• Der Attributwert kann “variant” lauten oder sonstiges Stichwort
• Diakritika oder historische Zeichen können mit Unicode angezeigt werden

<entry xml:id="père" xml:lang="fr"> 
  <form type="lemma">
     <orth>père</orth>
  </form>
  <form type="variant" notAfter="1820">
    <orth>pére</orth>
  </form>
  <form type="fictionalVariant" notAfter="1600">
    <orth>ᵱere</orth>
    <!-- 1D71 latin small letter p with middle tilde for illustration -->
  </form>
  <!--...-->
</entry>

Zweisprachige Wörterbücher

• Mit <cit> (und <form> oder <quote>), siehe: in der Spezifikation

<entry xml:id="horrifier" type="mainEntry" xml:lang="fr">
  <form type="lemma">
     <orth>horrifier</orth>
  </form>
  <!-- -->
  <sense xml:id="horrifier.1">
     <cit type="translationEquivalent" xml:lang="en">
        <form>
           <orth>horrify</orth>
        </form>
     </cit>
     <cit type="example">
        <quote>elle était horrifiée par la dépense</quote>
        <cit type="translation" xml:lang="en">
            <quote>she was horrified at the expense</quote>
        </cit>
     </cit>
  </sense>
</entry>

Unterschied von <cit> und <usg>

• <cit> = citation: jede Art von Beleg oder Illustration (siehe oben)
• <usg> = usage: Informationen zu abweichenden Verwendungskontexten (siehe hier)

<entry xml:id="pflaume" xml:lang="de" type="mainEntry" xml:base="../TEILex0.examples/examples.stripped.xml">
  <form type="lemma">
     <orth>Pflaume</orth>
  </form>
  <sense n="1" xml:id="pflaume.1">
     <def xml:lang="de">Frucht des Pflaumenbaums</def>
 </sense>
  <sense n="2" xml:id="pflaume.2">
     <usg type="socioCultural" norm="colloquial">ugs.</usg>
     <def xml:lang="de">Pflaumenbaum</def>
  </sense>
  <sense n="3" xml:id="pflaume.3">
     <usg type="socioCultural" norm="casual">salopp</usg>
     <usg type="socioCultural" norm="expletive">Schimpfwort</usg>
     <def xml:lang="de">ungeschickter, untauglicher Mensch</def>
  </sense>
  <sense n="4" xml:id="pflaume.4">
     <usg type="geographic" norm="regional">landsch.</usg>
     <usg type="socioCultural" norm="casual">salopp</usg>
     <def xml:lang="de">anzügliche, leicht boshafte Bemerkung</def>
  </sense>
</entry>

Wie kann man bibliographische Angaben / Quellenangaben kodieren?

• Mit <bibl> oder <biblStruct>
• Innerhalb von <cit> zu <quote>
• Oder als Quelle für eine Definition: <sense>/<def>

<entry xml:id="chien" xml:lang="fr">
  <form type="lemma">
     <orth>chien</orth>
  </form>
  <sense xml:id="chien.1">
     <cit type="translationEquivalent" xml:lang="en">
        <form>
          <orth>dog</orth>
        </form>
     </cit>
     <cit type="example" xml:lang="fr">
        <quote> Le matin j'ouvre au <ref type="lemma">chien</ref> et je lui fais manger sa soupe. Le soir je lui siffle de venir se coucher.</quote>
        <bibl>RENARD, Poil de Carotte, 1894, p. 102.</bibl>
     </cit>
  </sense>
  <sense xml:id="chien.2">
  <!-- --> 
  </sense>
</entry>

Einzelfrage Informationsreichtum von Wörterbüchern

• Frage: Sind digitale Wörterbücher besser als gedruckte, bspw. weil sie vollständig sein können und für mehrere Gruppen von Nutzenden (bspw. Anfänger und Expertinnen) geeignet sind?
• => Diskussion

Argumente

• Im digitalen Medium gibt es keine strikte Platzbegrenzung (Anzahl Lemmata; Anzahl und Umfang der Belegstellen; Umfang der Kommentare; Detailgrad der Etymologie)
• Das digitale Medium kann verschiedene Perspektiven auf die Daten anbieten (Etymologie oder Belegstellen einblenden/ausblenden)
• Mehrere digitale Wörterbücher können miteinander und mit Korpora vernetzt sein
• Der Aufwand, das alles umzusetzen, ist sehr hoch
• …

(2) TEI und TEI Lex-0: Diskussion

• Frage: Welche Gründe könnte es dafür geben, dass die TEI nicht grundsätzlich dem ja eigentlich einleuchtetenden Prinzip von TEI Lex-0 folgt, die Kodierung von Quellen stärker als bisher zu formalisieren und zu standardisieren?
• => Diskussion

Argumente

1. Standardisierung und Interoperabilität => projektübergreifende Datenintegration.
2. Viele TEI-Projekte: sehr individualisierte, spezielle Anforderungen.
3. Die TEI-Guidelines wollen flexibel, vielseitig und anpassungsfähig sein, um möglichst viele Projekte, Anwendungsfälle, Textsorten, Communities zu unterstützen.
4. Die TEI Guidelines sind allgemeine Richtlinien, nicht zwingende Normen
5. TEI erlaubt es, individuelle Lösungen zu entwickeln
6. Historische Entwicklung: nachträgliche Standardisierung würde bestehende Kodierungen verkomplizieren.
7. Komplexität und Vielfalt von Wörterbüchern (und anderen Quellentypen) erfordert flexibles Datenmodell
8. Man könnte für mehrere Module der TEI / verschiedene Textsorten ähnliche Teilmengen wie TEI Lex-0 für Wörterbücher definieren, als Austauschformat (siehe DTABf)
9. Unterschiedliche Benutzeranforderungen und Ressourcen für strengere Standards (?)

Sitzung 10:
MEI

Überblick

• Textsorten und Kodierungssprachen
• Nachfragen

Textsorten und Kodierungssprachen

Sie haben durchgehend sinnvolle Antworten gehabt, sehr gut! Ich ergänze hier noch ein paar Hinweise.

• Urkunden: TEI oder, speziell für Urkunden, CEI (Charters Encoding Initiative); Integration in TEI ist aber vorgesehen.
• Oper: Eine Mischung von MEI (für den Notenanteil) und TEI (für den Textanteil), in Kombination oder auch in einem Dokument (über Namespaces)
• Postkarte: TEI (mit Einbindung mindestens einer Bilddatei für die Bildseite)
• Lehrbuch: TEI oder auch LaTeX (mit Einbindung von mehreren Bilddateien für Illustrationen)
• Ausstellungskatalog: TEI oder LaTeX (für komplexen Textsatz vorteilhaft)

Beispiel für Musiktheater / Musical / Oper

• Ein gutes Beispiel hierfür ist die digitale Edition der “Begger’s Opera”
• Auf Github kann man auch die zugrundeliegenden Daten einsehen: Repository
• Der Ansatz des Projekts ist folgender
  • Es gibt eine TEI-Datei für den gesamten gesprochenen / gesungenen Text
  • Dort sind MEI-Dateien eingebunden, die den Notentext (mit Einzelnen Wörtern / Silben des Liedtextes) repräsentieren
• Einige Auszüge zur Illustration auf den folgenden Seiten

Begger’s Opera: der teiHeader mit den Namespaces von TEI und MEI

<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xmlns:xi="http://www.w3.org/2001/XInclude"
    xmlns:mei="http://www.music-encoding.org/ns/mei">
    <teiHeader>
        <fileDesc>
            <titleStmt>
                <title type="main">The Beggar's Opera: </title>
                <title type="subordinate">An Electronic Edition</title>
                <author>
                    <name key="n80045862">Gay, John, 1685-1732</name>
                </author>
                <editor>: <name><lb/>Newman, Steve</name>
                    <name><lb/>Rowland, Fred</name>
                    <name><lb/>Krick, Jack</name>
                    <name><lb/>Wermer-Colan, Alex</name>
                </editor>
            </titleStmt>
            <editionStmt>
                <edition>
                    <lb/>2023-8-9</edition>
            </editionStmt>
            <extent/>
            <publicationStmt>
                <publisher>Temple University</publisher>
                <pubPlace>Philadelphia, PA 19122</pubPlace>
                <availability>
                    <p>Usable according to the Creative Commons License <ref
                            target="http://creativecommons.org/licenses/by-nc-sa/3.0/">Attribution
                            Non-commercial Share-alike</ref>.</p>
                </availability>
            </publicationStmt>
            <sourceDesc>
                <biblStruct>
                    <monogr>
                        <title level="m">The Beggar's Opera. As it is Acted at the Theatre-Royal in
                            Lincolns-Inn-Fields.</title>
                        <author>
                            <name key="n80045862">Gay, John, 1685-1732</name>
                        </author>
                        <imprint>
                            <publisher>John Watts</publisher>
                            <pubPlace>London, UK</pubPlace>
                            <date>1728-00-00</date>
                        </imprint>
                    </monogr>
                </biblStruct>
            </sourceDesc>
        </fileDesc>
    <!--- 550 weitere Zeilen im Header! -->
    </teiHeader>

Quelle: https://github.com/BeggarsOpera/TEI-MEI/blob/master/bo.xml

Begger’s Opera: der div-Bereich mit den eingebetten MEI-Dateien

<div1 type="musical_scores" xml:id="SCORES1">
  <head>OUVERTURE in SCORE</head>
  <opener>Composed by Dr. PEPUSCH.</opener>
  <div2 type="musical_score">
    <notatedMusic xml:id="OUVERTURE" type="score">
      <xi:include href="mei/Overture.mei" xpointer="f-Overture_m-21">
        <!-- The xpointer must point to the <music> element in the MEI file -->
        <xi:fallback>Missing File</xi:fallback>
        </xi:include>
    </notatedMusic>
  </div2>
</div1>
<div1 type="musical_scores" xml:id="SCORES2">
  <head>SONGS in the BEGGAR's OPERA.</head>
  <div2 type="scores_by_act" xml:id="sba1">
    <head>ACT I.</head>
      <div3 type="musical_score">
        <head>AIR I. An old Woman cloathed in Gray, <hi rend="italic">&amp;c.</hi></head>
        <notatedMusic xml:id="SCORE_1" type="score">
          <xi:include href="mei/10101.mei" xpointer="f-10101_m-28">
            <!-- The xpointer must point to the <music> element in the MEI file -->
            <xi:fallback>Missing File</xi:fallback>
          </xi:include>
        </notatedMusic>
      </div3>
      <!--- Weitere div3-Elemente mit weiteren MEI-Dateien -->
  </div2>
</div1>

Quelle: https://github.com/BeggarsOpera/TEI-MEI/blob/master/bo.xml

Begger’s Opera: Ein kleiner Ausschnitt aus einer MEI-Datei

<?xml version="1.0" encoding="UTF-8"?>
<mei xml:id="f-10101_m-1" meiversion="4.0.1" xmlns="http://www.music-encoding.org/ns/mei">
  <meiHead xml:id="f-10101_m-2">
    <fileDesc xml:id="f-10101_m-3">
      <titleStmt xml:id="f-10101_m-4">
        <title xml:id="f-10101_m-14">A C T I.</title>
        <title xml:id="f-10101_m-15" type="subtitle">AIR I.  An old woman cloathed in gray.</title>
        <composer xml:id="f-10101_m-16">John Christopher Pepusch</composer>
        <lyricist xml:id="f-10101_m-18">John Gay</lyricist>
        <respStmt xml:id="f-10101_m-22">
          <persName xml:id="f-10101_m-23"/>
        </respStmt>
      </titleStmt>
      <!--- Weitere Header-Informationen -->
  </meiHead>
  <music xml:id="f-10101_m-28">
    <body xml:id="f-10101_m-29">
      <mdiv xml:id="f-10101_m-30">
        <score xml:id="f-10101_m-32">
          <scoreDef xml:id="f-10101_m-33" lyric.name="Times New Roman" meter.count="3" meter.unit="2" music.name="Opus Std" page.botmar="15mm" page.height="279.4mm" page.leftmar="15mm" page.rightmar="15mm" page.topmar="15mm" page.width="215.9mm" ppq="256" spacing.staff="17" spacing.system="18.5" text.name="Times New Roman" vu.height="0.875mm">
        <staffGrp xml:id="f-10101_m-34">
        <staffGrp xml:id="f-10101_m-48" n="4" symbol="brace">
        <staffDef xml:id="f-10101_m-35" clef.line="2" clef.shape="G" key.mode="minor" key.sig="2f" lines="5" n="1">
          <label xml:id="f-10101_m-36"> </label>
          <labelAbbr xml:id="f-10101_m-37"> </labelAbbr>
          <!-- keyboard.piano.grand.bright -->
          <instrDef xml:id="f-10101_m-39" midi.channel="1" midi.pan="63" midi.volume="100"/>
        </staffDef>
        <staffDef xml:id="f-10101_m-40" clef.line="4" clef.shape="F" key.mode="minor" key.sig="2f" lines="5" n="2">
          <label xml:id="f-10101_m-41"> </label>
          <labelAbbr xml:id="f-10101_m-42"> </labelAbbr>
          <!-- keyboard.piano.grand.bright -->
          <instrDef xml:id="f-10101_m-44" midi.channel="1" midi.pan="63" midi.volume="100"/>
        </staffDef>
       </staffGrp>
       </staffGrp>
       </scoreDef>
       <section xml:id="f-10101_m-49">
       <pb xml:id="f-10101_m-27"/>
       <sb xml:id="f-10101_m-51"/>
         <measure xml:id="f-10101_m-50" label="0" metcon="false" n="1">
           <staff xml:id="f-10101_m-52" n="1">
             <layer xml:id="f-10101_m-53" n="1">
              <note xml:id="f-10101_m-54" dots="1" dur="2" dur.ppq="768" oct="4" pname="b" pnum="70" stem.dir="down" tstamp.real="00:00:00" vel="0">
               <accid xml:id="f-10101_m-55" accid.ges="f"/>
               <verse xml:id="f-10101_m-56" n="1">
                 <syl xml:id="f-10101_m-57">Thro'</syl>
               </verse>
              </note>
              <!-- Weitere Noten --> 
             </layer>
            </staff>
          </measure>
        </section>
      </score>
     </body>
   </mdiv>
 </music>
</mei>

Quelle: https://github.com/BeggarsOpera/TEI-MEI/blob/master/mei/10101.mei

Frage: Lassen sich auch historische und alternative Notenschriften mit MEI auszeichnen?

• Ja, für eine (begrenzte Zahl) von historischen Notenschriften gib es MEI-Auszeichnungen
• Dafür gibt es eigene Kapitel in der Dokumentation
  • 5 Repertoire: Mensural Notation (etwa 13.-15. Jahrhundert)
  • 6 Repertoire: Neume Notation (etwa 9-12. Jahrhundert)

Sitzung 11:
SVG

Überblick

• Rückfragen
• Nachteile von SVG

Frage: Warum SVG selbst schreiben?

• Frage: Es gibt eine Menge Software, die SVG direkt zeichnen kann. Was sind also die weiteren Vorteile der Verwendung der XML-Sprache zum Zeichnen von SVG-Bildern?
• Antwort
  • Richtig, es gibt durchaus Software, die Bilder als SVG exportieren kann
  • Sowohl GUI (bspw. Inkscape) als auch Python-basiert (bspw. Pygal, Seaborn)
  • Vorletztes Mal haben wir ja auch SVG mit XSLT generiert
  • Es spricht gar nichts dagegen, diese Tools zu verwenden
  • Sie sollten aber das Format kennen und verstehen

Frage: SVG im Webdesign

• Frage: Welche Vorteile bietet die Verwendung von SVG-Dateien im Webdesign?
• Antwort
  • Hauptvorteil ist, dass die Bilder perfekt skalieren
  • Egal, welche Größe, sie sehen immer super aus
  • Und das auch, wenn die Dateigröße relativ klein ist
  • Daher für Logos, Icons etc. super geeignet
  • Auch bei responsive design gut geeignet

Frage: SVG zu pixelbasiertem Format

• Frage: Wann macht es Sinn ein SVG Datei in einer JPEG umzuwandeln?
• Antwort
  • Vielleicht in einem Szenario, wo man programmatisch eine sehr komplexe SVG-Datei generiert hat
  • Man hat diese dann vielleicht noch nachbearbeitet (Farben, Labels, etc.)
  • Sie ist jetzt aber sehr umfangreich und lädt langsam
  • Sie jetzt als PNG/JPG abzuspeichern, würde die Datei fast sicher kleiner machen
• Beispiel:
  • Wortwolke Word Embeddings mit interaktiven Labels
  • Einige Labels, die besonders interessant sind, feststellen
  • Dann als JPG abspeichern (klein, aber nicht mehr interaktiv)
  • SVG vs. PNG: siehe repo

Bonus: konkretes Beispiel mit Interaktion

• SVG mit Pygal

Nachteile von SVG

• SVG braucht mehr Rendering-Zeit als pixelbasierten Bildformaten um sehr detailierte Grafiken zu zeigen, weil das System jedes Element vom SVG berechnen muss.
• Aus dem gleichen Grund hat SVG viel größere Dateigröße bei komplexen Bildern, wie Fotos oder inhaltsreiche Illustrationen (zum Beispiel digital Artwork).
• Man muss spezielle Kenntnisse in der XML-Syntax haben, um SVG Dateien richtig zu erstellen und zu bearbeiten.
• Für einfache Formen ist SVG sehr platzsparend, aber wenn viele Details, eingebettete Fonts oder Filter enthalten sind, können SVG-Dateien größer werden als optimierte PNG- oder JPEG-Dateien.
• Hoher Speicherplatz bei großen Grafiken
• Für Bearbeitung mit Photoshop ungeeignet
• Zudem ist SVG für Fotografien ungeeignet, da es keine feinen Farbübergänge darstellen kann.
• Auch gibt es bei älteren Browsern oder Programmen teilweise Kompatibilitätsprobleme.

Sitzung 12:
Markdown

Fragen

Auf der Grundlage des Screencasts zu Markdown, und durch einen sorgfältigen Blick auf die Dokumentation zu Quarto hier – https://quarto.org/docs/authoring/markdown-basics.html – (einschließlich des Abschnitts zu “Scholarly Writing”), beantworten Sie bitte die beiden folgenden Fragen:

1. Haben Sie noch Fragen zu Markdown, beispielsweise zur Syntax oder zu Tools?
2. Bitte listen Sie mindestens drei Argument für und gegen die Idee, die nächste Hausarbeit mit Markdown (in Kombination mit pandoc oder Quarto) zu schreiben statt in Word oder Overleaf / LaTex.

Rückfragen zu Markdown

1. Komplexe Tabellen mit Markdown: unterschiedlichen Inhaltsarten (Texte, Bilder, Links, etc.) oder komplexes Layout möglich? => Eingeschränkt mit Markdown selbst, man kann aber immer auch HTML oder (in Quarto mit Typst) auch in Typst Tabellen schreiben
2. Wie gut ist die Unterstützung für Querverweise innerhalb eines Dokuments? => Sehr gut, für: Kapitel, Bilder, Tabellen, Formeln, Code-Listings etc.
3. Funktioniert die Integration mit Zotero gut? => Brauchbar (Export Collection, “keep updated”; Kontrolle der Bibliographie)
4. Gibt es wie bei HTML oder TEI einen Dachverband, der Markdown pflegt und ggf. überarbeitet? => Nein, aber es gibt CommonMark

Argumente PRO Markdown

1. Einfache Texte: Geeignet für einfache Notizen oder Ideen;
   
2. Einfache Syntax: einfache Syntax, leicht zu lernen, schnell zu schreiben, gute Lesbarkeit
3. Viele Exportmöglichkeiten: mit Pandoc/Quarto viele Formate verfügbar (PDF, DOCX, HTML, LaTeX etc.), auch für Single Source Publishing
4. Reiner Text: benötigt wenig Speicherplatz, versionierbar, kollaborativ zu bearbeiten, beliebiger Editor (ja, und gut archivierbar)
5. Einbettung: Bilder (auch in SVG) und Code einbetten leicht möglich (ja, mit “syntax highlighting”)
6. Mit Quarto: Zitationen, Formeln, Code für wissenschaftliche Texte (ja, und Fußnoten, Querverweise)
7. Bibliographie: Automatische Formatierung (ja, und auch Kontrolle über Einträge in der Bibliographie)
8. Keine Ablenkung: Man kann sich auf das Schreiben konzentrieren (beliebtes Argument)
9. Kostenlos: viele Markdown-Editoren sind kostenlos (ja, vgl. Word / Overleaf)
10. Leicht zu lernen: Einfacher als LaTeX, weniger komfortabel als Word

Argumente CONTRA Markdown

1. Viele oder komplexe Tabellen und Grafiken können problematisch sein (ja, nein)
2. Zitationsverwaltung schwierig, kein “citation rendering” (kein Problem bei Quarto)
3. Alles muss erstmal eingerichtet und gelernt werden: Quarto, Template, Zitierstil, Konvertierung
4. Begrenzte fortgeschrittene Formatierungsoptionen: Tabellen, Marginalien, dynamische Elemente
5. Keine Echtzeit-Vorschau, WYSIWYG oder Kollaborationstools (jein)
6. Eingeschränkte Unterstützung für wissenschaftliche Standards ohne Anpassung: Stylesheets oder Templates notwendig
7. Layout kann nicht so einfach verändert werden (richtig)
8. Formeln, Tabellen, Diagramme werden nur eingeschränkt unterstützt (nein, naja, nein)
9. Weniger benutzerfreundlich im Vergleich zu Word. (jein)
10. Weniger verbreitet (ja)
11. Es gibt keine Formatvorlagen (doch)
12. Fußnoten oder bibliographische Angaben nur mit Pandoc (ja, einen Renderer braucht man immer)
13. Keine Validierung (stimmt!)
14. Weniger Einfluss auf Darstellung, bspw. Größe von Bildern (ja, aber geht in Quarto)
15. Man muss Pandoc verstehen, um Markdown-Dokumente zu transformieren. (nein)
16. Word-Dateien lassen sich leichter mit anderen teilen, da die meisten damit vertraut sind. (Wenn das die Anforderung ist, empfehle ich Cryptpad)
17. Keine Standardisierung (richtig, aber siehe: CommonMark-Initiative)

Demo: Quarto-Template für Hausarbeit

• Link: gitlab.rlp.net/dhtrier/lehre/typst-dharbeit
• Tools
  • Quarto zum Schreiben, Preview, Rendern
  • Zotero für die bibliographischen Angaben
  • Im Hintergrund (Pandoc und Typst für das Rendern)
• Schritte
  • Quarto installieren, Template herunterladen
  • Text in Quarto schreiben, Literaturangaben in Zotero verwalten
  • Nach PDF rendern, fertig!

Zeit für die Evaluation

• 10-15 Minuten…

Sitzung 13:
JSON

Überblick

• Einführung in JSON
• Praxis-Beispiel: OpenAlex mit pyalex

Grundlagen von JSON

• JSON = JavaScript Object Notation
• Grundlegend: ein Format, das auf Paaren von “key” und “value” basiert
• Basis-Syntax: {key : value}
• Kann verschachtelt werden: eine value besteht wieder aus einem key-value-Paar
• value: String, Zahl, bool’scher Wert, Liste, Objekt, “null”

Hintergrundinfos

• Gibt es seit etwa dem Jahr 2000
• Ursprünglich für JavaScript entwickelt, heute aber sprach-unabhängig
• Wäre fast “JSML (JavaScript Markup Language)” genannt worden
• Sehr beliebtes Format in der Informatik (vs. XML in den Digital Humanities)

Einfaches Beispiel

{
  "fruit": "Apple",
  "size": "Large",
  "color": "Red"
}

Etwas komplexeres Beispiel

{
  "first_name": "John",
  "last_name": "Smith",
  "is_alive": true,
  "age": 27,
  "address": {
    "street_address": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10021-3100"
  },
  "phone_numbers": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "office",
      "number": "646 555-4567"
    }
  ],
  "children": [
    "Catherine",
    "Thomas",
    "Trevor"
  ],
  "spouse": null
}

Vergleich mit XML

• Ähnlichkeiten
  • Beide sind sprach- und plattform-unabhängig
  • Beide sind hierarchisch organisiert
  • Beide können Text und Daten kodieren
  • Beide definieren eine Syntax ohne eigene Semantik
  • In vielen Fällen kann ein XML-Dokument in JSON transformiert werden
  • Beide können als Transfer-Formate eingesetzt werden
• Unterschiede
  • XML ist durch das Prinzip von Element, Attributen und Werten ausdrucksstärker (m.E.)
  • XML kann viel präziser auf Wohlgeformtheit und Validität geprüft werden
  • JSON ist kompakter und kann schneller geladen werden
  • “JSON is simple, and XML is powerful”

Anwendungsgebiete

• Allgemein
  • Austausch-Format fürs Web
  • Viele APIs liefern die Ergebnisse einer Anfrage als JSON zurück
• Beispiele aus den Digital Humanities
  • Die Schnittstellen (APIs) von Bibliotheken und Museen liefern oft JSON
  • Eine wichtige Alternative: das “Open Archives Initiative Protocol for Metadata Harvesting” (OAI-PMH)
  • Beispiele: OpenAlex, Musicbrainz (XML und JSON), DPLA, Rijksmuseum (JSON, OAI-PMH), …
  • Inzwischen gibt es zunehmend linguistisch annotierte Korpora in JSON (ansonsten vor allem tabular (CSV/TSV), gelegentlich in XML oder XMI)
  • Das HathiTrust Research Center liefert seine “Extracted Features” als JSON
  • Das Kollationierungs-Tool “CollateX” erwartet als Input die Texte in JSON

Verbindung von JSON mit LOD: JSON-LD

• JSON-LD = JavaScript Object Notation for Linked Data
• Grundidee: JSON-Syntax, aber mit LOD-Fähigkeiten
• Also: Möglichkeit, JSON mit einem RDF-kompatiblen “Kontext” zu versehen
• Für Keys und Werte in JSON kann ein IRI definiert werden
  • Verortet Keys / Werte in einer Ontologie / Vokabular
  • Dort ist die Bedeutung des Keys / Werts vermerkt

JSON-LD: Beispiel

{
  "@context": 
    {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": "http://xmlns.com/foaf/0.1/workplaceHomepage",
    "Person": "http://xmlns.com/foaf/0.1/Person"
    },
  "@type": "Person",
  "name": "John Smith",
  "homepage": "https://www.example.com/johns"
}

JSON und APIs mit Python

1. Relevante Ressource mit API identifizieren, die JSON liefert
2. Beispielsweise mit der Python-Library requests bestimmte records herunterladen
3. Mit den Python-Libraries json weiter verarbeiten
   
4. Ggfs. mit pandas und seaborn visualisieren
5. Beispiel: Die API von OpenAlex mit der Library pyalex

Ressourcen

• Abigail Walker: “Getting Data for Digital Humanities with APIs: A Gentle Introduction”, 2019. URL: https://studentwork.prattsi.org/dh/2019/05/13/getting-data-for-digital-humanities-with-apis/
• Matthew Lincoln: “Reshaping JSON with jq”. The Programming Historian, 2016/2024. DOI: https://doi.org/10.46430/phen0055

Sitzung 14

Sitzung 15
Klausur

References

Jannidis, Fotis, Hubertus Kohle, and Malte Rehbein, eds. 2017. Digital Humanities: eine Einführung. Stuttgart: J.B. Metzler Verlag.