Webinar zu Release 5 des COUNTER Code of Practice

Editor's Notes

• #2: Was ist COUNTER? COUNTER steht für Counting Networked Electronic Resources COUNTER hat zur Aufgabe, den Code of Practice zur standardisierten Erstellung von Nuzungsstatistiken zu entwickeln und zu pflegen Der CoP soll ein einheitliches, verlässliches und vergleichbares Reporting ermöglichen. Anbieter verpflichten sich auf freiwilliger Basis zur Einhaltung des Standards und dürfen nach Audit mit dem COUNTER-Logo werben. COUNTER überwacht die Einhaltung Erster Code of Practice im Januar 2003, seither stetige Weiterentwicklung. Derzeit gültig: Release 4 (seit 2013). Seit 2006 gibt es COUNTER Reports für E-Books. Die Release 5 Arbeitsgruppe wurde im April 2016 etabliert und startete mit einem Workshop / Brainstorming zu Release 5, bei dem entschieden wurde, den Code of Practice von Grund auf zu erneuern und umzustrukturieren. Release 5 beinhaltet umfassende Änderungen im Vergleich zum bisherigen Code of Practice. Release 5 wurde völlig neu aufgebaut und neu strukturiert, um mehr Eindeutigkeit und Klarheit zu bieten. Zum Stichwort Continuous Maintenance: mir Release 5 wird ein Konzept zur Pflege und Weiterentwicklung eingeführt, das in Section 12 des CoP festgelegt ist. Vorschläge für Änderungen können jederzeit eingereicht werden und diese werden in einem geregelten Verfahren begutachtet und bearbeitet, bzw. umgesetzt oder begründet abgelehnt.
• #3: Hier sehen Sie einen Überblick über die Personen, die in der Arbeitsgruppe aktiv waren. Bibliotheken und Verlage waren nahezu in gleicher Zahl repräsentiert.
• #4: Release 5 ist im Juli letzten Jahres veröffentlicht worden und die ersten Verlage haben bereits begonnen, die Änderungen vorzubereiten. Ein Zeitplan der Umsetzung folgt am Ende der Präsentation. Was sind nun die wesentlichen Ziele des neuen Release? Die Vereinheitlichung und Vereinfachung der Strukturen soll alle Anbieter in die Lage versetzen, verlässliche COUNTER-Reports zur Verfügung zu stellen. Die Motivation für die komplette Überarbeitung: Release 4 ist sehr komplex und für die Anbieter teilweise schwierig umzusetzen und für die Nutzer schwierig zu interpretieren. Ein Bedarf nach klarer Struktur und besserer Vergleichbarkeit der Reports wurde erkannt. Außerdem werden durch die Entwicklung neuer Nutzungsformen neue bzw. andere Reports notwendig.
• #5: Die neue Struktur mit 4 Master Reports, die nach dem gleichen Schema aufgebaut sind, soll mehr Konsistenz bringen. Die Reduktion der Metriken bringt mehr Klarheit Und schließlich wurden Attribute eingeführt, mit denen die Reports flexibel angepasst werden können
• #6: Der Code of Practice definiert jetzt also vier Master Reports. Diese Master Reports enthalten für den jeweiligen Bereich die kompletten Nutzungsdaten mit allen möglichen Nutzungstypen und Metriken. Die Master Reports müssen von den Anbietern verpflichtend zur Verfügung gestellt werden, allerdings sind je nach Host-Typ nicht alle Reports erforderlich. Plattform-Report ist für alle verpflichtend. Datenbank-Reports dagegen müssen nicht von allen Anbietern zur Verfügung gestellt werden, sondern nur von solchen, die eben auch Datenbanken bereitstellen. Im Title Master Report sind jetzt die Statistiken für Zeitschriften und für Bücher zusammen enthalten. Item Reports für Statistiken auf Artikelebene sind zunächst nur für Repositorien vorgesehen.
• #7: Hier haben wir das mögliche Aussehen der Nutzeroberfläche in einem Reporting-Systems zum Download eines Title Master Reports. Man könnte einfach nur einen Berichtszeitraum eingeben und dann den Bericht runterladen. Die Master-Reports können aber sehr umfangreich sein, daher ist vorherige Filterung nach Nutzungsszenario sinnvoll! Man kann auf bestimmte Produktarten, Metriken und Attribute filtern und bestimmen, ob die Details in eine Spalte aufgeführt werden sollen oder ob ein Summenwert reicht. Details zu Metriken und Attributen folgen.
• #8: In diesem Beispiel hier werden Nutzungszahlen für 2016 angefordert, und zwar die Gesamtzahl der Downloads von OA-Artikeln in Zeitschriften, aufgegliedert nach Publikationsjahren, aber ohne Aufschlüsselung nach Monaten.
• #9: Um aber das Herunterladen der Statistiken für die Nutzer zu vereinfachen, wurden sogenannte Standard Views vordefiniert, die zusätzlich zu den Master Reports auf den Seiten der Anbieter zur Verfügung gestellt werden sollen. Diese sehen Sie hier den jeweiligen Master Reports zugeordnet. Verschiedene Filter bzw. Attribute sind voreingestellt, so dass der jeweils benötigte Report mit einem Klick angefordert werden kann. Somit muss nicht jeder Report vorher manuell konfiguriert werden. Beim Title Master Report können Sie sehen, dass die zugehörigen Standard Views differenzieren nach Büchern und Zeitschriften, wie es ja den Bedürfnissen der Nutzungsanalysen entspricht.
• #10: Das hier ist eine Konkordanz der bisherigen Reports nach Release 4 und der Standard Views nach Release 5 Plattform- und Datenbank-Reports sind auf der Ebene der Berichte eins zu eins umgesetzt Bei den Book Reports sieht es anders aus: Bisher gibt es den Book Report 1 für die Nutzung ganzer Bücher, also ein Reporting auf Titelebene, Book Report 2 zeigt die Nutzung auf Kapitelebene Der neue Standard View Book Requests enthält Nutzungszahlen sowohl auf Titelebene als auch auf Kapitelebene Reporting von OA Gold jetzt neu für Bücher, vorher nur für Journals Book Usage by Access Type enthält dann Nutzungszahlen gegliedert nach Closed Access und Open Access
• #11: Hier haben wir die Vergleichs-Übersicht für die Journal-Reports Bisher war für die Nutzung von Zeitschriften der Journal Report 1 der entscheidende, und mit Hilfe von JR1GOA kann man die Nutzungszahlen der Open Access Titel abziehen, um eine CdP-Analyse zu machen. Im neuen Standard View Journal Requests ist Gold OA ist bereits herausgefiltert, muss nicht mehr abgezogen werden, um CpD zu ermitteln Um die Open Access Nutzung mit zu betrachten, gibt es Journal Usage by Access Type: Alle Access Types (Controlled, Gold_OA) Nutzungszahlen nach Publikationsjahren kann man mit dem Standard View Journal Requests by YOP abrufen Zu den Report_IDs, die man rechts in der Tabelle sehen kann: erster Teil immer abgeleitet vom Namen des zugehörigen Master Reports Vergleich kann man auch im Appendix B des Code of Practice sehen. Zu einzelnen Use Cases kommen wir noch im Verlauf der Präsentation.
• #12: Neu eingeführte Metriken An dieser Stelle möchte ich auf die beiden Metric Types Investigations und Requests eingehen, die im Vergleich zum bisherigen Code of Practice eine große Veränderung in der Erhebung und Darstellung der Nutzungszahlen bedeuten. Investigations: Investigations erfassen alle Nutzeraktivitäten, die im Zusammenhang mit einem beliebigen Inhalt stehen. Das bedeutet, wenn ein Nutzer sich einen Abstract anschaut, auf den Link-Resolver-Button klickt oder aber auch den Volltext eines Artikels aufruft, zählt dies als Investigation. Total_item_investigations bedeutet, dass jedes Mal, wenn ein Nutzer auf einen Artikel klickt, dies als eine Aktivität gezählt wird. Wenn der Nutzer denselben Artikel dreimal hintereinander anklickt, werden an dieser Stelle auch drei Aktivitäten gezählt. Unique_item_investigations erfassen pro Artikel und Session nur eine Aktivität, auch wenn der Nutzer mehrmals auf den Artikel klickt. Wenn sich zum Beispiel der Nutzer auf der Webseite den Abstract zu einem Artikel ansieht und anschließend dann den Volltext, dann wird das an dieser Stelle nur als eine Investigation gezählt. Zur Definition einer Session: entweder das System erfasst User Session, stellvertretend werden für die Nutzungsstatistiken Abschnitte von der Dauer einer Stunde errechnet. Doppelklick-Filter-Regeln (30 Sekunden) gelten aber weiterhin! Unique_title_investigatons erfasst die Anzahl der Aktivitäten auf Titelebene. Das heißt zum Beispiel, wenn ein Nutzer auf 5 verschiedene Kapitel desselben Buches zugreift, wird an dieser Stelle pro Session nur eine Aktivität gezählt. Request entspricht der früheren Benennung full text article request, ist aber unabhängig vom Format (pdf oder html) Wieder haben wir die Unterscheidung nach Total und Unique. Total_item_requests erfasst, wie viele Volltextnutzungen insgesamt pro Session geschehen sind. Wenn ein Artikel dreimal hintereinander heruntergeladen wird, werden auch drei requests gezählt. Unique_item_requests erfasst pro Artikel bzw. Kapitel pro Session nur eine Volltextnutzung. Das heißt, wenn ein Nutzer sich zuerst den Volltext in HTML anschaut und dann das zugehörige PDF herunterlädt, wird hier nur ein einziger request gezählt. Unique_title_requests erfasst wiederum die Volltextnutzung auf Titelebene, indem pro Titel und Session ein einziger request gezählt wird, egal wie oft oder wie viele Volltexte genutzt wurde. Wenn also 5 Kapitel desselben Buchs heruntergeladen wurden, wird an dieser Stelle ein einziger request gezählt. Für die Nutzung von Zeitschriften ist der Metric Type unique_item_requests Grundlage für die Ermittlung von Kennzahlen wie Kosten pro Download. Hier werden die früheren Doppeltzählungen ausgeschlossen, wenn auf der Anbieterseite direkt der HTML-Volltext angeboten wird und anschließend das zugehörige PDF heruntergeladen wird. So wird aber auch vermieden, dass die HTML-Volltextnutzung gar nicht berücksichtigt wird, was bisher der Fall war, wenn nur auf die Nutzung der PDFs geschaut wurde. Für die Nutzung von Büchern ist der Metric Type unique_title_requests entscheidend. Wenn bisher für Analysen die HTML-Nutzung im Verhältnis zur PDF-Nutzung in Betracht gezogen wurde, bietet sich zukünftig ein Vergleich von total_item_requests und unique_item_requests an.
• #13: Hier noch eine Illustration, die die Unterscheidung von Investigations und Requests verdeutlicht. Die Requests werden als Teil der Investigations mitgezählt, in den Reports aber auch separat angezeigt. Investigation: Abstract ansehen, Link zum Link Resolver anklicken, Artikelvorschau ansehen … Request: Volltextnutzung egal welches Format: HTML, PDF, Multimedia-Inhalte
• #14: Jetzt kommen wir zu den weiteren Attributen, die neben den Metric Types verwendet werden: Zunächst den Data_Type, der die Art des Inhalts, für den Nutzungszahlen generiert werden, ganz generell beschreibt. In den Master Reports kommen verschiedene Data_Types vor und können dort als optionaler Parameter genutzt werden und zu Gruppierungszwecken eingesetzt werden. Für die schon beschriebenen Standard Views für Bücher bzw. Zeitschriften werden die Data Types Book bzw. Journal genutzt.
• #15: Der Section_Type wird eingesetzt, um Inhalte zu beschreiben, die in Abschnitte aufgeteilt sind, wie Buchkapitel, aber auch Artikel in Zeitschriften. Der Section_Type wird in den Standard Views nicht verwendet, sondern nur im den Title Master Report
• #16: Der Access Type beschreibt die Art der Zugriffsrechte zum Zeitpunkt der Nutzung. Controlled: beschreibt Inhalte, für deren Nutzung eine Lizenz benötigt wird, also z.B abonnierte Zeitschriften oder erworbene E-Books. OA_Delayed wird bei Inhalten verwendet, die nicht von Anfang an, sondern nach einer Embargofrist frei zugänglich gemacht werden. Dieser Access Type wird derzeit noch nicht verwendet, Möglichkeiten zur Umsetzung werden derzeit noch diskutiert und entwickelt. OA_Gold ist wie bereits in Release 4 für Gold Open Access Artikel gedacht. Unter Other_Free_to_Read fallen Inhalte, die nur zeitweise, z.B. für Werbezwecke, frei zugänglich sind. Der Access Type kann bisher nur von Repositorien verwendet werden. Die Verlage suchen noch nach technischen Möglichkeiten zur Umsetzung. In den Standard Views Journal Requests und Book Requests wird nur der Access_Type Controlled angezeigt, da diese Reports die Grundlage für Lizenzierungsentscheidungen bieten sollen. In den Standard Views Book Usage by Access Type und Journal Usage by Access Type wird Controlled Access und OA_Gold Access angezeigt.
• #17: Bei den Access Methods wird zwischen herkömmlicher Nutzung und Nutzung im Rahmen von Text- und Data-Mining unterschieden. Dabei wird davon ausgegangen, dass TDM nach vorheriger Vereinbarung mit dem Anbieter und durch einen kontrollierten Zugang geschieht. TDM ist ein optionaler Parameter für Master Reports und wird von den Standard Views nicht angezeigt.
• #18: Schließlich gibt es noch wie auch bisher das Attribut Year of Publication. YOP zeigt das Jahr an, in dem der genutzte Inhalt erschienen ist Es gibt einen eigenen Standard View für Zeitschriften mit Publikationsjahren, im Standard View für Book Requests werden die Publikationsjahre enthalten sein und natürlich wird dieses Attribut in den Master Reports zur Verfügung stehen, bei denen man auf der Anbieterwebseite vor dem Herunterladen des Reports die genauen benötigten Publikationsjahre sowie weitere Filtermöglichkeiten auswählen kann.
• #19: Anhand eines Beispiels schauen wir uns das Report-Format in COUNTER Release 5 an. Ein wichtiges Ziel für Release 5 war, die Inkonsistenzen bei Release 4 zu beheben und damit für die Anbieter die Implementierung und für die Bibliotheken die Nutzung und Weiterverarbeitung der Reports zu einfachen. Inkonsistenzen bei Release 4 sind zum Beispiel: Die Spalte mit den Metriken ist nur in einigen Reports enthalten und unterschiedlich benannt. Die Summen über alle Zeilen bzw. alle Zeilen einer Metrik sind manchmal vorhanden und manchmal nicht. Bei Journal Report 5 weicht nicht nur die Darstellung von den anderen Reports ab, sondern es sind auch unterschiedliche Daten im Excel- und XML-Format enthalten. Mit Excel-Format sind jeweils allgemein Reports in Tabellenform gemeint, d.h. im Excel-, CSV- oder TSV-Format.
• #20: Bei Release 5 gibt es für alle Reports eine einheitliche Struktur, die hier am Beispiel eines Standard Views „Journal Requests (Excluding OA_Gold)“, oder kurz TR_J1, zu sehen ist. Die Reports im Excel-Format enthalten einem Kopf mit 12 Zeilen, gefolgt von einer Leerzeile, den Spaltenüberschriften und dem Datenbereich. Das Format ist darauf ausgerichtet, die Reports möglichst einfach in einer Tabellenkalkulation weiterverarbeiten zu können, z.B. einen Autofilter auf die Spaltenüberschriften zu setzen und so die gewünschten Daten herauszufiltern. Summen über alle Zeilen sind nicht in den Reports enthalten. Die Reports enthalten üblicherweise mehr als eine Metrik und Summen sind daher nur in Kombination mit einem entsprechenden Filter sinnvoll. Die gewünschten Summen können mit der Tabellenkalkulation berechnet werden.
• #21: Alle Excel-Reports haben einen einheitlichen Kopf, der wie in Release 4 den Namen des Reports, die Einrichtung, für die der Report erstellt worden ist, und den Zeitraum enthält. Neu sind die Angaben, welche Metriken im Report enthalten sind (Metric_Types), welche Filter beim Erstellen des Reports verwendet worden sind (Report_Filters) und welche optionalen Spalten im Report enthalten sind (Report_Attributes). Das Feld Exceptions ermöglicht es bei Release 5, Fehlermeldungen und Warnungen auch im Excel-Format zurückzuliefern, bei Release 4 wurde dies nur im XML-Format genutzt. Ein Beispiel wäre die Exception 3030 (No Usage Available for Requested Dates), wenn es im angefragten Zeitraum keine Nutzung gab und der Report damit keine Daten enthält. Die Reports im JSON-Format enthalten dieselben Angaben wie die Excel-Reports.
• #22: Die Bezeichnungen sind auch bei allen Reports einheitlich, z.B. die Namen der Felder im Kopf und die Spaltenüberschriften. Die Bezeichnungen im Excel-Format und im JSON-Format stimmen ebenfalls überein, auch bei den Metriken, bei denen es in Release 4 z.B. noch Unterschiede zwischen dem Excel- und XML-Format gab.
• #23: Der Datenbereich ist ebenfalls bei allen Reports einheitlich, sowohl die Benennung als auch die Reihenfolge der Spalten und die Darstellung der Daten. Welche Spalten vorhanden sind, hängt dabei natürlich vom Report ab, und bei den Master Reports auch von den gewählten Optionen. Die Reports im JSON-Format enthalten dieselben Daten, bis auf Reporting_Period_Total, da die JSON-Reports grundsätzlich keine Summen enthalten.
• #24: Bei Release 4 basiert SUSHI auf dem SOAP-Protokoll und XML, die Handhabung ist entsprechend komplex.
• #25: Das COUNTER_SUSHI API bei Release 5 basiert dagegen auf REST und die Antworten werden im JSON-Format geliefert, das XML-Format gibt es bei Release 5 nicht mehr. REST und JSON sind die heute gängigen Techniken bei der Webentwicklung, was die Implementierung und auch die Weiterverarbeitung der Daten im Vergleich zu SOAP und XML deutlich vereinfacht. Es können nicht nur ganze Reports, sondern auch nur ausgewählte Daten abrufen werden, analog zu den Filtern bei den Master Reports. Damit wäre es z.B. möglich, aus einem Elektronic Resource Management-System gezielt die Statistik für eine einzelne Zeitschrift abzurufen und anzuzeigen.
• #26: Eine SUSHI-URL setzt sich zusammen aus der Basis-URL für den SUSHI-Server, in diesem Beispiel https://jusp.jisc.ac.uk/api/sushi/counter/r5 für einen SUSHI-Server von JISC, dem Pfad für die aufzurufende Methode, hier /reports/tr_j1 zum Abruf eines TR_J1-Reports, und den weiteren Angaben wie dem Zeitraum, die einfach als Parameter übergeben werden. Die SUSHI-URL funktioniert, Sie können damit Reports abrufen und sich das JSON-Format anschauen. Einen SUSHI-Client zu implementieren ist mit dieser Technik wesentlich leichter als bei Release 4.
• #27: Das Beispiel zeigt einen SUSHI-Client, der von EBSCO in Excel mit Makros implementiert worden ist und die Technik demonstrieren soll.
• #28: Auf der rechten Seite können die Basis-URL für den SUSHI-Server und die Parameter angegeben werden.
• #29: Auf der linken Seite können der gewünschte Report und der Zeitraum ausgewählt werden. Die Angaben zu den Reports stammen dabei von dem Arbeitsblatt „Reports Supported“. Mit einem Klick auf „Go“ wird der Abruf des Reports im JSON-Format gestartet.
• #30: Die Daten aus dem Report werden dann in Tabellenform konvertiert und im Arbeitsblatt „R5 Report“ gespeichert. Das Ganze dient wie gesagt zur Demonstration der Technik und ist in der aktuellen Form eher nicht für einen produktiven Einsatz geeignet.
• #31: Es folgen einige typische Anwendungsfälle, bei denen die vordefinierten Standard Views zum Einsatz kommen, sowie mit Nullnutzung und Konsortium-Reports zwei Themen, zu denen im Laufe des Konsultationsprozesses und seit der Veröffentlichung von Release 5 besonders viele Fragen gestellt worden sind.
• #32: Für die Ermittlung der Gesamtnutzung von Zeitschriften, z.B. für eine Cost-per-Use-Analyse, kann der Standard View „Journal Requests (Excluding OA_Gold)“, oder kurz TR_J1, verwendet werden. Wie schon der Name besagt, ist die Gold Open Access-Nutzung nicht im Report enthalten. Bei Release 5 ist die Situation also deutlich einfacher als bei Release 4, wo die Differenz aus Journal Report 1 und Journal Report 1 Gold Open Access gebildet werden müsste, um einen vergleichbaren Report zu erhalten. Ebenfalls nicht im Report enthalten ist, wie bei allen Standard Views, die Text and Data Mining-Nutzung. Die zu Release 4 vergleichbare Metrik wäre hier Total_Item_Requests. Für eine Cost-per-Use-Analyse wäre Unique_Item_Requests aber besser geeignet, da hier mehrfache Abrufe eines Artikels in einer Sitzung, z.B. im HTML- und PDF-Format, nur einmal gezählt werden.
• #33: Für die Auswertung der E-Booknutzung kann der Standard View „Book Requests (Excluding OA_Gold)“, oder kurz TR_B1, verwendet werden. Auch hier sind wieder die Gold Open Access- und Text and Data Mining-Nutzung ausgeschlossen. Mit der Metrik Unique_Title_Requests ist im Gegensatz zu Release 4 die Nutzung über alle Anbieter vergleichbar - egal ob ein E-Book bei einem Anbieter als Ganzes, in Kapiteln oder in anderer Aufteilung angeboten wird, die Nutzung innerhalb einer Sitzung wird für Unique_Title_Requests nur einmal gezählt. Soll die Nutzung mit Release 4 verglichen werden, ist Book Report 1 am ehesten mit den Unique_Title_Requests vergleichbar, Book Report 2 dagegen mit den Total_Item_Requests.
• #34: Die Nutzung von Zeitschriftenarchiven kann mit dem Standard View „Journal Requests by YOP (Excluding OA_Gold)“, oder kurz TR_J4, ausgewertet werden. Der Report kann nach YOP gefiltert werden, um die Nutzung auf bestimmte Erscheinungsjahre einzuschränken. Neu ist bei Release 5, dass die Erscheinungsjahre komplett aufgeschlüsselt sind, eine Zusammenfassung von älteren Jahrgängen wie beim Journal Report 5 in Release 4 gibt es nicht mehr. Um eine Darstellung wie beim Journal Report 5 zu erhalten, also Titel nach Erscheinungsjahren, müsste eine Pivot-Tabelle verwendet werden. Entsprechend kann mit diesem Standard View natürlich auch die Nutzung der aktuellen Jahrgänge ausgewertet werden. Wenn die Aufschlüsselung nach Erscheinungsjahren für die Auswertung nicht relevant ist, sondern nur die Einschränkung, kann alternativ auch der Master Title Report verwendet werden: durch Einschränkung auf die gewünschten Erscheinungsjahre und Ausschließen der Spalte YOP erhält man nur die aggregierte Nutzung pro Titel und damit im Allgemeinen einen deutlich kleineren Report.
• #35: Zur Auswertung der Datenbanknutzung kann der Standard View „Database Search and Item Usage“, oder kurz DR_D1, verwendet werden. Bei Release 4 werden typischerweise neben den Regular Searches, die es bei Release 5 weiterhin gibt, entweder die Result Clicks oder die Record Views für die Auswertung verwendet. Es darf nicht beides verwendet werden, da z.B. die Vollanzeige eines Treffers aus einer Trefferliste sowohl als Result Click als auch als Record View zählt. Bei Release 5 kann einfach die Metrik Total_Item_Investigations verwendet werden, die sowohl Result Clicks als auch Record Views ablöst und die Nutzung einheitlich erfasst. Neu ist bei Release 5 die Möglichkeit, mit den Unique_Item_Requests die Nutzung von Volltexten in Volltextdatenbanken auszuwerten.
• #36: Die Nullnutzung dürfte eines der meistdiskutierten Themen im Zusammenhang mit COUNTER Reports sein. Der Wunsch, einen Report mit genau den Titeln zu erhalten, die lizenziert sind, um feststellen zu können, welche Titel nicht genutzt werden, ist natürlich verständlich. Viele Anbieter sind aber nicht in der Lage, solche Reports zu generieren, z.B. weil die Systeme zur Lizenzverwaltung und zum Erstellen und Ausliefern der Statistiken unabhängig voneinander sind. In Release 4 gibt es bereits die Regel, dass Nullnutzung nur in Journal Report 1 mitgeliefert werden soll, und das auch nur für die lizenzierten Zeitschriften, d.h. nicht einfach für alle Zeitschriften auf der Plattform. Hintergrund ist, dass die Reports dadurch unnötig groß werden und u.U. nicht mehr handhabbar sind. Kritisch ist dies bei Release 4 insbesondere für Journal Report 5 und die Book Reports. Bei Release 5 würde sich das Problem wegen der weiter aufgeschlüsselten Reports entsprechend verschärfen. Bei Release 5 darf daher grundsätzlich keine Nullnutzung mitgeliefert werden. Wenn ein Anbieter, der COUNTER compliant ist, dies machen möchte, wäre dafür ein Custom Report erforderlich (was mit Release 5 grundsätzlich möglich ist). Statt dessen unterstützt COUNTER den Ansatz, Titel- und Bestandsinformationen im KBART-Format zu verwenden, um die gewünschten Statistiken zu erstellen. Dieser Ansatz scheint eher praktikabel und ist flexibler, da er das Erstellen von Statistiken für beliebige Pakete ermöglichen sollte. Die KBART-Dateien sollten dabei von den Anbietern zur Verfügung gestellt werden, sie könnten aber auch aus anderen Quellen wie z.B. der Global Open Knowledgebase (GOKb) oder Electronic Resource Management-Systemen wie LAS:eR stammen. Ein wichtiger Baustein ist der automatisierte Abruf von KBART-Dateien, an dem die NISO KBART Automation Working Group momentan arbeitet. Dabei soll dieselbe Technik verwendet werden wie bei den COUNTER-Reports. Um ein präzises Zusammenführen der Daten zu ermöglichen, sollten sowohl die KBART-Dateien als auch die COUNTER-Reports neben ISSNs, ISBNs oder DOIs möglichst auch die proprietären Titel-Identifier der Anbieter enthalten.
• #37: Dieses Beispiel von EBSCO, der KBART Harvester Demonstrator, zeigt, wie die Erstellung der gewünschten Reports mit dieser Technik aussehen könnte.
• #38: Die Anbieter werden auf dem Arbeitsblatt „My Providers“ verwaltet.
• #39: Die Anbieter können dann ausgewählt werden, genau wie der gewünschte KBART-Report. Mit einem Klick auf „Go“ wird der Abruf des KBART-Reports gestartet.
• #40: Die Daten aus dem Report werden dann in Tabellenform konvertiert und im Arbeitsblatt „KBART Report“ gespeichert.
• #41: Der KBART-Report wird dann mit dem COUNTER-Report, der im Arbeitsblatt „COUNTER Sample“ gespeichert ist, zusammengeführt.
• #42: Damit erhält man einen KBART-Report inklusive Nutzung. Da der KBART-Report die Basis ist, sind hier auch die Titel mit Nullnutzung enthalten.
• #43: Konsortium-Reports waren ebenfalls ein viel diskutiertes Thema, insbesondere nachdem der Release 5 Draft veröffentlich worden war und keine Konsortium-Reports enthalten waren. Bei Release 4 gibt es eine Reihe von Problemen mit den Konsortium-Reports: Die Reports sind separat spezifiziert, es gibt sie nur im XML-Format, und es gibt nicht für jeden Reports einen entsprechenden Konsortium-Report, was die Auswertungsmöglichkeiten deutlich einschränkt. Die Reports können sehr groß werden - so groß, dass sie für die Anbieter nicht mehr generierbar oder für die Bibliotheken nicht mehr nutzbar sind. Die Anbieter sind in solchen Fällen bei Release 4 nicht verpflichtet, die Konsortium-Reports zu liefern, statt dessen kann den Konsortien der Zugang zu den Reports der einzelnen Teilnehmer angeboten werden. Genau diese Alternative ist auch der Ansatz für die Lösung in Release 5, nämlich die Reports der einzelnen Teilnehmer abzurufen und diesen Prozess, sowie das Erstellen der gewünschten Konsortialreports aus den Reports der Teilnehmer, so weit wie möglich zu automatisieren. COUNTER wird dafür die Entwicklung und Bereitstellung eines entsprechenden Open Source Tools unterstützen. Vor einigen Wochen hat es dazu eine Ausschreibung gegeben, momentan läuft die Auswertung.
• #44: Das Tool wird vereinfacht dargestellt wie folgt arbeiten: Anbieter, die COUNTER compliant sind, müssen die COUNTER_SUSHI API-Methode /members unterstützen, mit der die Teilnehmer des Konsortiums sowie deren SUSHI-Zugangsdaten abgerufen werden. Voraussetzung dafür sind natürlich gültige SUSHI-Zugangsdaten für das Konsortium. Für jeden Teilnehmer des Konsortiums wird dann der gewünschte Report abgerufen und in der gewünschten Form ausgegeben, d.h. entweder jeder Report einzeln oder alle Reports zu einem Konsortialreport zusammenmontiert. Die Ausgabe kann dabei im CSV- oder TSV-Format erfolgen oder, wenn die Reports nicht zu groß sind, auch im Excel-Format. Die einzelnen Reports können auch im JSON-Format gespeichert werden, sozusagen als Rohdaten. Diese Lösung sollte einheitlich für alle Konsortien und Anbieter und alle Reports funktionieren. Außerdem sollte sie besser skalieren, da die Logik für die Generierung der Reports nur einmal im Tool implementiert werden muss.
• #45: Abschließend dann noch einige Information zur Umstellung von Release 4 auf Release 5. Die folgenden Angaben beziehen sich auf Anbieter, die bereits COUNTER compliant sind und es mit Release 5 bleiben wollen - auf andere Anbieter hat COUNTER natürlich keinen Einfluss.
• #46: Aktuell dürfen Anbieter bereits Reports nach Release 5 liefern, sie sind aber verpflichtet, weiterhin auch Reports nach Release 4 zu liefern. Dabei dürfen die nach Release 5 ermittelten Metriken auch genutzt werden, um die Reports nach Release 4 zu generieren - wie das genau funktioniert, ist im Code of Practice Release 5 beschrieben. Es kann dadurch ggf. Einschränkungen geben, z.B. dass beim Journal Report 1 keine Aufschlüsselung nach HTML und PDF mehr erfolgt. Ab Januar 2019 müssen dann Reports nach Release 5 geliefert werden, bis mindestens April 2019 aber auch noch Reports nach Release 4, um die Umstellung für die Bibliotheken zu erleichtern. Ab Mai 2019 müssen die Reports nach Release 4 dann nicht mehr geliefert werden, vorausgesetzt der Anbieter kann die Reports nach Release 5 mindestens für das aktuelle Jahr und die beiden Vorjahre liefern - das ist der Zeitraum, für den die Reports bei COUNTER 5 mindestens zur Verfügung stehen müssen. Wenn das nicht möglich ist, müssen weiter die Reports nach Release 4 abrufbar sein, um den Zeitraum abzudecken. Ab Januar 2021 sollten dann keine Reports nach Release 4 mehr geliefert werden. Es gibt im Code of Practice Release 5 nicht nur genaue Regeln für den Übergang zwischen zwei COUNTER Releases, sondern auch für den Wechsel eines Anbieters auf eine andere Plattform bzw. Statistikplattform. Das sollte helfen, die dabei in der Vergangenheit häufig aufgetretenen Probleme zu vermeiden.
• #47: Da der Code of Practice Release 5 ein sehr umfangreiches Dokument und als Spezifikation teilweise nicht gerade leicht lesbar ist, gibt es auch die Friendly Guides, die leichter verständlich sind und konkrete Beispiele enthalten. Da die Anbieter einen längeren Vorlauf für die Umstellung auf Release 5 benötigen, gab es zunächst den Friendly Guide for Providers und die zugehörigen Technical Notes. Seit einigen Wochen gibt es jetzt auch den Friendly Guide for Librarians, der auf ca. 20 Seiten einen Überblick über die wichtigsten Punkte gibt und anhand von Beispielen die Metriken und Reports erläutert.
• #48: Die wichtigsten Ressourcen zu Release 5 sind der Code of Practice, das FAQ zum Code of Practice und die Friendly Guides. Es gibt englischsprachige Mailinglisten, einerseits für Bibliotheken und andererseits zur Implementierung, also eher für Anbieter, die für Fragen und Diskussionen zu Release 5 genutzt werden können. Bibliotheken können gerne auch die deutschsprachige Gauss-Mailingliste für Fragen und Diskussionen zu Release 5 nutzen (bitte die dienstliche E-Mailadresse für das Abonnieren der Mailingliste verwenden).
• #49: Sie können sich mit Fragen natürlich gerne auch direkt an uns wenden!