[Allegro] Vb.256 Addendum: SRU-Datenabruf vom GBV

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Nun wird diese Sache ganz anders gelöst, und zwar mit Hilfe
> der Indexparameter, in denen ja die Umlaute aufgeloest und Akzente
> eliminiert werden. Die Umcodierung nutzt man mit dem Befehl  xcode iq
> oder xcode ip, d.h. mittels der q-Befehle bzw. p-Befehle. Vorzugsweise
> sollen diejenigen genommen werden, die den Text in Kleinbuchstaben

...

Im Prinzip ist auch das recht krueckig, denn es wird ein Web- (genauer
HTTP-)Zugriff durchgefuehrt, und wie nicht-7-bit-Zeichen fuer URLs
zuverlaessig codiert werden koennen (und sollen) ist seit einigen
Jahren (etwa korreliert mit dem Aufkommen von HTML 4) gluecklicherweise
geregelt und hat sich auch schon durchgesetzt (Ausnahme: Gewisse
Voreinstellungen in Windows XP, wohl seinerzeit mit Ruecksicht auf
richtig alte SharePoint-Anwendungen abweichend gesetzt).

Auch a99 kann einen Text in der iV in "Unicode" wandeln, also als
UTF-8 codieren, es fehlt allerdings noch ein internes Kommando, um
dann auf Byte(!)-Ebene die Sonder- und Nicht-ASCII-Zeichen zu
escapen.


> Im Prinzip und ganz allgemein, das wollen wir nicht beschönigen,
> sind diese FLEXe keine saubere Sache und mit Vorsicht zu genießen!
> Wobei der Akzent auf "genießen" liegen mag, aber man sollte wissen:
> Sie fußen auf zwei total verschiedenen Datenstrukturen, die keinerlei
> Standard sind und die in Frankfurt bzw. Göttingen jederzeit geändert
> werden könnten - und schon guckt man in die Röhre.

Nutzt der srugbv.flx nicht SRU? Dann sollte doch das Antwortformat
ein definiertes XML-Format sein, in das die eigentlichen Metadaten
in einem "ueblichen" bibliothekarischen XML-Format eingebettet sind.
Oder gibt es da ein Aequivalent zu SUTRS bzw. der Flex besteht auf
PICAXML?



> ZACK-Daten, auf die man jederzeit rekurrieren kann, sind eine andere
> Kategorie, weil sie auf standardisierten Datenstrukturen fußen (MAB2).
> ZACK ist nur ein wenig umständlicher in der Nutzung, bietet aber
> noch viel mehr Quellen zur Auswahl:
> 
>   http://opus.tu-bs.de/zack/       Startseite
> 
>   http://z3950.de/zack/help.html   Hilfe, und Liste der Quellen

Und: Die DNB bietet direkten Download in MARC21-XML an, allerdings
mit Moving Wall (/Titel/aufnahmen aus dem aktuellen und vorigem
Kalenderjahr sind vom Download ausgeschlossen).

