Alle Beiträge von martindelaiglesia

Semantic Hainhofer: Linked Open Data aus dem Projekt „Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen Philipp Hainhofers (1578-1647)“

Beitrag von Martin de la Iglesia (HAB)

Die digitale Edition der Reiseberichte und Sammlungsbeschreibungen Philipp Hainhofers (hainhofer.hab.de) umfasst aktuell 5 Texte (15 weitere sind in Vorbereitung), die durch kommentierte Register erschlossen sind bzw. zum Teil derzeit noch erschlossen werden. Diese Register, welche die in den Reiseberichten erwähnten Personen, Orte,[i] Objekte (Kunstwerke u.a.) und Körperschaften (Institutionen) verzeichnen, bilden die Hauptgrundlage für die jüngst veröffentlichten Linked Open Data (LOD).

In seiner ersten Version bietet das LOD-Datenset (RDF/XML, ca. 1,3 MB) rund 13.000 RDF-Tripel, die sich auf über 1000 Entitäten beziehen.[ii] Bis auf wenige Ausnahmen entstammen diese Entitäten der Gemeinsamen Normdatei (GND), d.h. die GND-URIs bilden die Subjekte der Tripel. Den größten Anteil an den Entitäten bilden Personen (692), gefolgt von Orten (263). Der Anteil an Objekten (33) und Körperschaften (16) ist zurzeit also noch überschaubar, wird aber voraussichtlich in den nächsten Jahren noch wachsen.

Grundsätzlich weisen alle Entitäten die folgenden Properties auf (Auflösung der Präfixe s.u.):

  • rdf:type – Zusätzlich zu den in der GND vergebenen gndo-Klassen werden die Entitäten weiteren Klassen aus denjenigen Ontologien zugeordnet, aus denen die anderen verwendeten Properties stammen.[iii] Dabei handelt es sich um die folgenden Klassen:
    • Personen: ecrm:E21_Person, foaf:Person, owl:Thing, schema:Person, wd:Q5
    • Orte: ecrm:E53_Place, schema:Place
    • Objekte: bf:Instance,[iv] ecrm:E22_Human-Made_Object, owl:Thing, schema:Thing
    • Körperschaften: ecrm:E74_Group, foaf:Organization, schema:Organization
  • rdfs:label – Die Vorzugsbenennung der Entität, wie sie auch auf der Editionswebseite verwendet wird. Oftmals unterscheidet sich diese von der in der GND.
  • schema:mainEntityOfPage – URL des zugehörigen Registereintrags auf der Editionswebseite. Dieser bietet in der Regel weiterführende, in den LOD nicht enthaltene Informationen wie Kommentartexte oder Abbildungen.
  • ecrm:P67i_is_referred_to_by – Link zu der Seite innerhalb eines Reiseberichts, auf der die Entität erwähnt wird. Mehrmalige Erwähnungen auf derselben Seite werden nicht gesondert berücksichtigt, sondern durch ein einziges Tripel repräsentiert.
  • Viele Entitäten weisen zudem die Property ecrm:P70i_is_documented_in auf, durch die auf Sekundärliteratur verwiesen wird, die zur Erstellung der Registereinträge herangezogen wurde. Bei den Objekten handelt es sich um URIs aus dem Gemeinsamen Verbundkatalog (GVK). Darin sind derzeit Sammelbandbeiträge und Zeitschriftenaufsätze noch unterrepräsentiert. Die GVK-URIs lassen sich am besten auflösen durch URLs in der Form http://unapi.k10plus.de/?id=gvk:ppn:… bzw. http://unapi.k10plus.de/?id=gvk:ppn:…&format=… (Beispiel: http://unapi.k10plus.de/?id=gvk:ppn:1671800486&format=isbd).
  • Ebenfalls häufig verwendet wird owl:sameAs, um auf Normdaten zu verweisen, die sich auf dieselbe Entität beziehen. Bei den potentiellen Datenquellen handelt es sich um Sandrart.net, bei Personen zudem um Getty Union List of Artist Names (ULAN) bzw. bei Orten um GeoNames und Getty Thesaurus of Geographic Names (TGN). Auf owl:sameAs-Links zu Wikidata wurde verzichtet, da diese bereits in der GND nachgewiesen sind.
  • Gelegentlich wird mittels foaf:page auf externe Webseiten mit weiterführenden Informationen zur jeweiligen Entität verlinkt. Bei Objekten entstammen diese vor allem dem Bildindex der Kunst & Architektur und Bavarikon, bei Personen dem Biographisch-Bibliographischen Kirchenlexikon (lizenzpflichtig) und der Deutschen Biographie.

