Jakoblog — Das Weblog von Jakob Voß

Führt das Ende der Alleinverdiener-Ehe zu mehr Ungleichheit?

Die wöchentliche Blogschau der Mädchenmannschaft verweist auf einen Artikel von Antje Schrupp. Sie berichtet darüber, dass das Ende der Alleinverdiener-Ehe zu mehr materieller Ungleichheit führt. Als Beleg führt Dr. Schrupp Nancy Fraser und einen Artikel von Spiegel Online an. SPON berichtet von einer Studie des Instituts der deutschen Wirtschaft (IW), welche inzwischen auch hier als PDF vorliegt. Demnach ist das „traditionelle Familienbild, in dem der Mann alleine für das Einkommen sorgt, […] ein Auslaufmodell“ und „immer häufiger gesellen sich Geringverdiener und Gutverdiener mit Partnern, die ähnliche Einkommen haben“ (Zitat SPON).

Soweit, so unüberraschend. Sowohl SPON als auch Schrupp machen allerdings in der Kombination der genannten Trends eine Ursache dafür aus, dass die „Kluft zwischen Arm und Reich“ zunimmt: Während es früher mehr Haushalte gab, bei denen ein Vielverdiener und ein Wenig- oder Garnichtverdiener (letzter in der Regel weiblich) zusammenkamen, gibt es heute mehr Paare bei denen beide viel oder beide wenig verdienen. Abgesehen von der monokausalen Darstellung bei SPON kann ich zumindest das Phänomen nachvollziehen: Unter dem Strich gibt es mehr ärmere Haushalte und mehr reichere Haushalte als noch zu Zeiten der Alleinverdiener-Ehe, was sich in der Studie an einem Anstiegt des Gini-Koeffizienten ablesen lässt.

Überraschend finde ich allerdings, dass Antje diesen Sachverhalt aufgreift und hofft, das die Studie „hoffentlich zu weiterführenden Diskussionen [führt]“. Mittlerweile gibt es in ihrem Blog auch schon über 50 Kommentare mit Verweisen auf ähnliche Studien. Bisher hat aber niemand in der Diskussion die Begriffe „Hauptwiderspruch“ und „Nebenwiderspruch“ angeführt. Das Konzept von Haupt- und Nebenwiderspruch stammt aus der Marxistischen Theorie (hier die wissenschaftlich verschwurbelte Kurzdarstellung). Soweit ich es verstanden habe, war die Idee von Haupt- und Nebenwiderspruch lange ein Totschlagargument der Linken, um Themen wie die Gleichberechtigung der Frau als nebensächlich im Vergleich zum Grundproblem Kapitalismus abzutun. Wenn nur der Kapitalismus bzw. die Ungerechtigkeit von Produktions- und Eigentumsverhältnissen abgeschafft wäre, würden sich Ungerechtigkeiten in anderen Verhältnisse ganz einfach auflösen. Irgendwann wurde das den Frauen zu blöd (bzw. einigen schon von Anfang an, wie Dr. Schrupp anhand von vier Beispielen im Rahmen ihrer Promotion zeigt). Spätestens mit dem bemerkenswerten Tomatenwurf 1968 spaltete sich die (west)deutschen Frauenbewegung von der damaligen APO ab. Aber auch innerhalb der Frauenbewegung gab und gibt es immer wieder Spaltungen, was ja garnicht so schlimm sein muss.

Schlimm finde ich nur, wenn Ungerechtigkeiten gegeneinander ausgespielt werden oder wenn ein Problem zum Haupt- und ein anderes zum daraus ergebenen Nebenwiderspruch erklärt werden. Es kann zwar vorkommen, dass die Abschaffung der einen Ungerechtigkeit (hier: Modell Alleinverdiener) zu einer Verstärkung der anderen Ungerechtigkeit (hier: Einkommensschere) führt. Daraus eine Wertigkeit oder eine Kausalität abzuleiten ist jedoch falsch. Eine Verstärkung ist keine Ursache. Deshalb ist das Ende der Alleinverdiener-Ehe für die ungerechte Verteilung der Einkommen auch völlig egal. Entweder man packt das Übel bei der Wurzel, das hieße zum Beispiel Einkommen und Kapitalismus abschaffen, oder man versucht die Wirkungen zu lindern, zum Beispiel durch Steuern auf Einkommen. Die Verbindung zwischen feministischen Errungenschaften und einem Anstieg der Armut ist jedoch eine Verschleierung eigentlicher Ursachen, selbst wenn das nicht Antje Schrupps Absicht ist.

