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]
  Diskussion 22.07.2015:
  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 vorliegenden Composite Description Records nicht benutzen kann, 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 (s.u.)
    
  • 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.
    Zepheiras 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)
    Diskussion 02.09.2015
    Siehe Sarah Hartmanns Modellierung Werk.

• 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).
  Diskussion 22.07.2015:
  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 MARC 21 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 M-21-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.) ([Reinhold nachträglich:] Ich habe welche gefunden in den DNB-Testdaten, eins hänge ich hier an.)
  Diskussion 02.09.2015
  Gemeinsames Anschauen des Beispiels aus dem RDA-Testsystem von Reinhold Heuvelmann.
  Jana Hentschke: Unklarheit ihrerseits betreffend die MARC-Felder, die betroffen sind. Zusammentragen:
  
  • 249 Manifestationstitel als Literal (Suche nach passender Property ausstehend)

  • 505 Manifestationstitel als Literal (bei Zusammenstellungen mit übergeordnetem Titel. Das ist zwar ein Bemerkungsfeld, aber strukturiert. Suche nach passender Property ausstehend.)

  • 7XX mit $t Werkverknüpfungen

  • 240 Werktitel als Literal (Wiederholungen eigentlich in 730, aktuell aber als wiederholte 240)

Abbildung des Manifestationstitel als Literal

Cornelia Katz: Man könnte es als weiteres dc:titel ausgeben
Sarah Hartmann: Inhaltlich würde das den Sachverhalt natürlich korrekt abbilden, aber wie reagieren existierende Systeme darauf. Gefahr z.B., dass nur ein dc:title angezeigt wird. Natürlich wäre auch keine Reihenfolge haltbar.
Lars Svensson: Prinzipiell ist nirgendwo gesagt, dass dc:title nur einmal vorkommen darf. Eine Ressource kann mehrere Titel haben.
Unterschiedliche Unterfeldbelegung in 245 und 249 werden kritisch gesehen. Das betrifft im Beispiel zum einen den Zusatz zum Titel (245 $b und 249 Teil von $a ($b ist dort der Zusatz zum Titel des gesamten Vorlage)) und auch die Verantwortlichkeitsangabe. Generell Kritik an der vorliegenden Implementierung, da schwerlich in RDF überführbar.
Cornelia Katz: Die 245/249-Implementierung (249 = lokales MARC-Feld) ist ein deutscher Sonderweg, den existierenden Systemen geschuldet. International wird der Sachverhalt in einem 245 ausgetauscht (dort befindet sich dann alles, was im dt. Sprachraum in 249 steht, in 245 $b).
Lars Svensson: Wir haben in dem Beispiel eine Manifestation, deren Titel sich aus 245 und 249 zusammensetzt. An der Belegung der Felder ist außerdem zu erkennen, dass diese Manifestation sich aus zwei verschiedenen Werken zusammensetzt. Diesen Sachverhalt in RDF widerspiegeln könnte man, indem man einen (sehr langen) dc:titel macht (aus 245 + 249) und mittels der Property, für die wir uns bei den Werktitel entscheiden, zwei bnodes für die beiden enthaltenen Titel.
Sarah Hartmann: eigentlich liegt hier aber eine Manifestation vor, die aus zwei Manifestationen besteht. Deshalb wäre es auch nicht schlecht, beide Manifestationstitel abzubilden.
Lars Svensson: wenn man zwei dc:title machen würde, hätte man wenig Optionen, 249 $b unterzubringen (das sich auf die ganze Manifestation bezieht).
Adrian Pohl: Beispiel http://d-nb.info/941154610 enthält noch mal etwas ganz anders in 249.
dcterms:hasPart kann aus verschiedenen Gründen nicht für die einzelnen Teile benutzt werden (z.B. ist es mit URI zu benutzten).
Lars: wirft Frage auf, was dc:title für eine Bedeutung hat. Es ist Text. Was macht man mit Text?
a) Indexierung zum Suchen.
b) Anzeige zum Anschauen.
c) Für maschinelle Verarbeitung verwenden, z.B. Dublettenerkennen
Es wird beleuchtet, wie sich mehrere dc:titles / ein langer dc:title auf diese drei Szenarien auswirken.
Zu c) noch die Frage, ob es darum geht, die Manifestationen zusammenführen oder Werke. Beides denkbar.

