Nach meiner Auffassung ist Umlaut (wie Link Resolver im Allgemeinen) eine spezielle Form einer Metasuche. Über eine OpenURL-Anfrage können mehrere Dienste und Quellen (SFX, CrossRef, Amazon, OCLC Worldcat, ISBNdb, LibraryThing, Google Books, HathiTrust, OpenLibrary, the Internet Archive, Worldcat Identities …) gemeinsam abgefragt werden und die Ergebnisse werden auf einer Seite zusammengefasst (siehe Beispiel). Das Zusammenfassen von Inhalten aus mehreren Quellen kann allerdings auch im OPAC bei einer Titelanzeige geschehen (siehe Beispiel).

Allgemein ist für die Zusammenfassung von Inhalten aus unterschiedlichen Quellen (Mashup-Prinzip) hilfreich, wenn auf einheitliche APIs und Datenformate zurückgegriffen wird. Das populärste Beispiel ist RSS (bzw. ATOM). SeeAlso kann als API und Format für einfachere Listen dienen und für komplexere Inhalte käme vielleicht die Universal Widget API (UWA) in Frage. UWA-Widgets können auch in eigene Seiten eingebunden werden. Einen OPAC als Widget gibt es ja schon – wie wäre es umgekehrt einen OPAC aus Widgets zusammenzusetzen? Ich denke, dass es noch einige Zeit dauern wird, bis sich neben ATOM/RSS weitere gute Standards für die Aggregierung von Inhalten auf Webseiten durchsetzen. Praktische Beispiele gibt es ja inzwischen immer mehr, gerade hat Lorcan Dempsey einige davon zusammengefasst.

Am 10.12.2002 veröffentlichte die Zeitung Chicago Tribute einen Artikel über den damaligen Konkurs der Flugline United Airlines. Der Artikel erschien auch im Online-Portal South Florida Sun Sentinel, das zum Tribune gehört. Inzwischen ist United Airlines wieder – mehr schlecht als recht – im Geschäft und der Artikel war im Sentinel über das Archiv abrufbar – im Google Cache kann man sich noch ein Bild davon machen. Wegen des Sturms am Wochenende suchten anscheinend mehr Sentinel-Nutzer nach “United Airlines” und stießen auf den Artikel, der – es war sonst wohl nix los – auf der Seite unter “Popular stories / most viewed” auftauchte. Die dort verlinkten, durch die “Wisdom-of-the-Crowds” ausgewählten Artikel werden nicht nur wiederum häufiger angeklickt sondern auch von Newsaggregatoren wie Google News eingesammelt. Die Agentur Income Securities Advisors Inc. bekommt den Artikel vom Newsaggregator über einen Suchalert und anstatt nochmal nachzurecherchieren schickt der betreffende Mitarbeiter eine Mitteilung an seine Kunden und an Bloomberg Terminal, das Informationsportal für Börsenhändler (die genaue Tickermeldung konnte ich nicht mehr ausfindig machen). Daraufhin werden UA-Aktien verkauft (durch Menschen oder Softwareprogramme, die den Ticker auswerten); als der Kurs fällt, verkaufen automatisch weitere Softwareprogramme und der Kurs stürzt bei einem Verkaufsvolumen von mehr als 20 Millionen $ von 12.45$ auf 3$ – bis der Handel ausgesetzt wird. Corey Rosenbloom hat in seinem Artikel eine Grafik ders Kursverlaufs.

Hm, das erinnert mich an Joseph Weizenbaums bereits 1976 erschienenes Buch “Die Macht der Computer und die Ohnmacht der Vernunft”. Irgendwo waren zwar noch Menschen beteiligt, aber die von ihnen geschaffenen Systeme (Online-Archive, Aggregatoren, Empfehlungs- und Alerting-Dienste, Börsenprogramme und – last-but-not-least – der alte “Schlawiner Kapitalismus”) beherrschen weitgehend das Geschehen. Ich habe die Geschichte in meiner Lehrveranstaltung verwendet, um verschiedene Informationsdienste zu illustrieren und auf die Bedeutung von Metadaten und Informationskompetenz hinzuweisen.

Eine eigene Darstellung der Geschehnisse von Sentitel vom 9.9. gibt es hier und ein passendes Video zur Bankenkrise gibt es von Extra 3.

Momentan überlege ich für die Webseite einer Veranstaltungsreihe mit Vorträgen, wie man am besten Weblog, Kalender und Literaturverzeichnis kombinieren könnte. Bislang gibt es für jede Veranstaltung einen eigenen Beitrag. Das Datum des Beitrags ist aber nicht das Datum der Veranstaltung, sondern das Veröffentlichungsdatum des Beitrags. Irgendwie müssten die einzelnen Beiträge aber auch noch in einem Veranstaltungskalender auftauchen; man könnte sie zum Beispiel zusätzlich bei Venteria oder bei LibraryThing local eintragen und die Daten von dort wiederum im Blog einbinden – was zumindest etwas umständlich klingt.

