2014-03-06

Sammelband herausgeben: Gelernt ✓

Im letzten Jahr wurde der von Patrick Danowski und mir herausgegebene Sammelband "(Open) Linked Data in Bibliotheken" veröffentlicht. In meinem Beitrag dazu schrieb ich:
"Es war auf jeden Fall eine interessante Erfahrung für mich, einen solches Druckwerk herauszugeben.  Ich habe eine Menge dabei gelernt und würde einiges beim nächsten Mal anders machen. (Dass es ein nächstes Mal geben wird, bezweifle ich allerdings ernsthaft.) Hoffentlich finde ich noch die Zeit, meine Erfahrungen in einem separaten Beitrag zu niederzuschreiben..."
Da Christian Hauschke in einem Kommentar sein Interesse an einem entsprechenden Beitrag angemeldet hatte, liefere ich hier nun nach und schreibe mal auf, was ich gelernt habe, wie ich ein solches Projekt beim nächsten Mal angehen würde und welche weitere Unterstützung mir von Verlagsseite willkommen wären.

Ein Projekt

Zunächst mal ist klarzustellen: Bei der Erstellung und Veröffentlichung eines Sammelbands handelt es sich um ein größeres Projekt, an dem ein mittelgroßes Projektteam beteiligt ist. In unserem Fall bestand das Projektteam aus 17 Autorinnen und Autoren (inklusive der beiden Herausgeber) sowie zwei Ansprechpartnerinnen bei de Gruyter. Das Projekt dauerte knapp zwei Jahre. (Die Idee eines solchen Sammelbands hatte Patrick mir bereits im Sommer 2011 unterbreitet. Begonnen hat das Projekt Anfang November 2011 als Patrick mir den Link zum ersten Entwurf des Call for Participation (CfP) schickte. Ende September 2013 habe ich dann die gedruckten Belegexemplare in Händen gehalten, womit für mich das Projekt abgeschlossen war. [1])

Dass das Projekt – wie so viele andere auch – nicht ganz wie geplant abgelaufen ist, zeigt sich in der Diskrepanz zwischen dem ursprünglich angekündigtem und dem tatsächlichen Veröffentlichungstermin des Sammelbands. Der CfP lief am 18.3.2012 aus. Darin deuteten wir einen sehr sportlichen Veröffentlichungstermin für Anfang Herbst 2012 an. Die tatsächliche Veröffentlichung war dann allerdings ziemlich genau ein Jahr später als ursprünglich geplant. Welche Probleme gab es? Was habe ich gelernt?

Lektionen

Hier die vier wichtigsten Lehren, die ich aus dem Projekt gezogen habe:

1. Habe realistische Vorstellungen vom Gesamtaufwand.
Ich hatte auf jeden Fall den Aufwand dieses Unternehmens stark unterschätzt. Ein Sammelband lässt sich nicht mal eben nebenher herausgeben! Für die Akquise von Beiträgerinnen und Beiträgern, das Lesen der Einreichungen und die gesamte Kommunikation ist eine Menge Zeit einzuplanen.

2. Plane gut.
Es sollten von Beginn alle Aufgaben gesammelt und realistische Fristen für deren Erledigung festgelegt werden. Das heißt: Sowohl die Autorinnen und Autoren als auch die Herausgeber sollten sich in der Lage fühlen, ihre jeweiligen Aufgaben innerhalb der vorgegebenen Fristen zu erledigen.
Beispielsweise hatten Patrick und ich in der ursprünglich für Texterstellung, Gegenlesen, Rückmelden und Verbessern der Texte vorgesehenen Phase nicht genug Zeit, weshalb wir die Zeitplanung bereits in dieser Phase nach hinten verschieben mussten. So etwas ist war vor allem für jene fleißigen Autorinnen und Autoren blöd, die sich an die Fristen halten und dann aber am längsten auf die Veröffentlichung ihrer Texte warten müssen. :-/ Da davon auszugehen ist, dass schon einige der Beiträge für Verzögerungen sorgen, ist es eigentlich Aufgabe der Herausgeber nachzuhaken und nötigenfalls Druck zu machen anstatt selbst für Verzögerungen zu sorgen.

3. Dokumentiere den Fortschritt und sorge für Einhaltung der Fristen.
Insbesondere bei zwei Herausgebern essentiell: ein Ticketsystem benutzen, in dem alle Aufgaben, deren Fristen und Fortschritte dokumentiert werden. So kann sich jeder in kurzer Zeit einen Überblick über den Stand des Projekts verschaffen. Es sollte zudem eine klare Festlegung geben, wie mit Nichteinhaltung der Fristen umgegangen wird und nach wie vielen Erinnerungen ein Beitrag gestrichen wird. Diese Vorgehensweise sollte säumigen Autoren klar kommuniziert werden. (Wir sind einem Beitrag monatelang hinterhergelaufen ehe wir unsere Bemühungen aufgaben und ihn endgültig aufgaben.)

4. Beschränke deinen eigenen Textbeitrag auf ein Minimum.
Wir hatten uns einiges vorgenommen: Neben der Herausgeberschaft haben Patrick und ich selbst noch einen der längsten Beiträge geschrieben, und ich habe zusätzlich noch ein Glossar zusammengestellt. Da die ganze Arbeit als Herausgeber schon eine Menge Aufwand bedeutet, ist es sinnvoll, sich mit eigenen Beiträgen zum Sammelband zurückzuhalten und sich z. B. auf ein knappes Vorwort zu beschränken.

Aufgaben eines Herausgebers: eine Übersicht

Die folgende Mindmap versucht einen Überblick über die Aufgaben zu geben, die bei der Herausgabe eines Sammelbands anfallen. (Update: Die Mindmap kann hier – z. B. wenn die Einbettung nicht funktioniert – direkt angeschaut werden.)
Sammelband Herausgeben on MindMup
Im folgenden werde ich auf einige dieser Aufgaben etwas näher eingehen.

Kernaufgaben

Die drei Bereiche AkquiseAuswahl und Redaktion stellen sicher die Kernaufgaben einer Herausgeberschaft dar (weshalb sie in der Mind Map auch alle in derselben dunkelblauen Farbe dargestellt sind).
  • Die Akquise bedeutete für uns zum einen das Verschicken des CfP und zum anderen das direkte Anschreiben und Ansprechen potentieller Autorinnen und Autoren.
  • Die Arbeit bei der Auswahl hat sich bei uns in Grenzen gehalten, da wir nur eine potentielle Ablehnung diskutieren mussten. Sollten mehr Beiträge vorgeschlagen werden als in den geplanten Sammelband aufgenommen werden können, kann die Auslese der Beiträge allerdings eine Menge Zeit in Anspruch nehmen.
  • Die Redaktion war sicherlich die aufwändigste der drei Kernaufgaben. Dabei wurden die Texte etwa zwei- bis zehnmal Mal zwischen den Beiträgern und Herausgebern hin- und hergeschickt und teilweise längere inhaltliche Diskussionen geführt.
    Glücklicherweise wurde uns die finale Lektoratsarbeit vom Verlag übernommen, was uns eine Menge Arbeit gespart hat.