Langes dc:title hat negative Auswirkungen auf eine Phrasensuche nach den einzelnen Teilen. Praktisch aber vielleicht eh eher die Stichwortsuche verbreitet. Vereinfacht aber die Anzeige (2).
Mehrere dc:title ermöglichen granularere Indexierung, verkomplizieren aber die Anzeigen.
Fazit: man kommt zu keiner guten Lösungen.
Zusammenfassung:

Drei Optionen:
1) ein langes dc:title für Manifestationstitel
2) alle unterscheidbare einzelnen Manifestationstitel in mehrere dc:title (und evtl. einen langes wie in 1?)
3) eine Mischung aus 1) und 2) nur andere Property für einzelne Manifestationstitel (die man noch suchen müsste)
Ausgewertet werden müssen MARC 249 und 505 (im Fall 505, übergeordneter Titel vorhanden, wäre allerdings klar, was in dc:title käme, es fehlte dann aber eindeutig die Property, die gesucht wird.)

Abbildung der Werktitelrelationen
Verknüpfte Werke der einzelnen enthaltenen Titel in MARC 7xx mit $t. Müssen so gelöst wie auch bei anderen Werken (s.o.).

Abbildung Werktitels als Literal
240 und 7xx $t (?)
Cornelia Katz berichtet, dass das bei Musik mitunter häufig vor.
Auch hier muss die Umsetzung erfolgen wie bei einzelnen Werktiteln (s.o.)

Jana Hentschkes Zusammenstellung der Optionen

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.

Diskussion 22.07.2015:

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:P60398 ("has contributor") 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. [Nachtrag Jana Hentschke: die marcRole-Properties sind Object-Properties, d.h. sie dürfen nur für Verlinkungen verwendet werden. Darauf sollte in den  Empfehlungen noch hingewiesen werden]

Diskussion 02.09.2015

Frage: dc/dcterms und MARC-role beibehalten? Bestätigung des letzten Diskussionsstandes.

Abstimmung: alle sprechen sich dafür aus, nicht auf rdau-Properties statt MARC-role zu wechseln und die Empfehlung beizubehalten. Empfohlen werden soll zusätzlich dc:creator wenn der Schöpfer noch eine andere Rolle hat.

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) (?)

Diskussion 22.07.2015:

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.

Diskussion 02.09.2015

Die vorgeschlagene Property rdau:P60527 "has date of resource" ("Relates a resource to the earliest date associated with a resource") ist die unconstrained Variante von rdae:P20214 "has date of expression" und rdaw:P10219 "has date of work". Damit ist es nicht genau das Gesuchte, kommt dem aber relativ nahe und diese Ungenauigkeit liesse sich im ohnehin unschärferen unconstrained RDA ganz gut kaschieren. Wenn man das Datum des Originals ausdrücken will, wird man wohl keinen besseren Weg finden.

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.)

Hintergrund: Leitseite zu CMC im DNB-Wiki (Login erforderlich): https://wiki.dnb.de/pages/viewpage.action?pageId=68060337

Diskussion 22.07.2015 CMC-Elemente allgemein
Sarah Hartmann: zwar hat sich die Themenspeichergruppe Implementierung der AG-RDA dafür ausgesprochen, den Inhaltstyp auch für Altdaten automatisiert zu ergänzen, das wird von den Betroffenen jedoch erst 2016 angegangen.
Reinhold Heuvelmann: näherungsweise ist diese automatisierte Ergänzung möglich. Aus der Allgemeinen Materialbenennung und der Umfangsangabe in Kombination mit Defaultwerten und ggf. tiefergehender intellektueller Analyse wird das grob (zumindest halbautomatisch) machbar sein. Die CMC-Elemente sind damit wohl die einzige Stelle, an der Altdaten um neue RDA-Elemente ergänzt werden und so eine flächendeckende Erschließung vorliegen wird. Als Grundlage gibt es ein Papier von PICA Leiden (niederländische Sprache) und eine Studie aus Graz in deutscher Sprache basierend auf MAB2-Format (AG-RDA Wiki mit Zugangsbeschränkung. Reinhold Heuvelmann vermittelt bei Interesse)
Cornelia Katz schlägt vor, die neuen granulareren RDA-Codes auf die RDA-Properties abzubilden und das zusätzlich zu den bisherigen Empfehlungen unter "Medientyp". So wäre alles Neue von RDA transportiert und die bestehenden Konversionen müssten nicht abgeändert, sondern nur ergänzt werden (sie greifen ja auf ganz andere Stellen zu als die zukünftigen). Zwar kommt es dadurch inhaltlich zu Doppelungen, aber man würde sich die Arbeit sparen, die bisher empfohlenen Werte alle einzeln durchgehen zu müssen.
Adrian Pohl: da diese Informationen im HBZ über RDF zur Facettierung benutzt werden, besteht dort großes Interesse daran, die Daten auch zukünftig in sich einheitlich abzubilden. Bevor er eine Präferenz äußert, möchte er sich die bestehende HBZ-Konversion noch mal ansehen und in das CMC tiefer einsteigen.
Sarah Hartmann & Cornelia Katz: die Formatstellen, die bisher für die Elemente des Abschnitts "Medientyp" herangezogen wurden (PICA 0500, MAB 050, 051, 052) bleiben mit RDA-Umstellung unberührt weiter bestehen. Das heisst, bestehende RDF-Konversionen werden auch in Zukunft weiter funktionieren.
Jana Hentschke: Im Fall Content Typ wäre es allerdings ein Leichtes, die bestehenden bisher zwei Elemente bereits jetzt statt mit bibo-Value mit RDA-value auszugeben.
 

