So wie ich das LIVE-Projekt verstanden habe, sollen bei der Olympiade 2008 sportliche Ereignisse “live” verschlagwortet werden, wobei freie Tags zeitnah mit Hilfe eines Thesaurus-Editors in die “Ontologie” eingearbeitet werden; das ganze basiert auf SKOS und ist damit weitgehend Semantic-Web-kompatibel – und ein Beispiel für Semantic Tagging. Mit Social Tagging hat das Projekt allerdings nur noch wenig zu tun. Falls sich dennoch normale Nutzer am Tagging der PR-Olympiade beteiligen dürfen, hier mal ein Vorschlag für die Tag-Cloud:

Aber zurück zum Semantischen Tagging: Die Bezeichnung ist eigentlich schon aus der Linguistik besetzt; dort wird unter Semantic Tagging die Erkennung und Auszeichnung von Namen und syntaktischen Strukturen in einem Text verstanden. Ein sehr einfaches Beispiel aus dem Web sind semantische HTML-Tags wie em, strong und cite; eine andere Form semantischen Taggings im Web, die eher in Richtung Auszeichnung von Daten geht, sind Mikroformate. Von dort lässt sich zwar wieder der Bogen zum Semantic Web spannen, aber eigentlich ist semantisches Tagging im Linguistischen Sinne etwas anderes: Gegeben ist ein Text, in dem einzelnen Bestandteile wie Subjekt, Objekt, Nebensatz, Personennamen etc. als solche markiert werden. Beim Social Tagging werden dagegen freie Tags an einen gesamten Text (oder ein anderes Objekt) angehängt, um seinen gesamten Inhalt zu beschreiben. Irgendwo sollte sich deshalb zwischen Semantischem Tagging innerhalb eines Textes und Semantischem Tagging als (Social) Tagging mit expliziter Semantik eine Grenze ziehen lassen.

Dachte ich. Bis ich entdeckt habe, was die Nachrichtenagentur Reuters Ende Januar online gebracht hat: Mit der kostenlosen Web-API “Calais” lassen sich Texte analysieren, indem Reuters Namen, Orte, Zahlen und andere Angaben extrahiert (siehe API-Dokumentation) und mit RDF auszeichnet. [via Taxonomy Watch] Ob die gefundenen Entitäten auch gleich mit URIs versehen werden oder ob nur ausgezeichnet wird, dass es sich beispielsweise um einen Firmennamen handelt, habe ich noch nicht rausgefunden – in jedem Fall dürften die extrahierten Terme gute Vorschläge für semantisches Tagging abgeben. Zum Ausprobieren kann dieses Formular verwendet werden.

Ach herrje – Ich weiß manchmal nicht, ob ich begeistert sein soll, in welch spannender Weise sich das Web zur Zeit weiterentwickelt oder ob ich daran verzweifeln sollte, wie komplex und schnell das alles geht. Inzwischen ist “Semantic Web” ja schon so hype, dass es schwierig wird, die Spreu vom Weizen zu trennen.

Search: SRU/SRW (including CQL), OpenSearch, Z39.50

Harvest/Syndicate: OAI-PMH, RSS, Atom Syndication (also with ATOM Extensions)

Copy/Provide: unAPI, COinS, Microformats (not a real API but a way to provide data)

Upload/Edit: SRU Update, Atom Publishing Protocol

Identity Management: Shibboleth (and other SAML-based protocols), OpenID (see also OSIS)

For more complex applications, additional (REST)-APIs and common metadata standards need to be found (or defined) – but only if the application is just another kind of search, harvest/syndicate, copy/provide, upload/edit, or Identity Management.

P.S: I forgot NCIP, a “standard for the exchange of circulation data”. Frankly I don’t fully understand the meaning and importance of “circulation data” and the standard looks more complex then needed. More on APIs for libraries can be found in WorldCat Developer Network, in the Jangle project and a DLF Working group on digital library APIs. For staying in the limited world if libraries, this may suffice, but on the web simplicity and availability of implementations matters – that’s why I am working on the SeeAlso linkserver protocol and now at a simple API to query availaibility information (more in August/September 2008).

P.P.S: A more detailed list of concrete library-related APIs was published by Roy Tennant based on a list by Owen Stephens.

