2012-05-23

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.

2012-04-12

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.

2012-03-21

Beitrag zur Zukunft der BibCamps

Das Bib meets KnowledgeCamp 2012 ist vorbei und es war ein großer Erfolg. Ich freue mich sehr darüber und möchte allen an der Organisation Beteiligten meinen Dank ausdrücken: allen voran den FH-Studierenden, die einen Großteil der Planung, Organisation übernommen haben und eine optimale Infrastruktur für ein erfolgreiches BibCamp bereitgestellt und am Laufen gehalten haben. Ihren Dozenten Ursula Georgy und Tom Becker, die das Management übernommen haben. Den Mitorganisatoren Constanze Döring (Stadtbibliothek Köln), Elke Rösner und Ulrike Ostrzinski (ZB MED), Susanne Hilbring (Max-Planck-Institut für Gesellschaftsforschung, MPIfG) und natürlich Karlheinz Pape von der Gesellschaft für Wissensmanagement (gfwm).
Ich selbst war auch an der Organisation beteiligt und ich denke, wir alle können stolz auf das Ergebnis sein. Im Sinne einer gesunden Weiterentwicklung des BibCamps möchte ich im Weiteren auf einen Punkt eingehen, der zu einiger Diskussion während der Planungen geführt hat.

Man war nicht immer einig bei der Planung...

Sicher können sich alle Organisatoren darauf einigen, dass das #bkc12 ein großer Erfolg war. Bei der Planung des BibCamps fiel uns eine Einigung allerdings auch manchmal schwer, insbesondere als es um Sponsoren und ihre Außendarstellung im Rahmen des BibCamps ging. Da dieses Thema - soweit ich es mitbekommen habe - auch bei vorherigen BibCamps zu Diskussionen geführt hat, es aber nie öffentlich diskutiert wurde, möchte ich zu einer solchen Diskussion mit diesem Beitrag einladen. Auch denke ich, dass dieser Beitrag zukünftigen BibCamp-Organisatoren zur Vermeidung einiger Diskussionen nützlich sein kann.

Was das BibCamp ausmacht

Was gehört zu diesem "Geist des BibCamp"? Ich würde folgende Punkte zu den grundlegenden Dingen zählen:
  1. Die Teilnehmer/innen
  2. Räumlichkeiten
  3. Verpflegung
  4. WLAN
Dies sind sozusagen die notwendigen Bedingungen für ein erfolgreiches BibCamp. Sobald diese vier Dinge gegeben sind, ist der Erfolg eines BibCamps gesichert. Darüber sollten sich zukünftige Organisatoren im Klaren sein und nicht denken, sie müssten die von vorherigen BibCamps gesetzte Messlatte immer wieder erreichen oder gar überbieten. Nein, das müsst ihr nicht, sorgt erstmal dafür, dass die Fundamente stehen ehe ihr über Anbauten nachdenkt.

Sponsoren und Institutionen stehen im Hintergrund

Eine weitere Eigenschaft des BibCamps war es bisher, dass Organisationen - seien es Sponsoren oder veranstaltende Einrichtungen - immer im Hintergrund standen. Sie wurden auf dem Blog genannt und auch vielleicht bei der Begrüßung kurz erwähnt. Manche Sponsoren haben VertreterInnen zum BibCamp gesandt. In Hamburg wurden sogar die Räume nach den Sponsoren benannt. Logos, Banner, Stände oder eine anderweitige Präsenz von Organisatoren wie Sponsoren auf dem BibCamp selbst gab es aber nicht. Das war den Organisatoren bisher wichtig und es ist auch mir wichtig. Den Sponsoren ist dies auch klar und freundlicherweise finden sich immer wieder welche, die das BibCamp unterstützen. Danke.

Diese Unaufdringlichkeit der Sponsoren und kommerziellen Anbieter ist einer der Aspekte, in denen das BibCamp sich erfrischend von etablierten Veranstaltungen wie dem Bibliothekstag abhebt. Den Hauptorganisatoren von der FH Köln war dies bei der Planung des #bkc12 verständlicherweise nicht klar, hatten sie doch allesamt noch kein BibCamp besucht. Constanze, Elke und ich war es aber wichtig, den "Geist des BibCamps" zu bewahren, Logos, und Marken im Hintergrund zu halten und keine Banner oder werbenden Informationsstände auf einem BibCamp einzuführen.

Stand != Stand

