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

> -----Original Message-----
> From: dv-technik-bounces@dfg-viewer.de [mailto:dv-technik-
> bounces@dfg-viewer.de] On Behalf Of Meyer, Sebastian
> Sent: Monday, November 29, 2010 5:08 PM
> To: technik@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@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@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@sub.uni-goettingen.de
> > Internet: http://www.sub.uni-goettingen.de
> >
> >
> >
> > -----Original Message-----
> > From: dv-technik-bounces@dfg-viewer.de on behalf of Kay Heiligenhaus
> > Sent: Mon 29.11.2010 12:42
> > To: dv-technik@dfg-viewer.de; dv-technik@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
> >
> >
> >
> >
> >
> >
>