Wird es sie bald geben, die eine API, sie alle zu finden und auf ewig zu binden? Im Workshop \u201eAPIs for text-based digital editions\u201c, der in Kooperation der Universit\u00e4tsbibliothek Heidelberg und Text+ am 25.09.2025 online stattfand, wurde unter anderem auch das diskutiert. Mehr Informationen dazu gibt es im folgenden Beitrag, der den Workshop und dessen zentrale Ergebnisse zusammenfasst.<\/p>\n\n\n\n
Programmierschnittstellen (\u201eAPI\u201c von Application Programming Interface<\/i>) stellen Funktionen bereit, mit denen Informationen aus einem System abgerufen oder gesendet werden k\u00f6nnen. Da die zul\u00e4ssigen Abfragen, m\u00f6glichen Parameter und R\u00fcckgaben einer API genau definiert sind, k\u00f6nnen verschiedene Systeme und Anwendungen so einheitlich und effizient auf die Daten zugreifen, ohne die genaue Struktur des zugrundeliegenden Systems kennen zu m\u00fcssen. <\/p>\n\n\n\n
Beispielsweise bietet das Hochschulbibliothekszentrum des Landes NRW die API lobid-gnd<\/i> an, durch die der Zugriff auf die Best\u00e4nde der Gemeinsamen Normdatei (GND) der Deutschen Nationalbibliothek verh\u00e4ltnism\u00e4\u00dfig aufwandsarm in andere Anwendungen integriert werden kann. In dem Webportal einer digitalen Edition k\u00f6nnten zum Beispiel weitere Informationen zu einer Named Entity angezeigt werden, indem beim Klick auf diese im Hintergrund eine Anfrage an einen Endpunkt der lobid-gnd<\/i>-API gesendet wird (z.B.: https:\/\/lobid.org\/gnd\/search?q=Heidelberg&format=json<\/a>). Diese liefert die in der GND gespeicherten Informationen in einem einheitlichen \u2013 und in der Dokumentation der API beschriebenen \u2013 Format aus, das so seitens des Webportals f\u00fcr die Anzeige aufbereitet werden kann und die gew\u00fcnschte Information angezeigt wird (z.B.: \u201eHeidelberg \u2013 Stadt am Neckar, Regierungsbezirk Karlsruhe, 1196 urkundl. erw\u00e4hnt“).<\/p>\n\n\n\n Die Zug\u00e4nglichmachung der Datenschicht einer Edition \u00fcber eine API kann damit die Recherche, Vernetzung und Nachnutzung der Editionsdaten bedeutend erleichtern; sie tr\u00e4gt also auch zur Umsetzung der FAIR-Prinzipien bei. Nicht ohne Grund fragt der Kriterienkatalog der Rezensionszeitschrift f\u00fcr digitale Editionen RIDE<\/i> explizit nach dem Vorhandensein von technischen Schnittstellen.1<\/a><\/sup><\/p>\n\n\n\n APIs finden jedoch trotz der vielen M\u00f6glichkeiten, die sie mit sich bringen, bisher noch keine breite Anwendung im Bereich der digitalen Editionen und der auf ihnen aufbauenden Forschung. Deshalb wurde in Kooperation der Universit\u00e4tsbibliothek Heidelberg mit Text+ ein gemeinsamer Workshop zum Thema \u201eAPIs for text-based digital editions\u201c veranstaltet.<\/p>\n\n\n\n Ziel des Workshops war es, m\u00f6gliche API-Nutzer:innen (z.B. Editionswissenschaftler:innen, Digital Humanists, Sprachwissenschaftler:innen) mit den Dienstanbieter:innen und Entwickler:innen zusammenzubringen, um gemeinsam Grenzen und M\u00f6glichkeiten der Schnittstellen zu erkunden, Bedarfe, W\u00fcnsche und Weiterentwicklungsm\u00f6glichkeiten zu sammeln sowie eventuelle H\u00fcrden bei der Verwendung und Implementierung zu minimieren.<\/p>\n\n\n\n Am 25.09. trafen \u00fcber 60 Personen f\u00fcr den Online-Workshop zusammen. Neben Forscher:innen aus Deutschland, \u00d6sterreich und der Schweiz waren auch Teilnehmende aus u.a. Polen, der T\u00fcrkei, Italien und den USA dabei, womit sich die Entscheidung, Englisch als Workshop-Sprache zu verwenden, direkt als richtig erwies. Vertreten waren u.a. Bibliotheken, Forschungsinstitute, dedizierte DH-Zentren und Data Science Labs sowie auch konkrete Forschungsprojekte.<\/p>\n\n\n\n Das etwa sechsst\u00fcndige Programm gliederte sich dabei in drei Teile:<\/p>\n\n\n\n Die vier vorgestellten Schnittstellen(-spezifikationen) werden nachfolgend zum besseren \u00dcberblick kurz erl\u00e4utert.<\/p>\n\n\n\n Diese API-Spezifikation wird seit 2015 unter st\u00e4ndigem Input der Community gemeinschaftlich entwickelt und liegt aktuell als Release Candidate vor; die Ver\u00f6ffentlichung von Version 1.0 soll dieses Jahr erfolgen. Die Spezifikation sieht neben dem Einstiegspunkt drei Endpunkte (d.h. Orte, an die Anfragen gesendet werden k\u00f6nnen) vor:<\/p>\n\n\n\n Citable units<\/i> k\u00f6nnen dabei grunds\u00e4tzlich jeder Art sein; denkbar w\u00e4ren z.B. Kapitel, Paragraphen, Seiten oder auch Verszeilen. Durch einen oder mehrere sogenannte citationTrees<\/i> wird f\u00fcr jede Ressource hinterlegt, welche Strukturen f\u00fcr sie als m\u00f6gliche Zugriffsform bereitstehen, sodass beispielsweise vom selben Text (sofern implementiert) sowohl die ersten 20 Seiten als auch semantisch-logische Einheiten wie z.B. 3 Kapitel abgerufen werden k\u00f6nnten. Das prim\u00e4re Format, das \u00fcber den document<\/i>-Endpoint bereitgestellt wird, ist TEI-XML; \u00fcber den mediaType<\/i>-Parameter k\u00f6nnen jedoch auch andere verf\u00fcgbare Serialisierungen der Daten abgerufen werden, z.B. plain text, HTML oder ganz andere. Die \u00fcbrigen DTS<\/i>-Endpunkte nutzen JSON-LD zur Auslieferung der Informationen.<\/p>\n\n\n\n\n\n Die SHINE API<\/i>-Spezifikation wurde im Kontext des RISE<\/i>-Projektes vom Max-Planck-Institut f\u00fcr Wissenschaftsgeschichte in Berlin sowie der Staatsbibliothek zu Berlin entwickelt und liegt in Version 1 vor. \u00c4hnlich wie bei DTS<\/i> werden Texte hier als Hierarchie von content units<\/i> und sections<\/i> verstanden, die in resources<\/i> enthalten sind, wobei die Ressourcen wiederum in collections<\/i> gesammelt werden. \u00dcber insgesamt 7 Endpunkte ist dabei u.a. Folgendes m\u00f6glich, wobei die Antwort stets im JSON-Format erfolgt:<\/p>\n\n\n\n Zum letzten Punkt: Ressourcen, die \u00fcber eine SHINE API<\/i> zugreifbar sind, k\u00f6nnen die RISE<\/i>-Infrastruktur nachnutzen; darunter den Import in Textanalyse- oder Annotationsplattformen wie MARKUS<\/i> und Recogito<\/i> oder die Einbindung in den RISE Catalog<\/i>. \u00dcber die RISE<\/i>-Middleware kann zudem beim Zugriff auf ausgew\u00e4hlte Ressourcen ein Authentifizierungsschritt erg\u00e4nzt werden, wenn gew\u00fcnscht.<\/p>\n\n\n\n\n\n Dieser API-Spezifikationsvorschlag orientiert sich am IIIF<\/i>-Standard und wurde in dem 2-Jahres-Projekt \u201eUnlocking Digital Texts: Towards an Interoperable Text Framework\u201c erarbeitet. Er liegt aktuell in Version 0.1.0-beta vor und wird weiter ausgebaut. <\/p>\n\n\n\n Der Zugriff auf Textfragmente erfolgt hier mittels der Text Fragment API<\/i>, w\u00e4hrend die Text Information API<\/i> Metadaten zu den Textressourcen und eventuellen Versionen ausliefert. Anders als die bisher vorgestellten API-Spezifikationen ist die Versionierung damit explizit in der Spezifikation enthalten \u2013 w\u00e4hrend bei DTS<\/i> z.B. indirekt mittels Dublin Core<\/i>-Metadateneintr\u00e4gen angegeben werden k\u00f6nnte, dass eine Ressource eine andere ersetzt, ist die Version hier Teil der Fragment-Anfrage: http:\/\/{server}{\/prefix}\/{identifier}\/{version}\/{mode}\/{fragment}\/{quality}{.format<\/a>}<\/p>\n\n\n\n Die Fragmente werden dabei durch sogenannte modes<\/i> spezifiziert. Vordefiniert sind u.a. char<\/i>, token<\/i> und book<\/i> \u2013 bei char<\/i> w\u00fcrden Fragmente z.B. anhand von character offsets<\/i> zugreifbar sein, w\u00e4hrend book<\/i> eine weitere Untergliederung in Seiten, Zeilen und Zeichen zul\u00e4sst, sodass book<\/i>-Fragmente mittels Koordinaten aus Seite\u2013Zeile\u2013Zeichen gebildet werden k\u00f6nnen. Diese Fragmente werden stets anhand der plaintext-Version einer Ressource berechnet, d.h. ein Server, der diese API-Spezifikation implementiert, muss sicherstellen, dass eventuelles Tagging ignoriert wird. Weitere, selbst definierte modes<\/i> auf Basis der vordefinierten M\u00f6glichkeiten sind ebenso zul\u00e4ssig wie das Zugreifen auf die gesamte Textressource mittels der mode<\/i> \u201cfull\u201d. Als auslieferbare Formate sind dabei txt, TEI-XML, HTML und Markdown im Entwurf vorgesehen. <\/p>\n\n\n\n Auf die weitere Gliederung der Textressourcen in \u00fcbergreifende Sammlungen wird hier verzichtet, d.h. das Konzept der collections<\/i> gibt es hier nicht.<\/p>\n\n\n\n\n\n Die TextAPI<\/i>-Spezifikation ist ebenfalls von IIIF<\/i> inspiriert und wird von der SUB G\u00f6ttingen entwickelt. Die Spezifikation liegt in Version 1.4.2 vor, wobei das Release der Version 2.0.0 aktuell in Planung ist. <\/p>\n\n\n\n Mittels der TextAPI<\/i> k\u00f6nnen collections<\/i>, manifests<\/i> (physische Expression eines Werks) sowie items<\/i> oder jeweils zugeh\u00f6rige Metadaten abgerufen, erstellt, gel\u00f6scht und ersetzt werden. Im JSON-Inhaltsobjekt k\u00f6nnen beliebige Serialisierungen der Ressourcen per URL verlinkt werden; worum genau es sich bei einem item<\/i> handelt, wird dabei durch den Typ-Eintrag im JSON-Objekt klar, der frei gew\u00e4hlt werden kann. Ebenfalls enthalten ist dort auch ein data integrity object<\/i>, in welchem die Pr\u00fcfsumme der referenzierten Ressource sowie der zur Generierung verwendete Algorithmus hinterlegt werden. Diese M\u00f6glichkeit zur Sicherstellung der Datenintegrit\u00e4t ist in den anderen Spezifikationen nicht integriert oder zumindest nicht pflichtm\u00e4\u00dfig enthalten.<\/p>\n\n\n\n Das hier entwickelte \u00d6kosystem umfasst neben der TextAPI<\/i> auch eine AnnotationAPI<\/i>, SearchAPI<\/i> und IndexAPI<\/i> sowie insbesondere den Text Viewer for Digital Objects<\/i> (TIDO), der TextAPI<\/i>-JSON konsumiert und als Frontend einer darauf aufbauenden Web Application verwendet werden kann. Ein Beispiel daf\u00fcr findet sich hier: https:\/\/ahiqar.uni-goettingen.de\/arabic-karshuni.html?tido=m5_i0_p0.0-1.0-2.1-3.0<\/a><\/p>\n\n\n\n Ausgehend von der Feststellung, dass die diskutierten API-Spezifikationen ein \u00e4hnliches Textverst\u00e4ndnis zugrundelegen und REST<\/i>-basiert sind, stellte sich gleich zu Beginn der Diskussionsrunde die Frage, ob die vier verschiedenen Spezifikationen in einen gemeinsamen Standard zusammengef\u00fchrt werden k\u00f6nnten. <\/p>\n\n\n\n Dagegen spricht, dass die pr\u00e4sentierten APIs nat\u00fcrlich nicht die Gesamtheit aller Schnittstellen in diesem Bereich darstellen und schon die vier genannten durch die unterschiedlichen Entwicklungs- und Anwendungskontexte verschiedene Fokusse und damit auch unterschiedliche Features mitbringen. Zudem sind manche der Schnittstellen bereits Teil eines gr\u00f6\u00dferen \u00d6kosystems, sodass \u00c4nderungen hin zu einer gemeinsamen Spezifikation f\u00fcr Inkompatibilit\u00e4ten und damit nachtr\u00e4glichen Anpassungsaufwand sorgen w\u00fcrden.<\/p>\n\n\n\n Allerdings br\u00e4chte ein gemeinsamer Standard enorme Vorteile sowohl f\u00fcr Forschende als auch Infrastrukturanbietende mit sich: Durch ein abstraktes und flexibles Textmodell (wie es die bisher betrachteten APIs verwenden) w\u00e4re es m\u00f6glich, einheitlich auf Texte und zugeh\u00f6rige Metadaten unterschiedlichster Editionsprojekte zuzugreifen. Die einmalige Einarbeitung in diesen Standard und die API-Verwendung w\u00fcrde also den Zugang zu einer F\u00fclle von mit viel M\u00fche und Zeit aufbereitetem Forschungsmaterial erlauben. Mit Sicherheit w\u00fcrde das auch die Nachnutzung dieser Daten f\u00f6rdern. Infrastrukturanbieter:innen m\u00fcssten gleichzeitig lediglich einen einzigen Standard implementieren und zugeh\u00f6rige Skripte pflegen, was die Etablierung und Verf\u00fcgbarhaltung dieser Services deutlich erleichtert. Gleiches gilt f\u00fcr Entwickler:innen von Forschungssoftware, die so leichter \u00fcberblicken k\u00f6nnten, welche Schnittstellen ihr Produkt vielleicht anbieten sollte.<\/p>\n\n\n\n F\u00fcr die Zusammenf\u00fchrung der verschiedenen Spezifikationen w\u00e4ren dabei nat\u00fcrlich viele Abstimmungen n\u00f6tig \u2013 idealerweise nicht nur zwischen den Entwickler:innen, sondern auch innerhalb der Community. Vielleicht kann die zur Vorbereitung des Workshops erstellte \u00dcbersicht der vier Spezifikationen neben der \u00dcberblicksfunktion hierf\u00fcr auch als Diskussionsgrundlage dienen: https:\/\/doi.org\/10.11588\/DATA\/4EKAGI<\/a> (falls Interesse besteht, dort weitere APIs aufzunehmen, gerne melden!). <\/p>\n\n\n\n W\u00e4hrend der Diskussionsrunden stelle sich mehrmals die Frage, wer genau APIs nutzt und zu welchem Zweck \u2013 dies sowohl von Seiten der Wissenschaftler:innen aus, die m\u00f6gliche Einsatzzwecke und damit Mehrwerte der Schnittstellen kennenlernen wollen, als auch von den Entwickler:innen, die konkrete Fallbeispiele nutzen k\u00f6nnen, um die API-Spezifikation weiterzuentwickeln und an die Bedarfe der Community anzupassen. Beispielsweise bat Hugh Cayless um Textzeugen mit komplexeren Strukturen aus Editionsprojekten, um sicherstellen zu k\u00f6nnen, dass das Design des DTS<\/i>–navigation<\/i>-Endpunktes die API-Implementierung in einem Projekt nicht behindert. <\/p>\n\n\n\n Im ersten Schritt k\u00f6nnten die (geplanten oder bereits umgesetzten) Anwendungsf\u00e4lle \u00fcber die jeweiligen GitHub-\/GitLab-Repositorien oder mittels der auf den API-Webseiten angegebenen Kontaktm\u00f6glichkeiten \u00fcbermittelt werden. Die auf den Webseiten oft schon enthaltenen Informationen zur API-Nutzung in bestimmten Projekten k\u00f6nnten dann noch weiter ausgebaut werden und so vielleicht auch weitere Nachnutzungen inspirieren.<\/p>\n\n\n\n Der Vortrag von Magdalena Turska und Wolfgang Meier zur Implementierung der DTS<\/i>-Spezifikation im TEI Publisher<\/i> stellte den letzten Teil des Workshops dar. In der aktuellen Version 9 des TEI Publishers<\/i> sind die beiden DTS<\/i>-Endpunkte collection<\/i> und document<\/i> \u2013 jeweils zur Einsicht in Dokumentensammlungen und zum Herunterladen von Ressourcen \u2013 bereits integriert; in Version 10 soll der fehlende navigation<\/i>-Endpunkt folgen. Den Nutzenden des TEI Publishers <\/i>soll es dabei m\u00f6glich sein, die DTS<\/i>-Komponente mit wenigen Klicks zu ihrer Editionsapp hinzuzuf\u00fcgen oder abzuw\u00e4hlen, ohne selbst etwas implementieren zu m\u00fcssen. <\/p>\n\n\n\n Dies stellt jedoch besondere Herausforderungen an die Entwicklung seitens TEI Publisher<\/i>, da der navigation<\/i>-Endpunkt Wissen zur Textstruktur fordert, die je nach Ressource sehr unterschiedlich ausfallen kann. Das aktuell daf\u00fcr herangezogene TEI-Element citeStructure<\/i> ist jedoch f\u00fcr die Abbildung sehr komplexer Strukturen nur bedingt geeignet. Magdalena Turska schlug deshalb nach der Darlegung der Schwierigkeiten als eine m\u00f6gliche L\u00f6sung vor, die ODDs<\/i> (One Document Does it All<\/i> \u2013 das TEI-eigene Schemaformat) derart anzupassen, dass \u00fcber sie Aussagen zur Textstruktur gewonnen werden k\u00f6nnen. Damit einher ging die Idee, eine Registry dieser ODD<\/i>-Dateien und DTS<\/i>-nutzenden Projekte zu nutzen, da die daf\u00fcr n\u00f6tigen Informationen dann ohnehin im TEI Publisher<\/i> vorl\u00e4gen. <\/p>\n\n\n\n Insgesamt sind meine Kollegen und ich mit vielen Fragen in den Workshop gestartet und mit mindestens so vielen Anregungen auch wieder davon zur\u00fcckgekommen. Die allgemeine Bereitschaft, Erfahrungen zu teilen, Entwicklungsentscheidungen zu diskutieren und erneut zu durchdenken sowie das gro\u00dfe Interesse an einem gemeinsamen Standard haben mich dabei besonders gefreut. Letzteres haben wir zusammen mit dem Wunsch nach mehr Orientierung und Nutzungsbeispielen auch klar als Bedarfe festgestellt. Gelegentlich hatten wir in den Diskussionsrunden den Eindruck, dass sich die Nicht-API-Entwickler:innen noch etwas zur\u00fcckhielten \u2013 vielleicht, weil das Thema neu ist und man sich erst einmal einen Eindruck davon machen wollte. Dass wir dies mit der Kombination aus Vortr\u00e4gen und Fragerunden unterst\u00fctzen konnten, ist gut; zuk\u00fcnftige Angebote k\u00f6nnten hier aber vielleicht noch expliziter auf API-Neulinge eingehen. Vielleicht gibt es ja sogar bald Schulungen zu einem gemeinsamen API-Standard\u2026 In jedem Fall hoffen wir als Veranstalter, dass alle Teilnehmenden etwas aus dem Workshop f\u00fcr sich mitnehmen konnten, und bedanken uns noch einmal herzlich f\u00fcr die gemeinsame Zeit.<\/p>\n\n\n\n <\/p>\n\n\n\n Verfasst von Katharina Br\u00fcckmann<\/a>, mit freundlicher Unterst\u00fctzung von Philipp Hegel<\/a>, Jakub \u0160imek<\/a> und Leonhard Maylein<\/a>.<\/p>\n\n\n Wird es sie bald geben, die eine API, sie alle zu finden und auf ewig zu binden? Im Workshop \u201eAPIs for text-based digital editions\u201c, der in Kooperation der Universit\u00e4tsbibliothek Heidelberg und Text+ am 25.09.2025 online stattfand, wurde unter anderem auch das diskutiert. Mehr Informationen dazu gibt es im folgenden Beitrag, der den Workshop und dessen […]<\/p>\n","protected":false},"author":441,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"id\":\"fa95d48b-41ce-4721-a8f1-fadab2f394e2\",\"content\":\"Siehe Punkt 4.9 in: Sahle, Patrick et al.: \\u201eCriteria for Reviewing Scholarly Digital Editions, version 1.1\\u201c, abgerufen unter https:\\\/\\\/www.i-d-e.de\\\/publikationen\\\/weitereschriften\\\/criteria-version-1-1\\\/<\\\/a> am 17.11.2025.\"}]"},"categories":[10],"tags":[1224,839,35,1814,1815,1818,1816,1817],"class_list":["post-22962","post","type-post","status-publish","format-standard","hentry","category-reflektion","tag-api","tag-bericht","tag-digitale-edition","tag-distributed-text-services","tag-shine-rise","tag-tei-publisher","tag-textapi","tag-textframe"],"_links":{"self":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/22962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/users\/441"}],"replies":[{"embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22962"}],"version-history":[{"count":16,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/22962\/revisions"}],"predecessor-version":[{"id":22978,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=\/wp\/v2\/posts\/22962\/revisions\/22978"}],"wp:attachment":[{"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22962"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dhd-blog.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Idee eines Workshops zum Thema APIs<\/h3>\n\n\n\n
Der Workshop<\/h2>\n\n\n\n
Teilnehmer:innen<\/h3>\n\n\n\n
Programm<\/h3>\n\n\n\n
\n
Vorgestellte APIs<\/h3>\n\n\n\n
Distributed Text Services<\/a><\/h4>\n\n\n\n
\n
SHINE API<\/a><\/h4>\n\n\n\n
\n
UDT-ITF API<\/a><\/h4>\n\n\n\n
TextAPI<\/a><\/h4>\n\n\n\n
Zentrale Ergebnisse der gemeinsamen Diskussion<\/h2>\n\n\n\n
#OneAPIToRuleThemAll?<\/h3>\n\n\n\n
Use Cases sammeln<\/h3>\n\n\n\n
Implementierung einer API-Spezifikation: DTS<\/i> im TEI Publisher<\/a><\/i><\/h2>\n\n\n\n
Pers\u00f6nliches Fazit<\/h2>\n\n\n\n