Selber schreiben

Die Produktion eines eigenen Beitrags (in der Mindmap hellblau) nimmt selbst nochmal eine ganze Menge Zeit neben der eigentlichen Herausgeberschaft in Anspruch. Neben der Recherche und der Lektüre einer Menge verschiedener Texten muss ein eigener Text verfasst, diskutiert und in vielen Zyklen angepasst werden, bis eine publikationswürdige Version herauskommt. Deshalb sollte man sich – wie bereits erwähnt – gut überlegen, ob man neben der Herausgabe auch noch einen eigenen Text beitragen will .

Projektmanagement & Kommunikation

Neben diesen Kernaufgaben habe ich in der Mind Map noch zwei weitere Aufgabenbereiche identifiziert: Kommunikation (gelb) und Projektmanagement (orange). [2] Dies sind zentrale Aufgaben eines jeden Projekts, ganz gleich, ob es sich dabei um die Herausgabe eine Sammelbandes, die organisationsweite Einführung einer neuen Softwarelösung oder die Ausrichtung der olympischen Spiele handelt. Hier gehe ich allerdings nur auf ersteres konkret ein.

Projektmanagement

Vor Verbreitung eines Call for Participation sollten die Heraugeber gemeinsam einen Projektplan erstellen, der festlegt, zu welchem Zeitpunkt die verschiedenen Meilensteine erledigt sein sollten. (Man kann das dann auch in einem Gantt-Diagramm festhalten, muss man aber nicht.)

Sobald es mehr als einen Herausgeber gibt, sollte eine Person für das Projektmanagement ausgewählt werden. Diese Person ist dann hauptverantwortlich dafür, dass allen Beteiligten die Fristen kommuniziert werden und auf deren Einhaltung abgezielt wird. Bei Verzögerungen ist das Projektmanagement auch verantwortlich für die Aktualisierung des Projektplans.

Schließlich sind die Herausgeber sowie im besten Fall auch die Autorinnen für die Dokumentation des Fortschritts verantwortlich. Zumindest dem Projektmanagement sollte jeweils klar sein: Wie weit ist ein Text gediehen? In welchem Status ist er beim Korrekturlesen? Wann wurde Autor X das letzte mal an die Frist erinnert? etc. Wie oben bereits erwähnt, würde ich all dies mittlerweile nicht mehr ohne ein Ticketing-System tun, in dem für jede (Unter-)Aufgabe ein Ticket angelegt wird und die dazugehörigen Kommentare den aktuellen Stand wiedergeben. Auf diese Weise habe ich selbst den besten Überblick, was ich bereits getan habe und was als nächstes zu erledigen ist. [3]

Kommunikation

Im Laufe der Arbeit an einem Sammelband müssen die Herausgeber mit verschiedenen Personengruppen kommunizieren.

Sollte es – wie in unserem Fall – mehrere Herausgeber geben, so ist das zunächst die Kommunikation zwischen den Herausgebern. Die direkte Kommunikation lässt sich auf ein Minimum reduzieren, wenn am Anfang genug Zeit in die gemeinsame Erstellung eines tragfähigen Projektplans gesteckt wird, die Verantwortlichkeiten klar verteilt sind und ein Ticketing-System zur Fortschrittsdokumentation genutzt wird.

Die Kommunikation mit dem Verlag war in unserem Fall meist auf ein Minimum reduziert. Es gab aber bestimmte Arbeitsabschnitte und Diskussionspunkte, zu denen wir uns recht intensiv mit den Verlagsvertreterinnen austauschten. Das ging mit der Vertragsgestaltung und Lizenzfragen los (de Gruyter ist nicht dran gewöhnt, dass Herausgeber eine offene Lizenz fordern, wenn auch Patrick bereits einen Sammelband unter ähnlichen Bedingungen mit de Gruyter veröffentlicht hat) und endete bei der Betitelung des Sammelbandes. Die meiste Zeit hat allerdings der konkrete Austausch zu den einzelnen Texten in Anspruch genommen, da de Gruyter wie gesagt wertvolle Korrekturen und Verbesserungsvorschläge geliefert hat.

Kommunikation mit Autorinnen: Die Vorschläge des Verlags mussten – genauso wie unsere eigenen – mit den Autorinnen und Autoren abgesprochen werden. Dadurch entstand ein mehrmaliges Hin und Her ehe die finale Fassung eines Textes vorlag. Wir mussten uns auf Zitiervorgaben einigen und diese durchsetzen, aufkommende Fragen verschiedener Art beantworten und bei säumigen Autoren nachhaken. Geplant war auch eine stärkere Vernetzung der Autorinnen und Autoren untereinander, um inhaltliche Wiederholungen zu vermeiden, Querverweise zwischen den Texten einzubauen und so den Sammelband mehr als eine Gesamtheit und nicht bloß als eine Ansammlung separater Texte umzusetzen. Dies hat in gewissem Maße geklappt, allerdings hätten wir als Herausgeber da noch mehr leisten können.

Was könnte der Verlag verbessern?

Ich bezweifle, dass der papierne Sammelband das Medium der Zukunft ist. Für Texte im Artikelformat bietet sich doch eher das Web als Publikationsmedium an, weshalb Verlage m. E. zumindest eine parallele Publikation der Papierfassung sowie einer PDF- und einer HTML-Version anstreben sollten. Ich hatte mich dennoch bereiterklärt, an der Erstellung eines Druckwerks mitzuwirken, vor allem, um das Thema Linked Open Data auch mal an andere Leute als z. B. die Leser dieses Blogs heranzubringen. (Ich weiß leider nicht, ob diese Rechnung aufgegangen ist...)

