Neues, konsolidiertes FRBR-Modell: FRBR-LRM (Teil 2)

Willkommen zum zweiten Teil meines Überblicks zum vorgeschlagenen neuen, konsolidierten FR-Modell "FRBR-LRM"! Als Grundlage dient wieder der Entwurf, der jetzt in die weltweite Kommentierung gegangen ist. Die Entitäten von FRBR-LRM wurden bereits im 1. Teil des Blog-Beitrags vorgestellt. In diesem Teil geht es einerseits um die "user tasks", also die Benutzeranforderungen, und andererseits um die in FRBR-LRM definierten Merkmale. Hier zunächst die Benutzeranforderungen im Überblick (Draft, S. 9):

Die fünf "user tasks" aus FRBR-LRM
Die fünf "user tasks" aus FRBR-LRM

Benutzeranforderungen

Die ersten vier "user tasks" - finden, identifzieren, auswählen, Zugang erhalten - gab es bereits in FRBR. Die fünfte Benutzeranforderung ist auch nicht ganz neu: In FRAD hieß sie "in den Kontext einordnen" ("contextualize"), in FRSAD "explorieren" ("explore"). Nicht übernommen wurde hingegen "begründen ("justify") aus FRAD ("Document the authority data creator’s reason for choosing the name or form of name on which a controlled access point is based"). Das Argument dafür ist, dass sich dies nicht auf Endnutzer bezieht, sondern auf Katalogisierer.

In den Definitionen gibt es merkliche Unterschiede. Das kann man sehr gut am Mapping zwischen den FR-Modellen nachvollziehen. Auffällig finde ich dabei, dass FRBR-LRM immer nur von Ressourcen spricht, wo die früheren Modelle das allgemeinere Wort Entitäten verwendeten. Man vergleiche etwa die Definitionen für "identifizieren" in FRBR ("to identify an entity (i.e., to confirm that the entity described corresponds to the entity sought, or to distinguish between two or more entities with similar characteristics") und FRBR-LRM ("to clearly understand the nature of the resources found and to distinguish between similar resources"). Allerdings heißt es am Anfang des Kapitels zu den Benutzeranforderungen: "the term 'resource' is used very broadly to stand for any of the entities defined in the model, as well as actual library resources" (Draft, S. 11). Das Identifizieren muss sich also nicht zwingend auf die WEMI-Entitäten beziehen, sondern gilt z.B. auch auf für "Agents" ("Ich suche Bücher von XY - habe ich den richtigen XY im Katalog gefunden?"). Nichtsdestoweniger halte ich die Verwendung von Ressource hier für sehr unglücklich, weil sie Missverständnisse geradezu herausfordert. Ich hatte es selbst auch erst falsch verstanden und habe erst beim genaueren Hinsehen gemerkt, dass gar keine Einengung des Bedeutungsumfangs beabsichtigt ist. In der deutschen Stellungnahme sollten wir deshalb eine Änderung der Formulierungen und die Verwendung des breiteren Begriffs Entitäten empfehlen.

Merkmale

Wie man es aus den anderen FR-Modellen kennt, bietet auch FRBR-LRM eine Übersicht von Merkmalen der verschiedenen Entitäten. Wie alles in FRBR-LRM, sind auch diese sozusagen "durchnummeriert". Im ersten Blog-Beitrag hatte ich vergessen, darauf eigens hinzuweisen: Beispielsweise hat die Entität "Res" die Nummer LRM-E1, die Entität "Werk" hat LRM-E2 usw. Bei den Merkmalen (Draft, S. 24-42) wird statt eines "E" ein "A" (für "attribute") verwendet. So ist etwa LRM-A1 das Merkmal "Category", das sich auf die Top-Level-Entität "Res" bezieht. Es gibt in den Tabellen jeweils eine Definition (hier z.B. "A type to which the res belongs"), außerdem häufig "scope notes" und in jedem Fall Beispiele. Die Liste der Merkmale hat keinen Anspruch auf Vollständigkeit hat; man kann jederzeit weitere Merkmale definieren. Betont wird außerdem, dass man aus der Auflistung eines Merkmals nicht schließen kann, dass dieses verpflichtend wäre (Draft, S. 24).

