Erster expliziter Entwurf einer Digitalen Bibliothek (1959)

18. März 2018 um 23:38 5 Kommentare

Ich recherchiere (mal wieder) zu Digitalen Bibliotheken und habe mich gefragt, wann der Begriff zum ersten mal verwendet wurde. Laut Google Books taucht (nach Aussortieren falsch-positiver Treffer) „digital library“ erstmals 1959 in einem Bericht für das US-Außenministerium auf. Die bibliographischen Daten habe ich bei Wikidata eingetragen. Der Bericht „The Need for Fundamental Research in Seismology“ wurde damals erstellt um zu Untersuchen wie mit seismischen Wellen Atomwaffentests erkannt werden können.

In Anhang 19 legte John Gerrard, einer von vierzehn an der Studie beteiligten Wissenschaftler, auf zwei Seiten den Bedarf an einem Rechenzentrum mit einem IBM 704 Rechner dar. Da das US-Regierungsdokument gemeinfrei ist hier die entsprechenden Seiten:



Bei der geplanten digitalen Bibliothek handelt es sich um eine Sammlung von Forschungsdaten mitsamt wissenschaftlicher Software um aus den Forschungsdaten neue Erkenntnisse zu gewinnen:

The following facilities should be available:

  1. A computer equivalent to the IBM 704 series, plus necessary peripheral equipment.
  2. Facilities for converting standard seismograms into digital form.
  3. A library of records of earthquakes and explosions in form suitable for machine analysis.
  4. A (growing) library of basic programs which have proven useful in investigations of seismic disturbances and related phenomena.

Klingt doch ziemlich aktuell, oder? Gefallen hat mir auch die Beschreibung des Rechenzentrums als „open shop“ und der Hinweis „nothing can dampen enthusiasm for new ideas quite as effectively as long periods of waiting time“. Die Bezeichnung „digital library“ bezieht sich in dem Text primär auf die Sammlung von digitalisierten Seimsmogrammen. Am Ende der Empfehlung wird abweichend der Begriff „digitized library“ verwendet. Dies spricht dafür dass beide Begriffe synonym verwendet wurden. Interessanterweise bezieht sich „library“ aber auch auf die Sammlung von Computerprogrammen.

Ob das empfohlene Rechenzentrum mit digitaler Bibliothek realisiert wurde konnte ich leider nicht herausfinden (vermutlich nicht). Zum Autor Dr. John Gerrard ist mir nicht viel mehr bekannt als dass er 1957 als Director of Data Systems and Earth Science Research bei Texas Instruments (TI) arbeitete. TI wurde 1930 als „Geophysical Service Incorporated“ zur seismischen Erkundung von Erdöllagerstätten gegründet und bekam 1965 den Regierungsauftrag zur Ãœberwachung von Kernwaffentests (Projekt Vela Uniform). An Gerrard erinnert sich in diesem Interview ein ehemaliger Kollege:

John Gerrard: into digital seismology, and he could see a little bit of the future of digital processing and he talked about how that could be effective in seismology, he was right that this would be important in seismology

In Birmingham gibt es einen Geologen gleichen Namens, der ist aber erst 1944 geboren. Ich vermute dass Gerrard bei TI an der Entwicklung des Texas Instruments Automatic Computer (TIAC) beteiligt war, der speziell zur digitalen Verarbeitung seismischer Daten entwickelt wurde.

Der Einsatz von Computern in klassischen Bibliotheken kam übrigens erst mit der nächsten Rechner-Generation: das MARC-Format wurde in den 1960ern mit dem IBM System/360 entwickelt (von Henriette Avram, die zuvor bei der NSA auch mit IBM 701 gearbeitet hatte). Davor gabe es den fiktiven Bibliotheks-Computer EMMARAC (angelehnt an ENIAC und UNIVAC) in „Eine Frau, die alles weiß“ mit Katharine Hepburn als Bibliothekarin und Spencer Tracy als Computervertreter.

Bis Ende der 1980er taucht der Begriff „digital library“ bei Google Books übrigens nur vereinzelt auf.

Data models age like parents

15. März 2018 um 21:51 Keine Kommentare

Denny Vrandečić, employed as ontologist at Google, noticed that all six of of six linked data applications linked to 8 years ago (IWB, Tabulator, Disko, Marbles, rdfbrowser2, and Zitgist) have disappeared or changed their calling syntax. This reminded me at a proverb about software and data:

software ages like fish, data ages like wine.

‏
The original form of this saying seems to come from James Governor (@monkchips) who in 2007 derived it from from an earlier phrase:

Hardware is like fish, operating systems are like wine.

The analogy of fishy applications and delightful data has been repeated and explained and criticized several times. I fully agree with the part about software rot but I doubt that data actually ages like wine (I’d prefer Whisky anyway). A more accurate simile may be „data ages like things you put into your crowded cellar and then forget about“.

Thinking a lot about data I found that data is less interesting than the structures and rules that shape and restrict data: data models, ontologies, schemas, forms etc. How do they age compared with software and data? I soon realized:

