Fachklassifikationen der Dokumente im OA-Netzwerk – Datenraum

OA-Netzwerk sammelt in seiner Funktion als Aggregator Metdaten zu wissenschaftlichen Publikationen sämtlicher DINI-zertifizierter Repositorien. Interessant ist dabei natürlich die Frage wie sich die fachliche Verteilung aller Dokumente des OAN-Datenraums gestaltet. Welche Fachdisziplinen sind besonders stark vertreten, welche weniger? Ein Stück weit sind diese Daten sicherlich auch ein Indikator dafür, in welchen Fachbereichen Open Access mehr Anklang findet als in anderen.

Die folgende Tabelle bezieht sich auf mehr als 50.000 Datensätze aus dem OAN-Datenraum, zu denen Volltexte sowie DDC-Klassifikationen verfügbar sind. Mehrfachklassifikationen sind im Verhältnis verrechnet.

11,74% Medizin (DDC: 610)
10,83% Informatik (DDC: 004)
9,56% Wirtschaft (DDC: 330)
9,1% Biowissenschaften, Biologie (DDC: 570)
8,05% Physik (DDC: 530)
7,98% Chemie (DDC: 540)
7,63% Psychologie (DDC: 150)
6,82% Ingenieurwissenschaften (DDC: 620)
4,39% Mathematik (DDC: 510)
3,3% Geowissenschaften (DDC: 550)
2,17% Politik (DDC: 320)
2,14% Bibliotheks- und Informationswissenschaft (DDC: 020)
1,72% Zeitschriften, fortlaufende Sammelwerke (DDC: 050)
1,5% Alte Geschichte, Archäologie (DDC: 930)
1,43% Erziehung, Schul- und Bildungswesen (DDC: 370)
1,32% Recht (DDC: 340)
0,91% Technische Chemie (DDC: 660)
0,9% Landwirtschaft, Veterinärmedizin (DDC: 630)
0,64% Architektur (DDC: 720)
0,58% Malerei (DDC: 750)
0,56% Hausbau, Bauhandwerk (DDC: 690)

6,73%

Sonstige

Die Aufstellung basiert demnach auf der Dewey-Dezimalklassifikation. Rein fachlich ließen sich einige der Daten sicherlich noch weiter aggregieren, beispielsweise Chemie (DDC: 540) und Technische Chemie/Chemische Verarbeitung (DDC: 660) laufen unter dem DDC-Schema unter verschiedenen Hauptkategorien, ließen sich aber im Sinne einer groben Übersicht fachlich durchaus auch in einer Kategorie unterbringen.

Fragen zu den genannten oder weiteren Zahlen gerne per email.

Ranking der Suchergebnisse in OAN

Der OAN-Blog dient neben der Information über die Aktivitäten des OA-Netzwerk-Teams der Dokumentation der Funktionen des OA-Netzwerkes. Über diesbezügliche Rückmeldungen und Fragen von Seiten unserer Nutzer freuen wir uns!

Für alle Informationssuchenden im OA-Netzwerk-Dokumentenraum mag beispielsweise von Interesse sein, nach welchen Kriterien das Ranking der Suchergebnisse und die Detailanzeigen des Browsings der OAN-Suche erfolgt:

Beide Ergebnisanzeigen werden nach Treffergewichten sortiert angezeigt. Die Treffergewichte werden je nach Ort und Qualität des Treffers für jedes Objekt im Trefferraum einzeln vergeben und abschließend aufaddiert. So erhält der Treffer eines ganzen Wortes mehr Gewicht, als ein Treffer in einem Wortteil (bspw. bei Suche nach „DDR“ erhält der Treffer im Wort „Schilddrüsenkrebs“ nur ein sehr geringes Gewicht). Auch werden Treffer im Titel höher gewichtet als solche in den Schlagworten, in den Abstracts etc. Treffer im Volltext werden ebenfalls einbezogen, sofern ein Volltext maschinenlesbar vorliegt.

Welcher Link wäre Ihnen recht?

Die Frage ist scherzhaft formuliert, doch muss sie ein Service Provider früher oder später für sich und sein System beantworten. Ob es nun darum geht, Suchergebnisse in einer Rechercheoberfläche aufzubereiten, Alerting-Dienste auf neue Artikel anzubieten oder ganz einfach einen Metadatensatz in einem Format wie BibTeX zu exportieren – immer hat man die Option, einen Link mit Bezug auf das durch die Metadaten beschriebene Objekt anzugeben. Welcher Link sollte dies sein, wo kommt er her und ist man sich sicher, dass er dorthin zeigt, wie man es annimmt?

