Von üblichen LMS wird die Recherche-Funktion zunehmend in so genannten Discovery Interfaces abgekoppelt. Idealerweise sollten auch andere Funktionen entkoppelt werden (z.B. die Benutzerverwaltung als LMS-unabhängiges Identity-Management). In der Realität sind die einzelnen Module von unterschiedlichen Herstellern aber nicht frei kombinierbar, womit deren ganzes Gerede von Schnittstellen und Services Augenwischerei ist.

Eine weitere Form der Verdummung von Bibliotheken ist mir auf der Veranstaltung mit mit dem Begriff Cloud aufgefallen. Cloud-Computing ist ein Buzzword, das anscheinend vor allem zur Verschleierung verwendet wird. Wenn wie im Workshop davon die Rede ist, dass “Daten in der Cloud verschwinden”, “eine eigene Cloud geschaffen werden soll” oder gar Forderungen nach einer “Deutschland-Cloud” laut werden, sollte eher von Nebel als von Wolke gesprochen werden. Denn ohne Angabe, was genaue für Dienste in eine Cloud ausgelagert werden sollen, ist der Begriff praktisch bedeutungslos und kann z.B. durch “Computer”, “Netzwerke”, “Server” oder “Hosting” ersetzt werden.

Dabei gibt es im Cloud-Computing eine etablierte Unterscheidung von drei groben Arten von Diensten: Bei Infrastruktur as a Service (IaaS) geht es um virtuelle Server. IaaS ist nicht mehr und nicht weniger als eine Alternative dazu, sich physische Rechner in die eigenen Räume zu stellen. Ein Beispiel für einen IaaS-Anbieter ist Amazon mit seinem Dienst Elastic Cloud Computing (EC2). Bei Platform as a Service (PaaS) wird eine Umgebung für eigene Programme bereitgestellt. PaaS ist nicht mehr und nicht weniger als eine Alternative zum Selber-Installieren und -Konfigurieren von Webservern, Programmiersprachen und allgemeinen Standard-Programmkomponenten. Die verschiedenen PaaS-Anbieter wie zum Beispiel Heroku, dotCloud und OpenShift unterscheiden sich vor allem darin, welche Programmiersprachen unterstützt werden.

Während verschiedene Anbieter von IaaS bzw. von PaaS jeweils in etwa vergleichbar sind, sieht es bei der dritten Art von Cloud anderes aus: Software as a Service (SaaS) bedeutet dass eine bestimmte Software nicht selber installiert und aktualisiert, sondern von einem Anbieter als Black-Box bereitgestellt wird. Ein populäres Beispiel für SaaS ist Google Docs. Während man bei IaaS und PaaS die Anbieter ähnliches bieten und man zwischen ihnen wechseln kann, hängt bei SaaS der Funktionsumfang völlig vom Anbieter ab und ein Wechsel ist praktisch nicht möglich. Im Gegenzug muss man sich als Nutzer keine Gedanken darum machen, wo die Software installiert ist und wie Updates durchgeführt werden. Beide Fragen wurden aber komischerweise auf dem GBV-Workshop diskutiert.

Vereinfacht gesagt lassen sich die drei Cloud-Arten so darstellen: Mit IaaS gibt es keine einzelnen Rechner mehr, mit PaaS gibt es keine einzelnen Installationsumgebungen mehr und mit SaaS gibt es keine einzelnen Updates mehr. Vor allem der letzte Punkt ist nach meinem Eindruck vielen nicht klar: bei SaaS gibt es keine Versionen oder Updates sondern nur neue Funktionen die im laufenden Betrieb aktiviert werden. Dieser Luxus wird erkauft mit (neben Geld) einer Einschränkung des Funktionsumfangs und mit einer Abhängkeit vom Anbieter.

So wie ich die Teilnehmer des GBV-Workshops verstanden habe, wollen Bibliotheken gerne die Vorteile aller Arten von Clouds zusammen: keine lästige Installation, Wartung und Auszeiten von Hard- und Software, kein Verzicht auf bisherige Funktionen (“alte Zöpfe”) und alles am Besten so, dass Anbieter gewechselt werden können. Wer Bibliotheken so etwas verkaufen möchte, hat aber entweder keine Ahnung oder er begeht mutwillige Täuschung. Software ist immer entweder Arbeit in Form von selber zu erbringender Programmierung und Konfiguration, oder sie ist in ihrem Funktionsumfang auf einen kleinsten gemeinsamen Nenner beschränkt. Ich ziehe dabei die erste Variante vor, zumal Programmierung ja auch über Einstellungen, Skripte und Plugins möglich ist. Es bleibt aber eigene Programmierung – wer als Anwender davor zurückschreckt, muss sich mit Einschränkungen Abhängigkeiten und Auszeiten abfinden, sei es im Bibliothekswesen oder anderswo.

