Name Authority Files & Linked Data

I haven't been spending very much time following the developments regarding the Bibframe vocabulary and only follow the Bibframe mailing list sporadically. That's why I am happy when someone else makes the effort to take a deeper look at the vocabulary and reports the results. That is what Robert Sanderson did with his text titled "Differences between BibFrame and other Linked Open Data Approaches".

The Problem: Using strings as/instead of identifiers

In his text, Rob wants to "point out the differences between BibFrame's use of RDF and other more common usage patterns". This blog post only discusses the first of the differences Rob points out in the chapter "String Authorities rather than Identifiers": Instead of putting the focus on interlinking things (bibliographic resources, persons, concepts, organisations etc.) identified by URIs, Bibframe emphasizes an approach that rather builds on using blank node identifiers and defining authorities by a canonical string like "Tolkien, J. R. R. (John Ronald Reuel), 1892-1973". Rob writes:

"BibFrame tries to make use of existing authority records and canonical string-based labels due to its background in MARC, a format designed to be as compact as possible for adding metadata to strings. Unfortunately, this does not map well into Linked Data which makes use of identifiers to globally and uniquely distinguish real world and digital entities. These two world-views collide in the use of Authorities in BibFrame."

By and large, I agree with Rob's diagnosis. It is important to note that this "string approach" isn't limited to Bibframe (as Rob says himself when he refers to MADS) but to a whole approach of representing authority data in RDF. Also, this isn't solely a MARC thing but is based on the Anglo-American cataloging practice in general. In fact, one can easily use MARC with an identifier-based authority approach as a look at some MARC records of German libraries shows. (Further down more about this.)

There are different practices of authority cataloging

What became clear to me while reading Rob's text is that German libraries might better be avoiding Bibframe, at least if its focus stays on a string-based authority approach. The following statement by Rob may be true for the Anglo-American cataloging practice:

An "authority is about the approved form in which the person's name should be recorded as a string, it does not identify the person directly. (...) This is a fundamental difference between regular Linked Open Data and BibFrame's use of RDF. BibFrame relies on strings, due to its heritage, whereas LOD makes use of identity."

Accordingly, the Library of Congress describes its name authority file as follows (my emphasis):

"The Library of Congress Name Authority File (NAF) file provides authoritative data for names of persons, organizations, events, places, and titles."

Accordingly, this is what the authority RDF for Tolkien looks like in the Library of Congress name authority (snippet):

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#> .
@prefix identifiers: <http://id.loc.gov/vocabulary/identifiers/> .

    a madsrdf:Authority, madsrdf:PersonalName, skos:Concept ;
    identifiers:lccn "n 79005673" ;
    identifiers:oclcnum "oca00239830" ;
    madsrdf:authoritativeLabel "Tolkien, J. R. R. (John Ronald Reuel), 1892-1973"@en ;
    madsrdf:elementList ([
            madsrdf:elementValue "Tolkien, J. R. R."@en ;
            a madsrdf:FullNameElement
            madsrdf:elementValue "(John Ronald Reuel),"@en ;
            a madsrdf:FullNameElement
            madsrdf:elementValue "1892-1973"@en ;
            a madsrdf:DateNameElement
    ) ;
    madsrdf:hasExactExternalAuthority <http://viaf.org/viaf/sourceID/LC%7Cn+79005673#skos:Concept> ;
    madsrdf:identifiesRWO [
        madsrdf:birthdate "18920103" ;
        madsrdf:deathdate "19730902" ;
        madsrdf:hasAffiliation [
            madsrdf:affiliatedWith "University of Leeds" ;
            a madsrdf:Affiliation
        ], [
            madsrdf:affiliatedWith "University of Oxford" ;
            a madsrdf:Affiliation
        ] ;
        a madsrdf:RWO, <http://xmlns.com/foaf/0.1/Person>
    ] .

One may find information about the "real word object" in this RDF but it doesn't get that much attention as it not even gets its own URI but is only identified by a blank node. (We will see further down that Library of Congress's approach is unique in this respect compared to other RDF authority files worldwide.)

About cataloging practice in Germany and Austria, though, one can not say that it "relies on strings" . A central tool for German-speaking catalogers is the German Integrated Authority File — created and curated by many different institutions in the German-speaking world. The Integrated Authority File exists since 2012 and is the product of integrating three different authority files for persons, corporate bodies and subject headings. It is described by the Deutsche Nationalbibliothek (DNB) as follows.

"The Integrated Authority File (GND) contains data records representing persons, corporate bodies, congresses, geographic entities, topics and works."

This already sounds a bit different and doesn't mention "names" at all. Let's take a deeper look at the German cataloging practice regarding authorities.