Über Stände wurde unter den Organisatoren des #bkc12 besonders ausgiebig diskutiert. Hintergrund war, dass dem BIB in der anfänglichen Planungsphase untersagt wurde, einen Informationsstand im Rahmen des BibCamps aufzustellen, obwohl er einen solchen als eine Bedingung für eine 500-Euro-Spende nannte. In dieser Frage hatten sich insbesondere Constanze Döring, Elke Rösner und ich durchgesetzt, denn uns hatte gerade dieser Aspekt auf vorhergehenden BibCamps immer sehr gefallen. Informationsstände kann man sich ja schließlich auf allen anderen bibliothekarischen Konferenzen anschauen. Auf der anderen Seite waren wir aber auch kompromissbereit und es wurden zwei Stände erlaubt (die Cocktailbar der Firma Lenk und die Itinerant Poetry Library), weil sie eben keinen werbenden Charakter haben, sondern einen anderen Sinn verfolgten: Erfrischung respektive Unterhaltung/Wissensvermittlung. Ich denke, wir haben hier die richtige Wahl getroffen und werde mich auch weiterhin prinzipiell gegen werbende Informationsstände auf BibCamps aussprechen, seien diese von kommerziellen oder nicht-kommerziellen Organisationen.

Nicht nachvollziehen konnte ich die Reaktion des BIB, der sich ob der Absage des Standes not amused zeigte. Er ließ über Tom Becker als seinen Vertreter unter den BibCamp-Organisatoren verlauten, dass er in Zukunft seine finanzielle Unterstützung für BibCamps einstellen werde, weil er als "kommerzieller anbieter" hingestellt worden sei. Eine solche Typisierung des BIB als kommerzielle Entität lag allerdings allen Beteiligten fern, es haben sich lediglich einige gegen einen Infostand des BIB ausgesprochen. Meines Erachtens keine souveräne Reaktion des Berufsverbands.

Was meint ihr?

Mich würde interessieren, wie andere BibCamp-Teilnehmer/innen die Frage nach Ständen und generell der Sponsorenpräsenz auf dem BibCamp sehen. Hat euch die Zurückhaltung der Sponsoren bisher auch so sehr gefallen oder stündet ihr einer "Bibliothekstagisierung" (die ja auf anderen Ebenen ohnehin stattfindet, weil das BibCamp eben im Mainstream angekommen ist) des BibCamps, d.h. einer Zunahme von Werbeständen, Bannern etc. gleichgültig bis positiv gegenüber?

2011-11-08

Weshalb Computer (nicht) verstehen

Die Künstliche-Intelligenz-Forschung ist seit langem - in neuerer Zeit in Form des Semantic Web - einiger Kritik ausgesetzt, wie sie etwa auch jüngst Jakob Voß im Blogbeitrag "Die Grenzen des Semantic Web" artikuliert. So wie die K.I.-Forschung verspricht, Maschinen zu erschaffen, die einem Menschen ähnlich Probleme lösen, nährt das Semantic Web die Hoffnung, dass es unabhängig von und im Dienste des Menschen, Schlüsse ziehen und Verantwortung übernehmen kann - etwa für eher triviale Dinge wie Terminplanung, Reise- und Hotelbuchungen aber auch für darüber hinausgehende Aufgaben.

Ich schließe mich jener Kritik an, dass die ganze Idee der künstlichen Intelligenz ein Traum ist, der nie Wirklichkeit werden wird. Ich halte den Ausdruck "Semantisches Web" und strenggenommen auch "Künstliche Intelligenz" für in sich widersprüchlich und werde einige Gründe dafür weiter unten erläutern.

Welche Aufgaben für Computer?

Sicherlich gibt es eine Menge Aufgaben, die elektronische Maschinen sehr gut erledigen können und dabei auch "intelligent" in einem weiten Sinne erscheinen mögen. Allerdings ist es wichtig, diese Aufgaben von jenen zu unterscheiden, derer sich die Menschen schon selbst widmen müssen. Nach welcher Regel sollen aber Aufgaben für Maschinen von jenen für Menschen unterschieden werden? Dies halte ich für die eigentlich relevante Frage. Zunächst versuche ich aber einige Gründe dafür zu nennen, wie das Missverständnis zustande kommt, dass Maschinen prinzipiell auch "denken" oder "verstehen" könnten.

Modellierung menschlicher Kommunikation und Kognition nach dem Vorbild des Technischen

Der Grund des Problems ist offensichtlich die Neigung, den Menschen zu verstehen, indem er die Funktion seiner eigenen maschinellen Hervorbringungen analysiert und die Ergebnisse dann auf sich selbst überträgt. Mit anderen Worten: Theorien und Modelle technischer Kommunikation und des Computers werden auf den Menschen, seine Kognition und seine Kommunikation übertragen und sodann der Mensch als eine Maschine unter anderen verstanden. Werden Mensch und Maschine als gleichartig konzipiert, ist es nur konsequent, im Umkehrschluss an die menschlichen Fähigkeiten der Maschine zu glauben.

Kognitionstheorien und Computermodelle

