Liebe Liste, 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. 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? 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. 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). 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: Sonntag, 28. November 2010 18:02 > An: dv-technik(a)dfg-viewer.de; Meyer, Sebastian > Betreff: Re: [DFG-Viewer] MODS-AP für digitalisierte Drucke - CfC > > Lieber Herr Heiligenhaus, > > > ich habe mir das heute nochmal näher angeschaut. Ich hatte > > wohl in der Tat den Vorschlag falsch verstanden, was aber > > nichts daran ändert, daß ich diesem nicht folgen mag, da das > > <relatedItem type="original"> einfach anders verwendet wird in > > MODS als wir es hier unterstellen müßten. > > > Allen Verwendungen von <relatedItem> dienen nach meinem > > Verständnis dazu, Beziehungen zu anderen Datensätzen (!) > > auszudrücken. > > Die Beschreibug in MODS lautet: > > "<relatedItem> is a container element under which any MODS element may > be > used as a subelement." > Also nicht nur und nicht unbedingt Identifier, die Datensätze > miteinander > verlinken. Und auch die Beispiele in der MODS-Dokumentation sehen nicht > so > aus, als sollten hier nur Beziehungen zwischen Datensätzen hergestellt > werden. > > s. http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html > > > Schaut man sich hierzu das LoC-MARC21-MODS-Mapping > > genauer an, dann sieht man, wie das Element zu verwenden ist. > > [1] Es leitet sich im Kern von den MARC21-Feldern 760-787 > > und 800-830 ab. > > Uns braucht hier nur die erste Feldsequenz > > zu interessieren [2] und hier dann speziell [3]. Schaut man nun > > ins Mapping, dann sieht man, daß die Mapping-Regeln nicht > > zu der Modellierung führen, die Frau Rühle vorschlägt. > > MARC21 Feld 786 (die MARC21-Grundlage von <relatedItem > > type="original">) ist einfach nicht dazu gedacht, Angaben zur > > Primärform in der hier vorgeschlagenen Weise zu transportieren, > > es dient vielmehr dazu, eine Beziehung zwischen Primär- und > > Sekundärform herzustellen! > > Ich gebe zu, mein Ausgangspunkt war nicht Feld 786 und auch nicht Feld > 533, > sondern Feld 534 > > s. http://www.loc.gov/marc/bibliographic/bd534.html > > In den Mappings wird <mods:relatedItem type="original"> > > sowohl in dem MARC21 zu MODS Mapping > s. http://www.loc.gov/standards/mods/mods-mapping.html#relateditem > > als auch in dem MODS zu MARC21 Mapping > > s. http://www.loc.gov/standards/mods//v3/mods2marc- > mapping.html#relateditem > > der Kategorie 534 zugewiesen (wobei 534 allerdings auch auf <mods:note > type="original version"> gemappt werden kann). > > > Wenn wir an dieser Stelle Änderungen vornehmen wollen, > > dann hilft uns m.E. ein Blick in die EROMM-"Empfehlungen > > zur Erfassung von layoutgetreuen Digitalisaten (digitale Master)" > > eher weiter. [4] Hier sieht man, daß nicht die Angaben zum > > Erscheinungsvermerk der Vorlage anders kodiert werden müßten, > > sondern die Angaben zur Onlineausgabe. > > Hierzu dient in MARC21 Feld 533. (Eine solche Abbildung wäre > > auch kompatibel mit den Mapping-Regeln der zugrundeliegenden > > MAB-Felder 610ff., wie sie in [6] beschrieben sind.) > > Was als Beziehung kodiert wird, ist m. E. immer davon abhängig, was ich > mit > meinem MODS-Datensatz beschreibe: > > - Beschreibe ich das Digitalisat, kodiere ich die Informationen zum > Original > als Beziehung (also Feld 534). > - Beschreibe ich hingegen das Original, dann kodiere ich die > Informationen > zum Digitalisat als Beziehung (in Feld 533). > > Das ergibt sich aus: <mods:physicalDescription><mods:digitalOrigin> ;-) > > Ich kann mich aber auch mit der anderen Richtung anfreunden - wir > beschreiben > das Original und verweisen über eine Beziehung zum Digitalisat. > > > Ist MARC21-Feld 533 noch hinreichend differenziert, um die > > Angaben, die wir hier brauchen, zu transportieren, wird nach > > Anwendung des LoC-Mappings jedoch in etwa folgendes > > MODS daraus: > > <note type="reproduction">[Online-Ausg.] Göttingen : Niedersächsische > > Staats- und Universitätsbibliothek, 2010</note> > > Wie Sie schon dargestellt haben, lässt sich Feld 533 leider nicht auf > <mods:relatedItem> mappen, sondern nur auf <mods:note > type="reproduction">. > Und dass lässt sich nicht in der gewünschten Form gliedern:-( > > Darum der Vorschlag mit <mods:relatedItem type="original". Die > Vorteile, die > sich daraus ergeben: > > * es ist sauberes MODS > * es entspricht dem one-to-one principle > > Ich kann die Bedenken, die Sie vorbringen allerdings gut verstehen und > sehe > ebenfalls die Nachteile: > > Ein Nachteil liegt darin, dass sich diese Lösung wie auch jede andere > bisher > nicht wirklich durchgesetzt hat. Es gibt von Jen Riley u.a. einen > Aufsatz, > der sich auch mit dieser Frage beschäftigt und die verschiedenen > Möglichkeiten auflistet (s. http://tinyurl.com/322j27x ab S. 15). Ich > habe > mit Jen und Steve Miller auf der letzten Dublin Core Tagung im Oktober > über > das Problem gesprochen. Von ihnen kommt übrigens auch der Vorschlag mit > <mods:relatedItem type="original">. Jen und Steve sehen das Problem > allerdings nicht in den Metadaten, sondern in den Erfassungsystemen > begründet, die häufig nicht in der Lage sind, strukturierte Daten zu > erfassen. Entsprechend haben sie mir empfohlen, einfach das Original zu > beschreiben und auf die originInfo-Angaben zum Digitalisat zu > verzichten. Die > meisten Datenlieferanten in zvdd machen es übrigens genau so:-( > > > >> Dann sollten wir m.E. eher dafür streiten, daß das > >><mods:originInfo>-Element um ein @type-Attribut erweitert wird. > > Wollen wir das den MODS-Editoren wirklich vorschlagen? > > >> daß wir die bibliographischen Informationen dazu _ > >>vollständig_ im <mods:relatedItem> wiederholen müssen. > > Sorry, ich habe mich im Anwendugsprofil offensichtlich sehr > un(miss)verständlich ausgedrückt. Egal, für welche Lösung wir uns > entscheiden, ich werde den Text natürlich überarbeiten. Auf jeden Fall > gilt: > <mods:relatedItem type="original" soll tatsächlich nur die Subelemente > <mods:originInfo> und <mods:location> enthalten. > > >> Und deshalb invalidieren wir alle bislang erstellten > >> MODS-Daten? > > Um diesem Problem aus dem Weg zu gehen, erlaube ich im Moment ja > beides: > sowohl die Lösung mit <mods:relatedItem type="original> als auch die > Lösung > ohne. Beide Lösungen zu mappen ist einfach, wenn wir davon ausgehen, > dass > alle originInfo-Angaben zum Digitalisat mit [Electronic ed.] > ausgezeichnet > werden - so im AP gefordert - aber auch das klappt selbst in zvdd nicht > immer > - geschweige denn darüber hinaus. > > Im Moment haben wir m. E. drei Möglichkeiten: > > 1. Wir lassen es so wie im alten AP vorgeschlagen: > * originInfo-Angaben des Originals in einem separaten > <mods:originInfo>, das > nicht gekennzeichnet ist. > * originInfo-Angaben des Digitalisats in einem separaten > <mods:originInfo>, > das mit [Electronic ed.] gekennzeichnet ist. > In diesem Fall sollten wir aber auf jeden Fall > <mods:physicalDescription><mods:digitalOrigin> nicht mehr verwenden. > Denn in > diesem Fall beschreiben wir nicht das Digitalisat, sondern das > Original. > > 2. Wir empfehlen die Verwendung von <mods:relatedItem > type="original">, > bedeutet: > * originInfo-Angaben des Originals als Subelement in <mods:relatedItem > type="original"> > * originInfo-Angaben des Digitalisats in <mods:originInfo> mit der > Kennzeichnung [Electronic ed.] > In diesem Fall muss <mods:physicalDescription><mods:digitalOrigin> > vergeben > werden, um deutlich zu machen, dass hier das Digitalisat beschrieben > wird. > > 3. Wir nehmen die Lösung aus dem alten AP, weisen aber darauf hin, dass > es > "eleganter" wäre, <mods:relatedItem type="original"> zu verwenden. Und > zeigen, wie ein Mapping von dem einen zum anderen aussehen kann. Dann > können > wir in einigen Jahren noch mal schauen, was sich durchgesetzt hat;-) > <mods:physicalDescription><mods:digitalOrigin> würde ich in diesem Fall > auf > conditional setzen. > > Wenn wir uns nicht auf 2. einigen können, würde ich natürlich 3. > bevorzugen - > mit dem Nachteil, dass wir über die nächsten Jahre "zweigleisig" > fahren. > > 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 > > > > -----Original Message----- > From: dv-technik-bounces(a)dfg-viewer.de on behalf of Kay Heiligenhaus > Sent: Sat 27.11.2010 21:29 > To: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de; Meyer, > Sebastian > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > Liebe Frau Rühle, lieber Herr Meyer, > > ich habe mir das heute nochmal näher angeschaut. Ich hatte wohl in der > Tat > den Vorschlag falsch verstanden, was aber nichts daran ändert, daß ich > diesem > nicht folgen mag, da das <relatedItem type="original"> einfach anders > verwendet wird in MODS als wir es hier unterstellen müßten. > > Allen Verwendungen von <relatedItem> dienen nach meinem Verständnis > dazu, > Beziehungen zu anderen Datensätzen (!) auszudrücken. Schaut man sich > hierzu > das LoC-MARC21-MODS-Mapping genauer an, dann sieht man, wie das Element > zu > verwenden ist. [1] Es leitet sich im Kern von den MARC21-Feldern 760- > 787 und > 800-830 ab. Uns braucht hier nur die erste Feldsequenz zu interessieren > [2] > und hier dann speziell [3]. Schaut man nun ins Mapping, dann sieht man, > daß > die Mapping-Regeln nicht zu der Modellierung führen, die Frau Rühle > vorschlägt. MARC21 Feld 786 (die MARC21-Grundlage von <relatedItem > type="original">) ist einfach nicht dazu gedacht, Angaben zur > Primärform in > der hier vorgeschlagenen Weise zu transportieren, es dient vielmehr > dazu, > eine Beziehung zwischen Primär- und Sekundärform herzustellen! > > Wenn wir an dieser Stelle Änderungen vornehmen wollen, dann hilft uns > m.E. > ein Blick in die EROMM-"Empfehlungen zur Erfassung von layoutgetreuen > Digitalisaten (digitale Master)" eher weiter. [4] Hier sieht man, daß > nicht > die Angaben zum Erscheinungsvermerk der Vorlage anders kodiert werden > müßten, > sondern die Angaben zur Onlineausgabe. Hierzu dient in MARC21 Feld 533. > (Eine > solche Abbildung wäre auch kompatibel mit den Mapping-Regeln der > zugrundeliegenden MAB-Felder 610ff., wie sie in [6] beschrieben sind.) > Ist > MARC21-Feld 533 noch hinreichend differenziert, um die Angaben, die wir > hier > brauchen, zu transportieren, wird nach Anwendung des LoC-Mappings > jedoch in > etwa folgendes MODS daraus: > > <note type="reproduction">[Online-Ausg.] Göttingen : > Niedersächsische > Staats- und Universitätsbibliothek, 2010</note> > > Wir hätten also die differenzierte aktuelle Codierungsform durch eine > "getypte Anmerkung" ersetzt. Ob ich das dann unterstützen würde, weiß > ich > noch nicht so genau. ;) > > Beste Grüße, > Kay Heiligenhaus > > [1] http://www.loc.gov/standards/mods/mods-mapping.html#relateditem > > [2] http://www.loc.gov/marc/bibliographic/bd76x78x.html > > [3] http://www.loc.gov/marc/bibliographic/bd786.html > > [4] > http://www.eromm.org/_media/public/de/digitalemaster.pdf?id=public%3Ade > %3Acat > aloguing&cache=cache > > [5] http://www.loc.gov/marc/bibliographic/bd533.html > > [6] http://www.d-nb.de/standardisierung/pdf/konkordanz_1.pdf > > > -----Original Message----- > > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > > bounces(a)dfg-viewer.de] On Behalf Of Kay Heiligenhaus > > Sent: Thursday, November 25, 2010 9:07 PM > > To: dv-technik(a)dfg-viewer.de; Meyer, Sebastian; technik(a)dfg-viewer.de > > Subject: Re: [DFG-Viewer]MODS-AP für digitalisierte Drucke - CfC > > > > Lieber Herr Meyer, > > > > ich fühle mich an Diskussionen bei unseren Sitzungen in Halle vor > zwei > Jahren > > erinnert. Da hatten wir das Thema auch schon auf der Pfanne... ;) > > > > > Die aktuelle Lösung ist meines Erachtens eben nicht immer > eindeutig, > > > da es für die Angaben zur Vorlage nur ein Negativ-Kriterium (*kein* > > > <edition>[Electronic ed.]</edition>), aber kein Positiv-Kriterium > > > gibt. Worauf bezieht sich also ein <originInfo>-Abschnitt, wenn es > > > keinen Abschnitt mit diesem Kriterium gibt? Handelt er dann von der > > > Vorlage oder folgt die METS- Datei schlicht nicht unserem Profil? > > > > Dann sollten wir m.E. eher dafür streiten, daß das <mods:originInfo>- > > Element um ein @type-Attribut erweitert wird. Unterm Strich würde ich > aber > > sagen: Wenn ein solcher Block nicht vorhanden ist, dann hat das > > zugrundeliegende digitalisierte Werk offensichtlich weder einen > Umfang > > noch einen Erscheinungs-/Entstehungsort noch einen Erscheinungs- > > /Entstehungszeitpunkt. Und es existieren auch offensichtlich > keinerlei > > Vermutungen darüber (was mich zumindest beim Umfang verwundern > > würde). Also eigentlich müßte man dann sagen: Es existiert folglich > gar > nicht > > und der Viewer muß es folglich auch nicht anzeigen. ;) > > > > > Mit der Lösung über <relatedItem> hätten wir dieses Problem nicht. > Und > > > ich verstehe METS hier so, dass kein vollständiger > bibliographischer > > > Datensatz in <relatedItem> stehen muss. (So handhaben wir das ja > auch > > > bei <relatedItem type="host"> und <relatedItem type="series">.) > > > > Stimmt. Das sagt der Entwurf aber so nicht. Und wenn er es sagen > würde, > > würde ich einwenden: Und deshalb invalidieren wir alle bislang > erstellten > > MODS-Daten? > > > > > Ihrem Vorschlag eines <dv:version>-Elements schließe ich mich an. > > > > Prima. Dann sollten wir nochmal überlegen, was noch auf unserer > Agenda > > stand. Ich erinnere mich z.B. an die Forderung aus den DFG-Gremien, > daß > > man das DFG-Logo gezielt überschreiben können sollte, um eine Nutzung > > auch außerhalb von DFG-Förderungen zu erleichtern... > > > > Beste Grüße, > > Kay Heiligenhaus > > > > > > > > > > >