[Allegro] Webservices im allegro-Katalog

[Thomas Berger]

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

Liebe Liste,

hier eine Ausarbeitung zu dem Teil meines Vortrags letzte Woche, der dem Titel
entsprach. [In eckigen Klammern wieder das ungesagte.]

Die im Vortrag gezeigten Beispiele (deren Links im folgenden angegeben werden)
sind jeweils mit populo realisierte Datenbanken, das liegt aber nur an meinen
persoenlichen Praeferenzen. Und gerade Webservices sind ja wesenhaft nicht fuer
sich alleine nutzbar [vgl. aber das etwas verwandte Thema der "Search Plugins"]
sondern werden an vorhandene Anwendungen "angeflanscht".
[Sobald man allerdings in einem Katalog mehrere (evtl. sogar aehnliche)
Webservices anbindet, oder denselben Service nach und nach in verschiedene
(evtl. sogar aehnlich realisierte) Kataloge, entsteht [seitens des
Programmierers] das Beduerfnis, die Funktionalitaet nicht immer "adhoc"
einzubasteln, sondern etwas universelleres zu basteln, das sich dann (auch durch
den End-Admin) einfach an- und abschalten bzw. auch konfigurieren laesst:
Webservices sind typischerweise nicht unter der eigenen Kontrolle, sie entstehen
neu, ziehen um, veroeden, werden unbeliebt etc. Nutzung von Webservices faellt
also eher in dieselbe Klasse von "Konfiguration" wie etwa auch die Praesentation
der Kontaktadresse an der Katalogoberflaeche: Die Einstellungen haben
typischerweise eine lange Lebensdauer, wenn sie aber geaendert werden, sollte
man nicht aufs naechst "Softwarerelease" warten muessen. Hier ist dann die
Bruecke dieses Vortragsteils zu den gestrigen Ueberlegungen zum OPAC-"Design"
geschlagen (<
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2009-November/030465.html
>): Selbst die einfachsten Verlinkungen erfordern letztendlich immer irgendeine
Form von "Plan", wie sie in der eigenen Anwendung pflegbar oder konfigurierbar
gemacht werden koennen. So ein "Plan" /kann/ allerdings erst nachtraeglich
entstehen, gerade im "Web"-Bereich entstehen ja zuerst interessante Dienste und
Anwendungen, nach einiger Zeit wird dann eine Normierung versucht, etwa durch
Schaffen von Spezifikationen. Insofern will ich auch niemandem vom
Experimentieren abhalten, sondern nur auf die uebliche "Komplexitaetsfalle"
aufmerksam machen, die sich auftut, wenn man zu lange unhinterfragt einfach
akkumuliert]

Wir hatten ja in beiden Tagen des Expertentreffens schon haeufig mit "Web 2.0"
und "AJAX" zu tun gehabt. Terminologisch habe ich meine Hausaufgaben [immer]
noch nicht gemacht, es geht aber um folgendes, das seit einigen Jahren
zuverlaessig moeglich ist, weil

a) alle Browser seit einigen Jahren (u.a.?) dem DOM (Document Object Model)
folgen (ohne das m.W. die Cascading Style Sheets (CSS) gar nicht moeglich sind),
und dies ueber Javascript auch weitestgehend einheitlich manipulierbar ist,
zumindest was das Einsetzen von Inhalten in vorbereitete Container angeht und
das anschliessende Sichtbarmachen derselben, wenn sie etwa inital ueber CSS
unsichtbar gemacht waren) [ich habe den Eindruck, dass gewisse "DOM-Methoden"
auch dann noch funktionieren, wenn in Browsern JavaScript deaktiviert ist.
Benutzbarkeit (von Kernfunktionen) "ohne" JavaScript ist immer noch ein
wichtiges Ziel, sollte aber nicht dazu fuehren, dass man alle Entwicklungen
seit 1996 negiert, weil sie "mit JavaScript" besser funktionieren als ohne]