Etwas ausholend: Ich fand immer, dass auch eine kleine Bibliothek
durchaus einen eigenen Katalog haben darf, die Titel stehen dort
in einem Bestandskontext, der bei Integration der Daten in
groessere Zusammenhaenge (Verbuende oder verteilte Suchen aber etwa
auch die "Sicht" auf Daten, die Literaturverwaltungsprogramme bieten)
nivelliert wird. Das betrifft die Darstellung (spezielle Verschlagwortung)
aber auch die Recherche als solche (Sonderregister etc.). Natuerlich
kennt niemand /alle/ kleinen Bibliotheken oder will deren Kataloge alle
abklappern (und deren Bedienung lernen) bzw. hat recht allgemeingueltige
Fragestellungen, die der "known-item-search" nahe kommen (wie hier: "Wer
hat etwas zur folgenden ISBN?"), d.h. Aggregation in Verbund- oder
Metakatalogen macht durchaus Sinn. Eine runde Sache wird das aber erst,
wenn die dann dem Recherchierenden einen Rekurs auf den Originalkatalog
ermoeglichen. Optimal ist es dann, wenn man aus dem Heimatkatalog der
Daten heraus dann tatsaechlich an die Daten "als Daten" kommen kann
("Download this record" oder eingebettes COiNS fuer Literaturverwaltungen,
oder unAPI-Funktionen oder ...).

Umgekehrt: Selbst ISBN-Suchen, selbst wenn sie eingeschraenkt auf
einen "realen" Katalog wie den der DNB oder des GBV durchgefuehrt
werden, sind nicht unbedingt nur mit "Ja, hier ist *der* Datensatz"
bzw. "Nein, sorry, habe ich nicht" beantwortbar. Der Originalkatalog
(oder auch eine auf "Dubletten" vorbereitete Spezialsuchmaschine
wie ZACK) hat u.U. Wissen eingebaut (DNB: "Verlagsmeldung", GBV:
???, Besitzangaben, ...) Mehrfachtreffer so zu praesentieren, dass
man Unterschiede sehen und eine Entscheidung fuer einen davon
treffen kann. Beim Zugriff ueber standardisierte Rechercheinterfaces
wie Z39.50 oder SRU mit standardisierten Antwortformaten faellt diese
Aufgabe an das recherchierende System, das daher Mehrfachtreffer etc.
geeignet aufbereitet zur Entscheidung praesentieren muss. Im
Endeffekt muss also im Client Funktionalitaet nachgebildet werden,
die die native Rechercheoberflaeche des Zielsystems bereits besitzt.

Solange also nicht der srugbv.flx wesentliche Funktionalitaeten
des GBV-Verbundkatalogs quasi nebenher nachbaut, halte ich Loesungen
wie ZACK mit dem Prinzip "Recherchieren, Auswaehlen, Downloaden"
fuer dem Ansatz "Fremddatenrecherche integriert in Bibliothekssystem"
fuer ueberlegen.

ZACK bietet uebrigens unter < http://z3950.de/zack/opensearch.html >
(zugaenglich ueber den "Tools"-Link < http://z3950.de/zack/cgi.html >)
Search-Plugins fuer den Browser: Damit kann man dann z.B. bereits
im Browser eine "interessante" ISBN markieren und mit Kontextmenue
oder Maus-Gesten eine ZACK-Recherche ausloesen (und man kann eine
ISBN natuerlich auch ganz klassisch in das Suchfeld im Browser kopieren).
Man sieht: Je nach Ausgangslage kann es bereits ein Umweg sein,
die Recherche nach Fremddaten aus dem Biblitohekssystem heraus
auszuloesen!


> Sinnvoll wäre es, nur können wir das hier nicht leisten, wenn jemand
> eine saubere XSLT-Lösung erarbeitete, die dann mittels externem,
> von a99 aufzurufendem Programm arbeitete, welches die Daten besorgen,
> umwandeln und mundgerecht für a99 bereitstellen würde. (z39.dll ist
> auch so etwas, nur ohne  XSLT, aber mit MARC21 als Format; es tut die
> Arbeit hinter dem zc.flx).
> Momentan vielleicht sollte man abwarten, bis BIBFRAME kommt!

D.h. MARC21 ueberspringen?

Attraktiv waere Download von ZDB-(Titel)Daten, die sind ueber SRU frei
zugaenglich (im DNB-Portal sind sie auch nachgewiesen, aber "geheim",
d.h. ohne ZDB-Nummer, das hat dann nicht so viel Wert). So eine
XSLT-Loesung, wie sie mir vorschwebt (weil ich das fuer Normdaten so
mache), ist aber auch nur ein kleines Stueck "Glue", das die Original-
MAB- oder MARC-XML-Daten in ein "gefeldertes Textformat" a la MAB-
Diskette, allegro-Externformat, oder ZACK-Downloads umwandelt, darauf
wird dann eine (kaum modifizierte) Schnittstelle fuer dieses Format
angewendet. Und daran hapert es speziell fuer das A-Format: DNB-
Daten in MAB gibt es schon nicht mehr, und auch die ZDB-(Titel-)Daten
sehen in MARC21 schon recht vernuenftig aus. Nur haben wir leider noch
keine vernuenftigen MARC21-unter-Beruecksichtigung-der-D-A-CH-Anwendungsschicht-
Schnittstellen fuer den Datenimport...

viele Gruesse
Thomas Berger