Volltextlink vs. Jump-Off-Page

Beschäftigen wir uns zuerst damit, was wir anbieten wollen. Mit dem Begriff ‚Volltextlink‘ soll im Folgenden eine URL benannt werden, die direkt auf die Volltext-Datei eines elektronischen Dokumentes im Netz zeigt. Surft man diese URL an, wird – je nach lokaler Browsereinstellung und unter der URL abgelegtem Dateiformat (z.B. pdf, html, xml, ps, doc) – das Dokument als neue Seite geladen, durch ein Plug-In dargestellt oder als Download zum Speichern bzw. Öffnen mit einer externen Anwendung angeboten.

Die Alternative wäre die so genannte ‚Jump-Off-Page‘, die auch als Abstract-Seite, Metadaten-Seite oder Frontpage tituliert wird. Hier handelt es sich um eine menschenlesbare Webseite, die den Metadatensatz strukturiert und mit allerlei Links, Zusatzinformationen und Corporate Design darstellt. Günstigenfalls ist einer der Links darin ein Volltextlink. Wir reden ja über Open-Access-Publikationen. Der Volltext sollte also auf die eine oder andere Weise verfügbar sein.

Zitat DRIVER Guideline Wiki:

  • The jump-off page is an html intermediate page that is used for human readable presentations when an Item that has more than one digital object file. This situation typically occurs with dissertations (theses) with separate object files (e.g. when the thesis consists of a set of previously published articles). It also occurs when the content provider has a PDF, MS Word DOC and a HTML version of the same article.

Jetzt müsste man korrekterweise weiter fragen: Woher kommt die Jump-Off-Page, respektive woher die Metadaten darin? Sowohl Service Provider wie Open-Access-Netzwerk als auch die Dokumentenserver stellen solche Übersichten im Stil von Datenblättern oder Karteikarten da. Auf eine der beiden Jump-Off-Pages könnte ein Link potentiell zeigen.

Welche Jump-Off-Page ist zu bevorzugen? Die lokale ‚Originalseite‘ des Data Providers, die eventuell zusätzliche Metadaten oder Services enthält, die gar nicht durch das starre Korsett der OAI-PMH-Schnittstelle an den Service Provider übertragen wurden, dafür aber keine Harmonisierung erfahren haben? Oder doch die Seite des Service Providers, wo vielleicht für die OAI-PMH-Welt unsichtbare Informationen verloren sind, aber dafür aus dem Kontext der Aggregation ganz neue, eventuell repositorienübergriefende Mehrwerte verfügbar sind?

In die Entscheidung spielt nebenbei hinein, dass nur auf Service-Provider-Seite ein einheitliches Layout der Jump-Off-Pages garantiert werden kann. Vertrautheit in der Anordnung der Informationen ist ein Usability-Kriterium.

Die durch OAI-PMH gegebene Realität

Der Service Provider ’sieht‘ in erster Linie nur, was die OAI-PMH-Schnittstellen der Data Provider exponieren. Im Format ‚Dublin Core Simple‘– noch immer der verbreitetste Standard in Deutschland – gibt es das Metadatenfeld dc:identifier. Die Dublic Core Metadata Initiative schreibt hierzu, das Feld möge eine ‚unambiguous reference to the resource within a given context‘ enthalten. Die Begriffe ‚unambiguous‘ und ‚within a given context‘ lassen Interpretationspielraum. Und der wird genutzt. Bei der Aggregation sieht man verschiedene Varianten. Jump-Off-Pages hier, Volltextlinks dort. Manchmal sind Ausnahmen wie relative Pfade dabei. So etwas sollte schon auf Data-Provider-Seite im OAI-PMH-Export korrigiert werden. Andere (meist zusätzliche) Varianten sind alternative Links, URNs, DOI oder irgendeine andere Form von Persistent Identifier oder was man dafür hält.

Zitat DRIVER Guideline Wiki:

  • […] many repositories place a link to a jump-off page in dc:identifier instead of a direct link to the digital resource file