Content negotiation is an important part of the Web architecture, but sucks for several reasons. The main problem is: there is no consensus about what defines a format/version/representation etc. and how to refer to selected forms of a digital document. At least for selection by different versions in time, there is a good specification with Memento and Accept-Datetime header. Content negotiation by language (Accept-Language) is similar unless you want to query by other aspects of language (slang, readability…), because language tags are clearly defined and precise. But the concept of “content types” (Accept header, also known as MIME types) is rather fuzzy.

Earlier I wrote about the difficulties to define “publication types” – it’s the same problem: there is no disjoint set of content types, document types, publication types, or formats! Each document and each representation can belong to multiple types and types may overlap. The easiest case, described by Christopher, is a subset relation between two types: for instance every XML document is also a Unicode string (be warned: there is no hierarchy of types, but maybe a Directed Acyclic Graph!). Not even this simple relationship between content types can be handled by HTTP content negotiation.

Anyway, the real reason for writing this post is yet another CPAN module I wrote: Plack::App::unAPI implements unAPI. unAPI is a kind of “poor man’s content negotiation”. Instead of sending additional HTTP headers, you directly select a format with format=... parameters. In contrast to HTTP Content negotiation, an unAPI server also returns a list of all formats it supports. This is a strong argument for unAPI in my opinion. I also added a method to combine unAPI with HTTP content negotiation.

Since last week BibSonomy has a new layout. Sure people always complain when you change their used interface, but this change is a usability desaster – at least if you work on a netbook with small screen, like me. To illustrate the problems here is a screenshot with my quick notes in red:

The screen is crowded with irritating and ugly user interface elements. The actual usage area is put into a little frame. Yes, a frame, in 2012! You cannot just scroll down to get rid of the header, because the frame is fixed. There are more flaws, for instance the duplication of account elements, scattered at not less than four places (logged in as…, logout, user:…, myBibsobomy) and the ugly custom icons (there are several great icon sets that could be used instead, for instance Silk, GCons, Glyphicons, Picol…). It does not get better of you try to edit content. I am sorry, but this is a usability disaster.

P.S: The BibSonomy team has responded and they fixed part of the problem with a nasty hack, based on actual screen size.

Die Palette der Materialien, aus denen bei Formulor Teile geschnitten werden können, reicht von Acrylglas in verschiedenen Farben und Lichtdurchlässigkeiten (transparent, transluzent, opak) über Holz, Filz, Leder, Wellpappe und Karton bis zu Spiegeln, Silikon und Stempelgummi. Aus dokumentarischer Sicht lässt sich allerdings die Beschreibung der Materialien verbessern.

Ich hätte gerne genaue physikalische Angaben zu Dichte, Lichtdurchlässigkeit, Bruch- und Feuerfestigkeit, Ausdehnungskoeffizient etc. – natürlich kann und sollte das nicht eine private Firma im Alleingang machen, mir schwebt eher eine “digitale Materialbibliothek” vor. Wäre das nicht eine gute Anwendung für das “Semantic Web”, um Suchen wie “Material mit Bruchstärke X und Gewicht zwischen Y und Z” zu ermöglichen? Die Materialdatenbank sollte wie Wikipedia möglichst offen und kollaborativ erstellt werden, z.B. als WikiData-Projekt.

Neben dem Lager von Modulor und ähnlichen Firmen (z.B. Material ConneXion Cologne und Materialsgate) gibt es bereits einige kleine Materialbibliotheken an Hochschulen, z.B. an der FH Münster, in Luzern, Mainz, Niederrhein etc. und Materialdatenbanken z.B. an der FH Potsdam und der TU Delft. Die beste Datenbank, die ich bei meiner kurzen Recherche finden konnte ist das Materialarchiv, ein Verbundkatalog der Schweizer Materialbibliotheken. Open Data sind die Materialbeschreibungen dort aber leider auch nicht.

P.S.: Und was die Buchmesse für die Literaturwelt ist, ist anscheinend die Materialica für die Materialwelt

