Hermann Bahr, Arthur Schnitzler (Teil 1)

Zur Modellierung der Daten aus Hermann Bahr – Arthur Schnitzler (Teil 1)

Die Modellierung der Bestandsdaten aus dem ausgelaufenen Projekt zu Hermann Bahr und Arthur Schnitzler ist mittlerweile so weit fortgeschritten, dass ich die vorläufigen Daten vergangen Freitag in den Triple Store geladen habe. Sie stehen nun für Abfragen über das Interface zur Verfügung.

Dieser Post erläutert als erster einer Serie die Modellierung, für die ich erstmals auf CIDOC-CRM und für die Werke auf FRBRoo als Metamodelle zurückgegriffen habe. Dieser Umstieg bedingt auch, dass sich die Daten, die über die Bahr-Schnitzler-API abrufen lassen und jene, die hier zu finden sind, erheblich unterscheiden.

Die Kombination aus CIDOC und FRBRoo ermöglicht zwar eine viel feiner Modellierung der Informationen, ist aber, wie ich finde, alles andere als selbsterklärend und bläht vor allem das RDF ziemlich auf. Das wird insbesondere bei den Werken deutlich werden. Die Informationen, die man dann tatsächlich sucht, muss man sich an unterschiedlichen Stellen zusammensuchen – alles nicht so einfach, aber ich erhoffe mir von diesem Umstieg eine bessere Nachnutzbarkeit der Daten.

URIs und PREFIXe

Die URI jeder Entität in dem Datensatz ist nach dem selben Muster aufgebaut, nämlich nach dem Muster http://bahrschnitzler.acdh.oeaw.ac.at/entity/{hbas-id}. Beispielsweise lassen sich Informationen zu Arthur Schnitzler, der die ID A002001 hat, wie folgt abfragen:

