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

21 Apr 2009

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).

Lassen Sie uns das also konkretisieren: Herr Meyer hat hier vor einiger Zeit ein Beispiel
geposted, das er wohl auch zur Implementierung des Viewers verwendet hat:

  http://digital.slub-dresden.de/Band.xml

Hier besitzt die Überordnung (mehrbändiges Werk) keine DMDID und ADMID (samt
korrespondierender dmdSec und amdSec), nur der Band hat solche. Das ist konsequent
gedacht, funktioniert aber bei Zeitschriften nicht recht. Dazu ein Beispiel aus einem
unserer Anwendungskontexte:

  http://www.dilibri.de/oai/?verb=GetRecord&metadataPrefix=mets&ident…

Hier besitzt die Überordnung (Zeitschrift) DMD und ADMID (samt korrespondierender dmdSec
und amdSec), der Band hat "nur" eine DMDID (samt korrespondierender dmdSec). 

...
  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

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