Die TIB/UB Hannover hat gerade eine Umfrage zum Thema Literaturverwaltung gestartet. Bitte nehmt / nehmen Sie teil. Es ist nämlich gar nicht so leicht herauszufinden, wer welche Literaturverwaltung benutzt, welche Features geschätzt oder vermisst werden, und wie man die Leute (insbesondere aus Sicht einer Bibliothek) dabei am besten unterstützen kann.
Als Verfechter von Open Data werden wir alle Umfrageergebnisse natürlich frei zur Verfügung stellen. (U.a. als CSV-Datei.) Bei den Benutzerkonten der TIB/UB auf Facebook und Twitter wird von der Bekanntgabe der Ergebnisse zu erfahren sein, dort sollen die Ergebnisse natürlich auch mit der Community diskutiert werden. Und, versprochen: Alle wichtigen neuen Diskussionsstränge und Einsichten werden wir ganz zum Schluß in diesem Blog hier verlinken und zusammenfassen!
http://www.tib.uni-hannover.de/de/aktuelles/aktuell/newsdetail/article/citavi-endnote-zotero-und-co/1.html

Disclaimer: Ich bin Mitarbeiter der TIB/UB Hannover und Autor der Umfrage.

Alf Eaton stellt in HubLog ein Skript vor, daß er für Google Texte & Tabellen (kurz Google Docs) geschrieben hat. Nach Installation des Skripts innerhalb der Google-Dienste

• durchsucht es auf Anforderung ein Dokument nach DOIs,
• ermittelt anhand dieser DOIs gleichförmig aufgebaute, gut lesbare Quellenangaben,
• erstellt aus diesen Quellenangaben eine Bibliographie im Anhang des Dokuments, und
• ersetzt abschließend die DOIs im Dokument mit durchnummerierten Angaben, die auf die vollen Quellenangaben im Anhang verweisen.
• Als Schmankerl wird das Dokument ganz zum Schluß in ein PDF umgewandelt und seinem Autoren per E-Mail zugeschickt.

Ein schönes Detail: URLs statt DOIs

Statt DOIs kann das Skript auch beliebige URLs erkennen und ersetzen, die als Quellen im Text erwähnt werden. Diese werden auf die gleiche Weise verarbeitet — vorausgesetzt, die URL gibt auf Abruf bibliographische Angaben in maschinenlesbarer Form (hier: in JSON) zurück. Eine solche Funktion ist für stabile URLs in Bibliothekskatalogen oder Repositories ebenso denkbar wie z.B. für Links auf Artikel in Wikis und Weblogs.

Mendeley-Integration, einfaches Zitate-Markup

Zwei weitere interessante Details

• Statt DOIs und beliebiger URLs können auch IDs bibliographischer Datensätze aus Mendeley-Bibliotheken verwendet werden. Sicherlich ein erfreulicher Zwischenschritt für Anwender, die Korrektheit und Vollständigkeit ihrer bibliographischen Angaben selbst konktrollieren wollen.
• Das Skript kann die bloße Erwähnung z.B. einer URL von einer URL als Quellenangabe unterscheiden, indem alle Quellenangaben durch ein sehr simples Markup gekennzeichnet werden müssen; Eaton nennt als Beispiel

{{cite:doi:10.1038/nchem.1108}}

Warum ist das mehr als eine Spielerei, sondern wegweisend?

Kurze Antwort: Weil es der überfällige Anfang vom Ende traditioneller Literaturverwaltung ist.

Eine etwas ausführlichere Antwort liefert das folgende Selbstzitat (sorry für die Stillosigkeit), ein Kommentar von mir in diesem Blog vor einigen Monaten:

In einer idealen biobliographischen Welt bekommt ein Werk in dem Augenblick, in dem es in die (Netz-)Welt gesetzt wird, eine identifizierende URI, unter der dauerhaft Metainformationen abgerufen werden können, und am Besten auch gleich der Volltext frei zugänglich ist. DOI, URN, Handle und Co. weisen den Weg. Was mir fehlt ist ein zweiter Schritt: Unter dem Identifier müßten auch maschinenlesbare (also strukturierte) bibliographische Informationen abrufbar sein. Klingt banal, aber das könnte die Welt der Literaturverwaltungssoftware vom Kopf auf die Füße stellen: Das Dokument holt sich seine bibliographischen Detailangaben anhand von Identifiern im Hintergrund, und der Leser (!) kann wählen, in welchem Stil ihm Quellen und Zitate anzeigt werden.

Die Hürde der bibliographischen Beschreibungssprache(n)

Die zurzeit größte Hürde: Es müßte sich als Standard etablieren, auf Maschinenanfragen an bestimmte URLs strukturierte bibliographische Angaben z.B. anhand der Citation Style Language in JSON zurückzugeben. Insbesondere Entwickler der Software für Kataloge, bibliographische Webdienste aller Art, Repositories, Journals, aber auch Wikis, Weblogs und andere Publikations-Plattformen aller Art müßten sich dies zu Herzen nehmen. Die relativ rasche Verbreitung von Konventionen wie COinS und unAPI in der Vergangenheit lassen hoffen, daß dies nicht zu fern von der Realität liegt.

Literaturverwaltung = Arbeit für Autoren; Literaturbeschreibung = Komfort für Leser

Eatons Gründe, seine maschinengestützten Literaturbeschreibung  (Literaturverwaltung wäre das ja nicht mehr, da die beschreibenden Daten keinen „Zwischenhalt“ mehr beim Autoren einlegen, der sie verändert, verwaltet etc.) zunächst in Google Docs zu implementieren, kann ich gut nachvollziehen: Es handelt sich um eine besonders populäre, vielseitig einsetzbare und zudem leicht zu skriptende Textverarbeitungsplattform.