Weitere Properties kommen nur bei einem Teil der Entitäten zum Einsatz:

  • Personen:
    • schema:birthDate und schema:deathDate – sofern das exakte Geburts- und/oder Todesjahr bekannt ist. Ungenaue oder unsichere Lebensdaten sind nur in den Registereinträgen auf der Editionswebseite enthalten. Zu beachten ist hierbei, dass das Datenformat dem Standard ISO 8601 entspricht, d.h. das Jahr 1 v. Chr. wird repräsentiert durch „0000“, 2 v. Chr. durch „-0001“ usw.
    • wdt:P140 – die Religionszugehörigkeit bzw. Konfession der Person. Mögliche Objekte: wd:Q1841 (katholisch), wd:Q23540 (protestantisch), wd:Q106039 (christlich allgemein; i.d.R. verwendet für Personen aus vorreformatorischer Zeit). Bei Konvertiten kann diese Property mehrfach vorkommen.
    • foaf:made – verweist auf Werke (v.a. Kunstobjekte; siehe auch [iv]), die diese Person geschaffen hat. Bislang sind allerdings nur wenige Datensätze für entsprechende Werke in der GND enthalten, so dass diese Property selten vorkommt. Grundsätzlich können auch Körperschaften Urheberinnen sein.
  • Orte:
    • ecrm:P89_falls_within – i.d.R. die Relation zwischen einem Gebäude und der Stadt, in der es steht. Viele Bauwerke werden hier jedoch als Objekte geführt; dann wird für diese Art der Relation die Property ecrm:P53_has_former_or_current_location verwendet (s.u.).
  • Objekte:
    • ecrm:P50_has_current_keeper und ecrm:P55_has_current_location – Gibt die heutige besitzende Institution (z.B. ein Museum) und den heutigen Standort an.
    • ecrm:P53_has_former_or_current_location – Gibt den Standort zu Hainhofers Zeit an.
    • ecrm:P53i_is_former_or_current_location_of – Wenn es sich bei dem Objekt um ein Bauwerk handelt, kann dieses seinerseits Standort von anderen Objekten (gewesen) sein. Auch diese Angabe bezieht sich auf Hainhofers Zeit.
    • ecrm:P62_depicts – Relation zwischen einem Kunstwerk und einer darauf dargestellten Entität (z.B. Porträtgemälde und porträtierte Person).
    • bf:subject – GND-Schlagwörter im Zusammenhang mit dem Objekt. Dies können sowohl Sachschlagwörter (z.B. künstlerische Motive) als auch Formschlagwörter (z.B. Technik, Material) sein.
  • Körperschaften:
    • ecrm:P107_has_current_or_former_member – Personen, die der Körperschaft angehören.
    • ecrm:P74_has_current_or_former_residence – Der (Haupt-) Sitz der Körperschaft.
  • Zusätzlich sind alle Entitäten aufgelistet, die Hainhofer nicht nur in seinen Reiseberichten erwähnt, sondern auf diesen Reisen selbst getroffen bzw. gesehen hat. Diese Auflistung erfolgt durch Tripel mit dem Subjekt http://d-nb.info/gnd/118700804 (Philipp Hainhofer) und dem Prädikat edm:hasMet. Die Datengrundlage dafür sind nicht die Register, sondern die TEI/XML-Dateien der Reiseberichte (tei:rs/@role).

Da in den nächsten Jahren fortlaufend neue edierte Reiseberichte und Registereinträge hinzukommen werden, wird auch das LOD-Datenset gelegentlich erweitert und aktualisiert werden. Das jeweilige Datum der letzten Bearbeitung ist dem dcterms:modified-Statement am Anfang des RDF-Dokuments zu entnehmen.

Verwendete Namensraumpräfixe:

  • bf: Bibframe, http://id.loc.gov/ontologies/bibframe/
  • dcterms: Dublin Core Metadata Initiative Metadata Terms, http://purl.org/dc/terms/
  • ecrm: Erlangen CRM / OWL implementation of the CIDOC Conceptual Reference Model, http://erlangen-crm.org/current/
  • edm: Europeana Data Model, http://www.europeana.eu/schemas/edm/
  • foaf: FOAF, http://xmlns.com/foaf/0.1/
  • gndo: GND Ontology, https://d-nb.info/standards/elementset/gnd#
  • owl: Web Ontology Language, http://www.w3.org/2002/07/owl#
  • rdf: Resource Description Framework, http://www.w3.org/1999/02/22-rdf-syntax-ns#
  • rdfs: RDF Schema, http://www.w3.org/2000/01/rdf-schema#
  • schema: Schema.org, http://schema.org/
  • wd: Wikidata entities, http://www.wikidata.org/entity/
  • wdt: Wikidata properties, http://www.wikidata.org/prop/direct/
Beispielvisualisierung: die am häufigsten in Hainhofers Reiseberichten erwähnten Personen (Auszug). Die Größe der Bilder ist proportional zur Anzahl der ecrm:P67i_is_referred_to_by-Statements. Gemeinfreie Bilder aus Wikimedia Commons via Wikidata (wdt:P18) via GND (owl:sameAs).

[i] Das Ortsregister umfasst auch Gebäude, sofern sie nicht aufgrund ihres im Vordergrund stehenden architektonischen Charakters ins Objektregister aufgenommen wurden.

[ii] Dazu kommen 1385 weitere Entitäten und Tripel, auf die im Weiteren nicht eingegangen wird, da sie nur der Klassenzuweisung für in anderen Tripeln als Objekte verwendete Entitäten dienen.