Zu jeder Veranstaltung gibt es passende Literatur, die natürlich auch irgendwie erschlossen sein sollte. Eine Möglichkeit wäre, für jedes Werk einen eigenen Blogeintrag zu erstellen, so wie es in Scriblio der Fall ist (übrigens auch mit Verfügbarkeitsstatus). Ein Vorteil dabei ist, dass zur Verschlagwortung von Veranstaltungen wie für Literatur die gleichen Tags für verwendet werden können. Die andere Möglichkeit wäre, eine Social Cataloging-Anwendung wie BibSonomy oder LibraryThing zu nutzen. Die Literatur wird also in einer eigenen Webanwendung verwaltet und muss irgendwie per Plugin in WordPress eingebunden werden. Für BibSonomy gibt es dieses WordPress-Plugin (sowie die Möglichkeit eines HTML-Export, der per JabRef-Filter angepasst werden kann) und für LibraryThing einen Widget-Generator. Leider lassen sich bei dieser Lösung Veranstaltungen und Literatur nicht gemeinsam erschließen und recherchieren. Bei der Vergabe von und dem Browsing über Tags ist jede Anwendung (Blog, Kalender, Literaturverwaltung) noch eine Insel. Wünschenswert wäre ein gemeinsames Tagging-Vokabular über mehrere Anwendungen – das wäre dann ein einfacher Fall von Semantischem Tagging … und wahrscheinlich erst etwas für 2009

P.S: Nein, ich habe nichts mit der “Jacobs University” zu tun, mein Name wird mit “k” geschrieben

Wirklich interessant werden solche aggregierenden Dienste meiner Meinung nach erst, sobald sich offene Standardformate zum Austausch von Kommentaren, Bewertungen, Tags etc. und anderen Metadaten durchsetzen. Bisher nicht bekannt in diesem Kontext war mir APML. Ein kritischer Punkt, der am Ende heftig diskutiert wurde, sind die Rechte an Metadaten und was juristisch und moralisch möglich und vertretbar ist. Ist es beispielsweise legitim, aus verschiedenen Social Networking-Plattformen soziale Graphen zusammenzuführen und weiterzugeben? Welche Rechte an Metadaten kann es überhaupt geben und welche lassen sich überhaupt durchsetzen? In jedem Fall spannend, wie es mit der Zusammenführung von Daten aus verschiedenen Diensten weitergeht.

Morgen nimmt Martin Memmel auch noch am Panel Social Media in der Wissenschaft teil, wo die “Möglichkeiten und Grenzen einer Wissenschaft 2.0″ diskutiert werden.

Angestoßen von einem Hinweis auf die Sammlung Ponickau an der ULB Sachsen-Anhalt und eine anschließende Diskussion um die andauernden Verwirrungen bezüglich URI, URN, URL Identifikatoren und Lokatoren, habe ich mir den DFG-Viewer etwas näher angesehen. Die Darstellung sieht nicht ganz so cool aus, wie bei The Open Library, dafür gibt es offene Schnittstellen. Digitalisate können dem Viewer per OAI oder direkter URL im METS/MODS-Format übergeben werden. Die einzelnen Seiten eines digitalisierten Buches und dessen innere Struktur (Gliederung) lassen sich dann durchblättern. Eine Volltextsuche ist anscheinend noch nicht implementiert und es fehlt eine eigene Zoom-Funktion; bislang ist es nur möglich zwischen verschieden großen Auflösungen zu wechseln, falls diese vom Repository ausgeliefert werden.

Ein Exemplar des auf INETBIB als Beispiel genannten Buches mit der VD17-Nummer 32:623995L ist in Halle digitalisiert vorhanden. Die Metadaten des Digitalisates können per OAI in METS/MODS abgerufen werden. Übergibt man nun dem DFG-Viewer die URL, kann das Digitalisat im DFG-Viewer betrachtet werden. Im Moment ist noch ein Schritt Handarbeit notwendig, da im DFG-Viewer ein falscher (?) OAI-Server für Halle eingetragen ist, aber grundsächtlich funktioniert das Mashup.

