Dass dieser Blog in den vergangenen Monaten in einen Dornröschenschlaf versunken ist, hat nicht nur mit meiner inzwischen chronisch gewordenen Arbeitsüberlastung zu tun, sondern auch damit, dass es derzeit sehr schwierig ist, sinnvoll über die aktuellen Entwicklungen im 3R-Projekt zu berichten. Zwar gab es seit dem ersten Erscheinen der Beta-Version mehrere Updates, aber es ist weiterhin nicht so richtig klar, welche Textteile nun schon endgültig sind, was noch verändert werden wird und was an Textmaterial noch dazu kommen wird. Eine richtige Gesamtschau auf das "neue" Toolkit wird deshalb wohl erst möglich sein, wenn der englische Text stabil sein wird. Nach dem aktuellen Zeitplan soll dies im April 2019 der Fall sein (vgl. RSC/Chair/21). Auch fehlen weiterhin wichtige Toolkit-Funktionalitäten, insbesondere das grafische Navigationstool, um sich in den zu einer Entität gehörenden Elementen bewegen zu können - im Moment gibt es nur eine wenig hilfreiche alphabetische Elementeliste, in der auch gesucht werden kann (allerdings bedauerlicherweise nur in Form einer Phrasensuche, d.h. man muss den Anfang des Namens richtig eingeben).

Wir müssen außerdem davon ausgehen, dass auch im April nächsten Jahres das neue Toolkit nicht wirklich fertig sein wird, denn offenbar werden manche schwierigen Punkte in eine "Post 3R"-Phase verschoben werden (vgl. dazu eine neue Präsentation von Kathy Glennan, dort Folie 10). Ich könnte mir vorstellen, dass dazu beispielsweise das knifflige Thema der "Aggregates", also der Zusammenstellungen, gehören wird, für die das IFLA LRM eine gegenüber FRBR deutlich veränderte theoretische Sicht eingeführt hat (vgl. Folien 22-27 in Kathys Präsentation).

Trotzdem denke ich, dass es Zeit wird, sich etwas intensiver mit dem zu beschäftigen, was auf uns zukommt. Für den jetzigen Blog-Beitrag habe ich mir das "Outcomes"-Dokument vom letzten RSC-Treffen im Oktober 2018 in Madrid näher angeschaut und werde dieses kommentieren, soweit ich es vermag. Wie immer, beschränke ich mich dabei auf eine Auswahl von Punkten, die mir besonders interessant und wichtig erscheinen.

Zeitplan

Zum Zeitplan habe ich weiter oben schon einiges gesagt. Im "Outcomes"-Dokument steht auch nicht viel mehr dazu drin, aber im schon erwähnten Dokument RSC/Chair/21 sowie in Kathys Präsentation (Folie 10) gibt es weitere Infos: Der "Meilenstein" vom April 2019 bedeutet definitiv nicht, dass das 3R-Projekt damit abgeschlossen ist. Vielmehr können dann erst die ÜbersetzerInnen und diejenigen, die sich um die Anwendungsrichtlinien kümmern, richtig loslegen. Erst, wenn hier ein ausreichender Stand erreicht sein wird (bei den Übersetzungen wird man dabei wohl insbesondere auf die beiden "Leitübersetzungen" Französisch und Deutsch schauen) und wenn die Verantwortlichen ("RSC, RDA Board, and the copyright holders") sich darüber auch einig sind, wird das neue Toolkit zum offiziell gültigen erklärt werden. Kathy Glennan hat als mögliches Datum dafür "Late 2019?" auf ihre Folie geschrieben, was ich für sehr optimistisch halte. Ab diesem Zeitpunkt soll dann die Ein-Jahres-Frist laufen, innerhalb der das bisherige Toolkit noch zur Verfügung steht, um allen Anwendergemeinschaften den Umstieg zu ermöglichen.

Application profiles

Im "Outcomes"-Dokument wird - nicht zum ersten Mal - betont, dass man künftig zwingend ein "Application profile" haben muss, um das neue RDA sinnvoll anwenden zu können:

"The effective use of RDA will require an application profile to communicate specific community choices among options. An application profile provides a general framework for defining what RDA elements a community uses."