Als Leser nimmt mir das Skript eventuell zu viele Entscheidungen vorweg. Wie wäre es, wenn das Skript anhand des Locales (Gebietsschemas) meines Browsers oder Ebookreaders vermutet, daß ich vielleicht den in Deutschland relativ verbreiteten DIN-Zitierstil bevorzuge, und mir eine entsprechende Bibliographie während des Textabrufs erzeugt? Oder ein Schieberegler neben dem Text, der mich frei einstellen läßt, wie ausführlich die bibliographischen Angaben sein müssen?

Standards, Sprachen und Webdienste statt komplizierter Clients

Wäre ich heute Hersteller einer Literaturverwaltungs-Software, dann würde ich es Zotero und Mendeley gleich tun, die derzeit offenbar viel Energie in die Ausarbeitung und Implementierung von Standards wie der Citation Style Language stecken. Webdiensten, die strukturierte bibliographische Angabe liefern, abrufen, verschieden formatiert darstellen, aber z.B. auch disambiguieren, in Sets präsentieren, sortier- und durchsuchbar machen, gehört die Zukunft.

Die Beispiele ZotPress und KCite

Warum soll ich mir schließlich eine Software kaufen und auf meinem Rechner installieren, warum mir einen Account bei einem kommerziellen Webdienst anlegen, wenn ich mir mit kostenloser und quasi überall verfügbarer Software wie Zotero und WordPress eine tadellose Bibliographie generieren kann? (Vgl. Katie Seaborns Zotpress.) Ein weiteres WordPress-Plugin, das — ohne Zotero — ganz ähnlich wie Alf Eatons Skript funktioniert, ist KCite.

Jeder Autor ein kleiner Experte für bibliographische Datenbanken? Vorbei…

Eigentlich ist es ein No-Brainer: Die Zukunft der Literaturverwaltung ist das Verschwinden komplizierter und manchmal teurer Literaturverwaltungs-Clients. Vorbei die Zeiten, in denen Autoren kleine Experten für bibliographische Datenbanken sein sollten. Wir Informationsprofis haben diese Fiktion der einschlägigen Client-Hersteller (und vor allem -Verkäufer) lange genug reproduziert. Endlich sehen wir all das allmählich verschwinden — es wird höchste Zeit!

Einsortiert unter:5. AddOns & Tools, Allgemeines

Warum überhaupt Forschungsergebnisse in peer-reviewed Journals veröffentlichen? – Joe Pickrell, Humangenetik-Doktorand an der Uni Chicago und Ko-Autor des Gruppenblogs Genomes Unzipped, unterzieht das traditionelle wissenschaftliche Journal einer radikalen Kritik:

I (…) argue that cutting journals out of scientific publishing to a large extent would be unconditionally a good thing, and that the only thing keeping this from happening is the absence of a “killer app”.

Pickrell räumt ein, daß das Journal eine wichtige Funktion erfülle. Es filtert unter dem Gesichtspunkten

• der Qualität,
• der Interessantheit für eine bestimmte wissenschaftliche Teilcommunity sowie
• der Nachvollziehbarkeit bzw. Reproduzierbarkeit der behaupteten Ergebnisse

was veröffentlicht wird. Das Mittel der Wahl dafür ist heute der Peer Review.

Pickrell referiert zusammenfassend einige bekannte Kritikpunkte an diesem Verfahren der Qualitätssicherung. Es sei

• langsam (im Verhältnis dazu, wie schnell im Web publiziert werden kann),
• aufwändig — die kostenlose Arbeit mehrerer Gutachter_innen sowie organisatorische Tätigkeit fließen ein,
• im Ergebnis kaum reproduzierbar, ja höchst unzuverlässig (“the correlation in perceived “publishability” of a paper between two groups of reviewers is little better than zero”),
• sowie stets anfällig für die Bevorzugung dominanter Meinungen bzw. die Benachteiligung origineller neuer Einsichten.

Pickrells Hauptargument: Heute ginge so etwas besser.

Social Networking-Anwendungen zeigen, daß ich mir selbst eine Gruppe vertrauenswürdiger Experten auf einem Themengebiet XY zusammenstellen könne. Sie wirken auf mich wie ein Filter — was wirklich relevant ist erreicht mich durch ihre “Vorsortierung”.

Hinzu kommen Experimente wie die Article-Level Metrics der Public Library of Science (PLoS). Sie weisen Pickrell zufolge in die richtige Richtung: Hier wird nicht vor, sondern nach der Veröffentlichung “gefiltert”. Filterkriterium sind dabei z.B. die Downloadraten der Artikel.

Einziger Haken: Das Filterergebnis der Article-Level Metrics kommt sozusagen immer zu spät. Pickrell schlußfolgert, daß die Zeit reif ist für eine “Killer App”, die effizientes soziales Filtern mit der innovativen Offenheit neuer Publikationsformen zusammenbringt — und daß wenn diese Anwendung erst einmal auftaucht, klar werde, wie überflüssig traditionell organisierte Journals im Webzeitalter überhaupt seien.

Sein Blogartikel kommt tatsächlich zur rechten Zeit. Das zeigt nicht erst die angeregte Diskussion unter dem Blogartikel in Genomes Unzipped.

Der Pharmazie-Professor Peter Murray-Rust hatte z.B. erst in diesem Sommer in seinem Blog eine Serie engagierter Artikel zu diesem Themenkomplex geschrieben. (Ein guter Einstiegspunkt, aus dem ich abschließend zitiere, ist hier.)

Pickrells jugendlicher Optimismus ist Murray-Rust (geboren 1941) offenkundig fremd. Er erwartet keine rasche Auflösung der verknoteten alten Filter durch eine schlagartig auftauchende “Killer App”. Er beharrt vielmehr darauf, daß der Wissenschaftsbetrieb selbst falsch gestrickt ist: Als Selektionsbetrieb, der er ist, sei er fixiert auf irgendwas, womit sich vergleichen läßt, und daß sei derzeit der berühmte Journal Impact Factor.