Insgesamt habe ich mich vom Verlag de Gruyter gut betreut gefühlt. Ich war froh über die Rat- und Vorschläge aus dem Verlag und das professionelle Lektorat. Und natürlich war es mir wichtig, dass de Gruyter unsere Bedingungen hinsichtlich einer offenen Lizenzierung (CC-BY) erfüllt hat. Sind Unklarheiten oder Meinungsverschiedenheiten aufgekommen, so habe ich die Diskussionen mit den Verlagsvertretern jederzeit als offen und konstruktiv wahrgenommen.
Allerdings empfand ich die Verlagspraktiken nicht überall als entlastend und schließe diesen Beitrag mit zwei Vorschlägen, wie die Arbeit von Sammelbandherausgebern durch einen Verlag noch weiter erleichtert werden könnte.
  • Ein Leitfaden für Herausgeber, der die wichtigsten Aufgaben eines Herausgebers und Strategien für deren erfolgreiche Umsetzung nennt, hätte mir – als Newbie in diesem Bereich – sehr weitergeholfen. Ich habe auch im Web nach einem solchen Leitfaden recherchiert und auf die Schnelle nichts gefunden. Hinweise in den Kommentaren sind willkommen. (Falls jemand vorhat, einen solchen Leitfaden zu erstellen: Dieser Text steht unter der CC0 Public Domain Dedication und kann ohne jegliche Bedingungen ganz oder in Teilen weiterverwendet werden.)
  • Ich würde eigentlich von einem modernen Verlag eine gewisse Flexibilität hinsichtlich der möglichen Dateiformate der Textbeiträge erwarten. Mich hat es sehr verwundert und gestört, dass die Texte allein als docx eingereicht werden konnten, was für mich u. a. bedeutete, dass ich monatelang mit Windows arbeiten musste, wo ich seit einigen Jahren – so weit es eben geht – sowohl beruflich wie auch privat auf ein Linux-Betriebssystem (Ubuntu) umgestiegen bin. (Offensichtlich ist das alleinige Akzeptieren von MS-Word-Formaten Standard bei Verlagen wie mir beim Lesen eines Blogbeitrags von Martin Fenner klar wurde.) Meines Erachtens sollte ein Verlag nicht nur eine docx-Vorlage, sondern zumindest auch eine LaTeX- und eine Markdown-Vorlage anbieten und sinnvollerweise auch eine odt-Vorlage. Das dürfte den Formatierungsaufwand für den Verlag sogar mittelfristig reduzieren. Im Falle unseres Sammelbandes hätten sicher einige der Autorinnen und Autoren Alternativen zu Microsoft-Office-Formaten begrüßt.

Fußnoten
[1] Dem könnte man widersprechen mit dem Hinweis darauf, dass ein Projekt erst nach Fertigstellung eines Projektberichts inklusive der Lessons Learned abgeschlossen ist. Demnach wäre das Projekt erst mit Veröffentlichung dieses Beitrags beendet.

[2] Es sei dahingestellt, ob es sinnvoll ist, Kommunikation als separaten Aufgabenbereich hinzustellen. Schließlich spielt das Kommunizieren – mit den Autorinnen und Autoren und den Verlagsvertreterinnen sowie der Herausgeber untereinander – bei der Herausgabe eines Sammelbands an fast jeder Stelle eine wichtige Rolle. Da es viel Zeit in Anspruch nimmt, scheint es mir jedenfalls sinnvoll, das hier gesondert aufzuführen.

[3] Ich werde versuchen, im hbz-LOD-Blog in der nächsten Zeit einmal die Projektmanagement-Praktiken vorzustellen, die wir bei den entsprechenden hbz-Projekten etabliert haben. (@Christian: Du kannst mich gerne wieder dran erinnern, falls nach dieser Ankündigung wieder nichts passieren sollte. :-)

2013-10-06

Sammelband "(Open) Linked Data in Bibliotheken" veröffentlicht


(Open) Linked Data in Bibliotheken - Buchcover
Ich freue mich, die Publikation des Sammelbandes "(Open) Linked Data in Bibliotheken" bekanntzugeben, den ich gemeinsam mit Patrick Danoswki herausgegeben habe. Bereits vor zwei Wochen sind die gedruckten Belegexemplare angekommen. Seit letztem Montag ist der Sammelband auch Open Access verfügbar unter  http://dx.doi.org/10.1515/9783110278736.

Vielen Dank an alle Autorinnen und Autoren für ihre Beiträge! Es hat mir Freude gemacht, mit euch zusammenzuarbeiten. Vielen Dank auch an unsere Ansprechpartnerinnen bei de Gruyter!

Unten eine Inhaltsübersicht mit den DOI-Links zu den einzelnen Beiträgen.

Leider kann man die URLs nicht nur in der Printfassung nicht anklicken, sondern auch in der PDF-Version des Verlags. Da sich in Patricks und meinem Sammelbandbeitrag eine Vielzahl von Links finden, habe ich auf E-LIS zusätzlich zur Print-PDF-Version die Preprint-Version des Artikels - mit klickbaren URLs -  hochgeladen (siehe den Link unten). Pascal Christoph hat das noch viel besser gemacht und vorbildlich seinen Beitrag mit RDFa angereichert veröffentlicht, siehe seinen Blogpost dazu.

Ein LOD-Glossar zum Remixen

