RDA-Neuerungen an Textressourcen-Kernelementen

Vorgehen

Bei der TelKo am 25.06.2015 wurden folgende Grundsätze für die Anpassungen der Empfehlungen nach RDA genannt:

• keine Brüche zu Altdaten
• möglichst geringer Anpassungsaufwand

Abschnitt 2.1 Titel

• Titel des Werks (~ "Einheitstitel" in den aktuellen Empfehlungen): aktuell dcterms:alternative [M21 130 / 240]
  Zukünftig liegt hier genau wie an anderen Stellen teilweise ein Literal und teilweise ein GND-URI (betrifft einen Teil der Verbünde und die DNB) vor.
  
  • ist dcterms:alternative nicht mehr angemessen, weil sich die Angabe auf eine andere Entität bezieht?
    Diskussion: Das war im Prinzip inhaltlich vor RDA auch schon so, aber jetzt geht damit stärker einher, dass diese andere Entität auch abgebildet und vor allem darauf gelinkt wird (s.o.). dcterms:alternativ ist sehr unspezifisch.
  • im unconstrained RDA gibt es rdau:P60588 (has preferred title for the resource)
    Sarah Hartmann spricht sich dafür aus, diese zu benutzen, da sie im unconstrained Element Set die richtige Property für den Sachverhalt ist. Das unconstrained Element Set hat aber den Nachteil, dass - weil unconstrained - dadurch nicht deutlich wird, dass es sich bei dem - jetzt auch in einigen Verbünden und an der DNB GND-verlinkten - Werk um eben ein Werk handelt.
    Problem: die Property rdau:P60588 kann nicht als Object-Property mit URI verwendet werden, weil sie wie der Name besagt, auf einen Titel hinweist.
    Andreas Kahl, Carsten Klee: Für beide Fälle sollte dieselbe Property genutzt werden und Literale als solche typisiert werden.
    Adrian Pohl: Findet den Namen der Property irreführend, weil daraus nicht erkennbar ist, dass es sich um den Titel des Werks handelt (im Gegensatz zu einem Titel auf der Vorlage)
  • In den contrained Element Sets gibt es rdam:P30135 (has work manifested, Domain: rdac:manifestation), bzw. rdae:P20231 (has work expressed, Domain: rdac:expression)
    Einigkeit besteht darüber, dass man sie in den zukünftig vorliegen Composite Description Records nicht benutzen könen, weil sonst die implizite Aussage gemacht wird, dass es sich bei der vorliegen Entität um eine Manifestation bzw. eine Expression handelt (sie ist aber tatsächlich eine Mischung aus beidem). Deshalb ist es auch keine Option, diese Properties zu verwenden, wenn eine GND-Verlinkung vorliegt.
  • Gibt es eine bessere Property?
    Adrian Pohl: eine schnelle Recherche liefert dcndl:uniformTitle von der Japanischen National Diet Library. Da die Beschreibung dazu nur auf Japanisch gegeben wird, sollte sie aber nicht übernommen werden.
    Andreas Kahl schlägt vor, notfalls selber eine passende Property einzuführen, wie es die GND-Ontologie auch tut.
    Sarah Hartmann erklärt sich bereit, zum nächsten Treffen einige Möglichkeiten durchzuspielen, die dann weiter besprochen werden können. TODO Sarah
    
  • Wie machen es andere?
    Cornelia Katz: was macht OCLC in schema.org?
    [Nachtrag Jana Hentschke:] Dort wird die Property schema:exampleOfWork verwendet (Beispiel: http://www.worldcat.org/oclc/73718235, wo das Werk, "Samson et Dalila", über die OCLC-Werk-URI http://worldcat.org/entity/work/id/2289216536 referenziert wird). Die Beschreibung dieser Property lautet "A creative work that this work is an example/instance/realization/derivation of." Domain und Range sind schema:CreativeWork ("The most generic kind of creative work, including books, movies, photographs, software programs, etc."), was bedeutet, dass man es nicht als Datatype-Property mit Literalen verwenden kann .
    Die BnF benutzt die mittlerweile abgeschaffte Property rdarelationships:workManifested (Beispiel), siehe auch Datenmodellierung
    Die BL gibt keine Werktitel aus Vgl. Datenmodellierung
    In BIBFRAME (LOC) gibt es   bf:workTitle ("Title or form of title chosen to identify the work, such as a preferred title, preferred title with additions, uniform title, etc.." - mit Domain bf:Work und Range bf:Titel ist der Verwendung in den Werksätzen vorbehalten und damit ungeeignet für unseren Zweck).
    Die Property bf:instanceOf ("Work this resource instantiates or manifests. For use to connect Instances to Works in the BIBFRAME structure.") hat Domain bf:Instance und Range bf:Work. Es wäre zu prüfen, ob bf:Instance ("Resource reflecting an individual, material embodiment of the Work.") auf die deutschen Composite Description Sätze (und die Altdaten) anzuwenden ist.
    Zephiras BIBFRAME lite (bibfra.me) hat die Property instantiates: "The Work this resource instantiates or manifests. For use to connect Instances to Works in the BIBFRAME structure." TODO Domain und Range Prüfen
    Die BNE hat selber die datatype property http://datos.bne.es/def/P1001 geschaffen (Anwendungsbeispiel)
• Titel von Werken bei Zusammenstellungen [M21 700, 710, 711 + $t 730 $a]
  Das waren in RAK enthaltene und beigefügte Werke und bisher wurde dazu keine Empfehlung ausgesprochen. Das könnte jetzt geändert werden unter der Überschrift "Teile von Zusammenstellungen"
  Die DNB transportiert sie bisher mit dcterms:alternative. Das RDA unconstrained Element Set bietet rdau:P60249 (is container of).
  Reinhold Heuvelmann zum Hintergrund: Es geht um mehrere Werke (eines oder verschiedener Autoren), die in einer Manifestation vereinigt sind. Das Thema ist wegen WEMI und Teil-Ganzes-Sachverhalt knifflig zu modellieren.
  Sarah Hartmann: auch hier kann es neben Literalen theoretisch zu GND-Werksatzverknüpfungen kommen (auch wenn es in der Praxis selten vorkommen dürfte)
  Lars Svensson: In der FRBR-Review Group wird am Thema "Manifestationen, die aus mehreren verschiedenen Werken bestehen" auch noch gearbeitet.
  Reinhold Heuvelmann: für D-A-CH hat sich eine Untergruppe der AG RDA Gruppe Teil-Ganzes-Beziehungen auf eine Lösung verständigt, die in MARC21 abbildbar ist.
  Vorschlag: Neues Empfehlungselement "Teile von Zusammenstellungen" mit rdau:P60101 (is contained in) (oder dcterms:hasPart?) aufnehmen.
  Bevor eine abschließende Entscheidung gefällt wird, soll beim nächsten Mal noch ein Beispiel untersucht werden.
  Beispiel: http://d-nb.info/990877124 ([Jana nachträglich:] können wir auch ein Beispiel mit M21-Formatillustration bekommen? Sind die aus der Präsentation von Schaffner/Labner vom Oktober 2014  - ab Folie 4 - noch aktuell? Im RDA-Approval-System scheinen bisher keine richtigen zu sein.)
  TODO: Beispiel durchsprechen.

Abschnitt 2.2 Personen und Körperschaften

[M21 1XX, 7XX] Die Erfassung von Beziehungskennzeichnungen wird mit RDA ausgeweitet und erfolgt als MARC-Code. Neu  ist außerdem, dass auch für den 1. Schöpfer eine Beziehungskennzeichnung erfasst werden kann. Das löst an sich keinen Änderungsbedarf an den Empfehlungen aus, da dort im Moment nicht sehr deutlich zwischen 1. und weiteren Schöpfern unterschieden wird (Unterteilung der Tabelle zwischen "creator" und "contributor" einfügen?) und die Empfehlung zu Beziehungskennzeichnungen allgemein gehalten ist:

Wenn es die Datenbasis zulässt, sollten die Funktionsbezeichnungen der Personen MARC-Relatorcodes ausgewertet und angegeben werden.

marcRole http://id.loc.gov/vocabulary/relators/<MARC-Relatorcode>

Beispiel: <marcRole:trl rdf:resource=“http://d-nb.info/gnd/137763638“/>

Fragen:

• sollen weiter die marcRole-Terms als Properties empfohlen werden, oder sollte auf die RDA-Properties geschwenkt werden?
  • oder wäre es eh zu früh dafür, weil sich RDA und MARC Relator noch nicht entsprechen? Was ist da der aktuelle Stand?

Hier zur Veranschaulichung ein kleiner Ausschnitt aus dem Mapping der Beziehungen für den 1. Schöpfer :

(Vollständig nach aktueller Anhang I Übersetzung bei Hentschke schon vorhanden)

• Dass auch der 1. Schöpfer dann beziehungscodiert wird, hätte nach den aktuellen Empfehlungen zur Folge, dass für RDA-Daten kein dcterms:creator mehr ausgegeben würde.
  • Sollten die Empfehlungen so erweitert (bzw. deutlicher formuliert) werden, dass der Inhalt des Elementes "1. Schöpfer" immer als dcterms:creator ausgegeben wird, auch wenn er eine Beziehungskennzeichnung trägt (die nicht "cre" ist)?
  • Und wenn eine nicht-"cre"-Beziehungskennzeichnung vorliegt, sollte das GND-Objekt/Literal dann ein weiteres Mal mit der entsprechenden Beziehungsproperty ausgegeben werden?
  • Gegen die rdau-Properties spricht übrigens, dass sie nicht zu dc aligned sind. Weiss jemand, warum? Die marcRelators sind dort, wo angemessen, als Subproperties zu dc:contributor ausgewiesen.
• Bisher wird anhand der Verwendung von dcterms und dc unterscheidbar gehalten, ob es sich um eine object property mit GND-URI (dcterms) oder um ein Literal (dc) handelt. Das wäre dann bei mehr Beziehungskennzeichnungen nicht mehr gegeben.

Sollten auch bei konkreter Funktionsangabe Schöpfer weiterhin parallel als dc/dcterms:creator ausgegeben werden?
Andreas Kahl spricht sich für die vorgeschlagene Doppelausgabe von dc:creator und marcRole:<MarcRelator Code>. Rückwärtskompatibilität!
Sarah Hartmann: Damit würde für eine und dieselbe GND-URI mehrfach ausgegeben. Redundante Information.
Carsten Klee: Macht aber auch die Dumps immer größer. Rückwärtskompatibilität zwanghaft halten sollte keine Bedingung sein.
Andreas Kahl: BSB würde vermutlich in jedem Fall dc:creator weiter ausgeben, egal, ob Empfehlung oder nicht.
Cornelia Katz: In RDA ist es sowieso so, dass eine Person mehrere Beziehungen zu einer Resource haben kann (spricht: Beziehungscodes sind wiederholbar). Das muss auch dort schon als als Doppelausgabe abgebildet werden.
Jana Hentschke: Die Hauptverantwortung für eine Resource sollte hier als eigene Beziehung zum Werk gesehen werden, die weiterhin mit dc/dcterms:creator ausgegeben wird. Auch hat dc/dcterms:creator sicherlich noch eine besonders zentrale Rolle, da es an vielen Stellen für die Anzeige ausgewertet werden dürfte.
Sarah Hartmann und Adrian Pohl stellen klar, dass in den meisten Fällen die RDA-Beziehung eindeutig der Creator- oder der Contributor-Rolle zuzuordnen sind. Es gibt nur wenige Ausnahmen. Die betreffenden RDA-uncontrained-Properties sind als Subproperties zu rdau:P60447 ("has creator") bzw. rdau:P60626 ("is contributor of") und  angelegt. [Nachtrag Jana:] Es gibt 5 Ausnahmen, eine ist die Beziehungskennzeichnung Komponist. Sie kann sowohl als 1. Schöpfer als auch als weitere geistige Schöpfer, sonstige Personen, Mitwirkende vergeben werden. Die zugehörigen RDA-unconstrained-Property rdau:P60426 ("has composer") ist wie beschrieben Subproperty zu rdau:P60447 ("has creator"). Das brächte mit sich, dass - wenn mit RDA-Properties ausgedrückt - der Kartograf immer auch creator wäre - was nicht der Fall sein muss. (Die weiteren Ausnahmen, die das beträfe: Choreograph, Komponist, Interviewter, Interviewer  - alle Expression-Ebene)

Sollten die Empfehlungen von marcRole-Properties auf RDA unconstrained Properties geändert werden?

Können die RDA-Properties auf die MARCRelator Codes gemappt werden? (offen geblieben)
Können die MARCRelator Codes alle auf RDA-Properties  gemappt werden?
Sarah Hartmann: alle nicht, denn es gibt mehr MARCRelator-Codes als RDA-Properties. Außerdem für eine Weiterverwendung von marcRole spräche, dass mit RDA auch die MARC Relator Codes erfasst werden.
Barbara Block: In Altdaten kann es sowieso vorkommen, dass MARC Releator Codes erfasst wurden, die keine RDA-Entsprechung haben.
Fazit: keine Notwendigkeit, von der Empfehlung MARC Role Terms abzuweichen.
Carsten Klee: Gäbe es einen Vorteil wenn man dc:creator gegen rdau:hasCreator austauschte?
Adrian Pohl: ein Vorteil wäre, dass man wegen der Subproperty-Beziehung innerhalb des RDA-unconstrained-Element-Set nur ein Triple bräuchte, um sowohl die spezifische Rolle als auch die Creator-Rolle auszudrücken ([Nachtrag Jana Hentschke]: Wobei noch das Problem der Ausnahmen hinzukommt, siehe oben).
Zur Frage, ob die Annahme richtig ist, dass dem dc:creator in der Anzeige eine besondere Bedeutung zukommt, berichtet Andreas Kahl von der Nutzung in München, dass es dort so sei und die marcRole-Relationen nicht weiter ausgewertet werden, weil zu speziell. Er vertritt die Ansicht, dass der Wegfall von dc:creator vermieden werden sollte, da dies vermutlich Aufwand bei vielen Nutzern erzeugen würde.
Vorläufiges Fazit/Tendenz: marcRole-Ausgabe der Funktionsbezeichnungen weiter empfehlen wie bisher und jetzt zusätzlich deutlich machen, dass Schöpfer immer zusätzlich als dc/dcterms:creator ausgegeben werden soll.
Dass bei der marcRole-Ausgabe im Gegensatz zu der dc/dcterms-praktizierten Ausgabe nicht anhand der Property unterscheidbar ist, ob ein Literal oder ein URI in Objektposition steht, wird wie schon im beim letzten Durchgang akzeptiert.

TODO: Vorgehen final beschließen

Abschnitt 2.3 Orts-, Verlags- und Datumsangaben

[M21 008Pos. 06=r Pos.11-14] Datum des Originals berücksichtigen? (betrifft Neuerungen bei Reproduktionen)

Entsprechende rdau-Property: rdau:P60527 (has date of resource) (?)

Rekapitulation: bisher wurde sich dem Thema Reproduktionen in den Empfehlungen noch nicht besonders gewidmet und schlicht nur die Ausgabe des Erscheinungsjahrs empfohlen.

Soll nun das Datum des Originals als neues Empfehlungselement aufgenommen werden?

Andreas Kahl befürwortet das, weil es bei Digitalisaten eine wichtige Information ist.

Adrian Pohl gibt zu bedenken, dass i.d.R. für Reproduktion und Original separate verlinkte Datensätze mit ausgewiesenen Erscheinungsjahren existieren. Eine Wiederholung des Originaldatums im Kontext der Reproduktion ist damit redundante Information.

Sarah Hartmann informiert, dass es im deutschsprachigen Raum auch Beispiel für die Ein-Datensatz-Lösung bei Reproduktionen gibt

Andreas Kahl berichtet, dass dieser Fall in Bayern vorkommt. Er beschreibt außerdem den Anwendungsfall, dass ein Nutzer nur an Digitalisaten interessiert ist und die Datensätze der Originale (wenn vorhanden) gar nicht mitnimmt. Der Redundanz gegenüber steht die erhöhte Nutzbarkeit der Daten für Konsumenten, die sie nicht so genau kennen (wollen).

Barbara Block: es sollte unterschieden werden, um was für eine Art Reproduktion es sich handelt. Bei Digitalisaten wurde vor RDA das Originaldatums an der Stelle des regulären Erscheinungsjahrs im Reproduktionssatz aufgenommen. Papierreproduktionen wurden und werden noch anders gehandhabt. Es müssen zunächst die unterschiedlichen Fälle zusammengestellt werden um dann separat über ihre Abbildung zu entscheiden.

Jana Hentschke denkt, dass die Unterscheidung der Fälle zu speziell für die Empfehlungen ist und dass stattdessen dort nur eine allgemeingültige Empfehlung ausgesprochen werden sollte.

Soll bei Reproduktionen das Datum des Originals mit ausgegeben werden (Redundanz zum verknüpften Datensatz des Originals), um die Konsumierbarkeit der Daten zu erhöhen?

Lars Svensson spricht sich für das Prinzip "Im Zweifelsfall für Redundanzfreiheit" aus.

Andreas Kahl schlägt vor, das Datum des Originals als optionales Element in die [erweiterten Empfehlungen] aufzunehmen. Er möchte es für die bayerischen Daten umsetzen.

Adrian Pohl: auch das HBZ findet es hilfreich, wenn man für die verschiedenen Datumsformen verschiedene Properties empfiehlt (dort werden aktuell bei Reproduktionen beide Jahre mit derselben Property ausgegeben).

Fazit: Die Wiki-Seite "Erweiterte Empfehlungen" soll um den Punkt "Datum des Originals bei Reproduktionen" ergänzt werden.

TODO: Klären, ob die vorgeschlagene rdau-Property rdau:P60527 die richtige ist ("Relates a resource to the earliest date associated with a resource") und ob es an anderer Stelle bessere gibt.

Abschnitt 2.5 Medientyp

Die aktuellen Empfehlungen behandeln unter dieser Überschrift (etwas irreführend) die RDA Themen Inhaltstyp und Datenträgertyp, Erscheinungsweise und Form der Notation und ihnen geht die Bemerkung voraus

Bisher gibt es noch keine zufriedenstellende Lösung für die Ausweisung von Medientypen. Im Kontext von RDA und anderer Initiativen wird bereits daran gearbeitet. Im Sinne einer einheitlichen Darstellung strebt die Gruppe Titeldaten an, sich den zu erwartenden Ergebnissen anzuschließen

(Siehe auch die damalige Zusammenstellung von Stefanie Rühle zum Thema.)

Inhaltstyp / Content Type (RDA 6.9, Expression-Ebene)

[M21 336] Bisher wurden aus diesem Bereich nur empfohlen:

Es ist zu klären, ob

• als value vocabulary das RDA Content Type Vocabulary zu verwenden ist (in den beiden Fällen: rdaco:two-dimensional moving image und rdaco:cartographic image)

• als property weiter rdf:type oder rdau:P60049 (has content type) benutzt werden soll
• eine Empfehlung für sämtliche mit RDA-erfassten Werte ausgesprochen werden soll (oder nur darauf verwiesen wird)

Das Mapping Code List for RDA Content Types (in der Erfassung verwendet) auf RDA Content Type Vocabulary müsste so aussehen (Quelle: Hentschke):

Medientyp / Media Type (RDA 3.2, Manifestationsebene)

[M21 337] Es handelt sich um Oberbegriffe zu den Datenträgertypen (RDA 3.3). Die aktuellen Empfehlungen gehen auf diese Art Information bisher nicht ein. Soll die Ausgabe empfohlen werden? Die RDA property dazu ist rdau:P60050 (has media type) und das Mapping vom erfassten Code List for RDA Media Types auf RDA Media Type Vocabulary sieht so aus (Quelle: Hentschke)

Datenträgertyp (RDA 3.3, Manifestationsebene)

[M21 338] Schon in den aktuellen Empfehlungen wird für die folgenden Elemente die Verwendung des RDA Carrier Type Vocabulary empfohlen:

Mit der Property dcterms:medium wird nur in einem Fall ein anderes vocabulary verwendet:

Es ist zu klären, ob

• zukünftig für alle nach RDA erfassten Datenträgertypen eine Empfehlung ausgesprochen (oder nur verwiesen) werden soll
• ob als Property weiter dcterms:medium oder dann rdau:P60048 (has carrier type) verwendet werden soll

Hier das vollständige Mapping von der erfassten Code List for RDA Carrier Types und dem RDA Carrier Type Vocabulary (Quelle Hentschke)

Erscheinungsweise (RDA 2.13, Expressionsebene)

In diesen RDA-Bereich fallen die bisherigen Empfehlungen (hier mit angefügtem RDA Mode of Issuance, die unspezifischer sind):

Hier die Fragen:

• Was ändert sich in der Erfassung nach RDA?
  • Werden die Media Type Codes irgendwo erfasst?
  • Ändert sich etwas an der Art, wie die bisher empfohlenen Werte Artikel, Ausgabe, Zeitschrift, ... erkennbar sind?
• als RDA-Property gibt es dazu rdau:P60051 (has mode of issuance), wie verhält sich das zu rdf:type?

Form der Notation (RDA 7.13)

Die Empfehlung

findet sich als einzige in diesem Abschnitt wieder und könnte jetzt mit rdaregistry-Mitteln auch so ausgedrückt werden:

Sollen Notationsformen jetzt noch systematischer ausgegeben werden?

Hier Ende der Diskussion in TelKo 22.07.2015

Abschnitt 2.6 Relationen

In RDA-Daten werden die Relationen mit kontrollierten Termen ggf. näher spezifiziert. Soll auch die Ausgabe mittels spezifischerer Properties empfohlen werden?

Teil-Ganzes-Beziehungen

dcterms:isPartOf

Aktuelle Empfehlung:

Neue mögliche Spezifizierungen:

dcterms:hasPart

Aktuelle Empfehlung:

Neue Spezifizierungen:

Schriftenreihen

Bisher dcterms:isPartOf (s.o.), weitere Option: rdau:P60193 (is in series)

Parallele Ausgabe

Aktuelle Empfehlung:

Neue Spezifizierungen:

dcterms:hasVersion

dcterms:isFormatOf

Chronologische Verknüpfung

In der aktuellen Empfehlung werden bereits die rdau-Properties verwendet:

Die neuen Spezifizierungen sind jeweils als Subproperties der beiden angelegt:

• Soll die Verwendung der spezifischeren Properties empfohlen werden?

Sprachliche Anpassungen

Anpassung der Bezeichnungen des konzeptuellen Mappings in den Spalten "Inhalt" nach Terminologieänderungen, z.B. Haupttitel (statt Hauptsachtitel), Titelzusatz (statt Zusatz zum Hauptsachtitel), ...

Erweiterte Empfehlungen für Textressourcen, die sich aus RDA ergeben (könnten)

• Copyright-Datum? [M21 264 Indikator 2=4 $c] (Z.B. durch dcterms:dateCopyrighted)
• Zielgruppe [M21 385] (dcterms:audience)
• Erste und frühere Veröffentlichungsangaben [M21 264 Indikator 1=#,2] als weitere rdau:P60333 empfehlen?
• Vertriebsangabe [264 Indikator  2 = 2], z.B. durch rdau:P60330 (has distribution statement), rdau:P60160 (has place of distribution), rdau:P60438 (has distributor), rdau:P60070 (has date of distribution)
• Herstellungsangabe [264 Indikator  2 = 3], z.B. rdau:P60331 (has manufacture statement), rdau:P60443 (has manufacturer), rdau:P60162 (has place of manufacture), rdau:P60072 (has date of manufacture)
• Entstehungsangabe [264 Indikator  2 = 0], z.B. rdau:P60332 (has production statement), rdau:P60161 (has place of production), rdau:P60441 (has producer), rdau:P60071 (has date of production)
• Titelkonkordanzen [787 Indikator 1=0 Indikator 2=8] (bei fortlaufenden Ressourcen) - rdau:P60193 (is in series).
• Andere Beziehungen (Werk- und Expresssionsebene sowie beschreibende Beziehungen (Manifestation)) [M21 787] (nur dc:relation oder spezifische rdau-Properties? z.B. Kurzfassung von, Bearbeitung von, Erweiterte Ausgabe von, ...)
• Hochschulschriftenvermerk [M21 502] (rdau:P60060 (has degree granting institution), rdau:P60514 (has year degree granted), Charakter der Hochschulschrift : größtenteils GND-URIs ableitbar)