Jakoblog — Das Weblog von Jakob Voß

Why do Wikimedia projects fail to deliver open content?

From time to time I’d like to link to a famous quotation. I then remember Wikiquote, a wiki-based „quote compendium“ similar to Wikipedia, also run by the Wikimedia Foundation. Or I’d like to link to a famous text, and I visit Wikisource, an „online library of free content publications“, also Wikimedia project since years. But even when the quotation or text is included in Wikiquote/Wikisource, I most times leave depressed. This also applies to other Wikimedia projects, such as Wiktionary, Wikibooks, Wikimedia Commons, and even Wikipedia to some degree.

failed open content or just perpetual beta?

The reason has been mentioned by Gerard Meijssen at the Wikimedia Berlin Hackathon (#wmdevdays) a few days ago. He wrote that „Both #Wikibooks and #Wikisource do a terrible job promoting their finished product.“ I’d like to stress that Wikimedia projects do not (only) fail promoting, but they fail delivering their products. That’s sad, because Wikimedia projects are about collecting and creating open content, which anyone should be able to reuse. But conrtent is not truly open when it is only available for reuse by experts. For instance, why can’t one just…

• …link to a single quotation in Wikiquote? (WTF?!)
• …highlight a section in Wikipedia and get a stable link to this selection?
• …download content from Wikibooks, Wikisource, or Wikipedia in different formats such as EPUB, LaTeX, MarkDown, OpenDocument etc.?
• …find out the precise license of a media file from Commons?

Most of these tasks are possible if you are an expert in Wikimedia projects. You have to learn a crude WikiSyntax, know about MediaWiki API and dozens of license tags, know about extensions, do error-prone conversion on your own, deal with full dumps etc. Maybe I am too harsh because I love Wikimedia. But if you are honest about its projects, you should know: they are not designed for easy reuse of content, but more about work-in-progress collaborative editing (and even editing capability is poor compared with Google Docs and Etherpad).

Gerard suggested to create another Wikimedia project for publishing but I doubt this is the right direction. There is already a feature called Quality Revisions for marking a „final“ state of a page in MediaWiki. The core problem of reusing content from Wikimedia projects is more how to actually get content in a usable form (deep link, eBook formats, LaTeX… etc.).

First draft of Patrons Account Information API (PAIA)

Integrated Library Systems often lack open APIs or existing services are difficult to reuse because of access restrictions, complexity, and poor documentations. This also applies to patron information, such as loans, reservations, and fees. After reviewing standards such as NCIP, SLNP, and the DLF-ILS recommendations, the Patrons Account Information API (PAIA) was specifed at the Common Library Network (GBV).

PAIA consists of a small set of precisely defined access methods to look up patron information including fees, to renew and request documents, and to cancel requests. With PAIA it should be possible to make use of all patron methods that can be access in OPAC interfaces, also in third party applications, such as mobile Apps and discovery interfaces. The specification is divided into core methods (PAIA core) and methods for authentification (PAIA auth). This design will facilitate migration from insecure username/password authentification to more flexible systems based on OAuth 2.0. OAuth is also used by major service providers such as Google, Twitter, and Facebook.

The current draft of PAIA is available at http://gbv.github.com/paia/ and comments are very welcome. The specification is hosted in a git repository, accompanied by a wiki. Both can be accessed publicly to correct and improve the specification until its final release.

PAIA complements the Document Availability Information API (DAIA) which was created to access current availability information about documents in libraries and related institutions. Both PAIA and DAIA are being designed with a mapping to RDF, to also publish library information as linked data.

Goethe erklärt das Semantic Web

Seit Google vor einigen Tagen den „Knowledge Graph“ vorgestellt hat, rumort es in der Semantic Web Community. Klaut Google doch einfach Ideen und Techniken die seit Jahren unter der Bezeichnung „Linked Data“ und „Semantic Web“ entwickelt wurden, und verkauft das ganze unter anderem Namen neu! Ich finde sowohl die Aufregung als auch die gedankenlose Verwendung von Worten wie „Knowledge“ und „Semantic“ auf beiden Seiten albern.

Hirngespinste von denkenden Maschinen, die „Fakten“ präsentieren, als seien es objektive Urteile ohne soziale Herkunft und Kontext, sind nun eben Mainstream geworden. Dabei sind und bleiben es auch mit künstlicher Intelligenz immer Menschen, die darüber bestimmen, was Computer verknüpfen und präsentieren. Wie Frank Rieger in der FAZ gerade schrieb:

Es sind „unsere Maschinen“, nicht „die Maschinen“. Sie haben […] kein Bewusstsein, keinen Willen, keine Absichten. Sie werden konstruiert, gebaut und eingesetzt von Menschen, die damit Absichten und Ziele verfolgen – dem Zeitgeist folgend, meist die Maximierung von Profit und Machtpositionen.

In abgeschwächter Form tritt der Irrglaube von wissenden Computern in der Fokussierung auf „Information“ auf, während in den meisten Fällen stattdessen Daten verarbeitet werden. Statt eines „Knowledge Graph“ hätte ich deshalb lieber einen „Document Graph“, in dem sich Herkunft und Veränderungen von Aussagen zurückverfolgen lassen. Ted Nelson, der Erfinder des Hypertext hat dafür die Bezeichnung „Docuverse“ geschaffen. Wie er in seiner Korrektur von Tim Berners-Lee schreibt: „not ‘all the world’s information’, but all the world’s documents.“ Diese Transparenz liegt jedoch nicht im Interesse von Google; der Semantic-Web-Community ist sie die Behandlung von Aussagen über Aussagen schlicht zu aufwendig.

Laut lachen musste ich deshalb, als Google ein weiteres Blogposting zur Publikation von gewichteten Wortlisten mit einem Zitat aus Goethes Faust beginnen lässt:

Yet in each word some concept there must be…

Im „Docuverse“ wäre dieses Zitat durch Transklusion so eingebettet, dass sich sich der Weg zum Original zurückverfolgen ließe. Hier der Kontext des Zitat von Wikisource:

Mephistopheles: […] Im Ganzen – haltet euch an Worte! Dann geht ihr durch die sichre Pforte Zum Tempel der Gewißheit ein.

Schüler: Doch ein Begriff muß bey dem Worte seyn.

Mephistopheles: Schon gut! Nur muß man sich nicht allzu ängstlich quälen; Denn eben wo Begriffe fehlen, Da stellt ein Wort zur rechten Zeit sich ein. Mit Worten läßt sich trefflich streiten, Mit Worten ein System bereiten, An Worte läßt sich trefflich glauben, Von einem Wort läßt sich kein Jota rauben.

Die Antwort von Google (und nicht nur Google) auf den zitierten Einwand des Schülers gleicht nämlich bei näherer Betrachtung der Antwort des Teufels, wobei das „System“ das uns hier „bereitet“ wird ein algorithmisches ist, das nicht auf Begriffen sondern auf Wortlisten und anderen statistischen Verfahren beruht.

In der Zeitschrift für kritische Theorie führt Marcus Hawel zu eben diesem Zitat Goethes (bzw. Googles) aus, dass Begriffe unkritisch bleiben, solange sie nur positivistisch, ohne Berücksichtigung des „Seinsollen des Dings“, das bestehende „verdoppeln“ (vgl. Adorno). Wenn Google, dem Semantic Web oder irgend einem anderen Computersystem jedoch normative Macht zugebilligt wird, hört der Spaß auf (und das nicht nur aufgrund der Paradoxien deontischer Logik). Mir scheint, es mangelt in der semantischen Knowledge-Welt an Sprachkritik, Semiotik und kritischer Theorie.

Was ist XML?

Mein letzter längerer Artikel für das Lexikon der Bibliotheks- und Informationswissenschaft (LBI), dessen letzter Band dieses Jahr erscheinen wird, beschreibt die Extensible Markup Language (XML). Wie bei den anderen Artikeln (vgl. Ontologie und Ontologiesprache sowie Metadaten) besteht die Kunst darin, sich auf das wesentliche zu Beschränken und sinnvoll mit den bereits festgelegten Artikeln zu verlinken.

Wer Cloud sagt muss auch Bullshit sagen

In den letzten beiden Tagen fand in Göttingen ein GBV-Workshop zur Entwicklung der Lokalsysteme statt. Lokale Bibliothekssyteme (LBS, wobei im GBV dabei das LBS der Firma OCLC/PICA gemeint ist) oder Library Management Systems (LMS) sind für die zentralen Geschäftsgänge einer Bibliothek verantwortlich, d.h. für Ausleihe, Erwerbung, Nutzerverwaltung etc.

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.

HTTP Content negotiation and format selection

In University of Southampton’s WebTeam Blog Christopher Gutteridge just complained that HTTP content negotiation could do better. And he is right. In a nutshell, content negotiation allows to retrieve different forms, versions or representations of a digital document at the same URI.

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.

BibSonomy usability disaster

In addition to other citation management systems, I use BibSonomy. It’s one of the less known social cataloging tools. Not as commercial and shiny as Mendeley, but useful, especially if you happen to collect many papers in computer sciences. The BibSonomy team is open and friendly and the project is connected to the local University in Kassel (by the way, they are hiring students!). I still like BibSonomy – that’s why I wrote this rant.

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.

Wir brauchen eine offene Materialbibliothek

Weniger als eine Woche nach meinen ersten Ausführungen ist die erste Lieferung vom 2D-Cutting-Dienst Formulor angekommen. Die Firma ist ein Joint-Venture des internationalen Anbieters Ponoko und dem Berliner Laden Modulor (weitere Partner in anderen Ländern sind Vectorealism und RazorLab, sicher kommen in Zukunft mehr). Das umfangreiche Angebot des Material-Ladens Modulor hatte mich schon begeistert als ich noch in Berlin wohnte. Das offene Lager (inzwischen am Moritzplatz) lässt sich eher mit einer gut sortierten Buchhandlung als mit einem Baumarkt oder einem einfachen Bastelladen vergleichen. Ich habe mir deshalb neben der Modulor-Musterkiste gleich eine Musterkiste von Formulor schicken lassen:

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 😉

Produktion 2.0 – eine Ãœbersicht

Seit einigen Jahren verfolge ich mit etwas Abstand und wachsender Begeisterung eine Bewegung, die unsere Gesellschaft möglicherweise in ähnlicher Weise umkrempeln wird wie das Internet. Eine prägnante deutsche Bezeichnung für diese Bewegung habe ich noch nicht gefunden. Vorhandene englischen Begriffe wie Do-it-yourself, Crafting, Personal Fabricating, Home fabricating etc. heben nur verschiedene Aspekte hervor. Im Grunde genommen geht es darum, dass die allgemeine Digitalisierung und Automatisierung von der Kommunikation auf die Produktion übergreift. Ob die Verbreitung von Produktionsmitteln wie in Star Trek vorhergesehen endlich zu einer Abschaffung des Kapitalismus führt, sei dahingestellt. Ich möchte hier einige Ideen und Notizen zusammenfassen, um sich
dem Thema zu nähern.

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.

DAIA-Server erstellen mittels Screenscraping

Um die aktuelle Verfügbarkeit von Büchern und anderen Medien in GBV-Bibliotheken über eine standardisierte API abrufen zu können, entwickle ich derzeit einen zentralen DAIA-Server under daia.gbv.de. Da die verschiedenen Bibliotheken ihre lokalen Bibliothekssysteme allerdings sehr unterschiedlich konfiguriert haben, dauert die Bereitstellung von DAIA für alle Bibliotheken noch eine Weile.

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.