Liebe Frau Rühle, lieber Herr Heiligenhaus,
das ist tatsächlich eine kniffelige Frage. Ich kann beide Standpunkte gut verstehen, würde
aber auch eher zu Frau Rühles Lösungsvorschlag tendieren. Nicht weil ich ihn gut finde,
sondern weil er meines Erachtens das kleinere Übel darstellt. Im Zweifel sind mir aber
semantisch saubere Metadaten wichtiger als der Verzicht auf MODS-Erweiterungen über
<mods:extent>.
Für mich stellt sich die Frage, wie denn die ideale Lösung aussähe? Wo und wie würden Sie
die Angaben denn am liebsten kodieren, wenn MODS es erlauben würde? Vielleicht sollten wir
besser eine entsprechende Erweiterung von MODS anstreben und uns bis dahin gar nicht zu
hierarchischen Druck- und Verlagsorten äußern, als jetzt einen Kompromiss zu schließen,
der niemanden glücklich macht.
Viele Grüße
Sebastian Meyer
-- 
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Telefon: +49 351 4677-206
Telefax: +49 351 4677-711
  -----Ursprüngliche Nachricht-----
 Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
 viewer.de] Im Auftrag von Ruehle, Stefanie
 Gesendet: Montag, 29. November 2010 16:25
 An: dv-technik(a)dfg-viewer.de
 Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
 
 Hallo Herr Heiligenhaus,
 
  <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. 
 
 ja, und das geschieht nicht nur in dem Mapping, sondern in der
 "Detailed
 Description of MODS Elements" wird auch und nur auf 752 verwiesen.
 (see:
 
http://www.loc.gov/standards/mods/v3/mods-userguide-
 elements.html#hierarchica
 lgeographic)
 
 M. E. ist das ein grober Fehler in der MODS-Dokumentation. Schauen Sie
 sich
 das Mapping an, so stellen Sie fest, das auch 662 auf
 <mods:subject><mods:hierarchicalGeographic> gemappt wird. Und damit
 wird aus
 dem Fehler ein echtes Problem. Im Grunde genommen haben wir jetzt den
 folgenden Sachverhalt:
 
 <mods:hierarchicalGeographic> wird definiert als: "a geographic name
 given in
 a hierarchical form relating to the resource"
 
 das klingt ja noch ganz gut und würde auch auf alles passen. Aber
 dieses
 Element ist nun einmal ein Subelement zu <mods:subject>, heißt, was für
 <mods:subject> gilt, gilt auch für <mods:hierarchicalGeographic> Und
 <mods:subject> ist definiert als:" A term or phrase representing the
 primary
 topic(s) on which a work is focused."
 
 Demnach kann <mods:hierarchicalGeographic> eigentlich nur dann
 verwendet
 werden, wenn es sich um geographische Angaben handelt, die den topic,
 also
 das Thema der Ressource beschreiben.
 
 Das Mapping auf MARC21-Feld 662 - "Subject Added Entry-Hierarchical
 Place
 Name" macht in dieser Hinsicht darum m. E. auch absolut Sinn, denn 662
 wird
 definiert als: "Hierarchical form of a geographic name used as a
 subject
 added entry."
 
 Das Mapping auf MARC21-Feld 752 - "Added Entry-Hierarchical Place Name"
 macht
 m. E. hingegen wenig Sinn. Wie Sie ja schon festgestellt haben, lautet
 die
 Definition: "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."
 
 Ärgerlich ist an der Sache aber vor allem, dass in dem Moment, wo
 sowohl 662
 als auch 752 in <mods:subject><mods:hierarchicalGeographic> verwendet
 werden,
 überhaupt nicht mehr zu unterscheiden ist, ob es sich nun um den
 Verlags-
 bzw. Druckort handelt - also die Frage, an welchem Ort ist das Werk
 entstanden -, oder um den Topic - also die Fragen nach dem Ort der
 Handlung
 des Werks, Thema des Werks usw. Das sind ja doch zwei grundsätzlich
 unterschiedliche Fragestellungen. Diese in einem Feld
 zusammenzuschmeißen
 finde ich für die Nachnutzbarkeit der Daten einfach fatal, denn
 
 * in Suche, Browsing und Anzeige der Treffen kann der Nutzer nun nicht
 zwischen Druck- und Verlagsorten einerseits und Thema des Werks
 andererseits
 unterschieden,
 * bei der Konversion der Daten in ein ggf. anderes Format lassen sich
 die
 Daten nicht mehr vernünftig mappen.
 
 Angesichts der Tatsache, dass wir das Profil ja nicht für eine einzelne
 Anwendung verwenden und es auch für zukünftige Anwendungen möglichst
 flexibel
 sein muss, müssen wir diese beiden Fragestellungen auf jeden Fall
 auseinanderhalten. Und da 622 nun einmal semantisch dem entspricht, was
 <mods:subject><mods:hierarchicalGeographic> eigentlich sein soll, würde
 ich
 dafür plädieren, für den Sachverhalt von 752 eine Lösung in
 <mods:extent> zu
 suchen.
 
 Wie stehen die anderen dazu?
 
 fragt sich
 
    Stefanie Rühle
 
 ------------------------------------------
 Stefanie Rühle
 Niedersächsische Staats- und Universitätsbibliothek (SUB) Göttingen
 Goettingen State and University Library
 Metadaten und Datenkonversion
 Papendiek 14
 37073 Göttingen
 Tel.: +49(0)551/39-10905
 E-Mail: sruehle(a)sub.uni-goettingen.de
 Internet: 
http://www.sub.uni-goettingen.de
 
 
 
 -----Original Message-----
 From: dv-technik-bounces(a)dfg-viewer.de on behalf of Kay Heiligenhaus
 Sent: Mon 29.11.2010 12:42
 To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de
 Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC
 
 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/00
 0489.html
 
 
 
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-
 20100607/00
 0492.html
 
  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