Liebe Frau Rühle,
vielen Dank für Ihre schnelle Rückmeldung! Kurz zu einigen Punkten:
4) Die
Ausführungen (S. 5ff.) zu Titeln sind m.E. nicht kompatibel mit
MAB2. Teile mehrbändiger Werke haben häufig keine eigenen Titel,
sofern sie eben keine Stücktitel sind. Ein Beispiel finden Sie unter
[2]. Ein MAB2-Mapping würde hieran scheitern rsp. das Mapping
erheblich erschweren.
Zudem berücksichtigt der Viewer diese Konstrukte hinreichend, sofern
man die Daten so liefert, wie es das Beispiel [3] zeigt.
Ich verstehe Ihre Anmerkung nicht ganz. Geht es um die Aussage, dass das
Wurzelelement einen <titleInfo> haben muss? Dann haben Sie
wahrscheinlich
recht: Bei mehrbändigen Werken ohne eigenen Stücktitel wird der Titel
bereits im Subelement <titleInfo> in <relatedItem type="host">
gespeichert,
es braucht also kein Element <titleInfo>. Geht es darum? Dann würde ich das
ändern.
Ja, darum ging es mir.
7) Bei
<mods:originInfo> (S. 11ff) sollte man m.E. Beispiele für die
Verwendung mehrere Erscheinungsorte und Verlage geben.
Ich kann entsprechende Beispiele nachtragen.
Hier spielt m.E. die Reihenfolge durchaus eine
Rolle!
Mir ist nicht ganz klar, in welcher Form. Könnte ich dazu ein Beispiel haben?
Die Frage ist hier m.E., wie man "Pärchen" von Erscheinungsorten und Verlagen
gruppiert. Besonders interessant wird es, wenn wir z.B. Verlage mit zwei Erscheinungsorten
haben in Kombination mit einem Verlag mit einem Erscheinungsort, also das Muster (EOXVY
für Erscheinungsort X des Verlages Y):
EO1V1, EO2V1 : V1 ; EOV2 : V2 ; EO1V3, EO2V3 : V3
8) Das
Beispiel zur Verwendung von @keydate (S. 15) halte ich nicht
für plausibel.
Ich werde die Beispiele überarbeiten, müsste aber wissen, was genau nicht
plausibel ist?
Für die Angabe von
<mods:dateCreated encoding="w3cdtf" qualifier="approximate"
point="start">1630</mods:dateCreated>
<mods:dateCreated encoding="w3cdtf" qualifier="approximate"
point="end">1633</mods:dateCreated>
sehe ich noch keinen rechten Sinn bei Druckschriften. Welchen "Spezialfall"
haben Sie denn hier im Auge? Besser fände ich es, wenn zunächst ein "einfaches
Standardbeispiel" aufgeführt würde und dann verschiedene Varianten von
mods:dateIssued/@qualifier anstatt mods:dateCreated/@qualifier.
10) Bei
<mods:subject> (S. 20ff.) fehlt mir ein Hinweis auf dessen
Verwendung im Rahmen der Codierung von normierten Druck-
/Verlagsorten.
Wir hatten das in Göttingen, Berlin und auch hier
auf der Liste
intensiv diskutiert. Vorgesehen dafür ist die Verwendung des Elementes
<mods:hierarchicalGeographic> [5].
Sorry, die Diskussion habe ich nicht mitbekommen:-(
Hier die beiden Einsprungpunkte dazu:
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-20100607/…
Ich habe den Vorschlag,
<mods:subject><mods:hierarchicalGeographic> zu verwenden noch einmal
geprüft und muss gestehen, dass das m. E. gar nicht geht. Die Definition zu
<mods:subject> lautet: "A term or phrase representing the primary topic(s)
on which a work is focused." Es wäre ein eklatanter Verstoß gegen die
Regeln semantischer Konformität, dies für die Druck- und Verlagsorte zu
nutzen. Aber warum nehmen wir nicht <mods:extent>? Das scheint mir
genau für einen solchen Fall gedacht: "used to provide for additional
information not covered by MODS." Was wir brauchen könnte
folgendermaßen oder ähnlich aussehen:
<mods:extension>
<xxx:wrap>
<xxx:hierarchicalPlaceOfPublication>
<xxx:country>Deutschland</mods:country>
<xxx:state>Sachsen</mods:state>
<xxx:city>Leipzig</mods:city>
</xxx:hierarchicalPlaceOfPublication>
</xxx:wrap>
</mods:extension>
<mods:extent> sollte man m.E. nicht zu schnell bei der Hand haben. Die Herleitung
für ein Mapping auf <mods:hierarchicalGeographic> habe ich im o.g. ersten Posting
gegeben. Es leitet sich ab von MARC21-Feld 752, das eben genau so definiert ist:
"Added entry in which the entry element is a hierarchical form of place name that is
related to a particular attribute of the described item, e.g., the place of publication
for a rare book." [1] Nach LoC-MARC21-MODS-Mapping wird es auf <mods:
hierarchicalGeographic> gemapped.
Denn darauf
beziehen wir uns, wenn wir hier z.B. VD-Nummern eintragen.
Das Problem ist mir auch schon bei der Bearbeitung des PICA+ Mappings
begegnet und ich muss gestehen, dass ich mich mit der Natur der VD-
Nummer nicht auskenne und nicht weiß, ob es sich dabei um einen Objekt-
Identifier handelt, wiederzugeben in <mods:identifier> oder den Identifier
der Metadaten, wiederzugeben in
<mods:recordInfo><mods:recordIdentifier>. Kann mir da jemand
weiterhelfen.
Hinter eine VD-Nummer können sich aber x
"Ressourcen"
(= Sekundärformen) verbergen.
Das ist bei einer ISBN auch so. Diese steht für alle "manifestations". Wie
sieht
das bei den VD-Nummern aus?
Nach meinem Verständnis ist eine VD-Nummer durchaus vergleichbar mit einer ISBN.
Beste Grüße,
Kay Heiligenhaus