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