Liebe Kolleginnen und Kollegen,
im Anhang finden Sie den Entwurf für das MODS-Anwendungsprofil für
digitalisierte Drucke (als doc und als pdf). Es handelt sich hierbei um eine
überarbeitete Version des zvdd-MODS Anwendungsprofils Version 1.0 (s.
http://www.zvdd.de/fileadmin/AGSDD-Redaktion/zvdd_MODS_Application_Profile_…
08-11-13.pdf). Dabei wurden die folgenden Änderungen vorgenommen:
* Erweiterung des Profils, um die übergreifende Nutzung in verschiedenen
Digitalisierungsprojekten zu erleichtern
** Einige Elemente sind nun nicht mehr verpflichtend, sondern conditional
bzw. optional
** weitere Attribute wurden hinzugefügt (z.B. authorityURI, valueURI, etc.)
* Der Aufbau des Profils orientiert sich nun an den MODS User Guidelines
(http://www.loc.gov/standards/mods/mods-outline.html)
* Die in dem zvdd-MODS Anwendungsprofil mit UNE (unerwünscht)
gekennzeichneten Elemente wurden in diesem Profil nicht mehr berücksichtigt.
* Informationen zu der analogen Vorlage des Digitalisats / zum Original
können in Zukunft unter <mods:relatedItem type="original"> zur Verfügung
gestellt werden.
* zvdd-spezifische Anforderungen wurden nicht übernommen und werden in einem
eigenen Papier veröffentlicht.
* Die in dem zvdd-MODS Anwendungsprofil integrierten Mappings werden in
Anhängen zur Verfügung gestellt.
Noch nicht fertigestellt sind die Anhänge:
* Die Überarbeitung der METS-MODS-Beispiele - diese würde ich gerne erst nach
der Verabschiedung des APs fertigstellen.
* Die Überarbeitung des PICA+-Mappings
* Die Überarbeitung des MAB-Mappings - bitte teilen Sie mir mit, ob dieses
Mapping noch benötigt wird.
* Die Erstellung eines Dublin Core Mappings - auch dies werde ich erst nach
der Verabschiedung des APs erstellen.
Zudem braucht das Anwendungsprofil nun einen anderen Namen. Über Vorschläge
würde ich mich freuen.
Bitte schicken Sie Anmerkungen und Korrekturvorschläge bis zum 15. Dezember
über diese Liste, damit sie von allen Interessierten diskutiert werden
können.
Viele Grüße
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
Lieber Herr Meyer,
> Richtig, aber ich habe den Druck _digitalisiert_ und nicht gedruckt, weshalb
> das _Digitalisat_ auch keinen Druckort besitzt, die Vorlage aber schon. Den
> Inhalt hat aber in beiden Fällen derselbe Autor verfasst, denn einen Inhalt
> hat auch das Digitalisat und dieser ist auch gegenüber der gedruckten
> Vorlage unverändert.
Wollen Sie das dann auch im Header im Viewer anzeigen? Also z.B. bei diesem Druck
http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net%2Foai…
Anstatt:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Wittemberg 1531 [VD16 L 7428]
Eben:
Luther, Martin: Widder den Meuchler zu Dresen gedrueckt Aachen 2010 [VD16 L 7428]
> Eben nicht. Meines Erachtens handelt es sich dann um eine Streitschrift
> Martin Luthers, digital publiziert von Kay Heiligenhaus 2010 in Aachen, die auf
> einer 1531 von Hans Lufft in Wittenberg gedruckten Vorlage basiert. Und
> genau so geben wir das doch bislang auch in den Metadaten an, nur dass wir
> die Angaben zur Vorlage und die abweichenden Angaben zum Digitalisat in
> zwei separate <mods:originInfo>-Blöcke kapseln, statt - wie es Frau Rühle
> vorschlägt - die Angaben zur Vorlage in <mods:relatedItem type="original">
> unterzubringen.
> Ich hatte die Tatsache, dass wir für die Digitalisate auch eigene Katalogisate
> im Verbund anlegen, bisher auch immer so verstanden, dass das Digitalisat
> tatsächlich als eigenständige Publikation betrachtet wird. Ist dem nicht so?
Nehmen wir einfach ein Beispiel aus dem Dresdner VD18-Bestand:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=331522233
In der Sekundärform finden Sie die Angaben zum Erscheinungsvermerk in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. Die Angaben zur Sekundärausgabe stehen in 033N$pDresden$nSLUB und 011B$a2010. Nun sehen Sie sich die Primärform an:
http://swb.bsz-bw.de/DB=2.1/PPNSET?PPN=061720305
Auch hier finden Sie die Angaben zum Erscheinungsvermerk ganz analog zur Sekundärform in PICA+ 033A$pLeipzig$nBauch und 011@$a1716. _Das_ ist die aktuelle Katalogisierungspraxis. Hierzu existieren Mappings zu MARC21, die vom BSZ auch ziemlich weitreichend umgesetzt wurden. Von hier aus kommen Sie via existierender Mappings zu MODS (hatte ich alles bereits, denke ich, hinreichend hier vorgestellt). Und wenn Sie das nun alles durchspielen, zerfallen alle Ihre Überlegungen: zu bibliographischem Staub. Es sei denn, man möchte einen proprietären Sonderweg einschlagen, der einfach die bibliographischen Tatsachen ignoriert und vollkommen inkompatibel ist mit dem, was der Rest der Welt so treibt. Ich denke nicht, daß Sie das wirklich möchten.
Wie gesagt, wenn man das alles konsequent durchspielt, dann bleibt zum Schluß: Entweder, wir lassen es, wie es ist. Oder, wir machen es via Abbildung auf MARC21 533 mit note/@type="reproduction" (das würde aus dem Mapping PICA+/MAB2 zu MARC21 folgen). Alles andere ist schlichtweg nicht haltbar, da mögen Sie noch so lange argumentieren, daß Sie das anders _sehen_. Es _ist_ nicht anders. Vielleicht sprechen Sie darüber einfach mal mit einem Katalogisierer Ihres Vertrauens. ;)
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
> Grundsätzlich gebe ich Ihnen recht: natürlich sollten alle bibliographischen
> Angaben zur Vorlage in <relatedItem type="original"> stehen. Dass das der
> Idealzustand wäre, wir ihn aber mit unserer aktuellen Katalogisierungspraxis
> nicht erreichen, ist mir bewusst - dennoch halte ich es für sinnvoll, auf diesen
> Idealzustand hinzuarbeiten.
Jetzt kommen Sie ins Philosophieren. ;) - - - Vor lt. Digitalisierung scheinen Sie zu verkennen, daß es einen guten Grund gibt, warum Sekundärformen so nicht katalogisiert werden: Wenn wir eine Streitschrift Martin Luthers, gedruckt von Hans Lufft 1531 in Wittenberg, heute auf den Scanner legen und ins Internet stellen, dann bleibt das eine Streitschrift Martin Luthers, gedruckt von Hans Lufft 1531 in Wittenberg (rsp. deren layoutgetreue Reproduktion)!
> Speziell beim Verfasser würde ich Ihnen allerdings widersprechen, denn der
> Verfasser ist der Urheber des Inhalts eines Werks - und der ändert sich doch
> durch die Digitalisierung nicht, sollte also bei Vorlage und Digitalisat identisch
> sein.
Und so ist das auch beim Erscheinungsvermerk, denn Sie haben genau diesen Druck digitalisiert, nicht den Nachdruck aus Leipzig von 1551.
> Richtig, allerdings sollte ein AP das meines Erachtens nur dort tun, wo es
> notwendig ist. Wenn sich die Zugehörigkeit eines Metadatums zu Vorlage
> bzw. Digitalisat in MODS nicht ausdrücken ließe, dann müsste eine
> entsprechende Festlegung im AP getroffen werden, die das ermöglicht. Nun
> haben wir aber in MODS eine (wie ich finde) sehr naheliegende Möglichkeit,
> die gegenüber unserer bisherigen Festlegung keine Nachteile hat, dafür aber
> den großen Vorteil, auch von jedem anderen MODS-Anwender ohne
> Kenntnis unseres AP verstanden zu werden. Deshalb halte ich es in jedem
> Fall für erstrebenswert, diese Möglichkeit künftig zu nutzen.
Ja. Sie befinden sich damit nur sehr allein auf dem Metadatenfeld. Kein bestehendes Mapping gibt diese Modellierung her. Wir müßten sie ins AP schreiben, damit das jemand verstehen kann (insbesondere eine Maschine, die das Mapping dann abweichend ausführen muß). Und wir müßten dem Rest der Welt erklären, daß er einem großen Irrtum unterliegt und doch bitte unserem, überlegenen Mapping folgen.
Nee. Das ist und bleibt m.E. grundsätzlich falsch gedacht. Es sieht nur mit Ihrer XPath-Brille rosafarben aus. ;)
Beste Grüße,
Kay Heiligenhaus
Liebe Frau Rühle,
ich habe mir das mal weiter angeschaut - und es gibt eine knappe Diskussion zum Thema auf der MODS-Mailingliste unter [1]. Das Ergebnis kann man sehen im Vergleich der XSLT-Versionen für MODS v3.2 [2] und MODS v3.3 [3]: Das Mapping von MARC21-Feld 752 gibt es seit MODS v3.0. Erst mit MODS v3.3 wird dann ein paralleles Mapping von MARC-Feld 662 eingeführt. Man kann also m.E. eindeutig davon ausgehen, daß es sich hier nicht um einen Fehler handelt, sondern eben um eine bewußte Entscheidung. Diese scheint mir auch begründet, den es gibt eine reichhaltige Diskussion über die Verwendung von MARC21-Feld 752. Schaut man sich z.B. den "Guide to Rare Book Records in Online Systems" an, dann liest man:
"NOTE (c): According to the USMARC format documentation, field 752 (Added Entry-Hierarchical Place Name) may be used 'to give access to a bibliographic record through a hierarchical form of a place name related to a particular attribute (e.g. for newspapers, the name of the community served; for rare books, the place of publication or printing).' Because of the range of situations in which this field may be used, it is advisable to give it a fairly general label, such as 'Place' or 'Associated place' rather than 'Place of publication'." [4]
Bedeutet unterm Strich, daß in MARC21 die Verwendung von Feld 752 so vielfältig ist, daß man schlicht nicht davon ausgehen kann, daß hier ausschließlich normierte Verlags-/Druckorte stehen. Diese Differenziertheit haben wir jedoch in MAB2 und PICA+ (wobei sie verloren ginge, sollten die Verbünde irgendwann auf MARC21 als Katalogisierungsformat umsteigen). Würde man so mappen, wie von mir vorgeschlagen, würde man mit dieser Einschränkung leben müssen, hätte aber den Vorteil, internationalen Standards zu folgen und nicht zwanghaft an der Differenziertheit unserer nationalen Erschließung zu kleben. Man sieht am MAB2-MARC21-Mapping der DNB, daß dieser Kompromiß hier eben eingegangen wurde.
Nun haben wir uns entschieden, das für digitalisierte Drucke noch weiter zu vereinfachen, indem wir MODS als Datenformat gewählt haben. Und gleichzeitig kleben wir an einer Reichhaltigkeit der bibliographischen Beschreibung, die es nicht mal in MARC21 gibt. Wie gesagt, ich bin damit auch nicht wirklich glücklich. Aber es macht auch m.E. keinen Sinn, bei unseren Diskussionen diese Grundentscheidung zur Simplifikation durch die Verwendung von <mods:extension> auszuhebeln oder schlicht wichtige Informationen dann eben gar nicht zu liefern.
Das nun wirklich abschließend von meiner Seite zu dieser Diskussion. Wenn wir uns für das MODS AP v2.1 nicht einigen können - wie es aussieht -, dann bliebe wohl tatsächlich nur, hier eben separate Vereinbarungen für z.B. das VD18 zu treffen und sich im AP v2.1 über das Thema einfach auszuschweigen.
Beste Grüße,
Kay Heiligenhaus
[1] http://comments.gmane.org/gmane.comp.text.mods/872
[2] http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-2.xsl
[3] http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-3.xsl
[4] http://www.rbms.info/committees/bibliographic_standards/committee-docs/guid…
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
> bounces(a)dfg-viewer.de] On Behalf Of Kay Heiligenhaus
> Sent: Tuesday, November 30, 2010 11:14 AM
> To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC
>
> Lieber Frau Rühle,
>
> > Ich bin weiterhin der Meinung, dass sich die Kollegen, die das Mapping
> > gemacht haben, entweder geirrt haben oder einen Anwendungsfall im
> Kopf
> > hatten, der mir nicht bekannt ist. Aber
> > Verlags- und Druckort an dieser Stelle zu speichern, ist m. E. ein
> > semantischer Fehler, den wir vielleicht in bestimmten Projekten über
> > die Verwendung kontrollierter Vokabulare steuern könnten, aber gewiß
> > nicht in allen Projekten.
>
> Um uns herum also offensichtlich lauter Irrtümer, denn auch die Schweizer
> Kollegen scheinen sich schlicht geirrt zu haben, wenn sie ebenfalls MARC21-
> Feld 752 genau zu diesem Zweck nutzen [1] und dem LoC-MARC21-MODS-
> Mapping folgend zu <mods:hierarchicalGeographic> mappen? [2] Daß die in
> MAB2 hier verwendete Segmentgruppe "Segment zusätzliche Suchkriterien"
> heißt, ist ebenfalls ein Irrtum. Daß wir bei Hochschulschriften den
> Hochschulort mit der GKD verknüpfen ebenfalls.
>
> Da wir also von lauter Irrtümern umzingelt sind, schließe ich mich Ihrer
> Schlußfolgerung an, daß wir im DV-MODS-AP v2.1 zu diesem
> Themenkomplex einfach keine Aussagen machen sollten.
>
> Beste Grüße,
> Kay Heiligenhaus
>
> [1]
> http://www.informationsverbund.ch/fileadmin/user_upload/dokumente/k
> atalogisierung/kids/kids_deutsch/bib.pdf - S. 134.
>
> [2] http://www.e-
> rara.ch/bau_1/oai?verb=GetRecord&metadataPrefix=mods&identifier=1062
> 363
Lieber Frau Rühle,
> Ich bin weiterhin der Meinung, dass sich
> die Kollegen, die das Mapping gemacht haben, entweder geirrt haben oder
> einen Anwendungsfall im Kopf hatten, der mir nicht bekannt ist. Aber
> Verlags- und Druckort an dieser Stelle zu speichern, ist m. E. ein semantischer
> Fehler, den wir vielleicht in bestimmten Projekten über die Verwendung
> kontrollierter Vokabulare steuern könnten, aber gewiß nicht in allen
> Projekten.
Um uns herum also offensichtlich lauter Irrtümer, denn auch die Schweizer Kollegen scheinen sich schlicht geirrt zu haben, wenn sie ebenfalls MARC21-Feld 752 genau zu diesem Zweck nutzen [1] und dem LoC-MARC21-MODS-Mapping folgend zu <mods:hierarchicalGeographic> mappen? [2] Daß die in MAB2 hier verwendete Segmentgruppe "Segment zusätzliche Suchkriterien" heißt, ist ebenfalls ein Irrtum. Daß wir bei Hochschulschriften den Hochschulort mit der GKD verknüpfen ebenfalls.
Da wir also von lauter Irrtümern umzingelt sind, schließe ich mich Ihrer Schlußfolgerung an, daß wir im DV-MODS-AP v2.1 zu diesem Themenkomplex einfach keine Aussagen machen sollten.
Beste Grüße,
Kay Heiligenhaus
[1] http://www.informationsverbund.ch/fileadmin/user_upload/dokumente/katalogis… - S. 134.
[2] http://www.e-rara.ch/bau_1/oai?verb=GetRecord&metadataPrefix=mods&identifie…
Lieber Herr Meyer,
> Genau so verstehe ich es auch. Wir beschreiben das Digitalisat und
> verweisen auf die Vorlage. Das entspricht auch unserem
> Digitalisierungsworkflow, der auf dem Verbund-Katalogisat des Digitalisats
> aufsetzt und nicht auf dem des Originals.
Dann sollten wir in der Konsequenz _alle_ bibliographischen Informationen der Vorlage in dieses <mods:relatedItem type="original"> packen, nicht nur die Angaben zum Erscheinungsvermerk. Einen Verfasser des Digitalisates gibt es ja ebenfalls nicht, den hat "nur" die Vorlage. - - - Ich muß ehrlich sagen, daß ich nicht verstehen kann, warum Sie hier unsere aktuelle Katalogisierungspraxis von Sekundärformen schlicht ignorieren und neue bibliographischen Tatsachen erfinden.
> Das veranschaulicht meines Erachtens sehr schön das Problem unserer
> aktuellen Kodierung: sie ist uneindeutig. Wenn kein <originInfo>-Element
> mit <edition>[Electronic ed.]</edition> existiert, sehr wohl aber eines ohne
> <edition>, dann können wir nicht sagen, worauf sich letzteres bezieht -
> Vorlage oder Digitalisat?
Warum das denn?
> Streng nach Anwendungsprofil ist die Sache zwar
> klar, aber auch nur, wenn man das Anwendungsprofil kennt - die Information
> ist nicht explizit in der METS-Datei verfügbar.
Okay. Es ist richtig, daß man an dieser Stelle das AP kennen muß. Aber das ist eben auch der Sinn von APs: spezifische Vereinbarungen zu dokumentieren.
> Insofern würde ich mich Frau Rühle anschließen: Variante 2 gefällt mir am
> besten, ich könnte aber auch mit Variante 3 leben (wobei bei Variante 3 sich
> letztlich die Praxis durchsetzen wird, die DFG-Viewer & Co. unterstützen -
> letztlich läge die Entscheidung also immer noch bei uns).
Ich halte beide Varianten - wie beschrieben - nach wie vor für nicht formal herleitbar. Und das hat mit gefallen oder nicht nichts zu tun!
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
> Wenn Sie doch ebenfalls nicht glücklich mit der Vereinfachung sind und lieber
> <originInfo><place> nutzen würden (was ich auch bevorzugen würde),
> warum dann nicht den Versuch wagen, das für MODS 3.5 anzustreben?
Weil es keinen Weg dahin von unseren aktuellen Katalogdaten aus gibt. Weder in MAB2 (Feld 673a), noch in PICA+ (Feld 033B/03) noch in MARC21 (Feld 752) werden die Informationen in dieser Form aufeinander bezogen (Ort := normalisierter Ort). Diese stehen "isolitert" als Suchhilfen zur Verfügung, mehr nicht. Deshalb ist die "unspezifische Form" über <mods:subject> den Katalogisierungsgegebenheiten durchaus angemessen.
> Oder benötigen wir dazu so dringend eine Festlegung, dass wir die
> Vereinfachung in Kauf nehmen müssen?
> Meines Erachtens würden wir mit einer "übereilten" Festlegung langfristig
> mehr Probleme bekommen (Stichwort: Abwärtskompatibilität).
Ja. Aber das zugrundeliegende Problem ist dann m.E. eben zu "altbestandsspezifisch", als daß man darauf hoffen könnte, hier auf Ebene der Formate zu einer besseren Lösung zu kommen, als wir sie aktuell haben. Selbst wenn es in MODS v3.5 eine adäquate Lösung gäbe, gäbe es keinen Weg von unseren aktuellen Daten dorthin...
Beste Grüße,
Kay Heiligenhaus
Entschuldigung, die Anrede sollte natürlich "Lieber Herr Heiligenhaus" lauten. Da hatte ich noch einen falschen Text in der Zwischenablage.
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206<tel:+49%20351%204677-206>
Telefax: +49 351 4677-711<tel:+49%20351%204677-711>
Web: http://www.slub-dresden.de
________________________________
Von: Meyer, Sebastian
Sent: Montag, 29. November 2010 19:59
An: technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
Lieber Herr Mittebach,
Wenn Sie doch ebenfalls nicht glücklich mit der Vereinfachung sind und lieber <originInfo><place> nutzen würden (was ich auch bevorzugen würde), warum dann nicht den Versuch wagen, das für MODS 3.5 anzustreben?
Oder benötigen wir dazu so dringend eine Festlegung, dass wir die Vereinfachung in Kauf nehmen müssen?
Meines Erachtens würden wir mit einer "übereilten" Festlegung langfristig mehr Probleme bekommen (Stichwort: Abwärtskompatibilität).
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206<tel:+49%20351%204677-206>
Telefax: +49 351 4677-711<tel:+49%20351%204677-711>
Web: http://www.slub-dresden.de
________________________________
Von: Kay Heiligenhaus
Sent: Montag, 29. November 2010 17:26
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
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
> >
> >
> >
> >
> >
> >
>
Lieber Herr Mittebach,
Wenn Sie doch ebenfalls nicht glücklich mit der Vereinfachung sind und lieber <originInfo><place> nutzen würden (was ich auch bevorzugen würde), warum dann nicht den Versuch wagen, das für MODS 3.5 anzustreben?
Oder benötigen wir dazu so dringend eine Festlegung, dass wir die Vereinfachung in Kauf nehmen müssen?
Meines Erachtens würden wir mit einer "übereilten" Festlegung langfristig mehr Probleme bekommen (Stichwort: Abwärtskompatibilität).
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Referatsleiter Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206<tel:+49%20351%204677-206>
Telefax: +49 351 4677-711<tel:+49%20351%204677-711>
Web: http://www.slub-dresden.de
________________________________
Von: Kay Heiligenhaus
Sent: Montag, 29. November 2010 17:26
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC
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
> >
> >
> >
> >
> >
> >
>
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
> >
> >
> >
> >
> >
> >
>