Murray-Rust postuliert die Frage, die sich heute jede junge Wissenschaftlerin systemnotwendig stellen muß:

Do I publish where it is openly visible or where it advances my career and institutional standings?

Sein Appell:

Reward research which is openly visible and which strives to allow reuse of the research. Do not reward research which is closed.

Ich finde, das ist eine spannende Frage: Bauen wir eine Killer App — oder müssen wir den Wissenschaftsbetrieb umwälzen?

(Abb. lizensiert unter CC-BY-SA, Gideon Burton: Peer Review Monster)

Der HOBSY-Workshop an der TIB/UB, festgehalten von Bernhard Tempel.

Die Foliensätze der Vorträge werden nach und nach hier gesammelt. Notizen und Ergänzungen zum Workshop finden Sie in den vorangegangenen und noch kommenden Beiträgen hier im Blog.

(Vgl. die erste Hälfte)

5. Katalogübersicht in HOBSY-Katalogen (Manfred Nowak – TIB/UB)

• Ziel: bessere Übersicht der Katalogauswahl (bisher nur nach Zufall: Reihenfolge des Beitritts zu HOBSY)
• Idee: HOBSY-Seite gleich durch neue Katalog-Auswahl ersetzen (altes Layout stammt von 2002 – bald 10jähriges Jubiläum)
• Vorschau: http://www.hobsy.de/katalogauswahl/

6. Libconnect (Christian Hauschke – Bibliothek der Fachhochschule Hannover)

• „Wir haben hier jetzt eine Weltpremiere“ (Auf jeden Fall ist es eine Hannoverpremiere)
• EZB und DBIS in Typo3 einbinden. FHH-Bibliothek hat diese Typo3-Extension, die als AUftragsarbeit von Agentur entwickelt und Open Source zur Verfügung gestellt wurde, jetzt versuchsweise in ihre Website eigebunden.
• Verschiedene Arten der Einbindung, z.B. Hosting anderswo, aber Layout angepaßt an eigene Website; oder: Javscript-Mashup, z.B. delicious-Links der FHH-Bib und der TIB/UB; hier: enge Einbindung durch eine Typo3-Extenion, die Daten über XML-Schnittstelle austau
• Fehler und Probleme der Extension werden von FHH-Bib jetzt zusammen mit den Urhebern, der SUB Hamburg, gelöst
• DBIS komplexer in Darstellung, mehr Aufwand auch für optische Anpassung. EZB in FHH-Bib quasi schon im Produktivbetrieb
• Erweiterung ist Open Source, dadurch gute Nachnutzbarkeit.
• Idee aus TIB/UB: Analog eine Open-Source-Typo3-Extension für LOTSE? (Integration von LOTSE in die TIB/UB-Homepage)

7. YQL-als Datenschnittstelle (Stefan Goetz – Arbeitsgemeinschaft Hannoverscher Behördenbibliotheken)

• Ziel: Interesse wecken; noch am Anfang der Beschäftigung, kein fertiges Produkt/Konzept
• YQL sehr reduzierte Variante von SQL
• YQL kennt nur sehr wenige Statements verglichen mit SQL (http://developer.yahoo.com/yql/guide/statement_summary.html) Vgl. zu YQL insgesamt: http://developer.yahoo.com/yql/
• Ausgabe optional in JSON, was sehr einfache Einbindung von strukturierten Daten in beliebige Websites erlaubt, z.B. Ergebnis einer Abfrage nach neu erworbenen Titeln zu Thema XY, die sich immer wieder aktualisiert
• Livedemo: Konstruktion und Ausführung einer Query bei arXiv
• Nützlich im Kontext open data bzw. open data Voraussetzung für entsprechende Dienste
• weiterhin: Kontext open government (Transparenz von Verwaltungshandeln)
• Bibliothekarische Anwendung: Abfrage DDC-Notationen bei DNB (wegen https nicht mit jedem Client möglich, REST mit YQL hilft): Verknüpfung von BASE und DNB-Daten als Beispiel

8. Bibliotheks-Apps für Smartphones (Lambert Heller – TIB/UB)

• http://www.slideshare.net/lambo/hobsy2011
• Definition Smartphone
• Wichtigkeit des Themas
• Wie sieht der Markt aus?
• Schwerpunkt: Was gibt’s schon an Anwendungen für Bibliotheken?
• Weiterlesehinweise (gut bestelltes Feld)
• Neues Arbeitsgefühl durch Touchscreen (analoge Erfahrung zu Fenstermanager beim PC Mitte der 1990er Jahre)
• Charakteristisch: Zahlreiche Sensoren (Kamera, GPS-Modul, Bewegungssensoren etc.)
• Voraussetzung: günstige Datenflatrates („always on“ setzt sich durch)
• neues Konzept der Verteilung von Anwendungen („App-Store“)
• Heller vor drei Jahren: Ist nur Spielzeug für Technikfreaks. Heute zu revidieren (mit quantitativen Daten untermauert: heute schon 1 Millarde Smartphones von weltweit 4 Millarden Handys. Von neuen Handys schon 33 % Smartphones
• Aus Sicht der Anbieter: Hälfte der Anfragen an Google kommen schon von mobilen Endgeräten, bei Facebook: ein Drittel etc.
• Perspektive: in wenigen Jahren gleichviele bis mehr mobile Endgeräte
• Übersicht über Plattformen; auffällig: 600% Wachstum bei Google Android in 2010 (Marktanteil 33%), Gewinn hingegen bei Apple mit AppStore gigantisch ($1.782.000.000), alle  anderen Plattformen: Größenordnung $100.000.000
• Blackberry: Smartphone-Modell der Vergangenheit, Symbian „sowas von Vergangenheit“, „Entwicklung verschlafen“
• Gemeinsame Plattform: HTML5 + HTTP-URI + JavaScript + Geräte-API
• Einschränkung: nur online? Kein Thema mehr, auch Browser als Plattform für Offline-Anwendungen längst möglich und Trend (vgl. VMware)
• Vorschlag für Sortierung von bibliothekarischen Anwendungen (mit Ranking):
• a) lokale Infrastruktur:
  • Beschilderung in puncto Mobilgeräte. Kann man nicht mehr einfach verbieten, eher: Ton aus, nicht telefonieren. Dem sollte Verbotsbeschilderung Rechnung tragen. Dies ist bereits Standard in vielen Bibliotheken.
  • Verfügbarkeit benutzerfreundliches WLAN? (Viele „Geschmacksrichtungen“: Eduroam, Gästeticket, Bezahlticket, freies Netz, Beispiel „Studentenstadt“ Exeter ist eine riesige WiFi-Zone)
• b) Sucheinstiege
  • BSB OpacPlus erste Anwendung für mobilen Katalog in Deutschland
  • nicht nur native Apps (vgl. VuFind)