Alle Merkmale einer übergeordneten Entität gelten automatisch auch für die hierarchisch untergeordneten Entitäten (Draft, S. 24). Z.B. gelten alle Merkmale der übergreifenden Entität "Agent" auch für "Person" und "Collective Agent". Allerdings ist das Merkmal "Category" offenbar bewusst für mehrere Entitäten definiert worden (z.B. beim Werk: LRM-A3, bei der Expression: LRM-A4, bei Ort/Geografikum: LRM-A34; vgl. Draft, S. 24) - warum, verstehe ich ehrlich gesagt nicht so ganz. Die Beispiele zu "Category" deuten an, dass man mit diesen Elementen ganz unterschiedliche Einteilungen realisieren kann. Bei Werken kann man hier etwa die Unterscheidung nach der Erscheinungsweise (z.B. monografisch vs. fortlaufend), die "creative domain" (z.B. Literatur oder Musik) oder die Gattung (z.B. Roman, Theaterstück, Gedicht) unterbringen. Bei der Manifestation gibt es die "Category of carrier" (LRM-A13), die u.a. für den Medientyp und Datenträgertyp genützt werden könnte. Vielleicht wollte man dies nicht alles in einziges Merkmal packen.

Insgesamt gibt es 37 Merkmale, die ich hier natürlich nicht alle im Detail vorstellen kann - im Folgenden deshalb nur eine Auswahl. Direkt hinter "Category" steht ein weiteres sehr nützliches allgemeines Merkmal: "Note" (LRM-A2) gilt für alle "Res" und ist ein ganz flexibles Freitextelement. Hier kann man offenbar alles unterbringen, was man nicht in einem spezifischeren Merkmal oder mit einer Beziehung erfassen kann.

Ein besonders interessantes Merkmal bei der Expression ist "Representativity" (LRM-A5). Damit soll ausgesagt werden, ob die fragliche Expression repräsentativ für das Werk ist oder nicht. Entsprechend sind hier auch nur zwei mögliche Werte vorgesehen, nämlich "ja" und "nein". Dahinter steht die Erkenntnis, dass aus der Sicht unserer Nutzer keineswegs alle Expressionen gleichwertig sind, wie es das FRBR-Modell - streng formal gesehen - eigentlich nahelegt. Sondern es gibt stets eine Expression, die das verkörperte Werk besonders gut repräsentiert. FRBR-LRM spricht von "original or 'canonical' expressions, (...) that can be said to best represent the initial intention of the creators of that work" (Draft, S. 62). In den meisten Fällen dürfte die erste Expression in der Originalsprache diese besonders repräsentative Expression sein.

Nebenbei: Bei uns wurde vor einiger Zeit darüber diskutiert, ob in Normdatensätzen für Werke überhaupt ein Sprachcode erfasst werden darf (wie es in der Sacherschließung seit langem Praxis ist) - denn eigentlich ist die Sprache ja kein Merkmal des Werks. Wir haben uns dann auf die Sprachregelung geeinigt, dass der dort erfasste Code eben nicht die Sprache des Werks angibt, sondern "die Sprache, in der das Werk erstmals realisiert wurde, d.h. die Sprache der Original-Expression" (Erfassungshilfe EH-W-01, S. 2, Anm. 1). Damit haben wir die Idee der repräsentativen Expression, wie sie jetzt in FRBR-LRM formuliert ist, eigentlich schon vorweggenommen. Ein weiteres interessantes Merkmal der Expression ist ihr Ausmaß ("Extent", LRM-A6); ähnliches wurde auch schon für RDA vorgeschlagen (vgl. 6JSC/ALA/Discussion/5).

Besonders interessant finde ich auch das Merkmal "Manifestation statement" (LRM-A16): Dieses steht für alle Angaben, die direkt von der Ressource übertragen werden, u.a. also für die Ausgabebezeichnung oder die Veröffentlichungsangabe. Die Granularität ist dabei nicht vorgegeben. Man könnte also die Veröffentlichungsangabe als Ganzes als ein "Manifestation statement" definieren, aber ebensogut auch drei einzelne "Manifestation statements" für Ort, Verlag und Erscheinungsdatum annehmen.

