Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

Lieber Herr Heiligenhaus, Genau diese beiden Fälle sollten doch mit dem in meiner anderen Mail vorgeschlagenen Ansatz korrekt funktionieren. In Pseudo-Code sähe es etwa so aus: 1. Prüfe, ob das oberste DIV-Element der logischen Struktur, das in der structLink-Sektion berücksichtigt wird (mit dem also physische Strukturen verknüpft sind), DMDID- und ADMID-Attribute enthält. 2a. Wenn ja, dann verwende diese. 2b. Wenn nein (oder nur eins von beidem), dann suche die noch fehlenden Angaben im obersten DIV-Element der logischen Struktur. Damit sollten in meinem Beispiel korrekt die DMDID und ADMID des Bandes gefunden werden und in Ihrem Beispiel würde die DMDID des Bandes und die ADMID der Zeitschrift verwendet werden. Wenn ich da nichts übersehen habe, kämen wir sogar ganz ohne eine Formatergänzung aus. 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: Dienstag, 21. April 2009 19:05 > An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) > veröffentlicht > > Hallo Herr Enders, > > > An dieser Stelle waere es wichtig den allgemeinen Zweck des METS > > Profils zu klaeren. Ist es eher eine Anleitung, um METS Dateien, die > > nach diesem Schema produziert wurden zu verstehen oder ist das Profil > > nicht vielmehr auch als Implementierungsanweisung gedacht? > > Ich würde es eher als Implementierungsanleitung verstehen, eine > narrative Umschreibung zum besseren Verständnis von METS-Dateien, die > der freien Inspiration von Entwicklern erwachsen, hätte m.E. nur einen > begrenzten Wert bei der Verfolgung der zuvor beschriebenen Zwecke > ("Standardisierung zur einheitlichen Anzeige von Digitalisaten > verschiedener DFG-geförderter Projekte"). ;) > > > Wenn letzteres, so fehlt an vielen Stellen eine Aussage ueber die > > Verbindlichkeit von Sektionen - kann, soll, muss darf ruhig haeufiger > > in dem Dokument auftauchen ;-) Wenn ich das Profil querlese faellt > mir > > auf, dass wenn immer etwas als optional gemeint ist, dies mit dem > Wort > > "kann" oder "koennte" auch so beschrieben wird. Verpflichtende Teile > > werden jedoch nicht als "muss" beschrieben, sondern eher all > allgemeine > > Beschreibung > > Dem kann ich mich nur anschließen. > > > Das ist in der Tat sehr missverstaendlich. Zumal sie darueber > streiten > > liesse, ob diese Information in die structMap Anforderung oder in die > > amdSec Anforderung 2: "Metadaten zu Herkunft und Online-Präsentation" > > sollte. > > Sie gehört m.E. in beide. In Anforderung 2 müßte der grundsätzliche > Ansatz beschrieben sein, unter den Anforderungen für die structMap dann > die Konkretisierung für verschiedene Anwendungsfälle, die - so > interpretiere ich den Angang des Profils - je nach "Dokumenttyp" (den > es aber leider formal hier nicht gibt, s.u.) unterschiedlich sein > werden. > > > Ferner ist unklar, ob ein eine amdSec von mehreren <div>s benutzt > > werden darf oder gar muss. IMHO muss nur das oberste logische <div> > > welches mit einem physischen <div> Element verknuepft ist eine amdSec > > zugeordnet bekommen. Das waere also die Monographie, der Band, oder > der > > Zeitschriftenband. > > Das sehe ich anders, zumindest scheint mir das Profil hier einen > anderen Angang zu wählen, den ich - offen gesagt - aber auch noch etwas > unausgegoren finde, wenn ich auch ad hoc keinen besseren vorschlagen > könnte: a) Bände von Zeitschriften und b) Bände von mehrbändigen Werken > wären hier unterschiedlich zu implementieren. Bei a) müßte die ADMID an > der Zeitschrift hängen (diese hat ein korrespondierendes Katalogisat > zur Anzeige), bei b) am konkreten Band (dieser hat ein > korrespondierendes Katalogisat zur Anzeige). Nun kommt man aber ins > Schleudern, denn die bibliographische Beschreibung, die anzuzeigen > wäre, setzt sich letztlich aus den Metadaten zusammen, die beide > "Ebenen" zusammen erst ergeben ("Ich bin Bd. 10 des mehrbändigen Werkes > X" sowie "Ich bin Jg. 3 der Zeitschrift Y). Das kann man aber gut auch > anders sehen (aber man kommt dann schnell ins Weiterschleudern, wenn > man größere Hierarchiestufen betrachtet). > > > > Ich denke, dass dies auch ein Problem der typen-unabhaengigen > > Implementierung ist. > > Ja, die "Dokumenttypen" sind ein echtes Desiderat des Profils, auch > wenn diese im Profil stillschweigend hier und da vorkommen. > > > Der DFG-Viewer nutzt m.W. ja den Wert des TYPE > > Attributes eines <div> Elements nicht, um entsprechend die Anzeige > etc. > > zu steuern. Daher sind solche Feinheiten auch im Profil nicht > geregelt. > > Bei Ihnen geht es ja ueberhaupt um die Frage, welche URLs in das > > Element <dv:reference> und <dv:presentation> eingetragen werden > sollen. > > So ist es. > > > Prinzipiell natuerlich die URL, die zu dem jeweiligen <div> gehoert. > > Wenn das <div> der Band ist, dann gehoert in <dv:reference> > natuerlich > > die URL des Katalogisat des Bandes. Wenn der Band kein Katalogisat > hat, > > muss diese URL entfallen. D.h. die beiden Elemente <dv:reference> und > > <dv:presentation> waeren nur mandatory, if applicable. > > Yep, so ist das für Zeitschriften. > > > In dem Fall dass das oberste logische <div> Element kein Katalogisat > > hat, koennte der DFG-Viewer einen Link fuer das Katalogisat des > > uebergeordneten <div> Elements praesentieren. D.h. dass die > Zeitschrift > > immer eine <amdSec> besitzen muss - sowohl in der METS Datei der > > Zeitschrift als auch in der METS Datei des Bandes. > > Und nun sind wir in der Misere: Was soll eigentlich das oberste > logische DIV sein? Und was wird im Viewer angezeigt, wenn das oberste > DIV mal dazu dient, eine Navigation von "unten nach oben" zu > ermöglichen (Band -> Zeitschrift, die Digitalisate des Bandes werden > angezeigt) und mal dazu, eine Navigation von "oben nach unten" zu > ermöglichen (Zeitschrift -> Bände, es wird kein Digitalisat angezeigt, > da die Zeitschrift keine unmittelbaren hat)? Vor allem, wie halte ich > diese Fälle formal hinreichend auseinander? > > Beste Grüße, > Kay Heiligenhaus >