• c) Ebook-Reader
  • textunes (Angebot von Hugendubel, analog zu iTunes, aber sehr beschränktes Angebot verglichen mit Amazon)
  • Sony-Reader (native Android-App)
  • dedizierte Geräte (Amazon Kindle)
• d) Lokalisierung
  • Standorte, Rauminformationssystem, bis zu Verlinkung von Katalog zu Regalstandort
• e) Soziale Präsenz, Chat etc.
  • Chat (via Skype, Textchat etc. -> ggf. auch als Mobile Anwendung anzubieten)
• f) QR-Codes und Co.
  • reales Beispiel schon in UB Heidelberg (man kann aus Katalog QR-Code zu einem Medium bekommen, abfotografieren und weiternutzen – statt Signatur auf Zettel zu schreiben und dann am Regal zu suchen)
• g) Augmented Reality
  • Livedemonstration: Shelvar – Augmented Reality App zum Finden verstellter Bücher

Diskussion

• Frage: Warum nicht eine App für HOBSY-Bibliotheken gemeinsam  entwickeln (lassen). Möglichkeit, sich innovativ zu zeigen und Nutzern  entgegen kommen.
• Hauschke:  Gibt schon ein Beispiel: App zur Nutzerkontoverwaltung (kostenlos  verfügbar): Edsync (siehe im Blog von Edlef Stabenau)
• Hauschke:  sinnvoller, erstmal vernünftigen Katalog ins Netz zu stellen, der  bereits mobiltauglich ist (VuFind oder sonstiger moderner Katalog, auch  Primo und Touchpoint können das schon)
• Selber entwickeln oder kaufen? (altes Thema) Frage der Nachhaltigkeit
• evtl. Thema für nächste HOBSY-Sitzung?
• Wie Seiten mobilgerätefreundlicher gestalten?
• Feig: Mobiloptimierte Seite nach eigener Erfahrung wesentlich besser nutzbar als App.
• Tempel: Apple schließt sich selbst ein, Android wenigstens offene Plattform, Zukunft: HTML5 und darauf basierende Browseranwendungen.

(Exportiert aus dem Etherpad zum Workshop.)

1. Hochschulbibliographie der MHH (Markus Schmiel – Bibliothek der Medizinischen Hochschule Hannover)

• Läuft seit 2008
• Motivation: Leistungsorientierte Mittelvergabe (LOM) anhand von Publikationsdaten
• Qualitätsprobleme bei Daten (Doppelmeldungen etc.)
• Ziel auch automatische Berechnung der LOM (erst unterdrückt, dann auf Wunsch des Präsidiums der MHH eingeführt)
• Hochschulbibliographie nur Nebenprodukt der professionalisierten LOM-Berechnung (kein Nachteil)
• Pubmed zentraler Ausgangspunkt der Metadatenerfassung; nur wenige Artikel nicht in Pubmed und müssen manuell ergänzt werden
• Zentrale Information zum Thema auf der Website der MHH: http://www.mh-hannover.de/bibliothek_hobib.html
• MHH-Bibliographie http://www.refworks.com/refshare/?site=047931198213200000/RWWS6A619751/000031199720621000
• Tag „Hochschulbibliografie“ im Weblog der MHH: http://mhhbibliothek.wordpress.com/tag/hochschulbibliografie/

• RefShare zur Präsentation der Hochschulbibliografie
• Eingabefehler manuell korrigieren, ggf. nach Nachforschung
• Publikationstypen nicht „bibliothekarisch“, nicht einmal logisch, sondern vor allem historisch gewachsen.
• Problematik der Mehrfachmeldungen; jetzt nur noch Meldung von Autoren der eigenen Abteilung
• Sonderfall „Buchfächer“ (u.a. Medizingeschichte, -ethik): quasi fiktive Impactfaktoren
• RSS-Feed aus Bibliografie ins Weblog der MHH eingefügt
• „Weihnachtsbibliografie“: „Da gucken se alle rein“ – beliebteste Ausgabeform (pdf)
• Zahlreiche Ausgabeformate: RefShare, pdf (Weihnachtsbibliografie), Forschungsbericht, LOM (‘geheim’) – alles aus derselben Datengrundlage
• Ergebnis: große Transparenz der Mittelverteilung
• Hauptzeitraum der Meldungen: letzte sechs Wochen des Jahres (schwierig für Bearbeitung in Bibliothek)
• 75% aus Pubmed importiert, Rest: Buchexporte, sehr geringer Teil: vollständig manuell erfassen
• Viele statistischen Auswertungen möglich, „Impact-Punkte“ je Autor, ggf. sortiert nach Instituten etc.
• keine öffentlichen Rankings gewünscht
• nicht gemeldete Publikationen kommen nicht in die Bibliografie (kein Ehrgeiz seitens Bibliothek für Ergänzungen – wahrscheinlich zu aufwendig)
• Personalaufwand: ca. 1/2 Stelle in der Bibliothek (Dez. bis März 1 Person vollständig mit beschäftigt)
• Primär wird die Bibliographie angesehen um herauszufinden, ob man seine Publikation schon gemeldet hat. Darum findet der Großteil der Zugriffe auf das aktuelle Jahr statt.
• Ca. halbe Stelle erforderlich, um das zu stemmen
• Repository, Open Access: kein Thema, einzig Impact Factor zählt (sehr konservativ)
• Eine Kollegin prüft, ob Speichern des Postprints im Intranet rechtlich zulässig