Ein bekanntes Beispiel ist die Konzeption menschlicher Kognition nach dem Modell eines Computers. Nicht zufällig fiel die Entwicklung der Künstlichen-Intelligenz-Forschung zusammen mit der "kognitiven Wende" in der Psychologie, die den Wechsel vom Behaviourismus zu einem Verständnis menschlicher Kognition markiert, das auf der Computer-Metapher basiert. Den Menschen als Maschine verstehend glaubte man, ihn durch die Entwicklung intelligenter Maschinen, deren Bauplan man kennt, verstehen zu können:
"A key idea in cognitive psychology was that by studying and developing successful functions in artificial intelligence and computer science, it becomes possible to make testable inferences about human mental processes. This has been called the reverse-engineering approach." (Quelle: Wikipedia)
Wenn der Mensch selbst als eine intelligente Maschine betrachtet wird, können Maschinen folglich auch intelligent sein. Mittlerweile hat sich zwar herausgestellt, dass menschliche Kognition weitaus komplexer funktioniert als Informationsverarbeitung in einem Computer, so dass man sich von dieser Sichtweise wieder abgewandt hat. Sie hat aber in den Medien sowie in der Alltagssprache ("Kurzzeit-", "Langzeitgedächtnis", Gedächtnis als "Speicher" etc.) ihre Spuren hinterlassen und kann weiterhin dazu verführen, Computer als dem Menschen prinzipiell gleichwertige Informationsverarbeitungssysteme zu verstehen.

Technische = sprachliche Kommunikation?

Abgesehen vom über lange Jahre vorherrschenden auf der Computer-Metapher basierenden Kognitionsmodell sehe ich als weiteren Hauptgrund für den Irrglauben an die "Macht des Computers"[1], dass häufig ein prominentes Modell technischer Kommunikation auch auf natürliche Kommunikation angewendet wird und diese grundlegend verschiedenen Formen von "Kommunikation" gleichgesetzt werden.

Das Shannon/Weaver-Modell technischer Kommunikation ist allseits bekannt und lässt sich wie folgt zusammenfassen: Es gibt einen Sender, einen Empfänger, eine Nachricht, einen Übertragungskanal und einen Code. Verfügen Sender und Empfänger über denselben Code, wird die Nachricht jeweils korrekt en- und dekodiert und wird der Übertragungskanal nicht gestört, dann ist die empfangene Nachricht mit der gesendeten Nachricht identisch.

Dieses Modell deckt eigentlich explizit nur technische Kommunikation ab, so heißt es in Shannons berühmten Aufsatz "A Mathematical Theory of Communication" von 1948:
"Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem."
Shannon geht es eben um das "engineering problem", so dass Konzepte wie "Bedeutung", "Semantik", "Verstehen" schlicht irrelevant in diesem Modell sind. Mit anderen Worten: Das Modell befasst sich allein mit Kommunikation auf der syntaktischen Ebene und abstrahiert von der semantischen Ebene. Leider wurde das Modell nur allzu oft missverstanden und auf natürliche Sprache angewendet, ohne die konstitutiven Unterschiede zwischen diesen "Sprachen" zu beachten. Und sobald menschliche Kommunikation analog zum Modell technischer Kommunikation verstanden wird, wird auch leichtfertig davon ausgegangen, dass Maschinen menschliche Kommunikation vollständig imitieren können.

Christian Stetter stellt den Unterschied zwischen technischer und sprachlicher Kommunikation in [2] klar heraus:
"[W]enn von „technischer Kommunikation“ gesprochen wird, so ist von Kommunikation hier nur in übertragenem Sinn die Rede. Sender und Empfänger sind technische Apparate, philosophisch gesprochen Dinge. Dinge haben jedoch nicht die Fähigkeit, miteinander zu kommunizieren, sie funktionieren gemäß den Gesetzen, denen sie unterliegen. Weder versteht der Sender im mindesten, was er dem Empfänger übermittelt, noch dieser im mindesten, was jener ihm mitteilt."
Technische Kommunikation findet allein auf der syntaktischen Ebene statt, sie basiert auf Diskretheit, auf der Digitalität schriftlicher Symbole, des Alphabets, der Zahlen, letztlich von 0 und 1. Semantik findet sich in der inter-maschinellen Kommunikation nicht und kommt erst auf der Ebene zwischenmenschlicher Kommunikation ins Spiel. Und die Semantik natürlicher Sprachen ist eine nicht-diskrete, so dass es unmöglich ist, sie mit einer Maschine zu repräsentieren. Deshalb ergibt es keinen Sinn, von einem "Semantischen Netz" zu sprechen, das aus Maschinen besteht.[3] Denn erst mit der Aufnahme und Interpretation der Daten (oder einer auf ihrer Basis generierten visuellen oder andersartigen Repräsentation - etwa in Form eines Diagramms) durch einen Menschen bewegen wir uns auf der semantischen Ebene.

Aufgaben für Computer: formale Verfahren

Maschinen operieren also auf der syntaktischen Ebene über digitale Symbole, die im Laufe einer bedeutsamen menschlichen Praxis produziert und gespeichert wurden. Kontext und Bedeutung der Symbole existieren für eine Maschine nicht, sie funktioniert einfach.

