Craigslist setzt auf Open Street Map

Open Street Map (OSM) gewinnt einen großen Nutzer nach dem anderen. Global Player wie Apple, Foursquare oder die Bibliothek der Hochschule Hannover setzen seit einiger Zeit auf OSM, um Karten in die jeweiligen Webseiten einzubauen. Und seit kurzem nun auch Craigslist.

Craigslist ist im deutschsprachigen Raum weitgehend unbekannt. Es handelt sich aber mit laut Eigenaussage [m]ore than 50 billion page views per month eindeutig um eine Webseite, deren Entscheidung für OSM auch in der Google-Zentrale wahrgenommen wird. Google ist bekannt dafür, APIs und andere Dienste mehr oder weniger unkompliziert zu entsorgen, kostenpflichtig zu machen oder wegzusperren, wenn ein Strategiewechsel gewünscht ist. Vor diesem Hintergrund ist die Entscheidung eines langfristig planenden Unternehmens gegen Google Maps sehr verständlich.

“I think it’s another major website making a great decision,” said Steve Coast, the founder of OpenStreetMap. He told Ars that he was unaware of Craigslist’s move until being sent a link to other media coverage on Tuesday.

So heißt es auf Ars Technica.

PS: Wenn so etwas nicht bemerkt wird, ist OSMs Serverausstattung offenbar beachtlich.

Ergebnisse: Wessen Inhalte dürfen ins Institutional Repository?

Vorbemerkung: Insgesamt wurden die Fragen 37x beantwortet. Es wurde kein aufwändiger Check betrieben, ob die Umfrage mehrfach ausgefüllt wurde. Die Ergebnisse sind ohnehin in keiner Weise repräsentativ. Sie können höchstens dazu dienen, Tendenzen zu erkennen.

Weitere Infos zur Umfrage: Wessen Inhalte dürfen ins Institutional Repository?

1. “IRs zerreissen das Werk von Wissenschaftlern, die die Institutionen wechseln.” Erläuterung: Gemeint ist, dass alle Publikationen eines Autors aus dem einen oder anderen Grund nicht in einem Institutional Repository (IR) gebündelt abrufbar sind. Ein Grund könnte sein, dass nur Schriften aufgenommen werden, die zur Zeit der Institutszugehörigkeit eines Autors entstanden sind.

Antwort Anteil (%) Anzahl
Ja, dies ist bei meinem IR der Fall. 37,8% 14
Nein, dies ist bei meinem IR nicht der Fall. 62,2% 23

2. “IRs nehmen manchmal ungern die Produktion vor dem Eintritt in die Institution.” Erläuterung: Manche IRs nehmen keine Publikationen an, die vor der Zugehörigkeit zur jeweiligen Institution entstanden sind.

Antwort Anteil (%) Anzahl
Ja, dies ist bei meinem IR der Fall. 27,0% 10
Nein, dies ist bei meinem IR nicht der Fall. 73,0% 27

3. “Nach dem Ausscheiden muss sich der Wissenschaftler eine andere OA-Bleibe suchen.” Erläuterung: Gemeint ist, dass Autoren nur Publikationen im IR veröffentlichen dürfen, solange sie der jeweiligen Institution angehören. Dies können sowohl ehemalige Studierende als auch ehemalige Mitarbeiter sein.

Antwort Anteil (%) Anzahl
Ja, dies ist bei meinem IR der Fall. 62,9% 22
Nein, dies ist bei meinem IR nicht der Fall. 40,0% 14

Von welcher Einrichtung wird das IR betrieben?

Typ der Einrichtung Anteil (%) Anzahl
Fachhochschule 13,5% 5
Universität 62,2% 23
Forschungseinrichtung 24,3% 9

Dazu 2 weitere Angaben, dass es sich genau genommen um eine UB handelt.

Anmerkungen und Kommentare (Freitextfeld):
Anmerkung 1:

Anfragen von Wissenschaftlern, die die Universität gewechselt haben, ob sie weiterhin auf unserem Server publizieren dürfen, kommen so gut wie nicht vor.

Anmerkung 2:

Die Richtlinien werden zur Zeit überarbeitet. An Alumni ist leider noch nicht gedacht.

Anmerkung 3:

Es wird nicht nur das Werk zerrissen, sondern es werden in einer wissenschaftlichen Vita unzählige Dubletten erstellt, die jedes mal einen neuen Persistent Identifier bekommen. Dies könnte Probleme bei statistischen Erhebungen (Citation index) oder bei Zitierungen (dem Autor oder anderen Wissenschaftlern ist nicht klar, welchen der PI sie zitieren sollen).

Anmerkung 4:

