24 Feb
2010
24 Feb
'10
8:13 p.m.
Lieber Herr Enders,
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!
Fuer die serialisierung koennte man sich durchaus
einen aehnlichen "Trick"
vorstellen wie dies bei Zeitschriften durchaus ueblich ist: Alle
Zeitschriftenhefte eines Jahres werden ueblicherweise zu einem Band
zusammengefasst. Auch wenn dieser als solches nie eigenstaendig publiziert
wurde liesse sich so das Problem ewig langer METS Dateien umgehen. Eine
feinere Untergliederung in Monate oder Wochen halte ich fuer unnoetig.
Hieße also:
newspaper -> volume -> issue
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.
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.
Ja. Da muß ich mich anschließen. Aber Sie schreiben weiter oben ja selbst:
"volumes" sind keine physischen Einheiten und auch keine Publikationseinheiten.
Sie sind eine Modellierungsebene, die gleichsam "künstlich" Struktur rsp.
Übersichtlichkeit in die Modellierung bringt (oder schlicht technische Handhabbarkeit
sichert). Das gälte dann m.E. auch für Monate, Wochen usw. Könnte also dafür sprechen, daß
man vielleicht sowas macht:
newspaper -> volume -> volume -> issue
Sieht mir aber auch nicht so wirklich überzeugend aus.
Beste Grüße,
Kay Heiligenhaus