Diskussion 02.09.2015 CMC-Elemente allgemein

Zu welchem Zeitpunkt sollen die Empfehlungen angepasst werden?

Zusammenfassung:

• Die aktuellen Empfehlungen verweisen auf die zukünftige Übernahme der RDA-Entwicklungen
• bei der TelKo 22.07. wurden Stellen identifiziert, wo man in rda weniger detailiert ausdrücken kann als in den aktuellen Empfehlungen (z.B. Erscheinungsweise)
• Retrospektive Ergänzung der Altdaten um CMC steht an den meisten Stellen erst im nächsten Jahr an

Adrian Pohl: hbz bepricht sich intern zu dem Thema CMC, zu früh für abschließendes Urteil. Vermutlich würde dort (unabhängig von den Empfehlungen) nicht direkt angepasst werden, zumal die alte Umsetzung ja weiter funktionieren wird.
Cornelia Katz: auch das BSZ würde erstmal die alte Umsetzung beibehalten, aber dann auch die RDA-CMCs (parallel) umsetzen.
Sarah Hartmann: wenn man sofort umsetzten würde, müsste das Mapping der Altdaten vorweggenommen werden. Das ist ein zusätzlicher Aufwand, der vielleicht aufgenommen werden muss.
Die anderen schließen sich den geäußerten Meinungen an.
Fazit: Die Empfehlungen nicht anpassen so lange keiner der Anwender direkt umsteigen möchte, um keine falschen Erwartungen zu wecken. Der Satz in den Empfehlungen soll umformuliert werden mit dem Hinweis, dass mit der alleinigen Empfehlung von RDA-CMC noch gewartet wird, bis das Verhältnis der im deutschsprachigen Raum existierenden Daten zu den ensprechenden rda-values an anderer Stelle generell geklärt wird. So lange bleiben die aktuellen Empfehlungen gültig.

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)

Diskussion "Medientyp", 22.07.2015

Jana Hentschke: es handelt sich dabei nur um Oberbegriffe zu den Datenträgertypen. Sollen beide ausgegeben werden?

Sarah Hartmann: für die RDA-Erfassung wurde der Beschluß gefasst, beides zu erfassen, dann könnten wir das der Einfachheit halber hier auch abbilden.

Jana Hentschke sieht die Entscheidung analog zu den anderen Stelle, wo zwischen Redundanzfreiheit und Nutzerfreundlichkeit der Daten abgewogen werden muss.

Reinhold Heuvelmann spricht sich auch dafür aus, alles auszugeben, wegen der Regelmäßigkeit der Verfügbarkeit und weil diese Redundanz an anderer Stelle schon als erstrebenswert ausdiskutiert wurde (Stichwort Facettierbarkeit)

[Nachtrag Jana Hentschke: die betroffenen RDA-Value Vocabularies RDA Media Type und RDA Carrier Type sind in ihrer RDF-Definition aktuell nicht miteinander in Beziehung gesetzt]

Fazit: RDA-Medientyp genau so wie er ist mit passender RDA-Property und -Werten empfehlen

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 Mode of Issuance-Werte 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?

Diskussion "Erscheinungsweise", 22.07.2015

Reinhold Heuvelmann: in diesem Punkt ist RDA mit nur vier Elementen sehr schwach besetzt. Die bisherige Modellierung mit den bibo-Werten ist ausführlicher.