Comics in Bibliotheken – ohne Social Cataloging?

Bevor ich das Buch aus der Fernleihe wieder zurückgeben muss, möchte ich auf die Aufsatzsammlung „Graphic Novels and Comics in Libraries and Archives“ (hrsg. von Robert G. Weiner, McFarland 2010) hinweisen. Der Schwerpunkt liegt zwar auf dem US-Amerikanischen Bibliothekssystem; grundsätzlich sei das Buch jedoch jedem empfohlen, der sich für Comics und Bibliotheken interessiert. Ein kurzes Interview mit dem Herausgeber gibt es hier. Außerdem ist mir in den letzten Monaten folgendes zum Thema untergekommen:

Matthias Harbeck hat 2008 am Institut für Bibliothekswissenschaft seine Masterarbeit „Das Massenmedium Comic als Marginalbestand im deutschen Bibliothekssystem?“ geschrieben (veröffentlicht 2009: urn:nbn:de:kobv:11-10099165). Eine Zusammenfassung erschien unter dem Titel „Comics in deutschen Bibliotheken – Ressourcen für Forschung und Fans“ letzten Dezember in Bibliothek – Forschung und Praxis DOI 10.1515/bfup.2010.044 [PDF].

Ralf Palandt hat letzten Monat im Blog der Gesellschaft für Comicforschung die drei großen Comicbibliotheken in Deutschland vorgestellt: Die Bédéthek der Arbeitsstelle für Graphische Literatur an der Universität Hamburg, das Comic-Archiv des Instituts für Jugendbuchforschung an der Goethe Universität Frankfurt a.M. und die Comic-Bibliothek Renate in Berlin.

Sowohl im Sammelband von Weiner als auch in der Arbeit von Harbeck spielt die Katalogisierung von Comics eine Rolle. Allerdings berücksichtigen beide nur die bibliothekarische Erfassung. Gerade bei der Erschließung von Comics weisen Bibliothekskataloge jedoch sowohl in der Breite als auch in der Tiefe große Lücken auf. Stattdessen gibt es einige Alternativen die aus freiwilligen Projekten stammen: Ein Beispiel ist die kollaborative Katalogisierungsplattform Grand Comic-Book Database (comics.org), deren Erschließungsregeln mich stark an die Komplexität bibliographischer Regelwerke erinnern. Selbstverständlich gibt es auch bei LibraryThing Einträge zu Comics. Einen Ersatz für die nicht existierende „Deutsche Nationalbibliographie Reihe Comics“ bietet der Deutsche Comic Guide. Leider haben die Betreiber des Comic-Guide eine etwas seltsame Rechtsauffassung was die (in Teilauszügen selbstverständlich mögliche) Weiternutzung ihrer Daten betrifft. Eine wichtige Rolle spielen auch Comic-Fachbibliographien, wie sie z.B. regelmäßig in der Literaturwissenschaftlichen Comiczeitschrift Reddition veröffentlicht werden. Wie praktisch alle Comic-Fachzeitschriften ist Reddition allerdings in deutschen Bibliotheken leider nur selten zu finden, von einer strukturierten digitalen Erfassung der darin aufgeführten Comics ganz zu schweigen.

