[Allegro] Kein Spass mit Exporten fuer Literarurverwaltungen

Mo Jul 27 16:52:35 CEST 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Eine see-also-Funktionalität scheint mir wenig sinnreich, jedenfalls
> nicht für die eigene Klientel der Bibliothek: Hat der Kunde ein Buch
> im Katalog "seiner" Bibliothek entdeckt, braucht er ja nicht noch
> anderswo danach zu suchen, etwa in KVK oder WorldCat. Für externe
> Nutzer von Spezialbibliotheken sieht's wohl etwas anders aus, aber für
> die muß sich die Bibliothek i.d.R. weniger zuständig fühlen.

"SeeAlso" ist der Name des Protokolls (falls es denn eins ist), vgl.
http://ws.gbv.de/seealso/ . Dahinter stecken unAPI (also die Bereitstellung
jeweils eines Datensatzes in einem bekanntgegebenen Format) und
openSearchSuggestions (Lieferung von mehreren alternativen URLs als
Resultat einer evtl. unvollstaendigen Eingabe).

Wenn man sich den Dienst pnd2wikipedia betrachtet, bekommt man eine
Idee vom Zusammenspiel:

http://ws.gbv.de/seealso/pnd2wikipedia/

die (mit openSearchSuggestions einher gehende) openSearchDescription

<OpenSearchDescription>
  <ShortName>PND2Wikipedia</ShortName>
  <dcterms:modified>2009-01-22</dcterms:modified>
  <dc:source>http://download.wikimedia.org</dc:source>
  <Query role="example" searchTerms="118578537" />
  <Query role="example" searchTerms="118562347" />
  <Url type="text/javascript"
template="http://ws.gbv.de/seealso/pnd2wikipedia/?id={searchTerms}&format=seealso&callback={callback}"
/>
</OpenSearchDescription>

kennt Beispiele fuer Anfragen und URL-Templates, kann jedoch nicht das Format
dokumentieren: Alles ist text/javascript.

Umgekehrt kennt die unAPI-Format-Liste keine Beispiel-Identifier, wohl aber
verschiedene Formate (die Art der Anfrage hingegen ist durch den Standard
festgelegt und muss nicht dokumentiert werden).

<formats>
<format name="seealso" type="text/javascript" />
<format name="opensearchdescription"
type="application/opensearchdescription+xml"
docs="http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_3#OpenSearch_description_document"
/>
</formats>

Inwieweit nun "SeeAlso" ein see-also realisiert, ist eine Frage des Standpunkts:
Die in Goettingen aufgelegten Dienste sind meist standalone-Anwendungen (es gibt
eine Referenz-Software von Jakob Voss auf CPAN), d.h. im Beispiel von
isbn2wikipedia wird regelmaessig der aktuelle  Wikipedia-Auszug heruntergeladen,
maschinell nach PND-Verlinkungen untersucht und daraus eine Tabelle PND-Nr.,
Wikipedia-Lemma und Wikipedia-URL erstellt und zum Zugriff unter SeeAlso online
gestellt. Wenn ich in meinem OPAC das SeeAlso-Client-Javascript einbinden lasse
und diesen Dienst zur Verlinkung auf die Wikipedia (oder anhand der ISBN
auf LibraryThing oder GoogleBookSearch nutze, ist das ziemlich deutlich
"siehe-auch").

Wenn ich aber - direkt *an* meinem Katalog - neben openSearchSuggestions auch
noch andere Formate im Kontext von SeeAlso selber bereitstelle, verschiebt sich
das Gewicht staerker zu "unAPI", also einfach eine schmerzlose Bereitstellung
alternativer Formate. In dem Fall werde ich dann natuerlich nicht im Rahmen
der OPAC-Anzeige eines vorhandenen Datensatzes mit dem SeeAlso-Client-Javascript
einen Link zum Datensatz noch einmal aus meiner Datenbank herauskitzeln[*], wohl
aber ueber die Mikroformat-Angabe <link rel="unapi-server"
type="application/xml" title="unAPI" href="http://example.com/unapi/" />
im HTML-Header die "Agenten" im Browser des Benutzers auf maschinenlesbare
Alternativen zum gerade "gesehenen" Content stupsen.

In meiner Mail von letzter Woche bin ich vor allem auf den zweiten Fall
eingegangen, d.h. aus Client-Sicht unAPI, der durch SeeAlso nur mit etwas
Selbst-Dokumentation und einer zusaetzlichen, menschenlesbaren Oberflaeche
aufgemotzt wird. Man kann natuerlich ueberlegen, ob hier auch
openSearchSuggestions als anzubietendes Format Sinn machen, genutzt wird
das ja v.a. fuer die Faelle, dass der Benutzer in einem Eingabefeld
los tippt und als Tooltip eine Menge moeglicher Vervollstaendigungen
angeboten bekommt. Ich habe das bislang noch nicht weiterverfolgt, schliesslich
erlaubt avanti keine persistenten Verbindungen, d.h. selbst wenn (HTTP 1.1)
zwischen Browser des Benutzers und Webserver die Verbindung gehalten werden
koennte, muessten fuer jedes weitere getippte Zeichen jeweils neue Instanzen
von acon hochgeschossen werden...