data models age like parents.

First they guide you, give good advise, and support you as best as they can. But at some point data begin to rebel against their models. Sooner or later parents become uncool, disconnected from current trends, outdated or even embarrassing. Eventually you have to accept their quaint peculiarities and live your own life. That’s how standards proliferate. Both ontologies and parents ultimately become weaker and need support. And in the end you have to let them go, sadly looking back.

(The analogy could further be extended, for instance data models might be frustrated confronted by how actual data compares to their ideals, but that’s another story)

in memoriam Ingetraut Dahlberg

28. Oktober 2017 um 09:24 5 Kommentare

Die Informationswissenschaftlerin Ingetraut Dahlberg, bekannt unter Anderem als Gründerin der International Society for Knowledge Organization (ISKO), ist letzte Woche im Alter von 91 Jahren verstorben. Meine erste Reaktion nach einem angemessenen Bedauern war es in Wikipedia und in Wikidata das Sterbedatum einzutragen, was jedoch schon andere erledigt hatten. Also stöberte ich etwas im Lebenslauf, und legte stattdessen Wikidata-Items zum McLuhan Institute for Digital Culture and Knowledge Organization an, dem Dahlberg schon zu Lebzeiten ihre Bibliothek vermacht hat, das aber bereits 2004 wieder geschlossen wurde. Der ehemalige Direktor Kim Veltman betreibt noch eine Webseite zum Institut und nennt in seinen Memoiren Ingetraut Dahlberg, Douglas Engelbart, Ted Nelson und Tim Berners Lee in einem Atemzug. Das sollte eigentlich Grund genug sein, mich mit der Frau zu beschäftigen.

Wenn ich ehrlich bin war mein Verhältnis zu Ingetraut Dahlberg allerdings eher ein distanziert-ignorantes. Ich wusste um ihre Bedeutung in der „Wissensorganisation-Szene“, der ich zwangsläufig auch angehöre, bin ihr aber nur ein oder zwei mal auf ISKO-Tagungen begegnet und hatte auch nie Interesse daran mich mehr mit ihr auseinanderzusetzen. Als „junger Wilder“ schien sie mir immer wie eine Person, deren Zeit schon lange vorbei ist und deren Beiträge hoffnungslos veraltet sind. Dass alte Ideen auch im Rahmen der Wissensorganisation keineswegs uninteressant und irrelevant sind, sollte mir durch die Beschäftigung mit Ted Nelson und Paul Otlet eigentlich klar sein; irgendwie habe ich aber bisher nie einen Anknüpfungspunkt zu Dahlbergs Werk gefunden.

Wenn ich zurückblicke muss der Auslöser für meine Ignoranz in meiner ersten Begegnung mit Vertreter*innen der Wissensorganisation auf einer ISKO-Tagung Anfang der 2000er Jahre liegen: Ich war damals noch frischer Student der Bibliotheks- und Informationswissenschaft mit Informatik-Hintergrund und fand überall spannende Themen wie Wikipedia, Social Tagging und Ontologien, die prinzipiell alle etwas mit Wissensorganisation zu tun hatten. Bei der ISKO fand ich dagegen nichts davon. Das Internet schien jedenfalls noch sehr weit weg. Erschreckend fand ich dabei weniger das Fehlen inhaltlicher Auseinandersetzung mit den damals neuesten Entwicklungen im Netz sondern die formale Fremdheit: mehrere der beteiligten Wissenschaftler*innen hatten nach meiner Erinnerung nicht einmal eine Email-Adresse. Menschen, die sich Anfang der 2000er Jahre ohne Email mit Information und Wissen beschäftigten konnte ich einfach nicht ernst nehmen.

So war die ISKO in meiner Ignoranz lange ein Relikt, das ähnlich wie die International Federation for Information and Documentation (FID, warum haben die sich eigentlich nicht zusammengetan?) auf tragische Weise von der technischen Entwicklung überholt wurde. Und Ingetraut Dahlberg stand für mich exemplarisch für dieses ganze Scheitern einer Zunft.

Inzwischen sehe ich es etwas differenzierter und bin froh Teil dieser kleinen aber feinen Fachcommunity zu sein (und wenn die ISKO endlich auf Open Access umstellt, werde ich auch meinen Publikations-Boycott aufgeben). In jedem Fall habe ich Ingetraut Dahlberg Unrecht getan und hoffe auf differenziertere Auseinandersetzungen mit ihrem Werk.

Wikidata documentation on the 2017 Hackathon in Vienna

21. Mai 2017 um 15:21 4 Kommentare

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

20. Mai 2017 um 09:44 1 Kommentar

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

5. Mai 2017 um 22:40 1 Kommentar

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

30. Dezember 2014 um 10:43 2 Kommentare

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

24. September 2014 um 09:57 1 Kommentar

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

9. September 2014 um 11:26 5 Kommentare

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

24. August 2014 um 22:32 4 Kommentare

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.