Lieber Herr Enders, auch, wenn das wohl tatsächlich unter dem Label "Viewer 3.0" zu fassen sein wird, möchte ich diesen Beitrag nochmal unter neuem Subject aus dem Gestrüpp der Diskussionsfäden reißen, da hier m.E. eine Reihe von interessanten Aspekten berührt werden: Das ist aus meiner Sicht der Kern der Überlegungen, die hier anzustellen sind (aus technischer Sicht): Wir haben m.E. zu unterscheiden zwischen den Aspekten der "Standardisierung/Homogenisierung/Interoperabilität" und den Aspekten der Funktionalitäten, die sich daraus ableiten. Den letzten Aspekt haben wir im Rahmen unserer Diskussionen bislang gar nicht behandelt. Die Viewer-Implementierung adressiert diese Zusammenhänge, soweit ich das Übersehen kann, bislang überhaupt nicht, sprich: für den Viewer sind alle Typen gleich (was auch aus meiner Sicht die konsequente Umsetzung dessen ist, was wir abgestimmt haben, von daher also ein Feature, kein Bug ;). Dem kann ich mich nur anschließen. Ja, das könnte er. Soweit ich das ausgetestet habe, zeigt der Viewer alles an, was ihm an Strukturhierarchien in einer METS-Datei "untergeschoben" wird. Damit kann man ganz interessante Effekte erzeugen - und das war auch ein Grund, warum ich die Darstellung der Strukturdaten auf der rechten Seite mit einem gewissen Argwohn betrachte: man scrollt sich hier u.U. einen Wolf, wenn man ein recht komplexes Inhaltsverzeichnis abbilden möchte. Das ist dann alles andere als übersichtlich und sinnvoll nutzbar. Von daher passen wir z.Z. auch die Lieferung unserer METS-Container bei komplexen Werken so an, daß sie mit der aktuellen Implementierung (und nichts anderes haben wir) einigermaßen sinnvoll nutzbar sind. Das bedeutet aber eben: wir nutzen die Granularität der METS-Dateien, die geliefert werden, da wir keine funktionale Sicht auf die Strukturtypen im Viewer vorfinden. Ebenfalls ein wichtiger Aspekt! Und auch hier gilt: in der aktuellen Implementierung ist man gezwungen, die MODS-Daten dynamisch so aufzubereiten, daß man bei der Navigation z.B. durch eine Zeitschrift tatsächlich auch erkennen, wo man sich gerade befindet. Naja, einen Testcase (aus den Zeitschriften der Deutschen Morgenländischen Gesellschaft) hatte ich ja bereits geliefert... Hm, das ist natürlich ein etwas gewagter Ansatz. Und ich glaube auch nicht, daß das ein technisch sinnvolles Konzept sein kann, auch wenn ich nicht bestreiten würde, das mancher Anwender das so sehen mag. Aus meiner Sicht ist das Thema aber bereits adressiert, da wir auf unserer letzten Sitzung in Halle besprochen hatten, daß der Viewer um einen technischen Validator ergänzt werden wird, der einem Entwickler die Informationen mitgeben wird, die er braucht, um eine konkrete Implementierung debuggen zu können. Das finde ich einen guten Ansatz. Ich hatte bislang eher dazu tendiert, das in <mets:digiprovMD> unterzubringen, aber da paßt es nicht wirklich rein. Oder Gadamer-Texte in unterschiedlichen Geschwindigkeiten vorlesen. ;) Das sieht auf den ersten Blick sehr interessant aus! Ich teile aber mit Herrn Stäcker gewisse Vorbehalte gegenüber RDF, habe aber selbst nichts zur Hand, nachdem Herr Stäcker "seine TEI-Taxonomien" hier schnell wieder aus dem Verkehr gezogen hat. Wie gesagt, das muß ich mir noch etwas genauer anschauen und vielleicht finden sich ja noch weitere Vorschläge. Beste Grüße, Kay Heiligenhaus