25 Feb
2010
25 Feb
'10
1 p.m.
Dieses Modell
greift im allgemeinen bei Zeitungen jedoch zu kurz.
Schliesslich muessen be Zeitungen auch noch verschiedenste Ausgaben
(Editions) beruecksichtigt werden. Ausgaben koennen sich sowohl
regional als auch zeitlich unterschiedlich sein.
Regional: Obwohl das Zeitungsheft im wesentlichen identisch ist,
werden 2 oder 4 Seiten je nach Region (Stadtteil etc.) getauscht.
Zeitlich: Das gleiche Zeitungsheft kann je nach Tageszeit leicht
unterschiedlich sein. Artikel koennen updates erfahren oder aber
Fehler/Typos koennen korrigiert sein.
Okay. Das ist ein interessanter Aspekt!
Hieße also:
newspaper -> volume -> issue
Ja, das hiesse es.
Letztlich das Modell, das wir bereits für Zeitschriften
haben. Jetzt überlegen wir aber
in unserem Projektzusammenhang, ob es nicht Sinn macht, PDFs für diese "mittleren
Einheiten" zu erstellen, die ich da gerne sehen würde (also konkret die Monate), da
die
Jahrgänge zu groß sind, die einzelnen Ausgaben aber zu klein. PDFs werden grundsätzlich
aus der logical structMap verzeigert. Mit dem vorgeschlagenen Modell aber sind wir hier
wenig flexibel. Was spräche dagegen, nicht doch ein Strukturdatum "other"
aufzunehmen?
Damit hätte man die Möglichkeit, hier flexibler zu agieren, ohne gleich jede Anforderung
in das Strukturdatenset zu gießen? "other" wäre also einfach ein
"untypisierter
Container" für Einheiten, die man logisch zusammenfassen möchte. Gleich aus welchem
Grund.
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...)
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.
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.
Sollte eine Navigationsstruktur entsprechend angeboten
werden sollen,
muesste man auf die MODS Metadaten fuer das jeweilige Heft (issue)
zurueckgreifen. Dies halte ich fuer legitim.
Ich denke nicht, dass die Navigationsstruktur einfluss auf die Art und
Weise haben sollte, wie METS Dateien erzeugt, gemanagt oder generiert werden.
Übersichtlichkeit in die Modellierung bringt (oder
schlicht technische Handhabbarkeit sichert).
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?
Ciao
Markus