Es dürfte sich inzwischen herumgesprochen haben, dass das die Digitaltechnik einen tiefgreifenden Wandel mit sich gebracht hat für die Art und Weise wie wir kommunizieren. Dies betrifft zum einen die Formen und Mittel über die wir kommunizieren (Handys, eMails, Instant-Messaging, Soziale Netzwerke…) als auch die Frage wer mit wem kommunizieren kann (nutzergenerierte Inhalte, Peer-to-Peer-Netzwerke, Print-on-Demand…). Für viele Menschen ist es einfach geworden, Texte, Bilder, Musik und Filme zu erstellen und zu verbreiten. Da diese Inhalte digital vorliegen, können sie auch leicht von anderen verändert und kombiniert werden, was kollaborative Projekte wie Wikipedia ermöglicht. Obgleich diese Möglichkeiten teilweise durch Gesetze und die ungleiche Verteilung von Reichtum und Bildung eingeschränkt sind, setzen sie sich immer mehr durch. Die neuen Möglichkeiten der Kommunikation haben auch ihre Nachteile, aber sie sich praktisch unumkehrbar. In Zukunft werden wir einen ähnlichen Wandel bei den Möglichkeiten der Herstellung von physischen Gegenständen erleben. Obgleich sich die Entwicklung eher über mehrere Jahrzehnte hinzieht, sind schon jetzt immer mehr Anwendungen sichtbar.

Um viele Menschen zu erreichen, waren früher große Filmkameras, TV-Stationen, Druckmaschinen, Pressevertriebe u.v.a.m. notwendig. Diese Kommunikationsmittel wurden immer kleiner und billiger so dass heute fast jeder zweite mit ihnen herumläuft. Das nennt sich dann Smartphone. Um physische Gegenstände für viele Menschen herzustellen braucht es bislang große Fabriken und Maschinen. Diese Produktionsmittel werden allerdings auch immer kleiner und billiger. Dabei lassen sich verschiedene Arten von Geräten für die digitale Herstellung unterscheiden:

3D-Drucker erzeugen, in der Regel durch schichtweises Auftragen, dreidimensionale Objekte aus Materialien wie Plastik, Metall, Keramik, Sandstein, Glas u.A. (additive Herstellung).

Cutter schneiden aus verschiedenen Materialen wie Papier, Plastik, Holz, Stoff, Kork, Metall etc. Stücke aus, wobei verschiedene Verfahren wie Laser und Messer zum Einsatz kommen. Daneben gibt es CNC-Fräsen und weitere Verfahren, um Objekten zu zerteilen, zu bohren etc. (subtraktive Herstellung)

Darüber hinaus gibt es spezielle Maschinen zum Zeichnen, Sticken, Nähen, Weben, Umformen, Drehen, Schweißen u.v.a.m. Schließlich gibt es Roboter, die unter Anderem verschiedene Teile zusammensetzen und andere Maschinen bedienen können. Abgesehen von Industrierobotern (die kommen auch noch) sind immer mehr dieser Geräte auch für normale Menschen verfügbar. Zum einen gibt es Dienstleister, die aus digitalen Vorlagen Produkte herstellen und verschicken, und zum anderen kosten 3D-Drucker und Cutter inzwischen weniger als was noch vor einigen Jahren für Laserdrucker ausgegeben werden musste. Der Schwerpunkt liegt dabei bislang auf 3D-Druckern und Cuttern. Während professionelle 3D-Drucker (u.A. von Hewlett-Packard) noch mehrere Tausend Euro kosten, gibt es einfache Schneidemaschinen, mit denen sich Papier, Folie und ähnliche Materialien schneiden lassen, schon für den Massenmarkt (hier eine Übersicht).

In der Computerzeitschrift c’t gab es bereits letztes Jahr einen Bericht und Vergleichstest von Anbietern für 3D-Druck. Der nach meinem Eindruck größte unter ihnen ist Shapeways. Weitere mir bekannte Anbieter sind Sculpteo, i.materialise und Kraftwurx. Ein vergleichbarer Anbieter für 2D-Cutter ist Formulor bzw. Ponoko. Daneben gibt es Firmen, die sich eher an Geschäftskunden wie rapidobject und Cut Laser Cut sowie lokale Anbieter, mit deren 3D-Drucker man sich Gegenstände ausdrucken lassen kann. Hervorzuheben sind vor allem die so genannten FabLabs, die ähnlich wie Hackerspaces als offene Werkstätten und Vereine konzipiert sind. Für den offene Austausch von Designvorlagen zur Produktion von Objekten gibt es die Plattform thingiverse.

