Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

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

ToDo: Jana Hentschke kümmert sich zum 08.10.2015 um eine Jana Hentschkes Zusammenstellung der Optionen

Abschnitt 2.2 Personen und Körperschaften

...

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. (Warnung) Darauf sollte in den  Empfehlungen noch hingewiesen werden]

Diskussion 02.09.2015

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

...

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.

ToDo: Jana Hentschke arbeitet den Vorschlag in die erweiterte Empfehlungsseite ein und dort wird er dann final von allen abgenommen.

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 dcterms:isPartOf (s.o.), weitere Option: rdau:P60193 (is in series)

Titelkonkordanzen

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

Diskussion 02.09.2015 Teil-Ganzes-Beziehungen + Schriftenreihen

...

Ü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 (Frage)Vorbehaltlich

dcterms:isFormatOf

bisher Empfehlung nur in eine Richtung.

(Frage) Was ist mit dcterms:hasFormat ?

Äquivalent

Äquivalent

rdau:P60191

Property name: is equivalent (Superproperty)

Erscheint auch als

rdau:P60195

Property name: is also issued as

Mirror-Site

rdau:P60197

Property name: is mirror site

Reproduktion vonrdau:P60297Property name: is reproduction of

Begleitet von 

rdau:P60196

Property name: is accompanied by (Superproperty)

Erscheint mit

rdau:P60256

Property name: is issued with

Verfilmt mit

rdau:P60258

Property name: is filmed with

Auf Disk mit

rdau:P60257

Property name: is on disc with

...

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.

Fazit: Ganz am Ende der Anpassungsarbeiten an den Empfehlungen durchgehen und die RDA-Begrifflichkeiten in Klammern ergänzen.

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

[M21 264 Indikator 2=4 $c] (Z.B. durch dcterms:dateCopyrighted)

Diskussion Arbeitstreffen 21.01.2016

Cornelia Katz hat RDA-Begriffe zu Elementbezeichnern der alten Empfehlungen zusammengestellt.
Stefanie Rühle: erinnert an Diskussion, ob Katalogisierungsregelspezifische Bezeichner für RDF-Nutzer vertragbar sind. Votiert für Ersetzen durch neue RDA-Begriffe statt beides, RAK und RDA. Barbara Block berichtet, dass die RDA-Begriffe teilweise sehr unintuitiv sind und die RAK-Bezeichnungen teilweise für nicht-Bibliothekare verständlicher sind.
Plan: zunächst Dokument fertigstellen und dann Begrifflichkeiten anpassen. Einheitlichkeit (RAK oder RDA) versuchen, bei ungebräuchlichen/unverständlichen Begriffen aber auch darauf verzichten. Die Gruppenmitglieder ohne bibliothekarischen Hintergrund sollen am Ende entscheiden, welche Begriffe am intuitivsten sind.

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

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

...

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

Fazit: ZDB soll noch befragt werden, (Warnung) Jana Hentschke erledigt dasKommentar 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

...

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.Fazit: ZDB soll befragt werden, wie wichtig dort das Thema ist. (Warnung) Jana Hentschke erledigt das

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

...

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

Offene Fragen:

...

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.


Diskussion Arbeitstreffen 21.01.2016
Vier Optionen:
1. (etwas unsauber) mit der RDA-Property (academicDegree => http://rdaregistry.info/Elements/u/P60175 ) direkt auf GND-Schlagwort für Charakter der Hochschulschrift linken (wird in MARC auch so gemacht)
2. mit rdf:type auf Hochschulschrifttypen (Klassen) linken (die wir noch erstellen müssen)
3. den Charakter der Hochschulschrift auf den jeweiligen Degree mappen und mit rdau:P60175  nutzen (Literal)
4. eine neue Property kreieren, die auf die GND-Hochschulschriftentypen linkt
Zu 2: In bibo gibt es
dazu die Werte
bibo:Thesis könnte auch schon am Vorhandensein eines (vor RDA) Hochschulschriftenvermerks abgeleitet werden).
Modellierung mit rdf:type wird als am stimmigsten mit der bisherigen Modellierung erachtet.
Fazit: Charakter der Hochschlulschrift mit rdf:type und entweder mit bibo:Thesis oder, wenn unterscheidbar, mit (neu zu schaffenden) dnbt:Dissertation, Masterthese,... empfehlen
(Änderung nach Diskussion TelKo 07.03.2017: die Unterarten der Hochschulschriften sollen doch nicht ausdrücklich empfohlen werden, da sie in den Daten nicht selten vorliegen)

...

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

...

)