One Pager: Webseiten-Konzentrat für Bibliotheken

One Pager ist ein minimalistisches, nutzerzentriertes Konzept für Bibliothekswebseiten. Grundprinzipien sind:

  • Designing for Mobile First
  • Saving the Time of the Reader
  • Librarians are Busy
  • Writing is Important
  • Clarity through Simplicity

Die Idee, primär für mobile Geräte zu entwickeln zahlt sich aus, da man sich dann zwangsläufig auf das Wesentliche konzentriert. Insgesamt gilt: weniger ist mehr!

Bislang ist der One Pager anscheinend noch nicht für CMS umgesetzt worden. Wer in näherer Zukunft eine neue Bibliothekswebseite plant, sollte sich das Konzept inkl. Screenshots auf jeden Fall näher ansehen.

One Pager ist in Github unter CC-BY-NC-SA veröffentlicht.

10 Bücher über Bibliotheks-Technologie (und mehr)

Das Tech Set ist eine Kollektion von 10 Büchern, die die neuesten (technologischen) Entwicklungen im BID-Bereich abdecken. Aus dem LITA-Blog:

The Tech Set includes ten printed books, ten wikis, and ten podcasts by the following authors:
Marshall Breeding (Next-Gen Library Catalogs)
Sarah Houghton-Jan (Technology Training in Libraries)
Jason Griffey (Mobile Technology and Libraries)
Lauren Pressley (Wikis for Libraries)
Robin M. Hastings (Microblogging and Lifestream in Libraries)
Cliff Landis (A Social Networking Primer for Librarians)
Steve Lawson (Library Camps and Unconferences)
Kelly Nicole Czarnecki (Gaming in Libraries)
Connie Crosby (Effective Blogging for Libraries)
Thomas Sean Casserley Robinson (Library Videos and Webcasts)

Was mich zu der Frage bringt, ob Blogstöckchen schon so sehr außer Mode sind, dass man eine Vintage-Retro-Renaissance-Auflage mit der Frage starten kann, welche drei Bücher der letzten fünf Jahre für den LIS-Bereich persönlich am besten/wichtigsten gefunden wurden. Kann man?

500.000 Bücher und Handschriften online

Die Bayerische Staatsbibliothek ist der größte deutsche Datenlieferant für „EUROPEANA“

Seit Anfang März bietet die Bayerische Staatsbibliothek mehr als eine halbe Million digitalisierter Bücher im Internet über ihren Online-Katalog OPACplus und ihre Digitalen Sammlungen an. Damit präsentiert die Bibliothek den größten Bestand digitalisierter Bücher im deutschen Sprachraum.

[via juraforum.de]

HSU-Bibliothek katalogisiert Youtube-Videos

Im Bibliothekskatalog der Helmut-Schmidt-Universität sind 36 Youtube-Videos katalogisiert, alle mit Bezug zum Namensgeber. Eine kurze Stichprobe in verschiedenen Verbundkatalogen ergab zwar Unmengen an Literatur über Youtube, aber keine weiteren Youtube-Videos.

Zwei Beispiele:

  1. Loki und Helmut Schmidt – Ihr letztes gemeinsames TV-Interview
  2. Global Power and Order : Zwiegespräch zwischen Henry Kissinger und Helmut Schmidt zum Thema „Global Power and Order“ ; 13.3.2009 / Helmut Schmidt, Henry Kissinger

Blogs als Quellen in der bibliothekarischen Fachkommunikation

Peter Mayr schlägt vor, Blogs als Quellen in der bibliothekarischen Fachkommunikation systematisch zu untersuchen. Er hat dies schon einmal anhand neuerer Publikationen aus den „Berliner Handreichungen“ und E-LIS durchexerziert und kommt zu folgendem Fazit:

Natürlich kann diese Untersuchung nur ein Schlaglicht auf die Quellenlage bibliothekarischer Fachkommunikation werfen, die verwendeten Stichproben sind natürlich relativ willkürlich gewählt und weit entfernt von jeder statistischen Signifikanz.

Trotzdem lässt sich festellen, dass Weblogs und konventionelle Publikationen im Bibliothekswesen nicht in getrennten Sphären existieren, sondern gegenseitig wahrgenommen werden.

Blogs kommt dabei die Funktion zu, neue Themen schnell aufzugreifen und breit zu diskutieren.

Interessant wäre eine breitere Untersuchung. Blogzitationen lassen sich durch einfache Heuristiken (z.B.: „’wordpress’ als URL-Bestandteil“, „Datumsangabe im Format ‘YYYY/MM/DD’ in der URL“) hinreichend genau erkennen und damit wird eine automatisierte Analyse von Literaturangaben möglich.

Zustimmen kann ich seinem Vorschlag, dass dieses Phänomen genauer untersucht werden müsste. Nicht zustimmen kann ich der Feststellung,