Der Begriff des "Application profiles" kommt aus der Welt der Metadaten. Marcia Zei Leng und Jian Qin schreiben dazu in ihrem Buch "Metadata" (2. Auflage von 2016, S. 54), allgemeine Metadaten-Schemata wie Dublin Core seien oft "too limited to meet specialized user requirements and local needs within a particular community or within a particular project" und müssten deshalb an die jeweiligen Erfordernisse angepasst werden. Dafür entwickelt man dann ein "Application profile", in dem man z.B. Elemente aus unterschiedlichen Metadaten-Schemata kombinieren und bei Bedarf noch mit selbst-geschaffenen Elementen ergänzen kann. Typischerweise werden darin auch Anwendungsregeln dokumentiert, z.B. ob Elemente verpflichtend oder fakultativ sind, ob sie wiederholbar sind, wie sie genau zu erfassen sind und ggf. welches Vokabular dafür zu verwenden ist.

Ein gutes Beispiel für ein solches Application profile ist das der South Carolina Digital Library, einer großen virtuellen Bibliothek für digitalisierte Ressourcen aus den Beständen zahlreicher Institutionen. Das dafür entwickelte Application profile beinhaltet 26 Elemente; die Dokumentation umfasst 40 Seiten. Blättern Sie ruhig mal rein, um sich einen Eindruck davon zu verschaffen!

Als Ausgangspunkt für unser künftiges Application profile für RDA kann sicher das Standardelemente-Set verwendet werden. Darin haben wir ja schon dokumentiert, welche Elemente verpflichtend sind (zur Erinnerung: im neuen Toolkit gibt es das Konzept der Kernelemente nicht mehr). Es müssten dann noch weitere Informationen ergänzt werden, z.B. zu den jeweils zu verwendenden "Recording methods" (vgl. dazu meine Präsentation vom Bibliothekartag, Folien 16-19), zu den anzuwendenden Optionen und evtl. auch zu den Informationsquellen für das jeweilige Element (dazu später mehr). Wie das genau aussehen wird und wie das Zusammenspiel zwischen dem neuen Application profile und den D-A-CH AWR sein wird, muss aber erst im Detail ausgearbeitet werden.

Arten der Beschreibung: umfassend, analytisch, hierarchisch

In RDA 1.5 (Art der Beschreibung) werden bekanntlich drei Beschreibungsarten erläutert, die vor allem bei Ressourcen relevant sind, die aus mehreren Teilen bestehen: Bei einer umfassenden Beschreibung gibt es nur eine Beschreibung für das Ganze (also im Echtsystem: nur einen einzigen Datensatz), bei einer analytischen gibt es nur Beschreibungen für die Teile und bei einer hierarchischen Beschreibung gibt es sowohl einen Datensatz für das Ganze als auch einen Datensatz für jeden Teil, wobei die beiden Ebenen miteinander verknüpft werden.

Im "Outcomes"-Dokument heißt es nun:

"Comprehensive/analytical/hierarchical description. These concepts have been replaced by a new framework: minimal description, effective description, and coherent description. More information is available in the beta Toolkit in the guidance chapter on Resource description."

Man findet die fraglichen Stellen, wenn man auf der Beta-Site auf "Guidance" geht und dort "Resource description" auswählt. Leider ist es mir auch nach mehrfacher Lektüre nicht gelungen, diese Stellen zu verstehen. Mein Eindruck ist, dass es hier um ganz andere Dinge geht als bei dem, was wir bisher mit den Beschreibungsarten verbunden haben. Ich hoffe, dass entweder irgendwann bei mir noch der Groschen fällt oder ich jemanden finde, der es mir erklären kann.

Informationsquellen

Im bisherigen Toolkit gibt es bei jedem Element eine Regelwerksstelle zu den zu verwendenden Informationsquellen (wobei zugegebenermaßen in vielen Fällen die Angabe nur heißt: "Nehmen Sie Informationen zu ... aus einer beliebigen Quelle"). Schon vor längerem war angekündigt worden, dass es im neuen Toolkit keine solchen Regeln mehr geben wird, sondern nur noch allgemeine Ausführungen zur Wahl von Informationsquellen in den "Guidance"-Kapiteln. Ich hatte deshalb erwartet, dass früher oder später dort noch ein Punkt "Sources of information" ergänzt wird. Beim Lesen des "Outcomes"-Dokuments habe ich nun festgestellt, dass dieser allgemeine Text bereits im neuen Toolkit vorhanden ist - nämlich als Teil des "Guidance"-Kapitels "Data provenance".