Sarah Hartmann: schon bei der Erarbeitung der aktuellen Empfehlungen hat man sich aktiv dafür entschieden, Artikel, Ausgabe, Zeitschrift, etc. in dieser Granularität auszugeben, auch wenn RDA das nicht bietet.

Jana Hentschke schlägt vor, diesen Teil der Empfehlungen vorerst genauso aufrecht zu erhalten (mit rdf:type), darüber hinaus aber auch die Ausgabe der RDA-Erscheinungsweise mit der passenden RDA-Property zu empfehlen.

Andreas Kahl und Sarah Hartmann stimmen zu und Sarah Hartmann ergänzt, dass die Erscheinungsweise in RDA ein Kernelement ist und deshalb immer damit verlässlich damit gerechnet werden kann.

Reinhold Heuvelmann rechnet in näherer Zukunft auch damit, dass dieser Punkt in RDA noch mehr ausgestaltet werden wird (in Zusammenhang mit der Bearbeitung von Teil-Ganzes-Beziehungen).

Fazit: vorerst werden sowohl bibo - wie bisher - als auch die neuen RDA-Mode-of-Issuance-Werte empfohlen. Wenn zukünft die RDA-Werte ausreichend erweitert werden, soll zu dem Zeitpunkt die Empfehlung der bibo-Werte beendet werden.

 Offene Frage: sollen die RDA-Werte weiterhin mit rdf:type abgebildet werden, oder mit der RDA-Property?

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?

Diskussion "Form der Notation", 22.07.2015

Jana Hentschke: inhaltlich gibt es aus dieser (RDA-)Sektion in den aktuellen Empfehlungen nur den Wert lib:Braillebook was erstmal recht exotisch wirkt. Wie kam es dazu und soll/kann zu diesem Thema jetzt vollständiger empfohlen werden?

Sarah Hartmann: Vermutlich war es ursprünglich zu diesem Element gekommen, weil es in den Ausgangsdaten unterscheidbar war und abgebildet werden sollte

Reinhold Heuvelmann: im RDA-Content Type gibt es den Wert "tactile text", was etwas allgemeiner ist. Da wird aber mittelfristig auch noch erweitert.

Cornelia Katz spricht sich dafür aus, dass diese Element erstmal auch weiterhin mit rdf:type und bibo-Wert ausgedrückt wird

Jana Hentschke sieht nach Reinhold Heuvelmanns Info auch Vorteile, wenn die alte Empfehlung zu Braillebook aufgegeben wird und die Konversionen an der Stelle stattdessen eine rdau:P60049 (has content type)-Aussage mit RDA Content Type Vocabulary-Wert macht, so dass die Daten schon vor der flächendeckenden Ergänzung der CMC-Werte vor und nach RDA homogen abgebildet würden.

Cornelia Katz berichtet aus der Themenspeichergruppe Implementierung, dass man sich dort gegen Mischformen (?) entschieden hat und sie die vorgeschlagene Lösung als unsauber erachtet.

Sarah Hartmann stimmt zu und fände es konsequent, dass, wenn bei den rdf:type-Aussagen mit bibo-Werten (Erscheinungsweise, s.o.) keine RDA-Überführung stattfindet, dies bei der Brailleschrift auch nicht geschähe

Jana Hentschke sieht den Fall "Brailleschrift" eher parallel zu den bisher empfohlenen zwei Werten aus dem Bereich Inhaltstyp (Audiovisuelles Material und Kartenmaterial), weil sich beide jetzt über RDA-Werte ausdrücken lassen (im Gegensatz zur Erscheinungsweise in ihrer aktuellen Granularität). Für diese Fälle plädiert sie dafür, auch die Information aus den Altdaten lieber mit RDA-Values auszudrücken, um Alt- und Neudaten frühzeitig homogen zu haben. Sie sieht die empfohlenen Werte aus dem Bereich "Erscheinungsweise" nur als Ausnahme für die weiterhin auch die bisherigen Empfehlungen aufrecht erhalten werden, weil die Information sich in RDA aktuell nicht in dieser Granularität transportieren kann.

Cornelia Katz denkt, dass es besser wäre, bis zur Ergänzung der CMC in Altdaten in 2016 nichts an den bestehenden Empfehlungen zu rühren, um den Arbeitsaufwand gering zu halten.

Sarah Hartmann: es sollte nichts dagegen sprechen, die alten Umsetzungen mit rdf:type in Betrieb zu lassen, da sie auch weiter funktionieren werden und zusätzlich dieselbe inhaltliche Information nochmal mit den RDA-Properties und den RDA-Werten auszugeben (in den Datensätzen, die die CMC-Felder schon haben).

