Wie ich schon öfter mal erkennen musste, ist längst nicht allen Nutzern und auch BibliothekarInnen bewusst, dass man in den Katalogen der GBV-Lokalsysteme nicht einfach auf einzelne angezeigte Titel verlinken kann.
Wenn man einen Titel angezeigt bekommt, ist es eigentlich eine relativ normale Gewohnheit, den URL aus der Adresszeile zu kopieren und z.B. per Mail weiter zu schicken. Das kann man eigentlich überall im Netz. Bei den PICA-Katalogen geht es nicht.
Natürlich ist dieses “Merkmal” bekannt und schon 2007 wurde es von Jakob Voss im GBV thematisiert. Offenichtlich wird das Thema Permalinks in Katalogen für nicht so wichtig gehalten, da bis jetzt nicht allzuviel passiert ist.
Vielleicht liegt es daran, dass ja im GVK eine unheimlich elegante Methode implementiert wurde, die aufmerksamen LeserInnen der Titelaufnahme sicher nicht verborgen bleibt. Auch hier kann man nicht den in der Adresszeile angezeigten Link benutzen, es gibt als Ersatz aber einen sogenannten Zitierlink. Wenn man unter den Titeldaten nachschaut, springt er einen förmlich ins Auge.
Zur Verdeutlichung ist er in dem Bild aber trotzdem markiert.
Wenn ich hier im Beitrag also auf den Titel in unserem Katalog verlinken wollte, hätte ich ein Problem (mir ist bekannt, dass man von Hand einen funktionieren Link zusammenbasteln kann), auf den Titel im GVK kann man verlinken, wenn man auf den Zitierlink stösst. Noch ein Grund mehr für unseren beta-Katalog, der mit vufind realsiert wurde und bei dem ich natürlich den in der Adresszeile angezeigten URL zur Verlinkung benutzen kann. Faszinierend!
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Edlef Stabenau (19. April 2010). GBV-Kataloge auf dem Weg ins Internet. netbib. Abgerufen am 12. Oktober 2024 von https://doi.org/10.58079/s6z0
@CH Ich würde wetten, dass es bei den EKIs sehr viel schneller als bei den PPNs Probleme mit der Eindeutigkeit geben wird. Solange damit nicht eine genauso strenge (d.h. rein formale und zugleich technische) Prüfung auf Eindeutigkeit durchgeführt wird wie bei der ID-Nummer der Datenbank, muss man damit rechnen, daß beim Erstellen von Titelaufnahmen durch ‘Überschreiben’ so wie jetzt z.B. unpassende Sacherschließungselemente dann eben auch unpassende EKIs mitkopiert werden. Aber der Ansatz ist richtig: Man bräuchte für Permalinks auf Katalogisate datenbankübergreifende eindeutige Identifier. Es muß ja nicht gleich eine im Grunde allumfassende Datenbank sein, deren eindeutige Identifier dann verwendet werden können.
Die ISBN sollte ja auch mal eindeutig sein, da es aber keine technische Kontrolle gibt, werden fröhlich für Neuauflagen alte ISBNs recyclet (um ISBNs zu sparen – man stelle sich mal eine Datenbank vor, in der man die Identifier mehrfach vergibt, um Speicherplatz zu sparen) oder für sog. ‘BaFöG’-Ausgaben der Preis gesenkt und eine zweite (manchmal sogar dritte) ISBN auf den Buchrücken geklebt, während im Impressum immer noch die ursprünglich steht, was ja auch richtig ist, denn wenn man die Aufkleber abzieht, ist die ‘BaFöG’-Ausgabe (ebenfalls durch entsprechenden Aufkleber gekennzeichnet) von der Originalausgabe nicht mehr zu unterscheiden. Kein Wunder: Es ist ja auch dieselbe Auflage.
@tillk
Danke für die Beispiele!
@Jakob
Wenn Primo und Touchpoint einen Katalogumstieg nicht abbilden könnten, wäre das in der Tat ein Armutszeugnis. WordPress kann sowas schließlich mit Bordmitteln, ich halte das auch für keine große Zauberkunst.
Zu den IDs: Wäre es nicht sinnvoller, gleich EKIs zu nehmen? Gibt es da Gespräche zwischen den Verbünden, dass sie bald flächendeckend genutzt werden können und sollen?
Danke für die treffende Darstellung (Edlef) und für die traurigen Praxisbeispiele (Till)! Ich spreche deshalb explizit bei Hinweisen auf die GBV-Zitierlinks von “Krücken” – keine richtigen Permalinks aber besser als gar keine benutzbare Möglichkeit, auf einzelne Titel zu verlinken.
Um richtige Permalinks im GBV einzuführen, wie ich 2007 angedacht hatte,
müssten die Weboberflächen aller PICA-Systeme umgestellt werden. Die DNB hat zum Beispiel vor 2 oder 3 Jahren ein eigenes “Portal” erstellt und das PICA-System werkelt nur noch im Hintergrund – leider sind auch hier die Permalinks nur halbherzig umgesetzt.
Ich möchte aber betonen, dass Permalinks nur sekundär eine Frage der Software sind sondern primär eine Frage der Vereinbarung! Die TU Harburg hat beispielweise jetzt folgende Permalink-Struktur:
http://katalog.tub.tu-harburg.de/Record/{GVKPPN}
Wenn PICA vor 10 Jahren ihren WebOPAC sauber konzipiert hätten und z.B. der alte OPAC Permalinks der folgenden Form hätte
http://opac.tub.tu-harburg.de/title/ppn/{GVKPPN}
Dann müsste die neue VuFind-Installation so konfiguriert werden, dass genau dieselbe URL-Struktur erhalten bleibt. Permalinks müssen also auch bei Wechsel der Katalogsoftware erhalten bleiben!
Fragt doch mal zum Beispiel bei ExLibris an, ob sie Primo so konfigurieren können, dass eine bestehende Permalinkstruktur erhalten bleibt (oder bei einem beliebigen anderen Hersteller). Wenn dies nicht der Fall ist, ist die Software schlicht schlecht konzipiert und es ist ein KO-Kriterium, die Software nicht zu verwenden. Keine Bibliothek würde auf die Idee kommen, eine Regalanlage zu kaufen, in die Ihre vorhandenen Bestände nicht reinpassen. Beim Katalogsoftware wird dagegen nur nachach geschaut, dass sie schick aussieht und die Bedürfnisse der Bibliothekare erfüllt.
Wenn eine Katalogsoftware vorschreiben würde, dass alle Titel eine neue Signatur erhalten und die alten Signaturen ihre Gültigkeit verlieren, würde jeder halbwegs engagierte Bibliothekar zu Recht vor Empörung aufschreien. Wieso also nicht bei Permalinks?
@CH Das ist kein Fehler. Eine PPN ist nur innerhalb eines sogenannten Filesets eindeutig. Da in so einem CBS durchaus mehrere Filesets existieren können, können auch PPNs mehrfach vorkommen. Da die Nationallizenz-Daten über verschiedene Filesets verteilt sind…
Filesets sind eine interne Angelegenheit der Software, als Benutzer kommt man damit normalerweise wohl nicht in Kontakt. Da kennt man eher die Datenbank-IDs, die wiederum Sichten auf Filesets sind. Innerhalb solch einer Datenbank sollten die PPNs allerdings auch eindeutig sein.
Es gab aber auch schon Fälle, bei denen PPNs in Lokalsystemen doppelt waren. Das waren wohl Folgen von Update-Fehlern und das sollte es tatsächlich nicht geben.
@tillk
Hast Du Beispiele für doppelt vergebene PPNs? Oder wird soetwas bei Entdeckung gleich behoben?
Diese “Permalinks” in Katalogen sind technisch üblicherweise auch “Suchen”. Irgendwo muss der Datensatz ja herkommen, der dann angezeigt wird. Bei VuFind wird halt nach der ID des Datensatzes, die ja in der URL steht, gesucht. So funktionieren die “GBV-Permalinks” auch. Der Permalink sieht nur ein bischen “schöner” aus als der “Suchlink”.
Wenn die Datensatz-IDs sich ändern, ändern sich auch diese Permalinks, bzw. die alten werden ungültig. Den Aufwand für einen Resolver, der “ewig gültige” Identifier verwaltet und auf Links in Kataloge abbildet, treibt keines der von mir aufgezählten Systeme. Man könnte natürlich jedem Datensatz einen Identifier (z.B. ein Handle) verpassen, aber wer machts (und vor allem: wer pflegt die Links?)?
Das Problem, dass sich Datensatz-IDs ändern, hatten wir bei der Suchkiste schon. Bei unserem allerersten Prototypen hatten wir auch die PPN aus dem CBS als Identifier verwendet. Bis dann PPNs doppelt auftraten (ja, das gibts). Seither setzen wir als Prefix das ZDB-Sigel des Nationallizenzprodukts davor, um sie eindeutig zu machen. Die alten IDs waren damit eigentlich ungültig. Wir haben allerdings einen kleinen Mechanismus eingebaut, der versucht, die alten IDs auf neue abzubilden. Im schlimmsten Fall bekommt ein Benutzer dann zwei Datensätze statt einem angezeigt, die aber mit neuer ID…
Das zeigt aber auch, wie wichtig es ist, dass man sich um den Aufbau solcher URLs Gedanken macht. Man sollte schon einen Identifier nehmen, der zumindest absehbar stabil bleibt (“ewig” wird niemand garantieren wollen…).
Oh, gleiches gilt natürlich auch für die restlichen Bestandteile solch einer URL: Der Host- und Domain-Teil oder der Pfad auf dem Server sollten natürlich auch stabil bleiben…
@aw
Das ist eben grad kein Permalink, sondern eine als URL kodierte Suche. Was passiert beispielsweise, wenn die PPNs verlängert werden und automatisch trunkiert wird? Der Permalink verliert seine Eindeutigkeit und man bekommt mehrere Treffer.
Permanenter sind dann schon direkte Aufrufe von PPNs, wie sie ja beispielsweise der GBV- oder auch SWB-Zitierlink darstellt:
Schön und vor allem auch permanent ist immer noch anders.
@till Danke! Ich war grad in der Pause, der Kommentar war wegen der Menge der Links auf Moderation…
Hmm, befürchte mein länglicher Kommentar wurde wegen der vielen enthaltenen merkwürdigen Links von WordPress als Spam klassifiziert…
Vielleicht kann ihn jemand aus dem Müll fischen?
Das Problem ist, dass diese Kataloge schlicht arrogant ignorieren, wie seit über 15 Jahren das Web funktioniert. Nämlich mit stabilen Links. Schön, dass das Thema in den letzten Monaten endlich wahrgenommen wird…
Dass Profis sich irgendwie helfen können ist keine Entschuldigung dafür, dass man ohne diesen vermeintlichen Expertenvorsprung nicht mit diesen Katalogen wie mit (fast) jeder anderen Webressource arbeiten kann (bookmarken, verlinken, bei Suchmaschinen finden, per Mail/Twitter/Brieftaube weitergeben, ausdrucken, …).
Und dass es noch schlechtere Lösungen gibt, entschuldigt auch nichts. Es gibt genug bessere, bei denen das hinreichend funktioniert. Dass das alles “erklärbare historische Gründe” (oder vielleicht manchmal welche, die im Geschäftsmodell des Softwareherstellers liegen) hat, entschuldigt auch nichts…
Mal eine kleine, spontane Umschau: Ich kopiere hier einfach mal ein paar Links aus der Adresszeile meines Browsers rein. Es geht dabei nicht darum, einzelne Institutionen an den Pranger zu stellen, es ist eher eine zufällige Auswahl (sowohl an Institutionen als auch an in der Branche verbreiteten Produkten):
kaputt: Gateway Bayern (Infoguide): http://opac.bib-bvb.de:8080/InfoGuideClient.fasttestsis/singleHit.do?methodToCall=showHit&curPos=6&identifier=1_FAST_327811267
kaputt: Swissbib (Touchpoint): http://www.swissbib.ch/TouchPoint/singleHit.do;jsessionid=D03395EBE9EB6695D0D7B1BF0ED02869.worker2?methodToCall=showHit&curPos=4&identifier=3_SWISSBIB_TARGET_3_1656789184
kaputt: Stadtbibliothek Göttingen (Bond): http://opac.stadtbibliothek.goettingen.de/wopac/index.asp?detmediennr=3
vielleicht gut gemeint, aber leider dann auch kaputt: neuer Katalog der UB Wien (Primo): http://search.obvsg.at:1701/primo_library/libweb/action/display.do?pag=nxt&indx=6&doc=UWI_aleph_acc006688267&dscnt=0&dstmp=1271667318733&vl%281UI0%29=contains&ct=display&indx=6&mode=Basic&vid=UWI&scp.scps=scope%3A%28UWI_O_SFX%29%2Cscope%3A%28UWI_O_metalib%29%2Cscope%3A%28UWI_aleph_acc%29&vl%28D3442612UI0%29=any&srt=rank&vl%2836668552UI1%29=all_items&tab=default_tab&dum=true&pag=nxt&frbr=&vl%28freeText0%29=web%202.0&fromLogin=true&doc=UWI_aleph_acc006629149&fn=search
Bei Primo ist das besonders gemein: Es zeigt zwar eine “Volltitelanzeige” an, das ist aber nicht die, bei der ich den Link kopiert habe (wirklich nicht, man kann das reproduzieren, indem man ein wenig in der “Volltitelanzeige” blättert, dann den Link aus dem Browser kopiert und in einem anderen Browser aufruft). Ein Bug? Prinzipiell sieht die URL schon so aus, als könnte sie “persistent” sein (wenn auch extrem hässlich). Christian Hauschke hatte dazu ja auch schonmal etwas geschrieben: http://infobib.de/blog/2010/04/09/auch-in-osterreich-permalinks-fur-katalogisate/
HBZ Verbundkatalog (Aleph): http://193.30.112.134/F/CGGID6HSHF9F6NLP516B8JP417G59HEKN3PE56EB8M8DMCL21S-02889?func=full-set-set&set_number=059633&set_entry=000003&format=999 (der Link könnte noch funktionieren, wenn ihr draufklickt, wird das aber nicht ewig tun, denn da ist die Treffernummer in einer bestimmten Suchsitzung drin kodiert)
SLUB Dresden (Libero): http://webopac.slub-dresden.de/libero/WebOpac.cls?VERSION=2&ACTION=DISPLAY&RSN=14302945&DATA=SLU&TOKEN=9GjHsvtmCh5030&Z=1&SET=1 (funktioniert evtl. auch noch, läuft aber auch irgendwann ab, auch wieder Session-ID, Suchsitzung und Treffernummer im Link)
Die Liste ließe sich beliebig fortsetzen…
Oh, und verschärft (mindestens zwei solcher Fälle sind auch in den Beispielen oben): Ganz toll sind Links, die einen Session-Identifier enthalten, der lange gültig ist, und bei denen das System nicht prüft, ob denn dieser Link nun “berechtigt” aufgerufen wurde (liebe Softwarelieferanten: bitte jetzt nicht solche Prüfungen einbauen, sondern es gleich richtig machen!). Wenn man sowas bekommt (z.B. von einem Kollegen per Mail oder über einen social bookmarking Dienst), kann man sogar in Sitzungen anderer Benutzer springen und z.B. die gesamte Suchgeschichte dieser Sitzung abrufen (oder manipulieren, …). (Als ich den Betreiber solch eines Datenschutzproblems mal darauf hinwies, bekam ich als Antwort, das müsse so sein, weil das Suchportal sonst an den Lesesaal-PCs nicht mehr funktioniere. Hallo, ihr betreibt da ein weltweit zugängliches Webangebot?!?). Kann man aber auch als Feature verkaufen: Social search history sharing…
Damit es nicht zu frustrierend wird, auch ein paar positive Beispiele:
Hochschule für jüdische Schriften (Koha): https://hfjs.bsz-bw.de/cgi-bin/koha/opac-detail.pl?biblionumber=3842
Stanford (Blacklight): http://searchworks.stanford.edu/view/7863254 (die URLs sind so “schön” wie die von VuFind)
Hong Kong University of Science and Technology (Scriblio): http://catalog.ust.hk/catalog/archives/734752 (bekommt auch einen zusätzlichen Sonderpreis für “Schönheit” der URLs).
North Carolina State University (Endeca Profind): http://www2.lib.ncsu.edu/catalog/record/NCSU2232911
Worldcat: http://www.worldcat.org/title/library-20-and-beyond-innovative-technologies-and-tomorrows-user/oclc/85892268&referer=brief_results
Auch hier gäbe es noch weitere Beispiele (VuFind wurde ja schon genannt)…
Wo ist das Problem in PICA?
Gerade bei PICA läßt sich eigentlich eine Katalogsuche sehr schön über die URL antriggern. (Extremst praktisch für einen Browsershortcut, und dem kann man jeden Suchschlüssel mitgeben!) Für obiges Beispiel muß man nur die PPN im OPAC suchen:
https://katalog.b.tu-harburg.de/DB=1/CMD?ACT=SRCHA&IKT=1016&SRT=YOP&TRM=ppn+571226744
dann hat man seinen Permalink, wenn man den einbinden wollen sollte. (Da kocht der GBV auch nur mit Wasser.)
Das berührt nicht das Problem, dass man aus der Browserurl den Keks entfernen muß, wenn man die nehmen will, keine Frage. Joe Dau wird da überfordert sein, das könnte schicker sein. Anyway, den Link verschicken bzw. verschickbar zu machen ist hinreichend trivial, wenn man den Benutzer etwas bei der Hand nimmt und sagt was er kopieren soll. Da gibts weiß Gott schlechtere Kataloge als PICA.
cu