Ein Paar Kommentare zu Grafs Mail, die ansonsten ein perfekter Diskussionsanstoss ist: – “Suchwerkzeuge wie BASE sind weitgehend unbekannt”: richtig, dafür Google und Google scholar – “Auch wenn eine Arbeit mit der Institution eindeutig in Verbindung steht (…) wird sie nicht aufgenommen”: Richtig, sonst wäre es ja kein IR. Einen Vorwurf sollte man aber nicht ZORA machen – auf deren Webseite kann die Arbeit sonst wie verlinkt werden – sondern der HTW Chur, die als I&D-Fachhochschule schon lange das gute Beispiel zeigen sollte. – “IRs parzellieren die Wissenschaft”: Mag sein, sie hat sich aber schon häufig genug selber parzelliert. Und für etwas gibt es FRs (Fachspezifische Repositories) und klassifikatorische Daten. – “ZORA kürzt den Vornamen ab, obwohl viele Disziplinen dagegen sind”: Wo kann man denn offizielle und einheitliche Stellungnahmen von ganzen wissenschaftlichen Disziplinen nachlesen, um zu wissen, wo wer gegen was ist? Wieviele Disziplinen pflegen mehrere Zitationsstile, obwohl die Gemeinschaft nur wenige hundert oder tausend Forschenden zählt?

Anmerkung 5:

Die These von Graf beschreibt kein wirkliches Problem. Der Vorteil des Webs und von Open Access ist doch gerade, dass die Publikationen eines Autors nicht wie in einer Bibliothek vollständig im gleichen Regal stehen müssen. Für das Suchen nutzt man sowieso besser BASE in Bielefeld oder internationale Fachrepositorien (oder Google oder Verbundkataloge wie Worldcat). IRs bieten zwar Suchfunktionen (und die sollen auch gut sein), aber nur für begrenzte Fragestellungen. Für das Finden ist es eigentlich egal, auf welchem Server die Publikationen liegen, Hauptsache er ist zuverlässig erreichbar und verfügt über standardisierte Schnittstellen.

Anmerkung 6:

Das institutionelle Repository soll auch die Basis für eine Universitätsbibliographie bilden. Der Zusammenhang mit der Universität ist gewollt und gewünscht. Die Primärdaten müssen ordentlich langzeitarchiviert werden, und auch bei der Institution vorliegen. Die Metadaten dagegen können auch anderweitig verwendet werden, das Zerreißen des Werks eines Autors ist also kein schlagkräftiges Argument.

Anmerkung 7:

Ich teile die Kritik, dass Publ. von Autoren zerrissen werden. Hier werden noch Lösungsmöglichkeiten gefunden werden müssen. Evtl. über ein anderes Portal (REsearchGate?) wo der Wissenschaftler die Publ. seines Werdeganges, aus unterschiedl. Repositories automatisiert (via Schnittstellen) in nutzerfreundlicher Bedienung zusammenführen kann. Derzeit ist meine Einschätzung: Ein institutionelles Repository hat den Fokus auf Publikationen der eigenen Einrichtung und soll hauptsächlich den Output der eigenen Einrichtung nach aussen widerspiegeln. Das ist schon ein sehr grosser Aufwand. Unser Rep orientiert sich an der Organisationsstruktur der Universität. Die Publ. werden den Fakultäten/Einrichtungen zugeordnet. Die Wissenschaftler der Uni können ihre Publikationen selbst einstellen, dadurch kommen natürlich auch Publ. aus früheren Arbeitsstätten in das Rep. Die Services sind daher auf die aktiven Mitarbeiter unserer Institution konzentriert. Dennoch wäre denkbar, dass man evtl eine Lösung für Interessierte entwickelt, die unser REP als zentralen Sammelpool nutzen wollen. Derzeit haben wir leider nicht die Kapazitäten, um hier etwas zu entwickeln. Ich behalte diesen interessanten Aspekt aber weiter im Hinterkopf.

Anmerkung 8:

Grundsätzlich ist die Beschränkung in den Leitlinien unseres IRs sowie des integrierten Hochschulverlages auf Mitarbeiter der Einrichtung bzw. der Mitarbeiter assoziierter Einrichtungen vernünftig, da wir für externe Veröffentlichungen grundsätzlich nicht die Verantwortung übernehmen können und wollen. Zumal wir auch argumentieren: die inhaltliche Qualität der Publikationen bildet das Niveau unserer Einrichtung ab, d. h. wir veröffentlichen – mit gewissen Einschränkungen – auch alles, was ein Mitarbeiter veröffentlichen möchte. Letztlich legen wir institutionelle Mitgliedschaft aber weit aus, um die von Herrn Graf beschriebenen Hürden möglichst niedrig zu halten. Hin und wieder erweist sich unsere Policy jedoch auch als Innovationsbremse, wenn wir z. B. Kooperationsanfragen lokaler, aber externer Einrichtungen ablehnen müssen oder diese aufgrund administrativer Verzögerungen scheitern (z. B. durch die notwendige, aber nicht zeitgerechte Zustimmung des Bibliotheksbeirats), weil die institutionelle Zugehörigkeit nicht belegt werden kann und wir so attraktive Publikationsprojekte verlieren.