Es gibt formalisierte Verfahren - frei von Kontext und Bedeutung - wie das deduktive Schließen und andere logische Operationen oder arithmetische und algebraische Kalküle, die von Menschen mit Stift und Papier entwickelt worden sind bevor Computer existierten.  Menschen waren es dementsprechend auch, die diese Handlungen - gewissermaßen als symbolische Maschinen - ausführten.  Die symbolische Tätigkeit des Menschen ist mit diesen formalen Operationen allerdings nicht erschöpft, ganz im Gegenteil handelt es sich um gattungsgeschichtlich recht späte Entwicklungen, weil sie an die Verwendung schriftlicher Symbole gekoppelt sind.

Es sind aber diese formalisierten Verfahren - als eine Untermenge der kognitiv bedeutsamen symbolischen Handlungen des Menschen - bei denen uns Computer an Geschwindigkeit und Rechenkraft übertreffen. Dementsprechend decken sich diese Verfahren mit dem Aufgabenbereich von Computern - nicht weniger aber eben auch nicht mehr.[4]



[1] Die deutsche Übersetzung des englischen Titels "Computer Power and Human Reason" ist übrigens völlig daneben und steht im Widerspruch zum Inhalt des Buchs (das zum Glück besser übersetzt ist als sein Titel).

[2] http://www.semantics.de/service/publikationen/kommunikationsmanagement/kommunikationsmanagement.pdf, S. 2f.

[3] Das deckt sich auch mit meiner Argumentation in der Daten-Diskussion mit Jakob, dass Daten - die ja der Stoff sind, mit dem Computer arbeiten - allein auf der syntaktischen Ebene anzusiedeln sind.

[4] Mit dieser Einsicht ist denkbar wenig erreicht. Die weitaus schwierigere Aufgabe ist es, die natürlichsprachige Kommunikation unter diesen Vorbedingungen zu verstehen.

2011-10-24

My Problems with FRBR I: Naming

The so called Functional Requirements of Bibliographic Records (FRBR) are a vital source of discussions in the library world since the 1990s. I mostly tried to don't get too deep into these discussions but haven't evaded them altogether. As FRBR discussions probably won't go away any time soon I will scribble down the basic two or three problems I have with FRBR, starting today with the label it was given: "Functional Requirements for Bibliographic Records".[1]

Functional Requirements? Really?

What I don't get is why FRBR actually goes by the name "Functional Requirements for Bibliographic Records"? (I don't understand much about functional requirements in software engineering or about requirements engineering. Maybe that's my problem...) Shouldn't it be called something like CMBU ("Conceptual Model of the Bibliographic Universe"). When I hear "functional requirements" in the context of bibliographic data, I think of the functionalities a bibliographic database should offer its users.[2] Unfortunately, FRBR is only indirectly talking about functional requirements in this sense as FRBR is focused on creating a data model. One just has to take a look at the FRBR paper by IFLA, Barbara Tillett's text "What is FRBR?" or the "FRBR" wikipedia entry. All of them describe FRBR as a "conceptual model"or "entity-relationship model".

And that is where I see a problem. I am highly in favour of creating functional requirements for bibliographic data covering different use cases. It really is important to do this if you want to develop a good conceptual model for bibliographic data. But one shouldn't confuse "functional requirements" with "conceptual model" as one data model can serve functional requirements from different users, use cases and contexts and as a data model can be created to only satisfy a small number of functional requirements.

Do we need new terminology to describe functional requirements?

Why develop a new language to talk about bibliographic resources if you can describe functional requirements in everday language that is used to talk about bibliographic resources? Users don't want to "select an expression of a work" nobody will tell you that he needs this function. They want to "find a French translation of Moby Dick", an "annotated version of Shakespeare's Julius Caesar", "get an overview over the œuvre of John Dewey" etc. So why doesn't FRBR use common language to show what these functions are users want? Instead, with FRBR, a data model is designed and a new language to talk about bibliographic resources and this language is then - in a circular move - used to formulate requirements for bibliographic data like
  • Find all manifestations embodying the works for which a given person or corporate body is responsible
  • Identify an expression of a work
  • Obtain a manifestation
Have you ever heard a user asking to "obtain a manifestation or expression of a work"? I believe not.

Requirements are always attached to use cases

Functional requirements, for what purpose anyway? - For tasks with which the libraries' users see themselves confronted. But there are so many other purposes one can use bibliographic data for, e.g. building public domain calculators or creating bibliographies and reference lists for research or lectures. And you definitely curtail your opportunities to re-use data for other purposes by adopting a model based on functional requirements that are quite narrowly tailored in the light of specific usage. For example, identifying a work in a FRBR sense doesn't help in a legal context where e.g. a translation is a work in its own right.

Am I just ignorant? Does FRBR actually provide what its name says? I would like to be disabused in my  opinion. So please, requirement engineers and bibliographs, explain it to me.


[1] I don't believe these points are very novel but I only could follow some FRBR discussions during the last three years. And they might be wrong. I am happy about any feedback.