German ID-based authority practice

In the Integrated Authority File an numeric ID (GND ID) is used to identify an authority record. Likewise, each bibliographic record that references this authority record uses the GND ID. For an example take a look at these two MARC XML records from DNB.

This cataloging practice emerged in the 1990s and makes German library data "linked data ready". The Integrated Authority File data was one of the first linked data publications in the German library world. Publishing the authority data, Deutsche Nationalbibliothek chose another approach than the Library of Congress. Instead of just publishing authority records in RDF and assigning URIs (Uniform Resource Identifiers) to these records they created URIs for the things the authority records describe, i.e. for persons, corporate bodies topics etc. "http://dnb.info/" is used as namespace where the respective GND ID is appended. For example: The ID for Tolkien's authority record is '118623222' and his Linked data URI is 'http://d-nb.info/gnd/118623222'. You can fetch the following RDF information from this URI (snippet, in turtle notation):

GND authority data in RDF

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix gndo: <http://d-nb.info/standards/elementset/gnd#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

    gndo:gndIdentifier "118623222" ;
    gndo:preferredNameEntityForThePerson [
        gndo:forename "J. R. R." ;
        gndo:surname "Tolkien"
    ] ;
    gndo:preferredNameForThePerson "Tolkien, J. R. R." ;
    a gndo:DifferentiatedPerson ;
    owl:sameAs <http://dbpedia.org/resource/J._R._R._Tolkien>, <http://viaf.org/viaf/95218067> ;
    foaf:page <http://de.wikipedia.org/wiki/J._R._R._Tolkien> .