P.P.S: And another list by Stephen Abram (SirsiDynix) from September 1st, 2009

Im Gegensatz zu ManyEyes und Swivel ist etwas mehr Handarbeit angesagt, um mit JavaScript dynamisch, webbasiert Zeitreihen anzeigen zu können, dafür ist Timeplot flexibler und kann auf eigenen Webseiten eingebunden werden. Die zu visualisierenden Daten können unter Anderem als kommaseparierte Zeitreihen oder Zeitpunkte im Timeline XML event format vorliegen (für welches ich leider keine gute Dokumentation aber dieses Tool gefunden habe). Mit diesem Dienst können Ereignisse im hCalender- oder vCalender-Format ins Timeline-Format konvertiert werden. Google experimentiert ebenfalls mit Zeitreihen als Antwort auf Suchanfragen aber so wie ich Google kenne, kann man die Suchergebnisse wahrscheinlich nicht weiterverwenden.

Wer ganze Mashups zur Visualisierung mit JavaScript zusammenbasteln möchte, sollte sich das ebenfalls bei SIMILE entstandene Exhibit ansehen.

Wie Patrick bemerkte ist es bereits seit Anfang August möglich, mit Zotero Daten aus dem GBV zu übernehmen. Dazu hatte der Zotero-Entwickler Ramesh Srigiriraju einen “Scraper” in JavaScript geschrieben, der das RIS-Format interpretieren kann, welches von der PSI-Katalogsoftware mit dem Parameter PRS=RIS exportiert wird – wer genauer sehen möchte, wie so etwas funktioniert, sollte im Quelltext nach “GSO” suchen.

Das Angebot von Daten via COinS ist wesentlich leichter nutzbar – sucht im im GSO-Katalog einfach mal nach einem Titel und schaut dann im HTML-Quelltext nach der Zeichenkette “Z3988″. Damit das Angebot auch in lokalen OPACs nutzbar ist, sollten meiner Meinung nach die einzelnen GBV-Bibliotheken erstmal selber Zotero ausprobieren und überlegen, wie sie das Angebot ihren Benutzern am Besten bekannt machen können.

Für die ganz harten Bibliothekshacker hier ein Stück Perl, um COinS für eigene Anwendungen aus beliebigen Webseiten auszulesen:

use HTML::TreeBuilder::XPath;
use LWP::UserAgent;
use URI::OpenURL;
use URI;
my $url = URI->new(shift @ARGV) or die "Please specify an URL!";
my $ua = LWP::UserAgent->new();
my $res = $ua->get($url);
my $html = $res->decoded_content;
my $tree= HTML::TreeBuilder::XPath->new_from_content( $html );
my @coins = $tree->findnodes( '//span[@class="Z3988"]/@title');
@coins = map { URI::OpenURL->new("?" . $_->getValue() ); } (@coins);
foreach my $c (@coins) {
  print $c->canonical->dump() . "\n";
}

Schon weiter fortgeschritten ist Firefox 3 – die neue Version des populären Webbrowsers macht zur Zeit wegen seiner auf das jeweilige Betriebssystem angepassten Optik von sich reden. Die aktuelle Experimentier-Version kann jederzeit ausprobiert werden, mit einem endgültigem Release wird Ende 2007 gerechnet. Ich habe mir mal die Liste der geplanten Neuerungen angesehen und möchte folgende Features hervorheben:

Völlig überarbeitet wurde die Lesezeichen-Verwaltung, die nun die Bezeichnung “Places” trägt: Neu ist vor allem, dass Lesezeichen und die Liste der besuchten Seiten gemeinsam verwaltet werden und auch mit Tags versehen werden können. Den Berichten nach, hat die Usability damit deutlich zugenommen. Offen ist für mich nur, wie Social Tagging-Dienste da reinpassen.

Eine weitere interessante Neuerung ist Content Type-Processing: Bisher kann Firefox auf Basis von Protokoll und MIME-Types beim Download verschiedene Anwendungen starten (Mailprogramm, Newsreader, Bildbetrachter…), RSS-Feeds können auch direkt an eine andere Webapplikation wie z.B. Bloglines weitergereicht werden. Im Rahmen eines grundsätzlichen Aufräumens der MIME-Type-Behandlung soll die Weiterleitung auch an andere Webanwendungen möglich sein, so dass z.B. beim Klick auf mailto:-Links der Webmailer geöffnet wird.