Anmerkung 9:

ich wäre mir auch nicht sicher, ob IR Einträge von Alumni von den Erlaubnissen der Verlage (s. Romeo) gedeckt wären.

Anmerkung 10:

Wollen Repositorien Publikationslisten-Features anbieten, ist es nötig alte Publikationen aufzunehmen. Export Möglichkeiten erlauben es wechselnden Autoren ihre Publikationen bzw. Metadaten auf ein neues Repositorium zu migrieren. Für den Forschenden ist dies sicher nicht ideal und mit Mehraufwand verbunden. Hier kann vielleicht die Intiative ORCID Abhilfe schaffen.

Anmerkung 11:

Die Zugehörigkeit zur Hochschule wird nicht explizit geprüft. Eine solche wird einfach vorausgesetzt. Ich verstehe nicht, warum mehrere Veröffentlichungsorte ein Problem darstellen sollten – in Zeiten von BASE etc…

Google Maps wird teuer

Ab sofort verlangt Google Geld für die Nutzung der Maps-API.

Mit etwas Verzögerung hat Google seine Pläne umgesetzt , die Nutzung der Maps-API nicht mehr uneingeschränkt kostenlos zu gestatten. Wer jetzt damit Karten auf seiner Website darstellt, muss für je 1000 Abrufe mindestens 4 US-Dollar zahlen. Als Abruf gilt jeweils das Laden der JavaScript- oder Flash-API durch die Webseite, das Laden einer Karte per Static-Maps-Schnittstelle sowie der Zugriff auf ein Panoramabild via Street-View-Image-API.

Es gibt zwar “Bagatellgrenzen”, die für viele Bereiche sicherlich ausreichen. Aber will man sich wirklich darauf verlassen, dass die eigenen Seite dauerhaft unpopulär bleiben?
Wer nicht zahlen will oder kann, bitte hier entlang.

[via Heise]

Google stellt APIs um

Google stellt verschiedene APIs um. Manche werden auch eingestellt und teils durch neue APIs ersetzt. So wird zum Beispiel die Google GData Books API am 1. Dezember 2011 zurückgezogen und soll durch die Books API ersetzt werden. Die Google Blog Search API hat ebenso wie die Google Translate API schon am 26. Mai den Dienst eingestellt:

Important: The Google Translate API has been officially deprecated as of May 26, 2011. Due to the substantial economic burden caused by extensive abuse, the number of requests you may make per day will be limited and the API will be shut off completely on December 1, 2011. For website translations, we encourage you to use the Google Translate Element.

Weitere Informationen in der Ankündigung im Google Code Blog, Kommentarunmut inklusive.

[via Coffee|Code]

Mobiles Bibliothekskonto von elbedev

Anne Christensen macht auf eine von Martin Kim Dung-Pham programmierte App aufmerksam: EDSync for iPhone. Der Nutzen der App:

EDsync verwaltet deine Entleihungen. Du kannst EDsync mit deiner Bibliothek synchronisieren. So hast du immer einen Überblick, wann und welche Medien du wo zurückgeben musst. Die lokale Speicherung auf deinem Rechner erlaubt dir jeder Zeit Zugriff auf die Entleihungsdaten – egal, ob du on- oder offline bist.

iCal ist EDsync’s bester Freund. In iCal wird ein Kalender angelegt, welcher für alle Entleihungen ToDo Items enthält. So wirst du automatisch gewarnt, sobald du den Rechner anschaltest, dass ein Medium demnächst zurück gegeben werden muss. Das ist nice.

Ist das großartig? Es ist großartig! Und gleichzeitig eine Motivation für uns Bibliothekswesen, mehr Daten und Schnittstellen zur Verfügung zu stellen. Denn:

Die Metadaten zu den Medien kommen von Amazon. Die haben ganz viele Informationen und Covers da.

Warum Amazon? Wahrscheinlich, weil solche Daten dort komfortabel zur Verfügung gestellt werden, und von Bibliotheken eben nicht. Ähnlich sieht es mit den Suchergebnissen aus. Jakob Voss hat seine Erfahrungen mit der Thematik und schon vor längerer Zeit festgestellt:

Das liegt unter Anderem daran, dass der Katalog zu oft noch als ein monolithisches System verstanden wird – die Idee der Serviceorientierten Architektur ist nicht angekommen. Anstatt auf offene Schnittstellen und Standards zu setzen, werden mit Primo, Touchpoint und diversen andere kommerziellen “Discovery-interfaces” neue Einbahnstraßen zu IT-Systemen eingeschlagen, die am Ende niemand anpassen und warten kann und/oder will (während ich bei Primo nichts dergleichen gefunden habe, enthält die aktuelle Entwicklungsversion von VuFind dagegen übrigens eine Mobil-Oberfläche).

Welche Bibliothen bislang unterstützt werden, ist leider ohne Anschauung der leider nur für Apple-Geräte verfügbaren App nicht zu erkennen, da nur Städtenamen (z.B. Erfurt, Göttingen, Greifswald, Hildesheim oder Magdeburg) genannt werden. Ich gehe davon aus, dass es sich jeweils um die UBs handelt. Im elbedev-Blog ist die Verteilung der EDsync-Nutzer, die Google Analytics nicht deaktiviert haben, zu sehen.

Da die Screenshots leider nicht unter CC lizenziert sind, möge man sich für einen ersten Eindruck bitte direkt zum Anbieter begeben.

OpenBib mit Cool URIs und vielem mehr

OpenBib wurde technisch ordentlich durchgeschüttelt. Unter anderem soll OpenBib besser für das Semantic Web vorbereitet werden. Dazu kommen verschiedene Technologien wie Trennung der HTTP-URI’s von den verschiedenen Daten-Repräsentationen wie HTML,JSON,RDF,RSS oder RESTful WebServices zum Einsatz.

Durch diese Kombination wird erreicht, dass das gesamte Recherche-Portal selbst zu einem WebService wird und sich mit allen seinen Funktionen und Informationen in beliebige andere Dienste integrieren lässt. Zusätzlich besteht weiterhin der bereits etablierte Mechanismus, beliebige Informationen über (neue) Konnektoren mit definierten Standardschnittstellen (s.o.) bereitzustellen.

Die Version 2.4alpha setzt unter anderem auch auf Cool URIs. Damit kommt auch OpenBib endlich im WWW an, sind Permalinks doch eine Grundlage für die Verlinkung von Inhalten. Das Thema Permalinks hatten wir hier ja schon zur Genüge.

Auch von der konkreten OpenBib-Entwicklung abgesehen ist Oliver Flimms Posting sehr lesenswert und (nebenbei bemerkt) ein sehr gutes Beispiel für die unkomplizierte Kommunikation konkreter Projektergebnisse an die Fachgemeinde.

SOAP-Daten in Google Fusion Tables

Die Daten aus der SOAP-Umfrage sind nun als Google Fusion Table verfügbar. Damit lassen sich mit ein paar Klicks nette Visualisierungen machen. Eigentlich lassen sich die Daten auch als interaktive Widgets einbinden. Da dies (zur Zeit?) nicht verlässlich funktioniert, hier nun drei Beispiele als Screenshots:

Verteilung aller Teilnehmer der SOAP-Umfrage:
Verteilung gesamt

Verteilung der Teilnehmer, die als “Main Discipline” Social Sciences angeben:

Verteilung der Teilnehmer, die die Frage “Who decides where to submit” mit “I am advised where to publish by a senior colleague” beantwortet haben:

Die Daten aus Fusion Tables sind auch via API nutzbar. Möge es nutzen.

Wir benötigen (mal wieder) Permalinks und offene Schnittstellen

Das Netzwerk Recherche hat einen Reader über Zukunftspfade und Sackgassen des Onlinejournalismus (PDF) veröffentlicht. Im Literaturverzeichnis ist ein bemerkenswerter Hinweis:

Unter jedem Eintrag ist (via Tinyurl) die „ISBNSuche“ der Wikipedia (de.wikipedia.org/wiki/Spezial:ISBN-Suche) verlinkt, mit der man das entsprechende Buch in Bibliotheks- und Verbundkatalogen sowie im Buchhandel und in Antiquariats katalogen schnell finden kann.

Das funktioniert natürlich, so richtig elegant ist es jedoch nicht. Wieder ein Grund für Bibliotheken, auf Permalink-fähige Kataloge zu setzen und – noch besser – eindeutige Werkidentifikatoren wie die EKI einzuführen.

Dies würde nicht nur die Verlinkung von Werken ermöglichen, die keine ISBN haben. Es wäre dann auch möglich direkt auf bestimmte Auflagen zu verlinken. Oder lokalisierbare Dienste anzubieten nach dem Motto: Welche Bibliothek in meiner Nähe führt das Werk in ihrem Katalog? Aus der Verknüpfung von Geokordinaten (Sigelverzeichnis oder Wikipedia), EKI (Bibliothekskataloge) und einer Verfügbarkeitsrecherche mit DAIA ließe sich so eine sehr nützliche Anwendung bauen.

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.