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.

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.

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:

• Querying philosophers which yields one answer: Kurt Grelling.
• Querying scientists is more fruitful.

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/

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 Nationalbibliothek, Harvard Library, Europeana, 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.

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/704257552. The 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.

DAIA & describing organizations, services, collections in RDF

In January Jakob Voß published the request for comments for the final DAIA specification. DAIA - Jakob writes -

"is more than an implementation: it provides both, an abstract standard and bindings to several data languages (XML, JSON, and RDF). The conceptual DAIA data model defines some basic concepts and relationships (document, items, organisations, locations, services, availabilities, limitations…) independent from whether they are expressed in XML elements, attributes, RDF properties, classes, or any other data structuring method."

As I have put some thought into the RDF-description of libraries, their services, collections, locations etc. for my master thesis (PDF, German) and as I will be holding a talk on this topic - together with Jakob - at this year's Bibliothekartag, I finally submit this comment on DAIA.

DAIA - Why and how?

Why was DAIA developed in the first place? As Jakob describes it in a post from 2009 DAIA tries to provide an API specification that's missing in the standard APIs for libraries, an

"open, usable standard way just to query whether a copy of given publication – for instance book – is available in a library, in which department, whether you can loan it or only use it in the library, whether you can directly get it online, or how long it will probably take until it is available again."

Thus, the" Document Availability Information API (DAIA) defines a data model with serializations in JSON, XML, and RDF to encode and query information about the current availability of documents" (from the English introduction). That is a very important standard and I hope DAIA will become widely adopted by libraries and system providers. I hope that my comments may help improving DAIA.

The Data Model

Here, I will focus on the underlying conceptual DAIA data model and on the corresponding OWL ontology. I am neither a heavy API user nor an API engineer and as such simply have no expertise on this so that I won't comment on the API specification at all.

As seen in the graphical representation of the conceptual model, DAIA's core classes are "Document", "Organization", "Service" and "Item".

I won't go into all the details here, just take a look at the specification and the ontology.

In my master thesis I took quite another approach than Jakob as my thoughts originated from the problem how to add structured data - e.g. in form of RDFa - to existing library websites.  Naturally, I didn't focus on the availability of documents, in fact I didn't go deeper into this topic but put my thoughts into describing an organisation, its site(s), collection(s) and services. I had a look at some library websites to find out what kind of information normally is displayed there and how to classify it. My general conceptual model that served as basis for a more detailled study (update and slightly reduced for this purpose as well as leaving aside the serials problem)  looks like this:

The DAIA model and my approach look quite similar in that both data models contain the core classes Document, Service, Organisation and Item. But also these models differ in at least one point: While DAIA establishes a Storage class the latter model uses the two classes of Site and Collection to express similar information.

Questions, Comments and Suggestions

After having highlighted my background, I want to proceed with actually responding to Jakob's call with some comments. I already gave some input on the W3C-LLD mailing list and might repeat myself here.

Storage

I have a problem understanding why the Storage class exists at all and whether it makes sense. If a collection is stored in closed stacks, it's of no interest to the user where an item actually resides, what's important to her, is where to get it, i.e. to know where the circulation desk is. Thus, I think one could even decrease complexity by omitting the Storage class. All users and applications care about is where to obtain an item not where it actually comes from. Thus, it's services that really count, not storage. (If an item is stored in a reading room, I would go on and classify the reading room as a service where items can be viewed locally but cannot be lent.)

Collection

Every library curates at least one collection which might comprise a number of subcollections. Often, on their web sites libraries give information about their collections by indicating the number of items in them, their mode of access, acquisition policy, contact information for a sub collection as well as storage location etc. That's why it might be useful to also make use of a collection class and to describe collections. But collection description is definitely not necessary to provide good services for users to easily obtain material they already identified as relevant for their needs. It's useful for other cases in which a researcher wants to find a number of libraries holding special collections he might be interested in. Or for libraries to find similar institutions in order to share data for improving the acquisition of new material.

DAIA namespaces

I don't get it, why the DAIA service classes get their own namespace, adding a "Service/" to the DAIA namespace, e.g. for loan . This isn't common practice and is really annoying. When you are writing turtle you either have to declare an extra prefix for the Service namespace or you have to write the whole URI as slashes aren't allowed after a prefix. (At least rapper doesn't like it.)

Minor comments

• An update of the graph model is needed as the dct:spatial property is displayed to link an Item to a Storage. That is neither mentioned anywhere in the ontology nor a correct use of this property.
• To be able to have a more concrete discussion I provide an example RDF description in a seperate post.

Web-Thesauri im Wandel der Zeit