[2] Actually, I also think the second part of the lable isn't appropriate as well. It doesn't make much sense to speak of Functional Requirements for Bibliographic Records but for bibliographic databases. It is a database as a whole that has to fulfil specific function in the first place and not individual records.

2011-09-13

Darum Linked Open Data


Eigentlich hatte ich diesen Artikel als meine morgige Stimme für plan3et.info geplant. Da Jakob Voß dort aber am Montag schon das Thema Linked Open Data angesprochen hatte, habe ich mir für plan3t.info etwas anderes überlegt. So komme ich endlich mal wieder dazu Übertext: Blog zu füttern, der von mir die letzten Monate vollständig vernachlässigt wurde. Mit dem Verfassen meiner Masterarbeit, die ich beenden wollte, bevor der Nachwuchs "Hello World!" sagt, hatte ich  aber auch die letzten Monate genug zu tun. Zudem schreibe ich desöfteren  Beiträge  für openbiblio.net, den Blog der OKFN Working Group on Open Bibliographic Data. Hoffentlich werde ich hier in Zukunft  wieder regelmäßiger etwas veröffentlichen.

Linked Open Data (LOD) in Bibliotheken und verwandten Organisationen erfährt eine breite Aufnahme. Immer mehr Organisationen arbeiten an LOD-Projekten, das W3C wird bald die endgültige Fassung eines Berichts zur Lage von Linked Library Data veröffentlichen und anscheinend wird nun auch die Französische Nationalbibliothek ihre Linked Data unter einer offenen Lizenz veröffentlichen.

Doch warum das Ganze? Anhand von fünf Publikationen aus den letzten Tagen möchte ich Motivationen und Hintergründe verschiedener Akteure aufzeigen.

Der Bericht der W3C Incubator Group on Linked Library Data


Der Bericht befasst sich in erster Linie mit den Vorteilen der technischen Seite von Linked Open Data und lässt den Aspekt der offenen Lizenzierung außen vor. Als Vorteile des Linked-Data-Ansatzes werden allgemein die dadurch ermöglichten Chancen zum TeilenErweitern und Nachnutzen der Daten genannt. Konkrete Vorteile sind:
  • Multilinguale Funktionalitäten wie multilinguale Bezeichnung von Klassifikationsstellen, Metadatenelementen etc.
  • Kollaborative Beschreibung von Ressourcen und einfache Nachnutzung von Informationen aus anderen Quellen
  • Einfache Zitierbarkeit von Beschreibungen
  • Flexiblerer Datenaustausch. Nicht gesamte Katalogeinträge müssen ausgetauscht werden, sondern - je nach Anwendung und Bedarf - auch nur einzelne Beschreibungsaspekte.
Neben dem Aufzeigen von Vorteilen eines LOD-Ansatzes nennt der Bericht auch wichtige Probleme, die mit der traditionellen Datenhaltung, ihrem Austausch und ihrer Publikation verbunden sind:
  • Bibliotheksdaten sind nicht im Web integriert und somit nicht durch die Webcrawler von Suchmaschinen auffindbar. Die Daten sind vielmehr Teil des Deep Webs.
  • Die Standards für bibliothekarische Daten werden nur in der Bibliothekswelt benutzt. Dies erschwert deren Nachnutzung durch andere Akteure oder die Kombination mit Daten aus anderen Quellen.
  • Bibliotheksdaten gleichen eher natürlichen als maschinenlesbaren Texten. Sie sind nur schwach strukturiert und nicht für maschinelle Verarbeitung optimiert.
  • Technologische Veränderungen in der Bibliothekswelt hängen von kommerzielen Softwareanbietern ab.
Wer mehr lesen möchte, gehe zu http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion.

Linked Open Data an der NTNU


Die Bibliothek der NTNU (Norwegische Universität für Wissenschaft und Technologie) in Trondheim publiziert seit 2009 Linked Open Data.  Rurik Greenall hat in einem Beitrag für den Blog der OKFN Working Group on Open Bibliographic Data, die Geschichte und Hintergründe beschrieben. Ich versuche hier den Teil zu übersetzen, in dem er die Vorteile von Linked Open Data aus der Anwenderperspektive nennt:
"Linked Open Data bringt Mittel zur Repräsentation und zur Anreicherung [von Daten, A.P.] zusammen, die mit anderen Technologien nicht möglich sind. Während die Lernkurve für uns nicht leicht war, wurden wir in vielerlei Hinsicht belohnt. Die Nutzung von Open Data hat uns die Möglichkeit verschafft, Systeme zu erschaffen, von denen unsere Nutzer/innen inspiriert werden können. Systeme, die Nutzerfragen beantworten und ihnen dabei helfen, mehr zu finden, als sie ursprünglich gesucht haben. Das geht hinaus über das Konzept monolithischer Systeme, bei denen unser Ziel war, Nutzer/innen in die Systeme zu bekommen; vielmehr dreht sich alles darum, die Daten herauszubekommen und sicherzustellen, dass sie verfügbar sind ohne Referenz zu einer bestehenden Webseite. Offenheit ist der Schlüssel und diese Denkweise hat unsere Arbeit enorm verbessert."
Wenn wir also möglichst vielen interessierten Menschen Zugriff auf unsere elektronischen und Print-Angebote anbieten wollen, dann sollten wir nicht versuchen, sie in monolithische Systeme zu locken, um von diesen Angeboten Kenntnis zu nehmen. Wir sollten stattdessen die Informationen zu unseren Angeboten möglichst breit verteilen, damit Nutzerinnen die Informationen in ihrer gewohnten Umgebung (z.B. Google) finden können. Passenderweise hat mir Rurik einmal gesagt, dass er keinen Sinn darin sieht, Discovery-Systeme wie Primo o.ä. zu lizenzieren; das Discovery-System seiner Bibliothek sei Google.