Hier möchte ich noch besonders auf das Glossar hinweisen, das ich für den Sammelband zusammengestellt habe. Es umfasst etwa vierzig Lemmata aus dem Bereich Linked Open Data in Bibliotheken. Mittlerweile wurde das Glossar in die Obhut der DINI AG KIM übergeben, in deren Rahmen es gemeinsam weitergeführt werden soll. Die jeweils aktuelle Version findet sich auf github (http://git.io/UmPKaA). Bisher bin ich allerdings der einzige, der weitergearbeitet hat.
Andere sind herzlich eingeladen, das Glossar (es steht unter der CC0) in anderen Kontexten zu nutzen, zu ergänzen und im besten Fall die Änderungen und Korrekturen wieder zu teilen.

Viel gelernt

Ich bin sehr froh darüber, dass der Sammelband endlich veröffentlicht ist und alle Beteiligten m. E. mit dem Ergebnis zufrieden sein können. Es war auf jeden Fall eine interessante Erfahrung für mich, einen solches Druckwerk herauszugeben. Ich habe eine Menge dabei gelernt und würde einiges beim nächsten Mal anders machen. (Dass es ein nächstes Mal geben wird, bezweifle ich allerdings ernsthaft.) Hoffentlich finde ich noch die Zeit, meine Erfahrungen in einem separaten Beitrag zu niederzuschreiben...

Inhalt


Anhang

2013-04-17

Mit der DFG und CIB nach WorldShare und Alma

Zur Klarstellung: Auch dieser Text spiegelt - wie der Rest dieses Blogs - alleine meine Meinung und nicht die meines Arbeitgebers wider.
Die DFG hat am 15. März den Ausgang der wichtigen DFG-Ausschreibung "Neuausrichtung überregionaler Informationsservices" verkündet. Ich denke, das Thema verlangt ein bisschen mehr Aufmerksamkeit in der Fachwelt als ihm bisher zugekommen ist, weil es sich eben nicht um eine der üblichen DFG-Ausschreibungen handelt, sondern um den erklärten Versuch, "einen umfassenden Umstrukturierungsprozess mit anzustoßen und zu unterstützen", der eine grundlegende Veränderung der Informationsinfrastruktur in Deutschland mit sich bringen kann. Im Themenfeld 1 "Bibliotheksdateninfrastruktur und Lokale Systeme" wurde der Antrag "Cloudbasierte Infrastruktur für Bibliotheksdaten (CIB)" bewilligt, mit dem ich mich hier näher befassen möchte.

Letzte Woche wurden Teile des CIB-Antrags veröffentlicht wie auch der von der DFG abgelehnte Konkurrenzantrag zum Projekt libOS. (Disclaimer: Ich habe am libOS-Antrag mitgeschrieben.) Ich begrüße diese Publikationen der Anträge und hoffe, so etwas macht Schule. (Jetzt sind die Antragssteller aus den anderen drei Themenbereichen am Zuge.) Ich habe bereits in einem Blogpost vom September 2011 für mehr Offenheit und Transparenz bei der Weiterentwicklung der deutschlandweiten Informationsinfrastruktur plädiert und am Beispiel der britischen Discovery-Initiative aufgezeigt, wie so etwas ablaufen kann. Schade, dass wir beim Neuaufbau der deutschen Informationsinfrastruktur diese Bewegung hin zu mehr Transparenz erst jetzt erleben, nachdem das Verfahren mehrere Jahre gelaufen ist und nachdem bereits beschlossen wurde, wohin die Reise gehen soll.

Ich habe mir den Gewinnerantrag CIB mal näher angeschaut, da er hoffentlich Aufschluss darüber geben wird, innerhalb welcher Infrastruktur wir in Zukunft unsere Arbeit erledigen werden. Zunächst mal scheint mir dieser Antrag rhetorisch recht wirkungsvoll umgesetzt zu sein. Er basiert auf einigen wenigen Grundannahmen über die zukünftige Entwicklung des Einsatzes von Bibliothekssoftware in Deutschland. Die Prognose wird in dem Antragstext mehrmals wiederholt, so dass sie sich im Kopf des Lesers gut verankern kann. Antworten zur konkreten technischen Umsetzung des Projekts und andere Details werden ausgespart (was sicher auch daran liegt, dass dazu derzeit einfach wenig gesagt werden kann). Eine Abbildung der beabsichtigten Systemarchitektur gibt es nicht.


Keine Alternative zu Cloudsystemen kommerzieller Hersteller

Welches sind nun die Annahmen, die stetig wiederholt werden? Die dem Antrag zugrundeliegende Prognose ist: Sämtliche Verbundsysteme und der Großteil der lokalen Bibliothekssysteme in den deutschen Wissenschaftlichen Bibliotheken würden auf die neuen "Cloudsysteme" von Ex Libris und OCLC migriert werden. Besonders deutlich wird dies in den Prämissen des Antrags. "Prämissen" verstehe ich als Voraussetzungen, von denen abhängt, ob der Antrag überhaupt Sinn ergibt für den Aufbau einer nationalen Informationsinfrastruktur. Die Antragssteller machen aber deutlich, dass sie darunter vielmehr eine - sehr wahrscheinlich eintretende - Prognose oder Vorhersage verstehen. Die drei Prämissen lauten (S. 8f):
  1. "Die Katalogisierung findet zukünftig nicht mehr in regionalen Verbunddatenbanken oder einer nationalen Aggregationsebene statt, sondern in einer international ausgerichteten Umgebung mit internationalem Regelwerk." Das heißt, regionale Verbundkataloge werden verschwinden und nicht durch nationale, sondern internationale Verbundkataloge ersetzt werden.
  2. "Ein nationaler Datenpool im Sinne eines 'nationalen Nachweises' kann in Form einer virtuellen Sicht auf den deutschen Teilbestand der internationalen Datenplattformen ('deutsches Datenfenster') und in Form von 'physischen' Ausspeicherungen generiert werden." Priorität hat demnach die Integration der Daten in proprietäre Cloudsysteme. Ein nationaler Nachweis kann - so man noch die Notwendigkeit sieht - in einem nachrangigen Verfahren generiert werden.
  3. "Die heute unter dem Begriff 'Lokalsystem' subsummierten Funktionen und Services werden ebenfalls weitgehend in cloudbasierte Managementsysteme verlagert." Nicht nur Verbundkataloge werden in die internationale "Cloud" verlagert, sondern eben auch der Großteil der lokalen Bibliothekssysteme.
Der Antrag macht keinen Hehl daraus, an welche "cloudbasierten Managmentsysteme" konkret gedacht wird: WorldShare von OCLC und Alma von Ex Libris. Auf Seite 9 heißt es etwa:
"Das von den Konsortialpartnern vorgeschlagene Infrastrukturmodell sieht vor, die Katalogisierung in den Verbundbibliotheken künftig in internationalen Katalogisierungsumgebungen, wie sie derzeit bereits von den beiden genannten Bibliothekssystemprovidern zur Verfügung gestellt werden, durchzuführen. Dies wird – sieht man auf die deutsche Bibliothekslandschaft – im Regelfall entweder die WorldShare-Umgebung von OCLC (mit dem WorldCat als globalem Datenpool) oder die Alma-Umgebung von Ex Libris (mit der Community Zone als ebenfalls globalem Datenpool) sein."
"Da die Antragsteller bewusst die zurzeit verfügbaren Plattformen als Ziel und zukünftige Arbeitsumgebung ihrer Migrationsstrategie ansehen", integrieren sie auch einen zweiseitigen Werbeblock für OCLC und Ex Libris in ihren Antrag (S. 4-6), in dem man die bekannten Informationen der beiden Hersteller zu ihren Systemen wiederfindet. Als Vorteile dieser Cloudsysteme werden "spürbare Reduzierungen bei der Applikations- und Systembetreuung, die Standardisierung von Arbeitsabläufen und Kernprozessen sowie zahlreiche Möglichkeiten der kooperativen Nutzung von Datenressourcen" und "Effizienzsteigerungen bei der Abwicklung von Routineaufgaben" (S.3) hervorgehoben.
Offensichtlich gegen Ende erst in den Text eingefügt, wird an einer Stelle auch das Open-Source-System Kuali OLE erwähnt, das "kontinuierlich beobachtet und gegebenenfalls in das Arbeitsprogramm einbezogen" werde (S.8).

Die Zukunft der in Deutschland erfassten bibliothekarischen Metadaten ist also in den Cloudsystemen von OCLC und Ex Libris zu suchen. Sollten manche Bibliotheken noch überlegen, ob sie WorldShare/Alma oder vielleicht doch lieber etwas anderes als zukünftiges System wählen sollen, dann werden sie nun durch die DFG mit Förderung dieses Antrags in eine bestimmte Richtung geleitet. Mindestens die BVB-, KOBV-und HeBIS-Bibliotheken werden sich wohl OCLC und Ex Libris zuwenden, weil eine Migration ja nun durch die DFG empfohlen und gefördert wird.

Exit-Strategie?

Soweit kann ich dem Antrag nicht unbedingt widersprechen, hört es sich für mich doch wie eine konsequente Fortführung der Shoppingmentalität in Bezug auf Bibliothekssysteme und der daraus resultierenden Herstellerabhängigkeit an, wie wir sie in der Bibliothekswelt seit Jahrzehnten kennen. [1] Dementsprechend musste in den CIB-Antrag nicht viel Kreativität fließen, wird doch meist das Offensichtliche benannt und beschworen.
Was mich allerdings vom Hocker gehauen hat, ist die einzige Stelle im Text, die Bezug nimmt auf die in der DFG-Ausschreibung geforderte "Herstellerunabhängigkeit". Nachdem auf Seite 9 abermals der allseitige Umstieg auf die OCLC/Ex-Libris-Cloud angekündigt und knapp dessen Vorteile hervorgehoben werden, folgt das hier:
"[Ex Libris' und OCLCs Plattformen für das Bibliotheksmanagement] können zur Entwicklung nutzergetriebener, spezifischer Applikationen eingesetzt werden, für die sowohl WorldShare wie auch Alma auf der Basis offener Schnittstellen bereits spezielle Programmierumgebungen anbieten. Da alle Plattformen die Erstellung kundenspezifischer Funktionserweiterungen erlauben und darüber hinaus auch über offene Schnittstellen in lokale Dienste eingebunden werden können, zeichnet sich für das zukünftige Dienstleistungsportfolio von Bibliotheken das vielversprechende Bild einer serviceorientierten "Orchestrierung" von Diensten ab. In diesem entwicklungsoffenen Konzept wird der Bedarf der Bibliotheken an lokalspezifischen Zusatzdiensten gedeckt, ohne den Gefahren eines Vendor- oder Technology-Lock-ins zu erliegen."
Ich verstehe die Argumentation wie folgt: Da WorldShare und Alma "offene Schnittstellen" anbieten, auf deren Basis man zusätzliche Dienste anbieten kann, ist die Gefahr eines Vendor- oder Technology-Lock-ins gebannt. Hat das eine etwas mit dem anderen zu tun? Meines Erachtens ist diese Aussage Bullshit und erklärt überhaupt nichts, selbst wenn die Schnittstellen für jeden nutzbar und offen lizenziert wären. Abgesehen davon wird "offen" hier als reiner Marketingbegriff verwendet. Die Verwendung hat nichts mit der allseits anerkannten Open Definition zu tun. So sind die WorldShare Web Services bestenfalls für nicht-kommerzielle Akteure nutzbar, meist aber nur durch "Qualifying Insitutions", womit zahlende Kunden gemeint sind. (Im "OCLC Developer Network handbook" heißt es: "Qualifying institutions. Your organization must contribute to WorldCat and maintain a subscription to WorldCat on FirstSearch (or subscribe to WorldCat.org, for non-US").) Bei Alma werden die API-Nutzungsbedingungen wahrscheinlich nicht anders aussehen. Fazit: Der Antrag sagt an keiner Stelle, wie er wirklich mit der Gefahr eines Lock-ins umgehen will, "Offenheit" wird als Marketingbegriff verwendet. Von Exit-Strategien - wenn etwa ein System nicht mehr weiterentwickelt wird oder die Dienstleistung unbezahlbar wird - ist keine Rede. Oder irre ich mich vielleicht doch? Auf Seite 20 heißt es:
"Ex Libris und OCLC sichern vertraglich zu, dass im Falle einer Vertragsauflösung alle Daten einer Bibliothek bzw. eines Bibliothekssystems in einem Standardaustauschformat zurückgeliefert werden. Dies umfasst auch die Daten, die von den Bibliotheken nicht selbst erstellt, sondern nur genutzt wurden ("Ex Libris Guidelines for the Community Catalog", "OCLC Security Whitepaper")."
Aha, wo finden sich denn diese Verträge? Ich wüsste gerne, ob es hier um mehr als Nutzerdaten, Titel- und Normdaten geht. Ich glaube nicht, dass statistische Daten zur Erwerbung und Ausleihe oder weitere durch eine Bibliothek generierte Daten ohne Weiteres aus dem System exportiert werden können. Um Genaueres zu erfahren, habe ich mich auf die Suche nach den "Ex Libris Guidelines for the Community Catalog" und dem "OCLC Security Whitepaper" gemacht. Leider sind beide Dokumente über Google nicht zu finden dies gilt auch für das im Antrag verlinkte OCLC Security Whitepaper. Allerdings ist dieses im Google Cache sowie dem Internet Archive vorhanden. Nach einem schnellen Durchschauen des Dokuments muss ich allerdings sagen, dass die Lieferung von Daten nach Vertragsauflösung nirgendwo angesprochen wird...