dass Weblogs und konventionelle Publikationen im Bibliothekswesen nicht in getrennten Sphären existieren, sondern gegenseitig wahrgenommen werden.

Meine Gegenthese: wer für die Handreichungen schreibt oder seine Publikationen sogar in E-LIS einstellt, ist mindestens zur Hälfte im Web angekommen. Die meisten Autoren im Bibliotheksdienst und BIT „Online“ werden E-LIS nicht nutzen. Spannender als eine Untersuchung der online zur Verfügung stehenden Arbeiten wäre also die der tatsächlichen Printpublikationen. Ich vermute, dass die Quote der zitierten Blogs dort drastisch geringer ist.

FigShare: Abbildungen und Daten teilen

Originalbeitrag CC-BY aus dem FigShare-Blog:

Google doesn’t work as well for finding science as it does for finding pizza, and that’s a shame. John Wilbanks.

We aim to change this. Today sees the release of FigShare alpha to the world!




What is it?

We are a scientific figure/data sharing platform for researchers around the world. Our aim is to get all researchers to:



Why?

Scientific publishing as it stands is an inefficient way to do science on a global scale. A lot of time and money is being wasted by groups around the world duplicating research that has already been carried out. We are a data sharing platform where you can add figures that would otherwise go unpublished – complete with the raw data tables. In doing this, other researchers will not duplicate the work, but instead may publish with your previously wasted figure. Thus making research more efficient and releasing hidden, raw data.



How?

FigShare allows you to share all of your data, negative results and unpublished figures. FigShare also allows you to tag your data, making it more searchable and allows you to search all other data.

Either using the search and upload boxes on the homepage:

By browsing the categories in the sidebar on the right (most need filling). Or by going directly to the database main page and searching and uploading from there.

So what do these uploaded figures look like?



What we are looking for right now?



Testers: We are asking that you upload 5 of your unpublished figures, and invite 5 of your colleagues to do the same. Any problems you come accross, let us know here.





What needs doing?

Assess the functionality/ease of use: If this sounds a bit confusing to you. Please try it. We will not be mad if you wreck the place, we want you to. If you get stuck or confused at any stage, let us know here. Suggest changes. What don’t you like?

Populate the databases, not just with the figures but with tags. Once somebody has added an individual ‘tag’ or ‘author’, nobody else will ever have to do this. Look at the tags you added to your figures. Are any of them red? If so, go to the ‘tag form’ and create the tag, usually with the description, “Figures tagged with “. For more details on how to do this, see instructions here.

Have you added multiple authors to a figure? Are any of them red? If so, go to the ‘authors form’ and add their details, saving time and immediately creating a page of all the figures that have been authored by said author. For more details on how to do this, see instructions here.

Why it’s so cool!

The databases are built on a semantic mediawiki platform. This means that the databases will:

Allow others to find your data and prevent other groups from repeating experiments.

You can update your data. Have you repeated an experiment, which you cannot publish again? Every figure you upload, you can edit. This isnt just for adding data. If you mess up, you can fix it. If you need to delete something, or even un-delete it, you can!

The site automatically remembers your details, and everyone elses. So once a piece of linking information has been added once. eg. a name, address, or tag. The database remembers it and autocompletes the upload form for you. So when you’ve uploaded your first figure, everything gets a lot quicker!

The data links to other data. In order to do science efficiently, we need to make use of the tools that exist already. To quote…we have better tools for linking our photos right now than we have for our data.

Allows people to provide the RAW DATA. Why do we not get this in journals?



Future Possibilities:

If the science community begins using the platform, the potential for linking data is huge. When we say share all of your data, we don’t just mean the negative and unpublished data – We mean all of your data.

As demonstrated very elegantly by Mendeley (a great bit of software that allows you to upload all of your publications and share them with the world, thus giving all scientists and researchers around the globe access to science). As stated above “why do we not publish RAW DATA?“. A second database for published data will be set up once all the tweaks and bugs are ironed out of the system.

Why would you re-publish your data?

How hard is it to find a specific figure hidden away in a journal? How hard is it to find 10 figures on the same subject from different papers? By uploading all of your previously published figures, this data can be found by searching for a few keywords, or ‘tags’.

This will not take long. If you have published the figures, they are ready to go, no preparation needed. Just throw in the raw data.

Exporting data in an RDF format. This is how data would be published if it scientific publishing were invented today. This is not something you need to worry about as a researcher, just be safe in the knowledge that we can make your data go a lot further.




If you have any thoughts, comments or would like to get involved. Please contact us via the links in the ‘contact us’ section on the right.

I will also be attending #scio11 so if you would like to discuss FigShare in person, just come and find me!

Google DataWiki

Google legt momentan ein flottes Tempo vor. Über den nGram Viewer wurde inzwischen anderswo so viel geschrieben, das spare ich mir erstmal. Auf Shared Spaces wurde hier noch gar nicht eingegangen. Aber DataWiki kann man hier nicht unerwähnt lassen. Es handelt sich hierbei um ein Wiki für strukturierte Daten. In eigenen Worten