Ruriks Artikel schließt folgendermaßen:
"Es ist offensichtlich für uns, dass die Nutzung von Linked Open Data nicht nur den nötigen Zugang zu unseren Daten herstellt, sondern auch ein Weg ist, um sie mit den Daten anderer anzureichern. Es ist auch klar, dass in einem Zeitalter, wo "vernetzt" die Norm ist, jeder andere Ansatz nicht nur den Erfolg beschränkt, sondern ihn wahrscheinlich sogar ausschließt."
Bietet LOD wirklich völlig neue Möglichkeiten?


Als kleines Korrektiv zu den 'neuen Möglichkeiten', die Linked Open Data erst eröffnen würde, verweise ich noch auf diesen Blogpost von Lee Feigenbaum. Er antwortet darin auf die oft gestellte Frage Was kann ich mit Semantic-Web-Technologien machen, das ich nicht mit anderen Technologien machen kann? - "Nicht viel." Allerdings stellt er klar, dass die Frage falsch gestellt ist und lauten müsste: Was kann ich mit Semantic-Web-technologien machen, das ich sonst nicht machen würde?
Da Linked Data zwar keine revolutionäre Technik ist aber einen evolutionären Vorteil mit sich bringe, weil es Projekte möglich mache, die mit anderen Technologien - aufgrund des damit verbundenen Aufwands - nicht durchgeführt würden. Linked Data bedeute für viele Projekte: vom No-Go zum Go.
In einem weiteren Blogpost stellt er als vorteilhafte Eigenschaften von LOD heraus, dass es sich um ein  "common, coherent set of standards" handelt.

hbz: Motivation und erwartete Vorteile


Silke Schomburg hat vorgestern in einem Vortrag (Folien) beim internationalen Ex-Libris-Anwendertreffen unter anderem die Motivationen des hbz für Linked Open Data genannt. Folie 4 fasst einige bereits genannte Argumente knapp zusammen:
"Nutzung internationaler, domänenübergreifender Standards führt zu:
  • Erhöhter Auffindbarkeit
  • Möglicher Mehrfachnutzung eines Datenbestands
  • Maximierter Interoperabilität und Nachnutzbarkeit
  • Flexiblem Datenmodell"
Dies erinnert an die Aufzählung der W3C-LLD-Gruppe. Daraus folgend werden als möglicher Return of Investment genannt (Folie 5), dass die Nutzung eines standardisierten Technologie-Stacks mittel- bis langfristig dazu führt dieselben Dienste mit weniger Ressourcen sowie neue und verbesserte Services anbieten zu können.

Offene Strukturierte bibliographische Daten: Machen wir es nicht, machen es andere...


Nicht nur scheint LOD also aus rationalen und Effizienzgründen die bessere Wahl zum Aufbau zukünftiger Informationsinfrastrukturen zu sein. Auch könnte es der Bibliothekswelt dabei helfen, relevant zu bleiben und nicht durch andere Organisationen verdrängt zu werden.

Jakob Voß hat am Wochenende darauf hingewiesen, dass Wikimedia überlegt, ein Projekt "Bibliographisch-archivalische Datenbank" anzugehen, in dem eine offene bibliographisch-archivalische Datenbank angelegt werden soll zur Nachnutzung durch die verschiedenen Wikimedia-Projekte aber auch durch andere Akteure wie Wissenschaftler oder Google Books.

Wenn bibliothekarische Organisationen nicht eine wichtige Rolle dabei übernehmen, bibliographische Daten im großen Stil offen, strukturiert und leicht nachnutzbar zur Verfügung stellen, werden es schließlich andere tun...

2011-02-03

Prinzipien zu offenen bibliographischen Daten jetzt auch auf Deutsch

Wie bereits angedeutet gibt es nun eine offizielle deutsche Übersetzung der Principles on Open Bibliographic Data. Die englische Originalfassung wurde bereits Mitte Januar 2011 von der Working Group on Open Bibliographic Data der Open Knowledge Foundation veröffentlicht.