In Open-Access-Netzwerk haben wir, wie in der Harmonisierung beschrieben, extra ein Modul integriert, welches die Aufgabe hat, den Volltextlink aus den übertragenen DC-Identifiern zu bestätigen bzw. sich heuristisch über die Jump-Off-Page dem finalen Link zu nähern. Für die Rückrichtung vom Volltextlink zur Jump-Off-Page – obwohl zum Beispiel für Open-Access-Statistik interessant – hat Open-Access-Netzwerk noch kein Konzept. Fakt ist, dass auf der Jump-Off-Page häufig alternative Dateiformate vermerkt sind. Das ist eine wichtige Information. Aus technischer Sicht benötigt das System jedoch den Volltextlink, um eine maschinenlesbare Repräsentation des Volltextes für nachgeschaltete Mehrwertdienste abrufen zu können.

Wolfram Horstmann und Friedrich Summann (DRIVER Projekt) waren 2007 nicht die Ersten und auch nicht der Letzten, die diese Thematik in einem Redebeitrag auf dem Workshop ‚Technische Aspekte des DINI-Zertifikats 2007‘ aufgegriffen haben. Die Folien 16-18 zu ‚Harvesting Challenges‘ zählen das beschrieben Problem auf: ‚Links to the Document adress a jump-off page (prevent indexing the fulltext)‘. Diese Hürde geht, wie gesagt, in Open-Access-Netzwerk der Volltextfinde-Dienst an. Die DRIVER Guidelines widmen dem Thema dc:identifier einen Abschnitt.

Exkurs: Dokumentbegriff und OAI-ORE

Bevor wir jetzt eine Empfehlung abgeben, wie man das in dc:identifier abbilden könnte, verweise ich die Problematik auf ein größeres Problemfeld: Welches Dokumentmodell wenden wir eigentlich an? Links auf alternative Dateiformate, die inhaltlich die selbe Publikation darstellen, oder Publikationen aus verschiedenen Datei-Komponenten, sind nur ein Teilproblem dessen. Hinzu kommen unterschiedliche Versionen einer Publiaktion, sowie die Einbettung von Dokumenten ineinander, wenn zum Beispiel ein Konferenzband verschiedene, per se unabhängige Beiträge zusammenfasst. Denkbar und teilweise bereits lokal auf einigen Dokumentenservern vermerkt sind verschiedenste Relationen, wie Volltexte zueinander einnehmen können. Das alles kulminiert in der Frage, was genau denn ein und dasselbe Dokument ist und was nicht.

Open-Access-Netzwerk stützt sich in der vorliegenden System-Version auf die Granularität, welche die OAI-PMH-Schnittstellen vorgeben. Was auf den einzelnen, in Deutschland verteilten Dokumentenservern ein Objekt ist, ist es auch in der Aggregation. Wie Beziehungen zwischen einzelnen, mittels OAI-PMH übertragen Dublin-Core-Simple-Datensätzen zu fassen sind, da gibt es aktuell keine Regelung, auch wenn die Problematik auf den einschlägigen Fachtagungen heiß diskutiert wird. Wer hier tiefer einsteigen will, sollte sich nach OAI-ORE (Object Reuse and Exchange) umschauen.

Grob gesagt, handelt es sich bei ORE um eine zusätzliche Schnittstellendefintion bzw. ein Protokoll, welches nicht nur bestehende Relationen zwischen Dokumenten abbilden kann, sondern ganz allgemein ein Konzept vorstellt, wie Dokumente unter beliebig vielen Gesichtspunkten bestimmten Gruppen (hier: Aggregationen) zugeordnet werden können. Dabei treten diese Aggregationen selbst als Mehrwertdaten auf, die verbreitet werden. Technologisch orientiert sich das Format im Übrigen an Austauschprotokollen, wie sie eher für Newsfeeds benutzt werden. Open-Access-Netzwerk verfolgt die Entwicklungen mit großem Interesse.

Benutzerführung zu Volltext und Metadaten

Kehren wir zur eigentlichen, ganz pragmatisch motivierten Problematik zurück und nehmen an, wir sind uns bereits im Klaren, welche Jump-Off-Page und welchen Volltextlink wir präferieren, und wir haben beides als Datum im System vorrätig. Was erwartet nun der Nutzer? Eine schwierige Frage.

