[Allegro] GND- und Titeldaten der DNB zum Download

[Thomas Berger]

Lieber Herr Skalweit, lieber Herr Eversberg, liebe Liste,

Am 06.06.2012 23:09, schrieb Kai Skalweit:
> Am Wed, 06 Jun 2012 09:07:35 +0200, schrieb Bernhard Eversberg:
> 
>> authority control", und in Minutenschnelle sind 10 Mio. Daten
>> indexiert, hört hört! Allein das Umwandeln mit IMPORT würde doch
>> ein paar Viertelstunden länger brauchen...
> 
> Ist mir auch nicht so klar, welchen Zauberrechner 
> man dort im Auge hat. Das Produktivsystem kann es 
> wohl nicht sein ... oder halt, vielleicht kommen 
> die ZDB-Ausfaelle ... ;-)

Erwaehnt wurde "Elasticsearch" (< http://www.elasticsearch.org/ >),
das scheint mir eine spezielle Engine fuer OpenSearchSuggestions
oder etwas in die Richtung zu sein.

An der Eingabemaske von VIAF < http://viaf.org > kann man erkennen, dass
man mit solchen Search Suggestions allerhand von dem abdecken
kann, wofuer man in Bibliotheken browsable Indizes vorhalten kann:
Ich tippe etwas ein, was ich fuer die Ansetzung halte, im
Fensterchen werden mir damit uebereinstimmende, existierende
Indexate gezeigt, ich sehe waehrend des Tippens, wo sich weiters
Ausformulieren etwa des Vornamens gar nicht lohnt und kann dann,
ohne die eigentliche Suche abgeschickt zu haben - meinen Suchbegriff
revidieren.

Und ich kann nicht angesetzte Dinge (etwa Vornname Jahreszahl)
recherchieren, dahinter duerfte dieselbe Search Engine stecken,
die Search Suggestions liefern dann erst einmal nichts (obwohl
sich vermutlich auch das einstellen liesse).

D.h. Ansetzungen und Verweise durchaus isoliert voneinander in
einem grossen und schnellen Suchindex zu haben, /ist/ anwendungs-
traechtig.


>> Ob wir in unsrem Kontext damit was anfangen könnten? Das nun
>> freigegebene Format ist noch mal was ganz anderes, kein MARC
>> und kein MAB, sondern RDF in der sog. Turtle-Notation (die braucht
>> etwas weniger Platz), XML-codiert und mit allerhand neuen Bezeichnungen
>> statt Kategorienummern, hier mal ein Beispiel:
>>
>> <http://d-nb.info/gnd/7505786-4>
>>       a       gnd:SubjectHeading ;
>>       gnd:complexSeeReferenceSubject
>>               <http://d-nb.info/gnd/4039634-4> , 
>> <http://d-nb.info/gnd/4309802-2> ;
>>       gnd:geographicAreaCode
>>
>> <http://d-nb.info/standards/vocab/gnd/geographic-area-code#XA> ;
>>       gnd:gndIdentifier "7505786-4" ;
>>       gnd:gndSubjectCategory
>>               <http://d-nb.info/vocab/gnd-sc#10.2ea> , 
>> <http://d-nb.info/vocab/gnd-sc#10.9a> , 
>> <http://d-nb.info/vocab/gnd-sc#10.4> ;
>>       gnd:oldAuthorityNumber
>>               "(DE-588c)4273804-0" , "(DE-588c)7505786-4" ;
>>       gnd:preferredNameForTheCorporateBody
>>               "Europäische Gemeinschaften / Wirtschaftsunion / 
>> Währungsunion" .
> 
> Wir reden also von diesem Satz, den ich auf die in der 
> "modernen" Version dargestellten Inhalte gekuerzt habe:
> |001 	|a (DE-588)7505786-4
> |024 	|a http://d-nb.info/gnd/7505786-4
> |035 	|a (DE-588)7505786-4
> |039 	|a (DE-588c)4273804-0
> |039 	|a (DE-588c)7505786-4 |v zg
> |043 	|a XA
> |065 	|a 10.4 |a 10.9a |a 10.2ea
> |110 	|k Europäische Gemeinschaften |x Wirtschaftsunion |x Währungsunion
> 
> Man muesste mir (nochmal) den Unterschied zu erklaeren 
> versuchen im Hinblick auf maschinelle Verarbeitbarkeit 
> und menschliche Lesbarkeit und Laenge des kategorien-
> strukturierten Datensatzes.
> 
> Insbesondere fehlen diese Kategorien:
> |260 	|a Europäische Gemeinschaften |9 (DE-588)4039634-4
> |260 	|a Wirtschafts- und Währungsunion |9 (DE-588)4309802-2
> |670 	|a EG-Vertrag (EGV), Gabler (13. Aufl.) unter Europäische Union
> |680 	|a Benutzt für zusammenfassende Darstellungen der Errichtung der Wirtschafts- und Währungsunion der EG, soweit aus der Sicht vor Inkrafttreten der Europäischen Union behandelt. Ab 1.11.1993 benutze die Verknüpfung Europäische Union ; Wirtschafts- und Währungsunion.
> 
> 260 sind in GND-MAB die Hinweissaetze zum Schlagwort.

Die waren schon in MAB kaum verstaendlich und sind in der GND
weitgehend abgeschafft. Gemeint ist hier, dass man in MAB 9xx der
Titel NICHT die Pseudo-Ansetzungsfolge
Europäische Gemeinschaften |x Wirtschaftsunion |x Währungsunion
verwenden DARF, sondern mit der Kombination der Einzelbegriffe
|s Europäische Gemeinschaften |9 (DE-588)4039634-4
|s Wirtschafts- und Währungsunion |9 (DE-588)4309802-2
...
verwenden MUSS. Das ist in diesem Kontext also ein aeusserst
schlechtes Beispiel.


> Ob es wirklich Sinn macht, diese reduzierten Daten fuer 
> eine aktive Katalogisierung zu verwenden, bezweifle ich.
> 
> Ob es Sinn macht, sie extra/gesondert fuer den Opac auf-
> zubereiten? Sie muessten etwas haben, was nicht aus den 
> eigentlichen GND-Daten erstellt werden kann - und das 
> kann ich auf den ersten Blick nicht erkennen.

Die RDF-Dumps sind nicht fuer den Import in Bibliothekssysteme
gedacht, ich weiss nicht, wie das so verstanden werden konnte.
Ich halte es auch fuer extrem schwierig (oder zumindest aufwendig),
solche RDF-typisch in Einzelaussagen zerlegten Informationen
zu einem anzeigbaren "Datensatz" zu rekonstruieren (bei den RDF-MAB
Daten der HBZ LOD Exporte (< http://www.lobid.org/ >) ist das noch
trivial, werden aber Anstrengungen unternommen, das wirklich
semantisch und unter Nutzung "fremder" Ontologien zu machen,
ist es mindestens so kompliziert wie der Versuch, aus MODS
MARCXML herzustellen...

Typische OPACs sind allerdings weitestgehend Normdatenfrei,
da kann natuerlich alles eine Verbesserung bringen...



>> Das ließe sich relativ leicht importieren, aber ob das *Sinn* ergäbe?
>> (Unsere GND-MARC-Umwandlung ist ja nun wohl schon wieder obsolet!?)
>> Sondern besser statt dessen eine Suchmaschine oder sog. "triple store"
>> aufsetzen und diesen dann zum Suchen und Ermitteln der richtigen
>> Namen und Schlagwörter nutzen? Denn was wir auf dem Gebiet so machen,
>> wird ja wohl langsam doch altmodisch.

Bei VuFind und anderen (m.E. zu stark) auf Bibliotheken getrimmten
"Discovery Interfaces" ist das noch ein Nadeloehr: Man hat eine
recht neutrale und extrem maechtige Indexierungsmaschine mit einem
Nadeloehr als Aufsatz versehen: Daten muessen nach ISO 2709-MARC21
gewandelt werden, damit das Discovery Interface die einlesen kann,
das macht nichts anderes als die zu fleddern (wenn Lucene: Vermutlich
in eine schwach strukturierte XML-Form) und auf Suchindizes zu
verteilen.

Auch VuFind ist nicht angetreten, alle Funktionen von ILS zu
uebernehmen, "altmodisch" waere hoechstens ein Standpunkt, das
als Uebergangszeit zu betrachten, bis die etablierten
Bibliothekssysteme da irgendwie aufholen und auch diese
Funktionalitaet absorbieren.


> Vielleicht ist das die Grenze: Der Normdatensatz 
> selbst ist im lokalen Katalog und kann dem Benutzer 
> angezeigt werden. Die Verlinkungen in der Normdaten-
> anzeige fuehren nach Frankfurt, damit der Benutzer 
> dort in den Normdaten blaettern kann - aber: will 
> er das? Vielleicht moechte er ja auch nur die Medien 
> zur Vorgaenger-Koerperschaft meiner Bibliothek.
> Wie bekomme ich ihn hinterher aus Frankfurt wieder 
> zurueck in den eigenen Opac?

Auch bei der Fernleihe ist es so, dass man zuerst anhand
des eigenen Katalogs ueberprueft, ob es da was gibt und
erst dann den Benutzer auf die Reise schickt (und zwar
durchaus gezielt).

Ein triviales Beispiel (eine "normale" Fehlerseite hat eine
weniger bedrohliche Ueberschrift bekommen und wurde um ein
Mashup angereichert) sieht man hier:

http://evb.online.uni-marburg.de/cgi-bin/evb?t_idn=pnd:101219373X

Der Link "Georgios <Hellas, Basileus, I.>" fuehrt auf:

http://evb.online.uni-marburg.de/cgi-bin/evb?t_idn=pnd102300186


Nach traditionellem Verstaendnis duerfen Normdaten zwar in
einen Katalog hinein, haben dort aber nur ganz diskret zu
wirken (etwa durch Bereitstellung von x Alternativeinstiegen
in Registern, oder durch Verflechtung von Registern mit
Verweisen), Anzeige von Normdatensaetzen hingegen war lange
Zeit gaenzlich unerwuenscht (die Normdatei ist kein Lexikon).

Und in der Anzeige von Titeldaten werden die angesetzten
Elemente (beteiligte Personen und Koerperschaften) auch
gerne unterdrueckt, z.B. wenn man eine Verfasserangabe
in Vorlageform hat. Die hat aber den Nachteil, dass man darin
die Zeichenketten, die eine gewisse Person betreffen, bei
der Katalogisierung nicht isoliert identifiziert hat, die
Vorlageform hilft also nicht beim Navigieren, nicht einmal zu
anderen Titeln.

Akzeptiert man aber die Sicht, dass eine Recherche in einem
Bibliothekskatalog *nicht* der Endpunkt jeglicher Internet-
aktivitaet eines Benutzers ist (und "die" Titelvollanzeige
sozusagen das Ende vom Ende wonach er dann nur noch vom
Stuhl aufspringen kann um eilenden Schritts zur Bibliothek
zu gelangen), sondern auch Ausgangspunkt fuer weiterfuehrende
Recherchen darstellen kann, dann wird auch die Anzeige von
Normsaetzen interessant, denn zumindest derzeit kann man
im Rahmen einer Titelvollanzeige die beteiligten Personen nur
kurz auffuehren, denn wuerde man zu jeder davon 50 weiterfuehrende
Links einblenden, waere die Titelaufnahme nicht mehr zu
entdecken. Und als Zwischenstation ganz im FISO-Sinn ist die
im Normsatz enthaltene minimale Erzaehlung dem Benutzer eigentlich
genau so nuetzlich wie bislang dem Bibliothekar: Bevor man sich
in Abenteuern verzettelt kann man kurz innehalten und verifizieren,
ob es sich anhand der Lebensdaten und Taetigkeiten etc. wirklich
um die oder eine Person handelt, die momentan interessiert.

Ich sehe die record-orientierten Bibliotheksdaten (Titel- und
Normsaetze) wirklich gerne als "Erzaehlung" bzw. semi-
strukturierte Texte, die gut in XML transportiert werden koennen
(gerne auch mit weniger Elementen und mehr Attributen), die
"harten Fakten", die sich da herausdestillieren lassen, koennen
wiederum gut in RDF abgebildet werden. Beispiele dafuer sind
die erwaehnten angesetzten bzw. parallel dazu als Vorlageform
transkribierten Informationen zu Personen oder bei Normdaten
folgendes Beispiel: Je genauer man sein will, umso mehr muss
man auf die natuerliche Sprache zurueckgreifen, um etwa aus-
zudruecken wann Beethoven geboren wurde:

Die Anzeige von http://d-nb.info/gnd/118508288 sagt nur
lapidar
Lebensdaten: 1770-1827
hinterlegt sind jedoch auch die exakten Lebensdaten, die als
"unnormiert" gelten:

    <datafield tag="548" ind1=" " ind2=" ">
      <subfield code="a">17.12.1770-26.03.1827</subfield>
      <subfield code="9">4:datx</subfield>
      <subfield code="w">r</subfield>
      <subfield code="i">Exakte Lebensdaten</subfield>
      <subfield code="9">v:Datum der Taufe</subfield>
    </datafield>

(Als Menschen koennen wir uns zusammenreimen, dass sich der Kommentar
in $9v auf das erste der angegebenen Daten bezieht und dass er also
"vor 1770-12-17" oder zumindest "nicht nach 1770-12-17" geboren ist,
was ja immerhin spezifischer ist als "ca. 1770-12-17" ...)

[der verlinkte Wikipedia-Artikel formuliert:
"Ludwig van Beethoven (getauft 17. Dezember 1770 in Bonn, Kurköln; † 26. März
1827 in Wien, Kaisertum Österreich)"]

Der RDF-Export enthaelt:

<gnd:dateOfBirth>1770</gnd:dateOfBirth>
<gnd:dateOfDeath>1827</gnd:dateOfDeath>

das ist fuer Zwecke der Vergleichbarkeit oder Recherchierbarkeit biographischer
Daten in den meisten Kontexten ausreichend (man gehe nur wenige Jahre weiter
zurueck und ist mitten in der vielhundertjaehrigen Uebergangszeit zwischen
Julianischem und Gregorianischem Kalender oder noch etwas weiter wird die
Nachweislage manchmal so schlecht, dass man nur Tag und Monat, aber nicht
das Jahr kennt: Da wird es umso wichtiger, *alles* anzugeben, was sich
ermitteln laesst und gleichzeitig aussichtsloser, das irgendwie normieren
zu wollen).

RDF entwickelt dann seine Staerke, wenn entsprechende Systeme aus den
normierten "1770" und "Bonn" maschinell schliessen koennen, dass der
zugehoerige Staat damals Kurkoeln (bzw. in der GND: Koeln <Hochstift> bzw.
Koeln <Staat>) gewesen ist: Dafuer reichen dann die Normdaten alleine
nicht aus und man muss die daraus extrahierten Informationen mit denen
aus weiteren Thesauri etc. zusammenbringen: Schlimm, wenn man die erst
einmal alle in ein Bibliothekssytem pruegeln muesste um dann doch an
der Aufgabe zu scheitern...


viele Gruesse
Thomas Berger