Mein Dank geht an Doreen Thiede und Felix Ostrowski für Korrekturen und Verbesserungsvorschläge.

Unterzeichnen!

Die Prinzipien können unter dieser URL unterzeichnet werden: http://openbiblio.net/principles/endorse/. Ich fordere alle dazu auf, von dieser Möglichkeit Gebrauch zu machen und natürlich können auch Institutionen diese Prinzipien unterzeichnen.

Gerade im Kontext einer langfristigen Umstrukturierung der wissenschaftlichen Informationsinfrastruktur und der Reformierung der bibliothekarischen Verbundsysteme in Deutschland aber auch im Hinblick auf Projekte wie Europeana oder die Deutsche Digitale Bibliothek (DDB) liegen die Vorteile offener bibliographischer Daten auf der Hand: Mit einer breiten Praxis der Publikation bibliographischer Daten unter Nutzung offener Lizenzen wird eine große Zahl rechtlicher Entwicklungsverzögerer hinfällig. Solche rechtlichen Stolpersteine können etwa sein langwierige Vertragsverhandlungen von Infrastrukturprojekten wie Europeana und der DDB mit den verschiedenen Metadatenlieferanten oder Einigungen über die Nutzung großer Mengen bibliographischer Daten in Forschungskontexten usw. Bereits das vascoda-Rechercheportal hat nicht wenig darunter gelitten, dass es keinen unkomplizierten Zugriff auf die Gesamtheit der zu aggregierenden Metadaten gab (siehe dazu meinen Kommentar hier).

Mit Open Data können sich die Bemühungen aller Beteiligten auf die eigentliche Aufgabe konzentrieren: die Schaffung besserer technischer Infrastrukturen für Wissenschaft und Kultur. Deshalb fordere ich auf, ein Zeichen zu setzen für Open Data durch das Unterzeichnen der Prinzipien! (Es ist übrigens ein Jammer, dass - soweit ich dies nach kursorischer Lektüre beurteilen kann - die offene Lizensierung von Wissen in den kürzlich veröffentlichten Papieren des Wissenschaftsrats keine Berücksichtigung findet, wo doch diese rechtlichen Aspekte eine fundamentale Rolle bei der Entwicklung einer zukünftigen Informationsinfrastruktur spielen. Dazu bei Gelegenheit hier sicher mehr...)

Es folgt der Wortlaut der Prinzipien zu offenen bibliographischen Daten:


Prinzipien zu offenen bibliographischen Daten



Einleitung


Produzenten bibliographischer Daten wie Bibliotheken, Verlage, Universitäten, Wissenschaftler oder soziale, webbasierte Literaturverwaltungsplattformen spielen eine wichtige Rolle bei der Entwicklung menschlichen Wissens. Damit ihre Arbeit der Gesellschaft in vollem Umfang zugutekommt, ist es zwingend erforderlich, bibliographische Daten zu öffnen, das heißt für alle zur beliebigen Nutzung frei verfügbar zu machen.

Bibliographische Daten

Um den Geltungsbereich der Prinzipien festzulegen, wird in diesem ersten Teil der zugrundeliegende Begriff bibliographischer Daten erläutert.

Kerndaten

Bibliographische Daten bestehen aus bibliographischen Beschreibungen. Eine bibliographische Beschreibung beschreibt eine bibliographische Ressource (Artikel, Monographie etc. – ob gedruckt oder elektronisch) zum Zwecke
  1. der Identifikation der beschriebenen Ressource, d.h. des Zeigens auf eine bestimmte Ressource in der Gesamtheit aller bibliographischer Ressourcen und
  2. der Lokalisierung der beschriebenen Ressource, d.h. eines Hinweises, wo die beschriebene Ressource aufzufinden ist.
Traditionellerweise erfüllte eine Beschreibung beide Zwecke gleichzeitig, indem sie Information lieferte über: Autor(en) und Herausgeber, Titel, Verlag, Veröffentlichungsdatum und -ort, Identifizierung des übergeordneten Werks (z.B. einer Zeitschrift), Seitenangaben.
Im Web findet Identifikation statt mittels Uniform Resource Identifiers (URIs) wie z.B. URNs oder DOIs. Lokalisierung wird ermöglicht durch HTTP-URIs, die auch als Uniform Resource Locators (URLs) bezeichnet werden. Alle URIs für bibliographische Ressourcen fallen folglich unter den engen Begriff bibliographischer Daten.

Sekundäre Daten

Eine bibliographische Beschreibung kann andere Informationen enthalten, die unter den Begriff bibliographischer Daten fallen, beispielsweise Nicht-Web-Identifikatoren (ISBN, LCCN, OCLC etc.), Angaben zum Urheberrechtsstatus, administrative Daten und mehr; diese Daten können von Bibliotheken, Verlagen, Wissenschaftlern, Online-Communities für Buchliebhaber, sozialen Literaturverwaltungssystemen und Anderen produziert sein.
Darüber hinaus produzieren Bibliotheken und verwandte Institutionen kontrollierte Vokabulare zum Zwecke der bibliographischen Beschreibung wie z. B. Personen- und Schlagwortnormdateien, Klassifikationen etc., die ebenfalls unter den Begriff bibliographischer Daten fallen.