Usability ist in dem Bereich ein Thema, das nicht unbedingt erschöpfend behandelt wurde. Die Rechercheoberfläche von Open-Access-Netzwerk orientiert sich salopp gesagt am ‚Google-Gewohnheitswert‘. Unter dem Namen bzw. Titel des Treffers verbirgt sich der ermittelte Volltextlink. Ein Klick und man hat in der Regel direkt den Volltext der beschriebenen Publikation auf dem Bildschirm. Open-Access-Netzwerk geht davon aus, dass bei der Recherche in Open-Access-Publikationen der möglichst hürdenlose Zugriff auf den Volltext Priorität hat. Ein separates Icon – zur Zeit das Lupensymbol – öffnet alternativ dazu die lokale Jump-Off-Page mit den Metadaten.

Die aktuelle Weiterentwicklung der Rechercheoberfläche bettet im Testbetrieb einen BibTeX-Export und einen RSS-Feed ein. Während der BibTeX-Export bereits brauchbare Ergebnisse beim Import in Literaturverwaltungsprogramme wie z.B. Citavi liefert, ist der RSS-Feed, der als Alerting-Feature eine Suche als Feed abonieren kann, noch nicht hinreichend performant. Wie das Format jedoch technisch aussehen wird und welche Möglichkeiten sich als Nutzung ergeben, lässt sich jedoch skizzieren. Hier bietet sich die Gelegenheit, von Anfang an auf konkrete Anmerkungen aus Nutzersicht einzugehen – nicht nur zu diesem Thema. Ich würde daher gerne versuchen, über die Kommentarfunktion Anmerkungen und Hinweise einzuholen.

Nachwort

Dieses Thema im Blog anzuschneiden und zur Diskussion zu stellen, wurde von Christian Hauschke vom Infobib-Blog angeregt bzw. durch begleitende Diskussionen unterstützt. Seiner Bereitschaft zu konstruktiver Kritik und der damit verbundenen Zeitinvestition sei an dieser Stelle ausdrücklich gedankt!

(-rm)

Aggregation und Harmonisierung

Beim Zusammenführen der auf verschiedenen Dokumentenservern generierten und archivierten Metadaten – beim Prozess der Aggregation – ergibt sich die Frage, wie die eingesammelten Daten für die Schaffung eines gemeinsamen Datenraumes vergleichbar gemacht werden können. Open-Access-Netzwerk hat für dieses Themenfeld häufig den Begriff „Harmonisierung“ verwendet. In diesem Artikel soll dies näher betrachtet werden.

Metadaten und Metadatenformat

Zur Begriffsklärung vorweg: Die Metadaten eines Dokumentes sind ein semantisches Konstrukt. Es sind Eigenschaften, die das Dokument, sowie den Kontext seiner Entstehung und Verbreitung, beschreiben. Bibliothekarisch gesehen ein ganz alter Hut, unabhängig von der elektronischen bzw. digitalen Welt gewachsen und gereift. Um interoperabel zu werden, um Vergleichbarkeit zu schaffen, wurden und werden Standards geschaffen. Formal abgebildet ergibt sich daraus ein Datenmodell und aus dem Datenmodell eine Syntax. Ein Informatiker würde sagen, man einigt sich auf eine Grammatik, d. h. auf ein Format für die Metadaten, um sie durch einen strukturierten Symbolstrom abbilden zu können.

So, und da fangen die Probleme an. Wie umfangreich will bzw. kann man die Dokumente beschreiben? Welches Datenmodell bzw. Metadatenformat wende ich an? Ist es mächtig genug, um die zu erfassenden, semantischen Beziehungen abzubilden? Wie werden die formatierten Daten möglichst verlustarm zwischen verschiedenen, technischen Umgebungen übertragen? Und ist das, was der Aggregierende am Ende aus Symbolstrom und Datenmodell semantisch als Aussage ableitet, wirklich das, was der Erfasser ursprünglich intendiert hat?

Schwierig. Halten wir uns zuerst an die konkreten Fakten: Der gemeinsame Nenner, mit denen die Datenerfasser (die Dokumentenserver) und die Datenzusammenführer (z. B. Open-Access-Netzwerk) ihre Metadaten austauschen, ist (zumindestens hier in Deutschland) noch immer das Metadatenformat „Dublin Core Simple„. Einige Server bieten auch alternative Formate an, aber nicht alle. Welches Format auch immer konkret eingesammelt und verarbeitet wird, es muss irgendwie „ins System“. Also muss es ein Datenmodell geben, was die von außen kommenden Datensätze aufnimmt.