As you can see, the German Integrated Authority File (GND) has its own ontology (GND ontology, see here for an overview over the ontology's class hierarchy) created and maintained by the DNB. The owl:sameAs links to DBpedia and VIAF (which models person authorities as persons, not as strings) clearly show that GND defines name authorities as persons with an ID and not simply as name authorities with canonical strings.

Linking to GND using Dublin Core & MARC relators

From 2010 on a handful of libraries and library service centers in Germany started publishing their bibliographic records as linked data. As one might expect reading the previous paragraph, it was quite easy for them to not only produce RDF but to link to other datasets, at least to the GND. Just take a look at these examples from two German union catalogs in RDF: lobid and b3kat.

In 2012, the DNB started publishing the German national bibliography as linked data. Also in 2012, different linked data publishers form the German-speaking library world started working together within the KIM-DINI working group (KIM = Competence Centre Interoperable Metadata) to promote best practices for the RDF representation of bibliographic records which resulted in a set of recommendations (German, pdf) first published 2013. Following these recommendations, an RDF representation of a DNB title record currently looks like this (snippet):

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix marcRole: <http://id.loc.gov/vocabulary/relators/> .

    marcRole:ill <http://d-nb.info/gnd/156605406> ;
    marcRole:trl <http://d-nb.info/gnd/110833732> ;
    dc:title "Der kleine Hobbit" ;
    dcterms:alternative "The hobbit <dt.>" ;
    dcterms:creator <http://d-nb.info/gnd/118623222> ;
    dcterms:issued "2012" .

You can see how DC terms and MARC relator properties are used to directly link to the persons in the GND authority file. (And yes, the German version of "The hobbit" was named "The small hobbit" though Bilbo is actually of average height — at least for a hobbit.)

Linking to GND using Bibframe (test data)

For some weeks now, DNB provides Bibframe representations of the title records along with the just mentioned linked data. Here is the RDF that you get when requesting it for the same resource:

@prefix bf: <http://bibframe.org/vocab/> .

    bf:dimensions "20 cm" ;
    bf:ean "9783423715669" ;
    bf:editionStatement "Neuausg." ;
    bf:extent "397 S." ;
    bf:frequency <http://marc21rdf.info/terms/continuingfre%23/u> ;
    bf:illustrativeContentNote "Ill." ;
    bf:instanceOf <http://d-nb.info/bf_temp/work_1034321757> ;
    bf:isbn10 "3423715669" ;
    bf:isbn13 "9783423715669" ;
    bf:modeOfIssuance "Einbändiges Werk" ;
    bf:nbn "13,A46", "13,N20" ;
    bf:responsibilityStatement "John Ronald R. Tolkien. Aus dem Engl. von Walter Scherf. Mit Vignetten von Max Meinzold" ;
    bf:title "Der kleine Hobbit" ;
    a bf:Instance .

    bf:associatedAgent [
        bf:hasGNDLink <http://d-nb.info/gnd/118623222> ;
        bf:label "Tolkien, J. R. R." ;
        bf:resourceRole <http://id.loc.gov/vocabulary/relators/aut> ;
        a bf:Person
    ], [
        bf:hasGNDLink <http://d-nb.info/gnd/110833732> ;
        bf:label "Scherf, Walter" ;
        bf:resourceRole <http://id.loc.gov/vocabulary/relators/trl> ;
        a bf:Person
    ], [
        bf:hasGNDLink <http://d-nb.info/gnd/156605406> ;
        bf:label "Hehn-Kynast, Juliane" ;
        bf:resourceRole <http://id.loc.gov/vocabulary/relators/ill> ;
        a bf:Person
    ], [
        bf:hasGNDLink <http://d-nb.info/gnd/1022774611> ;
        bf:label "Meinzold, Max" ;
        bf:resourceRole <http://id.loc.gov/vocabulary/relators/ill> ;
        a bf:Person
    ] ;
    bf:hasInstance <http://d-nb.info/1034321757> ;
    bf:title "Der kleine Hobbit", "The Hobbit" ;
    bf:uniformTitle "The Hobbit, dt." ;
    a bf:Work .

The most obvious difference compared to the DC-based RDF above is that there are actually two resources — a Bibframe instance and a work. Taking a look at the links to authority data you see what Rob is complaining about: Instead of a simple dcterms:creator link between a bibliographic resource and a person you get a blank node for a Bibframe person that then links to the GND with bf:hasGNDLink. Doesn't look like any sane person would prefer this data over the RDF shown above.

How do others do it?

So we have these two different practices of representing name authority data in RDF and see that the Bibframe initiative — calling itself the "foundation for the future of bibliographic description that happens on the web and in the networked world" — chose a rather impractical approach. This begs the question of how others do this. I understand Bibframe as an initative with an international scope so I guess it should meet the demands and be in line with authority practices around the world.

Below are examples of some RDF representations of records from other name/person authority files (snippets). I won't go into much detail discussing these but will comment on the general approach taken.


VIAF follows the same Linked Data compatible approach as DNB to represent authorities in RDF. Tolkien is typed as foaf:Person and can be directly linked to using properties like dcterms:creator.


@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix void: <http://rdfs.org/ns/void#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix viaf: <http://viaf.org/ontology/1.1/#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix skosxl: <http://www.w3.org/2008/05/skos-xl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdaGr2: <http://rdvocab.info/ElementsGr2/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdaEnt: <http://rdvocab.info/uri/schema/FRBRentitiesRDA/> .

    rdaGr2:dateOfBirth "1892-01-03" ;
    rdaGr2:dateOfDeath "1973-09-02" ;
    a rdaEnt:Person, foaf:Person ;
    owl:sameAs <http://d-nb.info/gnd/15818212X>, <http://data.bnf.fr/ark:/12148/cb11926763j#foaf:Person>, <http://dbpedia.org/resource/J._R._R._Tolkien>, <http://libris.kb.se/resource/auth/97224>, <http://www.idref.fr/027164918/id> ;
    foaf:name "J.R.R Tolkien", "JRR Tolkien", "John Ronald Reuel Tolkien", "T'olk'in, J. R. R. 1892-1973", ... .


Looking to Sweden's Libris catalog, we see a lot of similarities to VIAF. Libris primarily types person authorities as foaf:Person but adds a skos:Concept with its own URI which is linked to the person with foaf:focus.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dbpedia: <http://dbpedia.org/property/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rda: <http://RDVocab.info/ElementsGr2/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix libris: <http://libris.kb.se/vocabulary/experimental#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

    rda:dateOfBirth "1892" ;
    rda:dateOfDeath "1973" ;
    dbpedia:birthYear "1892" ;
    dbpedia:deathYear "1973" ;
    libris:key "Tolkien, J. R. R., 1892-1973" ;
    rdf:seeAlso <http://en.wikipedia.org/wiki/J._R._R._Tolkien> ;
    a foaf:Person ;
    rdfs:isDefinedBy <http://data.libris.kb.se/open/auth/97224.rdf> ;
    owl:sameAs <http://dbpedia.org/resource/J._R._R._Tolkien>, <http://id.loc.gov/authorities/names/325978>, <http://viaf.org/viaf/95218067> ;
    foaf:name "J. R. R Tolkien", "John R. R Tolkien", "John Ronald Reuel Tolkien", "Tolkien, J. R. R., 1892-1973", "Tolkien, John R. R., 1892-1973", "Tolkien, John Ronald Reuel, 1892-1973" .

    a skos:Concept ;
    skos:altLabel "J. R. R Tolkien", "John R. R Tolkien", "John Ronald Reuel Tolkien", "Tolkien, J. R. R., 1892-1973", "Tolkien, John R. R., 1892-1973", "Tolkien, John Ronald Reuel, 1892-1973" ;
    skos:exactMatch <http://viaf.org/viaf/95218067/#skos:Concept> ;
    foaf:focus <http://libris.kb.se/resource/auth/97224> .

National Diet Library (NDL), Japan

An authority file of the National Diet Library looks quite similar to Libris' authorities. Interestingly, foaf:primaryTopic is used instead of foaf:focus to link the skos:Concept to the foaf:Person.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xl: <http://www.w3.org/2008/05/skos-xl#> .
@prefix rda: <http://RDVocab.info/ElementsGr2/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dct: <http://purl.org/dc/terms/> .

    rda:dateOfBirth "1931" ;
    a foaf:Person ;
    foaf:name "阿部洋" .

    dct:created "1979-04-01" ;
    dct:modified "2005-01-05T10:44:08" ;
    dct:source "奥付", "韓国と台湾の教育開発 / 阿部宗光, 阿部洋 編" ;
    a skos:Concept ;
    rdfs:label "阿部, 洋, 1931-" ;
    skos:exactMatch <http://viaf.org/viaf/sourceID/NDL%7C00000047> ;
    skos:inScheme <http://id.ndl.go.jp/auth#personalNames> ;
    xl:prefLabel [
        ndl:transcription "Abe, Hiroshi, 1931-"@ja-latn, "アベ, ヒロシ, 1931-"@ja-kana ;
        xl:literalForm "阿部, 洋, 1931-"
    ] ;
    foaf:primaryTopic <http://id.ndl.go.jp/auth/entity/00000047> .

Bibliothèque nationale de France

BNF does it the other way around compared to Libris. Here, the a name authority is primarily typed as skos:Concept. This skos:Concept is linked to the person Tolkien using foaf:focus and, thus, enables direct linking to person authorities.

@prefix bio: <http://vocab.org/bio/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdagroup2elements: <http://RDVocab.info/ElementsGr2/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

    a skos:Concept ;
    rdfs:seeAlso <http://catalogue.bnf.fr/ark:/12148/cb11926763j>, <http://fr.wikipedia.org/wiki/J._R._R._Tolkien> ;
    owl:sameAs <http://dbpedia.org/resource/J._R._R._Tolkien>, <http://isni-url.oclc.nl/isni/0000000121441970>, <http://www.idref.fr/027164918> ;
    skos:altLabel "John Ronald Renel Tolkien (1892-1973)"@fr ;
    skos:prefLabel "John Ronald Reuel Tolkien (1892-1973)"@fr ;
    foaf:focus <http://data.bnf.fr/ark:/12148/cb11926763j#foaf:Person> .

    a foaf:Person ;
    rdagroup2elements:biographicalInformation "Romancier. - Professeur de langue et littérature anglo-saxonnes" ;
    rdagroup2elements:dateOfBirth <http://data.bnf.fr/date/1892/> ;
    rdagroup2elements:dateOfDeath <http://data.bnf.fr/date/1973/> ;
    rdagroup2elements:fieldOfActivityOfThePerson <http://dewey.info/class/800/>, "Littératures" ;
    rdagroup2elements:languageOfThePerson <http://id.loc.gov/vocabulary/iso639-2/eng> ;
    dc:date "1892-1973" ;
    bio:Birth "1892-01-03" ;
    bio:Death "1973-09-02" ;
    owl:sameAs <http://viaf.org/viaf/95218067> ;
    foaf:birthday "01-03" ;
    foaf:depiction <http://upload.wikimedia.org/wikipedia/commons/thumb/d/d9/Tolkien_1916-2.jpg/200px-Tolkien_1916-2.jpg> ;
    foaf:familyName "Tolkien" ;
    foaf:gender "male" ;
    foaf:givenName "John Ronald Reuel" ;
    foaf:name "John Ronald Reuel Tolkien" ;
    foaf:page <http://data.bnf.fr/ark:/12148/cb11926763j> .

Biblioteca Nacional de España

Looking at the BNE authority data what sticks out is the use of IFLA's FRBR and FRAD vocabularies. Obviously, BNE follows existing Linked Dta practices and doesn't emphasize the canonical strings as it types name authorities as persons. This becomes evident by the owl:sameAs links to GND, Viaf, Libris etc.

Some help for the people who don't know IFLA's FRBR and FRAD properties by heart:

  • ifla-frbr:C1005 = Person
  • ifla-frbr:P3039 = hasNameOfPerson
  • ifla-frad:P4031 = hasOtherVariantNamePerson
  • ifla-frbr:P3040 = hasDatesOfPerson

Here is a turtle snippet:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ifla-frbr: <http://iflastandards.info/ns/fr/frbr/frbrer/> .
@prefix ifla-frad: <http://iflastandards.info/ns/fr/frad/> .
@prefix locmads: <http://www.loc.gov/mads/rdf/v1#> .

    a ifla-frbr:C1005 ;
    ifla-frbr:P3039 "Tolkien, J. R. R." ;
    ifla-frad:P4031 "Tolkien", "Tolkien, John Ronald Reuel" ;
    ifla-frbr:P3040 "1892-1973" ;
    owl:sameAs <http://d-nb.info/gnd/118623222>, <http://dbpedia.org/resource/J._R._R._Tolkien>, <http://libris.kb.se/resource/auth/97224>, <http://viaf.org/viaf/95218067>, <http://www.idref.fr/027164918/id> .


As the overview shows, one currently can not find any other institution that follows an authority approach similar to the Library of Congress' that focuses on canonical strings. I guess, if Bibframe wants to be picked up by a broad mass of institutions internationally it will have to accomodate to the existing environment which would mean re-thinking Bibframe authorities by putting the primary focus on an approach that supports direct linking to persons as authorities. Today's mails on the Bibframe list by Kevin Ford of LoC (especially this one) give some hope that this may actually happen.

n Kevin Ford's and Ray Denenberg's first reply to Rob Sanderson's text on the Bibframe mailing list they write:

"BIBFRAME has explicitly stated that bf:Authority is not designed to compete with existing library authority efforts or replicate traditional library authorities. Furthermore, nowhere is it ever asserted that 'bf:Person != foaf:Person' and nowhere is it said that 'bf:Authority == madsrdf:Authority'. Nothing, either way, is actually declared presently. Rather, bf:Authority is an abstraction allowing the implementer to reference a traditional authority. It is these traditional authorities that include the strings in question.".

It is correct that there is no explicit and formal statement that a bf:Authority can not be a foaf:Person and must be a mads:Authority. But the use of a vocabulary is not only (and probably even not in the first place) guided by its RDFS/OWL representation. Examples and tools can have a lot more power directing the use of a vocabulary. The example Bibframe data from Deutsche Nationalbibliothek shown above makes clear that even early implementers (at least one) obviously did understand Bibframe authorities as string-centric (otherwise they'd put a direct link to the GND into the data).

Besides the DNB Bibframe test data, there exist other examples suggesting Bibframe is primarily dealing with string authorities:

  • Definitions and names currently have a lot of "controlled name" in them, e.g. http://bibframe.org/vocab/Person.html.
  • Examples in the Bibframe vocabulary documentation, e.g. at [http://bibframe.org/vocab/creator.html])(http://bibframe.org/vocab/creator.html).
  • Output of the Bibframe Editor, here is some example output I get when I chose a LoC person authority to link to (converted to turtle):

    @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
        <http://bibframe.org/vocab/language> <http://id.loc.gov/vocabulary/languages/eng> ;
        <http://bibframe.org/vocab/title> "Ways of Worldmaking" ;
        <http://id.loc.gov/vocabulary/relators/aut> <http://example.org/6636d72e-9933-649a-b769-2ef41d241937> ;
        a <http://bibframe.org/vocab/Work> .
        <http://bibframe.org/vocab/authoritySource> <http://id.loc.gov/authorities/names> ;
        <http://bibframe.org/vocab/authorizedAccessPoint> "Goodman, Nelson"@en ;
        <http://bibframe.org/vocab/hasAuthority> <http://id.loc.gov/authorities/names/n50037322> ;
        a <http://bibframe.org/vocab/Person> .

If Bibframe wants to make clear that it in fact does NOT require people to use blank nodes with string authorities and that it supports and may even prefer direct interlinking of works and associated agents then it should behave like that and replace the current definitions, examples and output of the Bibframe editor. It would be even better if the Library of Congress changed its approach of modeling its own authorities and added URIs for the real-world objects (persons, corporate bodies etc.) to their authority data so that one could directly link to them.


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äre.

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?


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.)
Im folgenden werde ich auf einige dieser Aufgaben etwas näher eingehen.
Update, Nov. 2014: Die Mindmap ist leider nicht mehr vorhanden, weil anonyme Maps auf Mindmup nur 6 Monate gespeichert werden, was mir bei Publikation leider nicht mitgeteilt wurde. Ich habe leider keine lokale Kopie der letzten Version. :-/


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.


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]


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.

[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. :-)


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...




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.


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:


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.


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:
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/>

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

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 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.