Vier Prinzipien

Wir empfehlen ausdrücklich die Übernahme und Umsetzung der folgenden Prinzipien:
  1. Wenn bibliographische Daten oder Sammlungen bibliographischer Daten veröffentlicht werden, sind die Wünsche und Erwartungen des Herausgebers im Hinblick auf Fragen der Nachnutzung und Wiederverwendung einzelner bibliographischer Beschreibungen, der gesamten Sammlung sowie Teilmengen der Sammlung klar und explizit anzugeben. Diese Angabe sollte präzise und unwiderruflich sein sowie auf einer angemessenen und anerkannten rechtlichen Erklärung in der Form eines „Waivers“ (Verzichtserklärung) oder einer Lizenz basieren.
    Die Veröffentlichung bibliographischer Daten erfolge mit einer expliziten und tragfähigen rechtlichen Erklärung.
  2. Viele weithin anerkannte Lizenzen sind weder bestimmt noch geeignet für bibliographische Daten oder Sammlungen bibliographischer Daten. Eine Auswahl von „Waivern“ und Lizenzen, die für die Anwendung auf Daten konzipiert und geeignet sind, ist beschrieben unter http://opendefinition.org/licenses/#Data. Creative-Commons-Lizenzen (mit Ausnahme der CC0), GFDL, GPL, BSD etc. sind NICHT geeignet für Daten und von ihrer Nutzung wird DRINGEND abgeraten.
    Benutze eine für Daten geeignete anerkannte Lizenz oder einen Waiver.
  3. Von der Benutzung von Lizenzen, die eine kommerzielle Nachnutzung verhindern oder eine Produktion derivativer Werke beschränken, indem die Nutzung für bestimmte Zwecke oder durch bestimmte Personen oder Organisationen ausgeschlossen wird, wird DRINGEND abgeraten. Solche Lizenzen machen es unmöglich, Datenbestände effektiv zu integrieren und nachzunutzen. Außerdem verhindern sie die Entstehung kommerzieller Dienste, die eine Aufwertung der Daten leisten sowie kommerzieller Aktivitäten, die zur Erhaltung der Datenmengen beitragen können.
    Um eine effektive Nutzung und Verbesserung der Daten durch andere zu erreichen, sollten die Daten offen im Sinne der Open Definition (http://opendefinition.org/) sein – insbesondere der Ausschluss kommerzieller Nutzung sowie andere einschränkende Klauseln sollten unterlassen werden.
  4. Darüber hinaus empfehlen wir – insbesondere öffentlich finanzierte – bibliographische Daten und Sammlungen bibliographischer Daten explizit in die Public Domain zu geben durch die Nutzung der Public Domain Dedication and Licence oder des Creative Commons Zero Waivers. Dadurch werden die Nachnutzungsmöglichkeiten maximiert, ganz im Sinne des allgemeinen Ethos des Teilens im Bereich öffentlich geförderter Gedächtnisinstitutionen.
    Wo möglich, empfehlen wir, bibliographische Daten mittels PDDL oder CC0 explizit in die Public Domain zu geben.
Beitragende: Karen Coyle, Mark MacGillivray, Peter Murray-Rust, Ben O’ Steen, Jim Pitman, Adrian Pohl, Rufus Pollock, William Waites

Addendum

Eine unvollständige Liste bibliographischer Daten.
Kerndaten: Namen und Identifikatoren von Autor(en) und Herausgeber(n), Titel, Verlagsinformation, Veröffentlichungsdatum und -ort, Identifizierung des übergeordneten Werks (z.B. einer Zeitschrift), Seitenangaben, URIs
Sekundäre Daten: Formatangaben, Nicht-Web-Identifikatoren (ISBN, LCCN, OCLC-Nummer etc.), Angaben zu Urheber- und Lizenzstatus, Angaben finanzieller Förderer, Angaben zum Trägermedium, Umfang- und Größenangaben, administrative Daten (letzte Änderung des Datensatzes etc.), relevante Links (zu Wikipedia, Google Books, Amazon etc.), Inhaltsverzeichnis, Links zu digitalisierten Auszügen eines Textes (Inhaltsverzeichnis, Register, Literaturverzeichnis etc.), Adresse und andere Kontaktdetails zum Autor/den Autoren, Coverabbildungen, Abstracts, Rezensionen, Zusammenfassungen, Schlagwörter, Stichwörter, Notationen, nutzergenerierte Tags, Exemplardaten (Signatur etc.),…
Übersetzung der englischen Originalfassung durch Adrian Pohl.