Nationale Infrastruktur? Nichts da!

Wie will der Antrag denn nun die in der DFG-Ausschreibung geforderte "Integration der nationalen Erschließungsdaten zur Schaffung einer funktional einheitlichen Katalogisierungs- und Datenplattform" umsetzen? - Gar nicht. Die Antragsteller interessieren sich augenscheinlich in erster Linie für ihre eigenen Kunden. Mir scheint als sei der primäre Zweck des Antrags, die Migration der BVB-, KOBV- und HeBIS-Verbundbibliotheken in die OCLC-/Ex-Libris-Cloud zu finanzieren. Auf Seite 9 heißt es entsprechend:
"Die antragstellenden Verbünde erklären, die hier skizzierte künftige Bibliotheksdateninfrastruktur bei erfolgreicher Projektumsetzung in ihren jeweiligen Verantwortungsbereichen zu institutionalisieren und dauerhaft zu betreiben, sofern die erforderlichen Haushaltsmittel zur Verfügung stehen."
Eine Antwort darauf, wie das Konzept auf die anderen Verbünde ausgeweitet werden soll, bleibt der Antrag schuldig.

Fragwürdig ist auch, dass wahrscheinlich ein Großteil der DFG-Geldmittel direkt oder indirekt an zwei kommerzielle Bibliothekssystemhersteller gehen dürfte. Ich wüsste gerne, ob so etwas gängige Praxis ist oder ob eine Förderung der Produktentwicklung bestimmter Marktteilnehmer mit öffentlichen Geldern nicht problematisch wäre. Ob überhaupt Geld für die Hersteller vorgesehen ist und wieviel genau, ist leider unklar, weil offensichtlich nicht der eingereichte Antrag, sondern mindestens eine gekürzte Fassung veröffentlicht wurde. Der Abschnitt zu den beantragten Mitteln ist vor der Publikation aus dem Antrag entfernt worden. (Siehe auch diese Mail von Rita Albrecht an Inetbib. (Update 2013-04-17, 15:30: Rita Albrecht schreibt auf Inetbib, dass Aufwände der privaten Anbieter nicht Gegenstand des Antrags seien, sondern nur was "auf Seiten der beteiligten Verbuende und Bibliotheken an Leistungen in den Prozess" eingbracht werde. Das hört sich so an, als wären keine Fördergelder für die kommerziellen Anbieter eingeplant.))

