21 Apr
2009
21 Apr
'09
5:45 p.m.
Hallo Herr Heiligenhaus,
2) Spezifikation der Nutzung von METS-Pointern zur
Abbildung "mehrteiliger Werke".
An dieser Stelle waere es wichtig den allgemeinen Zweck des METS Profils zu klaeren. Ist
es eher eine Anleitung, um METS Dateien, die nach diesem Schema produziert wurden zu
verstehen oder ist das Profil nicht vielmehr auch als Implementierungsanweisung gedacht?
Wenn letzteres, so fehlt an vielen Stellen eine Aussage ueber die Verbindlichkeit von
Sektionen - kann, soll, muss darf ruhig haeufiger in dem Dokument auftauchen ;-) Wenn ich
das Profil querlese faellt mir auf, dass wenn immer etwas als optional gemeint ist, dies
mit dem Wort "kann" oder "koennte" auch so beschrieben wird.
Verpflichtende Teile werden jedoch nicht als "muss" beschrieben, sondern eher
all allgemeine Beschreibung, wie bspw.
"In der File-Section <fileSec> sind alle Inhaltsdateien aufgeführt, aus dem das
Dokument besteht."
Vielmehr sollte es heissen:
"Alle Inhaltsdateien aus denen das Dokument besteht muessen in der File-Sektion
<fileSec> aufgefuehrt werden".
Derzeit ist dies tatsaechlich an vielen Stellen im Dokument nicht explizit genug, wenn das
Profil als Implementierungsanweisung verstanden werden soll.
Zu 2) Die Darstellung von "mehrteiligen
Werken" (Periodika und mehrbändige Werke) werden im METS-Profil unter Beispiel 11
behandelt (s.
http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.p…). Leider
schweigt sich das Profil, soweit ich das sehe, über das Vorhandensein von ADMIDs in der
logischen structMap aus, die für die Katalogreferenzen sowie die Darstellung der Icons der
digitalisierenden Einrichtung usw. notwendig sind.
Das ist in der Tat sehr missverstaendlich. Zumal sie darueber streiten liesse, ob diese
Information in die structMap Anforderung oder in die amdSec Anforderung 2:
"Metadaten zu Herkunft und Online-Präsentation" sollte.
Derzeit ist in der Tat nicht eindeutig, womit die unter amdSec Anforderung 2 beschriebenen
Metadaten verknuepft sind. Ich wuerde diese Information in die amdSec Anforderung 2
integrieren.
Ferner ist unklar, ob ein eine amdSec von mehreren <div>s benutzt werden darf oder
gar muss. IMHO muss nur das oberste logische <div> welches mit einem physischen
<div> Element verknuepft ist eine amdSec zugeordnet bekommen. Das waere also die
Monographie, der Band, oder der Zeitschriftenband.
Dies alles hat unmittelbare Auswirkungen auf die
Darstellung im DFG-Viewer, denn im Falle eines Bandes eines Mehrbändigen Werkes sind die
bibliographischen Daten des Bandes anzuzeigen und auf dessen Katalogeintrag zu verlinken,
im Falles eines Bandes einer Zeitschrift sind die bibliographischen Daten der Zeitschrift
anzuzeigen und auf deren Katalogeintrag zu verlinken usw.
Ich denke, dass dies auch ein Problem der typen-unabhaengigen Implementierung ist. Der
DFG-Viewer nutzt m.W. ja den Wert des TYPE Attributes eines <div> Elements nicht, um
entsprechend die Anzeige etc. zu steuern. Daher sind solche Feinheiten auch im Profil
nicht geregelt.
Bei Ihnen geht es ja ueberhaupt um die Frage, welche URLs in das Element
<dv:reference> und <dv:presentation> eingetragen werden sollen.
Prinzipiell natuerlich die URL, die zu dem jeweiligen <div> gehoert. Wenn das
<div> der Band ist, dann gehoert in <dv:reference> natuerlich die URL des
Katalogisat des Bandes. Wenn der Band kein Katalogisat hat, muss diese URL entfallen. D.h.
die beiden Elemente <dv:reference> und <dv:presentation> waeren nur mandatory,
if applicable.
In dem Fall dass das oberste logische <div> Element kein Katalogisat hat, koennte
der DFG-Viewer einen Link fuer das Katalogisat des uebergeordneten <div> Elements
praesentieren. D.h. dass die Zeitschrift immer eine <amdSec> besitzen muss - sowohl
in der METS Datei der Zeitschrift als auch in der METS Datei des Bandes.
Wird der <digiProvMD> Teil denn ueberhaupt als optional oder verpflichtend
angesehen?
In dieser Hinsicht ergibt sich unserer Ansicht nach
ein gewisser Präzisierungsbedarf im METS-Profil sowie bei der Umsetzung der Darstellung im
Viewer.
Ja.
Ciao
Markus