With DataWiki it should be easy to:

* create and edit structured data
* create simple mashup applications in a few minutes
* define formats in terms of others, e.g. Missing Person reports = vCard (who) + GeoRSS (last seen) + string (current status note)
* share information with other systems via built-in federation
* enable easy input/output from a variety of endpoints, e.g. via Twitter, ODK or SMS from a remote location

Es gibt ein Gästebuch, an dem man ein wenig probieren kann. Einträge erstellen und suchen (z.B. nach Hans Dampf) kann man auch hier:

Finden Erstellen
Name:
Comment:
Gender:
Country:
Homepage:


Name:
Comment:
Gender:
Country:
Homepage:

Eine kleine Dokumentation gibt es auch, ebenso die Möglichkeit, DataWiki (Open Source) selbst zu installieren. Man kann seine Daten also in der Cloud lagern, muss aber nicht.

Wer sehen möchte, was in Googles Laboren noch alles entwickelt wurde und wird, sollte sich diesen kurzen Überblick ansehen.

Wer traut der Cloud?

Gartner hat Cloud Computing zu einer der Strategic Technologies for 2011 erklärt. In Wikipedia ist Cloud Computing folgendermaßen zusammengefasst:

Ein Teil der IT-Landschaft (in diesem Zusammenhang etwa Hardware wie Rechenzentrum, Datenspeicher sowie Software wie Mail- oder Kollaborationssoftware, Entwicklungsumgebungen, aber auch Spezialsoftware wie Customer-Relationship-Management (CRM) oder Business-Intelligence (BI)) wird durch den Anwender nicht mehr selbst betrieben oder bereitgestellt, sondern von einem oder mehreren Anbietern als Dienst gemietet. Die Anwendungen und Daten befinden sich dann nicht mehr auf dem lokalen Rechner oder im Firmenrechenzentrum, sondern in der (metaphorischen) Wolke (engl. „cloud“). Das Bild der Wolke wird in Netzwerkdiagrammen häufig zur Darstellung eines nicht näher spezifizierten Teils des Internet verwendet.

Es geht als darum, Ressourcen zu sparen. Klingt attraktiv, doch kann man der Cloud wirklich trauen? Zwei Fälle in der jüngsten Vergangenheit sollten mindestens misstrauisch machen.

Yahoo vs. Delicious.com

Yahoo will Delicious verkaufen. Zumindest nicht mehr schließen, wie es kurze Zeit hieß. Auch wenn sich die erste Aufregung schon wieder ein wenig gelegt hat, steht fest, dass Delicious und ähnliche, in der Cloud gelagerten Dienste nicht Teil einer kritischen Infrastruktur sein dürfen. Wenn die Linksammlung einer Bibliothek kurze Zeit ausfällt, bis sie zu einem anderen Dienst übertragen ist, wäre das nur ärgerlich. Es sind jedoch auch Szenarien denkbar, in denen ein Dienst wie Delicious eine für den Fortgang einer Bibliothek oder eines Forschungsprojekts wesentlichere Funktion einnimmt.

Wikileaks vs. Amazon

Man mag von den Cablegate-Veröffentlichungen halten, was man will. Fakt ist, dass bislang niemand für die Veröffentlichung der Depeschen verklagt oder gar verurteilt wurde. Dennoch hat sich Amazon, wo Wikileaks bislang in der EC2-Cloud gehostet wurde, dazu entschieden, Wikileaks auszusperren. Dies ist ein Vorgehen von nicht zu unterschätzender Relevanz. Wenn zum Beispiel eine Bibliothek ein Online-Archiv in der Cloud errichten möchte, kann sie es auf keinen Fall dem Cloud-Provider überlassen, welche Inhalte sie dort publizieren darf und welche nicht.

Wichtig: Risikoabschätzung

Das Thema „Cloud Computing“ ist nicht nur ein Modethema, es ist jetzt schon Alltag. Man denke nur an Google Docs oder die Dropbox. Wenn Cloud-Dienste in Anspruch genommen werden sollen, ist es unbedingt notwendig, die möglichen Risiken abzuschätzen. Hilfreich kann dabei die Broschüre zum Cloud Computing Risk Assessment der European Network and Information Security Agency sein. Dort werden verschiedene Risikofaktoren unterteilt in drei Felder (Technical risks, policy and organizational risks und legal risks) identifiziert und erörtert. Auch der NYT-Artikel „Lost in the Cloud“ von Jonathan Zittrain gibt Hinweise auf weitere mögliche Risiken zum Beispiel für den Datenschutz.

PS: Wer noch keine Dropbox hat und mir einen Gefallen tun möchte, kann sich über diesen Link dort anmelden. Durch die Anmeldung bekomme ich eine Prämie in Form von mehr Speicherplatz.