Reinhold Heuvelmann: im Internformat und den anderen Ausgabeformaten ist das auch so.

Jana Hentschke: es wäre aber auch schön, wenn die Nutzer der RDF-Daten sich nicht mit diesen Hintergründen beschäftigen müssten, sondern möglichst homogen abgebildete Daten bekommen (Use case: Facettierung).

Reinhold Heuvelmann: für das MARC-Format hat man sich bei der DNB dagegen entschieden, Homogenität der Daten künstlich beim Export vorwegzunehmen, sondern gibt alle inhaltlichen Redundanzen genauso aus, wie sie sich aktuell in den Daten befinden.

Jana Hentschke: MARC hat natürlich eine andere Zielgruppe.

Cornelia Katz: die RDF-Daten werden wenig genutzt, das BSZ kann vor dem Hintergrund keinen Aufwand für Übergangslösungen investieren und ist für pragmatische Lösungen.

Jana Hentschke sieht nicht unbedingt zusätzlichen Aufwand, wenn sofort zu RDA-Werten umgeschwungen würde (wo möglich), da es da ja langfristig hingehen wird

Carsten Klee: die Empfehlungen sind in erster Linie dazu gedacht zu dokumentieren, in welche Richtung sich die RDF-Daten idealer Weise bewegen sollten. Wer das dann zu welchem Zeitpunkt bei sich lokal umsetzt, ist davon doch erstmal völlig unberührt. Würde man jetzt in der Empfehlung auf den Zwischenzustand der Daten eingehen, wäre das nicht mehr so sehr eine Empfehlung, sondern eine pragmatische Lösung.

 Hier Ende der Diskussion in TelKo 22.07.2015

Offene Fragen:

• sollen die Empfehlungen in Abschnitt "2.5 Medientyp" bereits zum jetzigen Zeitpunkt auf RDA-Properties und -Values umgeändert werden? Oder soll damit gewartet werden, bis die CMC-Altdaten-Ergänzung überall stattgefunden hat?
• sollen die Themenbereiche (RDA-)Inhaltstyp und Erscheinungsweise wie bisher empfohlen auch weiterhin mit rdf:type abgebildet werden, oder mit den RDA-Properties?
• soll für den Datenträgertyp weiterhin dcterms:medium verwendet werden oder die RDA-Property?soll die Überschrift "2.5 Medientyp", die bisher in den Empfehlungen für den ganzen CMC-Komplex + Erscheinungsweise verwendet wird, geändert werden, damit der Begriff vor seinem neuen RDA-Kontext nicht verwirrt?
• wie ist mit den RDA-Werten "other" und "unspecified" in RDF umzugehen?

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?

Diskussion 02.09.2015 Relationen allgemein

Konsens: alle Stellen, an denen bisher dcterms-Properties empfohlen werden, sollen so bestehen bleiben. Spezifizierung per rdau wenn Datenlage es zulässt empfehlen.

Frage: Soll das Mapping "Kontrollierte Beziehungsangaben nach rdau-Property" so mit veröffentlicht werden? In der Registry sind sie theoretisch drin. Allerdings können auch die englischen Beziehungsangaben - zumindest in der unconstrained Version - nicht direkt auf die unconstrained Property-Namen gemappt werden, weil sie nicht exakt gleich heißen, z.B. "also issued as" -> rdau:P60195, Property name: "is also issued as" oder . Deswegen war intellektuelles Mapping möglich
Beschluss: Das Mapping soll veröffentlicht werden, aber nicht im Empfehlungsdokument, sondern nur auf der MARC-Mapping-Seite
Die Übersicht der Relationen wird dann dort recht umfangreich.
ToDo: Die Liste hier vervollständigen (Jana Hentschke).

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)

Titelkonkordanzen

Beziehungskennzeichnung "Reihe enthält" -> rdau:P60240 (is series container of)

Diskussion 02.09.2015 Teil-Ganzes-Beziehungen + Schriftenreihen

Jana Hentschke: allgeine rdau-Properties sind alle Subproperties zu P60101 (is contained in), P60249 (is container of)

Option 1) Bei dcterms bleiben und ergänzende Formulierung, dass rdau-Properties, wenn die Datenlage eine genauere Spezifizierung zulässt.
Option 2) Ganz auf rdau schwenken auch auf dem allgemeinen Level (also P60101 (is contained in), P60249 (is container of)) mit dem Vorteil, dass sich dann aus dem spezifischen das allgemeine ableiten liesse.