Spannend finde ich vor allem, dass Produktionsmaschinen selbst physische Objekte sind, die sich automatisch herstellen lassen. Die gemeinsame Entwicklung einer Maschine, die eine identische Kopie von sich herstellen kann, ist das Ziel des RepRap Projekt. Die bereits entwickelten Modelle sind für unter Tausend Euro Materialkosten die derzeit günstigsten 3D-Drucker. Eine Alternative sind die Drucker der Firma MakerBot Industries, dem Betreiber von Thingiverse. MakerBot stellt die Baupläne ihrer Drucker dort frei zur Verfügung und läd dazu ein die Geräte anzupassen und zu verbessern. Daneben können die Drucker aber auch fertig gekauft werden. Das derzeit größte Modell ist mit 1749$ (ggf. plus Zoll) noch erschwinglich. Eine ähnliche Firma ist Ultimaker, deren Drucker in Europa als Bausatz €1,444 brutto kostet. Einen relativ großen Open Source Lasercutter gibt es demnächst mit dem LaserSaur und bereits jetzt den buildlog.net 2x.

Die Entwicklung von Maschinen zur digitalen Herstellung sollte auch im größeren Zusammenhang gesehen werden. So arbeitet die Open Source Ecology community beispielsweise an freien Werkzeugen für die Landwirtschaft und zur Energieerzeugung, z.B. einen Trecker und einer Dampfmaschine. Neben der Energieerzeugung sind die Rohstoffe nämlich noch eine offene Frage. Eigentlich kommen für eine nachhaltige, dezentrale Produktion nämlich nur nachwachsende Rohstoffe in Frage.

Neben Weltverbesserern und Techniknerds gewinnen digitale Produktionsmittel auch für ganz normale Heimwerker und Handarbeiter an Bedeutung. Gleichzeitig können Menschen mit ihren Produkten und Menschen, die ein Produkt suchen, leichter zueinander finden, zum Beispiel bei DaWanda. Aus bibliothekarischer Sicht muss ich allerdings sagen, dass die Erschließung und die zielgerichtete Auffindbarkeit von bereits vorhandenen Objekten bei allen genannten Plattformen mangelhaft ist. Es fehlt eine Art “WorldCat der Dinge”, in dem sich Anbieterübergreifend und übersichtlich nach Anwendungsgebieten, Materialien und anderen Kriterien suchen lässt.

Weitere Informationen und Neuigkeiten zum Thema gibt es unter Anderem bei 3druck.com und in dem Weblog handmade 2.0, das vor kurzem eine Übersicht von deutschsprachigen Crafting Zeitschriften veröffentlicht hat.

Eine alternative Lösung, die auch für Bibliotheken funktioniert, die nicht im GBV sind und/oder PICA-LBS einsetzen, ist die Erstellung eines eigene DAIA-Servers. Als Grundgerüst habe ich dafür das Perl-Modul Plack::App::DAIA entwickelt und stelle es als Open Source zur Verfügung. Das Modul enthält zudem Routinen, um eigene DAIA-Server ausbgiebig auf korrekte Umsetzung zu testen – schließlich sind technische Standards, die nicht (automatisch) getestet werden können, eher unverbindliche Absichtserklärungen als wirkliche Standards. Das Perl-Modul enthält ein Beispielskript, das mittels Sceeenscraping (dank des Moduls pQuery), dem Katalog der Universitätsbibliothek Bielefeld eine DAIA-Schnittstelle aufsetzt.

~~~~ {.dot .Grankdir:LR}
digraph {
A -> B -> C;
A -> C;
}
~~~~

and you get

or based on rdfdot you write

~~~~ {.rdfdot}
@prefix foaf: <http: //xmlns.com/foaf/0.1/> .
@base <http: //example.com/> .
<alice> foaf:name “Alice” ;
foaf:knows [ foaf:name "Bob" ] .
~~~~

and you get

A detailed description is included in the manual which has been transformed automatically to HTML and to PDF. Compare both documents to see that HTML includes PNG images and PDF contains vector images!

Feel free to reuse and modify the script, for instance by adding more diagram types! For instance how about ASCII tabs and ABC notation if you write about music?

Among other project, Koster points to LibraryCloud to aggregate and deliver library metadata, but it looks like they reinvent yet more wheels in form of their own APIS and formats for search and for bibliographic description. Maybe I am wrong about this project, as they just started to collect holding and circulation data.

At the recent Semantic Web in Bibliotheken conference, Magnus Pfeffer gave a presentation about “Publishing and consuming library loan information as linked open data” (see slides) and I talked about a Simplified Ontology for Bibliographic Resources (SOBR) which is mainly based on the DAIA data model. We are going to align both data models and I hope that the next libraries will first look at these existing solutions instead of inventing yet another data format or ontology. Koster’s proposal, however, looks like such another solution: he argues that “we need an extra explicit level to link physical Items owned by the library or online subscriptions of the library to the appropriate shared network level” and suggests to introduce a “holding” level. So there would be five levels of description:

• Work
• Expression
• Manifestation
• Holding
• Item