Wird der Antrag überhaupt umgesetzt?

Bevor man sich jetzt mit dem Antrag näher auseinandersetzt und überlegt, wie das Schlimmste zu verhindern ist, sollte man allerdings erstmal abwarten, ob sich die Sache nicht von selbst erledigt. Schließlich muss überhaupt erst einmal geklärt werden, ob die Speicherung der Daten außerhalb Deutschlands auf Servern anderer europäischer Länder überhaupt mit dem deutschen Datenschutz vereinbar ist. Genau dies soll gemäß der Projektplanung des CIB-Antrags (S.22) im ersten Projektjahr geschehen. Konkret heißt es dazu auf Seite 19f des Antrags:
"Bei beiden Systemanbietern werden die Verwaltungsdaten für deutsche bzw. europäische Bibliotheken auf Servern innerhalb der Europäischen Union gespeichert, so dass sowohl die Zertifizierung der Rechenzentren als auch die Einhaltung des Datenschutzes dem EU-Recht unterliegt. Nach der Rechtsauffassung der Anbieter wird dies als ausreichend betrachtet, um den Datenschutz und die Datensicherheit zu gewährleisten. Basierend u.a. auf Berichten der EU-Agentur für Internetsicherheit Enisa wird eine Speicherung in Deutschland daher nicht als zwingend notwendig erachtet. Dies gilt es dennoch zu prüfen.
Um hier Sicherheit zu gewinnen, sollten als externe Aufträge die Erstellung eines Gutachtens zu den rechtlichen Anforderungen an die Nutzung von cloudbasierten SaaS-Bibliotheksmanagement-Applikationen, insbesondere im Hinblick auf den Datenschutz und Datensicherheit (Systemverfügbarkeit, physische, Netz- und Applikationssicherheit, Integrität, Vertraulichkeit und Löschung von Daten etc.) sowie die Erarbeitung eines Musters für vertragliche Regelungen mit den Anbietern über die Datenhoheit, über die Einhaltung von einschlägigen Datenschutzrichtlinien und Richtlinien zur Datensicherheit vorgesehen werden."
Ich habe keine Ahnung von der relevanten Gesetzgebung. Allerdings habe ich mitbekommen, dass eine Antwort auf diese Fragen nicht leicht ist und einige Zweifel daran bestehen, ob deutsche Institutionen Nutzerdaten auf Servern bspw. in den Niederlanden speichern dürfen. Mal sehen, was bei dem externen Gutachten herauskommt...


[1] Softwareshopping ist nicht per se problematisch. Allerdings halte ich es als eine langfristige Strategie in öffentlichen Einrichtungen für geboten, die Entwicklung entsprechender Open-Source-Systeme auszuschreiben und einzukaufen wie es etwa beim Kuali-OLE-System geschieht, dessen Entwicklung von HTC Global Services durchgeführt wird. Dies ist ein wichtiger Schritt in Richtung Herstellerunabhängigkeit.

2012-12-12

Querying Freebase to Find Public Domain Authors

In October I wrote about querying DBpedia to find out which authors were born in 1942 resulting in their works (probably) entering the public domain in 2013. In a comment on this post, Tom Morris pointed out that a simple Freebase query easily leads to more results than the - ever-increasing - SPARQL query I had provided for DBpedia (Thanks, Tom). Eventually, I used Freebase to get a list of public domain authors as querying DBpedia to this end turned out to be impractical. (Maybe, in the future libraries will provide data and tools to learn about works entering the public domain...)

Missing class hierarchy in DBpedia

Why is querying DBpedia impractical? Following my blog post, Jindřich Mynarz helped me to improve the SPARQL query on this etherpad. We soon realized that you'd have to build a UNION query with hundreds of classes in order to get all people who died in 1942 and who have published something during their lifetime. The reason is, that little class hierarchy in DBpedia exists. There seems to be some hierarchy in the YAGO ontology that we would have liked to exploit but unfortunately typos in the ontology (rdfs:suBClassOf, see e.g. http://dbpedia.org/class/yago/Essayist110064405) render this impossible.

Querying Freebase

As already mentioned, I ended up querying Freebase. I modified the query provided by Tom and finally got a list of 481 authors who died in 1942 as well as information about their concrete death date, their profession, nationality and works published. I did this using rather a trial and error approach than understanding the details of MQL (Metaweb Query Language). It resulted in this query:
{
    "type": "/book/author",
    "name": [],
    "/people/deceased_person/date_of_death": null,
    "mid": null,
    "/people/person/nationality" : [],
    "/people/person/profession" : [],
    "works_written": [],
    "d2:/people/deceased_person/date_of_death<": "1942-12-31",
    "/people/deceased_person/date_of_death>": "1941-12-31",
    "limit": 500
}
Unfortunately, a query like this with a limit of 500 results would time out. It took me some time to search through the documentations and to finally find out how to employ the cursor in a Freebase query to handle off-sets. At last I came up with this query (now as URL) which worked fine for my purpose:

https://www.googleapis.com/freebase/v1/mqlread?&query=[{"type":"/book/author","name":[],"/people/deceased_person/date_of_death":null,"mid":null,"/people/person/nationality":[],"/people/person/profession":[],"works_written":[],"d2:/people/deceased_person/date_of_death<":"1942-12-31","/people/deceased_person/date_of_death>":"1941-12-31","limit":75}]&cursor

Conversion to Spreadsheet with Google Refine

At last, I needed to convert the JSON files Freebase was providing into CSV or similar to be able to upload it to a Google Spreadsheet. I used Google Refine (in transition to Open Refine), a tool that I have been wanting to try out for quite some time now. It was a logical step to use this tool for my purposes anyhow as it originates from the same people who have developed Freebase...
Google Refine was easy to install. It was also easy to upload the JSON to do some adjustments (mainly moving and renaming columns) and then I could directly upload the result to this Google spreadsheet.

Caveats

