[Allegro] Kein Spass mit Exporten fuer Literarurverwaltungen

[Thomas Berger]

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

Liebe Liste,

hier ein Bericht fuers Sommerloch, garniert mit Fragen, bevor ich zu viele
Details wieder vergesse.

Ab und zu artikulieren Benutzer ihren Unmut, warum ihr Lieblingskatalog
nicht ihre Lieblings-Literaturverwaltung unterstuetzt, vornehmlich sind
das Endnote-Benutzer, die auf der Suche nach einem Connection File (.enz)
fuer Endnote sind. Damit sind sie dann in der Lage, direkte Recherchen
ueber Z39.50 durchzufuehren und die Resultate nach Endnote zu laden.

Ich finde das etwas verdreht, denn der Benutzer zahlt dem Hersteller Geld
fuer das Literaturverwaltungsprogramm und erwartet nun von der Bibliothek, dass
sie ebenfalls diese Software beschafft, um dem Benutzer eine Konfigurationsdatei
zu stricken (obwohl: Ist das nicht genau das Geschaeftsmodell der grossen
Verleger wissenschaftlicher Zeitschriften?). Lt. Webseiten kuemmert sich
auch der Hersteller auf Nutzeranfrage darum, Profildateien fuer weitere
Datenbanken anzubieten, der Weg scheint den Nutzern aber zu weit, ich habe
sie leider nie gefragt. Man will ja auch die eigenen Benutzer nicht
verprellen, indem man sie "wegschickt" und obszoenerweise darauf hinweist,
dass sie die Einloesung der Werbeversprechen fuer die Software xy doch bitte
dort einfordern, wo sie dafuer bezahlt haben.

Wie dem auch sei, Besitzer von Endnote koennen diese Dateien erfahrungsgemaess
recht einfach selbst herstellen, wenn man ihnen ein paar Eckdaten zum
Z39.50-Target der Bibliothek mitteilt. Die Suchmoeglichkeiten in Z39.50 sind
natuerlich stark schematisiert (und sehr auf AACR getrimmt, man sollte eher
nicht das Spezialregister der cat.api fuer #83 anbieten fuer die Suche
nach "Conference"), und nach meinem Eindruck werden nur wenige davon
von Endnote genutzt, so sie denn vom Target unterstuetzt werden.

Man sollte wohl (aber ich habe anderes nie ausprobiert) MARC21 im ANSEL-
Zeichensatz ueber Z39.50 ausliefern, MAB oder UTF8-codiertes MARC21
waeren wohl zu exotisch (obwohl in .enz-Dateien wohl auch Filter definiert
werden koennen, die die Resultate dann auf die Beduerfnisse von Endnote
ummodeln).

Aehnliches gilt fuer Citavi, hier wird nach meinem Eindruck aber von
der Website des Herstellers aus eine verteilte Z39.50-Suche veranstaltet,
dementsprechend kann auch nur der Hersteller Profile fuer weitere Datenbanken
erstellen, allerdings habe ich hier schon einmal erlebt, dass der Hersteller
sich deswegen mit einer Bibliothek in Verbindung gesetzt hat. Die Umsetzung
der Daten nach Citavi (hier gibt es eine freie Version, mit der man das
dann kontrollieren kann) schien mir aber etwas lieblos, das kann aber auch
daran liegen, dass es fuer Aufsatznachweise, speziell aus Monographien
(Festschriften, Konferenzbaende) in MARC21 nicht wirklich ausgetretene
Pfade gibt, wie die abzubilden waeren (oder irre ich mich da?)

Nun gibt es auch den Citavi-Picker als Browser-Plugin, der ISBNs auf
Webseiten erkennt und eine allgemeine ISBN-Suche, Citavi als Schweizer
Produkt bedient sich da beim GBV. Was da uebernommen wird, ist nicht so
reichhaltig, wie man es sich aus bibliothekarischer Perspektive vorstellt,
aber es gab mir immerhin teilweise die Sicherheit, dass die suboptimale
Uebernahme auf eine besonders miese MARC21-Parameterdatei fuers allegro-
ZTarget zurueckzufuehren waere.