SELECT * WHERE {<http://bahrschnitzler.acdh.oeaw.ac.at/entity/A002001> ?pred ?obj .} »Ausprobieren

Ob es sich bei der Entität um eine Person oder ein Werk handelt, macht – zumindest was das Muster der URI anbelangt – keinen Unterschied. Hier sind beispielsweise die Informationen zum Reigen (A020018):

SELECT * WHERE { hbas_entity:A020018 ?pred ?obj .} »Ausprobieren

Im Übringen habe ich im zweiten Beispiel ein s.g. Prefix definiert, um mir das Ausschreiben der URI einer Entität zu ersparen: hbas_entity: steht hier für http://bahrschnitzler.acdh.oeaw.ac.at/entity/. Im Verlinkten Beispiel-Query sind dieses und einige weitere Präfixe definiert:

  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX crm: <http://www.cidoc-crm.org/cidoc-crm/>
  • PREFIX frbroo: <http://iflastandards.info/ns/fr/frbr/frbroo/>
  • PREFIX schema: <http://schema.org/>
  • PREFIX hbasp: <http://bahrschnitzler.acdh.oeaw.ac.at/property/>
  • PREFIX hbas_entity: <http://bahrschnitzler.acdh.oeaw.ac.at/entity/>
  • PREFIX hbas_type: <http://bahrschnitzler.acdh.oeaw.ac.at/type/>

Im Query selbst ist es dann ausreichend, nur mehr das jeweilige Prefix gefolgt vom Property-Namen bzw. der ID zu schreiben, beispielsweise hbas_entity:A000208 um die Daten zu dieser Entität abzufragen:

SELECT * WHERE { hbas_entity:A000208 ?pred ?obj . } »Ausprobieren

Entitätstypen

Im vorgegangenen Abschnitt wurden bereits drei Typen von Entitäten vorgestellt: Personen, Werke und Orte. Welche Typen es gibt, kann man per SPARQL-Abfrage ausgeben kann:

SELECT DISTINCT ?type WHERE { ?id a ?type . } »Ausprobieren

Interessant sind zunächst die folgenden.

Die übrigen Typen sind zum Teil bedingt durch die Modellierung in FRBRoo (beginnen mit F gefolgt von einer Nummer) oder werden verwendet, um zusätzliche Informationen zu einer der oben genannten Haupttypen zu erfassen.

In diesem Post wird crm:E73_Information_Object erläutert. Die übrigen CIDOC-Entitäten, also crm:E21_Person, crm:E53_Place und crm:E1_Entity bespreche ich im Folgepost. Ein weiterer Post wird sich mit der Modellierung von Werken als frbroo:F1_Work befassen.

Briefe, Aufzeichnungen, Dokumente

Im Projekt, aus dem die Daten stammen, wurden 1.366 Dokumente ausgewählt, die das Verhältnis der beiden Schriftsteller Hermann Bahr und Arthur Schnitzler dokumentieren. Auf der Webseite sind diese in drei Gruppen unterteilt, nämlich in Briefe, Aufzeichnungen und Dokumente. In vorliegenden Datensatz wurden sie als crm:E73_Information_Object modelliert – eine (vorläufige) Entscheidung, die übrigens gerne diskutiert werden kann – mir schien crm:E73_Information_Object recht passend zu sein, weil sich unter den erfassten Dokumenten sehr unterschiedliche Dinge befinden: Die meisten würden wohl unter E33_Linguistic_Object fallen, es gibt aber auch ein paar Fotos, bei denen diese Zuordnung sicherlich falsch wäre.

Die Dreiteilung, für die sich das Projekt entschieden hat, wird als Typ erhalten und kann mit crm:P2_has_type abgefragt werden.

  • http://bahrschnitzler.acdh.oeaw.ac.at/type/L Brief
  • http://bahrschnitzler.acdh.oeaw.ac.at/type/D Aufzeichnung (in den meisten Fällen Tagebucheintrag)
  • http://bahrschnitzler.acdh.oeaw.ac.at/type/T Dokument bzw. Text

Die entsprechenden Dokumente lassen sich nach folgendem Muster abfragen:

SELECT ?resource ?label FROM <http://bahrschnitzler.acdh.oeaw.ac.at> WHERE { ?resource a <http://www.cidoc-crm.org/cidoc-crm/E73_Information_Object> ; rdfs:label ?label; crm:P2_has_type <http://bahrschnitzler.acdh.oeaw.ac.at/type/L> . }»Ausprobieren

Im vorliegenden Datensatz wurde neben der groben Unterteilung in die drei genannten Typen zusätzlich eine Unterklassifizierung eingefügt. Diese findet sich in dieser Form zwar teilweise implizit in den Daten, wie sie in die Bahr-Schnitzler-Webseite eingeflossen sind (Attribut @tei:type), sind aber beispielsweise über das Interface nicht zugänglich. Alle vergebenen Dokumenttypen lassen sich so auflisten:

SELECT DISTINCT ?type FROM <http://bahrschnitzler.acdh.oeaw.ac.at> WHERE { ?resource a <http://www.cidoc-crm.org/cidoc-crm/E73_Information_Object> ; crm:P2_has_type ?type .} »Ausprobieren

Metadaten zu einzelnen Ressourcen

Anhand eines zufällig ausgewählten Dokuments – D041048, einem Tagebucheintrag – soll kurz erläutert werden, welche Metadaten momentan abfragbar sind.

SELECT DISTINCT ?p WHERE { <http://bahrschnitzler.acdh.oeaw.ac.at/entity/D041048> ?p ?o . } »Ausprobieren

Diese SPARQL-Abfrage nach eindeutigen Properties zur Ressource liefert acht Werte zurück:

  1. rdf:type Typ der Entität (bei Dokumenten immer* crm:E73_Information_Object)
  2. crm:P2_has_type Klassifizierung des Dokuments (hierzu zumindest 2 Triples http://bahrschnitzler.acdh.oeaw.ac.at/type/D sowie die Unterklassifizierung)
  3. rdfs:label Menschenlesbares Label (Das Label anzusehen macht immer Sinn, wenn man rausfinden will, was sich hinter einer URI verbirgt)
  4. schema:mentions Erwähnte Entitäten
  5. crm:P1_is_identified_by Identifikator (momentan hier jedenfalls die resolvende ID zu Bahr-Schnitzler)
  6. hbasp:SortDate Sortierdatum (wenn schnell und einfach sortiert werden soll, bietet sich dieses Property an)
  7. crm:P94i_was_created_by verweist auf die Aktivität, aus der das Dokument hervorgegangen ist
  8. owl:sameAs verweist auf Datensätze zum selben Dokument

Wer hat’s geschrieben?

Die meisten Properties sind selbsterklärend bzw. erschließen sich relativ schnell, wenn man mehrere Beispieldokumente ansieht. Das oben unter Punkt 7 angeführte Property P94i_was_created_by ist allerdings kommentierungsbedürftig, weil hier der ereigniszentrierte Zugang von CIDOC deutlich wird. created by meint hier nämlich nicht den Urheber des Dokuments (wie man vielleicht vermuten könnte), sondern verweist auf eine Aktivität crm:E65_Creation aus der das Dokument hervorgegangen ist. Möchte man den Urheber anzeigen, muss man das Propery crm:P14_carried_out_by dieses Ereignisses abfragen, das auf den Urheber verweist. Den Namen des Urhebers findet man am einfachsten im rdfs:label:

SELECT ?creator ?label WHERE { <http://bahrschnitzler.acdh.oeaw.ac.at/entity/D041048> crm:P94i_was_created_by ?creation . ?creation crm:P14_carried_out_by ?creator . ?creator rdfs:label ?label . } »Ausprobieren

Analog dazu lassen sich alle Urheber von Dokumenten ausgeben:

SELECT DISTINCT ?creator ?label WHERE { ?resource a crm:E73_Information_Object ; crm:P94i_was_created_by ?creation . ?creation crm:P14_carried_out_by ?creator . ?creator rdfs:label ?label . } »Ausprobieren

Sonderfall Brief

Briefe unterscheiden sich von den übrigen Dokumenten crm:E73_Information_Object vor allem dadurch, dass neben den Informationen zu ihrer Erstellung crm:E65_Creation zusätzlich die Korrespondenzmetadaten erfasst sind – der CIDOC-Logic folgend ebenfalls als Aktivitäten and denen wiederum Akteure beteiligt waren. Dazu ein Beispiel einer Postkarte (die sich über ?resource crm:P2_has_type hbas_type:Postkarte . finden lässt). Die ID des Dokuments lautet L041524.

Gibt man nach der oben beschriebenen Methode die eindeutigen Properties aus (SELECT DISTINCT ?p WHERE { <http://bahrschnitzler.acdh.oeaw.ac.at/entity/L041524> ?p ?o . }), findet man in der Liste neben dem schon bekannten crm:P94i_was_created_by ein weiteres Property crm:P12i_was_present_at. Es verweist auf Ereignisse, bei denen irgendetwas mit dem Dokument geschehen ist. Im Datensatz sind diese Aktivitäten typisiert, weshalb es Sinn macht, zunächst die Typen abzufragen:

SELECT * WHERE { <http://bahrschnitzler.acdh.oeaw.ac.at/entity/L041524> crm:P12i_was_present_at [crm:P2_has_type ?type] . } »Ausprobieren

Bei Briefen habe ich zwei Typen von Aktivitäten hinterlegt:

  • http://bahrschnitzler.acdh.oeaw.ac.at/type/ReceivingOfLetter
  • http://bahrschnitzler.acdh.oeaw.ac.at/type/SendingOfLetter

Ähnlich wie bei den Creation-Events lassen sich auch hier die an den Aktivitäten beteiligten Personen abfragen. Zusätzlich lässt sich in Erfahrung bringen, wann und von wo aus das Korrespondenzstück abgeschickt bzw. empfangen wurde. Notwendig hierfür sind die Properties:

  • crm:P14_carried_out_by
  • crm:P7_took_place_at
  • crm:P4_has_time-span (wobei hier das Datum mit dem Property crm:P82b_end_of_the_end aus der Zeitspanne crm:E52_Time-Span extrahiert werden muss)

Informationen zum Versand der Postkarte erhält man so:

SELECT ?senderLabel ?placeLabel ?date WHERE { <http://bahrschnitzler.acdh.oeaw.ac.at/entity/L041524> crm:P12i_was_present_at ?event . ?event crm:P2_has_type <http://bahrschnitzler.acdh.oeaw.ac.at/type/SendingOfLetter> ; crm:P14_carried_out_by ?sender ; crm:P7_took_place_at ?place ; crm:P4_has_time-span ?time . ?sender rdfs:label ?senderLabel . ?place rdfs:label ?placeLabel . ?time crm:P82b_end_of_the_end ?date . } »Ausprobieren

Die Abfrage zu der Sendeaktivität ist schon relativ komplex, insbesondere auch deshalb, weil hier drei Personen beteiligt sind. Sollen die Versender für die Ausgabe gruppiert werden, muss man dazu auf SPARQL-Funktionen zurückgreifen. Dazu mehr in einem der folgenden Posts.