I hope, the list of authors and possible public domain works may be useful to some people. It assumes that works enter the public domain 70 years after the author's death which is true for most countries. Of course, this list has to be taken with some care, so you might want to clarify the individual case before digitizing the works and publishing them on the internet. The list also includes many translations of original works which will probalby not enter the public domain in 2013 as translators usually enjoy a copyright for their translations. IANAL.

2012-10-30

Querying DBpedia to find Public Domain Authors


Yesterday, Sam Leon asked for help to populate a list of authors whose work will enter the public domain in 2013. My first thought was: This is a perfect use case for querying DBpedia's SPARQL endpoint! So I tried some queries.

Unfortunately, I had problems with the xsd datatypes when I built my query on the properties dbpedia-owl:deathYear and/or dbpedia-owl:deathDate. Doing a quick search on the web, I noticed that problems with xsd:date aren't new to DBpedia. It didn't work out to write a query guided by the workarounds provided in [1] and [2]. Perhaps somebody else can tell me, how you can solve these problems...

I decided to query based on the wikipeda category 1942 deaths. With this kind of query i had no problems, for example:

PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
PREFIX dct: <http://purl.org/dc/terms/>

SELECT ?person {
    ?person a dbpedia-owl:Writer .
    ?person dct:subject <http://dbpedia.org/resource/Category:1942_deaths> .
}
(See the result for the previous query here.)

This query only delivers persons that are typed as dbpedia-owl:Writer. Franz Boas for example isn't covered. One would have to do more queries with other categories of people that publish written works:
One can combine queries of multiple classes in SPARQL with a UNION query. To only list those people once that are members of multiple classes, one should add a DISTINCT to the SELECT query, for example:
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
PREFIX dct: <http://purl.org/dc/terms/>

