Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC - DV-Technik - SLUB-Domäne

29 Nov 2010

Liebe Frau Rühle, lieber Herr Meyer,

ich denke nicht, daß das ein Fehler in der Spezifikation ist. Es ist m.E. schlicht der
Vereinfachung geschuldet, die MODS eben vornimmt. Wenn wir uns damit nicht anfreunden
können, dann sollten wir grundsätzlich die Frage stellen, ob man statt dessen nicht gleich
MARC21 nimmt (sofern das Mapping der DNB irgendwann final ist) oder auf RDA wartet (sofern
das irgendwann Akzeptanz finden sollte)... Hier deshalb nochmal die Definition zu
<mods:hierarchicalGeographic>:

"Definition: a geographic name given in a hierarchical form relating to the
resource.

Application: 'hierarchicalGeographic' includes a hierarchical form of place name
which is both readable by humans and parsable by machines. This form can be applied to the
degree of specificity that is known or relevant and used to generate browsable hierarchies
even when values are specified to different levels. Explicit inclusion of the complete
hierarchy is of potential benefit for automated consultation of a gazetteer to derive map
coordinates or to support a map-based interface for searching by country or state. It is
equivalent to MARC 21 field 752." [1]

Es ist hier m.E. bewußt offengelassen, in welcher Relation der "geographische
Name" zur bibliographischen Einheit steht und wir tun uns m.E. keinen Gefallen, wenn
wir das nun einfach ignorieren, via <mods:extension> MARC21-Felder
"nachbauen" und mit bestehenden Mappings brechen (wenn die Verbünde irgendwann
auf MARC21 umgestiegen sein sollten, werden diese für uns viel wichtiger als aktuell).

Ich bin auch nicht wirklich glücklich mit dieser Vereinfachung (die Information gehörte
eigentlich in mods:originInfo/mods:place) und wir hatten das ja bereits hier ausführlich
diskutiert. Leider sieht das MODS v3.4 aber nicht vor. Warum auch immer.

BTW: Unterscheiden ließen sich die Verwendung jedoch durchaus. Man müßte "nur"
dafür sorgen, daß man klare Bezüge zu Normdatenquellen hätte (also z.B. RSWK, CERL usw.).

Beste Grüße,
Kay Heiligenhaus

[1]
http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#hierarchi…

...
  -----Original Message-----
 From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
 bounces(a)dfg-viewer.de] On Behalf Of Meyer, Sebastian
 Sent: Monday, November 29, 2010 5:08 PM
 To: technik(a)dfg-viewer.de
 Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC

 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
 http://www.slub-dresden.de/

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