Internes Metadatenformat und Objekterfassung

Die Technik von Open-Access-Netzwerk ist so beschaffen, dass alle ankommenden Daten in ein Internes Metadatenformat gespeichert werden. Das bedeutet wiederum, dass die Harmonisierung in diesem Speicherschritt stattfindet. Da das Filterungen und Interpretationen bedingt, die möglicherweise Information verwerfen, weil sie nicht auswertbar ist, haben wir Harvesting und Aggregation auf separate Komponenten verteilt. Der Datensatz wird zuerst im Originalformat bezogen und einem Objekt innerhalb unseres Systems zugeordnet (bzw. ein neues Objekt erstellt). Dabei wird genau der Datensatz unverändert als BASE64-Blob gespeichert und sein Bitstrom gegen Zeichensatzverluste konserviert. Die Aggregation, die Umsetzung ins Interne Metadatenformat, findet erst in einem Folgeschritt statt.

Im Vorübergehen haben wir jetzt einen wichtigen Punkt gestreift: Wie ist die Datenhaltung strukturiert bzw. was ist ein Objekt? Ein Objekt in Open-Access-Netzwerk ist immer genau das, was ein Datensatz abbildet. Im günstigsten Fall ist das genau ein Dokument. Wie genau der Dokumentbegriff zu fassen ist und welche Ausnahmen dabei in der Praxis auftreten, führt in eine tiefere Diskussion. Halten wir an der Stelle einfach fest, dass ein Objekt einem Datensatz entspricht und dieser Datensatz in der Mehrheit aller Fälle genau ein Dokument (eine Publikation) beschreibt.

Um nun aus dem registrierten Metadatensatz im Originalformat einen Datensatz des Internen Metadatenformats zu aggregieren, setzt Open-Access-Netzwerk eine eigene Software-Komponente als Aggregator ein. Diese ist so implementiert, dass später neben Originaldaten in Dublin Core Simple auch andere Formate geparst werden können. Aktiv ist jedoch im Moment nur ein Interpreter für den besagten, gemeinsamen Nenner Dublin Core Simple. Alternative Formate in den Prozess einzubeziehen, machte momentan nur Sinn, wenn man dadurch mehr Datensätze aufnehmen könnte. Das ist nicht der Fall. Einfach alternative Formate für bereits durch Dublin Core Simple beschriebene Objekte auszuwerten, stellt die Frage, wie beide (gewissermaßen konkurrierende) Formate in eine gemeinsame Beschreibung (das Interne Metadatenformat) abgebildet werden. Dafür gibt es noch kein zufriedenstellendes Lösungskonzept.

Harmonisierung = Informationsverlust? Smart Up!

Wie bereits angedeutet, ist der große TradeOff bei der Aggregation, die Balance zwischen „Was verwerfe ich, weil es für mich Rauschen bzw. Abweichungen zum erwarteten Standard darstellt?“ und „Was bewahre ich zusätzlich, auch wenn noch unklar ist, wozu ich es später parallel zu den benutzten Standards als Information habe?“

Man muss sich klarmachen, dass wenn wir sagen, wir beziehen einen Metadatensatz in Dublin Core Simple, dann haben wir zum Zeitpunkt der Aggregation ein XML-Dokument, welches in seinen Elementen die Metadatenfelder benennt und ihre Werte mit Zeichenketten ausdrückt. Was in diesen Zeichenketten steht, ist jetzt die große Frage. Weder bildet das XML-Schema ab, welche Kodierung für die Zeichenkette gilt, um von diesem primitiven Datentyp z.B. auf eine Datumsangabe zu kommen, noch welches Datum hier semantisch erfasst wurde. Erstellungsdatum des Dokuments? Publikationsdatum? Datum der letzten Änderung? Komplexere Formate wie Dublin Core Qualifed machen sich genau über diese beiden Punkte mehr Gedanken. Deren Datenmodell ist komplexer, ausdrucksmächtiger. Aber auch daran hängen im Grundsatz die selben Fehlermöglichkeiten, ganz zu Schweigen von der Problematik der Altbestände, die „unschärfer“ beschrieben sind.

