16 Nov
2008
16 Nov
'08
1:08 p.m.
Lieber Herr Funk, lieber Herr Meyer, liebe Kolleginnen und Kollegen,
zunächst meinen besten Dank für die Erstellung des METS-Profils. Ich hatte noch nicht die
Zeit, mir das im Detail anzuschauen, liefere aber meine Anmerkungen nach entsprechender
Lektüre noch nach. Kurz aber zu den noch offenen Fragen:
Ich habe sie aus der physischen StructMap verknüpft.
Für die
Einzelseiten geht es ja auch gar nicht anders, weil die keine
Repräsentation in der logischen StructMap besitzen.
Das haben wir analog gemacht und ich denke, das ist so auch sinnvoll.
Beim Download des Gesamtwerks scheiden sich die
Geister: ich habe das als Sequenz von
Einzelseiten interpretiert und entsprechend in der physischen Struktur
verlinkt, Herr Heiligenhaus hat das PDF dagegen mit der logischen
Struktur "Monographie" verknüpft. Wenn jemand Downloads von einzelnen
Kapiteln anbietet, kann er diese wiederum ausschließlich in der
logischen Struktur verknüpfen. Der Viewer sucht bisher übrigens nur in der physischen
Struktur nach
Downloads.
Ich hab nochmal etwas drüber nachgedacht. Aus meiner Sicht wäre es konsequenter, bei
Gesamtwerken und Kapiteln grundsätzlich von der logischen structMap aus zu verknüpfen. Das
grundlegende Argument ist für mich, daß wir uns hier auf der logischen Modellierungsebene
befinden. PDFs des Gesamtwerkes können eben Inhaltsverzeichnisse haben, Titelblätter,
weitere Metadaten in den dafür vorgesehenen PDF-Feldern usw. usf. PDFs auf
Strukturdatenebene sind per definitionem "logische" Einheiten. Es ist sicherlich
kein Problem, das bei uns entsprechend für die Gesamtwerke anzupassen, ich hielte aber
eine Änderung der Viewer-Implementierung in der beschriebenen Hinsicht für in sich
konsistenter.
(2) Was ist mit den zvdd-Srukturtypen? Sind diese für
den DFG-Viewer
nicht mehr Pflicht wie in der letzten Version?
Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn Strukturtypen codiert
werden, dann nach dem Schema, das unter
http://dfg-viewer.de/profil-der-strukturdaten/
beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet wurde. zvdd muß
diese Typen auf das eigene Typsystem mappen (die entsprechenden Mappingregeln sind auf der
o.g. Seite ja auch genannt).
Eigentlich sind sie für den DFG-Viewer tatsächlich
nicht nötig. Der
Viewer zeigt einfach für jedes Strukturelement das an, was im LABEL-
Attribut steht, und wenn das nicht belegt ist, dann zeigt er direkt die
Angabe im TYPE-Attribut an. Man könnte nun höchstens für die ZVDD-
Strukturdatenliste beispielsweise intern alternative Bezeichnungen
hinterlegen, so dass nicht der Inhalt des TYPE-Attributs als Fallback
angezeigt wird, wenn kein LABEL existiert, sondern diese interne
Bezeichnung.
Nach meinem Verständnis müßten dann die unter o.g. Adresse angegebenen dt. Bezeichnungen
verwendet werden (wenn der Viewer gerade in einem anderen "Sprachmodus" ist,
müßten entsprechende Übersetzungen angezeigt werden).
Ich halte die Strukturdatenliste aber dennoch für
wichtig, weil sie die
Ausgabe der verschiedenen OAI-Schnittstellen verschiedener
Einrichtungen ein Stück weit standardisiert. Dadurch dass jede
Einrichtung angehalten ist, ihre intern verwendeten Strukturdaten auf
dieses Set herunterzubrechen, bevor sie sie per OAI in der Welt
verteilt, liefern alle OAI-Schnittstellen ein vergleichbares
Strukturdatenset.
Sehe ich auch so.
(3) Darf es ein <div TYPE="page" /> in
der logischen Structmap geben?
Das war in einem der vorigen Beispieln so.
Meinem Verständnis nach darf es das nicht geben, weil eine Seite keine
logische Struktur ist.
Eine metaphysische Frage. ;) - - - Nein, ich sehe das ebenfalls so.
Ich kann jetzt selbst nur raten, weil ich zu Hause den
Quellcode nicht
einsehen kann, aber ich würde vermuten, der Viewer würde den ersten
MODS-Datensatz (den der Zeitschrift/des mehrbändigen Werks) ignorieren.
Das würde ich zumindest von ihm erwarten, ob er es wirklich tut, habe
ich ehrlich gesagt nie getestet. :o)
Da sehe ich noch etwas Diskussionsbedarf. Wir testen aber auch gerade, wie wir unsere
Daten modellieren, um ein gewünschtes Ergebnis zu erzielen.
Kurz noch eine abschließende Frage: Wir hatten uns ja darauf verständigt, daß auch
Einzelseiten persistent adressiert werden _können_. Ein Beispiel hierfür wäre:
<mets:structMap TYPE="PHYSICAL" >
<mets:div ID="phys582" TYPE="physSequence" >
<mets:div ID="phys52047" TYPE="page" LABEL="[Seite
1]" CONTENTIDS="urn:nbn:de:gbv:3-100002425-p0001-0" ORDER="1"
>
...
</mets:structMap>
Im <div> der Einzelseite in der phys. structMap findet sich also im Attribut
"CONTENTIDS" die persistente Adresse der entsprechenden Einzelseite. Im
METS-Profil ist das auch entsprechend dokumentiert. Leider wird diese Information aktuell
im Viewer nirgends angezeigt, was aus meiner Sicht ein Bug ist. Wichtig fände ich in
diesem Zusammenhang auch noch, daß dem Nutzer kurz erläutert wird, was es mit solchen
Identifiern auf sich hat. Es hat sich ja in verschiedenen Diskussionskontexten gezeigt,
daß das Konzept von URNs, PURLs usw. in Nutzerkontexten (und auch in der
bibliothekarischen Fachwelt) z.T. weder bekannt noch verstanden worden ist. Hier ist wohl
noch Aufklärungsarbeit nötig.
Und dann zum Schluß noch: Es gibt noch einen Bug bei der Anzeige der Strukturdaten im IE7.
Diese werden nicht neben den Images angezeigt, sondern darunter.
Beste Grüße,
Kay Heiligenhaus