Re: [DFG-Viewer] WG: MODS version 3.5 released

Wenn ich mir die Mapping-Beispiele anschaue dazu, dann sind diese jedoch m.E. schlichtweg fehlerhaft:

Liebe Frau Rühle, danke für den Hinweis, das war mir in der Tat nicht mehr präsent. Wenn ich mir die Mapping-Beispiele anschaue dazu, dann sind diese jedoch m.E. schlichtweg fehlerhaft: PICA: 011B $a Erscheinungsjahr der digitalen Ausgabe <originInfo><dateCaptured encoding="w3cdtf"> MAB: 619a Erscheinungsjahr der Sekundärform <originInfo><dateCaptured encoding="w3cdtf"> Da stimmt die Semantik mE schlichtweg nicht, denn beschrieben wird hier eben die Sekundärform und deren Erscheinungsmodalitäten - nicht die Umstände der Anfertigung der zugrundeliegenden Scans. Nehmen wir ein Beispiel der ULB Halle: http://gso.gbv.de/DB=2.1/PPNSET?PPN=594908418 Hier sind Hersteller der Scans und Erscheinungsform der Sekundärausgabe getrennt im Katalog vorhanden. Allerdings finden sich zu ersterem keine Jahresangaben im Katalog, sondern eben nur das Feld 011B$a, das aber eben das Erscheinungsjahr der Sekundärform ausweist und mit 033B/01 eine Einheit bildet. Völlig analog verhält sich das auch bei den MAB-Daten in anderen Verbünden, nur wird nach meiner Kenntnis der Hersteller der Scans hier nie erfaßt. Beste Grüße, Kay Heiligenhaus > -----Original Message----- > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces(a)dfg-viewer.de] On Behalf Of Ruehle, Stefanie > Sent: Tuesday, July 16, 2013 5:40 PM > To: dv-technik(a)dfg-viewer.de > Subject: Re: [DFG-Viewer] WG: MODS version 3.5 released > > Lieber Herr Heiligenhaus, > >> Wir diskutieren allerdings z.Z. m.E. primär die Änderung, die am >> bereits spezifizierten Element zur Abbildung der Sekundärform >> vorgenommen werden soll > > Ja, und dabei gehe ich von dem MODS-Anwendungsprofil aus, dass für DFG- > Viewer und zvdd gilt. Und sowohl in der Version 1.0 von 2008 (s. > http://dfg- > viewer.de/fileadmin/groups/dfgviewer/MODS_Anwendungsprofil_1.0.pdf) > als auch in der Version 2.1 von 2012 (s. > http://www.zvdd.de/fileadmin/AGSDD- > Redaktion/zvdd_MODS_Application_Profile_2.1.pdf) > ist die Verwendung von mods:dateCaptured innerhalb der mods:originInfo > mit mods:edition [Electronic ed.] verpflichtend, während mods:dateIssued in > diesem Zusammenhang gar nicht vorgesehen ist. Orientieren wir uns also an > der aktuellen Spezifikation, so haben wir nur eventType="digitisation" mit > mods:dateCaptured. > > Ich denke, wir sind uns einig, dass entsprechende Anpassungen an dem > Profil vorgenommen werden müssen. Und dabei sollten wir auf jeden Fall > beide Möglichkeiten - also sowohl den eventType ditization als auch den > eventType digitizationPublication berücksichtigen. Tatsächlich werden in > diesem Zusammenhang von den verschiedenen Datenlieferanten > verschiedene date-Element verwendet - in den Daten, die an zvdd gehen, > gibt es jedenfalls sowohl dateCaptured als auch dateCreated als auch > dateIssued zur Beschreibung der Electronic ed.. Und darauf sollten wir > reagieren. > > Viele Grüße aus Göttingen > > Stefanie Rühle > > > > Am 16.07.2013 17:10, schrieb Kay Heiligenhaus: >> Liebe Frau Rühle, >> >> dagegen ist nichts einzuwenden. Wenn Sie die Informationen für relevant > halten, dann sollten evtl. zusätzliche (optionale!) <originInfo>s definiert > werden. Wir diskutieren allerdings z.Z. m.E. primär die Änderung, die am > bereits spezifizierten Element zur Abbildung der Sekundärform > vorgenommen werden soll und diese benötigt m.E. ein <dateIssued>-, kein > <dateCaptured>-Element. >> Beste Grüße, >> Kay Heiligenhaus >> >>> -----Original Message----- >>> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- >>> bounces(a)dfg-viewer.de] On Behalf Of Ruehle, Stefanie >>> Sent: Tuesday, July 16, 2013 5:02 PM >>> To: dv-technik(a)dfg-viewer.de >>> Subject: Re: [DFG-Viewer] WG: MODS version 3.5 released >>> >>> Lieber Herr Heiligenhaus, >>> >>> m. E. können wir sowohl den eventType="Digitasation" als auch den >>> eventType="DigitalPublication" einführen. Und falls wir in diesem >>> Zusammenhang weitere eventTypes fürs Scannen, OCR usw. brauchen, > ist >>> auch das kein Problem. Das ist ja der Sinn der eventTypes, dass man >>> die Möglichkeit hat, zwischen den sehr unterschiedlichen Schritten im >>> Lebenszyklus eines Dokuments zu unterscheiden. Wenn es um das > Datum >>> geht, haben wir in der SUB z. B. in erster Linie die Information >>> darüber, wann das Digitalisat entstanden ist (also das Datum der >>> digitisation), denn diese Information ist in die Bilder eingebettet. >>> >>> Es ist nur wichtig, dass wir uns nicht nur auf ein gemeinsames >>> Vokabular für eventTypes einigen, sondern uns auch mit der Definition >>> dieser Typen klar werden, worum es sich jeweils handelt. >>> >>> Viele Grüße >>> >>> Stefanie Rühle >>> >>> >>> Am 16.07.2013 16:15, schrieb Kay Heiligenhaus: >>>> Liebe Frau Rühle, >>>> >>>>> Der eventType "digitisation" beschreibt nicht den Dokumenttyp - >>>>> also die Unterscheidung zwischen Primärform und Sekundärform, >>>>> sondern er beschreibt die "Aktion" in der aus der Primärform die >>>>> Sekundärform >>> wurde. >>>>> Handelt es sich bei der Aktion um das "Publizieren" eines Dokuments >>>>> (also eventType="publication"), dann kann das Datum, das zu diesem >>>>> Event gehört, nur das Publikationsdatum (also mods:dateIssued) sein. >>>>> Alles andere wäre semantisch nicht korrekt. Handelt es sich bei der >>> "Aktion" >>>>> um die "Digitalisierung" (eventType="digitisation") , dann ist das >>>>> Datum, um das es hier geht, das Digitalisierungsdatum (und das ist >>>>> das Datum, an dem das Digitalisat entstanden ist) und dies wird in >>>>> mods mit mods:dateCaptured wiedergegeben. >>>> Die Argumentation dreht sich dann etwas im Kreis, denn ich würde >>>> dann >>> vorschlagen, daß wir den eventType "digital publication" o.ä. nennen. >>> Folgt man Ihrem Vorschlag, dann müßte man wohl bei einem Digitalisat, >>> das nicht im eigenen Haus angefertigt wurde, angeben, daß es z.B. >>> 2010 beim Dienstleister XY in der Stadt Z angefertigt wurde und man >>> hätte folglich keinerlei Informationen mehr, wer dieses Werk wann digital > publiziert hat. >>> Verzeichnen wir in unseren Katalogen (auf denen ja die MODS-Daten qua >>> Mapping basieren) die verschiedenen Dienstleister, die Scans anfertigen? >>> Könnten Sie ein Beispiel für das PICA- und MAB-Mapping dieser Daten >>> geben? Anschließend würde ich dann auch fragen wollen: Wo ist >>> codiert, wer die Strukturdaten erfaßt hat? Wo ist codiert, wer die OCR > durchgeführt hat? >>> Die Digitalisierung eines Werkes besteht ja aus mehreren >>> Arbeitsschritten - das Scannen ist nur einer von vielen. Am Ende >>> steht jedoch die Publikation des Digitalisates - und diese Aktion ist >>> in unseren Katalogen verzeichnet, die anderen überwiegend nicht, soweit > ich das überblicke. >>>> Beste Grüße, >>>> Kay Heiligenhaus >>>> >>>> >>> -- >>> Stefanie Rühle >>> Metadata and Data Conversion >>> >>> Georg-August-Universität Göttingen >>> Göttingen State and University Library >>> D-37070 Göttingen >>> >>> Papendiek 14 (Historical Building, room 1.603) >>> +49 551 39-10905 (Tel.) >>> >>> sruehle(a)sub.uni-goettingen.de >>> >>> > > -- > Stefanie Rühle > Metadata and Data Conversion > > Georg-August-Universität Göttingen > Göttingen State and University Library > D-37070 Göttingen > > Papendiek 14 (Historical Building, room 1.603) > +49 551 39-10905 (Tel.) > > sruehle(a)sub.uni-goettingen.de >