Im Umfeld des besagten Dublin Core Qualifed wird bisweilen der Begriff des „Dumb-Down“ verwendet. Er adressiert das Problem unterschiedlich detaillierter Metadaten und wie man damit umgeht. Bei Open-Access-Netzwerk stellen wir den Gedanken auf den Kopf. Wir machen gewissermaßen ein „Smart-Up„. Fakt ist, wir wollen bei der Harmonisierung Daten nicht einfach umschreiben, und damit vielleicht Informationen verlieren oder falsche Interpretationen einbauen, sondern Daten mit Mehrwerten anreichern. Die Metadatenfelder im Internen Metadatenformat sind daher – auch wenn das Konzept in der vorliegenden Implementierung noch nicht perfekt überall eingehalten wurde – kleine „Smart-Up„-Container aus Originalwert und harmonisiertem Wert.

Der harmonisierte Wert darf dabei leer sein, wenn er nicht sinnvoll ermittelbar ist. Der Originalwert wird nicht mit einer Interpretation überschrieben und bleibt für alternative Deutungen mundgerecht zugreifbar. Vor allen Dingen kann man ihn einem menschlichen Nutzer wieder zur Anzeige bringen, der kann damit vielleicht intellektuell noch eine Mehrinformation herauslesen.

Mal ein Beispiel: Sprachkennung

In Dublin-Core-Simple-Metadatensätzen gibt es ein Feld „language„. Da soll in der Regel semantisch vermerkt sein, in welcher Sprache der Volltext vorliegt. Faktisch ist es jedoch eine Zeichenkette beliebiger Kodierung. Beim Aggregator kommen also wild gemischt natürlich sprachliche Begriffe, Kürzel konkurrierender Kodierungsstandards oder einfach falsch eingetragene oder falsch übertragene Kodierungen an. (Ja, auch die OAI-PMH-Schnittstelle kann die in der Datenbank eines Dokumentenservers abgelegten Werte falsch in den „Container“ des auszuliefernden Metadatenformats einfügen. Solche serienmäßigen Fehler kann man jedoch im Gegensatz zu Ungenauigkeiten der initialen Metadaten-Erfassung leicht identifizieren und abstellen.)

Open-Access-Netzwerk möchte das Metadatum der Sprachkennung gerne mit einer ISO-standardisierten Kodierung notieren. Das ist in dem Fall ISO-639-2, ein eindeutiger, dreibuchstabiger Code, dessen Interpretation in der Zuordnung zu einer Sprache weltweit nachlesbar ist. Für die Sprache „Deutsch“ gibt es das ISO-639-2 Kürzel „deu“. Ist in einem Wert also die Zeichenkette „Deutsch“ enthalten, soll auf „deu“ abgebildet werden. Leider gibt es im Standard auch den alternativ gültigen Wert „ger“. (Einige wenige Sprachkennungen haben nämlich nach terminologisch (ISO 639-2/T) und bibliografisch (ISO 639-2/B) synonyme Werte. Aber das kann man ja abbilden.)

So, ignorieren wir Case-Sensitivität, bilden zweibuchstabige Codes (ISO 639-1) auf die höhere Kodierung ab, ordnen natürlich sprachliche Begriffe den korrespondierenden Kürzeln zu, dann sind wir schon einen Schritt weiter. Dank Smart-Up-Container haben wir ja später immer den Original-Wert. Bei „Deutschland“ wäre „deu“ als Wert relativ unstrittig. (Obwohl in Deutschland nicht nur deutsch gesprochen und publiziert wird und der Wert eigentlich uneindeutig ist.) Bei „Schweiz“ wäre es noch komplizierter, da man auch auf die Werte von „Italienisch“ oder „Französisch“ abbilden könnte. Allein, dass „Schweiz“ selbst ein deutsches Wort ist, könnte man als Hinweis werten. Doch da endet die implementierte Heuristik unserer Harmonisierung. Am besten würde hier eine nachgeschaltete Sprachprüfung des Volltextes helfen, die die Werte zusätzlich am Volltext nachprüft, anstatt sie nur zu harmonisiseren.