Ebenfalls in die Richtung, aus dem Browser ein allgemeines Werkzeug zum Auswählen, Weiterleiten und Verarbeiten von Informationen zu machen, geht die bereits im Januar 2007 diskutierte Unterstützung von Mikroformaten. So wie ich es verstanden habe, sollen beliebige Microformats mitsamt den mit ihnen ausführbaren Aktionen im Browser registriert werden können (siehe Screenshot im Notizblog. Ein Bibliothekarisches Microformat lässt (abgesehen von COinS) ja noch auf sich warten.

Weitere Neuerungen der Benutzeroberfläche wurden bereits im Juni von Alex Faaborg zusammengefasst (mit Screenshots).

Das dritte Mozilla-Projekt, von dem es Neues zu berichten gibt, ist die Kalenderanwendung Sunbird, die gerade in der Version 0.7 herausgekommen ist. Ich habe mir trotzdem für 2008 wieder einen Taschenkalender aus Papier gekauft – bis es für den Sonnevogel ein passendes Linux-Handy gibt

Um sich nicht im Sommerloch langweilen zu müssen, habe ich hier eine kleine Aufgabe für ISBD-Experten, Bibliothekare und andere Zukunftsinteressierte: Es geht um nicht weniger als die die Entwicklung eines bibliothekarischen Datenformates. Da der Beitrag etwas länger ist, hier eine

Zusammenfassung

1. Im Web sind mehr und mehr Daten direkt und in standardisierten Formaten zur Weiterverarbeitung verfügbar
2. Durchsetzen wird sich am Ende das, was im Browser ohne Plugin unterstützt wird
3. So wie es aussieht, werden dies Mikroformate sein
4. Für Bibliographsche Daten fehlt bislang ein Mikroformat
5. Wenn sich Bibliothekare nicht mit ihrem Sachverstand an der Entwicklung eines solchen Formates beteiligen, tun es andere – und das nicht unbedingt nach bibliothekarischen Gesichtspunkten.

Worum geht es?

Im Rahmen des “Web 2.0″-Hypes tauchen immer wieder Begriffe wie “Web 3.0″ oder “Semantic Web” auf. Damit wird (abgesehen von der Verwendung als Buzzword) auf die folgende wichtige Entwicklung des Webs angespielt: Immer mehr Daten stehen direkt und in standardisierten Formaten zur Weiterverarbeitung zur Verfügung. Einfache Beispiele sind RSS und Dublin Core; auf der anderen Skala der Komplexität stehen Ontologien und RDF. Auch das Millionenprojekt Theseus hat zum Ziel, so genannte “semantische Technologien” zu entwickeln.

Ich gehe jede Wette ein, dass in Zukunft mehr und mehr Daten mittels “Semantischem Markup” in Webseiten integriert werden – bislang fehlte es jedoch an einer “Killerapplikation” und noch ist nicht festgelegt, in welcher Form die Daten in Webseiten eingebunden werden. Eine bereits jetzt nutzbare Form für bibliographische Daten ist das auf OpenURL basierende COinS (ContextObjects in Spans). Allgemeinere Formen für verschiedene Arten von Daten sind Microformats und RDFa (hier ein Vergleich der beiden und ein Beispiel auf Deutsch hier von Carsten Schulze).

Ob und wo sich Webstandards langfristig durchsetzen, hängt nicht zuletzt davon ab, ob sie standardmäßig von Webbrowsern unterstützt werden – bislang ist dies an über HTML hinausgehenden Formaten nur für RSS der Fall. Nun ist es so, dass die vorraussichtlich Ende 2007 erscheinende Version 3.0 des Firefox-Webbrowsers Microformats unterstützen wird. Und Microsoft ist dabei, die Zwischenablage so zu erweitern, dass einzelne Objekte von Webseiten kopiert werden können (auszuprobieren mit Live Clipboard)- die ersten Anwendungen sind die Mikroformate hCal und hCard. Damit ist klar, wohin die Entwicklung geht.

Was sind Mikroformate?

Mit Mikroformaten können Webseiten so durch Markup angereichert werden, dass ihre Inhalte möglichst detailliert auch für Computerprogramme verarbeitbar sind (dazu gibt es eine gute Einführung). Hier als Beispiel meine Dienstanschrift:

So kann es ein Mensch verstehen:

Verbundzentrale des GBV
Jakob Voß
Platz der Goettinger Sieben 1
37073 Göttingen
+49 (0)551 39-10242
jakob.voss@gbv.de

Und so muss es in HTML als vcard-Microformat angegeben sein, damit es auch Computer verstehen (erstellt mit dem Generator für hCard:

<div class="vcard">
 <div class="org">Verbundzentrale des GBV</div>
 <span class="fn">Jakob Voß</span>
 <div class="adr" class="work">
   <div class="street-address">Platz der Goettinger Sieben 1</div>
     <span class="postal-code">37073</span>
     <span class="locality">Göttingen</span>
 </div>
 <div class="tel">+49 (0)551 39-10242</div>
 <div class="email">
     <a href="mailto:jakob.voss@gbv.de"; class="email" >jakob.voss@gbv.de</a>
 </div>
</div>

Derzeit gibt es eine Reihe von etablierten Mikroformaten und weitere sind in Entwicklung. Die Dokumentation und Diskussion findet offen in einem Wiki statt. Eine Einführung in Mikroformate bietet auch das Buch “Microformats: Empowering Your Markup for Web 2.0″ und ein weiteres eBook auf deutsch.

Was hat das alles mit Bibliotheken zu tun?

Derzeit gibt es noch kein einheitliches Microformat für bibliographische Angaben – allerdings schon einige Ansätze. Es ist zwar alles andere als trivial, ein bibliographisches Datenformat zu entwickeln, aber das Web funktioniert pragmatisch – ich gehe davon aus, dass sich ein citation-Microformat durchsetzen wird, sobald jemand einen Standard dafür festlegt und umsetzt. Dabei kommt es nicht darauf an, wie gut dieser Standard ist, sondern dass er gut dokumentiert, verfügbar und benutzbar ist und dass er von einer kritischen Masse von Anbietern verwendet wird (siehe dazu VHS vs. Betamax und Video 2000).

Nun können wir als bibliothekarisches Fachpersonal a) entweder abwarten, bis sich der citation-Microformat-Standard stabilisiert hat und danach darüber wundern, dass er aus bibliothekarischer Sicht an der einen oder anderen Stelle völlig unzureichend ist oder b) uns aktiv an der Entwicklung des citation-Microformat-Standards beteiligen und ihre bibliothekarische Sachkompetenz einfließen lassen.