Insgesamt hat sich die Lage von Comics in Bibliotheken zwar in den letzten Jahren verbessert, sie führen aber noch immer eher ein Nischendasein. Wie mir meine Lieblingsfachreferentin, von der ich auch den Hinweis auf den Sammelband habe, mitteilte, wird jedoch an deutschen Hochschulen regelmäßig zu Comics gelehrt und geforscht. Dadurch sollte sich auch an Hochschulbibliotheken die Situation etwas verbessern. Für die Katalogisierung von Comics halte ich angesichts der Heterogenität von Quellen mittel- bis langfristig die Zusammenführung als Linked Open Data für vielversprechend, allerdings sind mir noch keine Initiativen in diese Richtung bekannt. Ideal wäre eine ViFa Comic (mit dauerhaften Personalmitteln) oder ein „Institut für Comicforschung“.

Zuletzt darf der Hinweis auf Unshelved nicht fehlen. Das Theme Bibliotheken im Comic wäre einen eigenen Artikel wert.

Ontologien und Ontologiesprachen definiert – ganz ohne „Semantik“

Die Artikel „Ontologie“ und „Ontologiesprache“ gehören neben dem Eintrag „Metadaten“ zu den umfangreichsten Artikeln, die ich für das Lexikon der Bibliotheks- und Informationswissenschaft (LBI) übernommen habe. Da die Artikel bis Donnerstag fertig sein müssen, hier die aktuelle Vorabversion. Die mit „↗“ gekennzeichnet Links ergeben sich aus der Auswahl anderer Einträge im LBI:

Nach meiner Definition hat Ontologie nichts mit „Semantik“ zu tun, zumindest wäre der Bezug zur Klärung wenig hilfreich. In der deutschsprachigen Wikipedia hatte ich es 2003 so eingetragen, inzwischen ist der Artikel dort etwas unverständlich und der Englischsprachige ziemlich einseitig. Aber das lässt sich ja ändern. Meine Texte stehen frei unter CC-BY-SA.

Metadaten – Versuch einer Kurzdefiniton

Obgleich ich dem Lexikon der Bibliotheks- und Informationswissenschaft (LBI) von Anfang an mit gemischten Gefühlen gegenüber stand – das Vorhaben eines gedruckten Lexikons ist anachronistisch und verspielt eine Chancen, die deutschsprachige Bibliotheks- und Informationswissenschaft als auf der Höhe der Zeit darzustellen – habe ich als Enzyklopädist inzwischen einige Artikel übernommen. Ich muss zugeben, dass die Beschränkungen des LBI auch einen gewissen Reiz haben. Vor allem ist die Länge der Artikel vorgegeben, so dass es darauf ankommt, einen Begriff in seiner Gänze auf das Wesentliche zu reduzieren. Der Begriff „Metadaten“, für den nächste Woche Abgabefrist ist, fällt mit bis zu 4.000 Zeichen in die umfangreichste Kategorie. Ich habe mit der Geschichte des Begriffs begonnen und versucht, das Wesentliche in diesem Umfang zusammenzufassen. Da sich die Bedeutung eines Begriffs erst aus seinen Relationen zu anderen Begriffen ergibt, habe ich auf möglichst viele andere, verwandte Einträgen des LBI verwiesen. Im Laufe der Diskussion vorgenommene Änderungen sind orange markiert.

Bei Google Books Ngram kann man schön den Anstieg der Verwendung des Begriffs nachvollziehen: Der deutlich zu erkennende Knick 1995 ist auf die Dublin Core Initiative zurückzuführen. Nun aber die Definition in ihrer aktuellen Form:

Über Korrekturen, Ergänzungen, Kritik und vorschläge für ein bis drei Literaturangaben würde ich mich freuen.

P.S.: Bei Mendeley habe ich eine Bibliographie mit Encyclopaedias of Library and Information Science erstellt. Im Terminosaurus Rex gibt es leider keinen Eintrag „Metadaten“.

XML Schema vs. Library APIs (OAI-PMH/SRU/unAPI…)

Much of our work at GBV library network has to do with record formats and APIs. We harvest or get metadata records in a wide range of formats (with many different interpretations and misconstructions of these formats), convert records to a wide range of formats (with many special request how to interpret this formats), and provide records through various APIs. Some of these APIs allow you to select different record formats, for instance OAI-PMH (first published 2001), SRU (2003), and unAPI (2006). These APIs are based on HTTP for transport and XML for encoding of the records. There are also older APIs and encoding formats like Z39.50 and newer APIs like pure Linked Data and SPARQL for RDF. unAPI also supports non-XML formats, but in this article I will concentrate on XML-based formats.