Im Anschluss an Joachim Neuberts gestrigen Vortrag im Rahmen des DINI-KIM-Workshops zum "Standard Thesaurus Wirtschaft (STW) als Dauerbaustelle" (Update: hier gibt es die Folien zu  Vortrag) war ein Hauptdiskussionspunkt die Frage, wie mit der Veränderung eines Thesaurus über die Zeit umzugehen sei.

Joachim nannte konkrete Zahlen, inwiefern sich der STW von einer Version zur anderen ändert: Neben einigen neuen Deskriptoren kommen etliche neue Nicht-Deskriptoren hinzu, Deskriptoren werden gelöscht oder erhalten neue präferierte Etiketten. All dies gilt es im Kontext einer Linked-Data-Variante des Thesaurus zu berücksichtigen und zu dokumentieren. Momentan gibt es im Linked-Data-STW einen übergeordneten URI für einen Deskriptor (z. B. http://zbw.eu/stw/descriptor/15441-2), die für alle seine Versionen steht. Bei Aufruf dieses URIs wird man mittels Redirect und Content Negotiation weitergeleitet auf die aktuelle Version der Deskriptorenneschreibung (http://zbw.eu/stw/versions/latest/descriptor/15441-2/about) im angefragten Format.

"Sammel"-URIs vs. Versionen-URIs

Diese Praxis eines Sammel-URIs, der für alle Versionen eine Deskriptors steht, wurde insbesondere von Georg Hohmann kritisiert. Ich habe sein Argument wie folgt verstanden: Sobald sich in unserer Beschreibung eines Konzepts auch nur ein wenig ändert, handelt es sich nicht mehr um die Beschreibung desselben Konzepts und muss einen neuen URI bekommen. Eine Änderung des präferierten Etiketts, die Ergänzung eines Nicht-Deskriptors oder die Ergänzung oder Löschung eines Verweises machen die Beschreibung also zu einer Beschreibung eines neuen Konzepts, was wiederum das Prägen eines neuen URIs nötig macht.

Übrigens: Ich finde es sehr problematisch, dass im Kontext von Thesauri und Klassifikationen häufig von "Konzepten"gesprochen wird (insbesondere SKOS ist mit diesem Sprachgebrauch durchwirkt). Das Denken in Konzepten verursacht m.E. mehr (Pseudo-)Probleme, wenn es um Dokumentationssprachen geht, als dass es Nutzen bringt. Aber dazu vielleicht mehr zu einem anderen Zeitpunkt. Im folgendenwerde ich jedenfalls konsequent von "Deskriptoren" sprechen.

Konsequente Umsetzung unmöglich

Ich gebe der Auffassung recht, dass sich Deskriptoren eine Thesaurus wandeln, sobald ihre Beschreibung verändert wird. Allerdings meine ich, dass ein Deskriptor auch durch andere Veränderungen einem stetigen Bedeutungswandel unterliegt. So wird die Bedeutung eines Deskriptors auch durch Löschung oder Hinzufügen anderer Deskriptoren desselben Thesaurus verändert, weil sich das Anwendungsgebiet des Deskriptors (seine Extension) dadurch erweitern oder verkleinern kann. Zudem ist ein Thesaurus kein in sich geschlossenes System. Vielmehr wird auch auf Deskriptoren von außen verwiesen, der Thesaurus verweist selbst auf Ausdrücke der natürlichen Sprache (mit Etiketten/Labels) und er wird von Katalogisieren und anderen bei der Inhaltserschließung angewandt. Dies führt dazu, dass die Bedeutung eines Deskriptors einem stetigen Wandel unterworfen ist.

1. Ein Deskriptor besteht meist aus einer ID, einer Menge von (präferierten und alternativen) Etiketten, möglicherweise in verschiedenen Sprachen sowie aus einer Menge von Verweisen (broader, narrower, match, see also) auf andere Deskriptoren innerhalb oder außerhalb des eigenen Thesaurus. Seine Bedeutung wird primär durch diese Referenzen zur natürlichen Sprache und zu anderen Deskriptoren bestimmt. Folglich ändert sich diese Bedeutung auch, wenn sich an den Verweisen etwas ändert. So müsste also der URI eines Deskriptors jedes Mal angepasst werden, wenn sich bei einem Deskriptor etwas ändert, auf den jener verweist.
2. Wie bereits erwähnt, wird ein Deskriptor allerdings nicht auschließlich oder hinreichend durch seinen Thesaurus-Eintrag definiert. Vielmehr bestimmt sekundär auch die Anwendung eines Deskriptors über dessen Bedeutung (Frei nach Wittgenstein: "Die Bedeutung eines Deskriptors ist sein Gebrauch in der Inhaltserschließung."). Es gibt sicher genügend Beispiele, wo ein Deskriptor im Widerspruch zu seiner ursprünglich intendierten Funktion benutzt wird, ich selbst habe dies schon häufig genug gesehen. Und wie wir von der natürlichen Sprache wissen, wird ein "falscher" Symbolgebrauch irgendwann korrekt, sobald genügend Menschen die "falsche" Verwendung praktizieren (Beispiele sind etwa "der Blog", "die URI", "wegen dem" etc.). Der Logik folgend, dass ein Deskriptor einen neuen URI braucht, sobald er nicht mehr "dasselbe Konzept" beschreibt, müsste sich mit jeder Anwendung eines Deskriptors seine URI ändern.
3. Wie gesagt wird die Bedeutung eines Deskriptors innerhalb eines Thesaurus u.a. durch Verweis auf natürlichsprachige Etiketten definiert. Auch diese unterliegenden in ihrer Nutzung innerhalb einer Sprachgemeinschaft einem stetigen Wandel. Wenn gestern "Management" nur im Kontext der Führung von Unternehmen und anderen Organisationen benutzt wurde, haben sich heute die Verwendungskontexte erweitert. Müssten dies nicht die entsprechenden Einträge in Thesauri berücksichtigen und beim Gebrauchswandel eines Deskriptor-Labels den URI des Deskriptors verändern? Jeder Person dürfte klar sein, dass dies keinen Sinn ergibt.

URIs und Veränderung von Webressourcen in der Zeit

Ich bin zwar wie Georg Hohmann der Meinung, dass die in einem Thesaurus aufgereihten Deskriptoren einem ständigen Bedeutungswandel unterliegen:

1. weil sich Deskriptoren wandeln, auf die ein Deskriptor verweist,
2. weil sich die Verwendung des Deskriptors bei der Inhaltserschließung verändert,
3. weil sich der Gebrauch der mit ihm assoziierten natürlichsprachlichen Etiketten wandelt
4. und weil das Hinzufügen/Löschen neuer Deskriptoren zum Thesaurus das Anwendungsgebiet der anderen Deskriptoren beeinflusst

Diesen Wandel würde ich aber nicht unbedingt zum Anlass nehmen, bei jeder Bedeutungsänderung einen neuen URI zu prägen. Wie soll man aber sonst mit dem Problem umgehen?

Das hier diskutierte Problem wird im Web-Kontext durch die Unterscheidung von Ressource und Repräsentation zum Ausdruck gebracht. Ich habe etwa die Ressource, die durch den URI "http://www.spiegel.de/" identifiziert wird, von der ich allerdings zu verschiedenen Zeitpunkten verschiedene Repräsentationen, unter Umständen sogar in verschiedenen Sprachen oder Formaten (Language/Content Negotiation) ausgeliefert bekomme.

Es gibt also mindestens drei Dimensionen, in denen sich verschiedene Repräsentationen einer Web-Ressource voneinander unterscheiden können:

• Format
• Sprache
• Zeitpunkt (und damit im Inhalt zu verschiedenen Zeitpunkten)

Der Logik folgend, dass unterschiedliche Dinge unterschiedliche URIs haben sollten, müsste jede Repräsentation ihre eigene URI bekommen. Dies wird aber derzeit nicht gemacht.

Es gibt derzeit Bemühungen, um den zeitlichen Aspekt einer Ressource zu berücksichtigen und die unterschiedlichen Repräsentationen adressierbar zu machen: Das Memento-Projekt möchte zur Content-Negotiation die zeitliche Dimension hinzufügen. So soll es möglich werden, bei der Anfrage einer Web-Ressource über den HTTP-Header eine bestimmte zeitliche Repräsentation dieser Ressource anzufordern.

Memento & Thesauri

Eine Memento-Implementierung in einem Online-Thesaurus würde es ermöglichen, Repräsentationen/Versionen eines Deskriptors zu einem bestimmten Zeitpunkt zu adressieren, ohne dass zusätzliche URIs für verschiedene Versionen geprägt werden müssten.

Eine solche Art der Versionierung auf Veröffentlichungsseite wäre allerdings nur eine Seite der Problemlösung. Auf Nutzungsseite, wenn es um die Verwendung von Deskriptioren in der Inhaltserschließung oder um Mappings zwischen Thesauri geht, wäre es genauso wichtig, den Zeitpunkt der Vergabe eines Deskriptors zu dokumentieren. Wie eine solche Dokumentation aussehen könnte, dazu hat sich Felix Ostrowski schon ein paar Gedanken gemacht. Ein anderer Ansatz wäre die Verwendung von dated URIs (DURIs), die in diesem Internet-Draft spezifiziert werden. DURIS würden es auch ermöglichen, über einzelne Versionen RDF-Statements zu verfassen.

Ich halte es für sinnvoll, einen generischen Ansatz zur Versionierung von Webressourcen einem Thesaurus-spezifischen Ansatz vorzuziehen und würde mich interessieren, was Thesaurus-Fachleute davon halten.