Adrian Pohl: Im hbz gerade Anpassung u.a. um ausdrücken zu können, dass ein mehrbändiges Werk Teil einer Schriftenreihe ist. dcterms:isPart wurde parallel erstmal beibehalten.
Sarah Hartmann: in den bisherigen Empfehlungen war es so gelöst, dass die Relation in beiden Fällen mit dcterms:isPart hergestellt wird und die konkrete Bandangabe/Zählung sich in separaten Literal (dcterms:bibliographicCitation) transportierte.
Adrian Pohl: dabei dann das Problem, dass Literal (mit Bandangabe) und Verknüpfung einander nicht mehr zugeordnet werden können. Über die Empfehlungen hinausgehend hatte das hbz für Serienzählungen bereits mit bibo:volume gearbeitet. dcterms:bibliographicCitation wird vom hbz nur in Aufsatzbeschreibungen verwendet. Jetzt ist für die Serienangabe gerade ein neues Konstrukt geschaffen wurden [Ergänzung Jana Hentschke: Beispiel https://lobid.org/resource/HT008790149/about, ein BlankNode des Typs lv:SeriesRelation]
Adrian Pohl: Gibt es in RDA die Unterscheidung "Teil eines mehrbändigen Werkes" und "Teil einer Serie"?
Sarah Hartmann: Nein, für den Sachverhalt "Teil eines mehrbändigen Werkes" gibt es keine präzise RDA-Property (u.a. weil hierachische Aufnahmen im anglo-amerikanischen Raum ja nicht so hoch gehalten werden).
Fazit: für die Multiparts sollte bei dcterms geblieben werden.

Parallele Ausgabe

Aktuelle Empfehlung:

Neue Spezifizierungen:

dcterms:hasVersion

Übersetzung von	rdau:P60244	Property-Name: is translation of
Synchronfassung von	rdau:P60111	Property-Name: is dubbed version of
Übersetzt als	rdau:P60280	Property-Name: is translated as
Synchronfassung	rdau:P60112	Property-Name: is dubbed version
Parallele Sprachausgabe		Vorbehaltlich

dcterms:isFormatOf

bisher Empfehlung nur in eine Richtung.

Was ist mit dcterms:hasFormat ?

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 RAK-begründeten Bezeichnungen des konzeptuellen Mappings in den Spalten "Inhalt" nach Terminologieänderungen mit RDA, z.B. Haupttitel (statt Hauptsachtitel), Titelzusatz (statt Zusatz zum Hauptsachtitel), ...

Diskussion 22.07.2015

Ist es überhaupt nötig bzw. angemessen, die Terminologie anzupassen?

Reinhold Heuvelmann: Es muss bedacht werden, dass ja auch die Altdaten weiterhin vorliegen. In MARC ist versucht worden, auf Formatebene terminologisch Mittelwege zu finden, die Alt- und RDA-Daten beschreibt.  Ein Beispiel: Manifestationstitel bei Zusammenstellungen. ([Nachtrag Reinhold:] Entsprechend der Entscheidung der Expertengruppe Datenformate zur Neufassung von Feld 249 heißt das Feld jetzt "Weitere Titel etc. bei Zusammenstellungen".)

Cornelia Katz: Es müssen auf jeden Fall keine neuen Begriffe überlegt werden. Alle Anwender haben in ihrem Umfeld Formatdokumentationen, die das ja genauso leisten müssen und wo Lösungen gefunden wurden. Vorschlag: Ganz am Ende der Anpassungsarbeiten an den Empfehlungen durchgehen und die RDA-Begrifflichkeiten in Klammern ergänzen.

Diskussion Arbeitstreffen 21.01.2016

ToDo: Jana Hentschke arbeitet Cornelia Katz RDA-Übersetzungen als Optionen in die neuen Empfehlungen ein und wenn die Gruppe sie abschließend noch mal durchgeht, wird jeweils gewählt

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)

Diskussion 08.10.2015
Kommentar Adrian Pohl: Ist das für deutsches Recht eine sinnvolle Ergänzung? Ist da nicht das Todedatum des Autors das wichtige Urheberrechtsdatum?
Andreas Kahl: Todesdatum ist nicht immer das relevante, weil auch Erbengemeinschaften Rechte beanspruchen können.
Sarah Hartmann: Das neue RDA-Element ist primär verpflichtend bei Musikressourcen anzugeben, kommt aber auch bei textuellen Ressourcen vor. Für das KIM-Kernset ist es deshalb sicher kein Kandidat. Eine Empfehlung könnte man aber machen.
Property dcterms:dateCopyrighted hat Range Literal und passt von daher. Die Definitionen dieser Property und der RDA-Property ist inhaltlich identisch.
Fazit: Empfehlung Copyright-Datum mit dcterms:dateCopyrighted.

