Seitenhistorie

...

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)

ToDo: Entscheidung treffen

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.

...