[iii] Genauer gesagt handelt es sich um Klassen, die als Domain bzw. Range der Properties definiert sind. Diese können auch fremden Ontologien entstammen. Dies ist beispielsweise der Fall bei foaf:made, dessen Range owl:Thing ist.

[iv] Auch wenn hier im Zusammenhang mit dem Objektregister auch von „Werken“ gesprochen wird, handelt es sich nicht um abstrakte Works im Sinne des WEMI-Modells, sondern um konkrete einzelne Artefakte, also Instances.

Report of the 2019 TEI SIG Text and Graphics meeting

by Martin de la Iglesia (HAB)

Text and Graphics is one of currently 10 active Special Interest Groups (SIGs) within the Text Encoding Initiative (TEI). Although the TEI is concerned first and foremost, as its name suggests, with the encoding of text, users of the TEI Guidelines will often also want to encode information relating to graphics which occur either as digital facsimiles of the text pages or as inline figures within the text. The Text and Graphics SIG aims to “discuss, develop, and document various strategies and best practices for implementing the digital facsimile structures available in TEI P5, especially as relates to graphically rich texts, and for developing methods to extend the TEI when existing structures are not suitable” (https://wiki.tei-c.org/index.php?title=SIG:Text%26Graphic). The SIG usually holds an informal meeting during the annual TEI Conference and Members’ Meeting.

Accordingly, this year’s SIG meeting took place in Graz, Austria, on September 17. To a small but select audience, Uwe Sikora (Göttingen State and University Library, Germany) kicked off the meeting with a presentation of a software application he is developing for the “Ilanot – Maps of God” project (http://ilanot.haifa.ac.il/site/, SUB Göttingen / University of Haifa). In this project, kabbalistic parchment scrolls containing “divine topographies” will be edited in the form of interactive maps. Uwe’s tool, which is based on the VGG Image Annotator (VIA,  http://www.robots.ox.ac.uk/~vgg/software/via/) and runs within the Virtual Research Environment TextGrid (https://textgrid.de/), enables users to select portions on a digital image in the shape of rectangles, polygons, paths, circles, ellipses and points.

These shapes are stored as SVG code that contains coordinates to record their position on the digital image.

The SVG shapes are linked to TEI code in which the selected scroll sections are encoded as tei:zone elements. Using a Graphical User Interface, semantic relations between these zones may be defined by arranging them in a hierarchical structure.

Furthermore each shape may be annotated by custom metadata and tagged according to a custom ontology:

Textual content of the scrolls can be transcribed and added to the resulting TEI document in the usual way, which may then be presented – in their respective positions, as indicated by the SVG code – as an annotation layer on top of the image. A standalone version of the application is going to be developed to provide non-TextGrid users the possibility to annotate image files on their own system and create TEI resources locally.

This approach ties nicely into a discussion that we have had in the SIG and the wider TEI community since at least the 2016 meeting in Vienna: are the current TEI Guidelines sufficient if we want to encode the position of zones in a non-TEI format? The corresponding GitHub Issue is https://github.com/TEIC/TEI/issues/1508, if anyone would like to weigh in. The idea is that some encoders prefer other formats such as JSON or SVG over the att.coordinated attributes (https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.coordinated.html) available in tei:zone (as well as in tei:surface and tei:line). One motivation behind this might be that other formats offer more options for defining shapes, e.g. circles which in SVG are simply encoded using x and y coordinates for the circle center and a third attribute for the radius. Another motivation might be interoperability: some applications may output coordinate data as e.g. JSON files which one would like to refer to directly from the TEI document, while some applications may require e.g. JSON as input – perhaps the most prominent example being IIIF applications – and one does not want to store the same coordinate data twice, in both TEI and JSON.

There are three possible solutions:

  1. Leave everything as it is. In the TEI document, semantically vague linking mechanisms such as @corresp may be used to refer to the non-TEI code, or in some cases it may be stored directly somewhere in the TEI file using its own namespace. Applications need to be configured on a case-by-case basis in order to make use of such coordinate data.
  2. Augment the TEI Guidelines so that TEI can express anything you want. For instance, if you would like to encode a circle in SVG style, a tei:circle element and @radius attribute need to be introduced. If other formats are still necessary for interoperability reasons, the TEI data can then be losslessly converted.
  3. Keep coordinate data in non-TEI files, but introduce a semantically strong linking mechanism so that the TEI code explicitly tells you what to expect at the other side of the link. For instance, a new attribute named @pointsRef would mean: “this link refers to coordinate points for the parent element”. Add some MIME type information, and relatively generic applications could be created that would know how to process e.g. SVG or JSON coordinates when they are explicitly referred to as such in a TEI document.

So far, no consensus has been reached about this issue, but questions of how TEI data and non-TEI data interact become more and more urgent as technologies such as IIIF rapidly rise in popularity.

Recommended citation: Martin de la Iglesia: Report of the 2019 TEI SIG Text and Graphics meeting. In: Ex officina Seleni: aus der Werkstatt der Herzog August Bibliothek Wolfenbüttel. Blog der Arbeitsgemeinschaft Digitale Editionen. October 17, 2019. https://eos.hypotheses.org/272.