Ungefähr ab der Mitte dieser Seite kommen tatsächlich entsprechende Regeln. Wie im neuen Toolkit insgesamt, ist die Darstellung leider auch hier extrem unübersichtlich und wegen des eigentümlichen Sprachstils nur schwer verständlich. Schauen wir uns dafür beispielhaft den folgenden Ausschnitt an. Schwierig ist es dabei immer schon herauszufinden, welche der bunten Kästen eigentlich zusammengehören. Ich habe den Ausschnitt nun schon sinnvoll gewählt, denn an der Überschrift "A source of metadata is a manifestation that is being described" beginnt ein neuer logischer Abschnitt, nämlich für den Fall, dass die Ressource selbst die Quelle der erfassten Informationen darstellt. Besonders irritierend finde ich an dieser und vielen anderen Stellen die Verwendung des unbestimmten Artikels. "Eine Quelle der Metadaten ist eine Manifestation, die beschrieben wird"?? Mit dem bestimmten Artikel wäre es viel verständlicher: "Die Quelle der Metadaten ist die Manifestation, die beschrieben wird."

Die Überschrift soll wohl nur bei der Gliederung helfen; im ersten hier abgebildeten gelben Kasten wird die Bedingung wiederholt. Beachten Sie dabei den Ausdruck "Metadata work" - die erfassten Metadaten stellen in der Logik des neuen Toolkit nämlich ein eigenes Werk dar. Die Regel lautet sodann, dass man die verwendete Informationsquelle im Element "Recording source" erfasst. Beispielsweise könnte dies ein Begriff wie "Titelseite" oder "Behältnis" sein (es gibt dafür auch ein neues normiertes Vokabular). Freilich ist dies - wie so ziemlich alles im neuen RDA - nur eine "Option", d.h. man muss es nicht so machen. Ich könnte mir vorstellen, für den D-A-CH-Raum eine Regelung zu haben, die das Erfassen der "Recording source" nur in bestimmten Fällen erfordert (insbesondere wenn die Angabe von einer unerwarteten Stelle kommt).

Der unscheinbare Satz "A manifestation may carry more than one source of information for the value of an element" ist wichtig, weil es ab hier um einen anderen Fall geht: Die fragliche Information ist in der Ressource an mehreren Stellen vorhanden, z.B. ist der Verlagsname sowohl auf der Titelseite als auch auf deren Rückseite genannt. Es geht jetzt also um die Hierarchie der Informationsquellen innerhalb einer Ressource. Warum dies nicht auch als "Condition" markiert ist, ist mir unklar. Der darunter stehende graue "Option"-Kasten ist dann eigentlich eine Überschrift für das Nachfolgende: In diesem Fall wenden Sie die nachfolgenden Regeln - uups, natürlich "Options"! - an. In den folgenden "Condition"-Kästen (von denen ich nur die ersten beiden abgebildet habe) steht immer, um welche Art von Ressource es sich handelt. Zunächst geht es um Ressourcen, die aus mehreren Seiten o.ä. bestehen. Dann gilt die beschriebene Rangfolge, die mit der Titelseite beginnt. Im nächsten gelben Kasten geht es wiederum um Ressourcen, die aus Seiten o.ä. bestehen - jetzt aber kommt als zusätzliche Bedingung hinzu, dass es sich um einen Alten Druck handelt. Vergleichen Sie dazu mal die Darstellung im jetzigen Toolkit bei RDA 2.2.2.2; dort wurde die Regel für die Alten Drucke noch als "Ausnahme" (Exception) geführt.

In vielen Fällen wird die allgemeine Hierarchie der Informationsquellen vermutlich tatsächlich ausreichend sein. Eine Ausnahme könnte z.B. der Erscheinungsort sein, der gemäß der bisherigen Regel (RDA 2.8.2.2) von derselben Informationsquelle genommen werden soll wie der Verlagsname. In einem solchen Fall könnte man die Regel im Application profile dokumentieren, wie es auch das "Outcomes"-Dokument vorsieht: "Application profiles for specific communities can provide detailed guidance about sources of information where desired."

Beziehungskennzeichnungen

Eine wichtige Änderung im neuen Toolkit ist, dass die Unterscheidung zwischen Beziehungselementen wie "Geistiger Schöpfer" und zugehörigen Beziehungskennzeichnungen wie "Verfasser" oder "Künstler" aufgegeben wird. Die bisherigen Beziehungskennzeichnungen stellen nunmehr eigene, dem bisherigen Element hierarchisch untergeordnete Elemente dar. Übersichten kann man sich unter "Resources" beim Punkt "Relationship Matrix" abrufen. Die folgende Abbildung zeigt einen Ausschnitt aus der Matrix für "Agent to Work". Es sieht zwar so aus wie der Anhang I, ist aber faktisch etwas ganz anderes, weil hier nicht Bezeichnungen, sondern Elemente aufgelistet sind.