Und hier kommt ISBD ins Spiel!

Ich möchte zunächst betonen, dass die der Katalogisierung, Ansetzung und dem Aufbau von Titelanzeigen nicht mein Fachgebiet sind. Soweit ich das Konzept der International Standard Bibliographic Description (ISBD) verstanden habe, legt dieser Standard fest, wie eine Titelaufnahme im Katalog aussehen sollte – vereinfacht gesagt also die Reihenfolge und Trennzeichen von Autor, Titel, Verlag und all die anderen Datenfelder einer Titelaufnahme. Obgleich viele Kataloge sich nicht streng an ISBD halten ist das Prinzip das gleiche: irgendwo ist festgelegt, welche Titeldaten in welcher Weise formatiert angezeigt werden.

Bei Mikroformaten ist es ganz ähnlich. Nur wird bei einem Mikroformat statt mit Sonderzeichen wie ; – [..] und , mit HTML-Tags <div> <span> und dem class-Attribut strukturiert.

Die Aufgabe besteht, wie schon von anderer Seite angedeuted also darin, eine Abbildung von ISBD (bzw. der am häufigsten in OPAC-Titelanzeigen verwendeten Untermenge) auf ein Mikroformat zu finden. Hier mal ein naiver Ansatz anhand eines konkreten Beispiels der folgenden Titelaufnahme (übrigens Herzlichen Glückwunsch an die Braunschweiger, die als erste GBV-Verbundbibliothek den neuen Harry Potter im Bestand haben

Titel: Harry Potter and the deathly hallows / Joanne K. Rowling. – [Children's ed.], 1. ed. – London : Bloomsbury, 2007
ISBN: 0-7475-9105-9 – 978-0-7475-9105-4 (Children’s edition)

Die bedeutungstragenden Bestandteile werden nun hierarchisch ausgezeichnet, ohne den Text selber zu verändern (das geht auch gut mit Papier und verschiedenfarbigen Stiften):

<div class='hCitation'>
  Titel:
  <span class='title'>Harry Potter and the deathly hallows</span> /
  <span class='n'>
    </span><span class='given-name'>Joanne K.</span>
    <span class='family-name'>Rowling</span>
  </div>. -
  [<span class='edition'>Children's ed.</span>], <span class='edition-number'>1.</span> ed. -
  <span class='location'>London</span> : <span class='publisher-name'>Bloomsbury</span>,
  <span class='publication-year'>2007</span>
</div>
<div>
  ISBN:
  <span class='ISBN'>0-7475-9105-9</span> -
  <span class='ISBN'>978-0-7475-9105-4</span>
  (<span class='edition'>Children's edition</span>)
</div>

Dabei muss festgelegt werden, wie fein die Daten aufgespalten werden sollen und wie die einzelnen Elemente mit class=”…” benannt werden. Sicherlich können nicht alle in ISBD vorhandenen Spezialfelder und Sonderregeln berücksichtigt werden, die Anzahl der Felder soll schließlich überschaubar bleiben. Aüßerdem müssen wo möglich, bereits bestehende Microformats und andere Formate berücksichtigt werden – so sind die Feldbezeichnungen für Namen mit ‘n’, ‘given-name’ und
‘familiy-name’ bereits im hCard-Standard festgelegt, da gibt es also nichts zu ändern.

Was also zu erstellen ist, ist eine genaue Festlegung eines Mikroformats für bibliographische Angaben. Vielleicht kann auch von anderen Standards als ISBD ausgegangen werden (OpenURL, RAK, AACR, MAB, MARC, MODS, BibTeX…) – in jedem Fall muss aber die Titelanzeige ausgezeichnet werden, so wie sie der Nutzer im Katalog sieht. Um es nochmal zu betonen: Wenn Firefox und Microsoft sich auf Mikroformate festlegen und diese von Haus aus unterstützen, ist es völlig egal, wie gut Mikroformate sind und ob es Alternativen gibt.

Der traditionelle Weg wäre vermutlich, eine Arbeitsgruppe “Mikroformate” mit den entsprechenden Experten einzurichten. Das kann
zwar grundsätzlich nicht schaden, jedoch sollte folgendes bedacht werden: Erstens hätte diese AG sowieso keinerlei Entscheidungsbefugnisse, da die Diskussion offen im Microformate-Wiki stattfindet, wo sich jeder beteiligen kann und zweitens haben wir keine Zeit für langwierige Projektplanungsphasen. Was zählt ist nur das direkt online verfügbare Ergebnis und kein Projektbericht oder Sitzungsprotokoll. Siehe dazu dieses schöne Posting, das den Konflikt von Bibliothekaren mit solch pragmatischen Lösungen darlegt.

Das das Format am Ende allen erdenklichen bibliothekarischen Ansprüchen genügen wird, bezweifle ich, aber es besteht zumindest die Möglichkeit, Einfluss zu nehmen und den bibliothekarischen Sachverstand einfliessen zu lassen – noch.

Wie kommen nun bibliothekarisches Know-How und Mikroformate zusammen?

Zunächst einmal sollte man sich etwas mit Mikroformaten vertraut machen – dazu gibt es die genannten Bücher und verschiedene Einführungen im Netz. Danach sind ISBD oder die Regeln zur Erzeugung der Titelanzeige im eigenen Katalog vorzunehmen und die atomaren bedeutungstragenden Bestandteile herauszuarbeiten. Diese sollten danach übersichtlich im Microformats-Wiki dargestellt und dort an konkreten Beispielen ausdiskutiert werden.

Zotero erkennt auf vielen Webseiten bibliographische Angaben, so dass sie mit einem Mausklick in die eigene Literatursammlung übernommen werden können. Darunter sind auch Bibliothekskataloge, allerdings bislang noch keine aus Deutschland. Das ist allerdings auch nicht verwunderlich, denn wer sollte die Anbindung an Zotero auch umsetzen wenn nicht die so genannten “Web 2.0″-Experten mit bibliothekarischem Umfeld?

Soweit ich es verstanden habe, genügt für Zotero, bei der Titelanzeige in die HTML-Seite OpenURL-Daten mittels COins (ContextObjects in Spans) einzufügen. COins sind nicht nur für Zotero von Bedeutung sondern wird bereits jetzt als allgemeines Mikroformat für bibliographische Daten eingesetzt (die Microformats-Community werkelt derweil dennoch an einem eigenen Standard herum).

Da COins auf OpenURL basiert, dürfte es bei Katalogen, die bereits OpenURL als Source für Linkresolver unterstützen, einfach sein, auch COins anzubieten. Dies ist nebenbei bemerkt auch ein Beispiel dafür, wie wichtig es ist, dass Bibliotheken die technische Kompetenz zur Entwicklung ihrer OPACs selbst benötigen anstatt die Katalogsoftware bei einem Hersteller einzukaufen ohne selber daran herumzuskripten. Denn obwohl die Einbindung von COins technisch nicht aufwendig ist, hat ein herkömmlicher kommerzieller Hersteller in der Praxis dazu weder die Möglichkeit (außer er hat direkten Zugang zum Katalogserver) noch den Anreiz (außer er bekommt einen expliziten, bezahlten Auftrag). Die Bibliothek selber kann aber ohne die technischen Fähigkeiten, weder mal eben etwas wie COins selber in die eigenen Katalogsoftware integrieren, noch seinem Softwarehersteller früh und konkret genug sagen, was dieser genau umsetzen soll – und bekommen dann deshalb irgend etwas unzureichendes als “Web 2.0″ verkauft.

P.S.: Wie infobib mitteilt ist seit kurzem die Institutsbibliothek der Saarländer Informationswissenschaft schon soweit – ist ja auch kein Produkt von der Stange.

Web2.0-Junkies mögen ihre Freude an technischen Spezifikationen haben, aber normale Menschen interessiert sowas wie “Format” doch zu Recht nicht die Bohne (ich darf mich hoffentlich je nachdem zu beiden Personengruppen zählen). Wenn sich schon jemand die Mühe macht, in einheitlicher Form eine maschinenlesbare “Visitenkarte” auf seine Webseite zu bringen, dann erwarte ich sie mit einem einfachen Klick in meiner Adressverwaltung übertragen zu können. Dazu sind aber bislang folgende Hürden zu nehmen:

• Die Überwindung, sich mit Mikroformaten zu beschäftigen, während es eigentlich einfach nur “funktionieren” soll.
• Die Wahl von Firefox als Webrowser und ein Microformats-Plugin wie zum Beispiel Operator, das die Mikroformate aus einer Webseite auslesen kann.
• Das Herumkonfigurieren am Plugin (in Operator sollte “display icon in status bar” in den Plugin-Einstellungen aktiviert werden).
• Eine Anwendung, die mit dem entsprechenden Mikroformat (hier vCard) etwas anfangen kann.
• Die Erkenntnis, dass bisher sowieso nur wenige Webseiten Mikroformate anbieten.

Mir war es beim vorletzten Punkt zu viel: Thunderbird kann vCard zwar beigebracht werden, aber nicht direkt aus dem Browser heraus, also muss ich die Adressdaten mit dem Operator-Plugin erst als vCard-Datei speichern und dann die Datei in Thunderbird importieren.

Bei Software-Monokulturen wie Apple oder KDE mag der Austausch von Daten über Programme hinweg ja einwandfrei funktionieren, aber dafür werden eigentlich keine Mikroformate benötigt. Bis verschiedenste Informationen problemlos aus dem Netz in andere Anwendungen übernommen werden können, dauert es sicherlich noch etwas, zumal selbst die Web 1.0-Grundlage Mime-type (auch Content-Type in HTTP) oft nicht richtig verwendet wird.