Den ersten Fall, also Nutzung von Web-2.0-Techniken (etwa SeeAlso) zur
fallweisen Verlinkung auf Content ausserhalb meiner Datenbank, wuerde ich
nicht so eingeschraenkt nuetzlich sehen, wie es in Ihrem Statement oben
anklingt: Zweck des Katalogs ist ja fast nirgendwo mehr ausschliesslich,
dem Benutzer zum einen und einzigen Ziel zu fuehren, naemlich der
Praesentation der Signatur des gewuenschten Titels, die er dann mit
Bleistift aufschreiben kann. Cover-Scans werden immer gerne gesehen,
sowohl allgemein- als auch Spezialbibliotheken wuerden mit Freuden Rezensionen
nachweisen (aus unterschiedlichen Quellen, mit clientel-gerechten
Warnhinweisen), und ein Link auf die Wikipedia ist selbst fuer super-
"wissenschaftliche" Spezialbibliotheken interessant, nicht unbedingt weil die
Artikel so spannend sind, sondern weil es dort oft Verweise auf diverse
Volltexte in wikisource oder digitalisierte Nachschlagwerke oder Bilder auf
wikimedia commons gibt.

Und bei zunehmender FRBRisierung koennte ich es mir fuer jede Bibliothek
spannend vorstellen, durch Verweis auf (lokal u.U. nicht vorhandene) andere
Ausgaben und Uebersetzungen dem Benutzer bei der Beurteilung zu helfen, ob er
nun wirklich "sein" Buch gefunden hat...

viele Gruesse
Thomas Berger

[*] Man sollte niemals nie sagen: Der Ausgangspunkt meiner Beschaeftigung mit
SeeAlso war folgender: HANS-Anwender wuenschten sich ein "Bestellformular"
(was das bedeutet, ist dem jeweiligen Anwender sonnenklar, ueber die breite
kann das aber die Bitte um Bereitstellung im Lesesaal zu einem bestimmten
Termin sein, oder Einsichtnahme, oder die Anforderung von Digitalisaten
fuer eine Publikation, oder gar die Frage nach im Katalog nicht findbaren
Materialien...). HANS-Anwender sind aber oft Handschriftenabteilungen innerhalb
einer sehr grossen Institution, d.h. u.a., sie haben keine eigene EDV-Abteilung,
sie haben keine eigenen Server, die Datenbank fuers WWW ist nur eine Lesekopie
des "Originals" und "das Haus" hat schon viel frueher Vorstellungen entwickelt,
wie Kontaktformulare auszusehen haben, wie Benutzer sich evtl. authentisieren
muessen und wie man ggfls. dazu steht, wenn Web-Anwendungen anfangen, Mails
zu verschicken...

Hier ist die von mir favorisierte Loesung dann tatsaechlich die folgende (vgl.
http://hansdemo.gymel.com/cgi-bin/hansdemo.pl?t_tunnel=idn&idn=b303742 ):
In den OPAC wird nur die URL einer "Bestellformular"-Anwendung
hineinkonfiguriert, dieser URL wird nur die HANS-Identnummer des gewuenschten
Datensatzes als Parameter mitgegeben. Die Zielseite kann nun gestaltet sein
wie sie will (im Demo ist es gar keine "Anwendung" sondern eine statische
HTML-Seite!) mittels des SeeAlso-Client-Javascripts rudimentaere Informationen
des Datensatzes anfordern und als Formular oder sonstwie praesentieren und
weiterschicken. Methodisch ist das ein bischen unsauber, weil die Resultate von
openSearchSuggestions gemeinhin "Alternativen" sein sollten und nicht "Aspekte"...

Jedenfalls: Hier wird ein WebService ganz gezielt eingesetzt, um innerhalb einer
grossen Institution ganz bewusst einen speziellen Katalog von der
Geschaeftsgangslogik des Gesamtauftritts abzukoppeln (die Maximen also:
Integration ins vorgegebene /Layout/ stets so weitgehend wie moeglich,
"funktionale Integration" aber durch Zwischenschaltung von Web-2.0-techniken
etwas abstrahiert)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSm2/M2ITJZieluOzAQJsOwQAt0TgJgoQnlzawbfkV9glMKXiTtX6/RLj
4qfD3YZj9bNOWsC6FW86N9kDJBMaHXWajcnkJOR3bX8SPOWEEiwFwCDSa8S8bM1P
IlJ1htDYJUxtmnta6oGlRhgZd8/HZzlvhthnu6EmTI4lbD24eVcJH+Z3DOk9nndL
shFzSxG90wg=
=bfXC
-----END PGP SIGNATURE-----