16 Jul
2013
16 Jul
'13
6:10 p.m.
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