Jakoblog — Das Weblog von Jakob Voß

Wikidata documentation on the 2017 Hackathon in Vienna

At Wikimedia Hackathon 2017, a couple of volunteers sat together to work on the help pages of Wikidata. As part of that Wikidata documentation sprint. Ziko and me took a look at the Wikidata glossary. We identified several shortcomings and made a list of rules how the glossary should look like. The result are the glossary guidelines. Where the old glossary partly replicated Wikidata:Introduction, the new version aims to allow quick lookup of concepts. We already rewrote some entries of the glossary according to these guidelines but several entries are outdated and need to be improved still. We changed the structure of the glossary into a sortable table so it can be displayed as alphabetical list in all languages. The entries can still be translated with the translation system (it took some time to get familiar with this feature).

We also created some missing help pages such as Help:Wikimedia and Help:Wikibase to explain general concepts with regard to Wikidata. Some of these concepts are already explained elsewhere but Wikidata needs at least short introductions especially written for Wikidata users.

Image taken by Andrew Lih (CC-BY-SA)

Introduction to Phabricator at Wikimedia Hackathon

This weekend I participate at Wikimedia Hackathon in Vienna. I mostly contribute to Wikidata related events and practice the phrase "long time no see", but I also look into some introductionary talks.

In the late afternoon of day one I attended an introduction to Phabricator project management tool given by André Klapper. Phabricator was introduced in Wikimedia Foundation about three years ago to replace and unify Bugzilla and several other management tools.

Phabricator is much more than an issue tracker for software projects (although it is mainly used for this purpose by Wikimedia developers). In summary there are tasks, projects, and teams. Tasks can be tagged, assigned, followed,discussed, and organized with milestones and workboards. The latter are Kanban-boards like those I know from Trello, waffle, and GitHub project boards.

Phabricator is Open Source so you can self-host it and add your own user management without having to pay for each new user and feature (I am looking at you, JIRA). Internally I would like to use Phabricator but for fully open projects I don’t see enough benefit compared to using GitHub.

P.S.: Wikimedia Hackathon is also organized with Phabricator. There is also a task for blogging about the event.

Some thoughts on IIIF and Metadata

Yesterday at DINI AG Kim Workshop 2017 I Martin Baumgartner and Stefanie Rühle gave an introduction to the International Image Interoperability Framework (IIIF) with focus on metadata. I already knew that IIIF is a great technology for providing access to (especially large) images but I had not have a detailed look yet. The main part of IIIF is its Image API and I hope that all major media repositories (I am looking at you, Wikimedia Commons) will implement it. In addition the IIIF community has defined a „Presentation API“, a „Search API“, and an „Authentication API“. I understand the need of such additional APIs within the IIIF community, but I doubt that solving the underlying problems with their own standards (instead of reusing existing standards) is the right way to go. Standards should better „Do One Thing and Do It Well“ (Unix philosophy). If Images are the „One Thing“ of IIIF, then Search and Authentication are different matter.

In the workshop we only looked at parts of the Presentation API to see where metadata (creator, dates, places, provenance etc. and structural metadata such as lists and hierarchies) could be integrated into IIIF. Such metadata is already expressed in many other formats such as METS/MODS and TEI so the question is not whether to use IIIF or other metadata standards but how to connect IIIF with existing metadata standards. A quick look at the Presentation API surprised me to find out that the metadata element is explicitly not intended for additional metadata but only „to be displayed to the user“. The element contains an ordered list of key-value pairs that „might be used to convey the author of the work, information about its creation, a brief physical description, or ownership information, amongst other use cases“. At the same time the standard emphasizes that „there are no semantics conveyed by this information“. Hello, McFly? Without semantics conveyed it isn’t information! In particular there is no such thing as structured data (e.g. a list of key-value pairs) without semantics.

I think the design of field metadata in IIIF is based on a common misconception about the nature of (meta)data, which I already wrote about elsewhere (Sorry, German article – some background in my PhD and found by Ballsun-Stanton).

In a short discussion at Twitter Rob Sanderson (Getty) pointed out that the data format of IIIF Presentation API to describe intellectual works (called a manifest) is expressed in JSON-LD, so it can be extended by other RDF statements. For instance the field „license“ is already defined with dcterms:rights. Addition of a field „author“ for dcterms:creator only requires to define this field in the JSON-LD @context of a manifest. After some experimenting I found a possible way to connect the „meaningless“ metadata field with JSON-LD fields:

{
  "@context": [
    "http://iiif.io/api/presentation/2/context.json",
    { 
      "author": "http://purl.org/dc/terms/creator",
      "bibo": "http://purl.org/ontology/bibo/"
    }
  ],
  "@id": "http://example.org/iiif/book1/manifest",
  "@type": ["sc:Manifest", "bibo:book"],
  "metadata": [
    {
      "label": "Author",
      "property": "http://purl.org/dc/terms/creator",
      "value": "Allen Smithee"
    },
    { 
      "label": "License",
      "property": "http://purl.org/dc/terms/license",      
      "value": "CC-BY 4.0" 
    }
   ],
   "license": "http://creativecommons.org/licenses/by/4.0/",
   "author": {
     "@id": "http://www.wikidata.org/entity/Q734916",
     "label": "Allen Smithee"
   }
}

This solution requires an additional element property in the IIIF specification to connect a metadata field with its meaning. IIIF applications could then enrich the display of metadata fields for instance with links or additional translations. In JSON-LD some names such as „CC-BY 4.0“ and „Allen Smithee“ need to be given twice, but this is ok because normal names (in contrast to field names such as „Author“ and „License“) don’t have semantics.

Ersatzteile aus dem 3D-Drucker

Krach, Zack, Bumm! Da liegt die Jalousie unten. Ein kleinen Plastikteil ist abgebrochen, das wäre doch ein prima Anwendungsfall für einen 3D-Drucker, oder? Schön länger spiele ich mit dem Gedanken, einen 3D-Drucker anzuschaffen, kann aber nicht so recht sagen, wozu eigentlich. Die Herstellung von Ersatzteilen aus dem 3D-Drucker scheint mir allerdings eher so ein Versprechen zu sein wie der intelligente Kühlschrank: theoretisch ganz toll aber nicht wirklich praktisch. Es würde mich vermutlich Stunden kosten, das passende Teil auf diversen Plattformen wie Thingiverse zu finden oder es mit CAD selber zu konstruieren.

Ohne verlässliche 3D-Modelle bringt also der beste 3D-Drucker nichts, deshalb sind die Geräte auch nur ein Teil der Lösung zur Herstellung von Ersatzteilen. Ich bezweifle sehr dass in naher Zukunft Hersteller 3D-Modelle ihrer Produkte zum Download anbieten werden, es sei denn es handelt sich um Open Hardware. Abgesehen von elektronischen Bastelprojekten ist das Angebot von Open-Hardware-Produkten für den Hausgebrauch aber noch sehr überschaubar. Dennoch denke ich, dass Open Hardware, das heisst Produkte deren Baupläne frei lizensiert zur kostenlosen Verfügung stehen, sowie standardisierte Bauteile das einzig Richtige für den Einsatz von 3D-Druckern im Hausgebrauch sind.

Ich werde das Problem mit der kaputten Jalousie erstmal mit analoger Technik angehen und schauen, was ich so an passenden Materialien und Werkzeugen herumliegen habe. Vielleicht hilft ja Gaffer Tape?

Einfachste Projekthomepage bei GitHub

Die einfachste Form einer Projekthomepage bei GitHub pages besteht aus einer Startseite, die lediglich auf das Repository verweist. Lokal lässt sich eine solche Seite so angelegen:

1. Erstellung des neuen, leeren branch gh-pages:

git checkout --orphan gh-pages
git rm -rf .

2. Anlegen der Datei index.md mit folgendem Inhalt:

---
---
# {{site.github.project_title}}
[{{site.github.repository_url}}]({{site.github.repository_url}}#readme).

3. Hinzufügen der Datei und push nach GitHub

git add index.md
git commit -m "homepage"
git push origin gh-pages

Abbreviated URIs with rdfns

Working with RDF and URIs can be annoying because URIs such as „http://purl.org/dc/elements/1.1/title“ are long and difficult to remember and type. Most RDF serializations make use of namespace prefixes to abbreviate URIs, for instance „dc“ is frequently used to abbreviate „http://purl.org/dc/elements/1.1/“ so „http://purl.org/dc/elements/1.1/title“ can be written as qualified name „dc:title„. This simplifies working with URIs, but someone still has to remember mappings between prefixes and namespaces. Luckily there is a registry of common mappings at prefix.cc.

A few years ago I created the simple command line tool rdfns and a Perl library to look up URI namespace/prefix mappings. Meanwhile the program is also available as Debian and Ubuntu package librdf-ns-perl. The newest version (not included in Debian yet) also supports reverse lookup to abbreviate an URI to a qualified name. Features of rdfns include:

look up namespaces (as RDF/Turtle, RDF/XML, SPARQL…)

$ rdfns foaf.ttl foaf.xmlns dbpedia.sparql foaf.json

@prefix foaf:  .
xmlns:foaf="http://xmlns.com/foaf/0.1/"
PREFIX dbpedia: 
"foaf": "http://xmlns.com/foaf/0.1/"

expand a qualified name

$ rdfns dc:title

http://purl.org/dc/elements/1.1/title

lookup a preferred prefix

$ rdfns http://www.w3.org/2003/01/geo/wgs84_pos#

geo

create a short qualified name of an URL

$ rdfns http://purl.org/dc/elements/1.1/title

dc:title

I use RDF-NS for all RDF processing to improve readability and to avoid typing long URIs. For instance Catmandu::RDF can be used to parse RDF into a very concise data structure:

$ catmandu convert RDF --file rdfdata.ttl to YAML

Das Wissen der Welt

Denny Vrandečić, einer der Köpfe hinter Semantic MediaWiki und Wikidata, hat eine clevere Metrik vorgeschlagen um den Erfolg der Wikimedia-Projekte zu messen. Die Tätigkeit und damit das Ziel der Wikimedia-Foundation wurde 2004 von Jimbo Wales so ausgedrückt:

Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That’s what we’re doing.

In Wikiquote wird dieser bekannte Ausspruch momentan folgendermaßen übersetzt: „Stell dir eine Welt vor, in der jeder Mensch auf der Erde freien Zugang zum gesamten menschlichem Wissen hat. Das ist, was wir machen.“ Wie lässt sich nun aber quantifizieren, zu welchem Grad das Ziel erreicht ist? So wie ich es verstanden (und in meine Worte übersetzt) habe, schlägt Denny Folgendes vor:

Für jedem Menschen auf der Welt gibt es theoretisch eine Zahl zwischen Null und Eins, die angibt wieviel vom gesamten Wissens der Welt („the sum of all human knowledge“) diesem Menschen durch Wikimedia-Inhalte zugänglich ist. Der Wert lässt sich als Prozentzahl des zugänglichen Weltwissens interpretieren – da sich Wissen aber kaum so einfach messen und vergleichen lässt, ist diese Interpretation problematisch.

Der Wert von Eins ist utopisch, da Wikipedia & Co nicht alles Wissen der Welt enthält. Für Menschen ohne Internet-Zugang kann der Wert aber bei Null liegen. Selbst mit Zugang zu Wikipedia ist die Zahl bei jedem Menschen eine andere, da nicht alle Inhalte in allen Sprachen vorhanden sind und weil viele Inhalte ohne Vorwissen unverständlich und somit praktisch nicht zugänglich sind.

Die Zahlen der individuellen Zugänglichkeit des Weltwissens lassen sich nun geordnet in ein Diagram eintragen, das von links (maximales Wissen) nach rechts (kein Wissen durch zugänglich) alle Menschen aufführt. Wie Denny an folgendem Bild ausführt, kann die Wikimedia-Community ihrem Weg auf verschiedenen Wegen näher kommen:

(1) Der Ausbau von vielen Artikeln in einem komplexen Spezialgebiet oder einer kleinen Sprache kommt nur wenigen Menschen zu gute.

(2) Stattdessen könnten auch die wichtigsten Artikel bzw. Themen in Sprachen verbessert und ergänzt werden, welche von vielen Menschen verstanden werden.

(3) Schließlich kann Wikimedia auch dafür sorgen, dass mehr Menschen einen Zugang zu den Wikimedia-Ihren Inhalten bekommen – zum Beispiel durch Initiativen wie Wikipedia Zero

Ich halte die von Denny vorgeschlagene Darstellung für hilfreich um über das einfache Zählen von Wikipedia-Artikeln hinauszukommen. Wie er allerdings selber zugibt, gibt es zahlreiche offene Fragen da sich die tatsächlichen Zahlen der Verfügbarkeit von Wissen nicht einfach ermitteln lassen. Meiner Meinung nach liegt ein Grundproblem darin, dass sich Wissen – und vor allem das gesamte Wissen der Menschheit – nicht quantifizieren lässt. Es ist auch irreführend davon auszugehen, dass die Wikimedia-Produkte Wissen sammeln oder enthalten. Möglicherweise ist dieser Irrtum für die Metrik egal, nicht aber für das was eigentlich gemessen werden soll (Zugänglichkeit des Wissens der Welt).

Falls Wikimedia an einem unverstelltem Blick auf die Frage interessiert ist, wieviel des Wissens der Menschheit durch ihre Angebote den Menschen zugänglich gemacht wird, könnte es helfen mal einige Philosophen und Philosophinnen zu fragen. Ganz im Ernst. Mag sein (und so vermute ich mit meinem abgebrochenen Philosophie-Studium), dass am Ende lediglich deutlich wird, warum dass ganze Wikimedia-Projekt nicht zu realisieren ist; selbst Erkenntnisse über mögliche Gründe dieses Scheitern wären aber hilfreich. Vermutlich ist es aber zu verpönt, Philosophen ernsthaft um Rat zu fragen oder die verbliebenen Philosophen beschäftigen sich lieber mit anderen Fragen.

P.S: Eine weitere relevante Disziplin zur Beantwortung der Frage wieviel Wissen der Welt durch Wikipedia & Co der Menschheit zugänglich gemacht wird, ist die Pädagogik, aber da kenne ich mich noch weniger aus als mit der Philosophie.

The GitHub of…

Nachdem mich die neue Version von knowable.org enttäuscht hat (die vorige Version hatte ich vor 1,5 Jahren positiv besprochen), habe ich mal gegoogelt, welche Anwendungen so mit GitHub verglichen werden (Suche nach „The GitHub of/for“ u.Ä.):

• …physical things (knowable.org)
• …Software Translation (Trasifex)
• …Mechanical Design and CAD (GrabCAD)
• …Writers (Penflip)
• …Science (Banyan †, Authorea)
• …Data (Mode, Domino, Sense)
• …

Ich kann zumindest Penflip (eingeschränkt) empfehlen, nicht zuletzt da es wie GitHub auf dem Versionskontrollsystem git basiert so dass Inhalte so zwischen den Anwendungen ausgetauscht werden können. Für Autorea soll ähnliches gelten, das muss ich mir mal genauer ansehen. In der Regel sind Vergleiche mit GitHub aber Quatsch. Im Zweifelsfall also besser erstmal direkt das Original benutzen!

Für den Bereich „Wissenschaft“ kann ich diesem Kommentar nur zustimmen: Anwendungen zum kollaborativen wissenschaftlichen Arbeiten benötigen zunächst einmal grundlegende Standards für die Kodierung und den Austausch wissenschaftlicher Artefakte. Grundlage von Git(Hub) sind versionierte Dateisysteme mit Schwerpunkt auf zeilenbasierten Textdateien – das ist zwar eine ziemlich rudimentäre Kodierung, aber besser als gar kein einheitliches Format. Im Bereich Data Science scheint CSV der kleinste gemeinsame Nenner zu sein, eine schöne Versionierung für CSV-Daten habe ich aber noch nicht gesehen.

Open-Access im (Neuerwerbungs)regal

In den letzten Monaten hatte ich endlich wieder regelmäßig das Vergnügen eine Fachbibliothek (auch) für den Bereich Bibliotheks- und Informationswissenschaft zu besuchen. Die Bibliothek der Hochschule Hannover im Kurt-Schwitters-Forum liegt zwar etwas am A… der Welt, dafür gab es immer wieder interessante Titel im Neuerwerbungsregal und genügend Comics. Die SUB Göttingen ist dagegen sowohl in Sachen Comics als auch fachlich nicht mehr so interessant, seit das SSG Buch- und Bibliothekswesen abgegeben wurde; dazu kommt dass das meiste sowieso unsortiert im Magazin steht. Jedenfalls bietet das Neuerwerbungsregal gute Anregungen mit bibliotheks- und informationswissenschaftlichen Titeln, auf die ich sonst nicht so gestoßen worden wäre. Bei der Lektüre von Sammelbänden wie die Sonderbände der ZfBB oder verschiedener bei de Gruyter verlegten Reihen, stößt mir jedoch ziemlich schnell auf, wie unpraktisch und anarchonistisch diese Medienform ist. Wieso verstecken Autoren freiwillig ihre Artikel in einem Medium, das sich nicht einfach verlinken, durchsuchen und überhaupt erstmal finden lässt? Closed-Access-Publikationen sind in unserem Fachgebiet einfach sowas von letztes Jahrtausend und eine Schande für die Wissenschaft. Sammelbänd sind sowieso eine Unart, aber das mag Geschmackssache sein. Inzwischen erwarte ich aber nicht nur Open Access (PDF stinkt) sondern langsam mal etwas neuere Publikationsformen. Aus diesem Grund unterstützte ich auch die Neugründung der Fachzeitschrift Informationspraxis.

Dennoch haben physische Sammlungen ihre Berechtigung und ich finde ausgewählte Hinweise auf Neuerscheinungen in gedruckter Form sehr praktisch. Was spricht also dagegen, alles digital als Open Access zu veröffentlichen und parallel ausgewählte Titel in gedruckter Form auszulegen? Ich fände so ein Vorgehen eine gute bibliothekarische Dienstleistung. Vermutlich ist es aber leider eher so, dass Open Access Publikationen gar nicht erst in gedruckter Form angeschafft werden, da sie ja schon digital verfügbar sind. Kennt jemand Fälle von Bibliotheken, die anders verfahren oder sogar selber Druckversionen von empfehlenswerten digitalen Publikationen herstellen und auslegen?

Testing command line apps with App::Cmd

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.