Benutzer bevorzugen bei der Literaturrecherche meist die echten OPACs
(und hocken nicht vor ihrem Literaturverwaltungsprogramm und sondern
verteilte Suchen nach Stichworten ab, bis etwas kommt), denn dort gibt
es evtl. passendere Suchmoeglichkeiten als Z39.50, Anzeigen mit Fussnoten
und Schlagworten etc. und erwarten dann allerdings eine Moeglichkeit der
Uebernahme in ihre jeweilige Literaturverwaltung. Aus Sicht der Bibliothek
ist das ein erfreuliches Nutzerverhalten, so bleiben die Nutzer im
direkten Kontakt mit dem Web-Angebot und Katalog, ohne dass zwischengeschaltete
Portale und Agenten eine Einheitlichkeit erzwingen, die evtl. gar nicht
sachgerecht waere.

Der eben erwaehnte Citavi-Picker ist da als hybrid einzustufen: Er erkennt
die ISBN im jeweiligen OPAC, beschafft die Titeldaten dann aber von anderswo.
Derzeit sehr beliebt (vermutlich, weil irgendjemand das als "Bibliothek 2.0"-
Features geadelt hat) sind "Export"-Buttons bei den Titelanzeigen.
Gaengige Exportformate sind RIS, BibTeX, "Endnote", desweiteren MODS, RDF,
CSV, und einige mehr. Nach meinem Eindruck ist RIS das Format, das alle
diese Programme beherrschen, und es gibt sogar einen Mimetyp dafuer
(application/x-Research-Info-Systems: D.h. am "x-" erkennt man, dass er zwar
nicht IANA-registriert ist, aber immerhin wird er manchmal erwaehnt).

RIS hat gewisse Einschraenkungen, Codierung ist z.B. ISO 8859-1, aber das
Format ist immerhin dokumentiert:
http://www.refman.com/support/risformat_intro.asp

Die folgende Tabelle listet die Dokumenttypen auf:
 http://www.refman.com/support/risformat_reftypes.asp