Für "Item" sind nur zwei Merkmale aufgeführt: "Location" (LRM-A19) und "Rights" (LRM-A20). Bei "Agent" sind es "Contact information" (LRM-21), "Field of activity" (LRM-22) und "Language" (LRM-23); bei der "Person" kommt noch "Profession/Occupation" (LRM-A24) dazu. Für den "Collective Agent" sind gar keine spezifischen Merkmale definiert. Falls Sie nun Dinge wie den bevorzugten und die abweichenden Namen vermissen: Dies wird ja in FRBR-LRM nicht als Merkmal ausgedrückt, sondern als eine Beziehung zur Entität "Nomen". Auch Informationen wie Geburtsort, Gründungsdatum etc. sind in FRBR-LRM keine Merkmale, sondern werden als Beziehungen zu den Entitäten "Place" und "Time-Span" modelliert.

Die Entität "Nomen" hat relativ viele Merkmale. U.a. gibt es wieder "Category" (LRM-A25). Hier könnte man u.a. angeben, dass es sich um einen Identifier, einen normierten Sucheinstieg, ein Pseudonym oder auch um einen Rückentitel handelt - denn "Nomen" gilt ja für alle Entitäten. Im Merkmal "Scheme" (LRM-A26) könnten wir beispielsweise sagen, dass es sich um ein "Nomen" aus einer bestimmten Klassifikation, einem Thesaurus oder einer Normdatei (z.B. der GND) handelt. Das Merkmal "Context of use" (LRM-A28) hatte ich schon im ersten Blog-Beitrag im Zusammenhang mit den Pseudonymen erläutert. Außerdem gibt es Merkmale wie die Quelle (LRM-A29) oder den Status (LRM-A33) - Dinge, die wir aus der Normdatenarbeit gut kennen.

Bei "Place" sind nur zwei Merkmale definiert: "Category" (LRM-A34), z.B. Stadt oder Land, und "Location" (LRM-A35), was man beispielsweise durch Koordinaten ausdrücken könnte. Die Zeit-Entität "Time-Span" besitzt Anfang (LRM-A36) und Ende (LRM-A37).

Damit soll es für heute genug sein. Die ursprünglich geplanten zwei Blog-Beiträge reichen ganz offensichtlich nicht aus, um auch nur einen groben Überblick über FRBR-LRM zu geben - dafür ist das Modell zu umfangreich und komplex. In einem dritten Beitrag werde ich mich mit den im Modell definierten Beziehungen beschäftigen. Und dann brauche ich voraussichtlich noch einen vierten Beitrag für einige Details, insbesondere für die Behandlung von Aggregaten (die mich nicht überzeugt).

Heidrun Wiesenmüller

Kommentar schreiben

Kommentare: 2
  • #1

    Margarete Payer (Dienstag, 15 März 2016 18:56)

    Liebe Frau Wiesenmüller,
    als erstes: ein sehr großes Dankeschön für Ihre Mühe. Ich schlage mich noch mit dem Entwurf rum.
    Zu den Benutzeranforderungen: für mich steht der Begriff "resource" nicht für eine Einengung sondern für eine allgemeinere Aussage. Vielleicht, weil einem dann gleich die 5 Benutzeranforderungen des Statement of international cataloguing principles einfallen, in denen von "resource" geredet wird. Es ist verständlicher und außerdem würde ich "Entität" automatisch als Einengung empfinden.
    Liebe Grüße
    Margarete Payer

  • #2

    Margarete Payer (Sonntag, 20 März 2016 15:37)

    Betr.: Benutzeranforderungen
    Liebe Frau Wiesenmüller,
    ich finde es schade, dass die Anforderung "justify" aus FRAD gestrichen wurde, denn nicht nur der Bibliothekar ist an einer Begründung für eine Ansetzung interessiert. Insbesondere, wenn man mit außereuropäischen Namen wie z.B. mit indischen und thailändischen Namen zu tun hat, ist eine Begründung hilfreich, will man diese Namen in eine wissenschaftliche Arbeit übernehmen. Besonders wichtig ist dabei nach meiner Erfahrung die Frage, woher die Lebensdaten stammen, bzw. bei unterschiedlichen Angaben, warum bestimmte Daten gewählt wurden.
    Schöne Grüße
    Margarete Payer