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
- Identifizieren der zu ändernden Stellen
- Zuordnen der entsprechenden rdau-Properties/-Values
- Recherchen nach Alternativ-Properties/-Values aus im Web etablierteren Ontologien
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 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 ausVgl. 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)
- ist dcterms:alternative nicht mehr angemessen, weil sich die Angabe auf eine andere Entität bezieht?
- 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 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.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 :
MARC rel | Inhalt | Property | Label |
arc | Architekt | has architect | |
art | Künstler | has artist | |
aus | Drehbuchautor | has screenwriter | |
aut | Verfasser | has author | |
chr | Choreograph | has choreographer | |
cll | Kalligraf | has calligrapher | |
cmp | Komponist | has composer | |
com | Zusammenstellender | has compiler | |
... |
(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: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) (?)
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.
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.)
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 autmatisiert 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 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 vermitteln 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.
Inhaltstyp / Content Type (RDA 6.9, Expression-Ebene)
[M21 336] Bisher wurden aus diesem Bereich nur empfohlen:
Audiovisuelles Material | rdf:type | „bibo:AudioVisualDocument“ |
Kartenmaterial | rdf:type | „bibo:Map“ |
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):
Quelle | Ziel | Inhalt |
crd | 1001 | cartographic dataset |
cri | 1002 | cartographic image |
crm | 1003 | cartographic moving image |
crt | 1004 | cartographic tactile image |
crn | 1005 | cartographic tactile three-dimensional form |
crf | 1006 | cartographic three-dimensional form |
cod | 1007 | computer dataset |
cop | 1008 | computer program |
ntv | 1009 | notated movement |
ntm | 1010 | notated music |
prm | 1011 | performed music |
snd | 1012 | sounds |
spw | 1013 | spoken word |
sti | 1014 | still image |
tci | 1015 | tactile image |
tcm | 1017 | tactile notated music |
tcn | 1016 | tactile notated movement |
tct | 1018 | tactile text |
tcf | 1019 | tactile three-dimensional form |
txt | 1020 | text |
tdf | 1021 | three-dimensional form |
tdm | 1022 | three-dimensional moving image |
tdi | 1023 | two-dimensional moving image |
xxx | ??? | other |
zzz | ??? | unspecified |
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)
Quelle | Ziel | Inhalt |
s | audio | |
c | computer | |
h | microform | |
p | microscopic | |
g | projected | |
e | stereographic | |
n | unmediated | |
v | video | |
x | ? | other |
z | ? | unspecified |
Diskussion "Medientyp", 22.07.2015
Jana Hentschke: es handelt sich dabei nur um Überbegriffe 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:
Mikroform | dcterms:medium | „rdacarrier:1020“ |
Onlineressource | dcterms:medium | „rdacarrier:1018“ |
Elektronische Ressource | dcterms:medium | „rdacarrier:1010“ |
keine Angabe | dcterms:medium | „rdacarrier:1044“ |
Mit der Property dcterms:medium wird nur in einem Fall ein anderes vocabulary verwendet:
Multimediamaterial | dcterms:medium | „isbdmediatype:T1008“ |
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)
Quelle | Ziel | Inhalt |
ca | computer tape cartridge | |
cb | 1012 | computer chip cartridge |
cd | 1013 | computer disc |
ce | 1014 | computer disc cartridge |
cf | 1016 | computer tape cassette |
ch | 1017 | computer tape reel |
ck | 1011 | computer card |
cr | 1018 | online resource |
cz | 1010 | other |
eh | 1042 | stereograph card |
es | 1043 | stereograph disc |
ez | 1041 | other |
gc | 1037 | filmstrip cartridge |
gd | 1035 | filmslip |
gf | 1036 | filmstrip |
gs | 1040 | slide |
gt | 1039 | overhead transparency |
ha | 1021 | aperture card |
hb | 1024 | microfilm cartridge |
hc | 1025 | microfilm cassette |
hd | 1026 | microfilm reel |
he | 1022 | microfiche |
hf | 1023 | microfiche cassette |
hg | 1028 | microopaque |
hh | 1027 | microfilm slip |
hj | 1056 | microfilm roll |
hz | 1020 | other |
mc | 1032 | film cartridge |
mf | 1033 | film cassette |
mo | 1069 | film roll |
mr | 1034 | film reel |
mz | 1031 | other |
na | 1047 | roll |
nb | 1048 | sheet |
nc | 1049 | volume |
nn | 1046 | flipchart |
no | 1045 | card |
nr | 1059 | object |
nz | 1044 | other |
pp | 1030 | microscope slide |
pz | 1029 | other |
sd | 1004 | audio disc |
se | 1003 | audio cylinder |
sg | 1002 | audio cartridge |
si | 1005 | sound track reel |
sq | 1006 | audio roll |
ss | 1007 | audiocassette |
st | 1008 | audiotape reel |
sz | 1001 | other |
vc | 1051 | video cartridge |
vd | 1060 | videodisc |
vf | 1052 | videocassette |
vr | 1053 | videotape reel |
vz | 1050 | other |
zu | ? | unspecified |
Erscheinungsweise (RDA 2.13, Expressionsebene)
In diesen RDA-Bereich fallen die bisherigen Empfehlungen (hier mit angefügtem RDA Mode of Issuance, die unspezifischer sind):
Artikel | rdf:type | „bibo:Article“ | rdami:single unit |
Ausgabe | rdf:type | „bibo:Issue“ | rdami:single unit |
Zeitschrift | rdf:type | „bibo:Periodical“ | rdami:serial |
Sammlung | rdf:type | „bibo:Collection“ | ??? |
Serie | rdf:type | „bibo:Series“ | rdami:serial |
keine Angabe | rdf:type | „bibo:Document“ | rdami:single unit |
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
Blindenschrift | rdf:type | „lib:Braillebook“ |
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 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?
Teil-Ganzes-Beziehungen
dcterms:isPartOf
Aktuelle Empfehlung:
Link übergeordneter Titel Teil-Ganzes-Beziehung (link) -> unselbständig | dcterms:isPartOf |
Link übergeordneter Titel Teil-Ganzes-Beziehung (link) -> selbständig | dcterms:isPartOf |
ist Beilage zu (Verknüpfungsnummer zu übergeordneten Werken) | dcterms:isPartOf |
Neue mögliche Spezifizierungen:
Faksimile enthalten in | rdau:P60100 | Property name: is facsimile contained in |
Beigelegt in | rdau:P60194 | Property name: is inserted in |
Supplement zu | rdau:P60259 | Property name: is supplement to |
dcterms:hasPart
Aktuelle Empfehlung:
Link untergeordneter Teil | dcterms:hasPart |
Neue Spezifizierungen:
Enthält Faksimile von | Property name: is facsimile container of | |
Beilage | Property name: is insert | |
Supplement | Property name: is supplement (muss wahrscheinlich heissen "has supplement"?) |
Schriftenreihen
Bisher dcterms:isPartOf (s.o.), weitere Option: rdau:P60193 (is in series)
Parallele Ausgabe
Aktuelle Empfehlung:
Parallele Ausgabe | dcterms:hasVersion |
Parallele Ausgabe (physikalisch anders) | dcterms:isFormatOf |
Neue Spezifizierungen:
dcterms:hasVersion
Übersetzung von | Property-Name: is translation of | |
Synchronfassung von | Property-Name: is dubbed version of | |
Übersetzt als | Property-Name: is translated as | |
Synchronfassung | Property-Name: is dubbed version | |
Parallele Sprachausgabe | Vorbehaltlich |
dcterms:isFormatOf
Äquivalent | Property name: is equivalent (Superproperty) | |
Erscheint auch als | Property name: is also issued as | |
Mirror-Site | Property name: is mirror site | |
Begleitet von | Property name: is accompanied by (Superproperty) | |
Erscheint mit | Property name: is issued with | |
Verfilmt mit | Property name: is filmed with | |
Auf Disk mit | Property name: is on disc with |
Chronologische Verknüpfung
In der aktuellen Empfehlung werden bereits die rdau-Properties verwendet:
Vorgänger (bei Periodika) | rdau:P60261 |
Nachfolger (bei Periodika) | rdau:P60278 |
Die neuen Spezifizierungen sind jeweils als Subproperties der beiden angelegt:
Darin aufgegangen | Property-Name: is absorption of | |
Aufgegangen in | Property-Name: is absorbed by | |
Teilweise darin aufgegangen | Property-Name: is absorption in part of | |
Teilweise aufgegangen in | Property-Name: is absorbed in part by | |
Fortsetzung von | Property-Name: is continuation of | |
Fortgesetzt von | Property-Name: is continued by | |
Teilweise Fortsetzung von | Property-Name: is continued in part by | |
Gesplittet in | Property-Name: is split into | |
Vereinigung von | Property-Name: is merger of | |
Vereinigt, um ... zu bilden | Property-Name: is merged to form | |
Prequel | Property-Name: is prequel | |
Prequel zu | Property-Name: is prequel to | |
Ersatz von | Property-Name: is replacement of | |
Ersetzt durch | Property-Name: is replaced by | |
Teilweise Ersatz von | Property-Name: is replacement in part of | |
Teilweise ersetzt von | Property-Name: is replaced in part by | |
Abgespaltet von | Property-Name: is separated from | |
Teilweise fortgesetzt von | Property-Name: is continued in part by | |
Sequel zu | Property-Name: is sequel to | |
Sequel | Property-Name: is sequel |
- 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)