Statt spaßeshalber eine METS-Datei mit Pornobildchen zusammenzustellen, um sie im DFG-Viewer anzeigen zu lassen, habe ich mir ein zufälliges Digitalisat von Wikisource vorgenommen. In Wikisource gibt es für jedes Digitalisat eine Indexseite, auf der einige Metadaten und die Seiten der digitalisierten Vorlage aufgelistet sind. Aus dieser Seite kann eine METS/MODS-Datei erzeugt und an den DFG-Viewer geschickt werden. Zwei bis drei Stunden später steht ein einfaches Perl-Skript, dass aus der Index-Seite in Wikisource eine METS-Datei erzeugt. Und so sieht es im DFG-Viewer aus (Draufklicken=größere Ansicht):

Das ganze ist nur ein schnell gehackter Proof-of-concept. Eine stabile Verwendung der Metadaten aus Wikisource sollte aus einer OAI-Schnittstelle bestehen, die METS/MODS liefert (und MABXML für ZVDD). Falls jemand Interesse hat (Bachelor/Diplomarbeit, eigenes Projekt etc.), biete ich gerne meine Unterstützung an – umsetzen muss er es jedoch erstmal jemand anderes da ich nicht dauernd nur neue Projekte anfangen kann.

Wie Edlef bemerkt, kann man ausgeliehene Bücher ja auch “in citavi, Librarything oder beliebigen anderen Literaturverwaltungssystemen für sich selbst [speichern]” – was prinzipiell tatsächlich die bessere Variante ist. Nur sollten Bibliotheken Nutzer dabei nicht in “kenn wa nich, wolln wa nicht, ham wa nich, geht nich”-Manier abspeisen, sondern aktiv für die Verknüpfung von Bibliothekssystemen mit Literaturverwaltungssystemen sorgen. Alles was über ein Feld “Ausleihen automatisch bei BibSonomy/LibraryThing/etc. eintragen” im Benutzerkonto hinausgeht, ist nicht zumutbar und überflüssig.

Ein Lösungsansatz gemäß Serviceorientierter Architektur sähe folgendermaßen aus:

Das Ausleihsystem bekommt eine Webschnitttstelle, über die Nutzer abfragen können, welche Medien sie zur Zeit ausgeliehen haben. Wenn dabei RSS oder ATOM eingesetzt wird (natürlich nur über HTTPS und mit Passwort), sollten gängige Feed-Aggregatoren damit klarkommen. Bisher muss der Zugang zum Ausleihsystem für jede Anwendung wie Bücherwecker einzeln gehackt werden, was mühsam und fehleranfällig ist. Die ausgeliehenen Werke sollten (per URL-Parameter steuerbar) in möglichst vielen Datenformaten beschrieben werden. Prinzipiell reicht aber auch die Standard-Kurztitelanzeige und ein Identifier, mit dem z.B. über unAPI weitere Details in verschiedenen Datenformaten angefordert werden können. Zusätzlich zu diesem Pull-Verfahren sollte die Möglichkeit gegeben werden, á la Pingback andere Dienste zu benachrichtigen sobald ein Benutzer ein Medium ausgeliehen hat.

Den Rest (das automatische Eintragen in eine Literaturverwaltung) kann – und sollte – bei gegebenen APIs eine eigene Anwendung übernehmen. Es würde mich nicht wundern, wenn die fixen Entwickler von LibraryThing das selber basteln oder sich ein Student im Rahmen einer Diplom- oder Bachelorarbeit daran setzt. Sobald saubere, einfache Schnittstellen verfügbar sind, ist der Aufwand für neue “Mashups” und Zusatzdienste minimal.

Bei einer Google-Suche nach der (leider etwas schwer auffindbaren) Seite der Bibliothek im Kurt-Schwitters-Forum Hannover bin ich dann auf das Weblog Bibliotheken in Hannover gestoßen, in dem Christian Hauschke und Manfred Nowak vom Workshop “Social Software in hannoverschen Bibliotheken” berichten. Christians Ausführungen zu Lageplänen mit Google Maps (einen Lageplan in Google Maps einzuzeichnen, dauert auch ohne Vorkenntnisse höchstens zwanzig Minuten) möchte ich um eine Mashup-Idee ergänzen, die ich bereits neulich in meiner Lehrveranstaltung vorgestellt habe: Mit dem Perl-Modul PICA::Record lässt sich der Gesamtkatalog Hannover über SRU nach Bestandsdaten durchsuchen – dazu ist lediglich in diesem Beispielskript die Datenbank 2.92 statt 2.1 auszuwählen. Die so ermittelten Bibliotheken können dann mit etwas Bastelei in Google Maps angezeigt werden. Statt oder neben einer Liste der Bestandsnachweise wird dann zu einem Titel geografisch angezeigt, in welcher Bibliothek das Buch vorhanden ist. Mit Zugriff auf die Exemplardaten in den einzelnen OPACs könnte sogar noch angezeigt werden, ob ausleihbare Exemplare gerade vorhanden sind – wie das im Ansatz geht, steht in diesen Folien.

