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

Lieber Markus, liebe KollegInnen! Rein formal dürfte eine amdSec eigentlich nicht mehreren DIVs zugeordnet werden, da sie ja im Kontext des DFG-Viewers zwingend einen Kataloglink enthält und dieser nicht auf mehrere Struktureinheiten zugleich verweisen kann. Eine amdSec, deren Kataloglink auf die Gesamtheit eines mehrbändigen Werks verweist, darf also formal eigentlich nicht auch dessen Bänden zugeordnet werden. Das funktioniert leider auch nicht. Im Fall eines Zeitschriftenbandes hat nämlich nur das oberste DIV (nämlich die Referenz auf die Gesamtheit) eine amdSec, allerdings keine verknüpften physischen Strukturen. Doch, inzwischen interpretiert der Viewer auch das TYPE-Attribut der DIV-Elemente. Einige METS-Dateien aus Halle enthalten beispielsweise auch physische Strukturen vom Type "verse", die im Viewer nicht zur Anzeige kommen. Der Viewer interpretiert nämlich nur Elemente des Typs "physSequence" und "page". Für logische Strukturen gilt das aber tatsächlich nicht, was vor allem daran liegt, dass das Strukturdatenset nach wie vor nur eine Empfehlung darstellt und auch überhaupt keine Aussage zur Bezeichnung von Strukturen der höchsten Ebene macht. Wie in meiner letzten Mail schon geschrieben, sehe ich hier auch eine Möglichkeit, dem Problem zu begegnen - aber eben um den Preis, dass die standardisierte Bezeichnung der Strukturdaten damit verpflichtend würde. Das wäre natürlich auch eine Möglichkeit, aus meiner Sicht aber nicht besonders nutzerfreundlich. Als Nutzer wäre mir dann lieber, dass ich wenigstens den Link zum Katalogisat der Gesamtheit angezeigt bekäme. Diesen Link zu hinterlegen wäre aber - siehe oben - formal wiederum nicht korrekt. Das wäre tatsächlich eine Möglichkeit: der Viewer prüft erst, ob das oberste logische DIV-Element, das mit einem physischen DIV verknüpft ist, DMDID- und ADMID-Attribute enthält. Ist das nicht der Fall, dann werden DMDID und ADMID aus dem obersten logischen DIV-Element genommen (ungeachtet dessen, ob damit physischen Strukturen verknüpft sind). Damit sollten alle möglichen Fälle abgedeckt sein oder habe ich etwas übersehen? 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 Enders, Markus > Gesendet: Dienstag, 21. April 2009 17:45 > An: dv-technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) > veröffentlicht > > Hallo Herr Heiligenhaus, > > >2) Spezifikation der Nutzung von METS-Pointern zur Abbildung > "mehrteiliger Werke". > > > 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? > > 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, wie bspw. > > "In der File-Section <fileSec> sind alle Inhaltsdateien aufgeführt, aus > dem das Dokument besteht." > Vielmehr sollte es heissen: > "Alle Inhaltsdateien aus denen das Dokument besteht muessen in der > File-Sektion <fileSec> aufgefuehrt werden". > > Derzeit ist dies tatsaechlich an vielen Stellen im Dokument nicht > explizit genug, wenn das Profil als Implementierungsanweisung > verstanden werden soll. > > > > >Zu 2) Die Darstellung von "mehrteiligen Werken" (Periodika und > mehrbändige Werke) werden im METS-Profil unter Beispiel 11 behandelt > (s. http://dfg- > viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.pdf). > Leider schweigt sich das Profil, soweit ich das sehe, über das > Vorhandensein von ADMIDs in der logischen structMap aus, die für die > Katalogreferenzen sowie die Darstellung der Icons der digitalisierenden > Einrichtung usw. notwendig sind. > > > 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. > Derzeit ist in der Tat nicht eindeutig, womit die unter amdSec > Anforderung 2 beschriebenen Metadaten verknuepft sind. Ich wuerde diese > Information in die amdSec Anforderung 2 integrieren. > > 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. > > > > >Dies alles hat unmittelbare Auswirkungen auf die Darstellung im DFG- > Viewer, denn im Falle eines Bandes eines Mehrbändigen Werkes sind die > bibliographischen Daten des Bandes anzuzeigen und auf dessen > Katalogeintrag zu verlinken, im Falles eines Bandes einer Zeitschrift > sind die bibliographischen Daten der Zeitschrift anzuzeigen und auf > deren Katalogeintrag zu verlinken usw. > > Bei Ihnen geht es ja ueberhaupt um die Frage, welche URLs in das > Element <dv:reference> und <dv:presentation> eingetragen werden sollen. > > > > Wird der <digiProvMD> Teil denn ueberhaupt als optional oder > verpflichtend angesehen? > > > > In dieser Hinsicht ergibt sich unserer Ansicht nach ein gewisser > Präzisierungsbedarf im METS-Profil sowie bei der Umsetzung der > Darstellung im Viewer. > > Ja. > > Ciao > Markus