und man sieht, dass Bandauffuehrungen / Stuecktitel nicht existieren (das
haette man auch nicht ernsthaft erwartet), aber dass merkwuerdigerweise
auch unselbstaendige Literatur nicht besonders differenziert ist:
"Book chapter", "Conference Proceeding" (gemeint ist wohl der einzelne
Aufsatz, das steht aber nirgendwo), "Journal" (gemeint ist der Aufsatz,
denn es gibt auch "Journal (full)", "Magazine article", und das waer's
dann auch schon. Bei Experimenten mit Citavi habe ich fuer Aufsaetze
aus einer Festschrift die besten Erfahrungen mit "Book chapter" gemacht,
aufgrund der voellig flachen Struktur war es aber voellig aussichtslos,
den Herausgeber der Festschrift in RIS ueberhaupt zu transportieren
(Fuer Citavi allerdings egal, weil sich hier das Zitat des Aufsatzes und
das der Festschrift miteinander verknuepfen lassen).

Ich habe neben Citavi auch etwas mit Zotero herumgespielt und dabei
insbesondere auf Aufsaetze geachtet, ab und zu auch etwas aus diesen
Applikationen nach RIS etc. exportiert. Das war alles nicht systematisch,
insbesondere habe ich mich diesmal ueberhaupt nicht um BibTeX gekuemmert
(insbsondere da kein gaengiger Mime-Typ und keine definierte Zeichencodierung),
mein Eindruck ist aber, dass das voellig simplistische bibliographische
Modell des RIS-Formats (Aufsaetze mal beiseite: Wie steht es um elektronische
Zeitschriften: "Data file", "Electronic Citation"?) vielleicht zwar nicht
ursaechlich ist, wohl aber typisch fuer den ganzen Zoo der
Literaturverwaltungen: Innerhalb der Programme kann man zwar moeglicherweise ein
paar Felder mehr belegen, ist aber einer Typisierung verhaftet, die mit den
Publikationsgewohnheiten mancher Disziplinen und Laender (und ueberhaupt denen
der Neuzeit) nicht immer voellig uebereinstimmt.

Nun ist es auch nach Ansicht der Hesteller so (personal communication am Stand
von Swiss Academic in Erfurt neulich), dass ein Anwender etwa von Citavi
ueberfordert ist, einem Button "RIS-Export" im OPAC anzusehen, dass sich
dahinter die gewuenschte "Uebernahme in Citavi" verbirgt. Der Hersteller raet
daher dazu, den Button irgendwie mit "Citavi" zu beschriften, das hat aus seiner
Perspektive auch wirklich nur Vorteile. Allerdings sollte man dann wohl auch
Buttons identischer Funktionalitaet anbieten bzw. die Beschriftung ausweiten
zumindest auf die aehnlich beliebten Produkte Endnote, RefWorks und Zotero.
Ich finde hingegen, dass man erstens dafuer bezahlt werden sollte, wenn man
so heftiges Product Placement betreibt und zweitens - gerade bei allegro-
Datenbanken, wo gerne mehr als eine Vollanzeige gleichzeitig zur Anzeige
kommt - man nicht wirklich darauf angewiesen ist, irgendwelche Leerstellen
auf dem Schirm auf Teufel komm raus mit interaktiven Elementen anzuf/muellen.

Citavi beherrscht nun auch COinS (das ist i.W. openURL 1.0 aka Z39.88), d.h.
einen Weg, ueber /nicht sichtbare/ Elemente dennoch die beliebte Funktionalitaet
"Uebernahme in die Literaturverwaltung" hinzubekommen. Diese "nicht sichtbare"
Art ist meiner Meinung nach die optimale Vorgehensweise um Interoperabilitaet
herzustellen, es mag allerdings sein, dass manche nicht auf das aufdringliche
Geschrei "ich bin Bibliothek 2.0" verzichten koennen, wie es sich durch einen
Buttonwald fuer Literaturexporte manifestiert (o.k., man kann sich bei
Google Scholar ansehen, wie man auf Konfigurationsseiten erst einstellt, welche
Zusatz-Buttons man sehen moechte, aber das ist dann wieder etwas aufwendiger).
Zeichensatz ist hier ganz klar UTF-8, d.h. voller Unicode, was auf jeden
Fall ein Vorteil gegenueber RIS ist, sobald man nur ein bischen osteuropaeisches
im Bestand hat.

Der openURL-Standard ist ein umfangreiches Dokument (vgl.
http://standards-catalogue.ukoln.ac.uk/index/Z3988-2004 , der Link von dort
auf niso.org ist zerbrochen, anscheinend gibt es seit kurzem keine Moeglichkeit
der Verlinkung auf den Volltext, man muss ihn stets neu ueber die Suchfunktion
auf http://www.niso.org/ heranziehen), ausserdem muss man ja zusammen mit
der Vollanzeige auch noch das volle Zitat als openURL (in COinS) in den
HTML-Code einbauen, das koennte also das Datenvolumen verdoppeln, nur auf den
Verdacht hin, dass ein Citavi-Benutzer gerade recherchiert.

In Erfurt habe ich uebrigens auch an den Staenden von Endnote und RefWorks
angefragt, wie diese Produkte sich eine "unsichtbare" Uebernahme vorstellen,
das Standpersonal war allerdings ueberfragt, man versprach mir jeweils, dass
sich ein "Techniker" mit mir in Verbindung setzen wuerde. Darauf warte ich
noch ;-)

Zotero beherrscht nun neben COinS auch Datenuebernahme via unAPI (vgl.
http://unapi.info/specs/ ), also sozusagen echtes "Autodiscovery": In den
Seitenkopf wird nur ein <link>-Tag eingebaut, das auf einen unAPI-Server
verweist, jede Titelaufnahme hat zusaetzlich ein <abbr>-Element mit
class="unapi-id" und als title-Attribut eine Identnummer. Ein unAPI-aware
Webclient (wie z.B. Firefox mit Zotero als Add-on) bemerkt dies und
fragt einerseits den Server nach den Formaten, die er ueberhaupt unterstuetzt
und andererseits gezielt nach den Formaten, die fuer die konkret auf
der HTML-Seite vorkommenden Identnummern lieferbar sind. Ist da ein
bekanntes bei, bietet Zotero den Download an. Erst wenn der Benutzer das
wuenscht, wird ueber erneute Anfragen an den unAPI-Server der Satz im
gewuenschten Format angefordert.

Von Zotero erkannte Formate sind (u.a., wenn ich mich recht entsinne) RIS
und - MODS, d.h. endlich einmal ein bibliothekarisches Format. Und weil ich
kurz vorher sowieso fuer Populo das SeeAlso-Protokoll von Jakob Voss
implementiert hatte ( http://ws.gbv.de/seealso/ ), das eine Art Verheiratung
von unAPI und openSearchSuggestions ist, habe ich schnell einen einfachen
MODS-Export gezimmert (ohne Bandauffuehrungen etc.) und mit Zotero ausprobiert.

Das Ergebnis war niederschmetternd, nicht einmal ein zweiter Verfasser wurde
importiert (und Uebergehworte am Titelanfang, restlicher Sachtitel und
Titelzusatz werden gnadenlos, nicht einmal mit einem Spatium als Trenner,
zusammengeballert). Zugegebenermassen ist Zotero open Source und es ist
anzunehmen, dass irgendwann (bald?) einmal jemand diesen wirklich miesen
MODS-Import aufmoebelt.

Meine Kritik an RIS habe ich oben schon geaeussert, ich fand es nicht
vertretbar, eine so moderne Methode zu implementieren, dass nur Zotero damit
umgehen kann und damit dann nur die Kruecke RIS auszuliefern.
Daher habe ich mich dann entgegen dem urspruenglichen Vorsatz durch die
Spezifikation von openURL 1.0 gekaut: Das PDF hat 120 Seiten und ist derart
redundant aufgebaut und formuliert, dass es wirklich muehsam ist, Information
daraus zu ziehen. Fuer COinS gibt es aber die Empfehlung, nur die primitivste
und expliziteste der spezifizierten Moeglichkeiten zu waehlen (im Prinzip
hat openURL auch eine "by reference"-Methode, die den Traffic aehnlich
oder sogar noch besser reduzieren koennte als unAPI). Jedenfalls verplempert
man viel Zeit, bis man erkennt, dass hier nur ein furchtbar abstraktes
Framework definiert wird (man lernt sofort, dass hier nicht (Meta)Daten auf die
Reise geschickt werden, sondern "Context Objects" zu bilden sind, die aus
"Referent", "Referring Entity", "Requester", "Service Type", "Resolver"
und "Referrer" aufgebaut werden), und die Frage "welche Datenfelder gibt es
und wie heissen sie" nicht abgehandelt wird, bzw. immer nur in Beispielen.
Nach genauem Hinschauen merkt man, dass "Referent" etwas mit den Metadaten
zu tun hat, und die Definition der Datenformate und eigentlich alles Konkrete
ausgelagert sind in eine eigene Registry bei OCLC als Maintenance Agency fuer
Z39.88: http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListSets

[Das ist nun mal etwas wirklich Schickes: ein "nacktes" OAI-Repository,
das durch angebundene XSLT-Stylesheets zu einer halbwegs gut benutzbaren
Web-Anwendung wird. Obwohl: Die oben erwaehnten SeeAlso-Server machen
das auch so]

In diesem Repository kann man nun lernen, dass die Welt der openURL aus "Books"
und "Journals" (und "Dissertations") besteht. Wie das genau aussieht, ist dann
hier geregelt:

"journal":
http://alcme.oclc.org/openurl/servlet/OAIHandler/extension?verb=GetMetadata&metadataPrefix=mtx&identifier=info:ofi/fmt:kev:mtx:journal

"book"
http://alcme.oclc.org/openurl/servlet/OAIHandler/extension?verb=GetMetadata&metadataPrefix=mtx&identifier=info:ofi/fmt:kev:mtx:book

In diesen Dokumenten wird jeweils auch ein "genre"-Element mit distinkten
Werten definiert, sogar mit zarten Andeutungen zur Semantik:

Bei "journal" (kev:mtx:journal / xml:xsd:journal):

journal: a serial publication issued in successive parts.

issue: one instance of the serial publication.

article: a document published in a journal.

conference: a record of a conference that includes one or more conference papers
     and that is published as an issue of a journal or serial publication

proceeding: a single conference presentation published in a journal or serial
     publication

preprint: an individual paper or report published in paper or electronically
     prior to its publication in a journal or serial.

unknown: use when the genre of the document is unknown.


Bei "book" (kev:mtx:book / xml:xsd:book):

book: a publication that is complete in one part or a designated finite number
   of parts, often identified with an ISBN.

bookitem: a defined section of a book, usually with a separate title or number.

conference: a publication bundling the proceedings of a conference.

proceeding: a conference paper or proceeding published in a conference
    publication.

report: report or technical report is a published document that is issued by an
    organization, agency or government body.

document: general document type to be used when available data elements do not
     allow determination of a more specific document type, e.g. when one has
     only author and title but no publication information.

unknown: use when the genre of the document is unknown.


D.h. mit openURL (1.0) hat man es wirklich geschafft, einen monstroes
abschreckenden, ueber-abstrakten Standard zu schaffen, der an konkreten Daten
nur etwas liefern kann, das noch etwas beschraenkter ist als das RIS-Universum
(aber immerhin Unicode). Insbesondere auch hier wieder die Einschraenkung,
dass man bei einem Sammelbandbeitrag gerade noch ISBN und "Titel" der
Festschrift mit auf den Weg schicken kann, aber etwa nicht den Herausgeber.
Damit ist dann auch klar, dass die Resultate bei der Uebernahme in Literatur-
verwaltungen Citavi und Zotero stellenweise etwas mager sind.

Natuerlich ist der Vorteil des abstrakten Standards, dass man kein neues
Framework benoetigt, sondern einfach weitere Metadatenformate registriert.
In der Tat kann man auch MARCXML ueber openURL transportieren, das allerdings
nicht als COinS eingebettet, das erfordert die "kev"-Serialisierung: Key Encoded
Values.

Fazit oder Thesen:

* Die Nutzer von Literaturverwaltungsprogrammen scheinen ohne zu Murren
  wesentlich mehr Handarbeit an importierte Zitate aufzuwenden (Nachtragen von
  diesem und jenem, insbesondere von Herausgebern, Titelzusaetzen, URLs) als ich
  es fuer moeglich gehalten haette. Oder die wissenschaftliche Zitierkultur ist
  in den letzten Jahren voellig auf den Hund gekommen (das habe ich jetzt nicht
  untersucht).

* Es ist wirklich leicht fuer Bibliotheken, ein serioeses(!) "Light"-Format wie
  MODS anzubieten, und Mikroformate, Autodiscovery, unAPI und Verwandtes sind
  auch keine Hexerei. Damit koennte man wirklich Web-2.0-maessig, ohne zu
  grossen Spielraum fuer technische Missverstaendnisse zwischen den Systemen
  (Codierungsfragen etc.) und ohne den Benutzer zu behelligen deutlich bessere
  Daten als bislang anbieten, Produkt-unabhaengig fuer alle, die die Standards
  sprechen.

* Manche Literaturverwaltungssysteme scheinen auf dem Weg zu sein, die Kataloge
  beim obigen Punkt zu treffen, insgesamt scheint mir aber gerade bei den
  "Platzhirschen" wenig Bewegung in der Szene zu sein.

* Das Anbieten von Export-Links zu irgendwelchen Literaturverwaltungen im
  OPAC ist die Art, wie man es vor 10 Jahren gemacht haette (da gab es
  natuerlich noch mehr Wirrwar in Zeichencodierungsfragen). Das jetzt
  massenhaft und intensiv zu betreiben (vgl. etwa eines der "strategischen"
  Projekte bei der Fusion von BVB und KOBV) ist pure Anbiederei, entweder
  bei Benutzern oder bei irgendwelchen "Entscheidern". Wegen der kostenlosen
  Werbung dadurch haben die Literaturverwaltungsprogramme nun noch einen
  Grund mehr, nicht innovativ zu sein.

* COinS (openURL) wird immerhin von Citavi und Zotero beherrscht, unAPI
  nur von Zotero, bringt aber derzeit keine Vorteile (ich habe allerdings
  nicht ausprobiert, wie sich der echte MARC21- oder MARCXML-Import verhaelt).

* Wer es sich leisten kann, Endnote und RefWorks nicht zu unterstuetzen (im
  doppelten Wortsinn), sollte m.E. COinS in den OPAC integrieren und bewusst
  keine "Export"-Buttons, das verschafft den innovativeren Citavi und Zotero
  einen kleinen, feinen Vorteil und macht der Konkurrenz dann vielleicht
  irgendwann Beine.

* openURL ist voelliger Hype (alte Kruecke in neuen Bandagen)


Korrekturen, Einsprueche, weitere Beobachtungen gerne erbeten

viele Gruesse
Thomas Berger

P.S.: Wer ein bischen vom Gesagten in Aktion sehen moechte:

* Im Capriccio-Demo-OPAC sind COinS und unAPI (RIS und MODS, Zotero waehlt
  dann von sich aus MODS) implementiert:
http://capdemo.gymel.com/
  (Dokumentation der SeeAlso-Schnittstelle:
http://capdemo.gymel.com/cgi-bin/capdemo.pl/seealso/

* Die Kataloge des Kunstbibliotheken-Fachverbunds Florenz-Muenchen-Rom bieten
  seit einigen Wochen heimlich COinS an: http://www.kubikat.org/

* Der HANS-Demo-OPAC http://hansdemo.gymel.com/ hat auch ein SeeAlso-Interface:
http://hansdemo.gymel.com/cgi-bin/hansdemo.pl/seealso/
  Metadatenformat aber nur OAI_DC (unqualified Dublin Core ist aber selbst fuer
  eine Literaturverwaltung zu primitiv), einen MODS-Export gibt es fuer HANS
  komischerweise immer noch nicht. [Ich hatte auf dem letzten HANS-Anwender-
  treffen einmal herumgefragt: Im Bereich der Nachlaesse und Autographen hat
  noch kein Nutzer der Bibliothek die Frage gesetellt, wie er ein Brief-
  katalogisat in seine Literaturverwaltung bekommt. Ist vermutlich auch nicht
  so einfach, weil es nirgendwo ein Datenfeld fuer die Signatur gibt, die ist
  in dem Bereich aber wirklich zentral]

* und ganz am Rande: In dieser Mail ging es wenn, dann um die Funktionalitaet
  des eigenen Katalogs als SeeAlso (unAPI)-Server. Noch einfacher zu
  implementieren ist aber SeeAlso-Client-Funktionalitaet, also fallweise
  "von alleine" auftauchende Verlinkungen zur Wikipedia, VD16, LibraryThing,
  GBV, HRO etc. Die obigen Demo-OPACs haben einige Beispiele davon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSmkM6WITJZieluOzAQJuYQP/Z936buPnpu+RCMdIVkSaWWaK7bysmXOs
HSJ2mUyQ1n+L59QKldbzqSgA5a5E49iHiWhmmh5K0GQFEDX5zXBpIt0rPe01xSKS
Q5RFNrl0CaCyg7oesglYifrswWMm7sOosl90TrVPpmZakBZC82jQOcp60kph9Qii
XqeioSm6tww=
=eCU6
-----END PGP SIGNATURE-----