Zielgruppe

[M21 385] (dcterms:audience)

Diskussion 08.10.2015

Stefanie Rühle: kommt das in den Daten dann überhaupt vor?
Barbara Block: Öffentliche Bibliotheken arbeiten sehr viel damit.
Die DNB wird es auch erfassen und ausliefern. Verknüpfung zur GND ist vorgesehen, d.h. es können sowohl Literale als auch URIs vorkommen. Die vorgeschlagene Property dcterms:audience hat Range Resource. Was kann man für Literale verwenden?
Andreas Kahl: für die URI dcterms:audience für Literale rdau:P60520 "has intended audience"? Bisher wurden verschiedene Properties aber nur innerhalb von DC (elements und terms) verwendet, der Zusammenhang zwischen dcterms und rdau wäre nicht mehr so ersichtlich und von daher keine gute Lösung.
Stefanie Rühle: ist hier überhaupt mit "echten" Literalen zu rechnen? Selbst wenn technisch Text erfasst wird, liegt vermutlich immer eine kontrollierte Liste o.ä. da hinter.
Barbara Block: Für DACH wurde sich auf eine kontrollierte Liste verständigt. Die Begriffe finden sich in der GND wieder. (7 Begriffe, RDA Toolkit)
Reinhold Heuvelmann: Beispiel DNB
Jana Hentschke: Empfehlung nur aussprechen, wenn Verlinkung da ist? Standpunkt "Information macht nur außerhalb des lokalen Kontext Sinn, wenn eine nachschlagbare Entität als Wert vorhanden ist".
Stefanie Rühle: Wäre ok. Streng sein. (Zustimmung Andreas Kahl)
Lars Svensson: Oder ein bNode?
Jana Hentschke: bNodes war immer ein heikles Thema und an dieser (recht unrelevanten) Stelle damit anzufangen wäre schon ein Schritt.
Sarah Hartmann gibt zu bedenken, dass wir bisher nie so streng waren, es gab immer die dcelements/dcterms-Option.
Da es den Anwendern ja trotzdem freisteht, bei Bedarf für Literale eine eigene Lösung zu finden, einigt sich die Gruppe darauf, dass "nur URIs" für die Empfehlungen ok sind. Diese Lösung baut außerdem einen leichten Druck auf, zu verlinken, was bei diesem Element generell wünschenswert ist.
Fazit: Empfehlung verlinkte Zielgruppe mit dcterms:audience. Keine explizite Empfehlung für Literale.

Erste und frühere Veröffentlichungsangaben

[M21 264 Indikator 1=#,2] als weitere rdau:P60333 empfehlen?
Diskussion 08.10.2015
Betrifft fortlaufende Ressourcen. Keine RDA-Änderung. War notwendig um die unterschiedlichen Prinzipien: "Deutschland: latest entry", "USA: first entry" austauschen zu können.
Jana Hentschke: ist es für RDF-Daten-Bezieher eine interessante Information?
Sarah Hartmann: und wenn, wie sollte man es modellieren? Aktuelles Statemement und frühere müssten unterscheidbar sein.
Adrian Pohl kommentierte: Wir haben die Angaben gerade in lobid herausgenommen, weil die nur in der Anzeige gestört haben. Ich sehe nicht wirklich den Anwendungsfall. Wenn sie ergänzt werden, dann sollte dies aber mit einer Property passieren, die explizit für frühere Veröffentlichungsangaben intendiert ist, was bei rdau:P60333 offensichtlich nicht der Fall ist.
Vermutlich gibt es keine vorhandenen Properties mit denen man den Sachverhalt klar transportieren kann.

Kommentar Carsten Klee (ZDB): Da es offensichtlich keine explizite Property gibt, können wir das entbehren.

Fazit: Das Hauptempfehlungsdokument soll an der Stelle "Orts-, Verlags- und Datumsangaben" ergänzt werden um den Hinweis, dass auf diese Weise der aktuellste Erscheinungsvermerk auszugeben ist. Frühere Veröffentlichungsangaben sollen weiterhin nicht abgebildet werden.

Vertriebsangabe, Herstellungsangabe, Entstehungsangabe

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)

