Der Aspekt der Editionen ist vor allem fuer Zeitungen
des 20 Jhdt.
interessant; gerade auch bei born-digital Zeitungen kommt dies ja durchaus
haeufig vor. Keine Ahnung, wie man sowas am Besten in der Navigation
strukturiert.
Ja. Das müßte man m.E. wirklich berücksichtigen im Modell. Wobei ich sagen würde, daß
diese Modellierungsebene tatsächlich nur in sehr spezialisierten Projekten eine Rolle
spielen wird. Sie werden an der BL ja auch Gründe gehabt haben, diesen Aspekt nicht in
Ihrer Modellierung zu berücksichtigen.
Die Idee "volumes" anzubieten kommt ja
daher, dem DFG-Viewer kleinere
Haeppchen an METS Dateien anzubieten. Das bedeutet nicht, dass diese
Haeppchen auch gleichzeitig der Granularitaet fuer die Auslieferung
entsprechen muessen. D.h. sollte es aus bestimmten Gruenden notwendig
sein, koennte der DFG-Viewer auch mehrere dieser Haeppchen laden - um
bspw. eine Navigation durch ein Jahrzehnt etc. anzubieten (bspw. eine
Timeline...)
Ja, da ließen sich noch viele, schöne Funktionalitäten ersinnen. Da würde ich aber sagen:
Das ist Viewer 4.0. ;)
Gleiches gilt auch fuer die Auslieferung von PDF
Dateien: Eine Auslieferung
kann sowohl auf Heft, Band oder sonstiger Ebene erfolgen. An dieser Stelle
moechten Sie jedoch weitergehende Flexibilitaet. Ich bin mir nicht sicher, ob
das ratsam ist: IMHO sollte der Nutzer doch ueberwiegend identische
Navigationsstrukturen vorfinden. Properitaere Strukturen fuer einzelne
Zeitungen / bzw. fuer Zeitungen aus vereinzelnten Quellen machen IMHO
wenig Sinn.
Ja, ich bin da auch kein Freund von. Deshalb auch meine Anfrage hier in die Runde. Nach
weiterem Nachdenken über das Thema scheint mir meine erste Überlegung jedoch nicht so
abwegig zu sein - wobei ich weiterhin denke, daß das noch nicht der Weisheit letzter
Schluß ist. Mein Punkt war aber der: Zeichnen sich Zeitungen nicht gerade durch ihren
zeitlichen Bezug (durch ihre Aktualität) aus gegenüber (wissenschaftlichen) Zeitschriften?
Bildet dieser zeitliche Bezug folglich nicht das Modell für die "logische
Modellierung" einer Zeitung?
Ggfs. waere es eine sinnvollere Alternative, dass sich
der Nutzer die PDFs
selbst zusammenstellt. Bspw. indem er die einzelnen Hefte, die in einem PDF
enthalten sein sollten anwaehlt und diese dann generieren laesst. Gerade
PDFs sind ja nicht wirklich schwierig on demand zu generieren - und bei
entsprechenden Source-Formaten sollte es auch kein Performanceproblem
geben, da die Bytestreams ohnehin nur in das PDF geschoben werden.
Vielleicht waere es mal an der Zeit einen entsprechenden zentralisierten
Service als Ergaenzung zum DFG Viewer anzubieten.
Ja. Das sehe ich auch so. Es ist aber eine Frage, ob man diese Funktionalität ebenfalls
dem Viewer anlasten sollte.
IHMO ist es ausschleisslich die technische
Handhabbarkeit. Wobei es mal
interessant waere zu sehen, wie der Viewer mit METS Dateien zurecht
kommt die mehrere tausend oder zehntausende von <div> Elemente
enthalten (eins pro Heft). Bislang behaupten wir ja nur, dass es von der
Performance her nicht ertraeglich waere; hat das mal jemand ausprobiert
oder gar gemessen?
Ja. Das sollte man wirklich mal tun. Dennoch betrachte ich das auch unter ergonomischen
Gesichtspunkten. Es macht m.E. überhaupt keinen Sinn, eine Liste mit 18.000
issue-Einträgen im Viewer anzubieten. Das mag in Zeiten von Hochgeschwindigkeitsnetzen
technisch gut übertragbar sein. Und auch aktuelle Browser werden damit zurande kommen.
Dennoch wäre das vergleichbar mit dieser Bestellung in einer Bibliothek: Ich brauche die
FAZ vom 18.2.2009. Ich recherchiere im OPAC und finde die Signatur Z38799/B. Auf meine
Bestellung hin fährt ein Gabelstapler zur Ausleihe und ich werde aufgefordert, aus den
18.000 angelieferten Kisten mal die entsprechende Ausgabe rauszusuchen. Technisch alles
machbar (wenn wir Gabelstapler 2.0 in Bibliotheken für die Ausleihe einführen). Aber nicht
das, was ich unter Service in einer Bibliothek verstehe. ;)
Beste Grüße,
Kay Heiligenhaus