2. Informationskompetenz und E-Learning an der TIB/UB (Kati Koch – TIB/UB)

• Seit 2007 Stelle für Informationskompetenz an TIB/UB
• An Aufgabe IK alle Standorte beteiligt (Auskunftsbereiche, Fachreferate): AG IK
• Schulungsforum, AG Schüler (am Anfang)
• Maßnahmen (v.a. aktivierende Lernmethoden, technisch unterstütz durch „Education Center’ – speziell konfigurierte Notebooks für Übungen); Personal: nicht Lehrer, sondern Moderator; Methode wird auch versucht auf Studierende zu übertragen
• Werbung ist wichtig, bei Hochschulveranstaltungen dabei sein und Bibliothek+Möglichkeiten vorstellen (Studierende ansprechen)
• Details zu Aktivitäten, Kooperationen (intern und extern) etc. siehe Präsentation
• Aufwand und Nachfrage nicht überall im richtigen Verhältnis (Problem auch in anderen Bibliotheken)
• Entwicklung „nützlicher“ Informationsdienste, die auch genutzt werden
• Interessantes Detail: Verschiedene Varianten der Videoproduktion, die TIB/UB durchgespielt hat. Wichtige Ziel: YouTube-Channel für alles, plus Links zu Videos dort, wo Benutzer die Informationen benötigen
• Screenr als schnelles Tool: quick and dirty, aber nützlich (auch intern anwendbar! also für Mitarbeiter)
• maximale Länge 90 Sekunden (wie im Radio seit Ende der 1980er Jahre, um die Aufmerksamkeitsspanne nicht zu überdehnen)
• Livedemo Screenr: Es wird deutlich, daß man ohne allzu große Einarbeitung rasch zu brauchbaren Ergebnissen kommt. Aufwand-Nutzen-Verhältnis sehr gut
• Routine beschleunigt die Screenr-Videoerstellung
• Idee: Benutzerfragen via Internet mit Screenr-Videos beantworten (Citavi probiert das gerade link: http://citavi.com/de/forms/supportanfrage.aspx unten rechts)

3. vufind – Erste Versuche (Christian Hauschke – Bibliothek der Fachhochschule Hannover)

• Folien:http://www.slideshare.net/hauschke/hobsy2011vufindpptx
• Schon auf vorigem HOBSY-Workshop Idee diskutiert, vufind für HOBSY-Katalog zu verwenden.
• ähnliches System wie Primo oder … – technisch und funktional gar nicht so unterschiedlich, aber open source
• Folien schon auf http://bibhann.wordpress.com/2011/06/23/vufind-beim-hobsy-workshop-2011/ verlinkt.
• Interessant: von vornherein geeignet für mobile Endgeräte, gesonderte App nicht erforderlich!!!
• Automatisch guter Permalink vergeben.
• sehr lebendige Benutzer- und Entwicklerszene, Chefentwickler diskutiert auf Mailingliste mit (Kulturschock im Vergleich mit Entwicklungszyklen bei OCLC/PICA-Systemen)
• Ab 1.7.2011 offizielles Angebot von VZG für vufind-Unterstützung: Alle Metadaten aus dem CBS gehen auch in vufind-geeigneten Index (Aktualisierung über Nacht).
• Einsatz bereits in: Villanova University, TUB Hamburg-Harburg, VZG (Suchkiste)
• Interessant: Integration von Website / Weblog der Bibliothek in den Suchindex, einschl. Facetten-Browsing in den Ergebnissen
• „Keine Amateurgeschichte für kleine Kirchenbibliotheken, sondern ein erwachsenes Softwaresystem.“
• Frage Nowak: Ausleihschnittstelle? Teil des Hostings bei VZG? Hauschke: Glaube ja (Benutzerkonto über DAIA):
  • Benutzerkonto (was hat Nutzer X ausgeliehen?) ist nicht teil von DAIA, sondern der Benutzer-unabhängige Status (ist Titel X verfügbar und wenn nicht wann wieder?)
• Cooles Detail: Irgendwie FRBRisiert vufind die Titel, bei einer Beisielsuche werden andere Ausgaben / AUflagen des angezeigten Werks in Randspalte angezeigt. Vermutung: Wenn Titel und Verlag identisch wird Werkidentität vermutet.

4. Das ISBN-Tool AutoLink TIB/UB (Bernhard Tempel – TIB/UB)

• Dokumentation und Anleitung zur Anpassung an den eigenen Bibliothekskatalog: http://www.tempelb.de/autolink-tibub/
• Voraussetzung: Als SSG-Fachreferent Vollständigkeit beim Erfassen neuer Literatur angestrebt
• Notwendigerweise viele Online-Quellen, z.b. keine Nationalbiblografie im angelsächsischen Raum
• ISBN kann „per Hand“ recherchiert werden („Hat TIB diesen Titel bereits?“), aber das ist mühselig
• Clientbasierter automatischer Abgleich, Abgleichergebnis wird in die jeweilige Webite neben der ISBN eingeblendet
• Als Plattform Greasemonkey gewählt, Erweiterung für hausgemachte Skripte im Browser Mozilla Firefox
• Automatisch wird beim Abgleich Link in den TIB-Katalog erzeugt, unter Nennung der Signatur, und je nach Ergebnis (positiv/negativ) visuell hervorgehoben
• Sehr nerdige Präsentation. Bernhard Tempel verändert im Zuge seiner Präsentation rasch den Quellcode seines skripts, um es auf den Katalog einer anderen Bibliothek anzupassen.
• Fazit: Greasemonkey ist toll

Mendeley hat heute ein interessantes Feature eingeführt. Das Taggen von Artikeln wird dort nun besser unterstützt. Zu jedem benutzten Tag kann von jedermann eine gemeinschaftliche Begriffsdefinition für diesen Tag erstellt, oder eine vorhandene Definition bearbeitet werden. Von jedermann erstellen, durch jedermann bearbeiten? — Richtig, es funktioniert wie eine Wiki-Seite. Neu ist dieses Konzept jedoch nicht.

Ein „Social Reference Management“-System mit diesem Feature gab es vor ziemlich genau fünf Jahren schon mal, Connotea. (Connotea News, mein Kommentar damals bei Netbib). Connoteas Wiki-Seiten sind nun anscheinend weitgehend eingeschlafen, nur noch der Spam wuchert ungestört vor sich hin…

Mendeley verkörpert (neben u.a. ResearchGate und Academia.edu) eine neue Generation dieser Gattung Webdienste. Hier heißt das Vorbild nicht mehr delicious, sondern Facebook. Und Mendeley hat anders als CiteULike keine Sponsoren, sondern Venture Capital im Rücken, was sich in einer ganz anderen Entwicklungsgeschwindigkeit ausdrückt.

Die Masse an bibliographischen Angaben, die Mendeleys Benutzer miteinander teilen ist durchaus beachtlich.

Auf Grundlage dieser aggregierten Angaben ermittelt Mendeley gleichzeitig auch thematische Verwandschaften zwischen den Tags. Hier hört die Analogie zu bekannten Wikis wie der Wikipedia auf. Auch die Wikipedia ist zwar reich an thematischen Verknüpfungen, doch diese werden intellektuell gepflegt. — Wie man die Ansetzungen der Wikipedia zum halbautomatischen Taggen von Bibliotheksbeständen oder Websites benutzen kann, hatte ich zuletzt in meinem eigenen Weblog bzw. in einem Artikel für das Goethe-Institut beschrieben.

Lamber Heller

Einsortiert unter:3. Offene, webbasierte Systeme, Softwaretrends Tagged: Mendeley, Tagging, Wiki-Funktionalität

Die systematische inhaltliche Erschließung von Literatur könnte und sollte heute besser in der Wikipedia stattfinden, denn die Wikipedia ist ein überlegener Thesaurus, und mit Unterstützung durch automatische Verfahren läßt sich vermutlich ein einfacher gemeinschaftlicher Erschließungsprozeß konstruieren. Diese These hatte ich im letzten Jahr zur Diskussion gestellt, und kürzlich durch Mockups ein wenig anschaulicher gemacht. Magnus Manske, einer der Erfinder der Software MediaWiki, der technischen Basis der Wikipedia, hat nun mit LITurgy den ersten funktionstüchtigen Prototypen für dieses Sacherschließungsverfahren geschaffen.

Zum Ausprobieren von LITurgy (setzt ein eigenes Benutzerkonto bei der Wikipedia voraus) lasse ich Magnus zunächst selbst zu Wort kommen:

Habe ein Demo, das (bei Bedarf) Publikationen aus PLoS abfragt und in eine Datenbank lädt (kann auch von anderen Quellen/mit anderen Methoden geladen werden).

Interface-Demo: Geh zu http://de.wikipedia.org/wiki/Special:MyPage/vector.js und füge die Zeile importScriptURI("http://toolserver.org/~magnus/liturgy/liturgy.js"); hinzu. Dann ein naturwissenschaftliches Thema ansteuern, z.B.: http://de.wikipedia.org/wiki/Ribosomale_RNA

Unter “Literatur” (wird bei Bedarf erzeugt) gibt’s ein StackOverflow-ähnliches Interface.

Was fehlt:

• Andere Methoden zum Datenbank-Seeding
• Sicherheit (jeder mit ein wenig Ahnung von JavaScript kann im Moment
  als jeder Wikipedia-Benutzer abstimmen…)
• Automatische Übernahme der Literatur in den WikiText
• Noch viel mehr…

Nachtrag: Es scheint, im gegenwärtigen Zustand funktioniert das Tool besser bei “speziellen” Themen als bei allgemeinen. Ein allgemein beschreibendes Paper zu “Krebs” wird eben kaum geschrieben während die Resultate z.B. zu http://de.wikipedia.org/wiki/Helicobacter_pylori ganz brauchbar ist.

Hinweis: Im Moment zeige ich nur PLoS-Review-Artikel an; Reviews sind normalerweise bessere Referenzen (“reviewed original research”:-) und nicht überspezialisiert. Hält auch die Kandidaten-Liste schön kurz…

Vielen Dank Magnus, du hast diese Idee wirklich greifbar gemacht!

An dieser Stelle ein dezenter Hinweis an interessierte Biblionik-LeserInnen: In der Weiterentwicklung dieses Prototyps schlummern zahlreiche spannende Hausarbeiten und Papers in Fächern wie Wissensorganisation und Informationsmanagement, vielleicht auch Software Engineering.

Ich möchte die kurz- und mittelfristigen Zielen, die Magnus nennt, und die ich in meinen beiden vorangegangenen Biblionik-Beiträgen (s.o.) genannt hatte, noch um drei z.T. langfristigere Perspektiven ergänzen:

• Der Maui Indexer bietet neben der Wikipedia-basierten Indexierung auch eine simple Keyword-Extraktion an. Wer mein Beispieldokument aus dem letzten Beitrag (Credit Rating Prediction Using Ant Colony Optimization von David Martens et al.) durch diese Maui-Demo laufen läßt, wird feststellen, daß u.a. “AntMiner” extrahiert wird. Das ist der Namen eines Datamining-Tools, über das es einige wissenschaftliche Publikationen, aber bisher noch keinen eigenen Wikipedia-Artikel gibt. Allein schon, um das so gewonnene Wissen nicht zu verlieren, müßte in so einem Fall eigentlich Thesaurusarbeit innerhalb der Wikipedia stattfinden. Z.B. müßte, wenn in mindestens zwei wissenschaftlichen Publikationen von unterschiedlichen Autoren ein solches Stichwort zutage gefördert wurde, das jeweilige Lemma in der Wikipedia angelegt werden. Die Stärke der Wikipedia ist jedoch gerade, daß sie ein lebendiges Produkt ihrer Autorengemeinschaft ist — und diese kann in puncto Relevanzkriterien auch eigenwillig sein. Hier wird es spannend: Wie könnte ein Wiki-Thesaurus aussehen, der die lebendige Wissenstruktur der Wikipedia aufgreift, sie jedoch selbständig  ergänzt, d.h. unabhängig von den Relevanzkriterien oder anderen Spezifikationen der Wikipedia als eines Lexikon-Projekts?
• Das Konzept Wikipedia ist vielfach kopiert und variiert worden. Bücherregale voller Literatur über Wikis im Unternehmen und ähnliche Szenarien machen deutlich, daß der Wiki-Weg der kollaborativen Wissensorganisation nicht nur von offenen Web-Communities wie der Wikipedia beschritten werden kann. Was wäre, wenn man einen Wiki-Thesaurus (bei dem es sich auch um die Kopie eines Ausschnitts der Wikipedia handeln kann, aber nicht muß) von einer streng begrenzten Autorencommunity entwickeln läßt, ggf. auch hinter der Firewall einer Firma oder einer Hochschule? — In einem solchen Szenario könnte eine halbautomatische Inhaltserschließungs-Komponente z.B. dabei helfen, obskure oder interne Medien in die Themenstruktur des internen Wikis hineinzubringen. (Herzlichen Dank an Leif Singer, Wissenschaftler an der Leibniz Universität Hannover, für den Hinweis auf dieses Szenario und zahlreiche weitere Anregungen!)
• Stefan Gradmann weist (Ideen wie die “Nanopublikation” von David Shotton und anderen aufgreifend) darauf hin, daß heute nicht mehr entlang von Mediencontainern indexiert werden muß. Vielmehr kann und sollte in die digitalen Texte eingestiegen werden, bis hinunter zu kleinsten bedeutungstragenden Einheiten wie einzelnen Begriffen, Daten und ihren Beziehungen untereinander, innerhalb eines Satzes oder eines Textteils. — Mit der Erschließung (selektierter?) Publikationen in die Tiefe zu gehen — ist vielleicht auch dies eine Perspektive der “Sacherschließung in und mit der Wikipedia”?

Genug der Spinnerei für heute, ich wünsche allen LeserInnen von Biblionik noch ein schönes Hasenfest!

Keine Tags zu diesem Beitrag.

In dem zurückliegenden Beitrag Sacherschließung von Literatur in und mit der Wikipedia — eine Spielidee hatte ich die Grundidee und die Potentiale einer kollaborativen Sacherschließung der Wikipedia-Community mittels der Wikipedia als Quasi-Thesaurus zur Diskussion gestellt. Dieser Beitrag ist eine Fortsetzung. Zum besseren Verständnis empfiehlt es sich daher, zunächst einen Blick in den alten Beitrag zu werfen.

Wie wird ein Aufsatz in und mit der Wikipedia erschlossen?

Um in diesem neuen Blogbeitrag zur Diskussion zu stellen, wie so etwas aussehen könnte, habe ich mit einigen Mock-ups die Erschließung eines realen Aufsatzes in und mit der Wikipedia dargestellt.

Mein Ausgangspunkt ist die frei zugängliche Preprint-Version des Zeitschriftenaufsatzes Credit Rating Prediction Using Ant Colony Optimization von David Martens et al. In BASE (Bielefeld Academic Search Engine) findet man die Metadaten, die zu diesem Preprint gehören, hübsch zusammengestellt. Datensätze wie dieser müßten, z.B. aus BASE, im ersten Schritt als Datensätze in die Wikipedia übernommen werden. Für Wikipedia-Benutzer sähe so ein importierter Datensatz vielleicht aus wie in Abb. 1.

Abb. 1: Datensatz in der Wikipedia-Bibliographie-Sicht

Woher kommen die vorgeschlagenen “Inhaltlichen Zuordnungen”?

Durch Indexierung mit Maui Indexer oder einem ähnlichen Tool sind im Abschnitt „WP:Inhaltliche Zuordnung“ automatisch Links zu Wikipedia-Artikeln hinzugefügt worden, die thematisch zu diesem Aufsatz passen könnten.

Die Links in dem Beispiel sind übrigens erfunden, aber das Ergebnis könnte so ähnlich aussehen. Im Aufsatztitel ist z.B. von „Ant Colony Optimization“ die Rede. Die englischsprachige Wikipedia enthält einen gleichnamigen Eintrag zu dieser Methode. Statt „Ant Colony Optimization“ könnte in der deutschsprachigen Wikipedia automatisch „Ameisenalgorithmus“ angezeigt werden, da dieser Wikipedia-Eintrag mit „Ant Colony Optimization“ verlinkt ist.

Die automatisch hinzugefügten Links landen zunächst im Feld „unbestätigte“. Erfahrungsgemäß werden bei der automatischen Indexierung häufig offensichtlich falsche Vorschläge gemacht. Diese können von jedem registrierten Benutzer durch Klick auf „entfernen“ beseitigt werden. Automatische Zuordnungen, die von Benutzern bestätigt worden sind, sollten sich hingegen nicht so einfach entfernen lassen, intellektuell vorgenommene Zuordnungen natürlich auch nicht.

Wie kommt es zu “bestätigten Zuordnungen”?

Wenn man in Abb. 1 auf den Vorschlag „Insolvenzprognoseverfahren“ klickt, hätte man den Wikipedia-Eintrag zu diesem Thema vor sich. Unten auf dieser Seite, unter „Literatur“, werden automatisch die zuletzt indexierten Literaturvorschläge aufgezählt. Der Beispiel-Aufsatz würde dort etwa so erscheinen wie in Abb. 2.

Abb. 2: Literaturvorschlag im Artikel entdecken

Jeder Wikipedia-Leser, der den Artikel überfliegt, stolpert im Literatur-Abschnitt über den vorgeschlagenen Aufsatz, neben der Aufforderung, diese Zuordnung zu bestätigen. Bei der Gestaltung dieser Aufforderung können Prinzipien, die sich in der Sacherschließung traditionell bewährt haben, ansatzweise berücksichtigt werden:

1. Grundlage der richtigen Erschließung ist die Betrachtung des zu erschließenden Objekts. Deshalb ist es hier wichtig, den Link zum Volltext besonders hervorzuheben.
2. Das verwendete Schlagwort sollte so genau wie möglich passen. Den Begriff „genau“ kann man in diesem Zusammenhang ruhig mehr als ein mal verwenden…
3. Mehrere Schlagworte können hilfreich sein — womit wir bei Abb. 3 sind, die darstellt, wie es nach dem Bestätigungs-Klick weitergeht.

Die Bestätigung wird mit dem Hinweis quittiert, daß der automatisch ermittelte Literaturvorschlag erst nach Bestätigung durch zwei registrierte Wikipedia-Autoren in die Literaturliste aufgenommen wird. (Vgl. Abb. 3. Wann welcher automatische Vorschlag von welchem Benutzer bestätigt wurde, sollte dauerhaft nachvollziehbar bleiben, wie andeutungsweise in Abb. 1 zu sehen.)

Abb. 3: Dialogfenster nach Zuordnung des Literaturvorschlags

Danach wird dem Benutzer angeboten, mit dem Zuordnen fortzufahren. Zwei Anknüpfungspunkte liegen dabei nahe:

1. Dem Benutzer werden weitere Wikipedia-Einträge („Ameisenalgorithmus“, „Basel II“…) angezeigt, die automatisch zu dem Aufsatz ermittelt worden sind. Hier findet gewissermaßen ein Perspektivenwechsel statt: Eben noch beschäftigte sich der Benutzer mit dem Thema des Wikipedia-Eintrags und ist dann auf vorgeschlagene Literatur dazu gestoßen. Nun schlüpft er in die Rolle des Bibliothekars/Dokumentars, der dieses eine Literaturstück vor sich hat und überlegt, zu welchen anderen Themen es passt…
2. Dem Benutzer wird darüber hinaus angeboten, sich alle weiteren Literaturvorschläge anzeigen zu lassen, die zu Wikipedia-Einträgen in den Wikipedia-Kategorien „Bonitätsprüfung“ und „Unternehmensbewertung“ gemacht worden sind. Gewissermaßen wieder ein Rollenwechsel — diesmal zum Fachreferenten, an dem alles vorbeiströmt, was (vielleicht) zu seinem gegebenen Themengebiet paßt. Diese Sicht kann z.B. für Wikipedia-Benutzer reizvoll sein, die sich dauerhaft für einen bestimmten Themenbereich interessieren. Für den Benutzer sehen die Vorschläge so ähnlich aus wie in Abb. 1, vielleicht ergänzt um den Kategorienbaum der Wikipedia, in dem er browsen kann.

Exkurs zum Schlagwort “Insolvenzprognoseverfahren” im gezeigten Beispiel

Ausblick: Wie kann man selbständige Literatur in und mit der Wikipedia erschließen?

Auch die Sacherschließung selbständiger Literatur — also von Büchern, bei denen es sich nicht um Aufsatzsammlungen o.ä. handelt — in und mit der Wikipedia wäre einen Versuch wert. Zumal angesichts der maroden Alternativen, siehe den obigen Exkurs.

Anders als bei Online-Aufsätzen ist der Volltext von Büchern leider selten einen Mausklick weit entfernt. Mir fallen zwei Szenarien zur Sacherschließung von Büchern in und mit der Wikipedia ein:

1. Viele Bücher werden im Bibliothekskatalog mittlerweile mit Verlags- oder Klappentexten, Rezensionen, Scans von Inhaltsverzeichnissen oder eingeschränkten kostenlosen Vorschauen angereichert. Denkbar wäre es, nur Bücher in die automatischen Vorschlagslisten aufzunehmen, die bereits mit solchen Materialien angereichert worden sind. Ich behaupte, daß sich viele Bücher allein schon anhand des Inhaltsverzeichnisses exakt und umfassend verschlagworten lassen.
2. In Kooperation mit einer Bibliothek bekommen Bücher beim Ausleihvorgang ein formschönes Papier-Lesezeichen. Darauf wird an den Benutzer appelliert, das jeweilige Buch in der Wikipedia-Bibliographie aufzurufen und zu prüfen, ob alles stimmt.

Ein Demonstrator für Dublin Core 2011?

Vom 21.-23. September 2011 findet die DC-2011 in Den Haag statt, die diesjährige Konferenz der Dublin Core Metadata Initiative, einer etablierten weltweiten Metadaten-Organisation. Kürzlich wurde die Deadline für Einreichungen auf den 30. April verlängert. Wer will dabei helfen, bis September einen kleinen Demonstrator zur Sacherschließung in und mit der Wikipedia zu bauen? Wenn sich das als machbar herausstellt, wäre bis zum 30. April ein englischsprachiges Abstract bei der DC-2011 einzureichen.

Abschließend bedanke ich mich herzlich bei Kai Eckert, der mit einigen beiläufigen Bemerkungen bei einem Flurgespräch während des BibCamp 4 über Metadaten mit transparenter Herkunft und Geschichte sowie über die DC-2011 indirekt zu diesem Blogartikel beigetragen hat.

Tags:Bibliographie, mock ups, preprint version, SWD, Wikipedia