The basic question (that I deal with since years) is „what exactely is a format and how do you refer to it?“. All three APIs provide a method for listing of all formats that are supported by a particular server. unAPI provides a „list of object formats“. Each format has a „name“, a „type“ (which must be an official Internet media type), and an optional documentation URL („docs“), which may refer to some human-readable documentation, or to an XML Schema (XSD) file. Here are three examples:

<format name="oai_dc" type="application/xml"
  docs="http://www.openarchives.org/OAI/2.0/oai_dc.xsd" 
/>
<format name="pubmed" type="application/xml" 
  docs="http://www.nlm.nih.gov/bsd/licensee/elements_descriptions.html"
/>
<format name="mods" type="application/xml"
  docs="http://www.loc.gov/standards/mods/" 
/>
<format name="marcxml" type="application/xml" 
  docs="http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"
/>

To avoid the uncertainty whether „docs“ references a formal schema or a plain document, there should have been a „schema“ attribute (first problem). To refer to a format in an unAPI request, you use the format’s „name“. In OAI-PMH you refer to a format by its „metadataPrefix“. You can get a list of supported formats with the ListMetadataFormats request. In addition to the „metadataPrefix“ each format has the location of an XML Schema („schema“) and an XML Namespace URI („metadataNamespace“). In theory the latter is dispensable, because each XSD document declares a namespace URI in its „targetNamespace“ attribute: Given a format with a schema that defines namespace „http://example.org/“ like this

<xs:schema targetNamespace="http://example.org/">

I would expect records in this format to use this namespace, at least for the XML root element:

<record xmlns="http://example.org/">

The OAI-PMH specification does not explicitly say that the „metadataNamespace“ must match the namespace in the schema file „schema“. What does it mean if they differ? (second problem).

In SRU a format is known as „schema“. A list of supported formats is contained in an explain request. Each schema has an optional „title“, a „name“ (used to refer to schemas in the „recordSchema“ HTTP parameter when doing a search query), an „identifier“, and an optional „location“. The „identifier“ contains an additional URI, and the „location“ contains a link to an XML Schema file or to some human-readable documentation (like the „docs“ attribute in unAPI). There is a list of known schemas at the SRU page, for instance:

Note that one name (for instance „mods“) can refer to several schemas, but one particular SRU server can only provide one particular format under this name. The additional identifier neither refers to a particular XML Schema (Third problem). The identifier may only give a hint which particular version or interpretation of a format is provided.

Does anyone really need this diverse methods to refer to formats? I found in practice you cannot rely on the claimed format anyway, unless you can automatically validate it. That’s what XML Schema can be used for. I don’t say that XML Schema is the best or only method to formally describe an XML-based format (personally I much bettter like RELAX NG), but if there is an XML Schema – shouldn’t this schema be enough to identify the format?. Is there really a need of four independent identifiers to refer to an XML-based format? In the worst case we have:

• Schema Name (e.g. mods)
• Schema Location (e.g. http://www.loc.gov/standards/mods/v3/mods-3-3.xsd)
• Schema Identifier (e.g. info:srw/schema/1/mods-v3.3)
• Schema Namespace (e.g. http://www.loc.gov/mods/v3)

This is bad design, because you cannot say which of the four is the right one and how they relate to each other. A clean solution would only have two identifiers for XML-based formats:

• The local name, which is only unique for a particular API and a particular server
• The global schema Location, which is a cool URI that resolves to an XML Schema file.

The Schema Namespace is included as „targetNamespace“ in the XML Schema, and the Schema Identifier is delusion anyway. Either you can identify a format by a formal schema (that can also be used to validate records) or you just cannot guarantee which format your records will be in. Sure you can give some hints by linking to documentations, examples, and guidelines. But adding more identifiers is a fakery of control. You are still allowed to provide more specific formats, variants, application profiles, and interpretations under different names. But these formats don’t get more clear or usable if you give them a „Schema Identifier“. Does anyone uses SRU’s Schema Identifiers anyway? I think for XML we can better live with XML Schemas that the XML namespaces can be extracted from. An application can identify a format by its schema location, by the XML namespace, and/or by other information contained in the schema. Additional pointers to human-readable documentation are great. But don’t confuse description with identification if you need to refer to a data format.

P.S. At Code4lib mailing list Rob Sanderson pointed to our discussion we had about the same topic in 2009, and one of my earlier postings on XML4Lib also deals with SRU and namespaces.

Named Entity Recognition with DBPedia

Yesterday the DBPedia team released DBPedia Spotlight, a named entity recognition service based on structured data extracted from Wikipedia. You can access the service via Web APIs or download the software as Open Source. I could not resist to feed Spotlight its own description:

DBpedia Spotlight is a tool for annotating mentions of DBpedia resources in text, providing a solution for linking unstructured information sources to the Linked Open Data cloud through DBpedia. Text annotation has the potential of enhancing a wide range of applications including search, faceted browsing and navigation. By connecting text documents with DBpedia, our system enables a range of interesting use cases. For instance, the ontology can be used as background knowledge to display complementary information on web pages or to enhance information retrieval tasks. Moreover, faceted browsing over documents and customization of web feeds based on semantics become feasible. Finally, by following links from DBpedia into other data sources, the Linked Open Data cloud is pulled closer to the Web of Documents.

Pretty cool, isn’t it? Natural Language Processing (NLP) for information extraction seems to be the next hype after Web 2.0 and Semantic Web. I don’t neglect the innovative capabilities of DBPedia Spotlight and similar tools, but you should never forget that these are just tools, which won’t automatically solve information problems, or replace all other tools. Given the example above, there is little chance that an automatic system will extract you an exact topic of the text (for instance „named entity recognition based on data extracted from Wikipedia“) because this requires much background knowledge combining domain-specific expertise with common sense. By the way: as long as both Wikipedia and NLP-software is mainly written by white males, the result of will always mirror a limited world-view.

You can compare the results of Spotlight with similar open services:

• OpenCalais
• Extractiv
• Headup Entity Extraction
• Zeemanta
• AlchemyAPI

I found little overlap between the different services. Spotlight seems to provide more results (depending on the Text) on an error rate between 10% and 30%. You could use such tools for automatic subject indexing based on abstracts and use the result at least for ranking. Unfortunately in library metadata we often have no full text or abstract to annotate. Furthermore many library entities have no DBPedia entry but catalogers create new authority records if needed. What do you think, named entity recognition and other NLP techniques can be used for in metadata land? Can we give up controlled subject indexing in libraries in favour of automatic NLP-based indexing on the one side and social tagging on the other? Or is room for all of these approaches, and how can you successfully combine them?

Linked Data/RDF/SPARQL Documentation Challenge

In a blog posting earlier in January Richard Pop descibed the difficulty to get started with Linked Data for the average programmer: „there is a new format (RDF), new query language (SPARQL) and new code libraries to learn and install (if you can find them in the first place)“. For this reason Pop created a challenge to come up with documentation for the basic steps of developing a Linked Data/RDF/SPARQL application. You can find contributions by Bill Roberts, Christopher Gutteridge, Pezholio, Gunnar Aastrand Grimnes, Tom Morris, Jeni Tennison (and here), Niklas Lindström, Felix Ostrowski, and John Goodwin. Meanwhile there are £50 prizes for solutions in PHP, Ruby, and Phython.

I have engaged in RDF since years, but mostly from a theoretical point of view. This year I started creating Linked Data applications with RDF::Trine, a powerfull programming library by Gregory Williams to handle RDF data in Perl (see more at perlrdf.org). I contributed some minor patches to further simplify usage. Next month I will write a tutorial on how to create an RDF based application in Perl. Meanwhile I work on a Perl module (limited preview) to create classifications and thesauri in SKOS/RDF.

Wikipedia, wie sie vor 10 Jahren aussah

Am 15. Januar 2001, also vor zehn Jahren, wurde die Wikipedia ins Leben gerufen. WikiPedia (so der ursprüngliche Name in CamelCase) war damals eher eine Notlösung oder ein Experiment, zu dem sich Larry Sanger und Jimbo Wales aufgrund des langsamen Fortschreitens der Nupedia entschlossen hatten. So wurde eines dieser neuartigen „Wikis“ aufgesetzt (UseModWiki), in dem jeder Internetsurfer Seiten direkt bearbeiten kann. Alle Änderungen werden dabei protokolliert und können von jedem überprüft und verbessert werden – dank dieser Offenheit und Transparenz wuchs Wikipedia zu dem, was sie heute ist.

Leider wurden jedoch in der Anfangszeit ältere Bearbeitungen nach einiger Zeit gelöscht – die allerersten Artikelversionen der Englischen Wikipedia waren deshalb für immer verloren geglaubt. Bis im Dezember Tim Starling ein altes Backup entdeckte. Mehr dazu im Wikipedia-Kurier, dem internen Mitteilungsblatt der deutschsprachigen Wikipedia.

Nun hat Kurt Jansson, Wikipedianer der ersten Stunde, ein Backup der deutschsprachigen Wikipedia vom August 2001 ausgegraben. Mit einer angepassten Version der ursprünglichen Software konnten wir die Wikipedia so wieder online stellen, wie sie damals aussah – die Bearbeitungsfunktion ist allerdings abgeschaltet. In der Versionsgeschichte fehlen nur einige wenige Bearbeitungen, die aber – wie bei der englischsprachigen Wikipedia – in einer Logdatei (500kB) erhalten geblieben sind. Die Entwicklung der Wikipedia beschreibt Logograph schön (bis auf das „Mann“) in einem Artikel der aktuellen ZEIT:

2001 ist die Wikipedia als Ruderboot mit drei Mann Besatzung und einer Flasche Limo in See gestochen, um dann in voller Fahrt zu einem riesigen Dampfer ausgebaut zu werden. Was immer gerade notwendig oder wünschenswert erschien, wurde irgendwo angeschweißt.

Nachdem die „deutsche.wikipedia.com“ (später de.wikipedia.com) am 16. März 2001 ins Leben gerufen worden war, wurden zunächst einige Artikel aus der Nupedia übernommen und ins Deutsche übersetzt. Die ersten dieser Artikel waren Vergil [W], Pylos [W], SNOBOL 4 [W], Der Plalast des Nestor in Pylos (kurz darauf gelöscht) und Polymerase-Kettenreaktion [W]. Die damals beteiligten Magnus Manske und Rainer Zenz sind noch immer in Wikipedia tätig, während sich SoniC etwas rar gemacht hat.

Da sich die Versionsgeschichte des Artikels Polymerase-Kettenreaktion als bisher älteste erhalten hat, gilt dieser Artikel oft als erster Artikel der deutschsprachigen Wikipedia. Die ersten, speziell für Wikipedia neu verfassten Artikel, wurden jedoch erst kurz danach, am 17. Mai angelegt. Lars Aronsson (ebenfalls noch immer aktiver Wikipedianer) legte drei ganz kurze Artikel zu Dänemark, Kattegatt und die Nordsee an. Heute würden solch kleinen Artikelanfänge sicher als zu wenig gelöscht. Die Versionsgeschichten sind vollständig in der aktuellen Wikipedia erhalten: ausgehend ganz vom Anfang kann durch wiederholtes Klicken auf die „Nächstjüngere Version“ nachverfolgen, wie sie innerhalb von zehn Jahren immer weiter ausgebaut und verbessert wurden.

Ich wünsche allen Lesern und Autoren viel Spaß beim Stöbern und Verbessern und freue mich schon darauf, am Samstag Abend das Jubiläum zusammen mit anderen Wikipedianern gebührend zu feiern!

Data is not meaning – but a web badge

I’m am sure that Douglas Adams and John Lloyd had a word for it: you know exactly what you mean, but not how to call it. Recently I tried to find information about : A particular kind of „web banner“, „button“, or „badge“ with specific size, border, and two parts. I finally found out, that it is a 80×15 web badge as introduced by Antipixel in 2002. A helpful description of the format is given by ZwahlenDesign, who also points to two online badge creation tools: Brilliant Button Maker and Button Maker. Note that the tools use „Button“ instead of „Badge“ to refer to the same thing.

I created a web badge to promote a simple philosophical web standard: data is not meaning* Here is the data as 177 bytes hexdump:

89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 50 00 00 00 0F 01 03 00 00 00 49 07 DA CC 00 00 00 01 73 52 47 42 00 AE CE 1C E9 00 00 00 06 50 4C 54 45 FF FF FF 00 00 00 55 C2 D3 7E 00 00 00 59 49 44 41 54 08 D7 63 F8 0F 07 0C 0D 0C 50 C0 C8 B0 FF FF FF 0F D8 99 0D 10 E6 8E CF 7D 05 2D 7E 86 42 2E 85 0C BB 73 EF 6E 7E 76 C2 73 52 4A 23 C3 EE C4 3B 06 AD 7E 95 41 21 1B C1 A2 4F 3C 3C 8D 7C 26 32 EC 78 7B 77 43 8B 9F A7 90 4B 22 B2 09 D8 AD 40 72 03 C2 65 00 CA 67 45 A7 86 69 B7 81 00 00 00 00 49 45 4E 44 AE 42 60 82

If data was meaning, that should be all to say. But data is just a stream of bits, bytes, numbers, characters, strings, nodes, triples, or sometimes even words. You have to make use of it in a meaningful way. For instance you could give the data above to a specific piece of software like your web browser. Here comes the data again:

This PNG image was the smallest I was able to create with optimized colors, LZW compression etc. There is another piece of data, that is only eight bits more (178 bytes) and looks the same as GIF image:

I could also express the monochrome badge with one bit per pixel. That makes 80×15 = 1200 bits = 150 bytes uncompressed. The meaning could be the same, but not when only looking at your browser (because this piece of software cannot handle my „ad-hoc monochrome 80×15 web badge format“).

I also created a version with color. Feel free to use and modify as you like. In this case the PNG with 198 bytes is slightly larger than the GIF with 196 bytes.

PNG:

GIF:

* I was suprised that there were only seven Google hits for this phrase, none of them with the same meaning (sic!) that I try to express by this article. The badge was inspired by this important warning sign.

P.S: Enough data philosophy, time for music. There is so much more than one and zero and one and zero and one!

Literaturempfehlungen vom 27C3

Mit dem 27C3 fand zwischen den Jahren in Berlin der jährliche Kongress des Chaos Computer Club statt. Da ich in Urlaub war, um der Kälte zu entfliehen, schaue ich mir erst jetzt nach und nach die interessanten Vorträge als Videomitschnitt an. Die offiziellen Videos sind noch nicht fertig, aber aus diversen Mitschnitten verschiedener Qualität und mit dem Programm sollten sich schon einige Perlen herauspicken lassen. Weitere Empfehlungen gibt es zum Beispiel bei Annalist – was hat euch sonst besonders gefallen?

Ich möchte hier nur auf den „Literarischen Abend“ hinweisen, der am Dienstag von Andreas Lehner und Lars abgehalten wurde. Der Vortrag fängt unter diesem Mitschnitt-Torrent bei etwa 18 Minuten an. Im Grunde haben die beiden in einer Stunde nicht mehr und nicht weniger getan, als Empfehlungen für gute Science Fiction Literatur auszusprechen. Leider habe ich den Vortrag nicht gesehen, bevor ich mit Stephen Baxters Vakuum Diagrammen in den Urlaub gefahren bin (war nicht schlecht, aber auch nicht wirklich gut). Zu Weihnachten gab es zum Glück Snow Crash von Neal Stephenson, der auch auf der Empfehlungsliste ist. Im Kongress-Wiki können weitere Titel und Autoren hinzugefügt werden. Am Liebsten würde ich jetzt das Jahr 2011 verbringen, indem ich mich einmal durch die Liste lese 🙂