Apart from the fact that at least one of Work, Expression, Manifestation is dispensable, I disagree with a Holding level above the Item. My current model consists of at most three levels of documents:

• document as abstract work (frbr:Work, schema:CreativeWork…)
• bibliographic document (frbr:Manifestation, sobr:Edition…)
• item as concrete single copy (frbr:Item…)

The term “level” is misleading because these classes are not disjoint. I depicted their relationship in a simple Venn diagram:

For local library data, we are interested in single items, which are copies of general documents or editions. Where do Koster’s “holding” entities fit into this model? He writes “a specific Holding in this way would indicate that a specific library has one or more copies (Items) of a specific edition of a work (Manifestation), or offers access to an online digital article by way of a subscription.” The core concepts as I read them are:

• “one or more copies (Items)” = frbr:Item
• “specific edition of a work (Manifestation)” = sobr:Edition or frbr:Manifestation
• “has one [...] or offer access to” = ???

Instead of creating another entity for holdings, you can express the ability “to have one or offer access to” by DAIA Services. The class daia:Service can be used for an unspecified service and more specific subclasses such as loan, presentation, and openaccess can be used if more is known. Here is a real example with all “levels”:

<http://dbpedia.org/resource/Tractatus_Logico-Philosophicus>
    a bibo:Book ;
    daia:edition <urn:nbn:de:eki:GBV128382600> ;
    daia:exemplar
        <http://uri.gbv.de/document/opac-de-23:epn:266449999> .

<urn:nbn:de:eki:GBV128382600> a bibo:Book ;
    daia:exemplar
        <http://uri.gbv.de/document/opac-de-23:epn:266449999> .

<http://uri.gbv.de/document/opac-de-23:epn:266449999>
    a bibo:Book, daia:Item ;
    daia:heldBy <http://uri.gbv.de/organization/isil/DE-23> ;
        daia:availableFor [
            a daia:Service ;
            daia:providedBy <http://uri.gbv.de/organization/isil/DE-23>
        ] .

I have only made up the RDF property daia:edition from the SOBR proposal because FRBR relations are too strict. If you know a better relation to directly relate an abstract work to a concrete edition, please let me know.

image created with rdfdot

• bibliographicIdentifer (string) → document (URI)
• itemIdentifier (string) → item (URI)
• dateAvailable (dateTime) → expected (xs:dateTime or xs:date or “unknown”) or delay (xs:duration or “unknown”)
• location (string) → storage (URI and/or string, plus optional URL)
• call number (string) → label (string)
• holdQueueLength (int) → queue (xs:nonNegativeInteger)
• status (string) and circulating (boolean) → available/unavailable (with service type and additional information)

So you could say that DAIA implements the abstract GetAvailability function from DLF-ILS. I like abstract, language independent specifications, but they must be precise and testable (see Meek’s forgotten paper The seven golden rules for producing language-independent standards). DAIA 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. The only reference to specific formats is the requirement that all unique identifiers must be URIs. Right now there is an XML Schema if you want to express DAIA in XML and an OWL ontology for RDF.

In its fourth year of development (see my previous posts from 2009) DAIA seems to have enough momentum to finally get accepted in practice. We use it in GBV library union (public server at http://daia.gbv.de/), there are independent implementations such as in Doctor-Doc, there is client-support in VuFind and I heard rumors that DAIA capabilities will be build into EBSCO and Summon Discovery Services. Native support in Integrated Library Systems, however, is still lacking – I already have given up hope and prefer a clean DAIA wrapper over a broken DAIA-implementation anyway. If you are interested in creating your own DAIA server/wrapper or client, have a look at my reference implementation DAIA and Plack::App::DAIA at CPAN and Oliver Goldschmidt’s PHP implementation in our common github repository. A conceptual overview as tree (DAIA/JSON, DAIA/XML) and as graph (DAIA/RDF) can be found here.

Still there are some details to be defined and I’d like to solve these issues to come to a version DAIA 1.0. These are

• How to deal with partial publications (you requested an article but only get the full book or you requested a series but only get a single volume).
• How to deal with digital publications (especially its possible service types: is “download” a service distinct to “loan” or is “presentation” similar to online access restricted to the library’s intranet?).
• Final agreement on service types (now there are presentation: item can be used in the institution, loan: item can be used outside of the institution for a limited time, interloan: item can be send to another institution, openaccess: item can be access unrestricted, just get a free copy). Some extensions have been proposed.
• A set of common limitation types (for instance IP-based access restriction, permission-based access etc.).

I’d be happy to get some more feedback on these issues, especially concrete use cases. We are already discussing on the daia-devel mailing list but you can also comment in your own blog, at public-lld, code4lib, ils-di etc.).