Der Vollständigkeit halber sei noch erwähnt, dass auch die Spezialwerte des Standards verwendet werden: Mit mul (von englisch multiple languages für „mehrere Sprachen“), der für die Auszeichnung mehrerer Sprachen gedacht ist, wenn eine Kennzeichnung durch alle einzelnen Kennungen nicht angebracht ist, sowie und (von englisch undetermined für „unbekannt“) für eine nicht identifizierbare Sprache gibt es zwei besondere Kennungen. Mit mis kann man angeben, dass die Kennung generell fehlt, und sie nicht einfach weglassen. Das grenzt Leerkennungen von bloßen Fehlern ab.

Andere Beispiele sind Datumswerte, die nach ISO8601 normiert werden müssen, oder die Dewey-Dezimalklassifikation (DDC), die mit den Set-Strukturen der OAI-PMH-Records übertragen werden. Nicht alle Set-Strukturen sind sofort als Wert von DDC, DNB oder DINI-Standard interpretierbar und werden ggf. als „OtherClassification“ aufbewahrt. Die Volltextlinks, die aus den Identifiern gezogen und dahingehend überprüft werden, ob sie zu einem vermutlich zugehörigen Volltext führen, schlagen in die gleiche Kerbe. Wie gesagt, Open-Access-Netzwerk wirft nach Möglichkeit nichts weg. Anreicherung ist die Prämisse.

Das Problem an der Wurzel packen – DINI-Zertifizierung

Die handfesten Erfahrungen mit den ankommenden Daten zeigen, dass man an vielen Stellen Hand anlegen kann, um die Qualität der Metadaten zu erhöhen und dass Forschung und Entwicklung  (s. Testbett-Aspekt) in Fragen der Harmonisierung noch Fortschritte erzielen kann. Verglichen mit Projekten, die sich auf ganz andere Datenquellen bzw. ein viel größeren Datenraum stützen, hat Open-Access-Netzwerk eine ganz entscheidende Erleichterung: Die DINI-Zertifizierung.

Die OAI-PMH-Schnittstelle wird kontrolliert, Dublin Core Simple ist als gemeinsamer Nenner Pflicht, es gibt Empfehlungen, welche Werte wie auszufüllen sind, Klassifikationen werden per Set-Struktur übertragen. Das alles macht das Leben als Aggregator so viel leichter. Wenn man jemals zu komplexeren Formaten als Dublin Core Simple kommen will, muss man schon an dieser Stelle beginnen, Richtlinien zu schaffen und vor allen Dingen eine organisatorische Infrastruktur schaffen, um diese Richtlinien einzuhalten und in Hinblick auf zukünftige Entwicklungen auszubauen. Auch da setzt Open-Access-Netzwerk immer wieder an. Das Netzwerk ist eben nicht nur – auch wenn es durch die technische Orientierung des Autors oft den Anschein haben mag – eine technologische Infrastruktur.

Eines der großen Ziele für kommende Projektphasen soll daher auch sein, den Bezug der neuen DRIVER Guidelines für Content Provider zum DINI-Zertifikat besser zu klären. Ein großer Abschnitt darin (Kapitel S.52) befasst sich mit der immer wiederkehrenden Thematik, wie Dublin Core Simple denn zu benutzen und günstigerweise strikter zu handhaben ist. Auch wenn hier bisweilen noch einige DRIVER-spezifische Zusatzannahmen getroffen werden, die gerade auch im Kontext des DINI-Zertifikates diskutiert werden müssen: Dieses Kapitel sollte jeder Data Provider einmal gelesen haben! Es beantwortet wichtige Fragen. Bei der Implementierung der Harmonisierung lag eine gedruckte Version immer neben den Begleitempfehlungen zum DINI-Zertifikat griffbereit.

Weiterführende Gedanken

Zuletzt noch ein paarAnmerkungen, die in die Thematik der Harmonisierung hineinspielen. Einerseits möchte ich den, meiner persönlichen Meinung nach sehr mächtigen (wenn auch sehr aufwändigen) Ansatz erwähnen, die Methoden der Harmonisierung repositorienabhängig zu gestalten. Meines Wissens nach zielt DRIVER darauf ab bzw. ist bereits an der Umsetzung einer solchen Aggregation. Anstatt einer gemeinsamen Heuristik für alle Datenquellen, kann man in DRIVER angeblich jede Datenquelle einzeln durch Mapping-Dateien „finetunen“. Fündig wird man wohl unter dem Begriff „transformation rules“. Ein guter Ansatz, und auf paneuropäischer Ebene (ohne die Erleichterungen der DINI-Zertifizierung) wahrscheinlich unumgänglich. Open-Access-Netzwerk stützt sich eher auf das Prinzip der Anreicherung, so dass im Datenknoten möglichst viele Daten erhalten bleiben.