und
b) moderne Browser die Moeglichkeit haben (ueber das weitgehend standardisierte
XMLHttpRequest-Objekt (cf. < http://de.wikipedia.org/wiki/XMLHttpRequest >),
"unsichtbare" Web-Zugriffe zu veranstalten, d.h. unter Kontrolle von JavaScript
Daten irgendwo anzufordern und das Resultat zu verarbeiten, ohne dass unbedingt
und automatisch sofort die aktuell angezeigte Seite ganz oder in Teilen
durch diese Daten ersetzt wuerde.

Ich habe dann im folgenden anhand der HANS-Demodatenbank

http://hansdemo.gymel.com/cgi-bin/hansdemo.pl?t_tunnel=idn&idn=info%3Aofi%2Fnam%3Ainfo%3Aoai%3Agymel.com%3Ahansdemo%3Ahttp%3A%2F%2Fd-nb.info%2Fgnd%2F118563394
[oder kuerzer:
http://hansdemo.gymel.com/cgi-bin/hansdemo.pl?t_tunnel=idn&idn=pnd118563394 ]

zunaechst darauf hingewiesen, dass sich in allegro wegen der v14-Verknuepfungs-
techniken hervorragende, aber leider bibliotheksferne (weil von PICA3, MAB,
MARC, ... nicht unterstuetzt) Moeglichkeiten fuer echten Hypertext bieten, weil
sich Normdatenverknuepfungen an beliebiger Stelle in Freitextberschreibungen
einbinden lassen (im Beispiel das Feld "persoenliche Beziehungen", hier handelt
es sich um eine Anreicherung eines ansosnten "echten" PND-Satzes). Wenn man
ueberregionale Normdaten-Nummern in der eigenen Datenbank hat, gibt es seit
Anfang 2008 die Moeglichkeit, auf das Normdatenportal der Deutschen
Nationalbibliothek zu verlinken, im Beispiel fuehrt die als Link ausgelegte
PND-Nummer auf die Adresse < http://d-nb.info/gnd/118563394 >. [Wenn man
es etwas pathetisch ausdruecken will: Datenbanken, die konsequent auf die
(ggfls. zusaetzliche) Erfassung ueberregionaler Nummern (Normdaten, ZDB, ...,
das war ja teilweise bereits in den fruehen 90er-Jahren elektronisch verfuegbar)
gesetzt haben, koennen allmaehlich die Ernte einfahren]

Das hat noch nichts mit Webservices oder Web 2.0 zu tun, denn wenn ich eine
Normdatenidentifikationsnummer habe, besteht kein Zweifel darueber, das es einen
Normdatensatz mit dieser Nummer gibt (oder zumindest gegeben hat, das
Normdatenportal < http://d-nb.info/ > weist aber auch "historische" Nummern
[seit etwa 2001 entfallende, fruehere sind wirlich weg] nach) und es ist "nur"
noch die Frage, ob es eine Verlinkungsmoeglichkeit anhand dieser Nummer gibt.
Es hat an dieser Stelle aber in den letzten Jahren einen ganz fundamentalen
Umschwung gegeben: Normdaten in Katalogen duerfen nicht nur als unsichtbare
Helfer im Hintergrund Verweise liefern, sondern werden gezeigt, Normdatennummern
(je persistenter und globaler, desto besser) werden erkannt als Vehikel fuer
"persistente Adressierung" und die Kataloge oeffnen sich (technologisch, durch
Ueberwindung des Sitzungskonzepts etwa) einer Verlinkung von "aussen"
[angefangen hat das bei "wichtigen" Datenbanken bereits Ende 2000 oder 2001 mit
dem ZDB-OPAC < http://zdb-opac.de >]. D.h. jetzt kann man - anders als noch vor
zwei Jahren - mit/anhand der Normdatennummer auf etwas interessantes Verlinken
(obwohl die DB ihr seinerzeit abgegebenes Versprechen noch nicht eingeloest hat,
ausgehend vom Portal auf weitere Inhalte zur Person zu verlinken, etwa auf
digitalisierte biographische Nachschlagewerke).

Ebenfalls noch nicht Web 2.0 oder "Webservices" sind Techniken, die Graphiken
benutzen, etwa das Einblenden von Cover-Scans (Bsp. nun gefunden: <
http://capdemo.gymel.com/cgi-bin/capdemo.pl?t_idn=004793 >, oder die "Ampeln"
von EZB oder des neuen, gemeinsamen Dienstes "Journals Online & Print" von ZDB
und EZB [nicht gezeigt: <
http://www.kubikat.org/ mrbh-cgi/test/testvbd_en?t_idn=u249660m > [bitte ein
Spatium in der URL entfernen], die "Test"-Version des Kubikat wegen der den
Benutzern in der Produktions-Version nicht zugemutbaren "Doppelampel" zu
EZB bzw. JOP]:
Graphiken in einer Webseite sind ja [i.d.R.] nicht als binaere Bilddaten in
den HTML-Quellcode eingebettet, sondern sie werden als IMG-Objekt nur
referenziert. D.h. hier ist HTML schon seit seinen aeltesten Version
/asynchron/: Zuerst wird die HTML-Seite an den Browser des Benutzers
uebertragen, dort wird sie angezeigt und anschliessend/waehrenddessen erst die
Bilder von ihren jeweiligen Web-Adressen angefordert und in die Bilddaten in die
Seite eingesetzt [oder auch nicht: Der Browser entscheidet, ob er Graphiken
brauchen kann oder will]. Cover- und Ampeldienste sind nun so eingestellt, dass
sie bei einer Anfrage (typischerweise nach ISBN, ISSN oder ZDB-Nummer) /stets/
ein Bild zurueckliefern, entweder das zur Anfrage passende, oder aber (bei
Nichtverfuegbarkeit o.ae.) anstatt einer Fehlermeldung ein "unsichtbares" (1x1
Pixel transparent). Der Katalog muss also nicht selbst wissen, ob ein Cover-Scan
verfuegbar ist, oder eine Zeitschrift (von der IP-Adresse des Benutzers aus) im
Volltext zugaenglich, er formuliert anhand eines ~hinreichend globalen~
Identifiers die Verlinkung auf die Graphik, der Browser des Benutzers erst ruft
diese Graphik ab und blendet das Bild in das Ergebnis ein (aufgrund der
Beschaffenheit des Dienstes wiederum ohne elaborierte Mechanismen, harte
Fehler bzw. zerbrochene Links abfangen zu muessen), und wirklich erst das /Auge/
des Betrachters kann erkennen, wie es um die Verfuegbarkeit bestellt ist.
[Das ist der Preis dabei bzw. bereits etwas Web2.0-typisch: Es gibt hier nicht
den allwissenden Katalog bzw. Serverprozess, der alle Daten hat und dem Benutzer
die Krumen zuwirft, sondern es wird wirklich nur vorbereitet, dass Information
aus diversen Quellen beim Benutzer praktisch gleichzeitig zusammenlaufen wird]

(Es folgte dann eine Diskussion ueber Coverdienste, LibraryThing hat ca.
1.000.000 von den eigenen Benutzern generiert und hochgeladene und damit
zunaechst [nur nach US-Recht?] freie Cover-Abbildungen, die anhand der ISBN
abgerufen werden koennen. Amazon, Lehmanns, OCLC haben wesentlich mehr, deren
Nutzung ist aber an Lizenzbedingungen geknuepft, ansonsten existiert auch noch
ein kommerzieller Markt von Lieferanten / Verfuegbar-Machern von Coverscans).

Drittens habe ich dann echte[?] Web2.0-Services [FN: mir sind diese
Attributierungen herzlich egal, "State of the Art" genuegt eigentlich. Wg.
(diesmal: Bibliothek) "2.0" steht in einem recht aktuellen Bibliotheks-
dienst[!]-Artikel von Anne Christensen kompakt viel Nuetzliches: <
http://www.zlb.de/aktivitaeten/bd_neu/heftinhalte2009/Erschliessung010509BD.pdf
>] gezeigt, allerdings ausschliesslich die experimentellen "SeeAlso"-Dienste von
Jakob Voss bei der GBV-Verbundzentrale: < http://ws.gbv.de/seealso/services/ >
[zum SeeAlso-Protokoll vgl. etwa < http://ws.gbv.de/seealso/ > als Startpunkt].
So werden im HANS-Beispiel oben anhand der PND-Nummer asynchron (daher
erscheinen die Links auch erst einige Zeit nach dem Laden der Seite) Links auf
die Wikipedia und (u.a.) VIAF eingeblendet: Der eigene Katalog veranlasst
hierbei den Browser des Benutzers, bei einem SeeAlso-Dienst in Goettingen
nachzufragen, ob und wie es eine Verlinkungsmoeglichkeit vom aktuell gezeigten
Normsatz in die Wikipedia gibt. Auf dieselbe Art werden etwa vom Capriccio-
Demokatalog < http://capdemo.gymel.com/ > anhand von ISBNs SeeAlso-Anfragen
veranlasst, die zu evtl. sogar mehreren Wikipedia-Artikeln fuehren koennen, wo
dieser Titel im bibliographischem Apparat angefuehrt wird, oder zum Nachweis in
LibraryThing [interessant, weil es einer dieser "sozialen" Dienste ist, aber
auch, weil hier konsequent an der Gruppierung nach Werken gearbeitet wird,
d.h. hier ist viel staerker FRBRisiert als in den meisten Bibliothekskatalogen].

Inhaltlich hat die Wikipedia-Verlinkung uebrigens einen Wert, der weit ueber
den zunaechst angebotenen Lexikonartikel zur Person hinausgeht: Denn an diesen
wiederum angebunden sind oft weitere Online-Quellen, z.B. grosse Sammlungen
digitalisierter Mateiralien in Wikisource oder die - beim DNB-Portal vermissten
- - gezielten Links auf die ADB (Allgemeine Deutsche Biographie).

Die SeeAlso-Dienste sind besonders elegant und leicht zu nutzen, weil es quasi
"herstellerseitig" direkt ein Skript seealso.js gibt (Dokumentation unter <
http://ws.gbv.de/seealso/javascript-client/ >), das man in die eigenen Katalog-
seiten einbindet. Dazu kommen wenige Zeilen "Konfiguration" (man muss die
Adressen der SeeAlso-Services deklarieren, die man benutzen wird, sowie jeweils
ein Kuerzel hierfuer benennen) sowie eine denkbar kurze Verankerung der
Platzhalter in der HTML-Seite, etwa

<div class="seealso-container" style="display: none;">Erwaehnt in wikipedia.de:
 <span title="3-473-51005-x" class="isbn2wikipedia seealso-csv"></span>
</div>

Das Span-Element wird vom Skript anhand des Class-Attributes identifiziert,
"isbn2wikipedia" ist ein Kuerzel fuer den eingangs deklarierten Dienst, der mit
dem einzigen, dem title-Attribut zu entnehmenden Argument abgefragt wird, das
Resultat wird auf eine gewisse (durch "seealso-csv" spezifizierte) Art
aufbereitet und anstelle des Span-Elements in die Seite eingesetzt,
abschliessend wird (bei Erfolg) das uebergeordnete, durch "seealso-container"
gekennzeichnete HTML-Element "sichtbar" geschaltet.

SeeAlso (als Protokoll) ist eigentlich "nur" die Zusammenfassung zweier
existierender Nicht[?]-Protokolle (unAPI und OpenSearch Suggestions, wobei dann
auch OpenSearch descriptions hereinspielen). Als "Framework" jedoch mit
1. beispielhafter Clientanbindung (die als "Black Box" funktiniert und nur in
   knappster Form fuer einen oder mehrere SeeAlso-Dienste zu konfigurieren ist,
   ich zeigte den HTML-Quelltext der Ausgabeseiten in den Beispielkatalogen,
   wo man das sehr gut sieht),
2. fuer sich bereits interessanten Beispieldiensten sowie
3. einem (von mir noch nicht ausprobierten) Perl-Modul zum Aufsetzen eigener
   SeeAlso-Server
ist das Ganze eine richtig runde Sache!

Abgesehen von den unter < http://ws.gbv.de/seealso/services/ > aufgefuehrten
SeeAlso-Diensten (diese sind nach muendlicher Aussage von Jakob Voss "fuer
kleinere Bibliotheken" frei nutzbar, man moechte wohl vor allem die Situation
vermeiden, aufgrund zu grosser Populoaritaet freier Dienste ploetzlich in
Hardware und Bandbreite investieren zu muessen) ist mir noch ein
(experimenteller) fuer HRO (Historische Rezensionen Online) bekannt (cf. <
http://www.collidoscope.de/blog/artikel/archive/2009/january/18/-c9f5e31378/ >).

Die Diskussion unter den Zuhoerern ergab schnell, dass ein aehnlicher Dienst
fuer Inhaltsverzeichnisse (v.a. von Sammelbaenden) denkbar und nuetzlich waere,
es gibt wohl nur niemanden, der ihn anbietet. Am Beispiel der Wikipedia-
bezogenen SeeAlso-Dienste kann man sehen, was dafuer noetig ist: In der
(deutschen) Wikipedia selbst wurde vor einigen Jahren als Kampagne eine hohe
fuenfstellige Zahl von biographischen Eintraegen auf standardisierte Weise mit
(den zugehoerigen) PND-Nummern versehen [und seitdem bei neuen Eintraegen auch
routinemaessig die PND konsultiert]. Dies gab fuer die Wikipedia selbst den
Vorteil, auf kohaerente Weise den Link "Literatur von und ueber ... im Katalog
der Deutschen Nationalbibliothek" anbieten zu koennen, (der frueher auf
komplizierte Art den PICA-Katalog ansteuerte und mittlerweile auf die oben
gezeigte einfache Form der Adressierung des Portals d-nb.info umgestellt ist).
Die Wikipedia ist nun selbst nicht unter der PND-Nummer ansprechbar, aber sie
(bzw. die zugrundeliegenden Daten) wird in Gaenze regelmaessig zum Download
angeboten. Jemand, der sich die Muehe macht, kann also regelmaessig (und
automatisiert) gezielt den Volltext downloaden und nach den deutlich erkennbaren
PND-Verlinkungen durchsuchen und daraus eine kompakte Tabelle mit der
umgekehrten Konkordanz PND-Nummer - Lemma - Web-Adresse aufbauen, die die
Grundlage fuer den Goettinger SeeAlso-Dienst "pnd2wikipedia" ist.

[Das ist m.E. sehr Web2.0-maessig: Ein /Dritter/ (GBV) stellt einen Dienst zur
Verfuegung, der eine vorhandene Anwendung (Wikipedia) auf neue, anbieterseitig
~eigentlich nicht vorgesehene~ Art (hier: Verlinkung anhand der PND-Nummer)
zugaenglich macht, zum Nutzen einer ganzen Klasse von Anwendungen (beliebige
Bibliothekskataloge mit Affinitaet zur PND)]

Ein hypothetischer Bereitsteller eines SeeAlso-Dienstes fuer Inhalts-
verzeichnisse muesste analog z.B. jeweils die Produktion /aller/
Bibliotheksverbuende durchsieben (ich vermute einmal, dass dort zumindest die
selbsterzeugten Inhaltsverzeichnisse am ehesten nachgewiesen sind, infrage
kaeme aber auch das deutlich kommerziellere dandelon.com) und nach bestimmten
Formen von MAB 655 Ausschau halten (es gibt zwar kein dediziertes Datenelement,
aber in der allgemeinen Hyperlink-Kategorie 655 nur einen kleinen Kanon von
typischen URLs und/oder typischen Wendungstexten), den so gefundenen
Datensaetzen entnimmt man dann die URL des Inhaltsverzeichnisses und die ISBN(s)
des Titels, fertig ist die Datenbasis fuer einen neuen Dienst. Anders als bei
der Wikipedia wird die Produktion der Bibliotheksverbuende jedoch nirgendwo zum
freien Download angeboten, insofern ist der Kreis derjenigen, die an das
Ausgangsmaterial zum Filtern kommen koennen, extrem eingeschraenkt.

[nachgelesen: AJAX steht fuer "Asynchronous JavaScript and XML", SeeAlso
benutzt aber nicht unbedingt XML, sondern basiert meist auf "open Search
descriptions" in JSON (JavaScript Object Notation), zentral ist aber jedenfalls
das "Asynchronous [HTTP] and JavaScript"]

Zu einer eigenen Datenbank kann man umgekehrt auch sehr einfach ein SeeAlso-
Interface anbieten, insbesondere weil der Dienst ueber mitgelieferte XSLT-
Stylesheets sein eigenes diagnostisches Interface aufbauen kann:
Im HANS-Katalog haben Objektsaetze einen Link "Anfrage", etwa
< http://hansdemo.gymel.com/cgi-bin/hansdemo.pl?t_tunnel=idn&idn=b303982 >
dies fuehrt im Beispiel auf eine statische(!) HTML-Seite als denkbar
primitivstes "Interface" fuer eine Bestellfunktion, die aber immerhin schon
mittels Javascript nachtraeglich ueber SeeAlso rudimentaere Informationen
zum angefragten Titel in ihr Formular eintraegt. Das SeeAlso-Interface ist
dabei < http://hansdemo.gymel.com/cgi-bin/hansdemo.pl/seealso/ >.
(Das Interface ist bewusst so primitiv gehalten: Die Funktionalitaet entstand
aus dem Desiderat, ~in~ HANS-OPACs "bestellen" zu koennen und mein Eindruck
ist, dass "Bestellfunktionalitaet" organisatorisch und technisch so heterogen
ist, dass das nicht geht. (Die einzige Gemeinsamkeit scheint zu sein, dass
eine intensive Verzahnung mit vom OPAC nicht beeinflussbaren Randbedingungen
besteht ;-). Also ist ein Webdienst die Antwort, der es beliebigen, extern[!]
realisierten (bzw. erst noch zu realisierenden :-( Loesungen zur
Bestellfunktionalitaet ermoeglicht, standardisiert und mit zeitgemaessen
Methoden an evtl. benoetigte Angaben zu kommen. Am Beispiel vuFind hatten
wir bereits in frueheren Vortraegen gesehen, wie hier auch die "Suchmaschine"
die Live-Verfuegbarkeits- und Standortnachweise ueber Webservices aus dem
"klassischen" Katalog bezieht und einbindet. Und strenggenommen ist auch
a30 als "datenlose" Anwendung konzipiert, die ueber HTTP "stateless"
standardisierte, von der konkreten Anwendung stark abstrahierte Daten
anfordert, "dahinter" koennte auch ein Nachbau von avanti mit SQL-Mitteln
stecken, "davor" muss es nicht unbedingt a30 bzw. das Flash-Runtime, sondern
koennte z.B. auch der vorgeschlagene Nachbau von a30 als reine HTML-Anwendung
sein, Hauptsache an beiden Enden herrscht Einigkeit ueber die Webschnittstelle.

[Nicht gezeigt: Die Capriccio-Demodatenbank bietet unter <
http://capdemo.gymel.com/cgi-bin/capdemo.pl/seealso/ > einen SeeAlso-Server,
der auch die Formate RIS und MODS anbietet. Das ist eine elegante Methode, um
Literaturverwaltungsprogramme zu bedienen, denn speziell MODS als von
Bibliotheken entwickeltes Format ist reichhaltig genug, um Zitate komplexerer
bibliographischer Situationen nicht von vorneherein zu verstuemmeln. Leider ist
dieser Weg so elegeant, dass nur Zotero ihn beherrscht, und dessen MODS-
Importfunktionalitaet scheint extrem verkrueppelt. Insofern besteht (derzeit)
kein Vorteil gegenueber COinS (openURL, Z39.88), das immerhin auch noch von
Citavi beherrscht wird. [Ebenfalls im Capriccio-Demo-OPAC, ebenfalls nicht
gezeigt]. Zu diesem Thema hatte ich im Juli ausfuehrlich etwas geschrieben:
"Kein Spass mit Exporten fuer Literaturverwaltungen" <
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2009-July/029828.html >]

[SeeAlso-Services sind eigentlich extrem leichtgewichtig, wegen der teilweisen
Herkunft von openSearch suggestions, wo ja jeder Tastendruck des Benutzers u.U.
eine erneute Abfrage ausloest, ist das auch wichtig. Insofern ist es durchaus
fragwuerdig, solche Services /mit/ dem OPAC zu realisieren, der ja
typischerweise eine eher schwergewichtige Anwendung mit entsprechender Last auf
dem Server ist. Im Fall der Anwendung "Bestellformular" ist allerdings
offensichtlich, dass sie selten genutzt wird, und die Anwendung fuer Literatur-
Verwaltungsprogramme hat gezeigt, dass (das eingeschaltete) Zotero aufgrund
relativ geringen Markups in der Ergebnismenge und einer einzigen Zusatzanfrage
(uanbhaengig von der Zahl der simultan gezeigten Titelaufnahmen) nach dem Format
"weiss", dass etwas zu holen ist, die Titel jedoch nur auf explizite Anfrage des
Benutzers ueber das SeeAlso-Interface anfordert. Demgegenueber steht COinS, das
prophylaktisch jegliche Titelanzeige mit einer viele hundert Bytes grossen
verkapselten Replikation der Titelinformation wie etwa
<span class="Z3988"
title="ctx_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Actx&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&url_ver=Z39.88-2004&ctx_enc=info%3Aofi%2Fenc%3AUTF-8&ctx_ver=Z39.88-2004&url_ctx_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Actx&rfr_id=info%3Asid%2Fgymel.com%3Aavdemo&url_tim=2009-11-14T22%3A07%3A58Z&rft.genre=book&rft_idn=urn%3AISBN%3A978-3-920269*-35-1&rft.btitle=Rolf-Gunter%20Dienst%20%3A%20Von%20der%20Ungleichheit%20des%20%C3%84hnlichen%20%3B%20Hans-Thoma-Preis%202007&rft.place=Baden-Baden&rft.pub=Staatl.%20Kunsthalle&rft.tpages=72%20S.&rft.isbn=978-3-920269*-35-1&rft.date=2007&ctx_tim=2007-12-11T00%3A00%3A00Z"></span>
anreichert]

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSwaEZWITJZieluOzAQLf5QP5AWJYCuyEax32A7gtTCFbkn0222MN497Y
GV/MvckZSYuHhJFA66rFNhj/uqWYhSyFo/qq6lVjPfN1z6pwe9ONCHSsYOMp5IWf
2JHsYucloocv7LVAto8J6Kj571ogOUew8h9imO5tLG1xrOpuoGyxP83l76nFohnU
QDgPxTPx/bQ=
=TLNu
-----END PGP SIGNATURE-----