17 Nov
2008
17 Nov
'08
12:32 p.m.
Liebe Liste,
hier noch einmal eine ausführlichere Antwort:
Meyer, Sebastian schrieb am 15.11.2008 18:16:
(1) Von wo aus werden die Dateien für die DOANLOAD
Sektion verknüpft? Aus
der logischen oder der physischen StructMap? Formulierung(en) prüfen.
Mehrfachnennungen vermeiden.
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. 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 sehe das wie Herr Heiligenhaus (Mail vom 16.11. 13:08). Wenn hier keine
Gegenstimmen kommen, formuliere ich das wie folgt um und würde Herr Meyer
bitten, den Viewer entsprechend anzupassen:
(1) Einzelseitendownloads werden *nur* von der physischen structMap aus
referenziert.
(2) Alle weiteren angebotenen Downloads (Gesamt- *und* weitere vorhandene
Strukturtypen) werden von der logischen structMap aus referenziert. Das macht
für einen Gesamtdownload Sinn und wir kommen nicht in die Verlegenheit, in der
logischen *und* in der physischen structMap zwei -- evtl. sogar voneinander
differierende -- Referenzen auf einen Gesamtdownload zu haben.
(2) Was ist mit den zvdd-Srukturtypen? Sind diese für
den DFG-Viewer nicht
mehr Pflicht wie in der letzten Version?
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. 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.
Siehe Mail von Herrn Kothe. Eine Vereinheitlichung ist auf jeden Fall angeraten.
(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.
Das sehe ich genauso.
(4) Gibt es evtl. Probleme mit anderen Page-Turnern,
wenn wir keine
MODS-Sektion für das erste <div> in der logischen StructMap haben
(Zeitschriften/Mehrbändige Werke)? Was macht der Viewer, wenn bei einer
Zeitschrift BEIDE <div> eine MODS-Sektion haben?
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) Ob andere Pageturner ein Problem damit
haben, weiß ich nicht.
Prinzipiell hätte ich ja gerne dieses erste <div> aus dem Profil verbannt, nur
brauchen wir es, um per METS-Pointer auf das übergeordnete Werk zu verweisen.
Viele Grüße und vielen Dank für den Input.
*fu*
--
Stefan E. Funk
DP-D - Diensteportal Digitalisierung
Goettingen State and University Library - The Historical Library Building
Papendiek 14, 37073 Goettingen, Germany
Phone: +49 551 39-7700 | 39-12170
Mail: funk(a)sub.uni-goettingen.de