The “Grid Services” that OCLC is going to provide is based on the “OCLC Services Architecture” (OSA), a framework by which network services are built – I am fundamentally sceptical on additional frameworks, but let’s have a look.

The basic idea about services is to provide a set of small methods for a specific purpose that can be accessed via HTTP. People can then use this services and build and share unexpected application with them – a principle that is called Mashups.

The OCLC Grid portfolio will have four basic pillars:

network services: search services, metadata extraction, identity management, payment services, social services (voting, commenting, tagging…) etc.

registries and data resources: bibliographic registries, knowledge bases, registries of institutions etc. (see WorldCat registries)

reusable components: a toolbox of programming components (clients, samples, source code libraries etc.)

community: a developer network, involvement in open source developement etc.

Soon after social services were mentioned, at heavy discussion on reviews, and commenting started – I find the questions raised with user generated content are less technical but more social. Paul stressed that users are less and less interested in metadata but directly want the content of an information object (book, article, book chapter etc.). The community aspect is still somehow vague to me, we had some discussion about it too. Service oriented architecture also implies a different way of software engineering, which can partly be described by the “perpetual beta” principle. I am very exited about this change and how it will be practised at OCLC|PICA. Luckily I don’t have to think about the business model and legal part which is not trivial: everyone wants to use services for free, but services need work to get established and maintained, so how do we best distribute the costs among libraries?

That’s all for the introduction, we will get into more concrete services later.

Wie bei vielen neuen Innovationen in den letzten Jahren werden auch bei den Mashups die in der Anfangsphase bestehenden Beschränkungen der genutzten Software, in diesem Falle u. a. des Browsers, ausgehebelt oder umgangen (siehe Theurer, D. (2007), S.58 – 63). Mashups nutzen zu einem großen Teil Javascript, um Anfragen zu senden, Informationen auszuwerten und dem Benutzer Funktionalität zu bieten. Ein Mashup verbindet nun zwei verschiedene Web-Dienste von unterschiedlichen Domains z.B. Fotos von flickr und deren Aufnahmestandort angezeigt auf Google Maps miteinander. Die bestehende Beschränkung im Browser ist der Sicherheit geschuldet und verhindert die Ausführung solcher domain-übergreifender Zugriffe durch Javascript (Crossdomain-Restriktion). Bei Mashups werden nun an dieser Stelle bewusst Restriktionen der Browser durch verschiedene Workarounds (Proxy-Weiterleitung/JSON-Aufrufe) umgangen, um ein Mashup überhaupt zu ermöglichen.

Mittlerweile gibt es nicht nur eine riesige Anzahl von Mashups und Web-Diensten mit offenen Schnittstellen, die diese ermöglichen – zu sehen bei Programmable Web – sondern auch eine wiederum ganz neue Art von Anwendung, die u. a. auch von Tim O’Reilly als neuer Meilenstein in der Geschichte des Internets bezeichnet wurden – die Mashup-Editoren. Diese Editoren sollen es einem Benutzer ohne großes Hintergrundwissen ermöglichen, selbst individuelle und vor allem neue Dienste auf Basis bereits bestehender Angebote bzw. Informationsquellen zu erstellen. Viele bekannte Unternehmen u. a. Google mit dem Mashup Editor, Intel mit dem Mashup Maker gefolgt von Yahoo mit Pipes und auch Microsoft mit Popfly und IBM mit ihrem QEDWiki bieten ihre eigenen Entwicklungen mehr oder weniger frei zugänglich an. Insbesondere Yahoo Pipes mit einem sehr schönen und intuitiven Interface bietet dem gewillten Benutzer die Möglichkeit allem voran bestehende News-Feeds nach eigenen Wünschen zu filtern und/oder zu kombinieren, um so bestehende Angebote ganz neu und indivuell angepasst zu erweitern und stellt somit einen erheblichen Mehrwert für seine Nutzern dar. Diese neu erstellten Dienste können dann auch wieder exportiert werden und erneut als Basis für andere Anwedungen dienen z. B. für Pageflakes, iGoogle oder Netvibes, die beide personalisierte Portalseiten anbieten. So ist es möglich, sich ohne großen Aufwand sein ganz eigenes, speziell auf die individuellen Bedürfnisse zugeschnittenes Portal im Internet »zusammenzuklickern«. Auch wenn das in der Praxis nicht immer ganz so leicht durchzuführen ist, wie von den Entwicklerunternehmen angepriesen, mit ein wenig Hintergrundwissen als Basis und etwas Einarbeitungszeit sind auf jeden Fall sehr gut nutzbare Ergebnisse zu erzielen.