24 Feb
2010
24 Feb
'10
8:22 p.m.
Lieber Herr Heiligenhaus,
nur ganz schnell noch:
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.
Haben wir sowas nicht schon als "section"? Was Sie beschreiben wollen, ist doch
ein Abschnitt der Zeitung, nämlich alle Ausgaben eines Monats.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
-----Ursprüngliche Nachricht-----
Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
viewer.de] Im Auftrag von Kay Heiligenhaus
Gesendet: Mittwoch, 24. Februar 2010 20:14
An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] Strukturdaten für Zeitungen?
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