Als Zweites stellte sich im Zuge der Implementierung die Frage, ob jemals konkret durch ein Projekt untersucht wurde, wie man bereits durch die Gestaltung der Technologien der Dokumentenserver während der Erfassung Fehler minimieren und Standard-Einhaltung anregen, wenn nicht gar forcieren kann. Warum – ganz ketzerisch gefragt – ist es überhaupt möglich, in ein Feld, das eine Sprachkennung aufnehmen soll, Freitext einzufügen? Warum gibt es da nicht serienmäßig eine Auswahlbox für ISO-Werte? Wenn unbedingt Freitext gewünscht ist, dann nur als optional auszufüllender Zusatz zum Striktwert. Das gleiche gilt für viele andere Werte. Ein optionaler (in der Repository-Software zuschaltbarer) strikt-Modus für die Eingabe-Oberflächen würde bereits dort die Datenqualität erhöhen.

Unterm Strich wäre es wirklich spannend zu erfahren, wo und wie die Fehler eigentlich entstehen und wie man Guidelines und Empfehlung dem Erfassenden zum Zeitpunkt der Ersteingabe wirklich präsent und praktisch umsetzbar macht. Mensch-Maschine-Interaktion ist doch kein neues Themenfeld. Da gibt es etablierte Methoden und Leute, die sich damit auskennen.

(-rm)

Die drei Bedeutungsaspekte der Technik

Es geht bei der Rechercheoberfläche nicht um den Versuch, die eine Killerapplikation zu erschaffen, welche alle anderen in den Schatten stellt und erfolgreich mit Google Scholar, BASE oder DRIVER konkurriert. Abgesehen davon, dass die Ressourcen eines einzelnen Projektes dafür gewiss nicht ausreichen würden, müsste man ernsthaft in Frage stellen, ob dies in einer dynamischen Umgebung noch möglich bzw. sinnvoll ist.

Was die Technologie von Open-Access-Netzwerk jedoch sehr wohl für die Open-Access-Bewegung auf der einen Seite und den Wissenschaftlern auf der anderen Seite leisten soll, lässt sich am leichtesten mit drei Kernaspekten umschreiben, drei Facetten bzw. Sichtweisen, die sich wechselseitig beeinflussen:

drei Aspekte von OAN

drei Aspekte von OAN

Es ist ein Knoten, weil es auf einer übergeordneten Daten sammelt, verbessert und als Kollektion bereitstellt. Dazu wird die implementierte REST-Webservice API offengelegt werden, um diese Daten auch jenseits der OAI-PMH-Mechanismen abzurufen und in anderen Kontexten nachzunutzen. Langfristiges Ziel ist ferner, technische Möglichkeiten zu finden und anzuwenden, um die Daten in übergeordneten Netzwerken wie DRIVER verfügbar zu machen.

Es ist ein Portal, in dem die Daten des Knotens exemplarisch Mehrwertdienste ermöglichen, die den Nutzern Funktionen zur Recherche anbieten. Erst in der praktischen Anwendung lässt sich die Qualität der Daten auf einen Prüfstein stellen, mit dem man konkretes Feedback für die Standardisierungsleistungen des DINI-Zertifikats ableiten kann. Die Verlinkung unter der Open-Access-Informationsplattform sehen wir dabei als wichtigen, organisatorischen Schritt, Open-Access-Vorhaben in Deutschland generell stärker in Kontext zueinander zu setzen.

Es ist ein Testbett, denn wo sonst kann Hilfe bekommen, um anhand der Echtdaten Forschung und Entwicklung zu betreiben? Das beste Modell der Wirklichkeit ist die Wirklichkeit selbst. Das gilt auch für den Datenraum mit all seinen verbleibenden Fehlern und Ausnahmen aber auch seinen Chancen. Erst in der Aggregation kann man experimentieren, welche neuen Mehrwerte die Open-Access-Welt aus der Möglichkeit der freien Verfügbarkeit von Volltext und Metadaten ziehen kann. Dublettenerkennung, automatische Fachklassifikation und verbesserte Harmonisierung sind hier Schlüsselworte.

(-rm)