Vor diesem Hintergrund sind Wünsche nach Ergänzungen in diesem Bereich problematischer als bisher: Denn jede Ergänzung bedeutet künftig nicht mehr nur eine zusätzliche Funktionsbezeichnung, sondern ein zusätzliches Element. Im "Outcomes"-Dokument heißt es dazu: "The RSC discussed granularity of relationship elements in RDA and expressed concern about the potential for infinite sub-typing. There may be a solution in cataloguers creating a separate description for important but granular resources."

Zitiernummern

Bekanntlich hat das RSC beschlossen, dass es im neuen Toolkit keine Nummerierung mehr geben soll. Die Begründung dafür kann man im Dokument RSC/Papers/1 nachlesen. Neben den durchaus nachvollziehbaren praktischen Problemen, die sich bei Regelwerksänderungen ergaben, werden hier auch grundsätzliche Überlegungen angeführt. Insbesondere hat das RSC entschieden, "that all entities and elements need to be presented equally, to avoid implicit priority or importance". Ich persönlich halte dies für eine realitätsferne Vorgabe. Denn es mag zwar von der Theorie her richtig sein, dass alle Elemente gleichwertig sind, aber in der alltäglichen Katalogisierungspraxis und auch beim Unterrichten und Erlernen eines Regelwerks wie RDA gibt es natürlich Elemente, die wichtiger sind als andere - schon alleine deshalb, weil sie praktisch in jeder Beschreibung vorkommen, während andere nur selten gebraucht werden. Eine kleine Anekdote mag dies illustrieren: Als ich im letzten Semester in meinem Wahlmodul "Vertiefung zur Formalerschließung" die Studierenden ein bisschen mit der Beta-Site herumspielen ließ, fragte ein Teilnehmer: "Wo sind denn die Elemente, die wir kennen?". In der Tat gehen diese besonders gängigen Elemente in dem Meer der insgesamt vorhandenen Elemente völlig unter.

Das RSC ist aber der Meinung, dass eine durch eine Nummerierung unterstützte logische Anordnung nicht mehr nötig ist. Im gerade zitierten Dokument werden der alte und der neue Ansatz folgendermaßen miteinander kontrastiert: Im bisherigen Toolkit hätten die Regelwerksnummern "as the organizational structure, including conveying hierarchies and a logical order" gedient. Für das neue Toolkit gelte hingegen: "With all entities and elements presented equally, RDA no longer has a hierarchical structure. Cataloguer workflows can start at any point."

Immerhin hat das RSC mittlerweile eingesehen, dass es z.B. für gedruckte Materialien oder Lehrbücher eine Möglichkeit geben muss, mit einer einigermaßen kurzen Zeichenfolge eine bestimmte Regelwerksstelle genau zu referenzieren. Dafür sollen nun sogenannte Zitiernummern (Citation numbers) eingeführt werden, was auf dem Treffen in Madrid bestätigt wurde. Soweit ich gehört habe, wird es sich bei diesen Zitiernummern allerdings - vermutlich ganz bewusst! - um völlig beliebige Zahlenkombinationen handeln, die in keiner Weise "lesbar" sein werden. Schön wird das sicher nicht werden.

Künftiges Review-Verfahren

Als letzten Punkt greife ich noch das künftige Review-Verfahren heraus. Das frühere, sehr aufwendige, aber auch sehr transparente Proposal-Verfahren war ja für die Zeit des 3R-Projekts ausgesetzt worden. Wie wir mittlerweile wissen, wird es in dieser Form auch nicht mehr zurückkommen, weil es "not fast enough nor responsive enough" sei. Es soll stattdessen möglich sein, Änderungen in kürzeren Abständen einzupflegen - angestrebt werden künftig vier Releases im Jahr. Die Details müssen aber wohl erst noch ausgearbeitet werden.

Das soll für heute genügen. Vielleicht schaffe ich es in der nächsten Zeit, in einer kleinen Serie einzelne Aspekte des neuen Toolkit näher zu beleuchten und zu erklären (soweit ich sie selbst schon verstanden habe...).

Heidrun Wiesenmüller