Testing command line apps with App::Cmd

1. November 2013 um 10:49 1 Kommentar

This posting has also been published at blogs.perl.org.

Ricardo Signes’ App::Cmd has been praised a lot so I gave it a try for my recent command line app. In summary, the module is great although I missed some minor features and documentation (reminder to all: if you miss some feature in a CPAN module, don’t create yet another module but try to improve the existing one!). One feature I like a lot is how App::Cmd facilitates writing tests for command line apps. After having written a short wrapper around App::Cmd::Tester my formerly ugly unit tests look very simple and clean. Have a look at this example:

use Test::More;
use App::PAIA::Tester;

new_paia_test;

paia qw(config);
is stdout, "{}\n";
is error, undef;

paia qw(config -c x.json --verbose);
is error, "failed to open config file x.json\n";
ok exit_code; 

paia qw(config --config x.json --verbose foo bar);
is output, "# saved config file x.json\n";

paia qw(config foo bar);
paia qw(config base http://example.org/);
is exit_code, 0;
is output, '';

paia qw(config);
is_deeply stdout_json, {
    base => 'http://example.org/',
    foo => 'bar',
}, "get full config"

done_paia_test;

The application is called paia – that’s how it called at command line and that’s how it is simply called as function in the tests. The wrapper class (here: App::PAIA::Tester) creates a singleton App::Cmd::Tester::Result object and exports its methods (stdout, stderr, exit_code…). This alone makes the test much more readable. The wrapper further exports two methods to set up a testing environment (new_paia_test) and to finish testing (done_paia_test). In my case the setup creates an empty temporary directory, other applications might clean up environment variables etc. Depending on your application you might also add some handy functions like stdout_json to parse the app’s output in a form that can better be tested.

My PhD thesis about data

23. September 2013 um 09:03 3 Kommentare

I have finally received paper copies of my PhD thesis “Describing Data Patterns”, published and printed via CreateSpace. The full PDF has already been archived as CC-BY-SA, but a paper print may still be nice and more handy (it’s printed as small paperback instead of the large A4-PDF). You can get a copy for 12.80€ or 12.24€ via Amazon (ISBN 1-4909-3186-4).

I also set up a little website at aboutdata.org. The site contains an HTML view of the pattern language that I developed as one result of the thesis.

I am sorry for not having written the thesis in Pandoc Markdown but in LaTeX (source code available at GitHub), so there is no EPUB/HTML version.

O’Reilly steigt mit HTMLBook auf HTML5 um

22. September 2013 um 13:22 Keine Kommentare

O’Reilly Media, führender und einflussreicher Verlag im Bereich elektronisches Publizieren und technischer Handbücher, hat angekündigt von DocBook XML auf eine Teilmenge von HTML5 umzusteigen. Neben dem Blogartikel wird der Schritt in einem Fachartikel auf der Balisage Konferenz erläutert. HTML5 soll sowohl erweiterte Dokumentformen (aka “Beyond the PDF”) ermöglichen, als auch gleichzeitig als Autorenwerkzeug dienen. Die von O’Reilly entwickelte Teilmenge von HTML5 heisst “HTMLBook” und ist ein einem öffentlichen Git-Repository einsehbar. Ich persönlich bin ja etwas skeptisch, da WYSIWYG dem Ziel widerspricht, Inhalte für verschiedene Ausgabeformate zu entwerfen und ziehe deshalb Pandoc vor.

Larry Nivens Ringwelt ist überbewertet

22. Juli 2013 um 19:41 1 Kommentar

Ich bin im Urlaub endlich mal wieder zum Lesen gekommen und habe mir Larry Nivens “Ringworld” vorgenommen, den ich neulich im Antiquariat mitgenommen hatte. Der 1970 erschienene Science-Fiction-Klassiker wurde mit drei der großen SF-Preise ausgezeichnet (Nebula, Hugo und Locus Award) und Nivens vier Jahre später erschienenen “Der Splitter im Auge Gottes” hatte ich als Junge mit Begeisterung verschlungen – da konnte ich doch eigenlich nichts falsch machen, oder?

Leider war der Roman aber enttäuschend. Nicht unbedingt schlecht, wann man wie ich auf Romane steht, die vor allem tief in den Weltraum führen. Ich würde ihm 3 von 5 Sternen geben. Aber die Schwächen, die mir vermutlich vor zehn oder zwanzig Jahren nicht aufgefallen wären, haben die Lektüre etwas getrübt. Kurz gesagt bleibt die Beschreibung der Ringwelt selber hinter den Erwartungen zurück und der Roman stört durch seine sexistische Beschreibung von Frauen. Wie ich später festgestellt habe, ist das auch bereits anderen aufgefallen, deshalb verweise ich hier auf Kritiken, denen ich nur zustimmen kann:

If there’s any reason I find Ringworld interesting it’s as an example of the blatant chauvinism, if not outright misogyny, that often suffuses science fiction works, even to this day.

Claire Love

Niven has often been criticised for being noticeably poor at female characters (if not for being downright misogynist), and having read Ringworld I now understand exactly what those critics mean.

Lobdozer

But what Niven wanted, for both kzin and puppeteer, was alien species with non-sentient females. He wanted this to an extent that it did not occur to him to justify it scientifically or rationally.

Feminist SF – The Blog

I know it’s supposed to be a classic but even without the intense sexism, it just wasn’t as impressive as quite a few of the other classics in the genre.

Melissa Berry

Sicher gibt es schlechtere Romane, auch hinsichtlich des hier herausgegriffenen Kritikpunkts Sexismus und Frauenfeindlichkeit. Aber es gibt eben auch bessere Science-Fiction. Bei meiner Suche nach Kritiken bin ich unter anderem auf den Thread “Non-sexist hard scifi: does it exist?” im xkcd-Forum und auf die umfangreiche Webseite Feminist Science Fiction, Utopian & Fantasy gestoßen.

Identifier in RDF considered harmful

18. Juni 2013 um 11:31 7 Kommentare

Ich bin gerade dabei die RDF-Daten des Linked Data Service der ZDB zu analysieren, um sie direkt im RDF-Bibliotheksverzeichnis des GBV nutzen zu können. Dabei sind mir einige Unterschiede bei der Behandlung von Identifiern aufgefallen. Hier ein Beispiel aus den Daten der
Stabi Berlin (das RDF-Subjekt habe ich zum Kürzen durch $BIB ersetzt):

GBV-RDF

$BIB
  dc11:identifier "DE-1a" ;
  foaf:phone <tel:+49-30-2-66-333501> , <tel:+49-30-2-66-433888> .

ZDB-RDF

$BIB
  dc11:identifier "(ISIL)DE-1a" ;
  vcard:tel [
     a vcard:Pref, vcard:Voice ;
     rdf:value "+49 30 2 66-433888 (Auskunft)"
  ], [
     a vcard:Fax, vcard:Pref ;
     rdf:value "+49 30 2 66-333501" .
  ] .

Solche unterschiedlichen Kodierungen sind besonders dann problematisch wenn RDF-Daten aus mehreren Quellen zusammengeführt werden sollen. Plötzlich hat dann in diesem Beispiel die Stabi Berlin zweil Identifier und vier Telefonnummern. Telefonnummern lassen sich übrigens nach RDF 3966 auch als URI kodieren, für ISILs gilt dies leider nicht, weil die internationale ISIL-Agentur versäumt hat, sich darum zu kümmern. Grundsätzlich bestärkt mich dieses Beispiel in der Überzeugung, dass Identifier in RDF-Daten Müll sind, solange sie nicht in Form von URIs kodiert werden – und zwar in vielen Fällen besser nicht als HTTP-URIs in mehrfacher Ausführung, wie im Rahmen von Linked Data gängige Praxis!

Auf der Suche nach einer korrekten Hose

12. Mai 2013 um 22:44 3 Kommentare

Nach dem letzten Fabrikeinsturz in Bangladesch mit über Tausend Toten habe ich mich endlich mal mit dem Thema Fair-Trade-Kleidung beschäftigt. Eigentlich will ich momentan einfach nur eine fair gehandelte Jeans. Da deutsche Innenstädte gefühlt zu 90% mit Klamotten und Telefonläden zugepflastert sind, sollte die Suche doch nicht zu schwierig sein (das mit dem Fair-Trade-Telefon ist eine andere Geschichte),.

Ganz so einfach ist die Suche dann aber doch nicht. Es gibt lediglich eine überschaubare Szene von vernetzten Fair-Trade-Kleidungsläden und -labels. Die umfangreichste Übersicht hat anscheinend auf “Grüne Mode” (in Form von PDF-Listen, die nur nichtkommerziell verwendet werden dürfen). Einige Labels haben eigene Übersichten durch die man sich mühsam durchklicken muss. Mein bislang bester Algorithmus zur Suche nach einer korrekten Hose, die ich vor Ort anprobieren kann (d.h. nicht erst im Internet bestellen muss) ist folgender:

  1. Wenn es in deiner Stadt einen “Ethical Fashion Store” gibt, schau dort vorbei.
  2. Andernfalls führe eine Verknüpfung von passenden Labels mit einer Zuordnungstabelle von Labels zu Ladengeschäften (wie TheLabelFinder), selektiert auf deine Stadt, aus.

Wenn das mit dem Semantic Web und Open Data anständig funktionieren würde, liesse sich eine Suchanfrage wie “Welche Göttinger Läden führen Fair-Trade-Jeans?” auch automatisch beantworten.

P.S: Inzwischen habe ich eine Hose von Nudie – den Göttinger Laden LEI kann ich allerdings nicht empfehlen, der hat von Fair Trade noch nichts gehört, kann nicht gut beraten und führt die Marke anscheinend nur weil es schick ist. Dafür habe ich einen Good Jeans Guide gefunden. Vor allem Manomama ist eine tolle Initiative von Sina Trinkwalder. Ihr Buch, das sie gerade fertig gestellt hat erscheint im Oktober.

Einladung zur Disputation

25. April 2013 um 14:30 7 Kommentare

Im Januar habe ich endlich meine Dissertation abgegeben und werde sie am Freitag, den 31. Mai verteidigen. Die Disputation findet um 16 Uhr im Jacob-und-Wilhelm-Grimm-Zentrum im Videokonferenzraum 1 ’312 statt (siehe auch die offizielle Einladung [PDF]). Der Titel meiner Dissertation lautet Describing data patterns. A general deconstruction of metadata standards. Meine Gutachter sind Prof. Dr. Stefan Gradmann, Prof. Dr. Felix Sasaki und Prof. Dr. William L. Honig.

Die Veranstaltung ist öffentlich, allerdings ist der Raum nicht sehr groß und in der Bibliothek (d.h. Jacken, Mäntel, Taschen etc. müssen an der Garderobe abgegeben werden). Da Prof. Honig in Chicago ist, wird der Vortrag per Videokonferenz übertragen und aufgezeichnet. Ob weitere Teilnehmer (per H.239/H.323) möglich sind und ob/wann die Aufzeichnung online gestellt werden kann, weiß ich derzeit noch nicht. Die anschließende Veröffentlichung der Arbeit erfolgt im Laufe des Jahres wahrscheinlich auf dem Dokumenten- und Publikationsserver der HU sowie ggf. per Print-on-Demand. Hier erstmal Abstract bzw. Zusammenfassung der Arbeit:

Many methods, technologies, standards, and languages exist to structure and describe data. The aim of this thesis is to find common features in these methods to determine how data is actually structured and described. Existing studies are limited to notions of data as recorded observations and facts, or they require given structures to build on, such as the concept of a record or the concept of a schema. These presumed concepts have been deconstructed in this thesis from a semiotic point of view. This was done by analysing data as signs, communicated in form of digital documents. The study was conducted by a phenomenological research method. Conceptual properties of data structuring and description were first collected and experienced critically. Examples of such properties include encodings, identifiers, formats, schemas, and models. The analysis resulted in six prototypes to categorize data methods by their primary purpose. The study further revealed five basic paradigms that deeply shape how data is structured and described in practice. The third result consists of a pattern language of data structuring. The patterns show problems and solutions which occur over and over again in data, independent from particular technologies. Twenty general patterns were identified and described, each with its benefits, consequences, pitfalls, and relations to other patterns. The results can help to better understand data and its actual forms, both for consumption and creation of data. Particular domains of application include data archaeology and data literacy.

Diese Arbeit behandelt die Frage, wie Daten grundsätzlich strukturiert und beschrieben sind. Im Gegensatz zu vorhandenen Auseinandersetzungen mit Daten im Sinne von gespeicherten Beobachtungen oder Sachverhalten, werden Daten hierbei semiotisch als Zeichen aufgefasst. Diese Zeichen werden in Form von digitalen Dokumenten kommuniziert und sind mittels zahlreicher Standards, Formate, Sprachen, Kodierungen, Schemata, Techniken etc. strukturiert und beschrieben. Diese Vielfalt von Mitteln wird erstmals in ihrer Gesamtheit mit Hilfe der phenomenologischen Forschungsmethode analysiert. Ziel ist es dabei, durch eine genaue Erfahrung und Beschreibung von Mitteln zur Strukturierung und Beschreibung von Daten zum allgemeinen Wesen der Datenstrukturierung und -beschreibung vorzudringen. Die Ergebnisse dieser Arbeit bestehen aus drei Teilen. Erstens ergeben sich sechs Prototypen, die die beschriebenen Mittel nach ihrem Hauptanwendungszweck kategorisieren. Zweitens gibt es fünf Paradigmen, die das Verständnis und die Anwendung von Mitteln zur Strukturierung und Beschreibung von Daten grundlegend beeinflussen. Drittens legt diese Arbeit eine Mustersprache der Datenstrukturierung vor. In zwanzig Mustern werden typische Probleme und Lösungen dokumentiert, die bei der Strukturierung und Beschreibung von Daten unabhängig von konkreten Techniken immer wieder auftreten. Die Ergebnisse dieser Arbeit können dazu beitragen, das Verständnis von Daten — das heisst digitalen Dokumente und ihre Metadaten in allen ihren Formen — zu verbessern. Spezielle Anwendungsgebiete liegen unter Anderem in den Bereichen Datenarchäologie und Daten-Literacy.

Jetzt muss ich nur noch anfangen, den Vortrag vorzubereiten…

On the way to a library ontology

11. April 2013 um 15:02 Keine Kommentare

I have been working for some years on specification and implementation of several APIs and exchange formats for data used in, and provided by libraries. Unfortunately most existing library standards are either fuzzy, complex, and misused (such as MARC21), or limited to bibliographic data or authority data, or both. Libraries, however, are much more than bibliographic data – they involve library patrons, library buildings, library services, library holdings, library databases etc.

During the work on formats and APIs for these parts of library world, Patrons Account Information API (PAIA) being the newest piece, I found myself more and more on the way to a whole library ontology. The idea of a library ontology started in 2009 (now moved to this location) but designing such a broad data model from bottom would surely have lead to yet another complex, impractical and unused library standard. Meanwhile there are several smaller ontologies for parts of the library world, to be combined and used as Linked Open Data.

In my opinion, ontologies, RDF, Semantic Web, Linked Data and all the buzz is is overrated, but it includes some opportunities for clean data modeling and data integration, which one rarely finds in library data. For this reason I try to design all APIs and formats at least compatible with RDF. For instance the Document Availability Information API (DAIA), created in 2008 (and now being slightly redesigned for version 1.0) can be accessed in XML and in JSON format, and both can fully be mapped to RDF. Other micro-ontologies include:

  • Document Service Ontology (DSO) defines typical document-related services such as loan, presentation, and digitization
  • Simple Service Status Ontology (SSSO) defines a service instance as kind of event that connects a service provider (e.g. a library) with a service consumer (e.g. a library patron). SSSO further defines typical service status (e.g. reserved, prepared, executed…) and limitations of a service (e.g. a waiting queue or a delay
  • Patrons Account Information API (PAIA) will include a mapping to RDF to express basic patron information, fees, and a list of current services in a patron account, based on SSSO and DSO.
  • Document Availability Information API (DAIA) includes a mapping to RDF to express the current availability of library holdings for selected services. See here for the current draft.
  • A holdings ontology should define properties to relate holdings (or parts of holdings) to abstract documents and editions and to holding institutions.
  • GBV Ontology contains several concepts and relations used in GBV library network that do not fit into other ontologies (yet).
  • One might further create a database ontology to describe library databases with their provider, extent APIs etc. – right now we use the GBV ontology for this purpose. Is there anything to reuse instead of creating just another ontology?!

The next step will probably creation of a small holdings ontology that nicely fits to the other micro-ontologies. This ontology should be aligned or compatible with the BIBFRAME initiative, other ontologies such as Schema.org, and existing holding formats, without becoming too complex. The German Initiative DINI-KIM has just launched a a working group to define such holding format or ontology.

Dead End Electronic Resource Citation (ERC)

29. März 2013 um 11:51 Keine Kommentare

Tidying up my PhD notes, I found this short rant about “Electronic Resource Citation”. I have not used it anywhere, so I publish it here, licensed under CC-BY-SA.

Electronic Resource Citation (ERC) was introduced by John Kunze with a presentation at the International Conference on Dublin Core and Metadata Applications 2001 and with a paper in the Journal of Digital Information, Vol. 2, No 2 (2002). Kunze cited his paper in a call for an ERC Interest Group within the Dublin Core Metadata Initiative (DCMI) at the PERL4LIB mailing list, giving the following example of an ERC:

erc:  Kunze, John A. | A Metadata Kernel for Electronic Permanence
      | 20011106 | http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Kunze/

An ERC is a minimal “kernel” metadata record that consist of four elements: who, what, when and where. In the given example they are:

who:   Kunze, John A.
what:  A Metadata Kernel for Electronic Permanence
when:  20011106
where: http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Kunze/

Ironically the given URL is obsolete, the host ‘jodi.ecs.soton.ac.uk’ does not even exist anymore. The ERC is pretty useless if it just uses a fragile URL to cite a resource. How about some value that does not change over time, e.g:

where: Journal of Digital Information, Volume 2 Issue 2

As ERC is defined as “a location or machine-oriented identifier”, one could also use stable identifiers:

where: ISSN 1368-7506, Article No. 81

Both ISSN and article numbers 81 are much more identifiers then URLs. Citing an URL is more like

where: at the desk in the little reading room of my library

By the way the current location is http://www.rice.edu/perl4lib/archives/2002-09/msg00017.html – but who knows whether Texas A&M University will still host the journal at this URL in 20 years?

There are some interesting ideas in the original ERC proposal (different kinds of missing values, TEMPER date values, the four questions etc.), but its specification and implementation are just ridiculous and missing references to current technology (you know that you are doing something wrong in specification if you start to define your own encodings for characters, dates etc. instead of concentrating to your core subject and refering to existing specifications for the rest). The current draft (2010) is a typical example of badly mixing modeling and encoding issues and of loosing touch with existing, established data standards.

In addition to problems at the “low level” of encoding, the “high level” of conceptual modeling lacks appropriate references. What about the relation of ERC concepts to models such as FRBR and CIDOC-CRM? Why are ‘who’, ‘when’, ‘where’, ‘what’ the important metadata fields (in many cases the most interesting question is ‘why’)? How about Ranganathan’s colon classification with personality, matter, energy, space, and time?

In summary the motivation behind ERC contains some good ideas, but its form is misdirected.

Überlegungen zur Modellierung von Bibliotheksdienstleistungen

13. März 2013 um 12:44 1 Kommentar

P.S: Mit Beschränkung auf Bibliotheksdienstleistungen, die sich auf Dokumente beziehen, habe ich inzwischen mit der Spezifikation einer Document Service Ontology begonnen.

Im Rahmen der Entwicklung der Patrons Account Information API (PAIA) und der Document Availability Information API (DAIA) bin ich wiederholt auf die Frage gestoßen, was für Arten von Dienstleistungen Bibliotheken eigentlich anbieten. Auf meine Frage bei Libraries.StackExchange antwortete Adrian Pohl, der sich in seiner Masterarbeit für lobid.org mit dem Thema beschäftigt hat.

Meine Fragestellung ist natürlich einseitig und zwar ausgerichtet auf die mögliche Verwendung in APIs, mit denen Nutzer und Programme verschiedene Bibliotheksdienstleistungen abrufen oder anfordern können sollen. Das bekannteste Beispiel ist die Dienstleistung der Ausleihe. PAIA und DAIA wurden primär dafür entworfen, damit Dienste wie die Ausleihe von Büchern aus Bibliotheken offen und maschinenlesbar möglich ist. Offen heisst, dass praktisch jeder oder zumindest alle Bibliotheksnutzer direkt per gut dokumentierter API auf die Dienste zugreifen können statt nur über bestimmte Benutzeroberflächen.

Dieser Blogartikel ist erst einmal ein lautes Denken, bei dem ich Adrians Klassifikation auf Eignung für meine Fragestellung untersuche. Wie jede Klassifikation sind sowohl die von Adrian bereitgestellte Liste als auch meine Kommentare also nicht neutral sondern nur eine mögliche Sichtweise.

1. Webbased services without direct personnel involvement:

  • OPAC and other research services
  • List of recent acquisitions
  • Online Tutorials
  • Place an order
  • Renewal of a loan
  • Online acquisition request service
  • Digitization Service
  • Consulting Service

Ein Katalog ist keine Dienstleistung die angefordert oder reserviert werden müsste, ebenso sieht es für andere Informationen auf der Webseite der Bibliothek aus. Die Punkte “place an order” und “renewal of a loan” gehören zur Dienstleistung Ausleihe (bzw. Ansicht bei Präsenzexemplaren). Zu klären ist noch, wie sich Anschaffungsvorschläge einordnen lassen. Die Digitalisierung von Bibliotheksbeständen (z.B. DigiWunschbuch ist vermutlich eine eigene Dienstleistung, die zu den bestehenden DAIA-Services hinzukommen könnte. Wieso “Consulting Service” hier eingeordnet ist, verstehe ich nicht.

2. Webbased services with direct personnel involvement:

  • Chat reference/consulting

Ist ein Chat eine Dienstleistung? Wie sieht es mit anderen Kommunikationswegen (Telefon, Gespräch vor Ort…) aus)? Ich würde das alles unter Auskunft zusammenfassen.

3. In-house services with direct personnel involvement

  • In-house guided tours and courses
  • Digitization Service
  • Microfiche readers
  • Reference Desk
  • Loan Desk
  • Registration Desk
  • Consulting Service
  • 3D printer
  • Makerspace

Schulungen und Führungen sind sicher eine eigene Art von Dienstleistung, allerdings gibt es hier verschiedene Arten. Ausleihtheke und Anmeldung sind keine eigene Dienstleistung sondern Teil anderer Services. Bei den Arbeitsmitteln wie Mirofiche-Leser, 3D-Drucker etc. kommt es darauf an, ob diese direkt nutzbar sind oder reserviert werden müssen und ob sie nur vor Ort nutzbar oder auch ausleihbar sind.

4. In-house services without direct personnel involvement

  • Reading Room
  • Study room
  • Wifi
  • Computers with Internet Access
  • Photocopier
  • Scanner for use by visitors
  • 3D printer
  • Computer for self-loan
  • Cafeteria
  • Drinks machine

Arbeitsräume und Arbeitsplätze, Kopierer, Scanner, Kaffeeautomat etc. gehören zu den oben genannten Arbeitsmitteln. Ich denke dass sich DAIA einfach erweitern lässt, so dass Nutzer per API abrufen können, ob ein Arbeitsmittel frei ist und PAIA erweitern lässt, so dass Nutzer Arbeitsmittel per API reservieren können.

Powered by WordPress with Theme based on Pool theme and Silk Icons.
Entries and comments feeds. Valid XHTML and CSS. ^Top^