SELECT DISTINCT ?person {
    { ?person a dbpedia-owl:Scientist }
    UNION
    { ?person a dbpedia-owl:Writer }
    UNION
    { ?person a dbpedia-owl:Philosopher }
    UNION
    { ?person a <http://dbpedia.org/class/yago/AmericanAnthropologists> }
    UNION
    { ?person dct:subject <http://dbpedia.org/resource/Category:German_poets>  }
    ?person dct:subject <http://dbpedia.org/resource/Category:1942_deaths> . 
}
(result)

Note, that you can also use relevant categories connected to the person by dcterms:subject. This SPARQL query already delivers 102 persons who died in 1942 and most probably all have published at least one written work. The query needs to be extended to cover most of the people in Wikipedia/DBpedia that have published written works.

As one can see, these queries aren't as simple as you would like them to be. That's because you have to adjust to the underlying data which - like all data on the web - is kind of messy. The good thing is: If you have worked out a useful SPARQL query that includes most of the categories and subject classes for people who publish stuff, you can easily re-use the query for upcoming lists of public domain material in coming years.


[1] http://answers.semanticweb.com/questions/947/dbpedia-sparql-endpoint-xsddate-comparison-weirdness

[2] http://pablomendes.wordpress.com/2011/05/19/sparql-xsddate-weirdness/

2012-09-15

Ob Jakob log oder die Zukunft voraussah?

Jakob Voß hat vor gut fünf Jahren nach dem Start der Open Library folgendes prophezeit:
"In spätestens 5 Jahren werden alle wesentlichen Katalogdaten frei sein, zu einem wesentlichen Teil nicht mehr ausschließlich von Bibliothekaren erstellt werden und verschiedene Anbieter werden Suchfunktionen über diese Daten bereitstellen. Auf diesen Wandel sollte sich das Bibliothekswesen einstellen."
Nicht schlecht, Jakob. Ich würde sagen, die Prognose war ziemlich gut. Fünf Jahre nach dem Beitrag sind etliche Normdaten offen zugänglich (viaf.org, DNB u. a.) sowie Titeldaten verschiedenster Organisationen (DNB, BNB, Spanische NationalbibliothekHarvard LibraryEuropeana, hbz, BVB und bei WorldCat/OCLC ist es ja auch losgegangen).[1] Ob das schon "alle wesentlichen Katalogdaten" sind, da kann man vielleicht drüber streiten...

Interessant ist der zweite Teil der Prognose, dass die Katalogdaten 2012 "zu einem wesentlichen Teil nicht mehr ausschließlich von Bibliothekaren erstellt" würden. Dies hat sich bisher so nicht bewahrheitet. Was die offen im Web publizierten Katalogdaten angeht, befinden sich die in bibliothekarischen Institutionen erstellten Daten - wenn ich das richtig einschätze - derzeit klar in der Überzahl. (Ausschließlich wurden Katalogdaten ja ohnehin nie von Bibliothekaren erstellt, wenn man etwa Verlagsdaten dazuzählt.)

Ich denke, die Bibliothekswelt hat sich sehr gut eingestellt auf die sich mit dem Start der Open Library 2007 abzeichnende Entwicklung zu offenen Katalogdaten : Seit 2010 wächst die Zahl der Projekte, in denen Katalogdaten befreit werden. Deshalb ist heute die Open Library nur ein Datenpool unter vielen und ein großer Teil der freien Katalogdaten im Web ist bibliothekarischen Ursprungs. Dazu kommen mittlerweile noch offene bibliographische Daten von Verlagen wie etwa von der Nature Publishing Group. Und sicher wird auch Wikidata in Zukunft einiges zu diesen "Bibliographic Commons" beitragen bzw. daraus schöpfen.

Die wechselseitige Verlinkung, Nachnutzung und Anreicherung der durch Bibliothekare erstellten Daten, der Daten von Verlagen, der Open Library, Wikidata und ähnlichen Diensten steht allerdings noch aus. Dies ist der nächste wichtige Schritt nach der Freigabe der Daten. Zu diesem Zweck gilt es unter anderem, Antworten auf die Fragen nach Provenienzinformationen und Datensynchronisierung zu entwickeln. Beides sind Dinge, an denen schon verschiedentlich gearbeitet wird (z.B. in der Provenance Working Group beim W3C und in ResourceSync-Initiative von NISO und OAI) und die übrigens auch bei der diesjährigen SWIB Thema sein werden.


[1] Für eine Übersicht über frei nachnutzbare bibliographische Daten siehe http://thedatahub.org/group/bibliographic.

2012-06-22

Linked Data in worldcat.org

Two days ago OCLC announced that linked data has been added to worldcat.org. I took a quick look at it and just want to share some notes on this.

OCLC goes open, finally

I am very happy that OCLC - with using the ODC-BY license - finally managed to choose open licensing for WorldCat. Quite a change of attitude when you recall the attempt in 2008 to sneak in a restrictive viral copyright license as part of a WorldCat record policy (for more information see the code4lib wikipage on the policy change or my German article about it). Certainly, it were not at last the blogging librarians and library tech people, the open access/open data proponents etc. who didn't stop to push OCLC towards openness, who made this possible. Thank you all!

Of course, this is only the beginning. One thing is, that dumps of this WorldCat data aren't available yet (see follow-up addendum here), thus, making it necessary to crawl the whole WorldCat to get hold of the data. Another thing is, that there probably is a whole lot of useful information in WorldCat that isn't part of the linked data in worldcat.org yet .

schema.org in RDFa and microdata

What information is actually encoded as linked data in worldcat.org? And how did OCLC add RDF to worldcat.org? It used the schema.org vocabulary to add semantic markup to the HTML. This markup is both added as microdata - the native choice fo schema.org vocab - as well as in RDFa. schema.org lets people choose how to use the vocabulary, on the schema.org blog it recently said: "Our approach is "Microdata and more". As implementations and services begin to consume RDFa 1.1, publishers with an interest in mixing schema.org with additional vocabularies, or who are using tools like Drupal 7, may find RDFa well worth exploring."

Let's take a look at a description of a bibliographic resource in worldcat.org, e.g. http://www.worldcat.org/title/linked-data-evolving-the-web-into-a-global-data-space/oclc/704257552The part of the HTML source containing the semantic markup is marked as "Microdata Section" (although it does also contain RDFa). As the HTML source isn't really readable for humans, we need to get hold of the RDF in a readable form first to have a look at it. I prefer the turtle syntax for looking at RDF. One can get the RDF contained in the HTML out using the RDFa distiller provided by the W3C. More precisely you have to use the distiller that supports RDFa 1.1 as schema.org supports RDFa 1.1 and, thus, worldcat.org is enriched according to the RDFa 1.1 standard.

However, using the distiller on the example resource I can get back a turtle document that contains the following triples:

1:  @prefix library: <http://purl.org/library/> .  
2:  @prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#> .  
3:  @prefix owl: <http://www.w3.org/2002/07/owl#> .  
4:  @prefix schema: <http://schema.org/> .  
5:  @prefix skos: <http://www.w3.org/2004/02/skos/core#> .  
6:  <http://www.worldcat.org/oclc/707877350> a schema:Book;  
7:    library:holdingsCount "1"@en;  
8:    library:oclcnum "707877350"@en;  
9:    library:placeOfPublication [ a schema:Place;  
10:        schema:name "San Rafael, Calif. (1537 Fourth Street, San Rafael, CA 94901 USA) :"@en ];  
11:    schema:about [ a skos:Concept;  
12:        schema:name "Web site development."@en;  
13:        madsrdf:isIdentifiedByAuthority <http://id.loc.gov/authorities/subjects/sh98004795> ],  
14:      [ a skos:Concept;  
15:        schema:name "Semantic Web."@en;  
16:        madsrdf:isIdentifiedByAuthority <http://id.loc.gov/authorities/subjects/sh2002000569> ],  
17:      <http://dewey.info/class/025/e22/>,  
18:      <http://id.worldcat.org/fast/1112076>,  
19:      <http://id.worldcat.org/fast/1173243>;  
20:    schema:author <http://viaf.org/viaf/38278185>;  
21:    schema:bookFormat schema:EBook;  
22:    schema:contributor <http://viaf.org/viaf/171087834>;  
23:    schema:copyrightYear "2011"@en;  
24:    schema:description "1. Introduction -- The data deluge -- The rationale for linked data -- Structure enables sophisticated processing -- Hyperlinks connect distributed data -- From data islands to a global data space -- Introducing Big Lynx productions --"@en,  
25:      "The World Wide Web has enabled the creation of a global information space comprising linked documents. As the Web becomes ever more enmeshed with our daily lives, there is a growing desire for direct access to raw data not currently available on the Web or bound up in hypertext documents. Linked Data provides a publishing paradigm in which not only documents, but also data, can be a first class citizen of the Web, thereby enabling the extension of the Web with a global data space based on open standards - the Web of Data. In this Synthesis lecture we provide readers with a detailed technical introduction to Linked Data. We begin by outlining the basic principles of Linked Data, including coverage of relevant aspects of Web architecture. The remainder of the text is based around two main themes - the publication and consumption of Linked Data. Drawing on a practical Linked Data scenario, we provide guidance and best practices on: architectural approaches to publishing Linked Data; choosing URIs and vocabularies to identify and describe resources; deciding what data to return in a description of a resource on the Web; methods and frameworks for automated linking of data sets; and testing and debugging approaches for Linked Data deployments. We give an overview of existing Linked Data applications and then examine the architectures that are used to consume Linked Data from the Web, alongside existing tools and frameworks that enable these. Readers can expect to gain a rich technical understanding of Linked Data fundamentals, as the basis for application development, research or further study."@en;  
26:    schema:inLanguage "en"@en;  
27:    schema:isbn "1608454312"@en,  
28:      "9781608454310"@en;  
29:    schema:name "Linked data evolving the web into a global data space"@en;  
30:    schema:publisher [ a schema:Organization;  
31:        schema:name "Morgan & Claypool"@en ];  
32:    owl:sameAs <http://dx.doi.org/10.2200/S00334ED1V01Y201102WBE001> .  

This looks quite nice to me. You see, how schema.org let's you easily convey the most relevant information and the property names are well-chosen to make it easy for humans to read the RDF (in contrast e.g. to the ISBD vocabulary which uses numbers in the property URIs following the library tradition :-/).

The example also shows the current shortcomings of schema.org and where the library community might put some effort in to extending it, as OCLC has already been doing for this release with the experimental "library" extension vocabulary for use with Schema.org. E.g., there are no seperate schema.org properties for a table of content and an abstract so that they are both put into one string using ther schema:description property.

Links to other linked data sources

There are links to several other data sources: LoC authorities (lines 13, 16, 41, 44) , dewey.info (17), the linked data FAST headings (18,19), viaf.org (20,22) and an owl:sameAs link to the HTTP-DOI identifier (32). As most of these services are already run by OCLC and as the connections probably all were already existent in the data, creating these links wasn't hard work, which of course doesn't make them less useful.

Copyright information

What I found very interesting is the schema:copyrightYear property used in some descriptions in worldcat.org. I don't know how much resources are covered with the indication of a copyright year and how accurate the data is, but this seems a useful source to me for projects like publicdomainworks.net.

Missing URIs

As with other preceding publications of linked bibliographic data there are some URIs missing for things we might want to link to instead of only serving the name string of the respecting entity: I am talking about places and publishers. Until now, AFAIK URIs for publishers don't exist, hopefully someone (OCLC perhaps?) is already working on a LOD registry for publishers. For places, we have geonames but it is not that trivial to generate the right links. It's not a great surprise that a lot of work has to be done to build the global data space.