Stefanie Rühle: wir sollten uns fragen, mit was für Objekten man es zu tun hat.
Andreas Kahl: Für alte Drucke Herstellungsangabe auf jeden Fall relevant.
Barbara Block: Bei Digitalisaten auch.
Sarah Hartmann: Bei Online-Publikationen auch. Entstehungsangabe bezieht sich auf unveröffentlichte Ressourcen.
RDA-Properties bieten sich an, weil es die nötige Spezifizierung bietet.

Fazit: Alle drei Angaben sollen mit den RDA-Properties wie oben beschrieben in die erweiterten Empfehlungen aufgenommen werden

Titelkonkordanzen

[787 Indikator 1=0 Indikator 2=8] (bei fortlaufenden Ressourcen) - rdau:P60193 (is in series).

Diskussion 08.10.2015
Sarah Hartmann: zu dem Thema laufen gerade noch Diskussionen in der ZDB, das MARC-Feld ändert sich vielleicht noch mal.
Reinhold Heuvelmann: es handelt sich um den Sachverhalt, dass in einem Datensatz, der eine Zeitschrift beschreibt, angegeben wird, dass es punktuelle Bezüge zu einer zweiten Zeitschrift gibt. Z.B. ein einzelner Band gehört zu Zeitschrift A, hat dort die Zählung 1 und gehört auch gleichzeitig zu Zeitschrift B, dort mit Zählung X. Da es es keine Datensätze für die einzelnen Bände gibt, wir das auf Titelebene verhakelt. Es gibt dazu ein (Freitext-)Bemerkungsfeld "Band 1 hier ist Band 5 dort, Band 2 ...".
Jana Hentschke: also könnte man sowieso keine präzise Aussage machen, weil die Details der Relation zwischen den Zeitschriften nur Freitext erfasst ist.

Kommentar Carsten Klee (ZDB): Das Pica+ Feld 039S enthält in Unterfeld $9 einen Titelverweis, der in M21 in 787$w wandert. Somit besteht hier doch wohl die Möglichkeit die Property zu nutzen.

Fazit: Der Sachverhalt wird vom Abschnitt Relationen mit abgedeckt.

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, ...)

Diskussion 08.10.2015

Sarah Hartmann: das Thema Titelkonkordanzen sollte zusammen entschieden werden mit den anderen Titelrelationen, die übrig sind. Sollen immer alle Relationen ausgegeben werden, oder nicht? Wir wollen vermutlich hier keine weitere Auswahl treffen.

Jana Hentschke: alle nicht bereits an anderer Stelle empfohlenen Beziehungen könnten einfach mit dc:relation empfohlen werden? Das ist eigentlich bereits das, was nach aktuellem Stand in das Hauptempfehlungsdokument geschrieben wird

Fazit: Dieser Punkt ist für die erweiterten Empfehlungen überflüssig

Hochschulschriftenvermerk

[M21 502] (rdau:P60060 (has degree granting institution), rdau:P60514 (has year degree granted), Charakter der Hochschulschrift : größtenteils GND-URIs ableitbar)

Diskussion 08.10.2015

Adrian kommentierte bereits, dass er weiss, dass Kundeninteresse besteht.

Hintergrund: Mit RDA werden die drei Elemente

• "degree granting institution" (Erfassung erstmal in Vorlageform vorgesehen),
• "year degree granted" und
• "Charakter der Hochschulschrift" (Standardisierung der Begriffe und GND-Verknüpfung geplant, erstmal aber kontrollierte Liste von sieben Literale. Geht aktuell weit über CMC-Angaben hinaus)

unterscheidbar erfasst. Nach RAK wurde ein mit Deskriptionszeichen "separierter" String erfasst. Damit macht es jetzt Sinn, die Elemente jetzt in die erweiterten Empfehlungen aufzunehmen.

Zu Charakter der Hochschulschrift:
Hintergrund: Nach RDA soll eigentlich der Akademische Grad erfasst werden. Die D-A-CH-Anwendungsrichtlinien überschreiben das zugunsten des Charakters der Hochschulschrift, d.h. die RDA-Property rdau:P60175 ist hier nicht hilfreich.

Fazit: auch die schon nach RAK erfassten Literale für den Hochschulschriftenvermerk sollen mit rdau:P60489 ("has dissertation or thesis information") empfohlen werden (hbz und DNB machten das bereits so)